📚 한 달을 기록해 작은 뿌듯함을 주는, Boocap 최지원 디자이너

🧑‍💻 오늘의 메이커 : 한 달을 기록해 작은 뿌듯함을 주는 “Boocap”의 최지원 디자이너

안녕하세요, 스타트업에서 B2B SaaS 제품 기획부터 UX/UI 디자인까지 전 영역을 주도하고 있는 프로덕트 디자이너 최지원입니다. 최근 급변하는 AI 트렌드 속에서 디자이너로서 진한 포모(FOMO)를 겪기도 했는데요. 마냥 불안해하기보다 시대의 변화를 적극적으로 수용하고 디자이너의 역할을 재정의해보고자 직접 제품 빌딩에 뛰어들었습니다. 평소 '기록과 성장'에 관심이 많았던 경험을 바탕으로, AI 코딩 툴을 활용해 독서 기록 시각화 서비스인 'Boocap'을 기획부터 디자인, 배포까지 1인 빌드하여 운영하고 있습니다.

오늘 팁스터와 한 달을 온전히 기록했다는 작은 뿌듯함을 주는 “Boocap”에 대해 함께 이야기할 수 있어서 기쁩니다. 포스터 한 장이지만, 그 안에는 "내가 이번 달 이만큼 읽었구나"를 돌아보는 시간이 담겨 있어요. 기록이 부담이 아니라, 돌아볼 때 기분 좋은 의식이 되었으면 해요.

레시피 하나, 프로젝트의 시작

Q. 시작에 앞서 Boocap을 처음 만들게 된 계기는 무엇이었나요?

제가 한 달에 책을 5~7권 정도 읽는 편이에요. 그러다 보니 매달 "이번 달엔 뭘 읽었지" 하고 돌아보는 게 자연스러운 습관이 됐는데, 막상 그 기록을 다양하게 표현해보려니 방법이 너무 제한적이더라고요. 독서 앱 화면을 캡쳐하거나, 실물책을 모아놓고 사진을 찍는 정도였어요. 분명 "내가 읽은 책"이라는 건 나만의 데이터인데, 그걸 보여주는 방식은 늘 비슷했어요. 그래서 이 데이터를 좀 더 다양하고 멋진 형태로 표현할 수 있는 방법이 있으면 좋겠다는 생각에서, 제가 쓰고 싶은 도구를 직접 만들게 됐어요.

에디터 : 그렇다면 Boocap은 좀더 다양하고 멋진 형태의 기록을 위해 시작된 프로젝트겠네요?

네, 맞아요. 프로젝트를 시작하기 전에 기존 독서 앱들은 표현의 방식이 너무 단조롭다고 생각했어요. 사실 책 한 권에는 정말 많은 정보가 담겨 있잖아요. 언제 읽었는지(날짜), 누가 썼는지(작가), 한 달에 몇 권을 읽었는지(권 수), 책 표지의 색깔, 그리고 심지어 책의 두께까지. 이런 특성들을 조합하면 표현할 수 있는 방식이 무궁무진하다고 생각했는데, 정작 우리가 쓰는 방법은 캡쳐 한 장에 멈춰 있었어요. 풍부한 데이터를 너무 납작하게만 보여주고 있다는 게 아쉬웠어요.

출처 : 메이커 직접 제공

Q. Boocap이라는 네이밍에 담긴 의미도 궁금해요.

boocap은 'Book + Recap'이에요. '책(Book)으로 한 달을 돌아본다(Recap)'는 의미를 한 단어에 담고 싶었어요. 발음했을 때 짧고 동글동글해서 부르기 쉬운 점도 마음에 들어서 고르게 되었습니다.

에디터 : 동글동글한 Boocap이라는 이름과 함께 사용자들에게 전달하고자 하는 대표적인 메세지가 따로 있을까요?

우선 Boocap은 다양하게 표현하고 싶은 마음과, 매번 직접 만들기엔 너무 귀찮다는 마음 사이의 간극을 메우는 거였어요. 솔직히 저도 매달 포스터를 직접 디자인할 만큼 리소스를 쏟고 싶진 않거든요. 다양한 표현은 원하지만 거기에 들이는 수고는 최소화 하고 싶었어요. 그 모순을 도구로 풀고 싶었어고요. 책이 가진 특성들을 가지고 다양한 결과물을 만들되, 사용자는 "이번 달 뭘 읽었지"만 떠올리면 나머지는 boocap이 알아서 멋지게 만들어주는 거죠.

