학습 루프를 만들었다: 증거 없이 완료되는 구멍이 나왔다

사유고는 책을 찾고 읽는 데는 강했지만, 모든 것이 책 한 권 단위로 묶여 있었다. 그런데 공부는 보통 책에서 시작하지 않는다. “7일 안에 재무제표 분석 메모를 쓸 수 있게 되고 싶다”처럼 할 수 있게 되고 싶은 일에서 시작한다. 7월 중순, 이 방향을 거꾸로 세운 학습 프로젝트를 만들었다.

먼저 백지에서 해 본다

흐름은 이렇다. 목표를 선언하면 앱은 설명부터 하지 않고 진단 미션을 준다. 아무것도 보지 않고 먼저 해 보는 것이다. 그 시도에서 드러난 빈 곳에만 책의 근거 페이지와 단계별 힌트를 연결한다. 마지막에는 힌트를 잠근 채 비슷하지만 다른 과제를 풀게 해서, 배운 것이 옮겨 가는지 확인한다.

처음 설계 문서에는 상태가 열세 가지나 있었다. 첫 버전으로는 너무 많아서 프로젝트 다섯 상태, 미션 다섯 상태로 줄였다. 그리고 중요한 결정을 하나 했다. 학습 순서를 지키게 하는 일은 프롬프트가 아니라 상태 머신, 곧 코드에 맡긴다. 모델에게 “힌트를 먼저 주지 마”라고 부탁하는 대신, 서버가 조건이 안 맞으면 다음 단계로 넘기지 않게 한다. 프롬프트는 힌트의 품질만 책임지게 한 단계 내렸다. 사용자가 일반 검색 탭으로 답을 찾아보는 것까지 막지는 않고, 도움을 받은 시도로 기록만 하게 했다.

두 번에 나눠 맡겼다

구현은 다른 코딩 에이전트에게 맡기고, 나는 지시문 설계와 독립 검증을 맡았다. 한 번에 전부 맡기려다 두 번으로 나눴다. 백엔드와 테스트를 먼저 끝내 검증하고, 그다음에 화면을 붙였다. 검증하는 순간이 한 번뿐이면 상태 머신의 결함을 화면이 잘 도는 모습이 가려 버리기 때문이다. 위임 지시에는 다섯 가지를 못 박았다. 단계 이동은 서버가 정한다, 첫 시도는 나중에 고칠 수 없다, 시간은 밖에서 주입해 테스트한다, 데이터 구조 변경은 명시적으로 한다, 기존 화면에는 덧붙이기만 한다.

감사가 찾은 구멍

기능이 다 돌아가는 것을 확인한 뒤, 또 다른 에이전트에게 교차 감사를 맡겼다. 결과는 불합격이었다. 가장 심각한 지적은 이것이었다. 마지막 확인 과제를 만들 때 진단 미션을 통과했는지 보지 않았고, 미션 완료는 평가 결과와 상관없이 누를 수 있었다. 그러니까 한 번도 제대로 해내지 않고도 “완료”를 찍을 수 있었다.

단계 하나하나의 규칙은 맞았다. 틀린 것은 단계 사이의 순서였다. 진단을 통과해야 확인 과제로 갈 수 있다는 연결이 빠지자, 루프 전체를 옆으로 돌아갈 수 있었다. 확인 과제를 만드는 일과 완료하는 일을 모두 증거 사슬에 묶었다. 진단 통과, 도움 없이 해낸 시도, 평가 충족이 차례로 있어야만 다음이 열린다. 이 조건을 검사하는 기준 아홉 개를 새로 추가했고, 전체 75개 기준을 모두 통과시켰다.

감사와 별개로 실제 화면에서도 두 가지가 나왔다. 화면을 다시 그릴 때 늦게 불러오는 썸네일이 영영 나타나지 않아 바로 불러오게 바꿨고, 오류 알림에 코드 원문이 그대로 보이던 것을 한국어 문장으로 바꿨다. 공백을 사용자가 승인하는 흐름이나 목표 수정 같은 네 가지는 첫 버전 밖으로 미뤘다.

배운 것

상태 머신이 무언가를 강제하려면 전환 조건의 그물이 빈틈없어야 한다. 각 전환이 옳다고 해서 전체가 옳은 것은 아니다. 그리고 그 빈틈은 만든 사람보다 처음 보는 눈이 훨씬 잘 찾았다. 이 뒤로 큰 기능은 만든 쪽과 검사하는 쪽을 나누는 것을 기본으로 삼았다.