커피챗은 30~45분짜리 가벼운 대화입니다. 카페든 화상 통화든 상관없습니다. 화이트보드도, 면접관 패널도, 함정 질문도 없습니다. 저는 우리가 뭘 왜 만드는지 이야기하고, 상대는 지금 뭘 하고 있고 다음에 뭘 원하는지 이야기합니다. 그것만으로도 더 깊은 대화가 의미 있을지 양쪽 다 알게 되죠. 채용은 선발 문제라기보다 매칭 문제이고, 매칭에 필요한 정보를 교환하는 데 이보다 빠른 방법을 저는 모릅니다.

왜 계속하는가

#

저는 이 대화를 “채용 활동"이라고 생각하는 걸 그만뒀습니다. 그냥 대화입니다. 그리고 그중 몇 개가 잊을 만하면 채용으로 이어집니다. 상대의 상황이 바뀐 18개월 뒤에 성사되기도 하고요. 좋은 채용을 꾸준히 만들어내는 파이프라인은 채용 공고가 아니라 이런 관계의 축적으로 이루어져 있습니다.

직무 기술서 문제도 해결해 줍니다. JD는 어쩔 수 없이 일반적으로 쓰입니다. 커피를 사이에 두면 후보자가 정말 궁금한 걸 물을 수 있습니다. 첫 6개월에 뭘 해내면 성공인지, 누구와 일하게 되는지, 팀이 지금 씨름 중인 제일 골치 아픈 기술 문제가 뭔지. 이런 질문에 솔직한 답을 들은 사람은 자기와 맞는지 스스로 잘 판단합니다.

그리고 커피챗은 문화를 “설명"하는 대신 “보여"줍니다. 준비해 왔는지, 진짜 호기심이 있는지, 상대의 시간을 존중하는지. 어떤 채용 페이지보다 많은 걸 말해주죠. 이건 반대 방향으로도 작동합니다. 긴장이 풀린 대화에서의 모습은 연습된 면접보다 함께 일할 사람에 대해 훨씬 많은 걸 알려줍니다.

특히 효과가 좋은 순간은 이렇습니다. 이직 생각이 없는 사람에게 다가갈 때, 정식 절차 전에 추천받은 사람과 미리 안면을 틀 때, 커리어 전환(IC에서 매니지먼트로, 스타트업에서 대기업으로, 혹은 그 반대)을 고민하는 사람과 이야기할 때. 인재 쟁탈전이 벌어지는 시장에서는 원하는 사람 대부분이 이 셋 중 하나에 해당합니다.

진행 방식

#

첫 메시지가 전부를 결정합니다. 템플릿 같은 접근은 그냥 삭제당합니다. 사전 조사를 하고, 의도를 솔직하게 씁니다.

“안녕하세요 Sarah님, QCon에서 하신 분산 시스템 발표와 이벤트 소싱에 대한 블로그 글을 잘 봤습니다. [회사]에서도 결제 인프라를 확장하면서 비슷한 문제와 씨름하고 있습니다. 30분 커피챗 어떠세요? 면접 의제는 없습니다—그저 관점을 듣고 저희가 하는 일을 공유하고 싶을 뿐입니다.”

이게 통하는 이유는 구체적이고, 의도를 숨기지 않고, 시간만 달라고 하는 게 아니라 “흥미로운 문제에 대한 대화"라는 가치를 내밀기 때문입니다. 그다음은 상대의 수고를 줄여주는 일입니다. 시간 옵션을 몇 개 제시하고, 상대에게 편한 장소(온라인이라면 다운로드가 필요 없는 화상 도구)를 고르고, 내용이 명확한 캘린더 초대를 보내서 아무것도 추측하게 만들지 않는 겁니다.

대화 자체는 느슨한 틀이면 충분합니다. 처음 몇 분은 진짜 스몰토크와 연락한 이유. 다음은 상대의 이야기입니다. 지금 하는 일, 즐거운 것, 답답한 것, 다음에 원하는 것. 여기서 할 일은 말하기보다 듣기입니다. 그다음이 우리 이야기입니다. 미션과 팀이 실제로 안고 있는 과제를, 힘든 부분까지 포함해서요. 후보자는 투명함을 존중하고, 영업 냄새는 귀신같이 맡습니다. 가장 값진 구간은 후반의 열린 시간인데, “어떤 조건이 갖춰지면 이직을 고려하시겠어요?“를 함께 탐색합니다. 마무리는 다음 단계를 분명히. “계속 연락하고 지내요” 정도라도 괜찮습니다.

