4)앱/웹 시스템 개발을 위한 구조화 설계 방법
- applefishP
- 3일 전
- 8분 분량
앞선 글에서 '서비스와 데이터 구조화의 기본: 앱과 웹 개발 설계', '서비스 기업의 자체 개발 시 구조화 설계 필요성에 대하여', '외주 개발 시 구조화 설계 필요성에 대하여' 내용을 정리하였습니다.
이번에는 우리가 일반적으로 앱과 웹 개발이라고 할 때의 기획/설계에 대하여 정리 하겠습니다. 그렇다고 화면 설계서, 스토리보드 작성법을 의미하는 것은 아닙니다.
엄밀히 화면 설계서, 스토리보드는 앱과 웹 개발을 위한 기획/설계의 최종 단계에 해당합니다. 과정이 불완전한 경우 결과가 미흡하듯이 기획/설계 과정 작업이 불완전하면 화면 설계서, 스토리보드는 부실해 집니다.
최근 많아진 개발 프로젝트의 불완전 종결 추세는 대부분 화면 설계서, 스토리보드 부실의 결과입니다. 그리고 이 부실은 과정 없이 진행된 기획/설계의 최종 단계 작업 때문임을 확인할 수 있었습니다.
1.앱/웹 개발 프로세스 요약
먼저 대략적인 앱/웹 프로세스 요약 정리 한 후, 각 진행 부분의 세부 내용을 검토 하겠습니다.
이 프로세스는 기계적으로 온라인 프로그램(애플리케이션)으로 개발을 위한 것입니다. 서비스 제품으로의 앱/웹은 아니라는 점을 먼저 밝혀 둡니다. 기업의 서비스 제품으로 앱/웹에 대해서는 앞으로 다른 주제로 다루어 보겠습니다.
그리고 저는 기획자이므로 코딩/프로그래밍적 부분은 기획/설계를 하면서 협업측면에서 제한적으로 보고 경험한 것에 한것에 지나지 않음을 미리 밝힙니다.
1-1.앱/웹 개발 프로세스
앱과 웹 개발은 앱/웹 서비스 비즈니스 기간에 비하면 매우 짧은 기간에 진행됩니다. 짧게는 1개월에서 길어야 1~2년에 지나지 않습니다.
그러므로 모든 미분 세계가 그러하듯 앱/웹 개발 과정 또한 선형성(직선)을 띠게 됩니다. 선형성으로 단계별 작업이 단 한번이라도 어긋나면 직선을 이탈해 진행에 영향을 줍니다. 작업의 이탈을 관리하기 위한 것이 바로 프로젝트 초반 진행되는 구조화입니다.
실무에서 앱/웹 개발 프로젝트이 진행을 분석하여 보면 매우 일관적이고 유사하다는 것을 알 수 있습니다. 방법론의 이름을 애자일, 폭포수 결국 기간과 단계가 뭉쳐 있느냐 분리되어 있느냐, 아니면 형식을 중요시 하느냐 형식보다는 실행을 중요시 하느냐 차이일 뿐 진행의 단계적 흐름은 유사합니다.
개발 목표 확인: 개발 의도 파악
개발 대상 구체화: 서비스 정책, 기능, 구조(메뉴 또는 IA, UX 여정) 설계
앱/웹 아이덴티티: 디자인 및 상호작용 방식
개발 환경 정리: 인프라, 자원, 연동 시스템, 규칙, 프레임워크 등 정리
구현 기능 정의: 개발을 위한 구체적 기능 내용, 정책, 프로세스 등 포함한 기능 목록 작성
화면 목록: 메뉴, IA를 포함한 앱/웹 화면 목록 작성
화면 설계서, 스토리보드 작성
디자인, 애플리케이션 아키텍처(AA), 데이터 아키텍처(DA), 인프라(TA, SA)
코딩, 단위 테스트
통합 테스트
이관
1-2.앱/웹 개발 시 구조화 설계를 하는 단계
일반적으로 뒤에 'A'가 붙은 작업과 직접적으로 '설계'가 붙은 작업을 앱/웹 개발을 위한 구조화 단계라 볼 수 있습니다.
흔히 국내에서 기획자라 부르는 화면 설계자 역시 구조화 설계 담당 인력입니다. 그러나 위의 총 11단계에서 화면 설계서, 스토리보드 작성은 7단계에 있다는 점을 주목해야 합니다.
화면 목록 작업을 국내 기획자가 한다고 하더라도 앞의 1단계에서 5단계까지 설계 작업 없이 화면 설계, 스토리보드 작업을 한다는 것은 해당 프로젝트에 타당한 앱/웹을 개발할 가능성이 지극히 낮은 형식적 문서화 작업이 될 것이라는 것을 알 수 있습니다.
제가 분석한 프로젝트 관리 케이스에 따르면 바로 회의를 통해 스토리보드(화면 설계) 작업을 한 프로젝트는 높은 확률로 통합 테스트 시 문제가 일어나고 팀 갈등에 빠질 가능성이 높았습니다.
특히 규모가 크고 복잡한 프로젝트일수록 이 가능성이 매우 높았습니다.
앞서 언급했듯이 앱/웹 개발은 서비스나 사업 기간에 비하면 현저히 짧은 기간(t가 0에 수렴)에 진행되므로 1단계에서 5단계까지 구조화 설계는 명백하게 통합 테스트에 영향을 줍니다.
그리고 실무적으로 보았을 때 대부분의 앱/웹 개발 기간이 9단계 코딩이 차지한다는 점에서 의외로 너무 많은 1단계에서 8단계까지 설계 단계가 기간에 비해 많다는 점을 주목해야 합니다.
이 단계를 구분하면 다음과 같습니다.
1단계~7단계 설계: 어떤 앱/웹을 개발할 것인가에 대한 구조적 설계
8단계: 어떻게 앱/웹을 개발할 것인가에 대한 구조적 설계
9단계: 1~8단계 설계를 바탕으로 프로그램(애플리케이션) 코딩
2.사업을 위한 개발 대상인 앱/웹 구조 설계: BA
1~5단계 설계 작업은 개발 타당성을 높여 줍니다. 정확히 개발을 해야 하는 이유에 합당한 앱과 웹이 만들어질 수 있도록 해줍니다.
이 말은 반대로 1~5단계 설계를 하지 않거나 부실하게 할 경우 확인이 가능한 수준의 앱과 웹이 완성될 경우 이견으로 인한 갈등이 생길 수 있음을 의미합니다.
예를 들어 이커머스 앱을 개발한다고 가정하겠습니다. 구매와 결제, 장바구니, 배송 등 이커머스 기능은 지마켓이나 쿠팡, 네이버 스마트스토어에도 다 있습니다. 그래서 이들 이커머스 앱이 유명하고 많은 유저가 쓰고 있다고 비슷하게 개발을 한다면 비즈니스 측면에서 만족을 할 수 있을까요?
이 케이스는 실제 제가 GS 그룹 이커머스 차세대 작업에 중간 투입 되었을 때 일어난 일이었습니다. 이로 인해 자회사인 SI 회사에서 형제 회사 SI 회사로 원청 개발 업체가 변경됩니다. 물론 다른 이유가 있을수도 있습니다. 그러나 제가 투입되어 원청이 변경되기까지 갈등은 바로 GS 이커머스 앱이 아닌 다른 이커머스 플랫폼을 개발하겠다는 것과 여러 앱의 기능과 DB를 통합하는 과정이 지연되는 것이었습니다.
GS 프로젝트에서 기능과 DB의 통합이 지연된 이유도 1~5단계 없이 바로 7~8단계를 시작했기 때문이었습니다.
그럼 1~5단계의 구조화 설계가 무엇이기에 이런 일이 일어난 것일까요?
2-1.비즈니스를 위한 타당한 앱과 웹의 개발을 위한 BA
아마 서비스 기업에서 서비스를 담당하는 PO 또는 기획, 설계자라면 비즈니스를 위한 앱/웹 개발은 당연한 것입니다. 평가 지표가 앱/웹의 매출과 비용과 직접적으로 연결되어 있기 때문입니다.
그러나 SI나 웹에이전시 같은 외주 개발사에서 기획과 설계를 했던 인력은 이를 제대로 이해하지 못할 수 있습니다. 평가 지표가 앱/웹의 매출과 전혀 관계 없기 때문입니다.
이런 이유로 비즈니스 타당성이 떨어지는 앱과 웹이 개발되는 경우가 많습니다. 심지어 고객사 상품이 복잡하거나 연동 시스템 등의 제약 조건이 어려운 경우 개발에 실패하는 경우도 종종 발생하게 됩니다.
이런 문제가 생기지 않게 하는 구조화 설계가 바로 BA인 것입니다. 이 작업은 화면 설계의 완성도를 높이는 요소가 되기도 합니다.
실제 제가 참여한 프로젝트들에서 문서로서는 깔끔하고, 작성 페이지 수도 많았던 화면 설계서가 개발하기에 부실했던 이유에는 앞서 작업되어야 할 BA 설계 없이 단지 다른 앱을 참고해서 화면을 설계한 것이 많았습니다.
2-2. BA 설계가 잘 이루어지지 않는 이유
기능이나 정책이라 하면 누구나 무엇을 의미하는 것인지 다 알 것입니다. 그러나 이를 프로젝트 상황에 따라 어떻게 작성해야 하는지는 모르는 경우가 많습니다.
기능은 다른 앱을 보면 쉽게 알 수 있습니다. 정책은 기능을 이용해 보고 약관, 고객센터를 보면 알 수 있습니다.
그러나 비슷해 보이는 기능과 정책도 앱 마다 조금씩 다르다는 것을 알 수 있습니다. 그러므로 개발할 앱/웹에 적용할 기능과 정책 세부 사항은 모르는 경우가 많습니다. 실제 회의를 해 보면 어떤 앱의 기능과 정책은 저렇고, 다른 앱의 기능과 정책은 어떻다는 말은 능란하고 설명하는 기획자는 많습니다. 그래서 우리가 개발할 앱의 기능과 정책은 어때야 하는지 결정해 달라고 하면 애매모호하게 말하는 경우가 많습니다.
이유는 간단합니다. 전자는 다른 앱을 보고 암기해 말하는 것입니다. 그러나 개발할 앱에 적용할 기능 세부 내용과 정책은 보고 따라할 것이 없습니다.
그리고 실무적으로 말하자면 앱/웹 화면 디자인과 설계라는 형식과 이 형식을 처리하기 위한 도구는 사용할 수 있지만, 앱과 웹의 세부 로직의 결정 이유인 비즈니스를 이해하지 못하기 때문입니다.
1~5단계는 비즈니스의 이해를 바탕으로 앱과 웹 개발을 설계하는 작업이기 때문입니다. 그래서 작업 이름도 BA(비즈니스 아키텍처), 작업자는 비즈니스 아키텍트라 부르는 것입니다.
2-2-1. BA 설계 예시 1
아래 이미지는 제가 BA 및 PM으로 투입되어 작업했던 구조 설계 작업 내용입니다. 기존 이커머스 플랫폼 내 건강 보조 식품 판매 촉진을 위한 추천 시스템을 개발하는 프로젝트였습니다. 외부 분석 시스템과 연동하여 추천 상품을 제공하고, 기존 운영 중인 이커머스 시스템에서 상품을 구매하게 하는 하위 연결 시스템을 개발이었습니다.
위 건강 보조 식품 추천 시스템은 고객사가 기존 운영 중인 이커머스 시스템과 외부 분석 시스템과 연동되어 작동합니다.
유저에게 건강 검진과 설문 내용을 받아 외부 분석 기업에게 전달하면 분석을 통해 결과를 전달 받습니다. 전달 받은 분석 데이터를 기반으로 기존 시스템에서 판매 중인 건강 보조 식품 중에서 추천 제품을 뽑아서 유저에게 제공합니다. 유저가 구매 선택하면 기존 운영 이커머스에서 상품을 구매하게 끔 하는 시스템입니다.
2-2-2. BA 설계 예시 2
아래의 2개 이미지는 과거 제가 진행했던 다른 작업입니다.
전형적인 앱/웹 개발 프로젝트의 기획/설계 과정인 화면 설계로 개발할 목적 시스템의 설계가 제대로 진행되지 못하고 지연됨에 따라 제가 중간 투입 후 문제 해결을 했을 때 초반 작업을 했던 구조 설계 문서입니다.
이 구조 설계 문서를 통해 성공적인 프로젝트 문제 해결을 완수 했습니다. 그리고 제가 인수인계 받은 문서는 미완성 화면 설계서였습니다.
대부분 문제가 있어 중간 투입된 프로젝트의 설계 자료는 1~5단계 설계서는 없고 화면 설계서만 있다는 공통점이 있었다는 점은 너무 많이 경험하여 이상하지 않을 정도입니다.
다음은 고객사 비즈니스 이해를 위해 상품 처리 프로세스를 정리한 것입니다.
위 프로세스의 프로젝트는 주차권 상품 관련 앱/웹이었습니다. 상품 처리 프로세스 단계마다 주요 정책을 고객사와 협의하여 확정하고 세부적인 처리 로직을 완성하였습니다.
이 개발할 앱/웹에서 판매하고 관리할 여러 상품의 프로세스를 정리한 후 이를 아래의 이미지 같이 전체 서비스 시스템의 구조를 설계하였습니다. 빨간 박스는 각 단계에 필요한 정책입니다.
해당 설계를 한 프로젝트는 제가 투입되기 전 이미 다수의 고급 개발자와 기획자, 설계자들이 투입되어 작업을 했다는 점에서 단순 기술이나 방법론의 형식적 문서화가 복잡한 개발의 경우 실효성이 없음을 보여준 사례라 할 수 있습니다.
실제 복잡한 상품과 정책, 개발 제약, 연동 관계를 지닌 시스템이라도 UI나 오픈 소스 프레임워크나 서버 등의 주장을 하는 것은 쉽습니다. 심지어 수백 페이지의 화면 설계서를 만드는 것조차 어려운 일은아닙니다.
이런 경우 단지 코드는 생산 되지만 통합 테스트에 다수 결함이 발생하고, 고객은 자신의 비즈니스를 위한 앱은 아니라고 할 뿐입니다.
이 상황을 비즈니스 타당성(비즈니스 목표 달성 및 전략 수행을 위한 앱과 웹)이 매우 낮은 앱/웹이 개발되었다 또는 개발이 아닌 산출물 제출을 위한 스토리보드가 만들어졌다고 합니다.
3.어떻게 하면 앱/웹 시스템 개발의 위한 구조화 설계를 할 수 있을까?
이 질문은 그 동안 기획/설계를 하면서, 프로젝트 완성도를 높이기 위해 기획자를 교육하는 방법론으로 고민을 많이 했던 것입니다. 그러나 답을 찾지는 못했습니다.
시스템 구조화 설계를 위해서는 당연히 시스템적 사고가 필요합니다. 그런데 이 시스템 사고가 설명으로, 그리고 특정 작업의 반복적 연습으로 만들어지지 않음을 경험했기 때문입니다.
그간 경험으로 차라리 이를 시스템화 하는 의사 결정(판단) 시스템을 만드는 것이 더 쉬울 것 같다는 생각을 했습니다.
3-1. BA(비즈니스 구조화 설계)가 어려운 이유
시스템의 단어적 의미는 "어떤 목적을 달성하기 위해 여러 요소가 일정한 규칙에 따라 상호작용하면서 작동하는 조직/체계/제도"입니다.
그러므로 기업, 프로젝트 팀 또한 시스템입니다.
개발은 고객사 뿐 아니라 SI 기업 같은 개발사 조직, 체계, 승진 체계 등에도 영향을 받게 되다는 것입니다. 그러므로 대부분이 경우 기획자 뿐 아니라 PM, AA, DA 등 조직과 시스템 설계를 담당하는 사람들은 어려운 BA보다는 쉬운 정치, 인맥 관계를 통해 문제를 타개하려 합니다.
이러한 흐름은 개발 측면에서는 문제 해결이 아니라 외면에 가깝지만, 개인 측면에서는 프로젝트가 잘못되어도 자신은 책임지지 않는 것이 되기 때문에 해결이라 생각합니다.
앱/웹 개발 구조화 설계 상위 구조화가 프로젝트 팀 구조화 설계, 개발사 조직 구조화 설계입니다. 그러므로 이런 정치적 활동 또한 일종의 비즈니스 구조화에 해당합니다.
사막에서 벼 농사를 할 수 없듯이 상위 비즈니스 구조화인 프로젝트 팀 구조화, 개발사 조직 구조화가 BA 작업을 할 수 없는 상황이라면 실질적으로 앱/웹 개발을 위한 구조화는 불가능합니다.
3-2. 앱/웹 시스템 개발 구조화 설계를 위한 대안
앱과 웹 시스템 개발도 결국 사람이 하는 것입니다. 놀라울 정도로 뛰어난 요즘 AI 조차 특정 상황에서는 환각에 빠져 잘못된 피드백을 제출합니다. 사람은 이 경우 대충 맞추어 일을 하거나 그 프로젝트를 떠날려고 합니다.
근본적인 앱/웹 시스템 개발 구조화 설계를 위한 대안은 이미 잡스가 과거에 정리했습니다. 바로 'A급, B급, C급 인재론'입니다.
화면 설계는 파워포인트만 할 수 있다면 작성이 가능합니다. 피그마 같은 툴을 쓸수 만 있어도 다른 앱을 참고해서 그릴 수 있습니다.
그러나 BA는 그렇지 않습니다.
BA는 기업마다, 앱/웹마다 다릅니다. 네이버의 BA는 네이버 것이지 쿠팡이나 구글의 BA는 아닙니다.
그러므로 앱/웹 시스템 개발을 위한 구조화 설계를 하기 위한 대안은 BA를 채용하는 것이 유일합니다.
국내에는 "꼭 너야 한다는 생각은 버려라", "너가 아니어도 누군가 한다" 같은 말이 있습니다. 그러나 지금의 IT 세상에서는 맞지 않는 말입니다.
오픈AI에서 나온 '다리오 아모데이'가 설립한 엔트로픽, 핵심 인재를 영입하기 위해 메타가 스케일 AI에 143억 달러를 투자한 이유, 이번 구글 핵심 인재인 존 점퍼의 엔트로픽 이직과 노암 샤지어의 오픈AI 이직 사건 등은 이런 말이 틀림을 의미합니다.
앱/웹 시스템 개발을 위한 구조화 설계를 하기 위한 대안은 그냥 그 정도 능력이 되는 인재에 그 정도 금액을 지불하여 쓰는 것 밖에 없습니다.
일단 아무나 적당한 인력을 쓰고 안되면 또 다른 인력을 쓰고 이렇게 시간이 흘러 지급할 수 있는 맨먼스 비용이 줄어 들여 또 저렴한 비용의 인력을 찾는 반복은 결국 수 십명의 개발자 비용을 허공에 날리고 추가 개발을 해야 하는 손실의 상황을 만들 것입니다.
3-3. A급 BA를 찾을 수 없다면
A급 BA를 확보한다는 것은 앱/웹 개발 프로젝트 성공률을 높이는 가장 쉬운 방법입니다. 어떤 앱/웹을 개발해야 하는지 명확히 알 수 있기 때문입니다.
그러나 A급 BA를 채용하는 하는 것은 단지 개발 프로젝트 맨먼스 단가 초과 이상의 큰 문제가 존재합니다. 바로 A급 BA는 극히 희소하다는 점입니다.
비즈니스 아키텍처 설계는 단지 여러 앱과 웹을 이용해보고 화면을 그려 보는 것으로 할 수 있는 것이 아닙니다. 또한 코딩 경험으로도 축적할 수 없는 역량입니다.
이에 대한 대안으로 플랜앤서치 SSF를 제안할 수 있습니다.
SSF의 총 4개 계층(Layer)으로 되어 있습니다. 이 중 1계층의 비즈니스 아키텍처 계층은 사업 계획을 서비스적으로 설계하는 작업을 수행합니다.
앱/웹 개발와 직접 연결되는 계층은 2계층과 3계층입니다. 개발 프로젝트의 BA와 연관성이 가장 큰 SSF 계층은 2층으로 사업 기반 서비스 설계를 구체적인 개발할 시스템으로 전환합니다. 3계층은 유저와 시스템의 상호작용을 설계합니다.
많은 프로젝트가 비용 절감 또는 BA작업의 낮은 이해로 인해 초반 설계에 실패하여 개발 중후반 혼란에 빠져 손실을 보게 됩니다. 그러므로 믿을 만한 비즈니스 구조 설계 파트너가 있다는 것만으로 프로젝트 수익률을 극적으로 높일 수 있는 방안임은 분명합니다.
댓글