라인 / k8s

LY Corporation의 클라우드 인프라 개편: 거대한 두 개의 클라우드를 통합한 차세대 플랫폼 Flava의 아키텍처 소개 (새 탭에서 열림)

LY Corporation은 기존의 'Verda'와 'YNW'로 나뉘어 있던 프라이빗 클라우드 인프라를 차세대 기반인 'Flava'로 통합하며 대규모 트래픽을 효율적으로 수용하고 있습니다. 이 과정에서 '장애를 전제로 한 설계'와 '소프트웨어 정의 기술'을 핵심 철학으로 삼아, 전용 장비에 의존하지 않고 범용 하드웨어의 성능을 극한으로 끌어올리는 아키텍처를 구현했습니다. 단순히 오픈소스를 사용하는 수준을 넘어 업스트림 기여와 자체 개발을 병행함으로써, 지속 가능한 운영 체계와 고성능 인프라 환경을 동시에 확보하는 것이 이번 통합의 핵심 결론입니다. **장애를 전제로 한 설계와 운영 철학** * **무상태성(Statelessness) 추구:** VM의 루트 디스크를 임시 저장소로 정의하고 영속 데이터는 외부 스토리지로 분리하여, 인스턴스 장애 시에도 서비스 영향을 최소화하고 즉각적인 재구축이 가능하도록 설계했습니다. * **애플리케이션 주도 가용성:** 인프라가 모든 신뢰성을 책임지는 대신, 애플리케이션 계층의 구성과 조합하여 전체 시스템의 가용성을 확보함으로써 인프라 단의 복잡성을 제거했습니다. * **신속한 복구 중심 운영:** 장애 발생 시 원인 규명보다 IaC(Infrastructure as Code)를 통한 환경 재구축을 최우선으로 하며, AZ(Availability Zone) 단위 배포를 통해 장애 영향 범위를 국소화합니다. **소프트웨어 정의 기술과 OSS 생태계 기여** * **업스트림 추종 아키텍처:** OpenStack, Ceph 등의 오픈소스를 독자적으로 커스터마이징하는 대신, 필요한 기능 개선안을 직접 업스트림에 커밋하여 유지보수 비용을 절감하고 기술적 최신성을 유지합니다. * **범용 하드웨어 성능 극대화:** x86 서버 위에서 XDP(eBPF)를 이용한 고속 데이터 플레인을 구현하고 하드웨어 오프로드를 활용하여, 고가의 전용 장비 없이도 와이어 스피드에 가까운 저지연 처리를 실현했습니다. * **자체 개발(Full Scratch) 역량:** 오픈소스만으로 해결하기 어려운 과제는 직접 개발합니다. HDD 효율을 극대화한 오브젝트 스토리지 'Dragon'이나 Rust/Go 기반의 SDN 컨트롤 플레인이 대표적입니다. **차세대 클라우드 Flava의 주요 개선 사항** * **단일 리소스 풀 통합:** 기존의 용도별 전용 환경을 폐지하고 거대한 단일 리소스 풀로 전환하여, 용량 관리의 복잡성을 해소하고 자원 활용 효율을 극적으로 높였습니다. * **VPC 기본화 및 보안 강화:** 모든 테넌트에 VPC(Virtual Private Cloud)를 기본 적용하여 논리적 격리를 강화했으며, 기존에 수개월이 걸리던 보안 환경 구축 시간을 단 몇 분으로 단축했습니다. * **자율적 비용 최적화:** 개발 환경 리소스에 유효 기간(Lifetime) 설정을 강제하여 유휴 자원을 자동 삭제하고, 접근 빈도에 따라 스토리지 클래스를 동적으로 변경할 수 있는 기능을 제공합니다. **관찰 가능성 및 자율 운영 체계** * **거시적·미시적 모니터링:** Prometheus와 자체 대시보드로 전체 트렌드를 파악(숲)하는 동시에, 커널 레벨 트레이스와 패킷 캡처를 통해 근본 원인을 심층 분석(나무)하는 도구 체계를 갖췄습니다. * **하드웨어 자율 운영:** 수만 대의 서버에서 발생하는 하드웨어 고장을 감지부터 교체 요청, 재투입까지 자동화했으며, 향후 LLM을 도입해 예외적인 고장 패턴까지 대응할 계획입니다. 성공적인 차세대 인프라 전환을 위해서는 기술적 고도화뿐만 아니라, 인프라를 블랙박스로 취급하지 않고 내부 동작을 깊이 이해하려는 팀 문화가 필수적입니다. 특히 기존 레거시 환경에서 신규 플랫폼인 Flava로의 마이그레이션 비용을 최소화하기 위해 사용자의 수동 대응을 줄여주는 투명한 이전 도구 개발에 집중할 것을 권장합니다.

