[연말정산 프로젝트] 한해동안 작업한 웹디자인 포토폴리오 직접 사이트로 구현하기 🤩

에 관심있으신 디자이너, 기획자 분들 계실까요?

피그마에 포토폴리오와 프로토타이핑으로 만들어놓은 멋진 웹디자인을
직접 노코드툴로 구현하는 연말정산 프로젝트를 진행해볼까 합니다.

Awwwards에 올라오는 이런 사이트들...?!

노코드 툴인 웹플로우를 통해서 구현할 예정이고,

Figma-to-Webflow와 같은 드로잉 코딩 툴도 사용해보려고 합니다.

제가 직접 만들어드리는게 아니고, 직접 구현하시게 될거고

웹플로우 사용법부터 복잡하고 멋진 인터랙션을 구현하는 방법까지 가르쳐 드릴 예정입니다!

그리고 정말 개발이 필요한 부분은 코드 작성해서 제공해드릴 생각입니다.

일주일동안 압축적으로 오프라인 1회, 온라인 2회, 중간중간 멘토링하는 식으로 진행할 생각이고,

가격은 무료입니다! 관심있으신 분들 아래 폼에 신청해주세요!

시간상 선착순 딱 두분만 진행할 예정입니다:)

🗓️ 일정: 12/26(화) ~ 12/31(일)

📌 방식: 온라인 2회, 오프라인 1회 각 2시간 (시간은 조율)

✨ 결과물: 실제로 동작하는 디자인 포토폴리오 사이트

✍️ 신청: 구글폼 신청하러가기

✍️ 디스콰이엇 피드백

@디스콰이엇 @이요한

제가 모더레이터로 운영하는 클럽은 클럽 통계 가 보이지 않습니다!

모더레이터로 참여하고 있는 클럽의 화면

참여하고 있는 클럽의 화면

피그마가 tldraw보다 드로잉 코딩에 적합한 이유, 간단 분석

피그마 vs tldraw

tldraw는 피그마 출신의 개발자가 만들고 있는 쉬운 화이트보드 서비스인데요, 인공지능에 눈이 달린 것과 같이 그림을 이해할 수 있는 GPT4-Vision과 결합되면서 “그림만 그려도 웹서비스를 만들 수 있다”라는 드로잉 코딩의 가능성에 많은 관심을 끌었어요.

하지만 사용해본 결과, “수정이 내 마음대로 어렵다”라는 단점으로 인해 원하는 웹페이지를 뽑아내기 힘들었습니다.

그래서 비교를 해보자면,

피그마 to 웹플로우, 프레이머

• 피그마의 Auto Layout 기능으로 목표하는 레이아웃을 쉽게 만들 수 있다.

• 코드 없이 웹플로우와 프레이머에서 바로 배포가 가능하다.

tldraw + GPT4 vision

• 레이아웃을 자연어로 설명하여 원하는 레이아웃이 나오지 않는다.

• 코드를 직접 옮겨야 한다. 피그마 Dev 모드와 같다.

앞으로 Figma - Webflow - GPT4 로 이어지는 드로잉 코딩 개발스택을 구축해볼까 합니다!!

Figma, 최고의 드로잉 코딩 툴 | 피그마 to 웹플로우

Figma로 드로잉 코딩해보기

이번 포스팅에서는 tldraw가 아닌 Figma로 드로잉 코딩을 해보려고 합니다.

너무 당연하지만 피그마는 최고의 디자인 툴입니다. 피그마가 가진 자유로운 드로잉 툴과 실제 CSS에 버금가는 기능들이 있기 때문이죠.

그리고 많은 분들께서 피그마 디자인을 프로토타입이 아닌, “실제 구동하는 웹사이트로 만들 수 없을까?” 라는 상상을 해보셨을거라고 생각합니다. 저도 매번 서비스를 개발할 때마다 “이거 코드로 언제 다 변환하지?”라는 생각을 했습니다🥲

Dev 모드가 있긴 하지만,,,

Figma에서 Dev 모드를 제공하기 시작하면서 Figma 컴포넌트, 프레임 등을 바로 코드로 뽑아볼 수 있습니다. 하지만 이 또한 React나 Vue 등 기본 코드 베이스를 세팅하고 난 후, 코드를 구조에 맞게 붙여넣어야 하는 했기 때문에 개발자에 한정된 기능이었습니다.

근데 찐으로 코드 한줄 볼 일 없이,

피그마의 컴포넌트를 웹서비스로 만들 수 있는 방법이 있습니다.

피그마 to 노코드 웹빌더

최근 가장 잘나가는 노코드 웹빌더인 Webflow와 Framer에서 피그마 플러그인을 직접 제공하고 있습니다.

피그마 플러그인은 피그마 서비스 내에서 사용할 수 있는 앱인데요,

웹플로우와 프레이머의 플러그인은 피그마 내의 컴포넌트나 프레임을 그대로 자신들의 서비스에 붙여넣을 수 있도록 합니다.

[피그마 to 웹플로우 사용법]

1. 플러그인 실행시키기

2. 옮기고 싶은 프레임 선택하기

3. 플러그인에서 생성하기

4. 웹플로우에 가서 붙여넣기

이렇게 되면 피그마에서 자유롭게 디자인하고, 웹플로우와 프레이머에 간단하게 컨트롤C+V를 하면서 웹페이지를 뚝딱 만들어 낼 수 있게 됩니다!!

피그마에서 디자인을 하는 것도 드로잉의 일종이라고 봤을 때,

피그마가 tldraw에 비해 드로잉 코딩에 더 적합해보여요.

피그마 to 웹플로우, 프레이머 유의사항

이렇듯 피그마 to 웹플로우, 프레이머는 매우 유용하지만, 잘 사용하기 위해서는 몇가지 유의사항이 있습니다.

다음에 더 자세한 튜토리얼을 올려보고 여기서는 몇가지만 언급해보겠습니다.

1. 무조건 프레임을 사용하고, Auto Layout을 사용해야 한다.

   해당 기능은 CSS에서 컴포넌트의 레이아웃을 설정하는 Flexbox를 표현한 것입니다. 레이아웃을 표현하는 만국 공통어인 것이고, 이를 활용하면 웹플로우와 프레이머에서도 똑같은 레이아웃을 구현할 수 있습니다.

2. 프레임의 이름을 꼭 지어주어야 합니다.

   이는 웹플로우에서 프레임을 잘 구분하고 수정작업을 할 때 용이합니다.

그럼에도 아직 안되는 것!

이렇듯 피그마를 드로잉 코딩의 툴로 활용하고 피그마 to 웹플로우, 프레이머를 사용하면 코드 한줄 볼 필요없이 웹페이지를 만들 수 있습니다.

이는 노코드 웹빌더 서비스의 발전으로 프론트엔드 코드가 점점 추상화되고 GUI 형태로 진화하고 있기 때문에 가능한 것입니다. (인공지능의 발전과 GPT4 Vision의 등장과는 별개로 가능했던 것이죠)

• html 또는 jsx 코드 → 드래그앤드롭

• css 또는 tailwind 코드 → 마우스 클릭

• javascript → ??

그러나 이처럼 정적인 웹컴포넌트를 옮기는 것은 문제가 없지만, 동적인 UI state 변경, 복잡한 이벤트 또는 애니메이션은 옮길 수 없습니다.

