devsuru 님의 블로그

[현장실습 #5] 신사업 프로젝트 개발단계 프로토타입 제작 및 구현

suru — Tue, 27 Oct 2026 22:36:12 +0900

현재 나는 현장실습으로 다니고 있는 회사의 신사업 프로젝트에 참여 중이다.

고객 조사부터 페르소나 제작, 콘셉브리프 도출 그리고 스토리보드 및 퍼널까지 설계를 하였고 이제 만들어진 것들을 토대로 프로토타입을 만들어야 한다.

우리 프로젝트는 서비스 제공 프로젝트라 우선 고객이 들어와서 서비스를 신청 할 수 있게 만들어야 하는 웹사이트가 필요하다.

순서대로 포스팅을 읽고 있다면 조금 혼란스러울수도 있는 부분이 있다.

서비스 경험 디자인 책에 보면, 프로토타입 제작과 스토리보드 제작은 닭이 먼저냐, 달걀이 먼저냐와 같다고 적혔있다. 딱 그대로이다, 현장실습 #4 와 #5도 프로토타입을 제작했다가, 스토리보드를 했다가 하면서 왔다갔다 하면서 진행된 프로세스다.

조금 혼란스러워도 이해해주시길 바란다.

개발자가 더 이상 개발만을 하지 않는다. AI시대에서의 개발자는 개발외에 다른 능력들도 요구된다.

그 중에 가장 많이 요구 되는 능력이 기획 능력이다. 예전에는 요구사항을 받고 개발만 하면 1인분으로 충분했다.

하지만 개발자의 많은 부분은 클로드가 해주는 현재 시점에서 개발자가 1인분을 할려면 기획, 마케팅, 디자인등 다른 능력도 필요하다고 생각한다.

그런면에서 현장실습에 와서 새로운 프로젝트에 참여하여 고객조사부터 프로토타입까지 고객의 의도를 파악하고 생각하며 개발을 할 수 있다는 것이 나에게 개발외에 다른 능력을 키우는 것에 큰 도움이 되고 있다.

오늘은 이렇게 처음부터 프로젝트를 하면서 내가 느낀 개발과 기획에 대해 나누려고 한다.

개발자로서 웹사이트 제작

개발자로서 UI/UX를 고민해보고 랜딩 페이지를 만들어본 경험이 이미 있는 입장에서는 사실 크게 어려울꺼라고 느끼지 않았던거 같다. 특히나 Claude, GPT 와 같이 개발하는 현 시점에서 프론트 개발을 딸각으로 할때가 정말 많다. 개발 프로세스를 보면 특별한 이슈가 없으면 에퀴지션에서 받은 콘텐츠들을 어느정도 나열하고, 구조를 짜고 해당 프로젝트 레포를 만들어 틀을 갖추고는 디자인이나 배치 등은 AI 한테 맡겨서 개발을 했었다. 물론 프로젝트 구조도 클로드가 잘 짜주긴 한다.

(회사에 중요 웹사이트인 경우에는 다양한 팀의 힘을 얻어 회의를 통해 승인이 난 내용들로 개발을 진행 하겠지만 인턴으로서 비중이 작은 페이지들을 주로 개편을 하기에 내 취향대로 아무 승인없이 개발을 많이 했었다.)

그리고 내 입맛에 맞게 음 여기 조금 별로 인거 같은데 하는 개인적인 취향도 반영하고, 해클을 통해 버튼, 스크롤 데이터를 수집해서 왜 여기서 사람들이 나갈까, 왜 이 버튼은 안누를까 같은 고민도 하면서 수정을 했었었다.

이렇게 콘텐츠를 에퀴지션팀에게서 어느정도 받고 개발을 하는 것이랑 현재 자료조사, 페르소나, 콘셉 브리핑까지 직접 도출해서 하는 웹사이트 개발은 느낌이 굉장히 다르다.

우선 우리팀은 책을 반영해 프로토타입팀, 컨텐츠팀, 스토리텔링팀으로 나뉘었다. 개발부서에서는 나와 나의 시니어(사수분)가 있었기에 우리는 우선 프로토타입과 컨텐츠 두개를 같이 진행하기로 되었고, 나머지 부서분들은 (에퀴지션/기획부서 사람은 없었음) 모두 콘텐츠와 스토리텔링을 하시기로 하셨다.

회사를 다니면서 프로젝트를 하는거다보니 따로 회의시간이 많이 주어지거나 그렇지 않아서 팀들간에 충분한 소통이 이루어지기가 쉽지 않은거 같다. 특히나 팀원 마다 우선순위가 있을꺼라 생각하는데 누구에는 이미 주어진일이 우선순위가 되면 신사업 프로젝트는 미루어질 수 밖에 없다는 생각이 든다. 특히나 우리 팀에서는 개발팀을 제외하고는 다들 너무 바쁘셔서 우리 프로젝트가 우선순위에서 밀려나가고 있는게 보였다.

그래서 이 프로젝트를 나름 우선순위로 두고 진행하고 있는 우리 개발팀은 우선 콘텐츠 및 구조를 스토리보드보다 먼저 정해서 프로토타입을 만들어 빠르게 피드백 받아 수정해 나가는 방식으로 일을 진행하기로 내부적으로 협의를 했다.

그렇게 스토리보드 없이 프로토타입 제작을 위해 처음부터 웹사이트안에 구조를 만들어야하는 건데..

우리 페르소나가 4명인거는 아마 앞에 블로그를 읽었으면 알 것이다. ~~그중에서 2개의 페르소나 분류는 이번 프로젝트에서는 제외하기로 해서 콘셉브리프가 도출된 두개의 고객 대상으로만 개발을 진행하기로 했다.~~ 하나더 추가해서 3개로 하기로 했다.

그렇게 만들어야 하는 페이지는 크게 3가지가 되었는데

1. 공통 웹페이지

2. 모집단1 페이지

3. 모집단2 페이지

4. 모집단3 페이지

이미 있는 개발팀 일도 처리해야 때문에 사수분께 레포 초대를 받으면 비교적 여유로운 내가 초기 기본 틀은 내가 잡기로 했다.

그리고 하게 된 기획 없는 프로토타입 제작

프로토타입은 말 그대로

프로토타입은 제품이나 소프트웨어를 본격적으로 개발하기 전, 아이디어를 검증하고 기능과 디자인을 미리 테스트해 보기 위해 만드는 초기 시제품 또는 원형

초기 시제품/원형이다 언제던지 바꿀 수 있고, 업데이트가 가능하다.

초기에 가장 힘들었던점이 프로토타입을 완성품으로 간주를 하고 고민을 하는 습관 때문이었다.

에자일 에자일 .. 그토록 많이 들었지만 실제로 실천하기에는 쉽지 않았다.

스토리보드가 없는 시점에서 콘텐츠도 아무것도 없고 정해진게 없는데 그러면 지금 나는 기획부터 해야하는 건가? 콘텐츠는 그러면 어떻게 넣지? 뭘 해야하지? 다양한 생각으로 무작정 웹사이트 기획하는법 하면서 몇 시간을 블로그를 읽고 정리하고 있기도 했다.

이때 프로토타입은 아직 완성된 제품이 아니고 피드백을 받으면서 얼마던지 수정이 가능한 페이지이니 우선 기본 틀만 잡아보고 콘텐츠를 천천히 넣어볼까요 ? 하면서 사수분의 제안이 많이 도움이 되었다.

그렇게 먼저는 가장 필요한 기능과 필요한 페이지들을 판별하고 기본적인 사용자 흐름을 정리해보기 시작했다.

그리고 기본적으로 우리 웹사이트들이 쓰는 랜딩페이지 형식으로 이미지와, 테마를 생성해 간단한 페이지를 만들었다.

그리고선 나온 콘셉브리프 멘트들과 콘셉을 활용해 페이지를 채워나갔다.

우선 여기까지를 활용해서 기본적인 프로토타입 구상을 끝내고 단톡방에 보냈다 !

저번 글처럼 모두 각자의 일의 바쁘셔서 답을 받지는 못했다 그리고 회의를 하고 스토리보드 및 퍼널을 우선 구축해야한다는 이야기가 나왔고 나도 하나의 페로소나를 맡아 저번 글 처럼 제작하였다.

2026.10.19 - [현장실습] - [현장실습 #4] 신사업 프로젝트 전환 퍼널 및 스토리보드 기획/설계

제작을 한 후에는 나는 콘텐츠를 만들기 시작하였다.

내가 맡은 페르소나에 맞게 사람들이 클릭할만한 컨텐츠를 만들고 해당 퍼널에 맞게 멘트를 넣으면서

마지막 버튼을 클릭하게끔 해서 웹사이트의 어느정도 랜딩페이지를 구상하였다.

하지만 여기서 문제가 있었다.

개발팀은 두명이었고 랜딩페이지는 3개가 제작이 되어야했고 한 페이지안에서의 퍼널을 만든 우리 팀과 다르게 나머지 두분은 밸런스게임 / 시물레이션 게임 등 다양한 재밌는 형태로 만드신거였다 !

나는 이탈자를 방지하는것이 중요하니까 무조건 심플하게 만들어서 내부적인 페이지에 안 넘어가고 바로 신청서 버튼 누르게 해야지 하고만 간단하게 생각했었는데 다른 팀이 제작한 방식들을 웹사이트로 구현하고 나서 보니까 생각보다 재밌었다.

밸런스 게임 과 시물레이션 등으로 고객이 가지고 있었지만 깨닫지 못하고 있던 자신의 문제 또는 문제로 크게 느껴지지 않던 부분들을 문제 정의 하여 버튼을 누르게 만드는 방식이었다.

이렇게도 퍼널을 구상하고 ctr button을 누르게 할 수 있구나하고 새롭게 얻는게 많은 내용들이었다.

우선적으로 초기 프로토타입을 구현하기 위해서 가장 우선순위를 둔 것은

1. 페이지 구조 (공통페이지 -> 각 페르소나별 맞는 서비스 페이지)

2. 페이지 마다 핵심 버튼 - 제작된 퍼널을 웹사이트로 반영

3. 최소한 사용자 여정을 고려하여 이동하며 필요한 페이지 구성

딱 이정도로 반영을 하고 초기 프로토타입을 구성하였다. 요즘 AI가 대부분 너무 잘해줘서.. 구조적인 부분은 원래 쓰던 구조를 설명을 하고 프론트 부분도 대부분 빠르게 코딩이 가능하였다.

쓰다보니 생각보다 간단한 말들 밖에 없는거 같지만 ㅎㅎ 나중에 단계별 최소한으로 정리해보고 싶었다.

이제 MVP가 나와서 언른 마케팅도 해보고 직접 잠재고객들의 경험을 이해하여 수익화 해보고 싶다는 생각으로 가득한 요즘이다

[현장실습 #4] 신사업 프로젝트 전환 퍼널 및 스토리보드 기획/설계

suru — Mon, 19 Oct 2026 10:54:22 +0900

서비스 경험 디자인 책을 읽은 사람이라면 4D ( discover, define, develop, deliver )에 대해 어느정도 알 것이라고 생각한다.

1,2주차때는 발견(discover) 단계에서 고객을 조사하고, 고객의 문제를 도출해내고, 가설을 세우고, 클러스터링으로 패턴을 발견하고 시드 아이디어들을 도출했다.

그리고 3,4주차때는 extreme costumer / early adapter 즉 돈이 있다면 바로 구매할 것 같은, 그리고 조사한 대상자들의 데이터를 모은 주 고객 대상 페르소나를 제작하고 해당 우리 사업/서비스에 맞는 주 콘셉을 정하는 콘셉 브리프를 만들었다.

이제는 해당 서비스를 직접 개발하는 개발(develop) 단계에 왔다.

우리 팀은 개발 단계에서 웹사이트 제작을 할려고 한다.

무작정 웹사이트를 제작하는 것은 아니다. 프로토타입을 만들기 전 우선 매주 하는 정기회의가 진행되었다.

정기회의에서는 참여하고 있는 9명이 3팀으로 나뉘어 각 페르소나 당 스토리보드를 구상하고 화면 전환의 핵심인 퍼널을 제작하기로 하였다 (대상 2개에서 다시 3개로 바뀌었다)

스토리보드 및 퍼널

스토리보드(Storyboard), 영화, 광고, 애니메이션, 웹툰, 앱·웹사이트 등 영상이나 디지털 서비스를 제작하기 전에 전체 흐름을 그림이나 화면 구성으로 미리 시각화하여 설계하는 문서
입니다

어떻게 고객에게 우리 물건을 사게할건지 그 흐름을 구상하는 것이다.

퍼널을 만드는 것이라고 했다.

구상한 스토리에서 사용자가 서비스에 처음 유입된 후 최종 제출 버튼을 누르게 까지 하는 깔 때기 형태의 흐름을 시각화하고 분석하는 프레임 워크다.

우리에 큰 흐름은 이랬다.

문제를 보여주고 공감 하기 -> 우리에게 해결책이 있어요 -> 걱정되는 부분 언급 후 안심 시키기 -> 제출

여기서 가장 중요한 것이 '사무치게 하는 내용' 이 들어가있어야 한다는 것이었는데, 고객이 제출 버튼을 누르게 할만한 그렇게 사무치게 악 진단해봐야지 하게 들게 하는 그런 문제가 제대로 정의되어 있어야 했다.

근데 같이 소통하시는 팀원분과 이야기 포인트가 톡에 자꾸 조금씩 어긋났다. 그리고 다른 분들께 피드백을 받아도 받아도 이해가 안되는 부분들이 생기기 시작하면서 이야기가 자꾸 중구난방으로 흘러갔다.

분명 문제를 정의 하고 멘트를 고민하기 시작했는데 다시 문제 정의를 하고 있다던가, 흐름이 완성될때쯤 다시 원시점으로 빙글 빙글 돌아가는 흐름이 계속 해서 반복되는걸 보고 결심했다. 안되겠다 제대로 정의하고 가자.

퍼널, 너가 뭔데 ?

퍼널

서비스 디자인 퍼널(Funnel)은 사용자가 서비스에 처음 유입된 후 최종 목표(구매, 회원가입, 결제 등)에 이르기까지 거치는 단계를 깔때기 형태의 흐름으로 시각화하고 분석하는 프레임워크입니다.

https://www.ascentkorea.com/marketing_funnel_from_concept_to_example/

그래 알겠어 우선 주목을 하게 만들고, 흥미있게 해서 욕구를 건드리고 결국 구매를 하게 만드는거겠지.

근데 그거 어떻게 하는 건데 ?

하고 보니까 3가지정도의 프렘이워크 있었다: AIDA, TOFU-MOFU-BOFU, AARRR

내가 이해한바로 이렇다

AIDA : 한 페이지 안에서 사람을 움직이는 방식
TOFU-MOFU-BOFU : 고객을 어떤 콘텐츠로 데려올지
AARRR : 서비스가 실제로 성장하는지 보는 방식

현재 우리팀에게 가장 맞는 프레임워크는 AIDA 라고 생각해서 우선 AIDA 방법으로 정리하자고 톡을 드렸다.

같은 팀원분께 aida 제안하기

우선 우리는 주목이 될 3초 안에 승부 문장은 이미 어느정도 나온 상태였기에 2번 인 고객의 문제를 다시 정의하는 것부터 시작했다.

개인적으로도 자꾸 원시점으로 돌아오는 일이 반복되어보니 고객의 문제를 정의해서 같은 문제를 바라보는 것이 가장 필요한 첫 걸음이라는 생각이 들었다.

근데 정말고 AIDA 기법을 쓰니 아침부터 소통한 모든 내용들이 정리되면서 멘트 수정 및 피드백하기도 훨 수월해져 5시반 쯤 모든 구상을 완료 했다.

이미 페르소나를 제작하고 콘셉브리프를 작성하면서 사실 고객의 문제에 대해서 쓰는 것은 그렇게 어렵지 않았다. 그리고 문제를 정의하고 난 뒤에 우리가 그토록 알고자 했던 '사무치는 마음 / 강한 욕구'를 바로 찾을 수 있었다.

덕분에 7시 퇴근전까지 빠르게 해당 시안을 정리하여 제출할 수 있었다 ! (다행)

개인적으로 느낀점

팀 프로젝트를 하면서 개인적으로 느낀 것이 있다. 한 팀으로서 특정 목표를 위해 달려갈때 가장 중요한 점은 모든 팀원들이 같은 페이지를 바라보는 것인 것 같다. 사용하는 용어가 같아야 회의 시간이 줄어들고, 헛돌지 않는다. 그리고 내가 어떤 것을 알고 모르는지를 알아 질문을 할 수 있게 된다. 회의에서 사용하는 용어, 진행되고 있는 단계 그리고 조사한 결과 등 모든게 중요하다.

팀원들이 서로 같은 페이지를 바라봐야, 같은 페이스로 달리기가 조금 수월하고, 프로젝트가 앞으로 나아갈 수 있다.

[CS 공부 #00] 회사 컴퓨터에 리눅스를 설치했다

suru — Fri, 16 Oct 2026 11:08:06 +0900

현장실습을 하다 보면 막히는 지점이 분명 생긴다.

나도 그런적이 많은데

회사에서 사용하는 웹사이트가 쇼핑몰 형식에서 회사 내부 개발 형식으로 바뀌면서 많은 것들이 필요해졌다.

원래 구)사이트에서 사용하던 사이트는 독립형 쇼핑몰 사이트형으로 백엔등 등 모두 업체가 관리해주는 사이트 였다보니 굳이 백엔드나 어드민 페이지가 따로 없었는데 이전을 하면서 사이트를 직접 관리를 해야하니 백엔드/ 관리자 페이지등이 필요해진 것이었다.

어쩌다보니 딱 사이트 이전시점과 내가 들어온 시점이 겹치면서 백엔드 구축과 관리자 사이트를 구현하게 되었다.

개발을 하고 배포를 하면서 다양한 문제를 경험하게 되었는데 오늘은 그거에 관련된 이야기와 느낀점을 나누려고 한다.

도커 포트 범위 실수로 인한 포트 충돌

배포는 대부분 Develop으로 머지해서 자동배포를 하기 때문에, 사수분께서 진행하시는데 배포중에 포트 충돌에러가 난거다.

포트는 1번부터 65535번까지 있고, 우리가 쓰는 건 몇 개 안 되는데 부족하다는 게 말이 안 됐다.

AI가 이상하게 도커 포트 범위를 잘라버린 것이다.

도커는 컨테이너들끼리 통신하라고 자체 네트워크를 만든다. 이때 그 네트워크가 쓸 주소 범위를 정하는데, 그게 172.17.0.0/16 같은 형태로 적혀 있다. 여기서 /16이나 /24가 바로 학교 네트워크 수업에서 배운 또는 정처기에도 나오는 서브넷 마스크다.

도커는 컨테이너들끼리 통신하라고 자체 네트워크를 만든다. 이때 그 네트워크가 쓸 주소 범위를 정하는데, 그게 172.17.0.0/16 같은 형태로 적혀 있다. 여기서 /16이나 /24가 바로 학교 네트워크 수업에서 배운 그거였다.

IP는 32비트이고 슬래시 뒤 숫자는 앞에서 몇 비트를 고정할지를 뜻한다. /24면 앞 24비트가 고정이고 뒤 8비트가 남는다. 2의 8승이니까 256개. 거기서 네트워크 주소와 브로드캐스트 주소를 빼면 실제로 쓸 수 있는 건 254개다.

/16이면 뒤에 16비트가 남으니까 65,536개가 된다.

그런데 숫자를 잘못 써서 /28 같은 걸로 잡으면 뒤에 4비트만 남는다. 컨테이너 몇 개만 띄워도 바로 바닥난다.

수업에서 계산 문제로 풀 때는 그냥 외워야 하는 공식 같았는데, 배포가 안 되는 걸 앞에 두고 보니까 전혀 다르게 보였다.

해결 방법은 그렇게 어렵진 않았다. 도커 네트워크 설정에서 그 범위를 다시 넓히는 것이었다.

docker network ls

로 어떤 네트워크가 있는지 보고,

docker network inspect

로 각 네트워크가 실제로 어떤 범위를 쓰고 있는지 확인하는 것이었다

그 다음엔 해당 네트워크를 지우고 제대로 된 범위로 다시 만들었다.

처음부터 이런 포트 관리를 철저하는 것이 중요하다는 것을 느꼈다.

서로 다른 프로젝트의 포트 충돌

그리고 이런 일도 있었다.

백엔드와 관리자페이지를 작업하고 PR은 보낸 상태였다.

'수루님 에러가 나네요 일단 에러 내용 보내놓을게요. 내일 배포합시다'

그리고 아침에 와서 보니 이런 에러가 나고 있었다.

Bind for 0.0.0.0:22410 failed: port is already allocated

포트 충돌 에러가 났다.

분명 빌드도 성공했고, 이미지 전송도 되었고, 이미지 로드까지 성공했는데 컨테이너를 띄우는데 마지막 단계에서만 실패한게 이상했다.

심지어 새로운 포트를 할당해준 것도 아니고 각 프로젝트마다 이미 있는 포트를 확인해서 구버전 삭제후 재실행만 하면 되는데 포트 충돌이 난 이유가 뭘까하며 원인을 따라가 보니 도커 문제가 아니었다.

관리자, 프론트, 백엔드 프로젝트 3개가 설정 파일을 서버의 같은 경로로 전송하고 있었다. 각자 다른 파일인데 이름이 같아서 나중에 보낸 쪽이 먼저 보낸 쪽을 덮어쓰는 구조였던거다.

평소엔 배포를 하나씩 해서 티가 안났는데, 그날 백엔드와 어드민을 같이 수정하면서 두 배포가 연달아 돌다보니 백엔드가 자기 파일을 보내놓고 이미지를 올리는 동안 어드민이 그 파일을 덮어썼고, 백엔드는 어드민 설정을 읽고 컨테이너를 띄울려고 했었던거다.

도커 컴포즈는 프로젝트명과 서비스명으로 기존 컨테이너를 찾아서 교체한다. 그런데 서비스명이 바뀌어버리니 기존 걸 교체하지 않고 새로 하나 더 띄우려고 했고, 그래서 이미 쓰고 있던 포트와 부딪힌 것이었다.

그래서 프로젝트 폴더명은 backend인데 서비스는 frontend 서비스라는 엉뚱한 컨테이너가 포트를 계속 잡고 있었던 것이었다.

고아 프로세스 삭제로 잘못 생성된 컨테이너를 자동 정리하는 옵션을 추가 할까 했지만 혹시나 모를 자동삭제 사고를 방지하기 위해 그냥 각 프로젝트별 시간차를 놓고 배포하기로 했다 ㅎㅎ

실무에서 막히는 것은 당연하다. 그리고 코드분의 많은 부분은 AI가 어느정도 해결해주기도 한다.

위와 같이 짠 코드는 멀쩡한데 코드가 올라가 있는 바닥에서 문제가 날때가 있다. 코드에서 에러 메시지만 보고 거기만 파고 있었는데 문제는 더 깊숙한 곳에 있을때다. 한 단계 아래에 뭐가 있는지를 모르니 자꾸 위에서만 멤돌게 될때가 있다.

그래서 CS 공부를 해야겠다고 생각했다. 운영체제, 네트워크, 자료구조, 알고리즘, 데이터베이스 전부 개발자로서 필수 역량이다.

어디서부터 시작할까 하다 막힌 지점에서 거꾸로 올라가니 실제로 필요한 부분은 운영체제와 네트워크로 느꼈다.

그리고 그 운영체제는 리눅스였다.

회사 컴퓨터에 리눅스를 설치하다

서버가 리눅스고, 도커 컨테이너 안도 리눅스다.

내가 만든 코드가 돌아가는 곳이 전부 리눅스인데, 나한테 리눅수는 막힐 때만 SSH로 들어가서 검색한 명령어를 붙여넣고 나오는 곳 뿐이었던거 같다.

리눅스를 알자. 운영체제를 이해하자. 하며 우선 리눅스 설치를 하기로 했다.

마침 개발팀내 리눅스 마스터 ( 꽤 유명한 리눅스 블로그 운영중 이신 분) 분이 계신데, 지나가는 말로 리눅스 설치해서 깔아봐요. 운영체제 과목이 중요하답니다. 하신 말이 생각이 났다.

매주하는 정기 회의날, 저번주에 이런 업무들을 했었고, 업무를 하면서 이런 필요성이 느껴졌다 그래서 이번주에는 회사 컴퓨터에 페도라를 설치를 하고 싶은데 해도 되냐하며 허락을 구하니 흔쾌히 허락해주셨다.

평소 작업을 리눅스 환경으로 구축해나가면서 조금 더 컴퓨터랑 친한 개발자가 되고 싶다.

[현장실습 #3] 신사업 프로젝트 - 콘셉 브리프 도출하기

suru — Mon, 12 Oct 2026 14:06:48 +0900

퍼소나 작업이 끝나고 다음은 매핑과 콘셉 브리프였다.

콘셉 브리프는 정의 단계의 최종 결과물이다. 책에서는 통찰에서 한 단계 더 나아가 다양한 기회 영역을 포착하고, 그중에 집중하고자 하는 기회나 해결하고자 하는 문제를 선별하는 것이라고 설명한다. 그 아이디어를 모아 하나의 콘셉트로 만들고, 이를 개략적으로 설명한 것이 콘셉 브리프다.

순서로 보면 발상 단계에서 HMW를 던져 아이디어를 구체화하고, 추려진 기회 영역 중 가장 중요하고 실현 가능한 데서 아이디어를 모아 하나의 콘셉트를 만드는 흐름이다.

회의에서 받은 기준은 명확했다.

"콘셉 브리프는 왜 하고 싶은가다. 이 콘셉트를 들었을 때 사고 싶어야 한다. 그만큼 꽂히고 끌려야 한다. 그런 걸 보고 콘셉 브리프라고 한다."

예시도 하나 들어주셨는데, 듣고 나서야 알았다. 콘셉 브리프는 기능 설명이 아니었다.

고객이 가장 아파하는 지점을 정확히 건드리고, 그걸 어떻게 뒤집어줄지를 한 문장으로 말하는 것이었다.

이번에는 대상을 넷으로 나누고 팀원 4명이 각자 하나씩 맡기로 했다.

우리는 같은 서비스라도 판매 될 대상이 다르기 때문에 각자 다른 컨셉 브리핑으로 나뉘어졌다.

내가 맡았던 퍼소나와 다른 팀원이 맡은 퍼소나는 같은 서비스를 사더라도 사는 이유가 완전히 달랐다. 누구는 시간이 없어서 사고, 누구는 혼자서는 안 돼서 사고, 누구는 기존 방법이 막혀서 산다.

사는 이유가 다르면 꽂히는 문장도 다르다. 그래서 대상별로 콘셉 브리프가 따로 나와야 했다.

그런데 내가 맡은 건 퍼소나 때 맡았던 대상이 아니었다.

나와는 성별도 상황도 전혀 다른, 솔직히 말하면 공감이 하나도 안 되는 대상이었다.

처음 배정받고 좀 막막했다. 퍼소나 때는 인터뷰를 직접 7명 하면서 그 사람들 말투까지 머릿속에 남아 있었는데, 이번 대상은 내가 겪어본 적도 없고 주변에서 들어본 적도 거의 없는 입장이었다. 뭐가 힘든지, 뭐가 아쉬운지 상상이 안 됐다.

근데 생각해보니 퍼소나 때 제일 크게 틀렸던 이유가 내가 그럴듯하다고 혼자 판단한 것이었다. 완벽해 보이는 답을 먼저 정해놓고 근거를 모으러 갔다가 인터뷰에서 바로 깨졌다.공감이 안 되는 대상이면 애초에 혼자 판단할 수가 없다. 자료를 보는 수밖에 없다. 그렇게 생각하니 오히려 나은 조건일지도 모르겠다 싶었다.

다행히 이번엔 자료가 있었다. 퍼소나 때와 반대 상황이었다. 퍼소나 때 내가 맡은 대상은 기존 조사 30명에 한 명도 없어서 인터뷰부터 새로 해야 했는데, 이번 대상은 그 30명 안에 들어 있었다. 추가 조사 없이 기존 자료로 시작할 수 있었다.

그래서 퍼소나 때 썼던 방식을 그대로 가져왔다. 해당하는 응답자만 추려서 같은 질문에 뭐라고 답했는지 가로로 늘어놓았다. 혼자 읽을 때는 각자 사정으로 보이는데 나란히 놓으면 반복되는 게 보인다.

여기서 하나 조심한 게 있다. 공감이 안 된다고 해서 자료를 내 식으로 번역하지 않는 것이었다.

인터뷰 때 배운 것과 같은 문제였다. 사람들이 쓰는 애매한 단어를 내가 해석해버리면 그 순간 내 생각이 된다. 응답에 쓰인 표현을 그대로 두고, 그 표현이 몇 번 반복되는지를 봤다.

그 다음은 발상이었다. HMW는 "우리가 어떻게 하면 ~할 수 있을까"로 질문을 바꾸는 방식이다. 문제를 문제인 채로 두면 답이 안 나오는데, 질문으로 바꾸면 아이디어가 붙을 자리가 생긴다. 여기서 제일 어려웠던 건 가치와 요구를 구분하는 것이었다.

책에 나온 예시가 명확했다. "정비소에서 세차까지 한꺼번에 하고 싶다"는 요구지 가치가 아니다. 가치로 쓰려면 "정비와 세차를 한 곳에서 함으로써 고객에게 편리함을 준다"가 된다.

실행 계획도 마찬가지다. "예약 시스템과 발레 주차를 통해 빠르고 간편한 서비스를 제공한다"는 실행 계획이고, 가치로 쓰면 "효율적인 서비스를 제공함으로써 고객의 시간 관리를 돕는다"가 된다.

조사에서 나온 불편 사항을 그대로 옮기면 그건 요구 목록이지 콘셉트가 아니었다. 한 단계 위로 올려야 했다.

그리고 반대로 너무 올려버리면 아무 서비스에나 해당되는 말이 된다. 적당한 높이를 찾는 게 계속 어려웠다.

아이디어를 추리면서는 세 가지를 확인했다.

무결성. 콘셉트가 서비스의 특징을 조화롭게 설명하는가.
차별성. 기존 서비스와 무엇이 다르고 그걸 얼마나 부각시키는가.
집중성. 제공하려는 것이 사용자의 욕구에 집중되어 있는가.

차별성에서 많이 걸렸다.

기존에 있는 방법들로도 어느 정도 해결이 되는 부분이 있었는데, 그러면 "그래서 왜 우리 걸 사야 하는데"에 답이 안 됐다.

퍼소나 때 썼던 질문이 여기서도 똑같이 쓰였다. 기존 방법으로 해결되는데 그 방법을 쓸 수 없는 지점이 어디인가. 그 지점이 차별성이 될 수 있는 자리였다. 콘셉트를 쓰면서는 충실도도 신경 썼다.

책에서는 정의 단계에서 무리하게 자세히 쓰면 개발 단계에서 역효과가 난다고 한다. 검증 전에 프로토타입까지 만들어버리면 유용성이 떨어질 수 있으니 조금 모호하게 남기고 다음에 발전시키라는 것이다.

처음엔 자세할수록 좋은 줄 알았는데 아니었다. 아직 검증 안 된 걸 확정된 것처럼 써놓으면 나중에 바꾸기 어려워진다.

그래서 어떤 기능을 어떻게 만들겠다까지는 안 쓰고, 무엇을 해결해주는 서비스인가까지만 썼다.

이번에 배운 걸 정리하면 이렇다.

공감이 안 되는 게 꼭 불리한 건 아니었다. 오히려 자료를 볼 수밖에 없게 만들었다. 퍼소나 때는 내가 공감한다고 착각해서 틀렸다.

콘셉 브리프의 목표는 "사고 싶은가"였다. 퍼소나의 목표가 "누가 돈을 내는가"였다면 콘셉 브리프는 그 사람이 들었을 때 끌리느냐다. 기준이 있으면 쓰다가 길을 잃어도 돌아올 데가 있다.

요구를 그대로 옮기면 콘셉트가 안 된다. 불편 사항 목록과 가치는 다른 층위의 말이었다.

산출물을 만들 때 그 산출물의 목표가 뭔지부터 보는 습관이 이번에도 똑같이 쓰였다.

세 번째 과제든 네 번째 과제든 결국 같은 방식이었다.

[현장실습 #2] 신사업 프로젝트 정의 단계 페르소나 제작

suru — Tue, 6 Oct 2026 19:04:45 +0900

그 전 포스팅에서 이야기한 것처럼 현재 나는 현장실습을 하고 있는 회사에서 신사업 프로젝트를 참여중이다 ! 새로운 아이디어를 발견하고, 정의하고, 개발하고 배포까지 ! 그리고 사용자경험을 해서 매출이 가장 많은 팀이 1등하는 방식이다.

지난 글에서 회의 피드백 받고 마음가짐 다잡았다는 이야기를 썼는데 그 이후 2주 동안 무엇을 했는지 적어둔다.

세 번째 과제는 퍼소나 5명 만들기였다. 남자 3명, 여자 2명. 여자 2명 중 1명은 외국인이라고 팀리더가 지정해주셨다.

회의에서 받은 기준은 "누가 우리 서비스를 실제로 필요로 하고 돈을 낼 것인가" 였고, "아주 급해서 설명만 해도 100만원, 300만원 결제하게 만들 사람들"을 찾으라고 하셨다. Extreme Customer라고 한다. 평균적인 고객이 아니라 문제가 가장 강하고 지금 당장 사는 사람을 뜻한다. 내가 맡은 건 '한국 결혼 및 정착을 희망하는 외국인 여성' 이었다.

근데 문제가 있었다.

책에서 가장 인상 깊었던 문장이 '미리 생각해놓은 콘셉트에 맞춰 데이터를 추려 나가는 것은 자기 아이디어를 정당화하는 것밖에 되지 않는다' 였는데 우리 팀 Discover 자료가 딱 그럴 위험이 있었다. 설문 응답 30명이 전원 한국인이었다.

외국인 응답자는 단 한 명도 없었다.

즉 내가 맡은 퍼소나는 근거가 0인 상태였다. '이런 사람이 있을 것 같다'는 추측 위에 세워져 있었던 것이다.

우선 팀리더께 제목이랑 같이 승인 요청드리면서 근거가 불충분한 경우 추가 인터뷰로 확보해도 되는지 여쭤봤고 승인 받고 바로 추가적인 인터뷰를 진행하기로 하였다.

인터뷰

첫 번째 과제 때 썼던 인터뷰 가이드가 61문항짜리로 있었다.

처음엔 거기에 외국인용 질문 몇 개만 추가하면 되겠다고 생각했는데 계산해보니 아니었다. 인터뷰 가능 시간이 30분인데 61문항이면 문항당 29초다. 그 속도로는 "네", "괜찮았어요" 같은 답만 돌아온다. 그건 인터뷰가 아니라 구두로 하는 설문이고 그런 데이터는 이미 30명분 있었다.

그래서 12문항으로 줄였다. 대신 한 사건을 끝까지 파고드는 방식으로 바꿨다. 책에도 일반론이 아니라 구체적 사례를, 되도록 최근 2주 이내의 경험을 물으라고 나와 있었다. 가장 공들인 건 축 분리 질문이었다.

"한국에 정착하고 싶으세요?" 라고 직접 물으면 답은 나온다.

근데 그 답으로는 왜 정착하려는지 알 수 없다. 한국이 좋아서인지 사람이 좋아서인지 본인도 정확히 모르기 때문이다. 그래서 하나씩 지워보는 방식을 썼다. 사람을 지웠을 때 남는 게 있는지, 나라를 지웠을 때 남는 게 있는지를 따로 묻는 식이다. 두 질문은 같은 것을 반대 방향에서 재는 한 쌍이다. 그리고 기존 조사 30명이랑 문장이 완전히 똑같은 강제선택 2문항은 반드시 유지했다. 비교 가능한 축이 하나는 있어야 했다.

질문지보다 더 막막했던 건 대상자를 어떻게 구하느냐였다.

인터뷰 대상자 구하기

일단 개인 인스타 스토리에 한국에서 결혼하고 장착을 희망하는가, 안하는가에 투표를 올렸다.

응답자 25명 중에 내가 장착을 희망하는 사람은 5명밖에 없었다.

시간이 없어서 전날 투표를 올리고 다음날 바로 30분 인터뷰 기준으로 가능한 사람의 수를 계산해서 인터뷰 제안을 드렸다. 그리고 거기서 가능한 분들로 추려서 그날그날 약속을 잡았다. 조건에 해당하는 쪽과 해당하지 않는 쪽 양쪽에서 가능한 사람을 다 모았다. 그런데 모으고 보니 한쪽이 비어 있었다.

장착을 희망하는 사람들은 대부분 한국에 온 지 오래된 분들이었다. 어릴 때 와서 자란 경우도 있었다. 그러면 내가 보려던 조건과는 상황이 달라진다. 대학 때쯤 한국에 와서 지금 정착을 고민하는 사람이 필요했는데, 그런 분이 주변에 없었다.

그래서 외국인이 많은 오픈채팅방을 찾아서 사례금을 걸고 모집했다. 한 분이 연락을 주셨고, 그분 일정에 맞춰서 밤에 인터뷰를 진행했다. 다행히 이분이 조건에 딱 맞는 분이었다. 그리고 결과적으로 이 인터뷰에서 퍼소나의 핵심이 되는 이야기가 나왔다. 7명 중에 가장 마지막에, 제일 어렵게 구한 분이었는데 거기서 나왔다.

표본을 채우려고 억지로 구한 게 아니라 비어 있는 칸을 찾아서 메운 것이었는데, 그게 제일 중요한 조각이 됐다.

그렇게 총 7명과 인터뷰를 잡았다. 한 사람당 30분씩, 거의 하루 종일 인터뷰를 하면서 근거를 모았다. 베트남, 네팔, 방글라데시, 아제르바이잔, 몽골, 대만, 러시아. 7개국이었다.

실제로 인터뷰를 해보니 질문지보다 훨씬 중요한 걸 알게 됐다.

사람들이 말할 때 애매한 단어를 엄청 많이 쓴다. "좋은 사람이면 좋겠다", "괜찮은 직장 구하면" 이런 식이다. 예전의 나였으면 그냥 넘어갔을 것 같다. 아 좋은 직장이면 연봉 높고 복지 좋은 거겠지, 아 좋은 사람이면 성격 좋은 사람이겠지 하고 혼자 해석해버렸을 것이다. 아니면 더 물어보면 실례가 될까봐, 말하기 싫어하는 건가 싶어서 안 물어봤을 것 같다.

근데 이게 제일 중요한 지점이었다.

"혹시 괜찮다는 게 어떤 의미예요?"
"좋은 게 어떤 건지 조금만 더 말씀해주실 수 있을까요?"

이렇게 아예 모르는 상태에서 물어보니까 전혀 다른 답이 나왔다. 내가 혼자 해석했으면 절대 안 나왔을 답들이었다. 어떤 경우엔 내가 짐작한 이유와 실제 이유가 완전히 반대이기도 했다. 안 물어봤으면 정반대로 기록할 뻔했다.

그러다 보니 깨달은 게 있다. 원래는 질문지에 있는 걸 다 물어봐야겠다고 생각했는데 그게 아니었다. 상대 답에서 유도를 해나가고 필요한 질문을 자연스럽게 끼워넣는 방식이 훨씬 나았다.

질문지는 길을 잃지 않으려고 들고 있는 거지, 순서대로 읽는 대본이 아니었다.

페르소나

산출물을 만들때 항상 해당 산출물의 주 목표는 무엇인지를 보는 편이다.

현재 가장 중요한 것은 “누가 우리 서비스를 실제로 필요로 하고 돈을 낼 것인가?”를 구체화하는 것이다.

단순히 나이·성별·직업을 정하는 것이 아니라, Extreme Customer를 중심으로 Persona를 만든다.

Extreme Customer란?

평균적인 고객보다, 문제가 강하고, 해결 필요성이 크며, 실제로 돈을 지불할 가능성이 높은 고객

“급해서 사는 사람”

따라서 Persona를 만들 때는 항상:

“이 사람은 왜 우리 서비스를 사는가?”

를 설명할 수 있어야 한다.

서비스가 엄청 매력적으로 느껴지지 않더라도 자신의 문제를 해결하기 위해 돈을 낼 이유가 있는 사람을 찾는 것이 핵심이다.

이게 회의에서 나온 내용이였다.

책에서는 퍼소나를 서비스를 쓸 것 같은 집단의 특성을 지닌 가상의 인물이라고 설명한다. 복잡한 데이터나 통계에 의존하는 대신 인간의 얼굴을 가진 한 개인으로 보게 해서 시장을 더 가깝게 느끼게 하는 도구다.

결국 흩어져 있는 인터뷰 내용들을 한 사람으로 묶어서 한눈에 보는 것이었다.

나는 이 내용들을 계속 되세기며 페르소나를 제작하였다.

*Early adapter: 설명만하면 돈을 지불하는 사람

우리 서비스를 이용할 외국인들중 어떤 것들이 그들을 extreme costumer로 만들 수 있을까? 원래 인터뷰 근거안에서 페르소나를 제작하면서 가야하는데 얼리어답터를 찾다보니 처음에는 자꾸 정해놓고 근거를 모을려고 했던거 같다..

'한국남자에 대한 환상을 가진 중산층' 이라는게 내가 보기에는 너무나 완벽한 extreme costumer이였다. 그래서 페르소나를 이걸로 해야겠다 라고 생각했었다. 근데 인터뷰를 막상 진행해보니 본국에서 중산층일수록 굳이 한국남자와 결혼하고 여기서 힘들게 살 생각이 없기 때문에 바로 돌아가면 된다는 생각을 가진 분들이 많았다. 내 가설은 틀렸던거 였다.

그래서 먼저 근거를 모으고 페르소나를 제작하기로 결심했다.

7명 인터뷰를 질문별로 다시 정리했다. 같은 질문에 7명이 뭐라고 답했는지 가로로 늘어놓으니까 혼자 읽을 때는 안 보이던 게 보였다. 한 명씩 읽을 때는 그냥 각자 사정으로 보였는데 나란히 놓으니 패턴이 생겼다.

여기서 첫 번째 문제가 나왔다.

내가 하나로 묶어놓고 시작한 두 가지가 실제로는 따로 움직이고 있었다. 나는 A이면 당연히 B일 거라고 전제하고 퍼소나를 짰는데, 인터뷰를 늘어놓고 보니 둘은 별개의 축이었다. 심지어 한쪽이 가장 강한 사람이 다른 쪽은 가장 약하기도 했다.

전제가 깨지니까 퍼소나의 기본 구조부터 다시 짜야 했다.

두 번째 문제가 더 컸다. 7명 중에 돈을 낼 사람이 아무도 없었다.

돈 이야기를 물어본 사람들은 전부 부정적이었다. 퍼소나의 목표가 "누가 돈을 내는가"인데 그 답이 0명으로 나온 것이다.

여기서 한참 막혔다. 근거 안에서 만들어야 하는데 근거가 "아무도 안 산다"고 말하고 있으면 어떻게 해야 하나 싶었다.

그러다 부정적으로 답한 사람들의 공통점을 봤다. 상황이 비슷했고, 무엇보다 전부 급하지 않았다.

그래서 거꾸로 생각했다. 급하지 않으면 안 산다는 게 확인된 거면, 그 반대 조건을 가진 사람이 사는 사람이다. 부정 응답이 쓸모없는 데이터가 아니라 조건을 알려주는 데이터였던 것이다.

그리고 시장 데이터를 찾아봤는데 여기서 구조적인 문제를 하나 발견했다.

내가 맡은 대상은 기존 시장에서 애초에 돈을 내는 쪽이 아니었다. 돈은 반대편에서 냈다. 내가 아무리 퍼소나를 잘 만들어도 "왜 돈을 내는가"가 안 채워졌던 이유가 여기 있었다.

그러면 질문이 바뀐다. 돈을 안 내도 되는 자리에 있는 사람이 그럼에도 돈을 내게 되는 상황은 뭘까.

답은 기존 채널을 쓸 수 없을 때였다. 기존 방법으로 해결되는데 그 방법을 쓸 수 없는 사람이라면, 돈을 내고서라도 다른 경로를 찾을 이유가 생긴다.

그 조건에 맞는 사람이 마지막 인터뷰에서 나왔다. 7명 중 유일하게 전제에 맞는 답을 한 사람이었고, 기존 채널을 왜 못 쓰는지, 뭐가 해결되면 생각해보겠는지까지 직접 말해줬다.

오픈채팅방에서 제일 어렵게 구한 그분이었다. 표본을 채우려고 구한 게 아니라 비어 있는 칸을 메우려고 구한 건데 거기서 핵심이 나왔다. 필요한 조각이 다 모인 셈이었다. 왜 급한지, 왜 기존 채널을 못 쓰는지, 뭐가 해결되면 사는지. 이걸 모아서 퍼소나를 썼는데 이번에는 순서를 바꿨다.

'어떤 사람인가'가 아니라 '왜 돈을 내는가'부터 적고 거기서 거꾸로 올라갔다. 돈 내는 이유가 먼저 서니까 나이나 신분 같은 건 그 이유를 성립시키는 조건으로 자동으로 정해졌다. 앞에서 세 번 막혔던 게 순서를 바꾸니까 한 번에 풀렸다.

마지막으로 두 가지를 지켰다.

하나는 항목마다 근거 수준을 붙이는 것이었다. 근거 있음, 부분 근거, 가설, 추가 조사 필요. 인터뷰 진술이 있는 건 근거 있음으로 쓰고 아무에게도 못 물어본 항목은 그냥 비워뒀다. 빈칸을 채우고 싶은 유혹이 계속 있었는데 채우는 순간 추측이 된다. 승인받기엔 다 확실한 것처럼 쓰는 게 나았을 수도 있지만, 나중에 실제 고객 만났을 때 틀리는 것보다 지금 비어 있다고 쓰는 게 낫다고 생각했다.

다른 하나는 반대 사례를 같이 적는 것이었다. 지우면 퍼소나가 깔끔해지는데 그러면 경계가 사라져서 '어떤 외국인 여성이든 다 해당되는 사람'이 되어버린다. 반대 사례가 있어야 "이 조건이 없으면 이 퍼소나가 아니다"라는 선이 생긴다.

그렇게 페르소나를 만들고 팀리더께 피드백 요청을 드렸다.

프로젝트 팀리더(대표님) 피드백

타팀 방 팀리더 내 페르소나 언급

다른팀 리더분께서도 내 페르소나를 해당 팀 방에 공유해주셨다.. 넘 뿌듯..

그렇게 페르소나 제작을 마치고 이제 매핑 및 hmw !! 그리고 콘셉 브리핑으로 컨셉을 도출해야한다..

[현장실습 #1] 회사의 신사업 프로젝트에 참여하다

suru — Wed, 30 Sep 2026 19:01:56 +0900

나는 현재 소프트웨어학부 4학년 2학기에 재학중인 상태이다. 학점을 듣는 대신 현장실습으로 학점을 대체하고 있는데

이번에 현장실습으로 다니고 있는 회사에서 새로운 비지니스 모델 구축을 위해 4가지의 신사업 프로젝트를 진행중이다.

감사하게도 인턴(현장실습생->인턴으로 통일하겠다)인 나도 프로젝트에 참여할 기회가 생겼다.

4가지 프로젝트 중에 나는 결혼과 관련된 프로젝트에 들어가게 되었다.

각 팀마다 팀장이 존재하는데 내가 맡은 프로젝트의 팀장은 대표님이셨다 !! (두둥)

우선 프로젝트 운영방식은 매주 팀 과제를 하면서 우승 팀에게 회식비 15만원이 주어지고, 최종 결과물은 10월 동안의 매출로 11월에 워크샵에서 우승이 결정 되는 방식이다.

이긴 팀에게는 매출의 이익, 1500만원 등 다양한 보상이 있었다 (보상 관련 규약(?), 조건 및 내용이 너무 많아 대충 이정도로 이해했다)

우선 현재 시점에서는 이미 첫번째, 두번째 과제가 주어진 상태다

첫번째 과제는

KPI 고객 조사하기 20건
팀 가설 10개 제출
유력 인사이트와 가설 제출 및 발표.
팀 방출 조건 정하기

이였다.

인터뷰 목적이 올라오면서 빠르게 폼 링크가 하나 만들어졌고 그 기준으로 우리 팀은 25세이상, 싱글 대상으로 인터뷰를 진행하기로 결정이 났다.

나는 설문 폼을 링크로 보내서 작성해달라고 부탁하는게 영 내키지가 않아서 인터뷰 방식으로 해야겠다 하고 진행을 하였는데 주변에 25세 이상 싱글을 찾는게 쉽지가 않아서 2명정도를 찾고 인터뷰를 진행했다.

대부분의 팀/팀원분들은 폼 링크를 받고 아 폼으로 보내면 되겠다 생각하셔서 인터뷰를 진행안하시고 링크를 보내신거 같다..!

또한 위 과제가 나오면서 참고하면 좋은 책 2권 [서비스 경험 디자인, 나 스티브잡스를 만나다] 1,2권과 필기 노트 몇가지가 있었는데 나는 개발팀 노션 권한만 있어서 열람하지 못하였는데 알고보니 위 자료를 보고 '제대로 된 인터뷰' 를 진행하는게 목적이었다보니 인터뷰 진행 대신 설문조사 함 + 필기 열람 10명 이하 이슈로 우리는 목요일 발표에 앞서 우선 위 내용 기반으로 필기시험을 우선 치뤄하는 상황이 되었다 .. !!

근데 현재 3주차 시점에서 너무 맞는 말인게 책 개념이 없으면 신사업 프로젝트를 한다는 것은 불가능하다..

Discover, Define, 클러스터링, 개인 인터뷰, 딥다이브 등 용어를 모르고 방법론을 모르는데 어떤 방식으로 인터뷰를 할 것이며, 어떤 것을 조사할 것이며, 어떻게 할 것인지를 정할 수 가 없고 팀장이 와서 무엇을 설명을 하거나 과제 내용을 봐도 엉뚱한 방향으로 흘러갈 가능성이 높다.

그렇게 첫번째 과제는 어찌저찌 조사를 하였고 가설 및 발표는 팀 팀장이 하였다.

이때까지만 해도 책을 읽을 시간이 정말 없어서 (낮에는 업무, 밤에는 개인적인 작업) 클러스터링이 뭔지도 잘 몰랐어서 가설 세우는것도 이해가 되지 않았고 따라가는게 정말 힘들었다. (아직도 물론 겨우겨우 쫒아가고 있지만..)

두 번째주 과제는

Discover final 클러스터링.
클러스터링 구글 슬라이드를 제출해주세요.
슬라이드지만 포스트잇 방식으로 진행해주세요.
드라이브에 서면제출을 기준으로 합니다.
27일에 평가합니다.
기준 정보의 갯수와 품질. 진단지에 연결된 방향성

너무 설문 조사였던 우리 팀에게는 추가적인 조사로 관찰, 몰입하기, 함께하기 등 다른 과제들도 제출되었고 시드 아이디어를 대신 내달라고 하셨다.

클러스터링 또한 팀장님께서 진행해주셨다...

정말 이때까지만해도 용어만 거의 알고 내가 현재 무엇을 해야할지를 전혀 아니 2주차때는 책을 4장까지는 한번 쭉은 읽어보았어서 아주 조금은 알고 있었을지도 모른다..

그럼에도 불구하고 27일이 추석 후에 일요일이었던점 때문에 과제 내지 못하였고... (수요일까지인줄 알았음..)

모든 팀이 회의를 하고 진행을 할 시점 우리 팀의 카톡방은 조용했던 탓에..... 1명 빼고 과제를 내지 않았기에 .... 그 주 화요일날 회의가 진행이 되었고 회의 시간 때 강력한 피드백과 동기부여를 받았다.

회의 내용은 대체로 신사업은 쉬운 프로젝트가 아니다. 그만큼 보상이 따르지만 될지 안될지는 아직 아무도 모른다.

그렇기에 하이리턴 하이리스크이기도 한다. 자율 참여이기에 시간이 안되는 사람과 따라 오지 못하는 사람은 참여를 하지 않아도 된다. 대신 참여를 할거면 리더십있게 아니면 최소한 좋은 팔로워가 되어서 따라와야 한다.

그리고 앞으로의 과제 및 어떻게 프로젝트를 진행해나가야는지에 대한 내용을 이야기 해주셨다.

해당 회의 이후에 조금 더 프로젝트에 대해 이해하고 마음가짐을 준비해야 하는지에 대해 알 수 있는 계기가 된 회의였다.

업무와 신사업 프로젝트 병행

사실 너무 어려운 프로젝트다. 낮에는 개발팀에 들어오는 업무도 처리해야 하는데 틈틈히 책 공부도 해야하고 계속해서 정리하고 발견해야 한다. 1.5시간의 대중교통 후 집에 와서는 또 취업 준비를 해야하니 시간이 정말 없다. 그럼에도 언젠가는 꼭 창업을 해보고 싶다는 마음이 있기에 이 과정을 배울 수 있어서 솔직히 말하면 감사한 마음이 크다.

창업은 아이디어는 그저 시작에 불구하고, 아이디어 구체화 하는 작업이 이렇게 많고 이론적으로 공부할 것이 많구나를 느끼고 있다. 또한 여태 학교를 다니면서 항상 중간고사, 기말고사를 쫒으며 살았는데 현장실습을 와서는 난이도가 굉장히 어려운 교양을 하고 있는 느낌이 들고 있다. 이 교양에도 꼭 A+을 맞을 것이다