SI 개발자 2.0 시대

웹 2.0이 한동안 화두였습니다. 웹 2.0의 특징 중 하나는 ‘소프트웨어 릴리즈 주기의 종말 즉 영원한 베타’입니다. 그렇다면 “SI 개발자 2.0”은 어떨까요 (참고로 SI 개발자 2.0이라는 용어는 기존 세대와 달라진 개발 환경을 맞이하는 차세대 개발자들을 지칭하는 용어로 제가 임의로 만든 용어입니다.) 분명히 제가 개발을 하던 10 몇 년 전과 지금의 SI 개발 환경은 많이 달라졌습니다. “SI 개발자 2.0” 시대에 필요한 요소들은 무엇이 있는지 한번 살펴보겠습니다. 그리고 SI 개발자 2.0 시대는 어떤 개발자가 요구되는지도 살펴 보겠습니다.

과거의 SI 개발 현장에 가보면 직접 Language에서 제공하는 API를 활용하여 나름대로의 라이브러리를 구축하여 개발하였습니다. 혹은 PowerBuilder등 생산성이 높은 RAD 툴을 통한 Client-Server환경의 개발이 많았습니다. 업무 자체 보다는 코딩 및 구현에 많은 시간이 할애 되었습니다. 당연히 복잡도는 올라갔고 비즈니스 변화를 빨리 수용하기 어려웠습니다.

그러나 요즈음은 framework 기반의 개발을 선호합니다. 과거 처럼 API 수준의 low level 개발을 요구하지 않습니다. 환경 측면에서의 변화를 살펴보면 데이터 량은 기하급수적으로 늘어났고, 웹에 이은 Cloud Computing, Mobile 환경이 대두되면서 처리 해야 할 트랜잭션은 더욱 증가하였습니다. 기업 환경이 글로벌하게 변하면서 이제는 전 세계에 걸쳐 무 중단 서비스를(24x365 Service) 제공하여야 합니다. 최근에 수 테라 급의 데이터는 흔하게 볼 수 있게 되었습니다.

DBMS에서 제공하는 SQL의 기능은 더욱 강력해졌습니다. 이제는 “SQL로 표현할 수 없는 비즈니스 로직은 없다.”는 이야기도 공공연히 나오고 있습니다.

정리를 해보면… SI 개발자 2.0은 더 많은 트랜잭션 더 많은 데이터를 처리해야 하고, 급격하게 변화하는 환경에 대해 빠른 대응이 필요해졌습니다.

최근 실패하는 대형 SI 프로젝트가 늘어난 배경에도 이러한 환경 변화가 큰 이유 중에 하나일 것으로 보고 있습니다.

자… 그러면 이러한 변화된 환경에 필요한 “SI 개발자 2.0”은 어떠한 기술을 가지고 어떻게 대응해야 할까요

업무 분석과 모델링에 대한 요구의 증대

과거에는 코딩을 잘하는 개발자가 뛰어난 개발자였다면, 지금의 환경은 정확한 업무 이해를 바탕으로 단순명료하고, 확장성 있게 설계하고 비즈니스 로직을 고성능의 SQL로 구현하는데 중점을 두어야 합니다.

과거에는 개발자들이 DBMS를 블랙박스로 보는 시각이 우세하였습니다. DBMS는 단순한 데이터의 저장소(Repository)로 보고, 꺼내온 데이터를 JAVA나 C같은 Language로 2차 가공하여 처리하였습니다.

그러나 업무가 복잡해지고 처리해야 할 데이터 량이 늘어남에 따라 명료하고 확장성 있는 데이터 모델링의 중요성이 대두되었으며, 데이터는 정규화되어 중복이 최대한 배제되어 저장 관리되게 되었습니다.

따라서 개발자들은 모델링에 대한 더 정확한 이해를 바탕으로 SQL을 작성해야 하는 임무가 주어졌습니다. 과거에 프로젝트 현장에 나가보면 개발자들의 업무 이해도나 모델링에 대한 이해가 많이 떨어지는 경향이 있었습니다. 작성된 ERD를 정확히 이해하지 못한 상태에서 SQL을 작성하는 경우도 비일비재하게 발생하였습니다.

그러나 비즈니스 환경의 변화가 많으며 대용량화 된 지금에 있어서 과거와 같은 방식의 개발은 실패하기 쉽습니다. 개발자들은 이제 누구나 ERD를 스스로 작성하고 이해할 수 있는 수준이 되어야 합니다. 과거처럼 주먹구구식으로 대충 설계한 후 코딩으로 메우려고 해서는 안됩니다.

더 높아진 SQL 작성 능력 요구

이제는 SQL에 대해 더 높은 수준의 능력을 요구하게 되었습니다. 과거처럼 JAVA나 C로 2차 가공하는 방법은 복잡 할 뿐 아니라 생산성이 매우 떨어집니다. SQL의 경우 생산성이 매우 높으며 비지니스가 변하더라도 쉽게 수정이 가능합니다.