끝나면 24시간 안에 대화 속 구체적인 내용을 언급한 짧은 감사 메시지를 보냅니다. 약속한 건(소개든 링크든) 바로 전달하고요. 이런 심심한 뒷정리야말로 회사 문화를 진짜로 보여주는 대목입니다.

이걸 꾸준히 할 거라면, 대화한 사람들을 간단한 스프레드시트로 관리하고 자리가 없을 때도 가끔 안부를 물어보세요. 매니저 전용 활동으로 둘 필요도 없습니다. 엔지니어들이 자기 네트워크의 멋진 사람들과 커피를 마시는 것. 좋은 리퍼럴은 대개 거기서 시작됩니다.

써먹을 수 있는 질문들

#

제가 자주 묻는 것:

• “최근에 작업한 것 중 제일 흥미로웠던 문제는 뭐였나요?”
• “다음 직장에서는 뭐가 달라졌으면 하나요?”
• “어떤 방식으로 배우는 게 잘 맞나요? 앞으로 어떻게 성장하고 싶으세요?”
• “핏이 맞을지 판단하는 데 도움이 될 만한, 궁금한 게 있으신가요?”

제가 후보자 쪽이라면 물어볼 것:

• “팀이 지금 마주한 가장 큰 과제는 뭔가요?”
• “이 역할의 성공은 어떻게 측정하나요?”
• “승진 경로는 어떻게 되나요?”
• “왜 이 회사에 오셨어요? 왜 계속 계신가요?”
• “여기서 일하는 것에 대해, 제가 들으면 의외라고 할 만한 게 있나요?”

커피챗 제안을 받은 쪽이라면

#

커피챗이 무슨 뜻인지 찾아보는 사람은 대부분 저와 테이블 반대편에 앉는 쪽입니다. 누군가에게 커피챗 제안을 받았고, 어떤 자리에 나가게 되는 건지 알고 싶은 거죠. 초대를 보내는 쪽에서 해 드리고 싶은 이야기는 이렇습니다.

면접이 아닙니다. 아무도 점수를 매기지 않고 테스트도 없으니 모범 답안을 준비할 필요는 없습니다. 그래도 첫인상인 건 맞으니, 친구의 친구를 만난다기보다 미래의 동료를 만난다고 생각하세요. 면접과 다른 점은 마음껏 궁금해해도 된다는 것, 그리고 대답하는 만큼 질문도 하길 기대받는다는 것입니다.

복장은 그 회사에 평범한 날 출근할 때 입을 법한 옷이면 됩니다. 잘 모르겠으면 깔끔한 캐주얼이 틀릴 일은 없습니다. 화상 통화라면 카메라를 켜고 조용한 방을 찾으세요. 셔츠보다 그게 더 중요합니다.

준비는 30분 정도면 충분합니다. 그 회사가 뭘 만드는지, 상대가 쓴 글이나 만든 게 있다면 읽어 보세요. 지금 하는 일과 다음에 하고 싶은 일을 2분 안에 말할 수 있게 정리해 두세요. 그 질문은 반드시 나오니까요. 직접 물어볼 질문도 두세 개 챙겨 가세요. 위의 질문 리스트로 시작해도 괜찮습니다.

무슨 이야기를 할지는 이렇습니다. 내 일, 그 일에서 즐거운 부분, 상대의 일에서 궁금한 부분. 연봉 이야기는 상대가 먼저 꺼내지 않는 한 나중으로 미루세요. 염두에 둔 포지션이 있는지, 있다면 절차가 어떻게 되는지 묻는 건 전혀 문제없습니다.

계산은 보통 초대한 쪽이 합니다. 내겠다고 말은 하되, 계산대 앞에서 실랑이까지 할 필요는 없습니다. 하루 안에 실제로 나눈 이야기를 하나 언급한 짧은 감사 메시지를 보내면, 이미 대부분의 사람보다 잘한 겁니다.

그리고 만나 보고 싶은 사람이 있다면 직접 커피챗을 요청하세요. 메시지는 짧게, 왜 하필 그 사람인지 밝히고, 수락하기 쉽게 만드는 게 요령입니다. “팀에서 진행하신 새 검색 기능 작업을 계속 지켜보고 있었습니다. 저도 플랫폼 엔지니어링 쪽으로 옮기는 걸 고민하고 있는데, 몇 주 안에 30분 정도 커피나 통화 가능하실까요? 시간은 편하신 대로 맞추겠습니다.” 이 정도로 구체적인 요청이면 대부분 응해 줍니다.

