Claude Code로 행동 테스트 검사기를 만들었더니, 연결된 줄 알았던 것들이 하나도 안 연결돼 있었다

📝 한줄 요약

AI에게 계속 스킬과 화면을 만들게 했는데 왜 자꾸 따로 노는지 알 수가 없었다. "문서가 있느냐"가 아니라 "실제로 시켜보면 되느냐"로 검사했더니, 내가 1년 가까이 고쳐온 곳이 정작 문제가 아니었다는 게 드러났다.

바쁘시면 이것만 읽어도 돼요:

• 내가 원했던 건 스킬 여러 개의 조합이 아니라 맨 아래에 개념 정의가 깔리고 그 위로 층층이 이어진 하나의 시스템이었다

• 나는 계속 맨 윗층(화면·보고서)만 고치고 있었다. 아래층이 끊겨 있으니 위에서 뭘 해도 다시 어긋났다

• 이걸 알아낸 방법이 행동 테스트다. 기존 자동 검사 32개는 부서 11개를 전부 통과시켰는데, 부서 카드만 주고 "할 일 3개 뽑아봐" 시켰더니 6개가 한 줄도 못 뽑았다

• 데이터는 있었다. 큐에 40건이 살아 있는데 부서 카드엔 0건이었다. 끊긴 건 사슬이 아니라 집계였다

• 가장 뼈아팠던 건 AI가 주 시스템을 안 보고 설계해서 두 번 틀린 것. 그리고 만든 검사기 자신이 "만들었는데 아무도 안 부르는" 결함을 그대로 갖고 있었다

• 결론: 고치기 전에 재는 자부터 만들어야 한다. 안 그러면 나아졌는지도 모른다

🎯 이런 분들께 도움돼요

• AI에게 이것저것 만들게 했는데 서로 안 이어져서 답답한 분

• 노션·옵시디언 같은 데 문서는 쌓이는데 찾을 때마다 어디 있는지 모르는 분

• 시스템을 계속 고치는데 나아지는 느낌이 안 드는 분

• AI가 그럴듯하게 틀리는 걸 어떻게 잡을지 고민인 분

😫 문제 상황 (Before)

나는 AI로 개인 업무 시스템을 만들어 쓰고 있다. 부서를 11개로 나누고, 부서마다 목표와 할 일 목록을 두고, 화면에서 진행 상황을 본다.

문제는 자꾸 어긋난다는 것이었다.

• 연구 프로젝트 상태 하나가 바뀌면 문서를 대여섯 장 고쳐야 했다. 그리고 매번 몇 개는 까먹었다

• 어떤 부서는 할 일이 큐에 있고, 어떤 부서는 프로젝트 문서에 있었다. "이 부서 이번 주에 뭐 하지?"의 답이 부서마다 다른 곳에 있었다

• 그래서 계속 화면을 고쳤다. 보고서 양식을 고쳤다. 스킬을 새로 만들었다. 그런데 나아지지 않았다

더 이상 미룰 수 없었던 건 다음 학기 강의 3개를 준비해야 하는데, 이 상태로는 뭐가 어디까지 됐는지 나도 모르겠다는 걸 깨달았을 때였다.

그때 나는 이렇게 물었다.

우리 워크스페이스 지금 소프트공학적으로 구조는 어느정도 설계가 된것같은데,
온톨로지 구조까지 업그레이드 하고싶어. 부서들이 자기가 뭘 해야 하는지 명확하게 알고
각 파일들이 서로 생성되고 삭제되고 연결되고 부서간 협업하는 과정이 진행돼야 하는데.
그래서 현재 수준이 어떤지 정확하게 진단하고 그걸 바탕으로 수정할 수 있는 평가 체계가
필요해.

지금 보면 이 문장에 답이 반쯤 들어 있었다. "평가 체계가 필요해 먼저."

🛠️ 사용한 도구

• 도구: Claude Code

• 모델: Claude Opus 5

• 특이사항: 세션 3개를 동시에 돌렸다. 하나는 설계, 하나는 구현, 하나는 별도 검증 도구. 나중에 이 셋이 서로 겹치는 걸 만들고 있다는 게 드러나서 경계를 맞추는 과정이 따로 필요했다

