본문으로 건너뛰기

톡브릿지, 데밍의 PDSA 루프를 품다 — 제품의 정원에서 처음 돈 신뢰성의 물레방아

담장 안, 나란한 두 정원 — 왼쪽은 원탁과 게시판 액자가 있는 익숙한 글쓰기 정원, 오른쪽은 새로 자란 제품 정원에서 작은 물레방아가 힘차게 돌고, 두 화단 사이에 나무다리가 놓여 있다. 정원지기가 다리 위에 서서 양쪽을 본다

3줄 요약 • 한 글쓰기 팀이 AI 에이전트를 부리는 틀(하네스, 이 시리즈의 말로는 정원)을 만들어 써 온 지 석 달. 같은 틀로 심은 두 번째 정원이 담장 안에서 자라 제품을 출시했다. 이름은 톡브릿지. 6월에 정원지기 혼자로 시작해 석 달 만에 전문가 스무 명과 물길(워크플로우) 일곱 개를 갖췄고, 9월 1일 운영을 열었다. • 글쓰기 정원에서는 삐걱이던 신뢰성의 물레방아(출시 뒤 고장에서 배우는 순환)가 제품의 정원에서는 돈다. 출시 준비의 QA(품질 보증) 검수에 장치 둘을 달았기 때문이다. 세 원천을 로컬에서 맞대는 로컬퍼스트 검증, 그리고 데밍의 PDSA(Plan-Do-Study-Act)를 그래프로 구현한 CLI(명령줄 인터페이스) 도구 pdsa. • 서른다섯 바퀴를 돌고 남은 것은 세 문장이다. 기대를 먼저 못박아야 판정이 성립한다. 충족률이 80%에서 61%로 내려간 것이 지표가 정직해진 증거였다. 계측기도 정원의 일부라서, 도구가 원인인 실패가 세 번 났다.

이 편의 낱말 여덟 • 하네스(이 시리즈의 은유로 '정원') — AI 에이전트에게 일을 시키는 틀. 도메인 지식(햇빛), 전문가 역할(꽃), 워크플로우(물길)의 세 겹으로 이루어진다. • 에이전트(꽃) — 하나의 역할을 맡은 AI 전문가. 문서 검토관, QA 장인처럼 이름과 절차를 갖는다. 정원지기는 그들을 배치하는 관리인이다. • 워크플로우(물길) — 에이전트들이 일하는 순서. 수문은 그 물길의 통과 기준이다. • 피드백 루프(물레방아) — 결과가 다음 판단으로 되돌아오는 순환. • 루프 엔지니어링 — 한 번 시키고 끝이 아니라, 결과에서 배워 다음 회차를 바꾸도록 설계하는 일. • QA(품질 보증) — 출시 전 제품이 설계대로 동작하는지 검증하는 일. 발견한 문제 한 건이 티켓, 고쳤다고 닫혔다가 다시 올라오면 재오픈. • 사이클 — 티켓 한 장을 계획 → 수행 → 판정 → 학습으로 돌리는 한 바퀴. • 씨앗 글 — 이 편을 쓰기 위해 먼저 써 둔 조사 글.

1. 담장 이쪽에서 자란 두 번째 정원​

이 시리즈는 한 글쓰기 팀이 AI 에이전트를 부리는 틀, 우리 말로는 정원을 만들어 써 온 기록이다. 앞선 세 편(17편, 18편, 19편)은 담장 너머를 돌았다. 다른 회사, 다른 방법론을 들여다보며 계속 같은 걸 물었다. 글쓰기의 정원이 제품의 정원이 되려면 뭐가 더 있어야 하나.

그런데 솔직히 적어야 할 게 있다. 그 질문을 던지는 동안 담장 이쪽에서 답이 이미 자라고 있었다. 이 정원을 심은 것과 같은 씨앗, 같은 카카시 하네스 플러그인, 같은 세 겹 토양, 같은 정원지기로 2026년 6월 8일에 심은 두 번째 정원이 있다. 이름은 톡브릿지(TalkBridge). 첫날엔 정원지기 혼자였다. 같은 날 전문가 다섯을 들였고, 석 달이 지난 지금은 스무 명에 워크플로우 일곱 개다. 그리고 9월 1일, 제품을 출시했다.

그래서 이번 편은 답사가 아니다. 실전기다. 두 번째 정원이 출시 직전 열흘 동안 무엇을 어떻게 돌렸는지를 정원 일지에서 그대로 옮긴다. 다 옮기지는 않고 한 바퀴만 본다. 출시 뒤 쏟아지는 고장, 재현, 재발의 신호에서 배우는 신뢰성 루프(관측 → 완화 → 근본 원인 → 재발 방지). 19편에서 우리는 이 글쓰기 정원의 그 바퀴를 두고 "장치는 있는데 신호가 드물어서 삐걱이며 돈다"고 적었다. 제품은 다르다. 신호가 넘친다. 그 바퀴에 무엇을 달았는지가 이 편의 본문이다.

에이전트가 고친 것을 QA가 다시 재현하는 왕복이 끝나지 않는 팀, 로그는 쌓이는데 같은 화면을 또 고치고 있는 팀이라면, 이 편은 그 팀의 정원 일지다.

씨앗은 이번에도 책상에서 줍지 않았다. 이 편을 위해 같은 컨셉으로 먼저 써 둔 글이 있다. 데밍의 PDSA, 루프엔지니어링이 되다 — pdsa CLI와 22번의 자기개선 사이클. 도구 하나를 소개하는 글이면서, 그 도구가 자기 자신을 만드는 데 쓴 스물두 번의 사이클 기록이기도 하다. 이 편은 그 도구가 처음으로 남의 정원의 출시를 계측한 기록이니 둘은 짝이다.

시리즈 독자에게 하는 정직 고지도 이어 간다. 17편이 예고한 "스킬 내장 Eval(평가, evaluation) 장착 실전기", 그러니까 에이전트의 작업 절차 안에 평가를 심는 이야기는 이번에도 아니다. 다만 14편이 그린 설계도의 마지막 조각, 판정을 학습으로 바꾸는 Study 센서가 처음 실물이 된 기록이긴 하다. 약속의 첫 분납이라고 해 두자.

2. 먼저, 데밍의 PDSA — 품질은 검사가 아니라 학습이다​

