사용기 - 맥에서 클로드 코드(Claude Code) 사용하기 : Codex와 비교한 실사용 후기

클로드 역시 코덱스와 같이 무료 플랜에서는 코딩 기능(Claude Code) 사용이 불가 하고 유료 플랜에서만 가능하다. 클로드 코드는 터미널, VSCode , Desktop app, Web, JetBrains 을 지원하고 있다.  테스트는 클로드 앱으로 진행했다. Desktop app 은 유료로 플랜을 업그레이드 하면 Code 탭이 활성화 되며 이를 클릭하고 로컬 저장소를 지정하는 것올 시작으로 바로 코딩 작업을 진행할 수 있었다.

유료 플랜은 Pro 요금제를 사용했다. 5시간 단위/주간 단위 사용량 제한 정책에 따라 가벼운 작업은 가능하지만 본격적인 코딩에는 무리가 있었고, 여러 테스트를 진행하는 과정에서 여러번 사용 제안이 걸려 추가로 $20 에 해당하는 토큰을 3회 구매해서 사용했다.

클로드는 기본적으로 실사용 인상으로는 작업을 여러 단계로 나눠 처리하는 듯한 흐름이 있었고, 그만큼 토큰 사용량이 커진다고 느꼈다. 코딩 성능은 확연하게 멀티 즉 서브 에이전트를 사용하는 것과 하지 않는 것에는 차이가 발생한다. 여러 단계의 중간 결과가 정리되면서 응답 품질이 더 안정적으로 느껴졌고, 개인적으로는 그것이 결과 차이에 영향을 준다고 보았다. (컨텍스트 오염 최소화)

오류 해결 테스트 (코덱스와 클로드)

비교를 통한 성능 측정을 목적으로 간단하게 런타임 오류 메시지에 대한 분석을 각각 ① Claude Sonnet 4.6 , ② GPT-5.4 (reasoning effort : medium) 을 사용하여 진행했다. 두 모델 모두 원인 분석 자체는 유효했지만, 이번 테스트에서는 Claude Sonnet 4.6 쪽이 번호와 표를 더 적극적으로 사용해 결과를 읽기 쉽게 정리해 주는 인상이 있었다.

코덱스 (GPT 5.4 medium) 답변

클로드 (Sonnet 4.6) 답변

“Claude는 분석만 요청했는데도 수정 방향까지 적극적으로 제안했다. 상황에 따라서는 장점이지만, 순수 분석만 원할 때는 과한 개입으로 느껴질 수 있었다.”( 아마도 코덱스의 경우는 호환 정책 파일들이 있어 발생한 것은 아닌가 하는 의심도 있다.)

기존 코드 기반 계획 수립 테스트 (코덱스와 클로드)

다음으로 소스 코드 분석을 실행하고 결과를 비교해 보았다. 

"*** 는 사용자 시스템 구현에 의존하지 않고 사용자를 식별할 하기 위한 계약이다. 이 모듈 코드를 좋은점, 나쁜점, 개선점 측면에서 분석하고 결과를 보여줘."

Claude (Sonnet 4.6) 답변

Codex (GPT 5.4 medium) 답변

결과가 예상과는 달랐는데 나쁜점의 경우 모두 거의 유사한 내용을 언급하고 있지만 좋은점과 개선점에서는 차이점이 있었다. 답변은 모두 코드에 근거하여 답변을 하고 있었다. 

이번 테스트 기준으로 클로드는 ‘바로 손볼 포인트를 빠르게 정리해 주는 리뷰’에 가까웠고, 코덱스는 ‘왜 그렇게 바꿔야 하는지까지 설명하는 리뷰’에 가까웠다. 이번 항목에서는 개인적으로 코덱스 쪽 답변이 더 좋았다. 특히 구조적 설명과 개선 논리 제시에 강점이 있었다고 느꼈다.

① 클로드

구체적인 결과 = 항목화된 판정 + 예시 코드 즉,

• 무엇이 좋은지
• 무엇이 나쁜지
• 무엇을 바꿔야 하는지

를 표와 목록으로 끊어서 보여준다. (정리본 형태)

② 코덱스

구체적인 결과 = 모듈 의도 + 실제 사용처 + 개선 논리 즉,

1. 이 모듈이 왜 존재하는지
2. 실제로 어디서 어떻게 쓰이는지
3. 그래서 어떤 혼란이 생길 수 있는지

를 설명 흐름 안에서 보여준다. (리뷰 대화록 형태) 

협업 테스트(코덱스와 클로드)

이번 테스트는 ① 클로드와 ② 코덱스 모두에게  코드 분석을 요청하고 ① 클로드의 경우 추가로 문서화 생성을 요청하고 해당 문서를 ② 코덱스에게 검토 및 보완을 요청했다. 마지막으로 다시 수정된 문서를 ① 클로드를 통하여 검증하는 작업을 진행했다. 아래는 최종 검증에 있어 코덱트의 출력 화면이다. 

이번 실험에서는 단일 모델 하나만 쓰는 방식보다, 서로 다른 모델의 장점을 교차 활용하는 편이 결과를 더 안정적으로 만드는 가능성을 보였다. 서브 에이전트와 같은 기능을 적극적으로 쓰지 않고 프롬프트 중심의 단순 작업만 놓고 보면, 이번 체감상 코덱스보다 클로드가 더 일을 잘한다고 느껴졌다. 

 

