line·2026년 2월 13일원문

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 코드 리뷰 도구를 도입할 때는 단순히 개별 리포지터리에 적용하는 것을 넘어, **'호출은 단순하게, 책임은 중앙으로'** 분리하는 아키텍처를 설계하는 것이 중요합니다. 이를 통해 조직 전체의 리뷰 품질을 상향 평준화하고, 보안 정책 변경이나 프롬프트 고도화 시 발생하는 운영 비용을 획기적으로 줄일 수 있습니다.

데이터베이스 설계쿠버네티스CI/CDclaude-code+4

line·2026년 2월 13일원문

슬로우 쿼리 해결기: 함수형 인덱스로 비트 연산 쿼리 최적화하기 (새 탭에서 열림)

LINE VOOM 서비스는 헤비 유저의 프로필 조회 시 비트 연산 조건으로 인해 발생하는 30초 이상의 슬로우 쿼리 문제를 해결하기 위해 MySQL 8.0.13의 함수형 인덱스(functional index)를 도입했습니다. 기존의 비트 연산 조건은 인덱스를 무력화하여 수십만 건의 데이터를 풀 스캔하게 만들었으나, 연산 결과를 인덱싱하고 이를 10진수 동등 비교 쿼리로 전환함으로써 스캔 범위를 3% 수준으로 대폭 축소했습니다. 이 과정에서 무중단 인덱스 생성과 점진적 롤아웃을 통해 운영 안정성을 확보하며 시스템 성능을 성공적으로 최적화했습니다. ### 비트 연산 조건에 의한 성능 저하 원인 * LINE VOOM의 포스트 메타데이터 테이블은 `category_flag`와 `access_flag`라는 `bit(64)` 타입 컬럼에 서비스 상태 정보를 압축 저장합니다. * 특정 상태를 필터링하기 위해 `category_flag & 0x0100`과 같은 비트 연산을 사용했는데, 이는 인덱스에 저장된 원본 값이 아닌 연산 결과를 조건으로 활용하므로 기존 인덱스를 타지 못합니다. * 결과적으로 특정 사용자의 모든 포스트를 일일이 순회하며 연산을 수행해야 했고, 포스트가 수십만 건에 달하는 헤비 유저의 경우 쿼리 타임아웃이 빈번하게 발생했습니다. ### 함수형 인덱스를 활용한 최적화 설계 * MySQL 8.0.13에서 도입된 함수형 인덱스는 표현식의 결과를 가상 컬럼 형태로 저장하고 인덱싱하는 기능을 제공합니다. * 팀은 `user_id`와 비트 연산 표현식을 결합한 복합 인덱스 `idx_user_premium_searchable (user_id, (category_flag & 0x0100), (access_flag & 0x0001))`를 설계했습니다. * 이 방식은 기존 테이블 스키마를 크게 변경하지 않으면서도 특정 비트 패턴에 대해 즉각적인 인덱스 조회를 가능하게 합니다. ### 인덱스 활성화를 위한 쿼리 튜닝 및 검증 * 개발 환경 테스트 결과, 단순히 비트 연산을 포함하는 것만으로는 인덱스가 작동하지 않는 것을 확인했습니다. * 인덱스를 타기 위해서는 쿼리의 표현식이 인덱스 정의와 완벽히 일치해야 하며, 특히 비트 연산 결과를 **10진수 값으로 동등 비교**(`= 256`)했을 때만 인덱스가 정상적으로 적용되었습니다. * 최적화 후 스캔 행 수가 805건에서 31건으로 줄어드는 등 극적인 성능 향상을 보였으며, 인덱스 용량 증가(약 24%)는 운영 환경에서 수용 가능한 수준으로 판단되었습니다. ### 운영 환경 적용 및 시행착오 해결 * **무중단 인덱스 생성**: DBA 팀과 협업하여 Online DDL 방식을 사용함으로써 서비스 중단 없이 수십 개의 테이블에 인덱스를 추가했습니다. * **복제 지연 대응**: 인덱스 생성 중 발생한 마스터-슬레이브 복제 지연으로 인해 최신 글이 보이지 않는 이슈가 발생했으나, 캐시 만료 시간을 단축하여 사용자 불편을 최소화했습니다. * **논리 오류 방지**: 비트 연산을 동등 비교로 바꿀 때 OR 조건과 AND 조건의 의미 차이로 인한 버그를 발견했습니다. 이를 방지하기 위해 동적 설정을 활용해 샤드별로 쿼리를 점진적으로 적용하며 안전하게 검증을 마쳤습니다. 비트 연산과 같이 컬럼 가공이 필요한 조건을 상시로 사용해야 한다면, MySQL의 함수형 인덱스는 스키마 변경 부담을 최소화하면서 성능을 극대화할 수 있는 강력한 도구입니다. 다만, 인덱스가 적용되는 정확한 표현식(10진수 비교 등)을 사전에 검증하고, 대규모 테이블 작업 시 발생할 수 있는 복제 지연과 논리적 조건 변화를 세심하게 모니터링하는 것이 중요합니다.

