기술부채란 무엇인가? (feat. 내가 쌓은 기술부채)

어쩌다보니 쌓인 기술부채

새해를 맞아 2024년 한 해 동안 내가 개발했던 것을 돌아보았다.

대학교 신입생이다보니 대학 수업과 개발 둘다 열심히 하다보니 생각보다 기술부채가  쌓였더라.

이번 글은 작년에 쌓은 기술 부채를 점검하고, 이를 어떻게 해결하면 좋을까 싶어서 쓰게 되었다.

 

기술부채란?

먼저 기술부채가 무엇일까?

더 나은 방법 대신 더 쉬운 방법을 선택함으로써 발생하는 다시 개발해야 하는 수고(=비용)

 

마틴 파울러의 기술부채 4분면

마틴 파울러는 기술부채의 유형을 사분면을 통해 나타냈다.

• Prudent & Deliberate ( 신중한 & 의도적인 )
• Reckless & Deliberate ( 신중하지 않은 & 의도적인 )
• Reckless & Inadvertent ( 신중하지 않은 & 비의도적인 )
• Prudent & Inadvertent ( 신중한 & 비의도적인 )

Prudent & Deliberate ( 신중한 & 의도적인 )

A와 B라는 방법이 있다고 가정해보자.
A 방법은 개발 속도가 얼마 걸리지 않지만, 나중에 코드를 재작성해야 할 수 있다.
B 방법은 개발 속도는 오래 걸리지만, 나중에 코드를 다시 쓸 가능성이 낮은(= 코드의 퀄리티가 좋은) 해결책이다.

A 방법을 선택하면 기술부채가 생긴다는 것을 모두가 알고 있다.

하지만, 기술부채보다 개발속도나 빠른 출시가 더 중요해서 충분한 고민 끝에 B 방법 대신 A를 고른 것이다.

 

이를 신중하고 의도적인 기술 부채라 하며, 일반적으로 많이 발생하는 기술부채이다.

 

Reckless & Deliberate ( 신중하지 않은 & 의도적인 )

모두가 더 나은 방법이 있는 것을 안다. 심지어, 그 방법을 적용하는데 큰 무리가 없는 상황이다.

그럼에도 불구하고, 시간이 없어 빠르고 지저분하게 진행하기로 한 결과이다.

 

이러한 기술부채는 출시 일정에 압박을 받거나, 급하게 수정을 해야할 때 발생한다.

 

Reckless & Inadvertent ( 신중하지 않은 & 비의도적인 )

진짜 잘 몰라서 발생한 기술 부채이다.

한마디로 '그게 뭔데? 나 처음들어봐.' 인 것이다.

Prudent & Inadvertent ( 신중한 & 비의도적인 )

그 당시에는 좋은 코드였고 최선의 방법을 선택했지만,

나중에 더 좋은 방법이 있다는 것을 깨달은 것을 말한다.

 

한줄로 요약하면, '그때 이 방법을 알았다면, 이렇게 코드를 작성하진 않았을 것' 이다.

성장 과정에서 자연스럽게 나타나는 기술 부채다.

 

내가 1년동안 만들어낸 기술부채

1년 동안 창업팀에서 활동하면서 기술 부채를 엄청 많이 만들어냈다.

아래는 2024년을 돌아보며 찾은 기술 부채들이다.

 

API 문서화 도구가.. 없어?

맞다. 놀랍게도 우리 창업팀은 API 문서화 도구를 쓰지 않았다.

지금까지 API가 새로 추가되거나 변경사항이 생기면 개발자가 직접 노션에 API 문서를 작성했다.

그러다보니 API의 실제 Response와 문서 상의 Response가 다른 경우도 있었다.

 

물론, 처음 개발을 시작할 때에 API 문서화 도구를 알고 있었다.

심지어 사용해본 경험도 있었다.

처음 개발을 했을 때는 MVP(Minimal Viable Product)만 만들기로 했었고,

API 개수도 5개 정도로 매우 적었다.

 

당시에는 5개의 API를 문서화하는데 문서화 도구를 사용하는 것은

비효율적으로 느껴졌고 시간도 부족했기에에 노션을 사용했다.

그런데, 대학 수업을 함께 병행하다보니 시간이 부족해졌고,

기존에 만들어둔 API에 이것저것 덧붙여 개발을 진행했다.

당연히 개발할 시간도 부족했고, API 문서화 역시 기존 노션을 계속해서 사용했다.

 

지금은 API 수십개로 늘어났고, 이들을 한번에 관리하는데 어려움을 겪고 있다.

위에서 언급한 신중하지 못한 & 의도적인 기술부채가 아닐까 싶다.

 

종강했으니 조만간 날 잡고 API 문서화 도구를 도입하려고 한다.

 

데이터베이스의 필드의 의미가 달라졌다.

개발 초기 MVP를 만들때 작성했던 데이터베이스의 스키마가 있다.

 

중간중간 개발 방향이 많이 바뀌고 기존 설계에 계속해서 덧붙여가면서 개발을 진행했다.

데이터베이스의 필드명은 유지하되 필드의 의미를 바꾸기도 했고,

초기 스키마 중에 안쓰는 필드와 의미없는 필드가 생기기도 했다.

 

여기까지는 큰 문제가 없어 보이기도 한다.

그런데 문제는 협업 과정에서 있었다.

 

안쓰는, 의미 없는줄만 알았던 필드가 프론트엔드에서 특정 값을 추출하기 위해 사용하고 있었다.

놀랍게도 이 문제로 인해 실제 서비스에서 문제가 발생할때까지 모르고 있었다..

 

이건 위에서 언급한 4개의 기술부채 중에 어디에 해당될까?

내 생각엔 신중하지 못하고 의도적인 기술부채인 것 같다.

 

기술 부채를 줄이는 방법

그럼 이런 기술 부채를 어떻게 줄이고 예방할까?

코드 리뷰

여러 개발자들과 코드 리뷰를 하면 내가 몰라서 생기는 기술 부채 같은건 어느정도 막을 수 있다.

근데 창업팀에는 나 혼자다.. 아무도 내 코드를 봐 줄 사람이 없다..

 

테스트 자동화

메인 브랜치로 Pull Request를 하는 과정에서 CI를 통해 테스트를 자동화하면, 

코드에서 발생하는 문제를 어느정도 미리 파악하고 막을 수 있다.

테스트 코드를 작성해야 한다.

 

지속적인 통합 / 배포 

CI/CD로도 불리는 지속적인 통합과 배포이다.

창업팀은 몇 달 전까지 각 파트에서 배포를 수동으로 진행했지만

Github Action과 CircleCI, Docker를 도입해 지속적인 배포가 가능하게 만들었다.

 

지금보니 이것도 기술부채를 해결한 사례네.

 

최신 기술 도입

새로운 기술이 나올때마다 최신 기술을 도입해 기술 부채를 최소화할 수 있다고 한다.

신기술은 개발 시간을 줄이고 더욱 효율적으로 개발할 수 있기 때문이다.

 

 

마무리

기술 부채는 피할 수 없다.

성장 과정에서, 개발 과정에서 자연스레 쌓일 수 밖에 없다.

 

중요한 것은 기술 부채를 최소화하는 것이다.

개발하는 과정에서 어떻게 하면 기술 부채를 줄여나갈 수 있는지 고민해보는 계기가 된 것 같다.

 

References

• 한컴 기술블로그 - 기술 부채란?
• 인포그랩 - 기술 부채 어떻게 상환할까?