1000억 ‘대형 프로젝트’의 진행 방정식

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

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

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

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

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

[IT 입문자를 위한 SI산업 가이드북⑥] 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

[IT 입문자를 위한 SI 산업 가이드북⑦] ‘대형 프로젝트’는 어떻게 할까?

큰 프로젝트는 어떻게 진행되는지 살펴보겠습니다. 이 글에서 설명하고 싶은 건 “프로젝트 규모에 따른 진행방식의 차이”입니다. 작은 정보지만 SI 초보자나 기업들에 도움이 되면 좋겠습니다.

“대형 프로젝트”라면 10억 원, 100억 원, 1000억 원짜리 프로젝트를 말합니다. 역시 규모에 따라 진행 방식에 차이가 큽니다. 자세하게 말하면 복잡해지니까 요령껏 설명해 보겠습니다. 베테랑들은 이미 알고 있는 흔한 내용입니다. 다만 ‘경험 사다리’가 끊어져 초보자들은 잘 모르는 내용입니다.

큰 프로젝트는 큰 규모만큼 책임도 큽니다. 시스템이 크니까 이해관계자도 많습니다. 일하는 방식도 까다롭습니다. ‘규칙’을 지키면서도 ‘유연’해야 합니다. 뭔가 모순인 것 같죠?

그래서 큰 프로젝트는 작은 회사에 맡기지 않습니다. 개발자 100명짜리와 5명짜리 회사가 같을 수는 없으니까요. 100억짜리 프로젝트를 5명짜리 회사에 맡길 고객은 없습니다.

결과적으로 대형 프로젝트는 “사람이 많아 경직된 회사가 규칙을 지키면서도 유연하게 문제를 해결해야 하는 성격의 일”입니다. 뭔가 시작부터 답답해지죠?

대형 프로젝트, 얼마나 많을까?

SI 초보자는 궁금합니다. 큰 프로젝트에 가야 할지 말아야 할지. 그래서 이런 것들이 궁금합니다. 

“대형 SI 프로젝트는 1년에 얼마나 발주될까?”, “얼마나 많은 회사들이 일을 할까?”, “거기서 일하는 개발자는 몇 명일까?”, “어떤 방식으로 일을 할까?” 등등.

장기적으로 보고 싶습니다. 이런 식의 통계가 있으면 좋을 것 같습니다.

“1년에 발주되는 프로젝트 중 발주금액 1,000억 원대 프로젝트는 X개, 100억 원대는 Y개, 10억 원 이하는 Z개.”

※ 발주금액 : “갑” 회사 입장에서는 “사업”이기 때문에 “사업비”라고 지칭하기도 합니다.

하지만 이런 통계는 없습니다. 삼성, LG 같은 일반기업이 자기네 회사 일을 정부에 보고하진 않거든요. 그래서 데이터가 공개된 곳을 뒤져봅니다. “나라장터”입니다. 공공부문 한정이라 상황이 다르겠지만 추정해 볼 수는 있죠.

※ 나라장터 : “조달청”이 운영하는 입찰사이트로 정부기관, 공공기관(학교, 협회 등)이 주로 이용하고 있습니다.

2023년 통계 중 “정보시스템 구축, 유지보수, 운영, 컨설팅” 등만 간추렸습니다.

“프로젝트 개수”를 봅니다. “SI 기업의 수주 기회”입니다. 연간 806건. 매주 15건씩 도전할 수 있군요. 1억 ~ 3억 원대가 49%를 차지합니다. 매주 7.5건씩 도전할 수 있습니다. 나머지는 10억 원대(12%)네요. 매주 1.8건씩 도전할 수 있습니다.

일반 기업체는 어떨까요?

체감상 일반 기업도 비슷합니다. 대부분 1억 원~2억 원대 규모로 주로 유지보수성 프로젝트들입니다. 정확한 통계는 없지만, 체감상 연간 발주량의 50%는 그런 업무로 추정됩니다.

SI 기업들의 먹거리는 대부분 1억 원~2억 원대의 프로젝트에서 나온다는 뜻입니다.

