에이전트가 짠 코드가 늘수록 잘 짜느냐보다 "다 됐습니다"를 어디까지 믿느냐가 문제가 됐다. 7월 실주문 경로도 Codex가 짰고 리뷰와 검증까지 같은 에이전트가 했다. 그래서 9월에 규칙과 역할, 검증 방법을 정해 코드와 같이 버전 관리하기 시작했다. Claude Code와 Codex가 같은 규칙과 역할을 따른다.
| 역할 | 하는 일 | 수정 범위 | 모델 (Claude / Codex) |
|---|---|---|---|
| lead | 범위 판단, 작업 분배, 통합. 작은 수정은 직접 | 전체 | Opus 5.5 / GPT-6 Sol |
| scout | 코드 경로와 영향 범위 조사 | 읽기만 | Sonnet 5 / GPT-6 Luna |
| backend | API·DB·트레이딩 로직 구현 | 서버·DB·테스트 | Opus 5.5 / GPT-5.6 Terra |
| frontend | 대시보드 구현 | 화면 | Opus 5.5 / GPT-5.6 Terra |
| qa | 돈이 걸린 변경의 테스트를 구현과 따로 작성 | 테스트만 | Opus 5.5 / GPT-6 Sol |
| reviewer | 돈이 걸린 변경 리뷰 | 읽기만 | Opus 5.5 / GPT-6 Sol |
실주문·청산·거래 모드·인증을 건드리는 변경은 누가 짰든 qa와 reviewer를 거친다. 조사는 가벼운 모델에, 리뷰는 제일 센 설정에 맡겼다.
| 용도 | 스킬 | 언제 쓰나 |
|---|---|---|
| 분석 | gitnexus-exploring, gitnexus-impact-analysis | 코드 구조 파악, 고치기 전 영향 범위 확인 |
| 디버깅 | systematic-debugging, gitnexus-debugging | 버그·테스트 실패. 원인부터 찾고 고친다 |
| 수정 | surgical-patch | 원인을 안 뒤 가장 좁은 곳만 고칠 때 |
| 리팩터링 | safe-refactor, gitnexus-refactoring | 동작은 그대로 두고 구조만 바꿀 때 |
| 검증 | verification-before-completion, verify-and-stop | 완료를 말하기 전, 검증만 요청받았을 때 |
| 도구 | gitnexus-guide, gitnexus-cli | 코드 그래프 사용법과 인덱싱 |
린트 → 테스트 → 앱 기동 → 설정 대조를 명령 하나로 돌리고 결과를 파일로 남긴다. 보고는 이 파일 값으로만 한다. 규칙 대부분은 실제로 걸린 뒤에 생겼다.
| 겪은 일 | 그래서 넣은 규칙 |
|---|---|
| 테스트는 전부 통과했는데 앱이 안 떴다 | 앱 기동 확인 추가. 테스트가 0건 돌아도 실패로 친다 |
| 코드 그래프가 주문 함수의 호출자 두 곳을 놓쳤다 | 호출자 0건이 나와도 텍스트 검색으로 다시 확인 |
| Codex가 프로젝트 설정을 무시하고 기본 모델로 돌았다. 경고 없이 | 모델을 바꾸면 한 번 실행해 기록의 모델명 확인 |
테스트 중에는 외부 네트워크를 막아 Upbit이나 유료 LLM을 실수로 부르지 않는다. push하면 GitHub Actions가 PostgreSQL을 띄워 한 번 더 확인한다.