tc-team
기획서를 넣으면 테스트케이스가 나온다. LLM은 문장만 쓰고, 구조와 게이트는 전부 결정론 코드가 소유한다.
기획서 원문을 넣으면 라이브 스프레드시트 탭에 테스트케이스 세트가 채워진다. 시작부터 끝까지 한 번의 호출로 돈다.
핵심은 “LLM이 TC를 쓴다”가 아니다. 그건 아무나 엉망으로 할 수 있다. 진짜는 역할을 가른 것이다.
2레인 원칙 — LLM은 문장과 판단만, 결정론 코드가 구조와 사실을 가진다.
왜 갈랐나
초기엔 모델이 파이프라인 전체를 몰았다. 드리프트했다.
단계마다 행 수가 달라지고, 커버리지가 조용히 떨어지고, 두 번 돌려서 같은 모양이 나온 적이 없었다. 모델은 “대충 맞게” 하는 데는 훌륭한데, 같은 입력에 같은 출력을 내는 데는 쓸 수 없다.
해법은 설득이 아니라 몰수였다.
| 소유자 | 가진 것 |
|---|---|
| 결정론 코드 | 단계 순서, 행 골격, 번호, 서식, 병합, 커버리지 원장, 시트 기록 |
| LLM | 설계 판단, 문장, 리뷰 지적, 판정 |
여덟 단계
| 단계 | 하는 일 | 주인 |
|---|---|---|
| S0 | 원문 수집, 실행락, 입력 자가검증 | 코드 |
| S1 | 기획서 분석 → 설계 골격 | LLM |
| S2 | 설계 격리 게이트 + 원문 슬라이스 | 코드 |
| S3 | 골격 생성 → 문장화 팬아웃 → 병합 | 코드 + LLM |
| S4 | 적대 리뷰 · 판정 · 커버리지 원장 | LLM |
| S5 | 수정 적용 + 게이트 4종 | 코드 |
| S6 | 라이브 시트 기록 | 코드 |
| S7 | 완료 처리 · 대시보드 · 알림 | 코드 |
S1~S7은 각각 따로 적어 뒀다. 단계마다 값을 치르고 배운 게 하나씩 있어서, 표 한 줄로는 안 담긴다.
S3이 이 구조를 가장 잘 보여준다. 골격을 코드가 먼저 만들고, 25행씩 잘라 모델에게 문장만 채우게 하고, 돌아온 것을 코드가 다시 병합한다. 병합할 때 인덱스·에코·해시·개수를 대조해서, 모델이 행을 밀거나 남의 행을 건드렸으면 그 청크만 다시 돌린다. 나머지 청크의 결과는 그대로 살린다.
게이트 — 못 넘으면 선다
이게 이 도구의 성격을 정한다. “최선을 다해 계속”하지 않는다.
| 게이트 | 단계 | 걸리면 |
|---|---|---|
| 입력 자가검증 | S0 | 재수집 1회 → 또 실패면 시작 금지 |
| design_gate | S2 | 설계 결함 → S1으로 되돌려 수정 루프 |
| merge 대조 | S3 | 어긋난 청크만 재실행 |
| apply before-불일치 | S5 | 거부가 정상 동작 — 수정 계획 재생성 |
| content_gate | S5 | 추상 표현·근거 없는 위임 차단 |
| dup_gate | S5 | 완전 동일 케이스 잔존 시 병합 강제 |
| traceability | S5 | 규칙 미커버 → 행 봉합 후 재적용 |
apply before-불일치가 특히 중요하다. 수정을 적용하기 전에 “내가 고치려는 그 자리가 아직 내가 본 그 내용인가” 를 확인하고, 다르면 거부한다. 사람이 중간에 시트를 만졌거나 앞 단계가 밀렸다는 뜻이라, 이때 밀어붙이면 엉뚱한 행을 덮어쓴다.
멈추는 지점은 딱 하나로 모아뒀다. 무결성 위반이면 즉시 서고, 그 외에는 무인으로 완주한다.
리뷰는 협력이 아니라 적대다
생성된 케이스를 렌즈 여럿이 병렬로 읽는다 — 구조, 품질, 원문 대조. 서로의 결과를 모른다. 알면 수렴하고, 수렴하면 같은 걸 놓친다.
별도의 판정자가 이 지적들을 교차신문해 오탐을 떨어내고, 기계가 적용 가능한 형태의 수정 계획을 만든다. 살아남은 지적은 코드가 적용한다. 모델에게 “고쳐주세요”라고 부탁하지 않는다.
같은 단계에서 커버리지 원장을 만든다. 기획서에서 뽑아낸 규칙 하나하나가 어느 케이스로 덮였는지를 기록하고, 안 덮인 규칙이 있으면 S5에서 행을 봉합한다.
시트는 한 번만 만진다
S6은 라이브 시트를 딱 한 번 접촉한다. 그리고 소유 마커로 판단한다.
- 우리가 만든 탭이면 → 통째로 지우고 다시 쓴다 (멱등)
- 남이 쓰던 탭이면 → 침범하지 않고
_v2접미사로 새로 만든다 - 다른 탭은 무조건 불가침
여러 번 돌려도 결과가 같고, 남의 작업을 절대 덮지 않는다. 자동화가 사람 옆에서 돌려면 이 두 개가 먼저다.
값을 치르고 배운 것 두 개
행을 끼워 넣으면 번호가 밀린다. 커버리지 원장은 케이스 번호로 규칙을 가리키는데, 봉합으로 행을 추가하면 그 번호가 통째로 낡는다. 처음엔 산술로 다시 매기려 했다 — 틀렸다. 지금은 번호가 아니라 내용으로 잇는다(분류 + 검증 단계 + 재현 스텝). 위치는 변하고 내용은 안 변한다.
손으로 몰면 절반이 사람 대기 시간이다. 한 번은 단계를 하나씩 손으로 돌렸는데, 벽시계로 2시간 23분 걸린 런에서 기계가 실제로 일한 시간은 1시간 12분이었다. 나머지는 전부 내가 다음 명령을 치는 걸 기다린 시간이다. 무인 완주를 만든 이유가 이 숫자다.
기각된 것들
버전 히스토리는 대체로 “진척처럼 보였지만 아니었던 것” 의 목록이다.
어휘 기반 진척도 감지 — 실측 2회로 기각. 임계값 통일 — 기각. 확신도 히트맵은 모델 채점판이 재현에 실패한 뒤, 모델 호출 0회의 순수 결정론 산출로 끝났다.
기각할 때마다 재개 조건을 같이 적었다. 안 그러면 반년 뒤에 같은 아이디어를 다시 꺼내게 된다.
정직한 한계
기획서가 부실하면 결과도 부실하다. 이 도구는 없는 기획을 지어내지 않는다 — 근거가 없으면 케이스를 만드는 대신 “기획 확인 필요”로 표시하고 넘어간다. 그게 맞다고 보지만, 기획이 얇은 조직에서는 산출량이 기대보다 적게 나온다.