line·2026년 8월 7일·4분 읽기큐레이션 요약

개인 AI 활용의 다음 단계는 무엇인가 - LY Corporation에서 AIDD 워크숍을 통해 살펴본 AIDD 조직 도입의 조건

LY Corporation은 개인의 AI 활용을 조직 차원의 재현 가능한 개발 방식으로 확장하기 위해 팀 단위 AIDD 워크숍을 진행했습니다. 워크숍의 핵심 결론은 AI 도구 자체보다 요구 사항, 사양, 용어, 제약 조건 등 컨텍스트를 정비하고 사람과 AI의 역할·책임을 설계하는 일이 더 중요하다는 것입니다. 또한 조직적 도입을 위해서는 다양한 직군과 의사결정자가 실제 업무 주제를 함께 다뤄야 합니다. ## AIDD의 정의와 지향점 - AIDD는 요구 사항 정리부터 설계, 구현, 리뷰까지 개발 전 과정에서 AI를 협력자로 활용하는 방식입니다. - AI에 업무를 일괄 위임하는 것이 아니라, AI가 초안을 만들고 사람이 의도·제약 조건을 제공하며 핵심 판단과 책임을 맡습니다. - 각 단계의 결과를 다음 단계로 연결하는 통합된 개발 프로세스를 설계하는 것이 중요합니다. - 따라서 AIDD는 단순한 보조 도구 활용이 아니라, AI와 사람의 역할 분담을 포함한 개발 방식의 재설계입니다. ## 개인 활용에서 조직 도입으로 넘어가는 장벽 - AI 코딩 에이전트는 코드 자동 완성, 테스트, 리서치, 문서 작성 등에 널리 활용되고 있습니다. - 그러나 다음과 같은 문제로 개인의 노하우에 머무르기 쉽습니다. - 개인이 사용해도 팀의 개발 프로세스와 연결되지 않음 - AI 산출물의 리뷰 기준과 책임 범위가 불명확함 - 기존 제품과 코드베이스에 적용하는 방법이 모호함 - 편리함은 확인했지만 조직 차원의 투자와 표준화로 이어지지 않음 - 워크숍은 이러한 정체를 해결하고, 조직이 AI를 활용하기 위한 ‘AI Ready’ 조건을 확인하는 데 목적이 있었습니다. ## 팀 단위 워크숍을 선택한 이유 - AI 활용의 성과는 프롬프트 작성 능력보다 정보 전달, 리뷰 지점, 최종 산출물 기준, 피드백 흐름에 좌우됩니다. - 기획, 디자인, 엔지니어링, 리더십 등 여러 역할의 관점과 암묵지가 함께 드러나야 프로세스를 설계할 수 있습니다. - 팀 단위로 실제 업무를 다루면 다음 논점이 구체화됩니다. - 어떤 업무에 AI를 적용할 것인가 - 누가 AI 산출물을 검토할 것인가 - 어떤 결과물을 공식 산출물로 인정할 것인가 - 책임과 의사결정의 경계를 어디에 둘 것인가 - 의사결정자가 참여하면 적용 범위, 투자 우선순위, 표준화 수준을 워크숍 이후 실행으로 연결하기 쉬워집니다. ## 이틀간의 프로그램 구성 - 첫째 날에는 문제 정의와 업무 컨텍스트 정리에 집중했습니다. - 둘째 날에는 팀이 자율적으로 AI 활용을 검증하고 실제 업무에 적용 가능한 형태로 구체화했습니다. - 21개 팀, 112명이 실제 프로젝트 주제를 가져와 실습했습니다. - Orchestration 길드, Developer Relations, Technical Directors가 콘텐츠 구성과 멘토링, 학습 공유를 지원했습니다. - 단순한 도구 시연이 아니라 이해, 실습, 검증, 공유를 반복하는 실천 중심 구조였습니다. ## 구현보다 중요한 사전 정리 - AI 코딩 에이전트의 코드 생성 속도보다 그 이전 단계의 정리 작업이 더 큰 가치로 인식되었습니다. - 특히 다음 작업이 중요했습니다. - 모호한 요구 사항을 논점별로 분해하기 - 요구 사항을 명확한 언어로 정의하기 - 팀 내부의 인식을 일치시키기 - 선행 의사결정과 우선순위를 정하기 - 다음 작업 단위로 구체화하기 - AI가 개발을 전진시키려면 사람이 목적과 제약 조건을 먼저 명확히 해야 합니다. ## 병목은 AI 도구가 아니라 컨텍스트 - AI 출력의 품질은 제공되는 컨텍스트의 품질에 크게 의존합니다. - 필요한 컨텍스트에는 다음이 포함됩니다. - 사양과 용어 - 제약 조건 - 설계 의도와 판단 이유 - 기존 코드와 기능 간의 관계 - 운영 규칙 - 컨텍스트가 부족하면 AI가 그럴듯한 답을 내더라도 실무 적용이 어렵고, 사람의 리뷰 부담이 커집니다. - 따라서 컨텍스트 정리는 부수적인 준비가 아니라 조직적 AI 활용을 위한 핵심 기반입니다. ## 팀 협업과 의사결정자의 역할 - 개인 실험에서는 잘 드러나지 않던 합의 형성, 책임 범위, 리뷰 기준이 팀 단위 활동에서 명확해졌습니다. - 서로 다른 직군이 같은 업무를 검토하면서 역할별 인식 차이와 숨은 전제가 드러났습니다. - 리더나 의사결정자가 참여한 팀은 워크숍 후에도 다음 실행으로 이어질 가능성이 높았습니다. - 조직 확산을 위해서는 다음을 결정할 사람이 초기 단계부터 참여해야 합니다. - 우선 적용 영역 - 투자할 시간과 자원 - 표준화할 대상 - 운영 프로세스에 내재화할 범위 ## 조직에 AIDD를 정착시키는 방법 - 처음에는 적용하기 쉬운 주제부터 시작해야 합니다. - 요구 사항이나 쟁점이 불명확한 업무 - 관계자 간 인식 정렬이 중요한 업무 - 기존 정보를 어느 정도 확보할 수 있는 업무 - 짧은 주기로 결과를 검증할 수 있는 업무 - 기능 하나, 요구 사항 정리 하나, 리뷰 기준 정리 하나처럼 작은 진입점을 마련해야 합니다. - 사양·용어·제약 조건·설계 의도를 정리하는 작업을 개인의 자발성에 맡기지 말고 공식 업무로 인정해야 합니다. - 컨텍스트 자산화는 AI를 위한 작업인 동시에 팀의 개발 역량과 지식을 강화하는 활동입니다. 실무적으로는 전사 도입을 서두르기보다, 의사결정자와 여러 직군이 참여하는 작은 팀에서 실제 업무 한 사이클을 검증하는 것이 좋습니다. 그 과정에서 컨텍스트, 리뷰 책임, 표준화 범위를 정리한 뒤 성공 사례를 조직 전체로 확장해야 합니다.

원문 읽기(새 탭에서 열림)

software-development코드 리뷰software-designcontext-engineering+4

line·2026년 7월 31일·5분 읽기큐레이션 요약

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다. ## 관측성 데이터가 분산되며 발생한 문제 - 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다. - 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다. - 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다. - Mimir: 메트릭 - Loki: 로그 - Tempo: 트레이스 - Pyroscope: 프로파일 - OpenTelemetry Collector: 데이터 수집 및 전달 - 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다. - 예를 들어 서비스명이 데이터소스마다 `service_name`, `resource.service.name` 등 다른 필드로 표현될 수 있습니다. ## 오픈소스 PoC에서 확인한 한계 - **사용자 컨텍스트와 권한 전파** - Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다. - **시스템 프롬프트 제어** - 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다. - **짧은 도구 호출 라운드** - 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다. - **데이터소스별 라벨 차이** - 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다. - **운영 및 라이선스 제약** - 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다. - 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다. ## SRELens 아키텍처 - SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다. - 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다. - 백엔드는 다음을 담당합니다. - LLM 호출 - 시스템 프롬프트 합성 - 도구 오케스트레이션 - 사용량 및 비용 제한 - 결과 크기와 재시도 제어 - 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다. - 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다. - `find_grafana_panel` - `render_grafana_panel` - 업스트림 도구와 로컬 도구는 `CompositeClient`를 통해 LLM에 일관된 인터페이스로 노출됩니다. ## 세 계층으로 분리한 프롬프트 설계 ### 베이스 시스템 프롬프트 - 조직 전체에 적용되는 전역 행동 정책입니다. - 다음과 같은 규칙을 포함합니다. - 도구 호출 순서 - 결과가 없을 때의 폴백 전략 - 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법 - 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙 - 응답 형식과 분석 근거 제시 방식 - 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다. ### 데이터소스 프래그먼트 - 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다. - 주요 내용은 다음과 같습니다. - 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID - 서비스명을 찾기 위한 라벨 후보 - Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법 - SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다. ### 사용자 프롬프트 - 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다. - Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다. - 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다. ## 백엔드 중심의 툴 오케스트레이션 - 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다. - 에이전트는 다음 루프를 반복합니다. 1. 사용자 질문을 LLM에 전달 2. LLM이 요청한 MCP 또는 로컬 도구 실행 3. 도구 결과를 다시 LLM에 전달 4. 최종 분석이 나올 때까지 반복 - 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다. - 최대 10라운드로 도구 호출 제한 - 동일 도구·동일 인자의 중복 호출 차단 - 도구별 재시도 최대 2회 - 개별 도구 결과 크기 제한 - 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환 - `tool_call_id`를 유지해 호출과 결과의 연결 보장 - 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도 ## 비용·요청량 및 장애 대응 정책 - 사용자별 일일 토큰 한도를 적용합니다. - 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다. - 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다. - 사용량은 Asia/Seoul 기준 자정에 초기화됩니다. - Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다. - Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다. - 대화 기록 및 개인화 기능은 제한될 수 있습니다. - SRELens 전체가 동시에 중단되지는 않습니다. ## 실제 장애 분석 방식의 변화 - 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다. - SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다. - 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 `CopyMedia` 호출 증가와 관련된 원인까지 범위를 좁혔습니다. - 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다. - 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다. 운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.

원문 읽기(새 탭에서 열림)

옵저버빌리티모델 컨텍스트 프로토콜redisgrafana+3

line·2026년 7월 30일·5분 읽기큐레이션 요약

AI 에이전트를 위한 Android CLI: 대규모 모바일 개발 환경에 적용하기

