언젠가는 돌아온다

외교관, s1 e1, 넷플릭스

 어느 날 아침 이란 연해에서 영국 함대는 로켓 공격을 받게 되고, 아프가니스탄의 대사로 발령될 계획이었던 케서린 와일러는 하루아침에 주영국 미국 대사의 자리로 이동하게 된다. 갑작스럽게 영국에 도착한 케이트는 대사 자리에 대한 공식적인 등록 처리를 위해서 공관에 간다. 공관에서 영국의 외무장관과 인사하게 되고 외무장관의 인도로 영국 총리와 대화를 하게 된다. 대화를 마치고 나온 케서린은 공관의 복도에서 부관(스튜어트)과 대화를 나눈다.

캐서린: (영국 총리가) 대통령님 전화로 질겁했대요. 테헤란을 폭격한다며 방송에서 위협이라도 하셨다가 진짜로 싸움 날까 봐요.

스튜어트: 그만큼 관심 있다는 대통령님의 표현이겠죠.

캐서린: 조용히 계셔 달래요. 분위기는 영국이 잡아야죠. 

스튜어트: 그럼 개넌(미국무장관)한테 맡기세요.

캐서린: (영국 총리는) 개넌 말고 나더러 처리하래요.

스튜어트: 그게 문제네요.

캐서린: 텔아비브에서 핼이 개넌한테 딱 이랬죠. 불쑥 나타나선 미국 대표단을 빈둥대는 꼴로 만들었어요.

스튜어트: 근데 대사님이 총리실로 쳐들어가신 게 아니라 영국 외무 장관이 자진해서 대사님을 찾았잖아요.

캐서린: 과연 그럴까요?... 핼 짓이죠.

스튜어트: 정말요?

캐서린: 네.

스튜어트: 설마 남편(핼)분께서...

캐서린: 기념사진이나 찍으려던 나를 총리 품으로 떠밀었냐고요? 맞아요.

스튜어트: 그렇군요, 대단하네요.

캐서린: 지금은 대단해 보여도 끝내 대가가 따르죠.

스튜어트: 어떤 대가요?

캐서린: 닥쳐 봐야 알아요. 닥치고 보면 확실히 알고요.

 핼은 문제를 빠르게 해결하는데 능하다. 마치 마법같이, 손가락을 한번 휘두르고 박수를 치고 코를 문지르면 문제를 해결한다. 하지만 그의 문제 해결 방식은 정말이지 확실한 부채를 만든다. 캐서린은 남편이자 유명하고 유능한 외교인인 핼의 그러한 능력이자 저주를 걱정한다. 이미 핼은 과거에 거대한 문제를 해결했지만 그만큼 거대한 업보를 만들었다. 마찬가지로, 이번에도 분명히 그 빚은 돌아올 것이며 어떻게 다가올지 알 수 없기 때문이다.

 비즈니스에서도, 당연하겠지만, 부채가 있다. 금융과 자산 이외에도 부채가 존재하는데, 일명 기술 부채라고 하는 것이다. 기술 부채는 소프트웨어 개발에서 품질을 희생하면서 단기적인 이익을 얻기 위해 사용한 코드, 설계, 또는 아키텍처적 결정을 말한다. 즉, 프로젝트를 빠르게 완료하거나 기능을 빨리 구현하기 위해 깔끔하지 않거나 비효율적인 코드를 작성하는 것이 기술 부채이다. 이는 장기적으로 유지보수 및 확장성에 문제를 일으킬 수 있으며, 나중에 더 큰 비용으로 이를 해결해야 하는 상황을 만들게 된다.

 기술 부채의 원인은 품질보다 단기적 이익을 추구하는 결정이다. 이러한 결정으로 비롯된 기술적 원인은 다음과 같다

1. 미흡한 설계  

 시스템이 성장할 것이라는 가정 없이 초기 설계를 너무 단순하게 하거나, 확장성을 고려하지 않은 설계는 기술 부채이다. 이 경우, 시스템이 커질수록 수정과 유지보수가 점점 더 어려워진다. 또한 설계에 대한 고려가 부족해 모듈 간의 의존성이 과도하게 복잡하면 시스템의 수정이나 확장이 어려워진다; 의존성 관리가 제대로 되지 않으면 부채가 쌓인다.

