세무조정계산서와 감사보고서 비교
스킬을 개발하기로 마음먹은 계기
회계법인 Tax팀에 있다보니 매번 법인세 신고 기간이 매우 바빴습니다. 바쁜 이유는 세액을 산출하는 업무보다는 신고를 위한 서식을 만들고, 이를 다시 검증하는 시간이 더 오래 걸렸습니다.
특히나, 제대로 잘 입력이 되 었는지를 사람이 일일히 하나씩 보는 업무이기 때문에 무척 지루하고 재미가 없었고, 이를 자동화할 스킬을 생각하게 되었습니다.
법인세 신고를 하는 서식의 양식은 정해져있기 때문에 감사보고서 주석만 제대로 분석을 하면 대사하는 데에 큰 무리가 없을 것이라고 판단했습니다.
사용한 도구
Claude Code, Codex, 사내 내부 에이전트
병목 사항?
결국 회사에서는 모든사람들이 클로드코드나 코덱스를 쓸 수 없기 때문에(특히 헤르메스는 절대 못씁니다) 사내 내부 에이전트에서 돌아가는 스킬을 만들어야 했습니다. 사내 내부 에이전트와의 대화만으로는 스킬을 정교화할 수 없다고 판단하여 클로드코드와 코덱스를 활용하여 스킬을 고도화하고 있습니다.
AI 자동화로 지식 관리 개선
세션이 바뀔 때마다 AI가 이미 확정한 도메인 규칙을 다시 물어보는 문제를 해결하려고, 지식을 "한 파일 = 한 사실 + 인덱스" 구조로 다시 짰습니다. 결과적으로 1,385줄짜리 결정 문서를 통째로 읽지 않고도 필요한 줄만 찾아가게 됐습니다.
바쁘시면 이것만 읽어도 돼요:
- 문제: 대화가 길어지면 컨텍스트가 압축되고, 어렵게 확정한 업무 규칙이 흐려져서 AI가 같은 질문을 반복합니다.
- 핵심 구조: 지식을 한 파일에 한 사실로 쪼개고, 한 줄짜리 인덱스를 따로 둡니다. 인덱스는 항상 읽고 본문은 필요할 때만 엽니다.
- 가장 효과 컸던 것: 43개 결정이 쌓인 1,385줄 문서를 "키워드 → 해당 줄 위치" 북마크로 만든 것. 전문을 읽지 않아도 됩니다.
- 지식과 상태를 분리했습니다. 오래 사는 것(도메인 규칙)과 매번 바뀌는 것(지금 몇 단계인가)은 저장 위치를 다르게 했습니다.
- 가장 큰 자산은 제가 만든 게 아니었습니다. 회사에 원천 자료가 이미 많았고, 선배들이 사람 손으로 만들어 둔 대사 산출물(정답지)이 있었습니다. 규칙을 추측하는 대신 정답지와 맞춰보며 확정했습니다.
- 다만 정답지를 AI에게 그대로 주지는 않았습니다. 주면 규칙을 배우는 게 아니라 답을 외웁니다 — 정답지가 없는 새 사례에서 아무것도 못 하게 됩니다. AI에게는 거기서 뽑은 규칙만 줍니다.
- 의외의 함정: 새로 본 사례 하나 때문에 이미 확정된 규칙을 덮어쓴 적이 있습니다. 그 뒤로 "기존 문서를 먼저 검색하고 고칠 것"을 규칙으로 만들었습니다.
- 교훈: 지식관리는 많이 적는 게 아니라 다음 세션이 틀리지 않을 최소 단위로 적는 것이었습니다.
AI 자동화의 문제 해결
- AI에게 매번 같은 배경 설명을 반복하고 있는 분
- 문서를 열심히 쌓았는데 정작 AI가 안 읽거나 못 찾는 분
- 내 분야의 규칙·용어·판단 기준을 AI에게 계속 물려주고 싶은 분
- 프로젝트가 길어지면서 "예전에 이거 결정했었는데" 하고 뒤지는 시간이 아까운 분
문제 상황 (Before)
법인세 신고서식과 재무제표 주석의 관계사 거래 내역을 대조하는 작업을 AI로 자동화하는 프로젝트를 몇 주째 하고 있었습니다.
이 분야는 규칙이 많습니다. 관계사와 의 거래를 매출·매입·대여·차입 네 가지로 나눠야 하는데, 무엇을 포함하고 무엇을 제외하는지가 항목마다 다릅니다. 이자는 어디로 넣는지, 배당금은 넣는지 빼는지, 대여금은 기말 잔액 기준인지 기간 평균 기준인지, 어떤 서식의 숫자가 판단 기준이고 어떤 게 참고용인지.
하나씩 근거를 찾아 확정하는 데 며칠씩 걸렸습니다. 문제는 그렇게 확정한 지식이 남지 않는다는 것이었습니다.
대화가 길어지면 컨텍스트가 압축됩니다. 그러면 AI가 이렇게 나옵니다.
- 이미 결론 난 걸 다시 물어봅니다. ("이자는 매출에 포함하나요?", "대여금은 기말잔액인가요 평균잔액인가요?")
- 예전 상태를 기준으로 판단합니다. (3주 전 구조를 현재라고 착각)
- 심지어 확정된 규칙을 새로 본 사례 하나 때문에 바꿔버립니다.
마지막 게 제일 위험했습니다. 문서 한 건을 보고 "아, 이 경우엔 이렇게 처리하는군요" 하면서, 이미 여러 차례 검토해 확정해둔 기준 문서의 문장을 고쳐버린 적이 있습니다. 나중에 발견했는데, 그 확정은 더 넓은 표본을 보고 내린 결론이었습니다.
문서는 이미 충분히 많았습니다. 브리핑 문서, 설계 문서, 결정 기록, 작업일지… 그런데 AI가 그걸 읽지 않거나, 읽어도 필요한 부분을 못 찾았습니다. 결정 기록 문서는 그때 이미 1,000줄이 넘었고, 매번 통째로 읽히기엔 너무 컸습니다.
사용한 도구
- 도구: Claude Code (파일 기반 장기 메모리 기능 포함)
- 모델: Claude Opus 5
- 특이사항: 지식은 전부 일반 마크다운 파일입니다. 특별한 DB나 벡터 검색을 쓰지 않았습니다.
작업 과정
1단계 — "많이 적기"를 멈추고 "찾을 수 있게 적기"로 바꿨다
처음엔 문서를 더 잘 쓰면 될 거라고 생각했습니다. 그래서 브리핑 문서를 더 자세히 썼습니다. 효과가 없었습니다.
원인을 다시 보니 문제는 양이 아니라 진입 비용이었습니다. AI가 어떤 판단을 하려고 할 때, 그 판단에 필요한 지식이 1,000줄짜리 문서 어딘가에 있으면 사실상 없는 것과 같습니다.
그래서 원칙을 바꿨습니다.
```
지식은 "한 파일 = 한 사실"로 쪼갠다.
그리고 한 줄짜리 인덱스를 따로 둔다.
인덱스는 항상 읽고, 본문은 필요할 때만 연다.
```
2단계 — 한 파일에 한 사실, 그리고 유형 붙이기
메모리 파일을 이렇게 통일했습니다. 파일 하나에 사실 하나. 맨 위에 이름·한 줄 요약·유형을 붙입니다.
유형은 네 가지로 나눴습니다.
- 사용자: 이 사람이 누구이고 무엇을 선호하는가
- 피드백: 일하는 방식에 대해 받은 지적 (그리고 왜 그랬는지)
- 프로젝트: 코드나 이력만 봐서는 알 수 없는 목표·제약
- 참조: 외부 자료 위치
특히 "피드백" 유형에는 반드시 왜 그런 지적을 받았는지와 다음에 어떻게 적용할지를 같이 적게 했습니다. 결론만 적힌 지식은 상황이 조금만 달라지면 못 씁니다.
예를 들면 이런 식입니다.
```
제목: 기록과 검증은 다르다
내용: 결과 파일에 값을 적는 것(기록)과, 읽는 쪽이 다시 계산해서 대조하는 것(검증)은 다르다.
왜: "입력 결박 완료"라고 썼다가, 그 값을 읽는 코드가 한 줄도 없다는 지적을 받고 한 라운드를 통째로 날렸다.
적용: 읽는 코드 줄을 지목하지 못하면 "검증했다"고 쓰지 말 것.
```
이렇게 적어두니, 몇 주 뒤 완전히 다른 작업에서도 같은 원칙이 그대로 적용됐습니다.
3단계 — 1,385줄 문서를 "북마크"로 만들었다
가장 효과가 컸던 작업입니다.
결정 기록 문서는 계속 커졌습니다. 43개 결정, 1,385줄. 매번 다 읽을 수는 없고, 그렇다고 안 읽으면 예전에 정한 걸 어깁니다.
그래서 문서를 줄이는 대신 인덱스를 만들었습니다. 인덱스에는 이렇게만 적습니다.
- 이 문서에 무엇이 들어 있는지 (43개 결정, 1,385줄)
- 어떤 키워드로 찾으면 몇 번째 줄로 가면 되는지
- 언제 반드시 이 문서를 열어야 하는지 (예: 도메인 정책을 구현하기 전에는 필독)
효과가 즉각적이었습니다. AI는 인덱스만 보고 필요한 줄 범위만 열어서 확인합니다. 읽는 양은 줄었는데 정확도는 올라갔습니다.
4단계 — 지식과 상태를 분리했다
처음엔 다 섞여 있었습니다. "지금 3단계 진행 중"과 "이 항목은 매출에 포함한다"가 같은 문서에 있었습니다.
이러면 문서가 금방 썩습니다. 상태는 매일 바뀌고 지식은 몇 달을 가는데, 같이 두면 바뀌는 것 때문에 안 바뀌는 것까지 신뢰를 잃습니다.
그래서 나눴습니다.
| 성격 | 예시 | 어디에 두나 | 수명 |
|---|---|---|---|
| 지식 | 도메인 규칙, 용어 정의, 판단 기준 | 도메인 규칙 문서 + 메모리 | 몇 달 |
| 결정 | 왜 이렇게 하기로 했는가 | 결정 기록 + 인덱스 | 영구 (추가만) |
| 상태 | 지금 몇 단계인가, 누구 차례인가 | 상태 문서 (맨 위가 최신) | 며칠 |
| 재개 | 새 세션이 첫 5분에 읽을 것 | 진입점 문서 | 상시 갱신 |
결정 기록은 추가만 하고 수정하지 않습니다. 결정이 바뀌면 새 결정을 추가하고 이전 것을 "대체됨"으로 표시합니다. 그래야 "왜 그때 그렇게 정했는지"가 남습니다.
5단계 — 흩어진 도메인 규칙을 한 문서로 통합
같은 주제 지식이 여기저기 흩어져 있으면 AI가 일부만 보고 판단합니다. 실제로 그래서 틀린 적이 있습니다.
그래서 핵심 도메인 규칙 — 매출·매입·대여·차입 네 가지를 각각 무엇으로 구성하고 무엇을 포함·제외하는지 — 을 한 문서에 통합하고, 인덱스에 이렇게 표시했습니다.
```
[4측정 도메인 규칙 (권위 문서)] — 매출/매입/대여/차입 구성·포함·제외 통합 규칙.
답하기 전에 먼저 확인. 재질문 금지.
```
"이자는 어디로", "배당금은 제외", "대여·차입은 기말잔액 기준", "평균잔액은 참고용" 같은 판단이 한 곳에 모여 있고 그게 권위 문서라는 게 인덱스에 적혀 있으니, 흩어진 문서를 뒤지다 일부만 보고 답하는 일이 없어졌습니다.
"재질문 금지"라는 표현이 의외로 잘 먹혔습니다. AI가 물어보려다가 먼저 그 문서를 열어봅니다.
5-1단계 — 회사에 이미 있던 자료를 "지식"으로 끌어올리기
사실 이 프로젝트에서 제일 큰 자산은 제가 만든 게 아니었습니다. 회사 안에 이미 자료가 아주 많았습니다.
두 종류였습니다.
첫째, 원천 자료. 실무에서 쓰는 신고서식과 재무제표 주석 파일이 여러 회사·여러 연도치로 쌓여 있었습니다. 흩어져 있어서 그렇지 없는 게 아니었습니다. 그래서 먼저 한 일이 모으는 것이었습니다. 흩어진 원본을 한곳으로 수집하되 읽기 전용 사본으로만 두고, 처리 결과는 반드시 별도 폴더에 내도록 규칙을 정했습니다. 원본을 실수로 덮어쓰면 복구가 번거롭기 때문입니다.
둘째, 그리고 이게 결정적이었는데 — 선배들이 사람 손으로 만들어 놓은 대사 산출물(정답지)이 있었습니다. 같은 작업을 이미 사람이 정확하게 해놓은 결과물입니다.
이건 지식관리 관점에서 굉장한 자산입니다. "정답이 뭔지"를 이미 아는 상태에서 규칙을 세울 수 있다는 뜻이니까요. 규칙을 하나 정할 때마다 "이 규칙이 맞나?"를 추측하는 대신, 정답지와 맞춰보고 틀리면 규칙을 고쳤습니다. 제가 며칠씩 걸려 확정했다고 쓴 도메인 규칙들은 대부분 이 대조 과정에서 나온 것입니다.
다만 여기에 규칙을 하나 강하게 걸었습니다.
```
정답지는 그라운딩(내가 방향을 확인하는 용도)으로만 연다.
정답지에서 본 값·문구·회사명을 AI에게 전달하거나 코드·문서에 옮겨 적지 않는다.
전달하는 것은 "그래서 규칙이 무엇인가"라는 결론뿐이다.
```
이유는 두 가지입니다. 하나는 그 값들이 그대로 노출되면 안 되는 자료라서고, 다른 하나가 더 중요한데 — 정답지를 그대로 먹이면 AI가 규칙을 배우는 게 아니라 답을 외웁니다. 그러면 정답지가 없는 새 회사에서 아무것도 못 합니다. 실제로 이 프로젝트 초기에 정답지를 직접 읽어서 만든 파생 파일들이 있었는데, 나중에 전부 격리 폴더로 빼고 "신규 코드에서 참조 금지"로 못 박았습니다.
정리하면 이런 계층이 됐습니다.
| 자료 | 어떻게 쓰나 | AI에게 주는가 |
|---|---|---|
| 원천 자료(신고서식·주석) | 읽기 전용 사본으로 수집, 처리 결과는 별도 폴더 | 준다 (입력) |
| 선배들의 정답지 | 내가 그라운딩용으로만 열람 | 안 준다 |
| 정답지에서 도출한 규칙 | 도메인 규칙 문서에 결론만 기재 | 이걸 준다 |
"자료를 그대로 주는 것"과 "자료에서 뽑은 규칙을 주는 것"은 완전히 다릅니다. 전자는 답을 외우게 하고, 후자는 일반화됩니다. 이 구분이 이 프로젝트 지식 구조의 뼈대가 됐습니다.
6단계 — 실수를 지식으로 바꾸는 칸을 만들었다
재개 진입점 문서에 섹션 하나를 뒀습니다. 제목은 "반복해서 밟은 지뢰"입니다.
거기에 지금 다섯 개가 적혀 있습니다. 전부 실제로 두 번 이상 반복된 실수입니다. 예를 들면,
- 기록과 검증을 혼동 (→ 한 라운드 낭비)
- 지적받은 곳만 고치고 같은 유형을 방치 (→ 다음 라운드에 같은 지적 재발)
- 제출 서류 4종 중 하나 갱신 누락 (→ 본문이 아예 안 읽힘)
- 확인하지 않은 사실을 문서에 기재 (→ 거짓으로 판명)
새 세션은 이 목록을 먼저 읽습니 다. 실수가 개인의 기억이 아니라 프로젝트의 자산이 되는 지점입니다.
7단계 — 지식이 덮어써지는 걸 막기
가장 위험했던 사건이 여기서 나왔습니다.
문서 한 건을 새로 보고, AI가 이미 확정된 기준 문장을 고쳐버렸습니다. 좁은 표본 하나로 넓은 결론을 뒤집은 것입니다.
그래서 규칙을 하나 추가했습니다.
```
확정된 규칙 문장을 새로운 사례 하나 때문에 고치기 전에,
기존 문서 전체를 먼저 검색해서 이미 다뤄진 사안인지 확인할 것.
```
비슷한 맥락에서 하나 더 있습니다. 새 절을 문서에 추가할 때, 문서 전체에서 관련 용어를 먼저 검색하게 했습니다. 안 그러면 새 절과 옛 문장이 서로 모순되는 채로 남고, 나중에 읽는 쪽이 어느 게 맞는지 알 수 없게 됩니다.
결과 (After)
Before vs After
| 항목 | Before | After |
|------|--------|-------|
| 확정된 규칙 재질문 | 세션마다 반복 | 인덱스 → 권위 문서로 자체 확인 |
| 1,385줄 결정 문서 | 통째로 읽거나 안 읽거나 | 키워드 → 해당 줄만 열람 |
| 지식 형태 | 긴 문서에 뒤섞임 | 한 파일 = 한 사실 + 한 줄 인덱스 |
| 결정 이력 | 덮어써져서 이유가 사라짐 | 추가만 — "왜 그렇게 정했는지" 보존 |
| 실수 | 사람 기억에만 남음 | "반복해서 밟은 지뢰" 목록으로 자산화 |
| 세션 교체 | 배경 설명부터 다시 | 진입점 문서 1장으로 이어서 시작 |
결과물
- 유형이 붙은 단일 사실 메모리 30여 개 + 한 줄 인덱스
- 결정 기록(43건)과 키워드 북마크 인덱스
- 도메인 규칙 통합 권위 문서 ("답하기 전에 먼저 확인")
- "반복해서 밟은 지뢰" 5건이 담긴 재개 진입점 문서
이 과정에서 배운 AI 활용 팁
효과적이었던 것
1. 한 파일에 한 사실. 긴 문서 하나보다 짧은 파일 여러 개가 훨씬 잘 쓰입니다.
2. 인덱스를 따로 두세요. 항상 읽는 건 인덱스, 본문은 필요할 때만. 이게 검색 설계의 핵심입니다.
3. 큰 문서는 줄이지 말고 북마크를 만드세요. "이 키워드는 몇 번째 줄"만 있어도 전문을 안 읽어도 됩니다.
4. 지식에 '왜'를 같이 적으세요. 결론만 적힌 지식은 상황이 달라지면 못 씁니다.
5. "재질문 금지"처럼 행동을 지정하는 표현을 인덱스에 넣으세요. 물어보기 전에 문서를 열게 됩니다.
6. 실수 목록을 문서로 만드세요. 두 번 반복된 실수는 반드시 세 번째가 있습니다.
7. 회사에 이미 있는 자료부터 뒤지세요. 저는 새로 만든 것보다 이미 있던 원천 자료와 선배들이 만들어 둔 결과물에서 훨씬 많은 걸 얻었습니다. 흩어져 있을 뿐 없는 게 아닙니다.
8. 정답이 있는 자료는 "검산용"으로 쓰고 AI에게는 결론만 주세요. 규칙을 추측으로 세우지 않아도 되면서, AI는 답을 외우는 대신 규칙을 배웁니다.
이렇게 하면 안 돼요
1. 지식과 상태를 한 문서에 섞지 마세요. 상태가 낡으면 지식까지 신뢰를 잃습니다.
2. 결정 기록을 수정 하지 마세요. 추가하고 이전 것을 "대체됨"으로 표시하세요. 이유가 사라지면 같은 논의를 또 합니다.
3. 새 사례 하나로 확정된 규칙을 고치지 마세요. 반드시 기존 문서를 먼저 검색하세요.
4. 코드나 이력만 봐도 아는 걸 지식으로 저장하지 마세요. 인덱스만 지저분해집니다.
5. 문서를 더 자세히 쓰는 것으로 해결하려 하지 마세요. 진입 비용을 낮추는 게 먼저입니다.
다른 업무에 적용한다면?
- 사내 규정·업무 매뉴얼: 매뉴얼 본문은 그대로 두고 "상황 → 해당 조항 위치" 인덱스만 따로 만들기
- 고객 응대 지식: 답변 문구가 아니라 판단 기준과 그 이유를 저장하기 (문구는 상황이 바뀌면 못 쓰지만 기준은 살아남습니다)
- 팀 온보딩: "우리 팀이 반복해서 틀렸던 것" 목록을 온보딩 첫 장에 두기
- 회의 결정사항: 덮어쓰지 말고 추가만 하고, 바뀐 결정은 이전 것을 대체 표시하기
앞으로의 계획
- 리뷰 기록 문서가 13,000줄을 넘어서 분할이 필요합니다. 다만 다른 에이전트가 그 파일에 쓰기를 끝낸 뒤에 손대려고 대기 중입니다.
- 지금은 인덱스를 사람이 관리합니다. 지식이 추가될 때 인덱스가 자동으로 따라가게 만들고 싶습니다.
- 도메인 규칙 문서를 실행 담당 에이전트에게 그대로 주입해서, 규칙을 아는 곳과 실행하는 곳을 일치시키는 게 다음 목표입니다.
재사용 가능한 프롬프트
프롬프트 1: 지식 파일 만들기
> 방금 우리가 확정한 내용을 지식 파일로 저장해줘. 규칙은 이래:
> - 한 파일에 한 사실만 담아
> - 맨 위에 이름, 한 줄 요약, 유형(사용자 / 피드백 / 프로젝트 / 참조)을 적어
> - 본문에는 결론뿐 아니라 "왜 이렇게 정했는지"와 "다음에 어떻게 적용할지"를 같이 적어
> - 코드나 변경 이력만 봐도 알 수 있는 건 저장하지 마
> - 저장한 다음 인덱스 파일에 한 줄로 추가해줘
프롬프트 2: 큰 문서를 북마크로 만들기
> [문서명]이 너무 길어서 매번 다 읽을 수가 없어. 이 문서의 인덱스를 만들어줘.
> - 이 문서에 무엇이 몇 개 들어 있는지
> - 어떤 키워드로 찾을 때 몇 번째 줄을 보면 되는지
> - 어떤 작업을 하기 전에 반드시 이 문서를 열어야 하는지
> 인덱스는 짧게. 본문 내용을 인덱스에 복사하지 마.
프롬프트 3: 확정된 규칙을 바꾸려 할 때 (자기 점검)
> 지금 기준 문서의 문장을 고치려고 하는데, 그 전에 확인해줘.
> 이 사안이 이미 다뤄진 적이 있는지 관련 문서 전체를 검색하고, 있으면 그때 어떤 근거로 결론이 났는지 보여줘.
> 지금 내가 본 사례는 표본 하나일 수 있으니, 더 넓은 근거로 내린 기존 결론을 뒤집는 게 맞는지 먼저 판단해줘.
프롬프트 4: 세션 시작 시 (지식 복원)
> 작업 시작 전에 지식부터 복원해줘.
> (1) 인덱스를 읽고 (2) 지금 작업과 관련된 항목만 골라서 본문을 열고 (3) " 반복해서 밟은 지뢰" 목록을 확인해줘.
> 그다음 지금 내 차례가 맞는지, 지금 목표가 뭔지를 한 문단으로 정리해서 알려줘. 기억으로 답하지 말고 문서를 실제로 열어서 확인해.
