Codex와 Claude Opus에게 동일한 Java AI 에이전트 모놀리스를 맡겨보았다

제 Java 개인 프로젝트에서 작은 실험을 진행했는데, 결과는 예상보다 깔끔하지 않았습니다.

작은 면책 조항: 저는 2026년 4월 19일에 최종 비교 검토를 수행했습니다. AI 코딩 도구의 특성상, 이 결과는 이미 어느 정도 시의성을 탑니다.

이 프로젝트는 텔레그램 봇, 에이전트 루프, 도구, 메모리, 스트리밍 응답, 그리고 로컬 모델과 OpenRouter 모델이 혼합된 다중 모듈 Java 모놀리스입니다. 당시 저는 이미 에이전트 로직의 일부를 Spring AI에서 제 자체 FSM/ReAct 흐름으로 옮기기 시작한 상태였지만, 코드에는 여전히 많은 버그가 있었습니다.

그래서 전체 프로젝트를 두 개의 별도 브랜치로 복사하고, Codex 5.3과 Claude Opus 4.6에 동일한 모호한 프롬프트를 준 뒤, 두 에이전트가 거의 자율적으로 작업하도록 했습니다.

규칙은 의도적으로 간단하게 설정했습니다:

• 옳다고 생각하는 방식으로 작업을 수행할 것
• e2e를 포함한 기존 테스트를 통과할 것
• 리뷰를 실행할 것
• 리뷰 코멘트를 수정할 것
• 사소한 코멘트만 남을 때까지 반복할 것

기본적으로, 순수한 '바이브 코딩(vibe coding)'이었습니다.

Claude Opus는 여러 부분에서 더 매력적인 아키텍처를 만들어냈습니다. 가장 좋았던 부분은 스트리밍 출력과 관련된 것이었습니다. 모델의 원시 청크(raw model chunks)와 텔레그램 사용자에게 보여줄 수 있는 텍스트 사이에 더 명확한 경계를 만들었습니다. 모델은 깔끔한 문장으로 스트리밍하지 않기 때문에 이는 중요합니다. 모델은 <th를 보낸 다음 ink>를 보내고, 그 뒤에 내부 추론을 보낸 다음 닫는 태그를 보낼 수 있습니다. 스트리밍이 완료된 후에만 최종 텍스트를 정리한다면, 그 쓰레기 데이터의 일부가 이미 사용자에게 도달했을 수 있습니다.

그런 의미에서 Claude의 아이디어가 더 나았습니다. 사용자에게 보이는 이벤트를 내보내기 전에 필터링하는 방식이었으니까요.

Codex는 덜 우아했습니다. 컨텍스트 변이와 후처리에 더 많은 로직이 묶여 있었습니다. 나중에 유지보수하기 더 어려워질 것 같은 코드처럼 느껴졌습니다.

하지만 시퀀스 다이어그램/호출 체인을 요청했을 때 불편한 사실을 발견했습니다. Claude의 멋진 아키텍처 중 일부가 실제로는 사용되지 않고 있었습니다. 테스트가 통과된 이유는 새로운 ReAct/FSM 스트리밍 흐름이 제대로 통합되었기 때문이 아니라, 기존 Spring AI 스트리밍 경로가 여전히 e2e 시나리오를 커버하고 있었기 때문입니다.

그 사실이 전체 결과를 읽는 방식을 바꿔놓았습니다.

Codex는 그 나름의 문제가 있었습니다. 더 많은 상태와 동시성 위험을 도입했죠. 한 브랜치는 전체 검증 실행에서 REST 테스트 슬라이스 하나를 실패하기도 했습니다. 하지만 Codex는 중요한 실용적인 것들도 추가했습니다:

• 멈춘 AI 스트림에 대한 타임아웃 및 폴백
• 재시작 후 대화 기록 복구
• 사용자에게 링크를 보여주기 전 URL 위생 처리
• 스트리밍 계약에서 진행 상황과 최종 답변의 더 나은 분리
• 텔레그램 진행 상황 업데이트를 위한 배치 처리

모든 것이 아름다운 것은 아니었습니다. 그중 일부는 나중에 단순화하고 싶은 종류의 코드였습니다. 하지만 그중 더 많은 부분이 작동하는 제품과 연결되어 있었습니다.

그것이 저에게 가장 큰 교훈이었습니다. AI 코딩 에이전트와 함께할 때, '좋은 아키텍처'와 '실행되는 코드 경로'는 같은 것이 아닙니다.

두 번째 실험도 비슷했습니다. 저는 동일한 영역에서 Codex 5.3과 더 새로운 GPT 모델을 비교했습니다. 이번에도 더 강력한 모델이 더 깔끔한 추상화를 제안했지만, 코드는 대부분 실행되지 않았고 실제 버그를 찾아내지도 못했습니다. Codex는 더 지루하고, 더 직접적이며, 이 특정 자율 개발 루프에는 더 유용했습니다.