기술 부채를 넘어서: AI 시대의 인지 부채와 의도 부채

게시일: 2026년 3월 26일 | 원문 작성일: 2026년 3월 23일 | 저자: Margaret-Anne Storey | 원문 보기

• • •

학생 팀의 벽: 이 이야기는 어디서나 일어나고 있어요

저자인 Margaret-Anne Storey 교수는 최근 창업 수업에서 이걸 직접 목격했어요. 학생 팀들이 생성형 AI를 활용해서 한 학기 동안 소프트웨어 제품을 만들고 있었는데, 8주차에 한 팀이 벽에 부딪힌 거예요. 간단한 변경이 예상치 못한 곳에서 문제를 일으키고, 진행이 완전히 멈춰버렸어요.

처음에 팀은 기술 부채(technical debt)를 탓했어요. 지저분한 코드, 급하게 만든 구현, 구조적 편법. 그런데 더 깊이 파보니 다른 문제가 드러났죠. 팀원 중 아무도 특정 설계 결정이 왜 내려졌는지, 시스템의 각 부분이 어떻게 맞물려야 하는지 설명할 수 없었어요. 코드가 지저분한 것도 문제였지만, 진짜 문제는 팀이 공유하던 시스템에 대한 이해, 즉 Peter Naur가 “시스템에 대한 이론(theory of the system)“이라 부른 것1이 조용히 흩어져 버린 거였어요.

이건 예외적인 이야기가 아니에요. 생성형 AI는 소프트웨어 엔지니어링의 어려움을 없애주지 않아요. 어려움이 놓이는 자리를 옮길 뿐이죠.

트리플 부채 모델: 소프트웨어 건강의 세 가지 층위

이 논문의 핵심 프레임워크예요. 소프트웨어 시스템은 코드만으로 존재하지 않아요. 세 가지 뚜렷한 층위에 걸쳐 있죠.

이 세 가지 부채가 어떻게 상호작용하는지 시각화해 볼게요.

특히 인지 부채와 의도 부채가 서로를 악화시키는 고리가 주목할 만해요. 의도가 명확하지 않으면 새로운 팀원이 정확한 멘탈 모델을 만들 수 없고, 반대로 시스템을 이해하지 못하는 개발자는 명세서나 결정 기록을 제대로 남길 수도 없거든요.

• • •

AI가 생성한 코드의 숨겨진 비용

오랫동안 소프트웨어 엔지니어들은 기술 부채를 걱정해왔어요.2 속도를 위해 품질을 희생하면 장기적 비용이 쌓인다는 거죠. 그런데 생성형 AI가 진짜 위험이 어디에 있는지를 조용히 바꾸고 있어요.

오늘날 AI 시스템은 개발자가 읽거나 이해할 수 있는 속도보다 빠르게 코드를 생성하죠. 동시에 자동화된 리팩토링, 테스트 생성, 코드 리뷰를 통해 기술 부채를 줄이는 데도 점점 더 기여하고 있고요. 여기서 역설이 생겨요.

코드가 잘 작동할 수 있어요. 아키텍처도 깔끔할 수 있고요. 그런데 팀은 그것이 어떻게 작동하는지 충분히 이해하지 못하거나, 왜 그렇게 만들어졌는지 기억하지 못할 수 있어요. 조직이 학습에 투자하지 않고 생산성 향상만 밀어붙이면, 역설적인 상황이 벌어지죠:

생산성 압박 → 이해력 쌓을 시간 부족 → 이해력 부재 → 시간 절약 불가

기술 부채: 잘 알려진 층위

기술 부채는 개발자들이 의도적으로든 무심코든, 당장의 출시를 장기적인 코드 품질보다 우선시할 때 생겨요. 금융 부채처럼 이자가 붙죠. 오래 방치할수록 시스템을 바꾸는 비용이 커져요.

