라인

71 개의 포스트

techblog.lycorp.co.jp/ko

태그로 필터

line

코딩 에이전트를 활용한 취약점 수집·생성 자동화로 가드레일 모델 고도화 (새 탭에서 열림)

LLM 서비스의 보안 위협인 프롬프트 인젝션과 탈옥을 방지하기 위해 가드레일 모델이 필수적이지만, 실제 운영 환경에서는 정상적인 요청을 공격으로 오해하는 오탐(False Positive) 문제가 주요 과제로 떠오르고 있습니다. 이를 해결하기 위해 개발팀은 코딩 에이전트(Codex)를 활용하여 테스트 데이터 생성부터 모델 평가 및 분석까지 전 과정을 자동화한 파이프라인을 구축했습니다. 이 시스템은 공격 유형을 카테고리별로 구조화하고 병렬로 테스트함으로써 가드레일 모델의 취약점을 체계적으로 파악하고 실서비스 적합성을 높이는 데 기여합니다. ### 벤치마크와 실서비스 성능의 간극 * **오탐(False Positive)의 문제:** 외부 벤치마크에서는 높은 성능을 보였으나, 실제 환경에서는 'ignore', 'bypass'와 같은 보안 키워드가 포함된 정상적인 개발/학술 질의까지 공격으로 차단하는 한계가 노출되었습니다. * **입력 다양성 확보의 필요성:** 단순한 성능 지표 개선을 넘어, 실제 사용자의 다채로운 입력 패턴을 모사하고 모델이 맥락을 정확히 이해하는지 검증할 체계적인 환경이 필요해졌습니다. * **코딩 에이전트 도입:** 반복적이고 복잡한 테스트 시나리오를 자동화하기 위해 LLM 기반의 도구 실행 및 파일 편집 능력을 갖춘 코딩 에이전트(Codex) 워크플로를 테스트 파이프라인에 접목했습니다. ### 코딩 에이전트(Codex)의 핵심 구성 요소 * **사용자 정의 지침 (AGENTS.md):** 프로젝트 루트에 전역 가이드라인을 명시하여 에이전트가 코딩 컨벤션과 보안 제약 사항을 준수하며 일관된 결과물을 내도록 제어합니다. * **서브 에이전트 오케스트레이션:** 복잡한 작업을 메인 에이전트(조율)와 작업자 에이전트(수행)로 분리하여 병렬 처리를 지원하고, 각 작업의 문맥을 명확히 분리해 효율성을 높입니다. * **스킬(Skill) 기반 표준화:** 특정 작업을 모듈화한 절차(SKILL.md)를 통해 데이터 생성, 모델 평가 등 반복되는 작업을 규격화하여 재현성을 확보합니다. ### 실험 단위의 카테고리화와 스킬 설계 * **실험 단위 분리:** 시스템 키워드가 포함된 업무 요청이나 교육 목적의 민감 주제 등 가드레일이 취약할 수 있는 지점을 카테고리별로 분리하여 병렬 실행 및 심층 분석이 가능하도록 설계했습니다. * **합성 데이터 생성 스킬 (synthetic-generator):** 카테고리별 제약 조건과 타깃 라벨을 반영하여 실제 서비스와 유사한 다채로운 문장 구조의 테스트셋(JSONL)을 자동으로 생성합니다. * **가드레일 모델 평가 스킬 (injection-classifier):** 생성된 데이터를 바탕으로 모델 API에 질의를 던져 오탐 및 미탐 통계를 산출하고, 원본 텍스트와 예측 결과를 통합 저장합니다. ### 자동화 테스트 파이프라인 아키텍처 * **메인 에이전트의 역할:** 테스트 명세를 파악하여 카테고리별로 서브 에이전트에게 업무를 할당하고, 최종적으로 모든 작업 완료 보고를 취합하는 컨트롤 타워 역할을 수행합니다. * **워커 에이전트의 실행 흐름:** 할당받은 카테고리에 대해 데이터 생성 및 평가 스킬을 순차적으로 호출한 뒤, 오탐/미탐 사례에 대한 심층 분석 보고서를 작성합니다. * **체계적인 산출물 관리:** 모든 실험 결과(입력 데이터, 평가 통계, 분석 보고서)는 고유한 실행 ID 경로에 저장되어, 향후 모델 패치 시 성능 개선 여부를 정밀하게 비교할 수 있는 근거가 됩니다. 가드레일 모델의 신뢰성을 높이기 위해서는 단순히 공격을 잘 막는 것을 넘어, 정상적인 비즈니스 맥락을 오차단하지 않는 정교함이 필요합니다. 코딩 에이전트를 활용한 자동화 파이프라인은 이러한 미세 조정을 위한 데이터와 분석 결과를 지속적으로 공급함으로써 보안과 사용성 사이의 균형을 잡는 핵심적인 도구가 됩니다.