정원 한켠의 낡은 칠판 — 네 칸 사이클이 그려져 있고, 세 번째 칸의 낱말 하나가 지워진 자리 위에 새 낱말이 동그라미로 강조되어 있다. 안경을 쓴 나이 든 정원지기 꽃이 분필을 들고 있고, 어린 꽃들이 둘러앉아 있다

본문으로 들어가기 전에 한 장을 쓴다. 이 편의 척추인 PDSA가 어디서 왔는지. 데밍을 이미 아는 독자는 3절로 건너뛰어도 좋고, 더 깊은 고증은 14편에 있다. 여기서는 씨앗 글의 고증을 그대로 옮긴다. 70년 전 품질공학자가 고집했던 단어 하나가 AI 에이전트의 장기 메모리 설계에 그대로 다시 등장하는 이야기다.

1920~30년대 벨연구소의 월터 슈와트(Walter A. Shewhart)는 통계적 품질관리와 함께, 훗날 "슈와트 사이클"로 불리는 반복 개선 루프를 정립했다. 그의 전환점은 단순했다. 라인 끝에서 불량을 검사(inspection)로 걸러내는 게 아니라, 생산 과정 자체가 균일한 결과를 내도록 만든다는 것. W. 에드워즈 데밍(W. Edwards Deming)은 1930년대 슈와트와 함께 연구하며 이를 현장 통계에서 경영 전반의 철학으로 밀고 나갔다. PDSA는 슈와트 사이클을 데밍이 다듬은 직계 후손이다.

품질을 뒷전에 두면 어떤 청구서가 돌아오는지 보여주는 가장 선명한 반면교사가 1983년 북미 비디오게임 크래시다. 무허가 개발사의 저품질 게임이 시장에 범람했고, 가정용 비디오게임 매출은 약 32억 달러(1983)에서 약 1억 달러(1985)로 거의 97% 폭락했다. 그 시대의 상징이 아타리의 E.T.(1982)다. 약 5~6주 만에 졸속 개발돼 500만 개를 찍었지만 150만 개만 팔렸고, 남은 카트리지 약 80만 개가 뉴멕시코 앨러머고도 매립지에 묻혔다. 오랫동안 도시전설로 치부되다 2014년 실제로 발굴됐다. 죽은 시장을 되살린 것도 품질이었다. 닌텐도는 NES(Nintendo Entertainment System, 1985)를 내며 Seal of Quality(품질 인증 도장)와 라이선스 락아웃 칩(10NES)으로 출시 관문을 강제했다. 전략은 "적게, 더 좋게(fewer, better games)". 통제 없는 물량이 신뢰를 무너뜨린 자리를, 강제된 품질이 다시 세웠다.

데밍은 일본과학기술연맹(JUSE)의 초청으로 1950년 7월 일본에 도착해 통계적 공정관리와 경영 철학을 함께 가르쳤다. 도요타는 1961년 전사적 품질관리를 도입하고 1965년 데밍상을 수상했으며, 그 원칙들은 도요타 생산방식(TPS)의 철학적 토대 일부가 됐다. 물론 TPS는 오노 다이이치와 도요다 가문의 공로이기도 하고, 일본 산업 부상에는 여러 동력이 있었다. 품질은 주요 요인이지 유일한 요인은 아니다. 품질 이론은 미국에서 태어났지만 먼저, 가장 온전히 실천한 곳은 일본이었다. 미국이 다시 배우기 시작한 계기로 흔히 꼽히는 것이 1980년 6월 NBC의 다큐멘터리 「If Japan Can... Why Can't We?」다(통설과 달리 BBC가 아니라 NBC다). 이후 말콤 볼드리지 국가품질상(1987), 유럽의 EFQM(유럽품질경영재단, 1991)이 일본의 데밍상을 본떠 만들어졌다.

가장 중요한 대목은 마지막 정정이다. 이 사이클은 흔히 PDCA(Plan-Do-Check-Act)로 가르쳐지지만, 데밍 본인은 1986년 청중 앞에서 이 버전이 정확하지 않다고 경고했다. 이유가 인상적이다. 영어에서 "check"는 "멈춰 세우다(hold back)"를 뜻한다는 것. 서신에서는 더 단호했다. "반드시 PDSA로 불러라, 변질된(corruption) PDCA가 아니라." 그가 고집한 것은 세 번째 단계를 Study로 둔 PDSA(Plan-Do-Study-Act)다. 단어 하나를 붙든 트집처럼 보일 수 있다. 그런데 뜯어볼수록 이 고찰이 놀랍다. 체크는 말 그대로 정지 동작이다. 판정이 나는 순간 활동이 끝난다. 통과면 다음 물량으로, 실패면 반려로. 어느 쪽이든 다음 공정을 개선하는 데 필요한 활동은 거기서 일어나지 않는다. 체크가 무의미하다는 말이 아니다. 체크만 해서는 루프가 돌지 않고 그 자리에 멈춘다는 것이다. 루프를 다음 회차로 굴리려면 판정 위에 학습이 얹혀야 한다.

PDCA (Check)PDSA (Study)
3단계의 질문통과했나?무엇을 배웠나?
지향구현 검증(성공/실패)예측 → 실측 관찰 → 비교 → 이론 수정
변동(variation)흔히 무시변동의 원인을 탐구
루프의 목적규격 준수공정 자체를 개선하는 학습

PDCA는 "됐나?"를 묻고, PDSA는 "무엇을 배웠고, 그로써 이론을 어떻게 바꿔야 하나?"를 묻는다. 여러 사이클에 걸쳐 지식이 복리로 쌓이게 만드는 것은 두 번째 질문이다.

70년을 사이에 둔 같은 설계도 — 왼쪽은 1950년대 공장 라인의 컨베이어와 톱니바퀴, 오른쪽은 오늘의 책상 위 화면과 키보드. 그 사이 공중에 같은 네 칸 순환 루프가 그려진 커다란 설계도 한 장이 떠 있고, 양쪽의 꽃들이 같은 그림을 올려다본다

