에이전틱 코딩이 흐름 상태를 깨뜨리는 이유를 ‘차분한 기술’ 관점에서 분석하고, 채팅봇이 아닌 형태의 AI 보조 개발 도구 아이디어를 제안한다.
나는 전반적으로 AI에 꽤 우호적인 편이지만 한 가지 큰 예외가 있다: 에이전틱 코딩(agentic coding)이다. 내게 일관된 인상은, 에이전틱 코딩이 실제로는 생산성을 개선하지 못하고 사용자가 코드베이스에 대해 느끼는 편안함과 친숙함을 오히려 악화시킨다는 것이다. 나는 다음을 통해 그런 인상을 갖게 되었다:
에이전틱 코딩 도구를 사용할 때마다 결과물의 품질에 늘 감탄하지 못했다.
나는 인터뷰 과제에서 지원자들이 에이전틱 코딩 도구를 사용하도록 허용하는데, 그렇게 하는 지원자들은 다른 지원자들보다 일관되게 더 성과가 나빴다. 과제를 끝내지 못하거나 잘못된 결과를 내곤 했다1. 처음에는 에이전틱 코딩이 불공정한 이점을 줄 거라고 예상했기 때문에 나로서도 매우 놀라운 일이었지만… 아니었다!
Becker 연구나 Shen 연구 같은 연구들은, 코드 작성 속도/양이 아니라 고정된 산출물(결과물)을 기준으로 생산성을 측정하면 에이전틱 코딩 사용자가 더 잘하지 못하고, 때로는 더 못한다는 점을 보여준다.
나는 에이전틱 코딩이 가망이 없다고는 생각하지 않는다. 하지만 지금의 구현 형태로는 소프트웨어 개발에 득보다 실이 더 많다고 믿는다. 또한 에이전틱 코딩의 부족함을 계속 파고들어 개발자를 더 잘 돕고 코드 품질을 높이도록 만드는 일은 여전히 가치가 있다고 생각한다.
다만 이 글에서는 다른 접근을 하려 한다. 소프트웨어 개발에서 AI를 활용할 수 있는 다른 방법들을 제시하고 싶다. 에이전틱 코딩이 문화적 상상력을 너무 강하게 사로잡은 나머지, 사람들이 AI 보조 소프트웨어 개발의 다른 훌륭하고 덜 탐구된 해결책들을 놓치고 있다고 믿기 때문이다.
나는 업계의 유행/과장에 반응하기보다는 제1원리(first principles)에서 출발해 도구와 인터페이스를 설계하는 걸 좋아한다. DevProd 분야에서 10년 넘게 일하며, 또 그보다 더 오랜 기간 오픈소스 프로젝트와 기여를 해오며 꽤 많은 일반 설계 원칙을 축적했다.
그 설계 원칙 중 하나가 내 개인적인 “마스터 큐(master cue)”인데, 이것이다:
좋은 도구나 인터페이스는 사용자가 가능한 한 오래 ‘흐름 상태(flow state)’를 유지하도록 해야 한다
이 원칙은 AI 보조 소프트웨어 개발에만 국한된 것도 아니다. 그럼에도 에이전틱 코딩이 왜 종종 빗나가는지 보여준다. 연구와 개발자들의 증언 모두, 에이전틱 코딩이 일반적인 코딩보다 흐름을 더 자주 끊고 개발자를 유휴/대기(언제든 방해받을 수 있는) 상태로 더 오래 묶어 둔다고 말한다.
예를 들어, Becker 연구는 화면 녹화를 통해 유휴 시간이 대략 두 배로 증가한 것을 관찰했다:
나는 “흐름 상태를 보존하기”를 북극성(north star)으로 삼는다면, 에이전틱이든 아니든 AI 보조 코딩 도구를 개선할 수 있다고 믿는다.
차분한 기술은 우리가 만드는 도구에서 흐름 상태를 촉진하는 설계 분야다. 코딩과 가장 관련이 큰 설계 원칙은 다음과 같다:
주의에 대한 방해와 침입은 흐름 상태를 깨뜨린다.
도구 자체가 주목의 대상이 되어서는 안 된다. 대신 도구는 (도구가 작용하는) 진짜 주목 대상이 드러나도록 드러내야 하며, 그것을 가리거나 흐리면 안 된다. 도구를 더 많이 사용할수록, 도구는 우리 인식의 배경으로 더 희미해지면서도 작업을 계속 지원해야 한다.
차분한 상태는 사용자가 흐름 상태에 들어가고 유지하는 데 도움이 된다.
엔지니어들은 이미 일상 업무에서 “차분한” 도구와 인터페이스를 사용한다. 아마 여러분도 익숙할 몇 가지 예를 들면:
VSCode 같은 IDE는 인레이 힌트를 지원해, 독자에게 유용한 주석을 코드 위에 뿌려줄 수 있다. 예를 들어 추론된 타입 주석 같은 것들이다:
이런 인레이 힌트는 다음 이유로 차분한 설계 원칙을 구현한다:
관심이 있으면 볼 수 있도록 주의의 주변부에 존재하지만, 관심이 없으면 눈에 거슬리지 않는다.
우리가 편집하는 코드를 대체하거나 대신하지 않는다. 코드 편집 경험을 강화하지만 사용자는 여전히 편집 중인 코드와 직접 접촉한다. 타입 힌트를 더 많이 사용할수록 힌트는 인식의 배경으로 더 사라지고, 코드는 주의의 중심으로 남는다.
코드 이해를 수동적으로 도와줌으로써 차분함을 촉진한다. 차분한 기술 원칙 중 하나의 표현을 빌리면: “기술은 소통할 수 있지만, 꼭 말할 필요는 없다.”
VSCode나 GitHub의 풀 리퀘스트 뷰어 같은 도구는 다음처럼 파일 트리 변경을 한눈에 미리 볼 수 있게 해준다:
여러분은 “예시로 들기엔 너무 재미없지 않나”라고 생각할 수도 있다. 하지만 그게 핵심이다. (차분한 기술 원칙으로 설계된) 최고의 도구는 스위치처럼 우리 삶에 널리 퍼져 있고 지루한 것들이다. 너무나 배경으로 사라져서 일상 워크플로의 일부로 존재한다는 사실조차 잊게 된다(전등 스위치처럼).
파일 트리 미리보기는:
정보가 필요하면 거기 있지만, 필요 없으면 무시하기 쉽다(심지어 존재를 잊을 정도로).
파일 트리 뷰어와 상호작용할 때 우리는 파일 시스템과 직접 상호작용한다. 표현(뷰어)과 현실(파일 시스템) 사이의 상호작용은 직접적이고, 빠르며, 정확하게 느껴진다. 뷰어를 더 많이 사용할수록, 표현은 ذهن속에서 현실과 구분되지 않게 된다.
프로젝트 구조의 최신 정보를 얻기 위해 파일 트리와 끊임없이 상호작용할 필요가 없다. 프로젝트를 변경하면 백그라운드에서 수동적으로 업데이트되며, 그 업데이트는 눈에 띄지 않고 주의를 끌지 않는다.
같은 렌즈로 채팅 기반 에이전틱 코딩 도구의 한계를 생각해볼 수 있다:
사용자는 에이전트가 보고할 때까지 앉아서 기다리거나, 다른 일을 하면서 LLM을 반자율적으로 돌려야 한다. 하지만 반자율 세션조차 사용자가 언제든 방해받을 수 있어야 하므로 흐름 상태에 들어가는 것을 막는다.
채팅 에이전트는 코드에 대한 고도로 매개된 인터페이스이며, 간접적(코드보다 에이전트와 더 많이 상호작용), 느림(기다리는 시간이 많음), 부정확함(영어는 무딘 인터페이스)이라는 문제가 있다.
새 정보를 얻거나 코드 이해를 업데이트하려면 사용자가 계속 채팅을 자극해야 한다(채팅 에이전트는 사용자의 이해를 수동적/조용히 알려주지 않는다). 또한 채팅 에이전트는 참여(engagement)를 극대화하도록 파인튜닝되는 경향이 있다.
차분한 설계 원칙을 일부 모델링하기 시작한 AI 코딩 보조 도구의 가장 이른 사례 중 하나는, 원조 AI 어시스턴트인 GitHub Copilot의 인라인 제안 지원이다(다만 몇 가지 단서가 있다).
이 기능이 정말 잘하는 한 가지는:
사용자는 여전히 코드와 직접 상호작용하고, 제안은 꽤 빠르게 나타난다. 또한 사용자는 제안을 무시하거나 제안 위로 계속 타이핑할 수 있다.
하지만 기본 설정에서는 다른 차분한 기술 원칙을 위반한다:
기본적으로 Copilot은 제안을 꽤 자주 표시하고, 사용자는 하던 일을 멈추고 제안 출력을 살펴봐야 한다. 충분히 반복되면 사용자는 제안을 기다리며 정기적으로 멈추는 습관을 조건화하게 되고, 이는 흐름 상태를 깨뜨린다. 이제 사용자는 능동적이기보다 도구에 의해 반응적으로 길들여진다.
GitHub Copilot의 인라인 제안 인터페이스는 시각적으로 복잡하고 침입적이다. 사용자가 모든 제안을 무시하더라도 여전히 방해가 된다. 제안은 시각적 초점의 한가운데에 나타나고, 사용자는 진행하기 전에 수락할지 무시할지 즉석에서 결정해야 한다. 이런 방식으로 제시된 정보를 수동적으로 흡수하기도 어렵다. 각 제안을 이해하려면 사용자의 집중된 주의가 필요하다.
… 하지만 이런 문제는 자동 제안을 끄고 Alt + \로 명시적으로 트리거하도록 바꾸면 부분적으로 해결된다. 그러나 불행히도 그렇게 하면 내가 더 좋아하는 다음 기능도 비활성화된다:
다음 편집 제안은 관련 후속 편집을 파일/프로젝트 전반에 걸쳐 표시해 주고, 사용자가 그것들을 순환하며 각 제안 변경을 수락할지 결정할 수 있게 해주는 GitHub Copilot 기능이다. “초강력 찾아 바꾸기”처럼 동작한다.
이 제안들은 사용자를 흐름 상태에 머물게 하는 데 놀라울 정도로 훌륭하다:
인라인 제안보다 인지 부하가 작은데, 제안이 더 자주 한입 크기(bite-sized)로 나오기 때문이며(그래서 사람이 검토하고 수락하기 더 쉽다).
인라인 제안과 마찬가지로, 다음 편집 제안도 사용자를 수정 중인 코드에 가깝게 붙들어 둔다.
제안은 눈에 거슬리지 않는 방식으로 제시된다. 사용자의 주의 한가운데에 쏟아붓지 않고 즉각적인 검토를 강요하지도 않는다. 사용자는 주변부에 있는 코드 제안을 무시할 수도, 원할 때 집중할 수도 있다.
나는 AI 보조 코딩 도구에 아직 발굴되지 않은 잠재력이 매우 크다고 믿는다. 이 섹션에서는 다음 세대 코딩 도구를 만들 때 차분한 기술 설계 원칙을 구현할 수 있는 몇 가지 작은 예를 스케치해보겠다.
의미적 패싯(semantic facet)의 트리로 프로젝트를 탐색할 수 있다. 예를 들어 Dhall의 Haskell 구현을 편집하고 있다면, 트리 뷰어는 내가 대충 만들어본 이 프로토타입2처럼 보일 수 있다.
여기서 목표는 의도(intent) 기준으로 프로젝트를 빠르게 탐색하는 방법을 제공하는 것뿐 아니라, 사용자가 이 기능을 더 많이 사용할수록 프로젝트 이해가 더 좋아지게 하는 것이다. “문자열 보간 회귀(string interpolation regression)”는 dhall/tests/format/issue2078A.dhall3보다 훨씬 더 많은 정보를 준다.
또한 위 영상은 단순한 목업이 아니라 실제 도구를 바탕으로 한다. 내가 그 의미적 패싯 트리를 생성하기 위해 사용한 코드는 여기에서 찾을 수 있고, 그 코드가 어떻게 동작하는지 설명하는 글도 곧 따로 쓸 예정이다.
에디터 세션, diff, 또는 풀 리퀘스트를 입력으로 받아 더 집중된 일련의 커밋들로 자동 분할할 수 있다. 그러면 사람들이 리뷰하기 훨씬 쉬워진다. 이건 AI가 사람의 리뷰 노동을 줄일 수 있는 사례 중 하나다(대부분의 에이전틱 코딩 도구는 사람의 리뷰 노동을 늘린다).
선행 사례가 약간 있긴 하지만, 여전히 초기 단계(nascent) 영역이다.
사용자 툴바나 컨텍스트 메뉴에 두 가지 새 도구를 추가할 수 있다: “...에 집중(Focus on…)” 과 “...로 편집(Edit as…)”.
_“...에 집중(Focus on…)”_은 사용자가 무엇을 바꾸는 데 관심이 있는지 지정하게 하고, 그 관심사와 관련된 파일과 코드 라인만 에디터에 보여주는 기능이다. 예를 들어 “커맨드라인 옵션”에 집중하고 싶다면 관련된 파일과 코드 라인만 표시되고, 다른 라인들은 숨김/접힘/폴딩 처리된다. 이는 기본적으로 “Zen 모드”를 특정 기능 도메인 편집에 적용한 것과 비슷하다.
_“...로 편집(Edit as…)”_은 파일이나 선택된 코드를 다른 프로그래밍 언어나 파일 포맷으로 편집하는 것처럼 편집할 수 있게 한다. 예를 들어 Haskell을 처음 접하는 사람이 Haskell 파일을 “Python으로” 편집하고, 편집이 끝나면 AI가 그 변경을 Haskell로 역전파(back-propagate)하려 시도할 수 있다. 또는 커맨드라인 파서를 수정하는 사람이 파일을 “YAML로” 편집하고, 커맨드라인 옵션을 단순화한 YAML 표현을 제공받아 새 옵션을 추가할 수 있다.
이 글은 분명 아이디어를 망라한 목록은 아니다. 하지만 단지 또 하나의 챗봇을 만드는 것 말고도, AI를 사람들의 워크플로에 통합하는 더 혁신적인 방법을 생각해보자고 독려하기 위해 썼다. 나는 채팅은 LLM을 위한 가장 흥미 없는 인터페이스라고 강하게 믿으며, AI 보조 소프트웨어 개발도 예외가 아니다.
올바른 출력 결과를 얻는 것조차 코딩 과제에서 어려운 부분이 되도록 설계한 게 아니었다. 표준 인터뷰 과제는 후보자에게 프로그램이 맞춰야 할 정답 출력(golden output)을 제공했는데, 에이전틱 코더들은 그 정답 출력에 맞추지 못했을 뿐 아니라, 때로는 프로그램이 정답 출력과 일치하지 않는다는 사실조차 알아차리지 못했다. 에이전틱하게 코딩한 해법을 실제로 실행해 정답 여부를 확인하지도 않았기 때문이다. 과제의 진짜 어려운 부분은 프로덕션까지 가는 여정에 대한 후속 질문들이었는데, 바이브 코더(vibe coder)들은 그 부분에서도 성과가 더 나빴다. ↩
클러스터 라벨러는 아직 개선이 필요하지만, 의도는 알 수 있을 것이다. ↩
그건 내가 파일 이름을 그렇게 지은 탓이다 😅. ↩
Copyright © 2026 Gabriella Gonzalez. 이 작업은 CC BY-SA 4.0 라이선스 하에 제공된다.
