라인 / database-design

AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG (새 탭에서 열림)

AI 에이전트가 다양한 기업용 서비스와 연동되는 과정에서 발생하는 인증 및 인가 복잡성을 해결하기 위해 **Identity Assertion JWT Authorization Grant(ID-JAG)**라는 새로운 표준안이 주목받고 있습니다. ID-JAG는 기존 SSO의 신뢰 모델을 API 접근 영역으로 확장하여, 기업 IdP가 중앙에서 권한 정책을 일원화해 관리하고 검증 가능한 JWT를 통해 안전하게 토큰을 교환하도록 돕습니다. 이를 통해 사용자 경험을 개선하고 보안 가시성을 확보함으로써, 복잡한 연동 구조가 AI 도입의 병목이 되지 않도록 하는 것이 핵심입니다. **ID-JAG의 개념과 기술적 배경** * SSO를 통해 확립된 IdP(Identity Provider)에 대한 신뢰를 앱 간 API 호출이나 에이전트 서비스 연동에 적용하는 방식입니다. * OAuth 2.0 Token Exchange(RFC 8693)와 JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523)라는 기존의 두 표준 기술을 결합하여 작동합니다. * IdP가 서명한 검증 가능한 JWT를 일종의 '소개장'으로 발행하고, API 리소스 측 인가 서버가 이 소개장을 신뢰하여 최종 액세스 토큰을 발행하는 구조입니다. **핵심 구성 요소와 작동 흐름** * **주요 주체:** 요청 에이전트(AI 등), 기업 IdP(중앙 정책 보유), 인가 서버(대상 앱의 서버), 리소스 서버(실제 API)의 네 가지 역할로 구분됩니다. * **작동 프로세스:** 사용자가 에이전트에 로그인하여 ID 토큰 획득 → IdP에 토큰 교환을 요청하여 ID-JAG 발급 → 인가 서버에 ID-JAG를 제시하고 최종 액세스 토큰 획득 → 리소스 서버 API 호출 순으로 진행됩니다. * **권한 판단의 주체 변화:** 개별 서비스 간의 파편화된 관계 대신, 조직 전체를 관리하는 기업 IdP와 인가 서버 간의 신뢰 관계로 허가 판단 시점이 이동합니다. **조직의 운영 및 보안 측면의 이점** * **사용자 경험(UX) 개선:** 새로운 도구를 연동할 때마다 나타나는 권한 동의 화면(Consent Screen) 절차를 IdP 관리자 정책에 통합하여 사용자의 번거로움을 줄입니다. * **보안 가시성 확보:** 모든 서비스 연결 관계가 IdP로 집중되므로, 누가 어떤 에이전트를 통해 어떤 데이터에 접근했는지 중앙 로그를 통해 명확하게 감사(Audit)할 수 있습니다. * **중앙 집중형 리스크 통제:** 승인되지 않은 '섀도우 AI'의 접근을 차단하고, 보안 사고 발생 시 개별 엔드포인트를 수정할 필요 없이 IdP 단에서 즉각적으로 권한을 제어할 수 있습니다. * **토큰 스프롤(Sprawl) 방지:** 장기 유효한 API 키나 리프레시 토큰 대신 동적으로 발행되는 ID-JAG를 사용하여 시스템 곳곳에 흩어진 인증 정보 노출 리스크를 낮춥니다. **도입 시 고려 사항 및 실용적 제언** * **표준화 상태 유의:** 현재 IETF 드래프트 단계이며 RFC로 최종 확정된 사양이 아니므로, 향후 변경 가능성을 염두에 둔 유연한 아키텍처 설계가 필요합니다. * **사전 신뢰 관계 구축:** 요청 에이전트가 IdP와 인가 서버 모두에 OAuth 클라이언트로 등록되어야 하며, 각 주체 간의 명시적인 신뢰 설정이 선행되어야 합니다. * **결론:** AI 에이전트 도입으로 인해 파편화된 권한 관리에 어려움을 겪는 기업이라면, ID-JAG를 통해 인가 정책을 중앙화하고 보안 표준을 프로토콜 기반의 동적 신뢰 구조로 전환하는 전략적 검토가 권장됩니다.

ODW #3: MCP 서버를 안전하게 활용해 개발 효율 높이기 (새 탭에서 열림)