여기서 이 역사를 AI 엔지니어링의 언어로 되읽어 보자. 데밍의 사이클에는 오늘 우리가 따로따로 부르는 두 가지가 이미 함께 들어 있다. 첫 번째가 슈와트와 데밍의 출발점. 라인 끝 검사가 아니라 생산 과정 자체가 균일한 결과를 내도록 만든다. 이것이 AI 시대의 하네스 엔지니어링 이야기다. LLM(대규모 언어 모델)의 산출물을 끝에서 검수해 걸러내는 게 아니라, 에이전트가 일하는 공정(지식, 규칙, 워크플로우, 평가 기준) 자체를 설계해 균일한 품질이 나오게 만드는 것. 70년 전 공장 라인의 전환과 같은 전환이다. 두 번째가 데밍의 마지막 정정. 단순히 체크하지 말고 학습하라. 이것이 루프 엔지니어링이다. 통과/실패 게이트를 도는 루프가 아니라, 매 회차가 배운 것을 남기고 그 학습이 다음 회차의 입력이 되는 루프. 앤트로픽이 스킬 2.0(에이전트에게 주는 절차 설명서의 규격)에서 Eval(평가)을 스킬 개선 루프의 중심에 둔 것과 놀랍도록 닮아 있다. 스킬을 한 번 만들고 끝내는 게 아니라 평가를 돌려 얻은 것으로 스킬 자체를 고쳐 나가는 구조 말이다.

그리고 Study라는 단어는 AI 과잉생산 시대의 병목을 정확히 관통한다. 지금 부족한 것은 산출량이 아니다. 아타리의 매립지가 보여줬듯 통제 없는 물량은 이미 넘친다. 병목은 사람의 이해다. Check(통과했나)는 물량을 더 빨리 흘려보낼 뿐이고, Study(무엇을 배웠나)만이 이해를 축적한다. 모두가 동의하지는 않을 수 있다. 하지만 하네스 × 루프라는 조합의 초기 컨셉이 IT가 태동하기도 전, 제조업 품질 이론에서 먼저 이야기됐다는 사실만큼은 기록해 둘 만하다. 이제 이 역사가 왜 2026년의 한 제품 저장소에 다시 등장하는지 이야기할 차례다.

3. 톡브릿지 — 카카오 상담톡에 에이전트를 잇는 다리​

개울 양쪽 화단을 잇는 작은 나무다리 — 한쪽의 노란 꽃 무리와 다른 쪽의 파란 꽃이 다리 위에서 편지 봉투를 주고받고, 다리 밑으로 물이 양방향 물결로 흐른다

주인공은 제품이 아니라 루프라서 제품 소개는 짧게 한다.

톡브릿지는 고객이 직접 구축한 AI(인공지능) 에이전트를 카카오 상담톡에 잇는 B2B(기업 간 거래) 브릿지다. 옴니채널 CX(고객 경험)를 스스로 구축하려는 기업에는 상담 채널이 필요하고, 그 채널에 자기 에이전트를 붙이려면 다리가 필요하다. 블룸에이아이는 카카오 공식 상담톡 딜러사로서 그 채널을 제공하고, 그 위에 A2A(에이전트 대 에이전트) 브릿지를 놓는다. 들어오는 대화도 나가는 답변도 모두 HTTP(웹 통신 규약)로, 서명된 웹훅과 Discord·Slack 게이트웨이로, 그리고 AI 클라이언트가 바로 붙을 수 있는 MCP(Model Context Protocol) 서버로.

쉽게 말해 카카오톡으로 들어온 고객 문의를 그 회사가 만든 AI 상담원에게 넘기고, 답을 다시 카카오톡으로 돌려보내는 중계 서비스다.

■ 인바운드   [카카오 상담톡] → [수신·상담 코어] → [게이트웨이] → [고객의 AI 에이전트 / Discord / Slack / 서명 웹훅]
■ 아웃바운드 [고객의 시스템] ─(HTTP)→ [파트너 API 엣지] → [코어] → [카카오]

정원의 관점에서 눈여겨볼 것은 기능보다 만드는 방식이다. 개발자 PC, 개발 서버, 운영 서버 세 환경이 같은 운영 기반(쿠버네티스, 서버를 자동으로 굴리고 갱신하는 기반) 위에 같은 모양으로 놓여 있고, 프로그램을 빌드해 서버에 올리고 데이터베이스를 갱신하는 일까지 AI가 명령줄로 직접 한다. 기획과 검수의 결정은 전부 정원의 knowledge/에 쌓인다. 저장소의 README(안내 문서)에 "작업 방식 — 카카시 하네스"라는 절이 따로 있다는 것만 봐도, 이 제품이 정원 안에서 자랐다는 걸 알 수 있다.

4. 스무 명은 어떤 순서로 심어졌나​

정원지기가 오솔길을 따라 꽃을 차례로 심는다 — 앞쪽은 활짝 피었고, 중간은 막 깨어난 새싹, 끝의 몇 송이는 아직 화분에 담긴 채 눈을 감고 차례를 기다린다. 옆의 작은 수레에 화분이 더 실려 있다

정원의 전문가는 한꺼번에 오지 않는다. 톡브릿지의 정원 일지(버전 문서 쉰일곱 건)와 저장소 이력에서 스무 명이 심어진 순서를 옮겨 본다. 각자가 맡은 역할과 규칙만 적고 제품의 속사정은 뺐다.

시기심은 꽃맡은 규칙
6/8 첫날정원지기 + 시장 정찰병·제품 전략가(활성) / 연동 수문장·과금 규칙 감시병·경비병(대기)조사·기획 단계에 맞춰 둘만 깨우고, 코드 단계에 쓸 셋은 미리 심되 잠재웠다
6/9디자인 장인·닷넷 도편수 · 연동 수문장 깨어남화면 일관성 / 구현의 표준·구조·테스트 / 외부 채널과 브릿지 연동의 안정성. 코드 착수와 함께
6/12도메인 설계자(전략 DDD)유비쿼터스 언어·바운디드 컨텍스트. 코드 이전에 도메인을 해석
6/20작업 지휘자·애저 데봇스작업 보드 운전(백로그 → 완료) / 개발·운영 인프라
6/23디비 분석가데이터 정합성 점검·쿼리 튜닝
7/1경비병 깨어남인증·권한·테넌트 격리·대화 데이터 보호
7/2~3테크블로그 저자·국제 비즈니스 컨시어지·CLI 경험 장인구현 사실에 맞춘 제품 스토리 / 해외 고객의 국경 변수 / CLI 온보딩·오류 안내
7/5고객대응 전문가(대기)오류코드 사전·문의 채널. 출시일에 깨우기로. "대응력은 출시일에 갑자기 생기지 않는다"
7/30QA 장인기능 명세·테스트 케이스 소유, 설계 의도 ↔ 구현의 갭 추적. QA 에픽이 열린 날, 이 편의 주인공
8/19결제 장인·문서 사서·운영 관제사 · 과금 규칙 감시병 깨어남소유자 없던 세 영역. 결제 구현 / 고객이 읽는 문서 / 배포된 시스템의 관측
8/27(심지 않음) 로컬퍼스트 검증 체계스물한 번째 대신 QA 장인 + 디자인 장인의 협업으로. 6절
9/1출시스무 명 · 물길 일곱

