앱과 웹, 시스템 외주 개발 기획에서 공학적 프로젝트가 더 쉬운 이유

여기서 가정은 온라인 서비스 기획, 시스템 기획 등 총체적 상품 기획이 아니라는 점입니다. 단지 외주 개발 시 주어지는 기획의 정도를 한정합니다. 그리고 공학적이라는 의미는 복잡하고 난해하지만 정리되어 있고, 데이터 정의가 잘 되어 있어며, 원인과 결과가 항상 같은 상황을 의미합니다. 

 

 

 

앱/웹, 시스템 개발 상황 중 외주

 

애플이 개발 외주를 한다고 했을 때 iOS 전체 또는 앱스토어 시스템 전체를 외주 주지는 않습니다. 또한 아이메시지, 넘버스, 페이지 등의 앱을 개발하는 것도 전체를 외주 주는 일은 없습니다.

 

외주 개발을 한다는 것은 비용과 자산, 핵심 역량과 경쟁 우위 유지 등 다양한 고려하에서 이루어집니다. 여기서 최적의 선택이 개발의 외주로 나타나는 것입니다.

 

그러므로 기획, 개발, 디자인 등 외주 개발 부분과 내부 개발 부분은 구분되어야 합니다. 그리고 일반적인 기업에서는 구분하여 진행합니다. 이는 비용 투자와 매출, 점유율과 이익 등을 다루는 경영학에서 가치 생성의 네트워크 전략으로 학부 때부터 공부하는 너무나 당연한 사항이기도 합니다.

 

이러한 지속적 경쟁 우위를 위한 가치 생산 네트워크 전략을 잘 보여주는 최근 사례로 애플의 TSMC, 폭스콘을 포함한 가치 생산 네트워크를 들 수 있습니다. 

 

이렇듯 외주는 핵심 역량이 아닌 부분에 대해 이루어집니다. 또한 '디자인 BY 캘리포이아'에서 알 수 있듯이 미리 정해진 설계에 따라 진행되는 단순 작업이 부여됩니다.

 

가치를 생산하는 전체 과정 중 단순 작업이라도 시간과 인력이 필요한 것은 같습니다. 단지 단순 작업과 핵심 작업은 일정 이상 해당 분야 기술만 있으면 할 수 있는 작업과 그렇지 못한 작업의 구분, 이 작업이 제품 경쟁력에 결정적이냐 아니야의 차이만 있을 뿐입니다. 이 차이에 따라 외주도 달라지게 됩니다. 

 

때로는 핵심 작업의 일 부분인 특별한 기술과 역량이 필요한 작업, 경쟁력에 결정적 영향을 주는 요소도 외주를 해야 하는 경우가 있을 수 있습니다. 이 경우 계약 자체가 다릅니다.

 

이런 점에서 국내에서 주로 이루어지는 SI, 웹에이전시 대행 기준 외주 개발은 단순 작업에 해당한다고 볼 수 있습니다.

 

일단 우리 앱/웹/시스템 개발을 한 개발자나 기획자, 디자이너가 프로젝트 종료 후 경쟁사 앱/웹/시스템을 개발하는 것이 큰 문제가 되지 않습니다. 심지어 이런 경우 개발자나 기획자, 디자이너가 더 선호됩니다.

 

이 말은 공개되어도 큰 문제가 안 되는 개발 작업을 했다는 것을 의미합니다. 그리고 앱/웹이 공개될 시 누구가 알 수 있는 부분의 개발을 하고 있음을 알 수 있습니다. 

 

하다 못해 애플이 삼성전자 파운드리에 칩 생산을 맡기지 않는 것에서도 이런 상황은 알 수 있습니다. 

 

어떤 기업도 외주 개발/생산을 통해 자신의 경쟁력, 시스템의 핵심 비밀을 다른 기업에 공개하려 하지 않습니다. 만약 어쩔 수 없이 그래야 한다면 법적으로 다양한 보호 장치를 만들 것입니다. 하다 못해 직원이 이직할 때도 일정 기간은 경쟁사로 이직하지 못하는 퇴직 계약을 하기도 합니다.

 

 

 

공학적 시스템의 외주 개발이 더 쉬운 이유

 

공학적 시스템 복잡하고 난해하지만 잘 정리된 시스템을 의미한다고 했습니다. 만약 A가 들어가면 B가 나오는 시스템이라고 하면 어떤 상황에서도 A 입력 시 B가 산출됩니다. 공학적 시스템에서 예외 발생은 버그입니다.

 

