이상과 현실

기술부채라는 말이 있다. 간단히 말하면, 프로젝트 마감날짜를 지키기 위해 구현 외의 모든 것을 미루는 행위다.

개인적으로는 테스트 케이스를 작성한다거나, 리팩토링을 한다거나 하는 부분에서 기술 부채를 민감하게 느끼는 편이다. 리팩토링의 경우 자잘한 리팩토링은 널리 알려진 방식처럼 하드코딩 후 중복제거 라는 방법으로 어느 정도는 하는 편이지만, 테스트 케이스 작성은 시작하기가 쉽지 않은 편이다. 또한 아키텍쳐 변경 수준이나 프로젝트의 디렉토리 구조를 뜯어고쳐야 하는 수준의 리팩토링 역시 할 일 목록에만 존재할 뿐 실제로 수행하는 경우는 드물다. 수많은 개발 공학 책에서 ‘견고한 앱’의 중요성을 이야기해도 막상 닥쳐오면 ‘작동하는 앱’이 먼저라는 생각이 든다.

이런 이상과 현실 사이에서 고민하는 개발자들이 많을 것이라 생각한다. 나 또한 그렇고.

신뢰자본

그러다가 얼마 전 개발자 회의에서 재미난 개념을 접했다. 신뢰자본 이라는 것인데, 자잘한 개발 업무를 수행하며 신뢰자본을 습득하면(마치 게임같이) 축적한 신뢰자본을 토대로 자신이 원하는 업무를 주도적으로 진행할 수 있다는 것이다.

실제로 회의 때 나왔던 예시로는 스타일링 수정부터 코딩 컨벤션을 맞추는 등의 작은 업무를 안정적으로 수행하며 신뢰자본을 적당히 모았다가, GraphQL을 프로젝트에 도입하여 전통적인 REST API를 대체한 경우였다.

REST API는 자료 찾기도 쉽고 클라이언트 프로그래밍(네이티브 앱, SPA 등)이 세분화된 요즘들어서는 거의 표준으로 자리잡은 API 형태일텐데 그것을 GraphQL로 바꾼다면, 당연히 해당 프로젝트를 주도하는 개발자는 프로젝트 내에서 거대한 존재감을 드러내는 위치에 있어야 한다. 또한 CTO를 설득할 수 있는 커뮤니케이션 스킬도 보유하고 있어야 한다. 이래저래 모험적인 시도이기 때문이다.

그런데 신뢰자본을 모으면 누구나 그런 모험을 저지를 수 있다면?

개발자라면 정말 꿈만 같은 상황이 아닌가. 해커톤에 나가거나 사이드 프로젝트를 진행하는 개발자들을 봐도 알 수 있듯 누구나 자신만의 무언가를 만들고 싶어하니까.

그리하여, 이 개념에 대해 좀 더 고민해보며 앞으로의 프로젝트 업무를 색다른 감각으로 해보고자 한다.

이래서 공학에도 인문학적 접근이 필요하다는 걸까.