라인 / postgresql

5 개의 포스트

line

기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다 (새 탭에서 열림)

사양서나 소스 코드를 참조할 수 없는 블랙박스 상태의 레거시 시스템을 내재화하기 위해, Kafka 생태계를 활용한 자동화된 검증 파이프라인을 구축하여 시스템의 동일성을 증명했습니다. 데이터 발생부터 분석까지 이어지는 검증 루프를 통해 불일치 건수를 0으로 수렴시키는 과정을 거쳤으며, 결과적으로 대규모 커머스 데이터를 안전하고 정밀하게 신규 시스템으로 이관할 수 있었습니다. **통합 커머스 검색의 도메인 구조** * **상품과 카탈로그**: 판매자가 등록한 개별 '상품'들을 동일 모델별로 묶어 최적의 정보를 제공하는 상위 객체인 '카탈로그'로 관리하며, 이는 최저가 산출 및 객단가 지표 제공의 핵심이 됩니다. * **수신 파이프라인**: 대규모 상품 데이터를 내부 표준 형식으로 변환하고 정합성을 검사하여 상품 및 카탈로그 정보에 반영하는 거대 파이프라인으로, 서비스 전체에 막대한 영향력을 미칩니다. **무중단 검증 루프의 설계** * **검증 파이프라인 아키텍처**: 트리거(DB 변경/이벤트) → 실행 및 비교(양쪽 시스템에 동일 입력 주입) → 가공 및 적재(불일치 데이터 저장) → 분석 및 개선(오류 패턴 수정)으로 이어지는 유기적인 루프를 생성했습니다. * **입력과 출력의 정의**: 동일한 ID나 스냅숏을 입력값으로 설정하고, API 응답이나 DB 업데이트 결과를 출력값으로 명확히 정의함으로써 내부 로직이 복잡하더라도 통계적으로 동일함을 증명할 수 있는 환경을 만들었습니다. **조회 로직 검증과 블랙박스 분석** * **CDC와 Kafka 기반 비교**: DB의 바이너리 로그를 실시간 스트리밍하는 CDC(Change Data Capture)를 트리거로 사용하고, Kafka를 통해 검증 로직을 물리적으로 격리하여 서비스 성능에 영향을 주지 않으면서 기존/신규 API 응답을 1:1로 대조했습니다. * **재귀적 필드 비교 및 정렬**: 100개가 넘는 API 응답 필드를 `Map<String, Object>` 구조로 변환해 재귀적으로 탐색했으며, 리스트 내 순서 차이로 인한 노이즈를 제거하기 위해 문자열 정렬 후 2차 비교를 수행하는 유연한 로직을 도입했습니다. * **가시성 확보 및 최적화**: ksqlDB를 활용해 실시간으로 이상 징후를 Slack으로 알리고 OpenSearch로 상세 로그를 분석했으며, 처리율 제한(Rate Limit)을 적용해 동일 패턴의 중복 오류가 분석을 방해하지 않도록 제어했습니다. **상태 변화를 다루는 업데이트 로직 검증** * **실시간 시뮬레이션**: 카탈로그 통계 업데이트 시 CDC 이벤트가 발생하면 검증 모듈이 신규 로직으로 예상 결과값을 즉시 산출하고, 이를 기존 로직이 업데이트한 DB의 실제값과 대조하는 시뮬레이션 방식을 채택했습니다. * **비동기 지연 및 트리거 누락 해결**: 비동기 환경의 시차 문제는 'N회차 재시도 큐' 전략으로 해결하고, 특정 필드 변경 시에만 검증이 작동하도록 필터링하여 리소스를 최적화했습니다. 또한 ETL 배치 검증을 병행하여 실시간 스트림에서 놓칠 수 있는 트리거 누락 결함까지 포착했습니다. **성공적인 시스템 전환을 위한 제언** 복잡한 시스템의 내재화는 단순히 코드를 옮기는 것이 아니라 '기존과 동일하게 작동함'을 객관적으로 입증하는 과정입니다. 데이터 스트림 기반의 자동화된 검증 체계를 구축하면 블랙박스 로직의 베일을 하나씩 벗겨낼 수 있을 뿐만 아니라, 실시간 트래픽 환경에서의 성능 비교 지표까지 확보하여 안정성과 성능이라는 두 마리 토끼를 모두 잡을 수 있습니다.

