외주 개발 상담을 다니다 보면 유독 기술 용어를 장황하게 늘어놓는 곳들이 있을겁니다. "A 기술에 B 프레임워크를 쓰고, C 서버 엔진에 D 데이터베이스를 연동해서..." 대표님들은 이런 말을 들으면 "와, 정말 대단한 기술력을 가진 곳인가 보다"라고 생각하기 쉽습니다. 하지만 엔지니어의 시각에서 보면 지나치게 화려한 기술 나열은 오히려 실력의 부재를 가리기 위한 포장지일 때가 많습니다.
단순하게 해결할 수 있는 문제를 굳이 복잡한 기술 여러 개를 섞어서 해결하는 건 실력이 아닙니다. 기술이 하나 추가될 때마다 나중에 그 부분을 유지보수하고 관리해야 할 비용은 기하급수적으로 늘어납니다. 결국 그 비용은 고스란히 대표님의 몫이 됩니다.
어떤 기술은 특정 부분에서 치명적인 약점을 가집니다. 그 약점을 보완하기 위해 또 다른 기술을 얹고, 그게 또 문제를 일으켜서 또 다른 도구를 추가하는 식의 땜질식 개발이 의외로 많습니다. 처음부터 비즈니스 목적에 맞는 단단하고 심플한 설계를 했다면 필요 없었을 군더더기들입니다.
복잡하고 특이한 기술 스택으로 도배된 시스템은 나중에 개발사를 바꾸고 싶어도 바꿀 수 없게 만듭니다. 그 기술을 다룰 줄 아는 사람이 적거나, 구조가 너무 꼬여 있어서 다른 엔지니어가 손을 댈 수 없기 때문입니다. 일종의 기술적 인질이 되는 셈입니다.
진짜 실력자는 기술의 이름을 나열하지 않습니다. 대신 대표님의 비즈니스가 어떤 예외 상황에서도 멈추지 않도록, 최소한의 핵심 기술로 최대한의 안정성을 뽑아내는 ${{ "type": "style", "bold": "true", "color": "dodgerblue", "value": "설계의 본질" }}을 이야기합니다. ${{ "type": "style", "bold": "true", "value": "화려한 수식어에 현혹되지 마세요." }} 지금 제안받으신 그 복잡한 기술들이 1년 뒤 대표님의 등에 업힌 무거운 짐이 되지는 않을지 반드시 따져보셔야 합니다.
${{ "type": "item", "value": "embed--post--2" }}