LY Corporation은 Model Context Protocol(MCP)을 활용해 AI 어시스턴트와 사내외 도구를 표준화된 방식으로 연결함으로써 개발 프로세스의 효율성을 극대화하고 있습니다. 보안 리스크를 체계적으로 관리하는 동시에 워크숍을 통한 조직적 학습을 병행하여, 엔지니어들이 안전하게 AI 에이전트를 확장하고 업무 자동화를 실현할 수 있는 환경을 구축하고 있습니다. **MCP의 개념과 표준화의 이점** * MCP는 AI 어시스턴트와 외부 시스템 사이에서 '번역자' 역할을 수행하는 공통 통신 규격으로, 각 서비스마다 별도의 인터페이스를 구현해야 했던 번거로움을 해결합니다. * 도구 개발자가 MCP라는 단일 인터페이스만 구현하면, 이를 지원하는 다양한 AI 어시스턴트(Claude, Cline 등)에서 동일한 방식으로 기능을 호출할 수 있어 호환성과 확장성이 비약적으로 향상됩니다. **보안 리스크 관리와 사내 거버넌스 구축** * 외부 MCP 서버의 약 53%가 정적 API 키나 PAT에 의존하고 있다는 보안 취약점을 인지하고, OAuth 등 최신 인증 방식을 권장하며 철저한 보안 검증을 수행합니다. * 사내에서는 허용 목록(Allow-list) 제도를 운영하여 검증된 MCP 서버만 사용하도록 제한하며, 내부 업무 시스템 연동을 위해 사내 보안 요구사항을 충족하는 전용 MCP 서버를 직접 구축해 제공합니다. * 'Help LY MCP'와 같은 전용 지원 도구를 마련해 전 세계 그룹사 직원들이 복잡한 절차 없이 자사 조직에 AI를 적용할 수 있는지 검토할 수 있는 체계를 갖추었습니다. **AI 에이전트 기반의 실무 자동화 사례** * **Claude Code와 Jira 연동:** 워크숍 실습을 통해 Claude Code가 작업 내용을 요약하고 사내 그룹웨어 MCP를 통해 Jira 티켓을 자동으로 발행하는 과정을 구현하여 반복적인 관리 업무를 자동화했습니다. * **멀티 에이전트 코드 리뷰:** Claude 3.5 Sonnet이 코드의 문맥과 로직을 1차로 리뷰하면, Codex MCP를 통해 연결된 다른 모델(GPT-5 등)이 리뷰의 타당성을 검증하는 2단계 리뷰 프로세스를 구축하여 객관성을 높였습니다. **조직적 학습과 공유의 가치** * 기술 변화 속도가 매우 빠른 AI 분야에서는 개인의 학습에만 의존하지 않고, '워크숍'이라는 형식을 통해 조직 전체의 배경지식과 위험 인식을 동기화하는 것이 중요합니다. * '무엇이 가능한가', '어떤 함정이 있는가', '어떻게 활용해야 가치가 생기는가'라는 세 가지 관점을 팀 전체가 공유함으로써 실질적인 업무 개선으로 이어지는 추진력을 얻을 수 있습니다. AI 기술은 정답이 정해지지 않은 채 매우 빠르게 발전하고 있으므로, 완벽한 모범 사례를 기다리기보다 호기심을 바탕으로 작은 시도를 꾸준히 쌓아가는 자세가 중요합니다. MCP 서버와 같은 최신 프로토콜을 적극적으로 탐구하고 팀 내에 공유하는 문화를 조성하는 것이 다가오는 AI 시대의 핵심 경쟁력이 될 것입니다.

AI로 리뷰 정체를 해소하다 - PR 리뷰 지원과 사내 워크숍으로 리뷰 문화 바꾸기 (새 탭에서 열림)