line

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

line

LINE DEV AI 리포터즈의 여정을 공유합니다! (새 탭에서 열림)

LY Corporation은 개인의 AI 활용 경험을 조직 전체의 자산으로 전환하기 위해 'AI 리포터즈'를 결성하고, 단계별 공유 체계를 구축하여 기술적 성장을 도모하고 있습니다. 단순히 도구 사용법을 익히는 데 그치지 않고, 실무 적용 과정에서 겪은 시행착오와 설계 역량의 중요성을 공유함으로써 AI가 기술 부채를 양산하지 않고 생산성 향상으로 이어지게 하는 조직 문화를 마련했습니다. 결국 AI 시대를 맞이하는 개발자에게 필요한 역량은 개별 구현 능력을 넘어 프로젝트 전체를 설계하고 관리하는 '메타 지식'임을 강조하고 있습니다. **가벼운 시도로 시작하는 공유 문화 형성** * 성공 사례에 국한되지 않고 개인의 실험적 시도와 시행착오를 가감 없이 공유하여 AI 도입에 대한 심리적 허들을 낮추었습니다. * Claude Code와 Antigravity를 활용해 하루에 서비스 하나를 제작하는 '바이브 코딩' 실험을 통해 빠른 구현 속도만큼이나 '명확한 명세와 기획'이 중요함을 확인했습니다. * 결과물보다 과정에 집중하는 분위기를 조성하여, 조직원들이 잘해야 한다는 부담 없이 AI를 업무에 우선 적용해 보는 환경을 만들었습니다. **실무 관점의 AI 협업과 기술 부채 관리** * Claude Code를 기반으로 한 달 이상의 실제 프로젝트를 진행하며, AI 에이전트와 협업할 때 개발자의 역할이 '구현'에서 '프로젝트 설계 및 관리'로 변화함을 실증했습니다. * AI 에이전트는 현재의 코드 상태를 기준으로 다음 작업을 수행하기 때문에, 구조 개선이나 리팩토링을 미루면 기술 부채가 평소보다 훨씬 빠르게 증폭된다는 실무적 인사이트를 도출했습니다. * 커밋 전 자동 테스트를 생략했을 때 발생하는 오류 사례를 통해, 에이전트의 결과물을 검증하고 아키텍처를 유지하는 사람의 역할이 더욱 중요해졌음을 공유했습니다. * 작업을 시작하기 전 에이전트가 충돌 없이 일할 수 있도록 환경과 순서를 먼저 정리하는 '계획 단계'의 비중을 높여 일의 흐름을 최적화했습니다. **조직 단위의 워크숍 및 기술 심화 공유** * 기획, 디자인, 개발, 배포를 한 흐름으로 연결하는 '원스톱 실습 워크숍'을 통해 ChatGPT, Claude Code, Stitch AI 등 여러 도구를 맥락에 맞게 결합하는 경험을 전파했습니다. * 'GAI 활용 연구회'를 통해 PyTorch 기반 LLM과 MCP(Model Context Protocol) 서버의 상호작용 구조, JSON-RPC 기반 메시지 설계 및 세션 관리 등 심도 있는 기술적 디테일을 다루었습니다. * FastMCP와 같은 고수준 라이브러리가 감추고 있는 추상화 레이어를 직접 구현해 봄으로써, AI 에이전트 시스템의 내부 작동 원리와 설계 선택지에 대한 깊이 있는 이해를 공유했습니다. **지속 가능한 AI 공유 생태계 구축** * AI 도구와 환경은 끊임없이 변화하므로, 일회성 교육보다는 '자주 시도하고 빠르게 공유하는 문화' 자체가 조직의 핵심 경쟁력이 된다는 점을 시사합니다. * 슬랙(Slack)을 통한 트렌드 공유와 월간 정기 미팅 등 개별 팀의 노하우를 조직의 경험으로 연결하는 구조적 장치를 통해 AI 활용 능력을 지속적으로 내재화할 것을 추천합니다.

line

미래의 클라우드를 창조하다 (새 탭에서 열림)