복잡한 이벤트와 애니메이션은 웹플로우에서 간단한 javascript 코드를 사용하면 가능하지만 이 또한 난이도가 있어 쉽지 않습니다.

결국 앞으로 LLM과 Vision 인공지능 모델이 기여할 수 있는 부분이 javascript 코드와 동적인 로직에 있지 않을까 생각하고 있습니다. 동적인 구조를 말과 그림으로 설명하면 javascript를 직접 노코드 웹빌더에 추가해주는 그런 모습이요!

그래서 당분간 동적 영역을 커버하는 웹플로우 플로그인을 기획해보자 합니다.

• javascript → 그림 + GPT4 Vision

이 부분에 대해서 여러분의 생각도 궁금합니다ㅎㅎ 댓글로 남겨주세요:)

여러분이 느낀 tldraw, 드로잉 코딩의 문제를 댓글로 달아주세요✍️

(이번 23년도 Next.JS 개발자 컨퍼런스의 등록 웹카드)

안녕하세요, 드코클 모더레이터 @연주환 입니다!

드로잉 코딩 클럽은 tldraw를 활용한 드로잉 코딩을 주제로 시작되었는데요,

그래서 제가 직접 tldraw로 멋진 웹서비스를 만드는 과정을 보여드리고자 준비하던 중에,,,

너무 답답해서 중단하고 글을 쓰게 되었습니다!

🪄 기획: 드코클 3D 멤버십 카드 생성기

우선 만들고자 했던 기획은,

드로잉 코딩 클럽에 참여해주신 분들에게

고유한 드코클 3D 멤버십 카드를 만들어주는 웹페이지인데요,

아래와 같은 기능을 담고자 하였습니다.

• 인풋으로 이름, 키워드 받기

• 키워드와 관련있는 이미지 생성 (Dalle 활용)

• 3D로 인터랙션이 가능한 멤버십 웹카드 컴포넌트

• 이름, 이미지 등을 에어테이블에 저장

• url로 멤버십 카드 구분

나열해놓고 보니 하나같이 필수적으로 개발이 필요한 기능이었는데요,

어떤 개발 기능이 필요한지 같이 표시해보겠습니다.

• 인풋을 통해 이름, 키워드 입력 -> UI 상태 관리

• 키워드와 관련있는 이미지 생성 (Dalle 활용) -> API call

• 3D로 인터랙션이 가능한 멤버십 웹카드 컴포넌트 -> 3D 인터랙션

• 이름, 이미지 등을 에어테이블에 저장 -> API call, DB 저장

• url로 멤버십 카드 구분 -> UI 동적 렌더링

이처럼 UI 상태관리, API Call, 3D 인터랙션, UI 동적 렌더링 등을

tldraw와 드로잉 코딩만으로 구현하는 것이 가능할까요?

네, 가능합니다!

하지만 너무 불편합니다!!!

(삽질의 흔적들)

실제로 해보니 원하는 결과(UI, 로직)을 얻을 때까지 너무 많은 실행을 해야 합니다.

"이럴바엔 그냥 개발하지...?" 라는 생각을 속으로 많이 했습니다..ㅎㅎ

그럼 왜 이렇게 많은 시행착오를 겪어야 할까요?

왜냐하면 GPT4 Vision은 LLM의 특성상 확률적(stochastic)으로 결과를 생성하기 때문입니다.

그러다보니 실행마다 어떤 결과가 나올지 쉽게 예측할 수 없습니다.

흠, 그렇다면 처음에 생성한 html, css, js를 직접 수정하면 되는거 아닐까요?

그러면 되지만 이번 튜토리얼의 목적은 직접 코드를 건드리지 않고 만드는 것이었습니다.

결국 코드를 직접 수정하지 않고는 너무 오래 걸리더군요.

이러한 과정을 거쳐 드로잉 코딩만으로 드코클 3D 멤버십 카드를 만드는 것을 포기했습니다!!

🫥 현재 드로잉 코딩의 문제점

현재 tldraw를 활용한 드로잉 코딩의 문제점을 몇가지 정리해보았는데요,

1. 코드를 건드리지 않고 UI를 수정하는 것이 매우 어렵다.

2. 페이지 전체 구조를 구성하는 것이 어렵다.

그러면 각 문제를 해결하기 위해서 어떻게 해야 할까요?

1. 생성한 UI 결과물을 GUI를 통해 결정론적(Deterministic)으로 수정한다.

2. 웹플로우, 프레이머와 같은 노코드 웹빌더와 함께 사용한다.

그래서 이번 기회에 1번 문제를 해결하기 위한

간단한 플러그인 프로덕트를 만들어보려고 합니다!

기획중인 플러그인은 웹플로우에서 직접 tldraw 도식+설명을 통해 컴포넌트를 생성할 수 있고, 웹플로우의 GUI로 쉽게 수정할 수 있도록 해볼 생각입니다.

(저희 클럽의 @박경식 님이 만드시는 노코드 웹빌더 바운스 코드에는 이미 있는 기능입니다!!! 미쳤죠!!)

우선 웹플로우 플러그인으로 만들어볼까 하는데 여러분의 생각은 어떠신가요!?

또 tldraw로 드로잉 코딩을 하면서 느낀 문제는 무엇이 있었는지

여러분의 의견이 궁금합니다!!

댓글로 의견 많이 달아주세요🤩

(”드로잉 코딩 쓸모없다, 필요없다” 같은 비판도 너무 좋습니다!!!)

P.S. 아 그리고 드코클 3D 멤버십 카드를 만드는 웹서비스는 노코드 웹빌더인 웹플로우로 만들어보고 포스팅으로 연재해보겠습니다! 뭔가 저희 클럽만의 아이덴티티 굿즈가 있으면 재밌을거 같아서요🫡

웹플로우를 통한 튜토리얼은 엄밀하게 드로잉 코딩은 아니지만, 앞으로 드코클에서 노코드 툴도 많은 비중으로 다뤄줬으면 하는 바람에 시도해보겠습니다!

(노코드 툴에 관심있는 분들, 함께해요!!!)

물들어올 때 노젓는 tldraw 미친 업데이트 속도

트위터 원문

안녕하세요, 이번 포스팅에서는 노코드 툴이나 드로잉 코딩과 관련한 포스팅은 아니고, tldraw 화이트보드를 기반하여 다양한 서비스 사례가 재밌어서 한번 공유해보고자 합니다.

tldraw 팀에서 최근 프리A 투자 유치 이후 채용까지 시작하며 매우 빠르게 재밌는 시도들을 하고 있는데요, 12월 1주차에 있었던 다양한 업데이트 공유드립니다🙌

1/ text-to-tldraw, 자연어로 tldraw 그림판 조작하기

출저 트위터

text-to-tldraw는 GPT4에게 원하는 그림을 자연어로 요청하면 tldraw 캔버스에 자동으로 그려줍니다🪄

웃는 사람부터 집, 다이어그램, 와이어프레임까지 다양한 예시가 있네요.

원리는 Assistant API를 사용하는데요, 인풋으로 현재까지 그려진 shape(객체)의 정보(위치, 관계)를 전달하고, 아웃풋으로 tldraw를 조작하는 명령어를 주게 됩니다. 해당 명령어를 통해 tldraw를 조작하게 됩니다. 아직은 직접 사용해볼 수 없고 내부 테스트중인거 같네요!