이슈 기반 개발

테스트에 앞서 코덱스에서 분석 및 작업 계획 테스트를 통하여 이슈를 생성하였고 클로드에서는 이미 생성된 특정 이슈를 기준으로 실제 구현 작업을 진행해 보았다. (개발은 언제나 항상 분석/설계 > 이슈 등록 > 구현 > 테스트 > PR 생성 > 리뷰 > 머지 순서로 하고 있다.) 

다음은 이슈 기반을 개발을 위하여 클로드에게 작업 가능성 확인 결과이다.

이슈 #163 에 대한 작업이 가능한가.

작업 이슈 내용을 바탕으로 기존 파일을 분석하여 수행했다. 

작업 완료 후 커밋과 PR 생성을 요청했고 해당 PR 을 코덱스가 검토하게 했다. 코덱스 검토 결과 1가지 문제가 발견되었고 이를 다시 클로드가 조치하도록 했다. (전후 맥락이 없는 상태에서 리뷰를 진행할 때는 좀더 많은 시간이 소요됨을 체감했다.) 

리뷰 결과를 클로드에서 입력하면 해당 내용을 확인하고 잘못 수정함을 인정하고 바로 수정까지 완료했다. (리뷰의 중요성이 확인됨)

조치결과에 대하여 클로드에 다시 확인 요청을 한 결과 처리됨을 바로 확인해주었다. (이전 맥락이 있어 이번에는 바로 응답함)

정리하면, 이번 테스트 기준으로 Claude는 정리형·실무형 리뷰에 강했고, Codex는 설명형·구조형 리뷰에 강했다. 따라서 둘 중 하나만 고르기보다, 분석·문서화·교차 검토 흐름으로 함께 활용할 때 더 큰 장점이 있을 수 있다고 본다.

사용기 - 코덱스(Codex)에서 서브에이전트(Subagents) 활용하기

Subagents란, Codex가 하나의 큰 작업을 여러 개의 작은 작업으로 나누어 각각 별도의 보조 에이전트에게 맡긴 뒤, 그 결과를 다시 통합하는 병렬 작업 방식이다. 복잡한 작업, 코드베이스 탐색, PR 리뷰 처럼 여러 항목을 동시에 볼 때 특히 유용하다고 한다. OpenAI 개발자 가이드

서브에이전트(subagent)는 언제 어떻게 사용하나

공식 문서에 따르면 컨텍스트 창(에이전트의 스레드 기억 공간)이 크더라도 요구사항, 제약조건, 의사결정 같은 핵심 정보 사이에 탐색 노트, 테스트 로그, 스택 트레이스, 명령 출력 같은 중간 결과가 과도하게 섞이면 모델의 응답 품질과 세션 신뢰성이 점차 떨어질 수 있다고 한다.  이런 문제는 중요한 정보가 잡음에 묻히는 맥락 오염과, 관련 없는 세부 정보가 많아지면서 판단 성능이 저하되는 맥락 왜곡으로 설명할 수 있다. (Context Rot: How Increasing Input Tokens Impacts LLM Performance) 

서브에이전트 워크플로(Codex가 병렬 에이전트를 실행하고 그 결과를 결합하는 워크플로)는 이러한 잡음을 메인 스레드에서 분리하여, 메인 에이전트는 핵심 요구사항과 최종 결과에 집중하고, 탐색·테스트·로그 분석 같은 읽기 중심 작업은 하위 에이전트가 병렬로 처리한 뒤 요약만 반환하도록 돕는다. 다만 병렬 에이전트는 읽기 작업에는 효과적이지만, 여러 에이전트가 동시에 코드를 수정하는 쓰기 중심 작업에서는 충돌과 조정 비용이 커질 수 있으므로 더 신중하게 운영해야 한다.

즉 맥락 오류가 커질수 있는 큰 작업을 여러 덩어리로 나눌 수 있을 때 좋은 결과를 예상할 수 있는데. 예를 들면 “보안”, “버그”, “코드 품질”, “테스트 불안정성”을 각각 따로 검사시키는 식이다. Codex는 용사자가 명시적으로 요청할 때만 서브에이전트(subagent)를 실행한다. 그리고 서브에이전트(subagent)가 늘어나면 그만큼 모델 호출과 도구 사용이 늘어서 토큰 비용도 더 많이 발생한다. 

 Prompt 예시  

다음 작업을 subagent로 분할해줘.
- explorer 1개: 인증 구조 파악
- worker 1개: 로그인 API 구현
- worker 1개: 테스트 추가
- default 1개: 전체 결과 통합 정리
모든 작업이 끝난 뒤 최종 보고서를 작성해.

“명시적으로 요청”한다는 것은, Codex가 알아서 subagent 를 만들 거라고 기대하는 것이 아니라, 프롬프트 안에 spawn, one agent per point, explorer subagent 를 생성, worker를 사용처럼 분업 지시를 직접 써주는 것이다.

 

Codex는 중간 관리자 역할을 수행

어떤 서브에이전트(subagent)를 띄울지, 후속 지시를 어떻게 줄지, 결과를 언제 모을지 등을 Codex가 조율하고 마지막에는 결과를 합쳐서 하나의 응답으로 보여주는 역할을 한다. 

 Prompt 예시  

