테크 뉴스
테크 뉴스 더 보기
기술 블로그

FastAPI에 모듈화된 구조 적용을 통한 빠른 프로토타이핑
오늘은 FastAPI와 SQLite를 사용하여 간단한 사용자 정보 관리 기능을 구축하고, 프로젝트를 모범 사례에 맞게 그리고, Fast라는 말에 걸맞게 신속하게 모듈화하는 과정을 공유해보려 합니다.이 글에서는 FastAPI의 주요 기능들을 활용해 어떻게 프로젝트 구조를 만들 수 있는지에 관한 간단한 예시를 소개합니다.이 프로젝트 구조는 API 엔드포인트(api/)와 데이터베이스 연동(db/, crud/)을 모듈화하여 관리합니다.• None 모델 정의는 models/에,• None 데이터 검증용 스키마는 schemas/에 분리하여 코드의 가독성과 유지 보수성을 높였습니다.• None 최상위 main.py는 FastAPI 애플리케이션을 초기화하고 라우터를 등록하는 역할을 합니다.이제, 각 모듈이 어떤 역할을 하는지 자세히 살펴보겠습니다.SQLite 데이터베이스를 설정하기 위해 파일을 작성했습니다.여기서는 함수를 통해 **의존성 주입(Dependency Injection)**을 사용하여 데이터베이스 세션을 주입합니다.2) 데이터베이스 모델 정의 (models/user.py)사용자 테이블을 정의하기 위해 파일을 작성했습니다.입력과 출력을 검증하기 위해 Pydantic 모델을 사용했습니다.데이터베이스와 상호작용하는 CRUD 함수들을 에 정의했습니다.에서는 사용자 관련 API를 정의했습니다.파일에서 FastAPI 애플리케이션을 생성하고 라우터를 등록합니다.서버 기동에 필요한 패키지를 배포합니다.이제 모든 준비가 끝났습니다! FastAPI 서버를 실행해서 API의 동작을 확인해 볼 수 있습니다.• None 모듈화된 프로젝트 구조의 중요성 🚀• None , , , , 로 기능을 분리하여 코드 가독성과 유지 보수성을 크게 향상할 수 있습니다. 모듈화를 통해 재사용성과 확장성이 극대화되었으며, 추후 기능 추가나 데이터베이스 변경이 용이한 구조를 갖추었습니다.• None• None 의존성 주입(Dependency Injection)을 사용해 데이터베이스 세션을 안전하게 관리하고, Pydantic을 활용해 입력 데이터 검증을 강화할 수 있습니다.• None SQLite와 SQLAlchemy를 통한 빠른 프로토타이핑 💡• None SQLite를 사용해 빠르게 데이터베이스 설정을 완료하고, SQLAlchemy로 ORM 방식을 적용해 데이터베이스 관련 처리를 직관적이고 효율적으로 구성할 수 있습니다.• None API 설계와 예외 처리의 중요성 🛡️• None RESTful API 원칙을 준수하며, FastAPI의 HTTPException을 활용해 에러 처리를 구조화했습니다. 이를 통해 명확한 에러 메시지 제공으로 사용자 경험을 개선할 수 있습니다.• None• None FastAPI의 자동 Swagger 문서 생성을 통해 API 테스트를 효율적으로 진행할 수 있었고, 을 사용해 빠르게 서버를 실행해 개발 속도를 높일 수 있습니다.
SK텔레콤
·
오늘