망치는 방법들

#

제일 빠른 건 몰래 면접으로 바꾸는 겁니다. 기술 역량을 테스트하거나 행동 면접 질문을 슬쩍 끼워 넣는 순간 암묵적인 약속은 깨집니다. 그건 정식 프로세스를 위해 아껴두세요. 그다음이 과한 영업입니다. 오래 남는 채용은 힘든 부분까지 다 보고 들어온 사람들에게서 나옵니다. 준비 없이 나타나는 것, 끝나고 연락이 끊기는 것도 조용히 타격을 줍니다. 커피챗 한 번의 인상이, 그 사람이 자기 네트워크에 여러분 회사를 어떻게 이야기할지를 정하니까요.

제 쪽에서 보는 위험 신호는 이렇습니다. 아무것에도 호기심이 없는 후보자, 완전히 거래처럼 느껴지는 대화, 과거 직장을 전부 똑같은 원망조로 이야기하는 사람. 후보자도 자기만의 리스트를 갖고 있어야 합니다. 일의 의미를 설명하지 못하는 담당자, 이직률이나 회사 방향에 대한 얼버무림, 여러분을 이해하기보다 팔아넘기는 데 열심인 상대.

모든 커피챗이 어딘가로 이어지는 건 아닙니다. 사실 대부분은 안 이어져요. 그래도 괜찮습니다. 중요한 건, 다음에 핵심 포지션을 채워야 할 때 백지 채용 공고가 아니라 쌓여 있는 진짜 대화들에서 시작할 수 있다는 점입니다. 직무 기술서 말고, 커피 한잔하자는 초대를 보내세요.

추가 읽기

#

이 사이트의 관련 글:

• 개발자 면접에서 STAR 방식을 쓰는 이유 - 커피챗이 정식 면접 프로세스로 이어졌을 때를 위해
• 새로 엔지니어링 매니저가 되면서 집중하기로 한 세 가지 - 팀을 굴러가게 하는 것이 무엇인지. 결국 매칭에서 봐야 할 것들입니다
• 스타트업에서 인턴을 해야 하는 이유 - 스타트업행을 고민하는 사람과 이야기할 때의 배경 지식으로

외부 리소스:

• First Round Review: 엔지니어 채용 - 경험 많은 운영자들이 쓴 스타트업 채용 가이드
• Lara Hogan의 “첫 1:1을 위한 질문” - 1:1용으로 쓰였지만 커피챗에서도 그대로 잘 먹힙니다
• Patrick McKenzie의 연봉 협상 글 - 후보자 쪽 시각을 이해하는 데 좋습니다
• Who: 채용의 A 메소드 - Geoff Smart와 Randy Street의 체계적인 채용 프레임워크
• Harvard Business Review: 채용 - 인재 확보에 대한 연구 기반 글 모음

Alan이 회의를 포기한 이유

#

출발점은 누구에게나 익숙할 겁니다. 아무도 준비를 안 해오고, 시작은 늦어지고, 목소리 큰 사람이 옳든 그르든 결론을 가져갑니다. 한 시간 뒤엔 들어가기 전보다 머리가 더 복잡해져서 서랍에 진통제가 남아 있나 뒤적이게 되죠.

Alan도 처음엔 회의를 고쳐 보려 했습니다. 최대 15분, 명확한 안건, 반드시 결정 도출. 그래도 안 됐습니다. 논의는 삼천포로 빠지고, 무슨 얘기가 오갔는지 아무도 기억 못 하고, 결석자나 원격 근무자는 그냥 소외됐습니다. 그래서 통째로 글로 옮기기로 한 겁니다.

그들이 내세우는 효과는 수긍이 갑니다. 글을 쓰려면 멈춰서 생각할 수밖에 없으니 논의가 더 정교해지고 근거도 탄탄해집니다. 모든 게 기록으로 남아 어렴풋한 기억에 기댈 필요가 없고, 더 이상 웅변 대회도 아닙니다. 게다가 포럼이 전사에 공개되어 있으니, 마침 회의실에 있던 사람만이 아니라 누구든 논의에 낄 수 있습니다.

사내 포럼이 된 GitHub

#

