정답보다 맥락

2026년 6월 18일 · 약 4분

개발을 하다 보면 자신의 선택을 거의 정답처럼 이야기하는 사람을 만납니다. 이 구조가 더 맞고, 이 추상화가 더 바람직하며, 이렇게 하지 않으면 결국 문제가 생긴다고 말합니다. 실제로 그 말이 맞는 경우도 많습니다. 더 좋은 설계가 있고, 피해야 할 방식이 있으며, 경험을 통해 쌓인 기준도 분명 존재합니다.

정답을 찾으려는 태도 자체가 문제라고 생각하지는 않습니다. 더 나은 방법을 고민하고, 품질에 대한 기준을 세우는 일은 엔지니어에게 필요한 역할입니다. 문제는 자신이 찾은 답을 모든 상황에 적용되는 정답처럼 다루기 시작할 때 생깁니다.

코드는 맞을 수 있어도, 판단은 틀릴 수 있습니다.

맞는 말이 좋은 판단은 아닐 때

기한이 얼마 남지 않았는데 구조를 다시 손봅니다. 제품의 방향이 바뀌었는데도 기존 설계의 완성도를 끝까지 끌어올립니다. 이용자가 많지 않은 서비스에 아직 오지 않은 규모를 가정하고, 함께 유지할 사람보다 자신이 생각하는 이상적인 구조를 우선합니다.

각각의 주장만 떼어놓고 보면 틀렸다고 말하기 어려울 수 있습니다. 확장성을 고려하는 것도 맞고, 중복을 줄이는 것도 맞고, 일관된 구조를 만드는 것도 맞습니다. 하지만 모든 맞는 말이 지금 해야 할 일인 것은 아닙니다.

한정된 시간 안에서 한 가지를 더 잘 만드는 동안 다른 무언가는 미뤄집니다. 제품이 시장에 나가는 시점이 늦어질 수도 있고, 더 중요한 문제를 해결할 기회를 잃을 수도 있습니다. 좋은 설계가 나쁜 판단이 되는 순간은 대개 여기에서 시작됩니다.

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

설계의 완성도를 중요하게 생각하는 사람이 빠지기 쉬운 함정을 떠올리면, 모두가 이미 건너간 강에 남아 가장 튼튼한 다리를 놓고 있는 모습과 비슷합니다. 다리는 분명 훌륭합니다. 구조적으로도 아름답고, 오래 버틸 수 있고, 누구에게 보여줘도 좋은 설계라고 말할 수 있습니다.

다만 이제 그 다리를 건널 사람이 없습니다.

제품 개발에서도 비슷한 일이 생깁니다. 처음에는 중요했던 문제가 더 이상 중요하지 않을 수 있고, 몇 년을 바라보고 만든 기능이 몇 달 뒤 없어질 수도 있습니다. 반대로 임시로 만든 기능이 예상보다 오래 살아남기도 합니다.

그래서 처음의 판단을 끝까지 지키는 것이 항상 일관성은 아닙니다. 상황이 바뀌었는데도 같은 답을 고집한다면 그것은 어느 순간 관성이 될 수 있습니다.

품질에도 우선순위가 있다

그렇다고 상황에 따라 품질을 포기해도 된다는 뜻은 아닙니다. 보안, 데이터 정합성, 금전 처리, 장애 복구처럼 실패 비용이 큰 곳에는 쉽게 낮출 수 없는 기준이 있습니다. 이런 영역에서 일정이나 속도를 이유로 필요한 품질을 포기하는 것은 또 다른 잘못된 판단입니다.

다만 모든 코드가 같은 수준의 완성도를 요구하지는 않습니다. 몇 달 동안 검증할 실험 기능과 앞으로 수년간 핵심 데이터를 다룰 시스템에 같은 비용을 쓸 이유는 없습니다. 하루에 몇십 명이 사용하는 내부 도구와 수백만 명이 사용하는 서비스도 요구되는 기준이 다릅니다.

품질은 높을수록 무조건 좋은 값이라기보다, 어디에 얼마만큼 투자할지를 결정해야 하는 대상에 가깝습니다. 더 좋은 구조를 만들 수 있다는 사실과, 지금 그 구조를 만들어야 한다는 판단은 서로 다른 문제입니다.

완벽함이 목적이 될 때

완벽을 추구하는 태도 역시 나쁘다고 생각하지 않습니다. 어떤 사람은 높은 기준 덕분에 다른 사람이 놓친 문제를 발견하고, 시스템이 쉽게 무너지지 않도록 지켜냅니다. 조직에는 그런 사람이 필요합니다.

다만 완벽함이 목적이 되기 시작하면 주변의 조건이 잘 보이지 않습니다. 왜 이 기능을 만드는지보다 구조가 얼마나 깔끔한지가 중요해지고, 지금 사용자에게 필요한 것이 무엇인지보다 설계가 자신의 기준에 맞는지가 중요해집니다.

그러다 보면 품질을 지키는 것과 자신의 기준을 지키는 것이 섞이기 시작합니다. 둘은 비슷해 보여도 다릅니다. 품질은 제품과 사용자를 위해 존재하지만, 자신의 기준은 언제든 다시 검토할 수 있어야 합니다.

AI가 코드를 더 잘 만드는 시대

요즘 AI는 익숙한 문제라면 꽤 좋은 코드를 빠르게 만들어냅니다. 일반적인 패턴을 적용하고, 보기 좋은 구조를 만들고, 흔히 이야기하는 모범 사례도 어렵지 않게 가져옵니다. 앞으로 이런 능력은 더 빠르고 저렴해질 가능성이 큽니다.

그럴수록 사람에게 더 많이 남는 일은 코드를 만드는 방법보다, 어떤 방법을 지금 선택할지 판단하는 일이 아닐까 생각합니다.

AI는 더 정교한 추상화를 제안할 수 있습니다. 더 확장 가능한 구조도 만들 수 있습니다. 하지만 이 기능이 세 달 뒤에도 남아 있을지, 지금 출시를 늦출 만큼 중요한 문제인지, 팀이 이 복잡도를 감당할 수 있는지까지 코드만 보고 결정할 수는 없습니다. 그 판단에는 제품의 상황과 사람, 시간, 비용이 함께 들어갑니다.