서랍장

포용적 디자인과 윤리, 미션잇 김병수 대표님의 북토크에서 얻은 인사이트 5가지

Drawer — Sun, 5 Jul 2026 17:38:06 +0900

이상서전에서 주최하는 MSV 신간 북토크에 다녀왔다 !

MSV 소셜임팩트 시리즈는,

한 호에 하나의 주제를 기반으로 포용력 있는 디자인을 소개하는 시리즈 서적이다. 이전에 [5호] 시니어 편을 인상깊게 읽어서 MSV 뉴스레터를 구독하고 있었는데 신간 소식과 함께 저자이신 김병수 대표님을 뵐 수 있다고 해서 신청하게 되었다.

결론부터 말하면 이번 북토크에서는 좋았던 점과 아쉬웠던 점이 각각 있었다. 좋았던 점은 물론 작가님을 실제로 뵙고 이번 호를 만들면서 만났던 인터뷰이 이야기를 실감나게 들을 수 있었다는 점이다. 작가님께 평소 궁금했던 점을 물어볼 수 있었다는 것도 큰 메리트였다. 무엇보다 '디자인 윤리' 라던지, '포용력 있는 디자인' 같은 주제에 관심을 가지고 있는 분들을 만날 수 있는 자리여서 반가웠다.

다만, 조금 아쉬웠던 점은 평소 내가 가지고 있던 생각, '포용력 있는 디자인을 지향하면서도 돈을 벌 수 있을까?' 에 대한 궁금증은 아직 해소하지 못했다는 점이다. 작가님께 질문했고, 이 게시물 말미에 어떤 대답을 들을 수 있었는지 적을 예정이지만 궁금증과 의문을 해결하기엔 아직 부족하게 느껴졌다. 그리고 내가 아직 실무 경험이 없다보니 다른 참여자 분들과 활발하게 소통할 수 없었다는 점도 아쉬웠다. 그러면서도 동시에 더 많은 인사이트를 얻고, 관련 분야에서 일하는 분들을 더 많이 만나기 위해 이런 자리가 또 있다면 적극적으로 참여해야겠다고 생각했다.

이제부터 내가 북토크를 들으며 기록했던 것들을 하나씩 풀어보도록 하겠다.

1. 보이지 않는 디자인의 중요성

점자블록처럼 눈에 보이는 디자인을 넘어, ADHD나 공황장애처럼 심리적 부담을 가진 사람을 위한 '보이지 않는 디자인'이 왜 필요한지 에어비앤비와 비행기 좌석 사례로 정리해본다.

MSV 1~6호까지는 물리적 디자인에 집중했다면, 7호부터는 보이지 않는 영역의 디자인도 중요하다는 걸 알게 되셨다고 작가님은 말씀하셨다. 물리적인 디자인은 말 그대로 우리 눈에 보이는 디자인으로, 시각장애인을 위한 점자블록이나 청각장애인을 위해 박물관 등의 공공 시설에서 마련해둔 수화 서비스 등을 예로 들 수 있다. 반면, 보이지 않는 디자인은 ADHD나 공황장애 등 심리적 부담감을 가지고 있는 사람들을 위한 디자인을 의미한다.

그 예로, 판데믹 시절 의료진에게 숙박시설을 제공한 에어비앤비의 예시를 들어주셨다. 당시 환자의 생명을 살리기 위해 매순간 최선의 결정을 해야했던 의료진들은 평소에도 선택해야 한다는 압박감에 시달리고 있었을 테다. 그런 이들에게 잠시 쉬어갈 숙박 시설을 고를 때에도 많은 옵션을 넣어 부담감을 주고싶지 않았던 에어비앤비는 숙소를 예약하는 과정에서 일부 과정을 스킵할 수 있도록 옵션을 마련해두었다고 한다.

그 밖에도 ADHD를 가진 사람의 경우, 비행기 좌석을 찾는 데에도 큰 어려움을 겪는다고 한다. 예를 들어 좌석 번호가 13D라고 했을 때, 해당 숫자와 영문자를 찾기까지 집중하기가 어렵기 때문이라고. 이때 좌석 번호의 크기를 키우는 등의 디자인적 결정이 승객이 겪는 불편함을 해소할 수 있게 되는 것이다.

이처럼 사용자가 서비스를 이용하면서 부담감을 느끼지 않도록 심리적 요인을 조절해줄 수 있는 디자인이 바로 보이지 않는 영역의 디자인이다. MSV 뉴스레터를 읽기 전에는 보이지 않는 영역에도 디자인이 필요하다는 걸 인지하지 못했다. 다만 어렴풋이 '공황장애를 겪고 있는 사람들을 위한 앱 서비스를 만들어보고 싶다' 고 생각했을 뿐. 실제로 그런 앱을 만든 사람도 있고 말이다.

