커피챗 회고 (한국교육파트너스 권기원 대표님)

저번주에 한국교육파트너스 권기원 대표님과의 커피챗이 있었다. 권기원 대표님의 B2G 마케팅 경험과 개인적으로 생각하시는 사업화 과정 등에 대해 정리해보고자 한다. (+ 느낀점까지)

B2G 마케팅

권기원 대표님 경험

B2G 마케팅에서 가장 중요한 것은 을의 입장이 되지 않는 것이다. 일반적으로는 어쩔 수 없이 정부의 요구와 인식때문에 을이 되는 경우가 많은데, 권기원 대표님의 경우에는 '우리 프로그램을 도입하면 강의를 진행하겠다.'라는 일종의 거래를 하여 이 문제를 해결하였다.

통상적으로는 본인이 속한 도메인의 저서를 집필하여 저서를 집필하고, 저자로서 강의를 진행하는 방법이 있다. 네트워크가 있다면 네트워크를 이용해 강의를 진행하는 것도 좋은 방법이다.

권기원 대표님은 서비스 홍보를 하며 생긴 입소문으로 진로 교사분들에게 서비스를 홍보하기 위해 교사 연수를 가셨다고 한다.

개인적인 생각

은 B2G 사업을 계획중이 아니기 때문에 생략하도록 하겠다.

사업화 과정

권기원 대표님 견해

사업화를 할 때에는 트래픽이 있어도 수익 전환에 실패할 수도 있다. 따라서 트래픽, 데이터, 기술력은 수단에 불과하고, 결국은 탄탄한 재무제표, 고객의 결제가 중요하다.

따라서 예전에 일반적이었던 '아이디어 -> 기획 -> 개발 -> 유저모으기 -> 돈 벌기' 흐름에서 탈피하여 'MVT -> 돈 벌기 -> 추가 기획 -> 추가 개발' 흐름으로 사업화 과정을 진행하는 것이 수익 창출에 있어서 효율적으로 작용할 수 있다.

또한 돈을 지불하는 고객들은 불만사항이 있으면 이야기 할 가능성이 높기 때문에 이러한 불만 사항이 기존 기능 개선 및 추가 기능 개발에 도움이 된다.

개인적인 생각

우선 트래픽이 있어도 수익 전환에 실패할 수도 있기 때문에 돈 부터 버는 것에 집중해야 된다는 견해에 완전히 동의하기는 힘들었다. 토스의 경우 사람들의 트래픽을 어떻게든 끌어모으고, 이 트래픽에 기인하여 투자를 유치하고, 수익을 창출할 수 있는 여러 관련 분야로 서비스를 고도화하여 성공적인 경영을 보여주고 있다. 따라서 트래픽을 안정적으로 유지하고 성장시킬 수 있는 주제이고, 수익성 있는 관련 분야로 확장해 나갈 수 있는 가능성만 있다면 트래픽을 먼저 모으는 것도 좋은 방법이라 생각된다.

다만 빠른 개발 능력이 있는 서비스 제작 팀의 경우, MVP 개발 및 검증에 큰 시간이 들지 않기 때문에 권기원 대표님이 얘기한 개발 흐름대로 가는 것이 수익성 있는 분야를 탐색하는 데에 많은 도움이 될 것 같다.

투자 받기

권기원 대표님 의견

투자의 시점을 크게 초기 투자와 후속(성장기) 투자로 나눌 때 중요한 것은 다음과 같다.

• 초기 투자: 대표의 역량 및 히스토리(90%에 해당) + 개발 팀의 역량

• 후속 투자: 재무제표 상 나타나는 실적

초기 투자의 경우 사업화 가능성, 수익성 및 개발 팀 역량보다는 대표의 경험을 매우 중요하게 생각한다.

개인적인 생각

초기 창업 팀 투자 설명회를 들어본 경험 상, 대표 역량 및 히스토리가 중요한 것 같다. 대표 히스토리에서 팀의 서비스 제작 및 인터뷰에 대한 열정을 들여다 볼 수 있기 때문이다. 하지만 개발 팀 구성 및 역할 명시가 일반적으로는 필수이고 MVP가 없는 경우 개발 팀의 기존 역량이 중요하게 생각되기 때문에, 대표 역량이 중요하다는 말을 개발 팀의 역량은 초기 투자에서 영향력이 사소하다는 말로 해석해서는 안된다고 생각한다.

창업가 키노트 스피치 회고