엔터프라이즈 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가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

Claude Code Action: 조직 전반의 코드 품질을 지키는 AI 코드 리뷰 플랫폼화 (새 탭에서 열림)

LINE NEXT는 조직의 성장에 따른 코드 리뷰 품질 편차를 줄이고 개인 단위로 파편화된 AI 도구 활용을 조직 차원의 표준으로 통합하기 위해 Claude Code를 활용한 플랫폼화된 코드 리뷰 시스템을 구축했습니다. GitHub Actions를 기반으로 설계된 이 시스템은 리뷰 기준과 실행 로직을 중앙에서 관리함으로써 수많은 프로젝트에 일관된 품질의 피드백을 신속하게 제공합니다. 결과적으로 개별 팀의 운영 부담은 최소화하면서 보안과 거버넌스가 강화된 자동화된 리뷰 환경을 전사적으로 확산시키는 성과를 거두었습니다. ### AI 코드 리뷰 플랫폼화의 배경과 목적 * **품질 편차 해소:** 조직 규모가 커짐에 따라 리뷰어의 경험과 성향에 따라 달라지는 코드 리뷰의 깊이와 관점을 조직 차원에서 일관되게 유지할 필요가 있었습니다. * **개인 도구의 한계 극복:** 개별 개발자가 로컬에서 AI를 사용할 때 발생하는 리뷰 기준의 상이함, 프로세스 단절, 신규 구성원 온보딩의 어려움을 해결하고자 했습니다. * **DevOps 관점의 표준화:** 파편화된 품질 프로세스를 하나로 묶어 PR(Pull Request) 워크플로에 자연스럽게 녹아드는 '표준 구성 요소'로 재정의했습니다. ### GitHub Actions 기반의 통합 전략 * **기존 흐름 유지:** LINE NEXT의 표준 소스 관리 도구인 GitHub와 CI/CD 도구인 GitHub Actions를 활용하여 개발자의 학습 비용을 낮추고 기존 워크플로에 즉시 통합했습니다. * **인프라 운영 효율화:** DevOps 팀이 공통 GitHub App Runner 환경을 제공함으로써, 각 서비스 팀은 추가 인프라 구성 없이 설정만으로 AI 리뷰를 도입할 수 있게 했습니다. * **접근성 향상:** PR 내에서 `@claude` 멘션만으로 리뷰를 트리거하고, 결과물은 GitHub 댓글이나 리뷰 형태로 즉각 확인하는 직관적인 UX를 제공합니다. ### 호출과 실행을 분리한 설계 구조 (Caller-Executor) * **서비스 리포지터리(Caller):** AI 리뷰의 진입점 역할만 수행하며, 서비스명과 리뷰 타입 등 최소한의 정보만 전달하여 구조적 단순함을 유지합니다. * **중앙 리포지터리(Executor):** 프롬프트 관리, 페르소나 정의, 리뷰 정책, 권한 제어 등 핵심 로직을 집약하여 관리합니다. * **일관성 및 확산성:** 중앙에서 프롬프트를 수정하면 연결된 모든 프로젝트에 즉시 반영되며, 새로운 프로젝트는 표준 워크플로 호출만으로 빠르게 온보딩이 가능합니다. * **보안 강화:** GitHub Apps 기반의 인증과 Secrets 중앙 관리를 통해 외부 AI 호출 시의 보안 권한과 코드 접근 이력을 명확히 추적하고 통제합니다. ### 기술적 제약 극복: 포크(Fork) 기반 PR 처리 개선 * **공식 Action의 한계:** Claude Code Action의 초기 버전은 변경 코드가 `origin` 저장소에 있다는 것을 전제로 하여, 외부 포크 저장소에서 생성된 PR의 차이(diff)를 가져오지 못하는 문제가 있었습니다. * **내부 참조(ref) 활용:** 특정 브랜치를 fetch하는 방식 대신, GitHub가 모든 PR에 대해 자동으로 생성하는 특수한 참조 주소인 `refs/pull/<PR 번호>/head`를 사용하도록 로직을 재설계했습니다. * **결과:** 이 구조적 개선을 통해 내부 브랜치뿐만 아니라 외부 기여자의 포크 PR에 대해서도 중단 없는 AI 코드 리뷰가 가능한 범용적인 플랫폼 환경을 완성했습니다. ### 실용적인 제언 AI 코드 리뷰 도구를 도입할 때는 단순히 개별 리포지터리에 적용하는 것을 넘어, **'호출은 단순하게, 책임은 중앙으로'** 분리하는 아키텍처를 설계하는 것이 중요합니다. 이를 통해 조직 전체의 리뷰 품질을 상향 평준화하고, 보안 정책 변경이나 프롬프트 고도화 시 발생하는 운영 비용을 획기적으로 줄일 수 있습니다.

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

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년 내에 실현될 이러한 변화는 개발자가 복잡한 인프라 관리보다는 서비스 본연의 가치에 집중할 수 있게 만드는 실질적인 기술 동력이 될 것으로 보입니다.

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를 활용한 예측 모델을 결합함으로써 시스템의 안정성을 선제적으로 관리하는 지능형 플랫폼으로 나아가야 합니다.