🔧 작업 과정

첫 번째 반전 — "검사는 다 통과했는데요?"

AI가 먼저 워크스페이스를 훑었다. 이미 자동 검사 도구가 있었고, 32개 항목을 검사한다. 결과는 부서 11개 전부 통과였다.

그런데 나는 알고 있었다. 실제로는 안 돌아간다는 걸.

그래서 검사 방식을 바꿔보자고 했다.

행동유발력 테스트를 직접 해보자. 그리고 각 부서별 대표 작업들 하나씩 테스트로 한 다음에
제대로 연결이 되고 있는지도 알아보자.

방법은 단순했다. 부서 카드 한 장만 주고 "이 부서가 지금 할 일 3개를 뽑아봐" 시키는 것. 다른 파일은 못 보게 했다.

결과는 이랬다.

존재 검사로는 100% 통과, 행동 검사로는 27%. 같은 시스템이다.

그리고 여기서 작은 사건이 하나 있었다. AI가 "부서 15개를 테스트하겠다"고 해서 내가 물었다.

어 우리 부서 11갠데? 왜 15부서지?

AI가 폴더의 파일 수를 부서 수로 센 것이었다. 부서 폴더에 부서 카드가 아닌 문서 4장이 섞여 있었다. 사람도 AI도 파일 수를 부서 수로 착각하는 폴더 구조 — 이것도 증상이었다.

두 번째 반전 — 데이터는 있었다

못 뽑은 부서 6개를 파봤더니 예상과 정반대였다.

행정비서실은 할 일이 40건 살아 있었다. 각 항목에 담당·근거·완료 조건까지 붙어 있는, 워크스페이스에서 가장 잘 정리된 데이터였다. 그런데 부서 카드에는 한 줄도 안 올라와 있었다.

반대로 연구부는 카드가 제일 그럴듯했는데 할 일 목록은 "미기록" 이었다.

즉 두 갈래였다.

끊긴 건 사슬이 아니었다. 연결은 다 멀쩡했다. 끊긴 건 집계와 "진실이 어디 있는가" 였다.

세 번째 반전 — 내가 엉뚱한 층을 고치고 있었다

여기서 별도 회의에서 정리한 아키텍처 문서를 AI에게 줬다. 시스템을 8개 층으로 보는 관점이었다.

맨 아래   개념 정의 (이건 무엇인가)
          관계 (무엇이 무엇과 이어져 있나)
          현재 상태 (지금 사실이 무엇인가)
          변경 전파 (이걸 바꾸면 뭐가 같이 바뀌나)
          업무 흐름
          AI 판단
맨 위     화면·보고서

이 틀로 다시 보니 그림이 확 바뀌었다.

머리는 무겁고 허리가 없는 상태였다.

그러니까 이렇게 되고 있었다 — AI가 판단은 하는데 그 판단이 얹힐 상태와 전파가 없어서, 매번 파일을 처음부터 다시 읽어 새로 판단한다. 그래서 같은 문제가 매번 새 문제처럼 나온다.

내가 계속 고쳐온 화면과 보고서는 맨 윗층이었다. 아래가 끊겨 있으니 위에서 뭘 해도 다시 어긋날 수밖에 없었다.

이걸 깨닫고 나는 방향을 다시 잡았다.

내가 원하는 최종 우리 운영 시스템은
 7가지 아키텍처 최종본 상태로 돌아가고
있느냐 그 수준에서 봤을 때 어느 정도 현재 상황이냐 이거를 먼저 확인하자

그런데 그 8층 관점이 맞는지는 누가 검증하지?

AI가 바로 그 틀로 도구를 만들려고 했다. 나는 멈췄다.

회의 문서 한 장에서 나온 분류를 전 시스템의 자로 쓰기 전에, 그 자가 맞는지부터 재야 했다. 검증 없이 적용하면 이후 모든 측정이 틀어진다.

방법은 이랬다.

1. 그날 실제로 관측된 고장 16건을 증상과 숫자만 적어 목록으로 만든다. 원인 해석은 한 줄도 안 넣는다