혼자서 공황 장애로 힘들어하는 사람들을 위한 앱을 만들어 수십억원을 버는 비개발자 (feat. 사

언섹시 비즈니스

maily.so

2. 집중력을 보존하는 방법은 사용자에게 선택권을 쥐어주는 것이다

토스·카카오페이의 주식 수익률 노출, 카카오톡 숏폼 강제 노출처럼 기업이 이익을 위해 사용자의 집중력을 흐트러뜨리는 다크패턴 사례를 통해, 선택권을 돌려주는 디자인이 왜 중요한지 짚어본다.

그래서 우리가 흐트러진 집중력을 다시 원래대로 붙잡아두기 위해서는 '선택권'이 필요하다. 그 말은 즉슨, 우리가 지금 집중하지 못하는 건 비단 스스로의 잘못 때문만은 아니라는 거다. 우리를 둘러싼 많은 온라인 서비스들은 우리의 집중력을 흐뜨러트리기 위해 고군분투한다. 왜냐하면 그 길이 기업의 수익을 창출하는 방법이기 때문이다.

이전에 읽은 작가님의 책 '모두를 위한 디자인은' 에서 나왔던 토스의 예시를 북토크에서 다시 한 번 들을 수 있었다. 토스에서 송금을 누를 때 화면에 주식의 수익 변동률을 함께 게시해두어서 의도치 않게 주식의 증감률에 더 신경쓰게 되었다는 작가님의 개인적인 경험에서 비롯된 예시였다. 이 UI 변화로 인해 평상시에도 주식을 더 신경쓰게 되었다는 말씀을 들려주셨다.

이처럼 때로는 사용자가 원하지 않는 기능이라도 기업의 이익을 위해 추가되기도 한다. 작가님은 수익 변동률을 보지 않기 위해 직접 토스 고객센터에 전화까지 걸었지만, 따로 해당 정보를 숨기는 기능은 개발되지 않았다는 게 기업의 입장이었다고 한다. 예시 화면을 찾기 위해 토스에 들어가봤으나 내가 토스에서 주식 투자를 하고있지 않다보니 증감률을 따로 확인하기 어려웠다. 그래서 혹시나 하고 카카오페이에 들어가봤더니 아래와 같이 송금 기능이 있는 화면에 주식의 수익률 변동 추이가 함께 게시되어 있는 걸 확인할 수 있었다.

또 다른 예시로는 모두가 공감할 '카카오톡 숏폼 강제시청' 문제가 있다. 카카오톡 앱의 바텀네비 중앙에 위치한 '오픈채팅' 을 탭했을 때, 첫 화면에는 무조건 숏폼이 등장한다는 점이다. 이 UX는 나도 크게 화가났던 부분이어서 공감했다. 나는 카카오톡에서까지 숏폼을 보고싶지 않고, 아직 SNS 기능을 도입한지 얼마 안 되어서 그런지 유독 카톡 숏폼에는 퀄리티가 떨어지는 콘텐츠가 많이 등장하곤 한다. 물론 오픈채팅 탭을 더블탭하면 빠르게 넘어갈 수 있지만, 그 잠깐 숏폼에 노출되는 것과 켜자마자 숏폼을 봐야한다는 사실 때문에 앱에 대한 이미지가 많이 나빠졌다. 그럼에도 불구하고 여전히 많은 사람들이 카톡을 사용하고 있기에 아예 해당 서비스를 벗어날 수도 없는 노릇이었다.

이러한 경우 기업은 '어차피 사용자들은 우리 앱을 쓸 수밖에 없다'는 마인드를 가지게 되고 (당사의 오피셜과 무관한, 지극히 저의 주관적인 생각입니다.) 사용자는 더더욱 앱을 편안하게 사용할 권리를 잃어버리게 된다.

위 예시들을 들으면서 전에 했던 '틱톡 리디자인 프로젝트' 가 떠올랐다. 다크 패턴이 많았던 틱톡 앱에서 사용자들이 의도치 않게 긴 시간동안 머물게 만드는 요소들을 최대한 배제하고, 그들에게 선택권을 쥐어주자는 게 우리 팀의 목표였다. 그래서 사용자들이 원치 않는 영상을 바로 넘길 수 있도록 스와이프 기능을 추가했고, 앱 이용 시간을 스스로 정할 수 있도록 스크린타임 기능에 접근하는 뎁스를 줄여주었다. 또, 스스로 정한 시간이 지났을 때에는 가차없이 앱을 강제종료시키는 아이디어도 냈다.

[UXUI] 부트캠프 리디자인 프로젝트 회고

플젝 시작한지 얼마 안 된 것 같은데 벌써 끝나버렸다 ... 2월 2일부터 시작했고 3월 6일에 끝났으니까 한 달 하고도 4일간 진행했던, 부트캠프 마지막 프로젝트가 끝났다. 지난 겨울이 어떻게 지

drawerrer.tistory.com

아이디어는 좋았으나... 프로젝트가 끝날 때까지 해결하지 못한 고민은 이런 것이었다. 사용자의 집중력을 보존하고 선택권을 쥐어주는 일이 기업의 이익과 상충되는 건 아닐까? 이 내용은 다음 문단에서 계속 이야기해보도록 하겠다.

3. 영리를 추구하는 기업에서 디자인 윤리를 추구하는 게 가능한가?

'디자인 윤리를 추구하면 돈 못 버는 디자이너가 되지 않을까'라는 고민에 김병수 대표님이 건넨 답변과, LG·배민 등 실제 기업이 접근성을 개선하고 있는 사례를 정리했다.

내가 작가님께 했던 첫 번째 질문이었다. 사회적 가치를 추구하는 기업이 아닌, 일반 기업에 취업하려고 했을 때 포트폴리오에 '디자인 윤리'를 추구하는 내용을 넣어도 괜찮을지 의문이었다. 위에 말했던 것처럼 사용자에게 선택권을 쥐어주는 일은 곧 기업의 이익과 상충되는 일이기 때문이다.

틱톡의 예를 다시 들자면, 사용자가 보기 싫은 콘텐츠를 빠르게 넘겨버리고 원할 때면 언제든 앱에서 탈출할 수 있게 만드는 건 '체류 시간'과 직접적인 관련이 있다. 사용자가 최대한 앱에서 머물러야 틱톡은 광고비용 등의 이익을 얻을 수 있기 때문이다. 사용자에게 선택권을 주었을 때 직격탄을 맞을 지표는 바로 이 체류 시간이 될 게 분명했다. 이런 경우에도 개인 디자이너가 디자인 윤리를 추구하며 기업의 이익에 배반하는 아이디어를 내게 된다면 스스로를 '돈 못 버는 디자이너'로 낙인찍게 될 것 같아 걱정되었다.

작가님은 이러한 내 질문에 '그래도 기업 입장에서는 다들 똑같은 생각을 하는 디자이너들 속에서 이런 문제의식을 느끼는 지원자가 있다면 오히려 좋게 보지 않을까요?' 라고 대답해주셨다. 내가 해온 고민이 무의미하지 않다는 걸 인정받아서 좋았으나, 여전히 실무자가 이런 지원자에 대해서 어떻게 생각할지에 대한 궁금증은 풀리지 않았다. 아니면 그저 내가 걱정이 많은 타입이어서 남들이 다 괜찮다고 하는데도 고민하고 있는 걸 수도 있다...

그치만 요즘 대기업에서 점점 서비스를 기획하고 디자인하는 데 있어서 윤리적 인식을 갖추는 추세라, 작가님 말씀을 믿고 이 가치관을 쭉 가져가도 괜찮을 것 같기도 하다. LG에서는 가전 접근성을 높이기 위해 노력하고 있고, 배민에서도 시각장애인들이 앱을 더 편하게 사용할 수 있는 방법을 모색하기 위해 미션잇(김병수 대표님의 회사)에 컨택해왔다고 한다.

LG전자, 포브스 ‘접근성 혁신’ 선정… “모두를 위한 디자인 적용”

LG전자, 포브스 접근성 혁신 선정 모두를 위한 디자인 적용

biz.chosun.com

사회문제 해결을 위한 디자인&콘텐츠 기업 미션잇

인클루시브 디자인 소셜벤처 미션잇, 최근 소개된 뉴스 및 보도자료 소개, 진행 예정인 교육 및 포럼 안내

missionit.co

이러한 대기업들의 노력에 이어, 중소기업들 그리고 소비자들 또한 디자인 윤리가 중요하다는 인식을 가지게 된다면 비로소 사회 전체가 변할 거라고 기대해볼 수 있다. 지금 우리는 일반적인 디자인과 포용적인 디자인을 별개의 문제로 두고 바라보는 경향이 있는데, 실은 이 두 분야는 하나의 범위 안에서 다루어져야 하는 게 맞다. 그치만 아직 디자인이 포용적이어야 한다는 인식이 일반적이지 않기 때문에 별개로 다루어지고 있는 거다. 그렇기 때문에 사회적 영향력이 큰 기업들이 적극적으로 서비스의 접근성 측면을 개선하려는 노력을 해야한다고 생각한다.

개인의 측면에서는 이 문제를 해결할 수 없다는 건 아니다. 요즘 SNS에서 장애인 크리에이터 분들이 일상생활에서 불편한 점을 말하는 콘텐츠를 여럿 본 적이 있다. 그걸 보면서 전에는 갖지 못했던 시각으로 일상을 바라볼 수 있게 됐다. 이렇게 콘텐츠를 통해 비장애인이 경험하지 못했던 일들에 공감하고 이해할 수 있게 되었듯이, 개개인이 포용적 디자인의 필요성을 계속해서 주장한다면 훗날 사회의 인식 또한 달라지게 될 거라고 믿는다.

4. 장애는 해결해야 할 문제가 아니다

장애를 '해결해야 할 문제'가 아닌 '이해하고 고려해야 할 요소'로 바라봐야 한다는 관점과, 그 시선이 프로덕트 디자이너에게 왜 중요한지를 담았다.

진행자님이 작가님께 뉴스레터를 발행하거나 책을 편집할 때 염두에 두는 요소는 무엇인지 여쭤보셨다. 작가님은 '장애가 불편하고, 문제이며, 해결해야 한다'는 표현을 지양한다고 하셨다. 가끔 장애인 분들의 이야기를 들으러 가면, 그분들이 먼저 '문제가 맞지' 하기도 하신다고. 그치만 직접 경험해보지 않은 사람들이 이를 부정적으로 바라보는 건 또 다른 문제인 듯 하다.

영화 <세계의 주인> 에서도 비슷한 메시지가 등장한다. 성범죄 피해자의 삶은 피폐해졌고, 일상을 평범하게 살아가기 어려우며, 모든 행복감을 느낄 수 없는 것처럼 묘사되는 데 주인공은 강하게 반대한다. 그의 서사를 통해 아픔을 느낀 이들이라도 얼마든지 행복해질 수 있다는 메시지를 얻을 수 있었다. 또한 성범죄 피해자들을 연민의 시선으로만 바라봤던 이전의 내 모습을 반성하기도 했다.

그렇다면 프로덕트 디자이너로서 이들의 아픔과 장애를 어떤 시선으로 바라보아야 하느냐. 장애를 해결해야할 문제가 아닌, 이해(고려)해야할 요소로 바라보아야 한다는 게 내 생각이다. 장애를 해결해야할 대상으로 바라보는 순간, 디자이너는 장애인에게 무언가를 '해주어야 하는' 위치에 서게 되고 장애인은 어떠한 도움을 받는 대상으로 전락한다. 하지만 이해해야할 요소로 바라본다면, 장애는 디자인을 하기 위해 고려해야할 지점이 된다. 마치 타겟의 특성에 따라 색상이나 폰트를 다르게 정하는 것처럼 말이다.

여기에서 나아가 장애인을 위한 디자인을 할 때 그들의 시선을 담고 목소리를 들을 수 있다면 더 나은 서비스를 만들 수 있을 것이다. 그들의 불편함을 어림짐작하는 데 그치지 않고 실제 그들의 경험을 들을 줄 알아야 한다. 백문이 불여일견이라는 말이 있듯, 백 번 상상하는 것보다 한 번 제대로 듣는 것이 실질적으로 그들의 불편함을 해소할 수 있는 디자인을 하는 데 도움이 될 것이기 때문이다. 그치만 말은 이렇게 해도 현실은 그들의 목소리를 듣기는 커녕 접점을 만들기가 여간 쉽지많은 않은 일이다. 따라서 장애인과 비장애인이 교류할 수 있는 장이 더 활발하게 마련되면 좋겠다고 생각했다.

5. 포용적 디자인이 필요한 곳은 아직 많이 남아있다

개발도상국을 위한 디자인, 느린 학습자를 위한 콘텐츠 등 앞으로 포용적 디자인이 더 다뤄야 할 영역과 김병수 대표님의 다음 행보를 정리했다.

작가님의 추후 행보는 어떻게 될까. 우선 미션잇 홈페이지에도 나와있듯, 2026년 후반기에는 '개발도상국을 위한 디자인' 프로젝트에 집중하실 예정으로 보인다. 작가님은 평소에도 개발도상국이 겪고 있는 문제들에 관심이 많았다고 하셨다. 저서 '모두를 위한 디자인은' 에서 일부 인터뷰 내용이나 디자인 과정을 엿볼 수 있었기도 하다.

그 밖에도 교육과 관련된 디자인의 필요성에 대해서도 MSV 에서 논할 예정이시라고 한다. 전에 롱블랙 아티클을 읽다가 '느린 학습자'를 위한 책을 만드는 '피치마켓' 대표 함의영 님의 인터뷰를 발견한 적이 있다. 여기서 느린 학습자는 '경계성 지능인' 과 같이, 일반인보다 학습하는 데 시간이 더 필요한 사람들을 일컫는 말이다. 그들을 위해 기존에 출판된 책의 문장을 수정하고, 자간과 행간을 조절하며, 직접 폰트를 개발하는 등의 열정을 쏟으신 대표님의 이야기를 들을 수 있었다. 마찬가지로 김병수 대표님도 장애 아동을 위한 학습 콘텐츠는 어떻게 만들어야 하는지 등의 주제를 해당 호에서 다룰 예정이라고 하셨다.

신간의 키워드인 '집중력' 그 자체 보다는, 포괄적으로 '포용적인 디자인'에 관해 이야기를 나눌 수 있는 시간이어서 더 좋았다. 그리고 늘 그렇듯 나의 사고 범위를 넓힐 수 있는 주제들을 알아갈 수 있게 되어 감사했다. 더 넓은 시야로 세상을 바라보기 위해서는 꾸준히 행동 반경을 넓혀가야 한다는 걸 또 다시 깨닫는다.

마지막으로 공식 사인회까지 마친 이후에 김병수 대표님께 또 한 번 여쭤봤다. 디자인 윤리에 관해 계속해서 공부해나가고 싶은데, 이것이 훗날에도 도움이 될지. 그리고 이 일로 돈을 벌 수 있을지 말이다. 다소 당황스러울 수도 있는 내 질문에 대표님은 "꾸준함이 가장 중요해요" 라고 대답해 주셨다.

MSV 만 해도 그렇다. 미션잇에서 진행하는 프로젝트 중에서 가장 품이 많이 드는 일은 바로 MSV 발행이라고 말씀하셨다. 그럼에도 불구하고 이 일을 계속해서 하는 이유는 사회적 가치가 있는 디자인 인사이트를 보다 많은 사람들에게 알리기 위함이라고 하셨다. 마찬가지로 나도 사회 문제를 해결할 수 있는 디자인을 계속해서 탐구하고, 그걸 다양한 형태의 콘텐츠로 세상에 내보낸다면 언젠간 내가 원하는 목표를 달성할 수 있을 것이라고 조언해 주셨다.

처음 들었을 땐 다소 원론적이고 추상적인 답변이라 실망했으나, 생각해볼수록 지금 단계에서 내가 할 수 있는 일은 꾸준히 공부하고 기록하는 일 밖에 없다는 생각이 들었다. 언젠간 내 글도 누군가의 기획이나 디자인, 혹은 상대방을 이해하는 데 도움이 될 수 있기를 바라면서 말이다.

[work] 비전공자 프로덕트 디자이너의 사수없는 스타트업에서 살아남기

Drawer — Mon, 25 May 2026 23:10:09 +0900

입사하고도 아직 한 달이 채 지나지 않았다. 시간이 빠르면서도 느리다.

나 언제쯤 경력있는 프로덕트 디자이너가 되는 걸까?

이번주는 내내 새로운 프로젝트의 아이데이션을 진행했다.

기획자를 포함해서 대표, 디자이너, 개발자 모두가 함께한 아이데이션이었는데... 업무 분장이 나누어져있지 않았다는 느낌이 들었다. 내가 잘 몰라서 그런건지는 모르겠지만 다소 비효율적이라는 생각이 들었다. 누가봐도 기획 팀원이 해야할 일을 왜 나머지 팀원들이 같이 하고 있는 걸까... 덕분에 지난 금요일에는 11시 넘어서까지 퇴근을 하지 못했다.

집에는 가고싶은데, 한편으로는 이 프로젝트가 잘 되어야만 회사와 내 자리가 지켜진다는 마음 때문에 '에라 모르겠다' 식의 태도를 보일 순 없었다. 그래서 답답한 마음 반, 내 아이디어를 어필하고 싶은 마음 반으로 끝에 가서는 목소리 톤이 살짝 높아졌고 말의 템포도 빨라졌다.

얼마전 팀원 분과의 점심식사 자리에서 나의 MBTI가 무엇인 것처럼 보이느냐는 질문을 한 적이 있다. 난생처음 INTJ 같다는 말을 들었고, 속으로 은근 기분이 좋았다. 일을 하는 데 있어서는 나의 F 성향이 그다지 도움되지 않는 것처럼 느껴졌고, 어떤 피드백을 들어도 상처받지 않기 위해서는 T 성향을 유지하는 게 도움이 될 거라고 생각했기 때문이다. 그래서 이제부터 일할 때 내 추구미는 INTJ 로 정했다 !

지금 가장 고민되는 부분은 앱의 '리텐션'을 올리는 것이다.

아직까지는 우리 서비스 타겟이 왜 이 앱을 써야만 하는지 정의내리지 못했다. 사실 있어도 그만, 없어도 그만인 앱처럼 느껴지기 때문이다. 같은 서비스를 제공하는 타 앱과의 차별점이 없다는 게 큰 문제로 느껴지고, 타겟 사용자들이 우리가 만들 앱이 없어도 문제를 인식하지 못할 거라는 생각이 든다. 프로젝트의 방향성이 아직 완전히 고착된 것은 아니다. 아이데이션을 통해 3개 정도의 컨셉을 도출했고, 개발자 분들이 각각 1개의 컨셉을 맡아 개발해오기로 했다. 솔직히 말하면 내 아이디어가 제일 참신하다고 생각했는데, 나는 일단 개발자가 아니고 차주까지 완성해야할 키 비주얼이 있어 개발에 참여하지 못할 것 같다. 주말동안 바이브코딩으로 대략적으로라도 만들어가서 보여줄까 생각해보기도 했는데 일단 맡은 일이나 잘하자... 하고 디자인 레퍼런스를 찾고, 클로드로 1차 기획을 한 뒤 스티치로 디자인을 땄고, 피그마메이크로 1차 개발을 끝냈다. 제발 야근 안 할 수 있기를...

대행사에서 근무할 때도 소비자의 리텐션을 끌어오는 데 고민이 많았다. 아무리 발버둥쳐도 나는 브랜드 소속이 아닌 대행사 직원이었기 때문에 '상세페이지를 고쳐주세요', '부정리뷰를 없애주세요' 같은 소극적인 요청만 넣을 수 밖에 없었다. 물론 광고 콘텐츠로 다른 브랜드와 차별화를 둘 수도 있지만, 당시 고객사는 광고소재 기획안까지 직접 작성해서 넘겨준터라 어떻게 손 써볼 도리가 없었다. 퍼포먼스는 올리고 싶었으나 뾰족한 방법이 없던 그때의 감정이 다시 밀려왔다. 그치만 지금은 그때와는 상황이 다르다고 생각한다.

일단 프로덕트 개발 전이니 내가 원하는 기능을 넣을 수 있다는 점. 그리고 타당한 근거를 적극적으로 제시하면 내 의견이 프로덕트에 적용될 확률이 거의 80%에 가깝다는 것. 그러니까 리텐션을 올릴 수 있는 방안만 찾으면 내가 원하는대로 서비스를 좌지우지할 수 있다는 게 그때와는 다른 점이자 더 좋은 상황이라고 할 수 있다.

아마 지금 리텐션을 올릴 방안을 생각해낸다고 해도 실제 사용자에게 테스트해보기 전까지는 가설에 불과할 뿐이다. 그러므로 리텐션에 관한 생각은 결코 단기적인 실행에 머무르지 않을 것이다. 사용자 리텐션을 어떻게든 끌어올려서 나의 실력과 성장가능성을 증명해보이고 싶다.

[work] 10일차 프로덕트 디자이너의 일기

Drawer — Sun, 17 May 2026 22:57:10 +0900

출처: 멋쟁이사자처럼 UXUI 디자인 7기

멋쟁이사자처럼 UXUI 디자인 부트캠프를 5개월동안 수강하고, 1개월의 취준 끝에 스타트업의 프로덕트 디자이너로 취업했다 !

내가 지금 일하고 있는 곳은 '멘탈 헬스케어' 도메인의, 자사 서비스를 보유한 스타트업이다. 타겟은 B2B2C. 도메인이 도메인인 만큼 B2B를 주 타겟으로 바라보고 있다. 내 포지션은 프로덕트 디자이너고, 자사 서비스의 리뉴얼 디자인을 준비 중이다.

오리엔테이션 때 대표님이 정의해주신 내 역할은 이렇다. 기획자와 개발자 사이의 브릿지 역할. 우리 팀의 기획자 분은 심리상담 분야에서 10년 이상의 경력을 쌓으신 분이고, 이분께서 기획해주신 바를 IT 적으로 제작 가능하게 디자인해서 개발자 분들께 전달하는 게 나의 임무다. 개발자는 총 3분으로, IOS / Android / CTO 로 나뉜다.

입사를 결심하게 된 계기

도메인의 영향이 컸다. 그냥 헬스케어였다면 고민해봤을텐데, '멘탈' 헬스케어였기 때문에 이 회사에 끌렸다. 정신 건강에 대해서는 쥐뿔도 모르지만 인간의 정신을 다루는 분야는 언제나 나의 관심 범위 안에 있었다. 전공 시간에 프로이트의 '정신분석학'을 배우면서부터였나? 사회를 살면서 자아가 항상 억압된 상태로 존재한다는 대목을 듣다가 눈물이 핑 돌았을 때부터일지도 모른다.

그리고 무조건 이번에는 인하우스로 가고 싶었다. 광고대행사에서 일하면서 암묵적인 을의 위치에 있는게 싫었다. 그리고 내가 죽어라 야근해서 성과 올려놔도 그 덕을 다 다른 회사가 본다는 게 힘이 빠졌다. 어차피 내가 건들 수 있는 건 광고 대시보드 하나인데, 영향력을 크게 발휘할 수 없어 답답했다. 데이터 요청해서 받아보는 데에만도 몇 시간, 길게는 며칠이 걸렸다. 이러저러한 한계들 때문에 난 이번엔 꼭 인하우스로 가리라 마음먹었다.

앞선 두 조건에는 만족하는 회사에 왔지만 이제부터 말할 두 조건에는 부합하지 않는다. 회사의 규모와 사수의 여부였다.

규모있는 회사에 가려고 했던 건 사실 부모님의 영향이 컸다. 사회 초년생 시절부터 큰 회사에서만 일했던 부모님은 내가 스타트업에 간다고 하면 걱정부터 하신다. 물론 안정성이라든지, 연봉이라든지 하는 것들이 보장되지 않는 건 사실이다. '노조가 있는 회사에 가야 꼬박꼬박 연봉이 해마다 오른다'는 말을 귀에 딱지가 앉도록 들었다. 그치만 원래 하던 업에서도 대기업 땅을 못 밟아봤는데, 처음 입성한 분야에서 어떻게 처음부터 그런 곳을 가겠어요... 삼성 자회사의 광고회사에 서류가 붙었을 때까지만 해도 사원증 걸고 일해보는 줄 알았는데 다시 스타트업에 입사했다. 그치만 나는 이 업계만의 자유로움도 좋다. 그리고 어쩌면 작고 애자일하게 일하는 곳이 나에게 더 맞을지도.

사수가 있으면 좋겠다고 생각한 건 단순히 디자인 실무가 처음이라서다. 체계 없는 곳에서 0부터 쌓아올리는 것도 싫지만은 않지만, 직전 회사에서 사수님들 덕을 톡톡히 봤기 때문에 이번에도 자연스레 그랬으면 좋겠다고 생각한 거다. 사수는 없지만 자문을 구할 팀원 분이 계시기 때문에 이정도면 됐다 싶다.

요약하자면, 멘탈 헬스케어 도메인이 좋아서 이 회사에 오기로 결심했다는 거다. 사실 디자인만 하면 어느 도메인이든 상관 없다고 생각했는데, 확실히 관심 분야에서 일하니까 탐구력과 호기심이 상승해서 일하는 게 덜 피곤하게 느껴진다.

지난 10일동안 한 일

- 기존 서비스 채널별로 화면 뜯어보고, 플로우 작성

- 이해관계자별 유저플로우 작성

이렇게 크게 2개로 나눌 수 있다. 서비스 채널은 총 4개로 어드민 채널 1개를 제외하면 3개 채널을 유저가 사용하게 된다. 왜 이렇게 많냐면, 서비스 특성상 이해관계자가 여럿이 되어 그렇다. 따라서 이해관계자별 유저플로우도 총 3개를 만들어야 했다.

이 일을 했던 이유는 기존 서비스 운영을 종료하고 본격적인 리뉴얼을 시작하기 전에 회고를 진행하기 위해서다. 기획-개발-디자인 팀원이 모두 모여서 이전 서비스는 어떻게 제작되었고, 어떻게 운영되었는지를 다같이 살펴본 다음에 서비스 전략부터 다시 짜기 위함이다. 그 과정에서 기존 서비스를 보여주는 시각 자료가 필요해서 내가 담당해 제작하게 되었다. (어차피 디자인 팀원이 나 혼자이므로... 내가 해야될 수 밖에 없기도 했고 말이다)

유저플로우는 우리 서비스를 둘러싼 이해관계자들이 어떤 흐름으로 일련의 과정을 겪고있는지를 알아보기 위함이다. 예를 들어 'PT를 받는 회원'의 플로우를 작성한다고 하면, 그 회원이 무엇 때문에 PT를 필요로 했는지부터 최종적으로 PT를 받게되는 과정을 쫙 펼쳐보는 일이다. 그 과정에서 잠재 고객의 페인포인트라던지, 센터 입장에서 매출이 발생하는 구간 등을 파악할 수 있게 된다. 팀원들이 함께 플로우를 보기 위함도 있었지만, 플로우를 작성하고 피드백을 받아 수정하며 느낀 점은 내가 이 서비스를 둘러싼 환경에 대해 더 딥하게 이해하기 위함이라는 걸 알게 됐다.

배운 점

1. 같은 현상이라도 워딩에 따라 다르게 해석된다

플로우를 작성하면서 사용자가 Yes/No의 판단을 할 때, '나는 OO할 것이다' 라는 워딩을 써왔다. 대표님은 '내가 미래에 할 행동을 예측하는 것 같다'며 수정을 요청해주셨다. 결론적으로는 '나는 OO하고싶다' 가 되었다.

여기서 배운 점은 단순히 말을 자연스럽게 고치는 방법이 아니다. 워딩을 수정했을 때 생각의 방향이 다르게 확장될 수 있다는 점이다. 예를 들어, '나는 슈퍼에 갈 것이다' 라는 문장을 접했을 때는 미래에 '예정된' 행동이라는 느낌이 든다. 반면, '나는 슈퍼에 가고싶다' 라는 문장을 접했을 때는 '왜 가고싶지?' 라는 의문이 떠오르게 된다.

대표님께서는 '나는 OO하고싶다' 로 문장을 수정한 다음, '이 사람이 왜 OO를 하고싶을까요?' 라는 질문을 던지셨다. 그에 'ㅁㅁ하기 때문입니다' 라고 내가 대답하자, '그럼 왜 ㅁㅁ하게 된 걸까요?' 라며 3번 정도 질문을 더 반복하셨다. 꼬리에 꼬리를 잇는 질문에 대답하며 나는 사용자의 진짜 심리를 파악하게 됐다.

2. '비즈니스적으로 사고하기' 라는 것

약간 유레카를 외친 순간이었다. 마찬가지로 이해관계자 중 한 그룹의 플로우를 제작하면서 대표님의 피드백을 받고 있을 때였다. 사용자의 결제가 이루어지는 구간에서 '이거 환불 규정이 어떻게 돼요?' 라고 대표님이 물어보셨다. 나는 케이스별로 다를 것 같다고 말씀드렸는데, 뒤이어 하신 말씀은 '매번 10만원씩 결제하는 A와 100만원을 한 번에 결제하는 B는 다르지 않을까요? 내가 사장이라면 B 같은 손님을 절대 놓치고 싶지 않을 것 같은데' 라고 하셨다.

그전까지 대표님이 너무 세세한 것까지 파고드는 것 같다고 생각했는데, 저 말을 듣자마자 '앗!' 하며 어떤 깨달음이 내 머리를 탁 치고 지나갔다. 그 말인 즉슨, B는 이미 '재력'이 검증된 사용자라는 것이다. 물론 A의 경우에도 적지 않은 돈을 지불하고 있기 때문에 놓치지 말아야 할 고객임에는 틀림없지만, 상대적으로 봤을 때 100만원을 한 번에 결제할 수 있는 사람과의 차이는 분명했다.

'결제'라는 같은 행위를 하는 사용자들 간에도 금액이나 방식에 따라서 사업자의 관점에서는 다르게 여겨질 수 있다는 걸 배웠다. 그러면서 '아 이런게 사업자 마인드구나' 하는 걸 알게 됐다. 난 여태까지 '비즈니스적 사고'라 하면, 숫자나 데이터를 읽을 줄 아는 능력이라고 생각했다. 몇 개월이지만 퍼포먼스 마케터로 일했기 때문에 왠만한 데이터는 읽을 줄 안다고 자부했던 나는, 디자인 능력 + 비즈니스적 사고를 모두 요하는 '프로덕트 디자이너'가 되기 위한 자격을 갖추었다고 생각했다. 그런데 실제로 사업을 운영하시는 대표님과 대화했을 때 나의 부족함이 크게 느껴졌다. 동시에 내가 제작한 플로우에 관해 피드백 받고 있는 시간이 단순히 내 작업물을 평가하기 위함이 아니라, 앞으로 함께 비즈니스를 성장시키기 위해 이해관계자를 둘러싼 일련의 과정과 환경들을 이해하며 공부하고 있다는 생각이 들었다.

3. 사용자의 여정에 따라 이탈 원인이 달라진다

정확히 말하자면 사용자가 여정에서 어떤 구간에 있는지에 따라 이탈 원인은 달라진다. 사용자가 어떤 서비스나 제품에 대한 니즈를 느끼는 계기를 '시작'이라 하고, 결과적으로 니즈를 충족시켰을 때를 '끝'이라 해보자. 이때, 사용자가 니즈를 충족하기 위해 밟게되는 일련의 과정 중에서 모종의 이유로 인해 끝에 도달하기를 포기해버리는 순간을 '이탈'이라고 할 수 있다.

예를 들어, 아침으로 밥 대신 먹을 간단한 음식을 사야겠다는 니즈를 느낀 소비자가 최종적으로 도달하게 되는 단계는 간단한 음식을 마트나 편의점, 혹은 대형마트에서 결제한 뒤 다음날 아침에 구매한 제품을 먹게되는 단계이다. 그런데 막상 마트에는 갔으나 원하는 음식이 없어 아무것도 구매하지 못하고 돌아오게 되거나, 제품을 구매하긴 했으나 막상 아침에 먹을 시간이 없어 평소와 같이 아무것도 못 먹게 된다면 목표를 달성하지 못하고 '이탈'하는 것이다.

당연한 말이겠지만 사용자가 서비스에서 이탈하는 순간도 여러가지다. 따라서 이탈하는 원인을 파악해서 개선함으로써 서비스로부터 사용자가 최대한 이탈하지 않도록 막는 게 나의 역할이라고 생각한다. 하지만 분명 이론적으로는 그렇게 생각했으나, 막상 이탈 원인을 분석할 때에는 내 상상에 따라 피상적으로만 사용자의 이탈지점을 파악하고 있더라. 나에게 필요했던 건 사용자에게 완전 '빙의'되어서 그 심리까지 꼼꼼히 파악하는 것이었는데 말이다.

우리 서비스의 특성상 사용자들이 '지속적으로' 어떤 행위를 하도록 유도해야하는 상황이 발생하는데, 이때 사용자들이 지속적으로 해주길 바라는 행위를 '@@마트에서 요거트 구매하기'라고 가정해보자. 요거트를 구매하기 위해 처음 마트에 방문했을 때, 만약 소비자들이 본인이 생각했던 요거트의 가격대와 실제 요거트 가격을 비교할 수 있게 된다. 여기서 발생할 수 있는 첫 번째 이탈 원인은 본인이 생각했던 것보다 실제 요거트 가격이 더 비쌌을 경우다. 반면, 이 단계에서 요거트를 한 4번쯤 구매한 소비자가 다시 마트에 방문했을 때 5번째로 요거트를 구매하지 않고 이탈하게 된다면 원인은 달라진다. 물론 '가격이 비싸기 때문에' 이탈할 수 있다. 하지만 이 '가격'이라는 요인은 첫 번째 구매자가 이탈했을 때와는 소비자에게 분명히 다른 영향을 미쳤을 것이다. 예를 들면, 5번째로 마트에 방문한 구매자에게는 이미 4번이나 요거트를 사먹었으나 5번째로 같은 요거트를 사지 않은 이유는 다른 더 저렴한 요거트를 발견했거나, 요거트가 가격대비 그렇게 맛있거나 건강에 도움이 되지 않는다고 생각할 수 있다.

사용자 플로우를 분석하면서 같아보이는 원인일지라도 사용자가 지나고 있는 구간에 따라 그 원인이 세밀하게 달라질 수 있음을 깨달았다. 앞으로는 좀 더 깊게 사용자에 공감하는 습관을 들여야겠다.

개선할 점

1. 나뿐만 아니라, 다른 팀원이 볼 수 있는 자료에 구어체 쓰지 않기

2. 같은 특성의 요소들이 나열되어 있으면 어느 것이 가장 중요한 것인지 구분하기 어려움 따라서 퍼센트, 볼드처리 또는 화살표로 중요도를 나타내야 한다.

3. 말을 짧게 줄여쓰는 연습이 필요하다.

4. 워딩 고민이 더 필요하다.

[book] 공공디자인 시대: 사회 문제를 해결하는 창조적인 아이디어들

Drawer — Sun, 26 Apr 2026 17:21:26 +0900

서비스 경험 디자인 기사 자격증을 공부하다보니 '공공 디자인'에 관심을 갖게 됐다. 내가 그동안 배웠던 서비스 경험 디자인은 기업의 이익을 높이기 위한 수단으로만 생각했는데, 그 출발점은 사람들의 편의를 향상시키는 데 목적이 있었다는 걸 알게 됐다. 그래서 모든 디자이너들이 사용자 친화적인 관점을 가져야 한다고 당부하는 말이 자격증 기본서 이곳 저곳에 적혀있었다.

사람들을 돕는 일을 하고 싶어 '프로덕트 디자이너'가 되고 싶었다. 누군가에겐 허영심 가득한 말로 들릴 지도 모르겠으나, 문제를 창조적으로 해결하는 프로젝트를 보면 항상 사회 문제를 다루고 있다는 걸 안 순간부터 언젠간 나도 혁신적인 해결방안으로 사회의 작은 문제라도 해결해보고 싶다는 생각이 들었다.

본 책, '공공디자인 시대' 를 읽으면서 우리나라뿐 아니라 세계 각국의 공공디자인 사례를 개괄적으로 훑어볼 수 있어 좋았다. 역시나 창조적인 아이디어들을 많이 발견할 수 있게 되어서 읽으면서도 여러 책장에 포스트잇을 붙여댔다. 그치만 책을 읽으면서 더욱 확실히 느꼈던 점은 내가 공공디자인에 관심을 갖게 된 이유는 단지 '사람들을 돕기 위해서' 라는 선한 생각에서 비롯된 것이 아니라, 그저 창조적인 아이디어에 도파민이 터졌다는 것에 그치지 않았다는 사실이다.

이유야 어떻게 되었든 문제를 해결하는 프레임에 관련해서는 배울 점이 많은 분야가 공공디자인인 것은 확실해 보였다. 그래서 이 책을 기점으로 조금 더 공공디자인에 관심을 가져보려 한다. 그럼 내가 해결하고 싶어하는 문제에 더 가까워질 수 있지 않을까?

1. 사람들이 행복하면 도시의 문제도 해결된다

이처럼 사회 문제에 디자인적 관점으로 접근할 때, 그 디자인은 문제를 해결할 뿐만 아니라 그곳에 사는 사람들에게는 행복과 자랑스러움을 선사한다. (중략) 공공디자인은 '보이는 부분'과 '보이지 않는 부분'으로 나눌 수 있다. (중략) 보이지 않는 부분은 무엇일까? 보이는 부분이 만들어 낼 가치를 포함해, 사람의 행동을 변화시키고 지속 가능한 사회를 만드는 가치들이다. (10-13p, 프롤로그)

디자인을 해야하는 궁극적인 이유. 일상의 문제를 해결한다는 기저에 사람들의 '행복'이 깔려있다. 그곳에 사는 사람들이 행복해진다는 이유만으로도 해결되는 문제들이 많다는 걸 이 책을 통해 알게됐다. 위험 지역으로 인식되었던 동네가 이웃과 교류하는 열린 공간으로 바뀌기도 하고, 몸이 불편한 사람도 언제든 나와 휴식을 취할 수 있는 공간이 되기도 한다. 이처럼 디자인은 사람들의 삶을 바꾸는 데에도 기여한다.

2. 최소한의 개입만으로도 일상을 편리하게 만들 수 있다

"도시 침술이란 어두운 골목을 밝히는 가로등, 특별한 기억을 담은 공원 벤치 같은 작은 요소를 통해 도시 생활을 바람직한 방향으로 이끄는 '최소한의 개입'을 뜻한다. (28p, 1_삶을 바꾸는 디자인)

여기서 내가 꽂힌 표현은 '최소한의 개입'이다. 모든 사람에게 도움을 주어야한다고 생각하면 머리가 복잡해진다. 여러 사람을 고려해야하고, 두 팔 걷어붙이고 나서야할 것 같기 때문이다. 그치만 잘 만든 공공시설 하나가 온 동네 사람들을 도울 수 있다면, 지금 내 눈 앞에 보이는 문제 하나에만 집중하면 된다. 물론 그 시설 하나를 만들기 위해 도시 사람들의 생활을 면밀히 지켜보는 관심이 필요하긴 하지만. 때로는 적극적 개입이 아니라, 최소한의 개입으로도 사람들의 일상을 편리하게 하고 감성을 자극해 본인이 살고있는 동네를 더 애정어린 시선으로 바라볼 수 있게 할 수 있다는 걸 알았다.

3. 더 나은 동네를 만들기 위해서는 당연한 모습에도 의문을 가져야 한다

변화는 법과 제도를 포함해 도시의 모든 현상 유지에 의문을 제기하는 것에서 시작한다. (31p, 1_삶을 바꾸는 디자인)

동네에 오래된 상가 뒷 편에 에어컨 실외기가 불안하게 쌓여있는 걸 본 적이 있다. 하도 오래 전 일이라 지금도 그렇게 되어있는지는 알지 못한다. 언젠가 내가 살고있는 도시의 시장님께 동네에 대한 질문을 할 수 있는 자리가 마련되었을 때, 익명으로 그 장소를 이야기한 적이 있다. 시장님은 질문의 주체를 알고싶어 하셨지만 당시 나는 그 자리에 없었기 때문에 시장님의 답변이 무엇이었을지 알지 못한다. 다만, 높으신 분이 알게 되었으니 뭐라도 해결이 되었겠지 하는 생각으로 지낼 뿐이다.

그 일을 제외하고는 평소에 동네의 시설물에 관해 깊이 생각해보지 않는다. 만약 도시를 이끄는 시의원을 포함해 누구도 동네를 관심있게 지켜보지 않는다면 지금과 같은 쾌적한 모습을 갖추기 어려웠을 거라고 생각한다. 통행을 방해하면서까지 다리를 새로 짓는 공사장 옆을 지나가며, '왜 있는 다리는 또 만드냐'라고 불평을 토로한 적이 있다. 새로운 다리가 생긴 지금은 누구보다도 더 그곳을 자주 건너가는 사람이 됐다.

어떤 일이든지 불편함을 느끼고, 현상에 대한 의문을 가져야 발전할 수 있다. 공공 디자인을 하려면 평범해보이는 일상에도 의문을 던지고, 마치 내 방에 있을 때처럼 시민들이 자주 사용하는 시설을 이용하면서도 감각을 곤두세워 불편함을 탐지해봐야겠다.

4. 도시는 자동차가 차지하기 이전에 시민들을 위한 공간이어야 한다

이처럼 파킹데이는 그동안 우리가 당연하다고 생각했던 자동차 중심의 공간에 새로운 시각을 제공함으로써 도시가 사람 중심의 공간으로 바뀌는 마중물 역할을 하고 있다. (48p, 2_제도 침술 : 낡은 디자인에 질문하기)

당연하다고 생각한 걸 당연하지 않게 받아들이는 것을 좋아한다. 새로운 관점을 터득했을 때 만큼이나 기분이 상쾌한 일은 또 없다. 샌프란시스코에서 비롯된 이 '파킹데이'는 도시의 주인이 다름아닌 '사람'이라는 걸 다시금 깨닫게 해주는 장치다.

보행자 도로를 걷다보면 자동차들이 무자비하게 영역을 침범한 채 세워져 있는 걸 종종 본다. 분명 직선으로 난 보도를 걷고 있는데 자꾸만 곡선으로 돌아가야하는 게 번거롭기도 했다. 도시에 주차 공간이 부족하다는 건 모두가 아는 사실일 테다. 나도 부모님과 서울에 놀러갈 때면 차를 댈 자리를 찾기 위해 적어도 10분은 뺑뺑 돌아야 했기 때문이다. 그런 점에서 도보에 차를 대는 행위를 이해하지 못할 것은 아니었으나, 그렇다고 해서 보행자들의 공간을 침해하는 게 정당화된다는 말은 아니다.

파킹데이는 주차장의 한 공간을 일시적으로 시민들이 쉴 수 있는 공간으로 만드는 캠페인이다. 어떻게 보면 주차장이 들어올 자리는 매장이 들어섰을 수도 있고, 운동 시설이 갖춰졌을 수도 있고, 공원이 생겨났을 수도 있다. 그치만 현재 주차장으로 자리잡으면서 그 공간은 오로지 자동차만을 위한 자리가 됐다. 그동안 도시 곳곳에 세워진 공영주차장 옆을 지나다니면서도 한 번도 이 공간이 새롭게 탄생했을 수 있다는 생각은 해보지 못했기 때문에 캠페인을 시작한 르바 스튜디오Rebar Art and Design Studio(도시 디자인 연구소, 미국)의 시선이 새로웠다.

출처: https://www.myparkingday.org/

5. 가치 소비를 추구하는 사람들이 늘어나는 요즘, 소비자들은 브랜드가 내는 사회적 목소리에 귀를 기울인다

브랜드 액티비즘Brand Activism이란 기업이나 브랜드가 가치 소비를 주도하는 소비자들의 니즈에 발맞춰 정치, 경제, 환경 등의 사회적 이슈에 '하나의 인격체'처럼 목소리를 내고 행동하는 것을 말한다. 즉, 브랜드가 사회적 주체로서 소비자 의식 변화와 사회적 문제에 발맞처 능동적으로 대응하는 것이다. (53p, 3_ESG 침술 : 행동하는 브랜드가 살아남는다)

인플루언서가 구매한 제품에 사람들이 열광하는 이유는 단지 유명한 사람이 썼기 때문이 아니라, 그 사람의 가치에 공감하기 때문이라는 말을 들은 적이 있다. 브랜드도 마찬가지다. 특정 브랜드를 좋아하는 이유도 브랜드가 추구하는 가치에 공감하기 때문이다. 내 최애 브랜드 중 하나는 '이케아'인데, 쇼룸에 갔을 때 누구나 전시된 가구를 보고 본인의 일상을 상상할 수 있게끔 하는 메시지 읽는 걸 좋아하기 때문이다. 그래서 일부러 방에 둘 작은 소품 하나 사는 데도 'IKEA' 라고 적힌 제품을 구매한다. 내가 자주 닿는 공간에 브랜드 상표를 배치하는 것만으로도 나의 공간을 신경쓰고 애정하는 느낌이 들기 때문이다.

이때 브랜드가 추구하는 가치가 비단 고객의 일상이나 겉으로 보여지는 분위기에 그치지 않고, 사회적 이슈와도 관련된다면 고객은 메시지를 더 쉽게 받아들일 수 있다. 어쩌면 받아들이는 걸 넘어서 그 이슈에 함께 관심을 가지고, 문제를 개선하는 데 동참할 수도 있다. 브랜드라는 것은 이처럼 사람들의 의식을 변화시키기고 사회 문제에 대응할 수 있는 힘을 가진다.

6. 문제와 나 사이의 연관성을 찾아야 실마리가 보인다

카카오 100up 프로젝트는 이처럼 사회 문제의 이해관계자 스스로가 질문을 던진다는 점에서 의의가 크다. 그 질문이 사소한 것일지라도 나와 사회 문제 사이에 연결 지점이 있어야 무엇이 문제인지를 정의하는 단계로 나아갈 수 있기 때문이다. (62p, 3_ESG 침술 : 행동하는 브랜드가 살아남는다)

사람들은 본인과 상관없는 일이라면 신경을 쏟기 어렵다. 나 하나 잘 먹고 사는 일도 힘에 부친다. 사회 문제도 마찬가지다. 내가 지금 한국에 사는데, 지구 반대편에서 일어나는 일이 나한테 큰 의미로 다가오기란 쉽지 않다. 카카오 100up 프로젝트는 청년실업, 가정폭력, 고령화 등 사회에 만연한 복잡한 문제들에 관해 시민들이 직접 참여해 문제와 나 사이의 연관성을 질문하고 스스로 솔루션을 발굴해나가는 캠페인이다.

관련성을 찾았을 때와 그렇지 못했을 때 해결책을 도출하는 깊이는 확연히 다를 수 밖에 없을 것이다. 직접 문제의 '이해관계자'가 되어 상황을 진단하고 해결 방안을 찾으러 나섰을 때, 문제에 대한 더 근본적인 정의와 솔루션을 찾아낼 수 있다.

01화 100up 문제정의 툴킷을 소개합니다!

100up 문제정의 툴킷 for Starter | 우리는 종종 무엇이 진짜 문제인지 정의 내리기 전부터 ‘솔루션’을 고민하곤 합니다. 그러나 천재 과학자 아이슈타인에게도 ‘문제정의’는 ‘해결책’보다 훨

brunch.co.kr

7. 사회적 약자의 일상을 상상해볼 필요가 있다

국내 최초로 무장애 통합 놀이터인 '꿈틀꿈틀 놀이터'를 만들었다. 처음 기획 단계에선 약 1년간 장애 아동과 비장애 아동이 놀이터에서 함께 노는 행동을 관찰하는 것부터 시작했다. 그 뒤엔 기존 놀이터와 무장애 놀이터를 구분하지 않는 독일의 놀이터들을 답사했고, 공개 세미나와 워크숍 등을 통해 학부모 의견을 반영하며 무장애 놀이터 디자인의 방향성을 설정했다. (71p, 3_ESG 침술 : 행동하는 브랜드가 살아남는다)

'베리어 프리' 환경을 만들기 위해서는 기존에 존재할 것 같은 메뉴얼을 참고하면 되지 않을까 하고 막연하게 생각했었다. 그런데 그 '메뉴얼'이라는 건 누가 처음으로 만들었을지는 생각해보지 않았다. 2000년대 초반까지 장애 아동이 마음껏 뛰어놀 수 있었던 놀이터는 전국 6만 여 개의 놀이터 중 10곳도 채 안되었다고 한다. 이러한 현상을 목격한 대웅제약에서는 장애 아동의 놀이 경험을 관찰하고, 다른 무장애 놀이터를 답사한 끝에 '꿈틀꿈틀 놀이터'를 만들었다. 그리고 '아름다운 재단'과 연대하여 '무장애 실내놀이터 매뉴얼'을 만들었다.

베리어 프리를 고려하고, 사회적 약자의 일상을 떠올리는 일들은 사회적 문제를 해결한다는 측면에서도 물론 가치가 있지만, 개인의 차원에서도 사회를 바라보는 사고의 지평을 넓혀준다는 데에도 의미가 있다. 내가 공공 디자인에 매력을 느끼는 지점도 그러한 측면인 것 같다는 생각이 들었다.

무장애 실내놀이터 매뉴얼

아름다운재단은 (사)장애물없는생활환경시민연대(이하 무장애연대)와 함께 모든 어린이가 장애 여부와 관계없이 자유롭게 이용할 수 있는 놀이터를 만들기 위한 ‘무장애 실내놀이터 매뉴얼’

beautifulfund.org

8. 산책길에 놓인 운동기구가 범죄를 예방할 수 있다

그 결과 소금길엔 산책 코스와 운동 기구가 놓인 쉼터가 생겼다. 혹시 모를 범죄 현장을 자연 감시하는 역할을 한다. (103p, 6_방지 침술 : 예방하는 도시는 남다르다)

산책 코스와 운동 기구가 놓인다면 자연스럽게 사람들의 발길이 닿을 것이다. 인적 드문 구역을 이런 식으로도 관리할 수 있다는 게 신기했다. 이러한 시민 친화적인 시설들은 CCTV가 설치되어 있다는 걸 알리는 경고판보다 범죄 예방 효과가 훨씬 좋을 것 같다.

9. 공공디자인 프로젝트는 팀원들의 적극적인 참여로 이루어진다

"이 공원에 설치할 소품을 당신의 고향에서 가져올 수 있다면 무엇을 가져오고 싶은가요?" (중략) 팔레스타인에서 실려 온 붉은 흙은 시간이 지나며 원래 있던 토양과 뒤섞였고, 이는 이민자를 덴마크 사회의 이웃으로 동화하는 수페르킬렌 프로젝트의 지향점을 상징적으로 보여 줬다." (중략) 범죄로 인해 공원의 동서로 분리되던 이웃들은 밝은 공원을 중심으로 밤낮 가리지 않고 교류하기 시작했고, 범죄는 자연스레 자취를 감췄다. (106-107p, 6_방지 침술 : 예방하는 도시는 남다르다)

동네의 범죄 문제를 해결하는 데 그치지 않고, 문화와 문화가 서로 동화된다는 걸 상징적으로 보여주기까지 해서 기억에 남았던 프로젝트다. 이민자들의 고향에서 물건을 가져온다는 발상은 기발하지만 사회적 연대를 달성하려는 목표를 가진 프로젝트라면 응당 할 법한 일이라고 생각했다. 그런데 해당 프로젝트를 운영하는 팀원들은 실제로 이민자들과 함께 그들의 나라를 방문해서 직접 물건을 공수해왔다. 만약 가져와야 하는 물건이 덴마크의 운/수송 법에 위반된다면 직접 만들어서 공원에 배치해 두었다.

이 프로젝트를 보면서 공공 디자인을 지향하는 팀원들은 어떠한 사명으로 이토록 열정적으로 활동할 수 있는 것일지 궁금했다. 앞서 말했던 것 처럼 사회 문제와 나 사이의 연관성을 떠올릴 때, 문제 해결에 집중할 수 있다고 했는데. 그들도 이 문제와 연관되어 있기에 이러한 일들을 벌인 것이었을까? 막연하게 더 많은 사람들을 위한 디자인을 추구해야한다는 것만 알고 있는 나로서는 그들의 생각이 무척이나 궁금해지는 대목이었다.

Superkilen | Bjarke Ingels Group

Superkilen is a park conceived as a giant exhibition of urban best practices. The park wedges through the Nørrebro area just north of the Copenhagen city center

big.dk

10. 제약이 새로운 아이디어를 만든다

RO&AD 건축 사무소는 본래부터 다리가 없던 곳에 다리가 생기면 해자의 미관을 해칠 수 있다고 생각했다. 그들은 경관을 유지하고자 멀리서는 보이지 않는 다리를 구상했다. 물길 사이에 놓인 이 다리는 마치 모세의 기적과 닮아 모세의 다리Moses Bridge라고도 불린다. (139p, 8_정서 침술 : 도시에 애정이 깃들 때)

때로는 '제약'으로부터 새로운 아이디어가 떠오르기도 한다. 인공 구조물이 자연 경관을 해치지 않아야 한다는 기준을 가지고 다리를 설계한 RO&AD 건축 사무소. 덕분에 세계적으로 이례적인 디자인이 탄생할 수 있었다. 전에 인스타그램에서 얼핏 봤던 다리인데, 설명 없이 봤을 때는 어떤 예술가 집단이 오로지 예술성을 위해 물길 안으로 다리를 집어넣은 것이라고만 생각했다. 그런데 의미를 알고 나니 구조물의 디자인이 새롭게 보인다.

이러한 시도를 할 수 있었던 건 애초에 도시에 대한 애정이 있었기 때문이라고도 볼 수 있다. 단지 시민들이 건너기 편리한 다리를 만들고자 했다면 '모세의 다리' 같은 혁신적인 디자인이 탄생하지 않았을 것이다. 이 구조물은 표면적으로는 '자연 경관을 해치지 않기 위해서' 이런 형태를 띄고 있다. 하지만 주민들이 사랑하는 동네의 모습을 부자연스럽게 만들지 않으면서도 동네를 기억할 만한 특별한 구조물을 만들어주었다는 점에서 도시에 살고있는 사람들에 대한 애정까지도 엿보이는 프로젝트라고 할 수 있다.

출처: https://divisare.com/projects/183386-ro-ad-architecten-moses-bridge

앱인토스 미니앱 배포하기: 스프레드시트로 관리하는 QA, 샌드박스 앱으로 테스트하기

Drawer — Thu, 23 Apr 2026 02:10:06 +0900

이제 디자인 단계는 얼추 끝나서 테스트를 진행 중이다.

테스트 프로세스

1. 스프레드 시트에 오류 및 수정사항 기록

2. 수정사항 반영

3. 앱인토스 샌드박스 앱 다운하고 로컬서버 연동

4. 폰으로 앱 확인하며 수정사항 계속 캐치

스프레드시트는 아래와 같이 정리했다.

크게 피드백 넘버 | 페이지명 | 반영여부 | 수정사항 | 코멘트 로 구성했다.

- 페이지명은 큰 카테고리 / 페이지명 으로 기재한다.

- 반영여부는 반영됨 | 반영안됨 | 논의필요 로 구성하고, 반영과 논의여부에 따라 상태를 변경한다.

- 수정사항에는 말그대로 고쳐야할 부분, 코멘트에는 수정사항에 대해 덧붙일 말들을 써둔다.

- 피드백 중 이미지 참고가 필요하다면, 두번째 시트에 이미지를 첨부한 뒤, 해당 셀의 링크를 페이지명에 걸어둔다.

원래는 피그마 파일에서 'Annotation' 기능을 활용해, 수정할 부분을 체크해뒀었는데. 페이지가 흩어져있다보니 일일이 확인하기가 번거롭고, 반영했을 때 표시하는 방식이 마땅찮기도 해서 스프레드 시트에 작성하는 방식을 제안했다. 퍼포마로 근무할 때 브랜드 공식몰 런칭을 서포트한 적이 있었는데 선배님들이 이렇게 시트로 개발 수정사항을 정리해서 외주 개발사와 커뮤니케이션하는 걸 보고 기억해뒀던 덕분이다.

앱인토스 샌드박스앱으로 테스트하기

1. 앱인토스 개발자 콘솔에서 '새 앱 만들기' 클릭

2. 앱 정보를 입력한 뒤 제출

(심사까지는 영업일 2일 정도 걸린다고 하는데, 심사 승인되기 전에도 샌드박스 앱에서 테스트할 수 있다!)

3. granite.config.ts 설정 -> 클로드에 요청

(이때, 'appName' 이 본인이 '앱 정보'에 입력한 appName과 동일한지 꼭 확인해야함)

4. PC의 터미널(terminal)에서 서버를 시작하기 위해 아래 코드 입력

cd [클로드와 연동된 파일의 경로 삽입 ex. Users/kildong/Desktop/appintoss]
npm run dev

5. 성공했다면 터미널에 아래 'GRANITE' 라는 문자가 뜨면서 정상 실행

6. 앱인토스 콘솔 앱(샌드박스) 설치 (▼ 아래 사이트에서 다운 가능)

앱인토스 개발자센터

샌드박스앱은 수시로 업데이트돼요. 오류가 보이면 최신 버전으로 업데이트해 주세요.

developers-apps-in-toss.toss.im

7. 콘솔 앱 로그인 후 [설정] 에서 'Metro 서버' 입력

-> Metro 서버 예시: 192.168.00.000

(*만약 클로드가 'http://192.168.00.000' 로 알려줘서 고대로 입력했는데 연결이 안 된다? 'http://' 를 떼고 입력)

*서버 찾는 방법

macOS: 터미널에 아래 코드 입력

ipconfig getifaddr en0

Windows:

설정 → 네트워크 및 인터넷 → Wi-Fi → 속성 → IPv4 주소

8. 휴대폰과 PC는 반드시 같은 WIFI에 연결되어있어야 함 (모바일 핫스팟 가능)

9. URL 입력

-> intoss://[내 앱의 appName]

10. URL 입력 후 '스키마 열기' 를 누르거나, 앱 메인 화면에서 'appName' 을 클릭하면 앱이 열린다!

제가 비전공자이고, 사실 위 프로세스도 클로드 잡도리해가며 겨우 진행한 것이기 때문에 만약 저대로 했는데 안된다? 하면 본인의 클로드를 잡도리해보시길...

여기서 잠깐!

한 번 콘솔앱과 로컬서버를 연동했다고, 다음 번에도 자동으로 연결되지 않는다.

터미널을 열어서 4번의 코드를 입력한 다음에 앱을 실행할 수 있으니 주의!

그리고 샌드박스 앱에서 테스트할 수 있는 기능은 제한적이다. 아래 리스트를 잘 확인해서 앱에 오류가 났다고 오해하지 마시길.

출처: 앱인토스 개발자센터

앱을 켜놓고 클로드에 수정을 요청하면 반영되는 게 바로바로 보여서 신기하다. 핸드폰과 연동하니, PC화면에서 봤던 화면이랑은 또 사뭇 다른 느낌이고 직접 손으로 조작해가며 앱을 사용해보니 수정사항도 더 잘 보인다. 단점이 있다면 수정사항이 너무 잘 보여 일이 또 이따만큼 늘어났다는 것...?

아 그리고 앱인토스에 심사 요청했던 앱정보도 오늘 승인이 났다! 영업일 이틀 내로 심사결과 메일로 알려주신댔는데, 딱 2일차인 오늘 밤에도 메일이 안 와서 날 밝으면 독촉메일(?) 보내려했는데... 밤 10:59에 승인 메일이 도착했다. 대체 토스에선 무슨일이 벌어지고 있나요?

이제 배포가 눈앞이다! 조금만 더 열심히~~...

앱인토스 미니앱 배포하기: 프롬프트, 어디까지 자세하게 적어야하는 거예요?

Drawer — Mon, 6 Apr 2026 00:54:28 +0900

여태까지의 작업 진행 상황...

서비스의 모든 페이지를 디자인하고, 기능명세를 작성했다. 작성한 기능 명세를 클로드에 입력해서 구현하게 만들었고, 현재 디자인은 모두 구현된 상태다. 기능의 경우, 단편적으로는 구현되지만 총제적으로는 아직 구현되지 않는 상태다. 예를 들면, '후기 작성하기' 같은 기능이 있다고 했을 때 버튼을 클릭해서 텍스트 입력까지는 가능하나 입력한 후기가 저장되지는 않는 상태인 것이다.

작업을 수행할 때 이전과 달라진 점은 프롬프트를 입력하는 방식이다.

이전에는 내 회사 동료같은 AI에게 '-해주세요' 라며 존대를 썼으나, 그게 토큰을 낭비하는 행위라는 걸 알게 된 후에는 최대한 프롬프트를 간략하게 작성하려고 노력한다. 'OO요청' 이런식으로 말이다.

그리고 비슷한 작업은 한꺼번에 요청하는 게 토큰을 절약하는 방법이라고 한다. 예를 들어, 기능명세서의 어떤 부분을 확인하고 반영해야하는 작업이 있다고 치자. 프롬프트를 입력할 때, 1) 확인해줘 2) 반영해줘 -> 이렇게 따로 요청하면 불필요하게 토큰이 낭비되는 것이다. 자세히는 알지 못하지만 파일 내부의 코드를 두 번 읽게 되어서 그런 게 아닐까 싶다. 왜냐하면 아까 나도 비슷한.. 바보같은 요청을 하는 바람에 피그마 파일 코드를 두 번 읽게 시켰거든.

