
구현은 Codex, 리뷰는 Claude, JetBrains Air를 이용한 크로스 에이전트 리뷰
요약
JetBrains Air를 활용하여 Codex로 코드를 구현하고, 다른 에이전트를 통해 리뷰를 진행하는 크로스 에이전트 워크플로우를 실험했습니다. 동일 에이전트가 구현과 리뷰를 모두 수행할 때 발생할 수 있는 편향성을 방지하기 위해 에이전트를 분리하는 전략을 다룹니다.
핵심 포인트
- 구현과 리뷰 에이전트를 분리하여 셀프 리뷰 편향성 방지
- JetBrains Air의 Agentic Development Environment 컨셉 활용
- Codex를 이용한 엔티티 필드 추가 및 테스트 자동화 구현
- 에이전트 리뷰를 통한 SQL 멱등성 문제 등 잠재적 오류 발견
지난번에는 JetBrains Air의 Git Worktree를 사용하여 병렬 태스크를 시도해 본 기사를 작성했습니다만, 그 과정에서 Review with Agent (에이전트에 의한 자동 리뷰)를 시험 삼아 사용해 보니, 구현을 담당한 것과 동일한 에이전트가 리뷰도 담당하도록 설정되어 있다는 것을 알게 되었습니다.
이번에는 설정에서 다른 에이전트를 리뷰 담당으로 지정해 보았습니다.
구현한 에이전트 자신이 리뷰까지 하게 되면, 자신이 채택한 전제나 설계 판단을 의심하지 않고 그대로 괜찮다고 판단해 버립니다. 인간의 셀프 리뷰에서도 일어나는 일이지만, AI에서도 똑같은 일이 일어날 것입니다.
JetBrains Air는 AI 에이전트에게 코딩 태스크를 위임하고, 인간은 워크플로우의 주도권을 쥔 채 결과를 확인한다는 컨셉의 Agentic Development Environment입니다.
Claude Agent, Codex, Gemini, Junie와 같은 여러 에이전트를 태스크 단위로 나누어 사용하는, 독립된 앱으로서 설계되어 있습니다.
2025년 12월에 발표되어 2026년 3월에 macOS에서 퍼블릭 프리뷰가 시작되었으나, 한동안 Windows 미지원 상태가 지속되었습니다.
그러다 2026년 6월 30일에 드디어 Windows 버전(x64/ARM64)이 출시되었습니다.
현 시점에서는 Air 본체는 무료로 이용할 수 있습니다.
에이전트를 구동하기 위해서는 JetBrains AI 구독을 사용할 수 있을 뿐만 아니라, BYOK (Bring Your Own Key) 방식으로 자신의 API 키를 설정하여 사용할 수도 있습니다.
이미 JetBrains AI를 계약 중인 분이나, 이용 중인 LLM 프로바이더의 API 키를 가지고 있는 분이라면 그대로 시도해 보기 쉬울 것입니다.
spring-petclinic의 Owner 엔티티에는 address, city, telephone은 있지만, 우편번호 필드가 없습니다. 이것을 구현 대상으로 삼았습니다.
실행 환경은 Git Worktree를 선택하고, Codex에게 다음과 같이 의뢰했습니다.
Owner 엔티티에 일본 우편번호 포맷(XXX-XXXX)의 필드 postalCode를 추가하고,
OwnerController의 폼에서 유효성 검사(Validation)가 작동하도록 해주세요.
기존 테스트를 확인하고, 필요하다면 새로운 테스트도 추가해 주세요.
Codex의 구현 내용은 다음과 같았습니다.
Owner.java에postalCode필드를 추가하고,@NotBlank와@Pattern(regexp = "\\d{3}-\\d{4}")로XXX-XXXX형식 검증createOrUpdateOwnerForm.html에 입력란 추가 - 소유자 상세 화면에도 표시 추가- DB 초기화 SQL, 각 locale의 메시지 키, 기존 테스트 데이터 업데이트
- 테스트 실행 결과:
Tests run: 26, Failures: 0, Errors: 0
언뜻 보기에는 필드 추가부터 테스트 데이터 업데이트까지 일관성이 있고, 빠진 부분이 없는 것처럼 보였습니다.
Review with Agent를 누르자, 지난번 기사와 마찬가지로 자동으로 리뷰가 시작되었습니다. 리뷰 또한 구현과 동일한 Codex가 담당하게 됩니다.
남겨진 코멘트는 2건이었습니다.
CREATE TABLE IF NOT EXISTS는 기존 MySQL PetClinic 데이터베이스에 이미 owners 테이블이 있는 경우 postal_code를 추가하지 않습니다. spring.sql.init.mode=always를 사용할 경우, 업데이트된 data.sql과 JPA 매핑이 누락된 컬럼을 참조하게 되어 시작/저장 작업이 실패할 수 있습니다. ALTER TABLE owners ADD COLUMN IF NOT EXISTS postal_code VARCHAR(8)와 같은 멱등성(Idempotent) 있는 마이그레이션 단계를 추가하거나, 그렇지 않다면 기존 MySQL 데이터베이스를 위해 이 스키마를 문서화하거나 드롭 후 재생성(drop-and-recreate)하십시오.
CREATE TABLE IF NOT EXISTS는 기존 PostgreSQL의 owners 테이블을 변경하지 않으므로, 이 변경 사항 이전에 생성된 데이터베이스에는 여전히 postal_code가 없습니다. 이 프로필은 항상 SQL 초기화(init)를 실행하며, 엔티티/데이터 스크립트가 이제 해당 컬럼을 요구하기 때문에, 기존 데이터베이스를 대상으로 할 경우 시작(startup) 또는 소유자 영속성(owner persistence) 단계에서 실패할 수 있습니다. 데이터 삽입(data inserts) 전에 멱등성(idempotent)을 보장하는 ALTER TABLE owners ADD COLUMN IF NOT EXISTS postal_code TEXT (또는 그에 상응하는 마이그레이션/리셋 경로)를 추가하십시오.
요약하자면, "CREATE TABLE IF NOT EXISTS는 기존 MySQL/PostgreSQL의 owners 테이블에는 적용되지 않으므로, 이미 가동 중인 DB에는 postal_code 컬럼이 추가되지 않는다. 따라서 시작 시점이나 소유자 저장 시 실패할 수 있다"라는 DB 스키마 마이그레이션 절차에 관한 지적입니다. 구현 시에는 인지하지 못했던 인프라 측면의 지적이었습니다.

