[SI 산업 가이드북⑤] SI 초보라면 이 8가지는 알고 하자

[IT 입문자를 위한 SI 산업 가이드북①] SI 회사는 가면 안되나요?

[IT입문자를 위한 SI산업 가이드북②] 스타트업, SI를 해도 되나요?

[IT 입문자를 위한 SI 산업 가이드북③] 갑은 SI 프로젝트를 어떻게 만들까?

[IT입문자를 위한 SI산업 가이드북④] SI에서 발전된 폭포수, 애자일 바로 알기

[IT입문자를 위한 SI산업 가이드북⑤] SI 초보라면 이 8가지는 알고 하자

이번 회차의 독자를 구체적으로 좁혀봅니다. 다른 분들은 이를 기준으로 대입·비교해 보면 됩니다.

이번 회차의 독자는, 컴퓨터 공학과 4학년 친구들이면서 파이썬 웹 크롤링 정도를 짜본 친구들입니다. 기본적으로 웹서버 + MySQL 정도, 2~3인으로 졸업작품 수준의 정말 작은 프로젝트는 해보았다고 가정합니다. CRUD 정도는 이해한 거죠.

※ CRUD: Create, Read, Update, Delete의 조합어, DB 에 데이터를 쓰고 읽고 지우는 기술 경험을 일컫는 표현

설명드릴 대상은 500만원짜리 “쇼핑몰 구축” 프로젝트입니다. 프로젝트 수행 기간은 약 30일 정도 주어지며 2~3인이 수행합니다. 발주자는 “조명가게 사장님”입니다.

참고로 “쇼핑몰 구축” 관련 키워드는 네이버 검색 기준 월평균 3만 회 이상 꾸준히 기록되는 “키워드”입니다. “꽃집”만큼이나 검색어 경쟁이 치열하죠. 수요가 많지는 않지만 꾸준한 반면, 공급이 부족합니다. 쇼핑몰 구축 프로젝트는 학생들 입장에서 조금 어렵긴 하겠지만, 한 번 하고 나면 생각보다 쉽게 반복할 수 있습니다.

“비기술 소상공인 창업”은 연간 200만 개가 넘습니다. “쇼핑몰 구축”이라는 키워드의 검색이 연평균 36만 회이니 비기술 소상공인 창업의 18%나 됩니다. 결코 적지 않은 숫자죠. 그래서 소형 프로젝트로는 꾸준히 자주 접하게 됩니다.

참고로 컴퓨터공학 계열 졸업자 수는 연평균 3만 명 정도입니다. 하지만 실제로 개발 가능한 친구들이 많지 않죠. 이런 프로젝트는 주로 경력자들이 참여하긴 하지만, 초보자들에게도 꽤 훌륭한 입문 창구가 됩니다.

이와 같은 “쇼핑몰 구축 프로젝트”를 처음 접하는 초보 SI 개발자가 시작 전 알아둬야 할 내용을 8가지로 정리해봤습니다.

IT를 모르는 고객

조명가게 사장님의 상황을 좀 더 구체적으로 적어 봅니다.(경험을 바탕으로 각색했습니다.)

이 사장님은 옥션, 지마켓 등에 상품을 올려서 팝니다. 정가의 13%를 플랫폼 수수료로 냅니다. 가격 할인, 광고비까지 생각하면 평균 20% 이상 떼이기도 합니다.

이걸 독립 쇼핑몰로 바꾸면 13%의 수수료를 아낄 수 있습니다. 연매출 10억 정도라면 1.3억 원 정도를 절약합니다. 독립 쇼핑몰 하나 만드는 것에 500만 원 정도 든다면 안 만들 이유가 없습니다.

다만, 사장님은 하루 종일 조명가게 영업을 합니다. 아파트 상가 인테리어 가게, 이삿짐 센터, 건설사 자재과 등을 열심히 돌아다닙니다. 그렇게 돌아다녀서 겨우 직원 하나 먹여 살립니다.

Apache, nginx, node.js … 등등은 설명해도 모릅니다. 이해할 생각이 1도 없습니다. 회원가입, 환불, 취소 등에 대해 한 번도 생각해 본 적이 없습니다. 웹디자인에도 큰 관심이 없습니다. 반응형이라는 용어도 이번에 처음 들었습니다.