line

SRE 팀의 반복 작업을 10분의 1로 줄인 SRE 봇 개발기 (새 탭에서 열림)

LINE Home DevOps 팀은 인프라 전환과 서비스 확대로 급증한 운영 문의 및 반복적인 배포 요청 문제를 해결하기 위해 Slack 기반의 통합 자동화 도구인 'SRE 봇'을 구축했습니다. 기존에 수동으로 수행하던 Jira 티켓 생성, 컨플루언스 체크리스트 복사, 배포 매뉴얼 검색 등의 프로세스를 자동화하여 업무 시간을 획기적으로 단축하고 휴먼 에러를 방지했습니다. 이를 통해 팀은 단순 반복 업무에서 벗어나 서비스 안정화와 인프라 고도화라는 본연의 업무에 집중할 수 있는 환경을 마련했습니다. ### 수동 운영 프로세스의 한계와 비효율성 * **복잡한 워크플로와 컨텍스트 스위칭:** 배포 요청 한 건을 처리하기 위해 Slack, Confluence, Jira 등 여러 플랫폼을 오가며 정보를 복사-붙여넣기해야 했으며, 이 과정에서 1건당 약 1시간의 시간이 소요되었습니다. * **휴먼 에러의 빈번한 발생:** 수동 작업 특성상 릴리스 버전 설정 오류, 필수 체크리스트 항목 누락, Epic 링크 연결 누락 등 실수가 잦았고, 긴급 상황일수록 이러한 문제는 더욱 심화되었습니다. * **가시성 부족과 정량화의 어려움:** Slack 멘션으로 들어오는 요청은 휘발성이 강해 진행 상황 추적이 어려웠으며, 팀의 업무량을 정량적으로 파악하여 성과로 증명하기 힘든 구조였습니다. ### 사용자 편의와 시스템 안정성을 고려한 기술적 설계 * **Slack 워크플로 기반 UI:** 사용자가 직접 명령어를 입력하는 방식 대신 Slack 워크플로 양식을 채택하여 필수 항목 누락을 방지하고 사용자의 진입 장벽을 낮췄습니다. * **백그라운드 비동기 처리:** Slack API의 응답 제한 시간(3초) 내에 외부 시스템(Jira, Confluence)과의 복잡한 연동을 마칠 수 없으므로, 즉시 응답 후 실제 작업은 백그라운드에서 수행하는 비동기 방식을 선택했습니다. * **Redis를 활용한 상태 관리:** Slack 스레드와 Jira 티켓 간의 매핑 정보를 Redis에 저장(TTL 30일 설정)하여 100ms 미만의 빠른 조회 성능을 확보하고, 트랜잭션을 통해 여러 SRE가 동시에 작업할 때 발생할 수 있는 동시성 문제를 해결했습니다. ### 헥사고날 아키텍처를 통한 유연한 확장성 확보 * **포트와 어댑터 패턴 적용:** Slack, Jira, Redis 등 외부 시스템과의 결합도를 낮추기 위해 헥사고날 아키텍처를 도입했습니다. * **비즈니스 로직 보호:** 인터페이스를 통해 외부 환경을 격리함으로써 Jira API 버전 업그레이드나 Slack SDK 변경 등 외부 변화가 발생하더라도 내부의 핵심 비즈니스 로직을 수정할 필요가 없도록 설계했습니다. * **테스트 및 유지보수 용이성:** 각 레이어가 명확히 분리되어 있어 기능 추가 시 영향 범위를 최소화할 수 있으며, 테스트 코드 작성이 수월해져 안정적인 코드베이스 유지가 가능해졌습니다. ### 도입 후 시나리오별 변화 및 성과 * **배포 요청 처리 시간 단축:** 기존 30분 이상 걸리던 배포 요청 처리가 SRE 봇 도입 후 1분 이내로 단축되었습니다. 봇이 Fix Version 생성, 티켓 연결, 매뉴얼 검색을 10초 만에 자동 수행하기 때문입니다. * **긴급 대응 및 가시성 개선:** 긴급 요청 시 즉시 우선순위가 높게 설정된 티켓이 생성되고 채널에 알림이 공유됩니다. SRE는 이모지 클릭만으로 본인에게 티켓을 할당하고 상태를 업데이트할 수 있어 실시간 추적이 용이해졌습니다. * **정기적인 업무 정량화:** 모든 요청이 정형화된 Jira 티켓으로 자동 기록됨에 따라, 팀원당 투입 시간과 처리 건수를 명확히 데이터화하여 운영 성과를 증명할 수 있게 되었습니다. 단순 반복적인 운영 업무로 인해 팀의 에너지가 고갈되고 있다면, 기술적인 자동화 레이어를 구축하여 'Zero Manual Work'를 지향하는 것이 장기적인 팀 생산성 향상의 핵심입니다. Slack과 같은 협업 툴을 Single Point of Truth로 설정하고 외부 시스템을 유연하게 연결하는 아키텍처를 고민해 보시기 바랍니다.

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