LY Corporation은 기존의 분산된 인프라와 플랫폼을 통합한 차세대 프라이빗 클라우드 'Flava(플라바)'를 통해 개발자 경험과 보안, AI 기술이 융합된 지능형 플랫폼으로의 진화를 꾀하고 있습니다. 단순히 자원을 제공하는 수준을 넘어 사내의 모든 플랫폼 기능을 하나의 UX로 통합하는 '플라바이제이션'과 강력한 보안 거버넌스 위에서도 높은 사용성을 유지하는 '실용적 보안' 구축을 핵심 목표로 설정했습니다. 나아가 AI를 인프라 운영과 아키텍처 설계에 접목하여 자연어만으로 클라우드를 관리할 수 있는 인텔리전트 환경을 실현함으로써 2~3년 내에 고도화된 클라우드 생태계를 완성할 계획입니다. ### 통합 플랫폼으로의 진화, 플라바이제이션(Flavaization) * 현재 DB, 컨테이너 등으로 파편화된 사내 플랫폼들의 권한 관리, 로깅, 모니터링, 빌링, API/CLI 등을 하나의 통합 클라우드 UX로 일원화하는 작업을 진행 중입니다. * 개발자가 각 플랫폼의 개별 사용법과 승인 프로세스를 일일이 익힐 필요 없이, 통합된 환경에서 모든 인프라 자원을 효율적으로 제어할 수 있는 환경을 1~2년 내 완수하는 것이 목표입니다. ### 강력하면서도 사용성 높은 실용적 보안 구축 * 기획 단계부터 보안 조직(CISO)과 협업하여 데이터 등급(기본, 기밀, 최고 기밀)별로 리소스를 분리하고 사내 보안 거버넌스를 기술적으로 자동 구현했습니다. * 리소스 생성은 수분 내로 단축되었으나, 이후의 접근 권한 승인 절차(VDI, 데이터 교환 폴더 생성 등)에서 발생하는 병목 현상을 최적화하여 보안성과 개발 속도의 균형을 맞추고자 합니다. * 강화된 VPC ACL(접근 제어 리스트)로 인한 네트워크 지연 시간을 개선하여, 메시징 서비스처럼 응답 속도가 중요한 애플리케이션 요구사항을 충족시키는 기술적 고도화를 병행합니다. ### 데이터 폭증에 대응하는 스토리지 및 하위 레이어 기술 * 사용자의 멀티미디어 데이터(사진, 영상 등)가 지속적으로 증가함에 따라 비용 효율적이면서도 합리적인 접근 속도를 보장하는 스토리지 계층화 기술을 확보하고 있습니다. * AI 워크로드의 대규모 데이터 처리를 위해 고속 네트워크 기술인 DPU(Data Processing Unit), 스마트 NIC, 초고속 NVMe 기반 스토리지 자동 계층화 등 하드웨어 및 인프라 하부 레이어의 최적화에 집중합니다. ### AIOps 및 인텔리전트 클라우드로의 도약 * MCP(Model Context Protocol) 서버 관리, 벡터 DB, AI 관측 가능성(Langfuse 등) 플랫폼을 사내 규정에 맞게 공통 서비스로 제공하여 개발팀의 AI 도입을 지원합니다. * 사용자가 자연어로 요구사항을 입력하면 AI가 최적의 아키텍처를 제안하고 인프라를 자동 구축하는 '인텔리전트 클라우드'로 진화하고 있습니다. * 저사용 리소스 탐지, 비용 최적화 제안, 암호화되지 않은 개인정보 탐지, OSS 취약점 관리 등 과거 엔지니어가 수동으로 수행하던 운영 업무를 AI 챗봇이 대신 수행하는 환경을 프로토타이핑 중입니다. Flava는 단순한 도구 제공자를 넘어 하위 레이어의 인프라 기술력과 상위 레이어의 AI 지능을 결합하여, 누구나 쉽고 안전하게 대규모 시스템을 운영할 수 있는 환경을 지향합니다. 향후 2~3년 내에 실현될 이러한 변화는 개발자가 복잡한 인프라 관리보다는 서비스 본연의 가치에 집중할 수 있게 만드는 실질적인 기술 동력이 될 것으로 보입니다.

line

Scaling to Infinity: 한계를 넘어서는 LY Corporation의 관측 가능성 플랫폼 진화기 (새 탭에서 열림)

