▲

OpenAI Codex 실사용 리뷰

 (zackproser.com)
14P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • OpenAI Codex는 GitHub 연동 기반의 멀티태스킹 코드 에이전트로, 자연어를 통해 여러 작업을 병렬로 지시할 수 있는 인터페이스를 제공함
  • 사용자는 하루치 작업을 빠르게 쏟아붓고 자동으로 브랜치 생성 및 PR 오픈까지 맡길 수 있으며, 모바일에서도 활용 가능하여 궁극적으로는 원격 중심의 워크플로우를 지원할 수 있음
  • 다만 현재는 에러 처리 미흡, 코드 품질 불안정, 기존 브랜치 업데이트 어려움, 샌드박스 네트워크 차단 등의 문제로 주요 리팩터 작업에는 부적합함
  • Codex는 작은 유지보수 작업 자동화에는 유용하며, 반복 가능한 작업을 빠르게 처리하는 데 실용적임
  • 향후 모델 개선, 다중 모델 믹싱, 고급 통합 기능이 도입된다면 하이레벨 오케스트레이션 도구로 발전할 가능성이 있음

OpenAI Codex의 동작 방식

  • OpenAI Codex는 채팅 기반 UI로, 초대나 $200/월 Pro 구독을 통해 접근 가능함
  • 사용자는 다단계 인증을 거쳐 Codex GitHub 앱을 조직마다 승인해야 하며, Codex가 저장소를 자체 샌드박스로 복제하여 명령 실행 및 브랜치 생성 업무를 대행함
  • 수십 개의 공개·비공개 저장소를 관리하는 경우, 다수 프로젝트 전환 및 작업 대기열 관리 효율성이 뛰어남
  • 1~2개 저장소만 관리한다면, 기존 LLM이나 AI 기능 편집기 사용이 더 가벼운 선택일 수 있음

Codex의 강점

  • 다중 작업 병렬 처리 및 인터페이스

    • 작업별로 저장소·브랜치 지정이 가능하여, 하루치 업무를 자연어로 병렬 등록하는 흐름이 자연스러움
    • Codex는 다수의 작업을 동시에 처리하는 방식을 권장하고 있으며, 이는 본인의 작업 습관과 잘 맞음

  • 유연한 워크플로우와 모바일 지원

    • Codex는 스마트폰에서도 모바일 친화적으로 동작하여, 사무실 밖에서도 효율적 작업 가능성이 높음
    • 업무 시작 시 여러 업무를 등록하고, 야외에서도 계속 계획 및 진행 상황을 관리하는 이상적 사용 시나리오를 지향함

  • 채팅 기반 피드백 및 PR 생성

    • 진행 중인 작업의 로그 및 상태를 채팅 인터페이스로 손쉽게 조회하며, 추가 지시도 가능함
    • 변경 사항이 만족스러우면 Codex가 Pull Request(이하 PR) 를 생성하고 설명을 자동으로 완성함
    • 단계별로 실행 로그와 명령 내역을 확인할 수 있어 좋음

개선이 요구되는 점

  • 불충분한 에러 처리

    • 작업 시작이나 PR 생성이 실패하는 상황에 대한 명확한 피드백 부재로 사용성이 저하됨

  • 코드 품질 및 1회성 작업 실행

    • Codex 모델은 GPT-3 계열로 12개 이상 언어를 지원하지만, 병렬 실행 시 40-60%정도만 만족도 확보 가능함
    • 사소한 유지보수 업무엔 유용하지만, 대규모 리팩터링엔 반복적 PR 생성으로 사용 효율이 떨어짐

  • 브랜치 내 연속 업데이트 미지원

    • 기존 PR 및 브랜치에 연속적 커밋 연동이 어려움으로, 다단계 리팩터 작업은 비효율적임
    • 현재는 단일 작업에서 바로 전달 가능한 간단한 업무에 Codex 사용이 적합함

  • 실행 샌드박스의 네트워크 접근 제약

    • 의도적 설계로 외부 네트워크 접근이 불가하여, 패키지 최신화나 의존성 처리 등 실무상의 다양한 작업에 한계 존재함
    • 예: 외부 패키지 설치 요청 시 동작하지 않음
    • 이런 작업은 여전히 로컬에서 직접 처리하거나, 기존 Bot(Dependabot 등) 기능에 의존해야 함

