[우테코 준비] MVC 모델

lucykim·2026년 1월 2일

우테코

목록 보기
1/3
post-thumbnail

우테코 최종 코테를 준비하며 계속해서 문제를 풀어나가고 있는 요즘 가장 큰 관심사는 객체지향 프로그래밍이었다. 절차지향이 더 익숙했고, 코테(백준, 프로그래머스)를 풀면서 js에 익숙해진 케이스이기 때문에 이렇게 프로그래밍하는 방식이 익숙하지는 않았기에 계속해서 문제를 풀고, 설계도 꼼꼼히 하는 연습을 하고 있었다.

프리코스 3주차에 풀어봤던 로또 문제를 설계하던 도중에 MVC 패턴에 대해서 궁금증이 생겨 오픈미션을 함께 했던 여빈님과 이야기를 해보게 되었고, 이에 대한 내용을 정리하고자 한다.

일단 내가 그동안 계층 분리를 했던 내용은 다음과 같다.



또한 프리코스 내내 이상하게... 계층분리를 했었다.


MVC모델에 대해서 제대로 학습해본 사람이 보면 뒷목 잡고 기절할 만한 상황이지만... 일단 내가 하고 있던 생각에 대해 설명해보자면

View는 사용자와 상호작용하며 입출력을 담당하는 내용이고, Controller는 뭔가 내용을 처리하는 로직이며, Model은 상태를 가지고 있는 객체!라고 생각을 했다. 이 부분에 대해서 티가 나는 부분이 맨 위에 있는 controller에 3개의 파일이 있는 미션인데, 이 미션의 경우에는 상태를 가지고 있는 객체가 없었기 때문에, model 계층이 하나도 없다.
그니까 내용을 계속 처리하는 로직들만 반복되기 때문에 controller만 있다고 생각했던 것이다.


이번에는 프리코스 3주차에 풀었던 로또 미션을 다시 진행하고자 하고 있었고, 기초 설계를 완료한 다음의 내용은 다음과 같다.

글씨는.. 나 혼자 보기 위해 쓴거라 개판이지만 오른쪽 아래를 보면 MVC를 나눠놓은 모습이 보인다.

Model

  • Lotto

View

  • Input
  • Output

Controller

  • GameController
  • LottoResult

이와 같이 나눠놨었고, 설계를 완료한 후에 README에 쓰고 있던 와중, 이와 같은 의문이 들었다.

1. GameController

- Input 받아옴
- Lotto 생성(LottoIssuer 만들까)
- 결과 출력
- Input 받아옴(당첨 번호, 보너스 번호)
- GameResult 돌림
- 결과 출력

여기서 2번째에 LottoIssuer만들까? 에 대한 부분에서 궁금증이 시작되었다. Lotto를 생성, 즉 발행하는 클래스를 만들까에 대한 고민이었고, 이 LottoIssuer를 만들게 되면 과연 이 파일은 MVC 중 어디에 해당되는가...에 대해 고민을 시작했다. 그리고 gpt에게 물어본 결과 model에 해당된다는 답변을 받게 되었다.
나는 의문이 생겼다. 아니.. 발행만 하는건데 왜 model이야? 그리고 mvc 모델을 검색해보게 되었고, 이와 같이 정리된 내용을 발견하였다.

내가 그동안 생각해왔던 방식과 완전히 다른 방식이었다. 완전히는 아니지만, 사용자와의 상호작용?을 하는 내용이 controller라는 말이었다. 이 내용을 바탕으로 그동안 해왔던 미션에 대해 생각해보면, controller가 단 한개만 존재하게 된다. 그래서 이 부분에 대해 여빈님에게 sos를 쳤고, 정말 좋은 답변이 돌아왔다.

