카카오가 ‘에이전트 기반 리엔지니어링’ 철학을 바탕으로 개발 업무를 진행하면서 겪은 초기 성공 경험 중 두 가지 사례를 소개합니다.

사례 1. 검증 스트레스를 줄이다

카카오의 애플리케이션이 사용자에게 배포되기 전, 반드시 거쳐야 하는 중요한 절차가 있습니다. 바로 오픈소스 자동화 관리 시스템 '올리브(OLIVE)¹’를 통해 라이선스 리스크를 검증하는 것입니다.

올리브는 5천만 건이 넘는 방대한 오픈소스 정보를 기반으로, 프로젝트에서 사용한 오픈소스의 의무사항을 준수하고 관련 리스크를 관리하도록 지원하는 필수적인 시스템으로 카카오에서 개발해 외부의 사용자들에게도 공개해 운영하고 있습니다.

올리브가 오픈소스 자동화 관리 시스템이라고는 하지만, 올리브의 모든 것이 자동화된 것은 아니었습니다. 수집되지 않은 오픈소스나 출처가 명확하지 않은 라이브러리가 발견되면, 개발자나 검증 담당자가 직접 오픈소스 정보를 입력하고, 연결하는 ‘수동 매핑’ 작업을 수행해야 했습니다. 이 ‘수동 매핑’ 작업은 전체 검증 과정의 큰 병목 지점이었습니다.

특히 공식 저장소가 사라진 오래된 오픈소스를 사용했거나 관련 문서가 부족해 찾기 힘든 경우, 개발자는 코드 분석 외에 고고학자처럼 웹을 탐색하며 출처를 증명해야 하는 상황에 놓였습니다. 이는 단순한 번거로움을 넘어, 프로젝트 배포 일정을 지연시키고 개발자의 집중력을 저해하는 ‘보이지 않는 비용’을 발생시켰습니다.

자동화의 벽과 복잡한 검증 절차

오픈소스 검증은 생각보다 자동화가 어려운 영역이었습니다. 특히 여러 명이 참여하는 대규모 프로젝트일수록 사람의 개입은 불가피했습니다.

예를 들어 '카카오톡’처럼 수많은 개발자가 협업하는 애플리케이션의 배포 상황을 상상해 봅시다. 검증을 요청하는 사용자가 직접 개발에 참여했더라도, 거대한 시스템의 모든 변경 사항을 파악하기란 쉽지 않습니다. 새로운 오픈소스가 어떤 경로로 추가되었는지, 왜 자동화 시스템이 감지하지 못했는지 확인하기 위해 동료에게 물어보거나 직접 웹을 검색해야 했습니다.

이렇게 모든 변경 사항을 수작업으로 확인하고 매핑을 마친 뒤에야 비로소 관리자에게 검토를 요청할 수 있었습니다.

특히 올리브에 ‘간접 의존성(Transitive Dependency)’ 분석 기능이 추가되면서 검증 스트레스는 절정에 달했습니다. 간접 의존성이란, 내가 직접 추가한 오픈소스 A가 또 다른 오픈소스 B와 C를 필요로 하는 것처럼, 의존 관계가 꼬리를 물고 이어지는 구조를 의미합니다. 이로 인해 검증해야 할 대상은 기하급수적으로 늘어났습니다.

이러한 상황에서 회사 전체에 ‘AI 네이티브’ 전환이라는 화두가 던져졌습니다. 우리 팀에서도 “AI 기술로 이 문제를 해결할 수 있지 않을까?” 하는 이야기가 자연스럽게 나왔습니다. 사람의 개입이 필수적이라 여겼던 바로 이 영역, 사용자의 검증 피로도를 줄이는 것을 최우선 목표로 삼고 AI의 가능성을 시험해 보기로 했습니다.

검증 프로세스

AI는 정말 사람을 대신할 수 있을까?