순서를 놓고 보면 몇 가지가 눈에 들어온다. 우선 한꺼번에 심지 않았다는 것. 첫날 다섯, 그 뒤 두 달 반에 걸쳐 열다섯. 쉰일곱 번의 정원 버전 가운데 영입은 열두 번뿐이고 나머지는 지식이나 물길, 규칙을 고친 것들이다. 전문가보다 지식이 더 자주 자란다.

심는 것과 깨우는 것을 따로 둔 점도 재미있다. 첫날 심은 셋 가운데 연동 수문장은 하루 만에 깨어났고, 경비병은 3주 뒤, 과금 규칙 감시병은 두 달 반 뒤에야 "감시할 코드가 실재하고 나서" 깨어났다. 고객대응 전문가는 출시 엿새가 지난 일지 기준으로 아직 자고 있다. 미리 심어 두되 일이 생기기 전엔 안 깨운다는 건데, 처음엔 왜 굳이 미리 심어 두나 싶었다. 일지를 읽다 보니 답이 있었다. 대기 상태로라도 이름과 절차가 먼저 있어야 다른 전문가들이 "그건 경비병 몫"이라고 미룰 수 있다.

8월 19일의 셋은 "누구도 맡고 있지 않던 자리"를 세어서 나왔고, 8월 27일의 검증 체계는 새 전문가 대신 둘의 판정을 합쳤다. 정원이 자라는 방향은 머릿수가 아니라 빈자리였다.

5. 같은 정원, 다른 물길​

두 물길의 대비 — 하나는 게시판 액자 앞에서 잔잔히 멈추고, 다른 하나는 물레방아를 지나 작은 수차 펌프로 다시 위로 올라가 순환한다. 같은 샘에서 갈라진다

두 정원의 토양은 같은데 물길이 다르다.

이 글쓰기 정원의 물길은 짧고 곧다. 씨앗을 고르고, 원고로 키우고, 세 검수자를 지나 게시한다. draft → review → published. 게시가 곧 완결이다. 제품의 정원에는 물길이 일곱 갈래다. 조사→기획, 외부 API(응용 프로그램 인터페이스) 분석, 문서 게시, 웹 게시, 백로그(할 일 목록)→완료, 기능 명세→테스트 케이스(검증 항목), 그리고 로컬퍼스트 검증. 19편이 미리 말했듯 제품의 물길은 배포에서 끝나지 않고 배포에서 시작한다.

시작하는 순간 신호가 쏟아진다. 톡브릿지의 출시 준비 QA는 7월 30일에 QA 팀이 연 "풀 테스트" 에픽(큰 작업 묶음) 아래 티켓(발견한 문제 한 건을 적은 카드) 서른네 장으로 굴러갔다. 8월 27일 시점에 열일곱 장은 검증 완료, 두 장은 재오픈이었다. 한 번 고쳤다고 닫혔던 것이 다른 얼굴로 다시 올라온 것. 나머지는 할 일, 개발 중, 보류로 흩어져 있었다. 글쓰기 정원에서는 게시 후 독자 신호가 드물어서 삐걱이던 바로 그 바퀴가, 제품에서는 신호가 넘쳐서 어떻게 돌릴 것인가가 문제가 된다.

톡브릿지가 그 바퀴에 단 것은 둘이다. 하나는 수문. 무엇을 통과시킬 것인가를 정하는 로컬퍼스트 검증(6절). 다른 하나는 학습. 통과시킨 뒤 무엇을 배웠는가를 남기는 PDSA(7~9절). 둘 다 같은 날, 8월 27일에 심었다.

6. 왕복 6단계를 2단계로 — 로컬퍼스트 검증​

등불 세 개 — 티켓 두루마리, 설계 도면, 실물 화분 — 를 한 테이블에 모아 비추며 대조하는 두 꽃. 뒤편에 굽이굽이 여섯 구비 오솔길과, 테이블 옆의 두 걸음 지름길이 대비된다

정원 일지의 첫 문장이 이 장치의 전부다.

QA 팀에 내보내는 것은 "고친 것"이 아니라 "세 원천이 서로 일치함을 로컬에서 확인한 것"이다.

그동안의 왕복은 여섯 단계였다. 개발이 고쳐서 내보내고, QA가 재현하고, 티켓에 적고, 개발이 다시 재현하고, 수정하고, 재배포한 뒤 재검증. 그 왕복의 대부분은 로컬에서 두 단계로 끝낼 수 있었던 것이었다. 그래서 검증의 순서를 뒤집었다. 결함을 QA 보드에 기록으로 남기기 전에 개발이 먼저 세 개의 진실을 맞댄다.

원천결정하는 것결정하지 않는 것
① QA 티켓무엇이 결함인가 — 현상올바른 화면이 무엇인지, 원인이 무엇인지
② UX(사용자 경험) 규칙 — UX 팀이 넘겨준 전달본(기준 화면과 규칙)올바른 화면·흐름·상호작용이 무엇인가외부 API 규격, 과금 불변식
③ 우리 구현지금 실제로 무엇이 일어나는가아무것도 — "구현은 언제나 피고다"

셋을 두 개씩 맞대면 결과는 넷뿐이다. 티켓과 구현이 어긋나면 A 결함잔존, UX와 구현이 어긋나면 B 준거이탈, 티켓과 UX가 서로 다른 것을 말하면 C 충돌, 셋이 일치하면 D 통과.