개발 생산성을 저해하는 리뷰 정체 현상을 해결하기 위해 AI 스크리닝 리뷰와 프로세스 체계화를 도입하여 팀의 업무 효율을 극대화한 사례를 소개합니다. 단순히 도구를 사용하는 수준을 넘어 Claude Code의 커스텀 명령어를 활용해 'AI의 1차 점검 후 사람의 최종 판단'이라는 2단계 리뷰 체계를 구축함으로써, 리뷰어의 부담을 줄이고 코드 품질을 안정적으로 유지할 수 있었습니다. 이러한 기술적 장치와 PR 작성 자동화 등의 문화적 노력이 결합될 때 지속 가능한 개발 환경이 만들어진다는 것이 핵심입니다. ## 리뷰 정체와 기술적 부채의 발생 * **특정 인원에게 집중된 리뷰 부하(SPOF):** 소수의 테크 리드나 숙련된 엔지니어에게 리뷰가 집중되면서, 자신의 구현 업무와 리뷰 대응을 병행해야 하는 과부하 상태가 지속되었습니다. * **효율과 품질의 트레이드오프:** 리뷰 속도를 높이면 버그 누락 위험이 커지고, 꼼꼼히 리뷰하면 전체 개발 속도가 늦어지는 딜레마에 빠졌습니다. * **리뷰 대기 시간 증가:** PR이 쌓이면서 구현 담당자가 다음 작업으로 전환하는 데 병목이 발생하고 프로젝트 전체의 리드 타임이 길어지는 문제가 나타났습니다. ## AI 스크리닝 리뷰 시스템의 도입 * **단순 요약의 한계 극복:** 초기에는 AI에 PR 내용을 붙여넣는 방식을 시도했으나, 매번 프롬프트를 입력해야 하는 번거로움 때문에 실무 정착에 실패했습니다. * **Claude Code 커스텀 명령어 활용:** 사내에 도입된 Claude Code를 이용해 리뷰 명령어를 자동화함으로써, 별도의 프롬프트 준비 없이 한 번의 명령으로 정교한 리뷰가 가능해졌습니다. * **2단계 리뷰 프로세스:** AI가 먼저 변경 사항 요약, 영향 범위 분석, 코딩 규칙 위반 여부, 잠재적 버그를 점검하여 리포트를 제공하면, 리뷰어는 이를 바탕으로 최종 판단만 내리는 방식으로 전환했습니다. ## Claude Code를 활용한 리뷰 자동화 디테일 * **단계적 분석 절차:** AI가 단순히 코드만 보는 것이 아니라 `gh` 커맨드로 PR 메타 정보와 코멘트 이력을 가져와 배경지식을 파악하고, 전체 코드베이스의 의존 관계까지 조사하도록 설계했습니다. * **리뷰어용 코멘트 제안:** AI가 지적 사항에 대해 `[must]`, `[want]`, `[imo]` 등의 라벨을 붙여 구현자에게 보낼 코멘트 초안을 작성해 줌으로써 리뷰어의 커뮤니케이션 비용을 절감했습니다. * **체크아웃 및 환경 동기화:** PR 브랜치를 자동으로 체크아웃하고 파일 차분(diff)을 직접 확인하여 분석의 정확도를 높였습니다. ## 선순환을 만드는 PR 작성 자동화와 조직 문화 * **PR 작성 지원:** 리뷰 효율을 높이기 위해 작성 단계부터 AI가 커밋 차분을 분석하여 제목과 배경, 변경 내용을 템플릿에 맞춰 자동으로 작성하도록 자동화했습니다. * **데이터 기반의 정확도 향상:** 충실하게 작성된 PR 설명은 다시 AI 스크리닝 리뷰의 분석 정확도를 높이는 데이터로 활용되어 리뷰 품질의 선순환을 만듭니다. * **지속 개선 구조:** '효율화-정확도 기반-문화 형성-지속 개선'이라는 네 가지 축을 바탕으로 기술과 문화가 조화를 이루는 통합적인 리뷰 환경을 지향합니다. 리뷰 정체 문제를 해결하고 싶다면 단순히 AI에게 "이 코드를 리뷰해줘"라고 요청하는 단발성 시도에서 벗어나야 합니다. Claude Code와 같은 도구를 활용해 팀의 코딩 규칙과 워크플로우를 반영한 **커스텀 명령어를 구축**하고, AI가 1차 스크리닝을 담당하게 하여 사람이 '최종 의사결정'에만 집중할 수 있는 환경을 만드는 것을 추천합니다. 이러한 체계화는 리뷰어의 심리적 부담을 줄일 뿐만 아니라 팀 전체의 개발 속도를 비약적으로 향상시키는 실질적인 해법이 됩니다.

AI 활용의 열쇠는 '조직적 학습'에 있다 - Orchestration Development Workshop의 시작 (새 탭에서 열림)

