본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 02. 21:09

마찰 없는 함정 (The Frictionless Trap)

요약

AI 코딩 에이전트의 도입이 코드 작성 속도와 처리량을 높여주지만, 엔지니어가 시스템의 동작 원리를 깊이 이해하는 인지적 과정을 생략하게 만드는 '마찰 없는 함정'을 경고합니다.

핵심 포인트

  • AI 에이전트는 코드 생성 속도를 높이지만 시스템 이해도를 낮출 수 있음
  • 엔지니어의 핵심 역량은 단순 구현이 아닌 시스템에 대한 멘탈 모델 구축임
  • 구현 과정에서의 마찰은 시스템을 이해하는 '재구성 배당금' 역할을 함
  • 추상화와 AI 도구의 과도한 사용은 엔지니어와 시스템 간의 연결을 약화시킴

최근 AI 코딩 에이전트 (AI coding agents) 도입률이 높은 여러 팀을 관찰해 왔습니다. PR (Pull Request) 양은 늘어났고, 생산성에 대한 인식도 높아졌습니다. 겉보기에는 건강해 보입니다.

하지만 엔지니어들은 본능적으로 작동하는 솔루션을 찾기 위한 가장 단순한 경로를 추구합니다. 이는 대부분 건강한 현상입니다. 실용주의 (Pragmatism)는 전문가의 미덕이니까요. 하지만 인도 (Delivery) 압박이 가해지면, 이러한 경향은 더 멀리 확장됩니다. 즉, 단순히 기능을 구축하는 작업뿐만 아니라, 이해도를 구축하는 인지적 작업 (Cognitive work)을 건너뛰는 단계까지 나아갑니다.

AI 코딩 에이전트가 이러한 경향을 만들어내는 것은 아닙니다. 그들은 이 경향에 대한 마찰 (Friction)을 낮출 뿐입니다. 처리량 (Throughput)이 지배적인 지표인 팀에서는 다음과 같은 상황이 빠르게 기본값 (Default)이 됩니다: 에이전트가 작성하게 하고, 배포하고, 다음으로 넘어간다. 그리고 무언가 조용히 얇아지기 시작합니다.

코드는 더 빠르게 작성됩니다. 하지만 이해도는 그렇지 않습니다. 그리고 이에 대해 더 깊이 생각할수록, 저는 코드 생성 (Code generation) 그 자체가 진정한 변화가 일어나고 있는 지점이라고 믿지 않게 됩니다.

엔지니어링 조직은 의도적으로 구축할 필요가 없었던 무언가에 의존합니다. 바로 자신들이 운영하는 시스템에 대한 축적된 이해 (Accumulated understanding)입니다. 이는 구현, 디버깅 (Debugging), 그리고 압박 속에서 사물이 실제로 어떻게 작동하는지에 대한 정확한 멘탈 모델 (Mental models)을 천천히 개발하는 과정을 거치며 부산물로서 형성됩니다. 이것은 문서가 아니라 엔지니어가 추론하는 방식 속에 살아있습니다. AI 코딩 에이전트는 이것이 형성되는 조건을 변화시키고 있습니다.

제가 함께 일했던 가장 뛰어난 엔지니어들 중 일부는 코드를 빠르게 작성할 수 있어서 핵심적인 가치를 가졌던 것이 아닙니다. 그들을 유능하게 만든 것은 시스템의 여러 계층에 걸쳐 일관된 멘탈 모델을 구축하는 능력이었습니다. 이는 대개 수년간 어려운 문제를 디버깅하고, 예상치 못한 동작을 추적하며, 잘못된 가정을 수정하고, 시스템이 실제로 어떻게 작동하는지에 대한 직관을 점진적으로 개발함으로써 얻어지는 능력이었습니다. 문서를 읽어서 얻은 것이 아닙니다. 시스템 자체와 반복적으로 직접 마주하며 얻은 결과였습니다.