그 포럼의 정체는 GitHub입니다. 원래 코드 리뷰용으로 만들어진 플랫폼을 Alan이 당당하게 용도 변경한 거죠. 세팅은 민망할 정도로 간단합니다.

1. GitHub 계정을 만든다.
2. 코드가 없는 비공개 저장소를 만든다(Alan의 저장소 이름은 “Topics”).
3. 대화를 분류할 라벨 체계를 만든다.
4. Issues 탭을 쓴다. 열린 이슈는 진행 중인 논의, 닫힌 이슈는 내려진 결정.

이들의 이슈는 17,000개를 넘었습니다. 열리지 않아도 됐던 회의가 그만큼이라는 뜻이고, 제가 가장 탐나는 부분은 이겁니다. 모든 결정이 “왜 그렇게 됐는지” 검색 가능한 역사로 남는다는 것. 옛날 결정에 이의를 제기하고 싶으면, 지난번엔 어떤 논거가 이겼는지부터 읽어볼 수 있습니다.

언제 이슈를 여는가

#

모든 결정이 이슈감은 아닙니다. 그들의 필터는 네 가지 질문입니다. 누가 영향을 받는가? 얼마나 되돌리기 쉬운가? 얼마나 급한가? 결정하려면 맥락이 더 필요한가?

대략, 영향이 크고 되돌리기 어려운 결정은 포럼으로 가고 나머지는 Slack에서 끝냅니다. 일방향/양방향 문이라는 구분도 씁니다. 일방향 결정(되돌리는 데 비용과 수고가 너무 큰 것, 예시로 든 건 요금 인상)은 풀코스로 글쓰기를 거치고, 양방향 결정(취소가 싸고 최악이라야 에너지 좀 잃는 것)에는 그런 격식이 필요 없습니다.

LOCI: 누가 무엇을 하나

#

모든 논의에는 LOCI 모델(Lead, Owner, Consulted, Informed)로 역할이 배정됩니다.

Lead는 결정의 성패에 책임을 지고, 결정의 배경이 팀에 제대로 이해되도록 합니다. 논의 초반에 자기가 어디까지 관여할지 밝혀 두고, 그다음엔 Owner를 믿고 팀의 결과물에 책임을 지되, 강하게 반대할 때만 목소리를 냅니다. 논의당 Lead는 한 명입니다.

Owner는 최종 결정을 내리고 프로젝트를 끌고 갑니다. 기여자들이 논의 내용을 알고 제때 의견을 내도록 챙기고, 문제를 조사하고, 이슈를 열고 닫고, 결정을 공유합니다. 혼자 못 넘는 벽에 부딪히면 Lead를 찾아갑니다. 결정당 Owner도 한 명입니다.

Consulted는 트레이드오프 판단에 의견이 정말로 필요한 사람들입니다. “덧붙일 게 없습니다” 한 줄이라도 제때 기여할 의무가 있고, 결정이 크게 잘못됐다고 판단하면 경보를 울리고 필요하면 Lead에게 에스컬레이션합니다. Alan은 이 그룹을 6명 정도로 제한합니다. 의견이 그보다 많아지면 일정이 밀리기 시작하기 때문입니다.

Informed는 대개 결정이 난 뒤에 통보만 받는 사람들입니다. 소통은 일방향이고 아무 기여도 기대되지 않습니다. 누구에게 알릴지는 영향 범위를 따져 Owner가 정합니다.

여기까지는 결정 하나 단위의 이야기입니다. 프로젝트 전체로 보면 저는 같은 내용을 프로젝트 커뮤니케이션 계획으로 한 번 정리해 둡니다. 누가 무엇을, 얼마나 자주, 누구에게서 전달받아야 하는지를 적은 표입니다.

이슈 해부도

#

모든 이슈는 같은 템플릿을 씁니다. 생각이 다듬어지는 건 물론이고, 주니어에게 문제를 쪼개는 법을 가르치는 교재 역할도 합니다.

• 범위(Scope) - 논의의 “왜”. 은근히 효과가 좋은 게 “이 이슈는 ~에 관한 것이 아닙니다"라는 한 줄입니다
• 맥락과 자료 - 과거 논의와 자료 링크
• LOCI - 누가 Lead, Owner, Consulted, Informed인지
• 마감일 - 기여 마감, 이슈 닫는 날, 해결책이 필요한 시점
• 해결책 제안 - 제안하는 답 하나, 또는 고를 수 있는 선택지 몇 개
• 질문 - 특정한 사람에게, 특정한 가정을 확인하거나 반박해 달라고 묻는 것. 이슈가 “바다에 던진 유리병 편지"가 되지 않게 하는 장치입니다