신뢰성 향상을 위한 SLI/SLO 활용 1편 - SLI/SLO 프레임워크 및 서비스 상태 확인 도구 LINE Status 개발기 (새 탭에서 열림)

서비스 신뢰성을 관리하기 위한 공통 언어로서 SLI/SLO를 전사적으로 확산하기 위해, 반복되는 도입 과정을 표준화한 'SLI/SLO 프레임워크'를 정립하고 이를 시각화하는 'LINE Status' 도구를 개발했습니다. 단순한 장애 여부가 아닌 사용자 경험(CUJ) 관점에서 서비스 상태를 정의함으로써, 기술적 지표에 매몰되지 않고 조직 전체가 동일한 기준으로 서비스 품질을 파악하고 의사소통할 수 있는 기반을 마련했습니다. 이러한 체계는 운영 자동화와 데이터 기반의 거버넌스 구축을 가능하게 하여 장기적인 서비스 신뢰성 향상을 이끌어냅니다. **SLI/SLO 프레임워크의 5단계 구조** * **CUJ 선정 및 SLI 정의:** 서비스의 본질적인 사용자 경험을 파악하여 핵심 여정(Critical User Journey)을 선정하고, 이를 측정 가능한 지표인 SLI로 구체화합니다. * **계측 및 메트릭 설계:** Prometheus나 OpenTelemetry의 표준 네이밍 규칙을 적용하여 CUJ에 적합한 메트릭을 설계하고 구현합니다. * **대시보드 및 기록 규칙 구성:** Grafana를 통해 SLO 달성 여부를 직관적으로 확인하며, 복잡한 연산은 Recording Rules로 사전 처리하여 조회 효율을 높입니다. * **SLO 및 알람 설정:** 28일 롤링 윈도우 기반으로 초기 SLO를 설정하고, 단계적으로 목표치를 확정하며 대응을 위한 Runbook을 정의합니다. * **에러 예산 기반 운영:** 릴리스 속도와 안정성 사이의 균형을 맞추고, 정기적인 리뷰를 통해 목표를 점검하며 거버넌스를 확립합니다. **사용자 경험 중심의 LINE Status 도구** * **CUJ 기반 상태 정의:** 단순한 서버 장애 유무가 아니라, 사용자가 서비스를 원활히 이용하고 있는지(User Happiness)를 기준으로 상태를 판단합니다. * **기능 중심의 명칭 노출:** "API 500 에러"와 같은 기술 용어 대신 "메시지 전송", "읽음 표시" 등 사용자가 체감하는 기능 단위로 상태를 표현하여 직관성을 높였습니다. * **자동화된 상태 관리:** 각 서비스의 SLI/SLO 알림을 웹훅(Webhook)으로 수집하여 실시간으로 상태를 갱신하고, 이벤트 발생 이력을 DB에 저장해 추적합니다. * **시각적 편의 기능:** AI를 활용한 한 줄 분석 요약, 직관적인 신호등 색상 표현, 타임라인 기반의 이벤트 히스토리 페이지 등을 제공합니다. **AI 활용과 프레임워크의 연결 효과** * **바이브 코딩과 명확한 기획:** 프런트엔드 개발 경험이 부족하더라도 AI를 적극 활용하여 UI를 구현했으며, 마크다운 형식의 구체적인 요구사항 정의가 결과물의 완성도를 결정함을 확인했습니다. * **공통 창구 제공:** 개발자와 운영자가 각자의 대시보드를 보는 대신, LINE Status라는 단일 창구를 통해 사용자 경험에 미치는 영향을 즉각적으로 파악할 수 있습니다. * **확산 가능한 운영 기반:** 프레임워크를 통해 서비스를 정의하고 그 결과를 LINE Status에 등록하는 일련의 과정을 통해, 특정 인원에 의존하지 않는 지속 가능한 신뢰성 관리 체계를 구축했습니다. **실용적인 결론** 성공적인 SLI/SLO 도입을 위해서는 기술적 측정보다 **'사용자 경험(CUJ)의 명확한 정의'**와 **'조직 간의 공통 언어 수립'**이 선행되어야 합니다. 또한, 표준화된 템플릿과 자동화된 상태 확인 도구를 결합함으로써 커뮤니케이션 비용을 줄이고 데이터에 기반한 의사결정 속도를 높일 수 있습니다.