여러 개의 작업을 요청할 때는 리스트 형식으로 요청하게 됐다. 줄글로 '이거 해주고, 저거 해준 다음에, 그거 해주세요' 라고 하던 지난 날은 가라! 'OO요청' 이라는 제목을 붙인 다음 소제목은 대괄호'[]' 를 써서 나타내고, 하위 텍스트로 관련 요청사항이나 참고사항들을 나열하게 됐다.

아참, 그리고 스레드하다 알게 된 건데 '하지 말아야할 일' 을 정의하는 것도 중요하다고 한다. 난 여태까지 AI가 나를 위해 해줬으면 하는 일들만 생각하기 바빴는데, 하지 말아야할 일도 정의내려야 엉뚱한 결과물을 얻지 않게 된다는 걸 알고나서 무릎을 탁! 치게됐다.

어찌저찌 디자인 시안을 마련해뒀던 페이지들은 다 구현을 했는데. 디자인한 그대로 개발되지 않은 게 내 고민거리가 되었다. 개발자님 신경 좀 써주세요, 예?

개발 요청할 때 기능명세 하단에 '[해당 페이지 이미지]' 라며, 디자인 시안들을 일일이 태그해줬다. 다만, 태그를 통해 불러온 이미지의 포맷이 'png'여서 디자인의 상세한 스펙을 AI가 알 수 없었던 게 디자인 구현이 그대로 되지 않은 원인이지 않을까 생각했다.

