에이전틱 코딩을 넘어서
게시일: 2026년 4월 1일 | 원문 작성일: 2026년 2월 7일 | 저자: Gabriella Gonzalez | 원문 보기
핵심 요약
에이전틱 코딩은 생산성을 높이지 못하고 오히려 개발자의 몰입 상태(flow state)를 깨뜨리고 있어요. 저자는 ‘차분한 기술(calm technology)’ 디자인 원칙을 통해 AI 코딩 도구를 더 잘 설계할 수 있다고 주장해요.
- 생산성 향상은 착각 — 개인 경험, 채용 면접, 연구 논문 모두 에이전틱 코딩이 결과물을 개선하지 못한다는 결론을 가리켜요.
- ‘차분한 기술’ 원칙 — 좋은 도구는 주의를 뺏지 않고, 투명하게 작동하며, 차분함을 만들어내야 해요.
- 코드와의 직접 접촉 유지 — 인라인 힌트, 다음 편집 제안처럼 AI가 조용히 도와주는 방식이 더 나은 방향이에요.
- 미개척 가능성 — 시맨틱 탐색, 자동 커밋 분할, 파일 렌즈 등 챗봇보다 훨씬 창의적인 영역이 남아 있어요.
• • •
저는 전반적으로 AI에 꽤 긍정적인 편인데, 딱 하나 큰 예외가 있어요: 에이전틱 코딩이에요. 에이전틱 코딩이 실제로 생산성을 높여주지 못하고, 오히려 사용자가 코드베이스를 편하고 익숙하게 다루는 감각을 무뎌지게 한다는 게 제 일관된 인상이에요. 이 인상은 다음에서 비롯됐어요:
에이전틱 코딩 도구를 쓸 때마다 결과물의 퀄리티에 계속 실망하게 돼요.
면접에서의 경험
면접 후보자들에게 에이전틱 코딩 도구 사용을 허용하고 있는데, 이걸 사용하는 후보자들이 다른 후보자들보다 일관되게 더 나쁜 성적을 보였어요. 과제를 완수하지 못하거나 잘못된 결과를 내놓는 거죠1. 처음에는 에이전틱 코딩이 불공정한 이점을 줄 거라고 예상했기 때문에 정말 놀라운 결과였는데… 아니었어요!
연구 논문들
Becker 연구*와 Shen 연구** 같은 연구들은 코드 속도/양이 아닌 고정된 결과물 기준으로 생산성을 측정했을 때, 에이전틱 코딩 사용자가 더 낫지 않고 때로는 더 나쁜 성과를 보인다는 걸 보여줘요.
에이전틱 코딩이 희망이 없다고는 생각하지 않아요. 하지만 현재의 에이전틱 코딩은 소프트웨어 개발에 득보다 실이 더 크다고 봐요. 에이전틱 코딩의 부족한 점을 계속 밀어붙여서 개발자에게 진짜 도움이 되고 코드 품질도 개선하는 방향으로 가는 건 여전히 가치 있는 일이라고 생각하고요.
하지만 이 글에서는 방향을 좀 바꿔서, 소프트웨어 개발에 AI를 활용하는 다른 방법들을 이야기해보려고 해요. 에이전틱 코딩이 너무 큰 관심을 독차지하는 바람에, 사람들이 AI 지원 소프트웨어 개발의 다른 좋은 가능성들을 놓치고 있거든요.
마스터 큐
저는 업계 트렌드나 과대광고에 반응하기보다는 첫 원칙에서 출발해서 도구와 인터페이스를 설계하는 걸 좋아해요. 10년 넘게 DevProd에서 일하고, 그보다 더 오랜 오픈소스 프로젝트와 기여 경험을 통해 꽤 많은 범용 디자인 원칙을 쌓아왔어요.
그 디자인 원칙 중 하나가 제 개인적인 “마스터 큐”인데, 이래요:
좋은 도구나 인터페이스는 사용자를 가능한 한 오래 몰입 상태(flow state)에 머물게 해야 한다
이 원칙은 꼭 AI 코딩에만 해당되는 게 아닌데도, 에이전틱 코딩이 왜 때로 핵심을 놓치는지를 잘 보여줘요. 연구와 개발자들의 경험담 모두 에이전틱 코딩이 일반 코딩보다 몰입을 더 자주 깨뜨리고, 개발자를 “가만히 앉아서 기다리는” 상태에 더 오래 머물게 한다는 걸 보여줘요.
예를 들어, Becker 연구에서 화면 녹화를 분석한 결과 유휴 시간이 대략 2배로 늘어났어요:
AI 지원 코딩 도구가 에이전틱이든 아니든, “몰입 상태를 지켜주는 것”을 최우선 목표로 삼으면 더 나아질 수 있다고 생각해요.
차분한 기술 (Calm Technology)
차분한 기술(calm technology)†은 우리가 만드는 도구에서 몰입 상태를 촉진하는 디자인 분야예요. 코딩과 가장 관련 있는 디자인 원칙들은 이래요: 주의 최소화 → 투명한 작동 → 차분함 생성.
도구는 우리의 주의에 대한 요구를 최소화해야 해요
흐름이 끊기거나 주의가 분산되면 몰입이 깨져요.
도구는 “투명(pass-through)“하게 만들어져야 해요
도구 자체가 우리 주의의 대상이 되어선 안 돼요. 오히려 도구는 우리가 실제로 주목해야 할 것 — 도구가 다루는 대상 — 을 드러내야 하지, 가려서는 안 돼요. 도구를 많이 쓸수록 도구는 인식의 배경으로 사라지면서도 여전히 작업을 뒷받침해야 해요.
도구는 차분함을 만들고 강화해야 해요 (그래서 이름이 “차분한 기술”이에요)
차분한 상태가 사용자의 몰입 상태 진입과 유지를 도와줘요.
• • •
LLM이 아닌 차분한 기술의 예시들
엔지니어들은 이미 업무의 일부로 “차분한” 도구와 인터페이스를 사용하고 있어요. 아마 이미 익숙할 몇 가지 예시를 들어볼게요:
인레이 힌트 (Inlay Hints)
VSCode 같은 IDE는 추론된 타입 어노테이션 같은 유용한 주석을 코드에 흩뿌리는 인레이 힌트를 지원할 수 있어요:
이런 종류의 인레이 힌트가 차분한 디자인 원칙을 구현하는 이유는 이래요:
우리의 주의에 대한 요구를 최소화해요
궁금하면 볼 수 있지만 그렇지 않으면 방해되지 않는, 주의의 주변부에 조용히 존재해요.
”투명(pass-through)“하게 만들어져 있어요
우리가 편집하는 코드를 대체하거나 치환하지 않아요. 코드 편집 경험을 향상시키지만 사용자는 여전히 편집 중인 코드와 직접 접촉하고 있어요. 타입 힌트를 더 많이 사용할수록 그것들은 인식의 배경으로 사라지고, 코드가 주의의 초점으로 남게 돼요.
차분함을 만들고 강화해요
코드에 대한 이해를 자연스럽게, 의식하지 않아도 채워줌으로써 차분함을 촉진해요. Calm Technology 원칙 중 하나가 이렇게 말하죠: “기술은 소통할 수 있지만, 말할 필요는 없다.”
파일 트리 프리뷰
VSCode나 GitHub의 풀 리퀘스트 뷰어 같은 도구는 파일 트리의 변경사항을 한눈에 미리 볼 수 있게 해줘요, 이렇게요:
“이거 예시로 쓰기엔 너무 재미없는 거 아니야?”라고 생각하실 수 있는데, 그게 바로 핵심이에요. 차분한 기술 원칙으로 설계된 최고의 도구들은 너무 흔하고 지루해서 있는 게 당연한 것들이에요. 전등 스위치처럼요. 인식의 배경 속으로 너무 깊이 스며들어서 일상 워크플로우의 일부라는 것조차 잊어버리게 되는 것들이죠. 이것도 전등 스위치와 같아요.
파일 트리 프리뷰는:
우리의 주의에 대한 요구를 최소화해요
정보가 필요하면 거기 있지만, 사용하지 않으면 무시하기(심지어 존재 자체를 잊기) 쉬워요.
”투명(pass-through)“하게 만들어져 있어요
파일 트리 뷰어와 상호작용할 때 우리는 파일시스템과 직접 상호작용하고 있고, 표현(뷰어)과 실체(파일시스템) 사이의 상호작용이 직접적이고, 빠르고, 정확하게 느껴져요. 뷰어를 더 많이 사용할수록 표현은 우리 머릿속에서 실체와 구분이 안 되게 돼요.
차분함을 만들고 강화해요
프로젝트 구조의 최신 정보를 얻기 위해 파일 트리를 일일이 건드릴 필요가 없어요. 프로젝트를 변경하면 알아서 조용히 업데이트되고, 그 업데이트가 시선을 잡아끌지도 않아요.
• • •
채팅 기반 코딩 에이전트는 차분하지 않아요
같은 렌즈를 통해 채팅 기반 에이전틱 코딩 도구의 한계를 생각해볼 수 있어요:
우리의 주의를 크게 요구해요
사용자는 에이전트가 보고할 때까지 앉아서 기다리거나, 다른 일을 하면서 LLM을 반자율적으로 실행해야 해요. 하지만 반자율 세션조차 사용자가 인터럽트 가능 상태를 유지해야 하기 때문에 몰입 상태에 진입하는 걸 방해해요.
”투명(pass-through)“하게 만들어져 있지 않아요
채팅 에이전트는 코드에 직접 닿지 않는 중개된 인터페이스예요. 간접적이고(코드보다 에이전트와 더 많이 상호작용하게 되고), 느리고(기다리는 시간이 많고), 부정확해요(자연어는 둔탁한 인터페이스‡니까요).
차분함을 훼손해요
새로운 정보를 얻거나 코드에 대한 이해를 업데이트하려면 사용자가 채팅을 계속 찔러봐야 해요. 채팅 에이전트가 알아서 조용히 알려주는 법이 없거든요. 게다가 채팅 에이전트는 사용자의 참여(engagement)를 극대화하도록 파인튜닝되어 있기도 해요.
• • •
차분한 디자인의 선행 사례들
GitHub Copilot의 인라인 제안
차분한 디자인 원칙에 가까워지기 시작한 AI 코딩 어시스턴트의 가장 초기 사례 중 하나가 바로 원조 AI 어시스턴트, GitHub Copilot의 인라인 제안이에요. 몇 가지 아쉬운 점이 있긴 하지만요.
이건 한 가지를 정말 잘해요:
“투명(pass-through)“하게 만들어져 있어요
사용자는 여전히 코드와 직접 상호작용하고 있고, 제안이 상당히 빠르게 나와요. 사용자는 제안을 무시하거나 제안 위로 타이핑해서 넘길 수도 있어요.
하지만 기본 설정에서 이 인라인 제안은 다른 차분한 기술 원칙을 위반해요:
우리의 주의를 요구해요
기본적으로 Copilot은 제안을 꽤 자주 보여주고, 사용자는 하던 일을 멈추고 제안 내용을 살펴봐야 해요. 이걸 충분히 반복하면 사용자는 무의식적으로 멈추고 제안을 기다리는 습관이 들어버리고, 그게 몰입 상태를 깨뜨려요. 원래 능동적으로 코딩하던 사용자가 도구의 출력에 반응만 하는 수동적인 존재로 길들여지는 거예요.
차분함을 훼손해요
GitHub Copilot의 인라인 제안 인터페이스는 시각적으로 산만하고 거슬려요. 사용자가 모든 제안을 무시하더라도 방해 효과는 여전해요: 제안이 시선의 정중앙에 나타나고, 사용자는 계속 진행하기 전에 수락할지 무시할지를 그때그때 결정해야 해요. 이렇게 제시된 정보를 은근히 흡수하기도 어려워요. 제안 하나하나를 이해하려면 집중해서 읽어야 하거든요.
… 하지만 이 문제들은 자동 제안을 비활성화하고 Alt + \로 명시적으로 트리거하도록 설정하면 부분적으로 해결돼요. 그런데 안타깝게도 그러면 다음 기능도 비활성화되는데, 이 기능은 저는 훨씬 더 좋아해요:
다음 편집 제안 (역시 GitHub Copilot)
다음 편집 제안(Next Edit Suggestions)‖은 파일/프로젝트 전체에서 관련 후속 편집을 표시하고 사용자가 이를 순환하며 각 제안된 변경을 수락할 수 있게 하는 GitHub Copilot의 관련 기능이에요. “슈퍼 찾기 및 바꾸기”처럼 동작해요:
이 제안들은 사용자의 몰입 상태를 정말 잘 지켜줘요:
사용자 주의에 대한 요구를 최소화해요
사용자에게 걸리는 인지 부하가 인라인 제안보다 작아요. 제안이 작고 소화하기 쉬운 단위일 가능성이 높아서 사람이 검토하고 수락하기 더 쉽거든요.
”투명(pass-through)“하게 만들어져 있어요
인라인 제안과 마찬가지로, 다음 편집 제안도 사용자가 수정 중인 코드와 긴밀한 접촉을 유지하게 해줘요.
차분함을 만들고 강화해요
제안이 눈에 거슬리지 않는 방식으로 나타나요. 주의의 정중앙에 떨어지지 않고, 즉각적인 검토를 요구하지도 않아요. 무시해도 되고, 여유가 생길 때 살펴봐도 되는, 주의의 주변부에 조용히 존재하는 코드 제안이에요.
• • •
AI 지원 차분한 기술
AI 지원 코딩 도구에는 아직 활용되지 않은 큰 잠재력이 있다고 생각해요. 이 섹션에서는 차분한 기술의 디자인 원칙을 차세대 코딩 도구에 어떻게 적용할 수 있을지 몇 가지 작은 예시를 그려볼게요.
패싯 기반 프로젝트 탐색
시맨틱 패싯(facet) 트리로 프로젝트를 탐색할 수 있을 거예요. 예를 들어, Dhall의 Haskell 구현체§를 편집하고 있다면 트리 뷰어가 제가 대충 만든 이 프로토타입처럼 보일 수 있어요2:
여기서 목표는 의도별로 프로젝트를 빠르게 탐색하는 것뿐만 아니라, 이 기능을 쓰면 쓸수록 사용자가 프로젝트를 더 깊이 이해하게 되는 거예요. “문자열 보간 회귀”가 dhall/tests/format/issue2078A.dhall보다 훨씬 더 많은 정보를 전달하잖아요3.
참고로 위 영상은 목업이 아니라 실제 동작하는 도구에 기반한 거예요. 저 시맨틱 패싯 트리를 생성하는 데 사용한 코드는 여기에서 볼 수 있고, 그 코드가 어떻게 작동하는지 설명하는 글을 곧 따로 올릴 예정이에요.
자동 커밋 리팩터링
편집기 세션, diff, 또는 풀 리퀘스트를 가져와서 사람들이 리뷰하기 더 쉬운 일련의 더 집중된 커밋으로 자동 분할할 수 있을 거예요. 이건 AI가 인간의 리뷰 노동을 줄일 수 있는 경우 중 하나예요 (대부분의 에이전틱 코딩 도구는 인간의 리뷰 노동을 늘려요).
이 분야에는 약간의 선행 사례가 있지만, 아직 초기 단계의 개발 영역이에요.
파일 렌즈
사용자의 툴바나 컨텍스트 메뉴에 두 가지 새로운 도구를 추가할 수 있을 거예요: “집중하기…(Focus on…)”와 “다른 형태로 편집하기…(Edit as…)”.
”집중하기…”는 사용자가 변경하고 싶은 것을 지정하면 지정된 관심사와 관련된 파일과 코드 줄만 보여주는 기능이에요. 예를 들어 “커맨드 라인 옵션”에 집중하고 싶다면, 관련 파일과 코드 줄만 에디터에 표시되고 다른 코드 줄은 숨겨지거나 접힐 거예요. 기본적으로 “젠 모드”와 비슷하지만 관심 있는 기능 도메인 편집에 특화된 거죠.
”다른 형태로 편집하기…”는 파일이나 선택된 코드를 마치 다른 프로그래밍 언어나 파일 포맷인 것처럼 편집할 수 있게 해주는 기능이에요. 예를 들어, Haskell에 익숙하지 않은 사람이 Haskell 파일을 “Python처럼” 편집하고, 편집이 끝나면 AI가 변경사항을 Haskell 코드에 다시 반영하려고 시도하는 거예요. 또는 커맨드 라인 파서를 수정하는 사람이 파일을 “YAML처럼” 편집해서 커맨드 라인 옵션의 단순화된 YAML 표현이 제시되면 이를 수정해서 새 옵션을 추가할 수 있는 거죠.
• • •
마치며
당연히 아이디어를 빠짐없이 나열한 건 아니지만, 또 하나의 챗봇을 만드는 것 말고 AI를 워크플로우에 녹여내는 더 창의적인 방법을 고민해보자는 취지에서 이 글을 썼어요. 채팅은 LLM의 가장 재미없는 인터페이스라고 강하게 믿고 있고, AI 지원 소프트웨어 개발도 이 원칙의 예외가 아니에요.
각주
- 정확한 출력을 내는 것 자체가 과제의 어려운 부분은 아니었어요. 표준 면접 과제에서는 프로그램이 맞춰야 할 정답 출력(골든 아웃풋)이 제공됐는데, 에이전틱 코더들은 정답을 맞추지 못하는 건 물론이고, 심지어 자기 프로그램이 정답과 일치하는지 확인조차 하지 않는 경우도 있었어요. 에이전틱으로 만든 솔루션을 실행해보지도 않은 거예요. 과제에서 진짜 어려운 부분은 프로덕션 배포까지의 과정에 대한 후속 질문이었는데, 바이브 코더들은 여기서도 성적이 더 나빴어요. ↩
- 클러스터 레이블러는 아직 개선이 필요하지만 아이디어는 전달될 거예요. ↩
- 파일 이름을 그렇게 지은 게 저니까 제 탓이긴 하죠. ↩
역자 주
- * Becker 연구: METR(Model Evaluation & Threat Research)에서 2025년 발표한 연구로, 경험 많은 오픈소스 개발자 16명을 대상으로 에이전틱 코딩 도구가 실제 업무 생산성에 미치는 영향을 측정했어요. 개발자들 스스로는 더 빨라졌다고 느꼈지만, 실제 작업 완료 시간은 오히려 19% 느려진 것으로 나타나 큰 반향을 일으킨 연구예요. ↩
- ** Shen 연구: 2025년 arXiv에 발표된 연구로, AI 코딩 도구의 효과를 코드 양이 아닌 고정된 결과물(기능 완성도, 정확성) 기준으로 측정했어요. Becker 연구와 유사하게, 에이전틱 코딩이 코드를 빨리 생성하더라도 최종 결과물의 질은 향상시키지 못한다는 결론을 내렸어요. ↩
- † Calm technology(차분한 기술): Mark Weiser와 John Seely Brown이 1995년 제록스 PARC에서 제안한 디자인 철학이에요. 기술이 사용자의 주의를 빼앗지 않고 ‘배경’에 머물면서 필요할 때만 전면에 나서야 한다는 원칙이에요. Amber Case가 이 개념을 현대적으로 정리한 calmtech.com이 이 분야의 대표적인 리소스예요. ↩
- ‡ Dijkstra의 “둔탁한 인터페이스”: 컴퓨터 과학의 선구자 Edsger W. Dijkstra(1930-2002)가 1978년에 쓴 에세이 EWD667 “On the foolishness of ‘natural language programming‘“에서 나온 표현이에요. 자연어가 프로그래밍 인터페이스로서 너무 모호하고 부정확하다는 주장으로, 저자는 이를 빌려 채팅 기반 코딩의 근본적 한계를 지적하고 있어요. ↩
- § Dhall: 이 글의 저자 Gabriella Gonzalez가 직접 만든 프로그래밍 언어예요. 설정 파일 작성에 특화된 함수형 언어로, JSON이나 YAML의 대안으로 설계되었어요. Haskell 생태계의 주요 기여자이기도 한 저자가 자신의 프로젝트를 예시로 드는 거라 맥락을 알면 더 자연스럽게 읽혀요. 저자의 블로그 haskellforall.com에서 관련 글들을 볼 수 있어요. ↩
- ‖ 다음 편집 제안(Next Edit Suggestions): 2024년 말 GitHub Copilot에 추가된 기능으로, 사용자가 한 곳을 수정하면 파일 내 관련된 다른 부분의 수정도 자동으로 제안해줘요. 예를 들어 함수 이름을 바꾸면, 그 함수를 호출하는 다른 곳들도 함께 바꿔주는 식이에요. 일반 인라인 제안(커서 위치에서 코드를 자동 완성)과 달리, 파일 전체를 아우르는 연쇄 수정을 제안한다는 점이 다릅니다. ↩
• • •
저자 소개: Gabriella Gonzalez는 10년 이상 DevProd에서 일한 경험과 오랜 오픈소스 기여 이력을 가진 소프트웨어 엔지니어예요. Haskell 생태계의 주요 기여자이기도 해요.
참고: 이 글은 Gabriella Gonzalez가 자신의 블로그에 게시한 아티클을 번역한 것이에요.
원문: Beyond agentic coding - Gabriella Gonzalez (2026년 2월 7일)
생성: Claude (Anthropic)