우리가 사용하는 RDBMS는 매우 고가의 제품입니다. RDBMS가 나온 목적은 개발을 좀 더 단순화하고 효율을 높이기 위해서입니다. DBMS의 많은 기능들을 이해 할 수록 좀 더 편해집니다. 이미 DBMS가 지원하는 기능을 자체 구현해서 개발하려고 애쓰는 경우도 많이 봅니다. 이는 마치 고가의 자동차를 사놓고, 마차를 타고 다니는 격입니다. 자동차는 마차보다 복잡할 수 있지만... 내연기관의 구동 원리를 이해하고 몇 가지 동작 방법에 대해서 이해만 하면 더 많은 짐을 쉽고 편하게 실어 나를 수 있습니다.

개발자라면 모름지기 아주 난해한 알고리즘을 써서 코딩하고, DBMS는 그냥 단순 저장소(Repository)일 뿐... 비지니스 로직은 프로그램 언어 내에 모두 구현해야 한다는 잘못된 믿음도 한 몫을 하고 있는 것 같습니다. SI 개발에서 난해한 알고리즘이 필요한 경우는 거의 없습니다. 또한 코딩 실력을 자랑하기 보다는 남이 알아보기 쉽도록 작성해야 합니다. 그리고 RDBMS는 단순한 저장소가 아닙니다. 저의 경우 과거에 통신사 중계기의 데이터를 가져와서 계층형태로 펼친 후 통계를 내는 업무를 한적이 있습니다. 개발자가 C언어의 구조체나 배열로 가져와서 복잡한 처리를 하려고 고민하는 로직을 불과 15줄 내외의 SQL로 몇 시간 만에 끝냈습니다. 더불어 나중에 업무가 변경되더라도>물론 대용량 처리에 있어 성능도 비할 바 없이 빠릅니다.

모든 비즈니스 로직을 SQL로 끝장내겠다는 각오로 임하는 것이 중요합니다.

또한 프로그램 API에서 제공하는 기능도 충분히 이해하고 있어야 합니다. 의외로 DBMS를 핸들링하는 JDBC API에 취약합니다. “그거 그냥 DB에 넣고 빼는 것이 전부 아닌가”라고 쉽게 생각 합니다. 그러나 Parsing Overhead를 줄이기 위해 나온 Statement Caching이나 대량의 데이터를 처리하기 위한 Batch update같은 기능을 최근 JDBC Spec에서 제공하고 있다는 사실은 잘 모르는 것 같습니다. 여전히 1건 읽어서 if-then-else식으로 처리를 하고 있습니다. One-query로 짜기 어렵다면 이들 API의 기능을 활용해보는 것도 훌륭한 대안이 될 수 있습니다.

더 높아진 DBMS에 대한 이해 요구

개발자도 RDBMS의 기능을 상세히 이해해야 합니다. 아키텍처나 백업, 복구 등을 수행하는 DBA와는 달리 성능에 직접적인 영향을 주는 Index나 IOT, Partition(Range,Hash,List)를 언제 어떻게 사용해야 하는지 알고 있어야 합니다. Data warehouse환경이라면 Materialized View나 Bitmap Index에 대해서도 이해하고 있어야 합니다. Sequence나 Synonym 그리고 DBMS마다 상이한 Lock 처리 메커니즘도 이해하고 있어야 합니다. 흔히 문제가 되는 채번이나 Deadlock 이슈도 여기에 해당합니다. RDBMS가 제공하는 low level locking 그리고 특히 Oracle의 경우 Multi version read-consistency 에 대한 이해도 필요합니다.

흔히 DB를 더 잘 알아야 한다고 하면… 거부감을 느끼는 개발자들도 있습니다. “나는 JAVA 개발자인데 왜 DB 공부를 하라고 하는가 DBA가 될 것도 아닌데…”라고 생각 할 수도 있습니다. 그러나 정 반대입니다. 더 효율적으로 일하고 미래에도 인정받는 개발자로 살아남기 위해서는 DB를 더 잘 알아야 합니다. DB에서 이미 제공하는 기능을 힘S> SI 개발을 했다고 볼 수는 없습니다. 언어는 변해도 설계와 업무 지식 그리고 SQL 작성 능력은 거의 불변입니다. DB를 더 잘 알수록 더 효율적으로 더 빠르게 일 할 수 있습니다.

SI 개발 일정이 지연되는 주요한 이유는 … 크게 업무 분석을 제대로 못해냈거나… 혹은 분석은 했는데 모호하게 설계 하였거나… 분석 설계도 하였지만 SQL 구현 능력이 떨어지는 경우로 볼 수 있습니다. (혹은 복합적으로) 모델링과 SQL에 자신 있는 개발자라면 업무가 어느 정도 바뀌어도 크게 동요되지 않습니다. 이미 확장성 있게 설계해놨기에 조금만 손보면 되기 때문입니다. 곰곰히 생각해보면 대부분의 시간을 바뀐 업무 때문에 기존에 작성한 코드를 뜯어고치거나 버그를 수정하는데 할애한다는 것을 알 수 있습니다.