LINE Android처럼 수백 개의 Gradle 모듈과 대규모 코드를 가진 저장소에서는 단순한 `grep`·`glob` 검색만으로 AI 에이전트가 의미론적 질문에 답하기 어렵고, 불필요한 결과와 재시도로 토큰 비용이 급증합니다. LINE 개발팀은 Android CLI를 문서 검색과 Android Studio 연동의 기반으로 활용하되, 고정된 바이너리·래퍼·스킬·프롬프트를 조합해 보안, 환경 일관성, 오류 처리, 토큰 효율성을 보완하고 있습니다. 핵심은 CLI를 에이전트에 그대로 노출하지 않고, 저장소 규모와 조직 환경에 맞게 통제된 인터페이스로 제공하는 것입니다. ## 대규모 Android 저장소에서 AI 에이전트가 겪는 문제 - 수백 개의 Gradle 모듈과 방대한 코드 때문에 검색 한 번에도 지나치게 많은 결과가 반환됩니다. - 검색 결과가 에이전트 컨텍스트에 포함되면서 토큰과 비용이 빠르게 증가합니다. - 텍스트 검색만으로는 다음과 같은 의미론적 질문에 정확히 답하기 어렵습니다. - 특정 심볼의 선언 위치 - 심볼의 실제 참조 위치 - IDE가 판단하는 사용되지 않는 코드나 경고 - 의존성 내부 심볼의 위치 - 관련 없는 결과를 바탕으로 에이전트가 반복 검색과 재시도를 수행하면서 비효율이 커집니다. - 따라서 Android CLI를 그대로 적용하기보다는 래퍼, 스킬, 프롬프트를 통한 보완이 필요합니다. ## 문서 검색을 Android CLI로 전환 - Android CLI는 빌드·배포, SDK 관리, 환경 진단, 공식 문서 검색, Android Studio 연동 등을 제공합니다. - 첫 적용 대상은 Android, Jetpack Compose, AndroidX, Firebase 등의 공식 문서 검색이었습니다. - 모델의 사전 학습 지식은 최신 API 변경을 반영하지 못할 수 있어 잘못된 시그니처를 생성하는 환각이 발생할 수 있습니다. - 최신 Android Knowledge Base를 직접 참조하면 문서의 권위와 최신성을 확보할 수 있습니다. - 기존에는 Google Cloud Knowledge MCP 서버를 사용했지만 다음 운영 부담이 있었습니다. - 개발자별 Google Cloud API 인증 설정 - 인증 프록시 운영 - API 할당량 제한 대응 로직 유지 - Android CLI의 `docs` 명령은 다음 두 단계로 사용됩니다. - `docs search`: 키워드로 공식 문서 검색 - `docs fetch`: 검색 결과의 KB URL로 문서 본문 조회 - 이 기능은 `get-android-dev-knowledge` 스킬로 에이전트에 제공됩니다. - 기존 MCP 방식과 비교해 인증, 프록시, 할당량 처리 인프라를 제거하고 더 적은 토큰으로 최신 문서를 참조할 수 있습니다. ## CLI 바이너리를 저장소에 번들링한 이유 LINE 팀은 전역 설치된 `android` 명령 대신 `.agents/tools/android-cli/android`처럼 저장소 내부의 고정 경로에 바이너리를 포함했습니다. ### 환경 파편화 방지 - 개발자마다 CLI 버전, 설치 위치, 운영체제가 달라지는 문제를 줄입니다. - 저장소를 클론하면 동일한 버전을 사용할 수 있습니다. - 개발자 장비뿐 아니라 CI와 AI 에이전트 실행 호스트에서도 동일한 환경을 보장합니다. ### 보안 정책과 래퍼 적용 - Android CLI는 호출 과정에서 일부 데이터를 수집할 수 있습니다. - 이를 막으려면 호출마다 `--no-metrics` 인자를 지정해야 합니다. - 에이전트가 해당 인자를 누락할 수 있으므로 모든 호출을 통과시키는 래퍼에서 강제하는 방식이 안전합니다. - 래퍼가 실제 바이너리를 안정적으로 찾으려면 바이너리 위치가 고정되어 있어야 하므로 저장소 번들링이 유리합니다. - 대규모 저장소에 이미 `git-lfs`가 적용되어 있어 바이너리 포함 비용도 감당할 수 있었습니다. ## `--no-metrics` 관련 버그와 오류 출력 개선 - Android CLI 1.0 도입 과정에서 정보 수집 기능이 `--no-metrics` 처리 전에 초기화되는 버그가 발견되었습니다. - 이 때문에 메트릭 수집을 비활성화해도 `~/.android/cli`에 쓰기를 시도할 수 있습니다. - 샌드박스나 파일 시스템 권한으로 쓰기가 차단되면 여러 페이지의 Java 스택 트레이스가 출력됩니다. - 장황한 스택 트레이스는 에이전트 컨텍스트를 불필요하게 차지하고 문제 해결도 어렵게 만듭니다. - 래퍼는 CLI 실행 전에 다음을 수행합니다. - `~/.android/cli` 디렉터리 생성 시도 - 임시 파일을 만들어 쓰기 권한 확인 - 쓰기가 막히면 한 줄짜리 파싱 가능한 오류 출력 - 에이전트는 이제 긴 예외 대신 “쓰기 권한을 부여한 뒤 재시도하라”는 원인과 조치를 직접 전달받습니다. - 반복적으로 발생하는 오류를 에이전트가 처리하기 쉬운 구조화된 메시지로 변환하는 방식은 이후 Android Studio 연동에도 적용됩니다. ## Android Studio 연동의 의미론적 기능 Android CLI 1.0에서는 실행 중인 Android Studio와 연결해 IDE 수준의 분석을 명령줄에서 수행할 수 있게 되었습니다. - `studio check` - Android Studio 실행 여부를 확인합니다. - 대상 프로젝트가 열려 있는지 확인합니다. - 프로젝트 인덱싱이 완료되었는지 확인합니다. - 다른 Studio 기능을 사용하기 위한 전제 조건입니다. - `studio analyze-file` - 빌드하지 않고 단일 파일에 IDE 인스펙션을 적용합니다. - 에러와 경고를 반환합니다. - `is never used`처럼 단순한 `grep`으로 파악하기 어려운 의미론적 문제도 찾을 수 있습니다. - `studio find-declaration` - 심볼의 선언 위치를 찾습니다. - 프로젝트 코드뿐 아니라 `.aar`, `.jar` 의존성 내부도 검색합니다. - `studio find-usages` - 특정 심볼이 사용된 위치를 찾습니다. - `studio render-compose-preview` - `@Preview`가 적용된 Jetpack Compose 화면을 PNG 이미지로 렌더링합니다. ## CLI를 래퍼와 스킬로 감싼 설계 - Android Studio 기능도 CLI를 에이전트에 직접 노출하지 않고 얇은 래퍼와 스킬을 통해 제공합니다. - 가장 먼저 `studio-check` 스킬을 만들었습니다. - 에이전트가 CLI의 복잡한 입출력과 환경 전제 조건을 직접 처리하지 않도록 하는 것이 목적입니다. - 래퍼는 권한 확인, 실행 환경 검증, 오류 메시지 정규화 같은 공통 처리를 담당합니다. - 스킬은 에이전트가 언제 어떤 기능을 사용해야 하는지 안내하는 고수준 인터페이스 역할을 합니다. 실무적으로는 대규모 저장소에서 Android CLI를 전역 도구로 배포하기보다, 버전을 고정한 바이너리를 저장소에 포함하고 모든 호출을 래퍼로 통제하는 방식을 추천할 수 있습니다. 특히 검색 결과를 무작정 늘리는 대신 문서 검색, 심볼 탐색, IDE 분석처럼 목적에 맞는 의미론적 명령을 스킬로 제공하면 토큰 낭비와 에이전트의 반복 작업을 크게 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)

모델 컨텍스트 프로토콜Androidgradleai-coding-agents+3

line·2026년 7월 16일·4분 읽기큐레이션 요약

오픈챗 이름 및 설명 글로 유해성 판단하는 모델 개발하기

LINE AI Services Lab은 오픈챗 이름과 설명을 바탕으로 징계 수위와 사유를 예측하는 자동 모니터링 모델을 개발했다. 기존 모델의 적용 범위를 넓히기 위해 데이터를 정제하고, 안전성 모더레이션에 특화된 2B 규모의 Granite Guardian 3.1 2B를 LoRA로 학습했다. 최종적으로 자연어 단일 토큰과 토큰별 확률을 활용해 실시간 운영에 적합한 분류 구조를 구현했다. ## 오픈챗 모니터링의 목적 - 오픈챗은 생성되거나 이름·설명 글이 수정될 때마다 운영 정책 위반 여부를 검수해야 한다. - LINE은 글로벌 서비스로 생성·수정되는 오픈챗이 많아, 사람의 수동 검수만으로는 대응하기 어렵다. - 기존 모니터링 모델은 여러 국가에서 효과를 보였지만, 국가별로 세분화된 판단 기준이 필요한 경우에는 자동 검수가 제한됐다. - 이번 프로젝트의 목표는 자동 검수 적용 국가와 범위를 확대하고, 기존 적용 국가의 정확도도 높이는 것이었다. ## 중복 데이터와 불일치 라벨 정제 - 현재 가이드라인과 일치하도록 해당 가이드라인이 적용된 기간의 수동 검수 데이터만 학습에 사용했다. - 동일한 오픈챗 이름과 설명에 서로 다른 징계 결과가 부여된 사례를 하나의 최종 라벨로 통합했다. - 징계 코드 처리 기준: - 가장 높은 수위의 징계가 2회 이상이면 해당 징계를 최종 라벨로 선택한다. - 최고 수위 징계가 한 번만 나타나면 노이즈일 가능성을 고려해 두 번째로 높은 수위의 징계를 선택한다. - 징계 사유 처리 기준: - 동일 그룹에서 가장 많이 등장한 사유를 우선한다. - 빈도가 같으면 전체 데이터에서 더 드문 사유를 선택한다. - 이는 희귀한 사유가 해당 데이터를 더 구체적으로 설명할 수 있다는 TF-IDF의 발상에서 착안했다. ## Granite Guardian 3.1 2B 선정 - 사전 학습 모델은 다음 조건으로 검토했다. - 디코더 기반 모델 - 안전성 모더레이션 과제로 튜닝된 모델 - 약 2B 규모 - 상업적 활용이 가능한 Apache 라이선스 - 실시간으로 대량의 오픈챗을 처리해야 하므로, 대형 모델보다 추론 비용과 응답 속도가 낮은 모델이 필요했다. - Granite Guardian은 입력이 유해한지에 대해 `Yes` 또는 `No` 토큰을 생성하는 방식으로 안전성을 판별한다. - 특정 후보 토큰의 생성 확률을 비교하므로 출력 형식이 흔들리지 않고, 확률을 신뢰도로 활용해 운영 임계값을 조정하기 쉽다. ## 징계 코드와 사유를 함께 예측하는 학습 구조 - 오픈챗 검수는 단순한 유해·무해 이진 분류가 아니다. - 유해성의 정도에 따라 징계 수위가 달라진다. - 징계 사유도 함께 예측하고 안내해야 한다. - 이를 위해 모델 응답을 다음과 같은 구조로 정의했다. ```text Action:{징계 코드 토큰} Reason:{징계 사유 토큰} ``` - Cross Entropy Loss를 사용하되, 전체 프롬프트가 아니라 모델의 응답 영역에 대해서만 손실을 계산했다. - 입력 문장을 복사하는 능력보다 징계 코드와 사유를 정확히 예측하는 능력이 중요하기 때문이다. - 전체 파라미터 대신 LoRA를 적용했다. - 기존 모델 파라미터는 고정한다. - 학습해야 할 변화량을 작은 행렬 두 개의 곱으로 근사한다. - 업데이트 파라미터와 메모리 사용량을 줄이면서 사전 학습 능력을 유지한다. ## 자연어 단일 토큰을 활용한 추론 - 실제 징계 코드와 사유 코드는 알파벳·숫자 조합이라 토크나이저에 의해 여러 토큰으로 분할될 수 있다. - 여러 토큰으로 나뉘면 각 코드의 생성 확률을 직접 비교하기 어렵다. - 따라서 코드와 사유를 의미 있는 자연어 표현으로 매핑하고, 각각 하나의 토큰으로 표현되도록 구성했다. - 자연어 토큰은 임의의 코드값보다 모델이 의미를 학습하기에도 유리할 것으로 판단했다. ## 단계별 확률 계산과 KV 캐싱 - 첫 번째 단계에서 모델의 마지막 출력 로짓 중 징계 코드 토큰에 해당하는 값만 추출한다. - 해당 값에 softmax를 적용해 코드별 확률을 계산하고, 가장 높은 확률의 징계 코드를 선택한다. - 이후 선택된 코드와 `Reason:` 프롬프트를 모델에 추가 입력해 징계 사유를 예측한다. - 징계 사유 역시 사유 토큰 후보의 확률만 비교해 최종 결과를 선택한다. - 두 번째 단계에서는 첫 번째 추론의 `past_key_values`를 재사용하는 KV 캐싱을 적용해 반복적인 계산을 줄였다. ## 실용적인 결론 이 사례는 대규모 생성 모델을 그대로 사용하는 대신, 작은 안전성 특화 디코더 모델에 구조화된 출력 형식과 LoRA를 결합해 실시간 콘텐츠 모니터링에 맞춘 접근이다. 운영 환경에서는 단순 정확도뿐 아니라 라벨 품질, 토큰별 신뢰도, 임계값별 검수량과 오탐·미탐 비용을 함께 평가하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

transformerpytorchloratokenization+4

line·2026년 7월 10일·5분 읽기큐레이션 요약

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

