시스템개발 현장에서 반복되는 실패를 피하는 방법
현업에서 수많은 기업의 전산화 과정을 지켜보며 느낀 점은 화려한 UI나 최신 기술보다 중요한 것이 결국 현장의 목소리라는 사실이다. 많은 경영진이 수억 원의 예산을 들여 ERP프로그램 도입을 결정하지만 정작 실무자들은 기존에 쓰던 엑셀이 더 편하다며 고개를 젓는 경우가 허다하다. 이는 시스템개발 과정에서 실제 사용자가 겪는 불편함보다 관리의 편의성에만 초점을 맞췄을 때 나타나는 전형적인 부작용이다.
최근 삼성전자 DS부문이 299개 협력사를 대상으로 시스템 구축과 공정 개선 컨설팅을 진행한 사례를 보면 알 수 있듯이 잘 만든 시스템은 단순히 코드를 짜는 행위가 아니라 공정 프로세스 자체를 이해하는 것에서 출발한다. 무작정 프로그램만들기 단계로 진입하기 전에 우리 조직이 해결하고자 하는 핵심 문제가 무엇인지 정의하는 시간이 반드시 선행되어야 한다. 이 과정을 소홀히 하면 결국 현장에서 외면받는 비싼 쓰레기를 만드는 꼴이 된다.
성공적인 시스템개발을 위해서는 개발팀과 현업 부서 사이의 간극을 좁히는 중간 관리자의 역할이 결정적이다. 기술적인 용어로 무장한 개발자와 현장의 언어를 사용하는 실무자 사이에서 적절한 타협점을 찾아야 한다. 이 과정이 생략된 프로젝트는 백이면 백 일정 지연과 예산 초과라는 늪에 빠지게 된다.
웹 애플리케이션 환경을 결정하는 기술 스택의 차이
현대적인 웹 애플리케이션 환경을 구축할 때 가장 먼저 고민하게 되는 부분은 역시 어떤 언어와 프레임워크를 사용할 것인가 하는 문제다. 과거에는 Java 기반의 무거운 시스템이 주를 이뤘으나 최근에는 JAVASCRIPT 생태계가 확장되면서 REACT 같은 프레임워크가 표준처럼 자리 잡았다. 리액트는 컴포넌트 기반으로 개발이 가능해 유지보수가 용이하고 사용자 경험 측면에서 매우 빠른 반응 속도를 제공한다는 장점이 있다.
하지만 무조건 최신 유행을 따르는 것이 정답은 아니다. 리액트나 뷰 같은 현대적인 프레임워크는 초기 설정 비용이 높고 숙련된 개발자를 구하기가 상대적으로 어렵다는 단점이 있다. 반면 전통적인 방식은 구조가 단순하여 빠른 개발이 가능하지만 대규모 트래픽이나 복잡한 기능 구현 시 한계가 명확하다. 따라서 프로젝트의 규모와 내부 인력의 숙련도를 고려해 적절한 기술 스택을 선택하는 혜안이 필요하다.
서버 환경 역시 중요한 고려 대상이다. 리눅스 환경에서 구동되는 오픈 소스 기반의 서버 구축은 비용 절감과 확장성 면에서 유리하지만 보안 설정이나 운영 관리에 있어 전문적인 지식을 요구한다. 윈도우 서버 환경이 제공하는 익숙함과 오픈 소스의 유연함 사이에서 우리 조직의 기술 부채를 얼마나 감당할 수 있을지 냉정하게 판단해야 한다.
거품을 뺀 AI개발과 KMS 도입의 현실적인 가치
요즘 어느 미팅을 가도 빠지지 않는 화두가 AI개발이다. 하지만 실제 현장에 적용된 AI프로그램 수준을 보면 실망스러운 경우가 많다. 챗봇 하나 만들었다고 해서 기업의 지식 관리 시스템인 KMS 기능이 획기적으로 개선되는 것은 아니기 때문이다. 데이터가 정제되지 않은 상태에서 무리하게 도입한 인공지능은 오히려 잘못된 정보를 제공해 실무에 혼선을 주기도 한다.
삼성중공업이 독자 개발한 SENSE 시스템이 1000시간 이상의 실증을 거쳐 기술력을 인정받은 사례처럼 시스템개발 단계에서 가장 중요한 것은 신뢰성이다. 특히 기업의 핵심 자산을 다루는 시스템일수록 화려한 기능보다는 데이터의 정확성과 보안에 목숨을 걸어야 한다. 겉모양만 번드르르한 인공지능 솔루션에 현혹되기보다 우리 회사의 데이터가 어떻게 흐르고 쌓이는지부터 점검하는 것이 순서다.
지식 관리 시스템을 고도화하고 싶다면 먼저 내부 구성원들이 정보를 공유하는 문화가 정착되어 있는지 살펴야 한다. 시스템이 없어서 정보를 못 찾는 게 아니라 정보를 공유할 동기가 없어서 데이터가 쌓이지 않는 경우가 대부분이기 때문이다. 기술은 도구일 뿐 조직의 문화를 대신해 줄 수는 없다는 점을 명심해야 한다.
실무자가 겪는 SI기업 선정 과정의 시행착오
자체 개발 인력이 부족한 기업이라면 결국 SI기업 손을 빌릴 수밖에 없다. 이때 많은 이들이 범하는 실수가 가장 낮은 단가를 제시하는 업체를 선택하는 것이다. 하지만 시스템개발 분야에서 싼 게 비지떡이라는 말은 뼈아픈 진실이다. 낮은 단가는 필연적으로 숙련도가 낮은 개발자의 투입으로 이어지고 이는 프로젝트 후반부의 수많은 버그와 기능 미구현으로 돌아온다.
실패 없는 업체 선정을 위해서는 다음과 같은 5단계 과정을 거치는 것이 바람직하다. 첫째는 내부 요구사항을 문서화한 제안요청서 작성이고 둘째는 해당 분야의 수행 실적이 있는 후보 업체 조사다. 셋째는 제안서 발표를 통한 기술력 검증이며 넷째는 핵심 개발 인력의 면담 및 투입 확약이다. 마지막 다섯째는 계약 범위와 유지보수 조건을 명확히 하는 단계다.
무엇보다 중요한 것은 해당 업체가 우리 산업군에 대한 이해도가 있는가 하는 점이다. 제조업 시스템을 만드는데 금융권 전문 업체가 들어오면 용어 설명에만 수개월을 허비하게 된다. 프로젝트의 성격에 맞는 전문성을 가진 파트너를 찾는 것이 전체 개발 비용을 아끼는 가장 빠른 길이다.
성공적인 시스템 구축을 위해 준비해야 할 서류와 절차
막상 개발을 시작하려고 하면 어디서부터 손을 대야 할지 막막하기 마련이다. 시스템개발 프로젝트의 첫 단추는 우리에게 필요한 기능이 무엇인지 상세히 적은 요구사항 정의서다. 이 문서가 부실하면 개발 과정 내내 이거 해달라 저거 해달라 싸우게 된다. 실무에서 바로 활용할 수 있는 체크리스트를 준비해 두는 것이 좋다.
기본적으로 준비해야 할 서류는 사업자등록증과 인감증명서 같은 행정 서류 외에도 과업지시서와 상세 업무 프로세스 맵이다. 특히 기존에 사용하던 양식이나 데이터가 있다면 이를 어떻게 마이그레이션할 것인지에 대한 계획도 미리 세워둬야 한다. 대한항공이 인적 요인 분석 시스템인 HFACS를 활용해 데이터를 체계화한 것처럼 우리도 데이터의 규격부터 통일해야 한다.
신청 및 진행 절차는 보통 요구사항 분석으로 시작해 설계와 구현 그리고 테스트와 배포 단계로 이어진다. 각 단계가 끝날 때마다 결과물을 검수하고 승인하는 절차를 거쳐야 나중에 딴소리가 나오지 않는다. 특히 사용자 수용 테스트 단계에서는 실제 업무를 수행하는 직원들이 직접 참여해 기능상의 결함이 없는지 꼼꼼히 따져봐야 한다.
커스텀 개발과 상용 솔루션 사이의 피할 수 없는 선택
모든 기능을 우리 입맛에 맞게 만드는 커스텀 개발은 매력적이지만 그만큼 대가가 따른다. 개발 기간이 길어지고 비용이 기하급수적으로 늘어날 뿐만 아니라 개발자가 회사를 떠나면 유지보수가 불가능해지는 리스크도 존재한다. 반면 기성 솔루션은 도입이 빠르고 안정적이지만 우리 업무 방식을 시스템에 맞춰야 한다는 불편함이 있다.
결론적으로 회사 고유의 핵심 경쟁력과 직결된 부분은 직접 시스템개발 투자를 진행하고 인사나 회계 같은 공통 업무는 잘 만들어진 상용 프로그램을 쓰는 것이 현명하다. 모든 것을 다 가지려다 보면 결국 아무것도 제대로 작동하지 않는 결과만 초래할 뿐이다. 지금 당장 우리 회사에 필요한 것이 세상에 없던 새로운 것인지 아니면 남들도 다 쓰는 검증된 도구인지부터 냉정하게 따져보길 바란다.
가장 먼저 할 일은 내부적으로 우리 시스템의 고질적인 문제가 무엇인지 리스트를 만드는 것이다. 그 다음 비슷한 규모의 기업들이 어떤 방식으로 문제를 해결했는지 사례를 검색해보는 것만으로도 시행착오를 절반 이상 줄일 수 있다. 기술에 압도당하지 말고 기술을 부리는 주인이 되어야 한다는 점을 잊지 말자.