인프런 커뮤니티 질문&답변
작성한 질문수
그럼에도 결코 수긍하지 않는 사람들이 있으니 말이죠
해결된 질문
작성
·
242
·
수정됨
1
토비님의 의견에 동의합니다.
화면에서 필드 하나 필요하다는 수정사항을 처리하기 위해 Presentation 레이어 이외의 클래스들을 수정하고 싶진 않아요.
그럼에도 불구하고 현업에선 정말 수많은 이유를 들어서 DTO로 반환하는 걸 유지하려고 합니다.
별도의 관심사를 끌어안게 되면서 애플리케이션 레이어의 테스트 코드 작성이 까다로워지고, 그로 인해 안정성이 하나씩 무너지고 균열이 생기기 시작하는 지점이 이곳이지 않을까 싶어요.
어찌보면 강의를 들을까 고민하던 때에 가장 매력있게 보였던 챕터였고, 무언가 해답을 얻을 수 있을까 했지만 여전히 뭔가 용기가 생기진 않는 것 같습니다.
물론 그것이 토비님 탓은 아니죠. 훌륭한 가르침이지만, 단지 이것을 제 현장에 전파할 때 발생할 어려움에 벌써 머리가 아파지는 것.. 그 뿐입니다.
질문은 아니고 그저 넋두리였습니다.
나머지 강의 마저 잘 들어보겠습니다. 감사합니다
답변 1
4
현장에서 수많은 이유를 들어서 ORM 도입을 거부하고 SQL에 로직을 담고 직접 다루는 코드를 유지하려고 했던 시절이 있습니다. 제가 2003년 부터 ORM을 썼고 도입을 주장해왔지만 한국 자바 개발자들 사이에 어느 정도 받아들이기 시작한 건 그 뒤로 십 년이 넘은 것 같습니다. 비슷하게 자바에서도 꽤 오랜동안 오브젝트에 데이터를 담는 대신 맵을 사용하는 것을 유지하려고도 했었죠. 각각 다 이유가 있었고, 그 선택을 적절한 트레이드 오프라고 생각했던 것 같은데 대체로 깊이 있는 고민 없이 단편적인 주장 하나로 관습을 유지하려는 듯해서 매번 아쉬웠습니다. 그래도 시간이 지나니 바뀌긴 하더라고요.
저는 예전에도 그랬던 것처럼 유행하는 방식이 어떤 것이든지 상관없이, 충분한 고민을 통해서 선택한 원칙에 맞는 방식으로 코드를 작성하는 방법을 따르고 이를 기회가 되는 대로 이야기할 것입니다. 언젠가 또 변화가 있을지도 모르죠. 사실 서비스 계층에서 엔티티를 리턴하는 방식은 스프링 등장 초기부터 사용해왔던 더 오래된 방식입니다. 거기에 OSIV 논쟁이 결부되고, 대용량 서비스에서 성능을 극한으로 끌어올려야 한다는 명분으로 여러가지 변칙적인 대안을 선택을 하던 것에서 출발해서 DTO를 만들어 리턴하는 방식이 보편화 되었고, 이를 지지하는 논리가 희한하게도 계층형 아키텍처의 규칙에 충실해야 한다는 것이어서 의아했긴 합니다.
그래도 이런 이야기를 할 수 있는 기회가 있어서 좋습니다.
흥미롭네요! DTO 이전에 OSIV 논쟁이 있었는지는 처음 알았네요. 😲
소 뒷걸음질 치다 쥐 잡은 격이네요.