현재 브랜치와 main을 비교해서 PR을 검토해.
항목별로 subagent를 하나씩 생성해.
모든 subagent의 작업이 끝날 때까지 기다린 뒤, 항목별 결과를 요약해줘.
1. 보안 이슈
2. 코드 품질
3. 버그 가능성
4. 동시성 문제
5. 테스트 불안정성
6. 유지보수성

 이 프롬프트를 받으면 Codex는 다음을 조율한다.

1. 어떤 서브에이전트(subagent)를 띄울지 정한다.
   예를 들어 보안 검토용, 테스트 검토용, 유지보수성 검토용처럼 항목별 서브에이전트(subagent)를 분리한다. 문서상 Codex는 서브에이전트(subagent)를 생성하고 오케스트레이션하는 역할을 한다.

2. 각 서브에이전트(subagent)에 후속 지시를 전달한다.
   예를 들어 “보안 서브에이전트(subagent)는 인증/인가 흐름을 보라”, “테스트 서브에이전트(subagent)는 누락된 테스트를 찾으라”처럼 작업을 나눠 보낸다. 공식 문서도 Codex가 follow-up instructions를 라우팅한다고 설명한다.

3. 결과를 기다린다.
   여러 서브에이전트(subagent)가 동시에 돌고 있으면 Codex는 요청한 결과가 모두 준비될 때까지 기다린다.

4. 마지막에 하나로 합친다.
   각 서브에이전트(subagent)의 결과를 항목별로 묶어 최종 응답으로 정리해 보여준다. 공식 문서에서는 consolidated response로 설명한다.

Codex 내장 서브에이전트(subagent)

default(범용), worker(구현/수정 중심), explorer(읽기 중심 탐색) 같은 기본 agent가 이미 제공되고 있다. 

• default: 특별히 역할을 안 나눴을 때 쓰는 범용 담당
• worker: 실제 수정, 구현, 정리, 반복 작업 담당
• explorer: 파일 찾기, 구조 파악, 원인 추적 전 단계 담당

 Prompt 예시  

worker를 사용해서 로그인 API를 구현해줘.
요구사항:
- 이메일/비밀번호 로그인
- JWT 발급 포함
- 기존 SecurityFilterChain 구조를 유지
- Controller, Service, DTO까지 구현
- 관련 테스트도 함께 추가
결과는 변경 파일 목록과 함께 요약해줘.

 

커스텀 서브에이전트(subagent)

TOML 파일로 “이 agent는 PR 리뷰 전용”, “이 agent는 문서 조사 전용”처럼 역할을 따로 정의할 수 있다. (최소한 name, description, developer_instructions 필요.)  좋은 서브에이전트(subagent)는 공식 문서에 따르면 “좁고 명확한 역할을 가져야 한다”고 설명하고 있다. 즉, 하나의 서브에이전트(subagent)가 다 하게 하기보다 “코드 탐색용”, “보안 리뷰용”, “문서 조사용”처럼 나누는 게 좋다.

용자 정의 서브 에이전트를 사용하기 위해서 특정 개발 작업을 위해 설계된 특수 AI 보조 도구인 Codex 서브에이전트 의 최종 모음집 저장소 Awesome Codex Subagents 을 활용했다. 

