기술부채를 바라보는 시간 세미나 후기

지금은 기술부채에 대해 관대적으로 대하고 프로덕트가 중심을 생각하고 개발하고 있지만 회사 입사 초기에는 많은 개발자들이 추천하던 클린코드, 소프트웨어 장인 정신 등을 읽으면서 클린 코드, 클린 아키텍처, TDD 등에 빠져살면서 이상주의 개발자처럼 개발했었다.  이런 이론만 접하고 공부하다보니 회사에 상황을 충분히 인지하지 못하고 프로덕트를 만들어서 가치를 창출하는 것보다 더 품질 높은 소프트웨어를 만들기위해 집착했었다.

 

그렇게 회사의 상황을 고려하지 못하고 회사에 기술부채가 너무 많아서 당장 기능 개발이 어렵다고 이야기하고 부채와 기능개발을 같이 하도록 개발자 인력 충원을 요청하고 이상적인 이론에 대해 공부 하다가 어느날 투자가 무산되어 회사가 망하게되면서 회사에 나오게 되었다. 해당 스타트업에 있었던 것은 3개월 정도밖에 안되었지만 나의 영향이 아예 없다고 할 수는 없을 것같다.

 

그 후 이직하고나서 여러 IT 세미나와 컨퍼런스를 다니면서 여러 개발자들을 만나고 책을 읽으면서 개발자의 역활은 좋은 소프트웨어를 만드는 것이 아니라 소프트웨어를 통해 문제를 해결하고 가치를 창출하다는 것이 중요하다고 한 것을 알게 되었다. 그렇다고 클린 코드와 클린 아키텍쳐등이 중요하지 않다는 것은 아니다. 결국 기술부채는 언젠간은 해결해야한다. 방치하고 있다가는 대형 장애나 큰 리스크를 가져오는 문제가 발생시켜 늦어버릴 수 있게 된다. 아직 경험이 부족한 나에게 이러한 기술부채에 대해 들려주는 세미나는 좋은 인사이트가 될 것 같아 참여하게 되었다.

 

스타트업의 이상

https://marmelab.com/blog/2016/02/12/build-measure-learn.html

이상적인 스타트업은 위 그림과 같은 구조로 일을 하는 기업이 이상적이라고 이야기를 해주셨다. 하지만 스타트업에 여러번 솔루션을 해주고 다녀본 경험을 이야기 해주셨는데 현실은 아래와 같다라고 이야기를 해주셨다.

• 대부분의 스타트업은 옆사람은 보지 못한다. 자기 앞만 보고 달려가기에도 바쁘다.
• 그렇게 달려가다보면 대부분의 스타트업은 문서화, 테스트 커버리지를 신경 쓰지 못한다.
• DDD - 데드라인 주도 개발, 우스갯소리로 이야기하시고 스타트업의 현실과 너무 맞는 단어라고 하셨었는데 너무 공감이 가는 부분 중 하나였다 :)
• 초기에 스택 오버 플로우는 이전에는 일주일동안 7일을 야근한 적이 있었다, 실리콘 벨리에서 가장 많이하는 회사는 구글이다.

기술부채가 나쁘다는 것은 알고 있지만 현실은 스타트업도 대기업도 각각의 부채를 가지고 있으며 부채가 없어질 수는 없다고 이야기를 해주셨고 일화를 들려주셨던 이야기 중 하나가 있는데 기술부채를 만들고 있는 자신에게 괴로우면 개발을 계속 해야되냐는 질문에 아래와 같이 답하셨다고 이야기 해주셨다. "기술 부채는 없어질 수 없다. 오늘 잘 만든 코드가 미래에는 부채가 된다. 그러니 기술부채에 대해 좀 더 포용하는 자세로 개발해야한다."

 

완성도와 적시성

소프트웨어를 완성도를 높여주는 좋은 툴이 여러가지 있다. sonaqube, eslint와 같은 툴을 활용하여 코드 컨벤션, 보안 취약점, 나쁜 냄새의 코드를 검사하여 빌드하기 전에 이러한 툴을 활용한다면 높은 수준의 소프트웨어를 개발할 수 있다. 하지만 이러한 높은 수준의 소프트웨어가 어떤 가치를 만드는지 생각해봐야 한다.  양수열 소장님은 기술부채를 해결하는 개발자를 방망이깎는 노인과 빗대어 완성도와 적시성을 이야기 해주셨다.

https://www.teamblind.com/kr/post/%EB%B0%A9%EB%A7%9D%EC%9D%B4-%EA%B9%8E%EB%8D%98-%EB%85%B8%EC%9D%B8-kVcwMxPw

• 좋은 코드와 구조를 검사해주는 여러가지 툴이 있기 때문에 이러한 개발도구를 활용하여 품질을 높일 수 있다.
• 높은 수준의 품질을 소프트웨어를 개발해도 결국 망한다면 의미없는 일이된다.
• 개발팀이 돈을 벌어다주고 비지니스적 가치가 있다면 회사는 투자를 하게 되어 있다.
• 우리는 기술 부채를 보게되면 방망이 깎는 노인처럼 되어 오버 엔지니어링을 하게된다.
• 그렇다고 너무 현실을 보지 말자. 작은 차이가 명품을 만들듯이 가까운 미래에서 일어날 수 있는 문제는 리소스를 투자하는 것이 좋다. 

