[Lv.1 - 블랙잭] 실제가 다가 아니다

본 글은 2025년 3월 11일 ~ 2025년 3월 18일 사이의 시간을 다룹니다.

 

블랙잭 미션

이전에 블랙잭 미션의 페어 우가와 객체 지향의 낭만이 가득 담긴 코드를 작성했었다. 작성할 때만 해도 정말 즐거웠고, 내가 배운 개념들을 코드에 녹여내는 것이 좋았다.

하지만, 구현이 모두 끝나고 나서 설계를 다시 바라봤을 때 하나의 객체에 책임이 너무 집중되어 있는 모습이 되어있었다.

결합도가 높고 응집도가 낮은 코드를 완성하게 되어서 무엇이 문제인지 회고해보았다.

 

우가와 처음에 블랙잭 step1을 했을 때는, 카드 객체가 점수 계산을 하는 것이 이상하다고 생각했다. 그러면 카드 객체는 더 이상 '카드'가 아니라, 블랙잭 규칙을 알고 있는 '카드'가 되기 때문이었다.

하지만, 다시 생각해 보면 카드에 점수 계산 로직이 있는 것은 전혀 이상하지 않다. 점수로 쓰이는 카드의 정보는 '카드'가 제일 잘 알고 있기 때문에, 정보와 행위의 응집도를 위해서라면 카드가 점수를 계산하는 것이 당연하게도 합리적이다.

 

이러한 사고 흐름은, 너무 극단적으로 객체를 실세계의 물체 혹은 무언가에 대한 proxy로 생각하기 때문이라고 생각을 정리했다.

 

처음 카드 클래스를 설계할 때, 이것을 현실 세계의 '카드'라고 생각했다. 실세계 카드가 가지고 있는 정보를 가질 수 있고, 그 이외의 것을 가진다면 그것은 예측하기 힘들다고 생각했다. 객체 지향 설계의 장점 중 하나는 특정 행위가 어떤 객체에 있을 것이라고 쉽게 예측할 수 있다는 것인데, 카드가 점수 계산을 가진다는 것은 예측하기 어렵다고 생각했다.

 

다른 클래스인 '카드덱'도 마찬가지다. 실세계의 카드덱처럼 카드 집합을 가지고, 카드를 하나 뽑거나, 섞을 수 있다.

사실 뽑거나 섞는 것은 실세계의 카드덱과는 상이한 부분이 있다. 실제로 카드덱은 살아있는 존재가 아닌, 수동적인 물체이다. 따라서 실제로는 직접 카드를 뽑아주거나 섞어줄 수 없지만, 수동적인 물체로 설계한다면 데이터 중심 설계가 될 위험이 있고, 캡슐화를 지키지 못하기에 오브젝트에서 나온 '의인화'처럼 객체를 '의인화' 했다. 이것이 많은 사람들이 말하는 객체지향 세계와 실세계와의 간극이라고 생각했다.

하지만, 이런 생각으로 하나의 설계를 완성하고 나니 생각이 완전히 뒤바뀌었고 새로운 인사이트를 얻었다.

 

객체지향 세계와 실세계와의 간극이라는 건 단순히 객체의 특징인 의인화를 일컫는 말이 아니라, 우리가 객체를 설계할 때 객체는 실세계의 물체에 대한 대리자(proxy)처럼 역할이 있고, 책임이 있는 것으로 간주하지만, 우리가 추구하는 유연한 설계(캡슐화 - 응집도, 결합도)를 위해 충분히 변경될 수 있다는 말이다. 아니 변경되어야 한다. 블랙잭 미션을 구현하는데, 카드와 카드덱이 실세계와 100% 일치한다면 현재 프로그램에서 협력이라는 문맥을 생각하면서 설계를 하고 있는지 검토해야 할 필요성이 있다.

 

내가 블랙잭 미션에서 작성한 객체들은, 실세계를 모방하고자 할 뿐 협력이라는 문맥을 고려하지 않았고- 결국 응집도가 낮은 코드의 작성으로 이어졌다.

 

결론적으로, 객체지향 세계와 실 세계는 간극이 있다.

아름다운 실 세계 모방 설계가 아닌, 변경에 유연한. 즉, 결합도가 낮고 응집도가 높은 코드를 작성해야 한다.

 

 

 

왜 쓰는가?

멋진 개발자로 성장하기 위한 학습 태도를 하나만 말할 수 있다면, "의심하기."라고 말할 수 있을 것 같다.

왜 DTO를 쓰는가? 왜 MVC 패턴을 쓰는가? 왜 View 계층을 나누고, 또 그것을 I/O라는 이분법적 개념으로 분리하는가?

왜 프로그램에 대한 시작 클래스는 항상 Application으로 끝나는가?

 

우리는 생각보다 이유를 알지 못하고, 그냥 그래왔으니까 혹은 주변에서 그러니까 사용하는 것들이 많다. 또 학습 태도와 메타인지에 대한 훈련이 부족할수록 더 그럴 수 있다. 

 

2025년 3월 5일, 갑작스럽게 든 생각

 

 

우리는 왜 유행처럼, 갑자기 객체지향을 공부하다가 MVC 패턴을 사용할까?