line

AttributedString 구조로 풀어낸 대규모 iOS 설정 시스템 (새 탭에서 열림)

LINE iOS 앱의 성장으로 인해 기존의 일체형 서비스 설정 시스템은 의존성 관리, 안정성, 개발 생산성 측면에서 한계에 봉착했습니다. 이를 해결하기 위해 LINE은 각 모듈이 독립적으로 설계를 정의하면서도 타입 안전성을 확보하고, 동시성 환경에서도 안전하게 작동하는 새로운 아키텍처로의 전환을 시도했습니다. 특히 Apple의 `AttributedString` 설계 방식을 벤치마킹하여 대규모 프로젝트에 적합한 확장성 있는 설정 관리 체계를 구축하고자 했습니다. **서비스 설정 시스템의 역할과 구조** * LINE은 2주마다 정기 배포를 진행하므로, 개별 서비스의 신규 기능 출시나 롤백을 앱 업데이트 없이 수행하기 위해 '서비스 설정' 시스템을 활용합니다. * 서버는 사용자의 지역, 기기, OS 버전 등에 따라 최적화된 설정값을 문자열 형태의 키-값 쌍(JSON)으로 클라이언트에 전달합니다. * 이 시스템은 기능 토글뿐만 아니라 A/B 테스트, 오류 수집 샘플링 비율 조정, UI 정책 결정 등 다양한 용도로 사용되며 현재 약 700개의 키가 운용되고 있습니다. **일체형 구조로 인한 순환 의존성 딜레마** * 과거에는 모든 설정 키를 단일 파일에서 관리했으나, 프로젝트 규모가 커지며 해당 파일이 7천 줄에 달하는 등 관리가 어려워졌습니다. * 설정 시스템이 특정 서비스 모듈의 전용 타입(예: 사진 품질 타입)을 반환하려 하면 모듈 간 순환 참조가 발생하여, 결국 타입 안전한 객체 대신 날것의 문자열을 노출하고 각 모듈에서 매번 파싱해야 하는 비효율이 발생했습니다. **불완전한 추상화와 구현 세부 사항의 노출** * 서버 규약에 따라 불리언 값을 "Y"/"N" 문자열로 처리해야 했고, 이를 위해 `decodeBoolIfPresent` 같은 비표준 메서드를 별도로 구현해야 했습니다. * 이 과정에서 표준 메서드와의 혼동으로 인한 버그가 잦았으며, 용도가 미묘하게 다른 기본값을 세 번이나 중복 정의해야 하는 설계 결함이 존재했습니다. * 이러한 복잡성은 신규 개발자에게 암기 위주의 온보딩 지식을 강요하여 생산성을 저하시켰습니다. **스레드 안전성 부재로 인한 런타임 오류** * 기존 시스템은 동시성을 고려하지 않고 설계되어, 여러 스레드에서 설정값을 읽는 과정에서 지연 평가 및 인스턴스 해제 타이밍이 겹치는 문제가 있었습니다. * 이로 인해 메모리 해제 후 사용(use-after-free) 오류가 발생하여 매일 수백 건의 크래시가 기록되는 등 앱 안정성에 심각한 영향을 미쳤습니다. **테스트 및 디버깅 효율성 저하** * 시스템 자체에 오버라이드 기능이 없어 QA 과정에서 설정값을 임시로 변경하려면 다수의 파일을 직접 수정해야 하는 번거로움이 있었습니다. * 싱글턴 구조의 의존성 때문에 각 모듈은 테스트를 위해 별도의 프로토콜과 테스트 대역을 각자 만들어 관리해야 했으며, 이는 실제 구현체와의 동작 괴리를 유발하는 원인이 되었습니다. **성장을 위한 설계의 재정립** * 대량의 키-값 쌍을 타입 안전하게 관리하면서도 각 모듈이 독립적으로 키를 정의할 수 있는 구조를 만들기 위해 Foundation의 `AttributedString` 설계를 참고했습니다. * 이는 개별 서비스가 자신의 도메인에 맞는 설계를 독립적으로 확장할 수 있게 하여, 거대해진 프로젝트 규모에 대응할 수 있는 유연한 기반을 마련하는 계기가 되었습니다.