우리는 사용자에게 새로운 기능을 바로 적용하는 대신, 먼저 관리자 입장에서 AI의 가능성을 철저히 검증해 보기로 했습니다. 이 실험의 핵심 도구로 MCP(Model Context Protocol)를 선택했습니다.

기존 방식에서 MCP 를 통해 하나의 명령으로 AI 가 동작하는 방식으로 변화

MCP는 AI 모델이 특정 상황(Context)을 이해하고, 정해진 약속(Protocol)에 따라 API 호출과 같은 행동을 수행하게 만드는 일종의 'AI 리모컨’입니다.

우리가 여러 AI 기술 중 MCP에 주목한 이유는 명확했습니다. 사람이 웹 화면의 정보를 ‘보고’, 버튼을 '클릭’하는 행위는 결국 시스템 내부의 API를 호출하는 과정입니다. MCP는 이 과정을 그대로 모방할 수 있습니다.

즉, AI에게 프론트엔드 화면 대신 구조화된 데이터(Context)로 상황을 보여주고, API 목록(Protocol)이라는 선택지를 주면, AI가 스스로 최적의 행동을 결정할 수 있으리라 판단했습니다.

빠르게 MCP가 올리브를 다룰 수 있도록 전용 API 엔드포인트를 개발하고 실험을 시작했습니다. 물론 처음부터 AI가 완벽했던 것은 아닙니다. 초기 모델은 내부에서만 사용하는 용어를 이해하지 못해 엉뚱한 오픈소스를 매핑하기 일쑤였습니다.

먼저 AI가 '리모컨’을 더 잘 사용할 수 있도록, 각 버튼에 대한 명세서를 작성하는 것부터 시작했습니다. 마치 제품 설명서처럼, 각 버튼(API)이 어떤 상황에 사용되는지, 호출 시 어떤 정보가 필요한지, 실행 후에는 어떤 결과가 나타나는지를 명확히 기술했습니다. 사람에게는 당연하게 느껴질 수 있는 맥락 정보가 AI에게는 명시적으로 주어져야 했고, 설명이 구체적이고 명확할수록 AI는 더 똑똑하게 작동했습니다.

다음으로, 내부 용어를 AI가 이해하기 쉬운 일반적인 용어로 표준화하는 작업을 진행했습니다. 오픈소스 검증은 국내에 공개된 서비스가 드물고, 해외에서도 소수의 플랫폼만 사용되는 전문 분야입니다. 자연스럽게 팀 내부에서만 통용되는 용어들이 자리 잡게 되었는데, 이는 AI에게 혼동을 줄 수 있어, 범용적인 언어로 용어를 정리하는 과정이 필요했습니다.

MCP 실험 작업 -AI 매핑

이러한 노력 끝에, AI는 까다로운 의존성까지 정확하게 매핑해내기 시작했습니다. 심지어 사람이 미처 발견하지 못한 더 정확한 정보를 찾아내는 성과를 보이기도 했습니다.

더 나아가, 웹 검색 기능을 연동하여 AI가 직접 오픈소스 정보를 찾아 등록하는 기능을 시험했습니다. 관리자조차 실수할 수 있는 번거로운 작업이었기에 큰 기대는 하지 않았지만 결과는 놀라웠습니다. AI는 능숙하게 웹을 검색해 정확한 정보를 찾아냈고 올리브 데이터베이스에 새로운 오픈소스 정보를 올바르게 등록했습니다.

이 순간 우리는 올리브가 AI 네이티브 서비스로 거듭날 수 있다는 확신을 얻었습니다.

기술을 경험 뒤로 숨기다

MCP 실험은 성공적이었습니다. 하지만 곧 중요한 사실을 깨달았습니다. MCP를 능숙하게 다루는 것은 AI 기술에 익숙한 개발자에게나 가능한 일이었습니다. 프로젝트의 검증을 요청하는 사람은 개발자가 아닌 기획자나 PM일 수도 있었고, 모든 사용자에게 새로운 AI 도구의 학습을 요구할 수는 없었습니다.