클로드의 MCP를 연동했을 때, 피그마 파일 그대로 디자인을 반영하기 위해서는 어떤 사항들을 고려해야할지 제미나이에게 물어봤다. 이때, 제안해준 여러 프롬프트 중에서 가장 근본적이고 내가 이해하기 쉬웠던 프롬프트를 복사해서 활용했다.

여전히 디자인과 다른 부분들이 있으나.. 톤에 맞지 않게 제멋대로 디자인되었던 부분이 조금 개선된 것처럼 보였다. 이로써 개발자에게 디자인 스펙을 구체적으로 명시하는 것의 중요성을 알게 되었다. (갑자기 학습 톤 ㅋㅋㅋ)

프로세스가 진행될수록 서비스를 구현하는 것 자체는 크게 걱정이 되지 않는데, '이게 과연 사람들에게 필요한 서비스일까?' 라는 걱정이 스멀스멀 올라오기 시작했다.

앱을 배포하기 직전까지 서비스에 관해 구체적으로 말하진 않을 예정이지만, 아이디어 구상 단계에서는 꽤나 수요가 있을 거라고 판단한 서비스였다. 설문조사를 돌렸을 때도 우리가 MVP로 밀고 있는 기능이 탑재된 서비스가 출시되었을 때 사용할 의향이 있는 질문에 68명 중 60명이 '의향 있다'는 답변을 들려주었기도 하고 말이다.

