1. 내가 생각하는 SI
SI 프로젝트를 하면서 그리고 다른 회사 지인들과 얘기하며 듣고 느낀점 모두가 그렇다는건 분명 아니겠죠 ^^ 1. 본인이 원하는 프로젝트의 청사진을 의외로 모르는 고객이 계신다. 받아들이고 고객과 공감대를 어떻게 형성할 것인가를 고민해야지, 저 고객은 어쩌고 저쩌고 ㅡㅡ 왜 감정으로 대하는지, 일을 해야지 😅 2. 사전영업, RFP(Request For Proposal) 작성하는 순간부터가 프로젝트의 시작이라는 공감대 형성이 잘 안되는 조직이 많다. 3. SI가 싫다고 하면서 싫어할 수 밖에 없는 방식으로 일을 해왔거나 하고 있다. 4. 아키텍트의 역할은 기준을 설립해야 한다. 근데 여러 곳에서 기술 쇼잉의 장이 펼쳐진다. 구조도를 그리고 선을 하나 연결했다면 그 선의 기준이 주루룩 나와야 한다. 모델링, 기준, 원칙, … 막말로 기술은 어떤 쓰레기(?)를 가져다 써도 기준에 부합되면 된다. “거래가 3초 안에 되어야 한다.”는 요구사항을 예로 든다면 3초 안에 들기 위한 기준과 규칙을 세워야지. 이 기술이 저 기술이… 고객은 의외로 기술에는 크게 관심이 없을지도 모르고 알고 싶지도 않은 TMI 일 때도 있다. 물론 상황을 잘 따져보고, 결정권자 보고용은 따로 또… 기술은 필요할 때 잘(?) 가져다 쓰면 된다. 개발은 프로그래밍 언어라는 도구를 사용해서 컴퓨터한테 일 시키는게 다라고 생각한다. OS, 혹은 브라우저, 다른 프로그램을 사용하기 위해 작성된 규칙일 뿐이다. 그 규칙을 바라보는 시야에 따라서 여러 언어가 존재하는 것일테구 ㅠㅠ 5. “이정도면 됐지”에서 끝낸다. 사업의 연계성을 고려하진 않는다. 그때 가서 아 저번엔 이렇게 하자더니 어쩌구 저쩌구 6. PM이 얼마나 힘든 역할인지를 모르고, PM이 제일 중요하다는 사실 인지가 부족하다. 그냥 개발만 하면 된다고 생각한다. 그러니 결과물이 ㅡㅡ 7. 사실 이게 가장 중요한데.. 인공지능 자체가 SI 다”라고 생각을 안한다. SI라는 용어가 혐오의 대상이 되어버린 현실이 안타깝다. 우리는 SI를 본래 포지션으로 돌려놓기 위해, 과거에도 그래왔고 지금도 그리고 앞으로도 치열하게 살아갈 것이다. 우리의 작은 날개짓이 대한민국에 태풍을 일으킬 수 있길 바라며, 과신하지 않고, 천천히 탄탄하게 쥐도 새도 모르게 가보려 한다. “문제정의” 고객과 이걸 정확하게 인지시키지 못하고 시작한 프로젝트는 계속 뒤집어지는게 당연하다. 제대로 정의하고 시작해도 뒤집어진다. 당연하다. 항상 그 상황에서의 최선을 선택하는게 SI다. 우리는 “움직이는 자”가 되기 위해 항상 경계하며 과거 그리고 현재에서 배우며 미래를 그려갈 것이다. https://en.m.wikipedia.org/wiki/System_integration
