IT 에이전시가 LLM으로 프로젝트 지식을 자산화하는 법

한줄 요약

프로젝트마다 사라지는 지식을 LLM 위키로 팀 자산으로 만드는 실전 전략

프로젝트가 끝나면 지식도 같이 사라진다

IT 에이전시의 가장 큰 낭비는 같은 문제를 반복해서 푸는 것이다. A 프로젝트에서 해결한 AWS 비용 최적화 이슈를, 6개월 뒤 B 프로젝트에서 처음부터 다시 조사한다. 특정 프레임워크의 버전 충돌 해결법은 그걸 직접 겪은 개발자 노트북 어딘가에 잠들어 있다. 클라이언트 도메인을 파악하는 데 온보딩 기간 2주가 통째로 사라진다.

에이전시가 이 문제를 해결하려고 Confluence나 노션 위키를 도입한다. 그런데 대부분 1~2년 안에 유령 공간이 된다. 이유는 단순하다. 문서를 작성하고 최신 상태로 유지하는 비용이 너무 크기 때문이다. 새 내용을 추가하려면 기존 문서와 중복되는 부분을 확인하고, 관련 페이지를 업데이트하고, 내부 링크를 정리해야 한다. 개발자는 기능 하나 배포하고 나서 이 작업까지 하기 싫다. 결국 위키는 멈추고, 지식은 또 흩어진다.

왜 기존 위키 관리 방식은 에이전시에서 실패하는가

일반 개인 지식 관리와 달리 에이전시 환경은 구조적으로 더 불리하다.

첫째, 기여자가 여럿이다. 한 사람이 일관된 구조를 유지하기도 어려운데, 팀원마다 작성 방식이 다르면 위키는 빠르게 뒤죽박죽이 된다.

둘째, 회전율이 높다. 프리랜서, 계약직, 이직 등으로 지식을 가진 사람이 팀을 떠나면 그 맥락도 함께 사라진다. 문서가 있어도 왜 그 결정을 내렸는지는 남지 않는다.

셋째, 프로젝트마다 컨텍스트가 완전히 다르다. 헬스케어 클라이언트 다음에 이커머스, 다음에 핀테크로 넘어가면, 도메인 지식이 쌓이는 게 아니라 매번 리셋된다.

이 세 가지 문제를 모두 가진 환경에서 사람이 직접 위키를 유지하는 건 구조적으로 지속 불가능하다.

LLM을 위키 관리자로 쓰면 무엇이 달라지나

핵심은 이렇다. 지루하고 반복적인 문서 관리 작업은 LLM에게 맡기고, 사람은 무엇을 기록할지 판단하는 데만 집중한다.

구체적으로는 세 가지 레이어로 운영한다.

소스 레이어는 원본 자료다. 회의록, PR 설명, 포스트모템, 클라이언트 브리핑, 기술 결정 문서(ADR) 등 날것의 정보가 여기 쌓인다. LLM이 읽기만 하고 수정하지 않는 영역이다.

위키 레이어는 LLM이 직접 생성하고 관리하는 정리된 문서다. 기술 스택별 트러블슈팅 가이드, 클라이언트 도메인 요약, 반복 패턴 정리 등이 마크다운 파일로 쌓인다. 새 소스가 들어올 때마다 LLM이 관련 페이지를 자동으로 업데이트한다.

스키마 레이어는 LLM에게 이 위키의 규칙을 알려주는 설정 문서다. "기술 결정 페이지는 배경-선택지-결론 구조로 쓴다", "클라이언트 페이지는 도메인-주요 제약-관련 프로젝트를 포함한다" 같은 컨벤션을 정의한다. 이 파일이 있어야 LLM이 일반 챗봇이 아닌 체계적인 위키 관리자로 작동한다.

---

이 구조에서 에이전시 팀원이 하는 일은 단순하다. 회의가 끝나면 회의록을 소스 폴더에 넣는다. PR을 머지하면 기술 결정 메모를 한 줄 남긴다. LLM이 나머지를 처리한다. 문서 작성 시간이 5분 이하로 줄어들면, 팀원들은 실제로 기록을 남긴다.

에이전시 위키에 넣어야 할 지식은 따로 있다

모든 걸 다 담으려 하면 실패한다. 에이전시 관점에서 가장 ROI가 높은 지식 유형은 세 가지다.

반복 등장하는 기술 문제다. 특정 라이브러리 조합에서 생기는 이슈, 클라우드 설정 실수, 배포 파이프라인 트러블슈팅 등은 한 번 잘 정리해 두면 다음 프로젝트에서 몇 시간을 아낀다.

기술 결정 맥락이다. 왜 이 기술 스택을 골랐는지, 왜 저 방식은 버렸는지가 코드보다 더 빠르게 사라진다. 1년 뒤 레거시를 유지보수할 때 이 맥락이 없으면, 잘못된 결정을 되풀이하거나 멀쩡한 구조를 뜯어고친다.

클라이언트 도메인 지식이다. 특정 산업의 규제, 클라이언트 특유의 비즈니스 로직, 담당자가 민감하게 여기는 포인트 등은 새 팀원이 온보딩할 때 결정적으로 중요하다. 지금은 이게 퇴사한 PM 머릿속에 있다.

에이전시에서 실제로 시작하는 방법

이론은 충분하다. 실제로 어떻게 시작하느냐가 문제다.

첫째, 도메인 하나를 고른다. 당장 가장 반복적으로 겪는 기술 영역 하나만 시작한다. 전체 조직 지식을 한 번에 담으려 하면 스키마 설계부터 막힌다.

둘째, 스키마 파일을 먼저 만든다. "이 위키에서 기술 결정 페이지는 어떤 구조인가", "트러블슈팅 페이지에는 어떤 항목이 들어가야 하는가"를 LLM과 함께 초안을 잡는다. 처음엔 짧아도 된다. 쓰면서 다듬어간다.

셋째, 지난 프로젝트 포스트모템 하나를 넣어본다. LLM이 어떤 페이지를 만들어내는지 보고, 스키마가 잘 작동하는지 확인한다. 이 단계에서 스키마를 두세 번 고치는 게 정상이다.

넷째, 팀 루틴에 붙인다. 주간 회의 후 회의록 업로드, PR 머지 후 ADR 한 줄 메모처럼 기존 워크플로에 소스 추가 행동을 끼워 넣는다. 별도 시간을 내야 하는 습관은 지속되지 않는다.

주의할 점도 있다. 위키가 커질수록 LLM이 전체 일관성을 유지하기 어려워진다. 스키마가 모호하면 어느 순간 위키가 제멋대로 커진다. 그래서 처음 설계에 공을 들이고, 주기적으로 페이지 간 모순이나 구조 이탈을 점검하는 린트 작업도 LLM에게 맡겨야 한다.

사람이 판단할 일은 여전히 있다. 무엇을 기록할지, 어떤 결정이 중요한지, 위키의 방향을 어디로 잡을지는 사람이 결정한다. LLM은 그 결정이 쌓이는 비용을 낮춰주는 인프라다. 에이전시에서 지식이 자산이 되려면, 쌓는 것보다 유지하는 비용이 더 중요하다. 그 비용을 낮추는 게 LLM 위키의 역할이다.