NewsScrap
← 목록으로
지난 소식

REA Reverse - 무엇이든 리버스 엔지니어링하기

요약
  • 현재의 AI 코딩 에이전트는 작업 분할, 모델 배정, 계획 수립 및 보안 측면에서 기술적 병목 현상을 겪고 있습니다.
  • 향후 효율적인 개발을 위해서는 작업 난도에 따른 자동 모델 전환과 사람이 이해하기 쉬운 계획 수립, 그리고 OS 수준의 샌드박스 보안 기술이 필수적으로 요구됩니다.
  • AI 지원 개발은 발전했지만, 모델을 코드베이스와 시스템에 연결하는 에이전트는 작업 관리, 위임, 소통에서 여전히 병목으로 남아 있음
  • 작업을 하위 과제로 나눠도 병렬 실행과 모델별 위임이 미흡해, 간단한 작업까지 느리고 비싼 모델에 맡기거나 사람이 직접 모델을 바꿔야 함
  • 읽기 어려운 계획, 자기 기능에 대한 무지, 사소한 질문 때문에 멈추는 실행 흐름이 개발자의 시간과 주의력을 계속 요구함
  • 접근하지 말라는 프롬프트나 반복적인 승인 대신, 파일시스템과 네트워크의 접근 경계를 강제하는 OS 수준 샌드박스가 기본으로 필요함
  • 이상적인 에이전트는 비용, 속도, 정확성을 조율하면서 사람이 이해할 계획과 자율 실행을 제공해야 함. 현재의 부족함을 대리인 문제로 보는 가설은 있지만, 충분한 답은 아직 없음
모델의 발전과 에이전트의 정체
  • 2025년 2월 처음 코딩 에이전트를 사용했을 때는 IDE와 AI 채팅 사이에서 복사해 옮기던 작업을 대신해, 파일을 직접 수정하고 오류를 실시간으로 고치는 모습이 인상적이었음
  • 며칠 뒤부터 응답 중단, 원시적인 개발 흐름, 성급한 완료 선언이 반복됐으며, 6개월이면 기반 LLM만큼 인상적인 도구가 될 것이라는 기대와 달리 문제가 이어짐

  • 모델과 에이전트는 다름

    • GPT Astra, Claude Sonnet, GLM-5.3 같은 모델은 텍스트, 이미지, 코드를 생성함
    • Anthropic의 Claude Code, OpenAI의 Codex 같은 에이전트는 모델을 코드베이스와 컴퓨터 시스템에 연결함
    • 모델이 두뇌라면 에이전트는 몸이며, 모델의 텍스트 출력을 실제 명령과 파일 작업으로 이어 줌
작업을 나누지만 제대로 병렬화하거나 위임하지 못함
  • OpenCode는 파일 업로드용 공유 링크를 만드는 PicoShare에 암호 문구로 링크를 보호하는 기능을 추가하면서 약 1,500줄의 새 코드를 작성하는 작업을 10개 하위 작업으로 나눴지만, 모두 순차 실행함
    • 서로 독립적이어서 쉽게 병렬화할 수 있는 작업까지 하나씩 처리함
  • Claude Code도 하위 에이전트 한두 개를 실행하지만, 이들이 모두 끝날 때까지 기다리는 경우가 있음
    • 종단 간 테스트를 몇 분씩 기다린 뒤에야 Git 이력을 살펴보고 커밋 메시지 규칙을 파악해 메시지를 작성하기 시작하는 일이 하루에도 여러 번 발생함
  • 작업 난도에 맞춘 모델 전환도 부족함
    • 5만 줄의 코드에서 특정 패턴을 찾는 작업에도 느리고 비싼 최첨단 모델을 계속 쓰며, 반대로 더 똑똑한 모델이 필요한 상황에서도 자동으로 교체하지 않음
    • 사람이 하위 작업마다 모델과 추론 수준을 바꿀 수는 있지만, 이를 직접 관리해야 한다는 점이 문제임
    • LLM이 작업 난도를 판단하고 가장 저렴하고 빠른 적합 모델을 고를 수 있어야 함
  • 작업의 95%가 단순 반복 작업이어도, 사람이 직접 분할하고 위임하는 데 드는 시간이 커서 결국 가장 똑똑한 모델에 전체를 맡기게 됨