물론 앱이나 웹, 시스템의 복잡하고 난해한 로직 및 변수 정의 등을 설계한다는 것은 매우 난이도 높은 기획 작업이기는 합니다. 하지만 이런 기획 작업을 외주 개발 기획으로 처리하는 경우는 없습니다. 이런 기획 작업은 내부로 하거나 컨설팅을 통해 진행합니다.

 

그리고 도출된 로직, 변수 등의 설계를 바탕으로 만들어진 요구 사항을 외주 개발 기획에 전달하게 됩니다.

 

외주 개발 기획자는 연산 로직이 아니라 이러한 연산 모듈 및 시스템을 이용할 수 있는 작동 로직을 바탕으로 기획을 하게 됩니다. 

 

상당히 많은 외주 기획자는 UI, 화면 설계 부분만을 기획하기도 합니다. 전체적인 앱/웹/시스템 설계를 바탕으로 한 작동 로직조차 기획하지 않는 것입니다. 앱이나 웹에서 작동 로직을 고려하지 않거나, 이는 화면 설계 후 개발자가 알아서 코딩해야 하는 것으로 남겨두기도 합니다.

 

 

  

외주 개발 기획 예시

 

 

ERP 시스템 중 회계처리 부분

 

예를 들어 SAP 등 회계 시스템을 기반으로 특정 기업이 사용하는 시스템을 외주 개발한다고 가정합니다.

 

아마 이때 투입되는 기획자는 거의 없을 수도 있습니다. 일단 SAP와 같은 시스템이 처리해 주는 부분과 디자이너, 개발자 조합으로도 처리가 대부분 가능하기 때문이기도 하고, ERP 시스템 기반 개발의 특성상 기획자가 할 부분이 거의 없기 때문입니다.

 

대부분의 기획자는 아마 SAP 등의 회계 시스템의 로우 한 상태를 해당 기업에 맞게 튜닝하는 개발 전 사전 작업에 투입될 것입니다.

 

저의 경우 SAP 회계 시스템 개발 기획자 경험은 없습니다. 그냥 회사에서 이런 ERP 시스템을 적용하고 사용하는 작업만 해보았을 뿐이고, SAP에 연동되는 웹전표 시스템 프로젝트 하나의 기획자를 한 것이 대부분입니다.

 

그럼에도 이렇게 이야기를 할 수 있는 것은 회계 시스템이기 때문입니다.

 

회계는 회사마다 다르면 안 됩니다. 그러므로 기준을 정합니다. 이를 국제 회계 기준, 각 국가마다 정해지는 기업 회계 기분이라 합니다. 

 

기본적으로 해당 기업에 적용할 회계 시스템이기 위해서는 국제 회계 기준과 기업 회계 기준에 기반한 표준 처리 프로세스와 이를 이용하기 위한 기본적인 UI가 세팅되어 있어야 합니다.

 

이 과정의 시스템 개발 기획이 복잡하고 어려운 것입니다. 그렇다고 이 설계가 불가능한 것은 아닙니다. 단지 어려울 뿐 일정 이상 회계, IT 기술만 있으면 누구나 가능합니다. 로직은 제 회계 기준과 기업 회계 기준에 기반한 회계 로직을 벗어나지 않기 때문입니다. 

 

그러나 로우 한 회계 시스템은 어느 기업에서나 사용할 수 있는 상태지만, 어느 기업에나 딱 맞는 상태는 아닙니다.

 

그래서 각 회사의 업무 처리 방식과 회계 기준에 따른 시스템 커스터마이징이 필요합니다.

 

메가 커피 예를 보겠습니다.

2019년에서 2022년 메가 커피 실적

 

메가 커피의 매출은 2019년 지속 성장합니다. 그리고 영업이익도 성장합니다.

그런데 2022년 이상한 일이 발생합니다. 매출도 증가했고, 신규 매장도 성장했는데 영업이익이 줄어든 것입니다. 

 

이러한 변화는 여러 가지가 있을 수 있겠지만, 이 기간 메가 커피의 회계 처리 방식이 달라졌기 때문일 수도 있습니다. 그렇다면 메가 커피의 모든 회계 장부를 수기로 하지 않는 이상 회계 시스템을 변경된 방식에 따라 조정해야 합니다. 일반적으로 회계 시스템 관련 기획자가 투입되어 작업을 하게 됩니다.

 