5월 13일, 창업 인큐베이팅 프로그램 러닝메이트에서 진행하는 오프라인 네트워킹에 다녀왔다. 두 분의 대표님이 오셔서 창업가 키노트 스피치를 진행해 주셨는데 이 내용에 대해 정리하고자 한다.

세션 1: '허밍버즈' 유시원 대표님

Slack 기반 사내 소통 Micro SaaS '아기고래'를 만드신 허밍버즈의 유시원 대표님이 첫 연사를 맡아주셨다.

유시원 대표님은 아기고래 이전에 크게 두 번의 실패 경험이 있었다고 한다.

첫 아이디어 때는 직접 발로 뛰며 예비 고객이었던 가게 사장님들을 만나 인터뷰를 하셨다. 아이디어 단계에서는 괜찮은 서비스라고 생각하셨지만 인터뷰 후 '우리 서비스를 위해 돈을 내지는 않겠다.' 라는 생각이 들어 그 아이템는 포기를 하셨다. 이 경험을 통해 유시원 대표님은 “돈을 벌기 위해서는 고객 인터뷰가 정말 중요하다”는 점을 깨달으셨다고 한다.

두 번째 아이디어는 교내 창업 경진대회에서 수상까지 한 아이템이었지만, 이 때는 막상 고객을 만나지 않으셨다. 콜드 메일, 링크드인 등을 통해 영업을 하셨는데 서비스가 해결하고자 하는 본질적인 문제를 해결하지 못한다는 느낌을 받으셔서 이 아이템도 접으셨다.

현재는 빠른 MVP 개발 및 검증을 통해 고객의 유무를 검증하고, MVP 이후 고객 반응에 팀만의 답안을 연결하여 현재까지 기능을 확장하셔서 '아기고래'를 서비스 하고 계신다고 한다.

유시원 대표님의 얘기에서 가장 핵심적인 부분은 '거절당할 용기'인 것 같다. 인터뷰 요청을 거절당하면 그냥 그 분의 이야기를 못 듣는 것이, 영업의 경우에도 서비스가 맘에 안들면 사주지 않을 뿐, 그 이상 잃는 무언가가 없다. 따라서 적극적인 인터뷰로 인사이트를 얻고, 자신있는 영업으로 판매를 해야겠다는 생각이 들었다.

또한 인터뷰, 영업 관련 메시지를 작성하셨던 사진을 보니 시간이 지날수록 명확하고 자신있는 글이 되어가는 것이 보였는데, 처음에는 미숙하더라도 꾸준한 인터뷰, 영업 시도를 하는 것 자체만으로 충분한 가치가 있는 것 같다.

세션2: '릴리스 AI' 오현수 대표님

두 번째 세션은 릴리스 AI를 만드신 오현수 대표님이 진행해주셨다.

창업을 할 때는 무엇을 만들 지와 유저 인터뷰에 집중하는 것이 어떻게 만들 지보다 중요하다는 말씀을 해주셨다.

그리고 스타트업이 망하는 이유가 무엇인지에 대해서도 말씀하셨는데, 시장의 의견을 반영하지 않고 대표 욕망만 좇다 망하는 경우도 많지만 오히려 유저 요구를 무지성으로 추종해 망하는 경우도 많다고 하셨다. 릴리스 AI에서도 유저의 요구에 따라 기능을 만들었지만 막상 기능을 만든 후에는 실사용이 없었던 적이 있었는데, 이런 문제를 피하기 위해서는 '유저의 요구가 문제에 대한 올바른 해답이 맞는가'를 잘 따져봐야 된다고 하셨다.

정리하자면 좋은 인풋(인터뷰, 서비스 통계, 시장 정보)과 좋은 추상화가 있어야 좋은 서비스를 만들 수 있다는 것이다.

'무엇을 만들 지와 유저 인터뷰에 집중하는 것이 어떻게 만들 지보다 중요하다'라는 내용은 나도 항상 아이디어를 낼 때마다 생각하는 부분이지만 막상 진행하다 보면 잊게 되는 부분이기도 해서 자주 리마인드를 해야겠다고 생각했다.

그리고 내 경우, 아이디어를 가지고 인터뷰를 진행한 후 '원래 만들고자 했던 서비스가 나쁘지 않은데?'로 결론을 낸 적이 많은 것 같아서, 인터뷰로 얻은 정보를 추상화하는 것을 좀 더 중요하게 생각해야 할 것 같다고 느꼈다.

