엔지니어링은 트레이드오프의 예술입니다
본론으로 들어가기에 앞서 미리 말씀드리자면, 제 경력이 아주 긴 편은 아닙니다. 기술을 바라보는 관점은 여전히 성장 중이며, 생각이 성숙하지 못할 수 있습니다. 하지만 현업에서 여러 문제를 마주하며 깨달은 확실한 진리 하나는 있습니다. 바로 소프트웨어 엔지니어링에 ‘완벽한 정답’은 없다는 사실입니다.
트레이드오프: 제로섬 게임, 그 이상
흔히 엔지니어링에서 트레이드오프(Trade-off)라고 하면 단순한 기회비용 정도로만 생각하곤 합니다.
성능을 위해 유지보수성을 희생한다거나, 당장의 개발 속도를 챙기느라 장기적인 확장성을 포기하는 식으로 말이죠.
하지만 경험 많은 엔지니어들은 이 문제를 단순히 제로섬 게임으로 보지 않습니다. 오히려 더 정교한 설계를 통해 희생을 최소화할 수 있는 최적의 지점을 찾아냅니다. 진짜 실력은 “무엇을 포기할까?“를 묻는 게 아니라, “나중에 우리가 충분히 감당할 수 있는 부채(Debt)는 무엇인가?” 를 판단하고 그 위에서 설계하는 데서 나옵니다.
엔지니어링이 왜 ‘예술’의 영역인가
훌륭한 엔지니어의 척도는 가장 복잡한 시스템을 구축하는 능력에 있지 않습니다. 현재 상황에서 무엇이 필수이고 무엇이 덜 중요한지(expendable) 판단하는 ‘결단의 예술’ 에 있습니다. 이러한 예술적 감각은 다음 세 가지를 통해 드러납니다.
맥락의 이해 (Understand Context)
엔지니어링의 가치는 코드 그 자체가 아니라, 그 코드가 살아 숨 쉬는 맥락(Context)에 의해 결정됩니다. 훌륭한 엔지니어는 기술적 의사결정을 비즈니스의 생애 주기와 동기화시킵니다.
- 생존 모드 (시장 검증 단계): 당장 시장 검증이 시급한 스타트업에게 “무한 확장 가능한 마이크로서비스 아키텍처"는 예술이 아닙니다. 낭비죠. 이 단계에서 가장 ‘예술적인’ 결정은 빠른 피드백 루프를 위해 모놀리식(Monolithic)하고 단순한 구조를 유지하는 것입니다.
- 확장 모드: 반대로 서비스가 대박이 나서 트래픽이 폭발할 때 기술 부채를 무시하는 건 예술적 실패입니다. 이때의 우선순위는 장기적인 성장을 뒷받침할 안정성과 모듈화로 이동해야 합니다.
오버 엔지니어링 피하기 (Avoid Over-engineering)
많은 엔지니어들이 “개발을 위한 개발"의 함정에 빠지곤 합니다. 하지만 진짜 실력은 복잡한 걸 단순하게 유지하는 능력에서 나오거든요.
- 복잡도는 쌓이는 이자입니다: 모든 시스템은 유지보수가 필요한 부채입니다. 사용자가 100명뿐인데 100만 명을 대비한 캐싱 시스템을 구축하는 건 “미래를 위한 대비"가 아니라 “현재의 낭비"입니다.
- 자전거 vs 우주선: 자전거로도 목적지에 갈 수 있다면, 우주선을 설계해서는 안 됩니다. “딱 필요한 만큼"인 솔루션에는 특유의 절제미가 있거든요. 몇 달 동안 격납고에서 정비만 하는 게 아니라, 오늘 당장 페달을 밟고 나갈 수 있는 솔루션을 내놓는 것 또한 진짜 기술입니다.
되돌릴 수 있는가 (Reversibility)
여기서 짬바가 드러납니다. 나중에 갚을 수 있는 기술 부채(코드 품질, 수동 프로세스)는 과감하게 짊어지고, 돌이킬 수 없는 손실(데이터 무결성, 보안)은 피하는 안목이 필요합니다.
되돌릴 수 있는 선택들:
- 나중에 마이그레이션 가능한 비정규화(Denormalized) 데이터
- 자동화할 수 있는 수동 프로세스
- 나중에 서비스를 떼어낼 수 있는 모놀리스(Monolith)
- 비동기로 전환 가능한 동기(Synchronous) 호출
돌이킬 수 없는 (혹은 되돌리기 비싼) 선택들:
- 수집하지 않고 날려버린 데이터
- 이미 털려버린 보안 취약점
- 외부 사용자가 의존하고 있는 API 스펙 (Contract)
- 수년 치 코드에 깊숙이 박힌 아키텍처 결정
스타트업이 비정규화된 user_orders 테이블 하나로 배포한다고 해서 게으른 게 아닙니다. ‘되돌릴 수 있는 부채’를 선택한 거죠. 아직 데이터 접근 패턴(Access Pattern)을 모르니까요. 서비스는 계속 개발 중이고, 데이터 형태도 확정되지 않았습니다. 흐름이 계속 바뀌는데 섣불리 정규화를 해버리면 그 자체가 빚이 됩니다. 스키마와 싸워야 하는 쿼리들, 요구사항이 명확해질 때마다 해야 하는 마이그레이션 작업들… 이게 다 비용이거든요.
하지만 스테이트풀 아키텍처를 선택하거나 보안을 방치하는 것은 차원이 다른 ‘비가역적 부채’입니다. 서버 로컬 메모리에 핵심 상태를 박아넣는 순간 ‘확장의 벽’에 갇히게 되며, 트래픽이 몰리는 결정적인 순간에 아키텍처 전체를 갈아엎어야 하는 재앙을 맞이합니다. 보안 역시 나중에 덧붙일 수 있는 옵션이 아닙니다. 데이터 유출은 ‘되돌리기’ 버튼이 없으며, 한 번 무너진 유저의 신뢰는 돈으로 살 수 없습니다. 이것은 단순한 기술적 지름길이 아니라, 비즈니스의 미래 속도나 회사 그 자체를 파산시킬 수 있는 근본적인 구조적 결함입니다.
완벽함이 아닌, 우선순위를 찾는 여정
정해진 정답 없이 수천 가지 선택지가 널려 있는 상황에서, 현재의 목표에 딱 맞는 최적의 균형점을 찾아가는 과정이야말로 엔지니어링의 묘미입니다.
이 글에서 딱 한 가지만 기억하신다면 이겁니다. 모두를 만족시키는 ‘완벽한 정답’을 찾느라 삽질하는 비효율을 멈추세요. 대신 우선순위를 철저히 따져보세요. 현재의 목표를 달성하기 위해, 지금 당장 감수할 수 있는 부분이 무엇인지 말이죠.
결국 엔지니어링이란, 무엇을 포기할지 가장 현명하게 선택하는 예술인 셈이니까요.