line

LINE 앱의 다자간 대화 기능 통합 (새 탭에서 열림)

LINE은 서로 다른 용도로 운영되던 '여러 명과의 대화'와 '그룹' 기능을 '그룹 대화'라는 단일 모델로 통합하여 사용자 경험을 개선하고 시스템 리소스를 효율화했습니다. 기존의 이원화된 구조에서 발생하던 기능 제한과 중복 대화방 생성 문제를 해결하기 위해 통합 API 설계 및 점진적인 데이터 마이그레이션을 수행했습니다. 이를 통해 사용자는 생성 방식에 관계없이 모든 기능을 동일하게 사용할 수 있게 되었으며, 중복 방 생성 비율을 획기적으로 낮추는 기술적 성과를 거두었습니다. ### 이원화된 대화 모델의 한계 * **여러 명과의 대화(Room):** 별도의 승인 없이 즉시 대화가 가능하지만, 일시적 목적으로 설계되어 앨범이나 노트 같은 그룹 전용 기능을 사용할 수 없었습니다. * **그룹(Group):** 초대 승인 절차가 필요한 대신 장기적인 소통에 적합한 다양한 편의 기능을 제공했으나, 초기 진입 장벽이 존재했습니다. * **사용자 혼란 및 리소스 낭비:** 사용자들이 두 모델의 차이를 이해하지 못해 기능이 제한된 방을 잘못 만들거나, 동일한 구성원의 대화방을 중복으로 생성하여 서버와 클라이언트의 리소스가 불필요하게 소모되었습니다. ### 그룹 대화로의 기술적 마이그레이션 * **점진적 API 전환:** 새로운 그룹 대화 API를 설계한 후, '이중 읽기(Dual Read)' 방식을 도입하여 이전 API와의 호환성을 유지하며 단계적으로 전환을 진행했습니다. * **데이터 배치 처리:** 기존의 모든 그룹 데이터를 배치 처리를 통해 신규 모델로 이관하였으며, 안정성이 확인된 후 이중 읽기를 중단하고 그룹 대화 시스템으로 단일화했습니다. * **통합 모델 확립:** 그룹 모델의 아키텍처를 기반으로 여러 명과의 대화 모델을 흡수하여, 향후 추가될 모든 신규 기능이 모든 대화방에 동일하게 적용되도록 구조를 개선했습니다. ### 사용자 경험 최적화 및 운영 성과 * **초대 메커니즘 단일화:** 대화방 생성 UI를 통합하여 '즉시 참여'와 '수락 후 참여' 여부를 사용자가 상황에 맞게 직접 선택할 수 있도록 개선했습니다. * **중복 생성 방지 힌트:** 동일한 구성원으로 새로운 방을 만들려 할 때 기존 대화방을 안내하는 '힌트' 기능을 제공하여 불필요한 대화 목록 생성을 방지했습니다. * **정량적 성과:** 프로젝트 결과, 동일 구성원으로 중복 생성되는 대화방 비율이 기존 15%에서 0.78%로 급감하며 데이터 관리 효율성이 크게 향상되었습니다. 대규모 서비스에서 유사한 기능을 통합할 때는 사용자에게 갑작스러운 변화를 강요하기보다, 점진적인 API 전환과 기능적 일원화를 통해 자연스러운 이동을 유도하는 것이 중요합니다. 이번 통합 사례는 시스템의 복잡성을 줄이면서도 데이터 일관성과 사용자 편의성을 동시에 확보할 수 있는 구체적인 마이그레이션 전략을 보여줍니다.