그렇다고 메가 커피가 회계 잘못했다는 뉴스는 없습니다. 그러므로 2021년 이전과 2022년 회계 처리 방식이 법적으로 문제가 없는 것입니다.

 

이런 것을 통해 회계 기준이 반드시 하나만 존재하는 것은 아니라는 점을 알 수 있습니다. 기업의 상황에 따라 기준이 다를 수 있고, 각 기업마다 주로 이용하는 기준이 다를 수도 있습니다. 

 

같은 비용이라도 회계 상 비용으로 처리되는 경우도 있고, 회계 상 자산으로 잡혀있다가 매년 상각처리 할 수도 있습니다.

 

이러한 회계 처리 방식을 회계 시스템 커스터마이징이라고 할 수 있습니다.

 

여기에 기업마다 회계 처리를 위한 품의 단계 및 부서 등이 다를 수 있습니다. 이에 대한 회계 진행 프로세스에 대한 맞춤도 필요할 것입니다. 그래야 좀 더 편한 ERP 회계 시스템이 될 수 있을 것입니다. 

 

이를 사전에 SAP가 모든 기업의 상황을 모두 알아서 수 십만, 수 백만 케이스를 미리 세팅해 놓지는 않습니다. 그러면 너무 비효율적입니다. 그래서 회계 시스템을 구매한 기업에 대해 기획자 또는 컨설턴트가 투입되어 최적화 설계하는 하는 것입니다. 그리고 이를 바탕으로 개발을 하게 됩니다. 

 

여기서 외주 개발은 회계 시스템 자체를 개발하는 것이 아닙니다. 회계 시스템을 구매한 기업이 이용할 수 있게 개발해 주는 것입니다.

 

그러서 외주 개발을 주어진 로직 및 시스템의 작동을 개발하는 것이라 했던 것입니다.

 

 

 

물류 시스템 외주 개발

 

물류 시스템의 외주 개발은 상품의 이동을 중심으로 작동을 개발하는 것이라 할 수 있습니다.

 

여기서 상품의 이동을 간략화해 보겠습니다.

일단 상품 상차 픽업하고 하차 전달하는 것을 것으로 볼 수 있습니다. 그러나 이 과정에서 다양한 하위 작업 프로세스와 시스템의 연결이 필요합니다.

 

일단 상차 픽업하는 상품과 관련한 정보입니다. 이는 창고 관리 시스템과 재고 관리 시스템에 연동되어 있습니다. 각 상품 일정한 인식 정보가 부여되어 있습니다. 이는 상품의 카테고리 및 관리 등의 기본 상품 데이터베이스, 상품의 위치 정보의 창고 DB, 입출입 등의 재고 관리 DB 등에 따라 상차되는 상품의 정보가 입력됩니다. 

 

상차 시 특정 배송 차량에 배차되므로 상품 배차를 결정하는 로직과 이 차량이 하나의 상품이 아니라 다수의 상품을 배송할 경우 최적의 이동 동선에 맞추어 상품이 배정되는 로직의 배차 시스템이 적용될 것입니다.

 

상차와 하차 사이에도 차주의 상품 파악과 관리를 위한 앱이 제공될 것이고 물류 관계 시스템을 이 차주의 앱과 연동하여 어떤 상품이 어떤 차량에 상차되어 어디로 이동하는 확인할 수 있게 됩니다.

 

이외에도 연동되는 다양한 시스템이 물류 시스템에는 존재할 수 있습니다. 지금은 그냥 블로그를 쓰면서 생각나는 대로만 몇 개 적어보았습니다. 그럼에도 상당한 인터페이스 필요한 시스템이 나오는 됩니다.

 

일반적인 UI는 이런 시스템 간 인터페이스까지는 기획하지 않습니다. 그러므로 보통 UI 또는 화면 설계 기회자는 독립 시스템의 외주 개발에 주로 투입됩니다.

 

그러나 요즘은 다양한 API 등의 활용이 되는 외주 개발이 많아졌습니다. 이에 따라 개발하는 앱/웹만 독립적으로 보아서는 작동하는 UI 개발이 어려운 경우가 많아지고 있습니다. 요즘 외주 개발 시 문제가 많이 발생하는 이유기도 합니다.    

 

 

 

이커머스 외주 개발

  

금융 관련 프로젝트만큼 많은 외주 개발이 이커머스 프로젝트입니다. 요즘은 2022년 이전에 비해 경기가 너무 안 좋아 조금 뜸해지기는 했습니다.

     