※ 참고 글: 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

“발주금액 합계”는 SI 기업 입장에선 “수주금액”입니다. 대부분 “인건비”죠. 따라서 이를 환산해 보면 일자리 수를 추정할 수 있습니다. 전체 발주금액 가운데 10억 원 이상 프로젝트의 발주금액이 79% 나 됩니다. 개발자의 79%가 대형 프로젝트에 참여한다는 뜻이죠.

즉, 산업 관점에서 보면 개발자 일자리는 대형 프로젝트들이 만들고, SI 기업 매출은 작은 프로젝트들이 올리고 있습니다. 만일 누군가 “스타트업”을 한다면 작은 프로젝트를 잘하는 요령이 중요하겠고 “개인 프리랜서”로 일한다면 큰 프로젝트에서 잘하는 요령이 중요하겠네요.

제안서, 큰 프로젝트의 시작

발주금액이 1억을 넘어가면 절차가 복잡해집니다. 그래서 “제안요청서”로 시작을 합니다.

영어로 하면 Request For Proposal. 줄여서 RFP 라고 합니다. 고객이 만들고 싶은 걸 시시콜콜하게 적어 넣습니다. 일반기업이면 워드 파일, 공공기업이면 “한글”로 만듭니다. 

보통 가이드를 따라 만드는데 일반기업이면 꼭 따라 하지 않아도 됩니다. 중요한 건 원하는 걸 잘 적어넣는 거니까요. 공공부문은 다릅니다. 규제가 있어서 엄격하게 따르는 편입니다.

그다음 홈페이지에 입찰 공고를 올립니다. 이런 걸 발주할 테니 답을 적어 오라는 거죠.

SI 기업들은 “제안요청서”를 보고 해결 방법을 적는데, 이를 “제안서”라고 합니다. 옛날에는 책처럼 만들었는데, 요즘은 그림책으로 만듭니다. 파워포인트를 쓰죠. 대형 프로젝트라면 400~500페이지 정도 됩니다. 1,000 페이지짜리를 만들 때도 있는데, 사업 규모에 따라 케바케입니다.

제안서 제출 직후에는 “평가발표”를 합니다. 예비 총책임자(프로젝트 관리자)가 직접 내용을 발표하고 평가자들이 질의응답을 합니다. 평가는 보통 이해당사자인 실무자들이 합니다. (공공기업은 프로세스가 좀 다릅니다.)

기술 점수와 가격 점수를 합산하는데, 평가 방법이 대부분 “제안요청서”에 나와 있습니다.

일반적으로 전 과정이 투명하게 진행됩니다. 규모가 큰 만큼 봐줄 여지가 전혀 없거든요. 평가자 입장에선 잘 안 되면 완전히 역적이 됩니다. 평생의 평판에 금이 가기도 하죠.

그런데 “제안요청서” 공고 기간이 보통 2~4주 정도입니다. 규모에 따라 바뀝니다. 짧게는 1주일만 공고하는 경우도 있죠.

※ 공공기업 공고 기간 : 7일, 10일, 14일, 30일, 45일 (금액에 따라 다름, 80억 원 이상 = 45일), 일반 기업은 자체 기준을 가지고 공지를 합니다.

하지만, 지나가던 SI 회사가 공고를 발견하고, 고객사의 고민을 제대로 이해한 다음, 우리 회사가 할 수 있겠구나라고 결심하고, 적합한 해결책을 찾아 제대로 된 제안서를 작성할 수 있는 시간으로는 절대적으로 부족합니다.

즉, 뜨내기 회사는 오지 마라는 거죠. 이미 그 고민을 알고 있고 해결할 방법이 있는 기업만 참여하라는 겁니다. 그렇다면 큰 기업들은 미리 그런 정보들을 알고 있다는 걸까요?