line

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로의 마이그레이션 비용을 최소화하기 위해 사용자의 수동 대응을 줄여주는 투명한 이전 도구 개발에 집중할 것을 권장합니다.

line

완벽한 AI 가드레일을 향한 여정: NeurIPS 2025 최신 안전성 기술 분석 (새 탭에서 열림)

NeurIPS 2025에서 제시된 AI 안전 연구의 핵심은 가드레일을 단순한 사후 필터링 도구가 아닌, 모델의 추론 메커니즘과 시스템 구조 전반에 통합된 필수 인프라로 격상시키는 것입니다. 특히 실제 배포 환경에서 서비스 지연을 최소화하면서도 보안성을 극대화하기 위해 정책의 코드화와 모듈형 방어 체계가 새로운 표준으로 떠오르고 있습니다. 결론적으로 차세대 가드레일은 텍스트를 넘어 멀티모달 환경에서의 복합적인 위협을 실시간으로 탐지하고, 규제 대응을 위해 판단의 근거를 추적할 수 있는 지능형 시스템으로 진화하고 있습니다. ### 효율적이고 유연한 가드레일 프레임워크 * **PRIME Guardrails의 저지연 방어:** 서비스 속도 저하를 막기 위해 조기 종료(early-exit) 파이프라인을 채택하여 명백한 공격을 비동기로 즉시 차단합니다. P(정책), R(위험 감지), I(개입), M(모니터링), E(평가)로 구성된 모듈형 구조를 통해 법무·정책 팀이 직접 안전 규칙을 정의하고 도메인별로 유연하게 적용할 수 있습니다. * **정책의 코드화(Policy-as-Prompt):** 기업 내 비정형 문서(PRD, 법적 규제 등)를 런타임에서 검증 가능한 '소스 연결 정책 트리'로 자동 변환합니다. 이를 통해 AI가 특정 요청을 거부했을 때 원본 문서의 어떤 조항에 근거했는지 법적 추적이 가능해지며, 금융이나 의료 등 규제가 엄격한 산업에서 기술 부채를 줄이는 핵심 역할을 합니다. ### 멀티모달 환경에서의 지능형 유해성 관리 * **GuardReasoner-VL의 강화된 추론:** 겉보기에 무해한 이미지와 텍스트가 결합되어 발생하는 교묘한 유해성을 찾아내기 위해 논리적 추론 과정을 훈련합니다. GRPO(Group Relative Policy Optimization) 기반의 온라인 강화 학습을 사용하여, 모델이 단순히 분류하는 것을 넘어 유해성의 근거를 논리적으로 분석한 뒤 결론을 내리도록 유도합니다. * **시각적 이어붙이기(Visual Stitching) 취약점:** VLM(시각-언어 모델)이 학습 과정에서 조각난 유해 이미지 패치들을 공통된 텍스트 레이블을 통해 내부적으로 재구성할 수 있다는 사실이 밝혀졌습니다. 이는 개별 조각이 안전해 보이더라도 모델이 전체 맥락을 복원하여 안전망을 우회할 수 있음을 시사하며, 데이터 정제 및 입력 처리 단계에서의 정교한 검증이 필요함을 역설합니다. ### 실용적인 가드레일 구축을 위한 제언 AI 서비스를 안정적으로 운영하기 위해서는 가드레일을 단순한 필터가 아닌 '시스템 설계'의 관점에서 접근해야 합니다. 특히 멀티모달 모델을 도입할 때는 학습 데이터의 파편화된 정보가 보안 취약점이 될 수 있음을 인지하고, 입력부터 출력까지 전 과정에 걸쳐 다중 방어(Defense in Depth) 체계를 구축하는 것이 권장됩니다. 또한 정책 변화에 유연하게 대응할 수 있도록 정책 문서를 가드레일에 실시간으로 반영하는 자동화 파이프라인을 구축하는 것이 장기적인 운영 효율성 측면에서 유리합니다.

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