최종적으로는 AI 지원 개발을 일관된 규칙, 템플릿, 자동화 스크립트로 표준화해 배포할 수 있게 만든 DevOps 정책 템플릿 저장소를 구성하여 사용했다. ( https://github.com/andang72/devops-policy-template ) 

먼저 세부 계획을 병렬로

서브에이전트 1: 현재 패키지/모듈 구조 분석 서브에이전트 2: 중복 책임, 순환 의존, 경계 위반 탐지 서브에이전트 3: 테스트 영향 범위와 회귀 위험 분석 서브에이전트 4: 후보 리팩토링 포인트 요약

를 통해서 수립해줘.

이렇게 프롬프트를 작성하면 코덱스는 병렬 작업에 맞게 작업 계획을 수립한다. 

계획이 수립되면 이슈를 등록하게 하고 순서대로 작업을 아래와 같이 특정 서브에이전트에게 진행을 요청한다. 

서브에이전트에 의한 작업은 좌측 스레드 목록이나 하단의 작업 목록 아래의 background agents (@ to tag agents ) 를 통하여 확인 할 수 있다. 

좌측 메뉴

하단 메뉴

서브에이전트를 도입하면 단순 오류 수정이 아닌 기존 코드를 분석하여 기능을 수정하거나 추가하는 경우 확연하게 결과가 개선되는 것을 확인할 수 있었다. 다만 서브에이전트를 사용하는 경우 토큰 소비가 크게 증가하기 때문에 이부분에 대한 사전 고려가 필요할 것 같다.

사용기 - 맥에서 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 사용에 있어 주요했던 것은 정책(코딩 규칙)을 수립하고 규칙에 따라 작업을 진행할 것을 요청한 점이였다.

사용기 - 윈도우에서 AI 코딩 사용하기 (Codex)

과거에는 개발자가 직접 코드를 작성하고 디버깅하는 방식이 일반적이었으나, 현재는 AI가 코드 생성, 테스트, 디버깅, 문서 작성 등 다양한 개발 작업을 지원하는 환경으로 전환되고 있다. 특히 AI 코딩 도구와 에이전트 기반 개발 환경의 확산으로 인해 개발 생산성을 크게 향상시킬 수 있으며, 복잡한 시스템 개발에서도 효율적인 작업이 가능해지고 있다.

이러한 변화에 따라 많은 개발 조직에서는 AI 기반 개발 도구를 적극적으로 도입하고 있으며, 개발 환경 또한 이러한 도구들이 원활하게 동작할 수 있도록 재구성하고 있다. 특히 AI 기반 개발 환경에서는 코드 분석, 자동 테스트, 컨테이너 실행, 인프라 구성 등 다양한 작업이 동시에 이루어지기 때문에 안정적이고 일관된 개발 환경이 중요하다.

많은 기업에서 개발자의 작업 환경으로 Windows 운영체제를 사용하고 있으나, 실제 소프트웨어 실행 환경은 대부분 Linux 기반 서버나 컨테이너 환경에서 운영되는 경우가 많다. 이러한 환경 차이는 개발 단계에서 다양한 문제를 발생시킬 수 있으며, 특히 라이브러리 의존성, 파일 시스템 차이, 실행 환경 차이 등으로 인해 개발과 운영 환경 간의 불일치가 발생할 가능성이 있다.

이러한 문제를 해결하기 위해 Windows 환경에서는 WSL(Windows Subsystem for Linux)을 활용한 개발 환경 구성이 널리 사용되고 있다.

WSL은 Windows 운영체제 내부에서 Linux 환경을 실행할 수 있도록 지원하는 기능으로, 개발자는 Windows 환경을 유지하면서도 Linux 기반 개발 도구와 환경을 그대로 사용할 수 있다. 이를 통해 개발자는 Linux 서버 환경과 동일한 개발 환경을 로컬에서 구축할 수 있으며, 다양한 오픈소스 개발 도구와 패키지를 보다 안정적으로 사용할 수 있다.

특히 AI 기반 개발 환경에서는 Python 기반 AI 도구, 컨테이너 환경, 패키지 관리 시스템 등 Linux 환경에 최적화된 기술들이 많이 사용된다. 예를 들어 AI 모델 실행 환경, 벡터 데이터베이스, 컨테이너 기반 서비스 등은 Linux 환경에서 보다 안정적으로 동작하는 경우가 많다. WSL을 활용하면 이러한 기술을 Windows 환경에서도 동일하게 사용할 수 있어 개발 환경의 일관성을 확보할 수 있다.

또한 WSL 환경에서는 Docker, Kubernetes, Git, Python 패키지 관리자 등 다양한 개발 도구를 Linux 환경과 동일하게 사용할 수 있으며, 이는 AI 기반 개발 도구와의 호환성을 높이는 데에도 중요한 역할을 한다. 최근 등장한 AI 기반 개발 도구들 또한 Linux 환경을 기본 실행 환경으로 가정하고 설계되는 경우가 많기 때문에, WSL 기반 개발 환경은 AI 코딩 도구의 활용성을 높이는 데에도 효과적이다.

개발자는 Windows 환경에서 Visual Studio Code와 같은 개발 도구를 사용하면서도, 실제 코드 실행과 빌드 작업은 WSL 내부의 Linux 환경에서 수행할 수 있다. 이러한 방식은 Windows의 편리한 사용자 환경과 Linux의 안정적인 개발 환경을 동시에 활용할 수 있다는 장점을 가진다. 특히 Visual Studio Code는 WSL과의 통합 기능을 제공하여 Windows에서 실행되는 IDE가 WSL 내부의 Linux 환경에 직접 연결되어 개발 작업을 수행할 수 있도록 지원한다.

이와 같은 구조는 AI 기반 개발 환경에서도 매우 효과적으로 활용될 수 있다. 예를 들어 AI 코딩 도구를 통해 생성된 코드가 Linux 기반 컨테이너 환경에서 바로 테스트되도록 구성하거나, 자동화된 빌드 및 테스트 프로세스를 Linux 환경에서 실행하도록 설정할 수 있다. 이러한 환경은 실제 운영 환경과 유사한 개발 환경을 제공함으로써 개발 과정에서 발생할 수 있는 환경 차이를 최소화하는 데 도움을 준다.



결론적으로 AI 기반 개발 환경을 도입하는 과정에서는 단순히 AI 도구를 사용하는 것뿐만 아니라, 이러한 도구들이 안정적으로 동작할 수 있는 개발 환경을 구축하는 것이 중요하다. Windows 환경을 사용하는 개발 조직의 경우 WSL을 활용한 Linux 기반 개발 환경을 함께 구성함으로써 개발 환경의 일관성을 확보하고, AI 기반 개발 도구와의 호환성을 높이며, 전체 개발 생산성을 향상시킬 수 있다. 이러한 접근 방식은 향후 AI 중심 개발 환경으로의 전환 과정에서도 중요한 기반이 될 것으로 기대된다.

WSL 환경 설치하기 

윈도우에서 "PowerShell" 을  검색창에 입력하면 설치된 경우 PowerShell 터미널을 그렇지 않는 경우는  설치를 위한 Microsoft Store 로 이동한다. 설치를 완료하면 열기 버튼이 활성화 되는데 이를 클릭해도 "PoswerShell" 이 실행된다.

코딩 에이전트(Codex CLI 같은 것)나 레포 자동 빌드/테스트는 윈도우보다 리눅스 환경이 명령 실행/경로/권한 문제가 적어서 안정적이라고 한다. 이런 이유에서 코딩 에어전트 이용을 위해서는 “윈도우에선 WSL2(Windows Subsystem for Linux 2) 권장” 이 자주 언급된다.

 설치 여부는 " wsl -l -v" 명령을 PowerShell 에 입력하여 확인 할수 있다.

wsl --status

wsl -l -v

가장 쉬운 설치 방법은 "PowerShell" 을 관리자 계정으로 실행하고  "wsl -- install" 명령으로 설치 할 수 있다.  특정 배포판 설치도 가능한데 설치 가능 배포한 목록은 "wsl --list --online" 명령으로 확인 가능하다. 이때 wsl 이 설치되어 있지 않았다면 자동 설치한다.

명령을 실행해보면 상당한 수의 배폰본은 지원하고 있음을 알 수 있다. 보통은 우분투를 가장 많이 사용한다고 하며 디폴터 설치 배포본 역시 우분투이다.

설치 전에 상태 확인이 필요한데 " wsl --status" 명령으로 확인 할 수 있다. 

WSL1(리눅스 명령을 윈도우가 번역하여 수행), WSL2 (가상화를 통한 리눅스 지원) 에 대한 활성화 작업이 필요하다. 지금 위의 환경에서는 모두 비활성화 상태이다.

활성화는 PowerShell 을 관리자 권한으로 실행하고 아래 명령을 입력하면 된다.

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

또는 시작 메뉴에서 "Windows 기능 켜기/끄기 를 실행하고 아래 기능을 채크 한다음 윈도우를 재시작 한다.

• 가상 머신 플랫폼(Virtual Machine Platform)
• Linux용 Windows 하위 시스템(Windows Subsystem for Linux)

설치는 PowerShell 을 관리자 권한으로 실행하고  "wsl --install" , "wsl --install -d Ubuntu" 명령으로 할 수 있다. 

설치가 완료되면 계정 생성을 진행하게 된다.  계정생성이 완료되면 가장 먼저 시스템을 업데이트 한다.

sudo apt update

sudo apt upgrade -y

WSL 환경에서 개발 도구 설치하기 

다음 단계는 AI Agent 기반 개발 환경을 만들기 위한 개발 툴 체인을 설치하는 것이다.

1) 기본 시스템 도구

