[정리 및 후기] 3월 COMMIT - 기술 부채를 바라보는 다른 시각

포스터

COMMIT

goorm에서 진행하는 COMMIT은 COMMUNICATION과 IT의 합성어로 한 달에 한 번 수요일에 기술, 개발, 성장, 조직 문화 등에 관한 이야기를 나누는 IT 세미나이다. 처음 참여했지만, 벌써 6번이나 진행했다고 한다.

구름-페이스북 과 구름-기술블로그 에서 공지를 확인할 수 있었다. 이번 회차에서는 한국인 최초 자바 챔피언이신 양수열 소장님을 모셔서 기술 부채에 대한 내용을 다루었다.

목차

여기서부터는 소장님의 발표 내용이다.

개요

기술 부채를 어떻게 하면 없앨 수 있을까요?라는 질문으로 시작한다.

"똥싸지 않는 방법이 있을까?"

답변은 "NO" 이다.

발표 내용 선요약으로, 기술 부채는 없앨 수 없다. 기술 부채를 없애지 못하는 이유와 어떻게 해결해 나갈지를 다룬다.

스타트업에서 서비스 만들기

위 그림에서 누가 사장이고 누가 개발자인지 맞춰보시오(5점) - 댓글로 작성해주세요

스타트업의 이상적인 개발 사이클은 보통 Build-Measure-Learn(BML)로 표현 된다.

1. Build (개발): 가설을 기반으로 제품 또는 서비스를 빠르게 개발합니다. 이 단계에서는 빠른 프로토타입 또는 MVP (Minimum Viable Product)를 만드는 것이 중요합니다.
2. Measure (측정): 제품이나 서비스를 실제 사용자에게 출시하고 사용자 행동 및 데이터를 수집하여 측정합니다. 이 단계에서는 주요 성과 지표(KPI)를 설정하고 수집한 데이터를 분석하여 가설의 검증 여부를 평가합니다.
3. Learn (학습): 측정 결과를 바탕으로 제품이나 서비스를 개선하고 발전시킵니다. 이 단계에서는 검증된 가설에 대한 새로운 가설을 세우고 반복적으로 빠르게 실험하며 개선합니다.

이상적이지 않은가?

현실적인 스타트업들은 그저 앞만 보고 달리는 경주마들과 같다.

소장님의 경험에 따르면 타이트하게 일하지 않던 회사들은 다 미국 갔다.

기술 부채

sprint를 하다 보면 문서화, 테스트 커버리지 등 부족한 점이 많을 수 밖에 없다. 누적이 되다보면 어느새 태산같이 쌓인 기술 부채를 볼 수 있게 된다.

위의 두 짤이 정말 기술 부채를 잘 설명한다. 현재의 방식이 구리다는 건 다 인지하고 있지만, 현실적으로 개선하지 못하는 것이다. 당장 급한불을 끄지 않으면 걱정할 미래 조차 없는 현실이기 때문이다.

많은 회사들이 DDD(Deadline Driven Development)에 의한 기술 부채가 발생한다. 피할 수 없는 자연스러운 현상이다.

완성도 vs 적시성

관련 없지만 재밌는 짤이라 추가했다.

documentation, test coverage등의 문제를 해결한 완성도 높은 서비스 vs 부족하더라도 시장성이 있는 서비스

과연 우리는 어떤 선택을 해야할까? 오프라인 참석자들의 대부분은 후자를 선택했다. 어찌보면 답정너 질문이긴 하지만, 다들 현실적이란 생각도 든다.

우리의 대응

"방망이 깎던 노인" 스토리. 수필 속의 주인공이 방망이를 주문하는데, 노인이 해가 질 때 까지 방망이를 깎고 또 깎는다.

"글쎄, 재촉을 하면 점점 거칠고 늦어진다니까. 물건이란 제대로 만들어야지, 깎다가 놓치면 되나."

결국 밤늦게 집에 와서 방망이를 내놨더니 아내는 예쁘게 깎았다고 야단이다.

개발자들은 보통 이 수필속 노인이다. 견고한 아키텍처를 만들고 싶지만 현실은 최소기능제품(Minimum Viable Product, MVP) 형태로 서비스를 만들어야 한다.

돈도 시간도 인적자원도 다 부족한 탓이다.

이제는 이 빚을 어떻게 해야할까? 돈을 빌리면 갚아야 한다. 원금을 갚을 수 없다면 이자라도 갚는게 현실이다.

이자내기

기술 부채를 상환해보자. 당장은 급해 죽겠으니까 이자부터라도 갚아보자.

주기적인 이자 상환

• Refactoring
• Pair-programming
  - 보통 코드를 작성한 인원이 해당 코드의 유지보수까지 맡게 된다. 그 인원이 휴가, 퇴사, 입원과 같은 이유로 자리를 비운다면 이 코드는 어떻게 될까? 바로 방치가 될 것이고, dead code가 될 가능성이 높다.
  - 한명은 프로덕트 코드를, 한명은 테스트 코드를 작성하는 등의 페어프로그래밍이 이를 방지할 수 있다.
• Risk management
• Testcase - log magagement
  - 로그는 100% 재현이 불가능하다. 따라서 사후 처리를 위해서는 디버그 범위를 줄이는 것이 도움이 된다. 테스트 케이스 작성하기가 효과적인 방법이다.

숨이 좀 트였을 때는, 원금도 좀 갚아보자 ㅋㅋ

돈 있을 때 원금 상환

• Restructuring
  - 외부의 전문가들을 데려와서 노하우를 배우는 등의 방법도 동원해보자