여기에 규칙 셋이 붙는다. C는 고치지 않는다. UX가 기준선이긴 한데, 티켓이 UX와 다른 것을 요구하면 그 자리에서 판정하지 않고 충돌 카드(합의 요청서)를 올려 합의를 받는다. B는 센다. 티켓에 없지만 규칙과 다른 구현은 지나치면 다음 회차의 티켓이 되기 때문이다. 그리고 재오픈은 다른 절차로 간다. 첫 수정이 뿌리를 못 훑었다는 신호니까, 재현·수정·확인 세 단계가 아니라 이력 복원과 재발 유형 판정을 거치는 다섯 단계다.

이 장치를 만들면서 정원은 스물한 번째 전문가를 심지 않았다. 교차검증은 두 판정을 합치는 일이지 새 전문성이 아니라는 판단이었다. QA 장인이 "결함인가"를, 디자인 장인이 "무엇이 올바른가"를 답하고, 충돌은 둘이 함께 카드로 올린다. 필요할 때 하나씩 심는다는 이 시리즈의 규약이 제품의 정원에서도 지켜진 셈이다.

첫 회차의 실물이 장치의 값을 증명했다. 8월 27일, 개발 중 상태의 티켓 넉 장을 로컬에서 재현하고 원인을 확정하고 고치고 다시 확인하는 데까지, 개발 환경 배포 없이 끝냈다. 그런데 티켓에 없던 결함 셋이 더 나왔다. 고객 화면에 서버 템플릿 코드가 그대로 노출된 자리, 약관 동의 게이트가 법적 고지 문서까지 막고 있던 자리, 명시적으로 기각된 초안을 진실처럼 적어 둔 낡은 주석. B를 센다는 규칙이 첫날 세 건을 셌다.

7. 적어뒀는데 걸러지지 않았다​

일지 장부가 높이 쌓인 선반 옆, 같은 모양의 화분 조각이 네 번 깨져 쌓인 자리 — 그리고 그 옆에 바늘만 있는 텅 빈 작은 계기판

14편은 이렇게 썼다. 게이트(Check)는 루프가 망가지는 것을 막고, 학습(Study)은 루프를 진화시킨다. 톡브릿지에 게이트는 처음부터 있었다. A/B/C/D 판정, 아홉 항목의 내보내기 완료조건, 사람만 바꿀 수 있는 티켓 상태. 그런데 정원 일지는 같은 병이 두 번 났다고 적는다.

원칙이 이미 문서에 있었는데도 같은 화면을 네 번 고쳤다. 첫 수정이 뿌리를 못 훑어 재오픈 두 건이 두 번째로 라이징됐다. 둘 다 "적어뒀는데 다음 회차에 안 걸러졌다"이다. 서사는 쌓였지만 회차를 가로지르는 계측이 없었다.

장면 하나를 옮긴다. 사용량 화면의 안내 배너 한 장이 세 번 올라왔다. 재오픈 두 건의 심층분석은 재발 유형이 서로 달랐음을 밝혔다. 배너가 아닌 다른 한 건은 첫 수정이 무관한 파일을 고친 부분 수정이었고, 배너 쪽은 커밋 기록의 표현을 빌리면 "우리 콘솔에 구현된 적이 없다. UX 팀의 '화면 추가'는 전달본 작업이었다", 그러니까 다른 진입점이었다.

두 번째 재오픈은 배너의 시각값(배경색, 테두리, 모서리, 잠금)을 실측으로 못박았다. 세 번째는 좀 달랐다. 브랜드 설정을 마친 고객에게도 배너가 "브랜드 설정을 하라"고 안내하는 거짓말이 났다. UX 전달본과 대조하니 준거이탈이 아니었다. 전달본이 '브랜드 없음' 상태만 상정했고, 브랜드는 있고 연동만 남은 중간 상태를 아무도 다루지 않았을 뿐이었다. 세 번을 지나서야 "배너는 단일한 미완료가 아니라 세 상태다"라는 문장이 남았다.

문제는 그 문장이 어디에 남는가였다. 하네스 로그(에이전트가 회차마다 남기는 작업 일지)는 한 회차에 무엇을 왜 했는지를 남긴다. 서사다. 그런데 서사는 다음 회차의 사람이 다시 읽어야 작동하고, 안 읽으면 네 번째 화분이 깨진다. 씨앗 글이 데밍의 한 글자에서 읽어 낸 게 정확히 이거다. "체크는 정지 동작이다. 판정이 나는 순간 활동이 끝난다. 루프를 다음 회차로 굴리려면 판정 위에 학습이 얹혀야 한다." 톡브릿지는 그 자리에 계측을 하나 붙였다.

무엇어디
하네스 로그서사 — 왜 그렇게 판단했나, 무엇을 밟았나저장소 안, 커밋됨
PDSA 그래프계측 — 기대 대비 얼마나 맞췄나, 무엇이 재발했나저장소 밖의 그래프 DB(관계를 선으로 잇는 데이터베이스)

로그가 그래프의 수치를 인용하고, 반대 방향의 의존은 없다. 그래프가 저장소 밖에 있는 것도 설계다. git status(저장소의 변경 목록)에 아무것도 뜨지 않으니 정원의 다른 물길과 동시에 돌아도 서로 영향이 없다.

8. 티켓 한 장, 사이클 하나 — pdsa CLI​

물받이가 네 칸인 작은 물레방아 클로즈업 — 첫 칸에는 카드가 못으로 고정되어 있고, 셋째 칸에는 초록·주황·빨강 세 색 등불, 넷째 칸에서 끈 하나가 다음 바퀴로 이어진다. 옆에 작은 되감기 손잡이

씨앗 글은 도구를 한 문장으로 정의한다. "Plan에서 세운 검증 가능한 기대 평가를 Study에서 LLM이 판정(met / partial / unmet — 충족 / 부분 충족 / 미충족)하고, 각 사이클을 프로젝트별 임베디드 그래프 DB에 누적해 AI 에이전트의 장기 메모리를 만든다." 세 판정어는 이 편 끝까지 계속 나오니 뜻을 먼저 적어 둔다. met(충족)은 계획 때 적은 기대가 관측으로 확인된 것, partial(부분 충족)은 일부만 확인되고 미검증이 남은 것, unmet(미충족)은 기대에 미달한 것이다. 이름은 pdsa, npm(개발자 도구 설치 명령)으로 설치하는 CLI다. 톡브릿지는 이 도구를 이슈 처리의 계측 축으로 좁혀 썼다. 티켓 한 장이 사이클 하나다.

