티스토리 뷰
목차
솔직히 저는 꽤 오랫동안 AI가 중간에 딴길로 빠지는 게 순전히 AI 성능 문제라고 생각했습니다. 긴 작업을 맡기면 어느 순간 처음 방향과 전혀 다른 결과물이 나오는 경험을 반복하면서도, "AI가 아직 부족하니까"로 넘겼던 거죠. 그런데 한 개발자가 Claude Code를 활용해 6개월 만에 책 300권 분량의 사내 프로그램을 혼자 재개발하는 데 성공한 사례를 접하고 나서 생각이 완전히 바뀌었습니다. 문제는 AI 자체가 아니라, AI에게 일을 맡기는 방식이었습니다.
자동 매뉴얼 시스템: AI가 지침을 스스로 읽게 만들기
Claude Code에는 '스킬(Skill)' 기능이 있습니다. 여기서 스킬이란 프론트엔드, 백엔드, 데이터베이스처럼 특정 작업 유형에 맞는 업무 매뉴얼을 미리 작성해두면, AI가 관련 작업을 할 때 꺼내 쓸 수 있도록 준비해두는 기능입니다. 제가 처음 이 개념을 접했을 때 "이거면 됐다" 싶었는데, 실제로 AI는 이 매뉴얼을 능동적으로 찾아 읽지 않는다는 게 문제였습니다.
이 문제를 해결하기 위해 활용한 것이 '후크(Hook)' 기능입니다. 후크란 특정 이벤트가 발생했을 때 자동으로 동작하도록 설정해두는 트리거 장치를 의미합니다. 작업 시작 전에 관련 매뉴얼을 자동으로 불러오는 '시작 전 알림 장치'와, 작업이 끝난 뒤 누락된 항목이 없는지 점검하는 '완료 후 체크 장치', 두 가지를 만든 것입니다.
이 장치들이 매뉴얼을 불러올지 판단할 때 사용하는 기준은 키워드, 의도 파악, 작업 위치, 파일 내용 네 가지입니다. 초기에는 하나의 스킬 파일을 1,500줄이 넘도록 만들었는데, 오히려 AI가 소비하는 컨텍스트 윈도우(Context Window) — 쉽게 말해 AI가 한 번에 처리할 수 있는 정보의 최대 용량 — 를 너무 많이 잡아먹는 부작용이 생겼습니다. 그래서 매뉴얼을 간략한 목차 파일과 세부 챕터 파일들로 분리하고, 필요한 챕터만 읽게 구조를 바꿨더니 자원 소비가 40~60% 줄었다고 합니다.
제가 직접 써봤는데, 긴 작업을 하다 보면 AI가 앞서 정한 코딩 규칙을 슬쩍 무시하고 예전 방식으로 돌아가는 경우가 분명히 있습니다. 매뉴얼만 만들어두고 끝내는 게 아니라, 그것을 강제로 읽게 만드는 장치를 따로 둬야 한다는 게 이 시스템의 핵심입니다.
- 스킬(Skill) 기능으로 작업 유형별 매뉴얼 사전 작성
- 후크(Hook)로 시작 전 자동 불러오기 + 완료 후 자동 점검 설정
- 매뉴얼을 목차 + 챕터 파일로 분리해 컨텍스트 윈도우 절감
작업 기억 시스템: 금붕어 기억력을 외부 문서로 보완하기
AI의 기억력 문제는 제가 직접 겪으면서 가장 답답했던 부분이기도 합니다. 대화가 30분만 길어져도 처음에 정한 방향이 흐릿해지고, 이미 끝낸 작업을 다시 반복하거나 앞서 정한 규칙을 슬쩍 무시하는 일이 생겼습니다. AI 자체의 한계라고만 생각했는데, 이를 '외부 기억 장치'로 보완하는 방법이 있었습니다.
큰 작업을 시작할 때 세 가지 문서를 먼저 만드는 것입니다. 계획서(무엇을 만들지 처음부터 끝까지 적은 설계도), 맥락 노트(왜 그렇게 결정했는지, 참고 자료 위치를 적은 기록), 할 일 체크리스트(완료 항목과 잔여 항목을 추적하는 공정표). AI는 대화가 길어져 기억을 잃더라도 이 문서들을 읽으면 현재 상황을 즉시 파악할 수 있습니다.
여기서 제가 특히 인상 깊었던 팁이 있습니다. 계획을 승인한 뒤 AI에게 바로 작업을 시작하게 하지 않는 것입니다. "잠깐, 먼저 이 계획을 문서로 저장해. 그다음 새로운 대화를 열어서 저장된 문서 읽고 이어서 작업해"라고 지시하는 방식입니다. 이렇게 하면 새 대화가 시작되더라도 AI가 문서를 읽고 맥락을 이어받기 때문에, 기억이 초기화되는 문제를 구조적으로 차단할 수 있습니다.
또 한 번에 열 가지를 다 시키는 대신, 한두 가지 작업만 지시하고 결과를 확인한 뒤 다음 작업으로 넘어가는 방식도 중요합니다. 중간중간 체크리스트를 업데이트하게 하면 AI가 길을 잃는 빈도가 눈에 띄게 줄어든다고 합니다. 제 경험상 이건 정말 효과가 있었습니다. 작업 단위를 잘게 나눌수록 오류가 눈에 잘 띄고, 수정 범위도 좁아집니다.
품질 검사 시스템: "다 했습니다" 뒤에 숨은 실수 잡기
AI가 "완료했습니다"라고 말할 때 실제로 실수가 없는 경우는 생각보다 드뭅니다. 솔직히 이건 예상 밖이었습니다. 처음에는 AI가 완료 보고를 하면 대충 맞겠거니 하고 넘겼는데, 나중에 보면 오류 처리가 빠졌거나 보안 확인을 건너뛴 경우가 꽤 있었습니다.
이 문제를 해결하기 위한 것이 자동 품질 검사 시스템입니다. 우선 '수정 기록 장치'는 AI가 파일을 고칠 때마다 어떤 파일을 수정했는지 자동으로 로깅(Logging)합니다. 로깅이란 시스템이 수행한 작업 내역을 시간 순서대로 자동 기록하는 것을 말합니다. 파일이 수정될 때마다 즉시 검사하는 방식은 작업 중간에 불안정한 상태를 검사하게 되는 문제가 있어, '완료 후 검사 장치'를 따로 두는 방식으로 변경했습니다.
완료 후 검사 장치는 AI가 작업을 완전히 끝냈다고 선언하는 시점에 자동으로 검사를 시작합니다. 수정 내역을 확인하고, 오류가 발견되면 AI에게 즉시 수정을 지시합니다. 오류가 많을 경우에는 해당 분야 전문 에이전트(Agent)를 투입하도록 추천하는 구조입니다. 에이전트란 특정 역할을 부여받아 독립적으로 판단하고 행동하는 AI 단위를 말합니다.
추가로 '셀프 체크 리마인더'도 활용합니다. 작업이 끝나면 자동으로 "오류 처리는 추가했나요? 보안상 위험한 부분은 없나요?"라는 알림을 띄워 AI 스스로 보완하게 만드는 방식입니다. 이 시스템 도입 후 AI가 실수를 남기고 넘어간 적이 단 한 번도 없었다는 사례 보고는(출처: Reddit r/ClaudeAI) 과장처럼 보일 수 있지만, 검사 장치가 오류를 잡아내고 AI가 즉시 수정하는 흐름이 정착되면 충분히 납득이 가는 결과입니다.
전문 에이전트 활용: 역할 분담이 결과물의 질을 바꾼다
하나의 AI에게 기획, 개발, 검수를 전부 맡기는 방식은 한 사람이 설계부터 시공, 감리까지 혼자 하는 것과 비슷합니다. 어딘가 구멍이 생길 수밖에 없습니다. 이 시스템에서는 작업 AI가 만든 결과물을 별도의 코드 리뷰 전담 AI가 검토하도록 역할을 나눕니다. 여기서 코드 리뷰란 작성된 코드가 오류, 보안 취약점, 일관성 문제 등이 없는지 제3자의 시각으로 점검하는 과정을 말합니다.
핵심은 이 전문 에이전트들에게 단순히 "검토해줘"가 아니라, 구체적인 보고서를 작성하도록 지시하는 것입니다. "무엇을 발견했고, 무엇을 수정했고, 왜 그렇게 판단했는지"를 보고서 형태로 남기게 하면 모호한 검토 결과가 나오는 것을 막을 수 있습니다. 제 경험상 AI에게 보고서 형식을 강제하는 것만으로도 결과물의 구체성이 눈에 띄게 달라졌습니다.
AI의 프롬프트 엔지니어링(Prompt Engineering) 관점에서 보면, 이 방식은 역할을 세분화할수록 각 역할에서 더 정밀한 출력을 이끌어낼 수 있다는 원리와 맞닿아 있습니다. 프롬프트 엔지니어링이란 AI에게 원하는 결과를 얻기 위해 입력 지시문을 설계하고 최적화하는 기법을 의미합니다. Anthropic의 공식 문서에서도 역할 부여와 구체적 출력 형식 지정이 결과 품질을 높이는 핵심 요소로 언급됩니다(출처: Anthropic Prompt Engineering Overview).
다만 이 지점에서 한 가지 짚고 싶은 게 있습니다. AI가 AI를 검수하는 구조는 효율적이지만, 두 AI가 같은 종류의 오류를 공유할 가능성도 있습니다. 때문에 중요한 최종 결과물만큼은 사람이 직접 확인하는 단계를 유지하는 것이 맞다고 생각합니다. 시스템이 아무리 정교해도 인간의 최종 판단을 대체할 수는 없습니다.
자주 묻는 질문
Q. Claude Code 말고 ChatGPT나 다른 AI에도 이 시스템을 적용할 수 있나요?
A. 후크나 스킬 같은 기능은 Claude Code 고유의 명칭이지만, 시스템의 핵심 원리인 매뉴얼 강제 참조, 외부 기억 문서 활용, 완료 후 검수는 어떤 AI 도구에서도 운영 방식으로 적용할 수 있습니다. 도구가 달라도 프롬프트와 작업 흐름 설계로 비슷한 효과를 낼 수 있습니다.
Q. 매뉴얼이나 체크리스트 문서를 만드는 데 시간이 너무 많이 걸리지 않나요?
A. 초기 설정에 시간이 드는 것은 사실입니다. 실제로 이 사례에서도 자동 매뉴얼 시스템 구축에만 이틀이 걸렸다고 합니다. 다만 단순하고 반복되지 않는 작업이라면 굳이 이 시스템 전체를 적용할 필요는 없고, 규모 있는 장기 프로젝트에 도입할 때 투자 대비 효과가 큽니다.
Q. AI가 품질 검사까지 하면 사람이 따로 확인 안 해도 되나요?
A. 아닙니다. AI끼리 검수하는 구조는 효율을 높이지만, 검수하는 AI 역시 같은 유형의 오류를 놓칠 수 있습니다. 특히 비즈니스 판단이나 보안 이슈가 걸린 결과물은 반드시 사람이 최종 확인하는 단계를 남겨두는 것이 안전합니다.
Q. 개발자가 아닌 일반인도 이 방식을 활용할 수 있나요?
A. 코딩이 아닌 작업에도 충분히 적용됩니다. 긴 글 작성, 데이터 정리, 기획 문서 작성처럼 여러 단계가 필요한 작업이라면 계획서와 체크리스트를 먼저 만들고 단계별로 진행하는 방식은 AI를 쓰는 누구에게나 유효합니다.
결론
이번 사례를 보면서 정리된 생각은 하나입니다. AI를 잘 활용한다는 것은 좋은 질문 하나를 만드는 게 아니라, AI가 작업을 시작해서 검수까지 마칠 수 있도록 전체 흐름을 설계하는 것이라는 점입니다. AI는 그냥 쓰면 50점이지만, 시스템을 만들어주면 95점이 된다는 표현이 과장처럼 들릴 수 있는데, 제 경험상 방향이 완전히 틀린 말은 아닙니다.
다만 한 가지는 덧붙이고 싶습니다. 시스템이 복잡해질수록 관리하는 사람의 부담도 커진다는 점입니다. 모든 작업에 후크, 에이전트, 체크리스트를 다 붙이면 오히려 사람이 해야 할 일이 늘어납니다. 작업의 규모와 반복성에 맞게 어느 수준까지 자동화할지를 판단하는 것, 그것도 결국 사람의 몫입니다. 저라면 앞으로 큰 프로젝트를 시작할 때 계획서와 체크리스트 문서를 먼저 만드는 것부터 천천히 습관으로 들여보려 합니다.