딱 하나 “AA 인테리어 사이트처럼… 이렇게 만들어주세요.”라는 희망사항만 있습니다. 일정을 어떻게 진행해야 할지, 무엇을 의사결정해야 할지 전혀 알지 못합니다.

이 프로젝트의 시작은 여기서부터입니다. 우리 고객은 이런 사람입니다.

우리의 미션은 이런 고객에게 결과물을 납품하고 개발대금을 받아내는 것입니다.

“쇼핑몰 프로젝트”의 시장 상황

프로젝트 상황을 정리해 봅니다.

“쇼핑몰 프로젝트”는 소상공인들에게 “독립 쇼핑몰”을 만들어주는 프로젝트입니다.

없는 시장을 개척하는 게 아니라, 있는 시장에 진입하는 게임입니다. 기술적으로는 이미 만들어진 플랫폼을 활용합니다. 플랫폼 자체를 변경하거나 개선하진 않습니다.

SI 기업 입장에선 할 수 있는 일과 없는 일을 미리 구분해 놓습니다. 기술력이 있더라도 전략적인 목적으로 “상품화”하지 않습니다. 예를 들어 “워드프레스”의 “플러그인” 코드를 수정할 수 있어도, 그걸 견적서에 올리지 않습니다. “코드 수정”이 메인 상품은 아닌 거죠.

※워드프레스: Wordpress, 오픈소스 기반의 콘텐츠 관리 시스템으로, 전체 시장 점유율의 43%를 차지하고 있다. 기본적으로 블로그 기능을 제공하고 있으며, 이를 기반으로 쇼핑몰이나 뉴스 미디어 사이트를 제작할 수 있다.

결과물을 “설치형”으로 제공할 수도 있고 “가입형”으로 제공할 수 있습니다. “설치형”은 독립 서버를 함께 제공해야 하고, “가입형”은 독립된 공간(관리 사이트)을 제공해야 합니다.

고객 입장에서 “설치형”은, 저장 공간, 컴퓨터 관리를 직접 해야 하는데, 내 맘대로 복잡한 시스템을  구성할 수 있습니다. 많은 가입자를 다양한 방식으로 다룰 때 유리합니다. “가입형”은 “서비스 회사”가 정해준 틀 대로만 이용해야 합니다.

생각보다 많은 사장님들이 가입형을 선호합니다. 가게 제품 팔기도 벅찬데 컴퓨터 관리까지 할 여유는 없는 거죠. 물론 월 이용료가 적정 수준이어야 합니다.

네이버 출신 개발자라도, “워드프레스”, “마젠토” 같은 플랫폼에는 손을 대지 않습니다. 이건 실력을 자랑하는 게임이 아니라, 쇼핑몰을 만들어주는 사업입니다. 마음에 들지 않는다고 뜯어내다 보면 일이 꼬리를 뭅니다. 집 앞 공사로 끝내려 했는데, 마을 전체를 뒤집어 놓을 수도 있습니다. 

※마젠토: Magento 오픈소스 기반의 쇼핑몰 플랫폼, 전 세계 이용자수가 25만명이 넘으며, 전체 시장 점유율의  30%를 차지하고 있다. 파일갯수가 2만개, 코드가 120만줄이 넘는 대형 플랫폼이다.

참고로, 2013년 “국세청 차세대 프로젝트”가 기능 1만 개에 2,000억 원짜리 일이었습니다. 그런데, “워드프레스”는 158개의 GitHub Repo를 가지고 있고,  파일갯수만 4,120개입니다. 결코 적지 않은 사이즈입니다. 실력이 있더라도 작은 SI 업체엔 허락된 일이 아닙니다.

경험 없는 학생도 할 수 있을까?

서두에 이야기한 학생들 말입니다. 아직 한 번도 이런 프로젝트를 해보지 않은 친구들이죠. 그 친구들이 이걸 할 수 있을까요?

단호하게 대답할 수 있습니다. “못합니다!” 제가 지켜봤던 경험에서, 이유는 이렇습니다.

첫째, 고객을 상대해 본 경험이 없어 합의에 이르기 힘듭니다. 고객은 IT에 대해서 전혀 모릅니다. 심지어 네이버 쇼핑을 안 써보신 분들도 있습니다. 카톡은 쓰지만 온라인 판매를 어떻게 해야 하는지 전혀 모릅니다. 택배발송 방법도 모릅니다.