🚀가능성 | 웹개발 자비스?!

text-to-canvas 가 더 고도화된다면 몇년안에 캔버스를 그리는 행위조차 없어질거 같네요! 더 나아가 말로 캔버스를 그리게 된다면, 웹사이트 제작까지 이어져서 그야말로 웹개발 자비스가 탄생하는 상상을 해봅니다.

2/ tldraw lens | 그림판으로 예술가되기

출처 트위터

tldraw 팀에서 재밌는 프로젝트를 테스트 오픈했습니다. tldraw의 도구를 사용해서 막그림을 그리면, 실시간으로 멋진 그림이 탄생하는데요,

fal_ai_data의 실시간 그림생성 API를 활용하여 붓질을 하는 순간 바로 새로운 그림을 만들어냅니다! 또한, 다른 사람들과 실시간 공동작업이 가능하다는 특징이 있습니다.

🚀가능성

아직은 원하는 그림을 그리기에는 어려움이 있는데요, 앞으로 예술이나 애니메이션, 아이들 미술 교육에 사용될 수 있을거 같아요!

3/ tldraw draw fast

출처 트위터

사실 얼마전에도 tldraw에서 비슷한 서비스인 tldraw draw fast를 런칭했는데요, 위의 lens와는 다르게 프롬프트를 입력할 수 있어서 더 쉽게 멋진 그림을 그려낼 수 있습니다! 개인적으로 Lens보다 더 재밌게 사용해봤어요.

정말 다양하고 상상력 넘치는 활용사례가 있는데요, 아이들 교육쪽에서 뭔가 재밌는게 나올 수 있지 않을까?라는 생각이 드네요!!

[활용사례]

https://x.com/tldraw/status/1729562588952789099?s=20 https://x.com/tldraw/status/1729499637579436174?s=20

마무리

다음 포스팅에서는 tldraw를 활용한 드로잉 코드 사례들을 가져와보겠습니다!!

(노코드 툴에 관심있는 분들, 함께해요!!!)

tldraw 드로잉 코딩 웨비나를 한번 열어보려 합니다!

안녕하세요!

이번에 교내 학회에서 tldraw 기초 사용법 및 활용과 관련한 웨비나를 진행하게 되었는데요, 드로잉 코딩 클럽에서도 함께 참여하면 좋을거 같아 공유드립니다.

카메라 끄고 편하게 접속하셔서 “아 tldraw가 이런거구나!” 하고 가볍게 알아가시면 좋을거 같습니다. (현재 10분 정도 신청했습니다!)

시간:

23년 12월 8일(금) 19:00 ~ 20:00

장소: 온라인(추후 링크 전송)

참여 신청 링크:

https://forms.gle/2nXzN1Eochyk96qJ9

참여 대상:

포트폴리오를 실제로 작동하는 프로토타입으로 만들고 싶은 디자이너/기획자

포트폴리오를 실제환경에서 배포하여 사용하고 싶은 디자이너/기획자

디자인 or 기획의도를 개발자와 커뮤니케이션하는데 어려움을 겪었던 디자이너/기획자

드로잉 코딩이란?

드로잉 코딩(Drawing Coding)은 단어 그대로
“그림을 그려서 코딩을 하는 신개념 노코드 방법론”입니다.

OpenAI에서 GPT4에 눈이 달린 GPT4 Vision 모델을 공식적으로 공개하고 난 후 등장한 개념입니다.

“A very good Whiteboard”를 지향하는 tldraw라는 화이트보드 서비스(오픈소스)에서 GPT4 Vision을 결합한 것이 드로잉 코딩의 신기원을 열였는데요,

현재 X의 해외 개발자 커뮤니티를 중심으로 와우한 사례들이 많이 등장하면서 매우 핫한 주제가 되었습니다.

실제로 사용법이 매우 간단합니다.

1. tldraw 화이트보드에 도형, 화살표 등으로 원하는 UI, UX, 비즈니스 로직을 그린다.

2. 화살표와 텍스트로 추가 설명을 작성한다.

3. 모든 요소를 드래그해서 인공지능에게 전달한다.

4. 조금 기다리면 바로 사용할 수 있는 웹 데모가 나온다.

X에서 다양한 와우 사례를 보면서 “와 이거는 앞으로 노코드 개발에 혁명이 되겠다!”라고 생각했고, 이번에 드로잉 코딩 클럽을 개설하게 되었습니다🤩

드로잉 코딩 클럽이 프로덕트 메이커, 기획자, 디자이너, 개발자들이 모여있는 디스콰이엇에서 드로잉 코딩과 관련한 각자의 노하우와 활용사례를 공유하는 장이 되었으면 좋겠습니다.

[드로잉 코딩으로 얻을 수 있는 것들]

메이커의 입장에서 드로잉 코딩을 사용하면 얻을 수 있는 것들을 몇가지 적어보자면,

1. 개발자가 없어도 자신이 상상하던 디자인, 기획을 실제 웹서비스로 구현할 수 있다.

2. 아임웹, 웹플로우 등 노코드 웹빌더와 연동하여 노코드 웹빌더에서는 안되던 복잡한 인터렉션 UX, API Call 등을 구현할 수 있다.

3. 프로토타이핑이 쉬워진다.

[드로잉 코딩 클럽에서 여러분과 하고 싶은 것들]

1. 드로잉 코딩 노하우 공유

2. 해외 사례 공유

3. 프로젝트 진행 및 연재

4. 콘테스트 / 세미나 등 오프라인 이벤트 진행

개인적으로 인공지능 시대는 직업 대통합의 시대가 올 것 같습니다! 그리고 드로잉 코딩이 그런 흐름의 시작이지 않을까 생각합니다.

변화의 흐름 속에서 두려워하지 않고 오히려 흐름을 타면서 다같이 성장했으면 좋겠습니다.

감사합니다!

[Roast My Product] #1 Ultimate GPT Calculator(UGC) - 하나씩 로스팅해봅시다!

UGC는 솔로프리니어 전환 후 첫번째 프로덕트인데요, OpenAI API 를 사용하시는 분들이 계산하기 복잡한 모델들을 빠르고 쉽게 계산할 수 있도록 했습니다.

제가 프로덕트를 만들면서 했던 고민은 "계산을 채워야할 것이 많은데 어떻게 하면 유저가 이해하기 쉬울까?" 였습니다.

UI/UX, 블로그 콘텐츠 등 다양한 부분에서 로스팅해주세요!! @Kyle @이요한

GPTsLink를 만들면서 보고 있는 기회 | GPTs 노코드 툴

🧐 먼저 간단하게 GPTsLink를 소개드릴게요.

팍스휴마나 팀은 "현재 GPTs의 검색/탐색이 어렵다"는 문제를 빠르게 해결해보고자 GPTs를 한번에 모아서 탐색/검색할 수 있는 GPTsLink를 만들었습니다.

OpenAI의 GPTs 공개 이후 일주일 뒤에 노션으로 MVP를 만들어 배포했고,

현재는 버전1을 배포 완료한 상태에요.

[버전1 업데이트된 기능]

1. GPTs 링크 입력 후 자동 업로드 기능

