9월 8일, 에이전트가 기술 복기 8항목마다 대본 댓글을 달고 11분도 안 되어 체크박스 8개를 모두 채웠다.
한 시간쯤 뒤 그 체크를 전부 되돌리게 했다.
대본이 있다는 것과 내가 그 내용을 설명할 수 있다는 것은 따로 확인해야 했다.
내 프로젝트를 남에게 설명할 준비를 하다가 시작된 일이다.
문제
에이전트는 산출물을 만들고 스스로 확인하고 체크까지 한다.
그 체크는 산출물이 있다는 표시였을 뿐 내가 그 내용을 소화했는지는 알려 주지 않았다.
설명해야 하는 사람은 나인데 대본을 읽어서는 내 이해가 얼마나 깊은지 알 수 없다.
그날 이슈에 새로 남긴 규칙은 네 가지다.
- 대본을 보지 않고 내 말로 설명한다.
- 에이전트는 빠진 것, 틀린 것, 얕은 것을 짚고 꼬리질문을 던진다.
- 다 이해했다고 판단될 때만 체크하고 판정 근거를 댓글로 남긴다.
- 모르는 부분은 대본을 고치지 않고 내가 아는 범위로 답을 줄인다.
에이전트 메모리에는 이 순서를 한 줄로 적었다.
"질문 → BK 답변 → 짚기 → 재답변 → 체크".
대본은 참고자료로 내렸다.
그 이슈의 체크박스 8개는 지금도 하나도 체크되지 않았다.
체크를 되돌리게 하면서 나는 에이전트에게 프로젝트를 거의 네가 주도했으니 내 기술적 깊이가 낮을 수도 있다고 가정해야 한다고 말했다.
대본을 멋대로 쓰지 말고 내가 확실히 아는지 하나씩 짚다가, 다 이해했다 싶은 순간에만 체크하라고 했다.
사흘 뒤 다른 복기에서는 이런 판정이 남았다.
"'왜'는 통과, '어떻게 동작·무엇이 실패'가 전 항목 공백."
이유는 설명할 수 있었다.
어떻게 동작하고 무엇이 실패하는지는 설명하지 못했다.
결과만 받은 숫자를 내가 다시 돌린다
9월 10일에는 규칙을 하나 더 정했다.
에이전트가 대신 잰 결과를 내 것으로 말하려면 내가 직접 한 번 이상 다시 돌려야 한다.
구술 준비만으로는 "결과만 받은 것"이라는 약점이 남는다.
첫 대상은 외부 API에 요청을 몰아 보내 429(요청 한도 초과) 응답을 받아 보는 실측이었다.
원본 실험 폴더에서 돌리면 실행이 끝날 때 결과 문서를 새로 만들면서 9월 7일의 증거를 덮어쓴다.
그래서 원본을 복사한 사본 안에서 같은 조건으로 요청 130회를 보냈다.
| 실행 | 200 응답 | 429 응답 |
|---|---|---|
| 9월 7일 원본 (에이전트) | 101건 | 29건 |
| 9월 10일 재실행 (나) | 104건 | 26건 |
표준 Retry-After 헤더는 재실행에서도 0건이었다.
이 결론은 먼저 쓴 판정문에 있다.
직접 돌렸다고 해서 이해가 함께 따라오지는 않았다.
같은 날 다시 설명해 보니 나는 429를 동시 요청 한도로 말했다.
실제로는 시간당 요청 수를 제한하는 속도 한도였다.
곧바로 정정받았다.
증거를 다시 만들어 재현하는 원칙은 에이전트 기록의 등급을 다룬 글에 있다.
여기서 재실행으로 다시 만든 것은 증거였고 내 이해는 확인되지 않았다.
같은 오개념이 세 번 넘게 돌아오면 차원을 낮춘다
krsec-rag-lab은 한국어 보안 문서로 RAG(검색 증강 생성) 평가 하네스를 만드는 공개 리포다.
여기서는 세션을 둘로 나눴다.
수집 스크립트나 인프라처럼 기계적인 일은 위임 세션에서 에이전트가 주도한다.
임베딩처럼 내가 이해해야 하는 일은 학습 세션에서 다루고 지침에 "학습 세션에서는 구현을 대신하지 말 것"이라고 적었다.
실행보다 설명을 완료 조건으로
노트북을 만들어 문서 한 건이 문자열에서 벡터가 되기까지의 과정을 손으로 따라가게 했다.
마지막 절에는 완료 조건을 이렇게 적었다.
"실행됐다"가 아니라 "노트북을 보지 않고 설명할 수 있다".
질문은 7개를 두었다.
답까지 적어 두면 게이트가 무력해지므로 답은 노트북에 넣지 않았다.
노트북 구현은 내가 "5도 바로진행"이라고 넘겨서 학습 세션이 아니라 위임 세션에서 에이전트가 만들었다.
이 루프가 없으면 이슈가 어떻게 닫히는지를 노트북 이슈 #5가 보여 준다.
노트북 구현 PR이 머지되면서 그 이슈가 자동으로 닫혔고
43초 뒤 "이슈는 열어둔다"는 댓글이 달렸다.
게이트를 통과했다는 기록은 그 이슈에 없다.
벡터 = 주소라는 오개념
9월 19일 첫 시험에서는 첫 질문을 넘지 못했다.
"1024차원의 특정 주소로 임베딩"이라고 답했고 같은 날 오전에 고친 "벡터 = 주소" 오개념이 세 번째로 돌아왔다.
9월 22일 두 번째 시험도 첫 질문에서 막혔다.
네 번째 재발이었다.
노트북을 연 채로 내가 한 말은 "노트북 봤는데, 눈에 한개도 안들어와.. 어떡하지"였다.
그때 노트북과 1024차원을 통째로 치우고 사람이 이름을 붙인 축 세 개로 장난감 좌표를 만들었다.
| 벡터 | 취약점 | 자바 | 요리 |
|---|---|---|---|
| D1 | 0.9 | 0.8 | 0.0 |
| D2 | 0.9 | 0.0 | 0.0 |
| D3 | 0.0 | 0.0 | 0.9 |
| 질의 Q | 0.8 | 0.9 | 0.0 |
효과가 있었던 것은 반례 두 가지였다.
주소라면 정확히 같은 것만 찾을 수 있으니 검색 결과는 0건이어야 한다.
그런데 노트북의 실제 1위 점수는 0.785684로, 1.0에 못 미쳤는데도 검색됐다.
또 주소라면 찾아가서 꺼낼 것이 있어야 하는데 이 숫자 자체가 내용물이라 꺼낼 것이 없다.
그 뒤로 나는 축별 차이를 스스로 짚었다.
D1은 질의와 취약점·자바 축에서 0.1씩 다르고 D2는 자바 축에서 0.9가 벌어진다.
그래서 D1이 가깝다고 답했고 "주소"라는 낱말은 쓰지 않았다.
그날 질문 7개 중 Q1~Q4를 통과했다.
Q1에서는 정규화의 목적을 값의 범위를 맞추는 것으로 답했고 이 초점 오류가 남은 채로 통과 처리됐다.
같은 날 KV 캐시(생성 중에 앞 토큰의 키·값을 저장해 두는 메모리)까지 손으로 계산했다.
7B 모델, 32층, 4096차원, fp16이면 토큰당 약 0.5MB이고 2000토큰이면 약 1GB다.
Q5~Q7은 아직 남아 있다.
닫기 전에 내 말로 설명한다
collection-resilience-lab은 차단하는 서버를 직접 만들고 수집 워커가 막힘을 어떻게 다루는지 잰 실험실이다.
무엇을 만들었고 무엇을 쟀는지는 개발일지에 있다.
여기서는 이슈마다 "닫기 전 확인할 질문"을 두고 내가 내 말로 설명해서 통과해야 이슈를 닫았다.
틀린 답과 교정은 이슈의 마지막 코멘트에 남겼다.
이 절차를 거치지 않은 이슈도 있다.
그보다 먼저 닫은 대상 서버 이슈 셋(#6, #7, #8)은 4초 사이에 차례로 닫혔다.
댓글은 각각 구현 요약 하나뿐이었다.
설계 결정을 담은 #17은 댓글 없이 닫혔다.
틀린 답과 교정
| 내가 처음 한 답 | 교정 | 기록 |
|---|---|---|
| 차단 표시가 남아 새 요청이 거부되는 것을 "멱등성"으로 설명 | fail-closed(확실하지 않으면 막는 쪽)의 의도된 대가 | #13 |
| "둘 다 막히면 DLQ" | 가장 빨리 풀리는 출발지까지 큐 정지 | #14 |
| 429는 "동시 요청 제한" | 시간당 요청 수(속도) 제한 | #14 |
| 150ms 지연은 "조절값" | 같은 조건 비교용 고정 인위 지연 | 세션 기록 |
DLQ(dead letter queue)는 처리를 포기한 작업을 옮겨 두는 곳이다.
셋째 줄은 9월 10일에 고친 혼동과 같다.
18일 뒤 다른 리포에서, 나는 같은 429를 다시 동시 한도로 말했다.
막혔을 때 쓴 방법
9월 8일에 정한 규칙 4번은 같은 달 하순에 이 리포에서 그대로 쓰였다.
빈 페이지와 파싱 실패를 묻는 질문에서, 핵심인 조용한 누락은 내 말로 먼저 답했다.
판정 기준은 한 문장으로 줄여서 확인했고 이슈에는 "범위를 줄여 통과"로 남았다.
큐 단위로 진행을 세는 질문에서는 한참 막혔다.
범위를 좁힌 상황 질문 3개로 나누자 풀렸고 나는 문 비유로 답했다.
"누군가 통과했으면 문(출발지)은 열린 것이니 DLQ에 보내지 않는다."
빈칸을 채우는 질문보다 상황을 던지는 질문이 나에게 맞았다.
측정을 내가 다시 돌렸다
9월 28일, 측정을 맡은 이슈를 닫기 전에 pnpm scenario를 내 터미널에서 다시 돌렸다.
exit 0, 처리량은 1.23 / 0.72 / 0.59 / 0.96건/초, 네 시나리오 모두 200/200, DLQ 0이었다.
전날 에이전트가 낸 값과는 둘째 자리에서만 달랐고 이슈에는 "같다"고 적었다.
노트북 한 대에서 시나리오당 한 번씩 돌린 값이라 편차는 알 수 없다.
출발지 전환 이슈와 측정 이슈를 같은 절차로 닫은 뒤, 리포 README의 AI 사용 절도 그 상태에 맞게 고쳤다.
결론
확인 방법은 세 번 바뀌었다.
처음에는 에이전트가 쓴 대본을 읽고 체크했다.
그다음에는 내가 답하고 짚히고 다시 답했다.
결과만 받은 숫자는 내가 다시 돌렸다.
같은 오개념이 반복될 때는 표현의 차원을 낮췄다.
참고
- krsec-rag-lab 이슈 #5 - 노트북 구현 머지와 자동 종료
- collection-resilience-lab 이슈 #11 - 범위를 줄여 통과한 설명 확인
- collection-resilience-lab 이슈 #19 - 문 비유로 통과한 설명 확인
- collection-resilience-lab 이슈 #15 - 설명 확인과 직접 재측정
- collection-resilience-lab - 차단하는 서버와 수집 워커를 함께 만든 실험실 - 무엇을 만들고 무엇을 쟀나