평면의 문제를 육면체로 보기: 기술·기획·디자인·운영·브랜드·AX

대부분의 문제는 처음에 평면으로 보인다. "이 기능을 만들어야 한다", "이 화면을 고쳐야 한다", "매출이 안 나온다." 하나의 면만 보이면, 그 면만 해결하면 될 것 같다.

하지만 실제로 제품 안에서 살아 있는 문제는 거의 항상 여러 면을 동시에 가지고 있다. 기술의 면, 기획의 면, 디자인의 면, 운영의 면, 브랜드의 면, 그리고 AI를 활용하는 면까지. 하나의 문제를 평면이 아니라 육면체로 돌려보는 것. 그게 내가 문제를 푸는 방식이다.

그리고 이건 그냥 멋있어 보이는 말이 아니라, 실제로 내가 일하면서 반복적으로 확인해온 방식이다.

먼저 써보고, '?'가 뜨는 곳을 전부 찾기

내가 문제를 풀 때 가장 먼저 하는 일은 직접 써보는 것이다.

기획서를 읽는 것도, 데이터를 보는 것도 중요하지만, 가장 정직한 정보는 직접 경험할 때 나온다. 써보면서 "왜 여기서 멈칫하지?", "이 버튼은 왜 누르기 싫지?", "이 흐름은 왜 어색하지?" 같은 물음표가 뜨는 지점을 전부 수집한다.

그다음에는 데이터를 본다. 물음표가 뜬 곳이 실제로 사용자도 이탈하는 곳인지, 아니면 나만 불편한 곳인지를 확인한다. 그리고 좋은 점은 강화하고, 나쁜 점은 패치하거나 헷징한다.

여기서 "헷징"이라는 건, 단점을 무조건 없애는 게 아니라는 뜻이다. 흐름상 반드시 필요한 허들이라면, 그 부담을 줄이는 방식으로 설계한다. 예를 들어 회원가입이 전환의 병목이지만 서비스에 필수라면, 가입 자체를 없애는 게 아니라 가입 전에 핵심 가치를 먼저 경험하게 해서 가입할 이유를 만들어주는 식이다.

이게 내 문제 해결의 출발점이다. 한 면만 고치는 게 아니라, 문제의 전체 컨텍스트를 파악하는 것부터 시작한다.

앱 10개를 출시하면서 배운 것

나는 토스 앱인토스에서 10개 이상의 미니앱을 직접 기획하고, 개발하고, 디자인하고, 운영까지 해왔다. 처음에는 내가 직접 불편했던 문제를 풀기 위해 만들었다. 나와 비슷한 페인포인트를 가진 사람들을 타겟팅했고, 가설이 맞았던 앱은 2달 만에 20만 명이 사용하는 서비스가 됐다.

여기서 중요했던 건 기능을 잘 만든 것만이 아니었다.

푸시 알림 하나를 보내더라도 사용자가 어떤 상황에서 그 메시지를 받는지, 어떤 문구가 행동으로 이어지는지를 계속 실험했다. 토스에서는 '잘 나온 푸시 클릭률'은 3%라고 하고, 일정 기간 성적이 4% 이하면 푸시를 비활성화 한다.  내 앱은 평균 5%대, 최고 6.8%를 기록했다. 사용하기 편한 디자인, 검증된 페인포인트, AI를 활용한 마케팅 최적화가 맞물린 결과였다.

물론 다 성공한 건 아니다.

친구에게 응원 메시지를 남기는 롤링페이퍼 앱도 만들었는데, 토스 안에서 롤링페이퍼를 작성한다는 행위 자체가 사용자에게 너무 큰 허들이었다. 광고 전환도, 유저 전환도 모두 처참했고, 결국 실패작으로 남겼다. 기능은 작동했지만 기획 가설이 틀렸다. 이 경험이 오히려 "기능이 되느냐"보다 "이 맥락에서 이 행동이 자연스러우냐"를 먼저 보게 만들었다.

또 하나. 앱인토스 초기, 전체 앱이 200개도 안 되던 시절에 진입한 앱이 있었다. 시간이 지나면서 카피앱들이 쏟아졌고, 경쟁이 심해지면서 유저가 빠져나갔다. DAU가 10명대까지 떨어진 시점에서 경쟁 앱들의 장단점을 분석하고, 앱을 처음부터 재구성했다. 결과적으로 DAU를 120까지 올렸고, 지금도 지속적으로 편의성을 개선하며 운영하고 있다.

이 과정에서 깨달은 건 단순하다. 만드는 것보다 계속 돌아가게 만드는 게 더 어렵고, 더 중요하다.

디지털 밖에서도 같은 방식으로 일한다

육면체로 보는 방식이 디지털 제품에만 통하는 건 아니다.

카페 브랜딩 프로젝트를 맡은 적이 있다. 단기간 3개월 프리랜서 포지션이었는데, 처음 진단했을 때 가장 큰 문제는 명확했다. 이 카페에는 얼굴이 없었다. 시그니처라고 부를 수 있는 메뉴가 하나도 없었다.

기존 판매 데이터를 보니 달달한 페이스트리류의 판매량이 높았다. 이걸 지역의 헤리티지와 결합해서 시그니처 빵을 만들기로 했다. 제빵팀과 오랜 협의가 필요했다. 외부 인력이었기 때문에, 제빵팀과 관계를 쌓지 못했으면 이 방향 자체가 불가능했을 것이다. 실행은 빠르게 돌렸다. 만들고, 팔고, 반응을 보고, 바꾸고, 다시 파는 사이클을 반복했다.