항목	설치 목적	설치 명령	확인 명령
curl	API 호출 및 다운로드	sudo apt install -y curl	curl --version
wget	파일 다운로드	sudo apt install -y wget	wget --version
unzip / zip	압축 파일 처리	sudo apt install -y unzip zip
git	소스 코드 버전 관리	sudo apt install -y git	git --version

2) 자바 개발 환경

항목	설치 목적	설치 명령	확인 명령
OpenJDK 17	자바 실행 환경	sudo apt install -y openjdk-17-jdk	java -version
Gradle	Java 빌드 도구	sudo apt install -y gradle	gradle -v

3) AI 코딩 Agent

항목	설치 목적	설치 명령	확인 명령
Codex CLI	AI 코드 생성 및 수정	npm install -g @openai/codex	codex --help
Aider	AI 코드 수정 도구	pip install aider-chat	aider --help

DE(VS Code)에서 Codex Agent를 설치한다면 WSL에 Codex CLI를 반드시 설치할 필요는 없지만 CLI 가 할 수 있는 작업이 더 많기 때문에 보통은 같이 사용한다. (npm 이 디폴트로 설치되어 있지 않아 sudo apt intall -y npm 명령으로 설치가 필요하다.)

추가로 Ubuntu 22.04 이후부터는 직접 시스템에서 사용하는 Python 을 변경하지 못하게 막고 있어 pipx 사용이 가장 안전한 방법이다. 

sudo apt update
sudo apt install -y pipx python3-venv

pipx ensurepath

터미널을 다시 실행하고 aider 을 설치한다. 

pipx install aider-chat

다음으로 자신의 환경에 필요한 빌드 도구를 설치한다.  Visual Studio Code는  https://code.visualstudio.com/ 에서 다운로드하여 설치 할 수 있다.

IED 도구 vscode 을 사용 중이라면 WSL 확장을 아래 명령으로 설치하고  PowerShell 에서 프로젝트 로 이동하고 code . 을 입력하여 VS 코드 리눅스 환경에서 실행할 수 있다.   

code --install-extension ms-vscode-remote.remote-wsl

VSCode 에서 Extenctions (Ctrl+Shift+X) 를 크릭하여 wsl 을 검색하여 설치할 수 도 있다.

VSCode 기반의 AI 코딩을 위해서 아래의 확장들은 거의 필수이다. (AI Agent 만 선택)

① Remote - WSL
② GitLens  , SVN (vscode-svn extension)
③ OpenAI Codex (선택)
④ GitHub Copilot (선택)
⑤ Docker

⑥ 기타 : Gradle for Java 

AI 코딩 시작하기