레시피 둘, 문제를 제품으로 바꾸는 과정

Q. 본격적으로 Boocap이 기존 서비스들과 비교했을 때, 가장 다르게 풀고자 한 지점은 무엇인가요?

저는 Boocap을 일종의 데이터 시각화 툴이라고 생각해요. 그게 기존 서비스들과 가장 다른 지점이에요. 대부분의 독서 서비스는 ‘기록과 관리’에 초점이 있어요. 별점, 리뷰, 책장 정리 같은 것들이요. 그런데 저는 그렇게 쌓인 독서 기록을 하나의 데이터로 보고, 그 데이터를 어떻게 아름답게 시각화할 것인가에 집중했어요. 날짜, 작가, 권수, 책의 두께 같은 책의 속성들이 결국 시각화의 재료인 거죠. 그래서 Boocap은 관리 도구가 아니라, 내 독서 데이터를 한 장의 시각적 결과물로 바꿔주는 도구예요. 흔히 데이터 시각화라고 하면 차트나 그래프처럼 딱딱한 걸 떠올리는데, 그걸 누구나 자랑하고 싶은 감각적인 포스터의 형태로 풀어낸 거라고 보면 돼요.

에디터 : 시각화 툴로서 서비스 초기 가장 중요하게 생각했던 사용자 경험은 어떤 것이 있었나요?

출처 : Boocap 서비스

아무래도 기록하고 회고하는 일이 최대한 가볍고 직관적이어야 한다는 점이었어요. 사실 회고하고 기록한다는 행위 자체가 생각보다 쉬운 일이 아니거든요. 마음먹고 자리에 앉아야 하고, 꾸준히 하기도 어렵고요. 그런데 거기에 도구까지 무겁고 복잡하면, 사람들은 "이번엔 그냥 넘어가지 뭐" 하게 돼요. 그래서 적어도 도구가 그 부담을 더하지는 말아야 한다고 생각했어요. 달력에 날짜를 누르고 책을 얹는 정도의 단순한 동작으로 끝나도록 한 것도 그래서예요. 실제로 "사용법이 직관적이라 쓰기 쉽다"는 피드백을 받았을 때, 제가 제일 추구했던 부분이 닿은 것 같아 기뻤어요.

반대로 기능을 늘려서 ’독서 관리 앱’이 되지 않겠다는 마음도 있었어요. 리뷰 작성, 별점, 통계, 소셜 기능 같은 걸 붙이면 그럴듯해 보이지만, 그건 이미 잘하는 서비스가 많고 Boocap의 핵심도 흐려진다고 생각했어요. 그래서 ‘입력은 최소로, 결과물은 멋지게’ 이 원칙을 기준으로 사용자 경험을 설계했습니다.

Q. 스스로 정한 제품 설계의 원칙을 지키는게 쉽지는 않았을 것 같아요.

맞아요. 사실 이런 원칙을 도출하기까지는 꽤 오래 고민했어요. "기록을 계속 쌓아두고 싶은데 왜 날아가느냐"는 사용자 피드백이 꽤 있었거든요. 저도 한 달이 아니라 더 긴 시간을 시각화하면 그것대로 좋은 자산이 되겠다는 생각에는 동의하고요. 기록을 차곡차곡 저장해주는 방향은 분명 매력적인 유혹이었어요. 그런데 거기까지 가면 결국 또 하나의 ‘관리 서비스’가 되는 거더라고요. 그래서 일단 시작은 작은 것 하나에 날카롭게 집중하자고 마음먹었어요. ‘한 달의 독서를 한 장으로’처럼 이 한 가지를 제대로 하는 게 먼저라고 생각했어요. 연간 리캡 같은 더 긴 호흡의 시각화는 이 작은 핵심이 단단해진 다음에 가도 늦지 않다고 생각했어요.

에디터 : 사실 내가 원하는 기능을 만드는 순간에도 덧붙이고 싶은 욕구라는 것이 샘솓기 마련이잖아요. 그럼에도 불구하고 초기 원칙을 잘 지킬 수 있었던 계기가 있으신가요?

특별한 한 가지 계기라기보다는, 실무를 하면서 몸으로 배운 게 많이 반영된 것 같아요. 일을 하다 보면 '이것도 넣고 저것도 넣고' 하면서 기능이 자꾸 많아지다가, 정작 제품이 어디로 가야 하는지 그 방향을 잃어버리는 경우를 종종 보게 되거든요. 그런 경우를 몇 번 겪고 나니, 항상 '지금 가야 할 방향은 어디인지, 우선순위가 어떤지'를 가장 우선적으로 고민하게 됐어요. 그래서 boocap도 처음부터 이것저것 기능을 다양하게 늘리기보다 작게 시작해 천천히 가자는 선택을 하게 된 것 같아요.

그리고 요즘은 워낙 제품이 많은 세상이잖아요. 그 안에서 뾰족하지 않으면 살아남기 어렵다고도 느껴요. 이것저것 다 하는 제품보다, 하나를 확실하게 잘하는 제품이 결국 기억된다고 생각해요. 그래서 더더욱, 욕심을 덜어내고 핵심에 집중하는 쪽을 택하게 됐어요.

레시피 셋, 디자이너가 제품 개발의 A-Z를 경험한다는 것

Q. 제작 과정에서 처음 생각했던 설계와 실제 구현이 충돌한 순간이 있었나요?

가장 어려웠던 건 다양한 케이스의 심미성을 동일한 수준으로 유지하는 일이었어요. 제품 특성상 책이 1권일 때와 10권일 때 같은 템플릿을 적용한다고 가정했을 때, 권수가 적으면 여백이 휑하게 비고, 많으면 책 이미지가 너무 작아지거나 여백이 들쑥날쑥해졌어요. 사람 눈에는 "이건 좀 빈 것 같다", "이건 답답하다"가 바로 보이는데, AI는 모든 경우에서 균질한 미감을 잡아내는 걸 어려워하더라고요. 제품을 만들기 시작하면서 AI가 제 기대 수준 이상을 척척 만들어내는 걸 보면서 점점 기대치가 높아졌었는데, 이때 AI의 한계를 좀 체감했어요.

결론은 두 가지 방법으로 풀었어요. 하나는 "모든 템플릿이 모든 권수를 담는다"는 욕심을 버리고, 각 템플릿이 가장 아름다운 권수 범위 안에서만 동작하도록 제약을 걸었어요. 그리고 다른 하나는, 심미성의 판단만큼은 AI에게 맡기지 않고 제가 직접 경우의 수를 하나하나 보면서 규칙을 잡아간 것이었어요. 결과물의 완성도’를 직접 보면서요.

에디터 : AI의 한계 뿐만 아니라 프로젝트를 진행하며 디자이너로서 낯선 경험들도 많으셨을 것 같아요.

맞아요(웃음). 이번 프로젝트에서 디자이너로서 가장 낯설었던 건 ‘이게 정말 동작하는가’를 끝까지 책임지는 역할이었어요. 디자인만 할 때는 화면이 의도대로 그려지면 제 몫이 끝나고, 제대로 구현될 때까지 기다리는게 일반적이었어요. 하지만 직접 만들 때는 이미지 다운로드가 특정 환경에서 깨지거나, 폰트가 안 불러와지거나 하는 것까지 다 제 문제더라고요. ‘보기 좋은 것’과 ‘끝까지 동작하는 것’ 사이의 거리를 처음으로 온몸으로 느꼈어요.

재밌었던 건 실무에서 일하다 보면, 버그를 발견해서 개발자한테 말하면 "아 그거 방금 고쳤는데" 하는 경우가 종종 있잖아요. 그런데 이번엔 제가 직접 사용자한테 버그 제보를 받으면서, 똑같이 "아 그거 방금 고쳤는데"를 제 입으로 말하고 있더라고요(웃음). 그 순간 '아, 내가 지금 그 반대편에 서 있구나' 싶어서 혼자 너무 웃겼어요. 늘 제보하는 쪽이었는데, 제보를 받고 대응하는 쪽의 입장을 처음으로 경험한 거죠.

Q. 본업에서 디자인을 할 때와, 직접 제품 전체를 만들 때 가장 다르게 느껴진 점은 무엇이었나요?

본업에서는 적어도 큰 제품의 방향은 PM이 결정하는 경우가 많았고, 구현 관련된 것들은 개발자가 담당해주니, 제 전문성은 디자인이라는 하나의 영역에 깊이 집중돼 있었어요. 그런데 혼자 제품 전체를 만들어보니, ‘큰 방향을 정하는 일부터 구현과 운영까지 전부 끌어안는 제너럴리스트가 될 필요가 있겠구나’ 싶더라고요. 무엇을 만들지 정하는 것부터 어떻게 구현하고, 어디서 멈출지까지 전부 제 몫이니까요. 하나의 전문성을 깊게 파는 것과, 제너럴리스트로서 전체를 넓게 끌고 가는 건 완전히 다른 근육이더라고요.

에디터 : ‘다른 근육’이란 말이 굉장히 공감되네요(웃음). 혹시 이렇게 직접 경험한 뒤에 스스로 달라진 점도 있으신가요?

네 있어요(웃음). '잘 알고 난 다음에 시작하자'는 태도를 많이 내려놓게 됐어요. 이번 프로젝트는 저한테 처음 해보는 것 투성이였거든요. AI로 개발을 한다는 것도, 개발 안에서도 이런저런 걸 시도해보는 것도, 제품 전체를 셀프 QA하는 것도 전부 처음이었어요.

사실 저는 원래 찬찬히 가는 걸 좋아하는 편에요. 예전 같으면 "이걸 먼저 공부하고, 그 다음에 실전에서 해봐야지" 하는 식이었을 거예요. 근데 시대가 바뀌면서 요즘은 학습법 자체가 바뀐 느낌이에요. 공부를 먼저 하고 시작하는 게 아니라, 그냥 하면서 배우는 쪽으로요. AI와 같이 부딪혀보는 것 자체가 공부가 되더라고요. 그래서 이제는 "겁먹지 말고 일단 해보자"는 쪽으로 마음이 완전히 바뀌었어요. 모르는 영역 앞에서 멈칫하던 모습이 많이 없어진 것 같아요.

Q. 서비스를 대하는 태도 외에도 “디자인 결과물”이 아니라 “서비스 전체 경험”을 바라보는 관점이 달라진 부분이 있을 것 같아요.

네, 가장 크게 달라진 건 "이 제품을 사람들이 대체 어떻게 알게 되지?"라는 질문 앞에서였어요. 아무리 잘 만들어도, 알리지 못하면 아무도 쓰지 않잖아요. 그게 걱정되기 시작하면서 직접 인스타그램에 릴스도 만들어보고 게시물도 올려보면서 일종의 마케팅을 하고 있더라고요. 예전 같으면 "내 일이 아니다"라고 생각했을 영역인데, 막상 제 제품을 손에 쥐니 그것까지가 제품 경험의 일부로 보였어요.

그러면서 시야가 훨씬 넓어졌어요. 사용자가 이 제품을 처음 발견하고 → 들어와서 → 포스터를 만들어 → SNS에 공유하기까지의 흐름 전체가 다 디자인의 대상이 되더라고요. 아무리 예쁜 템플릿도, 그 여정 어딘가가 막히면 의미가 없으니까요. 디자인이 ‘한 장면’에서 "여정"으로, 그리고 그 여정을 사람들에게 닿게 하는 일까지로 확장된 느낌이에요.

레시피 넷, AI와 함께 만드는 방식

Q. 글에서 ‘뿌리 파일’이라는 표현이 인상적이었어요. 실제로 그 문서에는 어떤 항목들이 들어가 있었나요?

뿌리 파일에는 맥락과 제품 원칙이 있어요. 맥락은 지금까지 AI와 어떤 대화를 나눴고, 그래서 제품이 어떤 방향으로 발전해 왔는지를 한 문서에 쌓아둔 거예요. 그리고 제품 원칙은 Boocap이 무엇인지부터 시작해서, 타겟은 누구인지, 핵심 플로우와 브랜드 키워드처럼 모든 의사결정에 기본이 되어야 할 내용들이에요.

AI는 대화가 길어지거나 새로 시작하면 앞의 맥락을 잊어버리잖아요. 그때마다 처음부터 다시 설명하는 게 너무 비효율적이라, "매번 같은 설명을 반복하지 않아도 되는 구조"를 만들고 싶었어요.

에디터 : 반복 설명을 줄이기 위해 가장 효과적이었던 문서화 방식이나 프롬프트 구조가 있었나요?

제 기준에서는 앞서 이야기한 뿌리 파일 내에 맥락을 최대한 구체적으로 적어두는 것이었어요. 제가 세운 기준은 ‘이 제품에 대해 아무것도 모르는 사람이 이 문서만 봐도 다 이해할 수 있게 적어두자’였어요. 제 머릿속에선 당연한 전제도 AI는 모르니까, 그 당연한 것까지 글로 다 꺼내두는 거죠. 이렇게 해두니 반복 설명이 확 줄었어요.

구체적으로는 "이게 무엇인가"만 적는 게 아니라 "왜 이런가"와 "어떤 느낌이어야 하는가"까지 적는 거예요. 단순히 "미니멀하게"라고 하면 AI마다 해석이 다른데, 감성 키워드("단정한 — 군더더기 없이 정리된")와 철학("복잡한 과정 없이, 데이터를 그 자체로 멋진 결과물로")을 함께 적어두면 판단의 기준이 생기거든요. 기능 요청은 매번 달라도 이 맥락은 고정되어 있으니, 매번 처음부터 설명할 필요가 없었죠.

Q. 디자이너의 감각을 AI가 이해할 수 있는 규칙으로 바꾸는 과정에서 가장 먼저 정리한 기준은 무엇이었나요?

출처 : Boocap 서비스

Boocap은 템플릿 작업이 많았어요. 그러다 보니 시각적인 느낌을 언어로 풀어내는 게 정말 어려웠어요. 머릿속에는 ‘이런 느낌’이 분명히 있는데, 그걸 AI에게 전하려면 말로 옮겨야 하잖아요. 그 과정에서 ‘이런 스타일을 대체 뭐라고 부르지?’ 하고 레퍼런스 이미지를 주면서 디자인 용어를 찾아본 적이 많았어요. 제 안에 감각으로만 있던 걸 정확한 어휘로 바꾸는 작업이었죠.

그래서 가장 먼저 한 건, 감성을 언어로 정의하고 그 반대편까지 적어두는 것이었어요. "단정한"이 무엇인지만 적는 게 아니라 "군더더기 없이 정리된"처럼 손에 잡히는 설명을 붙이는 거죠. 감각은 원래 머릿속에 흐릿하게 있는데, AI와 일하려면 그걸 문장으로 끄집어내야 하더라고요. 그리고 신기하게도, 그 과정이 제 디자인 의도를 저 스스로도 더 또렷하게 만들어줬어요.

에디터 : 그 과정에 AI와의 R&R은 어떤 기준으로 나누셨나요?

생각보다 기준은 단순했어요. "맞고 틀림이 분명한 일"은 AI에게 맡기고, "좋고 나쁨의 판단이 필요한 일"은 제가 가져갔어요. 그래서 개발이나 QA처럼 정답이 있는 영역은 AI가 정말 많이 도와줬어요. 구현하고, 버그 잡고, 반복적인 코드를 쓰는 일은 AI가 저보다 빠르고 정확하니까요.

반대로 심미성이나 감각을 보는 일은 제가 다 가져갔어요. "이 여백이 맞나", "권수가 달라져도 균형이 유지되나", "이 카피가 Boocap답나" 같은 건 결국 제 눈으로 판단해야 했거든요. 앞서 말한, 책이 1권일 때와 10권일 때의 미감을 맞추는 일도 그래서 제가 직접 잡았고요. AI는 그럴듯한 답은 잘 만들지만, 그게 "Boocap다운 답"인지를 가리는 건 끝까지 제 몫이었어요.

Q. 실제 개발 과정에서 가장 어려웠던 문제는 무엇이었나요?

출처 : Boocap 서비스

제품을 만들다 보면 "왜 자꾸 이런 현상이 생기지?" 싶은 순간이 많았어요. 그런데 그걸 AI에게 말로 설명하는 게 참 어려웠어요. 버그나 어떤 현상의 원인을 제가 온전히 이해하지 못하니까요. 디자이너로서 "이게 잘못됐다"는 건 눈에 바로 보이는데, 그게 왜 일어나는지 코드 내부를 다 알지는 못하니, AI에게 전달할 언어가 마땅치 않은 거예요. 현상은 또렷한데 원인은 흐릿한 상태, 그 간극을 메우는 게 가장 어려웠어요.

대표적인 게 화면에서 보이는 것과 다운로드된 이미지가 다른 문제였어요. 이미지로 변환하는 과정에서, 그리드 셀 사이에 머리카락 같은 얇은 선이 생기거나 표지 가장자리에 미세한 라인이 남더라고요. 화면에선 멀쩡한데 내보낸 결과물에만 나타나니, 저는 "여기 이상한 선이 생겼다"까지만 말할 수 있고 원인은 짐작만 할 뿐이었어요. 그래서 제가 관찰한 현상을 최대한 구체적으로 묘사하고, AI와 같이 원인을 좁혀가는 식으로 풀었어요. 픽셀 비율과 렌더링 방식을 여러 번 바꿔본 끝에 결국 단일 렌더링 패스로 정리됐고요. "보이는 것"과 "내보내지는 것"을 일치시키는 그 과정이, 원인을 모른 채 현상만 붙잡고 가야 해서 특히 길고 어려웠어요.

에디터 : 원인이 흐릿한 상태에서 “문제를 설명하는 능력”을 키워나가는 것도 중요했을 것 같아요.

맞아요. 사실 문제를 설명하는 능력은 이 프로젝트 이전에도 혼자 일하는 게 아니다보니 매우 중요했죠. 다만 사람과 일할 때는 조금 다른 데가 있더라고요. 개발자분들과 오랜 기간 합을 맞추다 보면, 어느 순간 눈빛만 봐도 "그거" 하면 서로 딱 아는 시점이 오거든요. 그러면 그 뒤에 있어야 할 많은 설명이 자연스럽게 생략돼요. 굳이 다 말하지 않아도 통하니까요. 그런데 AI는 그게 아니더라고요. 쌓아온 맥락이나 합 같은 게 없으니까, 정말 처음부터 끝까지 다 설명해야 해요. 그래서 '명쾌하게 설명해야 하는 범위'가 훨씬 넓어진 느낌이에요. 예를 들어 그냥 "여백이 어색하다"가 아니라, "책이 1권일 때 위쪽 여백이 과하게 비어서 허전해 보인다, 권수가 적을 때도 균형이 유지되게 해달라"는 식으로, 현상과 조건과 원하는 상태를 다 풀어서 말해야 하는 거죠. 감각이나 눈빛으로 통하던 걸 전부 언어로 옮겨야 하는 환경이, 오히려 제 설명하는 능력을 한 단계 끌어올린 것 같아요.

Q. AI로 구현한 기능이 “된다”에서 “사용자에게 보여줘도 된다”로 넘어가는 기준은 무엇이었나요?

출처 : 샨티 브런치 - '바이브 코딩하며 배운 AI와 함께 일하는 방법 5가지' 중 발췌

가장 고민했던 것은 ‘다운로드한 포스터를 제가 직접 SNS에 올려보고 싶은가’ 였어요. 기능이 동작하는 것과, 그 결과물이 부끄럽지 않게 예쁜 것은 완전히 다른 기준이거든요. 한 장의 이미지로 떨어졌을 때 "이거 자랑하고 싶다"는 느낌이 들어야 사용자에게 내보낼 수 있다고 봤어요. Boocap은 결과물이 곧 제품이라, 이 기준이 특히 엄격했어요.

에디터 : 엄격한 기준으로 서비스를 준비하다보면, QA 과정도 쉽지 않았을 것 같아요.

QA를 제가 일일이 하기엔 품이 너무 많이 들어서, AI에게 테스트 케이스(TC) 작성 자체를 맡겼어요. "이 기능에서 일어날 수 있는 문제 상황을 다 뽑아줘" 하고 시키면, 제가 미처 생각 못 한 엣지 케이스까지 짚어주더라고요. 예를 들어 사용자가 입력을 잘못했을 때, 책 검색이 실패했을 때, 이미지 로딩이 중간에 끊겼을 때 같은 상황들이요. 평소라면 다 써보고 나서야 발견했을 문제들을 미리 목록으로 받을 수 있었어요.