Athenz 엔지니어는 왜 Kubestronaut에 도전했는가? (새 탭에서 열림)

보안 플랫폼 Athenz를 담당하는 엔지니어가 쿠버네티스 전문가의 상징인 'Kubestronaut' 칭호를 얻기까지의 도전과 성장을 다루고 있습니다. 실무에서 마주한 기술적 한계를 극복하기 위해 시작된 이 여정은 단순한 자격증 취득을 넘어 클러스터 운영, 보안, 그리고 오픈소스 거버넌스에 대한 깊은 통찰로 이어졌습니다. 결국 체계적인 학습으로 쌓은 전문 지식은 더 견고한 아키텍처를 설계하고 팀의 기술적 역량을 끌어올리는 핵심 자산이 되었습니다. **Kubestronaut과 5단계 인증 체계** * Kubestronaut은 CNCF(Cloud Native Computing Foundation)에서 수여하는 칭호로, 쿠버네티스 관련 5가지 핵심 자격증을 모두 보유한 전문가를 의미합니다. * 인증 자격은 실무 능력을 평가하는 실습형 시험인 CKA(관리자), CKAD(개발자), CKS(보안)와 지식 수준을 측정하는 KCSA, KCNA로 구성됩니다. * 특히 CKA, CKAD, CKS는 실제 터미널 환경에서 제한 시간 내에 문제를 해결해야 하므로 국제적으로 실무 역량을 입증하는 지표가 됩니다. **역할에 따른 단계별 역량 확장** * **CKAD(Application Developer):** Athenz라는 애플리케이션을 쿠버네티스에 안정적으로 배포하기 위해 가장 먼저 취득했으며, 상황 파악 및 대응 속도를 높이는 데 집중했습니다. * **CKA(Administrator):** 여러 클러스터를 관리하고 매니페스트 파일을 분석하는 능력을 배양했습니다. 쿠버네티스 내부 컴포넌트 간의 유기적인 연동 원리를 파악하여 대규모 시스템 설계의 기초를 다졌습니다. * **CKS(Security Specialist):** 보안 플랫폼 담당자로서 클러스터 자체의 보안을 책임지기 위해 도전했습니다. 취약점 분석, 네트워크 정책 설정 등 실무적인 클러스터 강화 기술을 습득한 가장 난도 높은 과정이었습니다. **전문 지식이 실무에 미친 영향** * 오픈소스 거버넌스 이해: SIG(Special Interest Groups)나 PR 규칙 등 거대 프로젝트의 운영 방식을 체계적으로 이해하게 되었으며, 이는 Athenz 프로젝트의 성장 전략 수립에 영감을 주었습니다. * 아키텍처 설계 역량: 최근 진행 중인 'BMaaS(Bare Metal as a Service) 환경에 Athenz 제공' 프로젝트에서 더 안정적이고 효율적인 구조를 설계하고 동료들을 설득하는 근거가 되었습니다. * 문제 해결 속도 향상: 실습 위주의 준비 과정을 통해 실무 환경에서 발생하는 기술적 난제를 더 빠르고 정확하게 진단할 수 있게 되었습니다. **지속 가능한 성장을 돕는 환경과 철학** * '우보천리(牛步千里)'의 자세로 매일 새벽 공부와 GitHub 커밋을 실천하며 꾸준함을 유지했습니다. * 회사의 Udemy Business 지원, 하이브리드 근무 환경, 그리고 자격 취득 비용 지원 제도 등을 적극적으로 활용하여 학습 효율을 높였습니다. * 단순 작업을 넘어 시스템 전체의 이상적인 아키텍처를 고민하고 토론하는 팀 문화가 성장의 강력한 동기부여가 되었습니다. 쿠버네티스의 방대한 생태계 앞에서 망설이고 있다면, 자격증 취득을 하나의 이정표로 삼아 도전해 보길 권장합니다. 단계별 학습을 통해 얻는 넓은 시야와 깊은 기술적 디테일은 엔지니어로서 한 단계 더 도약할 수 있는 확실한 발판이 되어줄 것입니다.

