[기술부채] "왜 우리의 프로덕트는 완성되지 못 하는가?" - 2

소프트웨어 구축 프로젝트를 진행하다보면 여러 난관에 봉착하여 원하는 시점에 프로젝트를 종료하지 못 하는 일이 빈번하게 발생합니다. 두번째 마무리 일정도 지연되고, 다시 잡은 일정도, 그 이후의 일정도 지연을 반복하면서 결국 무한 개발중으로 수렴하곤 합니다. 이러한 일이 발생하는 이유들은 여러가지가 있겠지만, 오늘은 기술부채에 대해서 이야기 해보려 합니다.

---

1. 기술부채란 무엇일까요?

기술부채란, 특정 시점에 더 기술적으로 좋은 방법이 있음에도 불구하고, 당장 편리한 방식을 채택하여 미래에 추가적인 재작업의 비용을 예약해둔 상태를 말합니다. 예를 들면, 회원 시스템 개발 중에서, 로그인 인증 로직을 모듈화해두는 것이 편하지만, 당장의 일정을 앞당기기 위해 모듈을 별도로 개발하지 않고, 로그인 인증 로직을 복사+붙여넣기로 모든 부분에 보일러플레이트 코드로 삽입해놓는 것이 있겠습니다. 당연히 지금 1~2개의 복사+붙여넣기로 개발해놓은 로직은 간단하지만, 추후에 10개, 시스템이 커지면 100개 이상의 반복되는 코드를 삽입해야하는 일이 발생합니다. 결국 모듈화를 해서 해결해야 하는 상황인거죠.

2. 기술부채가 쌓이면 어떤 일이 발생하나요?

큰 제목에서 언급한 것 처럼, 기술부채가 누적되면 결국 프로덕트의 완성은 지연됩니다. 무한히 비효율적인 코드를 생성해서 결국 완성할 수 있을 것이라 생각하지만 그리 간단하지 않을겁니다. 그 이유는 세가지가 있습니다.

• 생산성: 당연히 반복되는 코드를 계속 생성해야 한다면, 생산성이 떨어집니다. 코드의 양도 많겠지만, 코드를 알아보기가 너무 어렵습니다. 이번 주 작업해둔 코드를 다음주에 볼 때 생각이 안 나면 처음부터 다시 해석해야 하는 일이 발생하죠.

• 인수인계: 이 코드를 평생 나만 볼 것 같죠? 절대 그렇지 않습니다. 프로젝트는 몇달에서 길게는 연단위까지 바라보고 수행하는 과업들의 집합입니다. 기술부채가 쌓인 코드는 다음 작업자, 그리고 현재의 공동 작업자들에게 큰 어려움을 제공합니다.

• 유지보수성: 유지보수는 프로젝트 종료후에만 발생하는게 아닙니다. 프로젝트 진행 중, 특히 QA 과정에서 오류가 났거나 개선해야하는 부분들이 반드시 발생합니다. 하지만 기술부채가 쌓인 코드는 하나를 수정하면 줄줄이 소세지처럼 다른 부분에서 버그가 연쇄적으로 터집니다. 필연적으로요. 그 버그를 고치면 또 다른데서 버그가 터지죠. 결국 프로덕트 완성은 지평선 너머로 멀어지게 됩니다.

3. 어떤 기술부채들이 있을까요?

위에서는 모듈화 하나만을 예로 들었는데요. 사실, 기술부채는 코드 뿐만 아니라 소프트웨어 개발 과정 전체에서 다양하게 발생합니다.

• 모듈화: 모듈화는 코드 뿐만 아니라 MSA 구조를 만들 때에도 필수적입니다. 모듈화가 되지 않으면 반복적이고 비효율적인 task들이 시스템의 무결성을 감소시킵니다. 낮은 무결성의 시스템은 병목이 잦고 유지보수가 어렵습니다.

• 보안: 지금 당장 기초적인 보안을 무시하고 개발하면 출시 전에 모든 소스코드를 손봐야 하는 일이 생깁니다. 예를 들면, 기본적인 SQL Injection 정도는 막아주어야 하지 않을까요? 처음 개발 시점부터 고려하고 개발하지 않았다면 모든 SQL 연관 코드를 다 고쳐야 합니다!

