LINE Engineering

LINE Planet 팀의 PM과 Android 엔지니어 두 명이 웹 전문 엔지니어 없이 LINE 앱 내에서 그룹 영상 통화 서비스를 개발한 과정을 다룬다. LIFF(LINE Front-end Framework)와 LINE Planet SDK를 활용해 React/Vite 기반 웹 앱을 구성했고, Firebase Cloud Functions로 별도 서버 인프라 없이 구현을 완료했다.

LY Corporation이 구 LINE의 Verda와 구 Yahoo Japan의 YNW를 통합하며 구축한 차세대 클라우드 플랫폼 Flava의 DBaaS 아키텍처를 상세히 설명한다. Kubernetes 오퍼레이터 패턴으로 DBA 도메인 지식을 코드화했고, 마이그레이션 전략부터 AI 기반 DBA-as-a-Service까지 미래 로드맵을 함께 다룬다.

LY Corporation Tech-Verse 2026에서 발표된 이 글은 LLM 기반 에이전트 시스템에서 컨텍스트 창을 단순히 더 크게 늘리는 것만으로는 한계가 있다는 문제의식에서 시작한다. 어텐션 희석, 컨텍스트 부패, 규칙 충돌 등 장기 실행 에이전트의 구조적 문제를 해결하기 위해 AST 기반 가지치기와 VFS 추상화를 결합한 시멘틱 컨텍스트 OS 아키텍처를 제안한다.

LY Corporation에서 Slack에 축적된 사고 대응·문의 응답 정보를 구조화하는 작업이 담당자별 품질 편차와 지연 문제를 겪었다.

사내 AI 툴 도입 확산에 따라 토큰 소비가 예상치를 초과하고, 긴 대화에서 컨텍스트 누적으로 AI 출력 품질이 저하되는 문제가 발생했다.

AI 에이전트로 Git 릴리스 자동화를 만들 때 MCP 서버와 에이전트 스킬 중 무엇이 더 적합한가.

LINE Album QA 팀이 "생성형 AI 가 QA 를 대체하나"라는 질문에, AI 는 QA 를 대체하지 않고 확장한다는 결론으로 답한 1년 운영기를 다룬다. QA 의 병목은 테스트 속도가 아니라 기획·Slack·Jira·PR·로그·리뷰에 흩어진 정보를 구조화하고 판단하는 일이며, AI 를 대화 도구가 아닌 30여 개 자동화 워크플로로 운영 체계에 통합한 게 핵심이다.

대량의 개발 문서 검색에 시간이 많이 들고, 사내 전문가 상담도 비효율적이다.

AI 에이전트가 조직 내 다양한 서비스를 연동할 때 복잡한 인증·인가 관리와 토큰 증식으로 운영 비용·보안 위험 증가.

기존 Copilot식 코드 보조만으로는 구현부터 PR까지의 개발 생산성 향상을 충분히 체감하기 어려웠다.

SLI/SLO 이론은 알지만 실제 서비스에 어떻게 적용하고 운영할지가 어려운 부분.

MCP 서버는 강력하지만, 사내 데이터/API 에 무방비로 연결하면 보안/감사 문제가 발생한다.

단일 LLM 에이전트로는 사내 시스템 통합 같은 복잡한 워크플로를 다루기 어렵다.

PR 리뷰가 적체되면 개발 속도가 느려진다. 큰 조직일수록 리뷰어 병목 심함.

AI 도구는 개인 학습만으로 회사 전체에 안 퍼진다. 조직 차원의 학습 구조가 필요하다.

Hive 기반 데이터 레이크에서 데이터 반영 속도가 느려 down-stream 분석/머신러닝 파이프라인이 지연된다.

메신저 / 게임 / 커머스 등 각자 채팅 기능을 따로 만들면 중복 개발 비용이 크다.

광고 플랫폼의 대규모 데이터 처리를 YARN 클러스터로 운영하면 자원 활용도와 격리에서 한계가 온다.

대규모 이미지 콘텐츠를 안전 정책에 맞게 검수해야 한다. 기존 이미지 분류기는 뉘앙스/맥락 처리에 약하다.

AI 코딩 도구가 만든 코드 자체의 안전성 검증이 어렵다. 보안 취약점이 우연히 들어갈 수 있다.