controller, service용 dto를 분리시키는 것에 대한 질문

안녕하세요, 재영님! :)
하나씩 답변 드리겠습니다.

1. dto를 분리할 때, 중복된 코드가 복잡성을 증가시킬 수도 있고 운영 시, 두 dto 간의 변환 과정의 비용이 어느 정도 성능에 영향을 미칠 수 있다고도 생각합니다.
2개로 분리하는 방법은 일반적인 설계 패턴은 아니라고 생각되는데, 혹시 현업에서도 자주 사용하는 방식이신지가 궁금합니다.

단순하게 보았을 때 복잡도는 증가한다고 볼 수도 있지만, 오히려 두 레이어가 같은 DTO를 공유했을 때 오는 복잡도가 훨씬 클 수도 있습니다. (유지보수 비용이 더 많이 들 수도 있고요.)
그리고 변환 비용은, 사실 요즘같이 하드웨어가 발달한 시대에 이 정도 변환이 성능에 미치는 영향은 무시해도 좋을 정도로 미미합니다. (메모리가 정말 중요한 임베디드 개발, 게임 개발 등을 하는 것이 아니라면요)
순수한 언어 레벨에서의 비용을 고려하기 보다는 오히려 다른 정말 중요한 포인트(네트워크, DB 등)에서 성능을 고려하고 개발하는 것이 더 중요합니다.

2. service에서 생성된 response 데이터에 대해서도 controller만의 response dto를 따로 생성할 필요가 있는지 궁금합니다.

Request 객체를 분리하는 이유는, Service 레이어가 Controller 레이어에 의존적이지 않도록 분리하기 위함에 있습니다.
반대로 이야기해서 Response의 경우는 (강의에서와 같이) Service의 Response DTO를 Controller가 사용하도록 하면 두 레이어 간 종속 관계의 방향을 유지하면서 설계하는 것이 되기 때문에 문제가 되지 않습니다.

3. 클라이언트로 내려주는 응답 객체로 controller 클래스에서 ResponseEntity는 사용하지 않으시는지,
주로 현업에서도 강의에서처럼 응답 객체(ApiReponse)를 커스텀해서 내려주는 방식을 선호하시는지 궁금합니다.

ResponseEntity를 사용하기도 하지만, 보통은 응답을 받는 쪽(ex. 프론트엔드, 다른 서버)과의 custom한 스펙이 적용되는 경우가 대부분이기 때문에 팀에서 공통 응답에 대한 스펙을 논의하여 적용하는 편입니다.

도움이 되셨기를 바랍니다.
감사합니다. :)

1. 단일책임원칙에 따라 개별적인 DTO를 사용하는 것이 일반적이라고 생각합니다. 필드가 완전히 대응되는 특별한 경우에만 중복 사용이 가능하도록 설계하는게 나을 것 같네요.

2. 서비스에서 생성된 Response는 ResponseEntity의 제네릭 인자로 리턴하면 될 것 같습니다.

3. 이건 컨벤션이나 개발명세에 따라 결정될 문제인 것 같습니다.