[Solution과 SI는 종이 한 장 차이다.] - Platform Solution에 대한 얕은 고찰 1. 오늘도 동료와의 회의 중에 나온 주제다. "그렇게 요구사항 들어올 때마다 기능이 추

[Solution과 SI는 종이 한 장 차이다.] - Platform Solution에 대한 얕은 고찰 1. 오늘도 동료와의 회의 중에 나온 주제다. "그렇게 요구사항 들어올 때마다 기능이 추가되면 SI 아닌가요?" 나는 방어적으로 설명을 했다. "일회성으로 끝날거면 SI지만, 재활용 가능한 거라면 Platform의 기능 요소로 올려야죠." 그리고 1초후에 생각했다. '이게 맞나?' 취직하기 전, 나는 IT기업의 솔루션 개발자에 대한 나름의 상상이 있었다. 완벽한 설계를 기반으로 완벽한 솔루션을 만드는 사람. 모든 것을 미리 예상하고 갑작스러운 요구사항도 능숙하게 처리하는 사람. 열심히 하다보면 그렇게 되겠지 했다. 새로운 요구사항이 들어왔을 때, 어떻게 처리하는 게 좋을지는 포지션에(혹은 성향?) 따라 의견이 나뉘는 듯 하다. 딜러 역할(구현)을 많이 하는 사람들은 처음부터 플랫폼의 요소로 개발하려 하는 것 같다. 반면에 탱커 역할(소통 및 프로젝트 관리)을 하는 사람은 프로토타이핑으로 진행했다가, 차후에 플랫폼에 올리는 것을 추구하는 것 같다. 딜러의 의견은 이렇다. 새로운 요구사항의 해결방법으로 새로운 기능을 개발하기로 결정했다면, 바로 플랫폼의 기능 요소로 올리자는 것이다. 요구사항에 따라 시스템 변경이 필요하면, 변경이 필요한 부분은 변경점으로 보고 계속 관리해 나가야한다는 것이다. 갑작스러운 요구사항에 긴밀하게 대처하기 위해 유연한 설계를 하고, 에자일 방식으로 운영을 하는 게 아니냐는 주장이다. ( 반은 맞고 반은 틀린 것 같다. ) 어차피 해당 기능은 모듈화되어 포함될 것임으로, 기능에 대한 피처가 바뀌더라도 해당 모듈만 수정하면 되기에 큰 문제가 되지 않는다고 한다. 탱커의 의견은 이렇다. 새로운 기능에 대한 피처가 명확하지 않기에 바로 올리는 것은 무리가 있다. 기존 서비스에 대한 영향도 역시 고려해야한다. 무엇보다 투자해야하는 리소스 차이가 크다. 프로토타이핑하는 것보다 (여기서 프로토타이핑은 새로운 어플리케이션을 올리든가, 내부적으로 어플리케이션 진입점에서 분기를 쳐서 아예 별개의 서비스처럼 관리하는 것을 말한다. ) 솔루션에 올릴 때 훨씬 많은 리소스를 써야 한다. 만약, 해당 기능의 피처가 너무나도 명확하고 모든 고객이 그 기능을 열렬하게 바라고 있다면, 이야기가 달라질 수 있다. 둘의 의견이 나름 첨예하다고 생각한다. 돈을 투자해서 돈을 생성해야하는 회사에서는 불명확한 기능에 대해 많은 리소스를 투자하는게 바람직한 방법은 아닐 것이다. 한편, 새로운 요구사항마다 프로토타이핑해서 관리하게 되면, 그 가지 수에 따른 관리도 쉽지않을 뿐더러 아웃소싱 플랫폼 같은 모습이 되어버릴 수도 있다. 누구의 의견이 맞는지는 포지션이든 성향이든 조직 상황이든 여러 요소에 따라 다르게 판단될 것 같다. 고려해야할 지표를 나열하고 지표마다 중요도를 설정한다. 지표 별 결과를 바탕으로 정량적인 결정을 내리는 게 가장 좋겠다만, 그게 어디 쉬운가. 데이터 기반 의사 결정이 쉬웠으면 DT를 도입한 회사들은 모두 폭발적으로 성장 했어야 한다. 매니저는 팀원을 어떻게 설득하고, 팀원은 어떤 마인드로 기능을 개발해야할까. 그래서 결국 우리는 어떻게 대처하는 것이 정답일까.