그런데 서비스가 실체화될수록 기존에 존재하는 여타 서비스와 다른 점이 무엇일지가 모호해지는 것이다! MVP 기능들은 기존 앱에 없는 부분이긴 하지만 그것만으로 사용자 유입을 발생시키기에는 약하다고 생각했다.

바이브코딩으로 비전공자도 서비스를 만들기 쉬워지는 요즘, 서비스 구현보다 중요한 건 '사람들이 사용하는 서비스인가?' 인 것 같다. 스레드에서 어떤 분은 본인이 만든 서비스를 본인도 사용하지 않게 된다는 글을 올렸다. 알고리즘의 영향인지, 그런 류의 글을 최근에 많이 접하고 있다. 사실 나부터도 내가 만든 웹사이트를 매일 들어가진 않고 있지 않은가. 나부터 사용하지 않는데 어떻게 사용자를 유입시키며, 그들이 이탈하지 않고 오래오래 써주길 바란다는 말인가.

이런 저런 생각을 할수록 '기획력'이 중요해질 수 밖에 없겠다. 그리고 그 기획의 일부로 나는 우리 서비스의 '아이덴티티'를 정의해보자고 파트너에게 요청해두었다. 우리 서비스가 배포되었을 때 사용자에게 어떤 의미를 갖게 될지를 정하고 싶었다. 일종의 브랜딩이라고도 할 수 있을 것 같다. 사용자에게 가닿는 의미에 따라 많은 의사결정이 달라질 수 있을 것 같은데. 현재까지의 의사결정은 내 마음 속에 있는 서비스의 아이덴티티를 참고해서 진행했다면, 이제는 그걸 파트너 마음 속에 있는 것과 일치시킬 필요가 있겠다고 느꼈다. 팀원들이 한 방향을 바라보고 있는 게 중요하기 때문이다.

상반기 채용 시즌이라 지원서를 쓴다는 핑계를 대고 며칠간 프로젝트에 소홀했다. 그 와중에 파트너까지 개인 일정으로 자리를 비우니 어떤 날은 하루종일 피그마에 들어가지 않기도 했다. 나태해졌던 지난 날들을 반성하며 이번주에는 다시 프로젝트 끌올해서 배포까지 힘내봐야겠다!

앱인토스 미니앱 배포하기: 디발자가 되는 길은 멀고도 험하다...

Drawer — Mon, 30 Mar 2026 12:27:51 +0900

멋쟁이 사자처럼 UXUI 디자인 부트캠프가 지난 수요일로 끝이 났다. 생애 최초로 겨울이 짧게 느껴졌던 이유는, 반은 지구온난화고 반은 프로젝트에 열중해서였을 것이다. 찍먹하길 좋아하는 내가 무언가에 몰입한다는 게 드문 일인데 그걸 가능하게 해준 동료들과 강사님들, 그리고 매니저님들께 감사하다. 그리고 과감히 이 길을 선택해준 과거의 나에게도 감사하다.

부트캠프가 끝났다는 건 그동안 열심히 갈고닦은 포트폴리오와 초보 디자이너로서의 역량을 구직시장에 펼쳐야할 시간이 왔음을 알렸다. 그와 동시에 매일 아침 9시마다 작업을 함께해줄 동료가 없어졌다는 의미기도 했다. 두 번의 프로젝트에 열심히 참여했지만 어딘가 부족해보이는 내 포트폴리오를 보충할 겸, 그동안 배웠던 것들을 까먹지 않기 위해서 사이드프로젝트를 시작했다. 두 번의 프로젝트를 진행하는 동안 가장 믿음직스러웠던 동기와 함께 말이다.

우리는 앱인토스에 미니앱을 배포하기로 했다.

앱인토스라고 하면 아직 뭔지 모르는 분들이 계시던데, 토스 앱 안에 미니앱들을 배포한 '앱인앱' 구조의 플랫폼을 의미한다. 2025년 7월에 정식 출시되었고, 7개월만인 지난 2월에 누적 미니앱 수가 1천개를 돌파했다고 한다.

앱인토스, 토스가 10년 성장 노하우를 모두 공개하는 이유

25년 2월, 토스는 창립 10주년 행사에서 “금융을 넘어 일상 전반의 슈퍼앱이 되겠다”는 새로운 도전장을 내밀었습니다. 동시에 “지난 10년간 검증한 토스의 성장 노하우와 기술 인프라를 파트

toss.im

내가 앱인토스를 처음 접하게 된 건 '두쫀쿠'가 확 유행하던 지난 겨울이었다. 스레드를 하는데 '두쫀쿠 지도'가 그렇게나 인기라는 걸 앱인토스 스레드 담당자님이 어필하시던 글을 읽었을 때였다. 당시에 나는 내 웹사이트를 구축하느라 안티그래비티랑 한창 씨름하고 있었고, 따로 설치하지 않고도 내 앱을 배포할 수 있다는 사실을 알고는 바로 '앱인토스' 스레드를 팔로우했더랬다.

언젠간 나도 앱인토스로 미니앱을 배포하겠다... 고 생각만 하던 차에 동기와 포트폴리오의 부족한 부분에 대해 이야기를 나누다가 우리 둘다 사이드프로젝트에 관심이 있다는 걸 알게됐다. 처음엔 MVP만 만들고 그럴싸하게 패키징할 예정이었으나, 강사님과의 커피챗 때 요즘은 디자이너도 '배포' 경험이 중요하다는 걸 알려주시는 거다. 그 길로 동기에게 앱인토스 배포에 관해 의견을 물었고, 긍정적인 반응을 보여주어서 배포를 염두에 둔 서비스 기획을 시작했다.

처음부터 우리가 디자인부터 개발까지 다 할 생각은 아니었다. 부트캠프 내에서 개발자 코스를 수료한 분들과 컨택을 해서 제 3의 멤버를 영입하려 했으나... 앱인토스 개발자 가이드라인을 보는데 왠지 마음속에서 알 수 없는 근자감이 생기기 시작했다. '이거 내가 할 수 있을 것 같은데?'