• Dead code detection
  - static analyzing tool
  - 며칠전 Naver Deview 2일차의 런타임 데드 코드 분석 도구 Scavenger - 당신의 코드는 생각보다 많이 죽어있다. 이 내용도 도움이 될 거 같다.
• Continuous Integeration
  - 오래된 시스템(legacy)을 마이그레이션 하자.
• Risk management
  - 감당이 가능한 범위 내의 Risk에 한해.

사실 Risk management는 뭔지 잘 모르겠다. 알려주시면 감사하겠습니다.

부채 정리는 스마트하게

• Static Analysis
• Test code
• CI/CD
• Communication

Q&A

Q: 항상 내가 짠 코드는 결국, 레거시가 된다고 생각하니 코드를 짤 때 종종 막막한 느낌이 있습니다. 어떤 마음가짐으로 임해야 될지 조언을 구하고 싶습니다.
A: 마음 가짐을 가지지 마세요. 뭐가 문제였는지, 본인의 판단 기준을 만들어가라

Q: 론 제프리스는 xp 규칙을 고수할 수 있다면, 부채상환을 위한 특별한 시간은 필요없다고 말합니다. 워드는 코드 확장(기능 추가) 전 리팩토링(부채상환)하는 것이 가장 좋은 타이밍이고, 미래를 위해 리팩토링(추측)할 필요는 없다고 주장하는 것 같습니다. xp 진영의 이러한 견해에 대해서 어떻게 생각하는지 궁금합니다!
A: 꾸준히 해라..

Q: 구성원의 기술 숙련도도 낮고, 경험 부족해 기술 부채를 갚지 못하고 있다면, 해결책으로 외부 인력 영입하는 방법 밖에는 없을까요?
A: 시니어가 많은 회사가 거의 없다. "Restructuring"을 한번 거친다.

Q: 이러한 기술 부채가 많은 회사에 다니는 게 제 커리어에 악영향을 미칠까요? (이런 단점이 있지만 회사 내에서 배우는 게 있기 때문에) 신입이라면 이런 부채도 겪어 보며 개인 공부를 계속 이어나가는 게 좋은지 멘토님의 의견을 듣고 싶습니다.
A: NO

Q: 기술 자산과 기술 부채를 어떻게 구분하면 좋을지, 그리고 기술 부채를 해결하기 위해 개발 조직이 가장 먼저 시도해야 할 것은 무엇인지 많은 경험을 가지고 조직을 이끄는 분의 조언을 듣고 싶습니다.
A: "해당 시스템을 유지 보수했을 때, 부가 가치를 만들어 내는가?"

Q: 실제 금융과 유사하게 기술 부채는 어느 정도의 규모에서 어느 정도의 부채를 감당할 수 있는지를 어떤 걸 기준으로 계량하고 어느 정도의 비율로 맞추는지 궁금합니다!
A: 회사가 감당 가능한 정도

Q: 보통 개발자는 오버테크롤러지를 우려하여 테스트과 통과되었을때 기술부채를 남기더라도 중단하는게 가장좋다고 이야기하는데, 하지만 정말 극단적인 동시성이라든가 완벽한 실버블릿에 대해서 꾸준히 고민하게 되는데요. 10만번에 한번 발생하는 이슈에 대한 기술부채에 대한 고견을 듣고 싶습니다.
A:

Q: SI는 거르는 게 맞죠?
A: 1000억, billing 400억 규모의 프로젝트 설계를 하게 되면, 시각이 달라지긴 한다. 하지만 1년짜리 이 프로젝트를 10년 반복하는 것. 새로운 시각을 갖고 서비스를 만들어보는 경험을 추가하는 것.

Q: 전자정부 프레임워크에서 JAVA를 채택했는데 계속 이런 기조가 유지 될 까요?
A: ㅋㅋ

Q: 기술부채의 이자비용에 대한 인식이 구성원들마다 다를 것 같습니다. 어떻게 하면 효과적으로 이자와 원금을 탕감해야한다는 공감대를 얻을 수 있을까요?
A: Communication. 뿐이다.

Q: 스타트업을 창업하셨는데 작게라도 창업을 해보는 것을 추천하시나요? 스타트업 창업 경험을 듣고 싶습니다.
A: 해보자

Q: 개발자에겐 기술 부채가 큰 문제이지만 비즈니스적(기획자나 사업자의 입장)으로는 다음 문제를 해결해야 하고 이미 정상적으로 작동 중인 로직은 손 댈 필요가 없다고 생각할 수 있습니다. 둘 사이의 갭을 메꾸기 위해서는 어떤 식으로 커뮤니케이션을 해야 할까요?
A: "돈"은 좋은 협상 수단이다. 하지만 기획자는 쉽지 않다.

정리

뭔가 용두사미 글이 작성될 걸 예상했는데 실제로 용두사미 글이 되어버렸다.

놀랍다. 나의 직감.

재밌게도 기술 부채에 대한 강연중 가장 공감이 많이 간 부분은 방망이 깎던 노인 내용인 것 같다.

나도 질문을 하나 남겼는데,

기술 부채는 현업에서만이 아닌 사이드나 포트폴리오를 위한 프로젝트에서도 충분히 생길 것 같습니다. 현업과 같은 기준으로 실전처럼 접근하는 것이 좋을지, 트레이닝하는 느낌으로 접근하면 좋을지 궁금합니다.

답변은 받지 못했다. 소장님은 어떤 답변을 해주셨을까 하는 고민이 남는다. 메일로라도 물어볼까..?

구름에서 진행한 양수열 소장님 인터뷰 도 한번 보는 것을 추천한다.