LLM의 개별 wiki 구조 이후에, 통합관리

목차

• 1. 에이전트에 거부감이 있었다
• 2. 혼자 A to Z를 하려니 병렬로 돌리게 됐다
• 3. 전환점 — 강의 강사님에게 "AI 에이전트를 위한 로컬 wiki" 개념을 들었다
• 4. 적용 — skill / rule / agent / session 파일 구조를 만들었다
• 5. 결과 — 체감상 최소 2배
• 6. 개인화하면서 느낀 것
• 7. 지금까지의 결론

1. 에이전트에 거부감이 있었다

처음엔 AI 에이전트에 거부감이 있어서, 1:1 검토용으로만 많이 썼습니다. 내가 짠 코드나 설계를 붙여넣고 "이거 문제 없나" 물어보는 식이었습니다. 에이전트가 알아서 파일을 만들고 고치는 건 통제를 잃는 느낌이라 꺼렸습니다.

2. 혼자 A to Z를 하려니 병렬로 돌리게 됐다

그런데 개인이 프로젝트를 처음부터 끝까지 혼자, 그것도 단시간에 끝내려니 손이 모자랐습니다. 그래서 AI 에이전트를 병렬로 돌리기 시작했습니다.

쉬웠던 것

• 초기 세팅: 매우 쉽고 간편했습니다. 프롬프트를 어떻게 쓰느냐에 따라 스캐폴딩·설정·보일러플레이트가 빠르게 나왔습니다.
• 단순 기능 단위 테스트와 코드 validation: 이것도 쉬웠습니다. "이 함수 테스트 짜 줘", "이 코드에 규칙 위반 있나" 같은 작업은 에이전트가 잘합니다. 어려웠던 것

프로젝트가 커지고 패키징(구조화) 작업이 늘어나면서, 정해 둔 코드 컨벤션과 rule, 요구사항이 점점 희미해졌습니다. 매 세션마다 에이전트에게 "우리 프로젝트는 이런 규칙이 있다"를 다시 설명해야 했고, 설명이 빠진 세션의 산출물은 스타일이 어긋났습니다. 병렬 작업이 커질수록 개별 작업이 아니라 그것들을 하나로 합치는 지점이 무너졌습니다.

3. 전환점 — 강의 강사님에게 "AI 에이전트를 위한 로컬 wiki" 개념을 들었다

현재 듣고 있는 강의의 강사님에게 도움을 받아, AI 에이전트를 위한 로컬 wiki 개념을 처음 접했습니다. 안드레이 카파시가 제안한 방향으로, 요지는 이렇습니다.

• 매 세션마다 모든 컨텍스트를 다시 읽거나, 컨텍스트 창을 초과하는 것을 방지한다.
• 지식을 .md 파일 단위로 쪼개고 백링크([[...]])로 연결해서, 에이전트가 지금 작업에 필요한 문서만 빠르게 찾아 읽게(fast search/thinking) 한다.
• 반복해서 참조되는 규칙·설계·이력을 문서로 축적해, 세션이 끊겨도 다음 세션이 이어받을 수 있는 외부 기억을 만든다.

4. 적용 — skill / rule / agent / session 파일 구조를 만들었다

들은 개념을 그대로 구조로 옮겼습니다.

• rule: 코드 컨벤션, 노트 작성 규칙, 폴더 구조 등 "매번 지켜야 하는 것"을 문서로 고정.
• skill: 반복 작업(배포 절차, 리뷰 체크리스트 등)을 절차 문서로.
• agent: 역할별 에이전트의 책임 범위와 사용할 도구를 정의.
• session: 세션 핸드오프 문서 — 이번 세션에서 무엇을 했고, 무엇이 남았는지. 그리고 각 파일에 붙은 설명을 읽고 내 프로젝트에 맞게 적용했습니다.

5. 결과 — 체감상 최소 2배

적용 후, 에이전트의 속도와 생산량이 이전보다 최소 2배는 나아진 것을 경험했습니다. 왜 그런지 짚어 보면:

• 매 세션 컨벤션·요구사항을 다시 설명하지 않아도 됩니다. rule 파일을 읽고 시작하니까, "우리는 이렇게 한다"를 프롬프트에 매번 넣던 시간이 사라졌습니다.

• 에이전트가 관련 문서만 골라 읽습니다. 전체를 통째로 주지 않고 백링크를 따라가니, 컨텍스트가 가볍고 응답이 빠릅니다.

• 세션이 끊겨도 이어받습니다. 핸드오프 문서 덕분에, 다음 세션이 "어디까지 했지"를 복구하는 데 쓰던 시간이 거의 0이 됐습니다. 구체적인 변화도 있었습니다.

• 블로그(이 wiki)에 훨씬 많은 주제를 기록하고 정리할 수 있게 됐습니다.

• 그동안 방치했던 것들 중 MVP를 선정해, 진행 중인 프로젝트를 순차적으로 이어 갈 수 있게 됐습니다.

6. 개인화하면서 느낀 것

이 wiki를 내 방식대로 다듬으면서 든 생각은, wiki가 에이전트들의 공유 기억 역할을 한다는 것입니다.

• 에이전트는 세션이 끝나면 컨텍스트를 잃습니다. 하지만 명세서·규칙·이력이 wiki에 글로 남아 있으면, 다음 에이전트가 그걸 읽고 이어서 합니다.
• 실제로 소스를 날렸을 때 복구가 가능했던 유일한 이유가 Notion 명세서였습니다. 그 역할을 지금은 이 wiki가 합니다.
• 그래서 wiki 구조를 개별 프로젝트에 도입하고, 나아가 여러 프로젝트를 한곳에서 관리하는 wiki center 형태를 고민 중입니다.

7. 지금까지의 결론

AI 에이전트는 시작(세팅)과 단순 검증엔 확실히 강합니다. 하지만 여러 갈래를 동시에 끌고 가는 것과 흩어진 산출물을 하나로 수렴시키는 것은 여전히 사람 몫이었습니다.

로컬 wiki는 그 두 약점을 메우는 장치였습니다. 규칙을 파일로 고정해 "매번 설명"을 없애고, 핸드오프로 "매번 복구"를 없애니, 에이전트가 잘하는 부분(빠른 실행)에 시간을 몰아줄 수 있었습니다. 개인화는 결국 "내 프로젝트들이 어떻게 연결되는지를, 나와 에이전트 둘 다 빠르게 찾아볼 수 있게 정리하는 작업"인 것 같습니다.