사실 나도 의문을 제기하긴 했지만, 모두가 사용하니까 당연하다고 생각했다. 코치 '구구'가 없었으면 계속 이런 학습 태도를 가지고 있었을 수도 있다. 나에게 이러한 태도를 이끌어준 '구구'께 정말 감사하다.

 

정말 웃기게도, 블랙잭 미션에서는 MVC라는 디자인 패턴을 사용하는 합리적인 이유가 없지만 우아한테크코스 크루 중 90%는 MVC 패턴을 사용했다. 왜 아무도 의심을 안 했을까? 우리는 너무 익숙함과 당연함에 길들여져서, 우리만의 잣대 없이 남들이 정해준 디자인 패턴이라는 정답지를 따라가고 안정감을 느끼는 것은 아닐까? 그것이 과연 진짜 학습일까?

 

위 문장은 이번 기간 동안 나를 포함해서 많은 크루들이 (특히 구구조의 크루들) 깊게 깨달은 부분이다.

합리적인 추론 과정을 통해 MVC 패턴을 사용해야 할 이유를 찾아봤지만, 콘솔 프로그램에서 MVC을 적용하는 것은 너무 명확한 단점들이 있었고 사용할 이유가 거의 없었다.

 

이 일로 인해 충격을 받았다. 나는 왜 지금까지 MVC 패턴을 사용했는가? 과거를 회상해 보면 프리코스 2주 차 때부터, 주변 사람들이 MVC 패턴을 사용하는 것을 보고 나도 적용해 봤던 것 같다. 그리고 MVCS가 더 고급스러워 보여서 Service 계층도 적용해 봤다. 그러자 관심사 분리.. DTO.. 같은 디자인 패턴과 함께 학습해야 할 내용들이 쏟아졌다.

 

현재 나의 학습 목표는 분명 객체 지향 설계인데 어쩌다가 디자인 패턴에 몰두해서 객체들의 역할, 책임, 협력에 대해 고민할 시간이 줄어들었다는 것에 회의감을 느꼈다.

 

내가 당연하다고 믿은 것이 이렇게 깨지니까, 내가 작성하는 모든 코드에 대한 신뢰가 깨졌고- 내가 작업하면서 봤던 수많은 레퍼런스에 대한 신뢰가 깨졌다. 남은 건 나의 판단밖에 없었다.

 

이후로 내가 평소에 익숙하게 사용했던 모든 것들을 의심해 보기 시작했다. 그러자 이렇게 작성한 이유를 모르겠지만, 내가 작성한 코드가 수두룩 나왔다. OutputView와 InputView도 진짜 이상하다. View 계층이 뭔지는 알겠는데, 왜 이것을 입력과 출력이라는 이분법적 개념으로 나누는가? 심지어 나눴으면서 왜 InputView에서는 입력을 위한 출력 행위를 하는가? 나는 개념들이 많이 혼재되었고 나의 학습이 올바른 방향으로 가지 않고 있음을 느꼈다.

 

인터넷 검색을 왜 하고, 책을 왜 읽는가? 

우리가 보통 책을 읽는 이유는, 특히 기술에 관련된 책을 읽는 경우는 책에 있는 정보가 사실이라고 가정하고 그것을 정답지처럼 내 것으로 습득하려는 목적일 것이다. 인터넷 검색도 신뢰도는 조금 더 낮겠지만 똑같은 목적이다.

 

하지만 이 방법으로는 정말 자신만의 판단과 이해력을 가진 개발자가 될 수 없다. 만약 그것을 정답지처럼 여기고 습득하고자 한다면,

"사실은 그것이 올바를 것이라고 믿는 것이지 그것이 올바르다고 생각하는 것이 아닐 수 있다."

 

실제로 책이나 레퍼런스를 참고하면서 "이 내용은 약간 다르다. 책이 거짓말을 하고 있다."라고 느낄 때가 꽤 많았고, 심지어 코치나 리뷰어가 조금 잘못된 판단 기준을 가지고 있다고 생각한 적도 있다. 실제로 2주 차 미션 때 리뷰어의 피드백에 대해, "나는 이렇게 생각하고, 리뷰어가 피드백 한 부분은 잘못된 것 같다."라고 말해서 리뷰어의 의견을 설득(반전) 시킨 적이 있다.

 

나에게 들어온 지식을, 상대방의 신뢰를 척도로 삼아 받아들이지 말고- 그것이 정말 올바른지, 올바르지 않은지는 오직 나만의 사고 과정을 통해 도출되어야만 한다. 그렇지 않으면 내가 올바르다고 생각하는 것이 아니라 올바르다고 믿게 된다. 이것을 깨달으면 점점 아무것도 믿지 않게 된다. 

“책이나 블로그를 쓴 사람과 나의 차이는 그들이 글을 썼다는 것 뿐임. 그들의 의견이 사실이 아님을 항상 염두에 두어야 함. “

 

이러한 태도를 얻게 된 이후에는, 앞으로의 학습 과정의 효율이 달라지고 새로운 시야가 생기게 된다.

가짜 학습으로 학습의 품질을 낮추지 말자.