RAG를 활용한 검색 서비스 만들기
안녕하세요! 당근 검색품질팀 ML 엔지니어 해리예요. 👋이 글에서는 RAG를 활용한 검색 서비스인 “동네생활 기반 동네업체 추천” 기능 구현에 사용된 기술에 대해 이야기해보려고 해요.혹시 활동하고 있는 커뮤니티가 있으신가요?커뮤니티는 고향을 떠나 먼 곳으로 대학을 진학한 제게 절대 없어서는 안 될 정보의 창구였어요. 대학 새내기 시절을 돌아보면, 낯선 학교 근처의 맛집이나 듣기 좋은 꿀강의들을 찾기 위해 교내 커뮤니티 게시판을 열심히 뒤지던 기억이 새록새록 떠올라요. 대학원 진학을 준비할 때는 대학원생 커뮤니티에서 각 랩실의 정보를 얻기도 했죠.이처럼 커뮤니티는 우리 생활과 밀접한, 신뢰도 높은 정보들로 가득해요. 하지만 이런 정보들이 여러 게시글에 흩어져 있다 보니, 사용자는 정보를 모으기 위해 다양한 키워드로 검색하고 많은 게시글을 일일이 확인해야 하는 불편함이 있어요.이러한 정보 검색의 불편함은 당근의 동네 커뮤니티인 동네생활에서도 마찬가지였어요. 동네생활에는 “과잉 진료 없는 치과”, “탈색 잘하는 미용실”, “마카롱이 맛있는 카페” 등 동네 이웃들만이 알 수 있는 신뢰도 높은 업체 정보들이 가득하죠. 하지만 이런 정보들이 여러 게시글과 댓글에 흩어져 있어서, 사용자는 1) 적절한 검색어를 입력하고, 2) 게시글과 댓글 내용을 모두 확인하고, 3) 얻은 정보를 취합하는 과정을 거쳐야 해요.이 글에서는 이런 불편을 해결하고자 RAG를 활용해 “동네생활 기반 업체 추천” 서비스를 만들었던 과정을 자세히 소개해보고자 해요.당근 동네생활의 검색은 어떻게 개선될 수 있을까요?이 질문에 답하기 위해 먼저 유저들의 동네생활 검색 패턴을 분석했어요. 분석 결과, 유저들은 동네생활에서 주변 업체 정보를 활발하게 찾아보고 있었어요. 특히 “용달”, “24시 동물병원”과 같은 동네 업체 관련 검색어가 실제 상위 검색어들 중 큰 비중을 차지했죠.하지만 기존 검색 시스템으로는 이런 정보를 효율적으로 찾기가 어려웠어요. 기존에는 당근에 업체 관련 검색어를 입력하면, 그와 관련된 당근 등록 업체들을 최상단에 보여줬어요. 예를 들어, “치과”라는 검색어가 입력되면 사용자의 동네에 등록된 치과들을 검색 결과로 보여준 거죠.물론 “치과”라는 검색어에 치과를 보여주는 것이 틀린 검색 결과라고 볼 수는 없지만, 이 방식으로는 유저의 니즈를 제대로 충족하기 어려워요. 유저들은 “우리 동네 주민들이 추천한 알짜배기 업체”들을 발견하기를 원하는데, 현재 검색은 단순히 “관련 업체 프로필”들을 최상위로 노출하는 데 그치고 있거든요. “유저가 정말 원하는 동네업체 정보는 동네생활에 있다”는 점을 고려하면, 현재 검색에는 동네생활과 동네업체 간의 정보들을 서로 연결해 주는 도구가 없는 셈이에요.이런 문제를 해결하기 위해 우리는 동네생활 검색 시스템을 개선하기로 했어요. 유저들이 원하는 업체 관련 정보를 동네생활에서 더 쉽고 빠르게 찾을 수 있도록 돕는 것이 핵심이었죠. 그래서 RAG(Retrieval Augmented Generation) 기술을 활용해 동네생활의 정보와 업체
당근
·
오늘