모듈화와 재사용성에 대해…

개발자들은 OOP 그리고 Platform 독립적인 Java나 닷넷 언어를 사용하면서 무의식적으로 모듈화와 재 사용 그리고 독립성에 대해서 생각하는 것 같습니다. 그러나 프로그램 언어 내에서의 재 사용만 생각할 뿐 DBMS 내의 재 사용성은 크게 생SPAN>

JAVA와 PRO*C를 함께 사용하는 프로젝트를 수행한 적이 있습니다. 공통 모듈은 JAVA로 작성되어 있습니다. 물론 JAVA 라이브러리 안에는 수 많은 SQL 호출이 들어 있습니다. 이러다 보니 동일한 쿼리에 대한 중복 호출 및 Network을 통한 왕복 지연(Round-trip delay) 등이 발생합니다. PRO*C나 혹은 미래에 추가될지도 모르는 다른 언어에서도 공통 모듈을 호출하고 싶다면 어떻게 해야 할까요 똑 같은 기능을 하는 모듈을 다시 C로 작성해야 할까요 만약 PL/SQL로 공통 모듈을 작성했더라면 어떻게 되었을까요 아마 JAVA나 PRO*C 모두 호출이 가능 했을 겁니다. 이원화된 관리가 아닌 공통 PL/SQL Package를 수정하면 양 쪽 모두 사용할 수 있습니다. 유지보수가 단순해집니다. 위와 같이 반복 호출이나 불필요한 Network 왕복지연이 사라집니다. 성능도 올라갑니다. PL/SQL은 DB의 Data를 처리하는 최적의 언어입니다. 문법도 어렵지 않습니다.

새로운 환경을 맞이하는 미래 개발자들의 화두는

SI 개발자 2.0 시대는 확실히 과거에 비해 코딩의 비중이 축소되었습니다. 이에 비해 모델링이나 SQL 그리고 RDBMS를 얼마나 잘 다루느냐가 그 사람의 실력을 판가름하는 잣대가 되었습니다. SQL을 잘 다루는 개발자일수록 생산성이 높으며 변화에 빨리 대처합니다.

업무는 항상 빠르게 변화합니다. 어제 했던 업무와 오늘 할 업무가 다를 수 있는 게 우리들 개발 현장입니다. 왜 매일 요건이 바뀌냐고 따져봐야 결국 구현해야 하는 것은 우리 개발자들의 몫입니다. 차라리 그 변화를 수용하고 얼마나 빨리 대처할 수 있느냐에 중점을 두어야 할 것입니다.

SI 현장에서 개발하는 개발자라면 이제 RDBMS에 대한 이해와 학습은 더욱더 중요해졌습니다. 데이터베이스 진흥원에서 주관하는 DAP, DAsP, SQLP, SQLD 시험에 응시하는 사람들이 나날이 늘어나는 것은 이러한 변화된 환경에 대한 반증이라고 봅니다.

과거 특정 Language 코딩에 할애했던 시간을 이제는 업무 이해 그리고 모델링, SQL과 DBMS 학습에 더 많이 할애하여야 합니다. 미래에는 업무를 많이 알고 이를 모델링으로 적절하게 표현해내고 SQL로 빠르게 구현해 낼 수 있는 개발자만이 제대로 된 대접을 받으며 살아남을 수 있을 겁니다. 언어는 계속 변합니다. 오늘은 JAVA로 개발하고 내일은 다른 프로젝트에서 닷넷을 사용할지도 모릅니다. 그러나 무슨 언어를 사용하더라도 여전히 SQL과 RDBMS가 필요할 것입니다.

IT 기술의 발전 방향을 유심히 관찰해보면 하나의 경향이 있습니다. 바로 생산성의 향상입니다. 과거에는 어셈블리나 기계어로 작성하다가 C, C++을 거쳐 JAVA나 RAD 툴이 나왔으며 이제는 Framework이 각광을 받고 있습니다. 아마 코어 한 분야나 패키지 개발 쪽은 여전히 어셈블리나 C 언어가 필요 할 것입니다. 그러나 SI 분야만 놓고 보면 더더욱 생산성이 강조되는 방향으로 갈 것은 자명합니다. 그 생산성의 중심에 데이터 모델링과 SQL 그리고 DBMS가 있습니다.

“SI 개발자 2.0”은 바로 DB의 기능을 충분히 활용할 수 있는 능력을 갖춘 개발자입니다.

지금까지 읽어주셔서 감사합니다. ^^