동시에 디지털 쪽도 함께 움직였다. 네이버 지도 최적화, SEO 최적화, 당시 주요 고객층이 가장 많이 사용했던 인스타그램에서 퍼포먼스 마케팅을 집행했다. 특히 이 카페는 위치가 애매한 곳이었는데, 자차가 아닌 워크인 고객의 비율을 40%까지 끌어올렸다. 전체 매출은 30% 올랐다.

이 프로젝트에서 한 일을 하나의 직무로 정의하기는 어렵다. 데이터 분석, 메뉴 기획, 브랜딩, 마케팅, 운영 개선이 전부 하나의 흐름 안에 있었다. 나는 이걸 자연스럽게 느꼈다. 문제가 여러 면을 가지고 있으면, 여러 면에서 동시에 접근하는 게 당연하다고 생각하기 때문이다.

AI는 도구이자 워크플로우

나는 AI를 "가끔 물어보는 도구"가 아니라 일하는 방식 자체에 녹여서 쓴다.

앱을 만들 때 나의 프로세스는 이렇다. 먼저 Spec Driven으로 기획 명세서를 작성한다. 이 명세서를 기반으로 Claude Code와 Codex가 각각 코드를 생성하고, 서로의 결과물을 교차 검증한다. QA는 Codex를 통해 진행하고, 거기서 나온 오류 리포트를 Claude Code로 해결한다.

여기에 skill.md를 만들어서 반복되는 작업의 기준과 패턴을 문서화해두었다. Human in the Loop 기반의 반자동화 시스템이다. 이 방식으로 앱 하나를 출시하는 데 걸리는 시간이 3주에서 4~5일로 줄었다. 종종 확인해야하는 귀찮음이 있지만 현재의 기술로써는 이 방법이 가장 완성도가 높다고 생각한다.

빠르게 찍어내는 것이 목적이 아니다. 속도가 붙으면 오히려 질이 떨어질 위험도 있다. 그래서 지금은 양보다 밀도를 택한다. 시간이 줄어든 만큼 기획과 디자인에 더 공을 들이고, 잘 만든 결과물을 포트폴리오로 쌓는 쪽으로 방향을 잡았다.

AI를 쓸 때 내가 지키는 기준은 몇 가지가 있다.

AI에게 묻기 전에 문제를 먼저 구조화한다. 구조 없는 질문은 구조 없는 답을 불러온다. 초안은 빠르게 받되 판단은 천천히 한다. AI가 만든 문장이 그럴듯하다고 맞는 건 아니기 때문이다. 기술 선택, 비용, 정책처럼 검증이 필요한 영역은 반드시 공식 문서와 실제 조건으로 다시 확인한다.

그리고 가장 중요한 건, AI를 쓰면서 나만의 기준을 잃지 않는 것이다. AI를 거치면 결과물이 평균적으로 깔끔해진다. 하지만 그 과정에서 내 문제의식이나 제품의 결이 흐려질 수 있다. 넓게 탐색하되, 최종 결과에는 내가 중요하게 여기는 기준이 남아 있어야 한다. 방향은 도구가 아니라 사람이 정한다.

여섯 개의 면, 하나의 방향

다시 정리하면, 나는 문제를 볼 때 여섯 개의 면을 함께 돌려본다.

기술적으로 지속 가능한가. 기획적으로 풀어야 할 진짜 문제를 짚고 있는가. 디자인적으로 사용자가 생각하지 않아도 이해할 수 있는가. 운영적으로 출시 이후에도 버틸 수 있는가. 브랜드적으로 이 제품이 스스로 어떤 인상을 주고 있는가. 그리고 AI를 이 흐름 안에서 어떻게 엮을 것인가.

이 여섯 개를 다 잘하는 사람이라는 뜻은 아니다. 각 면에서 전문가보다 깊지 않을 수도 있다. 하지만 나는 이 면들이 어떻게 연결되는지를 보는 데 감각이 있다고 생각한다. 그리고 그 연결을 실제로 만들어본 경험이 있다.

앱인토스에서 기획부터 마케팅까지 한 사람이 돌리면서 20만 유저를 만든 것도, 카페에서 데이터와 현장 감각을 섞어 시그니처 메뉴를 만들고 매출을 올린 것도, AI 워크플로우를 설계해서 출시 속도를 5배 줄인 것도 — 결국 같은 방식의 다른 표현이다.

멀티플레이어라는 건 이것저것 조금씩 할 줄 안다는 뜻이 아니다. 하나의 문제를 여러 면에서 동시에 보고, 각각의 면이 한 방향으로 작동하게 묶어내는 것이다. 원소스 멀티유즈. 하나의 관점에서 출발해서 기술로도, 기획으로도, 디자인으로도, 운영으로도, 브랜드로도, AI로도 풀어낼 수 있는 것.

AX가 중요해지는 시기에 이런 워크플로우가 중심이 되지 않을까?

나는 정답을 빨리 내는 사람이라기보다, 문제를 여러 층위에서 동시에 보고 실제로 지속 가능한 답으로 묶어내려는 사람에 가깝다.

평면의 문제를 육면체로 돌려보기.