금융 프로젝트의 경우 회계 프로젝트와 유사한 케이스에 속합니다. 물론 산업과 처리 시스템이 정말 다르기는 하지만 금융 정보가 회계 정보와 같이 반드시 일치해야 한다는 점에서, 금융 데이터도 일종의 회계 데이터이고, 기업 입장에서 금융 거래의 발생은 회계 처리의 발생이라는 점에서 저는 그렇게 구분합니다. 단지 산업 특수성 변수만 적용하면 거의 같다 생각합니다.

 

그러나 이커머스는 완전 다른 시스템입니다. 회계 데이터가 아니라 거래를 위한 시스템이 중심이 된다는 점에서 그렇습니다. 그리고 이커머스 시스템을 통한 처리가 완료되어야 회계 처리의 대상이 발생하므로 이 둘은 구분할 수 있습니다.

 

이커머스 앱/웹과 같은 시스템을 간단히 보면, 

온라인에 판매할 상품을 노출하고 사용자가 구매할 수 있게 하고, 구매한 상품을 배송하는 단계로 정리할 수 있습니다.

 

여기에 이커머스 시스템은 직매입이냐 오픈 마켓 같은 거래 제공 플랫폼이냐에 따라 사용자에게 보이는 앱/웹은 비슷하지만 처리 플로우는 달라지게 됩니다. 

 

특히 여기에 어떤 시스템 들과 연동하여 정보를 관리자에게 보여 줄 것인가 또는 admin에서 관리할 수 있게 허용할 것인가에 따라 개발의 범위와 내용은 많이 달라지게 됩니다. 당연히 일반 구매 사용자 입장에서 보이는 게 크게 달라지지는 않습니다.

 

여기까지가 아주 일반적인 이커머스 시스템 개발에 대한 것입니다.

 

솔직히 일반 구매 사용자 입장에서 다를게 거의 없기는 합니다. 그러나 관리자(admin), 연동 시스템 등의 구매 사용자가 보지 못하는 부분의 이슈는 상당합니다. 이런 이유 때문에 사용자 경험을 바탕으로 한 기획은 개발 기획으로는 한계가 있는 것입니다. 그렇다고 불가능한 것은 아닙니다. 약간의 경험과 상상력만 있다면 말입니다. 

 

그러나 역대급 개발비를 투입했음에도 2020년~2022년 진행되었던 많은 프로젝트가 어려움을 겪었습니다. 제가 투입되었던 이커머스 프로젝트에서 어려움이 상당했습니다. 

 

개인적으로 이런 문제가 왜 생기나 분석을 해 보았습니다. 문제는 크게 두 요소의 충돌 때문이었습니다. 하나는 높아진 외주 개발 비용과 외주 개발이라는 특성이 때문입니다.

 

이커머스 외주 개발비가 상승함에 따라 고객은 당연히 각각의 시스템 연동과 로직 설계까지 기대합니다.

 

특히 이 시기 많았던 기존 유통 대기업들의 온라인 프로젝트에서 이런 문제가 크게 발생했습니다. 이 기존 유통 대기업의 핵심 역량은 오프라인에 있습니다. 그리고 온라인은 당시 성장하는 온라인 스타트업들에 의해 오프라인 시장을 잠식당하고 있었기 때문이었습니다.

 

그래서 부족한 이커머스 지식을 막대한 자금으로 구매한 것이었습니다.

 

이런 이유로 온라인 로직 설계 및 각 시스템의 연동 인터페이스, 처리 방식은 알아서 외주 개발 기획자가 해주기를 원했습니다. 문제는 여기서 나타납니다.

 

앞서 말했듯 대부분의 외주 개발 기획자는 화면, UI 기획을 하지 정보 처리/사용자 로직 설계, 상이한 시스템의 연동 인터페이스 등을 작업하지 않습니다.

 

대기업은 기존 여러 이커머스 및 오프라인 상품 관리 시스템이 있었습니다. 이를 통합하여 하나의 이커머스 시스템에서 판매/관리가 가능하게 하기를 원했습니다. 하지만 외주 개발 기획자는 이를 해 본 적이 없는 경우가 대부분입니다. 필요한 경우 개발자가 처리하는 게 일반적 R&R이었습니다.

 