데이터베이스 설계mysqlcachingsharding+4

line·2026년 2월 4일원문

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

데이터베이스 설계AI쿠버네티스옵저버빌리티+4

line·2025년 8월 1일원문

일 평균 30억 건을 처리하는 결제 시스템의 DB를 Vitess로 교체하기 - 2. 개발 및 운영기 (새 탭에서 열림)

LINE Billing Platform 팀은 일 평균 30억 건의 요청을 처리하는 대규모 결제 시스템을 운영하기 위해 기존 Nbase-T에서 Vitess로 성공적인 데이터베이스 마이그레이션을 수행했습니다. 이 글에서는 성능 문제와 개발 편의성을 고려해 gRPC 대신 MySQL 프로토콜을 선택한 과정과 효율적인 데이터 처리를 위한 샤딩 전략을 상세히 다룹니다. 또한 VTOrc와 Prometheus를 활용한 자동 복구 및 모니터링 체계를 구축하여 분산 데이터베이스 환경에서도 높은 안정성을 확보한 실무 노하우를 공유합니다. ### 프로토콜 선정 및 개발 환경 구축 * VTGate는 gRPC와 MySQL 프로토콜을 모두 지원하지만, gRPC 사용 시 `http2: frame too large` 에러와 CPU 오버헤드가 발생하여 최종적으로 MySQL 프로토콜을 채택했습니다. * Java 클라이언트 사용 시 gRPC 프로토콜은 쿼리 결과를 객체로 변환하는 과정이 번거롭고 Vitess 측에서도 현재 MySQL 프로토콜 사용을 권장하고 있습니다. * 익숙한 MySQL 프로토콜을 사용함으로써 기존 개발 경험을 유지하면서도 Vitess의 샤딩 기능을 안정적으로 활용할 수 있게 되었습니다. ### 키스페이스 설계 및 데이터 처리 방식 * 시스템은 크게 두 개의 키스페이스로 분리되어 있습니다. '글로벌 키스페이스'는 단일 샤드로 구성되어 자동 증가(Auto-increment)하는 샤딩 키를 관리합니다. * 실제 데이터가 저장되는 '서비스 키스페이스'는 N개의 샤드로 분산되어 있으며, 코인 잔액 및 충전/사용 내역 등의 데이터를 저장합니다. * 서비스 키스페이스는 'Hash Vindex'를 사용하여 데이터를 균등하게 분산하며, 애플리케이션이 쿼리에 샤딩 키를 포함하면 VTGate가 해당 샤드를 자동으로 특정해 효율적인 요청 처리가 가능합니다. ### MySQL 호환성 및 주요 기능 활용 * 트랜잭션 격리 수준은 단일 샤드일 경우 `REPEATABLE READ`, 다중 샤드일 경우 `READ COMMITTED`가 적용됩니다. * Vitess는 MySQL 프로토콜을 지원하지만 일부 쿼리 제약 사항이 존재하므로, `unsupported_cases.json`을 통해 사전에 호환성을 확인해야 합니다. * 분산 샤드 간 트랜잭션을 지원하는 'Two-Phase Commit(2PC)' 기능과 쿼리 실행 계획을 분석하는 'VEXPLAIN/VTEXPLAIN' 등을 통해 분산 환경의 제약을 보완하고 있습니다. ### 안정적인 운영을 위한 모니터링 및 장애 복구 * 자동 복구 도구인 'VTOrc'를 도입하여 토폴로지 서버와 VTTablet의 데이터를 기반으로 문제를 자동 감지하고 복구합니다. * Prometheus를 통해 VTOrc의 지표(Metrics)를 수집하며, 장애 발생 시 이메일과 Slack으로 알람이 전달되도록 구성했습니다. * VTAdmin 웹 UI를 활용해 복구 내역을 시각적으로 확인하고, `tablet_alias`를 통해 문제가 발생한 MySQL 노드를 즉각적으로 식별하여 운영 효율성을 높였습니다. 대규모 분산 환경에서 Vitess를 도입할 때는 성능과 유지보수를 위해 gRPC보다는 MySQL 프로토콜 사용을 우선적으로 고려하는 것이 좋습니다. 또한 단일 샤드와 다중 샤드 간의 트랜잭션 격리 수준 차이 및 쿼리 제약 사항을 면밀히 검토하여 애플리케이션 로직을 설계해야 하며, VTOrc와 같은 도구를 적극 활용하여 고가용성 운영 체계를 구축하는 것이 중요합니다.

데이터베이스 설계grpcmysqldatabase-migration+4