세 가지 부채 중에서 기술 부채는 눈에 보이기 때문에 가장 관리하기 쉬운 편이에요. 소프트웨어 엔지니어링 커뮤니티가 테스트 주도 개발(TDD), 리팩토링, 코드 리뷰 등 풍부한 실천 방안을 이미 갖추고 있거든요. 생성형 AI도 리팩토링 자동화, 코드 스멜 식별, 테스트 생성을 통해 이 영역에 기여하는 중이고요.

하지만 중요한 포인트가 있어요. 기술 부채가 낮은 코드베이스라도 팀이 이해하지 못하거나 원래 목적을 반영하지 않으면 심각한 문제가 될 수 있다는 점이에요.

인지 부채: 보이지 않는 층위

인지 부채는 “팀이 시스템을 안전하게 바꾸기 위해 공유해야 할 멘탈 모델”이 부족한 상태를 가리켜요. 개발자들은 이걸 “시스템을 제대로 통제하고 있다”는 자신감이 사라지는 느낌으로 경험하죠.

사실 인지 부채 자체는 새로운 개념이 아니에요. 개발자들은 예전부터 불완전한 이해 속에서 일해왔어요. 자기가 만들지 않은 레거시 시스템을 물려받기도 하고, 잘 모르는 라이브러리를 쓰기도 하고, Stack Overflow에서 복사해 온 코드를 이해하지도 않고 붙여넣기도 하면서요. 새로운 건 이 격차가 쌓이는 속도가 훨씬 빨라졌다는 점, 그리고 AI 보조 개발에서는 그걸 알아차리기가 더 어렵다는 점이에요.

인지 항복이 인지 부채로 이어져요

핵심 심리 메커니즘은 Shaw와 Nave가 인지 항복(cognitive surrender)이라 부르는 현상이에요.3 직관적 판단(시스템 1)도 숙고적 분석(시스템 2)도 작동시키지 않은 채, AI 출력물을 그대로 받아들이는 거예요.

이건 인지 오프로딩(cognitive offloading)과는 본질적으로 달라요. 인지 오프로딩은 린터나 타입 체커 같은 도구에 특정 작업을 전략적으로 맡기는, 합리적인 선택이거든요. 반면 인지 항복은 비판적으로 따져보는 자세 자체를 잃게 만들 수 있어요.

더 위험한 건 이거예요: 인지 항복에 빠진 개발자는 AI가 틀렸을 때조차 자신감이 부풀어 오른다는 점이에요. 팀이 실제보다 시스템을 잘 안다고 착각하게 만들어서, 인지 부채가 손쓸 수 없을 때까지 보이질 않죠.

개발자가 직접 코드를 짜면, 지저분한 코드라도 그 과정에서 겪는 마찰과 고민 덕분에 최소한 부분적인 멘탈 모델이 생겨요. AI가 같은 코드를 생성하면, 개발자는 이해를 쌓지 않은 채 그냥 가져다 쓸 수 있죠. 팀 전체에 걸쳐 이게 쌓이면, “모름의 축적(accumulation of not knowing)“이 일어나요.

효과적인 문제 해결은 두 가지 이해의 상호작용으로 이루어져요. “이 문제가 뭐지?”라는 이해와 “이 시스템은 어떻게 돌아가지?”라는 이해가 끊임없이 서로를 교정하는 거죠. AI가 솔루션을 대신 만들어주면 이 피드백 루프가 끊겨요. 개발자에게 남는 건 갈수록 굳어가는 문제에 대한 시야뿐이죠.

인지 부채는 기술 부채처럼 의식적으로 감수할 수도 있어요. 앞서 언급한 창업 수업의 학생들이 좋은 예죠. 아이디어에 대한 빠른 피드백을 얻는 데 집중하면서 이해 부족을 감수한 거예요. 그러면서 의도 부채까지 덩달아 쌓였고, 팀이 어디로 가고 있는지에 대한 공통 이해도 놓쳐버렸어요. 큰 조직에서는 인지 부채가 눈에 안 보이는 데다 규모까지 커서, 얼마나 쌓였는지 파악하기가 훨씬 어렵고요.