다만 거기서 끝내지 않고, 동작이 깨지지 않는지는 AI가 만든 TC로 훑되, 결과물의 미감은 제가 직접 눈으로 확인했어요. 특히 이미지 다운로드는 권수별 · 템플릿별 · 무드별로 결과가 달라서, 여러 경우를 실제로 내보내 보면서 일일이 확인했고요. ‘기능이 도는지’는 AI와 나누고, ‘보기 좋은지’는 제 몫으로 남긴 거죠.

이 과정에서 코드 로직, 구현 방식, 라이브러리 선택처럼 검증 가능한 영역은 AI 판단을 빠르게 받아들였어요. 반대로 시각적 결과물, 카피 톤, 사용자 흐름처럼 "Boocap다움"이 걸린 부분은 무조건 직접 확인했어요. AI가 "이게 맞다"고 해도, 최종 화면을 제 눈으로 보기 전엔 내보내지 않는다는 원칙이 있었어요.

레시피 다섯, 한 사람의 메이커로서 얻은 변화

Q. 제품을 만들며 가장 크게 성장했다고 느끼는 부분은 무엇인가요?

‘끝까지 만들어 세상에 내놓는 힘’이요. 디자인 시안에서 멈추지 않고, 실제로 배포되고 사람들이 쓰는 데까지 끌고 가본 경험이 처음이었어요. 그 과정에서 평소엔 다른 직군이 맡던 일들 (예를 들면 마케팅 카피를 쓰고, 로고를 만들고, 제품의 톤앤매너를 잡는 일 등…)을 전부 혼자 책임져 봤어요. 디자인 하나만 잘해서는 제품이 굴러가지 않는다는 걸 몸으로 알게 됐어요. 아이디어를 살아있는 제품으로 만드는 전 과정을 한 번 돌려보니, 다음에 뭘 만들든 ‘이건 실제로 가능하다’는 감각이 생겼어요.

그래서인지 뭔가를 만든다는 것에 대한 겁이 없어졌어요. 예전 같으면 "이건 내 영역이 아니야" 하고 멈췄을 일들을, 이제는 일단 해볼 수 있겠다는 마음이 생겼어요. 그 과정에서 AI를 대하는 태도도 좀 바뀐 것 같아요. 처음엔 AI를 그저 시키는 일을 하는 도구로 봤는데, 제가 잘 모르는 영역에서는 오히려 동료처럼 기대게 되더라고요. 마케팅이든 개발이든, 평소 옆자리 동료에게 물어보던 걸 이제 AI와 의논하면서 시야를 넓혔어요. 그러면서 역설적으로, 함께 일하던 동료들의 사고방식이 얼마나 소중했는지도 새삼 깨달았어요.

에디터 : 이번 경험을 통해 AI 시대의 프로덕트 디자이너에게 가장 중요해졌다고 느낀 기초 역량은 무엇이라고 생각하세요?

판단의 기준을 가지고 있는 것이라고 생각해요. AI는 무엇이든 그럴듯하게 만들어주기 때문에, 이제 희소한 건 ‘만드는 능력’보다 ‘이게 좋은지 나쁜지 가려내는 눈’이에요. 무엇을 만들지, 어디서 멈출지, 어떤 결과물이 우리다운지를 판단하는 안목이랄까요, 그 기준이 명확한 사람일수록 AI를 더 잘 쓰더라고요. 감각을 언어화하고 기준으로 세우는 힘이 핵심인 것 같아요.

Q. 디자이너로서 메이커로서 본인 인생의 다음 과제는 무엇이라 생각하시나요?

디자인이라는 전문성을 바탕으로, 제가 볼 수 있는 업무의 범위를 더 넓히는 것을 다음 과제라고 생각하고 있어요. 앞으로든 뒤로든, 어디로 어떻게 넓혀야 할지는 아직 잘 모르겠어요. 아마 하다 보면 감이 오겠죠(웃음). 그런데 "넓혀야 한다"는 확신만큼은 분명해서, 개인적으로 이런저런 시도를 많이 해볼 것 같아요.

당장은 React 공부를 좀 해보려고 해요. 그리고 제품을 계속 만들어보면서, 자꾸 앞을 내다보는 눈을 길러보려고 하고요. 디자인에서 출발했지만 거기에만 머물지 않고, 제품 전체를 보는 시야를 가진 사람으로 넓어지는 것이 제가 가장 당장의 다음 과제라고 생각하는 일이에요.

에디터 : Boocap의 다음 과제, 미션도 궁금해요.