그때 가장 중요한 원칙을 다시 떠올렸습니다. “사용자는 새로운 기능을 배우거나 기존의 작업 방식을 바꾸는 것을 원하지 않는다.”

해답은 명확했습니다. AI를 사용자가 직접 호출하는 '기능’으로 제공하는 대신, 검증 프로세스에 자연스럽게 녹아든 '자동화된 경험’으로 만들기로 결정했습니다. 사용자가 올리브에서 프로젝트 검증을 시작하면, AI 에이전트가 보이지 않는 곳에서 스스로 움직이도록 설계했습니다. 또한, AI의 긴 응답 시간을 사용자가 체감하지 못하도록 비동기 처리와 같은 내부 최적화도 진행했습니다.

결과적으로, AI 에이전트 도입 후, 스캔이 완료되었을 때 사용자가 직접 개입해야 하는 수동 매핑 항목이 평균 95% 감소했습니다. 과거에는 100개의 미매핑 항목을 처리해야 했다면, 이제는 AI가 95개를 자동으로 처리하고 사용자는 AI가 처리하지 못한 5개에만 집중하면 되는 환경이 만들어진 것입니다.

개선된 매핑 프로세스

이 과정을 통해 올리브는 다음과 같은 성과를 이루었습니다.

사용자 (개발자, PM): 검증 피로도 해소와 업무 효율성 증대
- 사용자는 더 이상 오픈소스 출처를 탐색하는 데 시간을 낭비하지 않고, 본연의 가치 창출 업무에 집중할 수 있게 되었습니다. 특히, 기존의 작업 방식을 바꿀 필요 없이 AI의 모든 혜택을 자연스럽게 누리는 최적의 사용자 경험(UX)을 구현했습니다.
관리자: 더 빠르고 정확한 리스크 관리
- AI가 1차 검증을 수행하며 검토 대상을 획기적으로 줄여주므로, 관리자는 더 빠르고 정확하게 핵심 리스크를 판단하고 관리할 수 있습니다.

결국 최고의 기술은 사용자가 인식하지 못할 만큼 경험에 자연스럽게 녹아드는 것입니다. AI는 가장 필요한 곳에 조용히 스며들어, 사람이 어쩔 수 없이 해야만 했던 지루한 과제를 해결해주었습니다.

사례 2. 라이선스를 이해하는 AI

카카오의 오픈소스 검증 시스템인 올리브는 수천 개의 라이선스 정보를 다루고 있습니다. 그러나 그중 약 85%에 해당하는 1,350여 개의 라이선스는 의무사항이 수동으로 정리되어 있지 않거나, 검토되지 않은 상태였습니다.

각 라이선스를 검토하고 법적 의무사항을 명확히 파악하는 데는 평균 1시간 이상 소요되었고, 한정된 리소스로 인해 검증 지연, 잠재적 리스크 노출 등 문제가 지속되었습니다.

“AI 네이티브로의 전환이 없었다면, 검토되지 않은 라이선스 1,350여 건이 여전히 올리브에 잠재 리스크로 남아 있었을 것이다.”

해결 전략: LLM 기반 AI 에이전트가 오픈소스 라이선스 전문을 분석하고 리스크를 식별한다

이러한 문제를 해결하기 위해 우리는 LLM을 활용해 라이선스 분석 시스템을 구축했습니다. 이 프로젝트의 경우, 단순한 문장 요약이 아니라, 법적 리스크를 AI가 판단하고 구조화하여 의무사항으로 분류하는 고도화된 법률적 판단 능력을 요구하는 작업이었습니다. 따라서 AI가 단순한 도구를 넘어 ‘지능형 에이전트’로서의 역할을 수행할 수 있음을 보여주는 중요한 시도이기도 합니다.

주요 구현 내용은 다음과 같습니다.