2. 좋아요, View에 따른 트렌딩 기능

3. 북마크 기능

국내외적으로 비슷한 유사 서비스가 굉장히 많이 생기고 있는데, 저희 팀은 OpenAI에서 GPTs를 공개한 이후 빠르게 도메인을 구매해서 저희와 똑같은 도메인명을 뒤늦게 산 서비스(.xyz)도 발견하기도 했어요!ㅋㅋㅋ

현재는 저희를 비롯한 유사서비스가 GPTs의 검색/탐색 문제를 어느정도 해결했다고 생각해요. 하지만 1만여개의 GPTs 데이터를 모아 놓고보니 "어떤 GPTs가 나에게 필요한 GPTs인지 모르는 문제"가 발생했어요. 너무 대안이 많아서 아예 시도도 못하고 나가는 경우가 생긴거죠!

그래서 현재는 인간지능으로 하나하나 큐레이팅하는 작업을 진행하고 있습니다. 서비스에서 큐레이팅도 하고 앞으로 메이커로그로도 남겨보려고 합니다.

🫥 큐레이팅을 하다보니,, GPTs 노코드 툴에 기회가 있다!

큐레이팅을 위해 GPTs를 많이 사용해보고, 다른 커뮤니티에서 만든 GPTs를 구경해봤는데요,

대부분의 분들이 GPTs를 한정적인 기능만 사용하여 만들고 계시다는 것을 발견했어요.

코딩으로 치면 매우 하이레벨의 추상화 레벨에서 뭔가를 만들고 있는 상황이었어요. 여기서 한정된 기능이라 하면 코딩을 전혀 사용하지 않고 빌트인으로 제공되는 OpenAI Retrieval (Knowledge)를 사용하는 경우를 말합니다. 하이레벨의 일률적인 Retriever를 사용하다보니 직접 만든 Retriever보다 성능이 떨어질 수 있고요.

Function call 에 해당하는 Action은 전혀 사용하지 않고 계셨죠. (개인적으로 Action 을 사용해서 정말 와우한 GPTs를 만들 수 있다고 생각합니다.)

대부분의 분들이 한정적인 기능만 사용하는 이유를 생각해보면 GPTs Builder를 통해 개발을 몰라도 만들 수 있기 때문일 것입니다.

커뮤니티를 통해 여러 반응을 확인해본 결과, 한정적인 기능만 사용하는 분들은 개발을 모르는 분들이 많았고, 스스로 만든 GPTs 에 만족을 못하면서 개발을 배워야하는지에 대한 고민을 하시더라고요.

그렇다면 GPTs는 그대로 노코드로 만들면서,

개발자들이 사용하는 기능들을 노코드로 쉽게 붙일 수 있는

GPTs 노코드 툴에 기회가 있지 않을까?

노션, 우피, 카페24, 아임웹, 채널톡, 에어테이블 등이 나왔던 것처럼요!

그래서 당분간 저희는 개발을 곁들여 와우한 GPTs를 만들어보면서 노코드 제작자 분들이 사용할 수 있는 노코드 툴을 만들어보려고 합니다!

GPTsLink와의 연계도 생각하고 있고요.

혹시 GPTs를 만들면서 불편했던 점이나 필요했던 기능들이 있으셨다면 댓글로 알려주세요 🤩

Vector 기반 RAG의 성능을 높이기 위한 LlamaIndex 의 제안

제가 더 주목하고 있는 관점을 소개해보자면,

RAG의 성능 향상은 embedding 모델의 차이에서 오는 것은 크지 않을 것이고, 방법론의 차이에서 더 유의미할 것으로 생각합니다.

[라마인덱스를 필두로 제시되고 있는 방법론]

1. embeddings를 만들어내는 chunk의 단위를 어떻게 나눌 것인가.

문서의 종류, 성격마다 성능이 좋은 chunk의 크기가 다른 것이죠. 페이지, 문단, 문장 등 다양한 방법이 있을 것입니다.

OpenAI의 Assistant API Retrieval 성능이 떨어지는 것도 이런 이유로 보입니다. 일률적으로 같은 chunk 기준을 적용하기 때문인거 같아요.

2. 다른 indexing 방식과의 혼합을 어떻게 할 것인가.

기존의 키워드 매칭 방식의 BM25 알고리즘, 지식그래프를 활용한 Retrieval 등을 앙상블하거나 Routing 하는 방법 등이 있습니다.

3. 어떤 메타데이터를 함께 embeddings로 만들 것인가.

단순히 원본 데이터만 embeddings로 만드는 것보다 성능이 더 좋게 나옵니다. 다양한 상황에 따라 다양한 메타데이터를 추가할 수 있겠죠.

4. Recursive 방식 -> chunk 단위를 다양하게 쪼개서 나중에 merge하는 방식.