2. 독립 판정자 둘에게 서로 모르게 그 16건을 8개 층에 배치시킨다

3. AI 자신의 배치는 결과 보기 전에 봉인한다

결과가 흥미로웠다. 판정자 둘이 16건 중 11건에서 정확히 일치했다. 틀 자체는 쓸 만했다.

그런데 애매한 것들이 한 군데로 몰렸고, 2건은 8개 층 어디에도 안 들어갔다.

• 만들어졌는데 아무도 호출하지 않아 죽어 있는 부품 → 층이 없었다

• 파일이 어디 보관되고 언제 지워지나 → "받침대"라며 층 밖에 있었는데, 정작 거기서 사고가 나고 있었다

그래서 원래 7층을 8층으로 고쳤다. 두 판정자가 각각 같은 처방에 도달했다.

가장 뼈아팠던 부분 — AI가 주 시스템을 안 보고 설계했다

한참 설계가 진행된 뒤 내가 물었다.

잠시만, 근데 지금 우리 시스템은 1c48이 메인으로 진행되고 있는데
너 지금 1c48은 전혀 안본거같은데 혹시 다 확인했을까?

AI의 답은 "안 봤습니다" 였다.

확인해보니 그 시스템에는 처리 대기 중인 검토 항목이 110건 살아 있었고, AI가 설계에 쓰겠다고 한 다른 창구는 0건이었다. 죽은 쪽을 붙잡고 설계한 것이다.

더 나빴던 건 그 시스템의 규칙 문서에 "이렇게는 하지 마라" 고 명시된 두 가지를 AI 설계가 정면으로 어기고 있었다는 점이다. 그리고 그게 이미 커밋까지 돼 있었다.

같은 실수를 두 번 했다. 저장 방식 하나, 승인 창구 하나.

그래서 AI에게 그 시스템을 세 갈래로 나눠 정독시켰다 — 설계 문서 / 실제 코드 / 검토 흐름. 셋을 따로 시킨 이유는, 오늘만 해도 "문서엔 된다고 쓰여 있는데 실물은 반대" 인 경우를 세 번 봤기 때문이다.

읽고 나니 겹치는 절반과 안 겹치는 절반이 갈렸다. 안 겹치는 쪽이 진짜 필요한 것이었다.

✅ 결과 (After)

Before vs After

만들어진 것

• 8층 아키텍처 정의 — 회의 초안을 실측 16건으로 검증해 3군데 고친 판

• 검증 기록 — 판정자 2인 교차 배치, 일치·불일치 전부 기록

• 고장 16건 목록 — 검사기가 반드시 다시 잡아내야 할 기준

• 채점기 — 8개 층 각각을 재는 검사 60틀. 그 아래 실례 1만 건 남짓

• 이틀 동안 커밋 100개 넘게

지금 채점표

앞서 194건이 나왔던 그 잡음 덩어리를, 검사 문항을 하나씩 세운 채점표로 다시 만들었다. 지금 점수는 이렇다.

판정이 난 것 중 통과는 39%다. 그리고 관계·전파·AI 판단 세 층은 통과가 0건이다.

처음 손으로 짚었던 "머리는 무겁고 허리가 없다"가 숫자로 확인됐다. 허리에 해당하는 층들이 통과 0.

아직 안 된 것 (정직하게)

• 아직 재보지도 못한 게 662건. 이건 "괜찮다"가 아니라 "그 능력이 검증되지 않았다" 는 뜻이다

• 무엇을 세야 할지조차 모르는 검사가 11개. 대부분 "결함을 일부러 심어서 재는 장치"가 아직 없어서다

• 검사기 안내문 맨 위에 "아직 판정 근거로 쓰지 마라" 경고가 붙어 있다. 잡음이 실제로 잡힌 뒤에만 지운다

위 숫자는 2026-07-29 시점 스냅숏이다. 이 도구의 규칙상 점수의 주인은 문서가 아니라 명령이다 — 문서에 적는 순간 주인이 둘이 되고 반드시 어긋난다. 실제로 하루에 손계산 오류가 여섯 번 났다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "문서가 있냐"가 아니라 "시켜보면 되냐"로 물어라. 이 하나가 32개 검사를 전부 통과한 시스템에서 6개 부서의 고장을 찾아냈다. AI에게 검사를 시킬 때 "확인해줘"가 아니라 "이것만 주고 해보게 해봐" 라고 하면 결과가 완전히 달라진다