LINE의 대규모 Kafka 환경에서는 TLS·인증·인가만으로는 브로커에 저장된 평문 데이터를 충분히 보호하기 어렵기 때문에, 프로듀서부터 컨슈머까지 메시지 페이로드를 암호화하는 종단 간 암호화를 도입했다. 레코드 단위 암호화와 DEK-KEK 구조를 결합해 Kafka 표준 확장성을 유지하면서 성능 오버헤드를 줄였고, 공유 KEK·평문 폴백·점진적 배포로 초당 최대 100만 건 규모의 토픽에 무중단 적용했다. ## Kafka 기본 보안 모델의 한계 - TLS/SSL은 프로듀서·컨슈머와 브로커 사이의 전송 구간만 보호한다. - SASL 인증은 클라이언트의 신원을 확인하고, ACL 인가는 토픽 접근 권한을 통제한다. - 그러나 브로커에 저장된 메시지 페이로드 자체는 평문일 수 있다. - 따라서 접근 권한이 우회되거나 브로커 내부 데이터가 노출되면 민감 정보가 보호되지 않는다. - 데이터 생성 시점부터 컨슈머의 복호화 시점까지 암호화 상태를 유지하는 심층 방어 전략이 필요하다. ## 레코드 단위 암호화 - 배치 단위 암호화는 압축 효율과 처리 성능이 좋지만, Kafka 클라이언트 내부 동작을 수정해야 한다. - Kafka의 인터셉터와 같은 공식 확장 포인트는 레코드 단위로 동작한다. - 레코드 단위 암호화는 압축 효율이 낮고 메시지 크기가 다소 증가하지만 다음 장점이 있다. - 표준 Kafka API를 활용할 수 있다. - Kafka 버전 업그레이드 시 호환성과 안정성이 높다. - 기존 프로듀서·컨슈머 클라이언트 코드를 직접 수정하지 않아도 된다. - 이러한 이유로 레코드 단위 암호화를 선택했다. ## DEK-KEK 이중 키 구조 - **DEK(Data Encryption Key)** - 메시지 페이로드 암호화에 사용하는 AES 대칭 키다. - AES-GCM을 사용해 빠른 암·복호화와 무결성 검증을 제공한다. - **KEK(Key Encryption Key)** - DEK를 암호화하는 ECC 기반 비대칭 키 쌍이다. - KMS가 키를 관리하며, 프로듀서는 공개 키를 사용하고 컨슈머는 인가된 비공개 키를 사용한다. - DEK 암호화에는 ECIES와 `secp521r1` 곡선을 사용한다. - 대용량 데이터는 빠른 대칭 키로 처리하고, 짧은 DEK에만 비대칭 암호화를 적용해 성능 부담을 줄인다. - 프로듀서는 페이로드를 한 번만 암호화하므로 컨슈머 수가 늘어도 메시지 크기를 크게 늘리지 않는다. - 공개 키를 이용한 암호화 권한과 비공개 키를 이용한 복호화 권한을 분리해 최소 권한 원칙을 적용한다. ## 암호화 메시지 구조 - **키** - Kafka 파티션을 결정하는 기존 메시지 키를 그대로 유지한다. - **헤더** - 컨슈머가 사용할 KEK ID와 KEK로 암호화된 DEK를 저장한다. - **바디** - DEK로 암호화된 실제 페이로드를 담는다. - 외부 DB나 캐시 없이 메시지 자체에 복호화 메타데이터를 포함해 시스템 의존성을 줄였다. - 컨슈머는 헤더의 KEK ID를 확인한 뒤 DEK를 복호화하고, 복호화한 DEK로 바디의 페이로드를 복호화한다. ## 프로듀서 암호화 처리 - Kafka 인터셉터가 전송 직전 DEK를 생성하고 KEK 공개 키로 암호화한다. - 암호화된 DEK는 메시지 헤더에 삽입한다. - 기존 시리얼라이저를 감싼 래퍼가 직렬화된 페이로드를 DEK로 암호화한다. - 인터셉터와 시리얼라이저가 같은 실행 스레드를 공유한다는 점을 활용해 DEK를 `ThreadLocal`로 전달한다. - 매 메시지마다 DEK를 새로 만들지 않고 일정 시간 캐싱해, 반복적인 비대칭 키 연산을 줄였다. ## 컨슈머 복호화 처리 - 컨슈머는 KMS에서 인가된 KEK 비공개 키를 조회한다. - 디시리얼라이저가 헤더에서 암호화된 DEK를 추출하고 비공개 키로 복호화한다. - 복호화된 DEK로 페이로드를 복호화한 후 기존 역직렬화를 수행한다. - 여러 프로듀서가 생성한 암호화 DEK와 복호화된 DEK의 쌍을 캐싱한다. - 동일한 암호화 DEK가 반복되면 비공개 키 연산을 생략해 컨슈머 성능을 높인다. ## KMS 기반 키 관리 - 토픽 오너가 KEK 키 쌍을 생성하고 KMS에 등록한다. - 프로듀서는 공개 키를, 승인된 컨슈머는 비공개 키를 KMS에서 조회한다. - 신규 컨슈머는 비공개 키 접근 권한을 요청하고 토픽 오너의 승인을 받아야 한다. - KEK의 생성·배포·접근 제어·교체를 KMS를 통해 일관되게 관리한다. ## 공유 KEK로 메시지 크기 제어 - 컨슈머마다 별도의 KEK를 사용하면 컨슈머 수에 비례해 헤더 메타데이터가 증가한다. - 메시지 크기 증가는 배치당 레코드 수 감소, 네트워크 대역폭 증가, CPU·메모리 사용량 증가로 이어진다. - 특히 초당 최대 100만 건의 토픽에서는 컨슈머 추가에 따른 헤더 증가가 큰 성능 문제가 된다. - 여러 컨슈머가 하나의 KEK를 공유하면 헤더에는 하나의 메타데이터만 포함되어 메시지 크기를 일정하게 유지할 수 있다. - 대신 키 격리 수준은 낮아지므로 다음 보완책을 함께 적용한다. - KMS 기반 비공개 키 접근 인가 - 주기적인 KEK 교체 - 토픽 오너 중심의 키 관리 ## 평문 폴백을 이용한 무중단 마이그레이션 - 암호화 도입 과정에서는 기존 평문 메시지와 새로운 암호화 메시지가 함께 존재할 수 있다. - 디시리얼라이저가 헤더의 암호화 메타데이터 유무를 확인해 처리 방식을 결정한다. - 헤더가 있으면 복호화 후 역직렬화한다. - 헤더가 없으면 기존 평문 역직렬화만 수행한다. - 안전한 전환 순서는 다음과 같다. - 평문과 암호화 메시지를 모두 처리할 수 있는 컨슈머를 먼저 배포한다. - 모든 컨슈머가 준비된 뒤 프로듀서 암호화를 활성화한다. - 모니터링을 통해 평문 메시지 비중이 0%가 되었는지 확인한다. - 프로듀서 암호화 비율도 한 번에 100%로 변경하지 않고 점진적으로 높여 성능 저하나 암·복호화 오류에 대응한다. ## 실용적인 결론 Kafka의 TLS·인증·인가를 대체하기보다, DEK-KEK 기반 페이로드 암호화를 추가 보안 계층으로 적용하는 것이 적절하다. 대규모 환경에서는 레코드 단위 암호화, DEK 캐싱, 컨슈머 측 DEK 캐싱, 공유 KEK, 평문 폴백과 점진적 배포를 함께 설계해야 보안성과 성능, 무중단 운영을 동시에 확보할 수 있다.

원문 읽기(새 탭에서 열림)

Apache Kafkaend-to-end-encryptionzero-downtime-migrationkey-management-service+3

line·2026년 7월 2일·4분 읽기큐레이션 요약

AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기

LINE OA와 LIFF, LINE Planet SDK를 결합하면 별도 앱 설치 없이 LINE 안에서 그룹 영상 통화 서비스를 구현할 수 있다. 글에서는 LINE Planet 팀의 PM과 Android 엔지니어가 웹 엔지니어 없이 만든 사례를 바탕으로, LIFF 웹 앱과 액세스 토큰 발급용 앱 서버만 직접 개발하면 된다는 구조를 설명한다. LINE의 인증·WebRTC·글로벌 네트워크 인프라를 활용하므로 핵심은 각 컴포넌트를 연결하고 통화 흐름을 구현하는 것이다. ## LINE OA와 LIFF의 역할 - **LINE OA** - 사용자와 소통하는 접점이자 서비스 진입 채널이다. - 상담, 교육, 라이브 방송, 게임 음성 채팅 등 다양한 서비스를 제공할 수 있다. - **LIFF** - LINE 앱 내부 웹뷰에서 실행되는 웹 애플리케이션이다. - LINE 로그인 정보인 `userId`, `displayName` 등을 전달하므로 별도 인증 서버 없이 사용자를 식별할 수 있다. - **LINE Planet** - WebRTC 기반의 음성·영상 통화와 미디어 처리를 담당한다. - 글로벌 네트워크 인프라를 제공해 개발자가 통화 인프라를 직접 구축하지 않아도 된다. ## 구현해야 하는 전체 구조 - 직접 개발할 부분은 크게 두 가지다. - LIFF에서 실행되는 그룹 영상 통화 웹 앱 - LINE Planet 액세스 토큰을 발급하는 앱 서버 - 앱 서버는 Firebase Cloud Functions로 구성하면 별도의 서버 인프라 설정을 줄일 수 있다. - LINE OA와 LIFF가 사용자 인증을, LINE Planet이 미디어 통신을 처리하므로 개발자는 서비스 화면과 연결 로직에 집중할 수 있다. - 실제 구현 대상은 웹 앱 레이어와 서버 레이어의 앱 서버이며, LINE OA·LIFF·LINE Planet의 기반 기능은 외부 플랫폼을 활용한다. ## 적용 가능한 서비스 사례 - **전문 상담** - 변호사, 재무 설계사, 심리 상담사와의 1:1 화상 상담 - 별도 앱 설치 없이 LINE 앱에서 상담방 입장 - **원격 교육** - 수업 예약과 화상 수업을 LINE OA에서 제공 - 여러 강사가 동시에 독립적인 통화방 운영 가능 - 화면 공유를 이용한 문서·문제 풀이 지원 - **실시간 소통 방송** - 기본 500명에서 최대 1만 명까지 동시 참여 가능 - 팬미팅, 라이브 이벤트, 진행자와 청중이 대화하는 양방향 방송 구현 - **게임 음성 채팅** - LINE 친구와 게임 중 별도 앱 전환 없이 실시간 음성 대화 ## 개발 전 준비 사항 - **개발 환경** - Node.js 20 LTS 이상 - npm 기반 프로젝트 - LIFF 특성상 HTTPS 배포 필요 - 로컬 개발에서는 ngrok 같은 HTTPS 터널링 도구 사용 가능 - **LINE Developers 설정** - Business ID로 개발자 계정 등록 - Provider 생성 - LINE OA 생성 후 Messaging API 활성화 - 같은 Provider에 LINE Login 채널 생성 - LINE Login 채널의 LIFF 탭에서 LIFF 앱 등록 - **주의할 설정** - 발급된 LIFF ID를 이후 모든 초기화 과정에서 사용하므로 별도 보관해야 한다. - 친구 초대 기능인 `shareTargetPicker`를 사용하려면 LINE Login 채널이 `Published` 상태여야 한다. - **LINE Planet 준비** - LINE Planet Console 계정과 서비스 ID가 필요하다. - 해당 정보는 LINE Planet 팀에 요청해 발급받는다. ## 통화방 ID 설계 - 사용자가 통화에 입장하기 전에 방 ID를 생성하거나 URL에서 복원한다. - 데모에서는 `crypto.randomUUID()`에서 하이픈을 제거한 뒤 앞 16자리를 사용해 랜덤 방 ID를 만든다. - 초대 링크에 `roomId`가 포함되어 있으면 query string에서 해당 값을 읽어 같은 방에 입장한다. - 서비스 목적에 따라 다음과 같이 확장할 수 있다. - 관심사별 고정 방 - 사용자 그룹별 자동 방 생성 - 예약된 수업이나 상담 일정에 연결된 방 - 방 ID 자체만으로 권한을 판단하지 말고, 실제 서비스에서는 서버에서 접근 권한과 만료 여부를 검증해야 한다. ## `MediaStreamManager`를 활용한 미리보기 - 일반적인 웹 구현의 `getUserMedia` 대신 PlanetKit의 `MediaStreamManager`를 사용한다. - 미리보기 화면에서 생성한 MSM 인스턴스를 통화방 입장 후에도 재사용할 수 있다. - 이 방식의 장점은 다음과 같다. - 페이지 전환 시 카메라와 마이크 권한을 다시 요청하지 않음 - 모바일 웹뷰에서 권한 프롬프트가 반복적으로 노출되는 문제 완화 - 기존 미디어 스트림을 통화 연결 과정까지 유지 - 구현 흐름은 다음과 같다. - 컴포넌트 마운트 시 `MediaStreamManager`를 한 번 생성 - 비디오가 켜져 있으면 `createMediaStream()`으로 미디어 스트림 생성 - 이미 스트림이 있으면 `changeVideoInputDevice()`로 비디오 입력 장치만 교체 - 스트림을 HTML `<video>` 요소의 `srcObject`에 연결 - 마이크 끄기/켜기는 권한을 다시 요청하지 않고 오디오 트랙의 `enabled` 속성만 변경한다. ## 모바일 카메라 전환 처리 - 모바일 기기에서는 전면·후면 카메라 전환 기능을 제공할 수 있다. - `useIsMobileDevice`로 모바일 환경을 판별하고, 모바일에서만 전환 버튼을 노출한다. - `resolveFacingModeDeviceId`를 통해 `front` 또는 `back` 방향에 해당하는 카메라 장치 ID를 찾는다. - 카메라가 꺼진 상태에서는 전환 버튼을 비활성화해 불필요한 장치 변경을 막는다. - 데스크톱에서는 기본 장치를 사용하고, 모바일에서는 방향 기반 장치 선택을 적용한다. ## 데모 코드의 범위와 주의점 - 글의 코드는 핵심 흐름을 보여주는 데모 코드다. - 통화 셋업, 미리보기, 통화 화면의 세부 UI와 전체 사용자 경험은 직접 구현해야 한다. - 프로덕션 적용 전 다음 항목을 추가 검토해야 한다. - 액세스 토큰 및 방 접근 권한 보안 - 네트워크 오류와 권한 거부 처리 - 통화 종료 및 리소스 정리 - 모바일 브라우저별 호환성 - 성능 최적화와 사용자 상태 동기화 - 앱 서버에서는 LINE Planet 액세스 토큰을 안전하게 발급하고 클라이언트에 비밀 키가 노출되지 않도록 해야 한다. ## 실용적인 결론 LINE OA를 이미 운영 중이라면 LIFF와 LINE Planet을 조합해 상담·교육·방송 같은 실시간 서비스를 빠르게 확장할 수 있다. 초기 구현은 랜덤 방 ID, `MediaStreamManager` 기반 미리보기, Firebase Cloud Functions 기반 토큰 서버로 단순화할 수 있지만, 실제 출시 단계에서는 방 권한 검증과 토큰 보안, 모바일 환경의 예외 처리를 반드시 보강해야 한다.