논의가 늘어지지 않게 하는 글쓰기 규칙

#

글로 하는 논쟁도 말로 하는 것 못지않게 질질 끌 수 있습니다. 그래서 규칙이 있습니다. 우선 간결하게. 그들은 부알로의 “잘 구상된 것은 명료하게 진술된다"를 인용합니다. 단순하게 못 쓴다면 아직 자기 주장에 확신이 없다는 뜻입니다. 그리고 쓰는 모든 글에 “So what?” 테스트를 겁니다. 내 코멘트의 함의가 자명하지 않다면 명시적으로 적어 주는 거죠.

Owner에게는 이슈를 연 뒤의 운영이 그만큼 중요합니다. 논의를 “백만 달러짜리 질문”, 즉 진짜 중요한 단 하나의 쟁점에 계속 조준시키고 디테일의 바다에서 표류하지 않게 합니다. 합의된 것과 아직 열려 있는 것을 주기적으로 정리해서 보여 줍니다. Slack 리마인더는 최후의 수단으로, 기여가 늦어졌거나 정말 급할 때만 씁니다.

Owner는 대화를 진전시키지 못하는 댓글을 숨기기도 합니다. 그리고 제목, 각주, 표, 키보드 단축키 같은 GitHub의 서식 기능은 전원이 능숙하게 다루는 게 전제입니다. 글에서는 내용만큼 형식도 힘을 발휘하니까요.

합의도 없고, 구경꾼도 없다

#

이 시스템이 “위원회식 결정"으로 전락하지 않게 막는 장치가 두 가지 있습니다.

첫째, Owner는 Alan의 표현으로 “계몽 전제군주"로서 결정합니다. 아이디어를 조사하고, 리스크를 재고, 동료에게 질문은 하지만, 합의를 구하지 않고 들은 걸 전부 반영할 의무도 없습니다. Alan은 “우리는 민주주의가 아니다"라고 잘라 말합니다. 전원이 주주이고, 회사의 이익이 팀이나 개인의 이익보다 앞선다는 거죠. 그렇다고 고립된 졸속 결정을 바라는 것도 아닙니다. Owner가 “이 베팅이 맞다"고 어느 정도 확신하면 결정하고, 다 같이 실행해 보고, 영향이 보이기 시작하면 되돌아보며 다음에 더 잘할 방법을 찾습니다.

둘째, 기여자 수를 관리합니다. 제프 베이조스의 “피자 두 판” 규칙은 비동기에서도 유효합니다. 사람이 많아질수록 한 사람 한 사람의 기여는 줄어듭니다. 6명을 넘기면 방관자 효과가 고개를 들고 참여의 질이 떨어진다고 합니다. 알림도 같은 철학을 따릅니다. 모든 구성원이 자기 GitHub 알림을 제대로 설정해 뒀다고(Settings에서 “Participating"과 “Watching"의 “Web and Mobile” 체크) 신뢰하고, 이슈의 Questions 섹션에서 태그는 최소한으로 답니다.

내가 가져갈 것

#

회의에서 있었던 일을 그 자리에 없던 사람에게 온전히 설명하기란 불가능합니다. 하지만 글로 남은 결정은 누구나 읽을 수 있죠. Alan 스스로도 이게 최선이자 유일한 시스템이라고 하진 않습니다. 그저 자기들에게 가장 잘 맞았을 뿐이라고요. 방해가 줄고, 방관자 효과가 옅어지고, 한 걸음 물러나 사실에 기반해 결정하게 됐다는 겁니다. 저도 우리 팀의 모든 결정을 GitHub 이슈로 옮길 생각까진 없지만, 아래 템플릿은 바로 우리 저장소에 넣을 겁니다.

바로 쓰는 GitHub 이슈 템플릿

#

포럼으로 쓰는 저장소에 이 파일을 .github/ISSUE_TEMPLATE/decision.md로 저장해 두면, 누가 새 이슈를 열 때마다 GitHub가 이 템플릿을 띄워 줍니다. 섹션 구성은 Alan의 것이고, LOCI 항목과 라벨은 제가 덧붙였습니다.

---
name: 의사결정
about: 결정을 제안하고 의견을 글로 모읍니다
title: "[결정] "
labels: decision
---