인지 부채를 진단하는 신호들

인지 부채는 코드가 아니라 사람의 머릿속에 있기 때문에 측정하기 어렵지만, 눈에 보이는 흔적을 남기긴 해요.

• 변경 저항: 시스템을 이해한다는 자신감이 낮으면 개발자들이 수정을 꺼리게 돼요
• 예상치 못한 결과: 변경했을 때 예상과 전혀 다른 결과가 나온다면, 인지 부채의 확실한 신호예요
• 낮은 버스 팩터(bus factor)4: 시스템을 진짜 이해하는 사람이 한 명뿐이죠
• 번아웃과 스트레스: AI가 코드를 쏟아내는 속도와, 생성된 코드를 리뷰하고 이해하는 데 드는 인지적 부담 사이의 괴리가 피로로 이어져요
• 느리고 예측 불가능한 온보딩: 문서가 있는데도 새 팀원이 적응을 못 해요. 문서는 코드가 뭘 하는지 설명하지, 왜 그런지는 설명하지 않거든요. 게다가 기존 팀원들도 온보딩을 도와주기 어려워해요

인지 부채를 줄이는 실천 방안

기술 부채에 효과적인 실천 방안 중 일부는 여기서도 유용해요. 인간이 하는 코드 리뷰는 결함을 잡기 위해서뿐 아니라 팀 전체에 이해를 전파하는 데 가치가 있고, 페어 프로그래밍도 마찬가지죠. 하지만 인지 부채에는 다른 실천 방안도 필요해요. 기술 부채 관리에서는 잘 쓰이지 않는 것들이죠.

• 시스템 워크스루(system walkthroughs): 개발자들이 자기가 작성하지 않은 코드를 설명하는 세션. 문서화나 리팩토링이 아니라 지식 공유와 이론 구축이 목적이에요.
• 회고(retrospectives)와 포스트모템(post mortems): 문제가 발생했을 때 흩어진 멘탈 모델을 다시 모으는 계기가 돼요.
• 의도적인 온보딩/오프보딩 프로세스: 공유된 이해의 빈 곳을 드러내죠.
• 재구현을 통한 인지 부채 수리: 어차피 코드 생성 비용이 낮으니까, 다른 테스트나 설계를 적용해서 기능을 다시 만들어보면 이해가 회복돼요.

공통 주제가 보이시나요? 인지 부채를 효과적으로 줄이는 실천 방안들은 암묵적 지식을 명시적으로 만드는 것들이에요. 부산물이 아니라 개발 과정의 일부로서요. 바로 이 “외재화의 필요성”이 세 번째 부채로 이어지죠.

의도 부채: 잊혀진 층위

의도 부채는 세 가지 중 가장 간과되어 왔지만, AI 시스템이 소프트웨어 개발에서 더 큰 역할을 맡으면서 점점 더 중요해지고 있어요. 명시적 근거, 목표, 제약 조건, 즉 시스템의 진화 방향을 안내해야 할 것들이 없거나 무너진 상태를 말하죠.

일부 실무자들이 “컨텍스트 부채(context debt)”, 즉 AI 에이전트가 효과적으로 작업하기 위해 필요한 정보가 누락된 상태라고 부르기 시작한 것도 사실은 의도 부채의 증상이에요.

기술 부채가 코드에, 인지 부채가 사람에게 산다면, 의도 부채는 불완전하거나 누락된 비코드 산출물에 존재해요. 요구사항 문서, 아키텍처 결정 기록(ADR), 구현 계획, 인수 테스트, 명세서 같은 것들이 “시스템이 뭘 해야 하는지”를 기록해둔 외부 기억이죠.

흥미로운 통찰이 있어요. 저자는 Marshall McLuhan의 “기술적 되살림(retrieval)” 개념을 인용하는데요.5 새로운 기술이 등장하면, 예전 기술 때문에 불필요해지거나 아예 사라졌던 관행이 되살아나곤 한다는 거예요. AI가 더 많은 코드를 생성하면서, 의도를 포착하는 관행들(명세서, 테스트, 도메인 지식, 설계 근거)이 다시 중요해질 수 있다는 주장이죠.