2. 비효율적인 코드 작성  

 코드 표준이나 베스트 프랙티스를 따르지 않으면 코드의 가독성이 떨어지고, 다른 개발자들이 이해하기 어렵다. 이는 유지보수 시 더 큰 부담으로 작용한다. 또한 변수나 설정을 코드에 직접 하드코딩하면 코드의 유연성이 떨어지며, 변경 시 많은 부분을 수정해야 하므로 기술 부채 발생한다. 

3. 테스트 부족  

 코드 작성 시 충분한 단위 테스트나 통합 테스트가 작성되지 않으면, 이후 문제 발생 시 문제를 조기에 발견하기 어렵다. 테스트가 적으면 추후 변경이 있을 때 오류를 방지할 수 없기 때문에 부채가 늘어난다. 추가적으로 테스트가 자동화되지 않은 경우, 수작업으로 테스트를 진행하는 과정에서 오류가 발생하거나 테스트가 누락될 수 있다. 따라서 테스트를 자동화하는 것은 부채를 경감하는데 도움을 준다.

4. 반복되는 임시 해결책  

 시스템 문제를 임시방편으로 해결하고 근본적인 원인을 해결하지 않으면, 시간이 지나면서 문제의 복잡성이 커지고 기술 부채로 누적된다. 또한 단기적인 해결을 위해 빠르게 만든 패치는 이후 유지보수 시 많은 문제를 일으킬 수 있다.

 기술 부채는 유지보수 비용의 증가, 시스템과 서비스의 확장성의 저하, 버그 발생의 가능성 증가 등과 같은 비용을 요구한다. 부채를 관리하지 않으면, 부채의 증가와 함께 부채에 의한 이자 비용 등이 발생한다. 그리고 이러한 부채는 점점 커져서 추후에는 기술 파산이라는 파국을 맞이하게 된다. 기술 파산은 언급했듯 부채가 너무 커져서 시스템의 성능, 안정성, 유지보수성 등에 무시할 수 없는 심각한 영향을 미치는 것을 의미한다. 이러한 기술 파산을 막기 위해서는 기술 부채를 적절히 관리해야 하며, 관리하기 위해서는 다음과 같은 방법들이 있다.

  1. 기술 부채 상환

 기술 부채가 어느 정도 쌓이기 전에 이를 인지하고 점진적으로 해결하는 계획을 수립해야 한다. 정기적인 리팩토링, 코드 개선, 테스트 보강 등을 통해 기술 부채를 상환한다. 가능하면 가장 큰 영향을 미치는 부분부터 리팩터링 하는 것이 중요하다. 비즈니스 핵심 기능에 영향을 미치는 코드부터 시작하여 부채를 줄여 나가는 것이 좋다.

  2. 레거시 시스템 대체

 구식 기술 스택이나 레거시 시스템이 문제라면 이를 현대적인 기술로 점진적으로 대체하는 것이 필요하다. 이는 대규모 프로젝트가 될 수 있지만, 장기적으로 시스템 안정성과 확장성을 보장해 줄 것이다.

  3. 지속적인 코드 품질 관리

 코드 리뷰, 자동화된 테스트, CI/CD 파이프라인을 도입해 코드 품질을 지속적으로 관리하고, 새로운 부채가 쌓이지 않도록 방지한다. 기술 부채를 추적하고 이를 정기적으로 모니터링함으로써, 누적된 부채를 적시에 해결할 수 있는 시스템도 관리를 위해 필요하다. 이를 통해 기술 부채가 기술 파산으로 이어지지 않도록 방지할 수 있다.

 부채 또한 자산이다. 따라서 부채가 무조건적으로 나쁜 것은 아니다. 기술 부채도 마찬가지이다. 단기적인 이익이 품질에 부채와 같은 영향을 줄 수 있지만, 이러한 단기적 이익이 추후에 부채보다 더 큰 이득을 준다면  부채를 알맞게 관리한다고 볼 수 있을 것이다. 그러므로 중요한 건 부채 그 자체에 부정적이기보다는, 부채로 인해서 파산하지 않도록 관리하는 것이다.

 또한 기술에만 부채가 있는 것은 아니다. 인사, 영업, 홍보, 유통 등 모든 영역에서 부채는 존재한다. 이러한 부채를 적절하게 관리하는 지혜가 필요하다. 왜냐하면, 캐서린 와일러가 말했듯이, 결국 돌아오기 때문이다. 부채는 어떻게든 돌아오고, 맞이하고 나선 정체를 알게 될 것이다.