이 방식은 말로 설명이 어려운데 라마인덱스 docs 읽어보면 좋을거 같아요. (https://docs.llamaindex.ai/en/stable/examples/query_engine/recursive_retriever_agents.html)

추가적으로 RAG 관련한 소식과 트렌드는 라마인덱스 CEO 제리리우 트위터가 제일 빠르다고 생각합니다! 라마인덱스 닥스도 무조건 1회독하면 좋아요!

https://twitter.com/jerryjliu0

[솔프 2주차]명품 계산기 만들어보겠습니다!

안녕하세요, 팍스 휴마나 팀의 연주환입니다. 오늘은 얼마 전에 공유드린 프로덕트 “궁극의 GPT 비용 계산기” 업데이트 로그를 가져와봤습니다!

얼마 전 저희 팀이 Solopreneur 전략으로 선회한 후에 처음으로 만들었던 프로덕트인데요, 인공지능 기술은 없지만 순전히 저희 팀의 니즈와 문제에 맞춰서 개발을 하게 된 것이 Ultimate GPT Calculator (UGC) 입니다!

이번 업데이트는 저희 팀이 GPT API를 활용하여 개발을 할 때 느끼는 니즈와 “이런 것 있었으면 좋겠다.”하는 기능들을 직접 고객의 입장이 되어 기획하고 추가해보았습니다. 그리고 기능을 추가할 때 @Kyle 님의 명품 프로덕트와 관련된 글이 많은 영감을 주었습니다.

진짜 이렇게까지 하는 계산기는 없다고 자부합니다.

구글에 GPT Token Calculator라고 검색해서 나오는 모든 계산기를 봤지만, 어떤 계산기도 이렇게까지 세심하게 기능을 넣지 않았습니다. 어떤 기능들이 있길래 자부하는지 아래에서 설명드리겠습니다!

1. OpenAI API별 계산

이번 OpenAI의 발표에서 새롭게 등장한 비전, TTS, Assistant API 뿐만 아니라, 기존의 파인튜닝, Whisper, Dalle 등의 모델을 따로 구분하여 필요한 API별로 계산을 쉽게 할 수 있도록 했습니다.

2. Vision 계산

GPT4-Turbo-Vision 모델은 GPT4에 이미지를 첨부할 수 있는 모델인데요, 공식문서를 확인해보면 이미지의 픽셀별로 가격을 계산하게 됩니다. 이 방식이 한번 이해하면 쉽지만, 여러번 읽으면서 이해했던거 같습니다.

그래서 실제로 이미지를 활용한 서비스의 비용을 계산할 때, 유저에게 어느 정도 해상도의 이미지를 받아야할지, 비용은 얼마나 나올지 계산하기 어려운데요, 저희 UGC에서는 직접 이미지를 넣고, 해상도를 지정하면서 가격을 확인할 수 있습니다!

3. Fine-Tuning 계산

파인튜닝은 트레이닝을 할 때와 사용할 때 가격이 다른데요, 트레이닝의 경우 특히 사용되는 토큰의 양이 많기 때문에 보다 신중하게 접근하게 되는거 같습니다. 저는 파인튜닝을 하기 전에 일일이 엑셀로 계산을 했었는데, 이제 토큰, 훈련할 Epoch, Job 등을 입력하면 바로 계산이 됩니다. 그리고 자신이 파인튜닝한 모델을 사용하는 계산까지 함께 가능합니다!

4. 앞으로 추가할 기능

• Audio와 관련된 TTS, Whisper 계산 기능

• Assistant API과 관련된 Retrieval, Code

  interpreter, Tool 등의 계산 기능

• Vision과 관련된 Video Input 계산 기능

• 예산 설정 및 마진율 계산

이걸로 돈 어떻게 벌지?

이번 OpenAI DevDay에서 샘알트만 형님이 발표한 내용에 따르면, 전세계에 OpenAI API를 사용하는 개발자가 무려 200만명이라고 합니다. 저를 비롯한 많은 개발자 분들께서 가볍게 비용 계산을 하기 위해 Token Calculator, GPT Cost Calculator라고 검색해서 사용해보셨을 겁니다.

전세계에서 압도적으로 좋은 비용 계산기를 만들면, 매월 전세계 LLM 개발자의 1%의 트래픽은 확보할 수 있지 않을까? 라는 가설을 세웠습니다. 그리고 그중 0.1%만 돈을 낼 수 있도록 한다면? 그렇기만 한다면 투입 대비 너무 좋은 리턴이 될거 같습니다.

최소노력/최대효용 트래픽을 늘리자.

저희 팀의 Solopreneur 전략은 “최소 노력으로 빠르게 만들기”입니다. 그동안 4개월동안 함께 합을 맞춰온 개발자 기반 조직이다 보니 (벌써 저희끼리 만든 프로덕트가 6개나 되네요..!!) 매주 3일동안 빠르게 개발 및 세팅을 하고, 남은 4일동안은 유입을 늘리기 위한 전략들을 수행합니다. 그리고 간간히 업데이트를 하거나 트래픽을 기다리는 방식이죠.

이번에도 개발보다 더 힘 쓴 부분이 블로그 SEO 입니다. 저의 고객여정을 분석해보면, 검색을 통한 유입이 굉장히 많았는데 검색 키워드의 경쟁도가 굉장히 낮아 블로그를 통해 오가닉하게 유입을 끌어올 수 있겠다고 생각했습니다.

앞으로 블로그 SEO를 통한 오가닉한 트래픽이 증가된다면 관련된 콘텐츠도 다뤄볼까 합니다!

마지막으로 OpenAI API를 사용하시는 메이커분들 편하게 써보시고 피드백 주시면 감사합니다!

너무 빠르게 변하고 쉽지 않은 시장이지만, 함께 인공지능 시장에서 플레이하는 모든 메이커분들 응원합니다🫡

저희 팀은 LLM + Knowledge Graph와 사랑에 빠졌습니다 D+100❤️

저희 팀은 그동안 LLM을 생성의 측면뿐만 아니라, 관계추론엔진으로 바라보고 Knowledge Graph에 주목하고 있었습니다. 특히 LLM + KG 의 조합과 정말 사랑에 빠졌습니다. 앞으로 이 두 조합으로 많은 것들을 시도하는 과정을 공유하려고 합니다!

Knowledge Graph(=지식그래프)가 뭘까요?

Knowledge Graph는 데이터 그 자체보다, 데이터 사이의 연결에 집중합니다. 예를 들어 마이클과 새라는 부부 사이다. 그러면 마이클 노드(데이터 하나)와 새라 노드(데이터 하나)는 [결혼함]이라는 엣지로 연결됩니다.

(엣지(관계)는 주로 동사형입니다.)

여기서 KG는 마치 인간 언어의 문장과 흡사한 구조를 표현하는 것을 알 수 있습니다. 기존 SQL 기반의 관계형 DB는 명사 기반이며, 테이블의 관계형을 통해 최대한 그 관계를 표현하려 했지만 테이블 스키마에 맞춰야 해서 불편했습니다.

LLM 이전의 KG는 유저가 데이터의 정형화를 해주어야 가능했습니다. (데이터의 정형화 예, 해시태그 연결, 페이스북에서 연인관계 설정, 유저의 앱내에서의 행동 등의 작업이다.) 유저가 정형화하지 않은 수 많은 비정형 데이터는 지식으로 연결되지 않고 남아있게 되었죠. (또한, 라벨링 알바를 시켜 정형화 작업을 하기도 합니다.)

사람이 데이터를 정형화하는 모습을 보면,

[비정형 데이터 -> 사람의 뇌 -> 정형 데이터]

의 과정을 거치게 됩니다.

여기서 사람의 뇌만 관계추론엔진으로 바꾸어보면,

[비정형 데이터 -> 관계추론엔진 -> 정형 데이터]

으로 바뀔 수 있습니다.

즉, KG는 데이터 간의 관계를 포착할 수 있는 "관계추론엔진"이 필요합니다.

우리가 아는 한 우주에 존재하는 유일한 관계추론엔진은 사람의 뇌였습니다. 그러나 인간은 비로소 두번째 관계추론엔진을 이 우주에 탄생시켰습니다!

이 두번째 엔진은 사람의 노동력(비싼 첫번째 엔진)이 들어간 수 많은 정형 데이터(라벨링 작업), 컴퓨팅 파워, 수학적 모델, 넘쳐나는 비정형 데이터 등이 결합되어 탄생했습니다.

그리고 바로 관계를 가진 데이터를 담는 그릇이 지식그래프입니다. 그동안 연결되지 않았던 수 많은 비정형 데이터를 연결하는 것 외에, RAG에서도 성능을 굉장히 높일 수 있는 것으로 최근 주목받고 있습니다.

GenAI Stack with KG

무려 docker CTO, 랭체인 파운더, Ollama 코파운더, neo4j 파운더 라는 어마무시한 사람들이 모여서 지식그래프를 활용한 새로운 GenAI Stack에 대해 쥬피터 노트북을 만들고 발표했습니다.

그만큼 KG와 LLM의 연계는 정말 큰 흐름이라고 생각합니다. 특히 RAG에서도 documents의 지식연결을 기반으로 RAG 성능을 높이고자 하는 시도가 있는데요, 아래 미디엄 글 너무 재밌어서 강추드립니다!

Neo4j, 나만 알고 싶은 미친 프로덕트

지식그래프 데이터베이스를 제공하는 회사는 neo4j가 압도적으로 편하고 좋습니다.

• 무려 2010년부터 그래프 데이터베이스를 만들던 회사

• 시리즈 E까지 받은 회사 (상장하면 무조건 산다..!)

• 기존 RDBMS에서 그래프 데이터베이스를 구축하는게 아닌, 진짜 그냥 scratch에서부터 구축한 찐 그래프 데이터베이스. RDBMS 기반 그래프 데이터베이스보다 성능이 훨씬 좋음

• RDBMS의 query인 SQL과 같이, 지식그래프에서 표준이 되는 Cypher 라는 query language 개발. 진짜 이거 너무 아름답습니다..

• 클라우드로 서비스 전체 제공

• 심지어 벡터 embeddings, semantic search 기능 제공

공부해보고 싶으신 분들은 neo4j에서 공식으로 운영하는 아카데미를 봐보시는걸 추천드립니다!

DevDay 이후 Startup을 그만두기로 했습니다! [PaxHumana Journey]

좀더 정확하게 말하면, 스타트업식 전략을 그만두기로 했습니다.

저희 팀은 9월까지 “업무자동화 에이전트를 노코드로 쉽게 만들고 공유할 수 있는 플랫폼, Velix(벨릭스)”를 만들어갔는데요, 이번 OpenAI DevDay에서 발표한 GPTs, Assistant API를 보면서 큰 충격을 받았어요.

경쟁사로 SuperAgent,SuperAGI 등을 생각하고 있었는데, 갑자기 OpenAI가 Agent 시장에 참여해버린겁니다. 지금은 다른 솔루션(Fynd)를 만들어가고 있었지만, "우리가 만약 아직도 이 솔루션을 하고 있었다면?" 정말 아찔했습니다. 뿐만 아니라, “OpenAI의 발표 하나로 스타트업 수십개가 망한다”라는 자극적인 기사도 나오고 있죠. (물론 기회일 수 있다는 의견도 가지고 있습니다.)

이러한 맥락에서 저희는 “LLM 혁명에서 스타트업식 성장모델이 가능한 것일까?”라는 생각을 하게 되었습니다.

“모험자본을 받은 스타트업이 새로운 비즈니스 모델을 빠르고 민첩하게 시장에 안착시켜 독점구조를 만들어낸다, 그러고 하이리턴을 추구한다.” 라는 스타트업식 성장모델이 여기서도 가능한 것일까?

(저는 민첩함, 고객중심, 성장, 독점 등의 키워드가 스타트업을 정의하는 키워드라고 생각해요. 이외에는 스타트업이라기보단 사업이라고 생각해요.)

🫥 자본과 자원이 없고 있는거라곤 헝그리 정신밖에 없는 우리, 스타트업식 전략 괜찮을까?

LLM 혁명이 이전의 1세대 인터넷 혁명, 2세대 모바일 혁명 때와 같이 스타트업식 성장모델이 가능한 환경일까?

저희 뿐만 아니라 많은 분들께서 위의 질문에 대해 고민을 공유해주셨는데요,

DevDay를 보고 받은 충격을 받은 저희는 각각의 시장 플레이어들이 어떤 전략을 취해왔는지 분석해보기로 했습니다.

<시장 플레이어들>

1. 모델을 가진 기업들 (OpenAI, 구글 등)

2. 데이터와 자본을 가진 대기업들

   • 인터넷, 모바일 혁명 때 생겨난 신흥 대기업들 (에어비앤비, 트위터, 카카오 등)

   • AI Transformation을 시도하는 레거시한 기업들 (삼성전자, 은행권 등)

3. VC의 투자를 받은 스타트업

4. Solopreneur

이전의 혁명과 대비하여 하나씩 뜯어보자면,

1. 인프라를 만드는 기업들

   • 기술력을 가지고 있음

   • TCP/IP, HTTP, 이동통신 기지국 설치 등

2. 레거시 기업들

   • 대응이 느림

   • Transformation 하는데 오래 걸림

3. VC의 투자를 받은 스타트업

   • 레거시한 시장의 느린 대응을 틈타 새로운 비즈니스 모델 제시

   • 고객의 문제를 정의하고 민첩하게 움직이며 폭발적인 성장을 이뤄냄

4. Solopreneur

   • 거의 없었음

   • 이때는 서비스 하나를 만들어내기 위해 혼자서 하기에는 어려운 상황 (react, API, nocode 툴 없었음)

이전의 혁명에서는 모험자본의 투자를 받은 스타트업이 기존의 대기업들이 느리게 움직이는 틈을 빠르게 들어가 성장해왔습니다. 하지만 지금은 어떨까요?

1. 인프라를 만드는 기업들 (OpenAI, 구글 등)

   • 압도적인 인공지능 모델을 만들 수 있는 자본과 인프라가 있음

   • 이미 스타트업의 영역이 아님

2. 신흥 대기업들 (에어비앤비, 야놀자, 마이리얼트립, 쏘카, 토스 등)

   • 이들은 DNA가 스타트업이기 때문에 대응이 매우 빠름 (도전적)

   • 공개된 API와 자사 데이터를 활용하여 자사 비즈니스에 빠르개 적용 중

3. 레거시 기업들

   • 여전히 대응이 느림

   • Transformation 하는데 오래 걸림

4. VC의 투자를 받은 스타트업

   • 선배 스타트업들이 빠르게 대응하면서 자리가 적음

   • AI Native 한 서비스를 아직 가늠하기 어려움 → 그마저도 OpenAI 가 한다.

5. Solopreneur

   • 다양한 개발 프레임워크, 노코드 툴, 없는게 없는 API → 혼자서 서비스 하루면 만듦

스타트업의 경우 빠른 성장과 독점이 중요한데 반해, 장벽이 너무 낮아져 독점이 어려워지고 (수많은 카피캣) OpenAI와 같이 시장의 포식자마저 스타트업식으로 민첩하게 시장을 독점해나갑니다. 점점 설 자리가 없어지는 것이죠. AI Native한 비즈니스 모델을 고민하는 팀외에는 쉽지 않다고 판단했습니다.

🤩 그렇다면 다른 기회는?

여기서 두가지 기회를 볼 수 있는데요, 하나는 레거시 기업들에게 AI Transformation을 제공하는 AI Agent Agency, 두번째는 Solopreneur 입니다.

AAA는 이전의 웹페이지, 앱 개발 에이전시와 같은 모델이며 로컬에 초점을 맞춥니다. Solopreneur는 날카로운 문제를 찾고 빠르게 서비스를 만들어 전세계를 타겟으로 합니다. 날카롭게 문제를 정의하기 때문에 비율은 작을 수 있지만, 글로벌로 넓히면 모수가 커지기 때문에 마진율이 높게 나오죠.

저희 팀은 고객중심, 성장, 독점, 모험자본의 키워드를 가지는 스타트업에서 고객중심, 흑자, 글로벌, 무자본의 키워드를 가지는 Solopreneur를 시도하기로 했습니다.

이렇듯 앞으로 저희가 현재 만들고 있는 Fynd 또한 Solopreneur 전략으로 접근하고자 합니다.

🧐 Solopreneur vs Starup

저희는 이러한 차이에 기반하여 몇가지 원칙을 세웠습니다.

1. 고객중심 사고방식을 잃지 말자. 대신 고객검증 과정을 줄이기 위해서 우리가 느끼는 문제를 푼다.

2. 무조건 글로벌을 타겟으로 한다. 작은 비율이지만, 돈내는 소수에 집중한다. 또한 글로벌 확장이 용이한 플랫폼을 활용한다.

3. 빠르게 검증하고 빠르게 개발한다.

이번에 출시하게 된 Ultimate GPT Calculator(UGC) 또한 이러한 Solopreneur 전략으로 개발을 하게 되었습니다.

앞으로 저희는 일주일에 하나씩 저희가 느끼는 문제를 빠르게 프로덕트로 개발을 해보려고 합니다!

솔루션을 포기해봤습니다! 고객 이야기만 듣고 [PaxHumana Journey]

Pax Humana는 유튜브 여행 콘텐츠와 지도를 연결하는 여행정보 탐색 플랫폼,

Fynd를 만들고 있습니다.

이전 이야기 | LLM을 두고 고객으로 돌아갑니다!

🧐 어떤 문제를 검증할까?

아무래도 몽상가 기질이 강한 사람들은 솔루션으로부터 생각을 시작하는 경향이 있죠, 저희 팀도 마찬가지였습니다. 그래서 몇가지 솔루션을 먼저 상정하고 이들의 고객가설(CP Fit)을 한달에 하나씩 검증해나가기로 했습니다.

기존의 진행하던 업무자동화 에이전트를 더 세분화해서 두 개, 기존에 아이디어 백로그에 넣어놨던 것 한 개 해서 총 3개의 솔루션으로 추렸습니다.

• VC를 위한 시장조사 자동화 에이전트

• 개발자를 위한 Enthusiasstic을 위한 트위터 인사이트 에이전트

• 여행지에 대한 문장 기반 메타검색 플랫폼

그리고 “가장 기술적으로 쉬운 것”을 먼저 검증하자는 기준에 맞춰 “여행지에 대한 문장 기반 메타검색 플랫폼”을 선택하게 되었습니다. (고객인터뷰를 하면서 해당 솔루션에서 많이 변화하게 되었는데 그 과정도 앞으로 공유해드릴게요!)

여행지에 대한 문장 기반 메타검색 플랫폼은 RAG(Retrieval Augmented Generation)와 Agent Workflow 등 고려할게 많은 로직을 쓰지 않고, 크롤러와 embeddings, Semantic Search 만 해주면 되는 비교적 간단한 솔루션이었습니다. (물론 embeddings를 어떻게 텍스트를 쪼개서 만들어야 의미를 잘 담을 수 있을지에 대한 고민을 해야했겠지만요.)

😤 문제를 구조화해보자!

그렇게 10월 4일 (추석 지나고나서) 부터 본격적으로 문제를 구조화해보기 시작했습니다. 저희의 검증전략은 이랬습니다.

1. BM Tree를 활용하여 문제가설(CP Fit)을 구조화한다.

   • 고객이 실제 문제/욕구를 느끼고 있는지

   • 고객이 문제를 해결하기 위해 적극적으로 노력하고 있는지

2. 고객과 문제인터뷰를 통해 각 계층의 문제가설을 검증한다.

문제-솔루션-프로덕트의 계층과 가설들을 구조화해본 결과, 저희가 검증해야 하는 핵심가설이 추려졌습니다.

1. 20대 여행 예정자는 원하는 취향의 여행지를 찾기 위해 키워드를 잘 정의하는 것이 불편하다.

2. 20대 여행 예정자는 검색이 되지 않는 이미지와 영상장면 등의 비정형 데이터를 검색하고 싶다.

(실제 저희가 작성한 첫번째 버전의 BM Tree도 공유드립니다 👉 BM Tree 구경해보기)

🤩 문제인터뷰로 검증하자!

스티브 블랭크의 “기업 창업가 매뉴얼”, 애시 모리아의 “린스타트업”, YC Eric Migicovsky의 “How To Talk To Users” 등을 다시 복기하면서 문제인터뷰를 준비했습니다. (YC 사랑합니다..)

지키고자 했던 원칙은 두가지였습니다.

1. 우리가 생각하는 솔루션에 대한 언급을 일절 하지 말자.

2. 검증하고자 하는 문제와 상관없이, 고객의 여행 전 과정에 대해서 들어보자.

그렇게 1차 인터뷰(10월 2주차)를 진행하면서 얻은 인사이트는,

1. 고객의 여행정보 검색과정에서 사용하는 검색어는 매우 간단하다.

   • 검색어를 크게 고민하지 않는다.

   • 내 취향이 뭔지 말로 표현하는 과정이 생각보다 어렵기 때문이다.

   • 검색결과 나온 후보들을 직접 보면서 느낌적인 느낌으로 필터링하는 경우가 많다. (말로 표현은 안되지만, 필터링은 된다.)

2. 고객은 이미 다녀온 사람들의 후기를 신뢰한다.

   • 영상은 생생한 느낌을 얻을 수 있어 매우 사용빈도가 높다.

   • 영상의 단점은 정보수집이 불편하다.

   • 반면 텍스트 형태는 정보수집에 적합하다고 느낀다.

이를 통해 핵심 문제가설 중 첫번째 가설은 기각을 하게 됩니다.

1. 20대 여행 예정자는 원하는 취향의 여행지를 찾기 위해 키워드를 잘 정의하는 것이 불편하다.

2. 20대 여행 예정자는 검색이 되지 않는 이미지와 영상장면 등의 비정형 데이터를 검색하고 싶다.

첫번째 가설은 [여행지에 대한 문장 기반 메타검색 플랫폼]이라는 솔루션의 가장 핵심적인 가설이었는데, 보기 좋게 기각당했습니다..ㅎㅎ

그리고 저희는 고객의 목소리에 기반한 의사결정을 하기로 한 만큼

과감하게 Semantic Search 기반의 문장검색 솔루션을 포기하게 됩니다.

(이전의 망치에 집착하는 저희였다면 이런 선택을 할 수 없었을거 같아요.)

그리고 두번째 가설의 검증에 더욱 초점을 맞춰 검증을 이어나갔는데요, 더 자세한 이야기는 다음 편에서 다루겠습니다. 단순히 질의응답을 하는 인터뷰 방식을 넘어, 심리학 실험과 같은 형태로 활동을 구성해서 인터뷰를 진행해보았는데 그 이야기를 들려드리도록 하겠습니다!

아 마지막으로 최근에 여행을 다녀오셨거나, 계획하고 있는 분이 계시다면, 소중한 시간 내어 고객인터뷰 참여해주시면 감사하겠습니다😊 인터뷰 외에 가설검증, 인공지능과 관련한 이야기도 나누고 싶다면 언제든지 커피챗, 인터뷰 신청해주세요:)

