Show Cover Slide

“그건 기술부채가 아닙니다. 그냥 몰랐던 겁니다”

우리는 무지와 기술부채를 혼용하고 있다

1. 서문: 기술부채라는 말이 너무 쉽게 사용되고 있습니다

오늘날 소프트웨어 개발 현장에서 ‘기술부채’라는 용어는 매우 자주 사용됩니다.
다음과 같은 상황에서 이 표현은 반복적으로 등장합니다.

• 기능 구현이 예상보다 복잡해졌을 때
• 코드 구조가 엉켜버렸을 때
• 예기치 못한 오류가 반복될 때
• 빠르게 무엇인가를 만들어야 할 때

이럴 때 우리는 쉽게 말합니다.

“기술부채입니다.”

이 표현은 책임을 일시적으로 유예할 수 있는 언어처럼 작동하며, 언젠가 리팩터링을 통해 개선될 것이라는 막연한 기대를 남깁니다.

그러나 실제로 그 말이 사용되는 맥락을 들여다보면,
과연 그것이 진정한 의미의 ‘부채’였는지 의문이 생깁니다.
대부분의 경우, 이는 설계의 부재나 기술적 판단 부족으로 인해 발생한 문제이지만, 그럼에도 우리는 이를 ‘부채’라는 말로 포장합니다.
마치 그것이 전략적 판단이었던 것처럼.

이 글은 그 포장의 실체를 비판적으로 들여다보고자 합니다.
기술부채라는 이름 아래 묻히는 무지와 실수를 되짚고, 설계를 회피하는 문화가 기술 조직에 어떤 영향을 미치는지를 함께 살펴보겠습니다.

2. 무지를 기술부채로 포장하는 문화

많은 개발 팀이 구조적 문제를 마주할 때, 이를 ‘기술부채’라는 말로 설명합니다.
그러나 그 속을 들여다보면, 기술적 트레이드오프가 있었던 것도, 판단의 흔적이 남아 있는 것도 아닙니다.

단순히 몰랐기 때문입니다.
그리고 충분히 고민하지 않았기 때문입니다.

• 설계가 왜 필요한지 이해하지 못했고
• 구조가 왜 이렇게 되었는지 설명할 수 없으며
• 기술 선택의 근거도 문서화되어 있지 않습니다
• 아무도 그 결정을 다시 보려 하지 않습니다

그런데도 이렇게 말합니다.

“그건 기술부채예요.”
“그땐 어쩔 수 없었어요.”
“그때는 몰랐죠.”
“일단 이렇게 구현했어요. 나중에 리팩터링하면 되죠.”

이것은 기술부채가 아닙니다.
단지 설계하지 않은 것일 뿐이며, 몰랐던 것, 그리고 책임지지 않으려는 것일 뿐입니다.

“If you don’t know why your system is built the way it is, chances are you’ll break it when you change it.”
— Martin Fowler, Refactoring

시스템이 왜 그런 방식으로 만들어졌는지 모른다면, 그것을 변경할 때 망가뜨릴 가능성이 높습니다.

우리의 많은 시스템은 이미 그러한 경로를 밟고 있습니다.
이제는 그 책임을 회피하기보다, 기술적 판단이 없었던 사실을 인정하는 용기가 필요합니다.

3. 기술부채는 선택이 아니라 선언이다

기술부채라는 말에는 전략적 선택이라는 뉘앙스가 포함되어 있습니다.
즉, 더 나은 구현이 가능하다는 것을 인식하고도, 일정이나 우선순위, 시장 대응 등 여러 요인을 고려하여 일시적으로 간단한 방식을 택했다는 의미입니다.

이것이 바로 기술부채가 정의된 선언이어야 하는 이유입니다.
기술부채는 판단의 결과여야 하며, 기록된 근거와 함께 언제, 왜, 무엇을 포기했는지가 명확해야 합니다.

그러나 현실은 다릅니다.

• 그 결정은 누구에 의해 내려졌는지 알 수 없고
• 그 당시 어떤 선택지가 있었는지조차 남아 있지 않으며
• 구조가 반복적으로 꼬여가는 와중에도, 단지 “기술부채”라는 이름으로 넘어갑니다

“우린 MVP니까 기술부채 괜찮아.”
“빠르게 만들었지만, 나중에 고치면 되죠.”
“지금은 기능이 먼저니까요.”

이런 말들은 기술부채가 아닙니다.
의사결정이 아니었고, 판단이 없었으며, 선언도 없었기 때문입니다.
그저 기록되지 않은 무지와 책임지지 않은 구조의 파편일 뿐입니다.

“The whole point of the metaphor is that it’s okay to do things quickly, as long as you pay it off.”
— Martin Fowler, Technical Debt Quadrant

기술부채라는 은유의 핵심은, 빠르게 처리하는 것이 괜찮다는 것이 아니라
빚을 갚는다는 전제가 있을 때에만 괜찮다는 데 있습니다.

기술부채를 선언하지 않았다면, 그것은 부채가 아닙니다.
그저 책임지지 않은 설계일 뿐입니다.

4. 기술부채는 관리의 대상이 아니다

많은 팀이 기술부채를 ‘관리해야 할 일’로 간주합니다.
버그 트래커나 백로그에 ‘기술부채’라는 이름의 티켓을 남겨두고, 언젠가 여유가 생기면 고치겠다는 약속을 합니다.