이자내기

스타트업은 영끌, 빚투와 비슷하다. 방망이를 깎는 중에도 계속 돈이 나가게 된다. 스타트업은 자본이 한정되어 있기 때문에 지금 당장 빚을 지더라도 더 빠르게 가치를 창출하여 입증해야 한다. 그렇다면 기술부채를 계속 쌓아야 될까?

 

이자 상환

• 전세대출 이자 상환을 연체하게 되면 가상 금리가 붙게 된다. 기술부채도 마찬가지로 이자를 내지 못하면 더 많은 부채를 지게된다.
• 기술부채라는 단어보다 후불 코딩이라고 생각한다. 선불로 코드를 메인 비지니스 로직을 짜게 되고 나중에 여러 기능이 붙고 정책이 변경되게 되면서 지저분한 코드가 되었을 때 나중에 리팩토링을 통해 개선하면서 지불하는 것이다.
• 내가 짠 코드의 설계를 다른 사람이 모르는 것도 부채이다. 페어 프로그래밍, 테스트 케이스를 상대방이 작성 등을 통해 내가 짠 코드와 구조를 공유하여 내가 없더라도 대응할 수 있어야 한다.
• Risk management - 조금의 성능 개선, 리팩토링 등을 통해 리스크를 잘 관리해야한다.
• Testcase - 디버그를 해야하는 스코프를 줄이는 것이 중요하다. 실제 서버를 운영하다보면 로그를 찍더라도 그때 그상황이 아니라면 알기 어렵기 때문에 테스트 케이스를 작성하여 추측할 수 있는 범위를 줄이는 것이 좋다.

원금 상환

• Restructuring: 설계의 구조를 변경하는 것은 상당한 리스크를 가지게 된다. 하지만 방치해두다가는 건너지 못할 강을 건너게 될 수 있다. 예시로 로그인 하는데 Rest 요청만 24번하는 서비스가 있었는데 이러한 서비스의 문제가 발생한다면 문제를 해결하는 것도 원인을 찾는 것도 매우 어렵다.
• Deep code detection: 사용하지 않는 코드를 방치하는 것도 매우 위험한 행위이다. 나이키에서 전혀 안쓰는 코드를 놔두고 있다가 다른 코드가 변경되어 안쓰는 코드의 로직을 타게되면서 수천억의 피해가 발생한 적이 있다.
• Continuous migration:  잘 동작하여 오래된 기술을 방치해놓다가 나중에 문제가 발생하거나 새로운 기능을 추가하려고 할 때 기능을 개선할 때의 비용보다 더 큰 비용을 들이게 될 수도 있다. 개발자가 수급이 안되는 기술을 쓰다가 문제가 발생한다면 해결이 불가능하다.
• Risk Management: Restructuring은 엄청 큰 리스크를 따르는 행위이다. 회사에서 리스크를 감당하지 못하는 마이그레이션을 하는 행위는 하면 안된다. 해당 마이그레이션을 통해 서비스의 개발을 멈춰야 될 정도의 범위라면 조금씩 점진적으로 개편하는 것이 좋다.

부채정리는 스마트하게

• Static Analysis: 부채정리를 하면서 사람이 하나하나씩 고민해서 처리하는 것은 최소화하는 것이 좋다. 사람이 처리하면 리소스도 많이 들게 되고 휴먼에러로 인해 다른 부채를 가져올 수 있다. 좋은 개발 도구와 툴이 많이 있으니 잘 활용하여 자동화하자.
• Test code: 자동화된 테스트를 통해 디버그 스코프를 줄이는 이유도 있지만 공통으로 쓰는 모듈 같은 경우 오래쓰는 경우도 많다.
• CI/CD: 엄청 대규모 시스템이지만 아직도 수동배포를 하는 곳이 있다. 배포하는 것은 한번 구축해놓으면 변경될 일이 잘 없고 사람이 하는 것보다 컴퓨터로 관리하는 것이 안정적으로 배포할 수 있다.
• Communication: 개인이 하고 있는 일에 대해 간간히 공유해야된다. 팀원들에게 하고 있는 일에 대해 설득, 설명을 하지 않고 독단적으로 알고 개발했다면 그것은 회사의 부채이다. 그러다가 개인이 자리를 비웠을 때 감당못할 부채가 발생할 수 있다.

질의 응답

질문: 내코드가 항상 레거시가 된다고 생각 하는데 어떻게 해야될지?

대답: 그런 마음을 가지지 말고 뭐가 문제였는지 생각하고 자기의 판단기준을 만들어가는 것이 중요하다.

질문: 론제프리스(윈도우 개발자)가 부채 상환을 필요없다고 말한다. 코드 확장(수정)전 리팩토링이 가장 좋은 타이밍이다. 라고 하는데 어떻게 생각하는지?