LLM을 두고 고객으로 돌아갑니다! [PaxHumana Journey]

Pax Humana는 유튜브 여행 콘텐츠와 지도를 연결하는 여행정보 탐색 플랫폼,

Fynd를 만들고 있습니다.

🤣 LLM이라는 너무 재밌는 망치

8월부터 저희 팍스휴마나팀은 업무 자동화 에이전트 플랫폼 벨릭스를 만들고자 했습니다.

LLM, RAG, Agent.. 공부하고 개발할수록 “와.. 이거 너무 재밌는데?”

아이디어, 상상, 미래. N인 저는 매일 도파민 파티였습니다. 뭔가 생각이 항상 멀리 가있었던거 같아요.

마치 망치가 손에 쥐어지니 모든 것을 해결할 수 있을거 같은 느낌이랄까요.

다른 분들과 만나면 “지식노동의 자동화를 목표로 업무 자동화 에이전트 플랫폼을 만듭니다.” 라고 뜬구름 잡는 얘기를 했습니다. 돌아오는 답은 “정확히 뭘하려는건지 모르겠다.”, “고객은 얼마나 만나보셨나요?” “좀더 작은 것부터 날카롭게 보는게 중요할거 같다.” 였습니다.

하지만 뭔가 씌인 거처럼 “와우하게 만들기만 하면, 사람들은 쓸거야.” 라고 생각했죠.

