기술부채에 대하여.

개발자는 좋은 소프트웨어를 만들기 위해서 노력해야 한다. 그렇다면 좋은 소프트웨어라는 것은 무엇일까?
견고한 아키텍처와 잘짜여진 코드? 물론 맞다. 많은 사용자가 사용하는 소프트웨어가 견고한 아키텍처를 가져서 안정적이고 잘 짜인 코드로 기능의 개선이나 확장이 용이하면 잘 만들어진 소프트웨어다.

다만 소프트웨어 자체의 품질 이전에 결국 소프트웨어는 사용자에게 중요한 가치를 제공 할 수 있어야 한다. 이것을 다른 사람들은 비즈니스로 표현하던데 좀 더 간단히 말하면 그냥 목적이다. 해당 소프트웨어를 통해서 이루고자 하는 목적에 적합한 소프트웨어가 좋은 소프트웨어다. 그게 잘 만들어졌다면 더 좋고, 그럼 잘 만들어지고 좋은 소프트웨어가 된다.

이건 굳이 개발이 아니라도 당연한 것이다. 어떤 행위는 특정 목적에 부합해야하고 그것을 가장 충실히 실현해야 한다. 그 외 부가적인 요소들 역시 챙기면 챙길수록 더 좋은 목적을 이룰 수 있다. 당연하지만, 완벽 할 수 록 완전 할 수 록 좋다. 그게 가능하다면 말이지.

그러나, 알다시피 현실은 그렇게 넉넉하지 않다. 무엇인가를 얻고자 한다면 그것에 자원을 투입해야한다. 그리고 그 자원은 항상 유한하다. 그렇기에 적합한 목표를 정하고 그를 실현시키기 위해서 적절한 계획을 세우고 자원을 소모해서 일을 진행한다. 그리고 이를 효율적으로 하기 위해서는 관련 지식이 어느 정도 필요하다.(개인적으로는 어릴 때 자기 관리를 효율적으로 하고 싶어서 관련 전공서적들을 조금 읽어본 적이 있다.)

그리고 그런 경제나, 경영학적인 개념들을 소프트웨어 개발에 접목시켜서 나온 개념중 하나가 기술 부채이다.
물론 내가 해당 단어의 근원을 직접 세세하게 찾아본 것은 아니다 보니 추측에 가깝지만 어쨌든 중요한 것은 그래서인지 기술 부채라는 개념에도 경제나 경영학적인 관점으로 접근이 가능하다는 점이다.

부채도 자산에 해당한다. 기술 부채 역시 마찬가지다. 부채가 일정 비율의 이자 지출을 늘리는 대신 활용 가능한 리소스증가를 가져오듯이 기술부채 역시 일정 비율의 개발 리소스 지출을 늘리는 대신 목적을 달성하기 위해서 시간을 단축한다. 모든 점을 고려한 완벽한 소프트웨어 대신 조금 미흡하더라도 유효한 소프트웨어를 얻는다 정도로 표현할 수 있다.

부채가 고정지출을 늘려서 자산의 증식을 가져온다면 기술 부채는 리소스의 고정 지출을 늘려서 소프트웨어 규모나 기능 등에서 증식을 가져온다.(이걸 증식이라 표현해도 상관없으려나..?) 사실 잘 만든 소프트웨어의 경우 당연히 그만한 리소스(시간, 좋은 개발자 등)가 투입되어야 한다. 하지만 모든 경우에 잘 만든 게 필요하지는 않다. 그저 기본적인 기준선을 충족시킨 효율적인 가성비가 더 적절한 경우도 있는 것이다.

개발의 경우 그런 것을 고려한 방법론이 많다. 애자일이라던가 MVP라던가 사실 좋은 코드를 작성한다는 것. 즉, 클린 코드라는 것도 애초에 유지보수를 위함이다. 현실적으로 항상 최선의 상태로 남아 있을 수 없다는 것이 문제이기도 할 것이고 결국 소프트웨어라는 것은 도구이기에 그렇기도 하다. 목적을 충족시키기 위해서 목적에 맞춰서 최적화되어야 한다는 점이 결국 그런 방향성을 가지게 되었다. 개발은 여타 예체능(아닌 영역도 있지만)과 다르게 개발 자체가 목적이 되지 않는다.

물론 개인적으로 그런 목적을 가질 수 있겠지만 그것은 개인적인 목적인 것이지 개발이라는 활동 자체가 가지는 목적은 아니다. 그렇다면 기술 부채가 생기고 그걸 관리해야 이유는 무엇일까? 사실 원론적인 얘기로 들어가면 결국 개발자 실력이 문제이다. 여러 환경과 개발을 하는 사람들의 실력이 원인이 되어서 기술 부채라는 것이 생겨난다.

불가능한 일정, 불가능한 환경, 불가능한 동료, 불가능한 도메인 등 여러 환경에서 목적에 필요한 기능을 최소한의 기간으로 모든 것을 만족해서 만들어 낼 실력이 없기에 보통 기술 부채를 만든다.(그런 게 인간이 가능할까?)

