[우아한테크캠프Pro 2기] 1주차 미션 회고

1주차의 주제는 TDD였고, 미션은 문자열 계산기와 로또 게임이었다. 문자열 계산기는 사실상 몸풀기와 같은 느낌이었기에, 로또 게임을 하면서 더 많은 피드백과 깨달음을 얻었다. 

 

미션의 요구사항

프리코스 때와 마찬가지로 해당 미션의 기능적인 요구사항은 어렵지 않았지만, 프로그래밍적 요구사항이 날 정말 힘들게 했다. 요구사항 중에는 아래 앤솔로지의 객체지향 생활 체조 9가지 지침과 겹치는 부분들이 있다. 

ㆍ한 메서드에 오직 한 단계의 들여쓰기만 한다.

ㆍelse 예약어를 쓰지 않는다. 

ㆍ한 줄에 점을 하나만 찍는다. 

 

미션에 명시된 요구사항 이외에도 내가 개인적으로 세웠던 목표는 'MVC 패턴에 맞게 구현해보자' 였다. 지금 와서 생각해보면 특별한 목표나 이유가 있었던 건 아니었다. 사용자로부터 입력값을 받거나 사용자에게 결과를 알려주어야 하는 부분이 있었기 때문에, 무의식적으로 MVC 패턴을 따르는 것이 유지보수에도 용이하고(유지보수 할 일은 없겠지만 그래도 유지보수를 한다고 가정하면!) 각 객체들의 역할을 분리하기에 용이할 것이라고 생각했던 것 같다. 

---

1주차 미션을 완수하는데 걸렸던 시간은 대략 1주일 정도였다. 퇴근하고 나서 최소 2~4시간을 투자하고, 주말 이틀 내내 미션에만 집중했던 걸 감안하면 정말 오래 걸렸다. 지금와서 생각해보면 이 미션이 어렵게 느껴졌던 데에는 크게 3가지 이유가 있었다. 

 

첫 번째 이유 : MVC 패턴을 잘 몰랐다

정확히 말하자면 각 객체들의 역할에 대한 명확한 구분을 짓지 않은 상태에서 개발을 시작했기 때문에 코드 수정이 잦았다.

 

초반의 Application과 LottoController의 코드는 아래와 같았다. 이때 당시에는 Application은 어플리케이션 진입점의 역할만 하고, LottoController가 정말 모든 것을 컨트롤하자!라고 생각했었다. 틀린 생각이라고는 할 수 없지만, 딱히 깊은 생각 끝에 내린 결론은 아니었다. 그래서 요구사항이 추가 되었을 때 계속 우왕좌왕했던 기억이 있다. 커밋 이력에는 남지 않았지만, Application에서 모든 객체(InputView, Controller, LottoTickets)를 생성하는 방향으로 갔다가 다시 롤백한 적도 있고...여튼 혼자서 삽질을 정말 많이 했다. 처음부터 각 객체에 대한 역할이 잘 정의되었다면 그 정도까지는 아니었을 거라고 확신한다.

 Application 코드 : Controller 객체를 생성하고 메소드를 호출하는 역할만 한다

게다가 초반의 LottoController 코드에서는 View와 Model에 해당하는 객체들을 모두 멤버변수로 가지고 있다. 리뷰어님의 피드백 덕분에 최종 코드에서는 View에 해당하는 객체들만 변수로 가지고 있기는 하지만, 사실 그 마저도 조금 아쉬운 느낌은 든다. 

Controller에서 View와 Model에 해당하는 객체를 전부 가지고 있다

지금 다시 개발한다면 Controller의 역할을 조금 더 명확히 설정하고 시작할 것 같다. MVC 패턴에서 Controller의 역할은 Model과 View 사이의 연결고리가 되어주는 것이라고 생각한다. Model과 View 사이에서 중개자 역할을 하고 있다면, 굳이 Model 및 View 객체들을 변수로 가지고 있을 필요는 없을 것 같다. 

 

처음 개발할 때에도 위 생각을 안 했던 건 아니다. 굳이 Controller에서 View 객체를 가지고 있어야 하나? 생각했지만, Controller에서 View 객체를 가지지 않게 하려면 Application에서 View 객체를 가지고  있어야 했다. 근데 그게 괜히 찝찝했다. 진입점에 main 메소드가 아닌 다른 메소드를 만든 다는 게 좀 그랬는데, 왜 좀 그런지는 지금도 설명을 못하겠다. 어디에서 근원한 찝찝함일까?

---

두 번째 이유 : 유효성 검증을 어느 레이어에서 어느 정도까지 해야할 지 결정 내리기가 어려웠다 

 

일반 세계에서의 로또 번호를 생각해보자. 번호는 무조건 1부터 45까지만 있다. 하지만 사용자가 프로그램을 통해 로또 번호 값을 입력할 때 숫자만 입력하리라는 보장이 없다. 게다가 숫자를 입력한다고 해도 1부터 45 사이의 숫자만 입력할 것이라고 확신할 수 없다. 스페이스를 입력할 수도 있고, 한글 혹은 영어 혹은 특수기호를 입력할 수도 있다. 그렇기 때문에 개발자는 아래와 같이 크게 두 가지를 검증해야 한다. 

 

1) 입력된 데이터가 숫자인가?

2) 입력된 데이터가 숫자라면 범위(1~45) 내의 숫자인가?

 

미션을 진행하는 내내 1번과 2번의 검증을  View에게 맡길 것인가 Model에게 맡길 것인가를 결정짓지 못해 많이 헤맸다. 물론 지금은 그 기준을 조금은 쉽게 정할 수 있다. 비즈니스 로직과는 관계없이, 숫자라면 처리해야 할 1번 유효성 검증은 View에게 맡기고, 비즈니스 로직에 해당하는 2번 유효성 검증은 Model에게 맡길 것이다. 

 