pdsa recall "<티켓 주제>" --limit 3      # (재오픈·기능 그룹 착수 전) 과거 학습을 먼저 읽는다
pdsa plan  "<무엇을 왜>" --expect "<판정 가능한 성공 기준>"   # 기대를 먼저 못박는다
pdsa do    "<관측으로 확정한 원인> / <실제로 고친 것>"
pdsa study "<관측 결과·수치>"             # → met(충족) / partial(부분 충족) / unmet(미충족)
pdsa act   --note "<배운 것>" [--reinforce "<보강할 것>"]    # 재오픈이면 --reinforce 필수

루프가 작동하는 지점은 사이클을 닫을 때가 아니라 여는 순간이다. plan의 --expect는 "성공했다고 말하려면 무엇이 관측돼야 하나"를 착수 전에 문장으로 쓰는 자리다. 정원 일지는 이걸 로컬퍼스트 검증의 오래된 질문과 같은 자리에 놓는다. "이 검증이 실패하려면 어떤 데이터여야 하나." 그 답을 못 쓰면 착수하지 않는다.

이렇게 쓰지 않는다이렇게 쓴다
"로그아웃이 잘 되게 한다""약관 동의 화면의 로그아웃 요청 응답에 인증쿠키 만료가 포함되고, 이동한 화면이 로그인 화면이다"
"체크박스 버그 수정""필수 2건 중 1건만 체크하고 제출했을 때, 재렌더된 화면에서 체크했던 칸이 체크 상태로 남는다"

씨앗 글은 이것을 "Plan은 할 일 목록이 아니라 가설이다"라고 부른다. 대부분 계획만 하고 가설을 세우지 않으니까, plan이 LLM으로 검증 가능한 기대와 측정 지표를 강제한다는 것. 도구의 도움말도 같은 말을 한다. study의 설명은 "결과 보고 → 기대 대비 판정·학습(Check 아님)". 14편의 한 글자가 CLI 도움말 한 줄에 박혀 있는 걸 보고 조금 웃었다.

판정에는 규율이 있다. 실패할 수 있는 데이터로 확인해 재현되지 않으면 met(충족), 일부만 통과하고 미검증이 남으면 partial(부분 충족), 이때는 무엇이 미검증인지와 판정 방법을 함께 적는다. 재현이 지속되면 unmet(미충족).

두 예외가 이 규율의 심장이다. 로컬에서 볼 수 없는 영역(불가)은 partial(부분 충족)로 적되 met(충족)으로 올리지 않는다. 충돌(C)은 사이클을 닫지 않는다. 합의 전에 판정하면 그 판정이 근거가 되어 버리기 때문이다. 일지의 경고를 그대로 옮긴다. "met(충족)을 남발하면 충족률이 거짓말이 된다. 이 지표의 가치는 높은 숫자가 아니라 다음 회차를 바꾸는 것이다."

도구는 기록기만은 아니다. 반대편에 앉은 검토자이기도 하다. 사이클 하나를 show로 펼쳐 보면 단계마다 코칭이 붙어 있는데, 한 사이클의 do 코칭은 사람이 partial(부분 충족)로 판정하기 전에 이미 "계획 대비 수행 Gap" 표를 써 두고 있었다. 실제 환불 요청까지의 증거는 기록되지 않았다, 7일 경과 케이스는 수행 기록이 없다, 곁가지로 고친 결함 셋은 효과는 있으나 본 회차 목표와 분리해 관리하라. 물론 코칭도 LLM의 산출이다. 센서이지 판사는 아니다.

여기부터는 도구 세부다. 건너뛰어도 9절은 이어진다. 보조 도구 셋이 이 루프를 지탱하는데, 먼저 래퍼 스크립트(명령을 감싸 안전하게 부르는 보조 스크립트)가 맨손 호출의 함정 넷을 없앤다. 실행 경로(PATH) 미등록, 한글 깨짐, 기록 언어 표류, 그리고 가장 무거운 전역 프로젝트 오염. 도구의 project set은 전역 활성 프로젝트를 바꾸기 때문에 다른 역할이 바꿔 두면 QA의 기록이 남의 그래프로 들어간다. 그래서 래퍼가 매 호출에 프로젝트를 주입하고 init과 project set을 아예 막는다. 씨앗 글이 권장하는 진입 명령 둘을 역할별 그래프 분리 때문에 제품의 정원이 뒤집은 셈이다.

티켓 조회 CLI는 조회, 댓글, 첨부는 되지만 상태 전이 명령이 일부러 없다. 상태는 사람(QA)이 바꾼다. 화면 검증의 공식 수단은 Playwright(브라우저를 자동으로 조작하는 테스트 도구)다. 일지의 문장을 빌리면 "curl(명령줄로 웹 요청을 보내는 도구)로도 되는데는 사유가 아니다. 되는 것과 검증한 것은 다르다."

9. 서른다섯 바퀴의 숫자​

개울가 수위 표시 막대 — 처음엔 높이 찼다가 내려와 잔잔하게 안정된 수위. 정원지기가 그 높이를 있는 그대로 일지에 옮겨 적는다. 물레방아 둘레에는 서른 번 넘게 돈 물방울 자국이 남아 있다

숫자를 일지와 그래프에서 그대로 옮긴다. 조회 시점은 9월 4일이다.

일자누적 사이클기대 충족률회차 메모
8/2754/5 (80%)첫 회차. 첫 사이클은 검증 환경의 공백으로 partial(부분 충족), 보강 사이클이 로컬 인증 대역을 신설
8/2813 → 1761% → 58%기능 그룹 회차. 재오픈 하나는 도구가 원인
8/311855%계측 CLI의 버전 표류 발견
9/12456%이전 보강 과제가 닫힘. 시간을 되감는 도구
9/225 → 3058% → 59%고아 사이클 하나, 충돌 대기 사이클은 닫지 않음
9/333 → 3462% → 60%출시 후 첫 운영 티켓. 코드 변경 0
9/4 조회3519/31 (61%)met(충족) 19 · partial(부분 충족) 12 · unmet(미충족) 0 · 미판정 4

("13 → 17"처럼 화살표가 있는 칸은 같은 날 두 회차를 돌린 것이다. 충족률의 분모가 누적보다 작은 것은 판정을 미룬 사이클을 빼고 세기 때문이다.)