Spring 기반 멀티모듈 프로젝트 환경변수 설정 방법
roy.ce 카카오페이 서버 개발자가 알려주는 Spring 멀티모듈 환경변수 설정 노하우! 멀티모듈 프로젝트의 복잡성을 줄이고 효율적인 환경 설정을 원한다면 꼭 읽어보세요!zeta.wan 멀티모듈을 잘 활용하면 불필요한 설정을 최소화할 수 있다는 것을 느꼈습니다. 글을 읽는 여러분도 더 나은 방식이 무엇일지 고민하는 시간이 되면 좋겠습니다.안녕하세요. 파트너플랫폼파티에서 서버 개발을 하고 있는 그루(Geuru)입니다. 카카오페이에서는 Spring 기반 멀티모듈 프로젝트로 서비스를 개발하고 있습니다. 그 이유는 요구사항이 여러 가지 추가되면서 특정 목적을 위한 애플리케이션이 필요하거나, 도메인의 확장에 따라 모듈을 추가하기 때문입니다. 모듈을 추가함에 따라 각 모듈별로 필요한 환경변수 설정을 위해 yml 또는 properties 파일을 작성하고 있습니다.입사하고 파트너 도메인에 익숙해지기 위해 여러 프로젝트를 리뷰하면서 알게 된 사실이 있습니다. 팀 내 프로젝트마다 환경변수 설정하는 방법이 미묘하게 다르다는 사실입니다. 더 크게는 팀마다 환경변수 설정하는 방법이 다르고, 취향 차이도 있다는 것입니다.이번 글에서는 제가 사내 여러 프로젝트를 경험해 보면서 알게 된 환경변수 설정방법은 어떤 것들이 있는지 소개해보려고 합니다. 먼저 멀티모듈에서의 환경변수 설정 고민을 말씀드리고, 그 고민을 해결할 수 있는 환경변수 설정 방법 4가지를 알려드리려고 합니다. 그래서 최종적으로 저희는 그 4가지 방법 중 어떤 방법을 선택했으며, 그 이유는 무엇인지 말씀드리려고 합니다.이 글을 읽으시는 독자분께서는 각자의 프로젝트의 환경변수 설정 방법과 본 글에서 소개하는 설정방법을 비교해 보면서, 본인은 어떤 방식을 적용하고 있는지 알아보고 싶은 분들께 이 글을 추천합니다. 또, 이것 외에 다른 방법이 있으면 코멘트도 남겨주세요 😀멀티모듈의 정의와 장점멀티모듈 프로젝트는 여러 개의 모듈로 구성된 프로젝트로, 각 모듈은 독립적으로 빌드되고 배포될 수 있습니다. 멀티모듈로 프로젝트를 구성하는 이유는 코드의 재사용성을 높이고, 모듈 간의 의존성을 명확히 하여 유지보수성을 향상하기 위함입니다.예를 들어, 위와 같이 머니 송금 API를 사용하는 internal-api(사내용 API 모듈), external-api(서비스용 API 모듈)가 있다고 가정하겠습니다. 만약 internal-api, external-api가 각각 단일 모듈로 프로젝트를 구성한다면, 각 프로젝트마다 머니송금용 RestTemplate과 HttpClient 코드와 같은 구현체를 두 번이나 작성하게 될 것입니다.같은 코드 작성 두 번 정도야 할 수 있습니다. 유지보수하거나 신규 서비스 개발 시에는 어떨까요? 만약 머니 송금 API를 사용하는 admin-api(운영자용 API 모듈) 같은 애플리케이션이 늘어난다면, 한 번 더 구현체를 작성해야겠죠? 또, API 버전이 V1에서 V2로 변경되는 스펙 변경이 발생한다면 각 프로젝트마다 해당 내용을 반영해야 합니다.아까 말씀드린 상황을 해결하기 위해 멀티모듈로 구성
카카오페이
·
오늘