LLM 기반 분석 파이프라인 구축: 오픈소스 라이선스 전문을 입력하면, LLM 기반의 AI 에이전트가 이를 분석하여 주요 의무사항(예: 저작자 표시, 소스코드 공개 등)을 자동으로 추출합니다. 추출된 의무사항은 사전에 정의된 기준에 따라 의무사항의 위험도를 상(HIGH), 중( MEDIUM), 하(LOW)로 분류합니다.
의무사항 태그 생성 및 시각화: 라이선스 관리자 화면에서 AI가 식별한 의무사항은 태그로 표시됩니다. 각 태그는 위험도 수준에 따라 색상으로 구분되며, 태그를 선택하면 AI가 판단한 근거와 함께 라이선스 전문에서 해당되는 영역이 하이라이팅되어 표시 됩니다.

아래 그림은 ‘상업적 사용 불가’ 태그를 선택했을 때 예시 화면입니다.

라이선스 관리자 화면

라이선스 분석 프롬프팅과 LLM 분석 결과 자동 리뷰

AI를 활용한 라이선스 원문 분석과 자동 리뷰를 위해서는 반드시 해결해야 할 두가지 핵심 과제가 있었습니다.

라이선스 원문 분석 프롬프팅 : 원문의 복잡한 구조 파악하기

라이선스 원문은 일종의 계약서와 같은 형태로 구성이 되어 있습니다.

일반적으로 가장 상단에 라이선스의 목적/개요를 담고 있습니다.
이후 원문에서 사용할 각 단어들에 대한 정의를 설명합니다.
마지막으로 라이선스에서 정의한 의무사항들에 대해서 나열되어 있습니다.

이를 분석하기 위해서는 문맥 및 단어의 정의를 기억해야 합니다. 그리고 의무사항들에서 다른 의무사항을 참조하는 관계등을 파악할 수 있어야 합니다. 프롬프트를 구성할 때는 이를 고려해서 작성했습니다. 또한 출력 형식을 JSON 형태로 정의해서 데이터 변환을 쉽게할 수 있도록 했습니다. 아래는 프롬프트 내용 중 일부입니다.

[역할]
당신은  오픈소스  라이선스  전문가입니다.

[설명]
당신은  오픈소스  라이선스  전문을  분석하여  해당  라이선스가  부과하는  의무  사항을  추출하고,  이를  정의된  카테고리  기준에  따라  분류합니다.  각  의무  카테고리의  정의에  대한  최종  기준이며,  분석  결과는  항상  추가  설명없이  JSON  형식으로만  반환됩니다.

[분석  절차]
1.  정의  우선  해석  원칙
•  “Definitions(정의)”  섹션에서  특정  용어가  정의되어  있다면,  일반적  의미가  아닌  라이선스  내  정의를  우선  적용해야  합니다.
•  예:  “Covered  Code”,  “Modifications”,  “Source  Code”  등의  용어는  반드시  라이선스  내부  정의를  기준으로  해석합니다.
2.  조항  간  참조  추적
•  한  조항이  명시적으로  다른  조항을  참조할  경우,  해당  참조된  조항의  내용과  조건도  함께  고려하여  해석해야  하며,  해당  조항만  단독으로  해석해서는  안  됩니다.
3.  문맥  기반  해석
•  각  조항은  해당  섹션의  전체  흐름과  앞뒤  문장,  그리고  라이선스  전체  구조  내에서의  위치를  고려하여  해석해야  합니다.
•  단일  문장이나  단어만으로  의미를  판단하지  말고,  논리적  흐름과  문맥을  파악해야  합니다.
4.  모호하거나  불명확한  조항  해석
•  다음  우선순위에  따라  의미를  확정합니다:
(a)  정의  섹션을  참조
(b)  해당  조항이  속한  섹션  전체의  문맥  고려
(c)  유사  조항들과의  일관성  유지

[출력  형식  -  JSON]
1.  출력은  반드시  유효한  JSON  객체  형식이어야  하며,  다음  정보를  포함해야  합니다.
•  "license":  분석한  라이선스의  이름
•  "compliance":  의무  사항을  담은  객체  배열