자기 기능을 모르고, 계획도 읽기 어렵게 전달함
  • 자기 기능에 대한 지식이 부족해 Claude Code 사용법을 물으면 온라인 검색부터 하며, 검색한 지침이 설치된 버전과 맞는지도 보장하지 못함
    • 사용하지 않은 기능을 위해 13GB 파일을 내려받는 사례가 있는 반면, 자체 기능을 설명하는 압축 텍스트 50KB조차 설치 패키지에 담지 않음
    • 같은 질문을 다음 날 다시 해도 이전 대화를 기억하지 못하고 검색을 반복하는 것은, 코드 리뷰를 부탁받을 때마다 개발자가 하는 일인지 검색하는 동료와 같음
  • “Plan”과 “Execute” 모드를 나누면 복잡한 작업의 계획을 검토하고 수정한 뒤, 더 빠르고 저렴한 에이전트에 실행을 맡길 수 있음
    • 하지만 계획 자체가 읽기 어려워 검토를 건너뛰고 바로 구현하도록 맡기게 됨
  • Codex와 GPT-6 Astra에 미디어 감상 기록 웹 앱의 기능 추가를 요청했을 때 나온 계획은 저수준 설계 결정의 뒤섞인 목록에 가까웠음
    • 이해하기 좋은 계획은 UI 변경의 큰 그림에서 세부 사항으로 내려가거나, 데이터 모델 변경에서 시작해 상위 동작으로 올라가야 함
    • 기능에 관한 사실을 무작위로 나열하는 것은 실행 계획보다 브레인스토밍에 가까움
사소한 질문 하나로 실행이 멈춤
  • 밤새 처리할 긴 작업을 맡겼지만, 에이전트는 Git 브랜치 이름을 묻느라 시작 2분 만에 멈췄고 아침까지 아무 작업도 하지 않았음
  • 피상적인 세부 사항에 대한 답을 기다리느라 근무 시간 내내 멈춰 있는 직원처럼, 에이전트도 자율적으로 결정할 범위를 제대로 다루지 못함
프롬프트가 아니라 실제 보안 경계가 필요함
  • 처음 사용한 에이전트의 문서는 접근 가능한 파일을 제한하는 파일시스템 권한이나 제한된 chroot 같은 보호 장치 대신, 특정 경로를 읽지 말라는 프롬프트 지침을 쓰도록 안내함
    • 안내대로 지침을 설정했지만 에이전트는 곧 이를 무시하고 비공개 애플리케이션 키를 OpenAI와 Anthropic으로 전송함
  • 실용적으로 사용하려면 광범위한 권한을 줘야 하는 반면, 공급업체 자체 샌드박스를 우회하는 사례도 있음
    • 대안으로 하루 500번씩 “Allow”를 누르는 방식은 언젠가 잘못 클릭할 수 있어 신뢰할 만한 보호책이 아님
  • 샌드박스 기술은 10년 넘게 존재해 왔으며, 에이전트 실수의 피해 범위를 제한할 수 있음
    • 직접 만든 llm-sandbox는 저장소 디렉터리 밖의 파일시스템 접근을 차단함
    • 접근 권한 자체가 없으므로 홈 디렉터리 유출이나 시스템의 중요 파일 삭제를 걱정할 필요가 없음
요구하는 것은 별도 설정이 아닌 기본 동작임
  • 임의의 Git 저장소에서 20만 줄의 스킬 파일을 설치하거나, 숨겨진 기능 플래그를 켜면 문제를 해결할 수 있다는 식의 답은 요구와 다름
  • 기대하는 것은 무작위 플러그인과 스킬 파일을 설치하거나 몇 시간씩 설정을 조정하지 않아도 기본 상태에서 제대로 작동하는 에이전트임
2026년 코딩 에이전트가 갖춰야 할 기본 기능
  • 작업 분할과 모델 배정을 자동으로 수행해야 함
    • 요청을 여러 작업으로 나누고 각 작업에 적합한 모델을 배정함
    • 비용, 속도, 정확성을 최적화하되, 더 빠른 결과를 위해 비용을 늘리는 식으로 사용자가 작업별 우선순위를 조정할 수 있어야 함
  • 사람이 이해하기 쉬운 계획을 작성해야 함
    • 높은 추상화 수준에서 시작해 세부 사항으로 내려가야 함
    • UI 목업, 데이터 흐름도, 의사결정 트리를 만들어야 함
  • 실제 샌드박스 안에서 실행돼야 함
    • OS 수준 보안 기능으로 파일시스템과 네트워크 경계를 강제함
    • 접근 제어는 에이전트가 무시할 수 있는 요청이 아니라 결정론적 코드로 작동해야 함
    • Bash 명령을 검사하는 정규식 목록은 샌드박스가 아님
  • 환경별 접근 권한을 지원해야 함
    • 기본 접근 범위는 저장소 또는 디렉터리 하나로 제한함
    • 세션마다 다른 저장소에 읽기 전용 또는 읽기/쓰기 권한을 추가할 수 있어야 함
  • 자기 기능과 사용법을 정확히 알아야 하며, 작업이나 흐름을 어떻게 요청해야 하는지 온라인 검색 없이 답할 수 있어야 함
  • 모든 LLM 공급자와 무제한 요금제를 사용할 수 있어야 하며, 에이전트 자체는 오픈소스여야 함
  • 무응답 시 자율 결정과 “AFK mode”를 제공해야 함
    • “Execute” 모드에서 질문에 답이 없고 30분간 세션 상호작용이 없으면 스스로 결정함
    • “AFK mode”에서는 30분 대기 없이 진행함
  • 하위 에이전트 직접 제어도 가능해야 함
    • 사용자가 어떤 에이전트 세션에든 들어가 지시하거나, 작업을 조기에 끝내도록 할 수 있어야 함
  • Max 요금제에서 Fable을 사용할 수 없다고 잘못 안내하는 문제에 대한 불만은 수정될 때까지 공급업체 CEO를 형틀에 묶어 둬야 한다는 농담에 이를 정도임
