우리가 하는 IT 컨설팅은 무엇인가

호학당은

 

자체 서비스 외에도 IT 컨설팅 사업을 운영하고 있습니다. 

 

주로 스타트업이나 대기업의 IT 서비스 구축 또는 고도화 프로젝트를 진행하고 있는데,

 

주변 지인들은 계속 "정확하게 무슨 일을 하고 있는건데?"라고 물어봅니다.

 

 

 

이런 질문을 받으면,

 

"이 보게 나 친구, 사실 우리가 사용하는 많은 앱 서비스 외에도 세상에는 보이지 않는 IT 서비스가 많다네. 예를 들어, 은행에서는 전산화된 온라인 회계처리 시스템을 사용하고, 보험사에서는 상담을 위한 텔레마케팅 시스템을 사용하고, 제조사에서는 장치 판매 및 CS 업무를 위한 Web Ordering System을 사용하고, 항공사에서는 전산 예약을 위한 Global Distribution System을 사용하지. 우리는 그런 IT 서비스를 구축하거나, 개선하거나, 고도화하는 프로젝트에 참여해서 일을 하고 있다네. 그건 정말이지 힘들지만 뿌듯한 일이야."라고 속으로만 생각하고,

 

"뭐 그냥 이것저것 해.. 그 K기업이랑 H기업 알지? 거기랑 일하고 있어"라고 말해왔습니다.

 

 

 

 

그래서 오늘은

 

호학당이 하는 IT 컨설팅이라는 일이 무엇인지 정확하게 정리해보려 합니다.

 

호학당

 

 

 

 

많은 스타트업과 대기업들은

 

자체 비즈니스 모델을 위해서, 또는 업무의 효율성을 향상하기 위해서 

 

웹(앱) 서비스를 구축, 개선, 고도화하는 프로젝트를 진행하고 있습니다.

 

 

 

 

어떤 스타트업은 자체 플랫폼의 기능 구현을 위해 '호스트 사용자 콘텐츠 관리 웹 서비스'를 구축하기도 하고,

 

 

어떤 대기업은 업무 효율성을 향상하기 위해 기존 '수발주 관리 웹 서비스'를 개선하기도 하고,

 

 

어떤 대기업은 기존 상품 판매 서비스에 CS 통합 관리 기능을 더해 '주문 관리 웹 서비스'를 고도화하기도 합니다.

 

 

 

 

그리고 많은 경우

 

전문 인력(또는 팀)이 없기 때문에, 또는 외부의 인사이트를 얻기 위해서와 같은 이유로

 

프로젝트를 진행할 때 외부 전문가들이 함께 참여하게 됩니다.

 

 

 

 

그렇게 시작된 

 

IT 프로젝트는 대개 다음과 같은 단계로 진행됩니다.

 

1. 요구사항 정의 request specification
2. 서비스 기획 construct
3. 서비스 디자인 design
4. 서비스 개발 develop
5. 요구사항 검증 QA

 

그리고 위 1~2 단계가

 

호학당이 핵심적으로 제공하고 있는 IT 컨설팅의 범위입니다. 

 

 

 

 

그렇다면,

 

각 단계에서 어떤 업무가 이루어지는 것일까요? 

 

 

 

 

가장 먼저

 

요구사항 정의 단계에서는 프로젝트의 구체적 범위와 목표가 정의됩니다.

 

이는 고객사가 먼저 정의해주기도 하고, 함께 범위를 정의하기도 합니다. 

 

그렇게 구체적인 요구사항 정의가 완료되면, 해당 문서가 기준이 되어 프로젝트가 진행되게 됩니다.

 

이 단계에서는 구현 가능 여부 등을 파악하여 '요구사항 명세서'가 문서화되고, '프로젝트 위키' 문서를 생성합니다.

 

요구사항 정의 단계는 가장 중요한 단계라 할 수 있는데,

 

이 단계에서 '요구사항 명세서'가 구체적으로 정의되지 않을 경우

 

향후 프로젝트 결과를 검증에 문제가 생기기도 하고,

 

'프로젝트 위키'를 제대로 관리하지 않는 경우,

 

용어의 통일이나 프로젝트 수정 이력 등으로 인해 불협화음이 생기기도 하기 때문입니다.

 

 

 

 

다음으로

 

서비스 기획 단계에서는 대략적인 프로젝트의 구조를 설계합니다.

 

제공되어야 하는 데이터를 기준으로 개념 스키마를 작성하고,

 

기능이 제대로 작동하는 개념을 전달하는 화면 설계서를 만듭니다.

 

이 단계에서 생성된 문서를 바탕으로

 

디자인팀, 개발팀과 작업의 방향성을 공유하고,

 

고객사와 프로젝트 예상 결과물에 대한 합의점을 정리하게 됩니다. 

 

또한, 

 

작성된 개념 스키마와 화면 설계서는 시간에 따라 더욱 상세 내용을 개선해 나아갑니다.

 

이 과정에서 개념 스키마는 IA 문서나 간략한 Class Diagram의 형식으로,

 

화면 설계서는 Use-Case Diagram, Sequence Diagram, StoryBorad 등의 형식으로 산출됩니다. 

 

실무에서는 필요에 따라 산출물의 형식이나 양식이 상이한 경우가 있지만,

 

결과적으로는 '개념 스키마'와 '화면 설계서'의 형식을 띄고 있으며,

 

이러한 산출물의 목표는 다른 구성원들과 서비스의 실제 작동 방식이나

 

디자인·개발 시 참고할 만한 내용들을 함께 정리하는 것입니다. 

 

 

 

 

이후 단계에서는

 

지금까지 작성된 문서를 기준으로 실제 디자인 및 개발 작업이 진행되고,

 

최종적으로 테스트 및 요구사항 검증 과정을 거쳐 프로젝트가 마무리되게 됩니다.

 

 

 

 

물론 (당연하게도)

 

위 과정이 완벽하게 순차적으로 진행되지는 않습니다.

 

 

실제 프로젝트는 대부분 각 단계가 병렬로(서로 영향을 미치며) 진행되기도 하고,

 

어떤 이유로 인해 특정 단계가 다른 단계와 통합되어 진행되기도 하고,

 

진행 중 발생하는 이슈로 인해 이전에 단계로 되돌아가기도 합니다.

 

 

그렇기에 '문서화'가 정말 중요하다고 할 수 있습니다.

 

문서화라는 단어가 주는 관료적이고 비효율적인 이미지를 떠올리면,

 

"이게 맞나..?" 하는 생각이 들기도 하지만

 

 

결국 프로젝트가 성공적으로 마무리되기 위해서는

 

참여 인력 모두가 정확한 목표를 공유하고, 같은 방향으로 달려가야 하고,

 

이를 위해서는 모두가 공유하는 '기준'이 중요하기 때문입니다.

 

 

 

---

IT 프로젝트 진행 과정

프로젝트 진행 단계	참여인력	산출물
요구사항 정의	기획자, 개발자	요구사항 명세서, 프로젝트 위키, PR/FAQ
서비스 기획	기획자	IA 문서, wireframe, Concept Scheme, StoryBoard
서비스 디자인	디자이너	디자인가이드 문서, 화면 디자인 시안, 디자인 리소스
서비스 개발	개발자	UML 문서, CI/CD 가이드, 코드 파일
요구사항 검증	기획자, 개발자	Test Case 설계서, 검수보고서