brunch

라이킷 10 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 안영회 습작 Nov 14. 2022

기술 부채는 낮은 코드 품질에 대한 것이 아니다

베터코드 인사이트의 시작 7편

<기술 부채는 무엇인가?> 편을 페이스북에 올렸더니 페친님이 이런 코멘트와 함께 공유를 해주셨다.

내가 생각하는 기술 부채와 조금은 다른 뜻으로 기술 부채를 사용하셨지만, '적어도 두세 번은 써야 한다'는 말 때문에 중국에서 일하던 때가 생각났다.

다시 개발하라

2016년에 있었던 일인데, 2017년에 CTO님이 증언한 기록이 있다. 동작하는 코드를 만든 후에 내가 내린 미션은 다시 개발하라는 지시다. 조금 부연을 하면, 데모 수준으로 구현된 결과물을 보며 나는 개발자가 완전하게 이해하지 못했다고 판단했다. 나는 그에게 미시적인 오류를 지적하는 대신에 총체적으로 이해하길 바랬다. 그래서 다시 만들면서 스스로 배우기를 기대했다. 같은 기능을 가장 많이 만든 쿠폰 서비스의 경우에는 6번을 다시 개발하라고 했고, 그렇게 만든 서비스가 실제로 (중국의) 백화점에서 쓰였다.

나는 그 과정에서 개발자가 다양한 피드백을 받는다고 믿었다. 통역을 통해야 하는 중국인 개발자는 한국인 보스가 왜 저럴까 고민할 것이다. 그리고, 납득하기 위해 질문을 할 것이다. 그 후에 내가 하는 말을 자기 나름의 잣대로 이해할 것이다. 나는 바뀐 부분에 대해서 피드백을 할 것이고, 개발자가 일부를 고쳤는지 전체를 다시 개발했는지 내가 알 바가 아니다. [1] 다만, 나는 개발자가 '이해하고 짠 것이라고 느낄 때까지' 다시 개발하라고 말했다.

그래야, 릴리즈가 된 이후 수정을 요청할 때 그는 자신이 무엇을 해야 하는지 이해할 것이다.

기술 부채는 낮은 코드 품질에 대한 것이 아니다

놀라운 우연이다. 최근에 Vaughn Vernon이 기술 부채는 낮은 코드 품질에 대한 것이 아니라고 말했다. 도메인에 대한 이해가 되지 않았는데 어쩔 수 없이 배포되어서 발생하는 것이라고 정교하게 말했다. 그 이후에 벌어지는 교훈에 따라 재구성(refactoring)하며 부채를 갚는 일이라고 주장한다. 나는 그의 말에 100% 동의한다.

기술 부채는 사고 대응에 긴 시간이 걸리게 한다

정교한 규칙은 아니지만 경험적으로 나는 개발자가 구동 방식을 이해하면 큰 사고는 나지 않는다고 믿는다. 대체로 내가 짜지 않은 코드를 맡는 개발자들로 이뤄진 조직에서 장애 복구에 오랜 시간이 걸리거나 수정에 예상 밖의 긴 시간이 요구된다.

10/29 참사 때 무책임한 고위공직자의 발언에서 낯익은 단어가 다른 맥락에 쓰이는 기사를 보았다. 참사라는 표현을 감추기 위해 외신 기자들에게 우리말 사고를 의미하는 Incident 란 표현을 쓴 모양이다.

소프트웨어 공학에 Incident Management라는 개념과 관리 기법이 있다. 나는 한때 이를 정교하게 다루는 IT 프로젝트의 설계 과정에 잠시 참여한 일이 있다. 그때 기억을 떠올리는 기사 제목을 만난 것이다. 사고(Incident)가 참사로 커지지 않기 위해 신속한 조치가 필요하다.

체계적인 노력만이 참사를 막을 수 있다

기술 부채 관련 발표를 준비를 하다가 찾은 기사에서 부채를 줄이기 위한 활동들을 구체적으로 제시하고 있다. 외국 기자들에게 비난의 대상이 된 총리가 모르는 일은 사고 관리(Incident Management)는 탁상공론이 아닌 디테일의 축적에서 나온다는 점이다.

기술 부채 해결도 정확히 같은 성격의 일이다.

기술 부채는 IT가 비즈니스에 미치는 영향에 대한 이해 부족 문제

지난 기술 부채 관련 발표에서 나는 기술 부채는 개발자가 알아서 해야 할 문제로 치부해서는 해결할 수 없다고 주장했다. 나는 오늘도 인터넷 기업 대표를 만나 기술 부채 문제를 조금 더 심각하게 다루기를 바라는 마음으로 회의를 했다. 그리고, 오전에는 기술 부채 때문에 차세대 프로젝트(전면 재구축)를 했는데 역시 기술 부채 문제로 오픈이 연기된 상황에서 도움을 요청하는 기업에 우리가 무엇을 해줄 수 있는가 논의를 했다. 이런 상황은 이미 참사에 가깝다.