지금 가장 고민하는 건 ‘이걸 어떻게 잘 알릴 것인가’예요. 만드는 것만큼이나 어려운 게 알리는 일이더라고요. 아무리 잘 만들어도 사람들이 모르면 쓰지 않으니까요. 그래서 인스타그램에 릴스나 게시물을 만들어 올려보면서, "Boocap이라는 도구를 어떤 말과 장면으로 보여줘야 사람들에게 와닿을까"를 고민하고 있어요.

그리고 기존의 독서 기록 앱들은 대부분 기록을 차곡차곡 쌓아두는 형태잖아요. 그러다 보니 Boocap처럼 기록을 쌓는 게 아니라 한 달치를 모아 템플릿(포스터)으로 만들어주는 형태를 처음엔 잘 이해하지 못하시는 분들도 계셨어요. ‘그래서 내 기록은 어디에 저장되는 거지?’라는 의문을 갖게 되는 거죠.

사람들에게 익숙한 독서 도구의 문법이 워낙 '기록과 관리'에 맞춰져 있다 보니 그 간극이 있었던 거예요. 그래서 오히려, Boocap이 무엇을 하는 도구인지를 더 분명하게 보여주는 일이 중요하다는 걸 알게 됐어요. ‘데이터 시각화 툴이라는 정체성을 사용자에게 어떻게 직관적으로 전달할 것인가’ 이게 지금 홍보를 고민하는 이유와도 맞닿아 있고요.

Q. 마지막으로, 지금도 새로운 제품을 만들고 있는 다른 디자이너나 메이커들에게 전하고 싶은 이야기가 있다면 들려주세요.

이 프로젝트를 통해 많은 걸 경험하고, 그 덕분에 생각이 바뀐 것도 참 많은데요. 처음엔 'AI한테 시키면 알아서 잘 만들어주겠지'라고 당연하게 생각하고, "예쁘게 만들어줘" 하면 그럴듯한 결과가 나올 줄 알았거든요. 그런데 막상 해보니, 책이 1권일 때와 10권일 때의 심미성을 똑같이 유지하는 것처럼 사람 눈엔 당연한 균형을 AI는 의외로 어려워하더라고요. AI가 만드는 일을 대신해줄수록, 오히려 "무엇이 좋은 결과인지 판단하는 눈"이 더 중요해진다는 걸 알게 됐어요.

반대로 별거 아니라고 생각했던 건 '문서화하는 일'이었어요. 문서 정리쯤이야 쉬운 일이라고 생각했거든요. 그런데 막상 모든 걸 문서로 남기고, 그걸 계속 챙기는 게 은근히 쉽지 않더라고요. AI도 맥락을 누락할 때가 있고요. 그래서 중요한 일은 사전에 꼭꼭 요청으로 남겨두게 됐는데, 이젠 아예 습관이 됐어요. 그렇게 제품의 맥락을 한곳에 정리해둔 문서가 작업 내내 가장 큰 힘이 됐어요. 매번 처음부터 설명하지 않아도 되고, 길을 잃을 때마다 돌아가 기준을 확인할 수 있는 닻 같은 거였거든요. 화려한 기능보다, 잘 정리된 맥락 한 장과 그걸 꾸준히 챙기는 습관이 제품을 끝까지 끌고 가는 힘이라는 걸 배웠어요.

그래서 작게라도, 끝까지 한번 만들어 내놓아 보라고 말하고 싶어요. 저는 코드를 못 쓰는 디자이너인데도 AI와 함께 제품 하나를 끝까지 만들어 세상에 내놨거든요. 이제 "만들 줄 모른다"는 핑계는 거의 사라진 것 같아요. 남은 건 "무엇을, 왜, 어떤 결로 만들 것인가"에 대한 자기만의 답인데, 그건 결국 직접 만들어보면서만 생기더라고요. 그래서 한 번에 큰 걸 완벽하게 만들려고 하기보다, 작게 여러 번 만들어보길 권하고 싶어요. 저도 그렇게 매번 다른 깨달음을 쌓아가는 중이고요. 완성도 높은 기획서 한 장보다, 단 한 명이라도 실제로 써본 작은 제품 하나가 훨씬 많은 걸 가르쳐줘요.

오픈채팅방을 통해 뉴스레터로 다 소개하지 못한 정보를 확인해보세요!