본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 08. 23:56

There Are Two Gaps. Agents Closed One. The Other Is Yours.

요약

소프트웨어 개발의 패러다임이 '실행(Execution)' 중심에서 '평가(Evaluation)' 중심으로 이동하고 있습니다. 과거에는 사용자가 무엇을 할지 파악하는 어려움(실행의 골프)이 주된 문제였으나, AI 에이전트가 코드를 생성하며 이 간극을 크게 줄였습니다. 이제 개발자의 핵심 역할은 단순히 코드를 작성하는 것이 아니라, 에이전트가 제시한 결과물을 비판적으로 평가하고 판단하는 능력에 있습니다.

핵심 포인트

  • 소프트웨어 개발의 중심 기술 역량이 '실행'에서 '평가(Evaluation)'로 이동하고 있다.
  • AI 에이전트는 코드 생성 등 실행 과정을 자동화하여, 과거 UX 디자인의 핵심 문제였던 '실행의 골프'를 축소시켰다.
  • 개발자의 새로운 역할은 에이전트가 제시한 결과물의 정확성, 아키텍처 적합성, 경계 사례 등을 판단하는 것이다.
  • 인간-인간 루프(HITL)는 단순히 인간 개입 여부를 넘어, '어느 시점'에 어떤 수준의 검토를 할지 결정하는 디자인적 문제로 진화했다.

에이전트가 코드 40 줄을 생성합니다. 당신은 디프 (diff) 를 읽습니다. 변경 사항을 승인합니다. 거기서 무슨 일이 일어났나요? 당신은 코드를 작성하지 않았습니다. 플로우를 설계하지도 않았습니다. UI 를 클릭하는 것도 하지 않았습니다. 당신은 판단했습니다. 그리고 그 판단, 즉 평가의 이 순간이 현재 소프트웨어 개발에서 가장 중요한 기술입니다. 소프트웨어 개발은 실행 (execution) 에서 평가 (evaluation) 로 이동하고 있습니다. 에이전트는 작성합니다. 인간은 판단합니다. 이 변화에는 이름이 있습니다. 그리고 그것은 새로운 것이 아닙니다. 도 노먼 (Don Norman) 은 1986 년에 이를 설명했습니다. 《Everyday Things 의 디자인의 두 골프 (The Two Gulfs In The Design of Everyday Things)》에서, 노먼은 사용자가 시스템과 상호작용할 때 존재하는 두 가지 근본적인 간극을 소개했습니다: 실행의 골프 (The Gulf of Execution) 는 사용자가 하고자 하는 것과 그것을 어떻게 할지 파악하는 사이의 간극입니다. 이 동작을 어떻게 트리거할까요? 버튼은 어디에 있나요? 올바른 명령어는 무엇인가요? 평가의 골프 (The Gulf of Evaluation) 는 시스템이 한 것과 사용자가 그것이 작동했는지 이해하는 사이의 간극입니다. 그것은 내가 예상한 대로 했나요? 시스템은 올바른 상태인가요? 그것은 맞았나요? 수십 년 동안, UX 와 개발 도구에서 대부분의 힘든 작업은 실행의 골프를 닫는 데 있었습니다. 더 나은 애퍼던스 (affordances). 더 명확한 네비게이션. 자동 완성 (Autocomplete). 시NTAX 하이라이팅 (Syntax highlighting). 문서화. 모두 같은 질문을 목표로 했습니다: 나는 어떻게 이것을 할까요? 에이전트는 이 질문에 답하는 것을 훨씬 쉽게 만들었습니다. 실행의 골프는 축소되었습니다. 평가의 골프는 폭발했습니다. 당신이 에이전트에 무엇을 원하는지 설명할 때 ("이 폼에 입력 유효성 검사를 추가"), 에이전트는 그것을 어떻게 할지 파악하게 하지 않습니다. 그것은 바로 그것을 수행합니다. 코드베이스를 탐색하고 코드를 작성하며 린터 (linter) 를 실행하고 디프를 제시합니다. 실행의 골프는 대폭적으로 축소되었습니다. 단일 인터페이스로 압축되었습니다: 프롬프트입니다. 그러나 그것은 사라지지 않았습니다. 프롬프팅은 자신의 실행의 골프를 가지고 있습니다. 단순해 보이는 동일한 요청 ("입력 유효성 검사 추가") 은 실제로 모호합니다: 클라이언트 측이냐 서버 측이냐? 어떤 라이브러리인가? 어떤 오류 메시지가 필요한가? 사용자는 시스템을 잘 지시할 수 있는 만큼을 여전히 알아야 합니다. 실행의 골프는 프롬프팅으로 압축되었습니다. 평가의 골프는 병목 현상이 되었습니다. 이 구별은 중요합니다. 복잡성은 사라지지 않았습니다. 그것은 이동했습니다. 에이전트 이전에, 대부분의 시간은 실행에 가졌습니다. 평가는 수행하는 자연스러운 부산물로 일어났습니다. 이제 실행이 즉시 이루어졌기 때문에, 병목 현상은 완전히 평가 측면으로 이동했습니다. 검토가 필요한 출력의 양은 검토할 수 있는 시간보다 더 빠르게 증가합니다. 이는 점진적인 변화가 아닙니다. 그것은 질적 변화입니다."}