먼저 레파지토리에서 프로젝트를 가져온다. WSL 환경에 소스를 가져와야 하기 때문에 workspace 폴더를 생성하고 여기에서 다음 명령으로 소스를 가져온다. 

1. GitLab 프로젝트 페이지 → Clone 버튼에서 URL을 복사
2. git clone <HTTPS_URL>

이제 VS 코드를 실행하고 Ctrl + Shift + P 을 입력하여 명령 팔레트를 열고 WSL 을 입력하여 명령 목록에서 클릭하여 WSL환경에 연결한다.  

이제 폴더를 열면 된다. 보통은 "Do you trust the authors of this workspace?" 메시지가 나오는데 신뢰한다고 답을 하면 된다.

이제 좌측 아이콘에서 Codex 클릭하고 로그인 / 인증키 입력 한다. CLI와 IDE 확장은 동일한 로그인 정보를 공유하도록 설계되어 있어 터미널에서도 CLI 을 사용이 가능하다.

터미널에서 codex 을 실행하고 다음에 아래와 같은 간단한 명령으로 코드를 리뷰하게 할 수 있다.

"review this code focusing on security issues" 

Codex 앱 사용하기

Codex 사이트(https://openai.com/ko-KR/codex/)를 방문하면 맥/윈도우 용 앱을 다운로드 할 수 있다.  (2026.03.04 일 부터 윈도우지원) 

윈도우용 Codex 앱은 PowerShell + Windows Sandbox (네이티브 센트박스) 기반으로 에어전트가 작업을 실행하며 필요하면 WSL 에서 실행하도록 구성하여 사용할 수 있다.

앞에서 설치한 VS Code 확장(Codex in IDE)  + WSL 와 함께 아래와 같이 역할을 구분하여 사용할 수 있다. 

• VS Code 확장(Codex in IDE) : “에디터 안에서” 코드 편집/대화 중심
• Codex 앱 : “에이전트 관제센터”처럼 프로젝트/작업을 여러 개 굴리고, Windows Sandbox/PowerShell 또는 WSL 중 선택해 실행  

Codex 앱에 프로젝트를 추가할 떄는 WSL 의 경로를 사용하는 것이 좋다.  앞서 WSL 에서 생성한 프로젝트는 윈도우 파일 탐색기의 Linux 아이콘을 클릭하여 해당 프로젝트 경로를 찾아 추가할 수 있다.

프로젝트 추가를 위한 가장 쉬운 방법은 1) PowerShell 에서 wsl 명령으로 WSL 에 연결하고 해당 프로젝트로 이동하여 2) explorer.exe . 명령을 입력하면 탐색기로 리눅스 파일시스템을 확인 할 수 있다. 3) 파일 탐색기에 보여지는 이경로로 프로젝트를 추가하면 된다. 

에어전트 환경 모드는 좌측 하단의 설정 > 일반 의 Agent environment 설정에서 Windows Subsystem for Linux 와 Windows Native 를 선택할 수 있게 되어 있다.

