옳은 코드와 맞는 코드

2026년 6월 18일 · 약 3분

Software Engineer | Former Industrial Designer

오래 지켜보며 갖게 된 생각이 하나 있다.

코드를 정말 잘 짜는 사람이 있다. 구조도 깔끔하고 추상화도 정교하다. 그런데 그 옆에는 어딘가 엉성하게, 대충 짜는 것처럼 보이는 사람이 있다. 흥미롭게도 시간이 지나고 보면 조직에서 더 신뢰받는 쪽은 종종 후자다. 설계의 순수성을 끝까지 지키려던 사람이 오히려 변두리로 밀려나는 일을, 나는 여러 번 보았다.

흔히들 운이나 사내 정치 때문이라고 말하면 편하겠지만, 나는 거기에 다른 본질적인 이유가 있다고 생각한다.

이미 건너간 강에 다리를 놓는 일

순수성을 지키려는 쪽이 빠지기 쉬운 함정이 있다. 모두가 이미 건너간 강에 혼자 남아, 세상에서 가장 튼튼한 다리를 놓겠다고 고집하는 모습이다.

기한이 코앞인데도 설계를 다시 손보는 일을 멈추지 못한다. 사업의 방향이 이미 다른 곳을 향하는데도 지금 짜고 있는 코드의 우아함을 놓지 못한다. 쓰는 사람이 몇십 명뿐인 서비스에 거대한 트래픽을 가정한 구조를 욕심내고, 곁에서 함께 일하는 동료의 숙련도는 배제한 채 본인이 익히고 싶은 신기술을 밀어붙인다. 그러다 누군가 속도와 타협을 이야기하면 '품질'이라는 단어를 방패처럼 빼든다.

본인은 그것을 신념이라 부를 것이다. 하지만 내가 보기엔 신념이라기보다, 어느 순간 비용과 효용의 계산을 멈춰버린 맹목에 가깝다. 아무리 튼튼한 다리라도 건너야 할 사람이 남지 않은 곳에 놓고 있다면, 그건 솜씨가 아니라 헛수고일 뿐이다.

그리고 정작, 그렇게 완벽을 좇는 사람이 끝내 완벽한 무언가를 내놓는 것을 나는 본 기억이 없다. 완벽은 늘 다음 버전에, 리팩토링이 끝난 다음에, '조금만 더 시간이 있었다면'의 저편에 머물러 있었다.

품질을 어디에 쓸 것인가

나는 품질이 그 자체로 목적이 될 수는 없다고 생각한다. 적어도 누군가의 시간과 자본으로 굴러가는 조직 안에서는 그렇다.

품질은 모든 곳에 똑같이 쏟아붓는 것이 아니라, 어디에 집중하고 어디에서 손을 뗄지 고르는 '선택'의 문제다. 평소에는 약속한 기한을 지켜 신뢰를 쌓아두고, 정말로 시스템이 무너질 것 같은 치명적인 순간에 그 신뢰를 담보로 설계를 지켜낸다. 매 순간 모든 코드에 최고치만 욕심내는 사람에게는, 정작 진짜 버텨야 하는 순간에 끌어다 쓸 신뢰의 잔고가 남아있지 않다.

대충 짜는 것처럼 보였던 그 사람은, 아마 어디에 힘을 주고 어디에서 힘을 빼야 할지를 누구보다 잘 알고 있었을 것이다.