사람은 늘 성장을 한다. 그리고 특정 목적을 완벽히 수행하는데 현 수준에서 실력이 부족할 수 있다. 그럴 때 기술 부채가 생긴다. 최신 기술 스택을 목적을 만드는 게 쓸 능력이 부족할 수 도 있고, 일정이 부족해서 구조를 견고하게 짤 수 없을 수 도 있다. 모든 기능을 최선을 다해서 할 수 없을 수 있다. 이럴 경우 기술 부채를 만든다. 가장 핵심 되는 기능을 제외한 기능을 포기하거나, 이상적인 아키텍처에서 추상화 레이어 몇개를 제외한다거나, 추후에 잘 만든 소프트웨어가 될 수 있게끔 장애가 될 요소가 아닌 점들을 포기해서 기술부채를 만들고 기능을 개발한다. 이건 사실 일종의 MVP를 만드는 개념에 가깝다. 추후 애자일 가능한 선에서 중요한 우선순위를 먼저 실현시키는 것이다.

또는 자신의 실력이 아닌 동료의 실력이 문제가 될 수 있다. 짧은 러닝 커브로 해결할 수 있는 문제라면 동료의 실력을 끌어올려서 좋은 품질의 소프트웨어를 만들어 내는 게 가장 베스트다. 그런데 그럴 시간도 없다면? 그리고 모종의 이유로 그럴 수 없다면?(적성이 부족한 동료) 그럼 그 동료의 러닝 커브에 맞는 수준의 소프트웨어를 설계하고 기획하는 게 맞다.
보통 그래서 좋은 회사들은 교육기간을 둔다거나, 실력을 검증하는데 리소스를 투자한다.

혼자서 가능한 문제였으면 협업이 필요가 없었을 것이고, 협업이 필요하다면 최소한도의 협업이 되도록 프로젝트를 설계할 필요가 있다. 적절히 진행과정에서 성장하는 것까지 고려해서 적절한 수준의 프로젝트선에서 기술 부채에 타협한다. 동료와 스터디하면서 리소스를 소모하고 자신의 업무 +@로 동료의 업무까지 같이 할게 아니라면 말이다. 협업이 불가능할 정도 수준이라면 그게 아무리 좋은 것이라도 적절치 않다고 볼 수 있다.

또는 목적상 유지보수가 필요 없을 수 있다. 이럴 경우 만약의 경우만 고려한 선까지만 신경 써서 기술 부채를 만들고 개발하면 된다. 과제, 학습 목적이면 특정 주제에 집중하는 게 좋고 그 외 요소들은 적절히 덜어낸다. +@를 고려한다 할지라도 해당 프로젝트에 투자하는 리소스가 효율적인가를 간단히 따져 보면 된다. 효율적이지 않다면 그럴 리소스를 다른데 투자하는 게 합리적이다. 사실 이런 경우에 다시 해당 프로젝트를 건드는 경우는 거의 없다. 그리고 그럴 경우 기존 소프트웨어를 재활용하기보다는 차라리 다시 만드는 게 더 효율적인 경우가 많다.

또는 일정이 부족한 경우가 있을 수 있다. 아예 불가능한 게 아니라면 애자일스럽게(^^) 디테일을 다 덜어내고 일정을 맞추는 게 맞을 수 있다. 추후 유지보수 가능하게 개선해 나갈 수 있는 선에서 말이다.

보통 이런 것들을 비즈니스를 고려하는 것이라고 표현하고 그렇게 하라고 주장하는 것 같다. 개인적으로는 딱히 개발에만 한정된 영역의 문제가 아니라서 신입시절부터 고려했던 내용들이기도 하다. 솔직히 비즈니스를 고려하라는 것보다는 목적에 충실하라가 더 알맞지 않을까? 싶다.

목적을 충족시키지 못하는 소프트웨어는 잘 만든 소프트웨어라 할지라도 좋은 소프트웨어라고 보기 힘들다. (물론 교육용 등 다른 목적을 충족시킬 수는 있겠지만) 목적을 잘 충족시킨다면 해당 소프트웨어는 잘 만든 소프트웨어는 아닐지라도 좋은 소프트웨어다. 그리고 이를 위해서는 적절한 수준의 엔지니어링이 필요하다. 이를 보통 오버 엔지니어링, 언더 엔지니어링 등 개념을 들어서 설명하는데 그냥 여러 상황을 모두 고려해서 목적에 적절한 수준의 설계를 한다는 것 정도로 표현할 수 있다.

소프트웨어는 본래 점진적 개선을 통해 품질을 높인다. 그러니 적절히 기술 부채를 관리하면서 목적을 충족시키면 된다. 그리고 궁극적으로 잘 만든 소프트웨어를 지향하면 된다. 높아진 요구(목적)에 맞게 따라갈 수 있도록
기술 부채는 잘 활용하면 도움이 된다. 다만 리소스 지출 늘 개발에 영향을 주기에 적절히 관리할 수 있어야하고, 관리 할 수 없다면 안 만드는 게 제일 좋은 방법이다.