본문으로 건너뛰기
JSL107's Tech Note
돌아가기

계획을 성과로 오인하지 않는 근거 기반 자동 회고 설계

8분 분량이 글 고치기
목차 · 8

자동 회고에서 가장 위험한 오류는 문장이 어색한 게 아니라 아직 실행하지 않은 계획을 이미 달성한 성과처럼 기록하는 일이에요. 이를 막으려고 회고 입력을 계획과 코드 호스팅 서비스의 merged PR 실적으로 나누고, 근거가 없거나 불완전한 상태도 그대로 드러나게 설계했어요.

계획 목록이 그대로 실적이 된 문제

기존 일일 회고는 업무 계획에서 작업 제목을 가져와 다음과 같은 텍스트를 만들었어요.

오늘 계획 요약 (자동 생성, YYYY-MM-DD)
- 수집 실패 대시보드 검증
- 데이터 규칙 파싱 확인
- 시간 필드 문서화

주간 회고도 최근 일주일간의 계획 제목을 같은 방식으로 합쳤어요. 모델은 이 입력을 바탕으로 계획을 “작업 범위를 정리했다”, “검증 계획을 구체화했다”처럼 바꿔 표현했어요. 계획서에 저장소나 URL을 확인하지 못했다는 표시가 있으면 그 불확실성까지 회고에 담았고요.

실측 결과에서도 문제가 드러났어요. 최근 성공한 자동 회고 실행은 대부분 정량 영향 필드가 비어 있었는데, 한 줄 성과 필드에는 “여러 검증·문서화 작업의 범위를 정리”, “여러 오류·지연 검증 계획 구체화”처럼 계획을 성과로 받아들일 만한 문장이 들어갔어요.

프롬프트에는 이미 “정량 근거만 사용하고 근거 없는 칭찬을 금지한다”는 지시가 있었어요. 문제는 프롬프트가 아니라 입력이었어요. 근거를 요구하면서 정작 모델에는 계획서만 전달하는 모순된 구조였거든요.

더 큰 문제는 이 결과가 일회성 메시지로 끝나지 않는다는 점이에요. 생성된 회고는 문서 도구의 일별 페이지에 계속 쌓이기 때문에 입력 단계에서 계획과 실적을 혼동하면 잘못된 성과 기록이 장기 데이터로 남아요.

계획과 실적을 별도 입력으로 구성했다

이번 변경의 핵심은 모델에 더 강한 표현을 요구하는 게 아니라 모델이 판단할 수 있는 입력 구조를 만드는 일이었어요. 새로운 회고 입력 formatter는 입력을 계획과 실적, 두 섹션으로 나눠요.

[기간] YYYY-MM-DD
### 계획 (업무 계획 — 의도이지 실적이 아니다)
- 수집 실패 대시보드 검증
- 데이터 규칙 파싱 확인
### 실적 (머지된 PR 1건)
- 업무 저장소의 PR: 데이터 규칙 저장
(+412/-88, 14파일, merged YYYY-MM-DD)

계획 섹션에는 무엇을 하려고 했는지를 담고, 실적 섹션에는 해당 기간에 실제로 머지된 PR만 담아요. 각 PR에는 저장소 역할, PR 식별자를 대신하는 일반 참조, 제목, 추가·삭제 줄 수, 변경 파일 수, 머지 날짜가 들어가요.

이 구조를 쓰면 모델은 최소한 다음 세 가지를 구분할 수 있어요.

여기서 merged PR은 작업 완료 여부를 판단하는 운영 근거예요. 추가·삭제 줄 수나 파일 수가 곧 업무 임팩트를 뜻하지는 않지만, “실제로 어떤 변경이 머지됐는가”와 “얼마나 큰 변경이었는가”를 추측 없이 설명해 주는 정량 데이터예요.

기간 경계를 작업 기준일에 고정했다

자동 작업은 재시도될 수 있어요. 자정을 넘겨 재시도한 뒤 현재 시각을 기준으로 조회하면 회고 대상 기간과 코드 호스팅 서비스의 조회 기간이 달라질 수 있어요.

이를 막으려고 일일 회고는 작업 실행 기준 시각을 바탕으로 KST 00시부터 다음 날 00시까지 조회해요. 주간 회고는 같은 기준일의 6일 전 KST 00시부터 다음 날 00시까지 조회하고요. 코드 호스팅 서비스를 조회할 때는 시작 시각뿐 아니라 종료 시각도 지정하도록 바꿨어요.

merged:{startIsoDate}..{endIsoDate}

머지 날짜를 출력할 때도 UTC 문자열에서 날짜 부분만 잘라 쓰지 않고 Asia/Seoul 기준으로 변환해요. 예를 들어 UTC 기준 전날 밤에 머지된 PR이 KST 기준으로는 다음 날 실적이라면 회고에도 다음 날로 기록해요.

근거가 없거나 불완전하면 숨기지 않았다

근거 기반 시스템에서는 성공 경로보다 실패 경로가 더 중요해요. 조회 실패를 빈 배열로 바꾸면 “조회하지 못했다”와 “실제로 PR이 없다”를 구분할 수 없기 때문이에요.

실제로 merged PR이 없을 때는 다음과 같이 기록해요.