이 표를 처음 봤을 때 솔직히 당황했다. 씨앗 글의 그래프는 반대 방향이었기 때문이다. 도구가 자기 자신을 만든 스물두 사이클에서 충족률은 처음 열 회차 40%에서 마지막 여덟 회차 88%로 올라갔다. 자기 기대를 점점 잘 쓰게 된 예측력의 그래프. 톡브릿지는 80%에서 출발해 60% 언저리로 내려와 안정됐다. 나빠진 건가.

일지를 따라 읽으니 그건 아니었다. 첫 회차는 재현 경로가 분명한 티켓 넉 장이었고, 그 뒤로 규율이 자리잡았다. 첫 사이클을 소급해 올리지 않았고("그때는 실제로 판정하지 못했다. 지표의 요점이 그것이다"), 불가를 met(충족)으로 올리지 않았고, 충돌은 닫지 않았다. 내려간 것은 정직성의 그래프였다. 씨앗 글의 다섯 교훈 중 둘째가 이것이다. "쓸모 있는 판정은 partial(부분 충족)이다."

지표가 다음 회차를 실제로 바꾼 사슬 넷을 그래프의 보강 링크(한 사이클이 남긴 과제를 다음 사이클에 잇는 연결, 도구 용어로 REINFORCES 엣지)에서 읽었다. 첫 사이클이 "로컬에 계정 상태를 만들 수단이 없다"로 partial(부분 충족)을 받자 두 번째 사이클이 그 대역을 만들었고, 그 뒤 같은 영역의 세 장이 전부 met(충족)으로 닫혔다. 재오픈 회차가 "게이트웨이 대역이 없어 미검증"으로 남기자 다음 사이클은 대역을 만드는 대신 필요 없다는 것을 알아냈다. 기존 판정 경로가 있었던 것이다. 환불 기능을 다시 밟은 회차는 "완료조건에 전체 테스트 실행을 명시하라"를 보강으로 남겼고, 다음 회차 일지가 "지켰다"고 회신했다. 제일 좋았던 장면은 이거다. 8월 31일의 한 사이클이 "로컬에 시간 제어 수단이 없다. 그 전까지 이 조건은 met(충족)으로 올리지 않는다"고 미검증을 남기자, 9월 1일에 구독일을 되감는 테스트 도구가 생겨 7일 경과 케이스가 실측됐다. 미검증을 미검증으로 적어 두었기 때문에 도구가 생겼다.

그래프는 실패도 남긴다. 8월 29일의 한 사이클이 배운 것, "plan 없이 do로 시작해 키가 충돌했다. 티켓마다 plan으로 사이클을 먼저 열 것"은 9월 2일에 같은 실수로 재발했다. 두 티켓의 plan을 연달아 만들자 do가 엇갈려 고아 사이클(plan만 남고 뒤 단계가 붙지 못한 사이클)이 생겼다. recall이 과거 학습을 자동으로 주입하는데도 걸러지지 않은 이유는 단순했다. 되읽기는 도메인 키워드로 검색되는데 이 학습은 제품이 아니라 도구 사용법에 관한 것이었다. 그래프는 제품을 기억했지, 자기 사용법은 기억하지 못했다.

그 자리에서 이 편의 세 번째 문장이 나온다. 씨앗 글의 다섯째 교훈, "측정 도구도 시스템의 일부다"를 톡브릿지는 세 번 실물로 겪었다. 재오픈 하나는 코드 탓이 아니었다. 티켓 조회 CLI가 본문의 첨부 이미지를 통째로 버린 탓에 정책서 캡처를 못 봐서 났고, 그래서 첨부 조회 명령이 생겼다.

계측 CLI는 다섯 버전이 밀린 채 조용히 성공하고 있었다. 없는 프로젝트 이름을 주면 빈 그래프를 새로 만들며 종료 코드 0을 돌려주는 오작동은 로그와 수치만 봐서는 절대 안 잡힌다. 그래서 문서의 금지 규칙이 래퍼의 코드 가드로 승격됐다. 여기까지가 일지에 있던 이야기고, 그다음은 우리가 겪었다. 이 편을 쓰려고 그래프를 읽던 9월 4일, 도구는 한 버전이 더 올라 있었고 새로 생긴 조회 명령 둘이 래퍼의 주입 목록에 빠져 있었다. 같은 무늬의 재발을 이번엔 글쓰기 정원이 밟은 것이다. 16편이 "파일에 써야 래칫(한 방향으로만 도는 톱니, 되돌아가지 않게 거는 장치)이 걸린다"고 했다면, 그 다음 문장은 이렇게 돼야 할 것 같다. 코드가 지켜야 래칫이 안 풀린다.

속도도 적어 둔다. 첫날은 일곱 시간에 열 사이클, 티켓 한 장에 15분에서 한 시간. 판정이 빨라진 게 아니라 판정의 형식이 빨라진 거다.

10. 출시 — 수문을 지나서도 바퀴는 돈다​

마지막 수문이 열리고 물이 담장 밖 넓은 들판으로 처음 흘러나간다 — 뒤편에서 물레방아는 멈추지 않고 계속 돈다. 들판 쪽에서 첫 손님 꽃이 다가온다

9월 1일, 운영 환경에 첫 불변 릴리스 버전(한 번 붙이면 바꾸지 않는 배포 번호)이 붙었다. 이틀 뒤 그 번호는 여덟 번째였다. 사흘에 여덟 릴리스, 그중 다섯이 QA 회차를 지난 뒤의 태그다. 출시일부터 작업의 단위도 바뀌었다. 개발 브랜치(작업 갈래)에 직접 쌓던 커밋(저장 단위)이 티켓당 풀 리퀘스트(PR, 코드 변경을 검토받아 합치는 요청) 하나로. "출시 후에는 QA 검증 완료 건만 운영에 반영한다"는 규칙은 출시 직후의 준운영 기간에는 검증과 별개로 반영하는 실제 운영과 어긋나자 사흘 만에 고쳐졌다. 규칙이 실무를 못 따라오면 규칙을 고친다는 것도 정원의 학습이다.