LY Corporation은 AI 도입 초기 단계를 넘어, 여러 AI를 유기적으로 연계하여 엔지니어의 창의성을 극대화하는 ‘오케스트레이션 개발 워크숍(Orchestration Development Workshop)’을 본격적으로 시작했습니다. 이 워크숍은 단순한 도구 활용을 넘어 AI와 협업하는 조직으로 진화하기 위한 실무 중심의 배움터로, 반복적인 업무를 자동화함으로써 엔지니어가 보다 가치 있는 설계와 창의적 활동에 집중할 수 있는 환경을 구축하는 것을 최종 목표로 합니다. **여러 AI를 연계하는 ‘오케스트레이션’ 개발 방식** * AI 오케스트레이션은 단일 도구 사용을 넘어, 여러 AI를 조합해 복잡한 개발 프로세스를 일괄 수행하는 '협주형' 개발 방식을 의미합니다. * 주요 사례로 Jira 티켓 기반 코드 자동 생성, 테스트 및 리뷰 수행, Pull Request(PR) 작성까지 AI가 연속적으로 처리하는 워크플로우를 제안합니다. * Slack을 통해 접수된 장애 보고를 바탕으로 AI가 원인을 추정하고 즉각적인 수정안을 제시하는 등 실전적인 대응 모델을 포함합니다. **지속적인 지식 확산을 위한 3단계 조직 구조** * 특정 개인의 열정에만 의존하지 않고 조직 전체가 성장할 수 있도록 ‘추진(DevRel)’, ‘현장 인사이트(길드)’, ‘품질 보증(TD)’의 체계적인 협력 구조를 구축했습니다. * DevRel 조직은 프로젝트의 운영과 전사적 확산을 담당하며 지식 전파의 엔진 역할을 수행합니다. * 현장 엔지니어로 구성된 길드가 실무 지식을 제공하고, TD(Technical Director)가 콘텐츠의 품질과 재현성을 검증하여 교육의 신뢰도를 높입니다. **실무 재현성을 극대화한 양방향 학습 설계** * ‘보기만 하다 끝나지 않는다’는 슬로건 아래, 참가자가 발표자의 화면을 보며 실시간으로 따라 하는 핸즈온(Hands-on) 실습 환경을 제공합니다. * Zoom을 통한 실시간 대화와 Slack을 활용한 질문 수집을 병행하여, 학습 과정에서 발생하는 과제를 그 자리에서 즉시 해결하는 양방향 소통을 지향합니다. * 단순한 지식 전달을 넘어 각 엔지니어가 자신의 실제 프로젝트에서 AI 오케스트레이션을 재현할 수 있는 실질적인 기술 습득에 초점을 맞춥니다. **엔지니어의 창의성 해방과 미래 전망** * AI 활용의 본질은 단순한 작업 속도 향상이 아니라, 엔지니어를 반복 작업에서 해방시켜 고부가가치 설계 영역에 집중하게 만드는 것입니다. * 생성형 AI뿐만 아니라 비생성형 AI까지 아우르는 폭넓은 주제를 다루며, 사내에서 축적된 AI 주도 개발 노하우를 기술 블로그 등 외부 채널을 통해 적극적으로 환원할 예정입니다. AI가 코드를 작성하고 인간이 리뷰하는 단계를 넘어, 설계 단계부터 AI와 긴밀히 협업하는 시대가 오고 있습니다. 이제 엔지니어는 개별 코딩 기술에 매몰되기보다 여러 AI를 조율하고 제어하는 '오케스트레이터'로서의 역량을 갖추는 것이 필수적입니다. LY Corporation의 사례처럼 실무 중심의 핸즈온 학습을 통해 AI와 함께 만드는 조직 문화를 선제적으로 경험해 보길 추천합니다.

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀 (새 탭에서 열림)