고객은 궁금한 모든 것을 “수행 업체”에게 묻습니다. 어떤 건 대답할 수 있고, 어떤 건 대답할 수 없습니다. 그런데 중요한 의사결정은 고객이 해야 합니다. 그래서 고객이 쉽게 의사결정을 할 수 있도록 적절하게 커뮤니케이션을 리딩해야 합니다. 이게 학생들에겐 매우 어려운 일입니다. 대화가 잘 안 통해서 감정적 갈등으로 커지는 경우가 많습니다.

둘째, 계약부터 납품까지 전체 프로세스를 몰라 진도를 뺄 수 없습니다.학생들은 “계약”의 무서움에 대해 잘 모릅니다. 일을 순서 없이 하다가 납기일을 어기는 경우가  허다합니다. 고객은 “쇼핑몰”을 오픈해야 판매를 시작하는데, 납기지연이 곧 고객의 피해로 이어진다는 걸 알지 못합니다. 문제가 생기면 제 때 소통을 해야 하는데 이걸 실패합니다.

셋째, 노하우가 없어 문제 해결이 되지 않습니다. 워드프레스 기반의 간단한 쇼핑몰은 보통 약 30~40개 정도의 플러그인을 설치하게 됩니다. 메인 기능 외 메일 발송, 문자발송, 결제 연동, 보안기능, 캐싱 기능 등이 포함됩니다. 이게 서로 의존적이거나 독립적으로 동작하는데, 매커니즘을 알아야 이 문제를 해결할 수 있습니다. 이런 부분을 “서버 엔지니어링”이라고 합니다.

“서버 엔지니어링”은 정말 많은 삽질을 해야 알 수 있습니다. 생각만큼 뜻대로 잘되지 않습니다. 그런데, 초보자들은 이런 경험이 없어 삽질만 하다 시간을 허비해 버리곤 합니다.

입문을 위해 필요한 것?

아직 미경험자라면 일을 시작하기 전 반드시 경험을 완성시켜 봅니다. 가능하면 관련 회사에 들어가서 일을 배웁니다. 아니면 친구들끼리 삽질로 “경험세트”를 완성시켜 봅니다. 반드시 한 번 해봐야 합니다.

워드프레스 기반의 쇼핑몰이라면 기술 난이도는 어렵지 않습니다. 전공과 학생 2~3명이 한 학기에 만들 수 있는 난이도이자 크기입니다. 오픈소스를 활용해 빠르게 운영환경을 만들기 때문에 맨땅부터 코딩할 필요가 없습니다. 기존 코드가 어떻게 동작하는지 알아야 하니 저절로 공부가 됩니다. 다양한 고객 데이터를 직접 접해볼 수 있습니다. 다만, 많은 쇼핑몰 언어가 php로 개발되어 있습니다. 요즘 개발 언어는 아니죠.

디자이너가 붙어 썸네일이나 배너 이미지 작업도 함께 해봅니다. 디자이너와는 어떻게 일하는지, 프론트엔드, 백엔드와는 어떻게 일하는지 등등을 경험해볼 수 있습니다. 경험세트가 완성되면 꼭 한 번 공짜로 지인에게 만들어줘 봅니다. 단, 최소한의 품질 수준을 만족시켜야 합니다. 예외 상황에 대처하며 구현할 수 있게 되면 비로소 일을 시작할 준비가 된겁니다.

고수준의 SI 프로젝트와 비교해 보면 난이도는 한참 낮습니다. 어쨌든 프로젝트 경험 한 바퀴를 완성하는 데 집중합니다. 팀 사이즈는 보통 3명 정도 됩니다. 

• 디자이너 - 화면 기획 및 디자인, 고객대응 및 프로젝트 관리
• 백엔드 개발자 - 서버 설정 및 기능 개발, API 개발
• 프론트엔드 개발자 - 웹 화면 개발

디자이너가 프론트엔드를 같이 하기도 하고, 백엔드 개발자가 프론트엔드를 하기도 합니다. 대부분 “마젠토”나 “워드프레스”같은 오픈소스를 이용합니다.

“납기는 생명, 품질은 기본” SI 프로젝트의 본질

