왜 SI플젝은 기술적으로 단순한가?

잡코리아에서 흔한 인력파견 자바Si플젝중에서 대다수가 SQL중심 프로젝트입니다 이것들 상당수가 이미 안정화된 기간계(계정계) 시스템을 차세대 시점에 완성하고 일종의 고도화 플젝입니다. 무슨 무슨 회계시스템 이러면서 차세대가 아닌경우 거의 대부분 고도화 플젝입니다. 업무파트 자바개발자로 들어가면 정말 SQL 조금만 하면되요. 대졸 고졸 이런거도 필요없고 일지시하는 사람 말만 잘들으면 됩니다... 이미 코딩기법은 표준화되서요 SQL업무 중심 플젝은 정말 자바기술이 거의 필요가 없습니다. SQL 만 완성이 되면 나머지 자바/JSP 코드는 copy & paste가 90%를 차지입니다. 자바스크립트도 html도 모두 표준틀안에서 움직입니다 이런데서 백날 일해봤자... SQL 실력만 조금 늘뿐이죠 하지만 칼퇴근은 하고 비록 자바기술은 전혀 늘지 않지만 그럭 저럭 먹고살만 하죠 ===============고도화 플젝의 특징 =========================== 보통 금융회사 이런데서는 계정계 와 정보계 업무적으로는 크게 2개로 나누어져 있는데 계정계에서 마지막 배치(마감성업무)가 끝나면 -- 보통 정상적인 경우 새벽 1시경 종료되죠 -- 계정계 업무의 당일 종료 계정계가 마감되면 DW가 계정계, 계좌관련 정보등 (현재잔액.. 만기일등, 내야할이자액 ,연체시작일등)을 내립니다. --DW 구축 -- 정보계 업무의 어제 기준일로 데이터 구축 위 DW 데이터를 기초로 각 단위업무에서 Dm을 구축합니다 DataMart (DM)은 DW전체에서 각 업무에 필요한 데이터만 가지고 구축하는겁니다. 은행 각지점에서 사용하는 화면은 계정단말인데 이것은 현업들이 좋아하는 엑셀같은 화면이 아니죠 계좌번호 또는 주민번호를 검색조건으로 입력하고 조회 결과가 나오는구조입니다. -- 은행창구에서 대출신청할때 여자행원이 사용하는 바로 그 화면 -- 대출승인이나 실행(대출금 입금)같은 저장도 일어나구요 특정계좌번호의 입출금 거래내역은 조회되지만 대출고객을 다양하게 그룹핑해서 전일 마감 대출잔액을 기준으로 조회 할수도 없고 from - to로 해서 많은 양의 데이터를 자유 자재로 검색할수가 없죠 그러면 차세대 화면을 extention하는 고도화 화면들을 만듭니다. 자유롭게 다량의 데이터를 검색하고 paging 할수 있는 화면을 만듭니다. 은행데이터의 근간의 되는 여신 수신계좌 정보를 기초로 추가적인 테이블을 연결해서 확장(extention 또는 고도화) 하는겁니다. 결국 DW에 존재하는(select만 허용되는) 계좌정보 + CRUD가 자유로운 단위업무 이렇게 두가지를 합쳐서 배치 또는 화면 프로그램을 작성 이때 특징은 - 현재 계정계 디비시스템과 다른 독립적인 디비를 구축한다 시스템 다운등 치명적 에러를 사전에 방지하려고 Layer를 아예 따로 가져가는거죠 - 디비와 시스템이 다르므로 조회가 안되고 EAI를 사용하거나 새벽에 DW에서 전일자 계좌정보를 갖고 있는 많은 테이블을 내려서 사용해야죠 .. [DW 디비 -- SAM파일 -- 고도화 단위업무 디비] 이런구조입니다. - 실시간 데이터 조회를 해야하지만 보안상 SQL을 은행 계정계에 날릴수가 없으니 EAI 계정계호출을 사용합니다. select문으로는 간단한데 SQL을 날릴수 없어서 전문통신을 함 좀 기가막힌 중노동이지만 매번 실시간이 필요할때(은행원 요청시) 마다 정의해서 만들어야죠 장문의 문자열(대출계좌정보, 대출금등이 들어있는)을 TCP에 실어서 통신해요 이런걸 구축하는 금융회사에서 차세대 오픈 이후에 6개월 또는 4개월짜리 단기플젝이 많습니다. 6개월 짜리를 한 은행에서 10회하면 60개월을 한곳에서 보내고 이럽니다. 위에서 적은 내용은 정말 아무나 할수 있을정도로 간단합니다. 단 SQL은 잘해야 합니다. 하지만 요즘 SQL잘하는게 별의미도 없고 자랑거리도 못되고 -- 이화식저 대용량 데이터베이스 솔루션에 설명된거라, 고졸이어도 책 열심히 보고 3개워만 고민하면 웬만큼 다 합니다 그냥 제가 말하는 350만원-450-550 이정도 월급받을 정도죠 ========================================================= 위에 까지는 배치업무이고 그다음 본격적인 온라인 JSP코딩이 시작됩니다. 이때 좀 복잡한 업무를 할때 캐쉬(cashing)을 할 필요가 생깁니다. 즉 AA 업무는 A1 + A2 이렇게 구성되는데 A1 업무: DW성 전일자 대출계좌정보를 기초 -- 특징 하루동안 정보갱신이 않됨 A2 업무 : A1의 확장업무이고 CRUD가 빈번하게 일어남 이런상황에서 A1 업무를 직원(유저별)로 개인화를 하는데 -- 개인화:personalization 은행원을 위한 스마트work 환경구축을 해줌 ㅋㅋ A1 업무를 가져오는 SQL이 상당히 무겁다. 그리고 A2가 변경될때 A1의 값이 변동된다. 이런업무에서 A1을 캐싱 할수 있다면 select결과문을 매번 비지니스 오브젝트를 만들어서 세션에 담는것 보다는 A1의 업무를 Map에 담아서 관리 하는것이 빠를 수 있습니다. 초기에 업무종류별로 Abstract Factory 패턴으로 A1 업무유형으로 Concrete Factory를 싱글턴 (Was에 only 1개 instance) 으로 만들고 * Abstract의미는 추상화 말그대로 Abstract 클래스이고 반드시 다른클래스가 임플리멘트 해야 합니다 Concrete 의미는 반드시 implement 해야 할 메소드를모두 구현한 일반클래스(new로 인스턴스 화 할 수 있는) 여기서 A1 비지니스 오브젝트(data class)를 immutable 형태로 정의하고 A! 비지니스 팩토리 클래스가 인스턴스를 생성해주는 형태로구현하면 됩니다. -- sychronized 기법이용 (map은 오브젝트를 캐싱하는 저장소 이므로) -- map 이용해서 있으면 맵에서 꺼내주고 , 없으면 새로 생성해서 담고 -- 새로 생성할때는 무거운 select문들을 날려고 오브젝트 만들고 Map에 담고 -- 먼 이유에서인가 A1 비지니스 오브젝트를 다시만들 일이 있다면 무거운 Select문으로 다시만들고 Map에 담고 이런 패턴으로 코딩합니다 * 제가 말한 immutable 의미는 데이터클래스의 맴버변수를 String 같은 복제가 안되는 유형것으로 이루어진것을 의미합니다,. 그리고 factory 역할 클레스의 메소드에서만 인스턴스를 얻을수 있는, * synchronized 가 필수인 이유는 웹이 기본적으로 멀티쓰레드 환경이기 때문입니다. map 객체에 데이터클래스 인스턴스를 넣고 빼고 하면서 캐싱을 할때 값이 변하지 않도록 map의 put,get 부분을 블럭( { ..} )으로 감싸는거죠 상기과정으로 하는 디자인기법을 Flywieight 패턴이라고 합니다. 경량으로 가볍게 오브젝트를 미리 만들어 놓고 캐슁 한다 이런의미 같기도 합니다. 다수의 사용자가 반복적인 업무오브젝트를 쓰고 속도가 중요할때 쓸만한 기법입니다. DW성 SQL은 무겁지만 분석성격이 많아서 실시간 조회가 필요없는 경우가 많습니다 그럼 (1)하루전 영업일자 이미지로 가져가는 부분 + (2)그렇지 않는부분을 명확히 선을 그을수 있으면 (1)번 파트를 Flywieight 패턴을 이용하고 , (2)번 그렇지 않는 부분은 실시간 조횔회로 구성하고 이것이 (1)에 영향을 준다면 map에 들어있는 (1)을 끄집어내서 폐기처분하고 다시 (1)을 new 로 인스턴스(업무 데이터 클래스)를 만들어 map에 다시 담아 놓음 이것을 관리하는 부분을 - 싱글턴, synchronized - 일반 팩토리, abstract 팩토리 이것을 적절히 배합을 하면 아주 멋진 시스템이 탄생하는거죠 그런데 제가 지금까지 말한 자바코딩 기법이 별거 아닙니다. 자바책만 대충보면 누구나 할수 있는것이고 쉬운일이죠. 말그대로 생활의 팁정도입니다.. 지난번 글에서 이야기한 (참조: http://www.okjsp.pe.kr/seq/193503 ) 1) 디버깅요령 (OOP 스타일로) 2) 모든 Si의 핵심인 소트와 서치 (JDK API 이용;SQL 이외의 방법으로 ) 3) 오늘 이야기한 디자인패턴을 이용한 -- 은행 계정계 <-> 정보계 중간영역에 애매한 시스템을 위한 캐싱 요령 -- 시스템이 무겁다면 반복적인 무거운 SQL query 지양 -- WAS 메모리 부터 뒤지기 , 단) 캐싱할 layer를 잘 나누어야 함 3가지 정도입니다... SI자바 플젝에서 솔직히 이정도 이상 자바지식이면 충분합니다. 왜냐면 그외의 시스템 영역의 뛰는 소수 인력 1-2명이 트러블슈팅 형식으로 문제 해결을 하기 때문이죠 --> 이러한 영역은 그냥 날마다 단순하게 술마시고 잠자고 easy한 삶을 사는 평민에게는 도달하기 어려운 기술수준이죠 그래서 저는 저랑 유사한 코딩으로 밥먹어먹는 자는 모두 막일꾼이다 이렇게 주장합니다 ================================================ 여기까지 제가 언급한 자바실력은 회사업무만 해도 저절로 생깁니다. 워낙 상식적인게 JDK API이고 디자인패턴을 현재 회사일에 적용하는것이니까요 이 단계를 뛰어넘어야 막일꾼 스타일에서 벗어납니다.. 제가 말한 수준으로는 평생 잡코리아 자바SI개발자 급여 월 550만원을 못벗어납니다. 저도 월 550만원이상 달라는 말을 못하겠더군요.. 제가 양심은 있어서 투입되면 1년에 10만원정도 인상되니 그냥 얌전히 급여 받네요 제가 업무도 약한면은 있습니다. 그래서 측정하기 어려운 업무지식은 제쳐두고 이건 사람만 성실하면 누구든 좋은 업무개발자라는 이야기를 듣습니다. 결론 : 저 막*걸*리 정도 실력 갖고 늙어가는 경우는 사무직처럼 살아가는 개발자인데 결국 막일꾼 스타일이라는 말외는 표현법이 없습니다. 그리고 밥먹고 한짓이 이런 SQL, 이런 자바코딩 , 이런 JSP화면 만들기라서 상당히 능숙합니다.. 그래서 퇴근은 아무리 일정을 압박해도 요령것 7시정도면 매일 퇴근한다 이 장점외에는 없습니다.