LINE Plus는 수억 건에 달하는 상품 데이터를 처리하기 위해 기존에 사용하던 전체 데이터 복제(Full Dump) 방식의 ETL 구조를 탈피하고, Apache Iceberg와 Apache Flink를 결합한 증분(Incremental) 처리 구조를 도입했습니다. 이를 통해 데이터 규모가 커질수록 기하급수적으로 늘어나던 업데이트 비용과 시간을 대폭 절감하였으며, 결과적으로 데이터 반영 주기를 60분에서 5분으로 단축하여 약 12배의 성능 향상을 이루어냈습니다. 이 글은 대규모 데이터 환경에서 실시간성에 가까운 데이터 최신성을 확보하기 위한 기술적 여정과 엔진 선택의 근거를 상세히 다룹니다. **기존 전체 데이터 복제 방식의 한계** * **리소스 낭비와 지연:** 매번 수억 건의 전체 데이터를 다시 써야 하는 구조로 인해 데이터 규모가 커질수록 처리 비용이 증가하고, 사내 Hadoop 리소스 부족 시 업데이트 주기가 지연되는 문제가 발생했습니다. * **데이터 최신성 결여:** 스냅숏 기반의 추출 방식은 정합성은 보장하지만, 추출 작업에 걸리는 시간만큼 데이터가 과거 시점에 머물게 되어 라이브 서비스에서의 실시간 대응이 어려웠습니다. * **운영 DB 부하:** 대용량 데이터를 한꺼번에 추출할 때 발생하는 막대한 디스크 I/O와 Undo 세그먼트 팽창은 운영 환경의 성능 저하를 유발하는 고질적인 원인이 되었습니다. **Apache Iceberg를 통한 증분 처리 기반 마련** * **테이블 형식의 변화:** 기존 Hive의 디렉터리 기반 관리 방식에서 벗어나, 메타데이터를 이용해 스냅숏 단위로 파일을 추적하는 Iceberg 형식을 도입했습니다. * **행 단위 업데이트 지원:** 전체 데이터를 다시 쓸 필요 없이 변경된 행(row)만 선택적으로 업데이트(upsert)하거나 삭제(delete)할 수 있어, 데이터 규모와 상관없이 일정한 업데이트 비용을 유지할 수 있게 되었습니다. **Apache Flink 선택의 결정적 이유** * **스테이트풀(Stateful) 처리를 통한 최신성 보장:** Flink의 DataStream API를 활용해 `updatedate`를 상태값으로 관리함으로써, 컨슈머 랙 등으로 인해 뒤늦게 도착한 과거 데이터가 최신 데이터를 덮어쓰는 문제를 원천 차단했습니다. * **2단계 커밋(2PC) 기반의 정확히 한 번 처리:** Iceberg 테이블 쓰기와 Kafka 상태 메시지 발행을 하나의 트랜잭션으로 묶어, 데이터 누락이나 중복 없이 '전부 아니면 전무(All-or-Nothing)'의 정합성을 보장했습니다. * **강력한 장애 허용(Fault Tolerance):** 체크포인트 메커니즘을 통해 시스템 장애 발생 시에도 마지막 성공 지점부터 즉시 복구가 가능하며, 관리하던 상태값을 유실 없이 유지할 수 있습니다. **효율적인 운영을 위한 쿠버네티스 오퍼레이터 도입** * **운영 자동화:** 설정 작업을 수동으로 진행해야 하는 네이티브 쿠버네티스 방식 대신, Flink 쿠버네티스 오퍼레이터를 도입하여 라우팅, 웹 UI 구성 등 운영 요소를 커스텀 리소스로 추상화하고 관리를 자동화했습니다. * **격리 및 확장성:** 애플리케이션 모드를 통해 잡(job)별 클러스터 격리 수준을 높이고, 헬름(Helm) 차트를 이용해 손쉽게 배포 및 확장할 수 있는 환경을 구축했습니다. 대규모 데이터셋에서 실시간에 가까운 데이터 동기화와 엄격한 정합성이 모두 필요하다면, 단순한 배치 처리보다는 Flink와 Iceberg의 조합을 통한 증분 파이프라인 구축을 권장합니다. 특히 Flink의 2단계 커밋과 체크포인트 기능을 활용하면 분산 환경에서도 데이터 무결성을 보장하면서 시스템의 업데이트 주기를 획기적으로 단축할 수 있습니다.

도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까? (새 탭에서 열림)

