Knot · Toss Design Challenge
일정 잡기는 검색이 아니라, 협상이에요. 6명의 동료, 1시간짜리 회의, 하나의 마감, 열린 브리프에 화면 몇 장이 아니라 시스템으로 답하고 싶었어요. 문제를 다시 정의하고, 세 방향을 만들어 죽이고, 협상의 최소 단위를 찾아 동작하는 제품으로 조립한 기록이에요.Scheduling isn't a search problem, it's a negotiation. Six coworkers, one hour, one deadline; an open brief deserved more than screens, so I answered with a system: a reframe, three directions built and killed, and the smallest unit of a negotiation, assembled into a product that runs.
토스 프로덕트 디자이너 챌린지는 포트폴리오가 아니라 당신이 문제 하나를 어떻게 푸는지로만 평가하는 채용 과정이에요. 주어진 문제는 딱 하나. 동료 6명이 다음 주 전까지 1시간짜리 회의를 잡는 일을, 점심·외근·필수 vs 선택 참석 같은 실제 제약 안에서 설계하는 거예요. 제출물은 문제 정의 · 해결책 · 직접 눌러볼 수 있는 프로토타입, 그리고 세 가지 질문에 대한 답이에요. 토스가 내건 기준은 네 단어였어요. ‘문제에서 제품까지.’The Toss Product Designer Challenge judges you on one thing: how you solve a single real problem, not a portfolio. The brief is exactly one problem: design how six coworkers lock a one-hour meeting within a week, around real constraints like lunch, off-site days, and required vs. optional attendance. You submit a problem definition, a solution, and a clickable prototype, plus answers to three questions. Toss's bar, in four words: ‘from problem to product.’
여기까지 오는 동안 세 가지 방향이 죽었어요. “잘못된 시간이 잡히면, 누가 사과하나요?” 같은 질문에요.Three directions died on the way here, to questions like “when it books the wrong time, who apologizes?”
Where it actually breaks
→도구는 '모두 되는 시간 없음'에서 멈춰요. 진짜 일은 정확히 거기서 시작돼요.Tools quit at “no time works for everyone.” The real work starts exactly there.
조건은 단순해요. 같은 회사 동료 6명, 1시간짜리 회의, 다음 주 전까지. 시작 전에 정한 규칙은 한 문장으로 줄일 수 있어요. 캘린더가 이미 잘 푸는 문제는 피하고, 모든 주장은 실제로 돌아가는 것으로 검증하고, 못 푼 건 그대로 보여줄 것.The setup is simple: six coworkers, one hour, before next week. My ground rules for the challenge compress to one sentence: avoid problems calendars already solve, test every claim in something that runs, and leave the unsolved parts visible.
캘린더 도구에 6명을 넣고, 겹치는 빈 시간을 찾는다Drop six calendars into a tool and look for overlap
도구가 해줘요tools do this결과: 모두 비는 시간 없음Result: no time works for everyone
도구가 해줘요tools do this단체 채팅에 “다들 언제 가능하세요?”를 올린다Post “when works for everyone?” in the group chat
사람이 직접all manual21개의 답장 속 각자의 사정을, 주최자가 머릿속으로 조합한다The organizer mentally merges 21 replies into one picture
사람이 직접all manual“민준님이 점심을 옮기면 되려나?” 한 명씩 따로 물어보며 주최자가 메신저가 된다“Could Minjun move his lunch?”, pinging people one by one, the organizer becomes a messenger
사람이 직접all manual마감에 몰려, 최선인지 확신도 없는 시간으로 그냥 확정한다Deadline pressure wins, a time gets locked without knowing if it was the best one
사람이 직접all manual도구가 없는 게 아니에요. Doodle과 When2meet은 투표와 겹침 찾기를, Calendly는 1:1 일정을 잘 풀어요. 하지만 “모두 되는 시간 없음”이 뜨는 순간, 셋 다 문제를 주최자에게 그대로 돌려줘요. ③-⑥ 구간은 여전히 사람이 맨몸으로 버텨요.It's not that tools don't exist. Doodle and When2meet solve polling and overlap; Calendly solves one-on-ones. But the moment “no time works for everyone” appears, every one of them hands the problem straight back to the organizer. The ③-⑥ stretch stays manual.
일정 잡기는 검색이 아니라, 여러 사람이 함께 결정을 내려가는 과정이에요. 초대 → 거절 → 재초대가 반복될 때마다 이미 쌓인 맥락이 사라지고, 주최자는 메신저가 돼요. 그래서 목표를 바꿨어요. '시간 찾기'가 아니라, 맥락을 잃지 않고 협상을 끝까지 끌고 가기.Because scheduling isn't a search, it's a group trying to make a decision together. Every invite → decline → re-invite cycle shreds the context already built, and the organizer becomes a messenger. So the design target changed: not “find a time,” but carry the negotiation to done without losing its context.
Feelings, then requirements
→세 가지 사회적 눈치가 그대로 스펙이 됐어요. 모든 화면은 이 감정들에 채점받아요.Three social fears became the spec. Every screen that follows is graded against them.
조율이 불편한 이유는 기능이 부족해서가 아니라, 모두가 서로에게 부담을 주지 않으려고 애쓰기 때문이에요. 세 역할의 감정을 먼저 적었고, 이게 이후 모든 화면의 채점 기준이 됐어요.Scheduling feels bad not because a feature is missing, but because everyone involved is managing someone else's feelings. I wrote those feelings down first, and they became the rubric every later screen was graded against.
“괜히 귀찮게 하는 건 아닐까”“Am I being a burden?”
모두를 배려하는 '정답'을 찾아야 한다는 책임감, 그리고 재조율할 때마다 이유를 일일이 설명해야 하는 부담을 느껴요.Feels responsible for finding the considerate “right” answer, and dreads having to explain every reschedule.
“내가 걸림돌이 되긴 싫어”“I don't want to be the blocker”
거절할 이유를 정당화해야 할 것 같은 압박을 느끼고, 웬만하면 어떻게든 맞춰보려고 해요.Feels pressure to justify saying no, and often forces a “yes” that isn't quite true.
“내가 진짜 필요한가?”“Do they actually need me?”
본인의 필요성을 스스로 판단하기 어려워서, 예의상 일단 수락하는 경우가 많아요.Can't judge their own necessity, so they accept out of politeness alone.
이 세 가지 감정이 그대로 요구사항이 됐어요. 전체에게 뿌리는 질문을 만들지 않는다. 누구에게도 자기 몫보다 큰 결정을 요구하지 않는다. 답할 게 없는 사람에게는 아무것도 보내지 않는다.Those three feelings became the spec. Never broadcast an ask to the whole group. Never ask anyone to decide beyond what they personally own. If someone has nothing to answer, send them nothing.
Three dead ends, three kill questions
→그럴듯한 데모는 쉽게 나와요. 그래서 방향마다 죽일 질문을 하나씩 붙였어요.Plausible demos are cheap. So every direction got one question designed to kill it.
AI가 모두를 대신해 협상AI negotiates on everyone's behalf
킬 퀘스천: 잘못된 시간이 잡히면, 누가 사과하나요?Kill question: when it books the wrong time, who apologizes?
답할 수 없었어요. 책임과 공감은 위임이 안 돼요. AI는 대화를 구조화할 수 있을 뿐, 사람 사이의 결정을 대신하는 순간 관계 자체가 대리자를 통한 것처럼 멀어져요.No answer survived. Accountability and empathy can't be delegated. AI can structure the conversation, but the moment it decides between people, the relationship itself starts feeling outsourced.
채팅 중심 경험Chat-first experience
킬 퀘스천: 지금 상태는 어디에 있나요?Kill question: where does the current state live?
피드 어딘가에요. 그게 문제예요. 조율은 시간순이 아니라 공간적인 문제인데, 채팅은 모든 정보를 시간순으로 묻어버려요. 결정의 현재 상태를 한눈에 보여줄 수 없는 구조였어요.Somewhere up the feed, which is the problem. Coordination is spatial, not chronological, and chat buries state under recency. The structure physically can't show where the decision stands.
시간 슬롯에 대화를 붙이기Conversations anchored to time slots
킬 퀘스천: 그 시간이 사라지면, 대화는 어디로 가나요?Kill question: when the slot dies, where does the conversation go?
같이 사라져요. 시간 슬롯은 협상 중에 계속 바뀌는 임시값이에요. 대화는 바뀌지 않는 것에 붙어야 해요. 이 기각이 결정적이었어요. 앵커를 '해결되지 않은 이슈'로 옮기는 순간, 다음 섹션의 답이 보였거든요.It dies with it. Slots are the one thing guaranteed to keep changing mid-negotiation; conversation has to attach to something that persists. This rejection was the productive one, moving the anchor to the unresolved issue itself pointed straight at the next section.
The primitive
→기능은 쌓이지만, 단위는 조립돼요. Knot는 협상 토큰 하나에서 조립된 제품이에요.Features pile up; units compose. Knot is assembled from a single unit: the negotiation token.
Figma에 도형이, GitHub에 Pull Request가, Linear에 Issue가 있듯, 이 문제에도 모든 상호작용이 조립되어 나오는 원자 단위가 있어야 한다고 생각했어요. 그 단위를 찾은 뒤에야 제품에 이름을 붙일 수 있었어요. '매듭짓다', 끝을 맺는다는 뜻의 Knot예요.Figma has the shape. GitHub has the pull request. Linear has the issue. I wanted this product's version: the atomic unit every interaction composes out of. Only after finding it could the product earn its name, Knot, as in tying one.
협상 토큰 (Negotiation Token)The Negotiation Token
협상 가능한 정보의 최소 단위예요. 질문과 소유자, 그리고 답변이 만드는 효과를 하나로 묶었어요. 캘린더가 알 수 있는 애매함(임시 일정, 반복되는 점심, 종일 '외근?')은 시스템이 자동으로 토큰으로 만들고, 사람만 아는 사정은 주최자가 직접 토큰으로 만들어요. 토큰이 하나씩 매듭지어질 때마다, 회의 시간도 매듭에 가까워져요.The smallest unit of negotiable information: a question, an owner, and the effect an answer has, bundled into one thing. Ambiguity a calendar can see, tentative holds, recurring lunches, an all-day “offsite?”, becomes tokens automatically; things only a human knows become tokens the organizer writes by hand. Every token that gets tied down pulls the meeting one knot closer to settled.
이 단위가 2번 섹션의 요구사항을 구조적으로 보장해요. 토큰은 정의상 한 사람에게, 그 사람 몫의 질문 하나만 던질 수 있거든요. 원칙을 지키라고 팀에게 부탁하는 대신, 원칙을 어길 수 없는 단위를 만들었어요.This unit structurally enforces the spec from section 02: a token, by definition, can only ask one person one question they alone own. Instead of asking a team to honor a principle, the unit makes the principle impossible to violate.
Try it yourself
→주장은 실행돼야 검증돼요. 직접 눌러보세요.Claims have to run to be tested. Click through.
질문이 해소되면 최적 시간이 진짜로 바뀌어요. 주최자와 참석자는 필요한 게 완전히 달라서, 각자의 화면을 각자가 실제로 쓸 기기 그대로 만들었어요. 언어는 이 페이지의 KO/EN 설정을 따라가요.Resolving a question genuinely changes the best available time. Organizers and attendees need completely different things, so each surface lives in the device it would really run on. Both follow this page's KO/EN setting.
미팅을 설계하고 진행 상황을 봐요Sets up the meeting, watches it converge
이메일 하나에, 질문 하나로 답해요One email, one question, one answer
The decisions you clicked past
→두 화면 모두 하나의 질문에 답해요. 다른 사람의 주의력을 얼마나 아낄 수 있는가.Both surfaces answer one question: how little of other people's attention can this spend?
주최자에게는 판을 보는 보드를, 참석자에게는 배울 게 없는 30초를 줬어요. 계정도 앱도 없이, 이메일 한 통과 웹페이지 하나로요. 방금 프로토타입에서 지나쳤을 결정들이에요.The organizer gets a board that shows the whole game; the attendee gets thirty seconds with nothing to learn, no account, no app, one email and one web page. These are the decisions you just clicked past.
플로우는 캘린더를 읽기 전에 목표·마감·선호부터 물어요. 겹치는 시간만으로는 수요일과 금요일 중 뭐가 나은지 판단할 수 없어요. 의도가 있어야 순위가 생겨요.The flow asks for goal, deadline, and preference before it ever reads a calendar. Overlap alone can't rank Wednesday against Friday; intent can. It's what separates finding times from recommending one.
'지금 확정 가능한 시간'은 이미 되는 시간 하나를 맨 위에 고정해요. 최적화가 회의를 인질로 잡으면 안 돼요. 주최자는 언제든 협상을 멈추고 안전한 답으로 확정할 수 있어요.“Lockable right now” pins the one already-working time to the top. Optimization must never hold the meeting hostage: the organizer can stop negotiating and take the safe answer at any moment.
보내기 전에, 누가 이메일을 받고 누가 아무것도 받지 않는지 화면에 그대로 적혀 있어요. 여기서 쓰는 자원은 다른 사람의 주의력이니까, 청구하기 전에 명세서부터 보여줘요.Before anything sends, the screen states exactly who gets an email and who hears nothing. The resource being spent is other people's attention, so the interface shows the bill before charging it.
실제 이메일이 주최자의 이름으로 나가요. 확인 단계에서 수신자와 각자가 받을 질문을 그대로 보여주고, 시간이 확정되면 열려 있던 질문은 스스로 닫혀요. 누구의 받은편지함에도 좀비 질문을 남기지 않아요.Real emails go out under the organizer's name, so a confirmation lists each recipient and their single question, and locking a time closes every open question automatically. No zombie asks left in anyone's inbox.
질문에는 이유가 함께 와요. '지금 그 시간에 점심이 걸려 있어요. 옮길 수 있으면 수요일 2시가 열려요.' 이유 없는 부탁은 부탁이 아니라 요구예요.The question arrives with its reason: “your lunch sits on that slot, if it can move, Wednesday 2 PM opens.” A favor without a reason is a demand.
예/아니오가 아니라 '네, 12시 30분으로 옮길게요'와 '아니요, 점심시간은 고정이에요'예요. 버튼 바로 아래엔 '이 답변은 주최자에게만 전달돼요'라고 적어서, 망설임이 생기는 자리에서 사회적 노출을 낮췄어요. 답하면 '방금 답변으로 수요일 2시가 열렸어요'라고 효과를 보여줘요.Not Yes and No, but “Yes, moving it to 12:30” and “No, lunch is fixed.” Directly beneath them: “this answer goes to the organizer only”, privacy stated exactly where hesitation lives. And answering closes the loop: “your answer just opened Wednesday 2 PM.”
'이 창은 닫으셔도 괜찮아요. 확정되면 캘린더 초대로 알려드릴게요.' 끝났다는 것과 다음에 일어날 일을 분명히 말해요. '된 건가?' 하는 찜찜함을 남기지 않아요.“This tab is safe to close. You'll get a calendar invite once it's locked in.” The flow says it's over and names what happens next, no lingering “did that even work?”
The edges I left visible
→판단이 멈춘 지점을, 일부러 페이지에 남겼어요.Where my judgment stopped is on the page, on purpose.
이 구조, 첫 도입을 버틸까요?Does this survive first contact with adoption?
참석자는 처음 보는 서비스가 보낸 이메일에 답해야 하고, 주최자는 가치를 확인하기도 전에 캘린더 접근부터 허용해야 해요. 이 닭과 달걀이 진짜 보스전인데, 이번 라운드는 그 싸움을 하지 않았어요. 다음 라운드의 첫 질문이에요.Attendees must answer email from a tool they've never heard of; organizers must grant calendar access before seeing any value. That chicken-and-egg is the real boss fight, and this pass deliberately didn't fight it. It's the first question of the next round.
해소는 되돌릴 수 있어야 할까요?Should a resolved token be reversible?
지금은 한 토큰의 답이 다른 토큰을 다시 막을 수도 있어요. 도윤님이 “안 된다”고 답하면 화요일이 다시 막혀요. 이 되돌림이 조용히 일어나면 아무도 몰라요. 누군가에게는 알려져야 해요.One answer can silently re-block a time someone else already relied on, Doyun saying “no” re-blocks Tuesday. If that happens quietly, no one finds out. Someone downstream needs to be told.
이진 선택 너머의 답변은요?What happens beyond a binary answer?
지금은 모든 토큰이 두 개의 답 중 하나로 끝나요. 실제 협상에서는 예상 못 한 제3의 대안이 자주 나와요. 이번엔 이진 선택을 의도적으로 지켰지만, 그 다음 단계는 열려 있어요.Every token resolves to one of two pre-written answers. Real negotiation often produces a third option nobody anticipated. I kept it binary on purpose for this pass; that's the next real question.
How I used Claude
→AI는 산출량을 늘려요. 킬 퀘스천과 기준은 제 몫이었어요.AI multiplies output. The kill questions and the standards stayed mine.
모든 화면과 카피, 두 프로토타입을 Claude와 함께 만들었어요. 두 언어도 번역이 아니라 각각 따로 썼어요. 그중 판단이 실제로 갈린 순간 세 가지예요.Every screen, the copy, and both prototypes were built with Claude, including writing the two languages separately rather than translating one from the other. Three moments where the judgment actually diverged:
빠르게 펼치고, 제 기준으로 걸렀어요Explored fast, filtered by my standard
3번 섹션의 세 방향 모두 Claude와 함께 빠르게 만들어본 것들이에요. 죽인 건 제 킬 퀘스천이었어요. 첫 제안을 그대로 쓴 게 아니라요.All three dead ends in section 03 were directions Claude and I built fast. What killed each one was my kill question, not the first proposal, taken as given.
하나의 보드를 둘로 쪼갰어요Killed the single board
첫 버전은 모든 역할을 한 보드에 담으려 했어요. 주최자와 참석자가 필요한 게 완전히 다르다는 걸 알아채고, 데스크톱과 모바일로 완전히 분리하도록 방향을 다시 잡았어요.The first pass showed every role on one board. I caught that organizers and attendees need entirely different things and redirected the build into a fully separate desktop flow and mobile flow.
같은 버그를 세 번 돌려보냈어요Sent the same bug back three times
겉으로 그럴듯한 수정에 만족하지 않고 왜 다시 생기는지 계속 물었어요. 결국 원인 패턴을 찾아서, 한 곳이 아니라 전체의 원칙으로 적용했어요.I refused each fix that merely looked right and kept asking why it returned, until we found the causing pattern and applied it as a rule everywhere, not a patch in one spot.
Three questions, answered
이 챌린지는 결국 세 가지 질문에 답하는 일이에요. 2026년에 제출했고, 제 답은 이래요.This challenge ultimately asks three questions of every submission. Submitted in 2026; here are my answers.
도구는 겹치는 시간 찾기에 최적화돼 있지만, 진짜 어려움은 눈치를 보는 사람들이 합의에 도달하는 과정이에요. 초대와 거절이 반복될 때마다 쌓인 맥락이 사라지는 게 근본 원인이었어요.Tools optimize for finding overlap; the real difficulty is people, each managing social pressure, converging on a decision, while every invite/decline cycle throws away the context already built.
협상을 '협상 토큰'이라는 최소 단위로 쪼갰어요. 각 토큰은 답을 아는 단 한 사람에게 작은 질문 하나를 던지고, 답이 쌓일수록 최적 시간이 좁혀져요.I broke the negotiation into tokens, each asks one tiny question of the one person who owns the answer, and every answer narrows the field toward a single best time.
세 방향을 만들어보고 킬 퀘스천으로 버렸어요. 살아남은 건 “아무도 자기 몫보다 큰 결정을 하지 않는다”는 구조였고, 토큰은 그 제약에서 자연스럽게 떨어져 나온 단위예요.I built and killed three directions by their kill questions. What survived was a structure where no one decides beyond what they personally own, and the token is the unit that falls out of that constraint.