## 범위
- 이 이슈의 목표는 ...
- 이 이슈는 ...에 관한 것이 아닙니다

## 이 이슈를 여는 이유

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## 타임라인
- 기여 마감:
- 결정 기한:

## 맥락과 자료

## 제안

## 질문

GitHub Issues와 GitHub Projects, 뭘 써야 할까?

#

GitHub를 좀 더 넓게 프로젝트 관리에 쓸 생각이라면, 둘은 하는 일이 다르다는 걸 알아 두면 좋습니다. Issues는 논의를 담고, 닫히고 나면 결정을 담습니다. GitHub Projects는 하나 이상의 저장소에 흩어진 이슈들 위에 얹는 보드나 테이블로, 상태나 담당자, 마감일 같은 필드를 직접 만들어 붙일 수 있습니다. Alan 같은 의사결정 포럼이라면 라벨과 이슈 목록만으로 충분합니다. 열려 있는 결정을 한 화면에서 결정 기한순으로 보고 싶어질 때, 그리고 실제 개발 업무까지 같은 곳에서 관리하기 시작할 때 Project를 더하면 됩니다. 대부분의 팀이 결국 둘 다 쓰게 되는 게 바로 그 지점이죠.

아이디어

#

한국의 노점에는 주소가 없습니다. 포장마차는 자리 잡고 싶은 곳에 자리를 잡으니까, 그 자리를 원래 아는 사람이 아니면 온라인으로는 찾을 방법이 없죠. 우리 앱은 노점을 말 그대로 지도 위에 올립니다. 노점 사장님들한테도 좋고, 밤늦게 떡볶이 파는 곳을 수소문하는 사람한테도 좋습니다.

대회 당일

#

해커톤은 Lunit Global이 주최했고 사무 공간도 제공해 줬습니다. 별별 배경의 팀들이 모였고, 대부분 밤을 새워 가며 작업했고, 운영진 덕분에 행사는 매끄럽게 굴러갔습니다. 고개를 들어 보니 어느새 새벽 4시더라, 하는 류의 행사였죠.

팀

#

팀은 Sharon Levy, Jonothan Sue, 저, 그리고 Tiaan van der Riel 이렇게 넷이었습니다. 각자 잘하는 게 달라서 일을 나누는 데 잡음이 없었습니다. 피치가 심사위원들에게 먹힌 건, 문제 자체가 설명이 필요 없었기 때문인 것 같습니다. “노점은 온라인에서 보이지 않는다"라고 소리 내어 말하는 순간 해결책이 저절로 떠오르니까요.

앞으로

#

지금은 이 앱을 스토어에 올리는 작업을 하고 있습니다. 주말 프로젝트로 시작했지만, 풀려는 문제가 진짜인 만큼 여기서 멈추면 아까울 것 같거든요.

해커톤이 처음이라면

#

해커톤을 한 번도 안 해봤다면 꼭 해보시라고 권하고 싶습니다. 처음 만난 사람들과 빠르게 뭔가를 만들고, 압박 속에서 내가 실제로 어떻게 움직이는지 알게 되고, 가끔은 계속 키워볼 만한 결과물까지 들고 나오게 됩니다. 최악의 경우라 해봐야, 공짜 간식이 깔린 주말과 아무도 시키지 않은 작동하는 프로토타입 하나를 얻는 거고요.

해커톤을 준비한다면 미리 알아 두면 좋은 것들입니다.

• 한 문장으로 설명할 수 있는 문제를 고르세요. 심사위원이 문제를 이해하는 데 첫 1분을 쓰면, 정작 해결책은 제대로 듣지 못합니다.
• 역할은 일찍, 가능하면 첫 한 시간 안에 나누세요. 누가 개발하고, 누가 디자인하고, 누가 피치를 맡을지. 새벽 2시에 그걸 정하고 있으면 대가가 훨씬 큽니다.
• 데모 경로부터 만드세요. 무대에서 보여줄 흐름 하나를 처음부터 끝까지 돌아가게 만든 다음에 나머지를 붙이는 겁니다.
• 피치는 실제 데모를 띄워 놓고 소리 내어 최소 두 번은 연습하세요. 피치는 거의 항상 생각보다 길어집니다.
• 조금이라도 자세요. 두어 시간만 자도 아침에 내리는 결정과 피치가 눈에 띄게 나아집니다.

링크:

#

https://lnkd.in/drMXUgPB