네, 고객은 “제안요청서”를 작성하기 전 시장조사차, 여러 기업을 미리 만납니다. 그래야 프로젝트 범위, 일정, 비용 등을 현실성 있게 세울 수 있거든요. SI 기업을 만나면 고객은 솔직하게 고민을 털어놓습니다. 해결해 줄 기업이 있어야 프로젝트 발주도 할 수 있거든요. 시스템을 만들어 주겠다는 곳이 없는데 사업을 벌일 수는 없겠죠.

즉, 제안요청서가 나오기 전 고객들은 대부분 여러 기업을 만난 상태입니다. 프로젝트를 둘러싼 고객의 고민들이 시장에 다 공유되어 있죠.

우리 회사는 이런 내용이 나올 줄 몰랐다고요? 이미 대상기업이 아니었던 겁니다. 아니면 대상기업임을 외부에 잘 알리고 있지 못한 겁니다.

물론, 고객이 기업 보안 때문에 일부 기업하고만 하는 경우도 있습니다. 이건 복잡한 이해관계가 섞여 있으므로 일반 대상인 이 글에서는 스킵합니다.

일반적으로 제안서는 계약서의 효력을 가집니다. 거짓말로 수주한 후 나중에 바꿀 수 없다는 뜻입니다. 그래서 진짜로 현실성 있게 씁니다. 두루뭉술하게 “열심히 할게요.”라고 쓰지도 않습니다. 그러면 진행 중에 덤터기 쓸 수도 있습니다. 일이란 게 하다 보면 자꾸 늘잖아요.

제안서는 아키텍트와 각 분야의 전문가들이 모여 씁니다. 짧은 제안 기간 내에 목표시스템까지 그리죠. 실제 개발만 하지 않을 뿐, 글과 그림으로는 개발을 다 끝냅니다.

즉, 대형 프로젝트는 결론을 미리 내어놓고 거기에 맞춰 구현하는 방식으로 진행됩니다. 기본적으로 “설계 후 시공”이라는 건설 방식을 따르죠.

들어가는 돈이 크다 보니 어쩔 수 없습니다. 실패는 용납하지 않습니다. 대형 프로젝트는 시작부터 성공을 담보해야 합니다. 어떻게 될지 모르는 “열린 결말”을 추구하는 경우는 없습니다.

그래서 대부분 비용을 줄이거나 프로세스를 효율화하는 프로젝트가 많습니다. 이미 투자 대비 비용 효과가 검증된 사안들이죠.

누가, 어떻게 프로젝트를 관리할까?

프로젝트의 최종 결정권자는 PM(Project Manager)입니다. 프로젝트 기간만큼은 “CEO” 역할을 합니다. 프로젝트가 10억 짜리라면 10명~15명, 100억 짜리라면 100명~120명의 직원을 거느린 회사의 대표가 됩니다.

개발관리, 고객관리, 비용관리까지 모두 챙깁니다. 심지어는 협력사 직원들 월급까지 챙깁니다. 한 팀이 무너지면 다른 팀이 감당해야 하니까요.

그러다 보니 “프로젝트 관리”에는 위와 같은 내용이 몽땅 다 들어갑니다. 쉽게 말하면 성공하기 위한 모든 관리 활동을 하죠.

자세히 보면 스타트업에서 관리자가 하는 모든 일이기도 합니다. 물론 약간 딱딱한 버전이긴 하지만요. 어디나 일하는 건 똑같습니다.

팀 구성은 크게 “프로젝트 관리 조직”과 “프로젝트 수행 조직”(개발, 디자인)으로 나뉩니다. 프로젝트 관리 조직은 “PMO”(Project Management Office)와 “QAO”(Quality Assurance Office)로 나뉘고요.

“PMO”는 프로젝트가 잘 진행되도록 하는 팀입니다. 일정 관리, 문서 관리, 인력 관리 등을 하죠. “PM”(Project Manager)의 보조자 역할이자 직접적인 스태프 역할을 합니다.

“QAO”는 “소프트웨어 품질”을 관리합니다. 정확하게는 결과물이 만들어지는 과정을 통제하죠.

전통적인 산업에선 “제작 과정”을 잘 통제하면 좋은 “결과물”이 나온다고 믿습니다.