원문 읽기(새 탭에서 열림)

ReactTypeScriptnode.jswebrtc+4

line·2026년 6월 26일·4분 읽기큐레이션 요약

프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다. ## 프런트엔드 개발의 병목 변화 - 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. - 요구 사항: Jira - 디자인: Figma - 기술·정책 문서: Confluence - 의사결정과 논의: Slack - 구현과 검증: Git - 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다. - 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다. - 티켓과 디자인 분석 - 에지 케이스 확인 - 제품·백엔드 팀과의 동기화 - 기존 코드와 재사용 가능한 구성 요소 탐색 ## 프롬프트에서 반복 가능한 워크플로로 - 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다. - 워크플로는 입력부터 출력까지의 표준화된 경로입니다. - 여러 시스템에서 관련 컨텍스트 수집 - 요구 사항 요약 - 모호하거나 충돌하는 내용 식별 - 구현 계획과 파일 목록 제안 - 사람이 검토한 뒤 코드 수정 진행 - 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다. - 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다. ## 연결된 개발 컨텍스트와 Noah MCP - LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다. - AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다. - 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다. - 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다. ## 구현 전 요구 사항 통합 예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다. 워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다. - Jira 티켓 분석 - 관련 Confluence 문서 검색 - Slack의 최근 의사결정 확인 - 유사한 코드 구현 탐색 - 코드 수정 없이 다음 결과 반환 - 요구 사항 요약 - 프런트엔드 영향 범위 - 관련 파일 - 구현 체크리스트 - 테스트 체크리스트 - 미해결 질문 에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다. - `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일 - 기존 `useTableFilters`, `useUrlState` 훅의 재사용 - `GET /api/<feature>`의 기존 페이지네이션 API 활용 - 역할별 필터 표시 - viewer: 검색, 상태 필터, 날짜 범위 - editor: owner 필터 추가 - admin: 내부 전용 플래그 추가 - 필터·정렬·페이지 상태를 URL 파라미터와 동기화 - 로딩, 빈 결과, 검색 결과 없음 상태 구현 ## 숨겨진 요구 사항과 재작업 방지 - Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다. - URL 공유가 가능해지고 - 새로고침 후에도 상태가 유지되며 - 다른 사용자가 동일한 화면을 재현할 수 있습니다. - 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다. - 불필요한 중복 구현 방지 - 기존 동작과의 일관성 유지 - 개발 시간 단축 - 구현 전에 다음과 같은 미해결 사항도 드러납니다. - 필터·정렬 상태를 URL에 저장할지 여부 - 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부 - 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다. ## 코딩 이후의 폐쇄 루프 검증 워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다. - 구현 후 원래 계획과 실제 변경 사항을 대조합니다. - 자동 검증 항목을 실행합니다. - 타입 검사 - 린트 - 관련 단위 테스트 - 스모크 테스트 또는 로컬 검증 흐름 - 에이전트는 다음 결과를 보고합니다. - 통과한 검사 - 실패 후 수정한 문제 - 자동화하지 못한 검증 - UI 상태별 스크린샷이나 확인 메모 - PR 전 남은 위험 요소 - 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다. ## 실용적인 적용 방향 프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델모델 컨텍스트 프로토콜ReactTypeScript+4

line·2026년 6월 26일·5분 읽기큐레이션 요약

임베딩 안정화로 검색 리랭킹의 콜드 스타트 문제를 해결하다: LINE Part Time Jobs 적용 사례

LINE Part Time Jobs는 기존 2타워 임베딩 기반 리랭킹의 콜드 스타트와 검색 쿼리 미반영 문제를 해결하기 위해, 임베딩 공간을 날짜별로 안정화하는 후처리 방식을 도입했습니다. 저차원 SVD와 직교 Procrustes 정렬을 통해 매일 재학습되는 임베딩의 연속성을 유지했고, 그 결과 오프라인 전환 nDCG가 약 9%, 클릭 nDCG가 약 4.5% 향상되었습니다. A/B 테스트에서도 서비스 전체 KPI 4.7%, 매출 6.5% 증가를 달성했습니다. ## LINE Part Time Jobs 검색 리랭킹 구조 - 검색 시스템은 다음 두 단계로 구성됩니다. - **검색(retrieval):** 사용자의 쿼리에 맞는 구인 공고 후보를 수집 - **리랭킹(reranking):** 수집된 후보를 사용자별로 재정렬 - 기존에는 별도 배치 파이프라인에서 생성한 사용자·아이템 2타워 임베딩을 활용했습니다. - 사용자 임베딩과 아이템 임베딩의 코사인 유사도를 계산해 검색 결과 순위를 정했습니다. - 이 방식은 실시간 연산 부담을 줄일 수 있지만 다음 한계가 있었습니다. - 검색 쿼리와 역, 거리 같은 화면별 정보가 임베딩에 충분히 반영되지 않음 - 검색 외 추천 모듈이나 LINE 공식 계정에서 발생한 행동까지 함께 포함됨 - 검색 화면에 특화된 사용자 의도를 정밀하게 반영하기 어려움 ## 전용 리랭킹 모델 도입 과정의 문제 ### 공고 교체로 인한 콜드 스타트 - LINE Part Time Jobs의 공고는 월초에 대부분 교체됩니다. - 새로운 공고에 대한 클릭·지원 데이터가 충분히 쌓이기 전에는 전용 리랭킹 모델이 학습할 데이터가 부족합니다. - 그 결과 공고 교체 직후 모델 성능이 크게 저하되는 콜드 스타트 문제가 발생했습니다. ### 매일 변하는 임베딩 공간 - 2타워 모델은 성능 유지를 위해 주기적으로 랜덤 가중치에서 처음부터 재학습됩니다. - 재학습할 때마다 임베딩 공간의 방향과 좌표계가 달라질 수 있습니다. - 따라서 오늘 생성한 임베딩과 어제 생성한 임베딩은 실제 의미가 비슷해도 벡터 좌표상 직접 비교하기 어렵습니다. - 학습 시점과 추론 시점에 서로 다른 버전의 임베딩을 사용하면 다운스트림 리랭킹 모델의 입력 분포가 달라져 성능이 떨어질 수 있습니다. ## 임베딩 안정화 방식 - 각 날짜의 임베딩을 전날 안정화된 임베딩 공간에 맞춰 정렬합니다. - 첫날 임베딩은 별도 변환 없이 기준으로 사용합니다. - 이후에는 전날 결과를 다음 날의 기준으로 삼아 임베딩 공간을 순차적으로 연결합니다. - 이 방식은 특정 기준일에 모든 임베딩을 맞추는 대신, 시간에 따른 공간의 연속성을 유지합니다. - 결과적으로 임베딩 피처와 다운스트림 모델의 업데이트 시점을 엄격히 일치시키지 않아도 됩니다. ## 저차원 SVD와 직교 Procrustes ### 저차원 SVD - 아이템 임베딩과 사용자 임베딩을 각각 행렬 \(T\), \(W\)로 표현합니다. - 2타워 모델의 점수는 \(TW^\top\)로 계산되지만, 이 대규모 행렬을 직접 분해하지는 않습니다. - 대신 저차원 SVD를 사용해 변환 행렬 \(M_T\), \(M_W\)를 구합니다. - 변환 결과는 다음과 같습니다. - 아이템 임베딩: \(T' = TM_T\) - 사용자 임베딩: \(W' = WM_W\) - 이를 통해 각 학습에서 생성된 임베딩을 보다 표준화된 저차원 표현으로 변환합니다. ### 직교 Procrustes 정렬 - 당일 임베딩과 전날 안정화된 임베딩이 최대한 일치하도록 직교 변환을 계산합니다. - 직교 변환은 회전과 반전만 수행하므로 벡터 간 거리와 내적 구조를 보존합니다. - 따라서 임베딩의 유사도 기반 점수 계산 특성을 유지하면서 일별 공간 차이를 보정할 수 있습니다. ## 대규모 데이터 처리를 위한 구현 - 데이터 규모가 크기 때문에 알고리즘을 Apache Spark 기반 분산 처리로 구현했습니다. - 저차원 SVD에서는 원 논문의 QR 분해 대신 숄레스키 분해를 사용했습니다. - Gramian 행렬 \(G = A^\top A\)를 계산 - \(G = R^\top R\) 형태로 숄레스키 분해 - QR 분해에서 필요한 상삼각 행렬 \(R\)을 효율적으로 획득 - 직교 Procrustes에서는 다음과 같이 처리했습니다. - 대규모 행렬곱 \(M = B^\top A\)는 Spark로 분산 계산 - \(M\)은 임베딩 차원 \(e \times e\)의 작은 행렬이므로 SVD는 단일 노드에서 NumPy로 계산 - 대규모 벡터 데이터와 소규모 변환 행렬을 구분해 계산 자원을 효율적으로 배분했습니다. ## 안정화 효과와 평가 결과 - 안정화 전에는 서로 다른 날짜의 임베딩 상관관계가 거의 0에 가까웠습니다. - 안정화 후에는 다음 수준의 유사도를 유지했습니다. - 일주일 후: 약 0.88 - 한 달 후: 약 0.87 - 안정화하지 않은 임베딩을 다운스트림 모델에 추가하면 공간 불일치로 nDCG가 약 1~5% 하락했습니다. - 안정화된 임베딩을 사용한 경우: - 전환 nDCG 약 9.0% 향상 - 클릭 nDCG 약 4.5% 향상 ## A/B 테스트 결과와 해석 - 안정화된 임베딩과 콜드 스타트 대응책을 결합한 모델을 온라인 실험했습니다. - 검색 화면 단독 KPI에서는 통계적으로 유의미한 개선이 뚜렷하지 않았습니다. - 그러나 서비스 전체 기준으로는 다음 성과를 얻었습니다. - KPI 4.7% 향상 - 매출 6.5% 향상 - 이는 임베딩이 검색 화면뿐 아니라 서비스 전반의 사용자 행동과 장기적인 선호를 반영했기 때문으로 분석됩니다. - 검색 이후 다른 페이지로 이동하거나 다른 추천 모듈에서 지원하는 행동까지 긍정적인 영향을 받은 것으로 보입니다. - 기존 2타워 모델 구조나 학습 파이프라인을 변경하지 않고 임베딩 후처리만 추가했다는 점도 운영상 중요한 장점입니다. ## 실용적인 결론 재학습마다 좌표계가 달라지는 임베딩을 다운스트림 모델의 피처로 사용할 때는 날짜별 공간 정렬이 효과적인 해결책이 될 수 있습니다. 특히 저차원 SVD와 직교 Procrustes를 결합하면 임베딩의 유사도 구조를 유지하면서 버전 불일치와 드리프트를 줄일 수 있으므로, 기존 모델을 크게 변경하기 어려운 대규모 추천·검색 시스템에 적용하기 적합합니다.

원문 읽기(새 탭에서 열림)

머신러닝apache-sparkonline-learningtwo-tower-embedding+4

line·2026년 6월 25일·4분 읽기큐레이션 요약

AI 에이전트끼리 토론한다면? 멀티 에이전트 협업으로 재설계하는 개발 프로세스

