얼마전 기술부채에 대해서 그럴듯하게 쓴 기사를 하나 봤다. 특정 사이트의 외적인 사용성면에서의 기초가 되어 있지 않다며 짧은 시간의 기술부채가 큰 문제가 있다고 이야기했다.
기술부채란 단어가 많이 유명해진 것 같아서 다행이긴 한데, 적절한 사용은 아니라고 생각했다. 위의 위키백과에 나와있는 것처럼 기술 부채는 당시에 필요한만큼의 쉽지만 향후에 확장성의 제약이 많은 기술을 선택한 경우에 해당한다. 왜냐하면 나중에 재개발되는 경우가 엄청나게 많으니까, 그러니까 누구나 언젠가는 다시 고쳐서 개발한다는 걸 알고 있는 부채같은 것이란 뜻이다.
그런데, 사용자의 입장에서 내부의 상황은 전혀 알 수 없다. 구조적으로 확장성과 기능을 너무 많이 고려해서 케이스가 많을 때도 사용성과 성능은 떨어질 수 있다. 이건 개념적인 기술부채와는 좀 다른 문제다,
시간이 부족했다는 것은 상대적이다. 시간이 부족했으면 만들 양을 줄였어야했다. 맞다. MVP가 필요하다. 과도한 욕심을 부려서 완성도가 떨어진 건 기술부채가 아니다. 그건 그냥 완성도가 나쁜거다, 이 경우는 부채가 생겼다기 보다는 본인이 돈을 꿔주고 못받아오고 있는 꼴이다. 시간이 지나면 가치가 떨어져버리는 채권을 잔뜩 쥐고 있는 모습이다. 완성도를 높일 만큼의 양을 선택하고 계획된 기술부채를 남겼어야 했는데 그걸 할 여유도 욕심을 포기할 기준이 없었을 테니까.
기술부채는 경우에 따라서 '몰라서' 생기는 경우도 있다. 나아가야할 로드맵이 없는 상태에서 눈에 보이는대로만 개발할 때 확장성이 없을 때가 있다. 사용성의 완성도가 높다면 아무리 내부에는 기술부채가 쌓여있어도 밖에서는 모를 수 있다. 기술부채는 누구의 잘못도 아니다.
하지만 지나친 욕심으로 디테일 완성도가 떨어지는 건 스스로 선택한 잘못이다. 기획자로서 원하는 기능을 모두 갖추는게 최선이 아니라는 걸 깨달아야할 것 같다. 확장가능한 로드맵을 두고 상환가능한 기술부채를 만드는 게 사실 가장 이상적이라고 생각한다.
