우테코 레벨 1을 진행하면서 가장 많이 들은 피드백 중 하나는 바로 “도메인과 UI를 분리하라”는 것이었다.
하지만 처음엔 도메인이 정확히 무엇을 의미하는지도 몰랐고, 자동차 경주 미션을 진행하면서 막무가내로 코드를 작성했다.
그 결과...
이 피드백을 보고
"아, 내가 뭔가 제대로 이해하지 못했구나..."
를 느꼈다.
그래서 이번 기회에, 도메인과 UI가 무엇인지, 그리고 왜 분리해야 하는지 정리해보려 한다.
📌 도메인이란?
문제 자체를 해결하는 핵심 로직
도메인은 '유저가 보든 말든 상관없이' 동작해야 하는 비즈니스 로직이다.
즉, 사용자가 보지 않아도 내부적으로 꼭 필요한, '앱이 진짜로 해야 할 일'을 담당하는 부분이다.
예를 들어 계산기를 떠올려 보자.
덧셈, 뺄셈, 곱셈 등의 계산을 수행하는 코드가 바로 도메인이다.
이 계산이 잘못되면 아무리 화면이 멋져도 소용이 없다.
✅ 도메인의 특징
- 사용자 입출력과는 독립적
- 로직 자체의 테스트가 가능해야 함
- 재사용성과 확장성이 높아야 함
🖥️ UI란?
사용자와 소통하는 모든 인터페이스(화면)
UI는 사용자와 프로그램을 이어주는 역할이다.
즉, 사용자가 무언가를 입력하고, 결과를 확인하는 부분이다.
아까 말한 계산기에서,
숫자 버튼을 누르거나, 결과를 화면에 출력하는 모든 부분이 UI에 해당한다.
UI는 보여주는 역할에만 충실해야 하며, 로직을 포함해서는 안 된다.
🤔 왜 도메인과 UI를 분리해야 할까?
🧮 계산기 예시
| 역할 | 설명 |
|---|---|
| 도메인 | 숫자 두 개를 더하는 계산 로직 |
| UI | 버튼 입력, 결과 출력 화면 |
만약 도메인과 UI가 섞여 있다면?
- UI 코드 안에 계산식이 들어감
- 화면을 바꾸려면 계산식도 바꿔야 함
- 테스트가 어려워지고, 버그가 많아짐
이처럼 기능이 엉켜 있으면 유지보수도 어렵고 확장도 불가능하다.
초기에는 UI 내부에서 도메인 로직까지 처리하며 모든 기능이 뒤섞여 있었다.
하지만 두 영역을 나누자, 각자의 책임이 명확해졌다.
✅ 분리의 장점
- 테스트 용이: 도메인만 따로 테스트 가능
- 역할 명확화: UI는 입출력만, 도메인은 계산만
- 유지보수 편리: UI 바꿔도 도메인은 그대로
🔄 Controller의 필요성과 MVC 패턴의 이해
근데 도메인과 UI에 대한 이해가 생기니, 또 다른 궁금증이 생겼다.
“입력받은 값을 도메인에 전달할 때, 그 중간 다리는 도대체 어디에 속할까?”
예를 들어 main.js 같은 파일은 도메인일까, UI일까?
그래서 나는 리뷰어에게 질문을 했고...
💡 알게 된 점
도메인과 View를 직접 분리하다 보니 자연스럽게 Controller의 필요성을 느끼게 되었다.
입력을 받고 → 로직을 실행하고 → 결과를 출력하는 이 흐름 속에서
Controller는 도메인과 UI를 연결하는 다리라는 걸 몸소 체감하게 되었다.
🧠 MVC 패턴 구조로 정리하자면
MVC(Model-View-Controller) 패턴은 단순한 형식이 아니라,
책임을 명확히 나누기 위한 현실적인 설계 방식이다.
- Model (도메인): 핵심 로직
- View (UI): 사용자 입출력
- Controller: 흐름을 연결, 조율
📦 실제 적용하며 바뀐 점
- 원래는 라운드를 계산한 직후 곧바로 출력하는 흐름을 반복했다.
즉, "1라운드 계산 → 출력 → 2라운드 계산 → 출력 ..."을 계속 반복하는 구조였다. - 이 방식은 계산 로직(도메인)과 출력 로직(UI)이 강하게 엮여 있어, 도메인과 UI의 분리가 사실상 불가능하거나 매우 어렵다는 한계가 있었다.
- 그래서 구조를 변경했다. 도메인에서는 라운드 결과만 자료구조에 담고, View에서는 모든 라운드가 끝난 후 한 번에 출력하도록 리팩토링했다.
- 그 결과, 각 책임이 명확해졌고 가독성과 테스트 용이성이 훨씬 향상되었다.
- 자연스럽게 Controller의 필요성과 MVC 패턴의 구조적 장점도 몸소 느낄 수 있었다.
📊 MVC 구조 한눈에 보기
이 그림을 보면서 문득 궁금한 점이 생겼다.
Model에서 직접 View를 업데이트한다고?
그런데 내가 구현한 구조에서는 Controller가 View에 결과를 전달하고, View가 출력을 담당하도록 구성했단 말이다.
그럼 내가 구현한 방식은 잘못된 걸까?
🤔 Model이 View를 직접 업데이트해야 할까?
이 그림에서처럼 Model → View로 직접 화살표가 이어진 구조는
주로 GUI 환경, 특히 Java Swing과 같은 데스크탑 애플리케이션에서 많이 쓰이는 방식이다.
이 경우 View는 Model을 "구독(subscribe)"하고 있다가,
Model의 상태가 바뀌면 자동으로 View가 갱신되는 구조다.
(Observer 패턴이 쓰이는 대표적인 구조)
Model이 View를 직접 "알고" 있어야 하기에, 양방향 의존이 생길 수도 있다.
💡 내가 구현한 방식은?
내 구조는 다음과 같은 흐름이었다:
- 사용자의 입력을 View에서 받는다.
- Controller가 입력을 받아 Model에 전달해 상태를 변경한다.
- 변경된 결과를 Controller가 다시 View에 넘겨준다.
- View는 그 결과를 출력한다.
즉, Model은 View에 대해 전혀 모른다.
"Model은 로직만 담당, View와의 연결은 Controller가 조율"하는 구조다.
✅ 정리하자면
| 구분 | Model이 View를 업데이트 | Controller가 View를 업데이트 |
|---|---|---|
| 구조 | Observer 기반 | 흐름 중심 (Web 등) |
| 사용 환경 | Java Swing, 데스크탑 GUI | 웹, SPA 구조 등 |
| 장점 | 실시간 반응, 간결한 연결 | 역할 분리 명확, 테스트 용이 |
| 내 방식 | ❗ Controller가 View를 업데이트 |
결론적으로,
내가 구현한 MVC는 웹 애플리케이션 개발에서 널리 쓰이는 구조로, 전혀 문제가 없다.
오히려 도메인과 UI가 강하게 엮이지 않도록 역할을 명확히 분리한 설계이기에,
테스트하기도 편하고, 확장성도 좋은 구조라는 걸 알 수 있었다.
✍️ 마무리
도메인과 UI의 분리를 단순한 규칙처럼 받아들여었지만, 직접 구조를 고민하고 코드를 설계해보니 역할의 책임과 협력 방식을 이해하게 되었다.
MVC는 이제 그저 따라 쓰는 패턴이 아니라, 내가 왜 이 구조를 쓰는지 설명할 수 있는 설계의 기준점이 되었다.