Git Branch 전략

git에서 공동 작업을 할 때, 어떠한 브랜치에서 분기해서 작업 후 작업한 브랜치를 다른 브랜치로 merge하는 식으로 작업을 하게 된다.

이 때 branch를 관리하는 규칙이 git branch 전략이다.

가장 많이 사용되는 전략으로는 git flow, github flow 두 가지가 있다.

Git Flow

체계적이고 엄격한 브랜치 전략

브랜치 종류

• main: 배포에 사용하는 브랜치

• develop: 개발 내용 통합에 사용하는 브랜치 (master 브랜치에서 분기)

• feature/*: 특정 기능을 개발하는 브랜치 (develop에서 분기)

• release/*: 배포 준비를 위해 QA를 수행하는 브랜치 (develop 브랜치에서 분기)

• hotfix/*: 운영 중 발견된 버그를 수정하는 브랜치 (main 브랜치에서 분기)

장점

• 브랜치 역할이 명확

• 릴리즈 브랜치를 통해 안정적인 버전 관리 가능

단점

• 브랜치가 많아서 복잡

• 릴리즈 주기가 잦으면 관리 부담이 큼

적합한 사용 케이스

• 명확한 릴리즈 주기가 있는 경우

• QA와 운영을 분리하는 환경인 경우

Github Flow

단순한 브랜치 전략

브랜치 종류

• main: 배포에 사용하는 브랜

• feature branches: 특정 기능을 개발하는 브랜치 (main 브랜치에서 분기, PR을 통해 코드 리뷰 및 merge)

장점

• 단순하고 직관적

• CI/CD를 활용한 빠른 배포 가능

단점

• 버전 관리 어려움

• QA 및 스테이징 단계 관리 어려움

• 긴급 버그 수정 어려움

적합한 사용 케이스

• 빠른 릴리스가 필요한 스타트업

• 단일 운영 환경 소규모 팀

• 테스트 자동화와 CD가 잘 갖춰진 팀

Pyodide란?

이전 포스팅에서 Pyodide라는 것에 대해 언급했었다.

Pyodide란 어떤 건지, 어떤 구조로 동작하는 지에 대해 좀 더 조사해보았다.

Pyodide가 무엇인가

Pyodide는 WebAssembly와 Emscripten에 기반한 브라우저를 위한 파이썬 배포판이다.

그렇다면 WebAssembly와 Emscripten은?

웹어셈블리는 웹 브라우저에서 실행하는 프로그래밍 언어이다.

웹어셈블리로 작성된 소스 코드를 네이티브 바이너리로 컴파일하여 브라우저 상에서 실행시킬 수 있다.

여기서 문제가 하나 있는데, 웹어셈블리의 문법은 어셈블리와 유사하기 때문에 이를 직접 작성하기는 어렵다는 것이다.

다행히 웹어셈블리를 타겟으로 하는 컴파일을 지원하는 많은 프로그래밍 언어들이 있어서, 다른 언어를 웹어셈블리로 컴파일하고 웹어셈블리를 네이티브로 컴파일하는 방식으로 쉽게 활용할 수 있다.

Emscripten이 여기서 말하는 컴파일러 중 하나로, C/C++을 웹어셈블리로 컴파일하는 컴파일러이다.

그래서, 어떻게 파이썬을 실행하나요?

우선 운영체제에서 파이썬이 실행되는 과정을 살펴보자.

파이썬으로 코드를 작성하고 이를 인터프리터에 입력하면, 이를 인터프리터가 한 줄 씩 읽고 해석하고 실행한다.

이 인터프리터라는 것은 여러 언어로 작성될 수 있는데, 파이썬의 표준 인터프리터는 C언어로 작성되어있다.

그러면 웹어셈블리와 Enscripten을 여기서 어떻게 사용할 수 있을까?

Emscripten을 사용하면 C/C++을 웹 어셈블리로 컴파일할 수 있고, 웹어셈블리를 사용하면 코드를 웹 브라우저 상에서 실행시킬 수 있다.

즉, C/C++ 언어를 브라우저 상에서 실행시킬 수 있다는 것이다.

파이썬 인터프리터는 C언어로 작성되었으므로 인터프리터를 브라우저 상에서 동작하게 하여 파이썬 코드를 입력하면, 파이썬을 브라우저에서 실행할 수 있게 되는 것이다.

파이썬 패키지는?

파이썬의 경우 여러 패키지를 이용하여 코드를 작성하는 경우가 많다.

Pyodide를 사용할 때 만약 패키지를 이용하지 못한다면 제약사항이 많을 것이다.

다행히도 pyodide에서는 pandas, matplotlib 등 여러 패키지들이 내장되어있다.

아래 링크에서 지원되는 패키지 목록을 확인할 수 있다.

블록 코딩 플랫폼 구조

블록 코딩 플랫폼을 개발해야 해서 블록 코딩 플랫폼이 어떻게 동작하는 지 조사하고, 이에 대해 정리해보았다.

전체적인 과정은 다음과 같이 네 단계로 나눌 수 있다.

1. 블록 조합

2. 텍스트 코드로 변환

3. 코드 실행

4. 결과 표시

각 단계에 대해서 조금 더 자세히 알아보도록 하자.

블록 조합

블록 코딩은 블록을 드래그 앤 드롭으로 배치해 연결하고, 블록에 있는 속성을 변경해 코딩하는 방식이다.

우선 배치를 위해 블록을 다른 블록 근처에 가져다 놓으면 이를 인식하고 블록끼리 연결될 수 있게 해야 한다.

이 때 블록의 조합 중에는 올바르지 않은 조합이 있을 수 있으므로, 이런 경우는 서로 연결되지 않도록 처리하는 것이 필요하다.

속성의 경우 드롭다운 리스트 또는 직접 입력하는 칸의 형태로 사용자에게 제공한다.

만약 변수를 속성으로 사용하는 블록의 경우 해당 스코프에서 사용할 수 있는 올바른 변수 목록을 제공해야 한다.

다음 단계에서 텍스트 코드로 변환하기 위해, 이런 블록의 연결 관계나 속성을 잘 저장하는 것이 중요하다.

텍스트 코드로 변환

이 단계에서는 사용자가 블록 코딩한 내용을 텍스트 코드로 변경한다.

이전 단계에서 사용자가 블록 코딩한 블록의 연결 관계 및 속성은 트리 형태를 이루게 된다.

이를 시작 블록으로 부터 순회하며 각 블록마다 정해져 있는 변환 규칙을 적용하면 대응되는 텍스트 코드로 변환할 수 있다.

텍스트 코드는 실행을 위해 내부적으로만 변환해도 되지만 이를 사용자에게 제공하는 경우도 있다.

코드 실행

말 그대로 코드를 실행하는 단계이다.

일반적으로 백엔드로 코드를 전송해 실행하는 방식으로 처리한다.

서버 상에서 실행하는 만큼, 여러가지 보안 및 안정성 문제가 있을 수 있다.

그래서 보통 Docker 상에서 실행하는 방법을 많이 사용하는데, 다음과 같은 장점이 있다.

1. 컨테이너 상에서 실행하므로 서버 자체가 공격당하는 위험 감소

2. 자원 제한(CPU, 메모리, 시간 등)을 이용해 자원을 안정적으로 활용 가능

3. 여러 언어 및 버전을 사용할 경우 각각에 해당하는 Docker 이미지를 만들어 용이한 환경 설정이 가능

결과 표시

최종적으로 사용자에게 실행 결과를 제공해야 한다.

다음 두 가지 경우가 있을 수 있다.

첫 번째로 결과가 문자열 출력으로 제공되는 경우이다.

이런 경우는 코드 실행 결과를 텍스트 형태로 사용자에게 그대로 제공하면 된다.

두 번째는 시뮬레이션을 이용하는 경우이다.

화면 상의 캐릭터를 제어하는 형태 등으로 결과를 표시하는 경우가 이에 해당한다.

이 때는 코드 실행 단계에서 텍스트 코드 내용을 실행하는 것이 아니라 시뮬레이션에 대한 명령어로 바꾸게 된다.

그 후, 시뮬레이터에 해당 명령을 실행하여 결과를 표시한다.

마무리

위 단계들을 쉽게 하기 위한 도구들이 많이 존재한다.

예를 들어 Blockly라는 라이브러리를 이용할 경우 블록에 대한 정의만 하면 블록 조합 및 텍스트 코드로 변환 단계를 별도의 코딩 없이 할 수 있고, Pyodide라는 라이브러리를 이용할 경우 브라우저에서 python 코드를 바로 실행할 수 있다.

이런 도구들을 잘 활용하는 것이 블록 코딩 플랫폼을 빠르게 만드는 데 큰 도움이 될 것이라 생각한다.