OKKY - si 프론트엔드??
SI 프로젝트에서 개발자는 무슨 일을 하는가?
SI 개발 단계
보통 SI에는 화면 및 업무 분석 설계 및 퍼블리싱 등 초반 작업들이 존재하지만,
주로 개발 단계에서 개발자들이 하는 업무는 다음과 같다.
- 엑셀 또는 시스템에서 할당된 개발 물량을 확인한다
- 1.에서 파악한 화면 및 데이터에 대한 분석설계 자료를 확인한다.
- 화면 및 업무 대한 문제가 있을 경우 설계자(업무PL)와 논의한다.
- 데이터베이스 쪽 문제가 있을 경우 DBA 혹은 설계자(업무PL)와 논의한다.
- 기존 개발된 함수를 호출할 경우 해당 함수 개발자와 논의한다.
- 2에서 개발한 건을 해당 프로젝트의 테스트 기준에 맞게 테스트한다.
- 입출력 조건 및 업무 조건에 맞게 테스트한다.
- 때때로 테스트 가능한 화면을 산출물화 요구하는 경우도 있다.
여기에서 업무전문가, 업무PL, 설계자와 같은 용어로 분석설계 및 해당 업무 개발을 담당하는 사람을 지칭한다.
업무? 업무전문가?
SI 프로젝트를 하는 사람들은 몇억~몇백억 규모의 프로젝트를 해봤는가?로 커리어 자랑을 하는 경우가 많다.
이는 서비스기업 재직자 입장에선 웃긴 이야기일 수 있다.
프로젝트의 규모와 MAU, TPS와는 하등 상관없기 때문이다.
프로젝트 규모는 화면 건수와 코드 분량과 관련있지 사용자와는 아무 관련이 없다.
수백억짜리 프로젝트이지만 기관 내부 인원들만 사용하는 시스템도 많다.
그리고 더 중요한 업무를 맡아 개발할 수는 있지만, 중요성과 MAU, TPS와도 무관하다.
그리고 SI 시스템은 아래의 대학 전공과 유사하다.
대학(시스템)에는 수많은 전공(업무)들이 존재하고, 해당 학과에 수 많은 교수들과 학생(개발자)들이 존재하지만,
해당 학과를 구성하는 인원들은 다른 전공에 대해 어느 정도만 알면 된다.
즉, 내가 은행 프로젝트를 했다고 은행 비즈니스의 전체를 알 수 있는것도 아니며,
일부분(예를 들어 네이버로 따지면 메인 페이지 정도만...)만 알아도 충분히 개발할 수 있다.
네이버 개발자가 네이버 서비스목록 전체를 외울 필요가 없듯이 말이다.
이처럼 SI개발자들은 자신이 맡은 업무에 맞는 부분만 개발하게 되며,
주로 기존에 있던 시스템의 코드(ASIS)와 PPT를 참조하여 새로운 시스템(TOBE)을 개발하게 된다.
콘웨이의 법칙
"시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계물을 만들게 된다"
개발 자체가 업무를 중심으로 흘러가므로, 해당 업무와 관련된 화면 및 인터페이스 개발, 쿼리 개발 등을 전부 한 개발자가 하게 된다.
보통 개발 물량을 화면 단위로 할당하게 되며, 그렇다고 하나의 화면에 서버 개발자와 화면 개발자를 따로 할당하면,
이럴 경우 서버 개발자의 부담이 너무 증가한다는 점이 문제가 된다.
3-tier architecture
그러면 애초에 화면과 서비스를 잘 발라내서 서비스와 화면을 따로 개발하도록 하면 되지 않냐고 반문할 수 있는데,
이는 실제로 SI개발이 3-tier 아키텍처는 껍데기일뿐이고,
실제론 로직이 DB와 화면에 박혀있는 안티패턴 그 자체이기 때문이다.
이는 사실 SI개발환경의 저열함과 관련있는데,
개발환경에 대한 이해도가 높지 않은 인원들이 개발자들의 개발 환경을 구축하게 되면서,
다양한 성능 문제를 야기하기 때문이다.
스프링 부트의 HotSwap같은 것도 없이, 자바 코드 한줄 수정하면 2~3분씩 기다리는...
Vue.js에서 문구 하나 수정하고 20분을 기다리는...
이러한 환경을 너무나도 당연하게 생각하는 사람들이 이 업계에는 많다.
당연히 자바 소스보다는 새로고침만 하면 반영되는 화면에 더 많은 로직을 넣게 된다.
자바 코드는 단지 쿼리를 호출해 화면에 던져줄 뿐인 통로에 불과한 것이다.
화면과 로직이 강결합되니 당연히 화면도 로직도 재사용이 어려워진다.
로직은 어디로 가야 하는가?
요즘 웹 개발이 그렇다고 합니다 (리액트와 NEXT.js 가 벌리고 있는 일들..) - YouTube
사실 위 영상을 보고 이 주제로 글이 쓰고 싶어졌다.
본인은 웹개발자를 그만두고 요새 Sap 개발자 커리어를 준비하고 있는데(회사에서 월급받으면서 인강보고 책보는중....),
SAP는 CDS View라는 개념을 사용하여 비즈니스 로직과 DB 쿼리를 강결합한다.
여기서 View는 DB의 View와 유사하며, abap 문법을 통해 view와 쿼리, view의 확장(클래스로 따지면 상속)이 가능하다.
해당 view는 behavior와 service라는 외부 abap 코드 정의를 통해 command에 의한 데이터 조작을 허용한다.
한줄로 요약하자면 데이터 변경 로직을 view(db+query)에 최대한 가깝게 두는 것이다.
물론 SAP는 화면, 테이블, 타입, 쿼리까지 전부 abap으로 개발이 가능하기에 굉장히 유기적인 개발 및 디버깅이 가능하다는 게 기존 SQL과 PL 조합과는 다르다.
(물론 답답함이 좀 있지만)
이게 안티 패턴이고 실패한 방법이라고 하기엔,
SAP는 ERP 영역에서 Microsoft와 Oracle이라는 강력한 경쟁자들을 전부 GG치게 만든 실적이 존재한다.
결국 view와(react에서는 db view가 아닌 json representation이지만, 이는 db view도 될 수 있는게 아닌가?) 비즈니스 로직은 가까울 수록 좋은게 아닐까 하는 생각이 들기도 한다.
사실 이는 jpa나 typeorm과 같은 도구가 이미 해결한 문제가 아닌가?라는 이야기를 할 수도 있는데,
각 언어별로 dsl이 나눠지는 현상이 언어이기주의(한국의 java) 문화를 만드는게 아닌가 싶기도 함.
SAP이 성공한 이유도 아이러니하게 폐쇄적인 ABAP이라는 언어로 화면부터 테이블, 쿼리까지 전부 개발할 수 있도록 한방에 처리한 덕택이 아닐까 싶음.
SAP와 위 동영상의 내용을 자바 생태계에 대입하자면,
JPA와 Spring Data REST+ 마이크로프론트엔드가 SI를 구원할 도구가 아닌가 싶은데...
즉 DB와 View와 테이블 관련한 로직과 화면을 전부 한 곳에서 통합해서 처리하는 방식으로 가야한다는 것인데...
(언어가 자바인 것은 어쩔 수 없고...)
SAP과 같이 든든한 플랫폼에서 사용하는게 아니라, JPA 자체의 복잡도가 높기 떄문에 뛰어난 기술 전문가가 필요할 것이다.
'Career' 카테고리의 다른 글
| [CAREER] AI시대 컴퓨터학과, 컴퓨터공학과 전망. 개발자의 미래? (0) | 2023.12.23 |
|---|---|
| [SI 커리어] SI 업계에서 개발자가 기술역량을 키우기 어려운 이유 with 블라인드 (0) | 2023.11.28 |
| [SI 커리어] SI 회사에서 서비스 기업 이직하는 방법 (0) | 2023.11.08 |
| [SI 커리어] SI회사에는 git도 모르는 개발자들이 있다? (2) | 2023.11.08 |
| [SI 커리어] SI 업계에는 DTO가 없다? (2) | 2023.11.05 |