Central Dogma 컨트롤 플레인으로 LY Corporation의 수천 개 서비스를 연결하기 (새 탭에서 열림)

LY Corporation은 수천 개의 서비스를 효율적으로 연결하기 위해 Central Dogma를 활용한 통합 컨트롤 플레인(Control Plane)을 구축했습니다. 기존 레거시 시스템의 한계를 극복하고 xDS 표준 프로토콜을 도입함으로써, 물리 서버(PM), 가상 머신(VM), 쿠버네티스(K8s)를 아우르는 유연한 서비스 메시 환경을 구현했습니다. 이 시스템은 GitOps 기반의 설정 관리와 사이드카 없는(Sidecar-less) 아키텍처 지원을 통해 개발자 경험과 시스템 성능을 동시에 향상시키는 성과를 거두었습니다. ### 레거시 시스템의 한계와 새로운 요구사항 * **타이트한 결합과 동적 등록의 부재:** 기존 시스템은 특정 프로젝트 관리 도구(PMC)에 강하게 의존하고 있어 서비스의 동적인 변경사항을 즉각적으로 반영하기 어려웠습니다. * **상호 운용성 부족:** 자체 커스텀 메시지 스키마를 사용했기 때문에 Envoy나 다른 오픈소스 에코시스템과의 통합이 제한적이었습니다. * **제한적인 트래픽 제어:** 단순한 레지스트리 역할에 치중되어 있어 서킷 브레이커, 카나리 배포, 세밀한 로드 밸런싱 등 현대적인 컨트롤 플레인 기능을 수행하기에 부족함이 있었습니다. ### Central Dogma 컨트롤 플레인의 설계 및 구현 * **xDS 프로토콜 표준화:** 업계 표준인 xDS 프로토콜을 채택하여 Envoy 프록시 및 gRPC 클라이언트와 원활하게 통신할 수 있는 기반을 마련했습니다. * **GitOps 기반 관리:** Central Dogma의 Git 기반 저장소 특성을 활용해 설정 변경 사항을 버전 관리하고, 외부 Git 저장소(GitHub 등)와의 미러링을 통해 안전하게 설정을 배포합니다. * **하이브리드 인프라 지원:** PM, VM 환경의 레거시 데이터와 K8s의 엔드포인트를 모두 수용할 수 있도록 플러그인 구조를 설계하여 통합적인 엔드포인트 관리를 가능케 했습니다. * **고신뢰성 및 인증:** 다중 데이터센터 복제를 통해 가용성을 확보하고, 강력한 인증 시스템을 통합하여 보안성을 강화했습니다. ### 사이드카 없는 서비스 메시(Sidecar-less Service Mesh) * **리소스 및 복잡성 해결:** 일반적인 서비스 메시에서 발생하는 사이드카 프록시의 리소스 오버헤드와 운영 복잡성을 줄이기 위해 Proxyless 방식을 도입했습니다. * **라이브러리 수준의 통합:** gRPC 및 Armeria 라이브러리를 사용하여 애플리케이션이 컨트롤 플레인과 직접 xDS로 통신하게 함으로써 사이드카 없이도 서비스 메시의 이점을 누릴 수 있게 했습니다. * **효율적인 통신 제어:** 별도의 프록시 계층을 거치지 않고도 클라이언트 사이드 로드 밸런싱, 자동 재시도, 존 인식 라우팅(Zone-aware routing) 등을 직접 수행하여 성능을 최적화했습니다. 대규모 인프라에서 수천 개의 서비스를 연결해야 한다면, xDS와 같은 표준 프로토콜을 준수하면서도 기존에 검증된 구성 관리 도구(Central Dogma 등)를 컨트롤 플레인으로 확장하는 전략이 유효합니다. 특히 운영 효율성과 성능이 중요하다면 사이드카 없는 방식의 서비스 메시 도입을 적극적으로 고려해 볼 만합니다.

