서비스에서 필요한 스택과 SI에서 필요한 스택은 180도 다릅니다.



1) 대부분의 서비스 기업은 '자체 서비스를 만들기 위한 개발' 을 합니다.

망하는 걸 가정하고 시작하는 스타트업은 없으므로

최대한 오래 기능할 수 있는 단단한 코드를 작성하는 데 시간을 많이 씁니다.

만든 사람이 유지보수 해야하기 때문입니다.

따라서 코드에 업무 도메인이 많이 녹아있는 형태로 개발이 진행됩니다.

데이터 핸들링과 도메인 객체를 코드로 표현하기 위해 위해 ORM을 쓰고,

유지보수에 필요한 코딩량을 줄이기 위해 파이썬이나 노드 등의 스크립트 언어를 주로 채택합니다.



2) SI 는 '남이 쓸 프로그램' 을 만듭니다.

프로젝트의 당면과제는 고객 만족이 아니라

정해진 시간 내에 기능 목록을 몇 % 이상 완성할 수 있는가 입니다.

하지만 시간은 정해져 있는데, 고객의 요구사항은 프로젝트 중간에 거의 무조건 바뀝니다.

그래서 모든 비즈니스 로직을 쿼리에 담는 D.D.D.(DB주도 개발) 방법이 정착되었습니다.

조금 더 자세히 말해보겠습니다.

개발 도중 고객의 요구사항이 변경되면, 높은 확률로 DB의 스키마가 변경되어야 합니다.

만약 비즈니스 로직이 자바 코드에 녹아있다면, DB 테이블과 1대1로 매핑되는 객체도 변경해야 합니다.

당연히 해당 객체를 참조하는 모든 소스 코드와 View 영역에도 수정이 불가피 합니다.

시간은 없는데 요구사항 변경 스케일이 크다면 야근을 넘어 철야와 주말출근도 빈번하게 해야합니다.

그래서 SI 개발자들은 특정 테이블의 값만 담을 수 있는 객체(DTO, VO) 대신

'뭐든지 담을 수 있는 객체' 를 활용하도록 진화했습니다.

대표적인 것이 Map 과 List 입니다.

컨트롤러에서 요청을 받을 때부터 서비스를 거쳐 실제 쿼리가 실행될 때까지 일관성 있게 Map 을 사용하고,

반대로 값을 반환받을 때는 일관성 있게 List 타입으로 받게 코드를 작성한다면

DB의 변화에 프로그램이 영향을 최소한으로 받는 형태로 개발할 수 있게 됩니다.


여기서 한 걸음 더 나아가서 모든 비즈니스 로직을 PL/SQL 로 작성한다면

자바와 스프링은 거의 아무런 처리도 하지 않게 만들 수 있습니다.

요청은 그대로 DB로 보내고, 모든 로직은 프로시저로 처리하고, DB의 응답을 그대로 View로 쏴준다면

더 더욱 변경에 강한 프로그램을 만들 수 있습니다.

이제 개발자들은 수정 요구사항이 들어와도 SQL 쿼리만 변경하면 됩니다.

요구사항이 변하지 않는 프로젝트라 하더라도, 이미 수 많은 변경을 경험했기에 다들 이런 방식이 몸에 밴 것입니다.

표면적인 이유는 데이터베이스 커넥션에 컴퓨터 자원이 많이 들어서 그렇다... 이지만

이면에는 자바 코드를 한 줄도 안 고쳐도 된다는 것이 숨어있습니다.


많은 취준생들은 SI 도 개발하는 곳이니 1~2년쯤 몸 담아도 배워갈 게 있을 것이라 생각합니다.

하지만 몇몇 대기업이나 실력있는 PL이 고용된 프로젝트를 제외하면 현실은 이렇습니다.

다들 좋은 판단 하시고 열심히 준비해서 개발자의 꿈을 이루시길 바랍니다.