AI 코딩의 병목은 코드 생성 속도가 아니라 의도 정의, 가정 검증, 구현 확인, 리뷰 준비를 사람이 직접 조율하는 데 있다. LY Corporation은 이를 해결하기 위해 제안자와 도전자 AI 팀이 스펙·빌드·전달의 세 단계에서 토론하고, 조율자가 수정·상위 보고·진행 여부를 결정하는 파이프라인을 설계했다. 목표는 사람의 판단을 없애는 것이 아니라, 사람이 검토하기 전에 AI가 자신의 작업을 근거와 함께 입증하도록 만드는 것이다. ## 사람이 조율하는 AI 보조 방식의 한계 - 기존 방식에서는 AI가 스펙 작성, 코드 생성, 테스트, PR 설명 등을 빠르게 수행한다. - 그러나 각 단계 사이에서 사람이 다음 작업을 요청하고, 실패 결과를 전달하고, diff와 PR을 검토해야 한다. - 따라서 개별 작업은 빨라져도 의도·구현·검증·리뷰·전달 사이의 조율 비용은 그대로 남는다. - 진정한 생산성 향상은 각 단계를 단순히 가속하는 것이 아니라, 수동 인수인계를 프로세스에서 제거하는 데 있다. ## 제안자와 도전자로 나뉜 AI 협업 - 제안자는 산출물을 작성하고 단계가 진행될수록 이를 발전시킨다. - 도전자는 제안자의 결과를 검증하며, 단계별로 서로 다른 관점에서 문제를 제기한다. - 스펙 단계: 소크라테스식 질문으로 모호성·누락을 찾는다. - 빌드 단계: 테스트와 실행 결과 등 근거를 바탕으로 반론한다. - 전달 단계: 구현과 PR이 최종 리뷰에 충분한지 점검한다. - 역할을 분리하면 하나의 AI가 스펙, 구현, 검증, 리뷰를 모두 낙관적으로 처리하는 문제를 줄일 수 있다. - 사람은 시작 시 의도를 정의하고, 결과를 승인하거나, 해결하기 어려운 문제가 상위 보고될 때 주로 개입한다. ## 스펙·빌드·전달 파이프라인 ### 스펙: 이후 작업의 계약 정의 - 스펙은 다음 내용을 포함한다. - 목표와 제약 조건 - 해석된 요구 사항 - 명시적 가정 - 미해결 질문 - 제안된 접근 방식 - 완료 정의 - 빌드 에이전트는 “합리적으로 보이는” 구현을 임의로 선택하지 않고, 승인된 스펙에서 테스트와 검증 계획을 도출한다. - 스펙이 부실하면 이후 구현과 리뷰의 기준도 불명확해지므로 전체 파이프라인이 약해진다. - 기존 API, 테스트, 의존성, 코딩 관습, Jira·Confluence·설계 문서 등을 조사해 질문과 가정을 구체화한다. ### 빌드: 테스트 우선 구현과 반론 - 제안자는 코드를 수정하기 전에 스펙을 다음 항목으로 변환한다. - 예상 동작 - 에지 케이스 - 추가·수정할 테스트 - 실행 명령 - 도전자는 구현 전이나 구현 중에 검증 설계 자체를 문제 삼을 수 있다. - 제안자가 도전자의 이의를 거부하려면 실행 경로, 컴파일·린트 출력, 실패 테스트 등 구체적인 증거를 제시해야 한다. - 단순히 테스트가 녹색이라는 사실만으로 검증 누락을 숨길 수 없도록 설계됐다. ### 전달: 리뷰 가능한 PR 패키지 - 최종 산출물은 코드뿐 아니라 리뷰어가 신뢰할 수 있는 PR 패키지다. - 패키지에는 다음 정보가 포함된다. - 무엇이 변경되었는가 - 어떤 파일과 영역을 먼저 봐야 하는가 - 어떤 검사와 테스트를 통과했는가 - 남은 위험과 불확실성은 무엇인가 - 도전자가 어떤 문제를 제기했고 어떻게 처리했는가 - 전달 단계의 조율자는 중재자라기보다 출시 가능성을 판단하는 심사위원 역할을 한다. ## 조율자와 구조화된 토론 프로토콜 - 조율자는 제안자와 도전자 사이에서 토론을 관리한다. - 주요 책임은 다음과 같다. - 논의가 주제에서 벗어나면 방향 수정 - 교착 상태 해소 - 산출물 수정 요청 - 안전하지 않은 불확실성의 상위 보고 - 다음 단계 진행 여부 결정 - 스펙과 빌드에서는 수렴을 이끄는 중재자 역할을 하고, 전달 단계에서는 근거가 충분한지 판정한다. - 각 에이전트는 제한된 프롬프트와 자체 컨텍스트를 사용하며, 공통으로 접근하는 것은 워크스페이스·산출물·조율자가 누적한 기록이다. - 에이전트 간 실시간 공동 컨텍스트 대신 구조화된 산출물과 transcript를 통해 협업한다. ## JSON 기반 상태 머신 - 각 토론 라운드는 제안자와 도전자의 교환 및 조율자의 결정을 포함한다. - 에이전트는 긴 에세이가 아니라 조율자가 파싱할 수 있는 엄격한 JSON을 반환한다. - JSON에는 상태, 요약, 전문가 의견, 판단 근거, 요구 사항, 제약, 완료 정의, 가정, 질문 등이 담긴다. - 예를 들어 `/api/search`만 변경할지 인접한 검색 엔드포인트까지 포함할지 불명확하면, 도전자는 범위 경계를 명시적인 질문으로 제기한다. - 모호성이 작고 기존 근거로 안전하게 판단할 수 있으면 제안자가 가정으로 기록하고 진행한다. - 반대로 답이 없으면 위험하거나 파괴적이거나 되돌리기 어려운 문제라면 추측하지 않고 사람에게 상위 보고한다. ## 전문 역할과 근거 중심 검증 - 각 단계에는 목적에 맞는 전문 역할이 배정된다. - `requirements-synthesizer`: 요구 사항 정리 - `security-analyst`: 보안 위험 분석 - `test-coverage-reviewer`: 테스트 범위 검토 - `technical-writer`: 전달 문서 작성 - `evidence-verifier`: 구현과 검증 근거 확인 - 중요한 판단은 직감이 아니라 코드, 테스트, 문서, 실행 결과 같은 근거에 기반한다. - 핵심은 여러 AI를 단순히 병렬 실행하는 것이 아니라, 서로 다른 책임과 관점을 부여해 주장과 반론을 구조화하는 데 있다. ## 실용적인 결론 AI 코딩 시스템을 설계할 때는 코드 생성 에이전트 하나를 더 빠르게 만드는 것보다, 스펙부터 PR 전달까지의 인수인계를 자동화하는 것이 더 큰 효과를 낼 수 있다. 특히 스펙을 계약으로 명확히 만들고, 단계별 도전과 근거 제출을 강제하며, 위험한 가정은 사람에게 상위 보고하도록 구성하는 것이 핵심이다.

원문 읽기(새 탭에서 열림)

AI 에이전트CI/CD코드 리뷰json+3

line·2026년 6월 25일·5분 읽기큐레이션 요약

AI 시대의 개발 능력은 검증력으로 결정된다, Flava API Gateway 개발 중 배운 빠른 검증과 로컬 환경 구성 전략

코딩 에이전트는 빠르게 코드를 생성하지만, 설계 불명확성·출력 비결정성·검증 지연 때문에 신뢰할 수 없는 결과를 만들 수 있다. LY Corporation의 Flava API Gateway 팀은 이를 해결하기 위해 **스펙 주도 개발, 검증 자동화, 빠르고 독립적인 로컬 환경**을 구축했다. 결론적으로 AI의 생산성을 활용하려면 개발자의 전문성과 테스트·린터·사전 설계를 오히려 더 강화해야 한다. ## 코딩 에이전트가 만드는 개발 병목 - 에이전트의 코드 생성 속도에 비해 CI 대기, 환경 프로비저닝, 원격 테스트 같은 단계는 느리다. - 에이전트는 다음과 같은 오류를 반복적으로 만들 수 있다. - 컴파일되지 않는 코드 - 존재하지 않는 API 참조 - 명시되지 않은 설계 결정을 임의로 선택 - 동일한 프롬프트라도 실행마다 결과가 달라질 수 있어 출력의 일관성과 역량을 일반화하기 어렵다. - AI가 개발자의 리뷰 속도보다 빠르게 코드를 생성하면, 검토되지 않은 코드가 누적될 위험이 있다. - 따라서 AI 활용의 핵심은 단순한 생성 속도가 아니라, 잘못된 결과를 빠르게 발견하고 수정하는 개발 시스템이다. ## Flava API Gateway와 세 가지 대응책 - Flava API Gateway는 LY Corporation의 사내 프라이빗 클라우드 Flava에서 API를 생성·배포·모니터링하는 제품이다. - Kong이 데이터 플레인을 담당하고, 컨트롤 플레인은 각 팀이 독립적으로 API를 관리할 수 있는 다중 테넌트 REST API를 제공한다. - 팀은 다음 세 가지 원칙을 채택했다. - 코드 작성 전 설계와 요구사항을 확정하는 **스펙 주도 개발** - 테스트와 린터로 에이전트가 스스로 오류를 찾도록 하는 **검증 자동화** - CI를 기다리지 않고 전체 검증 루프를 돌리는 **빠른 로컬 환경** ## 스펙 주도 개발로 구현 방향 고정 - 에이전트가 설계가 정해지기 전에 구현을 시작하면, 에이전트가 임의로 설계 결정을 내리면서 비결정성이 커진다. - Flava 팀은 먼저 OpenAPI 스펙으로 컨트롤 플레인의 전체 설계를 정의했다. - OpenAPI 스펙은 다음 역할을 한다. - 에이전트가 따라야 할 명시적 기준 - 구현 결과가 설계에서 벗어났는지 판단하는 검증 기준 - API 동작 계약의 문서화 - 이후 기능을 작은 단위로 나누고 OpenSpec을 사용해 각 기능을 구현했다. ## Nickel을 활용한 OpenAPI 관리 - 원본 OpenAPI YAML은 반복적이고 장황해 수작업 유지보수가 어렵다. - 스펙과 실제 구현이 어긋나면 에이전트를 통제하는 기준으로서의 가치가 떨어진다. - 팀은 Nickel을 사용해 API 리소스를 선언적으로 정의하고, 이를 전체 CRUD 엔드포인트 스펙으로 변환했다. - 예를 들어 리소스 정의만으로 다음 요소를 일관되게 생성할 수 있다. - 목록·생성·조회·삭제 엔드포인트 - 페이지네이션과 정렬 - 정확히 일치하는 필터와 부분 문자열 필터 - ETag 기반 낙관적 잠금 - 공통 오류 응답 - 이 방식은 반복적인 YAML 작성량을 줄이고, API 설계 규칙을 생성기에 집중시킨다. ## OpenSpec 기반의 협업 워크플로 OpenSpec은 에이전트가 구현 전에 행동 계약에 합의하도록 다음 네 가지 산출물을 요구한다. - **제안(Proposal)**: 무엇을, 왜 변경하는지 설명 - **설계(Design)**: 기술적 결정과 트레이드오프 정리 - **델타 스펙(Delta Specs)**: 변경되는 요구사항을 Given-When-Then 시나리오로 정의 - **작업 목록(Task List)**: 구현 단계를 체크리스트로 분해 워크플로는 다음 순서로 진행된다. - 개발자와 에이전트가 기능, 세부사항, 에지 케이스를 함께 검토한다. - 에이전트가 네 가지 산출물을 작성한다. - 에이전트가 작업 목록을 단계적으로 실행하며 구현한다. - 완료 후 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합한다. - 축적된 델타 스펙은 시간이 지나면서 시스템 전체의 “살아 있는 스펙”이 된다. ## 검증 자동화로 에이전트의 오류 수정 유도 - 프롬프트에 주의사항을 계속 추가하는 방식은 효과가 제한적이며, 제약이 많아질수록 출력 품질이 낮아질 가능성도 있다. - 대신 테스트와 린터가 오류를 구체적으로 드러내도록 구성했다. - 에이전트는 다음과 같은 반복 루프를 수행한다. - 코드를 작성한다. - 테스트·린터·포매터를 실행한다. - 실패 원인을 확인한다. - 코드를 수정한다. - 다시 검증하고 다음 오류로 넘어간다. - 모든 요구사항을 처음부터 프롬프트에 주입하는 대신, 필요한 제약을 실패 시점에 점진적으로 제공하는 방식이다. - 프로젝트별 스킬에 테스트, 린터, 포매터를 묶고 `AGENTS.md`를 통해 언제 해당 스킬을 사용할지 안내했다. - 검사 지침을 매 턴마다 전달하지 않고 필요할 때만 로드해 에이전트의 불필요한 컨텍스트 부담도 줄였다. ## 세 계층 테스트와 완전한 로컬 검증 전체 테스트 모음은 2,754개이며 다음 세 계층으로 구성된다. - **단위 테스트** - 비즈니스 로직을 분리해 검증 - **통합 테스트** - 실제 PostgreSQL 사용 - 제약 조건, 트리거, 소프트 삭제 연쇄, 트랜잭션 검증 - 전체 인프로세스 HTTP 스택 검증 - 모든 응답의 OpenAPI 준수 여부 확인 - **E2E 테스트** - 실제 Athenz 인증 - Kong 데이터 플레인 - API 키 적용 - 멀티 테넌트 격리 - 전체 시스템 동작 검증 ## CI 의존성을 줄인 빠른 개발 환경 - 개발자가 직접 작성할 때는 CI 왕복을 줄이기 위해 어느 정도 완성된 코드를 먼저 제출할 수 있지만, 에이전트는 짧은 간격으로 수많은 시도를 반복한다. - 모든 시도를 원격 CI로 보내면 다음 문제가 생긴다. - 긴 대기 시간 - 반복 과정에서 에이전트가 컨텍스트를 잃을 가능성 - 원격 환경의 로그와 상태를 조사하기 어려움 - 완전한 로컬 환경을 구축하면 에이전트가 즉각적인 피드백을 받고 현재 작업 흐름을 유지할 수 있다. - 로컬 의존성의 로그와 상태를 직접 확인할 수 있어 실패 원인 분석도 쉬워진다. - 전체 테스트는 개발자 기기에서 약 15초 안에 실행되도록 최적화했다. - 이를 위해 테스트를 병렬화하고 테스트 간 격리를 강화했다. 공유 테이블을 매번 삭제하는 방식보다 각 테스트 패키지가 독립적으로 생성한 데이터를 사용해 실행 간 충돌을 줄이는 방향을 택했다. ## 실용적인 적용 권장사항 AI 코딩 에이전트를 도입할 때는 프롬프트를 복잡하게 만드는 것보다 먼저 API·행동 스펙을 문서화하고, 테스트·린터·포매터를 자동 실행하며, 핵심 검증을 로컬에서 빠르게 끝낼 수 있게 만드는 것이 효과적이다. 에이전트의 성능을 높이는 가장 현실적인 방법은 더 많은 일을 맡기는 것이 아니라, 실패를 즉시 알려 주고 스스로 수정할 수 있는 짧은 피드백 루프를 구축하는 것이다.