SI 프로젝트는 “기술노동력”을 파는 사업입니다. 한 명의 인건비를 고객으로부터 받아내는 겁니다. 이게 기본입니다. 받을 걸 받아야 회사를 운영할 수 있습니다. 그리고 제때 받아야 합니다. 그래서 종료일이 중요합니다. 종료일이 지나면 개발자는 다른 프로젝트에 투입될 수 있어야 합니다.

이런 이야기를 합니다.

“납기는 생명, 품질은 기본”

 돈을 받기 위해 필요한 겁니다.

“납기”. 납부기일. 즉, 합의된 날짜를 의미합니다. 개발이 끝나는 날짜가 아니라 고객에게 “받았다”라는 사인을 받아내는 날짜입니다. 납기일 이전에 납기가 끝나야 합니다.

“품질”. 고객이 원하는 기능이 기본적으로 잘 작동한다는 뜻입니다. 감성적인 만족이 아닙니다. “고객”이 인수받을 수 있는 기본수준을 말합니다. 더 좋고 예쁘게 만들 수도 있습니다만 그렇다고 납기일을 넘기면 안 됩니다.

“더 좋은 걸 드릴 테니 조금 더 기다려주세요.” 프로의 세계에서 이런 대화는 하지 않습니다.

이런 상황이 있었습니다. 사장님 A는 앱으로 조작할 수 있는 “사물인터넷” 제품을 만들었습니다. 앱은 기능이 많지 않아 외주를 주기로 합니다. 실제로 복잡하지 않은 앱이었습니다.

프리랜서 B가 앱개발을 합니다. 학생 개발자였습니다. 그런데 종료일이 다가오자 기한을 한 달 더 늘려달라고 합니다. 앱을 더 잘 만들고 싶어 요구하지 않은 기능을 넣고 싶었던 겁니다. 앱은 아직 미완성인 상태였습니다.

하지만, 이미 제품 출시일은 정해져 있었습니다. 기한을 미루면 다른 납품계약까지 어기는  되었습니다. 더구나 제품보관료, 광고계약 등 예상치 못한 지출까지 추가로 발생할 상황이었습니다. 아쉽지만 A는 미완성인 앱을 인수받아 보급합니다. 앱스토어에 악플이 달립니다. 고객민원에 시달립니다. 시장반응이 나빠지자 사장님은 소매상으로부터 2차 계약, 3차 계약 등의 기회까지  날아갑니다.

더 잘 만들고 싶어질 수 있습니다. 하지만, 약속한 것까지 만드는 게 우선입니다. 다시 한번 강조합니다. “납기는 생명, 품질은 기본” SI 에선 이게 기본 중의 기본입니다. 잘 동작해야 하고, 원하던 기능이 동작해야 하고, 약속했던 기일 내에 동작해야 합니다. 이게 기본 중의 기본입니다. (몇번을 강조해도 지나치지 않습니다.)

폭포수로 개발하기 

무조건 “폭포수 개발방법론”입니다. 이유는 고객이 바쁘고 이해하기 쉽기 때문입니다. 세상에 없는 걸 만드는 게 아니므로, 연구개발이 아니라 단순 구축으로 진행합니다.

“디자인 초안 - 환경구성 - 기능 개발 - 검수확인 - 수정개발 - 인수”

이렇게 각 단계별 일정을 정한 후 완성도를 높여 갑니다. 그리고 각 단계가 끝나면 고객이 진행사항을 확인하거나, 선택사항을 결정할 수 있게 해줍니다. 대부분의 고객들은 이 방법을 좋아합니다. 가게 일이 바쁘고 기술지식이 없으니 설명을 듣기 보다는, 그냥 전문회사가 알아서 잘해주길 바랍니다.

흔한 나쁜 사례가 있습니다. 이 SI 회사는 프로젝트에 대한 특별한 오너쉽이 없습니다. 그래서 애매한 기술적 결정을 고객에게 던집니다. 하지만 고객은 그게 무슨 내용인지 모릅니다. 정보도 없고 배경지식도 없으니 의사결정을 할 수 없습니다.차일피일 미루다 일정 지연이 일어납니다. 당연히 책임공방으로 이어지고 고소고발까지 갑니다. 초보 SI 회사가 자주 저지르는 실수 중의 하나입니다.

