Jira에서 최선의 결과를 만들어내는 데 중요한 에픽, 스토리, 서브태스크 작성법

이전에 스크럼 리딩 경험이 없던 프로덕트 매니저(오너), 프로덕트 디자이너 혹은 테크 리더(개발자)가 스크럼을 책임지고 운영해야 하는 상황이 발생했을 때, 당황하는 경우 중 하나는 직접 에픽(Epic), 스토리(Story), 서브태스크(Sub-task)를 작성해야 하는 때에 발생합니다. (경험담입니다.)

모든 스크럼 팀원들이 움직이기 위해 보는 하나의 지도가 Epic, Story, Sub-task 라는 요소들이기 때문에 이를 어떻게 작성해야 논리적이고 직관적일 지 고민이 많이 되는 부분입니다.

물론 정해진 정답은 없습니다. 주어진 상황과 환경에 따라 잘 적응하는 것이 최선이지만 적응에 앞서 참고할만한 표준이 있다면 더 쉽게 적응할 수 있다고 생각하여 Epic, Story, Sub-task를 작성하는 방법에 대해 공부한 글을 정리해봅니다.

📌 에픽의 제목은 프로덕트 로드맵에 해당하는 내용으로 기술합니다. 이 때, '000으로서'라는 주체를 명시하는 것을 권장합니다. 그 이유는 해당 에픽의 출처와 목적, 맥락을 알 수 있도록 하기 위함입니다.

📌 에픽의 하위인 스토리의 제목을 작성할 때는 'UUU는(User/Who), PPP 할 수 있도록(Purpose/Why), AAA 하길 원한다(Action/What)'의 방식으로 기술하는 것을 권장합니다. 그 이유 역시 해당 스토리의 출처와 목적, 맥락을 알 수 있도록 하기 위함입니다.

📌 어떤 상황에서도 통하는 완벽한 방법은 없으며, 스크럼 팀이 스프린트를 진행하면서 비즈니스 목표를 잊지 않고 일이 되는 방향(방법)으로 꾸준히 나아가고 개선하는 것이 가장 중요합니다.

본 글 보러가기 :

Jira로 스크럼 & 스프린트 운영하기

인생 첫 스크럼 & 스프린트를 앞두고 잘하고 싶은 마음에 부담감이 컸던 예전 기억이 있습니다. 특히, 스크럼과 스프린트라는 방법론에 대한 명확한 가이드가 없는 상태로 진행했던 터라 더욱 막막한 기분이 들었던 거 같아요.

결국 첫 스프린트는 좌충우돌로 종료하면서 지식이나 경험이 부족한 주니어라도 보고 따라갈 수 있는 좋은 가이드가 있으면 좋겠다고 생각했습니다. 그래서 공부하고 정리한 내용 중 오늘은 Jira로 스크럼과 스프린트를 어떻게 운영하면 좋을지 적어보려 합니다.

Index
1️⃣ Jira 프로젝트 운영 원칙
2️⃣ Issue Type은 어떻게 설정하고 어떤 내용을 적어야 하는 지
3️⃣ Backlog 관리 방법
4️⃣ Sprint Board 구성하기
5️⃣ Sprint Schedule짜는 방법

📌 Product 별로 Jira project를 생성해서 Sprint를 운영함을 원칙으로 합니다. Product의 특성에 따라 Project의 템플릿은 달라질 수 있으나, 기본적으로 스크럼 형태의 보드 운영을 기본으로 합니다.

📌 Epic(에픽)은 Product의 로드맵으로 관리되는 단위를 Epic으로 생성하고 구체적인 마일스톤과 그에 대한 일정이 담긴 요소로 지정하면 됩니다.

📌 Story(스토리)는 Product를 이용하는 사용자에게 제공하는 기능을 서술하는 단위를 의미합니다. Sprint 1회 안에서 개발 완료 및 사용 가능한 기능의 최소 단위로 Story를 생성하도록 권장합니다.

본 글의 링크는 아래 링크드인 업데이트의 댓글에 추가했습니다!

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 2

이전 업데이트에서 제가 스크럼을 탄탄하게 운영하기 위해 이론부터 공부하기 시작한 과정과 스크럼의 정의, 스크럼 팀이 어떻게 구성되는지 그리고 각 구성원들의 역할에 대해서 쓴 '어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1'을 공유했었습니다.