기술 부채는 나중에 고칠 수 있지만, 의도는 핵심 결정이 내려지는 순간에 포착해야 해요. 나중에 복구하는 건 불가능할 수도 있거든요.

의도 부채를 진단하는 신호들

• 동작 이탈(behaviour drift): 시스템의 실제 동작이 이해관계자들이 생각하는 것과 달라져 있는데, 테스트 중에야 알게 되거나 최악의 경우 고객 장애 때 발견되죠
• AI 에이전트의 헤맴: 광범위한 설명을 요구하거나, 기술적으로는 맞지만 핵심을 놓치는 솔루션을 내놓거나, 예상보다 많은 토큰과 시간을 쓰게 돼요
• 명시된 제약 조건의 소실: 성능 예산, 프라이버시 제약, 접근성 요구사항 같은 비기능적 요구사항을 소수만 알고 있다가 점점 잊혀져요

의도 부채를 줄이는 실천 방안

생성형 AI에 의존하기 전에는 소스 코드가 네이밍과 설계를 통해 인간의 의도를 어느 정도 포착했어요. 하지만 AI가 코드를 생성하게 되면서, 의도 우선 워크플로(intent-first workflows)를 통해 의도를 의식적으로 표현하고 포착해야 하죠.

• 실행 가능한 의도(executable intent): 단순히 동작을 검증하는 게 아니라, 목적을 포착하도록 설계된 BDD 명세와 테스트예요. 실패하면 시스템이 의도에서 벗어났음을 보여주죠.
• 결정 및 근거 기록: 아키텍처 결정 기록(ADR)6은 무엇을 결정했고, 왜 했고, 무엇을 하지 않았는지를 남겨요. 도메인 주도 설계(DDD)의 유비쿼터스 언어7와 협업적 도메인 모델링도 도메인 의도를 코드 전에 명시화하고요.
• AI 보조 개발을 위한 컨텍스트 산출물: 컨텍스트 엔지니어링(스킬, 에이전트 지시, 플레이북)이나 미팅/대화에서 AI로 의도를 포착하는 등 새로운 관행이 등장하고 있어요.

세 부채의 비교

AI가 균형을 바꾸고 있어요

세 가지 부채 모두 새로운 건 아니지만, 생성형 AI가 각 부채의 상대적 중요도와 축적 속도를 바꾸고 있죠.

기술 부채 관리에는 AI가 큰 잠재력을 보여요. 자동화된 리팩토링, AI 보조 코드 리뷰, AI 생성 테스트 스위트가 기술 부채를 줄이고 레거시 시스템 개선을 돕고 있거든요. 현재 추세가 계속된다면, AI가 점점 더 개발자를 대신해 코드 층위를 관리하게 될 수도 있어요.

하지만 인지 부채와 의도 부채에 대해서는 위험 증폭기(risk multiplier)가 될 수 있어요. AI는 코드를 빠르게 생성하지만, 팀이 그 코드를 안전하게 변경할 수 있을 만큼의 이해를 쌓는 속도는 따라가지 못하죠. 불충분한 프롬프트도 일단 받아서 빈틈을 알아서 메우고, 그럴듯해 보이지만 실제 의도와는 동떨어진 결과물을 내놓을 수 있어요. AI가 구현과 문서화 작업을 더 많이 맡을수록, 개발자가 코드를 이해하고 의도를 고민하게 만들던 마찰과 피드백 루프도 약화되고요.

• • •

실천을 위한 시사점

논문은 AI 보조 개발을 하는 소프트웨어 팀을 위해 네 가지 실천적 우선순위를 제시해요.

1. 이해를 산출물로 대하세요