### 실적 (머지된 PR 0건)
- 이 기간에 머지된 PR이 없다.
계획 항목의 완료를 단정할 근거가 없다.

코드 호스팅 서비스의 환경 변수가 없거나 API 조회에 실패하면 별도 상태로 표시해요.

### 실적 조회 불가
- 코드 호스팅 서비스 조회 실패: ...
- 계획만으로 회고하며, 완료·정량 근거를 단정하지 않는다.

코드 호스팅 서비스 조회에 실패해도 전체 회고까지 실패하지는 않아요. 회고 생성은 계속하되 근거가 없다는 사실을 입력에 남기는 best-effort 방식이에요.

부분 조회 실패도 따로 처리했어요. 검색된 PR 가운데 일부의 상세 정보만 가져오지 못한 채 정상 실적으로 전달하면 불완전한 목록이 완전한 목록처럼 보일 수 있거든요. 자동 회고 경로에서는 상세 조회에 한 건이라도 실패하면 예외를 발생시키는 옵션을 사용해 전체를 “실적 조회 불가” 상태로 전환해요.

정확하지 않은 일부 실적을 보여주기보다 불확실성을 그대로 드러내는 쪽을 택했어요.

조회 한도도 불확실성으로 표현했다

프롬프트가 무한정 길어지지 않도록 일일 회고에는 최대 30건, 주간 회고에는 최대 60건의 PR을 표시해요.

기존 코드 호스팅 서비스 연동 계층은 전체 검색 건수를 반환하지 않아요. 결과가 한도에 정확히 도달하면 PR이 더 있는지 알 수 없기 때문에 formatter는 전체 건수를 임의로 단정하지 않아요.

- 조회 한도 30건 도달 — 추가 머지 PR이 생략되었을 수 있음

자동 평가에서 중요한 건 모든 숫자를 채우는 일이 아니에요. 시스템이 알지 못하는 범위를 명시하는 일도 증거 설계의 일부예요.

프롬프트를 새로운 증거 구조에 맞췄다

입력만 분리하고 기존 프롬프트를 그대로 두면 앞뒤 지시가 충돌할 수 있어요. 기존 프롬프트의 “사용자가 오늘 한 일을 자유 텍스트로 제시한다”는 전제를 계획·실적 구조도 받을 수 있도록 바꿨어요.

다음 두 가지 규칙도 추가했어요.

단순히 모델에 조심해서 쓰라고 당부하는 데 그치지 않고, 어떤 입력이 의도이며 어떤 입력이 관찰된 사실인지 계약으로 정의했어요.

구현 결과와 아직 확인하지 못한 범위

실제로 코드 호스팅 서비스를 조회한 결과, 일일과 주간에 걸쳐 여러 건의 merged PR이 입력에 조립됐어요. 조회한 PR은 여러 저장소에 걸쳐 있었고, 상세 조회를 통해 추가·삭제 줄 수와 변경 파일 수도 채웠어요. 정량 필드가 모두 0으로 남은 PR은 없었어요.

검증 과정에서는 formatter의 정상·0건·조회 실패·표시 한도·KST 날짜 경계와 일일·주간 작업의 코드 호스팅 서비스 조회 조건을 테스트했어요. 최종 기록을 기준으로 lint, TypeScript 검사, build와 전체 test가 통과했고, 전체 일반 테스트와 의존 관계 그래프 테스트도 통과했어요.

기존 수동 회고 입력 경로는 건드리지 않았어요. 새로운 환경 변수나 DB 스키마 변경도 추가하지 않았고, 기존 영향도 보고서용 코드 호스팅 서비스 설정을 재사용했어요.

다만 이번 변경으로 회고 품질이 개선됐다고 완전히 입증한 것은 아니에요. 변경 작성 시점에는 실제 cron 실행에서 모델이 새 입력을 받아 어떤 정량 결과를 생성하는지 아직 관찰하지 못했어요. 확인된 결과는 “모델에 계획과 실제 실적을 분리해 전달하고, 근거 부재와 조회 실패를 숨기지 않는 구조가 구현됐다”는 범위까지예요.

업무 계획 실행 기록이 전혀 없는 날에는 기존 early return 때문에 회고가 생성되지 않는 제약도 남아 있어요. “계획 없이 완료한 일”은 업무 계획이 존재하는 기간에는 찾을 수 있지만, 계획 실행 자체가 없었던 날까지 완전히 지원하는 일은 후속 과제로 남았어요.

자동 회고의 핵심은 증거 계약이다

자동 회고가 신뢰를 잃는 순간은 모델이 문장을 잘 쓰지 못할 때가 아니에요. 계획, 시도, 완료, 실패를 같은 입력 안에서 구분하지 못할 때예요.

이번 변경을 통해 남은 원칙은 다음과 같아요.

자동 성과 평가의 품질은 화려한 요약이 아니라 입력 근거의 경계에서 결정돼요. 무엇을 했는지만이 아니라 무엇을 확인하지 못했는지까지 기록해야 자동 회고가 계획서를 재서술하는 도구에서 검증 가능한 업무 기록에 가까워질 수 있어요.


이 글 고치기
이 글 공유하기:

이전 글
실패를 성공으로 기록하면 재시도는 시작되지 않는다