Nginx 설정 통합과 Loki 연동으로 설계한 유연한 멀티사이트 아키텍처 (새 탭에서 열림)

LINE NEXT는 빠르게 확장되는 글로벌 서비스 환경에 대응하기 위해 파편화된 웹 서버 인프라를 중앙 집중형 네이티브 Nginx 멀티사이트 구조로 전환했습니다. 기존의 수동 구성 방식과 Ingress Nginx의 제약을 극복하고자 Ansible 기반의 자동화와 설정 통합을 도입했으며, 이를 통해 서비스 론칭 리드 타임을 80% 이상 단축하고 고급 Nginx 기능을 유연하게 구현할 수 있는 환경을 마련했습니다. **Nginx 인프라 아키텍처의 3단계 진화** * **PMC 기반 초기 구조**: 사내 배포 도구인 PMC와 `rsync`를 이용해 서비스별로 독립된 Nginx 서버와 로드밸런서를 운영했습니다. 하지만 서버 발급부터 설정까지 최대 2주의 시간이 소요되었고, 보안망 내 SSH 포트 개방 리스크와 설정 파편화로 인한 유지보수 어려움이 있었습니다. * **Ingress Nginx 기반 구조**: 쿠버네티스 환경에서 헬름 차트를 통해 도메인과 설정을 추상화하여 배포 속도를 높였습니다. 그러나 로드밸런서 프락시 모드 사용 시 클라이언트의 실제 IP(Remote Address) 확인이 어렵고, GeoIP 등 Nginx 네이티브 모듈 활용에 제약이 발생하는 한계가 있었습니다. * **네이티브 Nginx 멀티사이트 구조(현재)**: Ingress Nginx의 설정 중심 방식과 네이티브 Nginx의 기능적 자유도를 결합한 하이브리드 모델입니다. 별도의 Ansible 배포 서버를 구축하여 공통 설정은 유지하되 서비스별로 유연한 기능을 탑재할 수 있도록 개선했습니다. **효율적인 관리와 확장성을 위한 설정 통합** * **마스터 설정과 서버 블록 분리**: Apache의 구성 방식에서 영감을 얻어 `events` 및 `http` 블록의 공통 설정(timeout, log format 등)을 마스터 설정으로 추출하고, 서비스별 가상 호스트 설정은 `sites-available` 디렉터리 내 개별 파일로 관리합니다. * **멀티사이트 아키텍처**: 단일 Nginx 인스턴스에서 다수의 도메인과 서비스를 동시에 서빙할 수 있도록 구조화하여, 신규 서비스 추가 시 설정 파일만 배포하면 즉시 반영되는 환경을 구축했습니다. * **환경별 독립 관리**: 알파, 베타, RC, 프로덕션 등 각 배포 환경에 맞는 설정을 독립적인 리포지터리 구조로 관리하여 운영 안정성을 높였습니다. **Ansible 기반의 안정적인 배포 자동화** * **자동화 프로세스**: 사용자가 타깃 서버와 환경을 지정하면 Ansible이 최신 설정을 클론하여 배포하며, `Nginx Verify`를 통한 문법 검사와 프로세스 상태 체크를 자동으로 수행합니다. * **롤링 배포(Rolling Deployment)**: 서비스 중단을 방지하기 위해 순차적으로 배포를 진행하며, 특정 단계에서 오류가 발생하면 즉시 배포를 중단하여 서비스 영향을 최소화합니다. * **고급 기능 통합**: GeoIP 모듈을 통한 국가별 트래픽 처리, Loki 연동을 통한 실시간 로그 수집, SSL 인증서 자동화 등 복잡한 요구사항을 공통 템플릿 내에서 손쉽게 관리할 수 있게 되었습니다. 다수의 도메인을 운영하고 빠른 서비스 론칭이 필요한 환경이라면, 클라우드 네이티브의 편의성과 네이티브 소프트웨어의 제어권을 모두 챙길 수 있는 'Ansible+네이티브 Nginx' 조합의 멀티사이트 구조 도입을 적극 권장합니다. 이를 통해 인프라 리드 타임 감소는 물론, 보안과 로그 수집 같은 공통 요구사항을 표준화된 방식으로 해결할 수 있습니다.