‘기술 부채’는 개발자로 있는 한 마음속에 항상 품고 고민하는 주제입니다. 기술 부채가 없는 회사는 존재하지 않습니다. 그러나 기술 부채와 마주하기에는 현실이 녹록지 않습니다.
고민 끝에 한국인 최초의 자바 챔피언이자 여러 스타트업의 CTO를 역임한 양수열 소장을 만났습니다. 이 글은 COMMIT 세미나에 앞서 양수열 소장을 만나 기술 부채에 대해 나눈 일문일답입니다. 더 자세한 이야기는 3월 COMMIT에서 들을 수 있습니다.
Q. 기술 부채란 무엇인가요?
위키백과는 기술 부채를 현시점에서 더 오래 걸리지만 더 나은 접근 방식 대신, 쉬운 해결책을 채택함으로써 발생하는 재작업 비용이라고 말합니다. 결국 기술 부채는 언제든 생길 수 있는 ‘기술적 문제’라고 할 수 있죠.
흔히 Technical Debt를 그대로 직역해 ‘기술 부채’라고 하는데, 부채라는 용어가 풍기는 분위기가 그리 긍정적이진 않습니다. 그 점이 안타까워 한 개발자가 제안한 용어가 ‘후불 코딩’입니다. 후불 코딩이라고 하면 의미가 더 명확해집니다. 코딩 후에 돈을 또 내야 한다는 것이니까요.
제가 생각했을 때는 부채 없는 조직은 없습니다. 단지 감내할 수 있는 정도를 유지하는가의 문제죠.
Q. 기술 부채는 왜 생길까요?
타임투마켓과 같은 여러 비즈니스 요인으로 인해 서비스를 급하게 만들 수밖에 없을 때도 있습니다. 그 과정에서 자연스레 기술 부채가 생깁니다. 최소기능제품(Minimum Viable Product, MVP)으로 안 만들면 좋겠지만 현실은 그렇지 않습니다. 특히 스타트업에서 그렇죠. 잘 될지 안 될지 모르는 서비스 하나에 ‘올인’하기보다는 MVP로 서비스를 빠르게 만들고 시장 반응을 살피다가 성공 가능성이 보이면 그 서비스에 주력합니다. 그때는 당연히 서비스를 처음부터 다시 손봐야 하죠.
Q. 기술 부채의 원인은 무엇일까요? 흔히 이야기하는 린과 같은 비즈니스 전략이 원인일까요?
방망이 깎던 노인이란 수필을 읽어봤나요? 수필 속 주인공이 방망이를 주문했는데 할아버지가 해가 질 때까지 깎고 또 깎느라 결국 화를 내고 방망이를 받아 집에 갔더랬죠. 그리고 방망이를 본 아내가 보기 드물게 잘 깎았다고 칭찬하자 그제야 장인을 알아보지 못했다고 후회하는 이야기입니다.
개발자들은 마치 이 수필 속 할아버지 같습니다. 장인이죠. 프로그래밍하며 항상 견고하고 변화에도 잘 대응할 수 있는 훌륭한 아키텍처를 만들고 싶어 하죠. 하지만, 비즈니스 현실은 그렇지 않습니다.
생각해 보세요. 지금 당장 써야 하는 중요한 와이셔츠를 다림질해야 하는데 못 쓴다면 그건 문제입니다. 그럴 때는 적당한 선에서 쓸 수 있게 해야 합니다. 개발자 둘이 서비스 4~5개를 만들어야 한다고 칩시다. 한정된 시간을 써서 모두를 잘 만드는 건 쉽지 않습니다. 결국, 최소한의 기능이 갖춰진 최소기능제품(Minimum Viable Product, MVP) 형태로 서비스를 개발할 수밖에 없습니다.
돈도 인적 자원도 충분한 회사는 어디에도 없습니다. 작은 회사는 작은 회사대로, 큰 회사는 큰 회사대로 항상 일이 많고 개발자는 늘 부족하죠.
Q. 리팩토링을 피할 수 없는 ‘데드라인’이 있다면 어떤 때인가요? 어떤 신호들이 나타나면 기술 부채 해결을 진지하게 고민해야 할까요?
어떤 신호가 있을 정도라면 너무 늦은 게 아닐까요? 그래서 이런 얘기들을 하죠. 부채는 못 갚아도 이자는 내고 살자고. 부채를 인식하는 게 첫째고, 둘째는 이자를 조금씩이라도 내는 게 중요합니다. 일주일에 반나절이라도 시간을 내서 기술 부채를 갚아나가는 것입니다. 부채를 마냥 키우는 게 아니라 이자는 조금씩 내면서 원금도 갚아 나가는 거죠.
Q. 기술 부채를 최소화하려면 어떻게 해야 할까요?
언젠가 고쳐야만 한다면 서비스를 복잡하게 만드는 게 좋을까요? (웃음) 당연히 단순하게 만들어야 할 것입니다. 어플리케이션 구조가 복잡하면 할수록 고치기 어려우니까요. 그러므로 개발하기 전에 최소한의 표준을 만들고 최대한 단순하게 개발하길 바랍니다. 다음 MVP를 만들 때 표준에 근접하게 빠르게 만드세요. 그러면 기술 부채를 최소화할 수 있을 겁니다.
개발 프로세스도 테일러링(tailoring, 주어진 대상에 딱 맞게 줄이거나 늘리는 것)이 필요합니다. 인원이나 타임투마켓에 맞춰서 꼭 필요한 프로세스조차 꼭 줄여서 해야 하는 피치 못할 상황이 있을 수 있습니다. 정석은 없습니다. 회사 규모나 시스템에 맞춰 가져가야 하니까요. 개발자 두 명뿐인 회사와 50명 규모의 회사가 어떻게 똑같을 수는 없으니까요.
끝으로, 개발자는 보통 문제가 무엇인지 잘 알고 있습니다. 문제는 그걸 고칠 시간이 없는 거죠. 그래서 개발자는 이런 문제에 대한 ‘부채 의식’을 항상 가지고 있습니다. 개발자가 기술 부채라는 이자를 평소에 조금씩 갚아나가도록 의사결정권자가 결정을 해줘야 합니다.
Q. 기술 부채를 정기적으로 처리하도록 의사결정권자를 설득하는 게 쉽지는 않을 듯합니다.
기술 부채나 보안 같은 것은 비즈니스에 당장 도움이 되지 않습니다. 그래서 보통 회사에서는 이 부분을 등한시합니다. 당장 비즈니스에 도움이 안 되는데 계속 비용은 발생하거든요. 그렇다고 이 부분을 계속 눈 감고 가야 할까요? 아닙니다. 의사결정권자가 기술 부채의 심각성을 깨닫도록 설득해야 합니다. 기술 부채에 대한 올바른 정보를 계속 이야기하고 위험성을 인지시켜야죠.
그렇다면 누가 이 일을 해야 할까요? 보통 이 일은 가장 직급이 높은 개발자가 합니다. CTO일 수도 있고, 어떤 회사는 팀장일 수도 있겠죠. 그리고 의사결정권자와 깊은 신뢰를 이루는 관계여야 합니다. 그래야 설득도 가능하죠.
Q. 기술 부채와 관련해 기억에 남는 일은 없나요?
금융권에는 당장 동작은 해도 굉장히 오래된 레거시 코드가 많습니다. 한 파일이 2,000줄이 넘는 그런 코드죠. 이런 코드는 섣불리 손대기가 쉽지 않습니다. 그런 코드를 외면하다가 결국, 장애가 터진 적이 있었습니다. 백오피스에서 쓰는 코드라서 심각한 장애는 아니었지만, ‘거래 시스템’이었다면 엄청난 금전적 손실을 입었을 테죠. 2주 동안 풀타임으로 개발자를 투입한 끝에 문제를 해결할 수 있었습니다. 기술 부채에 대한 이자를 톡톡히 낸 셈이죠.
모른다고 그냥 놔두다 보면, 잘 모르기 때문에 문제가 생겨도 대처가 안 됩니다. 생판 보지도 않았던 코드를 장애가 나서 그제야 본들 금방 해결할 수 있을까요? 그렇기에 매일 조금씩, 단 몇 줄의 코드라도 살피고 테스트 케이스를 만들며 분석해야 합니다. 그래야 장애가 발생해도 더 빨리 원인을 찾아 대응할 수 있습니다.
Q. 개발자, 자신의 성장은 어떻게 해야 할까요?
스스로 ‘피드백 루프(feedback loop)’를 만들라고 말하고 싶습니다. 저는 JCO(한국자바개발자협의회) 개발자 커뮤니티 운영에 10년 동안 참여했습니다. JCO에서 뛰어난 엔지니어를 여럿 만났죠. “형 나 이거 하려는데… 그렇게 하면 안 돼”와 같은 대화 속에서 성장할 수 있었습니다. “리눅스, 유닉스에서 사용 가능한 스레드 개수가 달라. 그렇게 설계하면 안 돼” 같은 지식은 인터넷 어디를 찾아도 나오지 않습니다. 그런 지식을 얻을 수 있는 곳이 개발자 커뮤니티입니다. 질문만 하면 바로 나오거든요. 저는 책으로 배운 것보다 주위 개발자들과 얘기하며 그들의 경험을 얻고 성장했습니다. 점점 보는 눈이 달라질 겁니다. 내가 이만큼 보면 그 사람은 더 보고 있거든요.
또, 세미나 컨퍼런스에서 정말 많이 발표했습니다. COMMIT에서 발표하는 이유도 그 때문입니다. 난 받은 게 있으니까. 받은 만큼 돌려줘야죠. 준비하면서 공부도 많이 되고요.
Q. 시니어 개발자로서 ‘좋은 개발자’가 되는 길을 알려주신다면요.
좋은 개발자가 되려면 실패를 많이 해봐야 합니다. 그건 가르친다고 되는 게 아니고 시간이 필요합니다. 시간이 지나서야 알게 되는 것이 있습니다. 사실이나 정보는 바로 취할 수 있지만, 정보 뒤에 있는 ‘인사이트’는 보기까지 시간이 걸립니다.
결국 많이 만들고 해봐야 합니다. 자바뿐 아니라 파이썬도 해봐야죠. 저는 다른 언어도 배우면서 자바를 더 깊게 이해할 수 있었습니다. 다른 언어를 배우면서 언어의 콘셉트를 더 깊이 이해할 수 있었죠. 이 언어는 이러한 목적에 의해 이렇게 만들어졌구나. 모든 목적을 충족하는 언어는 없구나. 자바가 좋은 경우, 파이썬이 좋은 경우가 다 다르구나. 적재적소에 언어를 선택해야 해야 함을요.
한 가지 더 당부하고 싶은 것은 좋은 동료와 일하라는 것입니다. 책이나 웹에 있는 정보는 머릿속에 있는 정보의 1/100도 안 됩니다. 누군가의 조언이 성장에는 무척 중요합니다.
Q. 이번 COMMIT에서 개발자들에게 어떤 이야기를 꼭 전하려 하나요?
기술 부채를 나쁘게 보지 말았으면 합니다. 기술 부채는 굉장히 당연하고 자연스러운 것입니다. 그렇다고 기술 부채가 남발되어서는 안 됩니다. 기술 부채를 경험했는데, 새 프로젝트에서 또다시 반복해서는 안 됩니다. 문제라고 인식했으면 개선해야죠. 기술 부채가 반복되지 않도록 회고와 같은 안전망을 만드는 노력이 필요합니다. 느리더라도, 그렇게 한 발 한 발을 나아가야 합니다. 똑같은 기술 부채를 계속 만드는 팀에게 미래는 없습니다.
Embrace Change라는 말이 있습니다. 요구사항이 바뀔 수 있다고 가정하고 변화에 잘 적응할 수 있게 시스템을 설계하라는 말입니다. 기술 부채도 그렇게 받아들이기 바랍니다.
Edit Snow Design Lil