MessagingHub는 서비스마다 개별적으로 구축해야 했던 채팅 기능을 통합하여 플랫폼화함으로써 개발 비용을 절감하고 시스템 복잡도를 낮춘 메시징 플랫폼입니다. 특정 도메인에 의존하지 않는 독립성과 범용성을 바탕으로 챗봇, 상담 채팅, 1:1 대화 등 다양한 요구사항을 레고처럼 조합할 수 있는 구조로 설계되었습니다. 결과적으로 연동 서비스는 비즈니스 로직에만 집중하고, 채팅의 핵심 기능과 연결 관리는 플랫폼이 전담하여 효율적인 서비스 운영이 가능해졌습니다. ### 도메인 독립적인 인증 및 사용자 식별 * **연동 측 책임 중심의 인증:** MessagingHub는 직접 사용자를 관리하지 않고, 연동 시스템이 인증을 마친 후 요청한 연결 토큰(connection token)을 검증하여 웹소켓 연결을 허용합니다. * **유연한 사용자 식별:** 도메인 정보와 연동 측 식별자를 조합한 ‘client ID’를 사용해 여러 서비스의 사용자를 구분하며, 닉네임이나 프로필 같은 부가 정보는 연동 측에서 실시간으로 갱신하도록 설계되었습니다. * **서비스 컨텍스트 기반 제어:** '누가 누구와 대화하는지(Driver2CS 등)'를 정의하는 서비스 컨텍스트와 채팅방 유형(1:1, 그룹, 챗봇 등)의 조합을 통해 세밀한 접근 권한과 메시지 허용 정책을 관리합니다. ### 관심사 분리를 통한 모듈형 아키텍처 * **컴포넌트 기반 구조:** 연결 관리(connection-manager), 비즈니스 로직(chat-app), 메시지 중계(message-router), 알림(notification-app) 등 각 기능을 독립적인 컴포넌트로 분리하여 R&R을 명확히 했습니다. * **커맨드(Command) 패턴 활용:** 채팅의 모든 동작을 커맨드 단위로 정의하여 챗봇이나 상담 채팅 등 서비스 성격에 맞게 기능을 유연하게 조합하고 확장할 수 있습니다. * **이벤트 기반 연동:** 각 컴포넌트는 이벤트 기반으로 느슨하게 결합되어 있어, 특정 기능의 변경이 전체 시스템에 미치는 영향을 최소화했습니다. ### 효율적인 데이터 관리와 메시지 순서 보장 * **메시지 체이닝 및 상태 관리:** `prev_chat_log_id`를 사용하여 메시지 간 순서를 보장하며, 읽음 위치(`last_seen_chat_log_id`)와 전체 메시지 범위를 비교하여 정확한 안 읽은 메시지 수를 산출합니다. * **JSON 컬럼을 통한 확장성:** 연동 측에서 필요로 하는 도메인 특화 데이터(검색용 데이터, 사용자 상세 정보 등)를 MessagingHub가 해석하지 않고 JSON 형태로 그대로 보관 및 전달함으로써 범용성을 확보했습니다. * **보안 및 자동 삭제:** 모든 메시지는 암호화하여 저장되며, 참여자 이탈에 따른 즉시 삭제나 설정된 보관 기간에 따른 자동 삭제 정책을 지원합니다. ### 챗봇 시나리오의 안정적인 배포와 SOFT STOP 정책 * **계층적 시나리오 구조:** 관리자 도구를 통해 시나리오를 편집하고 배포할 수 있으며, 답변과 선택지 및 외부 연동을 위한 웹훅 기능을 지원합니다. * **SOFT STOP 상태 도입:** 새로운 시나리오 배포 시, 기존 대화 중인 사용자는 이전 버전을 유지하고 신규 사용자에게만 새 버전을 노출하는 'SOFT STOP' 단계를 두어 사용자 경험의 단절을 방지합니다. * **지능형 스케줄링:** 스케줄러가 이전 버전 시나리오의 잔여 연결 정보를 주기적으로 체크하여, 더 이상 사용하는 사용자가 없을 때 자동으로 해당 버전을 종료 처리합니다. ### 상담 효율을 높이는 문의형 채팅 최적화 * **상담 컨텍스트 제공:** 상담원이 사용자 정보를 별도로 조회할 필요가 없도록, 채팅방 생성 시 연동 측으로부터 전달받은 검색 데이터, 추적 데이터 등 풍부한 메타데이터를 상담 화면에 함께 제공합니다. * **생명 주기 관리:** 상담 대기(PENDING)부터 종료(DISABLE) 및 재진입 방지(BLOCK)까지 이어지는 상담 전용 상태 관리를 통해 상담 프로세스의 일관성을 유지합니다. MessagingHub와 같은 채팅 플랫폼 도입은 서비스 확장 속도가 빠르고 다양한 소통 창구가 필요한 환경에서 특히 유용합니다. 채팅 기능을 직접 구현하기보다는, 인증과 데이터 처리는 전문 플랫폼에 맡기고 도메인 특화 데이터(Metadata)를 적극 활용하는 방향으로 설계한다면 시스템의 유연성과 운영 효율을 동시에 확보할 수 있을 것입니다.

LINE 서비스의 대규모 광고 데이터를 처리하기 위한 Spark on Kubernetes 적용기 (새 탭에서 열림)