그러다가 저의 멘토이신 교수님과 오랜만에 만난 자리에서 진짜 망치로 머리를 맞았습니다.

작년에 대표님은 고객에 미쳐있었는데, 지금은 왜이렇게 엔지니어가 되셨어요?

그제서야 작년의 저와 비교하면서 “아.. 뭔가 잘못되고 있구나”를 깨달았습니다.

🧐 작년에 무슨 일이 있었는데?

작년에 저는 [마케팅 게이미피케이션을 노코드로 구현할 수 있는 SaaS, 버틀봇]로 교내 창업프로그램에 입주했었는데요,

사업은 결국 실패로 끝났고, 정작 남은건 [고객을 검증하는 프레임워크] 였습니다.

그 당시 린 고객개발의 계보를 잇는 책들(스티브 블랭크, 에릭 리스, 애시 모리아 등)을 바이블로 삼아, 고객 만나고 치밀하게 가설 세우고 검증하기를 반복했었는데,

그 과정에서 탄생한 것이 “5Fit Cycle”과 “BM Tree” 였습니다.

5Fit Cycle: “PMF가 하늘에서 뚝 떨어지는게 아닐텐데, 분명 그 전 단계들이 있지 않을까?” 하는 의문에서 시작하여, 린 고객개발의 과정을 함께 결합한 개념입니다.