Did it unlock insane productivity gains for me?

  • 아직은 폭발적인 생산성 향상은 느끼지 못함
  • Codex가 진정한 생산성 혁신으로 이어지려면
    • 더 많은 작업을 1회성 해결 가능하도록 맞춤 설계·알고리듬 개선이 요구됨
    • 기존 브랜치 PR 업데이트 흐름 개선
    • 위임/통합 관리 역량 강화 및, 여러 오픈AI API와의 통합이 확장되어야 함
    • Codex가 하이레벨 오케스트레이터로 진화해야 함
  • 현재 Codex는 루틴한 유지보수·소규모 업데이트 자동화 작업에 활용도가 높음
  • 대규모 기능 개발·리팩터링은 IDE와 LLM 지원 협업이 더 적합함

Final Thoughts

  • Codex는 조용하지만 기대되는 툴
  • 앞으로 다듬어질 기능들을 감안하면, 업무의 시작점 및 조율 도구로 자리 잡을 가능성이 큼
  • 지금은 가볍고 반복적인 작업에 집중하며 개선을 기다릴 시점임
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 Plus 구독자였고 Codex를 테스트해보고 싶어서 Pro로 업그레이드했는데, 솔직히 내 경험상 다소 실망감이 있는 결과물임
    UX도 아직 제대로 잡히지 않은 느낌이고, 결과가 나오는 데 얼마 걸릴지 알 수 없어 답답함이 있음
    Codex의 비동기적인 특성 덕분에 여러 작업을 동시에 돌릴 수 있어서 그나마 나은 부분
    또 불만 중 하나는, 이 도구가 유용하게 사용되려면 환경을 따로 지정해야 한다는 점임
    테스트에 필요한 컨테이너를 돌릴 수 없어 유용성이 크게 떨어지는 문제
    환경이 완전히 인터넷과 격리되어 있어서 활용도가 제한적임
    ChatGPT의 o3가 강력한 이유는 웹을 활용해 정보 검색까지 스스로 할 수 있기 때문인데, Codex는 그런 부분이 부족함
    비교하자면 Claude도 자주 쓰는데, GitHub 레포를 소스로 프로젝트를 만들면 복잡한 React 앱에서 생소한 버그도 잘 찾아줌
    Gemini 역시 컨텍스트 윈도우가 넓어서 요런 기능을 잘 지원함
    물론 OpenAI가 지향하는 바도 이해함
    Codex가 진짜 동료처럼 여러 작업을 맡아 해결해주길 바라지만, 현시점에서는 풀리퀘스트에 너무 집중된 느낌
    그래서 다시 Plus로 다운그레이드해서 조금 더 지켜볼 생각

    • 컨테이너 지원이 꼭 필요하다는 생각

  • 나는 OpenAI에서 일하고 있지만 Codex 팀은 아니고, 여러 프로젝트에 Codex를 성공적으로 사용해온 경험이 있음
    내 작업 방식은 다음과 같음
    항상 동일 프롬프트를 여러 번 실행해서 각각 다른 결과가 나오게 함
    여러 구현을 비교해서 가장 나은 걸 찾고, 프롬프트를 어떻게 바꿨으면 더 좋은 결과로 유도할 수 있었을지 고민
    모델이 틀리게 한 부분을 프롬프트에 수정해서 반복적으로 적용
    이런 식으로 작업을 작은 단위로 쪼개 병렬 실험을 반복하면 방대한 프로젝트도 몇 시간 만에 프롬프트 조율과 코드 검토만으로 끝낼 수 있음
    API 변환 작업뿐 아니라 Triton 커널같이 깊은 코드에도 이런 방식이 매우 유용함

    • "여러 구현 중 제일 나은 걸 고르고, 프롬프트에서 뭘 더 해야 좋은 결과로 가도록 만들 수 있었을지 고민한다"
      비전문가들은 뭐가 '최선인지' 어떻게 구별하는지 궁금함
      결국 올바른 방향을 찾으려면 그 분야 전문성이 필요하고, 이런 점이 LLM이 소프트웨어 엔지니어 일자리를 없애지 못하는 근거라고 생각

    • 수동으로 직접 하시는 작업 방식이 사실 강화학습(RL)의 기초가 될 수 있다는 생각
      UI에서 이런 경험을 약간만 손봐서 실제 데이터로 쓰면 좋은 학습 데이터셋이 나올 듯함

    • 이 방식이 직접 코드 작성하는 것보다 실제로 얼마나 빠른지 궁금함

    • 프롬프트를 새로 바꿨을 때 중요한 게 바뀌면 지금까지 작업을 포기하는 경우가 있는지 궁금함
      사소한 변화가 결과에 큰 영향을 끼치고, 사전 예제가 없는 문제라면 더 어려울 것 같음
      이 작업 방식이 반복되면 오히려 지치거나 본질과 멀어질 수도 있다고 생각
      나한텐 비효율로 느껴질 수도 있는데, 다른 사람들은 이런 반복작업에 더 높은 인내심이 있는지 궁금

  • 난 내 팀에서 Codex 관련 리뷰를 pod에 공유했음 (https://latent.space/p/codex)
    한 번에 쭉 코드 만드는 데는 아주 뛰어난 모델임 (OpenAI SWE 과제에 맞춰 oneshot으로 특히 파인튜닝된 걸로 pod에서 확인)
    상대적으로 통합 기능이 부족함 (예: 브라우저 통합 없고, GitHub 연동도 미흡 — 매 이터레이션마다 새 풀리퀘스트를 열라고 하니, 기존 브랜치에 후속 커밋 넣는 게 불편해서 불만)
    그래도 이런 통합 기능은 시간이 갈수록 개선될 것으로 기대
    시간당 동시 60개 Codex 인스턴스 돌릴 수 있다는 건 Devin(동시 5개)이나 Cursor(배경 에이전트 나오기 전엔 동시 1개)와는 질적으로 다른 차이라고 생각
    내가 Codex 모델의 성능 차이를 눈에 띄게 느끼진 않았는데, OpenAI에선 Codex가 GPT-3에서 파생됐다고 설명하지만 실제론 o3 파인튜닝임

    • “o3 파인튜닝”이란 주장 자체가 헷갈릴 만하단 생각
      OpenAI도 네이밍 규칙이 혼동을 부르고, 이 문제는 AI 회사 대부분이 겪는 것
      Codex는 원래 GPT-3 기반의 구모델이었고, 지금은 CLI와 툴 등 여러 곳에 같은 이름을 재활용하고 있음
      Google도 똑같이 “Gemini Ultra”를 모델명과 구독 상품명 양쪽에 써서 혼란을 주고 있음

    • 나에게 가장 불편한 부분은 네트워크 접근 제한임

      1. git fetch, 업스트림 싱크, 통합 버그 수정 불가
      2. 외부 라이브러리 새로 받아와 통합 실험 불가
        setup script에서 apt install도 안 되게 도메인을 막은 듯
        에이전트도 코드 전체 맥락 파악보단 그냥 git grep부터 하려는 성향이라 (UI 상에서 보임) 그저 그렇다고 느낌

    • Claude Code와 비교했을 때 어떤 점이 다른지 궁금

  • 여러 개의 레포를 빠르게 바꿀 수 있는 기능은 정말 멋지다고 생각
    수많은 예제 앱을 같이 관리하며, README 포맷 변경이나 링크 바꾸는 게, 20군데 이상 반복되면 정말 지루함
    이런 잡무를 Codex에 맡기고 나중에 머지버튼만 누를 수 있다면 나는 매우 행복할 것 같음

    • 나도 똑같은 기분
      곧 그렇게 발전할 거라 예상
      당분간은 Codex로 사소한 유지 보수 작업을 퍼뜨리면서, 대규모 리팩토링이나 중요한 개발은 IDE에서 계속 하게 될 듯함

  • 이런 류의 도구를 비개발자가 코드 변경하는 데 활용할 수 있을지 궁금함
    콘텐츠 수정이나 간단한 CSS 변경 등은 정말 직접 하고 싶지 않고, 테스트는 시각적으로 확인하면 되니 내가 코드리뷰만 하면 충분함
    티켓을 비개발자가 보고, 작업 시작하고, 결과만 "이거 좋아보임" 하면 내가 검토하는 식
    백로그에 있는 사소한 버그/기능 개선에 이상적인 워크플로우라고 생각

    • AI Assist 같은 도구는 결국 최고의 로우코드 플랫폼이 될 수 있다는 생각
      이러다 소프트웨어 엔지니어가 정말 대체될 날이 오지 않을까 기대

    • 하지만 콘텐츠 변경도 깊은 고민이 필요할 때가 많음
      규모가 조금만 있어도 상하류 의존성이 있고, 필드 하나만 추가해도 전체 시스템이 신경써야 할 게 많아짐
      CSS 같은 작은 변경도 사소해 보이지만 실제로 얼마나 작은지는 사용자가 알기 어려움

    • 접근성, 멀티플랫폼(모바일/데스크탑) 등 수많은 이슈도 곧 빠르게 배우게 될 것
      이런 흐름이 사람들이 소프트웨어 엔지니어로 "인바운드" 되게 하는 퍼널처럼 보이기까지 함

  • 작은 작업에선 40~60% 성공률이면 꽤 괜찮다고 생각
    더 복잡하고 깊은 논리가 필요한 작업에서 힘든 점이 있다는 게 알려져서 참고됨

    • 내 테스트 기준에서는, 약간만 비판적 사고가 필요한 작업부터 Codex가 완전히 헤맴
      현 시점 성능은 형편없는 쥬니어 엔지니어 수준임
      예를 들어 변경을 지시했을 때, 컴파일러 경고를 없애려고 클래스의 값을 일괄 nullable로 바꿔버림
      겉으론 작동하고 컴파일도 되지만, 데이터 무결성까지 사라지는 완전히 잘못된 결과
      이런 사례가 꽤 많음
      코드베이스 전체를 Codex에 무감독으로 맡기면 기술부채가 금방 쌓일 걸로 봄

  • Codex가 우리가 자리 비운 채로 일을 잘 하도록 도와줄 거라는 기대는 너무 낙관적으로 느껴짐
    많은 이들에게 "자리 비웠는데도 효과적으로 일함"이란 실은 "실업자의 줄"과 맞닿아 있다고 생각

    • 개발자들이 이런 변화에 즐거워하는 현상 자체가 신기함
      언젠가는 우리가 그냥 앉아서 에이전트가 다 해주는 걸 보면서 돈 받게 되는 날이 올 거라 착각하는 분위기에 놀람
      일이 쉬워져 봤자, 결국 일자리 자체가 사라지는 방향으로 갈 가능성

    • 생산성 증가 역사에서 근로자들이 더 많은 자유시간을 누리는 일은 거의 전례가 없음
      결국은 주주와 경영진 수익, 남은 직원 반만큼의 업무 증가, 나머지는 실업이라는 패턴

    • 당분간은 실업까지는 시간이 더 걸릴 것 같은 생각
      이런 모델들이 90~95% 수준으로 넓은 범주의 작업을 제대로 해내려면 엄청난 노력이 든다고 봄
      뭐든 처음 60~70%는 쉬워도, 마지막 5~10%가 진짜 어렵기 때문
      위에 언급된 대로, 여러 차례 실행해 다양한 결과를 뽑고 골라내는 게 현재론 월등히 비싸며, 모든 작업에 일괄 적용하려면 추론(인퍼런스) 비용이 많이 드는 문제도 있음
      어느 시점엔가 코드 리뷰도 기계가 작성한 코드일수록 반드시 필요하게 될 것
      작은 프로젝트나 소규모 기능에선 기계 작업을 신뢰해도 되겠지만, 오랫동안 유지될 코드베이스라면 인간이 구조 설계와 검토를 계속 해야 할 것
      AI는 다양한 방법을 더 빨리 탐색하게 도울 수 있지만, 최종 결정은 여전히 인간 몫이고, 직접 설계나 리뷰로 품질 유지해야 한다고 생각
      가까운 미래에는 엔지니어링팀들이 백그라운드 에이전트를 적극적으로 활용하는 방법을 모색하게 될 듯
      지금처럼 전부 강력한 모델에 외주시키는 방식엔 회의적
      현재 AI 코드 리뷰 작업은 꽤 답답하니 더 좋은 워크플로우가 필요함
      수년간은 ‘백그라운드 에이전트’ 자체가 회사별로 꼭 필요한 인프라(Infra)로 자리 잡게 될 것
      대부분의 회사는 이런 에이전트 인프라를 직접 호스팅하기보다 API로 쓰게 될 거라 예상
      에이전트 기반 엔지니어링 인프라는 아직 엄청 초기 단계라 새로운 업무 기회도 많아질 것으로 보임 (향후 3~5년간)

    • 낙관적으로 보자면, 무언가를 싸게 만들수록(예: 코드) 오히려 그에 대한 수요가 늘어난다는 점도 있음
      비개발자가 관리자로 활동할 가능성도 있지만, 실제로 사람들은 중요한 업무일수록 더 신뢰할 수 있는 사람(인간)에게 맡기고 싶어하는 경향이 있음을 경험함

    • 소프트웨어 개발자를 말(馬)로, Codex나 Claude Code 같은 신규 모델 에이전트를 자동차로 비유할 수 있다는 생각
      일부 말은 자동차의 운전자가 되고, 일부는 더 이상 수레를 끌 필요가 없어서 실업자가 되는 프레임이 맞을지 고민

  • 지원 언어 목록이 정리된 곳을 찾지 못했음
    공식 소개나 리뷰 어디에도 제대로 나와 있지 않고, 대부분 웹페이지 오타 수정 등 예제로만 설명함

  • 일주일 만에 gptel-tool로 뚝딱 만들 수 있는 수준처럼 보임

답변달기