인프런 커뮤니티 질문&답변

네, 조영호님의 말씀을 다음과 같이 이해했습니다.

• 관습적인 사고가 만들어 어떤 현상(?)

• 객체지향은 배우고 적용하기가 어렵기 때문.

이렇게 이해했습니다 😀 충분히 설명되었습니다 감사합니다.

그렇다면, 후속질문으로 이런 생각이 드는데요. 앞서 과거 개발 문화에 대한 궁금증이였다면, 조금 현시점의 관점에서 질문드리고 싶어요.

질문에서 언급드린것과 같이 도메인영역을 빈약한 도메인 모델과 트랜잭션 스크립트 패턴을 활용하는 개발자 무리가 있을 때, 개발자 무리가 "이렇게 코드를 작성하더라도 문제가 되지 않아! 우리는 충분히 요구사항을 반영할 수 있잖아!" 라고 말한다면, 조영호님이 전달해주시는 객체지향은 의미가 없어지게 될 수도 있을 것 같아요.

앞서 언급주신 것처럼 이것이 문제라고 생각하지는 않습니다. 모두가 문제가 아니라고 할 때, 한 사람만 문제라고 말한다면- 그것은 문제가 아니라고 생각하는데요.

이런 개발 문화를 가진 팀(회사)이라면, 객체지향 프로그래밍에 대해 설득하는 과정이 필요할 수도 있고, 아닐 수도 있을 것 같아요.

조영호님의 주관적인 생각이 궁금한데요, 이런 팀(회사)에서 객체지향에 대한 의미를 전달하고자하는 노력이 필요할까요?

(어떤 정답을 바라고 질문드리는 부분은 아닙니다. 조영호님도 비슷한 상황을 겪어보지 않았을까? 그럴때 어떻게 행동하셨는지 궁금하기도해서 여쭤봐요)

굉장히 민감한 이슈이고 대답하기 조금은 조심스러운 질문인데요

결론부터 말씀드리면 현재 적용한 트랜잭션 스크립트가 유지보수 측면에서 문제가 있다면 동료분들을 설득해서 더 좋은 방향으로 코드를 수정하는게 맞다고 말씀드리고 싶어요.

지금부터 제 생각을 말씀드리도록 하겠습니다.

개발자는 코드를 작성할 때 기능과 구조라는 두 가지 관점을 고민하게 됩니다.

• 기능은 사용자에게 제공하는 시스템의 행동을 의미합니다. 강의에서 예제로 사용한 상영 예매 기능을 떠올려보시면 될것 같은데 이 기능은 사용자가 특정한 시간대의 상영을 예매할 수 있는 행동을 제공합니다.

• 구조는 기능을 구현하기 위한 코드의 배치를 의미하며 우리가 설계라고 이야기할 때는 코드의 구조를 의미합니다. 하나의 기능은 여러 종류의 구조로 구현할 수 있습니다. 강의에서는 상영 예매 기능을 절차적인 방식과 객체지향적인 방식으로 구현했습니다.

동일한 기능을 다양한 구조로 설계할 수 있다는 이야기는 각각의 설계 방식에 따라 장단점이 있을 수 있다는 것을 의미합니다.

이제 첫 번째 질문에 대해 제가 답변 드렸던 내용을 다시 살펴보겠습니다.

실제로 객체지향으로 설계를 많이 하는지 궁금합니다나 객체지향은 여전히 유용한가에서 말씀드린 것처럼 절차적인 방식이 무조건 나쁜것은 아니고 객체지향이 적합한 곳에 절차적인 방식으로 코드를 작성할 경우에 문제가 된다는 사실을 먼저 말씀드리고 싶습니다.

위 답변에서 '절차적인 방식이 무조건 나쁜 것은 아니라는' 이야기는 동일한 기능을 절차적인 방식으로 설계하는 것이 적합한 경우도 있고 적합하지 않은 경우도 있다는 것을 의미합니다.

그리고 '객체지향이 적합한 곳에 절차적인 방식으로 코드를 작성할 경우에 문제가 된다'는 것은 동일한 기능을 객체지향으로 설계하는 것이 더 적합한 경우에 절차적인 방식으로 코드를 설계해서는 안된다는 것을 의미합니다.

그리고 이 말은 객체지향에도 동일하게 적용할 수 있습니다.

객체지향이 적합하지 않은 경우에 객제지향을 적용하는 것 역시 문제라고 할 수 있습니다.

객체지향은 여전히 유용한가 발표를 보시면 어떤 경우에 객체지향이 적합한 때와 절차적인 방식이 적합한 때를 구분하실 수 있으실거에요.