“PMF가 되기 전에 앞단의 Fit들이 맞아떨어져야 한다!”는 당연한 이야기를 좀더 시각화하고 정리한 것이죠.

BM Tree: 린캔버스나 비즈니스 캔버스로 가설을 정리할 때 가설의 위계구조를 만드는 스스로를 발견하게 되면서, 가설을 트리구조로 재구조화한 개념입니다. 이 또한 가설검증의 선행관계를 매우 중요하게 생각하는 구조에요.

(더 궁금하신 분들은 작년에 발행한 글을 참고해주세요!)

🫥 LLM 망치 내려놓을 각오됐어?

멘토님과 헤어진 후에 바로 긴급 미팅을 진행했습니다.

그리고 저희는 9월 25일 저희의 장난감이던 LLM 망치를 내려놓고 고객으로 돌아가기로 했습니다!

LLM에 매료되어 모인 개발자 팀이었기에 이전까지 린 고객개발, 5Fit Cycle, BM Tree, 고객, 가설검증 등은 제대로 꺼내본 적이 없었는데, 생각보다 팀의 반응은 폭발적이었습니다.

고객의 문제를 풀어주고 사랑받는 프로덕트를 만들자!

우리가 이 프레임워크의 좋은 선례가 되자!

라는 다짐으로 고객을 만나기 시작했습니다.

그래서 너희는 지금 “뭘하고 있는거냐”라고 물으시면! 바로 아래의 다음 편을 읽어주세요ㅎ.ㅎ

LLM을 코드 안으로 넣으려는 시도들 (feat. OpenAI Function call API)

10X AI Club 톡방에 올린 내용을 공유합니다!

OpenAI Function Call이 6월13일에 출시된 이후 LLM 개발의 게임체인저가 아닐까 생각했습니다. (6월 13일을 외우고 있는 이유는 모델이름에 0613이 들어가기 때문..)

Function call을 통해서 비정형 데이터를 정형 데이터(JSON)로 변환하고 이를 코드에서 바로 사용할 수 있도록 하는 것이죠.

같은 흐름으로 LLM을 Pythonic 한 파이썬 코드의 일부로 만드려고 하는 시도들이 많았는데, 점점 이렇게 Low Level로 LLM이 프로덕트 안쪽으로 통합되지 않을까 상상해봅니다.

관련해서 재밌게 팔로잉하고 있는 라이브러리 공유드립니다!

https://jxnl.github.io/instructor/

https://github.com/PrefectHQ/marvin

개인적으로 instructor 라이브러리의 개발자 Jason은 제가 트위터에서 좋아하는 분인데 Pydantic을 사용해서 LLM을 코드 안으로 넣으려는 시도를 많이 하시더라고요.

https://twitter.com/jxnlco

LLM을 손에 쥐어주니, 모든 것이 못으로 보였다.

예전 블록체인씬에서 밈처럼 돌았던 말:

If blockchain is a hammer, then everything looks like a nail.

지금의 내가 딱 이런 상태

If LLM is a hammer, then everything looks like a nail.

한동안 고객을 완전히 잊고 있었다.

고객의 문제보다는 기술, 쿨한 것을 쫓고 있었다.

많은 분들이 "고객 인터뷰는 얼마나 해봤어요? 고객들은 어떠셨어요?" 라고 물어보면 답하지 못했다.

그때 머리를 띵 맞았다.

그래서 다시 고객으로 돌아가기로 했다!

아무리 좋은 아이디어, 혁신적인 기술이라도 원하는 고객이 없으면 비즈니스 모델의 사이클은 굴러가지 않습니다.

-딱 1년전에 내가 했던 말

어릴적 좋아했던 SF 작품

어릴적 재밌게 보고 즐겼던 SF 작품들 갑자기 생각나서 끄적여봅니다.

(황금연휴 지나가는 아쉬움에..)

1. 스타트랙 유니버스 (미드)

   스타트랙 미드 시리즈 중 최애. 고대 외계문명의 우주선에 떨어지게 된 우주인들의 탐험기. 새로운 행성 갈 때마다 어떤 행성일까 설렜던 기억

2. 프린지 (미드)

   초과학적 현상을 수사하는 FBI 같은 느낌. 알고보면 멀티버스의 시조, 재밌는 현상 투성이에 마지막 멀티버스 떡밥 미침

3. 레볼루션 (미드)

   포스트아포칼립소 장르. 현대문명이 파괴된 후의 세계라 흥미롭고, 미국이 여러 국가로 쪼개지는 상상 자체가 즐거움. 떡밥도 나름 있지만 금방 끝나서 아쉽

4. 이외 파운데이션 (소설), 스포어(게임) 등

돌이켜보니 지금의 제 세계관을 만든 건 SF 작품이었던거 같네요!

다른 분들이 좋아하는 SF 작품들, 그냥 작품도 궁금하네요!

[데일리X]머스크 형님의 스트리머 데뷔 (모든 것이 되고픈 X)

https://twitter.com/elonmusk/status/1708776354597003329?t=km9wR3MMoBkklHeu7UMHqA&s=19

X에서 게임 스트리밍 기능을 업데이트한다고 하네요,

그리고 친히 직접 테스팅해주시는 머스크 형님..

과연 머스크 형님의 별풍 100개 리액션은 뭘까 설레서 잠이 오질 않네요ㅎㅎ