2023년 3월 COMMIT은 한국인 최초 자바 챔피언인 양수열 소장을 모시고 ‘기술 부채’에 대한 이야기를 나누었습니다. 기술 부채는 개발자라면 누구나 한 번쯤 마주치게 되어 있죠. 기술 부채가 없는 회사도 존재하지 않고요.
기술 부채를 피할 수 없다면 어떻게 바라보고 대해야 할지 양수열 소장이 들려주신 이야기를 정리해봤습니다.
🎤 이 아티클은 양수열 님의 3월 COMMIT 세미나 내용을 바탕으로 재구성되었습니다.
기술 부채는 없앨 수 없다
이런 절망적인 상황에서 우리는 어떻게 개발해 나가야 할까요? 기술 부채를 긍정적으로 받아들이는 방향으로 접근해 볼게요. 조금 다른 시각으로 기술 부채를 바라보는 시간이 되길 바랍니다.
스타트업에서 서비스 만들기
저는 외국계 스타트업, 한국 스타트업 등 다양한 곳에서 근무했습니다. 대다수의 회사는 사장님이 이것도 해보고 저것도 해보자며 열심히 직원을 설득합니다. 좀 더 큰 조직은 비즈니스 디벨롭을 하는 분이나 세일즈 디비전에서 아젠다를 가져와 개발팀과 미팅하기도 하죠. 대부분 이런 환경에서 개발하고 계실 텐데요.
이상적인 스타트업 개발 프로세스는 프로그램을 만들어서 측정하고, 인사이트를 도출한 다음 개선하는 과정을 거칩니다. 이런 사이클이 계속 반복되죠. 외국 회사도 마찬가지입니다. 아쉬운 건 ‘이상’이라는 점이죠. 좋은 프로세스라는 건 알지만 막상 적용하기는 어려워요.
대부분의 스타트업은 100m 달리기 주자라고 생각합니다. 100m 경기에서는 옆 사람을 보면서 뛰지 않아요. 0.1초라도 기록을 단축하려면 앞만 보면서 뛰기 바쁩니다. 열심히 달리다가 뒤를 돌아보면 문서나 테스트 커버리지 등이 모자랄 수밖에 없어요. 당연합니다. 모두가 못난 코드라는 걸 인지하고 있지만 그럼에도 목표를 향해 가야 하는 상황인 거죠.
그러다 보면 기술 부채는 모래시계처럼 계속 쌓입니다. 부채가 나쁜 건 알고 있지만 어쩔 수 없다면 다르게 보는 것도 방법이에요.
완성도 VS 적시성
기술 부채를 만들지 않으려면 매번 완성도 높은 문서와 테스트 커버리지, 정성적인 평가와 정량적인 분석이 필요합니다. 그럼에도 완성도를 낮추면 시장에 빠르게 릴리즈할 수 있고 성공한다면 돈을 벌 수도 있죠.
대다수 개발자들은 수필 ‘방망이 깎는 노인’ 속 노인 같아요. 잘 만들고 싶고, 잘 고치고 싶고, 좋은 아키텍처의 프로그램을 만들고 싶어 합니다.
열심히 방망이만 깎는 게 정답일까요? 안 팔리는 방망이가 계속 쌓이듯 기술 부채가 쌓이면 확장이 어렵습니다.
이자 내기
‘영끌’, ‘빚투’라는 말이 있죠. 저는 많은 스타트업에도 적용할 수 있는 용어라고 생각합니다. 제가 빚을 내 방망이를 만들고 있는 이 순간에도 회사는 돈이 나가고 있어요. 투자금을 쪼개 방망이를 만들고 있는 거죠.
스타트업 대표뿐만 아니라 개발자들도 빚에 대해 인지해야 합니다. 그래야 깎고 있던 방망이 중 팔 수 있는 일부는 먼저 선보일 수 있어요.
은행에서 돈을 빌리면 원금을 상환하거나 이자를 내죠. 원금도 갚지 않고, 이자도 안 내는 대출 상품은 없습니다. 적어도 이자는 낼 수 있어야 빚을 질 수 있어요. 기술 부채에서 이자를 낸다는 건 시스템을 조금씩이라도 계속 고치는 거예요.
주기적인 이자 상환
페이스북 지인분이 기술 부채를 ‘후불 코딩’이라고 표현하시더라고요. 저도 후불 코딩이 조금 더 적확한 표현이라고 생각합니다. 언젠가 돈을 지불해야 한다는 의미가 더 도드라지거든요.
조금씩이라도 이자를 내야 부채를 감당할 수 있습니다. 이자를 상환하는 방법은 크게 4가지인데요.
- 리팩토링(Refactoring)
- 페어 프로그래밍(Pair Programming)
- 위험관리(Risk Management)
- 테스트 케이스(Test Case)
회사의 규모에 상관 없이 어떤 모듈에 대한 유지 보수를 하는 사람은 대부분 한 명인데, 조금씩이라도 페어 프로그래밍을 해야 담당자가 퇴사해도 대처할 수 있습니다. 아니면 다른 동료가 테스트 케이스를 만들고 저는 메인 코딩을 하는 것도 방법이에요. 저는 동료가 만들어 둔 테스트 코드로 내가 작성한 코드가 테스트를 통과하는지 확인해보는 거죠.
리스크 관리도 중요합니다. 많은 회사가 발생할 가능성이 낮다고 해서 거의 관리하지 않지만, 시스템이 돌아가지 않는 리스크도 관리해야 해요.
런타임 환경의 시스템 리소스는 여유롭지 않습니다. 평소에 디버깅할 수 있는 범위를 줄이는 노력이 필요한 이유죠. 이런 노력은 당장 조금씩 시작해야 해요.
돈 있을 때 원금 상환
돈을 벌면 원금을 상환해 이자를 줄여나가야겠죠.
- 리스트럭처링(Restructuring)
- 불필요한 코드 찾기(Dead code detection)
- 지속적인 마이그레이션(Continuous migration)
- 위험관리(Risk management)
제가 아는 어떤 회사는 로그인을 하면 콜(call)만 24번을 거치더라고요. 서비스 모듈이 78개 정도 되고요. 콜이 그렇게 많을 필요가 있나 따져보면 아니거든요. 충분히 방법이 있습니다. 구조상 처음부터 그렇게 만들어진 것들은 변경하는 수밖에 없지만요.
인수인계가 여러 번 된 코드를 보면 콜이 안 되는 코드들이 매우 많습니다. 이런 코드는 주기적으로 찾는 게 좋아요. 나이트캐피탈 사태가 유명하죠. 한 번도 콜이 안 되던 코드 블록이 런타임에서 문제를 일으켜서 파산 직전까지 갔습니다. 여러분의 코드도 어느 순간 시스템 장애를 일으킬 수 있어요.
리스트럭처링이나 마이그레이션은 큰 시스템 변경인 만큼 충분한 안전망을 갖추고 진행해야 합니다. 중요도나 비즈니스 상태를 고려해야 하고요. 회사가 감당할 수 있는 범위의 리스크인지도 파악해야 합니다.
부채 정리는 스마트하게
저는 가급적 사람이 하나하나 고민하며 부채를 정리하는 건 최소화하는 게 좋다고 생각해요. 무언가 도움이 되는 방법이 있다면 최대한 이용하면 좋겠습니다.
- 정적 분석(Static Analysis)
- 테스트 코드(Test code)
- 지속적 통합(CI)/지속적 배포(CD)
- 커뮤니케이션(Communication)
로직 테스트 같은 건 개발자가 한 번 만들어 두면 계속 사용할 수 있는 자산이잖아요. 이런 자산에 대한 투자도 지속적으로 이루어져야겠죠.
아직 빌드 시스템을 자동화하지 않은 회사들도 많습니다. 금융권 같은 곳들은 아직 수동으로 배포하기도 해요. 이때 커뮤니케이션이 안 된 채로 일부 마이그레이션을 진행하면 큰 사고가 날 수 있습니다. 팀 내 혹은 다른 부서와 소통이 잘 이루어져야겠죠. 잘못하면 마이그레이션 자체가 부채가 될 수 있습니다.
기술 부채를 일반화해 정의하기는 어렵습니다. 회사의 규모나 비즈니스에 따라 천차만별이거든요. 어떤 회사에서는 부채인 게 어떤 회사에서는 자본일 수도 있습니다. 적어도 해결할 수 없는 부채는 없어요. 일단 안고 가는 거죠. 모두 차근차근 갚아나가시면 좋겠습니다.
Edit Sunny Design Lil