원문 읽기(새 탭에서 열림)

PostgreSQLcoding-agentsautomated-testingopenapi+4

line·2026년 6월 24일·6분 읽기큐레이션 요약

Flava DBaaS 딥다이브: 아키텍처부터 마이그레이션, 그리고 미래까지

LY Corporation은 Verda와 YNW를 차세대 프라이빗 클라우드 Flava로 통합하면서, 쿠버네티스 오퍼레이터 패턴 기반의 DBaaS를 설계했습니다. Flava DBaaS는 데이터베이스 비즈니스 로직과 IaaS 제어를 분리하고, 선언적 관리·자동화·일관된 사용자 경험을 제공하는 것을 목표로 합니다. 또한 DBaaS의 역할을 신규 데이터베이스 제공에 그치지 않고, 기존 플랫폼에서 Flava로의 원활한 마이그레이션까지 확장하고 있습니다. ## 쿠버네티스 오퍼레이터 기반의 선언적 DBaaS - 사용자가 원하는 데이터베이스의 상태를 커스텀 리소스(CR)로 선언하면, 컨트롤러가 실제 상태가 선언된 상태와 일치하도록 지속적으로 조정(reconcile)합니다. - 절차를 직접 지시하는 방식보다 운영 상태를 파악하기 쉽습니다. - 커스텀 리소스의 사양과 현재 상태 비교 - 컨트롤러 로그 및 이벤트 확인 - 문제 발생 원인 추적 - 이벤트 기반 컨트롤러이므로 대규모 데이터베이스 환경에서도 효율적으로 동작할 수 있습니다. - 쿠버네티스의 CI/CD, 권한 관리, API, 모니터링 등 생태계 기능을 활용할 수 있습니다. - 구현 난이도는 높지만, 장기적인 운영과 관리에는 유리합니다. ## 인프라 오퍼레이터를 통한 IaaS 추상화 - DBaaS는 여러 VM, 스토리지, 네트워크, 도메인 등 IaaS 자원을 조합해 데이터베이스 클러스터를 구성합니다. - DBaaS가 IaaS API와 호출 절차를 직접 처리하면 다음 문제가 발생합니다. - 인프라 제어 코드가 지나치게 많아짐 - 데이터베이스 운영 로직과 인프라 로직이 뒤섞임 - DBMS별 개발자가 IaaS 세부사항까지 이해해야 함 - Flava는 IaaS 자원을 인프라 오퍼레이터가 쿠버네티스 커스텀 리소스로 추상화하도록 구성했습니다. - 예를 들어 VM 생성 시 IaaS API를 직접 호출하지 않고, 다음과 같은 속성을 선언한 `server.yaml`을 작성한 뒤 `kubectl create -f server.yaml`로 리소스를 생성합니다. - 가용 영역 - 운영체제 이미지 - vCPU·메모리 등 서버 유형 - 계층은 다음과 같이 분리됩니다. - **DBaaS**: 데이터베이스 비즈니스 로직 담당 - **인프라 오퍼레이터**: IaaS를 쿠버네티스 리소스로 추상화 - **IaaS**: 컴퓨트·네트워크·스토리지 제공 - 이 구조를 통해 여러 DBMS가 IaaS 자원을 동일한 방식으로 사용하고, DBaaS 개발자는 DBMS별 기능에 집중할 수 있습니다. ## 커스텀 리소스와 세 가지 실행 컴포넌트 Flava에서 데이터베이스 클러스터 역시 쿠버네티스 커스텀 리소스로 표현됩니다. - 커스텀 리소스에는 다음과 같은 구성이 선언됩니다. - MySQL 버전 - VM 서버 사양 - 스토리지 종류와 용량 - 복제 멤버 수 - 리소스는 YAML 형태로 etcd에 저장되며 쿠버네티스 API를 통해 생성·조회·수정·삭제할 수 있습니다. DBaaS는 커스텀 리소스를 중심으로 API 서버, 매니저, 에이전트로 나뉩니다. - **API 서버** - 사용자와 UI, IaC 도구가 호출하는 REST API를 제공합니다. - 사용자의 요청을 DBaaS 커스텀 리소스 생성·수정·삭제 작업으로 변환합니다. - **매니저** - 커스텀 리소스의 변경을 감지하는 컨트롤러입니다. - 선언된 사양과 실제 클러스터 상태가 일치하도록 VM 생성, 구성 변경, 복제 설정 등을 조정합니다. - 인프라 오퍼레이터의 커스텀 리소스를 생성해 필요한 VM과 인프라를 준비합니다. - **에이전트** - 데이터베이스가 실행되는 VM 내부에서 동작합니다. - 운영체제 명령이나 데이터베이스 명령처럼 VM 내부에서 실행해야 하는 작업을 수행합니다. - MySQL 설치, 복제 구성, 프로비저닝 등 로컬 실행이 필요한 작업을 담당합니다. 예를 들어 MySQL 클러스터 생성 요청이 들어오면 API 서버가 MySQL 커스텀 리소스를 생성하고, 매니저가 필요한 VM을 만든 뒤, 에이전트가 VM 내부에서 MySQL과 복제 구성을 완료합니다. ## DBMS 지원과 확장성 개선 - Verda와 YNW에서 제공하던 DBMS를 통합해 Flava에서 지원하는 DBMS 종류를 확대했습니다. - 기존 사용자 만족도 조사와 운영 경험을 바탕으로 기능을 추가했습니다. - 스토리지를 100GiB 단위로 구성할 수 있어 용량 조정이 유연해졌습니다. - 블록 스토리지를 사용하는 DBMS는 최대 5TiB까지 지원합니다. - 기존에는 VM 로컬 디스크 용량이 하이퍼바이저의 VM 사양에 종속됐지만, Flava는 다음을 통해 제약을 줄였습니다. - 사용자 정의 인스턴스 유형 - VM과 분리된 블록 스토리지 - 확장된 최대 스토리지 용량 - 단일 VM의 저장공간 부족으로 샤딩을 검토해야 했던 사례를 줄일 수 있습니다. - 5TiB 제한은 대부분의 사용 사례를 충족하면서 블록 스토리지 측 서버 단편화를 방지하기 위한 설계 결정입니다. ## DBMS 전반의 통일된 사용자 경험 - 모든 DBaaS 상품에 공통 아키텍처와 UI·UX를 적용했습니다. - 한 DBMS에서 익힌 관리 방식으로 다른 DBMS도 사용할 수 있습니다. - MySQL에서 서버 사양을 변경한 경험을 Redis에도 적용 - Cassandra에서 설정한 모니터링 알람 방식을 MySQL에도 적용 - DBMS마다 별도의 사용법을 학습해야 하는 부담을 줄였습니다. - 플랫폼 차원에서 프로비저닝, 고가용성, 백업·복구, 확장성, 모니터링 같은 기본 기능을 제공합니다. ## 보안 및 편의 기능 강화 - DBaaS 기본 기능으로 다음 보안 기능을 제공합니다. - **TDE(Transparent Data Encryption)**: 저장 데이터 암호화 - **TLS(Transport Layer Security)**: 전송 구간 암호화 - **Custom DB Role** - 필요한 수준의 권한을 가진 데이터베이스 사용자를 생성·관리할 수 있습니다. - 정의한 역할을 재사용할 수 있습니다. - **Database Parameter Group** - 데이터베이스 파라미터를 원하는 값으로 관리할 수 있습니다. - 설정 그룹을 여러 클러스터에 재사용할 수 있습니다. - **Restore backup** - 특정 백업을 기반으로 새 데이터베이스 클러스터를 생성합니다. - 장애 복구뿐 아니라 실제 데이터가 필요한 성능 테스트 환경 구축에도 활용할 수 있습니다. - 일부 DBMS에서 아직 제공되지 않는 기능도 향후 확대할 예정입니다. ## 마이그레이션까지 포함하는 DBaaS의 책임 - 신규 DBaaS는 데이터베이스를 생성하는 기능만 제공해서는 충분하지 않습니다. - 기존 Verda·YNW 환경의 사용자가 Flava로 쉽게 이동할 수 있도록 마이그레이션 방법까지 제공해야 합니다. - 같은 DBMS 간 마이그레이션 방식은 크게 세 가지로 소개됩니다. ### 덤프 및 복구 - 소스 데이터베이스를 백업한 뒤 목적지 데이터베이스에 복구합니다. - 구현이 가장 단순합니다. - 데이터 정합성을 보장하려면 마이그레이션 중 애플리케이션 중단이 필요합니다. ### 실시간 복제 - DBMS 자체의 복제 기능으로 소스에서 목적지로 데이터를 실시간 복제합니다. - 복제가 완료되면 페일오버해 목적지 클러스터를 새로운 프라이머리로 전환합니다. - 이후 기존 소스 데이터베이스를 제거합니다. - 애플리케이션 중단을 최소화할 수 있지만, 프라이머리 전환 시 짧은 중단이 발생할 수 있습니다. - 데이터 정합성은 사용 중인 DBMS의 복제 메커니즘에 의존합니다. ## 실용적인 결론 Flava DBaaS의 핵심은 데이터베이스를 쿠버네티스 리소스로 선언하고, 인프라 오퍼레이터·매니저·에이전트가 실제 구성을 자동으로 맞추도록 만든 점입니다. 유사한 플랫폼을 설계할 때는 DBaaS와 IaaS의 책임을 분리하고, 공통 UI·보안·백업 기능을 플랫폼 수준에서 제공하며, 신규 기능뿐 아니라 기존 시스템의 마이그레이션 경로까지 함께 설계하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)

쿠버네티스infrastructure-as-codemysqldatabase-migration+4

line·2026년 6월 24일·5분 읽기큐레이션 요약

시멘틱 컨텍스트 OS 설계: 에이전트 시스템의 토큰 스터핑을 넘어