2.  각  의무  사항(compliance)  객체는  아래  항목을  포함해야  합니다:
•  "name_en":  영어  의무사항  이름
•  "name":  한글  의무사항  이름
•  "text":  해당  조항의  원문  문장  배열  (줄  단위,  공백/빈  줄  제외),  원본을  줄이지  말고  그대로  유지
시작하는  문장  앞에  붙은  숫자  목록  접두어(예:  “1)”,  “2)”,  등)를  제거.
예시:  "2)  The  modified  Vim  must  be  distributed"  →  "The  modified  Vim  must  be  distributed"
•  "reason":  해당  조항이  이  카테고리에  속하는  이유에  대한  한국어  설명

LLM API 연동 및 자동 리뷰 기능: 신뢰할 수 있는 자동화 시스템 구축

아무리 좋은 프롬프트라도 실제 시스템에서 안정적으로 동작하지 않으면 의미가 없습니다. 실제 서비스에서는 다음과 같이 적용했습니다.

AI 라이선스 리뷰 시스템 구성도

AI 도입 효과와 조직 문화에 끼친 영향

이 프로젝트를 통해 기존 평균 60분 걸리던 수작업 리뷰가 AI의 도움으로 10분 이내로 단축되었으며, AI는 특히 기존에 검토 누락된 라이선스를 대상으로 리스크를 사전에 탐지하는 데 큰 기여를 했습니다. AI 도입 이후, 미검토 라이선스에 대한 정량 분석은 다음과 같은 결과를 보여주었습니다.

리뷰 안된 라이선스 총 수: 약 1,350건
AI에 의해 위험도가 중(MEDIUM) 이상으로 확인된 라이선스: 560건 (약 41%)

AI는 이러한 라이선스 리스크를 빠르게 식별하고, 선제적으로 관리할 수 있는 체계를 마련하는 데 핵심 역할을 했습니다. 이러한 변화는 카카오의 오픈소스 관리 프로세스와 조직 문화에도 긍정적인 영향을 미쳤습니다.

검토 품질 향상: 사람이 실수할 수 있는 부분(고지문 누락, 리스크 구분)을 AI가 선제적으로 제시함으로써 검토 정확도와 일관성이 크게 개선되었습니다.
업무 프로세스의 디지털화: 기존에는 분석자가 고지문 전문을 일일이 검토하며 의무사항을 추출해야 했지만, 이제는 AI가 판단한 결과를 버튼 한 번으로 확인하고 승인하는 흐름으로 업무 방식 자체가 바뀌었습니다.
표준화된 의사결정 지원: 동일한 고지문에 대해 누구든 같은 결과를 얻을 수 있어, 정책 판단의 투명성과 예측 가능성이 확보되었습니다.
효율적인 리스크 검토: 라이선스 관리자 화면에서 의무사항 태그와 하이라이트를 볼 수 있게 되면서, 의무사항을 빠르게 확인하게 되었습니다. 이를 통해 업무 효율성이 높아졌습니다.

이 프로젝트는 단순한 LLM 활용을 넘어, AI가 실질적으로 법적 검토를 대체하거나 보완하는 단계까지 작동할 수 있다는 것을 보여주는 ‘AI 에이전트’의 대표 사례이기도 합니다. 특히 리스크가 높은 영역에 AI를 배치함으로써, ‘에이전트 기반 리엔지니어링’이 책임 있는 자동화를 통해 사람의 핵심 역량을 강화하고 업무 효율을 극대화할 수 있다는 것을 입증할 수 있었습니다.

각주

OLIVE(https://olive.kakao.com)(올리브)는 사용자의 개발 프로젝트에서 사용한 오픈소스 컴포넌트를 조회하고 오픈소스의 라이선스 의무사항과 이슈를 확인하여 고지 의무를 준수할 수 있도록 지원하는 카카오의 오픈소스 관리 시스템입니다.

[목차] AI Native: 실행과 확산 사례집

[칼럼] 오픈소스기술의 AI 네이티브 전환 성공 사례