소프트웨어 사업도 어느 정도 맞긴 하지만, 특히 더 모두가 잘 해야 하고 제대로 해야 하죠.

2013년에 시작한 “국세청 차세대 시스템 구축 사업”이 있었습니다. 지금의 “홈택스”를 만든 대형 프로젝트였죠. 대한민국 직장인이 모두 여기서 연말정산을 하죠? 이 사업 때문에 편해진 겁니다.

이 프로젝트는 2,000억 원짜리였습니다. 통합 대상 시스템만 12개였고, 세부 기능이 1만 개를 넘었습니다. 관리해야 할 소스 파일 갯수가 5만 개를 넘었죠. 5만 개면 두어 명이 검수할 수 있는 상황이 아닙니다.

※ 12개 시스템 : 기준DB 정리, 탈세 혐의 분석시스템, 국세청 포털(일반인), 상담채널 통합, 납세자 CRM, 24x365 전자민원관리, 국세업무포털(직원용), 세정업무통합, 프로세스통합관리, 직원별 맞춤형 자동안내, IT 통합관리체계

절대로 “열린 결말”을 추구할 수 없는 프로젝트입니다. 세금이 2,000억 원이나 투입되었으니까요. 망했다면 한두 명 옷 벗는 일로 끝나지 않았을 겁니다. 가입자 수가 1,300만 명이 넘고 등록된 계정만 6,800만 개였습니다.

시스템이 잘 돌아가지 않으면 국민들에게도 금전 피해가 생깁니다. 민원이 빗발치고 피해보상도 해야 했죠.

실패를 가정할 수 없었습니다. 결론을 정해놓고 과정을 맞춰가야 했죠.

프로젝트 수행 : 폭포수 개발방법론

이제 현실적으로 “소스코드”를 생산해 내는 과정입니다. 업무 기능별로 팀을 쪼갭니다. 목표가 대부분 업무 자동화이기 때문에 “업무기능”이 곧 결과물입니다. 물론, 결과물이 다르면 팀을 나누는 기준도 달라집니다.

“전부 다 그런 거냐, 혹시 규칙이 있는 거냐?” 물을 수 있습니다. 아닙니다. 그런 경향이 있다는 거지 그게 규칙은 아닙니다.

요즘은 흔하게 볼 수 있는 개발 방식의 비교입니다. 너무 많이 봐왔죠. 그런데 “폭포수(Waterfall) 방식”에 대한 상세한 설명을 흔하지 않습니다. 설명해 봅니다.

대형 프로젝트는 “결론”을 정해놓고 접근하는 방식입니다. “전체 결론”을, 그리고 “상세”를 채워나갑니다. 이미 알고 있는 길이니까 Try and Error를 반복할 필요는 없습니다. 그래서 단계별로 하나씩 프로젝트를 진행합니다.

이미 알고 있기 때문에, 설계를 아주 어마무시하게 상세하게 합니다. 이후 개발은 단순 코딩만 하면 되죠. 설계단계에서 모든 걸 다 예측하기 때문에 절대로 실패할 수가 없습니다.

정말 어려운 요건은 “솔루션” 구매로 해결합니다. SI 프로젝트는 신규 비즈니스를 “발명”하는 게 아니라, 맞춤복을 만드는 과정이니까요.

참고로, 남의 힘을 빌려 “발명”을 하면 원천기술을 뺏깁니다. 아무리 보안을 강조하고 법적 분쟁을 하더라도 결코 새는 기술을 막을 수 없습니다.

스타트업이 아웃소싱을 통해 “파일럿”을 만드는 이유는 “핵심 기능”이 아직 없기 때문입니다.

핵심 기능은 내부 직원을 고용해서 만드는 겁니다. 그건 SI로 만드는 게 아닙니다. 절대로, 네버!

폭포수 개발 방법론에 따른 개발 과정을 순서대로 봅시다.

1.요구사항 분석

가장 먼저 프로젝트 대상이 되는 요구사항들을 정리합니다. 프로젝트에서 해결해야 하는 목표입니다. 인터뷰를 하거나 기존 업무를 분석해서 엑셀로 정리합니다.