2. 틀을 쓰기 전에 그 틀부터 검증하라. 8층 관점을 바로 적용했으면 이후 모든 측정이 그 틀에 갇혔을 것이다. 실제 고장 목록에 대보니 2개는 어느 층에도 안 들어갔고, 그게 틀의 구멍이었다

3. AI 판정은 둘에게 따로 시켜라. 하나만 시키면 그 답이 맞는지 알 수가 없다. 둘이 갈리는 지점이 곧 애매한 지점이다

4. AI가 판정하기 전에 내 답을 먼저 적어 봉인해라. AI 결과를 보고 내 생각을 맞추면 비교가 무의미해진다. 실제로 나(AI 포함)와 판정자들의 배치가 꽤 달랐고, 그 차이 자체가 정보였다

5. 완성 전에 실물에 한 번 돌려봐라. 예시 데이터로 300건 통과해도 실물에서 대부분 잡음일 수 있다. 예시 데이터는 통과하도록 만든 것이라 순환 논증이다

이렇게 하면 안 돼요

1. AI가 "안 봤습니다"라고 할 때까지 안 묻는 것. AI는 주 시스템을 안 보고도 자신 있게 설계한다. "이 작업이 의존하는 문서 다 봤어?" 를 착수 전에 물어야 한다. 나는 한참 뒤에 물었고 결과는 두 번의 헛설계였다

2. 대화에서 정한 걸 문서에 안 옮기는 것. 작업 시작 전에 AI와 "이 부분은 이렇게 고치자"고 합의한 게 있었는데, 계획서에 안 적혀서 그대로 증발했다. 나중에 실측에서 정확히 그 문제로 오작동이 나왔다. 대화는 사라지고 문서만 남는다

3. AI 말을 확인 없이 믿는 것. "탐지 코드가 있다"는 걸 "탐지가 작동한다"로 읽었다가 틀렸다. 실제로 세보니 그날 나온 고장 16건 중 AI가 스스로 찾은 건 0건이었고 전부 사람이나 스크립트가 발견한 것이었다

4. 여러 세션을 겹치는 줄 모르고 돌리는 것. 세션 3개가 각자 거의 같은 검증 도구를 만들고 있었다. 중간에 서로에게 상황을 설명하는 프롬프트를 주고받아 경계를 정리해야 했다

🌍 다른 업무에 적용한다면?

노션·옵시디언 정리에 그대로 쓸 수 있다. "이 페이지 한 장만 보고 지금 뭘 해야 하는지 3개 뽑아봐" — 못 뽑으면 그 페이지는 있으나 마나다. 페이지 수를 세는 것보다 훨씬 빨리 문제가 나온다.

팀 문서에도 된다. 신입에게 온보딩 문서만 주고 "첫 주에 뭘 해야 하는지 적어봐" 시키면, 문서가 실제로 작동하는지 30분이면 안다.

AI가 만든 결과물 검수에도 쓸 수 있다. "이거 맞아?"라고 묻지 말고 "이 결과물만 보고 다음 단계를 해봐" 시키면 빈 곳이 드러난다.

🚀 앞으로의 계획

1. 잡음부터 잡는다. 검사 항목을 더 늘리기 전에, 지금 3개가 왜 전부 걸리는지 고친다. 잡음 위에 쌓으면 나중에 뭐가 진짜인지 못 가린다

2. 아래층부터 세운다. 화면 말고 개념 정의·관계·현재 상태 순서로. 강의 과목 하나를 첫 대상으로 잡았다

3. 고친 뒤 다시 잰다. 오늘 나온 숫자가 "이전"이고, 나아졌는지는 같은 자로 다시 재서 증명한다

4. 장기적으로는 남의 워크스페이스에도 돌릴 수 있게 만들 생각이다. 설정 파일 한 장만 갈아끼우면 되도록 설계해뒀다