매일 하던 업무를 디자인하기

안녕하세요. 토스뱅크에서 주택담보대출을 디자인하고 있는 Product Designer 김혜미입니다.

이번 글에서는 프로덕트가 아니라, 제가 일하는 방식을 디자인했던 이야기를 해보려고 해요.

매일 할 일을 손으로 옮겨 적었다

토스에 입사한 첫 주부터 저는 할 일을 매일 손으로 정리했어요. 처음엔 노션이었고, 나중에는 슬랙이었죠. 제 일의 대부분은 슬랙에서 시작되는데, 피드백이나 요청 스레드, 논의 링크를 다시 노션으로 옮기는 일이 번거로웠거든요.

하지만 채널이 바뀌었을 뿐 본질은 같았어요. 매일 아침 할 일을 정리하고, 끝난 일은 체크하고, 새 업무를 추가하고, 참고 링크를 붙였죠. 이렇게 2년 반을 했어요.

이게 이상하다고 생각해본 적은 없었어요. 할 일을 정리하고, 흩어진 맥락을 모으는 일은 원래 업무의 일부라고 생각했거든요.

그래서 한 번도 이런 의문을 가진 적이 없었죠.

"이걸 꼭 내가, 손으로, 매일 해야 하나?"

참을 문제가 아니라, 디자인할 문제

그러다가 할 일을 도저히 제가 관리할 수 없는 시기가 왔어요. 올해 초, 세 팀을 동시에 맡게 되면서 업무량이 크게 늘었거든요.

처음 슬랙에 할 일을 정리하던 시절엔 하루 10개 안팎이었는데, 어느 순간 20개가 넘었어요. 이제 더 이상 수기로는 할 수 없는 수준이 됐다고 생각했죠.

보통 여기서 더 좋은 할 일 앱을 찾거나, 더 열심히 관리하는 쪽으로 가잖아요. 저는 세 번째 길을 골랐어요. 이 불편을 제가 매일 쓰는 프로덕트라고 생각하고 디자인하기로 한 거예요.

프로덕트를 디자인할 때 늘 하던 방식을 그대로 적용했어요.

• 사용자는 누구인가? → 나
• 진짜 하려는 일은 무엇인가? → 할 일을 정리하는 게 아니라, 지금 가장 중요한 일을 놓치지 않고 처리하는 것
• 어디에서 마찰이 발생하는가? → 할 일을 옮겨 적고, 정리하고, 출처를 찾아가는 반복 작업
• 무엇이 잘된 상태인가? → 해야 할 일이 자동으로 모이고, 우선순위만 판단하면 되는 상태

이렇게 문제를 정의하고 나니 만들어야 할 것도 자연스럽게 따라왔어요.

• 할 일은 슬랙에서 생기는데, 그걸 옮겨 적는 게 일이다 → AI가 알아서 등록하게 하자
• 옮겨 적다 보면 왜 하는지 잊는다 → 출처 스레드와 문서 링크를 함께 남기자
• 뭐부터 해야 할지 모르겠고, 안 보이면 잊는다 → 우선순위를 붙이고 항상 보이는 위젯으로 두자

할 일 앱은 넘쳐나지만, 세상 어떤 앱도 제가 어떤 채널을 보는지, 무엇을 중요하게 생각하는지, 왜 이 일을 하는지까지는 모르잖아요. 그 맥락을 아는 사람은 저뿐이었어요. 그래서 직접 만드는 게 답이었죠.

AI에게 내 일을 이해시키기

위젯 동작 자체는 단순해요. 슬랙에서 특정 이모지를 달면 메시지가 한 채널에 모이고, Claude Code가 그 내용을 읽어 할 일로 등록해요. 출처 스레드 링크도 함께요.

말로는 간단해보이지만 실제로는 전혀 그렇지 않았어요.

가장 어려웠던 건 긴 맥락의 메시지를 한 줄의 할 일로 바꾸는 것이었어요.

슬랙 메시지는 길고 맥락이 잔뜩 붙어 있잖아요. 이걸 한눈에 알아볼 수 있는 한 줄의 할 일로 바꾸고, 알맞은 팀까지 연결해야 했어요. 군더더기를 걷어내고, 진짜 해야 할 일만 남기는 일이었죠.