한창 앱 화면 디자인을 하고 있을 때, 동기가 개발자인 지인으로부터 듣고 온 이야기를 해주었다. 우리가 원하는 걸 직접 개발하려고 하면 1년이 걸릴지도 모른다는 내용이었다. 헉... 우리가 스케줄상으로 잡아둔 개발 일정은 1주일이 채 안되는 기간이었고. 갑자기 마음이 불안해지기 시작했다. 직접 앱 배포를 해서 디자인부터 개발까지, 프로덕트 기획부터 운영까지 전 과정을 경험해보려는 의도도 있었지만, 뭐든 빨리 눈에 보이는 성과가 나지 않으면 포트폴리오에도 덧붙일 말이 없기 때문에 곤란해지는 거였다. 상반기 채용 시즌 안에 배포하려면 0부터 개발하는 건 절대 무리라고 생각했다.

그래서 클로드를 이용해서 바이브코딩으로 앱을 개발하기로 했다.

컴공인 동생에게 바이브코딩 이야기를 하면 극도로 민감한 반응을 보이곤 했다. 무슨 코드가 쓰여지는지도 모르면서 AI에게 모든걸 맡긴다는 건 무모한 거라고 말이다. 나도 그 말을 백번 이해하지만, 공부하고 난 다음에 코드를 짜기엔 시간이 턱없이 부족했다. 컴퓨터 활용능력 필기를 따는 데에만 2달이 걸린 나다.. 컴퓨터 용어와 친해지기 위해서는 좀 더 많은 시간이 필요할 것 같다고 예상하고, 일단 AI에게 코딩을 맡기기로 했다. 실제로 앱인토스에서도 비전공자 분께서 바이브코딩으로 앱을 출시한 사례도 있고 말이다.

무작정 시도해보려는 도전정신은 좋았으나, 우리는 금세 또 막연함에 직면하고 말았다. 클로드 코드는 뭔지, 코워크와 코드의 차이는 뭔지... 똑같은 '프로 플랜'인데 어디는 19달러, 어디는 17달러. 영어로 쓰여진 웹사이트에서 약 2시간 정도 헤매다가 부과세 포함 22달러를 지불하고 나서야 클로드 코드에 입문하게 되었다.

앱인토스 개발자센터

Are you an LLM? You can read better optimized documentation at /development/llms.md for this page in Markdown format AI가 프로젝트의 문맥을 이해하면 더 정확한 코드와 답변을 제공할 수 있어요. Cursor에서는 문서(URL) 또는

developers-apps-in-toss.toss.im

클로드만 결제하면 끝일줄 알았으나... 앱인토스 개발 정책에 알맞게 앱을 개발하기 위해서는 AI가 가이드문서를 참고해서 코딩할 수 있도록 공식 문서를 등록하는 과정이 필요했다. 위에 업로드해둔 링크에서 1페이지가 조금 넘는 가이드라인을 따라하는 데만 한 시간 정도를 소비하고 나니 어느새 밤이 되어버렸던 기억이 난다. 나와 동기는 기본 세팅을 하는 데에만 진이 빠져서 그 다음 날에는 개발을 쳐다보지도 않고 디자인에 몰두했더랬다.

그럼에도 개발까지 자체적으로 진행하겠다고 마음먹고 나서 얻은 것들도 있다.

1. 디자인 시안 핸드오프를 위해 UI의 각 요소를 더 세심하게 뜯어보기

우리의 세번째 멤버 클로드가 알잘딱깔센하게 개발할 수 있도록 '기능명세서'를 작성하기로 했다. 무턱대고 프롬트를 한줄씩 입력해가거나, 이미지만 달랑 주고 이대로 개발해주라고 말했을 경우에 시간과 토큰이 더 들것 같아서였다. 덕분에 부트캠프에서도 배운 적 없는 기능명세서를 작성하기 시작했다.

크게 Display / Interaction / Rule / Data 라는 5가지 요소로 나누어서 기능명세를 작성했다.
Display - 실제로 구현되길 원하는 화면에 대한 시각적인 요소를 설명한다.

Interacton - 사용자가 UI요소를 탭하는 등의 액션을 취했을 때 앱에서 어떤 상호작용을 하게 되는지에 관해 설명한다.

Rule - 썸네일을 몇 개까지 보여줄지, 바텀시트가 노출되는 조건은 무엇인지 등 어떤 조건에서 어떤 상호작용이 되는지 상세하게 설명한다.
Data - 말 그대로 UI 에 표시할 데이터들은 어떤 것들인지, 어디에서 끌어올지에 관해 설명한다.

물론 실제로 기능명세에 들어가야할 내용은 이것보다 훨씬 많지만 우선 이정도로 각 화면의 명세서를 상세히 정리했다. 1차적으로 디자인한 이미지를 클로드에 입력하고 기능명세 초안을 받아냈다. 그걸 손수 입력하면서 디자인상에서 누락된 부분을 추가하거나, 명세 상에서 의도와 다르게 출력된 값을 정리했다.

부트캠프에서 프로젝트를 할 때는 화면만 만들면 되었기 때문에 기획하는 데 더 집중했다면, 이번에는 개발을 어떻게 할지에 대해 더 고민하게 되었다. 물론 기획도 중요하지만, 개발 단계를 고려하지 않는다면 터무니없는 기능을 넣어서 효과에 비해 공수가 크게 드는 비효율적인 판단을 내리게 될 수도 있겠다는 생각이 들었다. 이와 관련해서 얻은 두 번째 깨달음이 있다.

2. '어떻게 디자인하는 게 개발하기 더 쉬울까?'를 고민하기

디자인 시안을 여러 버전으로 기획하고는 동기에게 물어봤다. '이거랑 이거 둘 중에서 더 나은거 골라주세요'. 그럴 때마다 동기는 어느쪽이 개발하기 더 쉬울지를 고민해서 답을 내려주었다. 이후로는 피드백을 받기 전에 한번 더 생각해보게 되었다. 어떤 방식이 개발 공수가 덜 들 것인가... 물론 나는 개발의 ㄱ 자도 모르기 때문에 어느쪽이 실제로 공수가 덜 들지는 잘 모른다. 일단 클로드에 물어보고 답변을 받은 다음 판단하는 수 밖에.

그리고 개발 난이도를 신경써야하는 또 다른 이유는 한정된 시간에 있다. 앞에서도 언급했듯이 상반기 채용시즌이 끝나기 전에 앱을 배포하고, 운이 좋으면 배포 후 사용자 데이터를 파악해서 UX를 개선해보는 게 나의 목표인데. 개발하기 어려운 기능을 넣었다가는 AI 와 씨름하다 시간이 다 지나버릴 수도 있는 노릇이다. 실제로 지난 밤에 기능명세를 좌르륵 입력하고 클로드에게 개발을 부탁했다가, 토큰 리밋에 걸리는 바람에 심장이 철렁했더랬다. 피그마 메이크에서 한 번 리밋이 걸리면 다음달 1일에나 다시 사용할 수 있다는 메시지를 받기도 했어서, 한 시가 급한 지금 그런 메시지를 받는다면 굉장히 큰 리스크가 될 것이라고 생각했기 때문이다. 다행히도 새벽 3시 이후로 다시 사용 가능하다는 안내 문구를 보고 오늘 아침 일어나서 못다한 작업을 마저 실행했다.

아무튼 배포 전까지 토큰을 효율적으로 써야하기 때문에 지금 당장 필요하지 않은 기능들은 모두 덜어냈다. 브랜딩 요소라고 생각했던 기능들도 빠져서 조금 아쉬웠지만, '일단 배포!' 가 목표인 지금으로서는 어쩔 수 없는 선택이었다. 처음부터 모든 걸 다 하려고 하다가는 중간에 포기해버릴 가능성이 높기 때문에 지속 가능한 발전을 위해서라도 지금은 한 발 물러서는 게 맞는 선택이라고 판단했다.

앞으로 남은 과제들은...

1. 토큰 효율적으로 쓰는 방법 연구하기

한 번 프롬프트를 입력할 때마다 n.nk 가량의 토큰이 소비되는 걸 보고 매 순간 두려움에 떨고 있다. 언제 또 다시 리밋이 걸릴지 모르겠어서 그렇다. 이런 내 고민을 어찌 아시고, 아침에 받은 '요즘IT' 뉴스레터 두번째 게시물에 클로드 토큰 사용량을 최적화하는 방법을 다룬 아티클을 발견했다. 대강 읽어보니 최대한 입력값을 단순화해서 나타내는게 좋고, 서술형이 아닌 나열식으로 정보를 전달해주는 게 토큰을 절약하는 방법이라고 했다. AI를 파트너처럼 생각해서, 회사에서 일하는 것처럼 존대말을 써왔던 과거의 노력이 부끄러워졌다... '~해주세요' 했던 것들이 AI 세계에서는 오히려 토큰을 낭비하는 비효율적인 방식이었다니. 프롬프트만 제대로 입력해도 1500토큰을 700토큰으로 줄일 수 있다고 한다. 아티클을 좀 더 읽어보면서 AI 활용 방법을 뜯어고쳐야겠다.

개발자를 위한 Claude Code 토큰 사용량 최적화 전략 | 요즘IT

Claude Code 사용 중 발생하는 응답 저하나 오류의 핵심 원인인 '토큰'과 '컨텍스트' 한계를 심도 있게 분석합니다. 한글과 영어의 토큰 차이부터 입력·출력 토큰의 구성 요소, /context 명령어를 통한

yozm.wishket.com

2. 우리 서비스의 와우포인트 구상하기

모든 서비스의 와우포인트는 필연적으로 '브랜딩'과 맞닿아있다고 생각한다. 다른 서비스에는 없는 차별화된 무언가. 아직 우리가 어떤 서비스를 낼 건지 밝힐 수는 없지만, 아직까지의 내용으로 봐서는 시중에 다른 서비스들과 차별점이 크지 않은 것 같다. 심지어는 대체 가능한 강력한 서비스가 이미 존재한다. 하지만 그 서비스들과의 '한끗차이'를 만들어낼 수 있는 건 결국 와우포인트, 즉 브랜딩이라고 생각한다. 따라서 서비스 초기 목표인 신규사용자 유입을 높이기 위해 그들을 후킹할 수 있는, 매력적인 브랜딩 방안에 대해 고민해봐야 할 필요가 있다.

3. 수익화 방안 고민하기

어제 우리가 전혀 고려하지 못하던 요소가 있다는 걸 알게됐다. 바로 데이터베이스(DB)다. 수익화 방안과 데이터베이스 간에 무슨 연관성이 있겠냐고 할 수 있겠지만... 데이터베이스가 필요하다는 말인 즉슨, 매달 고정 지출비용이 나간다는 걸 의미한다. 요즘 바이브코딩한다는 분들의 말을 들으면 심심치않게 'Supabase' 라는 서비스 이름을 많이 들을 수 있다. 그래서 플랜 별 비용을 알아봤는데, 클로드 코드 프로를 구독하는 것 만큼의 비용이 매월 지출될 수 밖에 없다는 걸 알게 됐다. 우리는 가난한(?) 취준생... 나가는 비용 만큼만이라도 수익을 얻을 수 있으면 좋겠다고 생각했다. 그래서 앱을 배포하고 나면 곧바로 수익화를 위해 버전을 업그레이드할 생각이다. 그치만 지금까지 떠오르는 수익화 방안은 MAU를 늘려서 광고를 받는 것 밖에 없다. 뭔가 다른 방안은 없을까... 다른 앱들을 살펴보면서 구상해볼 작정이다.

이러다보면 언젠간 배포하겠지~ 가 아니라 목표는 지금부터 일주일 내로 배포하는 것이다. UXUI 디자이너 둘이서 앱인토스에 미니앱 배포하는 이야기는 계속된다...

[UXUI] 부트캠프 리디자인 프로젝트 회고

Drawer — Wed, 11 Mar 2026 23:02:22 +0900

플젝 시작한지 얼마 안 된 것 같은데 벌써 끝나버렸다 ...

2월 2일부터 시작했고 3월 6일에 끝났으니까 한 달 하고도 4일간 진행했던, 부트캠프 마지막 프로젝트가 끝났다. 지난 겨울이 어떻게 지나간지도 모르겠고 10월부터 시작했던 부트캠프도 이제 막바지를 향하고 있다니. 아쉬운 마음보다는 '아 이제부터 시작이구나' 하는 부담감이 조금씩 커져오고 있다.

그치만 이게 시작이라면 오히려 좋은 걸 ! UI 프로젝트에서 만난 팀원들은 무슨 말을 하든 의견을 존중해주시는 분들이어서, 나도 스스럼없이 이런 저런 아이디어를 꺼낼 수 있었다. 오히려 내가 팀에서 제일 의견 존중 안 하는 사람이었을걸... 플젝하면서 나답지않게 'T' 같다고 느껴진 적이 한 두 번이 아니었는데, 그럴 때마다 팀원들에게 상처주진 않았을까 하는 걱정이 앞서면서도 다음 날 되면 다시 싸갈스 바갈스로 변해서 굉장히 미안했다..

그래도 스스럼없이 의견을 마구 낸 탓에 처음으로 프로젝트의 전 과정에 내 의견이 담겨있다고 느껴졌고, 팀원들과 토론하는 과정에서 내 의견을 타당성있게 설명하는 방식도 배웠고, 아닌 건 아니라고 눈치보지 않고 말할 수 있는 용기도 배웠다. 그리고 또 처음으로 ! 업무를 주도적으로 하는 게 어떤 건지 알 것 같다는 느낌이 들었다.

회사에서든, 다른 팀플을 하든 나는 목소리 큰 사람이나 해당 분야를 잘 알고있다고 생각하는 사람의 의견을 무지성으로 받아들이는 편이었다. 한마디로 상사가 까라면 까는 소극적이고 수동적인 사람이었던 것이다. 그런데 이번 프로젝트에서는 달랐다. 나보다 뛰어난 분들과 함께 하면서도 그분들의 말을 곧이 곧대로 받아들이는 게 아니라, '그게 진짜 맞을까?' 하고 한 번 더 생각해본 것이다. '자아'를 갖게 되니까 팀원들과 부딛히는 일도 많아졌지만, 오히려 그 과정을 통해 더 탄탄한 결과물을 만들 수 있었다고 생각한다.

그럼 더 까먹기 전에 회고를 해두어야겠다. 다른 프로젝트 혹은 회사에서 맡은 업무를 하면서도 이번 '틱톡 리디자인 프로젝트'를 했을 때와 같은 열정 넘치는 감정을 다시 느끼면 좋겠다.

1. 애자일한 프로세스

이번 프로젝트에서 정말 잘했다 ! 고 생각한 부분 중 하나는 '애자일' 방식을 택했다는 거다. 덕분에 UT를 3차까지 할 수 있었다. UT를 3차까지 할 수 있어서 좋았던 이유는 우리가 가는 방향이 맞는지 확인받을 수 있는 기회가 많았던 것이다.

나는 원래 무슨 일을 하든 신중하게 생각하고 판단내리는 편이었는데, 이번 일로 무작정 오래 시간을 끈다고 해서 더 나은 결과물이 나오는 건 또 아니라는 걸 느꼈다. 어차피 서비스를 써야할 대상은 우리가 아니라 사용자인데, 우리 머릿속에 있는 생각을 뱅뱅 돌리는 것 보다는 그 시간에 사용자 한 명이라도 더 만나서 이야기를 들어보는 게 효율적인 것 같다.