그러므로 통합 장바구니, 상품 관리/판매가 처리될 수 없었습니다. 통합 장바구니, 결제 화면은 기획되었고, 디자인되었지만 작동이 안 되었습니다. 때때로 데이터 에러가 나오기도 했습니다.

 

이런 시스템 통합의 문제는 쿠팡 이전 이미 전국에 수많은 물류 거점과 판매 거점을 형성하였고, 배송도 하고 있었던 이마트, 롯데마트가 인프라를 사용할 수 없었던 이유입니다. 그리고 쿠팡에게 밀리게 된 이유기도 합니다. 

 

SI가 시스템 통합의 약자라는 점에서 아이러니가 아닐 수 없습니다. 그리고 이런 대기업 SI 자회사를 가지고 있습니다.

 

간단히 상식선에서 상품 DB만 정리하고 마치겠습니다.

 

기존 독립적으로 운영되던 오프라인 법인이 A, B 2개가 있고 온라인 법인 C 하나가 있다고 가정합니다. 이 상황에서 통합 이커머스 플랫폼을 개발한다고 하겠습니다.    

 

통합 이커머스 플랫폼이 D라고 할 때 A, B, C, D의 상품 DB 서로 다르다고 가정합니다. 이 상황에서 기존 A, B, C 상품 데이터를 D에 맞추어 모두 바꾸는 것은 문제가 있습니다. 최악의 경우 A, B, C 모든 시스템을 다시 개발할 문제가 생길 수 있습니다. 또한 과거 데이터를 확인하기 위한 별도 시스템 또는 과거 데이터도 D에 맞추어 다 변경해주어야 합니다. 이것이 엄청난 작업입니다.

 

그래서 일단 앞으로 처리되게만 개발 작업한다고 하면 생각할 수 있는 것인 허브 DB 서버입니다. 통합 이커머스 플랫폼에서 A, B, C의 상품을 바로 가져오면 DB 구조가 달라 에러가 발생할 수 있습니다. 그러므로 중간에 DB 변환 서버를 두어 D에서 이용할 수 있는 형식으로 변환한 후 이를 각각 매핑하여 두는 것입니다.

 

물론 블로그 쓰면서 잠깐 생각해도 처리 과정도 길고 작업해야 할 부분, 데이터 규정 및 처리 로직에 대한 부분 등 작업할 것이 많을 것입니다. 

 

각 A, B, C가 운영 중인 창고나 오프라인 마트 등을 물류/배송 거점으로 이용하는 것은 더 복잡한 IT 개발이 필요합니다. 상품 DB 연동은 물론 물류 시스템 및 재고 관리 시스템의 추가 개발과 인터페이스가 필요합니다. 이 부분은 위의 물류에 대한 이야기로 넘어가겠습니다.

 

간단히 한마디만 하자면  허브 앤 스포크 최적화를 추구할지, 각 기존 물류 창고를 개발 노드로 하는 상호 최적화를 할지에 따라 상품 관리/이동 로직은 달라질 것입니다. 

 

이커머스 앱/웹 외주 개발은 이런 로직, 시스템 개발을 하지 않습니다. 당연히 기획도 없습니다. 

 

기획은 이런 시스템이 다 있다고 해도 연동 기획조차 하지 않는 케이스도 있습니다.

 

제가 투입되어 분석한 몇 개의 프로젝트에서는 화면은 있는데 화면을 개발한 자원이 없는 기획서, 기능 처리 화면이 있는데 개발에 이용할 시스템으로 나타내는 화면과 다른 기획서 등도 있었습니다. 어떤 이커머스 시스템은 앱/웹 개발과 상품 DB 정리 작업이 각각 다른 프로젝트로 2개가 운영되고 있는데 두 DB가 서로 다른 경우도 있었습니다.  

 

문제는 기획에서 왜 안 되는 이해를 못 하고 있다는 상황이었습니다.

 

개인적으로 그렇게 많은 프로젝트를 한 기획자인데 왜 모를까 이상했었습니다. 그러나 기획자뿐 아니라 디자이너와 개발들과 많은 이야기를 한 후 이유를 분명히 알 수 있습니다.

 

한 적이 없기 때문입니다. 화면 설계만 하거나 산출물로 기획서 작업만 했던 것입니다. 이는 기획자 개인의 문제가 아닌 외주 개발의 특성으로 볼 수 있습니다.

 

 

 

어려운 외주 개발 기획

 