개인 작업 흐름에 맞춘 추가 희망 기능
  • 통합 웹 인터페이스에서 모든 세션과 주의가 필요한 세션을 확인할 수 있으면 좋겠음
    • 백엔드는 로컬에서 실행하고, 시스템에서 임의 명령을 실행하는 인터넷 터널을 열 필요가 없어야 함
    • 휴대전화에서도 잘 작동해야 함
  • 작업 완료 예상 시간을 에이전트와 각 하위 에이전트가 유지해야 함
    • 진행 상황에 따라 계속 갱신하고, 과거 예측의 정확도에 따라 추정 알고리듬을 조정해야 함
  • 자기 세션을 검토해 개선점을 찾아야 함
    • 예를 들어 20GB 로그를 임시 명령으로 분석하느라 5일 동안 하루 1,000달러씩 토큰을 썼다면, 효율적인 전용 도구를 만드는 쪽으로 전환해야 함
  • 언어를 이해하는 변경 비교 화면을 제공해, 에이전트가 바꾼 내용을 보기 위해 GitHub에 푸시할 필요가 없어야 함
  • 네트워크 요청에 비밀정보를 주입하는 프록시를 기본 지원해야 함
    • 인증이 필요한 요청은 수행하되, 자격 증명을 다른 호스트로 유출할 수 없어야 함
  • 공급자 사용량 한도를 모델 선택에 반영해야 함
    • 주간 한도가 3시간 뒤 초기화되고 90%가 남았다면 비용 최소화에 계속 매달리지 않아야 함
  • 설정 가능한 복잡도 기준을 넘는 작업에는 다른 모델의 코드 리뷰를 자동 요청해야 함
    • 두 모델이 수정안에 합의할 때까지 리뷰를 반복해야 함
  • 이 추가 기능 중 일부는 개인적인 작업 흐름에 치우친 요구일 수 있음
에이전트 투자가 부족한 이유에 대한 가설과 한계
  • 에이전트 하네스가 왜 이렇게 부족한지에 대한 만족스러운 답은 없음
  • 가장 유력하게 보는 가설은 대리인 문제(principal-agent problem)임
    • Anthropic, OpenAI, Google 등에서 도구의 방향을 정하는 경영진은 매일 에이전트를 쓰는 일선 개발자와 동떨어져 있으며, 상당수는 인간 개발자를 완전히 자동화하는 미래를 꿈꿈
    • 경영진, 대형 고객, 주주는 이해하기 쉬운 화려한 데모와 벤치마크 점수에 주목함
    • 보안과 개발자의 시간 효율은 데모에서 중요하게 다뤄지지 않으며, 접한 벤치마크도 대부분 에이전트보다 기반 모델을 측정함
  • 다만 AI 기업도 에이전트에 어느 정도 관심을 보인다는 점에서 이 가설만으로는 충분하지 않음
    • Claude와 Codex에 매달 많은 기능이 추가되지만, 최근 실제 작업을 개선한 기능은 떠올리기 어려웠음
  • 사용 경험은 Claude, Codex, OpenCode, Cline, Pi로 한정되며, 일상적으로는 OpenCode와 Claude Code를 사용함
    • 더 나은 에이전트 추천을 요청함
    • 가상의 에이전트를 500억 달러에 인수하려는 기업이 있다면 즉시 VS Code를 포크하겠다는 농담으로 마무리함
키워드
코딩 에이전트작업 분할모델 배정샌드박스
그냥 목록으로
원문 보기 ↗