프로젝트 종료 시점에는 요구사항들과 매핑된 기능들이 모두 구현되어 있어야 합니다. 작동해야 하고, 검사까지 완료한 상태여야합니다.

눈에 보이지 않는 일들도 정리합니다. “비기능 요구사항”이라고 하죠.

즉, “요구사항 목록”은 해야 할 일의 목록입니다. 업무량을 측정할 때 기준이 되고 투입되어야 할 개발자 수를 짐작할 때 쓰입니다.

2. 설계

모든 기능을 담는 소프트웨어 구성, 하드웨어 구성을 설계합니다. 결제 기능을 포함한다면, 해킹이나 위변조가 불가능한 상황까지 고려합니다. 유지보수의 편의성 이런 것도 생각합니다.

3. 개발

기능을 나누어서 개발합니다. 팀을 업무별 파트로 나눕니다. “부가세 파트”, “연말정산 파트” 이렇게 말이죠. 파트의 책임자를 “파트 리더”라고 합니다.

이 파트는 업무적으로 하나의 완결성을 가집니다. 즉, 부가세 파트라면 부가세 처리 신청, 신고, 변경 등이 모두 개발 대상에 포함되죠.

4. 테스트

여기서 이야기하는 “테스트”란 일종의 통합 테스트입니다. 나누어 개발한 걸 다시 모아 합치죠. 그다음 그 기능을 테스트합니다. 점점 더 덩치를 키워가며 테스트하죠.

일반적으로 “통합테스트”라 함은 전체 시스템을 다 조립한 다음 진행하는 최종테스트를 말합니다. 실제 사용자들이 어떻게 사용할지 시나리오까지 정해놓고 이뤄집니다.

5. 오픈

사용자들이 실제로 사이트에 접속해서 써볼 수 있게 됩니다.

6. 인수인계

SI 프로젝트는 종료일에 철수해야 합니다. 그래서 고객사 운영팀에 인수인계를 하죠.

“이렇게 저렇게 쓰세요”라고 교육을 합니다. 사용된 솔루션의 계약서도 인계합니다.

이 단계가 끝나고 나면 고객으로부터 “최종인수확인서”라는 것에 사인을 받습니다.

이걸 받아야 고객사에 “프로젝트 결과물”이 “납품”된 겁니다.

7. 대금청구

“최종인수확인서”와 “세금계산서”를 재무팀에 제출하면 프로젝트 대금을 줍니다.

이제 돈을 받았으니, 정말 프로젝트가 끝난 겁니다.

잘 될까?

잘 안 됩니다. 우당탕탕합니다.

큰 프로젝트가 “결론”을 미리 정할 수밖에 없는 이유는 이해관계자가 많기 때문입니다. 

금융, 정부 등 규제 산업은 일이 잘못되면 피해 규모가 큽니다. 관련 부서가 많다 보니 일 하나 하자면 정말로 이해관계가 복잡하게 얽히죠.

그래서 꼭 시작 전에 적정선을 합의합니다. 프로젝트 진행 중에 적정선이 달라지면 관계부서에 의견을 다시 물어야 합니다.

빨리 답이 올까요? 아닙니다. 어떤 때는 한없이 결정이 미루어지죠. 개발 일정도 한없이 길어집니다. 정말, 정말, 정말, 길어집니다.

그래서 이런 프로젝트는 절대로 “열린 결말”로 진행되지 않습니다. 범위와 내용까지 결론을 다 내린 상태에서 일을 시작하죠. 그래서 이런 이해관계를 미리 다 정리하고 나면 어느새 프로젝트는 대형화되어 있습니다.

촘촘히 계획을 세웠어도 모든 걸 다 예측할 수는 없습니다. 생각보다 큰 폭탄이 많이 터지죠. 

하지만 정해진 결론 때문에 다른 과정을 선택하지 못합니다. 문제가 해결되지 않고 교착상태에 빠지죠.