메신저용 온디바이스 이미지 모델 학습기 2편: 초저지연 비자기회귀(non-autoregressive) 캡션 생성 전략 (새 탭에서 열림)

네트워크 호출 없이 모바일 기기 내에서 작동하는 초저지연 이미지 캡션 기능을 위해, 비자기회귀(Non-autoregressive) 디코딩 구조와 다단계 지식 증류(Knowledge Distillation) 기술을 결합한 온디바이스 모델을 개발했습니다. 기존의 순차적 생성 방식인 자기회귀 디코딩의 병목 현상을 해결하여 응답 시간을 5초 이상에서 200~400ms 수준으로 12배 이상 단축했으며, 172MB의 가벼운 모델 크기로도 실사용 가능한 수준의 품질을 확보했습니다. 결과적으로 프라이버시를 보호하면서도 오프라인 환경에서 즉각적인 이미지 이해 기능을 제공하는 메신저 UX를 구현하는 데 성공했습니다. ### 기존 자기회귀 모델의 모바일 환경 한계 * **추론 지연의 핵심 원인**: LLM에서 흔히 쓰이는 자기회귀(AR) 방식은 토큰을 하나씩 순차적으로 생성하므로, 문장 길이에 비례해 디코더의 연산 횟수가 늘어나 모바일 기기에서 수 초 이상의 지연 시간을 발생시킵니다. * **기존 모델의 부적합성**: BLIP-1, MobileVLM 등 기존의 오픈소스 모델들은 양자화 후에도 응답 시간이 5초를 초과하여, 즉각적인 반응이 필요한 메신저 서비스 시나리오를 충족하지 못했습니다. * **온디바이스 제약**: 단순한 모델 경량화만으로는 목표치인 수백 ms대 진입이 불가능했으며, 네트워크 상태나 기기 성능에 구애받지 않는 안정적인 속도 확보가 필수적이었습니다. ### 비자기회귀 디코딩을 통한 속도 혁신 * **병렬 토큰 예측**: 이미지 표현을 조건으로 하여 N개의 학습 가능한 쿼리 토큰이 모든 단어를 한 번에 예측하는 비자기회귀(NAR) 구조를 채택해 시간 복잡도를 O(1)로 낮추었습니다. * **Query-CTC 손실 함수**: 병렬 생성 시 발생하는 정답 토큰과 쿼리 위치 간의 정렬 문제를 해결하기 위해, 음성 인식에서 주로 쓰이는 CTC(Connectionist Temporal Classification) 계열의 손실 함수를 도입했습니다. * **초저지연 달성**: 이 구조를 통해 기존 2.8~5초 이상 걸리던 캡션 생성 시간을 200ms 내외로 획기적으로 줄여 사용자 체감 성능을 극대화했습니다. ### 실사용 품질 확보를 위한 평가 및 학습 전략 * **수락 비율(Accept Ratio) 도입**: CIDEr나 CLIPScore 같은 기존 벤치마크 점수가 실제 문장의 자연스러움을 대변하지 못하는 문제를 해결하기 위해, GPT-4o mini를 활용해 문법 오류나 중복 단어를 걸러내는 새로운 평가 지표를 정의했습니다. * **데이터 정제와 캡션 재생성**: 원본 학습 데이터의 노이즈(짧거나 장황한 캡션 등)를 제거하기 위해, 고성능 모델을 이용해 캡션을 다시 쓰는 Re-captioning 과정을 거쳐 고품질의 학습 데이터를 확보했습니다. * **다단계 지식 증류**: 거대 모델(Teacher)의 정교한 표현력을 작은 모델(Student)에게 전수하는 지식 증류 기법을 적용하여, 모델 크기는 줄이면서도 비자기회귀 모델 특유의 반복 문구 생성이나 문법 오류 문제를 해결했습니다. 온디바이스 AI 개발에서 성능 지표(Score) 향상보다 중요한 것은 실제 사용자 환경에서의 '수락 가능한 품질'과 '지연 시간'의 균형입니다. 단순히 모델을 작게 만드는 것에 그치지 않고, 디코딩 패러다임을 비자기회귀로 전환하고 데이터의 질을 높이는 지식 증류 과정을 반복하는 것이 모바일 환경에 최적화된 고성능 모델을 만드는 핵심 전략입니다.

