컴퓨터 과학에는 두 가지 어려운 문제가 있다고들 한다. 캐시 무효화와 무언가에 이름을 짓는 일이다. 그런데 정말로 어려운 문제는 따로 있다. 왜 우리는 이름을 짓는 데 그토록 서툴렀을까? 코드 한 줄, 변수 하나에도 이름을 붙여야 하는 순간이 오면 개발자는 마치 언어의 한계에 부딪힌 듯 멈칫하게 된다. 이 문제는 단순히 기술적 난이도를 넘어선다. 그것은 인간의 인지, 문화, 그리고 소프트웨어의 본질이 교차하는 지점이다.
이름짓기는 추상화를 위한 첫걸음이다. 변수, 함수, 클래스에 적절한 이름을 붙이는 것은 그 대상이 가진 의미를 압축해 전달하는 행위다. 그런데 여기서 문제가 발생한다. 소프트웨어는 끊임없이 변화하고, 그 변화에 따라 이름의 의미도 달라져야 한다. 하지만 현실에서는 이름이 한 번 붙으면 잘 바뀌지 않는다. 시간이 지나면서 본래의 의도와 멀어진 이름들이 코드베이스를 가득 채운다. 마치 오래된 지도에 적힌 도시 이름처럼, 현재의 현실과는 동떨어진 채 남아 있는 것이다.
이름의 문제는 언어의 한계를 드러낸다. 자연어는 모호하고 맥락에 의존적이다. “Manager”, “Service”, “Helper” 같은 단어는 너무 포괄적이어서 실제 의미를 파악하기 어렵다. 반대로 지나치게 구체적인 이름(“UserDataStorageWithRedisCache”)은 코드의 유연성을 해친다. 개발자는 이 두 극단 사이에서 균형을 찾아야 하는데, 그 기준은 늘 불분명하다. 팀마다, 프로젝트마다, 심지어 개발자마다 다른 기준을 적용하니 혼란은 가중될 뿐이다.
더 근본적인 문제는 이름짓기가 단순히 기술적 과제가 아니라는 점이다. 그것은 문화적 행위다. 개발자들은 종종 이름짓기를 “코딩의 일부”로 여기지만, 사실 그것은 커뮤니케이션의 도구다. 좋은 이름은 코드의 의도를 명확히 전달하고, 유지보수를 용이하게 하며, 새로운 팀원이 빠르게 적응할 수 있도록 돕는다. 반면 나쁜 이름은 오해를 낳고, 버그를 유발하며, 결국 프로젝트의 수명을 단축시킨다.
이름을 짓는 것은 세계를 이해하는 방식이다. 소프트웨어에서 이름을 짓는 것은 그 세계를 구축하는 일이다.
이름짓기의 어려움은 소프트웨어 개발의 본질적 모순을 반영한다. 우리는 정밀한 기계인 컴퓨터와 모호한 인간 언어를 연결해야 한다. 이 연결 고리가 바로 이름이다. 그런데 이 연결 고리가 너무나 취약하다. 개발자들은 종종 이 문제를 기술적 해결책으로 접근하려 한다. 네이밍 컨벤션을 만들고, 정적 분석 도구를 도입하고, 코드 리뷰를 강화한다. 물론 이런 노력은 필요하다. 하지만 그것만으로는 충분하지 않다.
이름짓기는 결국 인간의 문제다. 그것은 언어의 한계, 인지의 한계, 문화의 차이를 극복해야 하는 과제다. 개발자들은 이 문제를 해결하기 위해 더 나은 커뮤니케이션 기술을 익혀야 한다. 단순히 코드를 잘 짜는 것만으로는 부족하다. 동료와 협력하고, 도메인을 이해하고, 그 이해를 효과적으로 전달할 수 있어야 한다. 이름짓기는 그 모든 것의 시작점이자 종착점이다.
소프트웨어 개발에서 가장 어려운 문제는 어쩌면 이름짓기가 아닐지도 모른다. 그것은 우리가 이름짓기를 통해 드러내는, 소프트웨어와 인간의 관계 그 자체일 수도 있다. 우리는 아직 그 관계를 제대로 이해하지 못하고 있다. 하지만 그 이해의 여정에서 이름짓기는 여전히 중요한 이정표가 될 것이다.
이 글은 The Third Hard Problem을 바탕으로 작성되었습니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
