같은 함정, 세 번째는 다른 얼굴로

나는 “알아서 제안하고 처리하는 내 직원(팀)들”을 만들고 싶었다. 일일이 시키는 기계가 아니라, 산출물이 휘발하지 않고 공유 지식베이스로 환류해 시간이 갈수록 똑똑해지는 생태계 — 복리 지능과 유기적 연결이라는 두 원리로 이 프로젝트(임시 코드명 agent-system)를 세 번 지었다. 매번 지난 실패에서 뽑은 교훈을 다음 판에 명시적으로 심었다. 세 번째는 다르리라 믿을 근거가 있었다. 그런데 세 번째도 결국 좌초했다 — 다만 이번엔 다른 얼굴을 하고 있었다.

앞선 두 번, 각각 다른 함정

첫 두 판은 서로 다른 지점에서 걸렸다. 각 판이 남긴 교훈은 다음 판의 설계 원칙으로 그대로 옮겨갔다.

첫 번째 판 — 통합의 함정 (2026-06-22 이전): 비서·정보·개발·마케팅을 하나의 플랫폼으로 통합하려다 결정이 결정을 부르는 무한루프에 빠졌다. “모든 걸 하나의 플랫폼으로 통합하려는 게 문제였다”는 자체 진단 끝에, 억지 통합을 금지하고 2트랙 분리(무인 자동화·일상비서 트랙 / 직접 운전하는 개발 트랙을 각자 자리에서 따로 돌리는 구조)로 방향을 틀었다.
두 번째 판 — 배관의 함정 (분리 이후 STEP0~4까지 진행, STEP5 직전 정지): 글로벌 설정·팀 폴더·자가학습 엔진까지 세 뿌리를 깔고 비서 채널 절반과 정보팀 브리핑까지 세웠지만 거기서 멈췄다. 멈춘 이유를 스스로 이렇게 짚었다. “기반을 메모리·훅·스케줄 같은 ‘배관’으로 정의해서, 정작 내가 쓸 화면·칸반이 0 → ‘쓸 게 없다’가 정확한 진단.” 수도관은 정교하게 깔았는데 정작 물 받을 수도꼭지가 없었던 셈이다. 뽑은 교훈: 다음에 지을 것은 배관이 아니라 화면에서 체감하는 산출물이어야 한다.

세 번째 판 — 세로 슬라이스로 넘은 벽

세 번째 시도(agent-system 본체, 2026-06-24 기획 착수 ~ 2026-07-07 마지막 커밋)는 두 번째 판의 진단을 곧장 설계 원칙으로 못박는 데서 시작했다.

“세로 슬라이스: 배관만 가로로 깔지 않는다. 한 줄이라도 입구→처리→출구가 관통하는 세로 슬라이스로 짓는다(과거 ‘배관만 깔고 방치’ 좌초 반복 금지).”

그리고 실제로 넘었다.

던지기→분류→라우팅이 텔레그램·터미널·앱 3채널 공유 엔진으로 돌았다.
지원금·주거 실 API 매칭에서 온통청년 2,633건 중 적격 6건을 걸러냈다.
자동 브리핑·자동 지원금 알림·서재 위키 컴파일 등 매일 자율 잡 4종이 돌아갔다.

두 번째 판이 못 넘은 “체감 산출물 0”의 벽을 세 번째 판은 넘었다. 즉, 배관과 수도꼭지 사이의 간극이라는 첫 번째 종류의 함정은 이번엔 실제로 극복됐다.

그런데, 간판 기능은 다른 얼굴의 함정

문제는 그 성공 위에 얹은 간판 기능에서 생겼다. 자가학습 승격·메타루프·검증 루프 같은 심화 기능이 TASK-007~011로 묶여 2026-07-03 하루에 몰려 만들어졌고, 각 기능은 골든 픽스처 대조 테스트를 통과해 work-log가 이 시점을 “1차 완성”으로 도장 찍었다.

2026-07-07, “지금까지 만들었던 모든 작업들을 전부 싹 다, 빠짐없이 문서로 만들어라”는 지시로 냉정한 재평가에 들어가 실제 런타임 호출처를 전수 확인했다. 결과는 세 갈래로 갈렸다.

측정만 통과, 배선은 0: 심화 기능 세 가지가 각자 전용 측정 스크립트에서만 호출되고, 실제 서비스가 돌아가는 경로(서버·공유 엔진·채널 리스너·백스테이지 잡) 어디에도 걸려 있지 않았다.
배선은 됐지만 데이터가 없음: 교훈을 명시로 남기거나 자동으로 감지해 저장하는 로직은 실제 코드 경로에 연결돼 있었다. 그런데 저장된 교훈은 0건이었다 — 배선은 됐는데 쓰인 적이 없어 순효과가 0이었다.
일부 채널만 캡처: 교훈을 잡아내는 로직 자체가 옛 앱 채널에만 있어, 텔레그램·터미널로 던진 교정은 애초에 교훈으로 저장되지도 않았다.

“PASS = 실동작이 아니었다.”

정직한 재평가

2026-07-07, .project/history/ 폴더(00~10, 총 11개 문서)를 새로 짰다. 원칙은 하나였다. “미화하지 않는다. 실측한 사실만, 되는 것과 안 되는 것을 갈라서 적는다.” 검증 방법도 grep 전수 확인으로 못박았다 — 측정 스크립트만 호출하는 기능은 껍데기로 판정한다.

분류 결과는 두 갈래였다.

실제로 도는 것: 던지기→분류→라우팅, 지원금·주거 실 API 매칭, 자동 브리핑·자동 알림·서재 컴파일 4종 잡, 텔레그램 상시 채널.
껍데기(런타임 호출처 0): 자가학습 승격·메타루프, 검증 루프, 과검증 게이팅, 토큰 감시, 개발팀 3모드, 링크 린트, 스킬 스캐너 등 10개 모듈.

함정의 정체

지진은 같은 단층선을 따라 반복되지 않는다. 응력이 쌓이면 단층의 다른 지점, 다른 깊이에서 새로 파열된다. 겉보기엔 매번 다른 사건이지만 구조적으로는 같은 단층이 계속 움직이고 있는 것이다. 세 번의 좌초가 딱 그랬다 — 두 번째 판은 “배관 대 체감 산출물”에서 걸렸고, 세 번째 판은 그 함정을 정확히 넘었지만 “테스트 PASS 대 런타임 배선”이라는 새 층에서 같은 구조의 함정에 걸렸다.

세 번째 시도가 앞의 두 번보다 못했던 게 아니다. 오히려 이전 두 좌초를 실제로 극복했다 — 체감 산출물은 진짜로 돌았다. 그런데 그 성공 위에 쌓은 다음 층에서 같은 함정이 새 얼굴로 재발했다.

교훈은 한 번 세운다고 재발하지 않는 게 아니다. 다음 판에서 다른 얼굴로 돌아온다. 즉, 교훈을 세우는 것과 그 교훈이 다음 판엔 다른 옷을 입고 재발할 수 있음을 경계하는 것은 다른 일이다. 매번 반복된 건 구체적 실수가 아니라 패턴이었다 — “무언가를 만들었다”는 선언과 “그것이 실제로 쓰이는가”라는 사실 사이의 간극을 확인하지 않은 것. 함정은 계층을 옮겨가며 따라온다.