간단하게 "문서를 확인해서 프로젝트 구조 및 향후 과제를 확인해줘." 프롬프트를 입력해본댜. (모델은 GPT 5.3 Codex , 낮음 을 선택했다.

 

다음은 전체 개발 환경을 도식화 한 것이다.

2012 맥미니 "초기 설정값으로 재설정" 하기

2012 맥미니에 설치된 macOS 을  "초기 설정값으로 재설정" 하여 파일 공유 서버로 용도로 재활용하기로 했다. 가능한 리모트 방식으로 진행하였지만 마지막 작업은 모니터, 마우스 그리고 키보드를 직결하여 마무리 했다. 

macOS Catalina 다운로드 

앱스토어를 통한 다운로드는 불가능하기 떄문에 콘솔에서 10.15.7 버전을 다운로드 했다. 

• macOS Catalina와 호환되는 컴퓨터 자료를 보면  Mac mini(2012년 후반 모델) 지원하는 macOS 임을 확인할 수 있다.
• Catalina 는 22년 7월에 배포된 10.15.7 이 최신 버전이다. 같은 해 11월부터 공식 지원이 종료되어 더 이상 보안 업데이트나 기능 개선이 제공되지 않는다.

softwareupdate --fetch-full-installer --full-installer-version 10.15.7

다운로드가 완료되면 아래 명령으로 다운로드가 완료된 파일을 확인할 수 있다.

ls -l /Applications/Install\ macOS\ Catalina.app

또는

/Applications/Install\ macOS\ Catalina.app/Contents/Resources/startosinstall --usage

macOS Catalina 설치 

기존 데이터를 모두 삭제하고 설치하도록 아래 명령을 입력한다.

sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/startosinstall \

  --eraseinstall \

  --agreetolicense \

  --nointeraction

설치가 진행되면 더이상 리모트로 접속이 허용되지 않고 직접 맥미니에 키보드와 마우스를 연결하여 진행을 해야한다. 

사용기 - 맥에서 도커 기반 SonarQube 활용하기

SonarQube는 코드에 대한 버그, 코드 스멜(Code Smell), 보안 취약점을 자동으로 찾아내고, 코드 품질을 향상시키는 데 도움을 주는 소스 코드 품질 및 보안 분석 도구이다.

버전에 따라 기능의 차이가 있는데 Community Edition (무료) 은  GitHub Private Repository 연동을 지원하지는 않지만 Git 에서 직접 코드를 가져와 분석할 수 있기 때문에 사용하는데 있어 큰 이슈는 없을 것 같다.

버전	특징	GitHub Private Repo 분석
Community Edition	무료, 기본적인 코드 분석 가능	✗ (직접 클론 후 분석)
Developer Edition	추가적인 언어 지원, 분기(branch) 분석	✓
Enterprise Edition	대규모 프로젝트 지원, 포트폴리오 관리	✓

◼︎ 환경

• Model : MacBook Pro (14-inch, 2021)
• CPU : Apple M1 Pro
• MENORY : 16GB
• DISK : 512 GB SSD
• OS : macOS 15.3.1 (24D70)
• TOOLS : VS Code , Docker

1. Docker 설치

Docker 는 공식 웹사이트에서 Docker Desktop for Mac을 다운로드하여 설치한다.

https://www.docker.com/products/docker-desktop

설치파일을 다운로드 후 Docker.dmg 파일을 클릭하여 설치를 진행할 수 있다. 설치가 완료되면 터미널에서 docker --version 명력을 입력하여 설치 확인한다.

% docker --version
Docker version 27.5.1, build 9f9e405

2. SonarQube Community Edition 설치하기

SonarQube 는 간단하게 터미널에서 아래 명령으로 SonarSource에서 공식적으로 제공하는 이미지를 다운로드하여 설치하고 실행할 수 있다.  SonarQube 는 디폴트로 사용하는 H2 데이터베이스 보다는  postgres 사용을 권장하고 있어 먼저 postgres 데이터베이스를 설치하고 같이 실행할 필요가 있다.

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

SonarQube는 여러 버전의 Docker 이미지를 제공하고 있다. 

태그(Tag)	설명
sonarqube:latest	최신 안정 버전
sonarqube:lts	최신 LTS (Long-Term Support) 버전
sonarqube:lts-community	무료 Community Edition LTS 버전
sonarqube:developer	Developer Edition (유료)
sonarqube:enterprise	Enterprise Edition (유료)
sonarqube:datacenter	Data Center Edition (유료)

postgres는 터미널에 아래와 같이 한 줄 명령어로 postgres 를 설치&실행 할 수 있다. 

docker run -d --name postgres \

  -e POSTGRES_USER=sonar \

  -e POSTGRES_PASSWORD=sonar \

  -e POSTGRES_DB=sonarqube \

  -p 5432:5432 \

  postgres:16

참고로 PostgreSQL 공식 Docker 이미지는 다양한 버전이 있는데 여기에서는 16 을 사용했다. 

태그 (Tag)	의미
postgres:latest	최신 안정 버전 (현재 기준 PostgreSQL 16)
postgres:16	PostgreSQL 16.x
postgres:15	PostgreSQL 15.x
postgres:14	PostgreSQL 14.x
postgres:13	PostgreSQL 13.x

이제 SonarQube 을 앞서 실행한 postres 와 함께 설치&실행 해보자.

docker run -d --name sonarqube \

  -p 9000:9000 \

  --link postgres \

  -e SONAR_JDBC_URL=jdbc:postgresql://postgres:5432/sonarqube \

  -e SONAR_JDBC_USERNAME=sonar \

  -e SONAR_JDBC_PASSWORD=sonar \

 sonarqube:lts-community

옵션	설명
docker run	새로운 컨테이너를 실행하는 명령
-d	컨테이너를 백그라운드(Detached Mode)에서 실행
--name sonarqube	컨테이너 이름을 sonarqube로 지정
-p 9000:9000	호스트의 9000번 포트를 컨테이너의 9000번 포트와 연결 (SonarQube 웹 UI)
--link postgre-container	SonarQube가 postgre-container 컨테이너와 통신할 수 있도록 설정 (Deprecated - 다른 방법 권장)
-e SONAR_JDBC_URL=jdbc:postgresql://postgres:5432/sonarqube	SonarQube가 PostgreSQL 데이터베이스 sonarqube에 연결하도록 설정
-e SONAR_JDBC_USERNAME=sonar	PostgreSQL 접속 시 사용할 DB 사용자명 설정
-e SONAR_JDBC_PASSWORD=sonar	PostgreSQL 접속 시 사용할 DB 비밀번호 설정
sonarqube:lts-community	실행할 Docker 이미지 (sonarqube의 LTS 버전, 무료 Community Edition)

참고로 여기에서는 postgres 와 sonarquber 가 서로 통신가능하게 --link 옵션을 사용했지만 안정성 이유로 --network 을 사용하는 것이 권장된다고 한다. 설치가 완료되면 브라우저에서 localhost:9000 포트로 접속한다. 디폴트 계정과 비밀번호는 admin 과 admin 이다.

Docker Desktop 도구를 사용하면 좀더 쉽게 도커 컨테이너 제어와 자원 사용량을 실시간으로 확인 할 수 있다.

Docker Desktop 화면

일단 위 과정을 한번하고나면 다음부터는 Docker Desktop 을 사용하여 쉽게 컨테이너를 조작할 수 있다.

2. SonarQube Community Edition 사용하기

한글이 익숙하다면 로그인 후 macketplace 메뉴에서 "Korean Pack Localization" 을 설치하면 간단하게 한글을 지원하게 된다.

코드 품질을 분석하는 기본적인 과정은 아래와 같다. 

❶ 프로젝트를 생성

❷ SonarScanner 설치 및 실행

❸ 분석결과 확인 

2.1 프로젝트를 생성

"프로젝트" 메뉴를 클릭하고 Community Edition 이 GitHub Private Repository 연동을 지원하지 않기 때문에 로컬에 프로젝트를 복제하여 분석 하기 위하여 "Manually" 을 선택한다.

존재하는 프로젝트가 없는 경우

프로젝트 이름을 입력하고 Setup 을 클릭하여 프로젝트를 생성한다.

2.2 토큰 생성

보안된 인증을 통해 자동화된 코드 분석을 실행할 수 있도록 토큰을 생성한다. Loaclly 을 클릭한다.

① 토큰 생성하기에서 생성하기를 클릭하여 토큰을 생성한다.

생성된 토큰을 별도로 저장하여 보관한다. Continue 클릭하면 다양한 환경에 바로 적용 가능한 스크립트를 보여준다. 

기존 프로젝트가 maven 을 지원하고 있어 maven 스크립트를 복사했다.

2.3 SonarScanner 설치 및 실행

SonarQube 서버와 연결하여 코드 품질을 분석하고 결과를 업로드하는 SonarScanner 은 아래와 같이 터미널에 입력하여 간단하게 설치할 수 있다.

brew install sonar-scanner

SonarScanner가 분석하는 요소는 아래와 같다.

• Bug (버그): 코드에서 오류가 발생할 가능성이 있는 부분
• Code Smell (코드 냄새): 유지보수성이 낮거나 개선이 필요한 코드
• Vulnerability (보안 취약점): SQL Injection, XSS 같은 보안 문제
• Coverage (테스트 커버리지): 단위 테스트가 얼마나 잘 작성되었는지
• Duplications (코드 중복): 중복된 코드 블록 확인

설치 결과는 아래 명령으로 확인 할 수 있다.

sonar-scanner --version


이제 Git 에서 가져온 Maven 프로젝트에서 앞서 복사한 스크립트를 사용하여 실행한다.

mvn clean verify sonar:sonar \
-Dsonar.projectKey=my_project \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=your_generated_token

옵션	설명
mvn	Maven을 실행하는 명령어
clean	기존 빌드 파일을 삭제하고 새롭게 빌드
verify	테스트를 실행하고 빌드를 검증
sonar:sonar	SonarQube 분석을 실행하는 Maven 플러그인 (sonar-maven-plugin)
-Dsonar.projectKey=my_project	SonarQube에서 프로젝트를 구별하는 고유한 키
-Dsonar.host.url=http://localhost:9000	SonarQube 서버의 주소
-Dsonar.login=your_generated_token	SonarQube 인증을 위한 API 토큰

실행이 완료되면 SonarQube 웹에서 분석 결과 확인할 수 있다.

결과 화면

SonarQube 분석 결과을 보면 이 프로젝트는 다음과 같은 조치가 필요한 것으로 나타난다.

1. Bugs, Vulnerabilities, Coverage, Duplications 항목에서 개선 필요
2. 특히 Bugs (170개), Coverage (0%), 취약점 (13개)가 심각한 문제
3. 보안 문제를 해결하고, 테스트 커버리지를 높이는 것이 가장 시급함

이제 SonarQube 에서 "Issues" 탭을 확인하고, 하나씩 문제를 해결해 나가면 된다. 

이슈 목록 화면

각 이슈를 클릭하면 해당 건에 대한 상세 화면으로 이동하게 된다.  이슈 내용을 확인하고 코드를 수정한다. 이슈 상세 페이지를 보면 이슈 상태를 변경할 수 있는 기능이 있는데  코드 수정 후 다시 로컬에서 SonarScanner 을 실행하기 때문에 문자가 해결되면 자동으로  Resolved(Fixed) 로 상태가 변경 된다.  

이슈 상세화면에서 "See all issues in this file" 클릭하여 해당 파일에 대한 목록만 보여지는데  이를 활용하면 파일 별로 작업을 진행 할 수도 있다. 

이슈 상세 화면

파일 단위로 필터 된 이슈 목록

코드를 수정하고 SonarScanner 을 동일하게 실행하면 결과가 반영되어 다시 분석결과가 업데이트 된다. 

3. 느낀점

자바 언어를 사용하는 프로젝트에 1주 정도 적용을 해보았는데 아래와 같은 점에서 아주 만족스러웠다.

1. 좋은 코딩 습관을 위한 아주 좋은 도구이다. 코드에 대한  결함을 해결하면서 좋은 코드를 작성하는 방법을 자연스럽게 학습할 수 있었다.
• Bug (버그): 코드에서 오류가 발생할 가능성이 있는 부분
• Code Smell (코드 냄새): 유지보수성이 낮거나 개선이 필요한 코드
• Vulnerability (보안 취약점): SQL Injection, XSS 같은 보안 문제
• Coverage (테스트 커버리지): 단위 테스트가 얼마나 잘 작성되었는지
• Duplications (코드 중복): 중복된 코드 블록 확인
2. 자바 언어의 버전에 따른 좋은 코드를 지적해주기 때문에 코딩 스킬 향상에 도움이 되었다.