Skyscanner는 OpenAI의 Codex CLI를 JetBrains IDE와 연동해 AI 어시스턴트도 개발자가 쓰는 디버깅 도구와 테스트 도구를 그대로 활용할 수 있게 했습니다. 그 과정을 소개합니다.
Skyscanner에서는 품질을 유지하면서 개발 속도를 높일 방법을 늘 찾고 있습니다. 지난 몇 달 동안 저는 일상적인 개발 업무에서 OpenAI의 Codex를 페어 프로그래밍 파트너로 활용해 왔습니다.
이번에 새로 시도한 일은 JetBrains의 Model Context Protocol(MCP) 서버를 이용해 Codex CLI를 JetBrains IDE에 연결하는 것이었습니다. 덕분에 AI가 IDE에서 어떤 기능을 제공하는지 확인하고 직접 사용할 수 있게 됐습니다. 이 연동으로 개발 방식이 크게 달라졌습니다. Codex가 JetBrains 도구를 쓰면서 문제를 어떻게 더 잘 해결하게 됐는지, 저희 팀의 개발 속도는 어떻게 빨라졌는지 소개합니다.
Codex에 IDE 컨텍스트 제공하기
JetBrains MCP 서버를 연결하면 Codex가 평소에는 볼 수 없던 제 개발 환경의 상세한 컨텍스트까지 활용할 수 있습니다.
JetBrains MCP를 통해 Codex가 IDE에 추가 컨텍스트를 요청하는 방법은 다음과 같습니다.
- 파일에서 문제 찾기를 사용하면 IntelliJ의 코드 검사 기능으로 파일의 오류와 경고를 찾을 수 있습니다. 검사 결과에는 각 문제의 메시지와 정확한 위치가 포함됩니다.
- 실행 구성 실행하기를 사용하면 단위 테스트, 린터, 포매터 등을 위해 미리 정의한 실행 구성을 실행하고 종료 코드와 출력을 가져올 수 있습니다.
이 방식은 실제로 큰 효과가 있었습니다. 개발자가 코드를 작성하고 컴파일하고 테스트할 때 받는 피드백을 Codex도 똑같이 받을 수 있기 때문입니다. Codex가 IDE의 컨텍스트를 활용해 자신이 작성한 코드를 더 효과적으로 검증하면서 수정과 확인에 걸리는 시간이 줄었습니다.
오류를 더 빨리 발견한 실제 사례
Databricks Java SDK를 사용하는 코드의 오류 처리 로직을 검증하려고 단위 테스트를 작성하던 중이었습니다. 예외가 발생하는 상황을 재현할 스텁을 만들어 달라고 하자 Codex는 자신 있게 다음과 같은 Java 코드 한 줄을 내놓았습니다.
var stubError = new NotFound("dummy error");NotFound 오류를 재현하려는 것이니 언뜻 보면 그럴듯합니다. 하지만 잠시 후 IntelliJ가 그 줄에 굵은 빨간 밑줄을 표시했습니다.
Databricks SDK의 NotFound 예외 클래스에는 문자열 인수 하나만 받는 생성자가 없습니다. Databricks SDK 소스 파일인 NotFound.java에서도 확인할 수 있습니다. 결국 Codex가 제안한 코드는 그대로는 컴파일되지 않습니다.
기본 설정이라면 Codex는 이 실수를 알아채지 못했을 겁니다. 나중에 테스트를 실행하려고 할 때야 문제가 있다는 걸 알았을 수도 있습니다. 하지만 JetBrains MCP를 연동한 덕분에 Codex는 오류를 즉시 발견했습니다. 내부적으로 Codex는 IDE의 get_file_problems 도구를 호출해 파일을 검사했고, 일치하는 생성자가 없다는 컴파일 오류를 바로 전달받았습니다.
MCP가 없었다면 Codex는 대개 다음 과정을 거쳤을 겁니다.
- 코드를 생성합니다.
- 단위 테스트를 어떻게 실행할지 파악합니다.
- 단위 테스트를 실행합니다(명령어 실행을 위해 사용자에게 승인을 요청해야 할 수도 있습니다).
- 실패 메시지를 읽고 분석합니다.
- 오류 수정을 시도합니다.
JetBrains MCP를 사용하면 과정이 훨씬 짧아집니다.
- 코드를 생성합니다.
- JetBrains IDE에 해당 파일에서 어떤 문제가 발견됐는지 묻습니다.
- IntelliJ가 지적한 오류를 수정합니다.
덕분에 시간도 절약하고 Codex가 처리해야 할 컨텍스트도 줄일 수 있었습니다. 마치 옆에서 함께 코딩하던 동료가 곧바로 “아, 그 클래스에는 그런 생성자가 없어요. 다른 인수를 넘겨야 해요. 제가 금방 고칠게요.”라고 말하는 것 같았습니다.
미리 설정해 둔 테스트와 포매팅
또 좋았던 점은 Codex가 IDE에서 기존 빌드 및 테스트 도구를 직접 실행할 수 있다는 것입니다. 제가 맡은 프로젝트 대부분에는 테스트, 포매팅, 린팅을 위한 로컬 실행 구성을 IDE에 이미 만들어 두었습니다. JetBrains MCP를 사용하면 Codex가 필요할 때 이 구성을 찾아 실행할 수 있습니다.
실제로 Codex가 각 작업의 실행 방법을 알아내는 데 쓰는 시간과 컨텍스트가 줄어 원래 해결하려던 문제에 집중하기 쉬워졌습니다. 연동 이후에는 Codex가 테스트, 포매팅, 린팅을 실행하는 과정에서 더 이상 헤매지 않았습니다.
그래서 저는 사용자 지정 에이전트 지침에 코드를 수정할 때마다 테스트, 린팅, 포매팅을 실행하도록 명시했습니다.
## Code edit instructions
After you've finished editing
- Use the jetbrains mcp (if available) to find any problems
- Run format command if available
- Run lint command if available이제는 제가 개입하지 않아도 Codex가 스스로 문제를 해결하는 경우가 많습니다. 개발자로서 특히 반가운 변화입니다.
- Codex가 코드를 수정할 때마다 제가 직접 테스트, 린팅, 포매팅을 실행할 필요가 없습니다.
- 오류 메시지를 복사해서 채팅에 붙여 넣을 필요도 없습니다.
- Codex가 수정한 코드가 실제로 동작하는지 빠르고 정확하게 피드백을 받으므로, 수정하고 다시 확인하는 횟수가 줄어듭니다.
덕분에 제대로 작동하는 고품질 소프트웨어를 제공하는 일에 더 많은 시간을 쓸 수 있습니다.
개발 방식에 생긴 변화
Codex와 JetBrains MCP를 연동하면서 개발 과정에서 AI 어시스턴트에 맡길 수 있는 일이 눈에 띄게 늘었고 결과도 더 믿을 만해졌습니다. 실제로 체감한 이점은 다음과 같습니다.
- 더 빠른 피드백 — Codex가 컴파일 오류나 테스트 실패에 관한 피드백을 IDE에서 즉시 받습니다.
- 줄어든 프롬프트 왕복 횟수 — Codex가 IDE에 직접 물어볼 수 있어 제가 명령어를 실행하고 오류 메시지를 붙여 넣을 때까지 매번 기다릴 필요가 없습니다.
- 더 정확한 수정 제안 — Codex도 IDE에서 확인한 정보를 볼 수 있으므로, 수정한 코드가 첫 시도에 컴파일되고 테스트를 통과할 가능성이 높아집니다.
- 기존 워크플로우와의 자연스러운 연동 — Codex가 별도의 도구를 고안할 필요 없이 팀에서 이미 쓰는 도구를 그대로 활용합니다.
그동안 독립적으로 쓰던 Codex가 이제는 저희 개발 환경에 한층 더 긴밀하게 통합됐습니다.
요약
Skyscanner에서 이번 경험을 통해 깨달은 점은 간단합니다. 컨텍스트가 결정적이라는 것입니다. Codex는 그 자체로도 강력하지만 IDE에서 파악한 정보까지 활용할 때 훨씬 더 효과적입니다. 이 컨텍스트 덕분에 Codex가 문제를 더 깊이 이해하고 정확한 수정안을 더 빨리 제시할 수 있게 됐습니다. 저 역시 그 결과를 한층 더 신뢰하게 됐습니다.
저희 경험이 다른 개발자분들에게도 이런 연동을 시도해 볼 계기가 되기를 바랍니다. 직접 써 보니 도구를 사용한다는 느낌보다는 제가 보는 것을 함께 볼 수 있는 AI 페어 프로그래밍 파트너와 협업한다는 느낌이 훨씬 강했습니다.