학습 이론 (Learning theory)은 오랫동안 지속적인 이해가 수동적인 노출보다는 능동적인 재구성 (active reconstruction)을 통해 형성된다고 관찰해 왔습니다.¹ 돌이켜보면, 구현 (Implementation) 작업은 결과물을 전달하는 것 이상의 두 번째 기능을 항상 수행해 왔을지도 모릅니다. 즉, 엔지니어가 시스템의 일부를 내부적으로 재구성하여 그 모델이 직관적이 될 때까지 강제하는 역할을 한 것입니다. 이는 부수적인 효과가 아니라, 그 자체로 메커니즘입니다. 저는 이를 '재구성 배당금 (reconstruction dividend)'이라 부르고 싶습니다. 마찰 (friction)이 사라질 때 조용히 함께 사라져 버리는 부분 말입니다.²

현대 소프트웨어 조직은 프레임워크 (frameworks), 플랫폼 (platforms), API, 그리고 물리적 제약을 추상화 (abstract)하는 클라우드 서비스 (cloud services)를 통해 이미 대부분의 엔지니어를 기반 시스템의 상당 부분으로부터 분리해 놓았기 때문에, 이를 놓치기가 더 쉬워졌습니다. 이 중 어느 것도 본질적으로 나쁜 것은 아닙니다. 대부분은 현대 시스템이 확장 (scale)할 수 있게 해주는 바로 그 핵심 요소입니다.

하지만 추상화 (abstraction)에는 항상 트레이드오프 (tradeoff)가 수반되었습니다. 추상화는 국소적으로 인지 부하 (cognitive load)를 제거하는 동시에, 엔지니어와 시스템의 기저 동작 (underlying behaviour) 사이의 거리를 멀어지게 합니다. AI 지원 개발 (AI-assisted development)은 그 거리를 더욱 압축합니다.

이를 파악하기 어렵게 만드는 점은, 이득은 즉각적으로 나타나는 반면 비용은 오랜 기간 대부분 보이지 않는 상태로 유지된다는 것입니다. 복잡한 시스템은 스트레스 상황이 닥쳐 이해도가 희박해진 지점을 드러낼 때까지 최적화 (optimisation)의 결과를 숨기는 경향이 있습니다.

AI 지원 개발의 즉각적인 영향은 측정하기 쉽습니다. 출력값 (output)을 측정할 수 있기 때문입니다. 전달 속도 (delivery speed), 구현 처리량 (implementation throughput), 그리고 PR 속도 (PR velocity)는 모두 운영 지표 (operational metrics)에서 빠르게 드러납니다. 하지만 이해도는 그렇지 않습니다. 저는 팀이 실제로 자신들이 운영하는 시스템을 이해하고 있는지 포착하는 대시보드 (dashboard)를 아직 본 적이 없습니다. 공유된 멘탈 모델 (shared mental models), 디버깅 직관 (debugging intuition), 아키텍처 추론 (architectural reasoning), 그리고 깊은 시스템 이해 (deep systems comprehension)는 천천히 복리로 쌓이며, 조용히 침식됩니다.³

팀들은 근간이 되는 이해(underlying understanding)의 일부가 밑바닥에서부터 얇아지기 시작한 후에도 오랫동안 성공적으로 운영을 지속할 수 있습니다. 사실, 고도로 최적화된 환경은 일반적인 실행 경로(execution paths) 동안 개인에게 요구되는 직접적인 인지적 참여(cognitive engagement)의 양을 줄여주기 때문에, 역설적으로 운영 측면에서 성공하게 되는 경우가 많습니다.

문제는 전문성(expertise)이 일반적인 실행 경로 도중에는 거의 형성되지 않는다는 점입니다.

