코드를 작성하는 것보다 AI를 지시하는 것이 중요하다: 소프트웨어 엔지니어링의 미래

AI 코딩 에이전트

몇 년 전만 해도 제 업무에서 AI가 흥미로웠던 부분은 제가 코드를 몇 줄 쓰면 그것을 완성해 주는 것을 보는 것이었습니다. 그마저도 이제는 구식처럼 느껴집니다. 2026년의 대부분의 업무에서는 저는 아예 코드를 작성하지 않습니다. 대신, 코드를 작성하는 AI 코딩 에이전트(AI Coding Agents)를 지시하고, 돌아온 결과물을 검토합니다. 흥미로운 부분은 속도가 아닙니다. 중요한 것은 작업의 어려운 부분이 이동했다는 것입니다.

Anthropic의 2026 Agentic Coding Trends Report는 같은 변화를 설명하며 유용한 한계를 제시합니다. 엔지니어들은 자신의 업무 중 약 60퍼센트에서 AI를 사용한다고 보고하지만, 실제로 완전히 위임할 수 있는 작업은 0~20퍼센트에 불과하다고 말합니다. 이 간극이 전체 이야기입니다: 지속적인 사용, 제한된 위임, 그리고 모든 경계에서의 인간의 판단력. 현재 상황은 다음과 같습니다.

자동 완성에서 에이전트 팀으로의 전환

수년 동안 주요 기능은 인라인 제안(inline suggestion)이었습니다. 유용하지만 한정적이었습니다. 오늘날 그것은 기준점일 뿐, 최고점은 아닙니다. 논할 가치가 있는 도구들은 목표를 받아들여 단계로 분해하고, 여러 파일을 편집하며, 테스트를 실행하고, 오류를 읽고, 다시 시도합니다.

아래 비교는 제가 직접 사용한 경험과 함께 일하는 개발자들의 공통된 의견을 반영합니다. 벤치마크 데이터가 아니므로 순위로 취급하기보다는 시작점으로 간주해 주십시오.

작업의 단위는 더 이상 키 입력(keystroke)이 아닙니다. 그것은 하나의 작업(task) 또는 전체 기능(feature)입니다.

에이전트 하네스: 신뢰성이 나오는 곳

모델에게 모든 공을 돌리기 쉽지만, 모델은 이야기의 절반에 불과합니다. 언어 모델 자체만으로는 다음 단계만을 제안할 수 있습니다. 파일을 열거나, 테스트를 실행하거나, 반환되는 오류 메시지를 읽을 수는 없습니다. 단순한 제안 엔진을 실제로 작업을 완료하는 시스템으로 만드는 것은 그 주변 계층, 보통 에이전트 하네스(agent harness)라고 불리는 부분입니다.

하네스는 에이전트가 행동할 수 있도록 하는 지원 시스템입니다. 파일 읽기 및 쓰기, 셸 명령어 실행, 웹 검색, 데이터베이스 질의 등 다양한 도구들을 제공합니다. 또한, 에이전트가 작성한 내용을 이상적으로는 샌드박스(sandbox) 내에서 실행하여 잘못된 명령어가 사용자의 장치를 손상시키지 못하게 합니다.

무엇보다 중요한 것은 다단계 작업을 가능하게 하는 루프를 구동한다는 점입니다. 에이전트는 단계를 선택하고, 이를 실행하며, 결과를 확인한 후, 작업이 완료될 때까지 다음에 무엇을 할지 결정합니다. 이 루프가 없다면 그것은 에이전트가 아닙니다. 추가 단계가 붙은 자동 완성 기능에 불과합니다.

이 계층은 또한 신뢰성(reliability)이 확보되는 곳이기도 합니다. 권한(Permissions)은 에이전트가 건드릴 수 있는 것을 결정합니다. 메모리(Memory)와 체크포인트(checkpoints)는 긴 작업 전반에 걸쳐 이전 결정을 보존합니다. 관찰 가능성(Observability)은 무슨 일이 일어났는지 감사할 수 있게 해줍니다. 이 모든 것이 흥미롭지는 않지만, 데모를 실제 프로덕션 코드에 적용할 수 있는 시스템과 구분 짓는 핵심 요소입니다.

