AgentFlow

완료라고 부르기 전에 확인하는 것

작업마다 그 작업에만 집중하는 세션을 따로 두고, 결과를 검토하는 세션도 따로 나눴습니다. 한 세션이 여러 작업과 검토를 함께 맡으면 작업별 능률이 떨어지고 환각이 생기기 쉬워서, 각 세션이 맡은 일에만 집중하게 했습니다.

계획·개발·QA·Wiki 승인과 현재 후보의 해시를 모두 확인한 뒤에만 완료로 전환합니다. 검수 결과는 대상과 후보 해시뿐 아니라 보관된 입출력 기록과도 맞는지 검사합니다.

승인한 뒤에 파일이 바뀌면

QA가 실패하면 복구 개발로 돌아가고, 제품 코드가 바뀌면 기존 QA 승인이 아직 유효한지 다시 검사합니다.

만든 쪽과 확인하는 쪽을 나누기

독립 QA는 개발한 작업자와 다른 작업자가 맡아야 합니다. 필수 시나리오마다 행동·기대값·관측값과 UI 캡처 또는 CLI 로그가 있어야 통과합니다.

다만 캡처 형식이나 작업자 식별자 검사는 화면 조작과 관측의 의미까지 증명하지 않습니다. 그 판단은 Master의 검토로 남깁니다.

검수는 AI가 자동으로 진행하고, 제 판단이 필요한 지점에서는 Master가 저에게 질문해 승인을 받습니다. 검수 기준은 언제든 추가할 수 있고, 최종 결과는 제가 직접 확인합니다. Master가 정한 검수 기준에 제가 필요한 기준을 더할 수 있고, 진행 중 어느 단계에서든 직접 개입할 수 있게 해 두었습니다.

병렬 작업과 순차 통합

병렬 개발은 선행 작업 완료, 읽기·쓰기 범위, 공유 자원 충돌을 확인한 뒤 작업공간을 따로 준비합니다. 결과를 모은 상태는 승인이 아니고, 범위 밖 수정·동결 결과 변조를 검사한 뒤 하나씩 통합하고 다시 검수합니다.

사용 한도 때문에 기다렸다가 다시 시작할 때도 예정 시각·후보·승인 해시·남은 질문을 다시 확인합니다. 요청한 모델 설정과 실제로 관측한 실행값은 구분하고, 확인할 수 없는 값은 unknown으로 남깁니다.

Wiki를 한곳에 모으고 보존하기

문서를 한곳에 모아 편하게 관리하고 보기 위해 Wiki를 중앙화했습니다. 제가 필요한 내용을 빠르게 찾을 수 있고, AI에게 일을 맡길 때도 참조할 문서를 정확히 건넬 수 있으며, AI가 여러 곳에 흩어진 문서를 읽다가 혼란을 겪지 않습니다.

프로젝트별 Wiki를 중앙 저장소로 모으고 GitHub에 보존했습니다. 기록은 프로젝트 이름 대신 UUID와 명시적인 소스 연결로 찾고, 실행할 때 참조한 Wiki 입력은 스냅샷으로 남깁니다.

중앙 Wiki에는 승인받은 Markdown 변경만 반영합니다. 기준본이 달라졌거나 목록에 없는 변경이 섞이면 중단하고, 같은 입력으로 복구합니다. 문서 자동화는 선언된 자동 영역만 갱신하고 사용자 메모와 확정된 결정은 건드리지 않습니다.

서비스 개발에 적용하기

Make A Wish를 개발할 때 AgentFlow를 사용해 공격적인 입력 QA와 디자인 교차 검토를 작업 절차에 넣었습니다. 이것은 적용 사례이며, 공격 방어를 보장하거나 품질 향상률을 측정한 결과는 아닙니다.

부스 스탬프 화면의 별 모양 테두리 점선 간격이 디자인본과 다르게 구현된 적이 있습니다. 검수 에이전트를 추가로 만들어 실제 코드와 스크린샷을 함께 검수하게 했고, 그 뒤로 디자인과 화면을 맞춰 가며 작업을 이어갔습니다.