적지 않은 경우 문제가 터질 때까지 교착상태가 해결되지 않습니다. 사고가 터진 후에야 수습하는 과정에서 교착상태가 풀립니다. 일단 사고가 터지면 각자의 이해관계가 희생되니까요. 

규제 산업 분야는 또 다릅니다. 문제가 해결될 때까지 2~3년 동안 상황이 지속되죠.

그래서 스타트업은 절대 시작을 대형 프로젝트로 하지 않습니다. 그만한 돈도 없거니와 고객에게 첫인상을 “장애”, “오류”로 남길 수 없으니까요.

대형 프로젝트의 한계

대형 SI 프로젝트에는 몇 가지 문제가 있습니다.

실패를 허용하지 않는 분위기니까, 구성원 모두가 1인분의 몫을 해야 합니다. “초보자”가 설 자리가 없습니다. 당장 제 몫을 하기 힘드니까요. 그래서 신입사원이 유입되지 않습니다. 생태계가 말라가는 거죠.

구성원들의 동기도 약합니다. 프로젝트가 끝나면 결국 떠날 조직이거든요. 운영 중에 일어날 문제를 굳이 지금 꺼내어서 말할 필요는 없습니다. 살포시 묻어둡니다.

열정을 불태우는 건 자기 경력에 도움이 안 됩니다. 남의 회사니까요. 업무적으로도 금전적으로도 보상받을 길이 없습니다. 요구하는 만큼만 일하면 되죠.

PMO가 세세하게 일을 챙길 수밖에 없습니다. 일을 잘하기 위해 더 많은 일을 계획, 관리하게 되죠.

이상한 순환고리입니다. 100명짜리 중소기업인데 통제 수준은 높고 직원들 소속감은 없습니다. 주인도 안 보이고 한시적으로 일하는 손님들만 모인 조직이죠.

잘 될 리가 있을까요?

잘 안 됩니다. 우당탕탕합니다.

그럭저럭 일이 돌아갔던 시절도 있었습니다. 종이 장부 “회계”를 전산으로 바꾸던 시절이었죠. 한 번 정리된 “요구사항”은 프로젝트가 끝날 때까지 바뀌지 않았고, 중간에 등장하는 위험 요소도 없었습니다. 개발이 끝난 다음 손을 댈 일도 적었죠. 이미 만들어진 시스템도 현상 유지만 하면 되었습니다. 업무가 바뀌지 않았으니까요.

요즘은 아닙니다.

2015년에 오픈한 2,000억 원짜리 “국세청 차세대 시스템”은 어떻게 되었을까요?

연간 250억 원씩 운영 비용을 쓰는 “운영, 유지보수 프로젝트”가 되었습니다.

“우와, 250억 원이라니 단순 유지보수에 그런 큰 돈을 준단 말이야?” 아닙니다. 단순유지보수는 아니고 그만한 업무량이 있죠. 업무 변화에 맞게 시스템도 자꾸 뭔가 바뀌어야 합니다.

그런데 그 비용이면 아예 정직원을 뽑는 게 낫지 않을까? 

물론 정부 조직 내에도 전문가들이 있긴 합니다. 하지만, 인력 수가 절대적으로 부족하죠.

잘 되게 하려면?

프로젝트의 “결론”은 정해져 있지만 “상황”은 그렇지 않습니다. 계속해서 변하죠.

“국세청 차세대 프로젝트”는 프로젝트 진행 중 세법 개정이 세 번이나 되었습니다. 개정 사항 중 무시할 수 없는 건 반영할 수밖에 없었죠.

프로젝트는 살아 움직이는 생명체입니다. 아무리 완벽하게 설계를 해도 “상황”은 “계획”을 뛰어넘죠. “이 문제를 해결해 줘”라고 한 다음 멈추어 있는 경우는 절대 없습니다.

시작 시점에 모든 요구사항을 반영했다 하더라도, 프로젝트 중반에는 항상 새로운 문제가 생깁니다. 기능을 정의하고 코드를 개발하는 순간에 말이죠. 시작할 땐 보이지 않았던 문제들입니다.

