기술적 빚과 프로그래머의 실력

임백준

'기획자와 프로그래머가 서로를 이해하는 키워드는 시간'이라는 글을 흥미롭게 읽었다. 현장에서 사용되고 있는 소프트웨어에서 발생한 버그를 수정하거나 새로운 기능을 추가할 때 기획자와 프로그래머 사이에서 발생하는 의사소통 문제를 다룬 내용이다.

현장에서 발생한 버그를 수정하거나 사용자가 원하는 새로운 기능을 더하는 일을 최대한 빠르게 하기 바라는 기획자의 의도와 시간이 걸리더라도 코드를 체계적인 방식으로 수정하고 싶어 하는 프로그래머의 욕망은 충돌을 일으킬 수밖에 없다. 강연은 이러한 갈등을 합리적으로 조정하여 공동의 목표를 달성하는 방법을 설명한다.

강연이 제안하는 해결책은 간단하다. 거대한 시스템을 구축하기를 희망하는 프로그래머의 욕망을 기획자가 잘 이해하고 그 욕망을 억누르지 않는 방식으로 대화하라는 것이다. 그런 방식을 사용하면 프로그래머가 기획자 자신의 의도를, 즉 임시방편적인 하드코딩 방법을 동원해서라도 지금 당장 코드를 수정하라는 자신의 의도를 받아들이게 만들기 쉽다고 설명한다.

기획자가 프로그래머에게 어떤 작업을 요청했을 때 그가 “안 돼”라고 말하는 것은 사실 “시간이 부족해서 안 돼”라고 말하는 것이라고도 설명한다. 그렇다고 해서 시간을 더 줄 수는 없으니까 프로그래머의 욕망을 인정하는 것처럼 말하면서 조심스럽게 자신의 의도를 관철하라고 조언한다. 무조건 작업을 요구하는 것이 아니라 지금은 일단 하드코딩을 해서라도 코드를 수정하면 나중에 정상적인 코드를 작성할 수 있는 시간을 주겠다고 약속을 하라는 것이다.

나는 물론 이러한 주장에 동의하지 않는다. 강연이 이야기하는 기획자와 프로그래머 사이의 오해와 갈등은 새로운 것이 아니며 소프트웨어 엔지니어링의 역사, 혹은 엔지니어링 일반의 역사가 시작된 이래로 항상 있어온 일이다. 엔지니어가 시간의 압박 속에서 타협을 했을 때, 즉 하드코딩과 같은 험한 지름길을 택하면서 정상적인 경로에서 이탈했을 때 그 엔지니어는 미래의 엔지니어에게 부채를 안기는 것이다. 와드 커닝햄(Ward Cunningham)은 일찍이 1992년에 이러한 부채를 “기술적 빚technical debt”이라는 적확한 표현에 담아낸 바 있다.

그리고 2003년에 마틴 파울러는 자신의 블로그에서 이렇게 말했다.

“기술적 빚이라는 표현은 이러한 문제를 설명하기 위해서 와드 커닝햄이 만들어낸 놀라운 비유다. 이러한 비유에 의하면 빠르고 지저분한 임시방편은 실제 빚과 닮은 기술적 빚을 초래한다. 기술적 빚은 실제 빚과 마찬가지로 이자를 발생시킨다. 빠르고 지저분한 방식이 만들어놓은 시스템을 대상으로 작업을 할 때 (지저분하기 때문에) 추가적으로 들여야 하는 노력과 시간이 그러한 이자에 해당한다. 우리는 계속 그러한 이자를 지불하면서 살아갈 수도 있고, 리팩토링을 통해서 지저분한 설계를 바로잡아 원금을 갚을 수도 있다. 원금을 갚으려면 돈이 들지만, 앞으로 이자를 내지 않아도 되기 때문에 원금을 갚는 것이 장기적으로 이익이 될 수 있다.”

파울러는 계속해서 이렇게 말했다.

“빚을 그때그때 갚아 나간다면 약간의 빚을 얻는 것이 개발속도를 빠르게 만들어줄 수 있다. 여기에서 빚을 갚는 것은 코드를 다시 작성해서 바로잡는 것을 의미한다. 그렇지만 빚을 제때 갚지 않으면 위험한 상황이 초래된다.”

하드코딩과 같은 기술적 빚이 나쁜 이유는 하드코딩은 필연적으로 다른 하드코딩을 부르고, 버그도 부르고, 체계적인 테스트 과정을 방해하며, 무엇보다도 하드코딩을 바로잡을 수 있는 시간이 결코 오지 않기 때문이다. 마지막 항목이 중요하다. 프로그래밍 세계에서는 일단 빚을 지면 그걸로 끝이다. 원금을 갚을 수 있는 날은 결코 오지 않는다.

생각해보라. 프로그래머가 필요로 하는 시간을 주지 못해서 하드코딩을 하라고 부추기는 기획자가 어떻게 더 많은 시간이 들어가는 원금 갚기를 허용할 수 있겠는가. 나중이 되면 그때대로 시급하게 해야 할 일이 산적해 있을 것이고, 정상적으로 필요한 시간마저 부족해서 또 다른 형태의 하드코딩이 요구되고 있을 것이다. 빚만 계속 늘어나는 것이다. 원금을 갚는 것은 코드 자체의 품질이 더 이상 의미가 없어지는 날, 즉 소프트웨어 자체의 시장성이 사라지는 때가 오지 않으면 불가능하다. 이렇게 줄지 않고 늘어나기만 하는 빚이 초래하는 부담과 고통은 고스란히 프로그래머의 몫이다.

“다만 프로그래머 입장에서 하드코딩은 미래를 팔아서 현재를 사는 것이기 때문에 거부감을 가지는 프로그래머가 굉장히 많을 겁니다. 그때 그 거부감을 줄이는 좋은 방법이 ‘이번만’과 ‘나중에’입니다. 이 두 가지만 기억하시면 여러분도 프로그래머가 하드코딩을 하게 만드실 수 있습니다.”

의사소통의 개선을 통해서 공통의 목표를 달성한다는 좋은 취지에서 나온 말이겠지만, 상당히 놀라운 발상이다. 화자의 진정성과 무관하게 ‘이번만’이나 ‘나중에’와 같은 말은 강이 없는 마을에 다리를 놓겠다는 정치인의 공약과 마찬가지일 수밖에 없다. 프로그래머라면 누구나 알고 있는 사실이다. 그런데 그런 공허한 약속을 들으면 프로그래머가 ‘하드코딩’을 하도록 만들 수 있다니, 정말 진심일까? 그런 레토릭은 의사소통을 돕는 것이 아니라 장기적으로 진정성 있는 의사소통이 이루어지는 것을 방해하는 감언이설에 불과하다.

사용자 요구사항을 취합하고 정리하는 기획자가 ‘하드코딩’과 같은 구체적인 개발방법에 개입하는 것은 위험천만한 월권이다. 코드를 어떤 식으로 수정할지에 대해서 결정하는 것은 프로그래머 자신이다. 기획자는 요구사항을 정확하게 포착하고, 그것이 어느 정도의 우선순위를 갖는지 설명하고, 얼마나 촉박하게 요구되고 있는지에 대해서 최선을 다해서 설명을 하면 된다. 나머지는 프로그래머의 판단에 맡겨야 한다. 그렇게 하는 것이 진정한 의사소통이다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.