Part 2에서는 스크럼을 실질적으로 운영하는 방식과 스크럼의 산출물(=개선된 제품)에 대해 적어보았습니다.

📌 스크럼이 자동차라면 스프린트는 엔진이라고 비유할 수 있을 것 같습니다. 스프린트에서는 2주~4주 정도의 기간으로 고정된 길이의 이벤트로, 스프린트 기간 동안 스프린트 플래닝, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 제품의 목표를 달성하기 위한 모든 작업을 수행하게 됩니다.

📌 스프린트 플래닝은 스프린트 동안 수행할 작업을 선정하는 이벤트로 스크럼 팀 전체가 참여하여 플래닝합니다. 이때, 프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요하면서 우선순위가 높은 아이템들을 나열하고 해당 아이템들이 프로덕트 목표에 어떻게 연결되는 지를 논의할 수 있도록 준비해야 합니다.

📌가치의 증가분(산출물)
가치의 증가분은 최종적인 프로덕트 목표를 달성하기 위한 디딤돌입니다. 매 스프린트마다 스크럼 팀이 만들어낸 가치의 증가분은 누적되어 증가하여 전체 가치의 총량을 크게 만듭니다.

📌 2주 스프린트 예시
1️⃣ 스프린트 플래닝을 통해 이번 스프린트에 진행할 백로그를 선정하고, 백로그를 완료하기 위한 작업 목록을 쪼개어 배분합니다.
2️⃣ 백로그가 바로 기능 개발이 가능할 정도로 구체화되었다면 백엔드부터 설계 및 개발을 시작합니다. 프론트엔드는 디자인 작업물이 나온 뒤 작업이 가능하기 때문에 상대적으로 작업 시작 시점이 늦을 수 있습니다.
3️⃣ 스프린트 기간 동안 데일리 스크럼을 통해 지속적인 커뮤니케이션으로 목표 달성을 위한 최적화 작업을 진행합니다.
4️⃣ 백엔드와 프론트엔드 모두 개발이 완료되면 QA를 진행합니다.
5️⃣ 스프린트 리뷰를 통해 스크럼 팀원과 이해관계자가 실제 동작하는 백로그를 확인하고 다음 스프린트에 대해 논의합니다.
6️⃣ 스프린트 회고를 통해 이번 스프린트에서의 KPT를 논의하고 스프린트를 종료합니다.

본 글 링크는 아래 첨부합니다.

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

안녕하세요, 기획자Sean 입니다.

스크럼을 직관으로 운영하면서 발생하는 비효율을 개선하기 위해 이론 공부를 하고 이를 적용시켜 배운 점들을 이론과 함께 정리하고 있는 글을 링크드인에 발행했습니다.

많은 관심 부탁드려요 :)

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

저는 서비스 기획자로 시작해서 현재는 Product Manager로 총 6년동안 일을 하면서 6개의 프로덕트를 런칭하고 운영해오고 있습니다.(사이드 프로젝트는 제외했습니다.) 프로덕트를 개발하면서 워터폴과 애자일 환경을 모두 경험해보았고, 스크럼 팀 역시 다회 운영하고 있습니다.

하지만 고백컨데 주니어 시절의 저는 경험 기반의 직관에 의존하는 Product Manager이자 기획자였습니다. 고객에게 제품의 핵심 가치를 잘 전달하기 위해 필요한 개선점들을 백로그화하고 스프린트를 운영하긴 했지만, 이 제품 개발 프레임워크를 이론적으로 공부한 적은 없었죠.

이런 상황에서 실제 스프린트를 운영하다보니 프로세스적으로 비효율이 발생했고 심지어 비효율이 누적되는 것이 체감되기 시작했습니다. 그리고 몇 번의 이직을 하면서 느낀 점은 스크럼(Scrum)이라는 프레임워크를 제대로 교육하고 정착시켜 스크럼 방식을 통해 얻고자 하는 효과를 얻고있는 회사는 극히 드물다는 것이었습니다.

이 글은 제가 앞서 체감하기 시작한 문제를 해결하기 위해 스크럼(Scrum)을 이론적으로 공부하고 실제 적용해 보면서 배운 점들을 정리하는 동시에 팀에게 스크럼의 목적과 효과, 프로세스를 가이드하기 위해 쓰는 글입니다.

📌 스크럼을 풀어서 설명하면 '팀을 중심으로 문제에 대한 해결 방법을 고객 가치 관점의 솔루션으로 만들어내는 프로세스 프레임워크'라고 할 수 있습니다. 이 프로세스를 날씬하고 날렵한 사고와 이터레이션을 통한 지식 습득(린 씽킹), 이를 통한 반복적인 개선하는 방식(경험주의)으로 운영하면 이상적인 스크럼에 가깝지 않을까 생각합니다.

📌 저는 5명, 10명, 15명 규모의 스크럼 팀을 운영하면서 10명 내외의 크기가 스크럼의 이상적인 팀 크기라고 확신하게 되었습니다. 10명의 크기일 때, 상대적으로 소통이 원활하여 의사결정이 민첩하면서 규모가 있는 가치의 증가분도 만들어 낼 수 있었기 때문입니다.

📌 스크럼 프로세스
1️⃣ 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2️⃣ 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분 Increment of value 으로 만들어 낸다. (*증가분은 스크럼팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미)
3️⃣ 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4️⃣ 반복한다.

본 글의 링크는 아래 첨부합니다.

저를 소개합니다 🙉

1. 간단한 자기소개를 부탁드립니다.

• 그립(Grip)에서 Global Product Manager로 즐기고 있는 기획자Sean입니다.

• 6년의 커리어 동안 커머스, 핀테크, AI, 마케팅 분야의 프로덕트 6개를 런칭하고 운영하고 있습니다.

2. 왜 링크드인을 활용하려고 하는지/어떤 것을 얻고 싶은지 알려주세요.

• 6개의 프로덕트를 런칭하고 운영하면서 배우고 경험한 것들을 정리하고 나누고 싶습니다.

• 장기적으로 퍼스널 브랜딩이 더 큰 기회를 줄 수 있을 거 같다는 판단이 들어 그 시작을 링크드인으로 하고자 합니다.

3. 자신의 링크드인 URL을 꼭 첨부해주세요!

http://www.linkedin.com/in/seungjae-lee-062727111

1. 배우고 경험한 내용 중 북극성 지표에 관한 레슨런을 공유했습니다.
   팀이 한 방향을 바라보고 있지 않다고 생각하시거나, 조직의 급격한 성장으로 인해 비효율성이 증가는 상태에 있다면 도움이 되는 글이 아닐까 생각해봅니다 👏

우리 제품이 성공 중이라는 것을 알 수 있는 방법

안녕하세요. 저는 Grip에서 개발, 디자인, 사업 등 다양한 직군의 팀원들과 함께 서비스를 만드는 프로덕트 매니저입니다. 그리고 이 서비스와 제품이 얼마나 잘 만들어지고 있는지 측정하는 지표와 방법은 수없이 많습니다. DAU/WAU/MAU(Daily/Weekly/Monthly Active Users), 회원가입 수, ARPU(Average Revenue Per User), 기간별 리텐션 등 모두 열거하자면 끝이 없을 겁니다.

비즈니스와 개발, 디자인의 중심에서 신호등 역할을 하는 프로덕트 매니저로써 제품이 올바른 방향으로 나아가기 위해 어떤 지표를 중요하게 보아야 하는 지는 끊임없이 고민하는 부분입니다. 제품의 완성도만을 생각하면 사업적인 목표를 달성하기 어려울 수 있고, 사업적인 목표 달성에만 집중하면 고객에게 우리 제품의 가치를 제대로 전달하지 못하는 경우가 생길 수 있기 때문입니다.

스타트업이 PMF(Product Market Fit)을 찾고 큰 규모의 투자를 받아 스케일업하는 시기에는 제품과 구성원, 조직 구조에 급격하고 빠른 변화가 일어나기 때문에 견고하다고 생각했던 제품의 방향성이 흔들리는 경우가 종종 발생하곤 합니다. 이때 비즈니스와 개발, 디자인 관점에서의 요구사항들을 만족하는 동시에 서비스가 제대로 성장하고 있는 지 검증할 수 있는 지표가 필요하다고 생각했고 북극성 지표(North Star Metric)가 떠올랐습니다. 이 글은 제가 우리 제품이 성공 중이라는 것을 알 수 있는 근거가 되는 지표에 대해 조사하고 공부한 바를 정리하는 글입니다.

제품 성공의 척도, 북극성 지표(North Star Metric)

북극성 지표에 대해서는 다양한 정의가 존재하지만 저는 북극성 지표를 제품이 고객에게 전달하는 핵심 가치를 반영하는 지표로 정의했습니다. 즉, 제품이 고객에게 전달하고자 하는 핵심 가치가 고객에게 정말 잘 전달될수록 우리 제품이 성공하고 있다는 의미입니다.

그럼 많은 기업들이 중요한 지표로 보고 있는 매출과 같은 일반적인 지표가 좋은 북극성 지표일까요? 저는 아니라고 생각합니다. 그 이유는 매출이 제품이 고객에게 전달하고자 하는 핵심 가치를 반영하지 못하기 때문입니다. 비즈니스의 성장과 관계없이 마케팅 프로모션과 같은 단발성 이벤트를 통해 매출을 높일 수 있는 것처럼요. 또한 매출은 액션을 불러일으키기 어렵습니다. 매출을 높이기 위한 액션을 고민해보면 사실상 모든 액션이 후보가 될 수 있고, 그 중 우선순위를 판단하는 것 역시 어렵기 때문이죠.

좋은 북극성 지표의 예시

앞서 북극성 지표를 제품이 고객에게 전달하는 핵심 가치를 반영하는 지표로 정의한 것을 기억하면서 좋은 성과를 내고 있는 서비스들의 북극성 지표를 살펴보았습니다.

페이스북의 북극성 지표인 10일 안에 7명과 친구를 맺는 사용자의 수는 연결이라는 페이스북의 핵심 가치를 반영합니다. 이 수치를 늘릴수록 더 큰 네트워크 효과가 발생하고 주요 BM인 광고 사업 역시 성장하여 매출 증가라는 결실을 맺어오고 있습니다.

페이스북과 같이 에어비앤비, 스포티파이, 넷플릭스 등의 기업들도 예약, 음악 감상, 컨텐츠 시청과 같이 그들의 제품이 고객에게 제공하고자 하는 핵심 가치가 반영된 지표를 북극성 지표로 활용하고 있습니다.

이런 북극성 지표를 설정할 때는 대표적으로 3가지 요소가 필요합니다. 더 많은 요소가 더해질 수 있겠지만 아래의 3요소는 개인적으로 필요 조건이라고 생각합니다.

구체적으로는 대상 고객(who), 전달할 핵심 가치(what), 달성 기간 (when)을 명확하게 정의하는 것을 의미합니다. 경험적으로 who와 what은 필요성에 대해 인지하지만 when을 정의하지 않거나 모호하게 정의하는 경우가 종종 있는 것 같습니다. 하지만 시간 제한은 매우 중요합니다. 위의 예시에서 7명의 친구를 맺는 사용자의 수만을 북극성 지표로 설정한다면 이 가치를 경험하기까지 3년이 걸려도 틀린 것은 아니게 되기 때문입니다. 초기 스타트업이라면 3년이라는 시간은 생존 여부조차 불투명한 기간일 수 있으니까요.

북극성 지표의 의미와 역할

북극성 지표는 조직의 모든 구성원이 하나의 목표를 향해 움직일 수 있도록 나침밤의 역할을 합니다. 그러나 북극성 지표에 대해 공부하면서 어쩌면 나침반만큼 중요하면서 실질적인 도움을 주는 역할도 수행할 수 있다고 느낀 점은 북극성 지표는 구체적인 액션을 불러일으킬 수 있어야 한다는 점이었습니다.

예를 들어보겠습니다. 스포티파이는 '유료 사용자가 한 달 동안 음악을 듣는 총 시간'이라는 북극성 지표(=output metric)를 성장시키기 위한 투입 지표(=input metrics)로 기존 고객을 더 자주 불러오거나, 세션 당 사용 시간을 늘려야 한다고 정의했습니다. 그리고 이 액션들을 달성하기 위한 더 세부적인 투입 지표들로 쪼개고 있습니다.

Amplitude의 글에서는 이런 투입 지표를 설정할 때 고려할 차원으로 아래의 4가지를 꼽고 있습니다.

• 넓이(Breadth) : 얼마나 많은 활성 유저가 액션하는가?

• 깊이(Depth) : 활성 유저는 얼마나 깊은 액션까지 도달하는가?

• 빈도(Frequency) : 각 유저는 얼마나 자주 액션하는가?

• 속도(Efficiency) : 각 유저는 얼마나 빠르게 핵심 가치를 경험하는가?

이번엔 스포티파이의 예시를 대입해보겠습니다.

• 넓이(Breadth) : 트래픽. 음악 감상을 행하는 유저의 수

• 깊이(Depth) : 위의 트래픽이 상호작용을 하는 수준. 음악 감상 혹은 감상을 넘어 친구에게 공유하기

• 빈도(Frequency) : 각 유저는 얼마나 자주 액션하는가?

• 속도(Efficiency) : 각 유저는 얼마나 빠르게 핵심 가치를 경험하는가?

이렇게 세분화된 투입 지표는 신규 아티스트 알림 기능 추가, 음악 추천 기능 개선, 맞춤형 플레이리스트 제작 서비스 제공 등 구체적인 실행 계획으로 구체화될 수 있습니다. 그러면 우리는 북극성 지표를 성장시키기 위한 뾰족한 액션(=product initiatives)을 정의하고 실행할 수 있게 됩니다.

여기까지 보면 북극성 지표만 성장시키면 만사 오케이라는 생각이 들수도 있습니다. 하지만 북극성 지표는 미래 제품의 성공에 대한 선행 지표로 작용해야 합니다. 미래에 제품의 성공 기준으 매출이라면 연 매출을 올리기 위해 그 전에 시행되어야 하는 지표라는 뜻이죠. 정리하자면 고객에게 전달하는 핵심 가치가 가장 잘 반영되면서 우리 회사의 전략적인 방향성과 맞아떨어지는 지표를 북극성 지표로 설정해야 합니다.

이 과정을 통해 우리는 제품이 성공하기 위해 집중해야 하는 지표를 명확하게 분별하고 이를 달성하기 위한 구체적인 액션 아이템을 도출할 수 있습니다. 그리고 우리가 이 지표를 제대로 설정했고 액션을 실행한다면 우리는 결국 성공하게 될겁니다. 

북극성 지표 역시 끊임없이 적응하고 변해야 합니다.

실제 북극성과는 다르게 북극성 지표는 비즈니스, 제품의 성숙도에 따라 변할 수 있어야 합니다. 예를 들어, 초창기의 플랫폼 비즈니스는 네트워크 효과를 발생시킬만큼의 공급자와 소비자의 유입량 증대가 대표적인 북극성 지표가 될 수 있습니다. 하지만 비즈니스가 성숙함에 따라 수익성의 개선과 같은 질적인 요소로 북극성 지표의 방향을 선회해야하는 상황이 생길 수 있습니다.

산업과 조직마다 천차만별이겠지만 Amplitude의 글에서는 IT 서비스 제품 초기 단계라면 6~12개월, Product-Market Fit 을 찾아내고 안정화 단계에 들어서는 회사는 12~36개월의 단위로 북극성 지표를 돌아보는 경향이 있다고 합니다.

그리고 끊임없이 적응하고 변해야 한다는 것은 북극성 지표 역시 제품을 바라보는 수많은 관점 중 하나라는 것이 저의 생각입니다. 모든 조직을 하나의 목표로 얼라인시키는 데는 분명 유용한 도구이지만 북극성 지표가 비즈니스의 모든 측면을 커버하는 유일무이한 완벽한 지표는 아닐 것이기 때문입니다. 따라서 우리는 이 도구를 적절한 용도와 시기에 유용하게 사용하면서 계속해서 검증하고 개선하는 것이 필요하다고 생각합니다.

린 스타트업 방법론은 여전히 유효할까?

재즈 공부하던 유학생이 경영학으로 전공을 바꾸면서 품었던 목표가 있습니다.

'성공적인 IT 비즈니스를 만들어 경제적 자유를 확보하고 좋은 투자를 해서 선순환 고리를 만들자.'

이번 PMC 참여는 목표로 가는 길에 만나는 여러 에피소드 중 하나라고 생각합니다.