line

메신저용 온디바이스 이미지 모델 학습기 1편: 지식 증류로 확장한 다국어 이미지 검색 (새 탭에서 열림)

메신저 환경 내 사용자 경험을 개선하기 위해 네트워크 연결 없이 모바일 기기 내부에서 작동하는 온디바이스 이미지 이해 모델을 개발했습니다. 거대 모델의 정교한 표현력을 작은 모델에 전수하는 '지식 증류(Knowledge Distillation)' 기법을 핵심 전략으로 사용하여, 기존 영어 전용 모델을 한국어를 포함한 5개 국어 지원 모델로 확장하면서도 성능과 효율성을 동시에 확보했습니다. 이를 통해 모바일 기기의 제한된 자원 속에서도 높은 정확도의 다국어 이미지 검색 기능을 성공적으로 구현하는 성과를 거두었습니다. ### 온디바이스 이미지 이해의 필요성과 제약 조건 * 메신저 내 이미지 검색 기능을 키워드 매칭 방식에서 의미 기반(Semantic) 검색으로 고도화하고, 알림 시 이미지 내용을 요약해 주는 등 사용자 경험을 개선하고자 했습니다. * 지연 시간(Latency) 최소화, 개인 사진에 대한 프라이버시 보호, 오프라인 환경 지원을 위해 서버가 아닌 온디바이스 처리가 필수적이었습니다. * 앱 다운로드 부담을 줄이기 위해 모델 크기를 200MB 이하로 최적화해야 했으며, Android와 iOS 모두에서 수백 ms 이내의 빠른 응답 속도와 호환성을 보장해야 했습니다. ### 지식 증류를 통한 다국어 텍스트 인코더 확장 * 기존의 번역 파이프라인 방식은 번역 오류로 인한 품질 저하와 추가적인 지연 시간 문제가 있어, 지식 증류를 통해 다국어를 임베딩 공간에 직접 정렬하는 방식을 채택했습니다. * 이미 검증된 영어 텍스트 인코더를 교사(Teacher) 모델로 고정하고, 다국어 입력을 받는 학생(Student) 모델이 교사의 임베딩 공간을 복제하도록 MSE(평균 제곱 오차) 손실 함수를 사용해 학습시켰습니다. * 이미지 인코더를 재학습하지 않고 텍스트 인코더만 정렬함으로써, 기존 모델이 가진 강력한 이미지-텍스트 정렬 성능을 다국어 환경에서도 그대로 유지하며 효율적으로 확장했습니다. ### 다국어 검색 성능 및 기술적 구현 성과 * 지식 증류 결과, 다국어 Recall@5 지표가 기존 10% 미만에서 평균 78% 이상으로 약 7배 향상되어 실제 서비스에 적용 가능한 수준의 성능을 확보했습니다. * Android와 iOS 통합 지원을 위해 표준 런타임인 LiteRT를 선택했으며, PyTorch 모델 변환 과정에서 호환되지 않는 연산자(erf 등)를 의사 연산자로 대체 구현하여 최적화했습니다. * 언어별 데이터 불균형을 해소하기 위한 샘플링 전략과 모바일 환경에 맞춘 토큰화기(Tokenizer) 규약을 수립하여 실무적인 배포 완성도를 높였습니다. 이 프로젝트는 온디바이스라는 제약 조건 속에서 지식 증류라는 효율적인 학습 전략을 통해 다국어 지원 문제를 성공적으로 해결했습니다. 특히 영어 모델의 성능 손실을 최소화하면서도 한국어, 일본어 등 주요 언어의 검색 품질을 획기적으로 끌어올린 과정은, 리소스가 제한된 모바일 환경에서 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

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

line

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

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진수 비교 등)을 사전에 검증하고, 대규모 테이블 작업 시 발생할 수 있는 복제 지연과 논리적 조건 변화를 세심하게 모니터링하는 것이 중요합니다.

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