출시는 19편의 언어로 G4 수문(출시 수문)의 통과다. 루프의 끝은 아니다. 출시 직후의 첫 운영 티켓이 그 증거인데, 개발 환경에서는 되고 운영에서만 실패하는 연동 오류였고, 세 사이클의 진단 사슬 끝에 원인은 코드가 아니라 운영 앱의 배포 설정으로 확정됐다. 코드 변경 0, 판정 met(충족). 그날의 일지는 사이클 다섯에 수정 커밋 하나다. 씨앗 글이 스물두 사이클 사이에 루프 없이 나간 커밋 열넷을 두고 "불확실한 일에는 루프를 썼고, 확실한 일에는 쓰지 않았다. PDSA를 어디에 쓸지 자체가 학습"이라 적었듯, 톡브릿지의 열흘도 146 커밋에 35 사이클이다. 사이클의 단위는 커밋이 아니라 판정이 필요한 불확실성이었다. 그 열흘의 커밋 유형을 세어 보면 수정(fix) 38에 문서(docs) 29. 서사가 산출물의 절반이었다.

19편의 네 물레방아 표를 이번엔 제품의 정원에 대 본다. 네 바퀴란 발견(무엇을 만들지 고르기), 제작(만들기), 신뢰성(고장에서 배우기), 가치(실제로 쓰이고 값을 치르는가)다.

물레방아톡브릿지의 현재판정
제작 루프일곱 물길, 티켓당 PR, 세 환경 쿠버, 사흘 여덟 릴리스힘차게 돈다
신뢰성 루프로컬퍼스트 수문 + PDSA 서른다섯 바퀴돈다
발견 루프원탁·백로그·시장 정찰. 장치는 있다반쯤 돈다
가치 루프출시 사흘째. 첫 신호를 기다린다아직

이 표가 글쓰기 정원의 진단을 바꾸지는 않는다. 이쪽의 신뢰성 바퀴는 여전히 삐걱이고, G5·G6 수문(가치·퇴비 수문, 쓰이는가와 배운 것이 재사용되는가의 통과 기준)은 여전히 빈칸이다. 바뀐 것은 하나다. 그 바퀴를 어떻게 다는지의 설계도가 담장 안에 생겼다. 독자 신호가 드물어 바퀴가 삐걱인다면 신호를 기다릴 게 아니라 기대를 먼저 못박는 것부터 시작할 수 있다는 걸, 이제 우리는 남의 정원이 아니라 우리 정원의 일지로 안다.

11. 마치며 — 반복은 배움의 어머니, 단​

석양 — 담장 안 두 정원이 한 화면에, 같은 샘에서 갈라진 두 물길이 각자의 바퀴를 돌린다. 정원지기가 두 정원 사이 나무다리에 앉아 있다

한계부터 적는다. 이 편의 수치는 전부 톡브릿지 정원의 자기 계측이다. 일지가 이렇게 적고 있다는 것이지 외부가 검증한 숫자가 아니다. 그래프는 QA 이슈 처리에 한정된다. 제품의 결정과 설계는 여전히 정원의 지식이 소유하며, 이 편을 "PDSA로 제품을 만들었다"로 읽으면 과장이다. 서른다섯 사이클은 작은 표본이고, 판정은 LLM이 하며, 코칭도 그렇다.

unmet(미충족)이 한 번도 없었다는 사실도 자랑이 못 된다. 기대를 여러 항목으로 쪼개 쓰기 때문에 하나만 맞아도 partial(부분 충족)이 되어, 판정의 가장 아픈 칸이 비어 있을 수 있다. 씨앗 글의 스물두 사이클에는 unmet(미충족)이 하나 있었고, 그것은 "계획은 조사 문서를 요구했는데 수행은 코드를 냈다. 좋은 작업이었지만 계획한 것이 아니었고, Study는 이것을 성공으로 반올림하지 않았다"는 정직성의 기록이었다. 톡브릿지의 그래프에 그 붉은 칸이 없다는 것은 다음 회차에 물어야 할 질문이다.

그 한계를 다 적고도 남는 게 이 편의 수확이다. 14편은 이렇게 맺었다. 닌텐도의 도장만으로는 도요타가 되지 않는다. 톡브릿지가 출시 닷새 전에 단 것은 도장이 아니라 반성이었다. 기대를 먼저 못박고, 판정을 산출물이 아니라 기대에 맞춰 내리고, 미검증을 미검증으로 남겨 다음 회차가 그것을 닫게 하는 것. 그 반성이 사람의 기억이 아니라 저장소 밖의 그래프와 래퍼의 코드에 남게 하는 것. 씨앗 글의 마지막 질문을 여기 옮긴다. "당신의 엔지니어링은 무엇을 체크하고, 무엇을 학습하는가."

정원 은유로 맺는다. 담장 너머를 세 번 답사하고 돌아와 보니 담장 안에 정원이 둘이었다. 같은 샘에서 갈라진 두 물길이 각자의 바퀴를 돌린다. 하나는 게시에서 멈추는 짧은 물길, 하나는 배포에서 다시 위로 올라가는 긴 물길. 이 편은 그 긴 물길의 물레방아 하나를 가까이서 본 기록이다. 그 기록을 쓰는 방법도 씨앗 글에서 배웠다. 회고 문서를 따로 쓰는 대신 그래프와 커밋을 도구로 읽어 서사와 맞대는 것. 이 편은 그렇게 쓰였다.

Repetitio est mater studiorum — 반복은 배움의 어머니. 단, 배움 없는 반복의 이름은 재오픈이다.

하네스의 이야기는 계속됩니다. 감사합니다 💙

참고 자료​

씨앗 글​

도구​

데밍·아타리·닌텐도 (2절 고증 — 씨앗 글과 14편의 사실검증 출처)​

톡브릿지 정원 일지 (저장소 내부 기록 — 링크 없음)​

  • 로컬퍼스트 검증 지식·QA 보드 규약·PDSA 운용 규칙(pdsa-loop.md), QA 장인 로그 16건(2026-08-06 ~ 09-03), 정원 버전 문서 v1.21.0(로컬퍼스트 체계) · v1.22.0(운영 v1.0.0 오픈) · v1.23.1
  • ※ 이 편의 수치·인용은 전부 위 일지와 PDSA 그래프(9월 4일 조회)·커밋 이력에서 그대로 옮겼다. 자기 계측이므로 외부 검증 수치처럼 읽지 않기를 권한다

시리즈 내부 연결​