[

](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fe5t7ilw9mlpred86sqgc.png

이전 표의 모든 도구는 자체 개발했든 빌려왔든 이와 같은 구조(harness) 위에 놓여 있습니다. 개발자들이 여러 단계에 걸친 작업에서 어떤 에이전트가 다른 에이전트보다 더 신뢰할 만하다고 말할 때, 그들은 보통 모델 자체가 아니라 이 계층(layer)의 품질을 의미합니다. OpenAI도 Agents SDK harness and sandbox release에서 같은 주장을 하며, SDK reference에는 기본 요소(primitives)들이 나열되어 있습니다.

명세 기반 개발(Spec-Driven Development): 왜 명세가 다시 중요해졌는가

에이전트에게 모호한 프롬프트(prompt)를 준 적이 있는 사람은 누구나 실패 사례를 알고 있습니다. 컴파일은 되지만, 보기에는 그럴듯하고, 결정적으로 핵심을 놓치는 코드를 얻게 됩니다. 세 가지 문제가 팀들을 이 문제를 해결하도록 만들었습니다. 첫째, 프롬프트가 모호해서 에이전트가 추측하며 의도에서 벗어났습니다. 둘째, 코드베이스가 커지면서 에이전트가 여러 파일 전에 내렸던 결정을 잊어버립니다. 그리고 마지막으로, 출력이 정확한지 확인할 명확한 테스트가 거의 없었습니다.

해답은 오래된 아이디어를 새로운 포장지로 재탄생시킨 것입니다. 먼저 명세(specification)를 작성하고, 그것을 진실의 원천(source of truth)으로 취급하며, 그로부터 코드와 테스트 케이스를 생성하는 방식입니다. 요구사항이 변경될 때마다 코드를 수동으로 패치하는 대신, 명세를 업데이트하고 다시 생성하면 됩니다. 이 모든 것 중에서 제가 현행 도구보다 오래 지속되리라 예상하는 것은 바로 이것입니다.

작동하게 만드는 두 가지 관행이 있습니다. 하나는 Rolls-Royce에서 개발한 요구사항 구문(Requirements Syntax)의 쉬운 접근 방식인 EARS 표기법입니다. 이는 요구사항을 제약적이고 테스트 가능한 패턴으로 변환합니다: 사용자가 유효하지 않은 데이터가 포함된 양식을 제출하면 시스템은 관련 필드 옆에 검증 오류를 표시해야 한다. 이러한 구조는 에이전트가 추측으로 채울 수 있는 모호성을 제거해 줍니다. 두 번째는 프로젝트 헌법(project constitution)입니다. 이는 언어 선택, 테스트 표준, 의존성 규칙 등을 확정하는 안정적인 문서로, 모든 기능마다 같은 논쟁을 다시 벌일 필요가 없게 만듭니다.

open tools를 사용해 보세요: Spec Kit, cc-sdd, 또는 Kiro의 spec best practices. 하지만 spec-first development는 공급업체 블로그에서 종종 간과하는 트레이드오프를 안고 옵니다. 사양(Specification)은 아티팩트(artifact)이며, 아티팩트는 표류할 수 있습니다. 한번 사양이 코드와 동기화되지 않으면, 개발자와 에이전트가 구식 요구사항을 계속 신뢰할 수 있기 때문에 아무런 사양이 없는 것보다 더 나쁠 수 있습니다.

Spec-first development는 또한 초기 탐색적 프로토타이핑(exploratory prototyping)에는 적합하지 않습니다. 요구사항이 아직 형태를 갖추고 있는 경우, 이를 EARS 표기법에 강제하는 것은 유용한 구조라기보다는 잘못된 확신을 만들 수 있습니다.

증거 역시 유사한 주의가 필요합니다. 이러한 도구들에 대해 발표된 결과들은 통제된 실험(controlled trials)이라기보다는 주로 공급업체의 사례 연구(vendor case studies)입니다. 생산성 주장을 인용하기 전에, 근본적인 방법론을 확인해야 하며, 특히 40시간 분량의 기능이 8시간 이내에 제공된다는 것처럼 광범위하게 반복되는 수치들을 주의 깊게 살펴봐야 합니다.

MCP: AI 코딩 에이전트를 위한 통합 계층

만약 이 하네스(harness)가 에이전트에게 행동할 수 있게 한다면, 다음 질문은 그것이 어떤 도구와 데이터를 통해 행동에 도달하는지입니다. 이것이 바로 Model Context Protocol (MCP)이며, AI 시스템을 도구 및 데이터에 연결하기 위한 개방형 표준이고, 현재는 기본 답변(default answer)이 되었습니다. 모든 공급업체가 귀하의 데이터베이스나 티켓 트래커로 사적인 다리를 구축하는 대신, MCP는 그들에게 하나의 진입 경로를 제공합니다. 현행 개정판(2026년 7월 28일에 게시됨)은 출시 이후 가장 큰 규모입니다: 일반 HTTP 인프라에서 확장되는 상태 비저장(stateless) 코어, 공식적인 확장 프레임워크, MCP Apps를 통한 서버 렌더링 UI, Tasks 확장을 통한 장기 실행 작업, 그리고 강화된 권한 부여(authorization). 배포 형태를 결정하기 전에 2026년 로드맵을 읽어볼 가치가 있습니다.

더 많은 주의가 필요하지만 간과되는 한 가지 주의사항이 있습니다. 연결하는 모든 MCP 서버는 새로운 공격 표면(attack surface)입니다. 도구 설명과 반환된 콘텐츠 모두 모델 컨텍스트에 들어가기 때문에, 프롬프트 주입(prompt injection)은 단순한 호기심 문제가 아니라 공급망 문제(supply chain problem)가 됩니다. 서버별로 범위 자격 증명(Scope credentials)을 설정하고, 에이전트가 접근할 수 있는 항목 목록을 유지하며, 새로운 커넥터를 새로운 종속성으로 취급해야 합니다.

이는 제가 예상치 못하게 중요해진 기술인 컨텍스트 엔지니어링(context engineering)으로 이어집니다. 좋은 AI 코딩 에이전트를 좌절스러운 에이전트와 구분하는 것은 거의 모델 크기가 아닙니다. 그것은 도구가 파일을 하나씩 처리하는 것이 아니라, 저장소를 인덱싱하고, 종속성을 추적하며, 프로젝트 전반에 걸쳐 추론할 수 있는지 여부입니다. 올바른 컨텍스트를 제공하고 노이즈는 배제하는 것이 작업입니다. 컨텍스트 관리 및 신뢰할 수 있는 시스템 구축에 대한 더 많은 통찰력을 얻으려면 CapeStart AI & Technology Blog의 From Prompt to Production: Building Enterprise-Grade AI Systems Without Fine-Tuning을 확인해 보세요.

코드 검토 및 테스트가 에이전트 루프로 이동하다

에이전트가 코드의 상당 부분을 작성하게 되면, 병목 현상은 그것을 검토하는 쪽으로 이동합니다. Greptile이나 CodeRabbit 같은 AI 리뷰 도구는 풀 리퀘스트(pull request)를 전체 코드베이스와 비교하여 사람이 diff를 훑어볼 때 놓칠 수 있는 크로스 파일 이슈들을 표면화합니다. 이들 중 어느 것도 제품을 이해하는 검토자를 대체하지 못하며, 둘 다 대규모 diff에서는 노이즈를 추가하므로 적절히 조정할 시간을 할애해야 합니다. 테스트 생성 역시 같은 방향으로 움직이고 있으며, 스펙(spec)에서 파생되는 곳에서 가장 잘 작동합니다.

비용도 마찬가지입니다. 개발자들은 이제 성능(capability)만큼 토큰 효율성(token efficiency)에 대해서도 논의하며, 목표 지점에 도달하기 위해 재시도하는 에이전트보다는 처음부터 올바른 결과를 내는 에이전트를 선호합니다.

생산성 증거가 실제로 보여주는 것들

채택률에는 의심의 여지가 없습니다. Stack Overflow의 2025 개발자 설문조사에서 49,000명 이상의 개발자를 대상으로 조사한 결과, 응답자의 84%가 AI 도구를 사용했거나 사용할 계획이라고 답했습니다. 신뢰는 별개의 문제입니다. 33%는 AI 출력의 정확성을 신뢰한다고 말했지만, 46%는 적극적으로 불신하며, 45%는 AI 생성 코드를 디버깅하는 것을 구체적인 좌절감으로 언급했습니다. 이 수치들은 오늘날의 측정치가 아닌 가장 최근의 광범위한 기준선인 2025년의 것입니다.

모두가 주목해야 할 숫자는 METR의 무작위 대조 시험에서 나온 결과로, 이 연구는 2025년 2월부터 6월 사이에 진행되었습니다. 숙련된 오픈 소스 개발자 16명이 자신이 잘 아는 저장소(repository)에서 246개의 실제 작업을 완료했으며, 주로 Cursor Pro와 Claude 3.5 또는 3.7 Sonnet을 사용했습니다. 그들은 AI가 자신들을 24% 더 빠르게 만들 것이라고 예측했습니다. 하지만 실제로 경험한 후에는 20% 더 빨라졌다고 믿었습니다. 측정 결과, 그들은 19% 더 느렸습니다.

이 부분을 주의 깊게 읽어주십시오. 16명의 개발자는 작은 표본이며, 설정은 이미 이해하고 있는 성숙한 코드베이스였고, 도구들은 더 발전했습니다. METR의 자체 후속 연구인 2026년 자료는 선택 효과(selection effects)에 부딪혀 중앙 추정치(central estimate)가 신뢰할 수 없게 되었습니다. 지속 가능한 발견은 19%가 아닙니다. 그것은 인식된 속도 향상(perceived speedup)이 실제 속도 향상의 증거가 아니라는 점입니다.

숫자에 대해 한 가지 더 언급하겠습니다. 이 숫자는 어디서든 접하게 될 것입니다. 코드의 41%가 AI 생성이라는 주장은 2024년 분석에서 유래되었으며, 날짜와 함께 재활용되지 않고 사용되고 있습니다. 다른 측정치들은 27~30%에 더 가깝습니다. 만약 명시된 방법론을 가진 주요 연구(primary study)를 통해 수치를 출처화할 수 없다면, 그 내용은 제외하십시오.

엔지니어링 팀에게 이것이 의미하는 바

도구들이 손으로 할 작업을 처리할 만큼 충분히 좋아졌다는 것입니다. 그것이 전체 변화이며, 생산성 슬라이드보다 더 중요합니다. 왜냐하면 이 변화는 업무의 어려운 부분을 타이핑에서 판단(judgment)으로 옮기기 때문입니다.

어떤 증거도 도구를 내려놓으라고 말하지 않습니다. 그것은 얻는 이득이 실재하며, 불균등하고, 어떻게 작업하느냐에 따라 달라진다고 말합니다. 에이전트(Agents)들은 그린필드 코드(greenfield code), 명확한 과제, 그리고 잘 정의된 변경 사항에서 효과를 발휘합니다. 그들은 이미 잘 알고 있는 성숙 시스템에서는 오히려 독이 됩니다. 이것이 바로 METR 시험이 도달했던 지점입니다. 위임하기 전에 자신이 어떤 상황에 놓여 있는지 아는 것이 중요합니다.

이번 주 세 가지 조치: