UI가 끝이 아니다
많은 초보 프디들이 착각하는 것이 있다. 화면을 다 그리면 내 역할이 끝났다고 생각하는 것이다. 틀렸다. UI 완성은 절반이다. 나머지 절반은 장표, QA, 그리고 PR에 있다.
발표를 위한 장표 디자인하기
개발자들이 개발하는 동안, 디자이너는 장표를 만들어야 한다. 개발이 끝나길 기다리다가 발표 직전에 장표를 급하게 만드는 실수를 하지 말자. 개발과 장표 작업은 반드시 병행해야 한다.
발표 장표는 단순한 보고서가 아니다. 우리 서비스를 세상에 처음 소개하는 무대다. 심사위원들은 짧은 시간 안에 여러 팀의 발표를 듣는다. 그 짧은 시간 안에 서비스의 가치를 각인시켜야 한다. 텍스트로 가득 찬 슬라이드는 읽히지 않는다. 시각 자료로 말하자.
장표의 흐름은 정해진 답은 없지만 대부분 문제정의 > 솔루션 > 핵심 기능 > 기대효과 순으로 전개해나간다.
① 문제정의 — 근거로 설득하기
"이런 문제가 있습니다"라고 말만 하면 설득력이 없다. 근거가 필요하다. 가장 강력한 근거는 직접 진행한 사용자 인터뷰다. 실제 유저의 말 한 마디는 어떤 통계보다 생생하게 와닿는다. 인터뷰이의 말을 그대로 인용하거나, 공통적으로 발견된 패턴을 시각화해서 보여주자.
만약 인터뷰를 진행하기 어려운 상황이었다면, 공신력 있는 공식 데이터를 활용하는 것도 좋다. 통계청, 한국리서치같은 기관의 조사 결과나 관련 산업 리포트를 찾아보면 생각보다 쓸 만한 데이터가 많다. 출처만 명확히 표기하면 충분히 설득력 있는 근거가 된다.
② 솔루션 — 연결고리를 보여주기
문제를 정의했다면, 우리의 솔루션이 왜 그 문제를 해결할 수 있는지 연결고리를 명확하게 보여줘야 한다. "이런 기능을 만들었습니다"가 아니라 "이 문제 때문에 이런 기능이 필요했고, 그래서 이렇게 만들었습니다"의 흐름이 되어야 한다.
③ 핵심 기능 — 디테일보다 컨텍스트
핵심 기능을 설명할 때 가장 흔하게 하는 실수는 기능의 디테일에 집착하는 것이다. 버튼이 어디 있고, 컬러가 어떻고, 인터랙션이 어떻게 동작하는지를 설명하다 보면 정작 중요한 걸 놓친다.
심사위원이 알고 싶은 건 이거다. "이 기능이 유저의 어떤 문제를 어떻게 해결해주는가." 기능 하나하나를 나열하는 대신, 유저가 이 서비스를 쓰는 맥락 안에서 기능이 어떤 역할을 하는지를 보여주자. 유저 플로우를 따라가며 설명하거나, 핵심 기능 화면 한두 개만 골라서 임팩트 있게 보여주는 편이 훨씬 효과적이다.
발표 시 가장 효과적인 건 시연 영상으로 동작하는 것을 보여주는 것이다. 만약 그게 어렵다면 프로토타입으로 만들어 영상을 제작하는 것도 한 가지 방법이다.
④ 기대 효과 — 숫자로 마무리
마지막은 이 서비스가 실제로 만들어내는 변화를 보여주는 것이다. 수치로 표현할 수 있다면 더 좋다. 막연하게 "더 나은 경험을 제공합니다"보다 "이 기능으로 인해 사용자의 이탈 지점을 줄일 수 있습니다"가 훨씬 설득력 있다.
배포 전 QA, 대충 하지 말자
서비스가 배포되면 그때부터 진짜 시작이다. 실제 유저가 쓰는 화면에서 예상치 못한 버그가 나오고, 의도한 플로우대로 유저가 움직이지 않을 수 있다. 심사 전까지 계속 다듬을 수 있으니 배포 후에도 긴장을 풀지 말자.
실제 업무 환경에서는 Jira 같은 툴로 버그를 리포트하고 이슈를 트래킹하지만, 해커톤은 그런 환경이 허락되지 않는다. 빠르게 움직여야 하는 해커톤에서 디자이너와 개발자가 협업하기 가장 좋은 툴은 단연 피그마다.
배포된 화면을 캡처해서 피그마에 올리고, 수정이 필요한 부분에 코멘트로 설명을 달면 된다. 말로 설명하거나 슬랙으로 텍스트만 보내는 것보다 훨씬 빠르게 이해되고, 오해도 줄어든다. 개발자 입장에서도 "어디를" "어떻게" 고쳐야 하는지 한눈에 파악할 수 있어서 수정 속도가 올라간다.
조금 더 체계적으로 관리하고 싶다면 노션을 활용하는 것도 좋다. 핵심 플로우를 기준으로 QA TC(테스트 케이스) 리스트를 체크박스 형태로 정리하고, 팀원들과 함께 하나씩 검증해나가는 방식이다. TC를 처음부터 직접 짜려면 시간이 걸리는데, 여기서 AI를 활용하면 빠르다. 서비스의 핵심 개요와 주요 기능을 AI에게 설명하고 "QA TC를 짜줘"라고 하면 초안을 금방 만들어준다. 그걸 우리 서비스에 맞게 다듬어서 쓰면 된다.
피그마든 노션이든, 중요한 건 개발자가 무엇을 수정해야 하는지 명확하게 전달하는 것이다.
번외. 여유가 있다면 — 참가자들 환심 사기
꼭 해야 하는 건 아니다. 하지만 여유가 조금 생긴다면, 이것도 해보자.
비사이드 포텐데이처럼 참가자 투표가 있는 해커톤이라면, 같이 참여한 다른 팀들이 곧 유권자다. 심사위원만 공략 대상이 아니라는 뜻이다.
가장 기본적인 방법은 슬랙이나 디스코드 같은 플랫폼의 공용 채널에 서비스 소개글과 링크를 함께 올리는 것이다. 이때 "저희 서비스 출시했습니다" 같은 밋밋한 문구 대신, 조금 더 마케팅적인 문구를 고민해보자. 어떤 사람에게 필요한 서비스인지, 한 줄로 찌르는 카피 하나가 클릭률을 만든다.
나는 한발 더 나아가서 QR코드에 서비스 링크를 연결하고, 그 QR코드를 활용한 짤을 만들어서 에어드롭으로 뿌렸다. 해커톤 현장에서 갑자기 에어드롭이 날아오면 다들 한 번씩은 열어보게 되어 있다. 재치 있게 만든 짤 하나가 생각보다 많은 사람들의 눈길을 끌었다.
좋은 서비스를 만드는 것과 그것을 알리는 것은 별개의 일이다. 해커톤은 경쟁이지만, 서로의 서비스를 탐색하고 자극받는 축제이기도 하다. 재밌으면 즐기면 된다.
완주한 자만이 다음 레이스를 안다장표를 완성하고, QA를 돌리고, 서비스 링크를 세상에 던지는 순간. 그게 결승선이다. 많은 팀들이 UI를 완성하고 나서야 장표가 없다는 걸 깨닫고, 배포하고 나서야 버그를 발견한다. 준비된 팀은 다르다. 개발이 달리는 동안 디자이너는 장표를 만들고, 배포 전에 TC를 돌리고, 여유가 생기면 PR까지 챙긴다.
UI는 절반이었다. 나머지 절반을 채운 것이 이 레이스의 진짜 실력이다.
해커톤의 결승선은 서비스 출시가 아니다. 우리가 만든 것을 세상에 제대로 알리는 것까지다.
자, 이제 결승 테이프를 끊을 준비가 됐는가?