매끄럽게 작동을 유지하는 시스템은 이해를 구축하는 데 필요한 재구성(reconstruction)을 유도하는 강제 기능(forcing function)을 제공하지 않습니다. 높은 처리량(high throughput), 깔끔한 대시보드, 적은 장애 발생 — 이것들은 바로 그 격차(gap)가 가장 오랫동안 보이지 않게 유지되는 조건들입니다.

격차는 재구성 과정에서 형성됩니다. 모호함 속에서 형성됩니다. 시스템이 예상과 다르게 작동하는 디버깅(debugging) 세션 중에 형성됩니다. 그리고 일관된 설명이 나타날 때까지 사람들이 여러 추상화 계층(abstraction layers)을 한꺼번에 정신적으로 가로질러 가도록 강제하는 장애(incidents) 상황에서 형성됩니다.⁴

AI 보조 개발(AI-assisted development)이 이해의 필요성을 제거하는 것은 아닙니다. 하지만 이해가 형성되는 조건을 변화시키며, 그 차이는 겉으로 보이는 것보다 훨씬 더 중요합니다.

그 격차는 구현 단계에서 예상하지 못한 방식으로 시스템이 처음 고장 나고, 팀 내 그 누구도 이를 설명할 적절한 모델(model)을 가지고 있지 않을 때 표면 위로 드러납니다. 코드가 실패한 것이 아닙니다. 그 실패를 해석할 수 있는 이해가 구축되지 않았던 것입니다.

AI는 이러한 재구성이 일어나는 위치를 제거하기보다는 변화시킬 가능성이 있습니다. 어떤 팀들은 AI가 만들어낸 여유 역량을 아키텍처(architecture), 디버깅, 또는 시스템 추론(systems reasoning)에 더 집중적으로 투자하는 데 사용할 수도 있습니다. 이것이 실제로 일어날지 여부는 도구 자체보다는 그 도구의 사용을 둘러싼 인센티브(incentives)에 달려 있습니다.

엔지니어링 리더들에게 던져진 질문은 AI 보조 개발을 사용할 것인가가 아닙니다. 그들이 구축하고 있는 환경이 여전히 이해가 형성될 수 있는 조건을 만들어내고 있는가 하는 점입니다. 이를 위해서는 직관에 반하는 무언가가 필요합니다. 즉, 특정한 종류의 마찰(friction)을 의도적으로 보존하는 것입니다. 왜냐하면 어떤 것들은 오직 저항(resistance) 속에서만 형성되기 때문입니다.

참고 및 추가 읽을거리:

  1. 생성 효과 (Generation Effect), 바람직한 어려움 (Desirable Difficulties), 그리고 더 넓은 범위의 구성주의 (Constructivism) 연구는 모두 유사한 아이디어를 가리킵니다: 즉, 지속적인 이해는 수동적인 노출보다 능동적인 재구성(active reconstruction)과 노력이 필요한 참여 (effortful engagement)를 통해 더 깊게 형성된다는 점입니다.
  2. 성찰적 실천가 (The Reflective Practitioner, Donald Schön, 1983) — 실행과 성찰의 반복적인 사이클을 통해 실천적 지혜가 어떻게 발달하는지에 대한 Schön의 설명입니다. 실행 사이클이 단축되거나 위임될 때, 직관을 형성하는 성찰 루프 (reflective loop)가 완성되지 않을 수 있습니다.
  3. 야생에서의 인지 (Cognition in the Wild, Edwin Hutchins, 1995) — 실제 환경에서의 분산 인지 (distributed cognition)에 관한 연구입니다. 이해가 순수하게 개인 안에 머무는 것이 아니라, 팀과 도구 전반에 걸쳐 집단적으로 유지되는 방식과 관련이 있습니다.
  4. 암묵지 (Tacit Knowledge)는 문서화나 명시적 교육 (explicit instruction)을 통해 완전히 포착하기 어렵고, 대신 실습과 경험을 통해 나타나는 전문성의 형태를 설명합니다.

AI 자동 생성 콘텐츠

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

원문 바로가기
0

댓글

0