대답: 개인이 론제프리만큼은 하기 어려울 수 있다. 하지만 자기가 할 수 있는 수준까지 시간내서 조금씩이라도 하자. 

질문: 구성원의 기술 숙련도가 낮고 경험이 부족해서 기술 부채를 갚지 못한다면 외부 인력 영입할 수 밖에 없을까?

대답: "회사에 캐시가 얼마나 있느냐", "외부 인력을 가져올 여유가 있느냐"에 따라 매우 달라질 것이라고 생각한다. 투자를 받았을 때 잠깐이라도 스팟을 하여 내부에 있는 인력에게 전파하고 나가는 형식일 수도 있다. 내부의 인력을 성장시키려고 하는 것이 중요하다.

질문: 기술 부채가 많은 회사에 다는게 커리어의 악영향을 끼칠까?

대답: 큰 회사, 작은 회사든 기술부채가 있다. 이러한 상황이 없던 것이 아니다. 기술부채가 많아지는 것은 새로운 기술이 나오고 언어들이 나오면서 어쩔 수 없다. 자기가 자바로 하고 있는데 자바로 하는 메인 트러스가 많다면 그것이 나쁜 것일까?

질문: 기술 자산과 기술 부채를 어떻게 구분해야할까?

대답: 비지니스적 가치를 계속 창출하느냐 아니냐가 그차이이다. 비지니스적 가치를 창출해내지 못한다면 그것이 부채이다. 메인트러스에 쓸 코드가 줄어든다는 것은 다른 곳에 좀 더 리소스를 활용할 수 있다는 것이다. 목적이 있고 가치있는 것을 만드는 개발팀이 되자.

질문: 기술 부채는 어느정도 규모에서 어느 정도의 부채를 감당할 수 있을지 기준을 계량할까?

대답: 회사가 리스크를 감당하냐 못하냐 차이다. 마이너스가 발생했을 때 어느정도 감내할 수 있는지 돈으로 측정해봐야된다. 감당할 수 없는 부채는 해결방안을 마련해야된다. 그것이 리스크 매니지먼트이다. 

질문: 동시성, 실버불릿과 같은 빈도가 낮은 기술부채에 따른 의견을 듣고 싶다.

대답: 스레드 안정성, 타입 안정성이 필요한 시스템이 있다. 시스템을 설계할 때 부터 고려해야되는 것이지만 나중에 개선해야 되는경우가 발생하기 마련이다 . 그렇다면 리소스 대비 얼마나 이팩트가 나오는지 생각하자. 들어가는 리소스 대비 이펙트가 그렇게 크지 않는데 너무 많은 리소스를 소모하게 되면 이기적인 사람이라고 생각한다. 돈을 벌기위한 것과 내가 하고 싶은 것을 적절하게 구분하자.

질문: SI는 안좋은 커리어가 될까요?

대답: 프로젝트 비용이 몇백억이나 몇천억이 들어가는 것을 보게되면 시스템을 설계하는 관점이 달라진다. 금융권 같은 경우 보안이 중요하기 때문에 방어적 프로그래밍하는 방법에 대해 많은 지식을 얻을 수 있었다. 안좋은 경험은 없다. 그 경험을 받아들이는 나의 태도가 중요하다.

질문: 기술부채와 이자비용에 대한 인식이 구성원마다 다르다. 어떻게 공감대를 얻을 수 있을까?

대답: 커뮤니케이션이 중요하다. 꾸준히 이러한 문제가 어떤 리스크를 가지고 어떠한 피해를 입는지 충분히 공유해야한다. 문제가 발생했을 때 에는 너무 늦을 수 있다.

질문: 비개발자에게 개발 부채를 어떻게 설득하면 좋을까?

대답: 구체적인 돈이나 데이터를 근거로 이야기하면 좋다. 기술 부채로 우리가 어떤 손해를 입을 수 있는지 이야기하여 설득해보자.

느낀점

회사에 입사하기 전 인터뷰에는 어려운 기술면접과 과제들을 통과하고 입사했지만 실상은 그렇게 좋지 못한 설계와 코드, 기술부채들을 보고 실망하게 된다. 나도 그 중 하나였고 스타트업을 다닌 경험이 있다면 모두가 겪었을 것이라고 생각한다. 그때에는 기술 부채에 끼워맞추고 있는 나 자신에게 회의감이 들고 스트레스를 받았었지만 지금와서 생각해보니 어쩔 수 없는 선택을 했던 것이라고 생각이 든다.

내가 그 순간에는 알고 있던 지식과 기술들로 최적에 판단을 하고 개발을 했지만 지금와서 봐보니 아니였던 순간들도 있었고 지금 당장 Restructuring 하기에는 너무 많은 리소스를 들여야 되서 임시방편으로 일단 처리해놓은 순간도 있었다. 이처럼 개발을 하다보면 지금은 맞지만 미래에는 아닌 판단을 하게된다. 그렇기에 개발자는 기술부채에 대해 포용적인 자세로 받아들이고 기술부채가 눈덩이처럼 불어 문제를 일으키지 않도록 관리하는 것이 개발자의 역활이라는 것을 알게될 수 있는 좋은 시간이였다.