기술 부채를 보는 다른 시각 (3월 구름 COMMIT)
SW 교육 플랫폼 '구름'의 3월 COMMIT 무료 세미나를 유튜브 온라인 LIVE로 수강하여 세미나 요약과 간단한 수강 후기
기술 부채, 꼭 다 갚아야 할까요?
기술 부채
1992년 와드 커닝험이 만든 용어로 기술적인 ‘빚’에 가깝습니다. 기술의 완성도보다
비즈니스 속도를 중요하게 여겨 기술적인 문제를 뒤로 미루다 보면 마치 갚아야 할 부채처럼 압박이 될 수 있다는 뜻이에요. 급하게 개발한 것들이 결국 나중에 해결해야만 하는 업무로 남는 거죠.
- 개발자라면 누구나 한 번쯤 기술 부채를 마주치게 된다. (필연적으로 발생)
- 오버엔지니어링
- 빠듯한 일정
- 급격한 요구사항 변경
- 개발 전문성 부족 등
다양한 이유로 쌓여만 가는 빚... 부채는 무조건 나쁜 것인가?
최소기능제품(Minimum Viable Product, MVP)을 개발하다 보면 어쩔 수 없이 쌓이는 기술 부채가 그렇죠. 기술 부채를 완전히 막기는 어려운데, 피할 수 없다면 어떻게 관리해야 하는지 한국인 최초 자바 챔피언, 케어마인드 CTO 양수열 님이 말하는 기술 부채를 바라보는 새로운 생각과 태도에 대해서...
출처 - 구름 블로그
자바 챔피언..? 전 자바를 잘 모르는데..양수열 님은 대체 어떤 분일까요...?
기술 부채 다시 생각하기
기술 부채가 생기는 주요 개발 과정의 딜레마
완성도 높은 개발 vs 일정을 준수한 빠른 개발
"그동안 제가 본 대부분의 개발자는 방망이 깎는 노인"이었어요."
대부분의 개발자가 만드는 소스 코드들..
필립스의 유명한 광고 '작은 차이가 명품을 만든다'
명품은 작은 차이까지도 고려하지만..
스타트업은 투자 받는 순간 빚이다
이자를 낼 수 있다는 현실 감각
주기적인 이자 상환이 필요한 시점
- Refactoring : 유지보수하면서 기술 부채를 조금씩 갚아나가는 것
- Pair-Programming : 기술 부채가 많은 시스템에 대해 아는 개발자가 만약 교통사고 당하거나 6개월 간 입원하여 해당 개발을 할 수 없다면..? 이럴 때 대체하여 팀에서 해결해갈 수 있어야
- Risk Management : 예를 들어 은행 시스템의 경우 기본적인 방침은 리스크 관리, 그러나 감당할 수 없는 부채가 리스크가 된다면?
- Test Case : 기술 부채가 발견될 때
돈 있을 때 원금 상환
-
Restructuring : 가령 구조상 만들어진 문제들을 개선하는 것은 쉽지 않음 (굉장히 큰 변경사항을 동반함)
-
Dead code detection : 사람이 못 찾는 에러들..
ex) 나이트캐피탈의 사례
한 번도 콜 안 되던 코드들이 시스템에 쌓여 있었는데(그동안 유지보수 없이), 런타임 시 조건 변경하니 발생한 생각지도 못한 에러 -> 시스템에 크리티컬한 장애 유발 -
Continuous migration : 흔히 말하는 레거시를 개선할 수 있는 설계자 수는 많지 않다. 그러나 유지비용이 갈수록 올라간다 (특히 코어 시스템을 자바로 전환하거나 웹 기반 분산 시스템으로 변경 동반이 필요할 경우)
-
Risk Management : 큰 변화를 대응할 수 있는 안전망이 필요할 때. 마이그레이션 하면 되지? 그러나 마이그레이션을 할 경우 현재 비즈니스 상태를 고려해야 함.
회사가 현재 감내할 수 있는 범위 내의 리스크인가? 아닐 경우라면 마이크레이션의 시기가 적절한지 생각해 볼 필요성
부채 정리는 스마트하게
- Static Analysis : 사람이 할 수 없다면 기계나 툴(SW, 솔루션) 도입, 활용한 개선
- Test Code : 재사용할 수 있는 Code Assets을 추가
- CI/CD : 빌드 시스템 자동화 여부. 단, 크리티컬한 시스템은 아직도 수동 배포를 하는 회사가 많다.
- Communication : 팀 또는 유관부서와의 소통이 부재할 경우 그 또한 기술 부채 유발.
우리 팀끼리만 소통 X. 관련있는 부서에도 설득 & 설명의 필요성
Q & A 시간
이렇게 세미나 후 실시간 질문 받기를 통해 양수열 님께서 몇 가지를 선별해 질의응답 시간을 가졌다.
Q : 항상 내가 짠 코드는 결국, 레거시가 된다고 생각하니 코드를 짤 때 막막한 느낌이 있다. 어떤 마음가짐으로 임해야될 지 조언을 구하고 싶다.
개발자로서의 부담감을 내려놓아라.
대신 뭐가 문제였는지 경험해보고,
자신만의 판단 기준을 만들어 가라.Q : 구성원의 기술 숙련도가 낮고, 경험이 부족해서 기술 부채를 갚지 못하고 있다면, 해결책으로 외부 입력을 영입하는 방법 밖에는 없을까요?
현실적으로 최근 시니어가 많은 회사가 적다.
개발자 수요가 늘고, 개발자 인력이 시장에 늘어나고 있지만
회사의 상황(캐시)에 따라 다를 것 같다.
시리즈A로 투자를 받았을 때 대대적으로 리팩토링을 하는 경우도 있다.
우선 돌아가게 만들고, 유지하다 투자를 많이 받으면
대대적으로 싹 다 개선하거나..
만일 외부 영입이 어려울 경우 조직 성장 관점에서
내부 인력 멘토링이나 학습을 통한 방법도 있다.Q : 기술 부채가 많은 회사에 다니는 게 제 커리어에 악영향을 미칠까요? 배우는 것도 있지만 신입이라면 이런 부채도 겪어 보며 개인 공부를 계속 이어나가는 게 좋은지 멘토님의 의견을 듣고 싶습니다.
기술 부채가 없는 회사는 존재하지 않음.
기술 부채가 내 커리어에 악영향을 준다?
저는 자바로 첫 컴파일을 1990년대에 했었는데,
게임회사에 다니는 지인은 C++를 사용중이다.
지인 왈 "아직도 C++이 많이 남아 있어"
다만 오래된 시스템을 유지보수하는 인력도 존재하고
Y2K 사례처럼 운영중인 시스템에서
발견되지 못하는 에러들은 계속 나올 것이므로
(그런 것을) 해결해갈 수 있어
레거시가 커리어에 부정적인 영향을 준다고 생각하지 않음.
현재 많이 사용중인 파이썬이나 노드에서도
Y2K와 같은 사례가 나올 가능성이 앞으로도 있을 것이라 생각Q : 기술 자산과 부채를 어떻게 구분하면 좋을지? 기술 부채를 해결하기 위해 개발 조직이 가장 먼저 시도해야 할 것은 무엇인지?
개발 조직으로서 가져야 할 기준은
이 시스템을 유지해서 부가가치를 창출하느냐?
예를 들어 API gateway와 같은 인프라성 시스템을
내부에서 자체 개발하여 유지보수하고 있는 회사가 있다.
그런데 이 시스템이 회사의 메인 비즈니스와 관련이 있는지 판단.
이 때 유지보수하는 시간과 비용을 고려한다면
자체 개발이 아닌 다른 솔루션으로 대체하고
다른 더 핵심역량에 집중하는 방법도 생각해볼 수 있다.
개발조직으로 인지해야 할 것은
"목적없이 개발하지 않을 것"
"부가가치가 있는 것을 개발할 것"
저는 이제까지 개발팀이 한가하고 리소스가 남는
스타트업을 본 적이 없어요.Q : 실제 금융과 유사하게 기술 부채는 어느 정도의 규모에서, 어느 정도의 부채를 감당할 수 있는지?
감당 가능한 리스크인가?
파산하는 리스크인가?
회사 관점에서 시스템을 돈과 결부지어 판단
가령 국민은행 인터넷뱅킹이 하루, 1주일 장애라면?
은행권 오프라인 지점을 폐쇄하는분위기에서
온라인이 중요한 시스템이라면?
(은행은 라이센스가 있어야 함으로 리스크 관리가 되지 않을 경우
라이센스를 반납할 가능성도 있다)Q : 오버 테크놀로지가 우려될 때 필요한 은탄환은? 10만 번에 1번 발생하는 이슈에 대한 기술 부채가 있다면?
개발자는 대부분 방망이 깎는 노인인데
Thread Safety, Type Safety와 같은
미션 크리티컬한 경우는 이미 설계 때부터
고려하거나 고민했을 것이고
그에 맞는 구현 언어를 채택했을 것.
그런 게 아니라면 10만 번에 1번 발생하는 이슈에
기술적 리소스가 많이 투입된다면?
저는 그것을 이기심이라고 본다.
적정선을 찾을 필요성.
지인 중에 소켓통신, 전문개발, TCP/IP 프로그래밍과 같은
정형화된 개발을 하는 사람이 있다.
회사에서 하는 개발을 비슷하게 하여
범용성 좋은 프레임워크를 개발한 분인데
내가 돈을 받고 구현하는 개발과
나를 위한 완성도 높은 개발을 구분할 수 있는 관점 필요Q : SI는 거르는 게 맞는지?
SI는 과연 나쁜가?
1,000억 짜리 대규모 시스템을 접하게 되면,
소프트웨어를 보는 관점이 달라진다.
만일 1년 짜리 SI를 10번 다닌 커리어는 쳇바퀴와 같겠지만
SI든 서비스든 스타트업이든 다양한 분야를 오고가는 경험을
또 다를 수 있음.
장단점이 없는 곳은 없다.
대기업은 나에게 주어진 업무만 하지만
스타트업은 연좌제나 다름 없다. 내 일이 아니어도 할 수 밖에 없다.
이 때 어느 분야에서 개발하든 내가 그곳에서 배운 것과
본인 스스로 어떤 판단하는가가 중요하다.Q : 전자정부 프레임워크에서 JAVA를 채택했는데 계속 이런 기조가 유지될까요?
저도 참여중인데 앞으로 계속될 거 같다Q : 기술부채의 이자비용에 대한 인식이 구성원들마다 다를 것 같다. 어떻게 하면 효과적으로 이자와 원금을 탕감해야한다는 공감대를 얻을 수 있을지?
'이자내는 돈이 아까워..'
그런데 상환을 잘 하지 않으면
채권압류, 경매, 채권추심.. 이런 것이 들어간다.
이 때 구성원 간의 커뮤니케이션을 통해
기술 부채에 대한 이자 상환과 원금 상환까지
제고해야 할 필요성을 가져야Q : 스타트업을 창업하셨는데 작게라도 창업을 해보는 것을 추천하는지?
개발자라면 언젠가 창업을 하거나 조인을 하게 됨 (자의든 타의든)
개발자 웝급에는 언젠가 한계
언젠가 창업에 참여하거나 참여되는 상황에 놓임
언젠가는 직면하는 현실.
카카오톡 게임 중 초창기에 '애니팡'을 만든 회사의 이름을 아시나요?
'선데이토즈'
네이버 출신 개발자들이 일요일마다 토즈에 모여 게임을 제작했다는 유래
앞으로 챗GPT같은 것으로 인해 노동력이 상쇄되고
그런 것에 도움을 받아 코딩, 로직을 아는 개발자라면
1인 창업을 준비하거나 5천만원 ~ 1억 미만의 마이크로서비스를 만드는 것도 가능
이런 개발을 통해 만들면서 배워가게 됨Q : 비개발자 직군에게 기술 부채를 갚는 것에 대해 어떻게 설득해야할지?
재무부서를 설득해야한다면
기술 부채를 유지하는 것에 대한 손실액을 들어 설명하거나
마케팅부서를 설득해야한다면
data 기반으로 마케팅 데이터를 들어 설명하거나
기획부서를 설득해야한다면..
그런데 기획부서 설득이 제일 어렵다.
IT도 좀 알고...
이럴 때 대표이사에게 압력을 넣거나(농담)
'사업 접는데요' '리스크가 방치되고 있어요'
기획부서 설득이 가장 어려운 부분..정리
COMMIT 세미나 내용을 글로 보려면
양수열 소장, “개발자 마음속의 짐 ‘기술 부채’를 덜어내려면”
-
19시에 시작하는 유튜브 LIVE인데 조금 늦게 접속하여.. 19:20분부터 수강
-
마지막 부분에서 사회자분께서 오늘 세미나를 듣고 '이자를 반드시 내야한다'라는 말을 하니
양수열 님께서 '채권 추심'되요!라고 외치고 나가셨는데... 이 말이 참 현실적인 게
우리 아빠는 군 생활 이후 사기업에 2-3년 근무하신 적이 있다. 그 때 카드사에서 근무하신 적이 있는데
당시 아빠가 했던 일이 채권 추심과 관련된 일이었다. 이후 카드대란과 같은 사회적 현상이 있었던 것으로 기억...(짧게 다니신 회사였지만 당시 직원 가족들을 초대하여 운동회같은 워크샵도 했는데 그 때 한솥도시락이 고급이었던 그런 시절..) -
근데 바로 채권 추심이 되진 않고 아마 신용불량자가 되는 게 먼저일거다. (맞나?) 예전에 취준생 시절 1-2달 학자금대출을 연체한 적이 있는데 이 때 신용회복위원회에서 강의를 들었던 기억이 있다. (그리고 정권이 바뀌어서 학자금대출에 대한 전환대출이 이루어졌다) 아무튼 이자상환이든 원금상환이든 중요하다...
-
난 자바를 잘 모르지만, 자바도 아마 지금의 러스트나 고, 타입스크립트와 같은 핫한 기술인 시절이 있었을텐데 오늘 세미나에 나온 연사님의 연배가 되시던 분들은 대부분...
-
얼마 전 갤럭시23이 나온 적이 있다. 그 때 같은 팀분들이 굉장히 열광적(?)인 반응을 보인 적이 있었는데.. 그 때서야 내가 이제 더 이상 디자이너가 아니라는 것을 체감했다. 알다시피 디자인계에 있다면 애플과 아이폰은 신성, 바이블이기에.. 디자이너들끼리 FLEX하는 방법은 아이폰이나 아이맥, 맥북이었는데...
나중에 친구에게 이 이야기를 했더니 자바에 대해서 공부해 봐!라고 답변해주었다..😀