예를 들어 "대출에서 연장 신청할 때 이런 에러가 떠요. 봐주실 수 있을까요?"라는 메시지가 오면, 위젯에는 "대출 연장 에러 케이스 확인"이라는 한 줄의 할 일로, 해당 팀 태그와 함께 들어와야 했죠.

처음부터 잘 되지는 않았어요. 요약이 너무 길어지기도 하고, 핵심을 놓치기도 하고, 엉뚱한 팀에 들어가기도 했어요.

그래서 UX 라이팅 가이드를 만들듯 접근했어요.

좋은 할 일은 어떤 형태인지, 어떤 기준으로 팀을 나눌지, 어떤 표현을 사용할지를 예시와 규칙으로 하나씩 정의했죠.

그리고 결과가 "내가 직접 적었을 법한 문장"이 될 때까지 계속 다듬었어요.

돌이켜보면 이 과정이 가장 디자인에 가까웠어요.

코드를 짠 게 아니라, 무엇이 진짜 할 일인지, 그걸 어떤 언어로 표현해야 하는지에 대한 제 판단을 AI가 따라 할 수 있게 만드는 일이었거든요.

위젯을 실제로 쓰고 싶을 만큼 자연스럽게 만드는 것도 힘들었어요.

작게 접힌 상태에서 펼쳐지는 동작 하나를 다듬다가 코드를 전부 갈아엎고 다시 만든 적도 있었고, 드래그 기능은 일주일 가까이 붙잡고 있었어요.

두 경우 모두 결국 중요한 건 AI에게 어떻게 설명하느냐였어요. 머릿속에서는 너무 당연한 것도 한 줄 한 줄 풀어서 설명해야 했어요. AI에게 내 일을 이해시키는 일은, 결국 제 요구를 더 또렷한 언어로 정의하는 과정이었어요.

놓칠 걱정 대신 우선순위 고민하기

이제 할 일을 보기 위해 슬랙이나 노션을 열지 않아요. 위젯이 늘 화면 위에 떠 있으니까요. 별것 아닌 것 같지만, 저는 하루에도 수십 번 "할 일이 뭐였더라?" 하며 다른 창을 열고 있었더라고요. 불편한 줄도 모르던 불편이 사라진 거예요.

진짜 달라진 건 제 머릿속이에요. 예전에는 할 일을 모으고 정리하는 데 계속 에너지를 썼어요. 지금은 그 일을 AI가 대신 해주니까, 저는 무엇부터 해야 하는지만 고민하면 돼요. 무언가 놓칠 것 같은 불안감이 없으니, 우선순위를 판단하는 데 더 많은 시간을 쓰게 됐죠.

사실은 모두의 문제였다

저 혼자 쓰려고 만든 도구였지만, 지금은 팀의 많은 분들이 사용하고 있어요. 돈 주고서라도 쓰고 싶은 서비스라고 말씀해 주신 분도 계시고요.

특히 개발자분들의 반응이 의외였어요. 저는 개발자분들은 이미 더 좋은 도구를 쓰고 있거나, 필요하면 직접 만들어서 해결할 거라고 생각했거든요.

그런데 오히려 먼저 찾아와 버그를 제보하고 기능을 제안해주시더라고요.

평소에는 디자이너인 제가 개발자분들께 "이것 좀 고쳐주세요"라고 요청하는 입장이었는데, 이번에는 반대의 그림이 펼쳐진 거죠.

개발자분이 버그를 알려주고, 제가 수정해서 다시 배포하는 모습이요.

그 역할이 뒤바뀐 것도 신기했지만, 그보다 더 흥미로웠던 건 제가 개인적인 문제라고 생각했던 불편이 사실은 여러 사람이 함께 겪고 있는 문제였다는 점이었어요. 할 일을 정리하고, 우선순위를 관리하고, 흩어진 맥락을 모으는 일은 직무와 상관없이 많은 사람들이 비슷하게 겪고 있었던 거죠.

이 위젯이 퍼진 이유도 획기적인 아이디어여서가 아니라, 많은 사람들이 이미 겪고 있던 불편을 해결했기 때문인 것 같아요. 회사에서 제품을 디자인할 때도 마찬가지잖아요. 새로운 문제를 찾는 것보다, 이미 겪고 있는 문제를 해결하는 게 더 중요하니까요.

적용해보기