• DB 튜닝: DB 튜닝은 단순히 인프라만의 문제가 아닙니다. 코드에 트랜잭션이 없거나, 과도하게 호출되는 쿼리(for문에 들어있다거나..)는 DB에 과부하를 줍니다.

• 프레임워크 선정: 프레임워크의 선정은 생산성 측면의 고려뿐만 아니라, 프로덕트 자체에 최적화된 것으로 진행되어야 합니다. 영상처리나 AI의 기술이 많이 사용되는데 Spring이 사용되면 당연히 생산성이 저하되고 구현에 어려움이 생깁니다. 또는 대용량 접속이 필요한 서버를 구축해야 하는데, 파이썬의 Fast API를 사용하면 보일러플레이트가 많아지고 성능이 저하됩니다.

• 데이터 구조: 데이터 구조는 DB 설계 과정에서, 전체 시스템의 무결성 측면에서 고려되어야 합니다. 데이터는 다른 종류의 데이터들과 연관관계가 복잡하게 얽히기 때문에 잘못 설계된 데이터 구조는 필연적으로 불필요한 작업들을 수행할 수 밖에 없게 합니다.

• 아키텍처: 아키텍처가 잘못 설계된 시스템은 출시 자체가 불가능할 수 있습니다. MSA 에서 하나의 서비스는 하나의 기능만 해야합니다.

• 파일 저장소: 파일 저장소는 MSA 구조에서 정교하게 설계되어야 합니다. 개발 편의를 위해 단순한 로컬 저장 방식으로 구현한 경우에는 모든 파일 관련 코드를 수정해야 하는 대규모 작업을 야기할 수 있습니다.

4. 이러한 기술 부채들은 왜 생기나요?

처음부터 이러한 일이 일어나지 않도록 설계를 하면 되지 않을까요? 그리 복잡할 것 같지 않은데 왜 기술부채를 만들고 가나요? 라고 생각할 수 있습니다. 하지만 구축 프로젝트에서 기술부채가 없는 경우는 단언코 없습니다.

• 대표가 기술을 모르는 경우: 대표가 기술을 모르는 경우에는 프로젝트가 어떻게 진행되는지 알 수 없기 때문에 작업자들의 편의 위주로 개발이 진행될 수 밖에 없습니다. 따라서 기술부채가 계속 쌓이게 됩니다.

• CTO가 없는 경우: 대표가 기술을 모르면 CTO가 있으면 됩니다. 하지만 제대로 된 CTO 구하기는 하늘의 별따기죠. CTO가 없다면 아키텍처 수준에서의 기술부채는 불가피합니다. 전체 그림을 누군가는 봐야하거든요.

• 리드 개발자가 없는 경우: CTO라고해서 모든 코드를 일일히 볼 수는 없습니다. 이건 리드 개발자의 업무입니다. 실력있는 리드 개발자는 코드 단위에서, 프레임워크 단위에서 기술부채가 최소화되도록 할 수 있습니다.

• 개발자가 적은 경우: 개발자가 적으면 현재 상황과 타협할 수 밖에 없습니다.

• 경영진이 자꾸 기획을 바꾸는 경우: 개발자가 열심히 구상해서 데이터 구조를 잡아두었는데 경영진이 자꾸 바꾸면 계속 이상한 구조가 덧붙게 됩니다. 마치 워크래프트의 못생긴 살덩이골렘처럼요.

5. 어떻게 해야하나요?

어떤 경우에도 기술부채는 발생할 수 밖에 없다고 보시면 됩니다. 그저 최소화 할 뿐입니다. 기술부채를 최소화 하는 첫번째 방법은 CTO를 잘 채용하는 것입니다. 그리고 훌륭한 CTO는 훌륭한 팀을 만들 것입니다.

CTO 구하기가 어렵다면 좋은 파트너사를 만나는 것도 방법입니다. 실력있는 개발자는 자기 사업체가 있는 경우가 많습니다.

우리의 기술부채는 흔하고 흔한 우리 소프트웨어만의 고질병이라고 보시면 됩니다. 심지어 글로벌기업 구글에서 만든 소프트웨어도, 페이스북에서 만든 소프트웨어도 기술부채가 있습니다. 기술부채를 모두 해결하고 프로덕트를 출시할 필요는 없습니다. 프로덕트는 부채를 갖고 갑니다. 사용자들 모르게 언젠간 수정하면 되니까요. 치명적이지만 않다면요.