LLM의 컨텍스트 창이 커져도 입력을 무작정 늘리는 ‘토큰 스터핑’만으로는 소프트웨어 에이전트의 추론 성능을 보장할 수 없다는 것이 글의 핵심 주장입니다. 긴 컨텍스트에서는 어텐션 희석과 컨텍스트 부패가 발생해 검색 정확도와 논리 일관성이 떨어질 수 있으므로, 컨텍스트를 텍스트가 아닌 관리 가능한 시스템 자원으로 다뤄야 합니다. 이를 위해 글은 로컬 루프백 프록시 형태의 ‘시맨틱 컨텍스트 OS’와 VFS, AST 기반 가지치기, 동적 토큰 관리 구조를 제안합니다. ## 컨텍스트 창은 전통적인 RAM과 다르다 - Karpathy의 은유에 따르면: - LLM은 사전 학습된 가중치를 바탕으로 추론을 수행하는 CPU와 유사합니다. - 컨텍스트 창은 현재 상태와 실행 데이터를 담는 휘발성 RAM과 유사합니다. - 그러나 전통적인 RAM과 달리 LLM의 컨텍스트 검색은 결정론적인 주소 조회가 아닙니다. - 특정 메모리 주소에서 데이터를 정확히 읽는 방식이 아니라, Q·K·V 행렬과 어텐션 점수에 기반한 확률적 검색입니다. - 컨텍스트가 32K에서 1M 또는 2M 토큰으로 커져도 정보 접근 정밀도가 선형적으로 증가하지 않습니다. - 입력이 커질수록 계산 표면적과 구조적 잡음이 증가해 오히려 추론 성능이 저하될 수 있습니다. ## 어텐션 희석과 ‘중간 정보 유실’ - 긴 코드베이스나 시스템 로그에는 다음과 같은 불필요한 정보가 포함됩니다. - 보일러플레이트 정의 - 참조되지 않는 import - 중복된 구문과 유틸리티 - 관련 없는 로그와 실행 데이터 - 이런 정보가 키 행렬에 많이 포함되면 쿼리와 키 사이의 의미 차이가 작아지고, 어텐션 로짓이 균일해집니다. - 그 결과 중요한 정보에 집중하던 날카로운 어텐션 피크가 넓게 분산되어, 정확한 사실 검색이 어려워집니다. - 글은 이를 Stanford 연구에서 제시한 ‘Lost in the Middle’ 현상과 연결합니다. - 컨텍스트의 시작과 끝에 있는 정보는 비교적 잘 검색됩니다. - 중간 영역, 특히 중간 70% 부근의 정보는 검색 정확도가 크게 낮아집니다. - 수만 줄의 코드나 복잡한 서비스 의존성을 다루는 에이전트에게 이러한 검색 편향은 심각한 논리적 오류로 이어질 수 있습니다. ## 장기 작업에서 발생하는 컨텍스트 부패 글은 자동 리팩토링, 레거시 마이그레이션, API 계약 검증처럼 여러 단계가 필요한 작업에서 컨텍스트가 시간이 지나며 악화되는 현상을 ‘컨텍스트 부패’라고 설명합니다. - **컨텍스트 오염** - 과거 실행 로그, 터미널 오류, 원시 데이터를 계속 누적합니다. - 모델이 일시적인 과거 오류를 현재 작업의 영구적인 제약으로 잘못 해석할 수 있습니다. - **컨텍스트 산만** - 모노레포의 동일한 이름, 오버로드된 메서드, 중복 유틸리티가 검색 결과에 함께 들어옵니다. - 구조적으로 비슷하지만 논리적으로 무관한 코드가 핵심 실행 경로를 가립니다. - **컨텍스트 충돌** - 이전 단계의 지시사항을 제거하거나 갱신하지 않으면 서로 모순되는 명령이 남습니다. - 에이전트가 논리적으로 마비되거나 무한 추론, 타임아웃, 환각을 일으킬 수 있습니다. - 글은 능동적인 관리 계층이 없을 경우 컨텍스트 깊이가 커질수록 실패율이 비선형적으로 증가하고, 깊은 코드 구조에서는 실패율이 약 40%에 이를 수 있다고 주장합니다. ## 수동적 프롬프트에서 능동적 거버넌스로 - 일반적인 구현은 문자열을 계속 이어 붙여 다음 LLM 호출에 전달하는 방식입니다. - 이 방식은 메모리 관리, 토큰 최적화, 노이즈 제거를 LLM의 내부 어텐션에 맡깁니다. - 시맨틱 컨텍스트 OS는 애플리케이션 로직과 파운데이션 모델 API 사이에 위치하는 AI 전용 커널로 제시됩니다. - 로컬 `localhost:8080` 루프백 프록시로 동작하며 다음 작업을 담당합니다. - 컨텍스트 상태와 접근 경로 관리 - 토큰 생명 주기 모니터링 - 전송 전 데이터 격리와 정책 적용 - 모델별 하드웨어 토큰 한계와 의미론적 컨텍스트 거버넌스의 분리 ## MVC(Minimum Viable Context) 파이프라인 MVC의 목표는 거대한 텍스트 덤프가 아니라 현재 추론 단계에 필요한 최소한의 고밀도 정보만 모델에 제공하는 것입니다. - **수집 및 토큰 매핑** - 소스 파일, 의존성 트리, 런타임 로그를 수집합니다. - `cl100k_base`, `o200k_base` 등 실제 모델 토크나이저를 사용해 정확한 토큰 수를 계산합니다. - **구조 가지치기** - 정적 코드 분석과 구조 규칙으로 불필요한 정보를 제거합니다. - 컴파일러 주석, 미사용 import, 관계없는 유틸리티 코드 등이 대상입니다. - 글에서 제시한 전체 아키텍처는 이후 단계에서 의미적 정제와 실행 중 토큰 최적화를 수행하도록 설계됩니다. ## 시맨틱 컨텍스트 OS의 구성 요소 - **POSIX 유사 VFS** - 컨텍스트와 에이전트 상태를 가상 파일 시스템처럼 구조화합니다. - 상태 토폴로지와 접근 경계를 명시적으로 관리합니다. - **PathAlign** - AST를 활용해 코드의 구조적 경로를 분석합니다. - 현재 작업과 관련된 가지를 남기고 무관한 코드 트리를 제거합니다. - **비동기 톱니(sawtooth) 메모리 모델** - 실행 중 컨텍스트를 계속 축소·갱신하는 방식으로 토큰 사용량을 최적화합니다. - 장기 실행 루프에서 오래된 상태와 불필요한 데이터를 누적하지 않도록 합니다. - **보안 및 격리** - 모델에 전달되는 데이터의 범위를 제한합니다. - 기업 코드와 로그 등 지적 재산이 불필요하게 외부 추론 엔진으로 유출되는 위험을 줄이는 것을 목표로 합니다. 시맨틱 컨텍스트 OS의 실질적인 메시지는 “큰 컨텍스트 창”보다 “잘 선별되고 지속적으로 관리되는 컨텍스트”가 중요하다는 것입니다. 엔터프라이즈 에이전트를 구축할 때는 토큰 예산을 명시적으로 계산하고, AST·의존성·의미 기반 필터링을 적용하며, 오래된 지시와 로그를 정리하는 런타임 거버넌스 계층을 두는 것이 권장됩니다. 단, 글의 실패율과 성능 개선 수치는 제안된 아키텍처의 주장으로 보아 실제 환경에서 별도의 벤치마크 검증이 필요합니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트transformerabstract-syntax-tree+4

line·2026년 6월 23일·4분 읽기큐레이션 요약

프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

프롬프트 튜닝은 반복적인 수작업과 개인 의존성 때문에 수일에서 수주가 걸리지만, 유전 알고리즘 기반의 GEPA를 적용하면 이를 약 한 시간으로 단축할 수 있다. GEPA는 후보 프롬프트를 여러 세대에 걸쳐 평가·변이하고, 점수뿐 아니라 자연어 피드백까지 활용해 개선 방향을 찾는다. LY Corporation은 이를 Yahoo! JAPAN Search의 건강·의료 쿼리에 적용해 정책 준수와 답변 가독성을 함께 최적화했다. ## 프롬프트 튜닝이 어려운 이유 - 프롬프트를 조금만 수정해도 출력을 다시 생성하고 사람이 품질을 판단해야 한다. - 수십~수백 개의 프롬프트 패턴을 시험하는 경우가 있어 반복 작업량이 크다. - “특정 표현이나 지시 순서가 효과적이다” 같은 노하우가 담당자 개인에게 남기 쉽다. - 개선 이유와 시행착오 과정이 기록되기 어려워 재현성과 설명 가능성이 떨어진다. - 모델 버전이 바뀌면 출력 품질도 변하므로 지속적인 재튜닝이 필요하다. - 사람이 직접 해야 할 정책 검증, 평가 기준 정리, 품질 판단에 충분한 시간을 쓰기 어렵다. ## 프롬프트 자동 최적화 방법 - 대표적인 접근법은 다음과 같다. - **강화 학습 기반**: 출력에 대한 스칼라 보상을 이용해 프롬프트 생성 정책을 학습한다. - **베이지안 최적화 기반**: 지시문과 퓨샷 예시를 탐색 공간으로 보고 효율적으로 후보를 선택한다. - **유전 알고리즘 기반**: 여러 프롬프트 후보를 집단으로 관리하며 세대별로 개선한다. - 자연어로 구성된 프롬프트는 이산적인 구조이므로 유전 알고리즘과 잘 맞는다. - 실행 결과와 평가 내용을 자연어로 분석하는 **리플렉션(reflection)**을 통해 단순 점수 이상의 개선 정보를 활용할 수 있다. ## GEPA의 진화적 최적화 루프 - 여러 후보 프롬프트를 생성하고 각 후보를 평가한다. - 점수가 높거나 여러 평가 축에서 균형이 좋은 후보를 선택한다. - 후보의 출력과 피드백을 자연어로 분석해 문제점을 찾는다. - **Reflective Prompt Mutation**을 사용해 기존 프롬프트를 개선한 변이 후보를 생성한다. - 이 과정을 수~수십 세대 반복하면서 평가 기준에 맞는 프롬프트로 수렴시킨다. - 여러 평가 관점을 동시에 고려하기 위해 **Pareto frontier 기반 선택**을 사용한다. - 스칼라 보상 하나에만 의존하는 방식과 달리, “왜 감점됐는가”라는 설명을 개선 과정에 반영할 수 있다. ## DSPy와 GEPA를 이용한 구현 - DSPy에서는 입력과 출력을 정의한 `Signature`, 실행 로직을 담은 `Module`, 예측을 수행하는 `Predict`를 구성한다. - 시그니처의 독스트링은 LLM에 전달되는 인스트럭션으로 사용된다. - GEPA는 이 인스트럭션을 자동으로 재작성해 최적화한다. - 최적화 과정에서 다음 모델을 분리해 설정할 수 있다. - **추론 모델**: 실제 답변을 생성하는 모델 - **평가 모델**: 생성 결과를 채점하는 모델 - **리플렉션 모델**: 평가 결과를 바탕으로 개선 프롬프트를 만드는 모델 - `num_candidates`, `num_generations` 등의 설정으로 후보 수와 세대 수를 조정한다. - 최적화는 학습 예제 집합을 대상으로 `optimizer.compile()`을 실행해 수행한다. ## 평가 함수와 자연어 피드백 - GEPA의 평가 함수는 기본적으로 `score`라는 단일 스칼라 값을 반환해야 한다. - 평가 기준이 여러 개라면 각 점수를 0~10 범위로 계산한 뒤 평균 등을 사용해 하나의 값으로 정규화한다. - 예를 들어 구체성, 정책 준수, 가독성의 점수를 합산해 전체 점수를 만들 수 있다. - 동시에 `feedback` 필드에 감점 이유와 개선 방향을 자연어로 전달할 수 있다. - 점수만 전달하면 “0.6점”이라는 결과만 알 수 있지만, 피드백을 주면 “의료 판단을 단정적으로 표현해 감점됐다”처럼 구체적인 원인을 알 수 있다. - 정답 데이터가 있다면 `gold`를 사용해 기대 출력이나 레이블과 비교할 수 있다. - 정답이 없는 경우에도 LLM-as-a-Judge나 규칙 기반 평가를 사용할 수 있다. - LLM-as-a-Judge를 사용할 때는 평가 기준을 명확히 작성하고, 출력 점수의 범위를 제한하는 등 평가 결과를 정규화해야 한다. ## Yahoo! JAPAN Search 건강·의료 쿼리 적용 - 건강·의료 답변은 일반 쿼리보다 정책 요구가 많다. - 주요 정책에는 다음이 포함된다. - 질병명이나 중증도를 단정하지 않기 - 근거 수준에 맞는 표현 사용하기 - 일반적인 설명 범위를 유지하기 - 필요할 때 의료기관 진료를 권유하기 - 허위 정보나 확증되지 않은 정보를 제공하지 않기 - 동시에 제목, 목록, 강조 등 마크다운 형식을 적용해 가독성도 높여야 했다. - 정책 준수와 가독성은 한쪽을 강화하면 다른 쪽이 약화될 수 있어 사람이 동시에 최적화하기 어렵다. ## 실제 최적화 방식과 기대 효과 - 초기 프롬프트에는 기존 범용 프롬프트와 건강·의료 정책 문구가 단순히 이어 붙어 있었다. - GEPA는 시그니처의 인스트럭션 부분을 재작성하며 두 목표를 동시에 최적화했다. - 평가 함수는 여러 품질 관점의 점수를 집계하고, LLM이 작성한 평가 이유를 리플렉션 피드백으로 제공했다. - 결과적으로 수일~수주가 걸리던 프롬프트 조정 작업을 약 한 시간으로 줄이는 것을 목표로 했다. - 모델 업데이트나 정책 변경 때도 동일한 평가·최적화 파이프라인을 다시 실행할 수 있어 유지보수 자동화에 유리하다. 프롬프트 최적화를 도입할 때는 먼저 정책과 품질 기준을 세분화하고, 점수뿐 아니라 구체적인 자연어 피드백을 평가 함수에 포함하는 것이 중요하다. 다만 LLM 평가자의 편향과 변동성이 결과에 영향을 줄 수 있으므로, 가능하면 규칙 기반 검사와 정답 데이터 기반 평가를 함께 사용해 최적화된 프롬프트를 별도로 검증하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델llm-as-a-judgeprompt-optimizationdspy+3

line·2026년 6월 23일·5분 읽기큐레이션 요약

총 용량 1EB 초과! 서로 역사가 다른 두 HDFS를 어떻게 연결할까? 데이터 플랫폼 연계 중 직면한 과제와 설계 결정

