software

내 아키텍처를 재고하게 만든 인터뷰 질문: Domain‑Driven Design 이해

발행: (2025년 12월 21일 오후 01:20 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

위에 제공된 소스 링크 외에 번역할 텍스트를 알려주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

인터뷰 질문

“과거 프로젝트에서 도메인‑주도 설계(Domain‑Driven Design)를 어떻게 사용했는지 설명해 주실 수 있나요?”

그 한 가지 간단한 질문에 나는 완전히 멈춰 섰다.

It was my second interview — and also my last one for that position. After the first round, the interviewer had mentioned that a technical test would be required. So, when I got the invitation to the second interview, I spent almost a week preparing — mostly focusing on LINQ and Entity Framework in .NET Core.

→ 그것은 두 번째 인터뷰였으며, 그 직책에 대한 마지막 인터뷰이기도 했다. 첫 라운드 이후 면접관이 기술 테스트가 필요하다고 언급했다. 그래서 두 번째 인터뷰 초대를 받았을 때, 나는 거의 일주일 동안 준비에 매진했다 — 주로 .NET Core의 LINQ와 Entity Framework에 집중했다.

My programming journey started with Visual Basic 6, then moved to VB.NET, and later to C# and Python. In my C# years, I mostly worked with ADO.NET, writing raw SQL queries and stored procedures. That’s why I wasn’t familiar with these newer methodologies — and I knew that was a weakness I had to fix.

→ 나의 프로그래밍 여정은 Visual Basic 6으로 시작해 VB.NET으로 옮겼고, 이후 C#와 Python으로 발전했다. C# 시절에는 주로 ADO.NET을 사용해 원시 SQL 쿼리와 저장 프로시저를 작성했다. 그래서 이러한 최신 방법론에 익숙하지 않았고, 이것이 내가 고쳐야 할 약점이라는 것을 알았다.

I spent a week catching up. It only took a couple of days to get the big picture (thanks to my previous experience), and the rest of the week went into polishing and preparing for the test.

→ 나는 일주일 동안 따라잡았다. 큰 그림을 파악하는 데는 며칠만 걸렸고(이전 경험 덕분에), 나머지 일주일은 다듬고 테스트 준비에 쏟았다.

내가 생각한 DDD

면접 중에 나는 내 아키텍처를 이렇게 설명했다:

  • 리포지토리는 Entity Framework를 통해 데이터베이스와 통신했다
  • 서비스는 이러한 리포지토리를 사용해 비즈니스 로직을 처리했다
  • 컨트롤러는 엔드포인트 역할을 하며 프론트엔드 또는 모바일 앱과 데이터를 교환했다

설명을 마치자 면접관이 미소를 지으며 말했다:

“Tim, 정말 똑똑하구나, 솔직히.”

면접이 끝난 뒤 나는 AI에게 그 아키텍처 스타일이 무엇이라고 부르는지 물었다. 답변은 Domain‑Driven Design이었다. 그 순간 나는 놀랐는데, 나는 DDD의 일부를 전혀 인식하지 못한 채 적용하고 있었던 것이다.

내가 나중에 깨달은 점

처음에는 DDD가 단지 추가적인 레이어—엔티티, 리포지토리, 서비스… 같은 깔끔하게 정리된 폴더 구조에 관한 것이라고 생각했습니다. 하지만 나중에 깨달은 것은 DDD가 구조에 관한 것이 아니라 의미에 관한 것이라는 점입니다. 구조가 실제 비즈니스 도메인을 어떻게 나타내는가가 핵심입니다.

핵심 아이디어는 범용 언어(ubiquitous language) — 비즈니스가 실제로 작업에 대해 이야기하는 방식을 코드가 그대로 반영하는 것입니다.

다음과 같이 생각하는 대신:

“이 함수는 테이블을 업데이트한다.”

DDD는 이렇게 생각하게 합니다:

“이 함수는 주문을 완료한다.”

차이는 작아 보일 수 있지만, 코드 설계, 읽기, 논의 방식을 완전히 바꿔 놓습니다. 면접관은 내 프레임워크 지식을 테스트한 것이 아니라, 내가 기술 구현을 비즈니스 의도와 연결할 수 있는지를 평가한 것이었습니다. 바로 이것이 도메인‑주도 설계(Domain‑Driven Design)의 전부입니다.

DDD가 실제 의미하는 바 (간단히 설명)

  • Domain – 여러분이 모델링하는 실제 세계의 문제 영역(주문, 결제, 고객 등).
  • Ubiquitous Language – 개발자와 도메인 전문가가 공유하는 언어.
  • Entities – 정체성과 라이프사이클을 가진 객체(예: Order, Customer).
  • Value Objects – 정체성 없이 특성을 정의하는 객체(예: Money, Address).
  • Aggregates – 하나의 단위로 함께 변경되는 엔티티 그룹.
  • Repositories – 추상화된 영속성, 데이터베이스 로직을 노출하지 않고 애그리게이트를 저장하거나 로드할 수 있게 함.

그 통찰 적용하기

그 인터뷰 전에, 내 OrderService는 다음과 같았습니다:

public void CompleteOrder(int orderId)
{
    var order = _repository.GetById(orderId);
    order.Status = "Completed";
    _repository.Update(order);
}

작동은 하지만, 주로 데이터 중심입니다. 도메인 관점을 배우고 나서, CRUD 작업이 아니라 의도를 표현하도록 다시 작성했습니다:

public void CompleteOrder(Order order)
{
    order.MarkAsCompleted();
    _repository.Save(order);
}

이제 초점은 비즈니스가 무엇을 하는가에 맞춰졌으며 — 데이터베이스가 어떻게 변하는지가 아니라. 그 작은 변화가 내 아키텍처를 더 깔끔하고, 읽기 쉬우며, 의미 있게 만들었습니다.

핵심 요약

  • DDD는 화려한 패턴이나 레이어에 관한 것이 아니라 비즈니스 도메인을 코드로 표현하는 것입니다.
  • 전체 DDD를 적용하지 않더라도 도메인 관점으로 사고하면 코드가 더 명확하고 유지보수가 쉬워집니다.
  • 최고의 아키텍처는 단순히 동작하는 것이 아니라 소통합니다.

마무리 생각

그 인터뷰는 내가 예상하지 못한 것을 가르쳐 주었습니다 — 때때로, 좋은 건축 원칙을 이미 이해하고 있지만, 아직 그 이름을 배우지 못했을 뿐입니다. 이해는 층을 이루듯이 진행됩니다 — 좋은 건축과 마찬가지로.

Back to Blog

관련 글

더 보기 »