Settings → Global 탭 → AI | Review → Agent review model을 Claude Agent로 변경하고, 동일한 작업에 대해 다시 한번 Review with Agent를 실행했습니다.

이번에는 Codex와는 다른 종류의 지적이 돌아왔습니다.
정규 표현식(Regular Expression) \d{3}-\d{4}는 일본의 우편번호 형식으로 고정되어 있습니다. 시드 데이터(seed data)의 소유자는 Madison, WI나 London 등 미국·영국 주소이며, 실제 미국의 ZIP 코드(5자리 또는 +4 형식을 포함한 10자리)나 타국의 우편번호는 모두 이 검증에서 거부됩니다. PetClinic이 특정 지역에 한정되지 않는다는 전제라면, 포맷을 더 범용적으로 만들거나(예: 영숫자 및 가변 길이 허용, 또는 국가별 검증 분리), 최소한 의도적인 사양인지 주석으로 명시하는 것이 좋습니다.

이것은 DB 스키마에 관한 이야기가 아니라, 애초에 이 요구사항 자체가 프로젝트의 실제 데이터와 모순된다는 도메인·요구사항(domain/requirement) 수준의 지적입니다.
spring-petclinic의 시드 데이터에는 Madison, WI(미국)나 London(영국)의 소유자가 포함되어 있어, 일본 우편번호 형식으로 고정된 검증(validation)을 사용하면 기존 데이터의 상당수를 아예 저장할 수 없습니다.
동일한 구현물에 대해 두 에이전트가 지적한 내용의 차이가 명확히 드러납니다.
| 리뷰 담당 | 지적 종류 | 지적 내용 |
|---|---|---|
| Codex (자기 리뷰) | 인프라·스키마의 정확성 | 기존 DB에 대한 비멱등적(non-idempotent) 컬럼 추가, 시작·저장 실패 위험 |
| Claude Agent (별도 에이전트) | 도메인·요구사항의 타당성 | 우편번호 포맷이 실제 시드 데이터(미·영 주소)와 모순 |
- "구현자와는 다른 관점"을 의도적으로 도입함으로써, 지적의 "종류" 자체가 늘어난다는 것을 실감했다
단일 코딩 에이전트 도구(구현과 리뷰가 하나의 도구로 완결되는 것)에서 "다른 AI에게 리뷰를 시키는 것"을 수행하려면, diff를 수동으로 복사하여 다른 채팅 도구에 붙여넣는 등의 번거로움이 발생합니다.
JetBrains Air에서는 설정만 변경하면 동일한 UI와 동일한 작업 문맥을 유지한 채 리뷰 담당자만 교체할 수 있습니다.
- 기본 설정은 구현 에이전트와 동일한 모델이 리뷰도 담당하도록 되어 있으므로, 의식적으로
Settings를 열지 않으면 "다른 에이전트에게 보여줬다"고 생각한 것이 실제로는 자기 리뷰(self-review)였던 상황이 발생할 수 있습니다. - 리뷰 담당자 전환은 글로벌 설정(
Settings | Global)이므로, 작업마다 매번 바꾸는 운영 방식에는 적합하지 않습니다. 프로젝트 단위로 고정하고 싶다면 별도의 확인이 필요해 보입니다.
AI가 구현한 코드를 동일한 AI에게 리뷰하도록 맡기고 있는 분들이라면, JetBrains Air에서 Agent review model을 다른 에이전트로 변경하여 태스크를 리뷰해 보시는 것을 추천합니다.
이번 사례에서는 인프라 관점의 지적과 도메인·요건 관점의 지적이라는, 한쪽만으로는 나타나지 않았을 두 종류의 문제를 발견할 수 있었습니다.
"어떤 AI에게 리뷰를 맡길 것인가"까지 의식할 가치가 있다고 느꼈습니다.
저희 회사는 JetBrains 제품에 관한 질문이나 상담 등을 접수하고 있습니다. 저희의 X(구 Twitter) 또는 이메일로 연락해 주시기 바랍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기