사용기 - 맥에서 Codex 앱 경험하기

 https://openai.com/ko-KR/codex/get-started/ 방문하여 맥용 앱을 다운로드하여 설치하였다. (지금은 윈도우즈 버전까지 출시되었다.)

처음 앱을 실행하면 Select a project 창이 보여지는데, 로컬에 존재하는 여러 Git 프로젝트 목록을 보여주고 선택하게 하는 것이 처음 사용하는 사용자에게는 도움이 될 것 같다.

VisualStudio Code 에서 Codex 확장을 사용하여 코딩에 활용하고 있었는데 Codex 앱은 좌측에 이들 프로젝트 목록(앞선 Select a project 에서 선택함 ) 과 그동안 해당 프로젝트에서 입력했었던 프롬프트까지 모두 보여준다. 또한 작업중에도 프롬프트는 계속 입력이 가능한데 입력된 프로프트들은 스티어링(Steering) 상태가 되는데 진행 중인 프롬프트가 완료되면 바로 이어서 진행하게 된다.  이점은 미리 다수의 프롬프트를 순차적으로 입력해두면 이어서 연속적으로 작업을 수행하는 점이 좋았다. 

스티어링(Steering)은 “처음부터 다시 시키지 않고, 지금 하던 작업에 추가 지시를 넣어 방향 수정하는 것”으로 조금 더 구체적으로 보면, Codex App Server 문서에는 turn/steer 가 있고, 이것은 현재 실행 중인 turn에 사용자 입력을 덧붙여 새로운 turn을 만들지 않고 계속 진행하게 하는 방식이라고 한다.

모델은 응답 속도 이슈로 GPT-5.2-Codex Low 을 사용했다. 사실 High 모델을 사용해도 별 품질 차이를 느끼지는 못했지만 속도는 매우 느렸다. 사용 과정에서 모델이 추가되어 GPT-5.3-Codex Low 를 주로 사용하게 되었다.

테스트 과정에서 사용한 코딩 환경 및 목표는 아래와 같다.

1. eGovFrame 4.3.0 (Spring 5.3.37, Spring Security 5.8.13) + 자체 프레임워크 기반 웹 프로그램을
2. 전자정부 프레임워크 와 자체 프레임워크 기반의 웹 프로그램을 스프링 부트 기반으로 변경
3. 자체 프레임워크는 최신 버전으로 다시 적용, 적용 불가시 신규 코드 작성하여 적용.
4. UI 부분의 오류 제거 및 중복 파일 삭제. 특희 kendoui 관련 부분 최적화.
5. 패키지 명 등 구조 리팩토링 (유지보수를 고려하여)

코딩 진행은 프로젝트의 단일 스레드가 아니라  context window 크기를 고려해서 작업 단위를 다음과 같이 쪼게서 다중 스레드로 진행했다. 참고로 context window 는 지금 스레드(세션) 에서 사용중인 대화전체 기억을 의미하는데 메뉴에서는 아래와 같은 형태로 보여주고 있다.

위 화면에서 현 코덱스의 최대 258k 토큰을 기억할 수 있고 지금 까지 176k 토큰 기억 메모리를 사용중이라는 의미이다. 

• 기존 프로젝트 구조 분석을 통한 리팩토링(가능한 기존 구조 유지).
• 리팩토링 결과물 디버깅을 통한 런타임 오류 수정.
• 새로운 자체 프레임워크 적용 (단계적 기존 모듈 삭제).
• 업무모듈 리팩토링 기준 설정 및 리팩토링 진행.
• 리팩토링 결과물 검토에 따른 코드 개선.
• 코드 기반 수정에 따른 UI (jsp) 런타임 오류 수정.

각 스레드가 이전 스레드 작업 또는 다른 스레드 작업의 이력을 확인 할 수 있게 작업 후에는 README, CHANGELOG, TODO 등의 문서를 작성/업데이트 하게 했다. 스레드가 다른 스레드 작업을 이어 계속 진행할 수 있도록 문서화는 최종 목표, 진행 현황등을 파악 할 수 있데 작성을 지시했다.

또한 코딩 성능 개선을 위해서 OpenAI의 창립 멤버이자 전 Tesla AI 이사인 안드레 카파시(Andrej Karpathy)가 신경망(Neural Networks) 및 딥러닝 모델을 훈련하고 디버깅할 때 제안한 핵심 원칙과 모범 사례(Best Practices) 파일은 SKILL.md 파일을 추가하여 항상 가이드 라인을 준수하게 했다. 적용 후 처음은 그 차이를 인지하지 못했지만 작업을 반복하는 과정에서 codex 가 작업의 범위를 축소하고 언제가 작은 단위로 쪼게서 작업을 수행하는 것을 확인 할 수 있었다. 이런 이유에서 계속해서 프롬프트를 입력하여 다음 작업을 진행하도록 해야 했다.

예상보다 작업 속도와 품질은 매우 높았다. 예를 들면 기존 스프링 프레임워크 환경에서 xml 로 정의된 컨텍스트 파일들을 java 코드로 변경하는 작업의 경우 기존 코드와의 연관성 등을 고려하면 상당한 난이도 작업이지만 큰 실수 없이 코드 만들어 낸다. 

주의할 것은 반복적으로 개선 작업을 진행하는 과정에 이미 완료된 코드도 같이 수정하는 경우가 많아 다시 확인해서 보완 조치 하는 경우가 빈번하게 발생한 것은 많은 집중을 요구했다.

결국 작업을 반복하여 지속적으로 코드를 개선하는 경우는 중간 중간 품질을 확인하고 잘못된 점을 지적해야 했다. 

어느 정도 리팩토링 작업이 완료되고 UI 기능을 변경하는 작업을 해보았다. 화면의 경우 더 쉽게 처리하는 것 같다. 예를 들어 기존에 어떤 메뉴는 로그인 전에 클릭하면 로그인 창을 보여주었는데 어떤 메뉴는 경고 후 메인 페이지로 이동으로 구현되어 있는것을 수정해달라고 요청했고 결과(작업속도, 품질)는 만족스러웠다. 

코딩 이외의 작업도 진행했는데, 로컬 도커에 이미 설치된 mysql 에  연결된 개발 서버 디비의 모든 데이터를 포함하여 이관해달라고 작업을 요청해보았다. 작업을 위한 몇번의 권한 요청을 했고, 진행 과정에서 오류가 발생하면 바로 해결방안을 찾아서 작업을 이어 진행했다. 이관 완료 후에는 검증을 위하여 테이블 과 데이터 건수 검증까지 이어서 처리했다, 이 모든 작업을 스스로 진행하고 작업을 위한  권한 요청에 대한 승인 만허용하여 데이터 이관을 완료 했다. 

마지막으로 Codex 사용에 있어 주요했던 것은 정책(코딩 규칙)을 수립하고 규칙에 따라 작업을 진행할 것을 요청한 점이였다.