이 작업이 실제로 무엇을 하는지. 이제 어려운 질문은 어떻게 작성할 것인가가 아니라: 이 구현이 올바른가? 우리 아키텍처와 일치하는가? 에이전트가 놓친 경계 사례가 있는가? 이것이 올바른 접근법인가, 아니면 그냥 하나의 접근법인가? 이를 승인해야 하나? 마지막 질문은 과거에는 단순해졌었다. 이제 그것은 상호작용의 전체 무게를 지니고 있다. 인간-인간 루프 (Human-in-the-loop, HITL) HITL 은 새로운 아이디어가 아니다. ML 시스템에서 잘 확립된 원칙: 자동화된 의사결정 사이클의 어느 시점에서 인간을 관여시켜 정확성, 안전성, 책임성을 보장한다. 고전적인 HITL 질문은 이진적이다: 인간이 루프에 있는가, 예 또는 아니오? 에이전트 도구의 시대에는 이미 그 질문은 답변되어 있다: 예, 당연히. 인간은 출력을 선반 전에 검토한다. 하지만 그 대답은 이제 더 이상 충분하지 않다. 새로운 질문은: 루프의 어느 시점에서 인간이 있어야 하는가? 대답은 세 가지 변수에 달려있다: 위험 수준, 되돌릴 수 있는가, 도메인 전문성이 필요한가. 함께하면 그들은给你 실제적인 heuristics 를 제공한다: 낮은 위험 + 되돌릴 수 있는 (복사 변경, CSS 튜크): 자동 승인, 필요시 사후 검토. 높은 위험 + 되돌릴 수 없는 (스키마 마이그레이션, 결제 흐름): 에이전트가 진행하기 전에 엄격한 게이트링을 가진 사전 검토. 모호한 전문성 (이것이 디자인과 아키텍처에 영향을 미치는가?): 양쪽 모두 루프에 포함. 즉, 인간이 루프에서 어디에 앉는지를 결정하는 것 자체가 평가의 해안 (Gulf of Evaluation) 문제이다. 당신이 올바르게 했는지 알려주는 버튼은 없다. 커서 (Cursor) 를 사례 연구로 Cursor 의 워크플로우가 이를 구체화한다. 개발 사이클의 모든 단계에서 누군가가 평가자를 결정했다. 그 결정은 디자인: 프롬프트 : 인간, 또는 이전 지시에 실행되는 에이전트. 생성 : 에이전트, 능동적 감독이 있거나 없으며. 차이 검토 (Diff Review) : 인간, 또는 에이전트에 위임하여 첫 번째 패스. 유지/거부 (Keep/Reject) : 인간, 또는 사전 정의된 규칙에 기반하여 자동 승인. 테스트 (Tests) : 에이전트, 실패 시 인간 검토. 커밋 (Commit) : 인간, 또는 자동화. PR : BugBot 의 자동 검토, 또는 위험에 따라 인간 검토. 배포 (Deploy) : 인간, 또는 환경에 따라 자동화. 인간은 루프에서 제거되지 않는다. 그들은 그 안에 재위치되며, 위치는 선택이다. 누군가가 체크포인트를 어디에 두는지, 인간 검토가 무엇인지, 자동 승인이 무엇인지를 결정해야 한다. 그것은 기술적 결정이 아니다. 그것은 기술적 결과를 가진 디자인 결정이다. 에이전트가 출력을 생성하는 곳에서는 이 패턴이 반복된다. v0 또는 Google Stitch 에서, 디자이너는 생성된 c

