Claude Code Vs. Open AI Codex, which one is best for pair programming? 🎯
As a developer constantly looking for tools to enhance my workflow, I've been fascinated by the...
dev.to
0. AI 시대에 대한 자각
왜 이 글을 쓰게 되었는가
스타트업에서 인턴십을 하면서 클라우드 + AI 결합을 위한 소프트웨어 개발을 시작한지 만으로 3개월이 지났다. 회사 생활에 대한 근황이나 틈틈이 깨달은 점을 적어보고 싶었는데 이번에 확고한 주제가 떠올라서 글로 작성해보게 되었다.
내가 이 주제로 글을 쓰게 된 가장 큰 트리거는, 요즘 스타트업에서 AI-First-Development 움직임이 활발하다는 것을 알게 된 이후이다. 즉, 지금 다니는 회사를 포함한 다른 많은 회사들에서 공통적으로 보이는 요소라는 것이다. 친구들이나 개발자 지인들, 심지어 해외 취업한 지인들이나 커뮤니티에서도 귀중한 인사이트를 많이 얻을 수 있었고 내가 경험했던 것들과 많이 닮아있었다.
계속 서로 경험담을 공유할수록 개발의 paradigm shift를 대비해야겠는 생각이 들었다. 이 글은 사회 초년생의 어린 백엔드 엔지니어 입장에서 작성되었다. 그동안 질리도록 AI Coding Agent와 고군분투하며 자유롭게 사용하고, 기준을 직접 세우고 공부한 경험을 기반으로 한다.
최근 떠오른 몇 가지 질문? 상상을 공유한다
- 앞으로 OLTP 진영의 인력 보충이 많이 필요할까? (인력 감축 추세를 반등할만한 다른 요소가 있는가?)
- OLAP 진영에서 AI의 결합이 일어나서 데이터 인텔리전스 플랫폼이 상용화 되는 시기는 향후 몇 년일까?
- 누구나 코딩에 접근할 수 있게 되면 역으로 API로 말아야하는 데이터… 즉, 사람들이 원하는 원천 데이터를 꽉 잡은 쪽이 더 유리하지 않을까? (데이터 수집, 활용에 대한 규제 문제는? 혁신과 함께 금방 풀릴 것인가?)
- AI를 가지고 날카롭게 생각하고 성장하려면 어떤 자질을 가져야 하는가?
1. AI Agent 코딩의 장점
빠른 아이디어 검증의 시대
그동안 AI Coding Agent와 함께 일하면서 가장 먼저 체감한 것은 "아이디어에서 구현까지의 거리와 속도"가 극적으로 줄어들었다는 것이다. 이전에 또래 친구들과 개발할 때, “특정 기능을 구현하는 코드”를 단편적으로 요청한 것과 차원이 다른 속도로 실체화와 PoC(Proof of Concept)가 가능하다.
오히려 우리는 PRD라는 아주 상세한 설계와 계획, 패키지 구조, 아키텍처, 코드 컨벤션, 예외 처리 등을 총체적으로 담은 문서가 필요하다. 이 문서를 제대로 만들기 위해 깊게 고민하면서 소프트웨어 설계의 본질을 고민해야한다.
이전에 SSAFY에 다니면서 프로젝트 할 때 실시간 채팅(동접 n백명 이상 목표) PoC 구현할 때 약 4일이 걸렸지만, 지금은 몇 시간 안에 새로 만들어서 더 나은 코드 구현과 실행까지 보여줄 수 있다. 완전 장담할 수 있다.
PoC 속도 향상과 실험 비용 절감
전통적인 개발 방식에서 PoC는 상당한 시간과 인력을 필요로 한다. "이 아이디어가 정말 작동할까?"를 검증하기 위해 시간을 투자해야했다. 위에 언급했던 SSAFY에서 겪은 PoC 사례는 불과 몇개월 전이다. (2025년 초)
그러나 AI 시대의 PoC는 다르다. 상세한 설계를 담은 문서와 프롬프트, 그리고 검증 절차를 거치는 몇 번의 반복으로 작동하는 프로토타입을 만들 수 있다.
이는 단순히 "속도가 빨라졌다"는 의미를 넘어선다. 우리는 앞으로 더 많은 아이디어를 “직접” 시도해볼 수 있다. 코드도 볼 수 있고, PoC 코드를 빠르게 훑어보면서 예상 문제점도 예측해볼 수 있다. 10개의 아이디어가 있을 때, 과거에는 신중하게 고르고 골라 2-3개만 시도했었다면, 지금은 같은 시간에 전부를 빠르게 검증하고 가장 좋은 것을 선택할 수 있는 것이다.
반복 작업의 자동화
소프트웨어 개발에는 창의성이 필요한 부분과 반복적으로 타이핑해야 하는 부분이 공존한다. CRUD API, DTO 변환 로직, 기본적인 예외 처리, 단순 Unit Test Code 등은 개발에 익숙해지다보면 타이핑에 가까워진다. 백엔드 개발자 입장에서 생각해 볼 때, 도메인을 공들여서 설계하고, 도메인 사이 경계를 정의하고, 책임을 나누고, 비즈니스 로직의 기반이 되는 규칙을 명확하게 만드는 것 등등.. 이런 작업에 비하면 상대적으로 타이핑으로 느껴진다는 뜻이다.
타이핑에 대한 시간을 절약할 수 있다면, 진짜 중요한(위와 같은 문제)들에 집중할 수 있다. 하루의 많은 시간을 회의에 할애하고 / 규칙을 정하고 / 협업하는 사람들 모아놓고 도메인 규칙을 이끌어내는 leading의 역량이 더욱 필요해진다. 이 역량을 leader만 갖추는게 아니라 모두가 갖춰야하는 역량이 되어가고 있으며 요구하는 연령, 연차도 더욱 낮아질 것이다.
탐색 비용의 획기적인 감소
이 장점은 PoC 속도 향상과 실험 비용 절감과도 이어지는 장점이다. 이전에는 적절한 코딩을 위한 Research 시간도 상당했다. 정확한 정보 탐색을 위해 공식 Document를 찾거나 StackOverflow를 뒤지기도 했다. 그러나 지금은 이런 Research 결과를 “딸깍”하여 원하는 형태로 보고받을 수 있다.
많은 사람들이 프론티어 모델의 Deep Research 기능을 많이 써보았을 것이라고 생각한다. 우리는 코딩 중에도 이런 리서치를 CLI에서 “편하게” “원하는 조건”을 담아 “병렬”으로 실행할 수 있다.
즉, 리서치 한 번 돌려놓고 설계를 진행할수도 있고 새로운 오픈 소스 하나 발견하면 clone 받아서 전체 프로젝트를 탐색하는 세션을 하나 돌려놓을 수 있다. 즉, 사람은 기존 작업을 계속 하면서 동시에 병렬로 띄워놓고 편하게 결과만 받을 수 있다는 것이다.
프론티어 모델들은 기본적으로 Surface Web을 기반으로 찾는다. 만약에 리서치 범위나 RAG가 시원치 않은 것 같다(?) 싶으면 바로 상용 크롤러 mcp를 달아주면 된다. 예전에는 개발자 포폴에 웹 크롤러 만드는 토이 프로젝트도 많이 있었지만, 요즘은 mcp 크롤러를 본인 환경에 쉽게 장착하여 도구처럼 쓸 수 있다. 필요할 때 얼마든지 정보를 수집하고 추출하여 개발에도 활용할 수 있다.
생산성이 높은 사람은 이미 본인이 필요한 작업에 대한 각종 도구나 MCP를 수집해 개발 환경에 장착해두고 있다. 주변에서 새롭고 유용한 도구를 하나씩 떠먹여줄 때마다 다 소화하느라 벅차다. 그만큼 AI를 활용한 도구가 많고, 내게 필요한 도구를 선별해서 작업 환경을 잘 만들어 놓는 것이 중요하다.
장점을 누리기 위한 전제 조건
하지만 이 모든 장점에는 전제 조건이 있다. AI를 제대로 활용할 수 있는 능력이 필요하다. 명확한 프롬프트를 작성하고, 결과물을 비판적으로 검증하고, AI가 잘하는 것과 못하는 것을 구분할 줄 알아야 한다.
AI가 여전히 헤메는 부분이 존재한다. AI의 한계를 이해하지 못하면 장점을 제대로 활용하기 어렵고, 일반적인 방법이나 프롬프트로 사용하다가 막히는 경우도 많다. 다음 섹션에서는 지난 두 달간 체감한 AI 코딩의 한계와 함정을 솔직하게 풀어보려 한다.
2. AI Agent 코딩의 한계
아래에서 설명할 내용들로 왜 아직까지 인간이 필요한지를 써보겠다. 물론 많은 인간이 필요하지는 않기 때문에 점점 채용 한파가 되고 있지만... 인간이 완전히 대체되지는 않을 것 같다. 인간은 인간이 할 수 있는 일에 집중하는 구조로 바뀔 것이다.
다만 현재 작성하고 있는 시점 기준의 한계점을 적은것이다. 추후 가까운 미래에 많이 극복될수도 있다. 발전 속도를 함부로 예측할 수 없기 때문에 아래에 내가 기준으로 작성한 구체적인 Agent Version을 명시해두었다.
대규모 시스템 안정성 문제, 도메인 문제, 트레이드 오프 판단의 책임 부재
앞서 설명했듯이 AI 코딩은 PoC에 더할나위 없이 제격이다. 그러나 실제 서비스하는 시스템의 규모가 커지고 보안이 중요해질수록 AI에 온전히 맡기기 어렵다.
규모가 커질수록 엔지니어는 여러 계층을 넘나들며 데이터의 흐름을 이해하고 구현하기 시작한다. 클라우드(또는 온프레미스) 인프라의 리소스 구성, API 요청 흐름, 메시지 큐의 처리 지연, 로그의 패턴, 장애 발생 시 복구 절차까지 모든 요소가 복잡하게 얽혀 있으며, “전체 시스템 동작 맥락”이 중요해진다.
그러나 이런 전체 동작 맥락에 대한 구체적인 설명과 정보를 AI에게 제공하더라도 놓치는 부분이 생긴다. 거대한 서비스일수록 세션 기억이나 작업 지침 문서로 감당할 수 없는 규모가 된다. Context Window 밖으로 밀려날 확률이 높아진다.
특히 디버깅 할 때 많이 느낄 수 있는 부분이 있다. 바로 추상적인 고차원 레벨의 문제와 ↔ 저수준 레벨의 문제간 이동이 활발하지 못하다는 것이다. 인간의 사고는 여러 단계를 자유롭게 넘나들며 확장과 축소를 반복한다. 하지만, 아직까지 AI는 최근 컨텍스트를 가장 강하게 인식한다. 인간이 직접 구체적으로 추상화 레벨과 계층별 정의를 내리고 이를 넘나들수 있는 가이드를 주어야만 이런 인간의 디버깅 사고를 흉내낼 수 있게 된다. 즉, 아직까지 대규모 서비스에서는 개발 이력과 동작 흐름, 맥락을 모두 알고 있는 개발자가 필요할 수 밖에 없다. 이 개발자가 직접 AI에게 구체적인 정의와 지시를 내려야하기 때문이다.
또한, 보안 요소를 서비스에 제공하고자 하는 경우는 문제가 더 복잡해지는데 바로 도메인/행간/맥락과 연결되기 때문이다. 실제 서비스의 보안은 단순 로그인 인증이나 토큰 기능에서 멈추지 않는다. 사용자 정보의 암호화 정도, 민감 데이터의 마스킹, 접근 로그 관리, 보안 감사 대응, 그리고 법적&윤리적 요구사항 준수까지 포함한다. 이런 요구사항은 도메인마다 다르고, 심지어 비즈니스의 변화나 고객 환경에 따라 달라지기도 한다. 고객이 직접 연결된 서비스일수록 개인정보를 더 많이 다루게되고, 예상치 못한 보안 요구사항이 추가되는 것이다.
AI는 이러한 보안 설계의 트레이드오프를 스스로 판단하지 못한다. “어떤 데이터를 암호화해야 하는가?”, “성능과 보안 중 어느 쪽을 우선해야 하는가?”,“로그에 남겨야 하는 정보의 범위는 어디까지인가?” 이런 질문들은 단순한 결정이 아니라, 서비스 철학과 책임 의식이 개입된 판단이다. 결국, AI는 보안 지식을 사람에게 알려주고 코드를 작성할 수는 있어도 그 코드가 비즈니스와 사용자 신뢰를 보호하는 올바른 선택인지는 결정할 수 없다. 이 부분은 엔지니어의 경험, 윤리적 판단, 그리고 시스템적 통찰이 뒷받침 되어야한다.
어쩌면 우리는 비즈니스맨이 되어야할지도 모른다.
Context Window의 한계
Context window 문제는 많이 들어보았겠지만, 리소스는 무한정하지 않다는 한계를 여실히 보여준다. 내가 컨텍스트 엔지니어링을 공부하면서 느꼈던 두 개의 핵심 내용을 중심으로 설명하겠다.
첫 번째, 각 프론티어 모델마다 컨텍스트를 다루는 방식이 다르다. 각 모델이나 Agent 서비스마다 주력 Context 관리 방식이 다르다. 보통 컨텍스트를 일정량만큼 주고, 그만큼을 기억하고 있다가 window 밖으로 용량이 밀려날 때 모종의 조치를 취하는 것이다.
예를 들면 현재를 기점으로 Claude Code 2.0.25 ver.에서는 윈도우를 넘어가면 자체적인 방식으로 Session Compacting을 한다. 즉, 내용을 자동으로 압축해서 기존 내용을 줄이는 것이다. 이 방식은 내부적으로 일어나기 때문에(BlackBox) 얼마나 context가 손실되는지 알 수 없다. 따라서 사용자 입장에서, 이 컨텍스트 압축이 유의미한지, 아니면 새로운 세션을 여는게 나을지 잘 판단하는 것이 좋다.
또한, Claude Code에서 매번 보이는 피드백인데, Compacting 소요 시간이 너무 길다는 단점이 있다. 답변을 받고자 기다리는게 아니라, 순수 압축을 기다리는데에만 긴 시간이 소모되는 것이다.
물론 지난 Sonnet 4.5 발표와 함께 압축 로직을 상당히 개선했다는 글을 읽었다. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Effective context engineering for AI agents
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
www.anthropic.com
매 업데이트마다 빠르게 달라지므로 컨텍스트 압축에 어떤 발전이 있을지, 우리의 컨텍스트 엔지니어링은 구체적으로 어떻게 바뀌어야 하는지 계속 주시하고 팔로잉하면 좋을 것이다. 실제로 회사에서 동료들과 각 모델 Update마다 주요 변경점이나 사용해본 후기들을 솔직하게 공유했었는데, AI를 이해하고 사용하는데에 큰 도움이 되었다. 이런 가벼운 세션들을 자주 가지면 좋을 것 같다.
다른 예시로는 Codex가 있다. 현재 Codex 0.59.0 ver. 에서는 초기부터 꽤 큰 윈도우를 제공하는 것 같다.(체감상 Claude Code 윈도우보다 큰 것 같은데, Codex가 질문 답변을 핵심만해서 내용이 짧기 때문에 역으로 윈도우가 크게 느껴지는 건지, 실제로도 더 큰 지는 실제 검증이 필요하다.)
또한, Codex는 과거 버전에서는 컨텍스트가 끝나면 자동으로 압축해주지 않고, 새로운 세션을 열도록 강제했다. 그러나 최근 버전부터는 Auto Compacting기능을 제공하고 있다. 여전히 처리 속도가 꽤 걸리고, 압축 후 window를 많이 차지하기도 한다. 내가 겪어본 최대 비율은 compacting한 내용이 전체 window에 25%가 넘었을 때였는데 꽤 놀랐었다.
두 번째로, 위와 같은 압축 상황에서 Context Pollution이 일어날 수 있다. 애매하게 남은 맥락은 사용자를 빙빙 돌게 만들고 핵심을 파악하기 어렵게 만들 수 있다. 예를 들어, 디버깅이 길어져 여러 번의 실패 시도가 컨텍스트에 쌓인 채 압축이 되면 실패 시도를 압축하여 참조 문맥으로 만들 수 있다. 이런 불필요한 정보가 쌓인것 같다면 적절한 시점에 세션을 초기화하는 것이 좋다.
이것 역시 인간 엔지니어의 판단과 지시가 중요하다. 개인적으로 Claude Code 2.0.25에서는 실패한 시도가 쌓일 때, 인간의 구체적인 지시가 없으면 코드나 추론이 실패 지점 언저리에서 행해지는 것을 많이 느꼈다. 오죽하면 Claude Code를 사용하는 사람들 사이에서, “이전까지의 맥락을 모두 잊고 지시하는 맥락 위주로 철저하게 단계적으로, 점진적으로 접근하여 문제를 해결하라.” 라는 종류의 프롬프트가 유행했던 이유가 있다.
위에서 이미 언급했듯이, 아직까지 LLM은 자유자재로 추상화 레벨을(고수준과 저수준을) 넘나들면서 추론하는 능력이 부족하다. AI에게 문제 추론, 원인 분석을 온전히 맡기지 말고, 인간의 문제 추론 능력도 함께 100% 발휘하여 Co-working 하는 것이 중요하다.
인간-인간 사이 협업의 한계와 새로운 협업 패러다임의 필요성
우리는 git이라는 좋은 형상 관리 툴을 가지고 있다. 그러나 잦은 AI의 코드 수정은 코드 이력과 커밋 단위를 흩트릴 수 있다. 보통 커밋 컨벤션을 정해놓고 협업하는 경우가 많다. 특히, Atomic Commit을 통해 하나의 커밋에는 그룹에서 정한 단위의 변경사항만 담는 경우가 많다.
하지만, AI Agent를 사용하면 이 원칙을 깨트리기 쉽다. AI Agent의 glob, grep, MultiEdit 툴 등으로 여러 범위의 코드를 읽고 변경을 한 번에 수행하는 경향이 있다. 이렇게 코드 변경이 쌓이다보면 빠른 속도를 누릴 수 있겠으나, 코드 리뷰나 이력 관리가 망가질수도 있다. 특히, 특정 기능을 롤백하거나 할 때 MultiEdit의 여파를 주의해야한다. 코드뿐만 아니라 AI가 생성한 주석이나 문서의 버전 관리 또한 빠른 코드의 변화 속도를 따라가지 못해 싱크가 깨지는(Drift) 현상도 생길 수 있다.
이런 일을 막고자한다면 인간 엔지니어의 구체적인 지시, 문서, 작업 스코프 좁히기 등 여러 노력과 추가 비용이 소모된다. 또한, 스코프를 제대로 설정하지 않았을 때 발생하는 협업 문제도 있다. 코드 소유권과 코드 책임의 문제가 크다. 이전까지는 책임의 경계가 확실하게 유지되어왔지만, AI의 동시다발적인 read/write 때문에 충돌이 일어나거나 서로의 책임을 침범하고 모호해질 위험이 있다.
이런 일이 일어나는 근본적인 이유를 알고자 한다면, AI Agent가 사용하는 Tool에 대해서 자세히 알아야한다. 즉, 개발자는 AI Agent가 내부적으로 어떤 도구를 써서 코드를 읽고, 수정하는지 이해해야한다는 뜻이다. 자동으로 맡겨두고 작업 과정이나 Tool 사용 부분을 아예 보지 않는다면 놓치는 부분이 많다.
대부분의 AI Agent는 보통 정규식 기반의 패턴 매칭을 통해 코드를 찾고, 읽고, 수정한다. 여기서 치명적인 맹점이 발생하는데, AI가 패턴 매칭을 할 때 임의로 관련 단어를 생성해서 파일 이름이나 코드를 찾는다는 것이다. 이렇게 AI가 찾은 코드는 “과연 이 코드가 참조해도 되는 올바른 코드인지” 판단할 수 없다. 그렇기에 수정 작업 전에 사용자에게 확인을 받는 것이다.
구체적으로 예를 들면, 대규모 프로젝트에서 패키지 구석에 있는 n년전의 레거시 코드나, 임시 방편으로 짠 코드들이 패턴 매칭에 걸리면, 그것을 참고할 수도 있다는 뜻이다. 물론 AI도 맥락 정보로 최근 패키지 위치 등 여러 데이터를 참고하나, 의도치 않은 패턴 매칭이 일어나는 것은 아닌지 직접 파악해야 한다.
결론
이 모든 위험성을 통제 불가능하기 때문에 사용하지 말라고 주장하는 것이 아니다. 우리는 프롬프트를 통해 AI에게 "커밋 단위를 쪼개라", "이 레거시 코드는 참조하지 마라", "비즈니스 로직의 우선순위는 이것이다"라고 자세하게 지시하여 위험을 회피할 수 있다.
그러나 이러한 지시와 통제에는 반드시 비용이 따른다. AI의 Output이 안전한지 검증하고, AI의 컨텍스트를 컨텍스트 엔지니어링을 통해 이해하면서 제어하고, 사전에 가이드라인과 문서, PRD를 세우고, 복잡한 프롬프트를 정교하게 설계하면서도 그것이 잘 지켜지고 있는지 까지 관리 감독해야하는 일련의 모든 과정 자체가 거대한 “엔지니어링 비용”이자 “인지적 소모”이다.
숙련된 인간 엔지니어가 암묵지로 알고 행하는 것들을 하나하나 언어로 정의하고, 문서로 만들고 팀과 공유하며, 해당 규칙이 잘 지켜졌는지 틈틈이 확인해야한다.
지금 우리가 치르는 이 비용을 감수하면서 “AI-First Development”가 새로운 표준으로 자리 잡을 것인가? 아니면 이 모든 비용조차 무용지물로 만들 AGI의 특이점이 올 것인지는 아직 알 수 없다.
정답은 알 수 없지만 기업들의 변화하는 JD를 볼 때, AI의 동작 과정, 컨텍스트 등 관련 지식에 대해 깊게 고민해보고 더 잘 활용할 수 있는 AI 매니징 지식을 갖추는 것이 필수가 될 것 같다.