기술과 부채의 만남

기술 부채란?

위키백과에서 설명하는 기술 부채

위키백과 기술 부채 링크

기술 부채(technical debt, design debt, code debt)는 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점이다.

기술 부채는 금전적인 채무와 비유될 수 있다.

• 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용

일반적으로 알려진 기술 부채

"기술 부채"라는 용어는 워드 커닝햄(Ward Cunningham)이 처음으로 사용했다. 기술 부채는 금융 부채와 비슷한 개념으로 우리의 결정이 계속해서 미래에 선택할 수 있는 옵션을 줄이고, 어떻게 시간이 지날수록 점점 더 해결하기 어려운 문제가 되는지를 설명한다. 아무리 신중하게 고려한다 하더라도 우리는 여전히 이자를 물게 된다.

- 데브옵스 핸드북

• 미래에 선택할 수 있는 옵션을 줄이고
• 시간이 지날수록 점점 더 해결하기 어려운 문제

기술 부채는 어떻게 생길까?

빨리 일을 처리하려고 하다보니 기술의 완성도는 뒷전이 되어서 생긴다고 알려져있다.
분명 급하게 처리하려고 시간을 최대한 줄이게 되면 그에 따른 부작용으로 기술 부채가 쌓이기도 한다.

이 아래로는 규모가 있는 회사나 팀은 해당사항이 없을 것이고, 내가 보고 듣거나 겪어온 규모가 작은 회사나 팀에 해당이 된다.

개발자 개개인이 가진 기술 부채를 일을 하면서 그대로 쏟아 붓는 경우도 있다.

개발자 개개인의 기술 부채?

시니어 개발자나 팀원들이 확인하여 그런 부분을 극복해야 하지 않냐고 생각할 수 있지만,
개발자를 구하기 힘든 회사에서는 경험과 지식이 부족한 주니어 개발자 한명(혹은 2~3명)에게 모든 것을 맡기는 경우도 흔하다.

가끔은 주니어 개발자 임에도 지식과 실력이 뛰어난 사람도 있지만, 대다수는 그렇지 않다.

빚 독촉

금융 부채는 연락을 하거나 직접 찾아 오는 것으로 독촉을 하지만,
기술 부채는 운영중인 서비스를 불안정하게 만들거나 장애를 발생시키는 것으로 독촉을 한다.

파산

기술 부채를 상환할 능력이 되지 않는다면 '기술 파산' 이 아니라 그냥 파산한다.
서비스는 지속적으로 불안정한 상태와 장애가 발생하고, 그런 상태를 개선하지 못하여 포기해야 하는 상황이 온다.
(혹은 현재 상태를 포기하고 처음부터 다시 만들거나.)

상환

금융 부채는 보통은 일시불로 상환하기 힘들기 때문에 몇 달 혹은 몇 년에 걸쳐 상환한다.
기술 부채도 마찬가지다.

회사의 금융 부채도 마찬가지지만, 기술 부채도 대출하는 사람과 상환하는 사람이 다른 경우가 존재한다.

이해되지 못하는 상황 (절망편)

슬프게도 개발자가 아닌 대표나 매니저나 동료들은 이런 부분을 이해하지 못할 가능성이 높다.

"여태까지 잘 됐는데 오늘 갑자기 왜이러냐?"
"당신이 오고나서 장애가 발생하기 시작했다. 대체 뭐하는거냐?"

"그래서 오늘 안에 다시 정상화 되냐?"
"뭘 잘했다고 퇴근을 하나? 해결 될 때 까지 퇴근 할 생각 말아라."

해결 (절망편)

별로 상환 할 생각도 없고 어떻게 해야할지도 모르면
근본적인 문제를 해결하는 대신 당장만 어떻게 되도록 대충 틀어막는다.

금융 부채에 빗대어 표현하자면 카드 돌려막기를 하는 상황이다.

상환 계획

이런 억울한 상황에도 당신이(혹은 전임자들이) 대출한 기술 부채를 상환하겠다고 마음먹었다면, 계획을 세워야 한다.

문제의 원인은 어떻게 파악 할 것인지
어떻게 작게 나눠서 점진적으로 해결할 것인지
어떤 방법을 사용 할 것인지, 어떻게 할 것인지
얼마나 시간을 들여서 상환 할 것인지 말이다.

보통 이 정도까지 왔다면 간단하게 해결할 수 없는 상태일 것이다.
하루 이틀이나 일주일 안에 해결하려는 생각은 금물이다.
이 상태가 되기까지 걸린 시간 만큼은 들여야 한다고 생각해야 할 것이다.

당신은 분명 기술 부채를 해결하는 일 외에 다른 일도 해야 할 것이다.
어쩌면 기술 부채를 해결하는데는 업무시간의 10% 정도 밖에 쓰지 못할수도 있다.

예방

안타까운 이야기지만 실력이 오르고 경험이 생겨야 한다.
어느 선 까지 성장하지 않고는 그걸 잡아 줄 누군가가 없다면 예방이 불가능하다.

보이스카웃 규칙

보이 스카웃 규칙 : 언제나 처음 왔을 때보다 깨끗하게 해놓고 캠프장을 떠날 것.

그 정도는 지났다고 생각한다면, 작업을 하는 부분에는 항상 보이스카웃 규칙을 적용해야 한다.

변수명을 올바르게 지었는지 다시 한번 확인하고
단일 책임 원칙을 어기는 함수가 있다면 분리해야 하며
강하게 커플링 된 부분이 있다면 느슨하게 만들어야 하고
여러 if문에 의해 지옥의 계단이 만들어졌다면 제거해야 하고
반복되는 부분이 있다면 모듈로 만들어서 제거해야 하며
항상 테스트 코드를 작성하여 코드의 안정성과 유지보수가 가능 한 상태로 만들어야 한다.

교육

여기서 말하려는 교육은 당신이 만약 시니어 개발자라면 주니어 개발자에게 올바른 방향을 알려줘야 한다는 의미다.
시니어 개발자는 그저 일만 잘해서 되는 것이 아니다.
다른 주니어 개발자들이 할 수 있는 삽질을 막고, 올바르게 일을 할 수 있도록 가르칠 능력이 되기 때문에 시니어 개발자인 것이다.

코드 리뷰를 하며 잘못된 부분을 알려주거나, 스터디를 열어서 지식을 높여주거나 하는 등의 노력을 해야한다.
(물론 각각의 주니어 개발자도 배우기 위해 노력을 해야한다.)