조치할 내용이 관계 부서에 불리할 때도 있습니다. 그럴 때는 커뮤니케이션을 새로 시작해야 하죠. 난감합니다.

본 프로젝트가 아직 완성되지도 않았는데 사이드 프로젝트가 런칭됩니다. 데이터 정리가 끝나지도 않았는데 데이터를 달라고도 하고요.

PMO는 이렇게 계속되는 갈등 상황을 해결해 가야 합니다.

결국 “고객”과 끊임없이 커뮤니케이션하는 수밖에 없죠. 최종적인 의사결정권자는 고객이거든요.

“폭포수 개발방법론”이라고 하지만 사실은 “애자일 방법론”입니다. 조금 빡셀뿐.

프로젝트 끝나고 나면 10년은 늙습니다. 멘탈도 멘탈이지만, 건강도 많이 나빠집니다.

애자일이냐 아니냐

“설계가 끝날 때까지 기다리세요.”

“개발이 안 끝나서 볼 수 없어요.”

“디자인이 안 나와서 보여줄 수 없어요.”

이런 대화가 오고 간다면, 다 망하는 프로젝트들입니다.

“설계가 된 부분까지만 보여드릴게요.”

“정리가 다 되진 않았지만, 이야기는 들려드릴 수 있어요.”

“전체적으로 그림이 정리되는 건 2주 후에나 가능해요.”

반면에 이건 되는 프로젝트들입니다.

차이가 뭘까요? 대화입니다. 

“후자” 케이스는 문제 해결을 위해 대화의 장이 열리고 있음을 쉽게 알 수 있습니다.

그러다 보면 위험 요소를 미리 발견하고 제거하기도 합니다. 긴장감을 낮추죠. 그런데, 적지 않은 프로젝트가 “전자”처럼 일합니다. “개발방법론”을 방탄으로 사용하죠.

왜 그럴까요? 경험상 보고, 상황공유가 문제해결에 전혀 도움이 안 되었기 때문입니다. 보고를 해도 기능 개발에 필요한 시간을 얻어낼 수 없고, 문제 해결을 도와달라고 부탁할 곳도 없으니까, 커뮤니케이션을 포기하는 겁니다.

칸반이나 간트 차트로는 개발이 제대로 진행되고 있음을 확인할 수 없습니다. 내용을 알 수 없으니까요. 

내용을 알려면 메인 아키텍트가 개발 중인 소스코드를 확인할 수 있어야 합니다.

의도한 대로 만들어지고 있는지 확인할 수 있는 유일한 방법이죠.

또, 의도한 대로 만들어지고 있는지 확인할 수 있는 유일한 사람이고요.

프로젝트가 커지면 책임자도 많아집니다. 혼자 다 확인할 수 없으니 QC(Quality Check) 담당자도 생기죠. 이런 과정은 대부분 복잡한 문서로 남깁니다. 보고 절차도 복잡해지죠.

하지만, 문제해결이 되지 않는다면 애자일이든 폭포수든 모두 다 공허한 외침입니다.

대형 프로젝트를 할 때 사람을 모으는 이유는, 해야 할 일을 100개로 잘라서 100명에게 나누어주기 위함이 아닙니다. 물론 그 목적도 있지만, 100명이 힘을 모아 하나의 돌멩이를 치워야 할 때도 있죠.

마치며

대형 프로젝트는 여러 가지 이유로 이렇게 어렵게 진행됩니다. 책임의 무게 때문이죠.

문서도 만들고 절차도 지켜야 합니다. 때문에 작은 기업들에게는 기회가 잘 오지 않죠.

작은 회사로선 큰 프로젝트를 경험해 볼 기회가 많지 않습니다. 다만 개인 개발자는 비교적 기회를 얻을 수 있습니다 특히 아키텍트나 리더로 올라서고 싶다면 공부할 수 있는 것들이 많습니다.

대형 프로젝트도 케바케가 많은데 이번 시리즈에선 이 정도로 갈무리할까 합니다.

다음 편은 좀 더 평범한 이야기에 집중해 보겠습니다.

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