안녕하세요! 주식회사 무쿠일의 iguchi입니다.
AI 사용 자체에 PDCA를 적용해 보기
Java로 작성된 오래된 핵심 시스템을 PHP로 이식하는 프로젝트에서, 단순히 작업을 처리하는 것을 넘어 AI 사용 방식 자체도 개선하고자 스스로 PDCA(Plan-Do-Check-Action) 사이클을 돌려보게 되었습니다.
처음에는 솔직히 'PDCA라고 해도, AI에게 지시를 내리고 수정하게 하는 것으로 끝나는 것 아닌가'라고 생각했습니다. 하지만 실제로 진행해보니, 이는 단순히 '이식 작업의 PDCA'가 아니라 'AI를 어떻게 구동할지라는 레일(즉, 하네스)에 대한 PDCA'라는 이야기로 바뀌었습니다. 이 글에서는 그 과정에서 발견한 설계상의 핵심 포인트를 정리했습니다.
하네스란 무엇인가요?
여기서 말하는 '하네스'는 AI 에이전트에게 전달하는 지시서, 규칙, 정형 프롬프트(定型プロンプト), 서브 에이전트 설정, 메모리 메커니즘 등을 통칭하는 단어입니다. 구체적으로는 다음과 같은 요소들로 구성됩니다.
- 프로젝트 루트 디렉토리에 배치하는
CLAUDE.md (절대 해서는 안 될 것 / 작업 단계별로 읽어야 할 파일 / 환경 주의사항 / 응답 스타일 등) - 정형 작업을 커맨드화한 부분
skill
(‘조사해라’, ‘설계서에 전개해라’, ‘구현해라’, ‘회고해라’ 등의 내용을 매번 문장으로 설명할 필요가 없게 하는 기능) - 무거운 조사만 전달하는 서브 에이전트
- 세션을 넘나들며 축적되는 영속 메모(Persistent Memory)
이러한 요소들을 개별적으로 사용하는 것이 아니라, 'P (어떤 레일로 구동할지 결정) → D (그 레일에서 실제로 작업 수행) → C (레일이 효과가 있었는지 기록) → A (효과가 없었던 원인을 레일에 추가하여 다음부터 자동으로 적용되게 하기)'라는 하나의 루프(Loop)로 설계하는 것이 이번 주제입니다.
핵심은 Act의 결과물이 반드시 하네스 자체에 반영된다는 점입니다. 단순히 '다음엔 이렇게 주의하자'로 끝내는 것이 아니라, 그 교훈이 문서 한 줄로 기록되어 다음 작업에서는 누가 담당하든 자동으로 누락되지 않게 만드는 것입니다. 이것이 없다면, 같은 함정을 다른 사람이 반복해서 빠지게 됩니다.
회고는 '개인의 성적표'가 되어서는 안 된다
C 단계, 즉 회고 설계에서 가장 주의를 기울인 부분입니다. 회고 양식에는 5가지 지표를 두었습니다.
- 반송 건수 (재작업이 필요한 건수)
판단이 나중에 뒤집힌 건수 (가장 중요한 지표) - 업무 판단 대기로 인해 되돌아간 건수
- 사양에서 벗어나 생성물을 직접 수정해버린 건수 (이상적으로는 0건)
- 하네스 때문에 발생한 사고 건수
이것을 '누가 몇 번 실수했는지'라는 맥락으로 운영하면, 순식간에 기능을 상실하게 됩니다. 솔직히 적으면 자신의 평가가 낮아질 것이라고 생각하기 때문에, 아무도 진실을 쓰지 않게 되기 때문입니다. 0이 나열된 깨끗한 양식은 어떤 가치도 없습니다. 오히려 '여기서 레일이 없었기 때문에 재작업했다'는 기록이야말로 보물입니다.
그래서 운영 규칙으로 '원본 수정은 특정 한 사람에게 일원화한다 (제안은 누구나 가능)'와 '격주 회고에서는
또 하나 실측하고 경악했던 것은, '대용량 파일은 전용 서브 에이전트를 통해 읽는다'라는 규칙을 만들었음에도 불구하고, 97세션 및 21,095요청 동안 그 서브 에이전트의 사용 횟수가 0회였다는 점입니다. 애써 저렴한 모델로 작동하는 조사 전용 에이전트를 준비해 두었는데, 아무도 호출하지 않았습니다.
원인을 찾아보니, 규칙의 작성 방식이 '필요할 때 사용해 주세요'라는 조심스러운 표현이었기 때문에, AI 스스로가 매번 '지금 사용할 타이밍인지'를 꼼꼼하게 망설이다가 결국 사용하지 않고 넘어갔던 것 같았습니다. 그래서 문구를 '이는 상시 유효한 지시이며, 그때그때의 요청을 기다리지 않는다'라는 강한 어조로 수정했습니다. 규칙은 단순히 '사용할 수 있도록 해 두는 것'만으로는 기능하지 않으며, '사용하지 않는 것이 예외'라는 방식으로 작성해야 발동한다는 것을 배웠습니다.
범용 부분과 고유 부분을 분리해 두기
이것은, 만든 하네스(Harness)를 다른 프로젝트에서도 재사용하려고 할 때 피할 수 없었던 작업입니다. 문서를 검토했을 때, 처음에는 '이 파일은 고유 정보라서 통째로 빼낼 수 없다'는 파일 단위의 판단을 내리려고 했습니다. 하지만 실제로 고유한 단어(시스템명이나 프로젝트 특유의 용어)가 포함된 행의 비율을 세어보니, 1%~38%로 파일마다 편차가 있었고, 완전히 고유한 내용만 있는 파일은 극히 일부에 불과했습니다. 즉, 대부분의 문서는 '범용적인 틀(형식)에 고유한 단어가 점재하여 박혀있는' 구조였던 것입니다.
여기에 깨달은 후로는, 파일을 통째로 잘라내거나 빼지 않는다는 생각을 버리고, 내용을 3개 층위로 나누어 생각하게 되었습니다.
- L1: 범용 (금지 사항・근거를 제시하는 자세・도구의 출력을 과신하지 않기 등)
- L2: 업무 방식의 틀(판단 프레임워크・카드화 포맷・회고 지표) → 여기가 사실 가장 큰 자산
- L3: 완전히 고유한 내용 (사내 생성 도구 이름, 특정 파일 명명 규칙 등)
이렇게 정리하니, '다른 프로젝트에 가져갈 때 무엇을 대체해야 하는지'가 명확해집니다. 자산의 본체는 L2이며, L1은 너무 당연해서 누구나 쓸 수 있고, L3는 그 프로젝트에 너무 고유해서 재사용할 수 없습니다. 이 사이에 있는 '그 현장의 방식을 틀로 만든 것'이야말로 시간을 들여 다듬을 가치가 있는 부분이었습니다.
요약
반년 동안 해보면서 가장 크게 배운 것은, 'AI에게 일을 맡긴다'는 말의 내용물이 사실은 'AI에게 어떤 레일을 깔아줄 것인가'라는 설계 문제였다는 것입니다. 지시하는 방식을 그때그때 고안해내는 것이 아니라,
- 레일을 명문화하기 (CLAUDE.md, 스킬)
- 실측하여 레일이 효과가 있었는지 확인하기 (회고표, 비용 측정)
- 효과가 없었던 원인을 레일 자체에 추가하기
- 범용적인 부분과 고유한 부분을 나누어 자산으로 키워나가는
이 루프를 계속 돌려야만 '교훈이 개인의 머릿속에만 남는' 상태에서 벗어날 수 있습니다. 지루한 작업이지만, 이것을 할 수 있게 되면 AI 에이전트의 정확도는 날마다 올라갑니다. 반대로 이것을 게을리하면, 같은 실패를 매번 다른 담당자・다른 세션이 계속 겪게 될 것입니다.
Discussion