컴포넌트입니다. 루프는 동일합니다. 평가 문제는 동일합니다. 변하는 것은 체크포인트가 얼마나 명시적인지, 그리고 누가 소유하는지에 불과합니다. 이 모든 것에 따른 위험은 있습니다: 평가 피로 (evaluation fatigue). 에이전트가 인간이 의미 있게 검토할 수 있는 속도로 출력을 생성할 때, 읽지 않고 승인하려는 유혹이 생깁니다. 승인은 자동화됩니다. 이 전환의 전체 실패 모드가 바로 이를 방지하려는 것입니다. Gulf of Evaluation 을 잘 설계한다는 것은 그 경향에 대항하여 설계하는 것이며, 단순히 루프에 인간을 두는 것이 충분하다고 가정하는 것을 넘어선다는 뜻입니다.

남은 작업 (The Work That Remains) 에이전트는 실행할 수 있습니다. 확인할 수 있습니다. 버그를 잡을 수 있고, 수정안을 제안하며, 자신의 출력을 검토할 수 있습니다. 그들은 판단 (judgment) 을 개발할 수는 없습니다. 판단은 과정 (course) 에서 배운 기술이 아닙니다. 그것은 작동하지 않는 것을 출시하는 데经过多年的 경험을 통해, 좋은 것과 훌륭한 것을 구분하는 것을 관찰하고, 왜 그것이 맞는지 설명하기 전에 직관을 개발하는 과정을 통해 구축됩니다. 미감 (Taste) 도 동일합니다. 그것은 우수한 작품에 대한 노출, 실수, 그리고 실제 제약의 마찰을 통해 서서히 축적됩니다. 이는 현재 모델의 일시적인 한계가 아닙니다. 이는 규모의 패턴 인식과 시간이 지남에 따라 작업을 수행함으로써 얻어지는 종류의 문맥적 이해 사이의 구조적 차이입니다.

에이전트는 출력을 생성합니다. 그들은 기준 (standards) 을 생성하지 않습니다. 시스템은 답변을 제안할 수 있습니다. 그러나 그들이 수용 가능한지 결정하는 것은 오직 당신뿐입니다. 판단은 당신의 것입니다. 에이전트가 생성할 수 있는 것이 아닙니다.

Further Reading The Design of Everyday Things : Don Norman (1988). 두 Gulf 의 출처입니다. 여전히 인간이 시스템과 상호작용하는 방식에 대한 가장 명확한 설명입니다. Agent Mode : Cursor 공식 문서. 에이전트가 어떻게 작동하고 에이전트 워크플로우에서 인간의 판단이 어디에 해당하는지에 대한 실용적인 분석입니다. Design in Tech Report 2026: From UX to AX : John Maeda. 실행에서 평가로의 전환에 대한 더 넓은 맥락입니다. 2015 년부터 오늘날까지의 역사적 흐름을 읽기 위해 가치가 있습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
3

댓글

0