하지만 처음 미션을 수행했을 때만 해도 이 기준을 정하는 것이 어려웠다. 경험이 부족해서일 수도 있고, 무조건적인 답이 있을 것이라고 생각해서일 수도 있다. 어쨌든 이 부분에 대해서도 리뷰어님께 피드백을 받았고, 최종 스텝에서는 1번 유효성 검증의 책임은 View에게, 2번 유효성 검증의 책임은 Model에게 위임하였다. 

 

하지만 이렇게 역할을 분리하고 나니 유효성 검증이 더 복잡해졌다. View부터 Controller, 그리고 Model 모든 객체가 '지속적으로'  협력해야 하는 로직이 되어 버렸기 때문이다.

 

'지속적으로 협력'한다는 말이 애매할 수 있어 이해를 돕기 위해, View에다가 1번과 2번 유효성 검증을 모두 구현했다고 가정하자. 그리고 이때 사용자가 로또 번호로 100을 입력했다. InputView에서는 100이 숫자 값에는 해당하지만(=1번 검증은 통과하지만) 45보다 큰 숫자이기 때문에 입력이 잘못되었음을 감지한다. 그러면 바로 에러 메세지를 내뱉게 되고, 이후 사용자가 올바른 값을 입력할 때까지 대략 아래와 같이while문을 통해 입력을 요청할 수 있다. (아래 예시에서는 Integer인지만 검증하기는 하지만, 숫자 범위까지 검증한다고 해도 비슷한 형태일 거다).

 

하지만 1번 유효성 검증과 2번 유효성 검증의 책임을 각각 View와 Model에게 위임하면 어떻게 될까? 이때 사용자가 100을 입력했다고 가정해보자. View 입장에서는 100이 숫자값에 해당하기 때문에 유효성 검증을 통과시키고 Controller에게 숫자를 전달한다. 그러면 Controller에서는 이제 Model에게 숫자 100을 전달하는데, Model에서는 숫자 100이 유효성 검증을 통과하지 못한다.  이제 Model에서는 Exception을 통해 Controller에게 이 사실을 알리게 되고, Controller에서는 OutputView를 이용하여 이 사실을 사용자에게 알린다. 그리고 InputView 를 통해 다시 사용자로부터 입력을 받아야 한다. 올바른 범위에 해당하는 값이 들어올 때까지 이 사이클을 무수히 반복해야 한다.

LottoController에서 사용자로부터 수동 로또번호를 입력받는 로직

 

즉,  위 코드의 첫번째와 두번째 노란색 박스와 같이 Controller 단에서도 while문을 통해 계속 검증을 수행하게 되고, 마지막 세 번째 박스의 메소드 내부에서도 입력값에 대한 검증을 수행하게 된다. 미션을 할 당시에는 이렇게 '검증'이라는 행위에 모든 객체가 참여하는 게 되게 어색하다고 생각했다. 그래서 만약 View 객체들을 Controller가 아닌 Application에 생성한다면 Application의 main 코드가 너무 복잡해질 것이라고 생각했다. 또 다시 첫번째 이유로 회귀하는 것 같은 느낌이 있는데, 어쨌든 Application의 코드가 복잡해지는 게 꺼려졌다. 내가 오 ㅐ그렇게 느끼는지 제발 그 이유를 찾고 싶다.  

 

지금에 와서 다시 보니 단순히 유효성을 '검증'하는 것에서 끝나는 것이 아니라 이 사실을 사용자에게 '안내'하고 다시 입력을 받아야 하니 View와 Controller, 그리고 Model이 모두 참여할 수 밖에 없는 것 같다.

 

---

세 번째 이유 : 한 단 들여쓰기가 너무 힘들었다 

여러 요구사항 중 날 가장 괴롭게 했던 건 '한 메서드에 오직 한 단계의 들여쓰기만 한다.' 였다. 코드를 통해 직접적으로 풀어쓰자면, for문이나 while 문 안에 if를 사용해서는 안 된다. 그럼 어떻게 하냐? if문을 요구하는 로직은 메소드로 분리하면 된다.

 

굉장히 쉬운 해결방법 같지만, 의외로 어렵다. 그 동안 내가 너무 절차지향적으로 개발을 해왔나 싶으면서도 솔직히 가끔은 '아 진짜 이렇게까지 해야 돼?'라는 생각도 들었다. 메소드로 분리는 할 수 있는데 그렇게 분리한 메소드는 정말 그냥 코드를 분리한 것 이외에는 의미가 없어보였기 때문이다. 물론 지금은 else를 보면 나도 모르게 '아 좀 어색한데...' 할 정도로 짧은 시간 안에 한 단계 들여쓰기에 익숙해져버렸고, 이렇게 빡세게 연습함으로써 얻는 이점도 느꼈다. 

습관적으로 else로 문제를 해결하기 전에 '혹시 이 메소드를 분리해서 재사용할 수는 없을까?' 생각해보게 됐고, 굳이 else를 사용하지 않고 빠르게 return해도 되는지 확인해보게 되었다. 

---

어쩌다 보니 첫번째 회고가 넘 길어져버렸는데, 사실 개발하면서 든 온갖 고민과 잡생각의 반에반에반도 안 된다. 이 미션 덕분에 오랜만에 자바로 개발해보기도 했고, 처음으로 TDD라는 걸 해보기도 했어서(하지만 TDD를 했다고 말하기 부끄러울 수준의 TDD였다) 가장 애착이 가고 아쉬움도 많이 남는다.