그러나 대부분의 경우, 그 티켓은 갱신되지 않습니다.
상환 계획은 없습니다.
책임자는 존재하지 않으며, 그 구조를 다시 검토하려는 사람도 없습니다.

“그건 기술부채니까 언젠가 고치자.”
“관리 티켓에 넣어뒀어요.”
“지금 당장은 중요한 기능이 먼저예요.”

이런 방식은 관리가 아닙니다.
방치에 가깝습니다.
기술부채는 관리라는 이름으로 미뤄둘 대상이 아니라, 정의하고, 상환하거나 폐기해야 할 대상입니다.

“Managing technical debt isn’t about tracking tasks; it’s about avoiding becoming insolvent.”
— Martin Fowler, Technical Debt Quadrant

기술부채를 관리한다는 것은 단순히 작업을 목록화하는 것이 아니라,
기술적으로 파산하지 않도록 하는 일입니다.

기술부채는 ‘관리’라는 단어로는 결코 해결되지 않습니다.
그것은 명확히 정의되어야 하며, 실행 가능한 상환 또는 폐기 전략과 함께 다뤄져야만 합니다.

5. 기술부채의 본질은 설계의 부재입니다

지금까지 살펴본 기술부채의 다수는 실제로 ‘전략적 판단’이라기보다, 설계되지 않은 구조, 혹은 설계를 할 수 없는 문화에서 비롯된 것입니다.

애초에 기술부채는 더 나은 구조를 알면서도, 일시적으로 단순한 길을 선택한 결과여야만 성립합니다.
그러나 우리는 종종 더 나은 구조를 아예 상상하지 못하거나, 그럴 시간도, 역량도, 문화적 여유도 갖고 있지 못한 상태에서 구현을 시작합니다.

그 결과 생겨나는 구조적 문제들은 기술부채가 아니라 설계 부재의 결과물입니다.

• 문서로 남지 않았고
• 설명할 수 없으며
• 이해되지 않는 구조라면

그것은 부채가 아니라 책임 없는 코드의 잔재일 뿐입니다.

기술부채를 진지하게 다루기 위해 우리는 설계라는 행위 자체를 다시 복원해야 합니다.

6. 설계는 정의하고 폐기하는 것이다

설계란 무엇일까요?
많은 사람들은 설계를 문서나 다이어그램, 혹은 정해진 구조로 생각합니다.
하지만 진짜 설계는 고정된 형식이 아닙니다.
설계란 시스템의 흐름과 책임, 연결을 정의하는 행위이며, 그 정의가 더 이상 유효하지 않을 때 기꺼이 폐기할 수 있는 판단이기도 합니다.

좋은 설계는 완벽한 형태로 존재하는 것이 아닙니다.
오히려 다음의 조건을 만족할 수 있어야 합니다.

• 왜 이 구조를 택했는지를 설명할 수 있고
• 그 설계가 유효했던 맥락이 명시되어 있으며
• 필요할 때, 구조를 파괴하고 새로 구성할 수 있는 용기가 있다면
  그것은 살아 있는 설계입니다.

“Architecture is the decisions you wish you could get right early, but you have to live with.”
— Martin Fowler, Who Needs an Architect?

아키텍처란 처음부터 제대로 했으면 좋았겠지만, 결국 오랫동안 떠안게 되는 결정들입니다.

이 말은 설계가 얼마나 위험하고 무거운 선택인지를 보여줍니다.
우리가 설계를 하지 않는 이유는, 그 결정에 책임지고 싶지 않기 때문입니다.
하지만 설계를 회피한 대가는 언젠가 반드시 되돌아옵니다.

설계를 정의하지 않으면 시스템은 방향을 잃고, 설계를 폐기하지 못하면 시스템은 정체하게 됩니다.

설계란 그 자체로 선언이며, 유효 기간이 있는 생물입니다.
정의하고, 공유되고, 폐기될 수 있을 때 비로소 설계는 팀의 자산이 됩니다.

7. 맺으며: 설계를 회복해야 기술이 살아납니다

기술부채는 단순히 “고쳐야 할 것”이 아닙니다.
그것은 설계하지 않은 대가, 그리고 책임지지 않은 구조의 흔적입니다.

우리가 기술부채라고 부르는 많은 것들은 기술부채가 아니었습니다.
실제로는 판단이 없었던 구현이며, 설계할 수 없었던 문화의 산물입니다.
그럼에도 우리는 이렇게 말하곤 합니다.

“우린 스타트업이니까 원래 부채 있어요.”
“그때는 몰랐던 거니까 어쩔 수 없었죠.”
“기능이 먼저라 설계는 나중에 해요.”
“일단 만들어보고, 나중에 리팩터링하면 되죠.”
“그건 기술부채니까 언젠가 정리하죠.”

이러한 표현 속에는 회피, 무지, 책임 없음이 숨어 있습니다.
그리고 그러한 문화가 계속되는 한, 우리는 같은 문제를 반복하고, 더 많은 기술적 고통을 만들어낼 것입니다.

설계는 기술의 시작이자 끝입니다.
설계를 하지 않는 문화는 기술을 소모품으로 만들고, 개발자를 일회용으로 소모합니다.

이제는 선언해야 합니다.

• 설계는 정의되어야 합니다.
• 설계는 공유되어야 합니다.
• 설계는 폐기될 수 있어야 합니다.

기술 조직의 회복은 설계의 회복에서 시작됩니다.
기술부채를 넘어서기 위해 우리는 다시 설계의 언어, 구조의 책임, 연결의 사고로 돌아가야 합니다.