옳은 코드와 맞는 코드
오래 지켜보며 갖게 된 생각이 하나 있습니다.
코드를 정말 잘 짜는 사람이 있습니다. 구조도 깔끔하고 추상화도 정교합니다. 그 옆에는 어딘가 엉성하고 대충 짜는 것처럼 보이는 사람이 있습니다. 그런데 시간이 지나고 보면 조직에서 더 신뢰받는 쪽은 종종 후자입니다.
처음에는 실력보다 운이나 사내 정치가 앞선 결과라고 생각하기 쉽습니다. 하지만 비슷한 장면이 반복되는 것을 보며 다른 이유가 있다고 생각하게 됐습니다. 두 사람의 차이는 코드를 다루는 솜씨보다, 어디에 그 솜씨를 쓸지 고르는 판단에 있을 수 있습니다.
이미 건너간 강에 다리를 놓는 일
설계의 순수성을 중시하는 사람이 빠지기 쉬운 함정이 있습니다. 모두가 이미 건너간 강에 남아 세상에서 가장 튼튼한 다리를 놓으려는 모습입니다.
기한이 코앞인데도 설계를 다시 손보는 일을 멈추지 못합니다. 사업의 방향이 바뀌었는데도 지금 코드의 우아함을 놓지 못합니다. 쓰는 사람이 몇십 명뿐인 서비스에 거대한 트래픽을 가정하고, 함께 유지할 동료의 숙련도보다 자신이 써보고 싶은 기술을 앞세웁니다. 그러다 속도와 타협을 이야기하면 '품질'이라는 말로 대화를 끝냅니다.
좋은 의도에서 시작한 선택일 수 있습니다. 하지만 비용과 효용을 더는 저울질하지 않는 순간 신념은 관성이 됩니다. 아무리 튼튼한 다리라도 건널 사람이 남지 않은 곳에 놓고 있다면 그 솜씨는 닿을 곳을 잃습니다.
품질은 어디에 힘을 줄지 고르는 일
조직 안에서 품질은 그 자체로 완결된 목적이 되기 어렵습니다. 시간과 자본은 한정돼 있고, 한곳에 더 쓴 시간은 다른 곳에서 빠져나갑니다.
그렇다고 품질을 낮춰도 된다는 뜻은 아닙니다. 보안과 데이터 정합성, 장애 복구처럼 실패 비용이 큰 곳에는 타협할 수 없는 기준이 있습니다. '상황에 맞는 코드'라는 말은 위험한 코드를 합리화하는 면허가 아닙니다.
다만 그 기준을 넘은 뒤에도 모든 코드에 같은 수준의 완성도를 요구할 수는 없습니다. 어디에 더 투자하고 어디에서 멈출지 선택해야 합니다. 평소에는 약속한 기한을 지켜 신뢰를 쌓고, 시스템이 무너질 수 있는 순간에는 그 신뢰를 담보로 설계를 지켜냅니다.
대충 짜는 것처럼 보였던 사람은 어쩌면 품질을 포기한 것이 아니라, 품질을 어디에 써야 하는지 알고 있었을지 모릅니다.
옳은 코드와 맞는 코드
요즘 AI는 표준적인 코드를 순식간에 내놓습니다. 깔끔하고 모범적이며, 익숙한 문제에서는 어지간한 사람보다 빠릅니다.
하지만 그 코드는 회사에 남은 시간이 얼마인지 모릅니다. 이 기능이 다음 분기에도 살아 있을지, 이번 주에 무엇을 포기해야 하는지, 이 코드를 함께 유지할 사람이 누구인지도 모릅니다.
코드가 일반적인 기준에서 옳은지와 지금 놓일 자리에 맞는지는 다른 문제입니다. 옳음은 규칙과 패턴으로 상당 부분 확인할 수 있지만, 맞음은 맥락과 책임을 함께 봐야 판단할 수 있습니다.
도구가 표준적인 코드를 더 잘 만들어낼수록 사람은 구현보다 선택에 더 많은 시간을 써야 합니다. 왜 지금 이것을 만드는지 묻고, 얻는 것과 포기하는 것을 함께 고르는 일입니다.
무엇을 지키고 무엇을 덜어낼 것인가
더 좋은 구조를 제안하는 능력만큼 지금은 하지 않아도 되는 일을 알아보고 충분한 지점에서 멈추는 판단도 필요합니다.
물론 멈추는 선택에는 책임이 따릅니다. 무엇을 덜어냈는지 기록하고, 언제 다시 돌아와야 하는지 남겨야 합니다. 판단 없이 생략한 것과 판단 끝에 미룬 것은 겉으로 비슷해 보여도 전혀 다릅니다.
그래서 잘 짜인 코드를 오래 들여다볼 때면 이제는 코드 바깥의 질문도 함께 떠올리려 합니다.
이 코드는 지금 누구의 문제를 풀고 있는가.
지키려는 품질은 곁에 있는 사람과 제품을 실제로 앞으로 옮기고 있는가.
