[SI 커리어] SI 업계에는 DTO가 없다?

DTO

회사에서 프론트엔드 개발자로 근무하던 시절이다.

프론트엔드 개발팀 프로젝트 리더(PL)분께서 이런 말씀을 하셨다.

"타입스크립트를 사용하면 생산성이 너무 떨어지기 때문에, 타입스크립트는 안 쓰고 싶다."

그 때는 이 말이 이해가 되지 않았다.

타입(명세)를 작성하게 하면 인터페이스 사용자 입장에서 매우 편한데, 생산성이 떨어진다고?

한 회사의 개발(기술)팀 리더께서 왜 이런 말씀을 하셨을까?

---

DAO 대신 MAP

이 말의 의미를 자바 개발 프로젝트에 투입되어 알게 되었다.

이 프로젝트는 dto라는 개념이 존재하지 않으며, 자바 MAP(HASHMAP)을 파라미터 타입으로 사용하고 있었다.

그리고 어떤 필드가 있는지는 "주석"만으로 표현하고 있었다.

즉 db에서 가져온 데이터의 직렬화 결과 객체의 타입도 MAP이고, 클라에서 보낸 파라미터의 직렬화 결과 객체 타입도 MAP이다.

MAP 주도 개발

OKKY - 자바신입개발자로서 처음으로 vo(DTO)가아닌 map을 쓰면서 드는 생각. 답답합니다.

OKKY - 자바신입개발자로서 처음으로 vo(DTO)가아닌 map을 쓰면서 드는 생각. 답답합니다.

위 글을 읽어보면 알겠지만... 결국 개발 속도를 위해 TYPE 개념을 프로그래밍에서 배제하겠다는 것이다.

위와 같은 방식으로 프로그래밍을 하면... 자바 개발이나 자바스크립트 개발이나 별 차이가 없게 된다.

프로그래밍에서 TYPE(CLASS)란 개념이 사라지기 때문이다.

객체의 행동과 데이터를 캡슐화한다는 개념은 사라지고, 메서드 대신 펑션과 프로시저 라는 개념만 남는다.

[Java] Map보다 DTO 클래스를 사용해야 하는 이유 - MangKyu's Diary (tistory.com)

[Java] Map보다 DTO 클래스를 사용해야 하는 이유

여튼 이러한 요소 중 하나가 SI 개발자들의 성장을 가로막는 발목 중 하나라 생각한다.

솔직히 이렇게 파라미터의 타입 정의가 명확하게 되지 않는 문제가,

결과적으로 수많은 이슈 프로젝트들의 원인이 되는 연계 장애를 발생시키는 것이 아닌가 생각한다.

그리고 swagger와 같은 좋은 도구들의 활용도 저해시키는 것이 아닌가...

사실 뭐 문제삼을 것들은 한 두가지가 아니긴 하지만...

 

가끔 생각날 때마다 재미있는(?) SI 개발 이야기들을 한, 두편 더 적어야 겠다.