AI 학습을 위한 LLM 스터디 - 배치 전략 및 어텐션 개선 방안
LLM에 대해 아무것도 모른채로 공부하고 싶은 마음에 LLM 스터디 (딥그라운드)에서 좋은 기회로 이렇게 제가 공부한 부분에 대해 정리 하게 되었습니다.사실 AI라는 분야가 워낙 방대해서 처음에는 어디서부터 시작해야 할지 막막했어요.하지만 조금씩 공부하다 보니 재미있는 부분들이 많이 보이더라구요.부족한 점이 많겠지만, 저와 비슷한 초보자 분들에게 조금이나마 도움이 되었으면 좋겠어요.• None 입력 데이터 추론 시, 한번에 많은 데이터를 받으면 좋겠지만, 한번의 하나씩 토큰을 생성하고 입력에 따라 몇의 토큰을 추가할 지 예상하기 어려워 데이터 처리에 전략이 필요하다.• None 일반배치, 또는 정적배치는 전통적인 배치 처리 방식입니다. 이 방법은 고정된 크기의 입력 배치를 한 번에 처리합니다 하지만 이 방식에는 몇 가지 단점이 있습니다:• None 배치 내 각 요청이 서로 다른 수의 완료 토큰을 생성할 수 있어 실행 시간이 달라집니다.• None 모든 요청은 가장 긴 요청이 완료될 때까지 기다려야 합니다.• None 생성 길이의 큰 차이로 인해 성능이 저하될 수 있습니다.• None 동적배치는 정적배치의 단점을 보완하기 위한 방법입니다. 이 방식은 입력의 길이와 복잡성에 따라 배치 크기를 동적으로 조정합니다. 이를 통해:• None 다양한 길이의 입력을 효율적으로 처리할 수 있습니다.• None 연속배치, 또는 인-플라이트 배칭은 정적배치의 문제를 해결하기 위한 또 다른 접근 방식입니다. 이 방법의 특징은:• None 요청이 도착하는 대로 처리를 시작합니다.• None 진행 중인 요청과 새로운 요청을 동적으로 결합합니다.• None 각 요청의 완료 시간을 개별적으로 관리합니다. 이 방식을 통해 대기 시간을 줄이고 전체적인 처리량을 향상시킬 수 있습니다.플래시 어텐션(FlashAttention)은 트랜스포머 모델의 핵심 요소인 어텐션 메커니즘을 크게 개선한 혁신적인 알고리즘입니다.이 기술은 대규모 언어 모델(LLM)과 긴 컨텍스트를 다루는 애플리케이션에서 성능 병목 현상을 해결하는 데 중요한 역할을 합니다.• None 입력 준비: 입력 시퀀스를 세 개의 벡터로 변환합니다 - 쿼리(Q), 키(K), 값(V).• None 유사도 계산: 쿼리와 키 사이의 유사도를 계산합니다. 이는 두 벡터의 내적(dot product)으로 이루어집니다.• None 스케일링: 유사도 점수를 키의 차원의 제곱근으로 나눕니다. 이는 값이 너무 커지는 것을 방지합니다.플래시 어텐션은 다음과 같은 핵심 원리를 바탕으로 작동합니다:• None 메모리 최적화: 어텐션 연산을 재배치하고 타일링 기법을 사용하여 메모리 사용량을 시퀀스 길이에 따라 제곱에서 선형으로 줄입니다.• None 타일링 기법: GPU의 주 메모리(HBM)에서 빠른 캐시(SRAM)로 입력 데이터 블록을 로드하여 처리합니다. 중간 결과 최소화: 큰 중간 어텐션 행렬을 HBM에 저장하지 않아 메모리 읽기/쓰기를 줄입니다.• None 재계산 활용: 필요한 경우 중간 결과를 재계산하여 메모리 사용을 줄입니다.•
SK텔레콤
·
하루 전

FE News 25년 2월 소식을 전해드립니다!
주요내용25년 2월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser FingerprintingJavascript와 Cookie 없이 CSS만으로 브라우저 지문 채취의 가능함이 증명되었습니다The Ai-Assisted Developer Workflow: Build Faster and Smarter TodayAI를 활용한 다양한 개발 도구가 어떻게 개발 방식을 변화시킬 수 있는지 알아봅니다.Toss Frontend Fundamentals토스의 프런트엔드 개발자들이 공개한 변경하기 쉬운 프론트엔드 코드를 위한 지침서Do JavaScript frameworks still need portals?Dialog, popover, CSS anchor positioning 등의 기능으로 Portal(React), Teleport(Vue) 를 대체하는 방법을 소개합니다.>> FE News 25년 2월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다.매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다.▷ 구독하기
네이버
·
2일 전

