[4주 차] 회고

 

4주 차 미션이 끝났습니다!!!!!!!!!!!!!

 

프리코스 끝나면 후련할 줄 알았는데, 마지막 미션에서 테스트 케이스 하나도 통과 못한게 너무 아쉬워서 미련만 남습니다.

 

테스트 불통 ㅠ

 

 

솔직히 모든 테스트 통과 할 줄 알았는데, 통과 못한게 너무 충격적이었습니다. 

 

진짜 통과 못한 것만 기억에 남아서, 제출 하고도 계속해서 분석했고 답을 찾아냈습니다.

 

테스트 통과하지 못한 이유 분석

 

테스트 불통의 원인

 

이번 요구사항 중에, resourse 패키지 안에 들어있는 products.md , promotions.md 파일의 정보를 읽어와 데이터를 읽어들이는 요구사항이 있었습니다.

 

그래서 저는 해당 파일이 들어있는 경로를 복사하여 객체에 주입함으로서, 데이터를 받도록 하였습니다.

 

하지만 파일 경로를 제 컴퓨터 경로가 포함된 절대 경로로 설정한 것이 문제였습니다. 

 

제가 작성한 코드를 깃허브에 푸시하게 되면, 다른 사람 컴퓨터에서는 당연히 실행 될 리가 없었습니다. 제 컴퓨터 경로의 파일을 설정했으니까요.... 상대 경로로 설정해야 했습니다. 

 

패키지에 포함되어 있는 ApplicationTest 도 모두 문제 없이 다 통과하고, 왜 이런가 했더니.... 이런 실수를 저질러버렸습니다. 새벽 6시까지 잠 안자고 오류를 찾은 보람이 있긴 했습니다 ㅋㅋㅋ..

 

정말 아쉽긴 하지만, 되돌아 가더라도 저 실수는 발견하지 못했을 것 같아요 ㅎㅎ.. 미션 문제가 너무 어렵기도 했고, 테스트 불통 뜨자 마자 머리가 새하얘져서 아무 생각도 안났어요 ㅋㅋ

 

그래도 이유를 알았으니 만족하렵니다. 다음부터 파일 경로는 다른 사용자를 위해서, 상대 경로로 설정해야겠어요... 아아아아아아 지금까지도 많이 아쉽네요.

---

 

지금까지는 제 찡얼거림과 한탄이였고요, 본격적으로 회고를 시작해보겠습니다.

 

이번 미션은 정말 어려웠습니다. 문제를 보자마자 요구사항이 너무 많아 어떻게 코드를 구현해야 할지 막막했습니다. 

 

하지만...!! 저에겐 숨겨진 무기가 하나 있었습니다. 바로 도메인 분석입니다.

 

로또 미션을 TDD로 진행하며, 3번이나 갈아엎은 경험을 통해 다져진 도메인 분석이 빛을 발할 때가 왔던 것 같습니다. 

 

 

잘한 점

 

이번 미션의 목표는 객체 지향을 최대한 지키는 것이었습니다. 문제 난이도가 어려웠기 때문에, 제대로 분석하지 않고 시작하게되면 모든 객체지향이 무너질 것이라고 생각했고, 분석부터 철저히 하자고 생각했습니다. 

 

큰 단위부터 작은단위로 도메인을 어떤식으로 나눌 것인지 분리 하였고, 각 도메인 마다 어떤 역할을 해야 할 지 정했습니다. 정말 세세하게 파고들어 분석하였고, 이 과정만 이틀은 걸린 것 같습니다. 이 과정에서 객체가 어떻게 상호작용할 지 많은 고민을 했던 기억이 납니다.

 

도메인을 세세하게 분석하니, 기본 뼈대를 잡는 것은 너무나도 쉬웠습니다. 필드에 필요한 요소가 많아 보였지만, 각각을 원시값 포장 객체로 만들어 사용하니 객체 간 상호작용도 자연스럽게 이루어졌고, 하나의 객체에 너무 많은 역할이 몰리는 것을 방지할 수 있었습니다.

 

이 덕분에 TDD도 잘 지켜서 구현할 수 있었고, 로직 자체에 수정사항이 생기더라도, 기본 베이스로 깔아둔 객체들은 크게 수정할 필요가 없어서 나름 행복했던(?) 기억이 납니다.

---