질문에서 언급하셨던 "이렇게 코드를 작성하더라도 문제가 되지 않아! 우리는 충분히 요구사항을 반영할 수 있잖아!"라는 말은 구조는 생각하지 않은 채 기능 측면만을 고려한 이야기입니다.

과장을 조금 보태자면 "같은 기능을 구현할 때 변수명을 a, b, c로 선언하고 goto문을 사용한 스파게티 코드를 작성해도 문제가 되지 않아!"라는 말과 흡사합니다.

따라서 어떤 경우에 어떤 구조가 적합한지 트레이드오프하지 않았기 때문에 위와 같은 주장은 잘못된 것입니다.

최종적으로 빈약한 도메인 모델과 트랜잭션 스크립트 패턴을 적용하는게 적합하다고 결론이 나더라도 그 이유가 명확해야 하고 동료 개발자들에게 설득할 수 있어야 하겠죠.

마찬가지로 무조건 "객체지향적으로 코드를 작성하더라도 문제가 되지 않아! 우리는 충분히 요구사항을 반영할 수 있잖아!"라고 말하는 것도 잘못된 접근 방법입니다.

객체지향 설계가 적합한 경우와 적합하지 않은 경우가 있기 때문이죠.

강의에서도 계속 강조한 것처럼 어떤 설계가 적합한지를 결정하는 것은 요구사항의 변경입니다.

결론적으로 어떤 설계가 적합한가는 코드 작성 관점이 아니라 유지보수 관점에서 판단해야 합니다.

따라서 애플리케이션의 특정 부분의 요구사항이 객체지향 설계가 적합한 방향으로 변경되고 있다면 개발자분들을 설득해서 설계를 개선할 필요가 있습니다.

제 개인적으로 회사에서 일을 할 때 동료 개발자분들께 객체지향 설계를 이해시키는 것이 더 쉬웠는데 함께 유지보수하는 시스템의 요구사항이 실제로 변경되고 있기 때문입니다.

좋은 설계는 요구사항이 변경될 때 코드를 쉽게 변경할 수 있도록 해주기 때문에 실제 코드를 통해 객체지향 설계의 장점을 이해시키면 그래도 잘 납득해 주시더라구요.

이런 설득 과정에서 다소 미묘하고 껄끄러운 이슈들이 발생할 수 있기는 한데 제 개인적인 경험으로는 결국은 실제로 동작하는 코드를 보여드리고 그 설계가 기존 설계보다 어떤 측면에서 더 개선됐는지를 설명드리는게 가장 효과적인 방법이었어요. 🙂

적다 보니 설명이 길어졌는데 더 궁금한 부분이 있으시면 추가 질문 부탁 드릴게요.

다소 질문의 관점이 강의에 대한 이야기가 아닐 수 있음에도 불구하고, 영호님께서 생각하시는 바에 대해 답변주셔서 감사합니다.

객체지향프로그래밍에 대해서 개인적인 경험을 가지고 있고, 강의에서 말씀해주신 객체지향에 대해서도 격하게 공감합니다. 공감하면서도 한편으로, 설득의 과정을 만들기 어려운 환경에 대한 아쉬움에 대해 토로하고 싶었을 수도 있을것 같아요.

다시한번 진심으로 답변 주셔서 감사합니다. 그리고 좋은 강의를 만들어 주셔서 감사합니다. 이 강의를 통해 더 많은 미래의 동료 개발자가 코드를 작성할 때, 객체지향에 대해 한번더 고민하고 코드를 작성하는 날이 올 수 있도록 저도 열심히 홍보하겠습니다.

오프라인 강의를 하다보면 멍때리기대마왕님과 비슷한 고민을 하시는 분들과 이야기를 나눌때가 있는데 안타까운 경우도 많더라구요.

저도 비슷한 고민을 했던 시기가 있다보니 어떤 말씀인지 잘 이해하고 있습니다.

개인적으로 개발과 관련해서 다양한 이야기를 나누는 일이 즐겁기 때문에 강의와 상관이 없더라도 서로의 생각을 나눌수 있는 주제가 있으면 편하게 올려주셔요. 🙂

그리고 나중에 오프라인에서 뵐 일이 있다면 멍때리기대마왕님이라고 말씀해 주시면 꼭 기억하고 인사드리겠습니다.

부족한 강의 들어주셔서 정말 감사드리고 행복한 주말 보내세요!

영호님과 이야기나눈 것에 대해서 작은 저의 생각에 대해 글로 작성해봤어요.

[링크] 왜 사람들은 빈약한 도메인 모델을 만들어 활용할까?

어떤 피드백을 받고자 하는건 아니고, 이 글을 보시는 다른 분들에게 추가적으로 도움이 될 수 있는 내용이 있을까 싶어 첨부드립니다.

영호님도 행복한 하루 보내세요!