물류의 물짜도 모르던 OMS PM의 OMS 구축기
물류의 물짜도 모르던 OMS PM의 OMS 구축기컬리의 OMS (Order Management System)의 Product Manager로 일하고 있는 염태환입니다.2022년 1월 OMS라는 팀이 컬리에서 처음으로 생기고, 제가 해당 도메인의 첫 PM 역할을 하면서 해당 시스템이 과거 어떤 모습으로 존재했고 현재까지 어떻게 진화해왔는지, 그리고 PM으로써 어떤 과정을 통해 OMS가 진화되었는지 자식처럼 아끼고 성장시켰던 PM의 관점에서 내용을 소개드리겠습니다.1. 현재를 모르면 미래도 없다: As-Is 먼저 명확히 파악하기2022년 1월 회사에 처음으로 OMS라는 팀이 생기고 제가 첫 OMS의 PM을 맡았을 때 OMS는 SOMS(Sales Order Management System)라고 불리우고 있었습니다.당시 제가 받은 느낌은, 이 시스템이 불빛 하나 없는 안개 속에 혼자 서 있는 듯 했습니다.이 시스템의 목적이 무엇인지, 현재 어떤 상태인지 명확히 정의한 문서를 거의 찾을 수 없기 때문이었죠.특히 github에서 모든 코드를 다 읽고 분석할 수 없는 PM의 입장에서는, 이 안개를 걷어내기 위해서는 스스로 질문을 나열해야 했습니다.그때 당시 제가 스스로 나열했던 질문은 아래와 같았습니다.• SOMS가 연동하고 있는 시스템은 어떤 것들이 있는가?• 해당 시스템과 어떤 데이터를 주고 받고 있는가?• 주고 받는 데이터의 주기가 어떠한가?• SOMS가 직접 판단하고 생성하는 데이터는 어떤 것들이 있는가?• 그 데이터가 운영과 사용자에 미치는 영향은 무엇인가?• SOMS가 판단하고 생성하는 데이터라면 어떤 근거로 판단되고 있는가?• SOMS가 현재 갖추고 있는 기능은 무엇인가?• 현재 SOMS를 누가 사용하고 있는가? (사용자 및 이해관계자 리스트업)• 해당 사용자가 어떤 업무를 위해 어떤 목적으로 어떤 기능들을 사용하고 있는가?위 질문에 명확히 답을 얻는 과정은 매우 중요했습니다.현 상태를 그릴 수 없으면 앞으로 우리가 설정해야할 Product Vision도 설정할 수 없기 때문이었죠.2. 데이터를 파악하며 도메인 지식을 넓히다: 거미줄처럼 얽혀있는 데이터들SOMS는 현재도 그렇지만, 당시에도 거미줄처럼 얽힌 시스템이 많았습니다.커머스 주문시스템, 배송시스템(TMS), 권역관리시스템(TAM), 생산처리시스템(WMS), 배송대행시스템(TOMS)등 연동되고 있는 시스템만 5개가 넘었죠 (현재는 더 많습니다).각 시스템의 이해관계를 파악하기 위해서라도 각 시스템들과 어떤 데이터를 어떤 방식으로 어떤 주기로 연동받는지 PM으로써 저도 파악하고 있어야했습니다.아직도 기억에 남는 것이 여러 데이터 중 배송회차라는 데이터가 있었는데(현재도 있고), 고객의 주문이 “몇 배송회차로 배송되어야하는지” 판단하는 방식은 이러했습니다.이러한 과정을 통해 물류 지식이 많지 않았던 제가 도메인 지식이 점점 넓어지는 것을 느꼈고, 다양한 데이터들의 의미를 알 수 있었습니다.• 배송회차마다 주문마감시간과 출차마감시간이 정해져있다.• 출차시간이 달라지면 고객에게 배송되는
마켓컬리
·
2일 전
기술 블로그 더 보기
테크 뉴스
테크 뉴스 더 보기
코드너리에서 이용할 수 있는
새로운 기능
새로운 기능
지금 확인해 보세요!

이달의 컨퍼런스
컨퍼런스 일정 더 보기