작동하는 코드가 소프트웨어 개발의 결과물인 것처럼, 공유된 이해도 일급 산출물로 취급해야 해요. 코드를 쓰다 보면 저절로 생기는 게 아니거든요. 워크스루, 온보딩/오프보딩 시 지식 이전, 주요 마일스톤마다 명시적으로 시간을 써야 하죠.

2. 의도 우선 워크플로를 채택하세요

AI를 활용한 개발에서는 의도를 일찍 포착하세요. ADR, 잘 작성된 명세, 도메인 모델링, 결정 근거, 명확한 사용자 인수 기준 같은 것들이 인간의 이해를 뒷받침하는 동시에 AI 에이전트에게도 꼭 필요한 원재료거든요.

3. 이해의 자동화에 저항하세요

AI를 사용해서 코드뿐 아니라 문서까지 생성하고 싶은 유혹이 있어요. 팀이 진짜 이해를 쌓지 않은 채 “시스템이 뭘 하는지”에 대한 설명만 만들어내는 거죠. 이건 실제 이해를 겉모습으로 대체하는 것이고, 인지 부채를 감지하기 더 어렵게 만들어요. 앞으로 개발자의 핵심 역량은 코드를 작성하는 게 아니라, 시스템이 무엇을 하고 왜 그런지, 어떻게 진화할 수 있는지를 정확히 이해하고 유지하는 것이 될 수 있어요.

4. 세 층위를 함께 모니터링하세요

기술 부채에는 측정과 모니터링을 위한 풍부한 도구 생태계가 있어요. 인지 부채와 의도 부채에도 비슷한 관심을 기울여야 하죠. 온보딩 시간 추적, 지식 집중도 메트릭, 요구사항 커버리지 분석, 그리고 문서화된 의도와 실제 동작 사이의 괴리를 점검하는 정기 감사 등이 있죠. 최소한, 팀이 세 가지 차원에서 부채를 줄이기 위해 지금 어떤 실천 방안을 쓰고 있는지 점검해 보는 것만으로도 충분히 가치가 있어요.

열린 논쟁들

논문은 아직 합의되지 않은 흥미로운 질문들도 던져요.

AI가 암묵적 지식을 명시화할 수 있을까요? 일부 실무자들은 AI가 암묵적 지식을 표면화해서 의도 부채를 뒤늦게나마 줄일 수 있다고 제안해요. 반면 문서화의 주된 가치는 그 과정에서 얻는 인간의 이해라는 반론도 있죠.

”의도”를 문서화해야 할까요? 모든 실무자가 의도 포착이 노력할 가치가 있다고 동의하지는 않아요. “어떻게 여기까지 왔는지는 중요하지 않고, 앞으로 어떤 변경이 필요한지에만 집중하면 된다”는 주장도 있거든요.

부채는 위험인가요, 전략인가요? 이 논문은 인지 부채를 관리해야 할 위험으로 다루고 있어요. 동시에, 이해가 반드시 구현 세부사항까지 포괄할 필요는 없고 팀원들 사이에 분산될 수 있다는 점도 인정하죠. 매니저가 항상 팀원을 신뢰해야 했던 것처럼요. AI가 더 많은 개발 작업을 자동화하는 지금, 어느 정도의 부채까지 허용할 수 있는지는 여전히 열린 질문이에요.

마치며

생성형 AI는 소프트웨어를 만드는 속도와 용이성에서 놀라운 이점을 약속해요. 하지만 많은 기술적 전환이 그렇듯, 이점에는 숨겨진 반전이 따라오죠. 바로 기술 부채에서 인지 부채와 의도 부채로의 전환이에요.

AI 보조 개발 시대를 가장 잘 헤쳐나갈 팀과 조직은, 코드 품질에 투자했던 것만큼 이해와 의도에도 적극적으로 투자하는 곳일 거예요. AI 시대에 건강한 소프트웨어 시스템을 유지하려면, 의도와 코드와 이해가 서로 어긋나지 않도록 지켜야 하죠. 소프트웨어 팀은 코드를 관리하는 것과 같은 정성과 긴급함으로 이해를 관리해야 해요.

• • •