그런데, 착각하면 안 됩니다. 사업은 이기기 위한 게임이 아니라 돈을 벌기 위한 게임입니다. 책임공방에서 이길 수는 있습니다. 하지만 매번 반복할 수는 없죠. 프로젝트를 할 때마다 고소고발 건이 추가될 테니까요. 책임공방은 성공엔딩이 아니라 배드엔딩입니다.

SI 회사는 눈치껏 애매한 기술적 결정을 할 수 있어야 합니다. 예를 들어 쇼핑몰 설치에 필요한 서버 사이즈 같은 거죠. 처음엔 작은 사이즈로 먼저 설치한 후 트래픽이 늘어나면 증설해 줍니다. 이렇게 하는 것만으로도 대부분의 상황 중 90%는 커버됩니다.

이 시장은 결과물이 정형화되어 있습니다. 거의 그에 맞게끔 준비합니다. 간혹 기한도 짧은데 “애자일” 한다고 무한정 반복하는 팀이 있습니다. 진짜? 네, 진짜 있습니다. 물론 작은 프로젝트에서도 과정은 중요합니다. 하지만 프로세스를 잘 지켰다고 용서받을 수 있는 게 아닙니다. 프로젝트 종료일에는 일이 끝나야 합니다. 그게 핵심입니다.

유지보수, 운영 염두에 두기

소프트웨어도 기술 환경의 변화 때문에 자꾸 낡아집니다. 예를 들면 이런 겁니다.

갤럭시폰이 새로 나왔습니다. 폴더블 폰입니다.

흠, 화면 해상도가 훨씬 더 넓군.

2개씩 보이던 상품 이미지가 이제 4개씩 보일 수 있겠는데?

그런데 우리 쇼핑몰은 왜 안되지…?

엇, 그리고 OS 가 15.0 버전이네?

결제 모듈이 동작하나?

아… 안되네.

하아~

빈번하지는 않지만 이런 일이 꾸준히 발생됩니다. 지속적으로 수정하고 보완해야 현재 기능이 유지됩니다. 자동차의 타이어를 갈거나, 엔진오일을 제 때 교환하는 것과 비슷합니다. 이렇게 “상태가 더 나빠지지 않게 정상 수준으로 유지시키는 것”, 이걸 “유지보수”라고 합니다.

쇼핑몰이 영업을 시작하면 기술적으로도 할 일이 많습니다. 간혹 결제 메일이 고객에게 발송되지 않을 수 있습니다. 원인을 확인하고 조치해야 합니다. 갑작스러운 해킹 시도 때문에 사이트가 느려질 때도 있습니다. 새로운 공격패턴을 분석해서 방화벽을 강화하거나, 백도어를 막아야 합니다. 기타 등등.

이렇게 사업운영이 되도록 지원하는 역할을 “운영”이라고 합니다. 생각보다 일이 다양하고 기술이 아닌 일도 많습니다. 하지만, 기술을 알아야 대처할 수 있는 일입니다.

이렇게 웹 사이트는 한 번 오픈되고 나면 끝이 아닙니다. 생각보다 눈에 보이지 않는 숨은 작업들이 많습니다. “쇼핑몰”도 마찬가지입니다. 하지만, 대부분의 사장님들은 이런 상황이 필요한 걸 모릅니다. 사이트를 한 번 만들고 나면 돈 들어갈 일이 없다고 생각하는 거죠.

미리 이야기하지 않고 중간에 이런 이야기를 하면 어떤 사장님은 의심을 합니다. 돈을 더 뜯어내려는 수작으로 생각하죠. 그래서 일이 다 끝날 때까지 이런 이야기를 하지 않는 기업들도 있습니다.

가장 좋은 건 초반 상담 단계에서 이야기를 해주는 겁니다. 준비한 돈에 얼추 맞춰보라는 거죠. 보통 월이용료 개념으로 이야기를 합니다. 전기세 내듯이 어필합니다. 적지 않은 사장님들이 쉽게 이해를 합니다. 그 돈을 낼지는 모르겠지만요.

월이용료는 SI 기업 입장에선 꾸준히 들어오는 고정수익입니다. 크진 않더라도 회사 운영에 큰 도움이 됩니다. 어떤 기업은 오히려 이걸 노리고 구축비용을 싸게 부릅니다. 구축단계에서 손해를 보고 운영단계에서 만회하려는 거죠.