프로세스를 애자일하게 이끌 수 있었던 이유 중 하나는 매일매일 일정표를 들여다봤던 게 아닐까 싶다.

프로젝트 시작할 때 팀장님께서 이번에는 UT를 3차까지 해보면 좋겠다고 말씀해주셨다. 그 목표에 따라서 일정을 잡고, 설령 부족한 부분이 있더라도 일정을 맞추기 위해 어느정도는 타협하고 넘어가며 유도리있게 진행됐기 때문에 일정에 맞춰 프로젝트를 마감할 수 있었다. 위 일정표는 초기에 작성한 거였는데, 프로젝트가 끝날 때 쯤의 일정표와 거~의 비슷하다. 그만큼 우리가 일정을 중시하고, 업무를 탁탁 맞춰 진행했다는 걸 알 수 있었다.

2. 초기 가설 설정 명확하게 하기

첫 번째 프로젝트 때에는 가설 설정을 다소 모호하게 했던 게 아쉬웠다. 그러다보니 이미 나온 결과를 바탕으로 가설을 역으로 작성하다보니 방향성이 흐트러지곤 했었다. 반면, 이번에는 데스크리서치할 때부터 가설을 명확하게 정의내리고, 그걸 팀원 모두가 동의하고 나서 다음 프로세스를 진행하다보니 모두가 같은 방향을 보고 있다는 게 느껴졌다. 그리고 시간이 흐른 뒤에도 '우리가 가고 있는 방향이 맞나?' 라는 의구심이 느껴질 때 가설을 되새겨보며 진단하니 한결 마음이 편했다.

이런식으로 <우리의 방향성> 이라는 카드를 하나 만들어놓고, 거기에 팀원들이 동의한 내용에 맞게 가설 + 방향성을 붙여 넣었다. 덕분에 사소한 것 하나 결정할 때도 이게 우리 목적에 맞는 일인지 이걸 보면서 고민할 수 있었고, 내 의견이 맞다는 걸 증명할 때에도 가설을 들고와서 말하면 되기 때문에 설득력이 더 높아질 수 있었다.

3. 사전 설문조사

우리가 '다크패턴 없애기' 를 대주제로 정하고 나서 주제를 좁혀들어가기 위해 선택한 방식은 '사전 설문조사'를 돌리는 거였다. 틱톡에서 나타나는 다크패턴을 6종류로 분류한 다음, 각 항목별로 질문을 만들어 부정적인 응답이 높은 다크패턴을 골라 개선하기로 한 것이다.

다크패턴을 항목화한 것 까지는 좋았으나, 각 항목별로 들어간 질문들의 체계가 조금 부족하다는 느낌이 들었다. 우선 항목별 질문의 수가 일정하지 않았고, '부정 응답이 높다' 를 판단하는 기준이 명확하지 않았다. 예를 들면, '틱톡이 AI 생성 콘텐츠를 엄격히 필터링하지 않는 데에 거부감을 느끼나요?' 라는 질문에 대한 부정응답이 50%를 넘어가는 순간부터 '확실히 부정적인 응답이 높다' 라고 판단할 건지, 상대적으로 다른 문항보다 부정응답 비중이 높으면 '부정적인 응답이 높다' 라고 판단할 건지 정하지 못했다.

내가 분석할 때는 초기에 50% 가 넘어야 '확실히 부정적이다' 라는 응답으로 받아들였으나, 결과적으로 과반수 이상 부정응답을 한 문항이 그렇게 많지 않아서 상대적으로 높은 응답을 부정응답으로 간주하고 넘어가기도 했다.

실무에서도 이정도의 유연성은 보이지 않을까? 싶기도 했지만, '데이터를 다룬다'는 느낌을 받기 위해서는 분석 방식도 체계화될 필요가 있겠다고 생각했다.

그리고 미처 확인하지 못한 치명적인 오류도 있어서 체계적으로 분석하기가 더 어려웠는데. '전혀 불편하지 않다' 척도 다음으로 '불편하지 않다' 가 나왔어야 했는데, '약간 불편하다' 가 나왔다는 것이었다. 의도한 바로는 불편함의 정도가 '보통이다' 보다 낮아야 하는데, 약간 '불편하다' 는 워딩 때문에 느낌상으로는 '보통이다'와 '불편하다' 사이에 있어야 할 것 같은 정도가 되었다. 팀원들과도 이 응답을 분석할 때, 응답자들이 '불편하다' 생각하고 해당 선지를 골랐을 것이다 VS 아니다, 선지를 그렇게 자세히 읽지 않고 위치 상으로 봤을 때 '보통이다' 이하의 수준으로 판단하고 골랐을 것이다 -> 사이의 논쟁이 있었다. 설문을 발행하기 전에는 검토를 더욱 꼼꼼히 해야한다는 걸 다시 한 번 느꼈다.

해당 질문에도 오류가 있었다. 해당 설문 자체가 '틱톡을 사용하는 사람'인데, 또 한 번 '틱톡을 사용하는지'를 물은 것이나 마찬가지다. 그런데, 이론상으론 틱톡을 사용하는 사람만 해당 질문에 응답했어야 하니, '틱톡'을 고른 사람이 전체 응답자인 48명이 되어야 하는데 28명밖에 되지 않는다. 아무래도 응답자 전원이 틱톡을 사용하진 않았던 것 같다. 이러면 유효응답이 줄어들 수 밖에 없는데... 물론 이후에 응답자가 더 모여서 유효 응답 수가 해당 자료를 '정량적 자료'로 쓸 수 있을 정도로는 모였지만, 이렇게 되면 데이터가 희석되어 정확한 판단을 내리기 어렵게 만들 것 같다.

4. UT 제작

이번 프로젝트에서 UT를 3번이나 진행한 만큼 가장 많은 인사이트를 얻은 파트도 이곳이다. UT를 직접 진행해봤을 뿐만 아니라, 다른 조 분들의 UT에 응답자로 참여하기까지 해서 더 많이 배울 수 있었다.

[3번의 UT 진행 방식]

1차 UT - 기존 틱톡에서의 불편함 발견 / 응답자의 기존 틱톡 화면을 공유하여 태스크를 읽어주고, 실행하는 모습을 직관함

2차 UT - 1차 리디자인 틱톡에서의 기능 검증 / 메이즈를 제작하여 응답자의 화면 공유 후 UT 진행

3차 UT - 2차 리디자인+리브랜딩 틱톡에서의 기능 및 인식 검증 / 메이즈를 제작하여 응답자의 화면 공유 후 UT 진행

1) UT 진행 전에 답변 양식을 만들어두기

질문에 맞게 팀원 분이 답변 양식을 만들어주셨다. 처음에는 해당 양식이 있어 단순히 인터뷰 내용을 받아 적기에 편리해졌다고만 생각했는데, 이후 응답을 분석하는 과정에서 한결 수월하다는 걸 알게 됐다. 왜냐하면 답변 별로 참여자들의 응답을 분류하는 작업을 거칠 때, 해당 양식 없이 진행했던 2,3차 UT에서는 AI를 이용해 응답을 한번 더 필터링하는 작업을 거쳐야 했기 때문이다. 처음부터 답변을 질문별로 나누어 작성했다면 필터링 과정이 더 수월했을 거라고 생각한다.

2) 질문 리스트를 따로 만들어두기

이것도 후에 AI를 사용해 분석할 때 필요한 자료다. 메인 질문과 하위 질문을 함께 병기해두니, 총 몇 개의 질문을 하는지 파악이 되지 않았다. 질문 자체를 검토하는 시간도 첫 번째 프로젝트보다 짧았는데, 그래서인지 실전 UT 를 진행하면서 '이런 것까지 꼭 물어봐야 하나?' 싶은 질문도 있었다. 팀원들과 함께 논의해서 만든 질문이기에 질문지에 있는 내용은 무조건 다 물어보긴 했으나, 진행자 입장에서는 프로페셔널하지 못하다고 느껴졌다. 물론 실무에 뛰어든 적이 한 번도 없는 내가 벌써부터 프로를 따라하려는 것 자체가 웃기지만, 응답자를 피곤하지 않게 배려하는 것도 진행자의 일이라고 생각해서다. UT 경험을 더 많이 쌓아서 꼭 필요한 것만 물어볼 수 있도록 질문 짜는 능력을 개발하고 싶다.

3. 척도를 넣은 질문은 한정적으로 하기

정성적 응답을 정량 데이터로 바꾸기 위해 어떤 느낌에 대한 정도를 1점부터 10점까지로 매겨서 응답해 달라는 질문이 꽤 많은 프로젝트였다. 그럴 수 밖에 없다고 생각한 건, 응답자들이 생각하는 난이도나 신뢰도 따위의 추상적인 느낌을 그나마 객관적으로 전달받기 위해서는 점수를 통해 나타내달라고 요청하는 방법밖에 없다고 생각했다. 1차 때는 약 7개, 2차 때 10개, 3차 때 8개의 척도 질문이 있었다. 특히 2차 때에는 한 테스크에 3개의 척도 질문이 연달아 나와서 응답자들이 곤란했을 것 같다.

척도 질문을 한정적으로 해야한다고 주장하는 이유는 역시 응답자들의 피로도를 줄이기 위함이다. 실제로 지인에게 UT 를 진행하다가 척도 질문을 연달아 하면서 '이번에도 점수로 나타내주면 좋겠는데~' 라고 운을 떼자, 살짝 곤란해하는 표정으로 '아, 이것도?' 라는 반응이 돌아왔다. 그때 처음으로 응답자들이 추상적인 걸 점수로 나타내는 걸 어려워하겠구나 하는 생각이 들었다. 그러고보니 나도 다른 팀의 UT 참여자로 질문을 받았을 때, 점수를 매겨달라는 질문 앞에서 꽤 오랜 시간 고민하기도 했다.

그래서 이번 프로젝트의 가장 큰 지표였던 '신뢰도' 와 '난이도' 를 제외하고는 되도록 척도 질문을 넣지 않았어야 한다고 본다. 실제로 척도형으로 질문을 하고 데이터를 수집한 다음에 유의미하게 사용된 질문은 일부였다. 사용되지 않은 질문들은 굳이 척도형으로 응답을 수집할 필요가 없었다고 생각한다. 물론 데이터를 분석하다보면 프로젝트가 진행됨에 따라 필요한 지표가 바뀌기도 하기 때문에 되도록 많은 데이터를 수집해둘 필요도 있다고 생각한다. 그럼에도 가능하다면 경험을 많이 쌓아, 깊은 분석이 필요할 것 같지 않은 데이터들은 사전에 질문 형식을 간소화해서 응답자들의 피로도를 낮출 수 있으면 좋겠다.

4. UT 응답을 보며 팀원 모두가 아이디어 내기

UT를 마친 이후에는 질문별로 응답을 모아서 함께 분석하는 시간을 가졌다. 나는 프로젝트를 통틀어서 이 시간이 세 손가락 안에 드는 중요한 일이었다고 생각한다. 이전 프로젝트에서는 설문 응답이나 UT 응답을 제대로 살펴볼 기회가 적었었던 게 아쉬웠다. 열심히 UT를 했음에도 결과물을 보면 '여기에 사용자들의 의견이 반영된 게 맞나?' 하는 의문이 들었기 때문이다.

그치만 이번에는 달랐다. 설문조사든, UT든 매번 사용자의 목소리를 듣고 온 이후에는 팀원들이 모두 모여 인사이트를 나눴고 그 결과를 바탕으로 리디자인할 요소를 정했고 기능을 업그레이드했다. 첫 번째 프로젝트에서 사용자 응답 사용률이 40% 정도였다면, 이번에는 80%까지 끌어올렸다고 할 수 있다.

나머지 20%는 UT 참여자가 테스크를 수행하기 위해 터치하는 요소들의 순서를 녹화본을 보고 조금 더 분석해봄으로써 멘탈모델에 대해 더 알 수 있지 않았을까 하는 점이 있다. 그리고 절대적인 시간이 부족했기 때문이지만 응답하거나 테스크를 수행할 때 참여자의 표정이나 말투에 관해 조금 더 생각해봤더라면 기능을 사용할 때의 유저들의 감정을 조금 더 알 수 있지 않았을까 하는 아쉬움이 따른다. 그치만 그것까지 하려면 시간이 좀 더 충분했어야 했고, 자료조사도 논문 찾아보면서 더욱 세밀하게 했어야 했기 때문에 한 달이라는 한정된 시간 안에 80% 채운 것으로 만족한다.

5. 신뢰도는 검증된 질문으로 묻기

마지막 날에 실무자 분 앞에서 프레젠테이션을 하고 받은 피드백 중 하나는 전혀 예상치 못했던 데 있었다. 바로 '신뢰도' 를 측정하는 문항이 공식적이지 않았던 것. 단순히 비공식적인(우리가 만든) 문항을 사용해서가 아니라, 신뢰도와 같은 추상적 개념을 측정할 때에는 이미 연구를 통해 검증된 질문들을 사용하는 게 더 설득력있게 보일 수 있다는 것이다.

그 피드백을 받고 나니 알 것 같았다. '이 브랜드에 대해 신뢰하시나요?' 라는 질문이 정확히 브랜드의 어떤 면을 신뢰한다는 건지 사용자 입장에서는 모호하게 느껴질 수도 있겠다는 거였다. 그래서 우리 팀은 공신력 있는 지표를 활용해 만든 설문조사를 다시 한 번 UT 참여자 분들께 돌리려고 한다. 원래 SUS(System Usability Scale) 지표를 활용하려고 했으나, 우리 팀의 북극성 지표는 '신뢰도' 이기에 브랜드 신뢰도와 관련된 지표를 찾아보려 한다. (찾은 후 업데이트 예정)

6. Maze는 최대한 단순하게 제작하기

우리팀은 UT를 3차까지 했고, 더 넓은 타겟을 대상으로 한 매스테스트까지 진행했기에 메이즈 파일이 4개나 된다. 매스테스트는 틱톡을 이용해본 사람과 이용해보지 않은 사람을 나누어서 정보를 수집했기에 총 2개의 파일을 만들어 진행했다.

이렇게 여러 파일을 만들고, 다른 팀 분들의 UT에 참여하면서 느낀 점을 정리해본다.

1) UT 테스크는 간단해야 한다

테스크가 길어지면 그걸 다 읽고 이해하는 데 시간이 오래 걸리더라. 겨우 다 읽고 테스크를 진행하려 하면서도 테스크가 뭐였는지 계속 상기하게 되어서 정작 중요한 화면에 집중하지 못하는 날 발견했다.

2) UT 질문은 최대한 직관적으로, 추상적인 개념을 묻는 질문은 최소화한다

우리팀의 북극성지표가 '신뢰도' 였기 때문에 UT 때 신뢰도를 묻는 질문이 필수로 들어가야 했는데, 난 항상 질문'하는' 입장이었으니 거기에 답변해야 하는 사람의 입장을 미처 헤아리지 못했다. 내가 인터뷰이로 참여했을 때 비슷한 질문을 받았는데, 뭐라고 대답해야할지 자꾸 고민하게 되었다. 물론 신중하게 생각해야 유의미한 답변을 해줄 수 있다는 점에서는 나쁘진 않지만, 그렇게 신중히 생각해야하는 질문 수가 늘어나면 인터뷰이 입장에서는 에너지를 많이 써야할 것 같다는 느낌이 들었다.