LY Corporation은 구 LINE과 구 Yahoo Japan의 HDFS 클러스터를 통합해 1EB를 넘는 데이터 플랫폼을 운영하고 있습니다. 두 플랫폼은 같은 HDFS를 사용했지만 Namespace 구성, 권한 관리, 사용자 접근 방식이 달라 운영·연계 설계에서 서로 다른 과제가 발생했습니다. 대규모 환경에서는 단순한 용량 증설보다 NameNode 메타데이터, 소규모 파일, Balancer 트래픽, 클라이언트 접근 경로를 함께 관리해야 한다는 것이 글의 결론입니다. ## 구 LINE과 구 Yahoo Japan의 운영 모델 차이 - **구 LINE** - 여러 분석 환경을 통합한 Hadoop 3.x 기반 플랫폼을 구축했습니다. - 사용자가 HDFS 권한이나 Apache Ranger를 직접 다루지 않도록 웹 포털을 제공했습니다. - DB·테이블 중심의 데이터 카탈로그와 역할 기반 권한 신청·승인 구조를 사용했습니다. - BI, 리포팅, ETL 등 다양한 사용 방식을 지원했지만, 기존 클러스터를 Namespace 단위로 통합하면서 관리 복잡성이 증가했습니다. - **구 Yahoo Japan** - Hadoop 0.2.x 시절부터 제한된 목적의 대규모 분석 플랫폼을 운영했습니다. - 접근 인터페이스를 최소화하고 사용 방식에 일정한 제약을 둬 안정적인 운영과 사용자 지원을 우선했습니다. - 단일 Namespace가 커지면서 NameNode 확장에 한계가 생기자 RBF(Router-Based Federation)를 도입했습니다. - 권한 관리는 여전히 HDFS Permission(POSIX 유사 모델)을 사용해 현대적인 세밀한 권한 관리에는 제약이 있습니다. - 같은 HDFS라도 데이터 위치, 사용자 접근 경로, 권한 변경의 영향 범위, 운영팀의 개입 방식이 크게 달랐습니다. ## Namespace 구성과 접근 방식의 차이 - 두 플랫폼 모두 NameNode 병목을 피하기 위해 여러 Namespace로 HDFS를 분할했습니다. - 각 Namespace는 2~4대의 NameNode로 이중화했지만, Namespace와 DataNode를 묶는 방식은 달랐습니다. ### 구 LINE: ViewFS와 DataNode 공유 - ViewFS를 사용해 클라이언트의 마운트 테이블에서 실제 Namespace와 NameNode를 결정했습니다. - 유연하고 단순하지만 모든 사용자와 서비스에 올바른 마운트 설정을 배포·유지해야 합니다. - 여러 Namespace가 DataNode를 공유해 자원 효율은 높지만 클러스터 구성과 운영이 복잡해졌습니다. - 통합 과정에서 NameNode와 DataNode 버전이 혼재한 점도 운영 부담을 키웠습니다. ### 구 Yahoo Japan: RBF 기반 서버 측 라우팅 - 사용자는 Router에 접속하고, Router가 적절한 Namespace와 NameNode로 요청을 분배합니다. - 클라이언트 설정을 단순화하고 여러 HDFS를 투명하게 연결하기 쉽습니다. - 대신 Router 계층의 가용성, 확장성, 네트워크 도달성, 진입점 제어가 중요합니다. - Observer NameNode를 활용해 읽기 부하도 분산했습니다. - 이 차이는 플랫폼 간 데이터 복사에서도 중요합니다. - ViewFS 환경은 클라이언트 마운트 테이블과 설정 배포가 핵심입니다. - RBF 환경은 Router를 통한 접근 경로와 Router 계층의 안정성이 핵심입니다. ## 구 LINE에서 발생한 용량과 네트워크 문제 - 전사적 활용이 확대되면서 예상보다 빠르게 HDFS 용량이 부족해졌습니다. - 신규 서버 납품 전까지 기존의 오래된 서버를 임시 재사용하고, 이후 서버를 교체하는 작업이 반복됐습니다. - DataNode를 대규모로 추가하거나 제거하면 HDFS Balancer와 블록 재배치가 대량의 네트워크 트래픽을 발생시켰습니다. - 따라서 서버 변경 작업은 HDFS뿐 아니라 네트워크 구성과 혼잡 가능성까지 고려해 네트워크팀과 협력해야 했습니다. ## 블록 증가와 NameNode 부하 - NameNode는 파일·디렉터리·블록 메타데이터를 메모리에 보관하므로 파일과 블록 수가 증가할수록 힙 사용량과 처리 부하가 커집니다. - 힙이 지나치게 커지면 GC 시간이 길어지고 NameNode 응답 지연과 불안정성이 발생합니다. - 특히 소규모 파일이 많은 Hive 테이블이 주요 원인이었습니다. - 해결을 위해: - FSImage를 정기적으로 덤프해 Hive 테이블로 저장했습니다. - 사용자별 경로, 파일 수, 블록 수, 데이터량을 분석했습니다. - 삭제나 스키마 변경이 필요 없는 테이블을 우선 선정했습니다. - 파일 병합으로 파일 수와 블록 수를 줄였습니다. - 파일 병합은 메타데이터 규모뿐 아니라 HDFS 요청 횟수도 줄여 잡 실행 속도와 NameNode 응답성을 개선했습니다. ## Namespace별 부하 특성과 Balancer 조정 - 부하는 Namespace마다 다르게 나타났습니다. - 임시 파일이 많은 Namespace에서는 평상시 부하는 낮지만 DataNode 추가 시 Balancer가 급격한 부하를 유발했습니다. - Apache Spark의 스테이징 파일은 짧은 시간에 생성·삭제되며 NameNode의 write lock을 빈번하게 발생시켰습니다. - Balancer의 블록 이동은 블록 정보 조회를 늘리고 read lock을 오래 유지해 파일 생성·삭제를 지연시킬 수 있었습니다. - 초기에는 Balancer 병렬도를 높였지만, DataNode 디스크 여유와 서비스 영향을 고려해 병렬도를 낮추고 처리 시간과 안정성 사이의 균형을 맞췄습니다. ## 조직 통합과 플랫폼 연계 - 조직 통합 후에는 서로 다른 설계 철학의 데이터 플랫폼을 연결해야 했습니다. - 주요 설계 과제는 다음과 같습니다. - 어느 플랫폼과 Namespace를 연결할 것인가 - 권한 관리 단위를 어떻게 맞출 것인가 - 어떤 접속 경로와 진입점을 사용할 것인가 - DistCP 등으로 데이터를 어떤 경로로 전송할 것인가 - 네트워크 도달성과 운영 책임을 어떻게 나눌 것인가 - 글의 후반부에서는 플랫폼 간 권한 모델 통합과 DistCP 기반 데이터 연계 방식을 다룰 예정이지만, 제공된 본문은 해당 설명이 시작되기 전에 끝나 있습니다. 대규모 HDFS를 운영할 때는 용량 증설만으로 문제를 해결하기 어렵습니다. 파일·블록 수를 지속적으로 관찰하고 소규모 파일을 줄이며, DataNode 변경과 Balancer의 네트워크 영향을 사전에 통제해야 합니다. 또한 플랫폼 통합 시에는 ViewFS와 RBF의 접근 모델 차이, 권한 체계, Router 및 클라이언트 설정까지 포함한 운영 경계를 함께 설계하는 것이 권장됩니다.

원문 읽기(새 탭에서 열림)

apache-sparkdata-platformhdfsapache-hadoop+3

line·2026년 6월 22일·5분 읽기큐레이션 요약

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

PJ One Piece는 생성형 AI 에이전트로 비즈니스 질문, 데이터 분석, 결과 해석, 다음 액션까지 연결해 분석 업무의 단절을 없애려는 프로젝트입니다. 기존에 평균 2주 걸리던 분석을 약 10분 만에 수행할 수 있게 되었고, 사업부 구성원의 절반 이상이 사용하는 플랫폼으로 확산되었습니다. 핵심은 단순한 SQL 자동화가 아니라 도메인 지식, 분석 프로세스, 도구, 로그와 피드백을 결합해 조직의 분석 역량을 지속적으로 축적하는 데 있습니다. ## 프로젝트 출범 배경: 세 가지 단절 - **비즈니스와 데이터의 단절** - DWH와 BI가 있어도 SQL 작성, 테이블·컬럼 선택, KPI 정의, 결과 해석에는 높은 장벽이 남아 있었습니다. - 데이터에 접근할 수 있는 것과 사업 담당자가 필요한 정보를 스스로 얻는 것 사이에 ‘마지막 1마일’이 존재했습니다. - **분석 프로세스 내 단절** - 과제 정의, 분석 설계, 실행, 리뷰, 액션이 담당자와 도구의 차이로 분리되었습니다. - 사업 배경과 의사 결정 목적이 제대로 전달되지 않아 재작업이 발생했고, 단계 사이의 대기 시간으로 리드타임이 길어졌습니다. - 분석 품질이 균일하지 않고 결과가 실제 액션으로 이어지는 속도도 떨어졌습니다. - **도메인 간 단절** - 사업마다 KPI, 테이블 구조, 사용자 행동, 시책 맥락이 달라 분석 지식과 패턴이 특정 도메인에 머물렀습니다. - 시책 평가, 퍼널 분석, 원인 분석처럼 구조가 유사한 분석도 조직 전체에서 재사용하기 어려웠습니다. ## 분석 에이전트로 분석 흐름 연결 - 사용자는 채팅 형태의 화면에서 자연어로 질문을 입력합니다. - 에이전트는 질문의 목적을 해석하고 분석 계획을 세운 뒤 다음 작업을 수행합니다. - 필요한 데이터와 문서 탐색 - SQL·Python 기반 집계 및 분석 - 시각화와 보고서 작성 - 결과 해석과 추가 분석 제안 - 다음 의사 결정과 액션 검토 - 자연어 질문만으로 분석을 시작할 수 있어 사업 담당자가 데이터 사이언티스트에게 요청하고 기다리는 구조를 줄입니다. - 질문 정리, 지표 선택, 비교 축, 리뷰 관점, 추가 분석 판단을 로그로 남겨 분석 지식과 패턴을 재사용 가능한 자산으로 만듭니다. ## 분석 플랫폼을 구성하는 다섯 가지 요소 - 사용자와 상호작용하는 애플리케이션 - 추론과 도구 사용을 담당하는 LLM 기반 에이전트 - SQL·Python 실행, 사내 문서 조사, 시각화 도구 - 도메인 지식, 스킬, 테이블 정보를 제공하는 지식 베이스 - 실행 로그, 사용자 피드백, 모니터링과 평가를 담당하는 측정 시스템 - 지식 영역은 도메인별 플러그인으로 확장할 수 있으며, 사용량이 늘수록 지식과 분석 패턴이 축적됩니다. ## 자연어 질문을 분석 요구 사항으로 변환 - 사용자가 상세한 분석 설계를 직접 작성하도록 요구하지 않고, 에이전트가 부족한 전제 조건만 확인합니다. - 예를 들어 캠페인 효과 분석에는 대상 정책, 기간, KPI, 비교 대상, 분석 단위, 제외 조건 등이 필요합니다. - 서비스 이해, KPI 정의, 집계 주의사항, 정책 탐색 방법, 리뷰 관점은 도메인 지식으로 관리합니다. - 테이블과 컬럼의 의미, 사용 조건, 적절한 활용 상황도 별도로 정비합니다. - 에이전트는 이미 확정 가능한 항목과 사용자 확인이 필요한 모호한 항목을 구분해 불필요한 질문을 줄입니다. ## 필요한 데이터에 안전하게 접근하는 구조 - 대규모 테이블 정보를 한꺼번에 LLM에 제공하지 않고 단계적으로 공개합니다. - 먼저 테이블 목록으로 후보를 좁힘 - 선택한 테이블의 상세 정의 확인 - SQL 작성 전에 컬럼 설명, 샘플, 파티션 조건, 사용상 주의사항 확인 - 원천 테이블을 그대로 사용하지 않고, 분석에 적합한 속성을 결합한 와이드 테이블을 논리적 뷰나 실제 테이블로 제공합니다. - 복잡한 JOIN을 줄여 SQL 생성 난이도와 오류 가능성을 낮춥니다. - SQL 실행 전후에 시스템 차원의 가드레일을 적용합니다. - `SELECT` 중심의 읽기 전용 제한 - 공개된 테이블 정의 및 사용 규칙 검증 - 파티션 조건 확인 - 개인정보·민감 정보 접근 제한 - 결과 행 수 제어 ## 멀티 에이전트로 분석 맥락 유지 - 슈퍼바이저형 멀티 에이전트 구조를 사용합니다. - 메인 에이전트는 사용자 요청, 분석 목적, 확인된 내용, 다음 판단 과제를 계속 관리합니다. - 통계 검정, 시계열 분석, 클러스터링, 리뷰 등 전문 작업은 역할이 제한된 서브 에이전트에 위임합니다. - 전체 분석 설계와 전문 작업을 분리해 긴 시행착오나 전문 분석이 전체 맥락을 압박하지 않도록 합니다. - 장시간 분석 중에는 발견 사항, 분석 설계, 사용 가능·불가능한 데이터, 제약 조건을 공유해 사용자가 중간에 방향을 수정할 수 있게 합니다. ## 로그와 스킬을 통한 조직 자산화 - 실행 로그로 다음 내용을 추적합니다. - 입력과 출력 - 에이전트의 도구 사용 과정 - 전제 조건 확인 방식 - 분석 설계와 생성된 SQL - 오류가 발생한 지점 - 사용자와 분석 담당자의 피드백을 결합해 프롬프트, 도구, 데이터, 스킬 중 개선이 필요한 영역을 백로그로 관리합니다. - 반복되는 분석은 스킬로 일반화합니다. - 범용 스킬: 시계열 분석, 클러스터링 등 - 도메인 특화 스킬: 월간 보고서, 정책 모니터링 등 - 스킬에는 전제 조건, 비교 축, 주의사항, 결과 해석 방법까지 포함해 다른 담당자와 도메인에서도 재사용할 수 있도록 합니다. ## 선행 도입으로 확인한 사업 가치 - 일부 서비스 사업부에 도입한 결과 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. - 데이터 사이언티스트뿐 아니라 프로덕트 오너와 현장 구성원도 일상 업무에서 먼저 질문하는 진입점으로 활용하고 있습니다. - 기존 요청부터 결과 회신까지 평균 약 2주 걸리던 분석을 약 10분 만에 실행할 수 있게 되었습니다. - 월 수백 건의 분석이 실행되며 데이터 활용 인원이 빠르게 증가했습니다. 분석 AI를 도입할 때는 SQL 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트생성형 AIPython+4