코덱스 툴 사용법 03: 안전 실행과 검증 루프 | DAKER 커뮤니티

코덱스 툴 사용법 03: 안전 실행과 검증 루프

코덱스를 잘 쓰는 팀은 "빨리 수정해줘"보다 "수정 후 무엇으로 증명할지"를 먼저 정한다. 코덱스는 파일을 바꾸고 명령을 실행할 수 있기 때문에, 작은 패치와 빠른 검증 루프를 붙여야 안정적인 작업 에이전트가 된다.

1. 코덱스에게 완료 기준을 먼저 준다

좋은 요청은 작업과 검증이 한 문장 안에 같이 들어 있다.

로그인 버튼의 loading 상태가 두 번 눌리지 않게 고쳐줘.    아래 작업은 바로 실행하지 말고 먼저 위험도를 설명해줘.
- 데이터 삭제
- 운영 배포
- 토큰, 쿠키, 비밀값 출력
- 요청하지 않은 대규모 리팩터링   이 기준을 프롬프트나 AGENTS.md에 넣어두면 반복 작업에서도 안전성이 올라간다.  3. 실패 로그는 그대로 붙인다  테스트가 실패하면 "안 돼"라고 말하기보다 실패 로그의 핵심 줄을 그대로 준다. 코덱스는 스택 트레이스, exit code, 재현 명령이 있을 때 훨씬 정확하게 움직인다.   명령: npm test -- login-button.test.ts
결과: expected button to be disabled, received enabled
이 실패만 먼저 고치고 다른 파일은 건드리지 마.   4. 완료 보고는 증거 중심으로 받는다  마지막 보고에는 "무엇을 바꿨는지"보다 "무엇으로 확인했는지"가 있어야 한다. 예를 들어 `npm test`, `npm run lint`, 공개 API 200, Playwright screenshot 같은 증거다. 검증을 못 했다면 그 이유도 같이 남겨야 다음 사람이 이어받을 수 있다.  Senior takeaway: 코덱스는 수정 능력보다 검증 루프와 함께 쓸 때 가치가 커진다. 작은 변경, 즉시 테스트, 실패 축소, 증거 보고를 한 묶음으로 만들면 바이브코딩이 실제 팀 워크플로우로 바뀐다. 
수정 후 관련 테스트를 실행하고, 실패하면 원인을 좁혀서 다시 고쳐줘.
마지막에는 변경 파일과 검증 결과만 짧게 보고해줘.

이렇게 쓰면 코덱스가 단순히 코드를 바꾼 뒤 멈추지 않고, 결과를 확인하는 방향으로 움직인다.

2. 위험한 명령은 게이트를 둔다

자동 실행을 맡겨도 삭제, 운영 배포, 비밀값, 요청 범위 밖 변경은 별도 게이트로 봐야 한다. 코덱스가 이런 작업을 하려면 목적과 영향 범위가 명확해야 한다.