정말 이해가 잘 됐다.
그니까 정리하자면 알바생은 사용자와 상호작용을 하며, 알바생이 해주는 서비스나 사용하는 기계들은 모두 model이라는 말이다. 그니까 view는 사용자가 하는 말, 그리고 영수증? 받는 물품? 에 해당되고, 알바생은 controller며, 포스기나 뭐 커피기계 이런건 다 model이다.


이 부분에 대해서 웹일 때의 경우를 찾아보았다.

  1. 사용자가 브라우저에서 웹 페이지 주소를 입력해 서버로 HTTP GET 요청을 보낸다.
  2. 서버는 Controller에서 HTTP GET 요청을 받는다.
  3. Model(Service)에서 비즈니스 로직을 처리한다.
  4. Model은 Controller로 화면에 필요한 데이터를 넘겨준다.
  5. Controller는 받아온 데이터를 View에 넘겨주어 HTML 페이지를 만든다.
  6. Controller에서 만들어진 HTML 파일을 브라우저에게 넘겨준다.
  7. 브라우저는 HTML 파일을 렌더링한다.

이걸 보니 이해가 더 잘 됐다. 왜냐면 우리는 콘솔에 print되는, 그리고 콘솔을 통해 사용자와 상호작용하는 프로그램을 만들고 있기 때문에

  1. 사용자의 입력을 받는다(View)
  2. 받은 요청(입력)을 보낸다.
  3. Controller에서 요청을 받는다.
  4. Model에서 로직을 처리한다.
  5. Model은 Controller로 필요한 결과를 넘겨준다.
  6. Controller는 받아온 결과를 View에 넘겨준다.
  7. View는 출력한다.

이렇게 정리될 수 있다는 것이다.


그래서 여기서 또 생긴 의문은 Controller가 2개 이상인 경우도 있는가?였다. 뭔가 우리가 그동안 해온 연습들은 다 controller가 1개였는데, 그럼 2개 이상인 경우는?에 대해 생각해보았고 첫번째 가설은

로직이 길어지면 controller 2개로 쪼개기
였다.

이 부분에 대해 Lotto로 설명하자면

  • 입력 -> 로또 발행
  • 결과 -> 출력

이렇게 나뉜다고 하자. 하지만 입력 -> 로또 발행한 내용을 아래의 결과 -> 출력 로직에서도 사용하기 때문에 서로 독립적이지가 않고, 이어줄 수 있는 매개체가 필요하게 되어 Controller가 서로를 이어주게(처리해주게) 되고, 그럼 이 두 로직은 model이 된다.

다음 가설은
사용자와 컴퓨터가 따로 있는 경우다.

이 부분은 예전에 풀어봤던 타노스 게임에서 생각해봤는데, 타노스 게임은 사용자쪽에서 실행하는 부분, 그리고 컴퓨터쪽에서 실행하는 부분이 나눠졌었다. 그럼 사용자쪽, 컴퓨터쪽 이렇게 나뉠 수도 있겠다 라는 생각을 했는데, 이 부분도 잘못 생각했었다.

만약 게임이 사용자 혼자 게임하기, 그리고 컴퓨터 혼자 게임하기로 나뉜다면 2개가 맞지만 이 부분도 사용자와 컴퓨터가 서로 상호작용하는 부분이 있기 때문에 controller는 하나가 되게 된다.

결론은 서로 독립적이지 않는 이상 controller는 하나라는 이야기이다.


최종 코테를 앞두고 계속 연습을 해가며, AI를 사용하지 않으니 생겨나는 의문점들도 많고, 확실히 짚고 넘어가고 싶은 내용들도 생기고 있는 것 같다. MVC 모델도 제대로 찾아보고, 애매한 부분을 해결하고자 하는 생각을 이전에는 못했었는데, 이번에 제대로 공부해보고 넘어갈 수 있게 되었다. 계속해서 연습을 해가며 헷갈렸던 부분들에 대해서 공부해나가면 좋은 결과가 있지 않을까 기대해본다!

profile
코린이의 코딩 도전기

0개의 댓글