보편적 언어(Ubiquitous Language)는 도메인 주도 설계(DDD)에서 개발자와 비즈니스 전문가(도메인 전문가)가 서로의 지식 격차를 해소하고 하나의 팀으로 기능하기 위해 프로젝트 전체에서 공통으로 사용하는 공유 언어이다. 이 언어는 단순한 회의용 어휘를 넘어, 소프트웨어의 설계 문서, 모델링 다이어그램, 그리고 실제 소스 코드의 명명 규칙(클래스, 변수, 메서드 등)에까지 일관되게 반영되어야 한다.
2. 핵심 원칙 및 실천 방안
공통 어휘 도출: 비즈니스 프로세스에서 사용하는 용어를 기술적인 용어(예: UserTable, DataObject)로 치환하지 않고, 도메인 전문가가 사용하는 비즈니스 용어(예: Customer, Order)를 그대로 채택.
코드와 모델의 일치: 보편적 언어의 변경은 즉시 코드의 리팩토링으로 이어져야 하며, 코드의 변화 역시 언어의 갱신을 의미해야 함. "코드가 곧 언어이고, 언어가 곧 모델"이라는 철학 유지.
컨텍스트별 격리: 동일한 단어라도 바운디드 컨텍스트(Bounded Context)에 따라 의미가 달라질 수 있음을 인정하고, 각 컨텍스트 내에서만 유효한 언어 세트를 관리.
시각화 및 도구 활용: 이벤트 스토밍(Event Storming) 워크숍이나 공유 용어 사전(Glossary)을 통해 언어의 정의를 명시화하고 지속적으로 업데이트.
3. 엔지니어링 가치
의사소통 비용 절감: 개발자와 기획자 간의 '번역' 과정을 없애 오해를 줄이고, 요구사항이 코드로 정확히 전이되도록 보장.
코드의 자가 문서화 (Self-Documenting): 코드가 비즈니스 용어로 작성되어 있어, 기술 지식이 부족한 사람도(혹은 도메인 지식만 있는 신규 개발자도) 코드의 의도를 훨씬 빠르게 파악 가능.
지식의 무결성 유지: 비즈니스 규칙이 변경될 때 어떤 코드를 수정해야 하는지 명확히 매핑되므로, 유지보수의 정확성과 속도 향상.
4. 트레이드오프 및 주의사항
초기 합의 비용: 비즈니스 전문가의 적극적인 참여와 용어 정의를 위한 심도 있는 토론 과정이 필요하며, 이는 초기 프로젝트 속도를 늦출 수 있음.
언어의 부패 방지: 비즈니스가 진화함에 따라 언어도 변하므로, 코드와 언어 사이의 동기화를 유지하기 위한 끊임없는 리팩토링 규율이 요구됨.
기술적 용어와의 균형: 모든 것을 비즈니스 용어로 명명할 수는 없다. 인프라스트럭처나 프레임워크 수준의 코드는 기술적 명명법을 따르되, 도메인 핵심 로직(Domain Core)만큼은 보편적 언어를 엄격히 준수해야 함.
Antigravity Agent