그리고 원시값 포장 객체를 필드로 사용할 때, 한 가지 고민이 생겼습니다. 예를 들어 Product 클래스에 Price라는 원시값 포장 필드가 있다면, getPrice().getPrice()와 같은 형태로 값을 가져와야 하는 상황이 어색해 보였습니다.

 

이 문제를 해결하기 위해 우테코 블로그를 찾아보면서, "객체의 내부 구조는 외부 객체가 알 필요가 없다"는 원칙을 참고하게 되었습니다. 이를 기반으로, getPrice() 메서드 하나로 값을 반환하도록 리팩터링해 문제를 해결할 수 있었습니다.

---

또한, 이번 미션에서는 "보여주는 역할"과 "생성하는 역할"을 명확히 분리해 객체를 구성해보았습니다. 기존에는 생성하는 역할을 맡은 객체가 동시에 보여주는 역할도 담당하도록 했습니다.

 

생성된 정보를 통해 보여주는 기능까지 쉽게 제공할 수 있다고 판단했기 때문입니다. 하지만 시간이 지나면서 하나의 객체에 너무 많은 정보와 책임이 쌓여가고, 그로 인해 유지보수가 어려워지는 문제를 겪게 되었습니다. 객체의 책임이 커지면서 코드의 가독성과 응집도가 떨어졌습니다.

 

이를 개선하기 위해 생성과 표현을 분리하고 각 역할을 명확히 나누니, 코드 구조가 훨씬 깔끔해졌고 리팩토링도 수월했습니다.

 

특히, 보여주는 역할만을 하는 객체의 반환 값으로 모두 DTO를 사용했습니다. 이전에는 컨트롤러에서 개별 값을 받아 각각 포장했지만, DTO를 통해 반환된 값을 바로 View에서 처리할 수 있어 더 가독성 높은 코드 구성이 가능해졌습니다. 해당 과정을 통해 객체의 책임이 명확해지고, 전반적인 코드 품질이 향상되는 경험을 할 수 있었습니다.

 

 

아쉬운 점

 

프리코스에서 제가 추구했던 방향은 MVC 패턴을 구현하되, 도메인과 뷰 간의 의존성을 완전히 분리하는 것이었습니다.

 

그러나 마지막 미션에서 “프로모션 재고에 해당하지 않으면 메시지를 안내하라”는 요구사항이 제시되면서 Service 계층 사용에 대한 고민에 빠졌습니다.

 

정말 몇십 번은 Service를 사용할까 말까 고민했습니다. 하지만 Service 계층을 사용하면, 제가 MVC 패턴을 통해 구현하는 의미도 없어지고, 도메인과 뷰 간의 의존성을 완전히 끊어내는 노력이 헛되는 것 같았습니다.

 

오랜 고민 끝에 새로운 해결책을 찾기 위해 DDD(도메인 주도 설계) 방식을 공부하게 되었고, 그 과정에서 Domain Service라는 개념을 알게 되었습니다. 이를 통해 Service 계층 없이도 도메인과 뷰의 의존성을 끊어내면서 문제를 해결할 수 있었습니다.

 

그러나 제가 도메인 서비스를 목적에 맞게 정확히 사용한 것인지 의문이 듭니다.

 

미션 자체가 어려웠고, 다른 방법이 떠오르지 않아 급하게 개념을 익히고 사례를 찾아 사용하긴 했지만, 이 방식이 정말 맞는지에 대한 확신이 부족했습니다. 확실한 목적을 알지 못한 채 적용하다 보니, 제 코드에 대한 자신감이 점점 떨어졌습니다. 

 

정말 "하나를 쓰더라도 제대로 알고 쓰자"라는 말이 떠오릅니다.

 

---

이렇게 4주가 끝났습니다.  유종의 미를 거두지 못한 것 같아 많이 아쉽습니다.

 

원래 통신에 관심이 많았지만, 프로그래밍 세계에 발을 들이게 되었고, 그런 저에게 있어서 프리코스는 한 줄기 빛과 같았습니다. 실력 있는 동료들의 코드를 보면서 새로운 관점을 얻고, 큰 동기부여를 받으면서 부족한 점들을 채워나갔습니다.

 

정말 우테코에 도전하지 않고 혼자 독학했다면 어땠을까 싶을 정도로 많은 지식과 경험을 쌓을 수 있었던 시간이었습니다. 이번 과정을 통해 저라는 사람이 공부뿐만 아니라 다방면에서 성장할 수 있었음을 느낍니다.