개발 용어보다 자기 생각과 운영 경험을 선택하기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

저는 가끔 “개념 객체”라는 표현을 씁니다. 코드 안에서 중요한 동작이나 규칙을 가지거나 모델의 중심적인 위치에 있는 객체라는 뜻입니다. 경계 사이에서 데이터만 운반하는 객체와는 역할이 다릅니다. 다른 사람은 비슷한 대상을 도메인 객체, 조금 오래된 표현으로 비즈니스 객체라고 부를 수 있습니다.

그 말 자체는 중요하지 않습니다. 특정 소프트웨어 설계 학파에 먼저 합의하지 않아도 의미를 알아들을 수 있는 평범한 표현을 쓰고 싶었습니다. 이 선택에는 개발 대화에서 제가 느낀 더 큰 불편함이 들어 있습니다. 용어가 생각을 대신하는 순간이 있습니다.

이론의 이름은 설명이 아니다

설계에 관해 물으면 언제나 “그건 DDD가 아닙니다”, “그건 TDD가 아닙니다”, “패턴 X를 위반했습니다”라고만 답하는 개발자를 만난 적이 있습니다. 특정 이론을 공격하려는 이야기가 아닙니다. 도메인 주도 설계, 테스트 주도 개발, 객체지향, 함수형 프로그래밍, 디자인 패턴에는 모두 배울 만한 작업이 있습니다.

문제는 실제 코드를 말할 때 이론의 권위 없이는 설명하지 못하는 경우입니다. 저는 왜 이 의존성이 있는지, 어떤 요구사항 때문에 이 객체가 나왔는지, 무엇을 얻는 대신 어떤 비용을 감수하는지, 운영에서 어떻게 동작했는지 듣고 싶습니다. “이론에서 그렇게 말한다”로 답이 끝나면 그 선택이 우리 소프트웨어에 맞는지는 여전히 알 수 없습니다.

자신의 코드를 한 줄씩 자기 언어로 설명할 수 있는 사람과 일하고 싶습니다. 모든 기법을 직접 발명할 필요는 없습니다. 다만 동료에게 유지보수를 맡길 코드라면 그 코드에 대한 자기 판단이 있어야 합니다.

오픈 이후에는 이 차이가 더 크게 보입니다. 발표 자료에서는 근사한 구조가 운영하기 어렵고 확장 비용이 크며 동료들이 다시 고쳐야 하는 코드일 수 있습니다. 구조를 열어 놓고 결과가 나타나기 전에 떠났다고 아키텍처가 성공한 것은 아닙니다. 남아서 서비스를 운영하는 동료가 용어와 결과 사이의 차이를 지불합니다.

패턴은 반복된 작업에서 나왔다

좋은 방법론을 정리한 사람들이 어느 날 아침 완성된 이론을 갑자기 떠올렸다고 생각하지 않습니다. 소프트웨어를 만들고, 실패하고, 고치고, 운영하면서 반복되는 모양을 발견했을 겁니다. 다른 개발자가 더 빨리 배울 수 있도록 그 관찰을 정리했을 것입니다.

그래서 그 작업을 공부하면 시행착오를 줄일 수 있습니다. 초년차에 디자인 패턴이라는 목록 자체를 모르던 때가 있었습니다. 어떤 클래스가 하나의 인스턴스만 가지면 운영하기 좋겠다는 필요가 생겼습니다. 여러 번 헤매다 그렇게 동작하도록 만들고는 꽤 만족했습니다. 책을 읽고 나서 이미 싱글턴 패턴이라는 이름이 있다는 것을 알았습니다.

패턴을 먼저 알았다면 더 빨리 해결했을 겁니다. 무지를 권하는 게 아닙니다. 그렇다고 수백 개의 이름 붙은 해법을 외우는 것만으로 충분하지도 않습니다. 기억한 페이지와 맞지 않는 문제는 반드시 만납니다. 그때 “본 적 없는 패턴이라 못 풉니다”라고 멈추지 않고 상황을 관찰해 해법을 만들어야 합니다.

경험으로 패턴을 발견하는 데에도 가치가 있습니다. 정의만 외운 것이 아니라 실제 문제에 교훈이 붙어 있기 때문입니다. 책에서 이름을 알게 된 다음 축적된 지식과 자기 판단을 비교하면 무엇을 놓쳤는지도 볼 수 있습니다.

공유 어휘는 도움도 되고 권력도 된다

팀이 이미 의미를 공유한다면 약자는 효율적입니다. 같은 설명을 매일 반복하는 코치에게도 간결한 언어가 필요합니다. 용어와 실제 방식을 함께 이해하는 동료끼리 TDD라고 말하는 것은 문제가 없습니다.

용어를 지위로 쓸 때 문제가 생깁니다. 리뷰어가 주니어 개발자에게 낯선 세 글자 원칙을 위반했다고만 적고 구체적인 설명은 하지 않습니다. 상대에게 지식을 전달하지 않은 채 모른다는 느낌만 남깁니다. 좋은 리뷰가 아닙니다.

더 나은 리뷰는 이 코드가 왜 이렇게 만들어졌는지, 어떤 문제를 풀며 운영과 확장에 어떤 영향을 주는지 구체적으로 설명합니다. 결과를 먼저 설명하고, 이후 같은 문제를 짧게 이야기하는 데 도움이 된다면 기존 용어를 소개하면 됩니다.

순서가 중요합니다. 용어는 이미 만들어진 이해를 압축해야 합니다. 이해가 없다는 사실을 가리는 데 쓰면 안 됩니다.

낯선 문제에서도 작동하는 판단을 쌓기

저는 알고 있는 단어 수보다 지혜와 운영 경험에 더 무게를 둡니다. 무언가 만들고, 선택을 설명하고, 운영하고, 실패한 지점을 보고, 규칙을 고치는 과정을 반복하면서 판단이 생깁니다.

설계를 검토할 때는 평범한 질문을 던집니다.

• 이 코드는 지금 어떤 문제를 푸는가?
• 이 객체는 왜 중요하고, 왜 이 동작을 소유하는가?
• 요구사항이 바뀌면 어디가 함께 바뀌는가?
• 제안자는 이론의 이름 없이도 선택의 비용을 설명할 수 있는가?
• 운영 결과가 처음 가정을 확인해 주었는가?

그 과정 내내 책과 이론을 참고하면 됩니다. 아프게 다시 발견하지 않아도 될 교훈이 많이 들어 있습니다. 다만 구체적인 시스템을 보기 전에 이름만으로 토론을 닫지는 말아야 합니다.

나쁜 용어 사용을 겪은 경험 때문에 제 표현이 의도보다 세게 들릴 수 있다는 점은 알고 있습니다. 기존 어휘를 쓰는 사람이 모두 생각이 없다는 주장이 아닙니다. 그 어휘가 다시 코드, 결과, 자기 판단으로 이어져야 한다는 요구입니다. 거기까지 이어지지 못한다면 근사한 이름은 팀에 도움이 되지 않습니다.