이런 일이 자주 반복되고 일거리가 많아지다 보면 이런 생각이 듭니다.

음, “설치형”을 “가입형”으로 바꿀까? 

“가입형”도 홈페이지처럼 “독립형 방식”이 있던데,

아냐, 오픈마켓 같은 “입점형 방식”으로 바꿀까?

축하합니다. 이 정도까지 생각하셨다면 이미 사업이 잘된다는 뜻이네요.

이 이야기를 하자면 또 길어지므로 이번 회차에선 뛰어넘겠습니다.

작은 프로젝트 유형과 대응 전략 이해하기

마지막으로 작은 프로젝트의 다양한 유형을 이해할 수 있는 틀을 공유해봅니다. 작은 프로젝트도 구축부터 운영까지 이어지는 흐름은 큰 프로젝트랑 똑같습니다. 다만 “고객이 IT에 대한 배경지식이 없다”는 게 가장 큰 차이점이죠. 

고객이 IT에 대한 배경지식이 없다는 건 생각보다 불편한 일입니다. 효과적으로 의사소통을 할 수 없다는 뜻이거든요. 크고 불확실한 문제를 해결해가기 어렵습니다. 대안으로 템플릿을 만들어 선택옵션을 줍니다. 혼자서 하기보단 3-4인 팀을 만들어야 수행하기 쉽습니다.

여기에서 파생되는 불확실성이 큽니다. SI 업체들의 “프로젝트 관리자”가 해소해야 할 문제죠. A 형 100만원, B형 150만원. 이런 식으로 견적서 옵션을 만들 수 있습니다. 옵션을 만들 때는 다음과 같은 틀을 활용할 수 있습니다.

[표1] 작은 프로젝트의 다양한 유형들

“전체 개발”의 경우는 비슷한 프로젝트가 계속 등장하니까 사업화하기 좋습니다. 분업화를 통해 일의 속도도 높이고, 품질도 높일 수 있습니다.

“부분개발”의 경우는 사업화하기 어렵습니다. 정형화할 수 없어 분업하기 어렵거든요. 단순 아르바이트에 그치는 경우가 많습니다.

초보 SI 회사는 R&D형 프로젝트가 재미있어 보여도 참여하지 않는 것이 좋습니다. 불확실성이 높아 종료일을 결정하기 힘들거든요. 자칫하면 돈도 못 받고 기약 없이 늘어지게 됩니다. 반복성이 없어 노하우와 프로세스를 활용하기도 어렵습니다. 사업성이 없는 겁니다.

마치며

이 글에서 소개한 “쇼핑몰” 사례가 많이 있을까요? 엄청 많습니다. 다만 다 제각각입니다. 정형화하기 어렵죠. 그래서 이 이야기를 하나의 사례로 이해하면 좋겠습니다.

“아 맞아, 저런 일이 일어나겠구나. 내가 이 일을 하려면 이렇게 준비해야겠구나.” 이렇게 말이죠.

작은 프로젝트는 기간도 짧고 금액도 낮습니다. 반면 요구되는 품질 수준은 높죠. 품질수준은 오랫동안 경험이 축적된 오픈소스를 활용하여 맞춥니다. 연구개발비용이 대폭 줄어들죠. 짧은 기간은 몇 개의 템플릿으로 대응합니다. 모든 고객 요구를 만족시키지 못하므로 시장공략에 한계가 있습니다. 딱 준비한 시나리오만 대응할 수 있죠.

이 시장에서도 나만의 경쟁력을 갖기 위한 노력은 필요합니다. 새로 찾은 오프소스가 해결책이 되기도 하죠. 잘 다듬으면 새로운 종류의 “서비스 상품”이 됩니다. “로우코드”, “노코드” 등도 이럴 때 유리합니다. 유연하지 못한 플랫폼을 보완할 수 있으니까요. 가능하면 이런 툴들은 꼭 찾아서 배워둡니다.

더 자세한 건 나중에 이야기하기로 합니다. 일단 입문이 먼저니까요.

다음 회차에선 조금 더 큰 프로젝트에 대해 이야기해보겠습니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.