Codex
Codex와 함께 작은 기능을 개발해 본 기록
요구사항 정리부터 코드 검토와 빌드 확인까지 Codex를 개발 워크플로에 적용하며 느낀 장단점을 정리합니다.
AI 코딩 도구를 평가할 때는 생성된 코드의 양보다 요구사항을 얼마나 정확히 지키고 검증 가능한 결과를 남기는지가 더 중요합니다. 작은 정적 사이트 기능을 만들며 작업 흐름을 관찰했습니다.
테스트 방법
작업을 요구사항 분석, 기존 코드 탐색, 구현, 정적 검사, 빌드 검증으로 나눴습니다. 각 단계에서 변경 이유와 실패 원인을 확인할 수 있는지를 살폈습니다.
좋았던 점
반복 작업이 빨라진다
여러 페이지에 같은 메타데이터 규칙을 적용하거나 비슷한 테스트 사례를 추가하는 작업에서 시간을 줄일 수 있었습니다.
검증까지 연결하기 쉽다
완료 조건에 빌드와 테스트 명령을 명시하면 구현 뒤 바로 오류를 찾아 수정하는 흐름을 만들기 좋았습니다.
아쉬웠던 점
모호한 요구사항은 결과도 흔들린다
“깔끔하게 만들어 달라”처럼 판단 기준이 없는 표현은 구현 범위를 불필요하게 넓힐 수 있습니다. URL, 화면, 완료 조건을 구체적으로 적을수록 결과를 검토하기 쉬웠습니다.
최종 책임은 사용자에게 있다
라이브러리 버전, 보안 설정, 콘텐츠의 사실 관계처럼 시간이 지나며 바뀌는 정보는 반드시 공식 문서와 실제 실행 결과로 다시 확인해야 합니다.
추천하는 사용 방식
- 먼저 작업 범위와 제외 범위를 적습니다.
- 성공 여부를 판단할 명령이나 화면을 정합니다.
- 작은 단위로 변경하고 diff를 검토합니다.
- 자동 검사와 직접 사용 테스트를 모두 수행합니다.
결론
Codex는 개발자를 대신하는 자동 완성보다 함께 저장소를 살피고 검증하는 협업 도구로 접근할 때 장점이 선명했습니다. 특히 정적 검사와 테스트가 갖춰진 프로젝트에서 활용하기 좋습니다.