LINE 광고 플랫폼(LINE Ads) 팀은 급격히 증가하는 광고 데이터와 연산량을 효율적으로 처리하기 위해 기존 Hadoop 기반의 YARN 환경을 Spark on Kubernetes로 전환했습니다. 기존 구조의 자원 경합 및 인프라 종속성 문제를 해결함으로써, 컴퓨팅과 스토리지를 분리하고 컨테이너 기반의 유연한 운영 환경을 구축하는 데 성공했습니다. 이를 통해 데이터 파이프라인의 확장성을 확보하고 최신 기술 스택을 자유롭게 활용할 수 있는 인프라 독립성을 달성했습니다. **기존 Spark on YARN의 구조적 한계** * **자원 경합 발생:** HDFS 스토리지와 컴퓨팅 자원이 단일 노드에 결합된 구조여서, 대규모 연산 시 HDFS 서비스와 Spark 작업 간의 리소스 간섭이 발생했습니다. * **확장의 비효율성:** 컴퓨팅 자원만 필요한 상황에서도 Hadoop 노드 전체를 증설해야 하므로 운영 비용과 스토리지 낭비가 초래되었습니다. * **환경 종속성:** Hadoop 클러스터의 설정에 묶여 있어 최신 Spark 버전이나 특정 라이브러리, JVM 환경을 자유롭게 변경하기 어려웠습니다. **Spark on Kubernetes의 작동 원리와 장점** * **파드 기반 실행:** Spark 드라이버와 익스큐터를 독립적인 Kubernetes 파드로 실행하며, Kubernetes가 클러스터 매니저 역할을 수행하여 리소스를 할당합니다. * **클러스터 모드 채택:** `spark-submit`을 통해 드라이버 파드를 먼저 생성하고, 드라이버가 직접 익스큐터 파드를 요청 및 관리하는 방식을 통해 운영 권한을 Kubernetes에 위임했습니다. * **완전한 컨테이너화:** 모든 의존성을 Docker 이미지에 포함하여 환경 재현성을 높였으며, CI/CD 파이프라인과의 연동이 쉬워졌습니다. **인프라 독립성 및 운영 효율성 확보** * **스토리지 자유도:** HDFS에 국한되지 않고 S3, GCS 등 다양한 클라우드 네이티브 스토리지를 자유롭게 선택할 수 있는 기반을 마련했습니다. * **오토 스케일링 용이:** 클러스터 오토스케일러를 통해 워크로드에 따라 유연하게 자원을 확장할 수 있으며, 온프레미스 제약에서 벗어났습니다. * **거버넌스 강화:** 네임스페이스와 리소스 쿼터(ResourceQuota)를 활용해 팀별로 자원을 격리하고, RBAC 기반의 세밀한 권한 제어가 가능해졌습니다. **통합 데이터 플랫폼을 위한 레이어 구성** * **배포 레이어:** GitHub Actions와 ArgoCD를 결합하여 코드 기반의 자동 배포 및 실시간 상태 모니터링, 손쉬운 롤백 체계를 구축했습니다. * **컴퓨팅 레이어:** Spark Operator를 도입해 Kubernetes 커스텀 리소스(CRD)로 앱을 관리하며, Apache YuniKorn을 통해 배치 잡 스케줄링을 최적화했습니다. * **관측성 및 로깅:** 파드의 로그를 OpenSearch에 실시간 적재하고, Prometheus 지표를 통해 Spark 애플리케이션의 성능을 정밀하게 모니터링합니다. 대규모 데이터 처리가 필요한 환경에서 인프라 유연성과 운영 자동화를 동시에 달성하고자 한다면 Spark on Kubernetes 도입을 적극 권장합니다. 특히 컴퓨팅과 스토리지를 분리하여 비용을 최적화하고, 다양한 워크로드를 하나의 클러스터에서 통합 운영하려는 조직에 매우 효과적인 솔루션이 될 것입니다.

대규모 서비스 환경에서의 이미지 콘텐츠 모더레이션(feat. 멀티모달 LLM) (새 탭에서 열림)

