자명해 보이는 ‘기술 부채’라는 용어를 다시 들여다보며, 실제로는 인지 부하와 구현 노력, 그리고 운영 안정성에 영향을 주는 더 넓은 동인들이 있음을 논한다.
자명해 보이는 용어를 다시 들여다보기
2026년 1월 30일 · Uwe Friedrichsen · 읽는 데 14분
분명히 하자면: 나는 실제로 기술 부채를 잊어야 한다고 생각하지 않는다. 또 이 글은 “부채”가 적절한 은유인지에 대해 n번째로 토론하는 글도 아니다. 나는 그 은유에 대해 강한 의견이 없다. 내가 말하고 싶은 핵심은, 최근의 한 토론에서 결국 이것은 기술 부채 자체의 문제가 아니라 다른 무엇인가의 문제라는 점을 깨달았고, 그 생각을 공유하고 싶었다는 것이다.
그래서 예를 들면 “이건 기술 부채만의 문제가 아니라 기술 부채만큼(혹은 그보다 더) 해로운 영향을 주는 더 많은 것들에 관한 이야기이며, 기술 부채는 원인이기도 하지만 결과이기도 해서 더 복잡하다” 같은 제목이 더 정확했을지도 모른다. 하지만 이 제목은(여전히 정확히 못 박지도 못하면서) 끔찍한 제목일 것이고, 아마 명확해지기는커녕 더 혼란만 줄 것이다. 그래서 나는 단순한, 클릭베이트 같은 제목을 택했고 미리 양해를 구한다.
그러니, 클릭베이트 제목이라 미안하다!
변명은 했으니, 이제 들어가 보자…
최근 한 고객이 기술 부채를 측정해야 한다며 나를 찾았다. 그들은 소프트웨어 현대화(모더나이제이션) 노력을 더 정확히 조정하기 위해, 자사의 시스템 전반에서 기술 부채를 평가하고 싶어 했다. 합리적으로 들리는가? 그렇다. 소프트웨어 현대화에 돈을 쓸 거라면, 먼저 가장 “아픈 곳”, 즉 현대화의 투자 대비 효과가 가장 큰 곳에 투자하자는 것이다.
그들의 시스템 환경은 여러 기술과 프로그래밍 언어로 구성되어 있었기 때문에, 단순히 도구를 하나 사는 것이 선택지인지도 불분명했다. 수십 년에 걸친 소프트웨어 기술과 프로그래밍 언어를 포괄하는 도구(수십 년 된 기업이라면 흔히 겪는 현실)는 드물다. 그리고 그런 도구가 존재하더라도, 원하는 일을 제대로 해내는 경우 대개 매우 비싸다.
그래서 그들은, 비교적 쉽게(가능하면 자동으로) 조사할 수 있는 기술 부채 유용 지표를 내가 개발할 수 있는지 물었다(동시에, 합리적인 가격으로 그 조사를 수행할 수 있는 적절한 도구가 있는지도 확인해 달라고 했다).
그렇게 나는 작업을 시작했다…
잠재적 지표를 고민하면서 나는 기술 부채의 구체적 징후를 떠올려 보았다. 소프트웨어 개발에서 사실상 모두가 이 말을 하니, 지표를 도출할 수 있는 명확한 징후 목록이 어딘가에 있을 것이라 생각했다. 적어도 나는 그렇게 생각했다. 웹을 검색하며 여러 정의와 글을 훑어봤지만, 내 과업에 도움이 되는 것은 찾지 못했다.
대부분의 글은 용어를 다소 추상적으로 정의했다. 보통 기술 부채의 유발 요인과 줄이는 일반적 아이디어도 설명한다. 하지만 지표를 도출할 수 있는 “부채 징후”의 구체적 목록은 제시하지 못했다.
이 점이 다소 이상하게 느껴졌다. 어디를 봐도 사람들은 기술 부채를 말한다. 그렇다면 디자인 패턴 카탈로그처럼 기술 부채 징후의 명확한 카탈로그가 있을 법하다. 하지만 적어도 나는 찾지 못했다. 마치 기술 부채가 주로 일종의 포괄적 구호(“기술 부채를 줄여야 한다”)로 쓰이거나, 무언가를 깎아내리는 반박 불가능한 표현(“이 프로그램은 기술 부채로 가득하다”)으로 쓰이는 것 같았다.
어쩌면 내가 잘못된 곳을 뒤졌을지도 모른다. 어쨌든 그 조사로는 내 과업에 도움이 되는 것을 얻지 못했다. 그래서 나는 처음 원리부터 다시 시작하기로 했다.
처음부터 시작하면서, 나는 “기술 부채를 줄이면 무엇을 달성하려는가?”라는 질문부터 시작했다.
이 질문을 곱씹어 보면, 기술 부채는 _인지 부하(cognitive load)_에 관한 것임을 금방 깨닫게 된다. 기술 부채는 소프트웨어 엔지니어의 인지 부하를 높인다. 시스템에 기술 부채가 많을수록 코드를 이해하기가 더 어려워지고, 변경을 구현하거나 새로운 것을 추가하려 할 때 엔지니어는 더 많은 개념, 땜질, 그 밖의 것들을 머릿속에 넣어 두어야 한다. 즉, 인지 부하가 증가한다.
하지만 인지 부하는 종착점이 아니다. 엔지니어의 인지 부하를 줄이는 것은 그 자체가 목적이 아니다. 인지 부하를 줄이는 것이 왜 바람직한지 생각해 보면, 우리는 인지 부하를 줄임으로써 뒷받침하려는 두 가지 주요 목표에 도달한다:
시스템의 기술 부채를 늘리면, 그 위에서 일하는 개발자의 인지 부하가 증가하고, 이는 곧 우리의 주요 목표에 부정적 영향을 준다:
이는 대략 다음과 같은 의존 그래프를 만든다:
기술 부채 -> 인지 부하 -> 구현 노력의 점증 / 런타임 안정성 악화
여기서 화살표는 “유발한다(drives)”를 의미한다.
지금까지는 기술 부채에서 출발해, 기술 부채를 줄이자는 아이디어 뒤에 있는 실제 목표로 이어지는 인과 연결을 찾았다. 그렇다면 반대 방향은 어떨까? 두 가지 주요 목표가 훼손되는 상황에서 출발해 반대 방향으로 보면 어떤 그래프가 나올까? 인지 부하를 “경유지”로 하여 기술 부채로 이어지는 같은 단순한 그래프가 나올까? 아니면 결과 그래프는 달라질까?
여기서부터 흥미로워진다.
_구현 노력의 점증_을 유발하는 요인을 보면, 즉시 여러 가지 요인이 떠오른다. 예를 들면:
그리고 물론 _인지 부하의 증가_도 있다.
_런타임 안정성 악화_를 보아도 비슷한 패턴이 나타난다. 예를 들면:
그리고 물론 인지 부하 증가로 인해 발생하는 _소프트웨어 버그 증가_도 있다.
여기서 우리는, 두 가지 주요 목표의 훼손에서 출발하면 인지 부하로 이어지는 단순한 선형 구조가 나오지 않는다는 것을 알게 된다. 대신 일종의 “동인 트리(driver tree)”가 나타나며, 인지 부하는 그 잎(leaf) 중 하나일 뿐이다.
한 단계 더 들어가 인지 부하의 동인을 보면, 트리는 더 크게 퍼진다. 소프트웨어 엔지니어의 인지 부하는 기술 부채만으로 증가하는 것이 아니다.
몇 가지 예만 들어보자:
등등. 다시 말하지만 “인지 부하”라는 가지에서 또 하나의 동인 트리가 나온다. 인지 부하의 형제 동인들, 혹은 그 형제들의 동인들까지 같은 연습을 반복하지 않더라도, 우리는 단일 선이 아니라 거대한 동인 트리로 가게 되며, 기술 부채는 그저 잎 하나에 불과하다는 것이 분명해진다.
따라서 _구현 노력의 점증_과 _런타임 안정성 악화_를 줄이고자 한다면, 기술 부채만 보는 것으로는 충분하지 않다. 기술 부채는 퍼즐의 한 조각(정확히는 트리의 잎)일 뿐이다. 시스템에서 기술 부채를 완전히 제거했다 하더라도, 다른 동인들 때문에 여전히 구현은 느리고 런타임 안정성은 나쁠 수 있다.
이 사실을 깨달은 뒤, 나는 기술 부채를 유발하는 것이 무엇인지, 즉 트리의 더 아래를 보려고 했다. 여기서도 흥미로운 것을 깨달았다. 동인들은 기본적으로 두 가지 범주로 나뉘었다.
첫 번째 범주는 기본적으로 _구현 노력의 점증_으로 이어지는 것과 같은 동인들이다. 이 동인들은 즉각적 효과와 지연 효과를 동시에 가진다. 즉각적 효과는 구현 노력의 점증이다. 지연 효과는 해법과 품질에 대한 집중이 떨어지면서 기술 부채가 증가하는 것이다. 또한 이 동인들 중 상당수는 소프트웨어 엔지니어의 인지 부하도 증가시키며, 이는 해법과 품질에 대한 집중을 다시 낮춰 결과적으로 기술 부채를 늘린다.
부수 효과로, 우리의 “깔끔한 트리”가 많은 순환과 상호 의존성을 가진 꽤 복잡한 의존 그래프로 진화하기 시작한다는 것을 알게 된다. 또한 추가 동인들 중 많은 것이 기술 부채에도 영향을 준다는 점도 보게 되는데, 이는 기술 부채만 관리하는 것으로는 충분하지 않다는 앞선 관찰을 강화한다. _구현 노력의 점증_과 _런타임 안정성 악화_라는 상위 목표를 놓고 보면, 기술 부채를 줄이는 것만으로는 충분치 않다. 더 나아가, 다른 동인들을 통제하지 못하면 기술 부채 자체도 낮추기 어렵다.
기술 부채 동인의 두 번째 범주는 개발자 과부하와 그 부정적 결과에 관한 것이다. 예를 들면:
기술 부채의 동인을 종종 이 범주로만 환원하곤 한다. 이 동인들이 (부정적 의미에서) 강력한 동인인 것은 맞지만, 이것들이 기술 부채를 유발하는 유일한 요인은 아니라는 점을 인식하는 것이 중요하다.
이 그림을 본 뒤 내가 스스로에게 던진 질문은 이것이다: 왜 소프트웨어 엔지니어링 커뮤니티에서는 논의를 이렇게 자주 기술 부채로만 제한할까? 기술 부채만 줄이려 해서는 상황이 개선되지 않는다는 것이 분명해졌다. 실제 목표인 _구현 노력의 점증_과 _런타임 안정성 악화_에 미치는 영향은 제한적이다. 그리고 앞서 논의한 다른 동인들을 억제하지 못하면, 기술 부채는 우리가 줄일 수 있는 속도보다 더 빠르게 쌓일 것이다. 게다가, 기술 부채 동인을 논할 때 왜 개발자 과부하에만 그렇게 집중하고 다른 동인들은 무시할까?
이 질문들은 내게는 꽤 난해하며, 좋은 답을 찾는다면 우리의 작업이 미치는 영향을 크게 개선할 수 있을 것이라 생각한다. 하지만 이는 복잡한 이슈이기에 완벽한 답을 찾지는 못했다.
대신 (바라건대) 그럴듯한 추측 하나는 제시할 수 있다. 소프트웨어 엔지니어링 커뮤니티에서 기술 부채로 논의를 자주 제한하는 이유는, 그것이 어떤 중간 단계도 없이 곧바로 우리에게 부정적으로 영향을 주는 것이기 때문이라고 생각한다. 그래서 우리는 즉시 그것을 인식한다.
다른 많은 동인들은 우리의 직접적 인식 범위 밖에 있다. 그것들이 어떤 식으로든 우리에게 부정적 영향을 주고 있을 것이라 “느끼기는” 하지만, 우리가 즉각 경험하는 고통은 아니다.
또한 우리는 그 다른 동인들이 우리의 영향권 밖에 있다고 생각할 수도 있다. 그래서 우리는 우리 손으로 어떻게든 낮출 수 있을 것 같은 기술 부채에 집중한다. 대부분의 다른 동인들은 그렇게 간단하지 않다. 그것들은 다른 주체들이 만들어 내는 것이고, 우리는 그들이 어떻게 일해야 하는지에 대해 발언권이 없다. 그래서 우리가 즉각 경험하고, (시간만 주어진다면) 즉각 손볼 수 있는 기술 부채에 집중하게 되는 것 같다.
기술 부채의 동인으로 개발자 과부하에만 초점을 맞추는 이유도 비슷할 것이다. 이것은 우리가 매일 겪는 고통이다. 대부분에게 매우 현재진행형의 불쾌한 경험이다. 그래서 개발자 과부하는 기술 부채의 지배적 동인으로 인식되기 쉽고, 그저 눈에 덜 띈다는 이유로 다른 동인들을 무심코 놓치게 된다.
다시 말하지만, 이 설명이 정확히 핵심을 찌르는지는 확신할 수 없다. 하지만 설령 그렇지 않더라도, 꽤 많은 진실을 담고 있다고 생각한다. 적어도 우리가 왜 기술 부채에 과도하게 집중하고 큰 그림의 나머지를 놓치는지 더 이해하기 쉽게 해 준다.
질문은 이것이다: 이 통찰로 무엇을 할 것인가?
우리는 기술 부채만으로는 충분하지 않다는 것을 보았다. 기술 부채는 _인지 부하_의 여러 동인 중 하나일 뿐이고, 인지 부하 역시 _구현 노력의 점증_과 _런타임 안정성 악화_의 여러 동인 중 하나일 뿐이다. 게다가, 기술 부채만과 싸우는 것으로는 충분하지 않다. 다른 많은 동인들이 기술 부채를 우리가 줄일 수 있는 속도보다 더 빠르게 끌어올리기 때문이다.
내 개인적 추천은 다음과 같다. 우리는 여전히 기술 부채에 대해 이야기해야 한다. 그리고 기술 부채가 IT 밖의 사람들에게 가장 중요한 것들—구현 노력과 운영 안정성—에 해로운 영향을 준다는 점을 분명히 해야 한다.
하지만 동시에 관점을 넓혀야 한다. 구현 노력과 런타임 안정성에 무엇이 더 영향을 주는지도 분명히 해야 한다. 상황을 개선하려면 무엇이 필요한지 더 총체적으로 논의해야 한다. 특정 종류의 결정과 습관이 어떻게 역효과를 내는지에 대한 인식을 만들어야 한다.2
이것이 기술 부채만 이야기하는 것보다 훨씬 어렵고 복잡하다는 것을 안다. 하지만 우리가 정말로 상황을 개선하고 싶다면, 나는 두려워도 그 길—논의를 확장하는 길—을 택해야 한다고 생각한다. 여기에는 IT 밖의 사람들과 사려 깊은 대화를 시작하는 것도 포함된다.
이 글이 생각해 볼 거리들을 제공했길 바란다. 우리의 상황을 개선하는 데 도움이 될 만한(혹은 최소한, 우리 운명을 좌우하는 결정을 내리면서도 그 결정의 결과를 이해하지 못하는 IT 밖의 사람들에게 상황을 더 잘 설명하는 데 도움이 될 만한) 아이디어가 더 있다면, 커뮤니티와 공유해 주길 바란다. 상황은 더 나아질 수밖에 없다…
카테고리: General, Architecture
태그: technical debt, cognitive load
바라건대 대부분의 버그는 QA 단계에서(개발과 함께 수행되든 별도 단계로 수행되든) 발견되겠지만, 일부 버그는 감지되지 않은 채 운영으로 흘러 들어간다. 그리고 인지 부하가 너무 커서 개발 시점에 더 많은 버그가 유입될수록, 더 많은 버그가 결국 운영에 도달하게 된다. ↩
AI가 소프트웨어 개발을 대신해 이 모든 문제를 해결해 줄 것이라는 약속과 관련된 부록: 다른 것은 바꾸지 않은 채 AI만 추가한다고 문제가 해결되지는 않는다. 기존 문제를 해결하지 않은 채 AI 보조/AI 주도 코딩만 더하면, 그 문제를 해결하기는커녕 오히려 문제를 강화하게 되며, 이는 우리가 AI로 달성하고자 하는 것과 정반대다. ↩