3) 화면에 관해 질문하려면, 화면을 보여주면서 해야 한다

질문 중에 '아까 보신 ~화면에서 ...' 로 시작하는 것들이 있었는데 참여자가 화면을 잘 기억하지 못할 것 같다는 게 내 생각이다. 왜냐면 내가 인터뷰이로 참여할 때 그랬으니까...^^ 그래서 이미지로 화면을 다시 보여주던지, 아니면 질문용 테스크를 따로 파서 화면을 탐색하면서 질문을 받을 수 있도록 하면 좋겠다고 생각했다.

(쓰다보니 너무 길어질 것 같고 바빠서 지금 당장 다 쓰지도 못할 것 같아서 계속 내용을 덧붙이려 한다)

바이브코딩으로 타로운세 서비스 만들기

Drawer — Mon, 2 Feb 2026 00:34:16 +0900

https://mystellatarot.figma.site/

부트캠프 UI 실습 때 만든 타로운세 서비스 'Stella Tarot' 이다. 선생님이 '별' 에 무슨 의미가 있는건지 물어보셨는데, 타로하면 뭔가 점성술이 떠올라서 넣어봤다. 웹사이트 한정 별들 위에 마우스를 호버링하면 깜박거리는 인터렉션을 체험할 수 있다.

글꼴은 엘레강스하면서도 오묘한 느낌이 나는 궁서체로 찾고 싶었다. 그러다가 찾은 건 '국립박물관문화재단'의 전용 서체였다. 다운 받을 수 있는 사이트는 아래에▼

국립박물관문화재단

www.nmf.or.kr

메인페이지의 중앙 부분에는 'marquee'라는 인터렉션을 적용한 붉은 문구들이 우측에서 좌측으로 흘러가고 있다. '운명'과 관련된 명언들을 검색해 넣은 것인데, 타로 결과가 마음에 들지 않더라도 운명은 어차피 본인이 개척하는 것이니 너무 상심치 말라는 의미에서 넣어둔 것이다. 그리고 피그마 Site 의 인터렉션을 최대한 적용해보기 위해 넣은 것도 있다. 내가 찾은 명언들은 아래와 같다.

['운명' 관련 명언들]

“운명을 바꾸는 힘은 나에게 있다” - 윌리엄 셰익스피어

“인간은 자기 운명의 설계자이다" - 아리스토텔레스

“운명은 우리가 예상하지 못한 길로 이끈다" - 오 헨리

“운명은 우리가 선택하는 것이고, 선택은 우리를 만든다" - 프란시스 베이컨

“우리는 운명을 받아들일 수 밖에 없지만, 그것을 다스릴 수 있는 힘도 있다" - 토머스 칼라일

“운명은 우리를 특정한 길로 이끌지만, 그 길을 걷는 것은 우리의 선택이다" - 오스카 와일드

Figma Make

이번 서비스를 만들면서 사용했던 AI 서비스와 거쳤던 작업과정을 기록해두려 한다.

AI: Figma Make, Antigravity, Manus, Claude

️ 작업과정 (2일)
1. Figma Site에서 페이지 디자인 제작 및 인터렉션 연결
2. Figma Site의 CMS 활용하여 타로 결과 페이지 제작 시도
3. Manus에 메인페이지 디자인 첨부하고, 비슷한 무드로 타로카드 78장 제작 요청
4. 타로 결과 내용이 삽입된 CSV 파일을 Claude한테 뽑아서 CMS에 삽입하는 것까진 성공했으나, 결과가 랜덤으로 보여야 하는 기능 구현 실패
5. Figma Make에 디자인한 프레임 붙여넣고 자연어로 인터렉션 구현
6. Antigravity에 요청해서 '랜덤 결과' 페이지를 보여주는 기능 덧붙여 코드 수정
7. 수정한 코드를 Figma Make에 수동으로 붙여넣고 퍼블리싱
8. Figma Make 토큰 부족 이슈로 파일 모두 다운받아 로컬에 저장해두고 Antigravity와 디자인 디벨롭
9. 수정한 코드는 수동으로 Figma Make에 붙여넣고 퍼블리싱 업데이트 (반복x100)
10. 노션 폼 및 노션 페이지 URL 링크로 연결하여 웹사이트 상단의 헤더 활성화
11. 인터렉션으로 인해 발생한(추정) 오류 디버깅

찐 서랍장 모양의 블로그 제작기 (feat. Antigravity, Stitch) - 파트1, 디자인

Drawer — Mon, 26 Jan 2026 21:22:48 +0900

오백년 만에 블로그 디자인을 바꿨다.

이번에 리뉴얼하면서 제일 도움을 많이 받은 건 단연 '안티그래비티(Antigravity)' 였다. 링토스 게임 만들고 나서 바이브코딩에 재미가 들려서 블로그까지 바꿔버린 건데. 이거 하려고 Google AI Pro 결제했다.

링토스 게임 만들었던 후기는 여기에 ▼

안티그래비티로 수중 링 던지기(링 토스) 게임 만들기

어제 부트캠프 휴강일이어서 뭘 하면 시간을 알차게 보냈다고 소문이 날까.. 싶어서 게임을 만들어보기로 했다. 이유는 모르겠지만 얼마 전부터 어렸을 때 했던 게임인 '수중 링 던지기 게임(ring

drawerrer.tistory.com

내 블로그 이름은 '서랍장' 이다. 그래서 직관적으로 서랍장 모양의 블로그를 만들어보았다. 이 발상을 처음 한 건 1년 전이었는데, 그때까지만 해도 내 머릿속에만 떠돌아다니던 그 그림을 어떻게 웹사이트로 옮길지 고민이 많았다. 컴공 전공인 동생한테 물어서 웹사이트 빌딩하는 책을 사려고도 했으나, 본격적으로 공부해야할 것 같고 무엇보다 책이 두꺼워서 고사했었다.

그렇게 '나만의 블로그 만들기' 계획은 아이디어 무덤에 묻히는가 했는데... 그로부터 몇 개월 후 바이브코딩 붐이 시작할 무렵 ChatGPT 를 이용해서 블로그를 대강 만들어뒀었다. 글과 사진만 볼 수 있는 형태로 말이다. 그마저도 사진은 업로드된 모양새가 몇 번을 수정해도 애매해서 나중에는 사진 탭을 없애버렸다.

그렇게 글만 5편 올려두고 거의 방치하다시피 해놨던 내 블로그를 안티그래비티를 통해 소생하게 되었다. 한 번 시작하니까 고치고싶은 부분들이 계속 보여서 지난 주말도 계속 웹사이트를 수정했다. 아직도 수정할 부분이 많지만 내가 제대로 만든 첫 블로그인 만큼 계속해서 디벨롭해나가고 싶다. 나중에는 블로그나 SNS 보다 이 공간에 내 소식을 더 많이 올려두는 날이 올지도 모르겠다.

파트 1 - 블로그 시각 디자인, 메뉴별 레이아웃 짜기, 관리자 페이지 생성

파트 1에서는 블로그의 각 페이지를 디자인하고, 각 페이지별로 기능에 따라 레이아웃을 짜고, 콘텐츠를 올릴 관리자 페이지를 생성한 일에 관해 이야기할 예정이다. 각 과정에서 사용한 툴을 정리해본다.

✏️ 디자인 - Stitch(디자인 초안 뽑기) / Pinterest(레퍼런스 수집) / Antigravity(개발 중 자잘한 디자인 수정)
️ 레이아웃 - Claude(PRD 제작) / Antigravity(PRD에 따라 레이아웃 및 기능 구현)
️ 관리자 페이지 - Claude(PRD 제작) / Antigravity(PRD에 따라 기능 구현, 기능 디벨롭) / Firebase(DB 구축)

총 6개의 플랫폼을 거쳐 블로그를 리뉴얼했고, 배포할 때 사용한 깃허브까지 더하면 총 7개의 플랫폼을 활용했다. 세어보니 많긴 한데 제대로 코딩하시는 분들은 이보다 더 많이 쓰겠지..? 근데 정작 코딩할 때는 여기저기 왔다갔다하는 느낌도 안 났다. 그냥 필통에 형광펜, 볼펜, 샤프, 자 등 여러가지 필기도구를 넣어두고, 상황에 따라 필요한 도구들을 꺼내 쓴 느낌이었다.

✏️ 디자인 - Stitch(스티치)와의 기싸움

작업 방식:

1) 스티치에 내가 원하는 모습의 블로그 이미지 글로 전달

2) 1차 시안 여러 장 받아보고, 마음에 드는 이미지 골라서 디벨롭 시작

3) 핀터레스트에서 레이아웃 및 구체적인 요소 관련 레퍼런스 다운받아서 스티치에 삽입

4) 레퍼런스대로 이미지 출력해달라고 스티치에 요청

5) 마음에 드는 작업물 나올 때까지 반복

스티치 작업 필드

스티치에 첫 번째 프롬프트를 입력했다. 이때는 레퍼런스 없이, 오로지 내 머릿속에 있는 컨셉을 얘기했다.

저는 독특한 형태의 개인 블로그를 디자인할거예요. 방 안에 목재 도면 서랍장이 있고, 서랍장 한 칸 한 칸을 메뉴로 사용할 거예요. 첫 번째 칸은 '글', 두 번째 칸은 '사진', 세 번째 칸은 '댓글 및 커뮤니티' 를 위한 공간으로 구성할 거예요. 제가 지금까지 말한 대로 웹사이트 화면을 구성해주세요.

그 결과, 아래와 같이 세 가지 컨셉의 서랍장 모양의 웹사이트 이미지를 출력해줬다.

그런데 왠지 묵직~ 한게 내 생각과는 조금 달랐다. 그래서 이번엔 레퍼런스와 함께 프롬프트를 다시 입력했다.

서랍 디자인은 이 이미지를 참고해서 '사실적으로(realistic)' 생성해주세요.
그리고 메인 페이지에는 서랍 이미지(메뉴 기능추가)만 있으면 좋겠어요. 하단의 사진이나 요소들은 모두 제거해주세요.

좌: 레퍼런스(핀터레스트) / 우: 스티치 출력물

어때요? 제법 비슷한가요? 나름 색상은 또 맞춰서 출력해주었다. 좌측 디자인처럼 가운데 뚫린 것도 반영해주길 바랐는데.. 일단 디자인 초안을 뽑는 게 우선이니 저정도로 만족하기로 했다.

메인페이지를 뽑고 나서 다른 칸 페이지도 디벨롭하기 시작했는데.. 이런 디자인의 웹사이트가 기존에 잘 없었다보니 얘(스티치)가 갈피를 못 잡는게 느껴졌다. 매 페이지가 고난이었기 때문이다. 아래에 각 페이지의 첫 디자인과 최종 디자인을 함께 기록해두도록 하겠다.

1) Writings Drawer - 글 수록

어려웠던 점: 내가 원하는 레이아웃을 스티치가 이해하지 못했다. 내가 원했던 건 서랍 안에 인덱스 붙은 파일이 가로로 가지런히 꽂혀져 있는 모양새였는데, 레퍼런스를 입력하고 여러 번 프롬프트를 바꿔 입력해봐도 알아듣지 못하는 거다. 인덱스 붙은 파일 형태까지는 제작해주는데 자꾸 서랍 뒤쪽에 붙여두고 앞은 공백으로 두는 거다. 앞쪽부터 채워달라고 해도 모른척... 결국 우측처럼 리스트 형태로 바꿨다. 파일 형태 잡으려다간 내가 지칠 것 같아서.

좌: 레퍼런스 / 우: 출력물

내가 오죽 답답했으면 손으로 그려서도 올려봤다.. 그런데도 결과물은 요지경. 인덱스 올라온 것까지 완벽한데 거기서 하단부 여백을 줄여주라는 말은 곧죽어도 이해를 못한다. 왜그랬을까...

2) Photograpy Drawer - 사진 수록

생각해보니 사진 서랍은 그닥 어려웠던 점이 없었던 것 같다. 프롬프트 입력할 때마다 내가 의도했던 대로 잘 수정해주었다. 그럼에도 초기 디자인을 수정한 이유는 서랍 전체를 사진으로 가득 채우고 싶었기 때문이다. 모든 사진을 2번째 칸 이미지처럼 폴라로이드 프레임으로 해달라고 요청하니까 바꿔주었다.

우측 상단에 있는 'REFRESH' 버튼을 누르면 사진이 진동하면서 새로운 사진으로 바뀐다. 아쉽게도 지금은 4장만 올려둔 상태라, 저 버튼을 눌러도 사진의 순서만 바뀌고 다 보여준다. 나중에 사진을 많이 올렸을 때를 대비했다.

3) Community Drawer - 방명록 수록

어려웠던 점: 서랍장 내 각각의 박스 안에 요소를 채워넣는 일이 어려웠다. 내가 집어넣고 싶은 것들을 핀터레스트에서 모두 긁어와 스티치에 붙여넣고, 이것들을 각각의 칸에 넣어달라고 했다. 아무래도 3D를 2D로 옮기다보니 형태가 제대로 옮겨지진 않았다.. 그래도 나름 만족했는데 문제는 온라인으로 봤을 때 서랍 이미지가 완전 찌부되어서 보인다는 점이었다. 그래서 지금과 같은 간단한 형태로 수정했다.

4) Home - 메인페이지

어려웠던 점: 침대 디자인과 배치가 골치아팠다. 아니, 지금 생각해보면 침대는 메인도 아니었는데 내가 왜 그렇게 진을 뺐지.. 싶다. 그치만 거슬리는 걸 어떡해! 침대도 마찬가지로 레퍼런스를 입력했는데, 우측과 같은 형태로 나왔다. 흐린눈 하면 멀쩡해보이는데, 자세히 보면 책 사이에 요상한 띠들이 껴있다. 배게도 잘린 것 같이 되어있다.

무엇보다 신경쓰였던 건 침대의 배치였다. 서랍과 틈을 주라니까, 오히려 더 옆으로 붙이는 게 아닌가. 침대 오른쪽으로 조금만 더 밀어달라는 프롬프트를 5번은 입력한 것 같다. 아래는 나와 스티치의 사투가 담겨있는 B급 시안들이다.

아참, 신기한 거 하나 발견했다. 스티치에서 히트맵 기능도 되는 거 알고 계셨는지? 내가 입력했던 프롬프트를 못 찾았는데, 히트맵을 보고싶은 웹사이트 화면을 클릭한 다음 프롬프트를 입력하면 출력해준다. 내 블로그 이미지가 기존 블로그보다조잡해서 메뉴가 어딘지 알까 싶었는데 정확히 메뉴 탭 부분에 빨간색으로 표시되는 걸 보고 안심했다.

그리고 스티치에서 나이트모드도 뽑아준다. (신기) 스티치는 이미지만 출력해주는 거라고 생각했는데, 나이트모드로 바뀔 때 램프에서 은은하게 빛이 나면 좋겠다고 요청하니까 진짜 그런 효과가 나게끔 바꿔줬다.

원래는 이 게시물에서 레이아웃 디벨롭하고 관리자페이지 생성하는 것까지 얘기하려 했는데.. 게시물이 너무 길어져서 나눠야겠다.