[세미나] 구름 3월 COMMIT <기술 부채를 바라보는 다른 시각> 행사 리뷰

 

 

지난 11월 구름스퀘어에서 개발자로서의 '성장'을 주제로 진행된 두번째 COMMIT 행사에 참여하고 4개월 만에 다시 COMMIT 세미나에 오프라인 참여를 하게 되었다.

이번에는 취준생으로서 나에게는 조금은 생소한 단어, "기술 부채(Techincal Debt)" 라는 주제로 세미나가 진행되었다.

 

출처: 구름 공식 블로그 (https://blog.goorm.io/commit_6th/)

 

 

speaker은 양수열 소장님으로, 한국인 최초 Java Chapion, Oracle ACE Pro, 전자정부 프레임워크 리더를 맡고 계시면서 다수의 스타트업 CTO로 역임되며 수많은 멘토링을 하셨고, Software Maestro 멘토로 활동 중이시다.

 

 

기술부채, 과연 무엇일까?

 

기술 부채란, 1992년 와드 커닝험이 만든 용어로 기술적인 '빚'을 말한다.
기술의 완성도보다 비즈니스의 속도를 중요시 여기며 기술적인 문제를 다음 순위로 떠넘기다 보니, 기술적인 허점들, 문제점들이 마치 갚아야 할 부채, 빚처럼 쌓여 압박이 될 수 있다는 뜻이라고 한다. 스타트업 초기 단계에서(꼭 스타트업이 아니더라도 프로젝트 초기 단계) 급하게 개발한 것들이 쌓여 나중에 해결해야 하는 업무로 남게 된다. 

 

사실 나는 아직 회사에서 인턴으로 짧게 일한 경험, 작은 협업 개발 프로젝트를 진행한 경험이 끝이기에 기업 내에서의 기술 "부채" 를 경험해 본 적은 없다. 

다만 해커톤과 같이 짧은 시간 내에 협업 프로젝트를 완성해내야 하는 때, 설계도 채 완성하지 않은 상태로 의존 관계들이 서로 얽히고설킨 스파게티 코드들을 급히 짜내며 기능들을 개발해 본 경험이 있다. 때문에 기술 부채라는 단어를 듣는 순간, 내가 그 때 짰던 그 코드들이 실제 기업에서 제품을 양산해내기 위한 코드라고 생각하면.. 심각한 기술 부채가 되겠다라는 직감이 왔던 것 같다.

 

 

 

기술 부채를 없앨 수 있나요?

기술 부채를 없애는 건 사실상 불가능하다고 한다.

 

MVP(minimum viable product) 제품을 개발하고 출시(release)하 과정에서 다음과 같은 이상적인 프로세스, build-measure-learn 프로세스가 있다고 한다.

좀 더 알아보니 BML(Build-Measure-Learn)은 제품을 개발하고(build), 소비를 측정하고(measure), 고객의 니즈에 더 잘 응답하고 기업의 궁극적으로 지속 가능한 제품을 향상시키기 위해 배우는(learn) 일련의 과정이다. 

 

 

위의 과정은 사실 매우 이상적이라고 한다. 심지어 외국계 회사에서도 이를 일일히 다 지키기 어렵다고 한다.

이런 과정 속에서 기술적 부채, technical debt가 생기는 것은 일상 다반사고 자연스러운 현상이라 한다.

제품 출시를 위해 열심히 개발하고 열심히 달리다보면, 생산되는 문서나 테스트 커버리지가 부족해지는 때가 분명히 온다.

 

흔히들 DDD 개발을 하자고는 하는데.. DDD(Deadline Driven Development)가 되어버리고 마는 것이다.

Domain Driven Design, 마이크로서비스의 설계 방법으로서 비즈니스 도메인별로 나누어 설계하며, 모듈 간의 의존성은 최소화(loosly coupling)하고 응집성은 최대화(high cohesion)하는 전략적인 설계 방법론으로 즉, 비즈니스의 상황에 알맞게 설계하자는 concept

(소프트웨어공학 전공 과목을 수강하며 교수님이 말씀해주셨던, 제품 출시일에 맞추어 긴박하게 개발하게 된다는 어쩔 수 없는 상황의 예시들이 머릿속을 스쳤다.)

 

 

stackoverflow 회사도 지금은 정말 많은 개발자들이 이용하는 웹사이트지만, 초창기 개발 시기에는 일주일에 7일을 모두 근무할 정도로 업무량이 많고 긴박하게 개발을 해야 했다고 한다. (기술적 부채가 안쌓일래야 안쌓일 수가 없는)

 

 

 

기술적 부채를 어떻게 바라보아야 하는가?

완성도와 적시성을 생각해보자.

즉 완벽하게 제품을 개발하는데 집중할 것인가? 또는 적합한 때에 시장에 제품을 출시하여 수익을 얻을 것인가? 

 

학습을 위한 프로젝트를 하는거라면 몰라도.. 회사는 수익을 얻어야 하는 곳이다.

완성도를 못 갖추었다 하더라도, 시장에 빨리 내놓아 성공을 하고 수익을 내야 한다!

 

 

기술 부채에 개발자들은 어떻게 대응을 해야 하는가?

사실 많은 개발자들은 방망이 깎던 노인에 비유할 수 있다.

대강 코드를 짜서 해결하려는 개발자와도 있는 반면, 좀 더 유연한 아키텍처의 프로그램을 만들려는 개발자도 많다.

speaker인 양수열 소장님께서 그동안 만났던 대다수의 개발자들은 방망이 깎는 노인과 같았다고 한다.

(내가 잘 이해한 부분인지 확실친 않지만?) 방망이 깎는 노인과 같은 유형의 개발자에게도 유연한 설계를 위해 오랜 시간 공을 들이기 위해 애쓰는 것도 중요하지만, 회사의 매출 증가를 우선시 해야 함을 잊어서는 안된다는 것을 강조하시는 것 같았다. 

몇 십억 투자금을 받은 스타트업에서도, 시간이 지남에 따라 투자금은 야금야금 고정비와 인건비 등으로 계속 빠져나가고 있기 때문..

 

 

주기적인 이자 상환이 필요하다.

원금 상환에 앞서, 날로 배로 불어 가는 이자를 주기적으로 상환하는 것은 매우 중요하다.

어떻게 상환을 한다는 것인가?

 

1. 후불 코딩을 하고 있음을 인지해야 한다. 

2. Refactoring 이 지속적으로 벌어져야 한다.

3. Pair Programming. 한 사람이 개발하고 있을 때 다른 누군가가 테스트 케이스를 만드는 방법 등으로, 개발한 그 한 사람만이 유지 보수 가능한 코드를 생산해내는 것에는 큰 위험성이 있다.

4. Risk Management. 위험을 항상 대비해야 한다.

5. Testcase. 다양한 테스트 케이스들을 만들어 발생할 수 있는 사고를 미연에 방지해야 한다. Debugging 해야 하는 범위를 줄여낼 수 있는 최선의 방법이라 할 수 있다.

 

 

원금 상환도 해야 한다!

 

어느정도 자금이 마련되면, 원금도 상환해야 한다.

원금을 상환하기 위한 방법

 

1. Restructuring. 

어떤 기업의 레거시 코드에는, 로그인을 한 번 하는데에만 call stack에 24번의 call 이 쌓인다. 즉 Rest API call 만 총 24번이 필요한 것이다. 하나의 기능에 필요한 서비스 모듈만 7~8개를 거치는 경우도 있다.

초기에 만들어진 코드는, 구조 자체를 바꿔야 할 필요도 있다. 굉장히 큰 변경 사항이지만, 원금을 상환해야 하는 상황에서는 restructure (재구조화) 을 고민해 보아야 한다.

 

2. Dead Code Detection.

많은 개발자의 인수 인계를 거친 수없이 많은 코드들 중에는, call 자체가 안 되는 죽은 메서드도 정말 많다.

사용되고 있지 않은 Dead Code를 발견하여 제거하는 작업이 필요하다.

 

3. Continuous Migration

필요 시에는 언어와 기술 스택을 옮기는 방법도 있다. 

적절한 시기에 안전망이 갖춰져 있을 때, 그리고 변경에 대한 리스크를 감내할 수 있는 상황에서 Migration을 해야할 필요도 있다.

 

4. Risk Management

 

 

부채 정리는 스마트하게!

 

1. Static Analysis

정량적인 분석이 필요하다. 

 

2. Test Code

테스트 케이스는 한 번 만들어지면, 지속적으로 활용할 수 있는, 앞으로 유지 보수하여 부가 가치를 창출해  수 있는 매우 중요한 자산, asset이다.

Debugging scope, logic scope에 대한 테스트 케이스는 지속적으로 만들어내자.

 

3. CI/CD

아직도.. 수동 배포하는 회사가 많다고 한다. Build 후 컨테이너 이미지화하까지는 많이 하지만, 실제 컨테이너 등록을 한 후 배포를 수동으로 하는 경우는 아직도 많다. (금융권)

빌드, 테스트, 배포 자동화 인프라를 구축하자.

 

4. Communication

팀에서 Migration (시스템 변경, 구조화 변경)에 대한 소통은 지속적으로 이루어져야 한다.

모든 부서 내에서 시스템을 왜, 언제 옮기는지, 그리고 왜 Migration이 필요한지에 대한 설득과 설명이 필요하다.

 

 

---

 

 

아직 사회 초년생으로서, (취준생이며 학생으로서) 부채에 대한 이해도 낮거니와

기업에서 경험하고 있는 기술 부채, 즉 IT 회사에서 code-level 에서 감당해내야 할 기술적인 부채들을 극복해내기까지의 과정에 대해 이해하기 매우 어려운 내용이었다다.

회사에서 시스템의 구조를 변경해야 하는 상황, Migration이 필요하여 소통과 설득이 필요한 상황,

Dead Code를 발견하여 제거하고, 코드 리팩토링을 하는 상황 등.. 

기술적 부채를 당연히 겪을 수 밖에 없는 스타트업을 포함한 모든 IT 기업의 개발 이사와 팀장, 그리고 기술 부채를 직접적으로 갚아 나가야 하는데 동참하는 개발자들이 겪을 만한 내용들을 세미나를 통해 간접 경험해볼 수 있어서 매우 유익했다. 

 

이렇게 들은 내용을 한 번 다시 정리해보니, 개발자로서 훌륭한 코드를 만들어내는 것의 중요성을 다시금 느낀 것 같다.

앞으로 개발자로서, code-level의 설계와 구현의 중요성을 인지하고, 누군가에게 인수 인계 해주어야 할 코드를 보다 클린하게, 유연하게 잘 작성해야 하지 않을까.