단순함이 보상받지 못하는 진짜 이유와 PR의 기술

최근 소프트웨어 엔지니어링 업계에서 흥미로운 글 하나가 공유되었다. 핵심은 아무도 단순함을 이유로 승진시켜주지 않는다는 것이다. 복잡한 설계를 가져온 엔지니어는 화려한 기술적 서사를 써 내려가지만, 문제를 가장 단순하게 해결한 엔지니어는 구현했다는 한마디 외에 쓸 말이 없어진다는 문제 제기다.

상당히 통찰력 있는 분석이지만 현장의 시각에서 보면 조금 결이 다른 부분이 있다. 엔지니어가 무조건 복잡한 것을 선택하지는 않기 때문이다. 실제 현장에는 기한과 인력이라는 명확한 제약 조건이 존재한다. 가용한 자원이 한정된 상황에서 엔지니어는 결국 최적의 답을 찾아가기 마련이다.

진짜 문제는 단순함 그 자체가 아니라 자신이 한 일을 어떻게 정의하고 포장하느냐 하는 PR의 문제다.

많은 엔지니어가 복잡함을 기술적 우위로 착각하고 이를 서사로 활용한다. 하지만 진정한 실력은 수많은 기술적 대안 중에서 왜 가장 단순한 방식을 선택했는지 논리적으로 증명하는 데서 나온다. 승진 심사나 평가 과정에서 이것을 어떻게 풀어낼지는 결국 본인의 몫이다.

예를 들어 단순히 기능을 구현했다고 말하는 대신 세 가지 아키텍처 대안을 검토했음을 밝혀야 한다. 확장성을 고려한 복잡한 모델이 있었음에도 현재의 운영 리소스와 비즈니스 타임라인을 고려해 가장 비용 효율적인 구조를 선택했다는 논리가 필요하다.

단순함은 게으름의 결과가 아니라 치열한 고민 끝에 도달한 최적화의 결과여야 한다. 그리고 그 최적화 과정을 기술적인 언어로 번역하여 조직에 전달하는 능력이 필요하다. 아무도 알아주지 않는 단순함은 자기만족에 그칠 위험이 크다.

결국 복잡한 시스템을 만드는 것만큼이나 중요한 것이 자신이 선택한 단순함의 가치를 입증하는 일이다. 엔지니어링의 목표가 문제 해결이라면 그 과정에서 발생한 기회비용과 선택의 근거를 기록하고 공유해야 한다. 화려한 상자 속에 빈 강정을 담는 것이 아니라 투명한 상자 안에 담긴 보석의 가치를 설명할 수 있어야 한다.

승진은 복잡한 일을 한 사람에게 가는 것이 아니라 자신이 조직에 기여한 가치를 가장 잘 설명한 사람에게 돌아간다. 단순함을 선택했다면 그 단순함이 조직에 가져다준 유지보수 비용의 절감과 출시 속도의 향상을 숫자가 아니더라도 논리로 설명해내야 한다. 그것이 에이전트 시대에도 변하지 않을 엔지니어의 핵심 역량이다.