대규모 플랫폼에서의 이미지 콘텐츠 모더레이션은 방대한 데이터 처리 성능과 정교한 맥락 이해라는 두 가지 과제를 동시에 해결해야 하는 고난도 영역입니다. LY Corporation은 전통적인 ML 모델과 멀티모달 LLM을 결합한 하이브리드 구조를 도입하고 vLLM 프레임워크를 최적화함으로써 높은 탐지 정확도와 비용 효율성을 모두 달성했습니다. 이를 통해 단순히 시각적 객체를 인식하는 수준을 넘어, 이미지 내 텍스트와 정황을 결합해 정책 위반의 의도까지 파악할 수 있는 선제적 대응 체계를 구축했습니다. ### 이미지 모더레이션의 기술적 난제 * **비정형성과 시각적 복잡성**: 이미지는 배경, 객체, 구도 등 다양한 요소가 복합적으로 작용하며, 동일한 객체라도 상황에 따라 유해성 여부가 달라지는 맥락 의존성이 높습니다. * **교묘한 우회 시도**: 밈(Meme), 일부 가리기, 생성형 AI를 활용한 합성 등 탐지 시스템을 회피하기 위한 변형이 지속적으로 발생하여 난이도가 상승하고 있습니다. * **대규모 처리 인프라 요구**: 하루 수백만 건 이상의 이미지를 실시간에 가깝게 처리해야 하므로, 높은 정확도뿐만 아니라 낮은 지연 시간(Latency)과 운영 비용 효율이 필수적입니다. ### 높은 정확도와 처리 속도를 위한 3단계 최적화 * **전통적 ML 모델의 고도화**: PyTorch 기반 모델을 ONNX 형식으로 변환하고 FP16(Half Precision) 정밀도를 적용하여, 메모리 사용량을 줄이면서도 처리량을 최대 4.3배까지 개선했습니다. * **ML과 LLM의 하이브리드 파이프라인**: 1차 필터(ML 모델)가 명확한 데이터를 90% 이상 신속히 처리하고, 판단이 모호한 사례만 2차 필터(멀티모달 LLM)로 전달하여 LLM의 높은 연산 비용을 효율적으로 관리합니다. * **vLLM 기반 성능 극대화**: * `enable_prefix_caching`: 반복되는 시스템 프롬프트의 KV 캐시를 재사용하여 연산량을 절감했습니다. * `max_model_len` 및 `max_num_seqs`: 메모리 과할당을 방지하고 서비스 특성에 맞는 동시 처리 수를 조절하여 지연 시간을 안정화했습니다. * `max_num_batched_tokens`: 프리필(Prefill) 중심의 워크로드에 맞춰 설정하여 GPU 자원 활용도를 높였습니다. ### 맥락과 의도를 파악하는 하이브리드 판별 구조 * **단일 모델의 한계 극복**: 특정 객체의 존재 여부만 학습하던 기존 엔드 투 엔드(End-to-End) 모델에서 벗어나, 국가별·서비스별로 복잡한 정책을 유연하게 적용할 수 있는 구조로 재설계했습니다. * **시각 정보와 텍스트의 결합**: OCR(광학 문자 인식) API를 통합하여 이미지 내 텍스트를 추출하고, 이를 시각 정보와 결합해 단순 노출이 아닌 '판매 행위'나 '특정 의도'가 담긴 콘텐츠를 정교하게 판별합니다. * **확장성 있는 의사 결정**: 모든 정책을 모델이 직접 학습하는 대신, 정보를 분리하여 추출하고 멀티모달 LLM이 추론하는 방식을 통해 빠르게 변화하는 운영 정책에 유연하게 대응합니다. ### 실용적인 권장 사항 대규모 이미지 모더레이션 시스템을 설계할 때는 모든 데이터를 고성능 모델로 처리하기보다, 데이터의 분포를 분석하여 다수의 일반 케이스를 저비용 모델로 걸러내는 **계층적 구조**를 설계하는 것이 중요합니다. 또한 vLLM과 같은 최신 서빙 프롬프트의 최적화 옵션을 적극적으로 활용하고, 비동기 스케줄링 및 양자화 기술을 지속적으로 업데이트하여 인프라 효율을 높일 것을 권장합니다.

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로 설정하고 외부 시스템을 유연하게 연결하는 아키텍처를 고민해 보시기 바랍니다.

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

사양서나 소스 코드를 참조할 수 없는 블랙박스 상태의 레거시 시스템을 내재화하기 위해, 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 배치 검증을 병행하여 실시간 스트림에서 놓칠 수 있는 트리거 누락 결함까지 포착했습니다. **성공적인 시스템 전환을 위한 제언** 복잡한 시스템의 내재화는 단순히 코드를 옮기는 것이 아니라 '기존과 동일하게 작동함'을 객관적으로 입증하는 과정입니다. 데이터 스트림 기반의 자동화된 검증 체계를 구축하면 블랙박스 로직의 베일을 하나씩 벗겨낼 수 있을 뿐만 아니라, 실시간 트래픽 환경에서의 성능 비교 지표까지 확보하여 안정성과 성능이라는 두 마리 토끼를 모두 잡을 수 있습니다.

신뢰성 향상을 위한 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)의 명확한 정의'**와 **'조직 간의 공통 언어 수립'**이 선행되어야 합니다. 또한, 표준화된 템플릿과 자동화된 상태 확인 도구를 결합함으로써 커뮤니케이션 비용을 줄이고 데이터에 기반한 의사결정 속도를 높일 수 있습니다.

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` 설계를 참고했습니다. * 이는 개별 서비스가 자신의 도메인에 맞는 설계를 독립적으로 확장할 수 있게 하여, 거대해진 프로젝트 규모에 대응할 수 있는 유연한 기반을 마련하는 계기가 되었습니다.

완벽한 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) 체계를 구축하는 것이 권장됩니다. 또한 정책 변화에 유연하게 대응할 수 있도록 정책 문서를 가드레일에 실시간으로 반영하는 자동화 파이프라인을 구축하는 것이 장기적인 운영 효율성 측면에서 유리합니다.

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

메신저용 온디바이스 이미지 모델 학습기 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) 향상보다 중요한 것은 실제 사용자 환경에서의 '수락 가능한 품질'과 '지연 시간'의 균형입니다. 단순히 모델을 작게 만드는 것에 그치지 않고, 디코딩 패러다임을 비자기회귀로 전환하고 데이터의 질을 높이는 지식 증류 과정을 반복하는 것이 모바일 환경에 최적화된 고성능 모델을 만드는 핵심 전략입니다.