LY Corporation은 수만 대의 서버와 컨테이너 환경에서 발생하는 일간 수조 건의 지표를 효율적으로 처리하기 위해 독자적인 시계열 데이터베이스(TSDB)를 개발하여 운영하고 있습니다. 초기 MySQL과 OpenTSDB의 한계를 극복하고자 인메모리(IMDB), Cassandra, S3를 결합한 다중 계층 저장소 아키텍처를 구축함으로써 데이터 폭증에 유연하게 대응하고 있습니다. 이를 통해 개발자와 운영자가 인프라 관리 부담 없이 서비스의 건강 상태를 즉각적으로 파악하고, 향후 AI 기반의 지능형 관찰가능성 플랫폼으로 진화하는 것을 목표로 합니다. **시계열 데이터의 규모와 저장소의 중요성** * **기하급수적인 데이터 증가:** 서버 1대의 CPU 지표(15초 주기)는 연간 약 562 MiB를 차지하며, 수천 대 규모의 인프라에서는 연간 테비바이트(TiB) 단위의 저장 공간이 필요합니다. * **고해상도 데이터의 필요성:** 장애 징후를 사전에 포착하고 정밀하게 모니터링하기 위해 1분 미만의 고해상도 지표 수집이 필수적이지만, 이는 범용 데이터베이스에 엄청난 쓰기 부하를 줍니다. * **클라우드 네이티브의 복잡성:** 쿠버네티스 환경에서는 파드(pod)의 잦은 생성과 소멸로 인해 관리해야 할 대상(Cardinality)이 폭증하며, 이를 수용할 유연한 스키마 구조가 요구됩니다. **자체 시계열 데이터베이스 엔진 개발 과정** * **기존 솔루션의 한계:** MySQL은 쓰기 성능과 경직된 스키마 문제로, OpenTSDB는 태그 개수 제한 및 문자열 제약, 쿼리 전 웜업(warm-up) 필요성 등의 운영상 한계가 있었습니다. * **Gorilla 논문 기반 최적화:** 데이터 조회의 85%가 최근 26시간 이내에 집중된다는 점에 착안하여, 최근 데이터는 IMDB에 저장하고 과거 데이터는 디스크 기반 저장소로 보내는 전략을 수립했습니다. * **사용자 편의성 유지:** 백엔드 아키텍처를 근본적으로 교체하면서도 기존 API와의 호환성을 완벽히 유지하여, 사용자가 코드 수정 없이도 성능 향상의 혜택을 누리게 했습니다. **데이터 홍수에 대응하는 계층형 저장 구조** * **가중치 기반 부하 분산:** 서로 다른 스펙의 노드가 혼재된 환경에서도 성능을 극대화할 수 있도록 IMDB의 부하 분산 알고리즘을 개선했습니다. * **S3 기반의 하이브리드 저장소:** 고성능 처리가 필요한 최근 14일치 데이터는 Cassandra에, 그 이전의 방대한 데이터는 비용 효율적인 S3 호환 저장소에 적재하는 3단계 계층 구조를 도입했습니다. * **데이터 파이프라인 최적화:** IMDB의 데이터를 슬롯 단위로 읽어 블록화하여 S3에 저장하는 '덤퍼(Dumper)'와, 읽기 성능을 위해 디스크 캐싱을 수행하는 'Storage Gateway'를 구축했습니다. **기술적 난관 극복과 협업의 성과** * **메모리 고갈 문제 해결:** 스토리지 게이트웨이의 I/O 과정에서 페이지 캐시 점유율이 급증하는 문제를 발견하고, 직접 I/O(Direct I/O) 대신 커널 페이지 캐시를 효율적으로 쓰는 B+ 트리 기반 캐시로 전환했습니다. * **부서 간 협업:** 직접 I/O 적용 시 발생할 수 있는 클라우드 스토리지 대역폭 문제를 유관 부서와 긴밀히 소통하여 조기에 파악하고 최적의 해답을 도출했습니다. 대규모 시스템의 관찰가능성을 확보하기 위해서는 데이터의 접근 패턴에 맞춘 계층형 저장소 설계가 필수적입니다. 단순한 저장소 확장을 넘어, 파편화된 데이터를 통합하고 AI를 활용한 예측 모델을 결합함으로써 시스템의 안정성을 선제적으로 관리하는 지능형 플랫폼으로 나아가야 합니다.