정말 어려운 외주 개발 기획은 공학적 시스템 개발이 아닙니다. 개발은 쉬워도 취향을 반영해야 하는 앱/웹입니다. 그리고 그 취향이 문제가 있거나 서로 충돌하는 프로젝트는 정말 어렵습니다.

 

공학적 시스템은 A를 넣으면 B가 나옵니다. 이는 절대 변할 수 없습니다. 그러나 취향 기반 프로젝트는 A를 넣으면 B가 나오기도 하고 C 또는 D도 나올 수 있습니다. 심지어 사람에 따라 B가 맞다고 하고, 다른 사람은 C가 맞다고 합니다.

 

취향 중심 외주 개발의 경우 개발을 위한 정리가 되어 있지 않은 경우도 많습니다. 요구 사항이 취향이므로 프로젝트 때문에 처음 본 입장에서 알 수 없습니다. 그리고 취향의 설명을 자신이 그린 그림으로 하는 경우도 있습니다. 이를 와이어프레임이라고 하면서 말입니다.

 

문제는 이 취향을 주장하는 담당자가 최종 의사결정자가 아닌 경우가 많습니다. 그러므로 기획은 화면 설계를 무한 반복이 됩니다.

 

사실 이런 경우 기획자로 너무 힘이 듭니다. 기획 단계에서 화면 디자인 수정을 하고 있는 것입니다. 그렇다면 그냥 디자인 작업을 하면 되지 왜 기획을 하는지 이해가 되지 않습니다.

 

실제 중간 투입된 외주 개발 프로젝트에서는 기획서는 없는데 디자인 파일은 다 있는 케이스도 있었습니다. 그런데 고객은 컨펌한 게 아니라 해서 이 디자인 파일이 어떻게 있는 것인지도 확인이 안 되었습니다.  

 

이런 프로젝트가 화면이 아닌 복잡한 기능 개발, 데이터 처리 등의 있다면 정말 어렵다 못해 진행이 불가능합니다. 아니 어떻게든 개발은 끝낼 수 있을 것입니다. 그러나 서비스가 진행되면 될수록 문제가 불거질 것입니다. 이는 고객사에 상당한 문제가 될 것입니다. 차리리 개발에 실패하는 것이 더 좋았을 것이라 느낄 수도 있습니다.

 

저의 경우 외주 개발 기획뿐 아니라 자체 서비스도 작업했기에 이런 생각을 하는 것일 수 있습니다. 내가 서비스 시 문제 생길 방식으로 개발하고 운영하고 싶지는 않기 때문입니다. 그러나 외주 개발은 다릅니다.

 

제가 기획/PM을 맡았던 어떤 프로젝트에서는 개발의 절반 가까이 앞의 프로젝트 개발 소스를 그대로 사용하면 되는 것이 있었습니다. 앞 프로젝트는 거의 끝이 나가서 개발자를 그대로 우리 프로젝트로 데려와서 작업하는 것으로 외주 개발사가 생각하고 있었습니다. 그런데 앞을 프로젝트 개발자가 한 명도 합류하지 않는 상황이 발생했습니다.

 

그래서 이전 프로젝트 기획서를 분석하고, 개발된 프로그램을 개인적으로 아이디를 받아 테스트해 보았습니다. 그런데 그 잠깐 혼자서 하는 수동 테스트에서도 상당한 에러를 발견했습니다. 분석한 기획서는 개발을 할 수 없는 상태였습니다. 실제 개발도 기획서로 한 것이 아니라는 사실을 알게 되었습니다.

 

이 경우라도 완료 컨펌받고 철수하면 외주 개발에서는 끝이 납니다. 오히려 에러로 시작되어야 할 제 프로젝트가 중단되었습니다.

 

기획 입장에서 너무나 뻔하게 개발이 안될 취향에 맞추어 설계를 해야 하는 경우, 그렇지 않으면 기획서 컨펌이 절대 안 되는 상황이라면 너무 힘이 듭니다.

힘들게 취향을 맞추었더니, 취향을 맞춘 담당자 그 위의 담당자는 이게 뭐냐고 리젝트 하는 경우도 힘이 듭니다. 기준이 없는 경우기 때문입니다.     

 

차리라 처음 파악은 어렵지만 파악만 되면 돌발 변수가 없는 공학적 시스템의 외주 개발 기획이 더 쉽습니다. 

 

마치 데이트 시 '그렇게 설명했는데 내 마음 왜 몰라?' '잘못한 게 뭐야?'라는 질문의 상황이 더 쉬울 것입니다.