제 성향과 환경을 고려했을 때, 목표를 이루려면 리스크를 최소화하는 린 스타트업 방법론이 필요하다고 판단했습니다.

제가 생각하는 린 스타트업 방법론의 주요 키워드는 '빠르고' '안전하게'입니다.

빠르게 만들고, 확실하게 검증해서 실패의 가능성을 0에 가깝게 만들면서 사업을 진행하는 방식입니다.

손자병법에서 말하는 '이겨 놓고 싸운다.' 와도 맥이 닿아있다고 생각합니다.

(아아.. 선생님!)

저는 Thx, Dad 라는 서비스를 린 스타트업 방법론으로 빌드업해보려고 합니다.

Thx, Dad 는 매일 일상에서 부닥치는 문제에 대해 아빠가 자녀들에게 알려주듯 자상한 조언(dadvice)을 해주는 LLM 기반 챗봇 서비스입니다.

Thx, Dad 는 1)LLM을 이용한 제품의 Product Manager로 일하고 있는 저의 경험과 2)우연히 알게 된 470만명의 구독자를 보유한 Dad, how do I?(https://www.youtube.com/@DadhowdoI) 채널에서 영감을 받았습니다.

현재 초기 기획을 완료해서 prototype을 준비 중에 있으며, 앞으로 6주간 이 서비스를 어떻게 '빠르게', '안전하게' 빌드업하는 지에 관한 로그를 남겨보겠습니다.

린 스타트업 방법론은 여전히 유효할까요?

사용하는 사람을 위한 설계의 중요성

식어가던 AI 산업에 대한 기대와 관심을 뜨겁게 만든 ChatGPT를 시작으로 구글의 Bard, 안트로픽의 Claude, 메타의 LLaMA, 네이버의 HyperCLOVA X 등 대규모 언어 모델 (Large Language Model, 이하 LLM)들이 튀어나오고 매일같이 새로운 레코드를 찍고 있습니다.

LLM을 다루는 PM의 관점에서 AI는 놀라울 정도로 빠르게 발전하고 있지만, 사용자에게 전달되는 가치가 기술만큼 빠르게 발전하고 있느냐고 물어본다면 아니라고 답할 거 같습니다. 최종 사용자가 LLM 기반의 서비스를 이용할 때의 사용성은 여전히 불편하기 때문입니다.

순식간에 월간 사용자 1억 명을 돌파해 역사적인 기록을 남겼던 ChatGPT의 최근 활성 유저 수가 감소세에 접어든 이유 중에 하나도 이런 이유가 있지 않을까 합니다.
(물론, 아직도 어마어마한 사용자를 보유하고 있습니다.)

하지만 최근 generative AI 씬에서 귀여우면서도 배울 점이 가득한 제품을 찾았습니다.

Stable Diffusion으로 유명한 stability.ai의 'Stable Doodle'입니다.

Stable Diffusion이 사람이 사용하는 plain text 기반의 프롬프트를 이용해 이미지를 생성하는 generative ai 서비스라면, Stable Doodle은 'doodle(낙서)'과 함께 간단한 프롬프트를 이용해 이미지를 생성할 수 있습니다.

둘의 차이는 작은 낙서 하나이지만 사용성의 차이는 매우 큽니다. 양궁에서 2mm의 높낮이 차이가 과녁에서 38cm의 차이가 되는 것처럼요.

Stable Diffusion은 text 기반의 프롬프트를 아주 구체적이면서 AI 감수성이 충만한 문장으로 배경부터 분위기, 피사체까지 모든 묘사를 해내야 원하는 결과를 얻을 수 있습니다. 즉, 경험치가 낮은 일반 사용자가 원하는 결과물을 얻기가 쉽지 않다는 뜻입니다.

Stable Doodle은 머릿속에 있는 이미지에 대한 투박한 낙서를 추가함으로써 상대적으로 간단한 프롬프트만으로도 내가 원하는 결과물을 얻을 가능성을 비약적으로 높여줍니다. 첨부한 이미지처럼 허접한 저의 낙서일지라도 말이죠.

재밌고 귀여운 방식으로 사용자의 허들을 낮춘 stable doodle를 보면서 LLM에서의 '낙서'는 무엇일까 고민해보게 됩니다.