[테크포임팩트] 기획에서 프로토타입으로, 다로링크를 서비스로 구현하기 (프로토타이핑&테스팅 워크샵/추가 필드트립/팀별 내부 피드백)

　사실 수강신청을 하면서는 이렇게 기획에 몰두해서 프로젝트를 하게 될 줄은 상상도 하지 못했다. 개발 팀원으로서 무엇을 구현할지 이미 확정된 이후에 개발을 하는 프로세스에 집중할 거라고만 생각했던 것 같다. 하지만 지난 여정은 실제로 기술이 문제를 해결하려면 사용자의 니즈에 충분히 공감하고, 그 공감을 바탕으로 기획을 몇 번이나 다시 뜯어보는 과정이 먼저 필요하다는 것을 몸소 체감하는 시간이었다.

　이번 글은 여러 번의 회의와 현장 테스트, 개발 멘토링을 거치면서 어떻게 실제 프로토타입을 구현했는지, 그 과정에서 어떤 고민을 거쳤는지, 유저테스팅을 반복하면서 무엇을 수정하였는지를 기록해보려고 한다.

드디어 기획을 확정하다!

　기획을 다시 잡은 뒤에도 넣고 싶은 기능은 한동안 줄지 않았다. 교통, 교육, 일자리, 마을 공지, 공공 서비스 안내까지, 다로리에서 들었던 생활 문제들은 서로 따로 떨어져 있지 않았다. 아이를 학교에 보내는 일은 교통과 이어지고, 일자리를 구하는 일은 결국 지역 사람들과의 관계와 이어지고, 버스 정보는 병원이나 읍내에 가는 일과 맞닿아 있었다. 그래서 처음에는 지역 생활 커뮤니티답게 여러 기능을 한 번에 담아보고 싶었다.

　그런데 막상 프로토타입을 만드려고 포기하는 일이 중요하다는 것을 깨달았다. 기능이 많아질수록 첫 화면에서 무엇을 보여줘야 할지 모호해졌고, 사용자가 앱에 들어와서 가장 먼저 무엇을 해야 하는지도 제대로 설계되지 않았다. 회의 때마다 “그래서 이 앱을 켜면 제일 먼저 뭘 할 수 있어야 하지?“를 계속 물으면서 필수적인 기능 위주로 서비스를 피봇팅했다. 기능 수정을 거듭할수록 모든 문제를 한 번에 풀려다가 아무것도 제대로 보여주지 못할 수 있다는 생각이 들었다.

문제 재정의/이에 맞춰 기능 추리기

　그래서 최종적으로는 라이드 셰어링, 행복버스 아카이빙, 인재 풀 등록으로 기능을 좁혔다. 라이드 셰어링은 같은 방향으로 가는 사람을 모집하거나 신청할 수 있는 기능이고, 행복버스 아카이빙은 노선과 정류장 위치, 배차 정보를 더 쉽게 확인할 수 있게 하는 기능이다. 인재 풀 등록은 지역에서 일손이 필요하거나 새로 온 사람이 자신이 할 수 있는 일을 알리고 싶을 때 쓸 수 있는 기능으로 잡았다.

　세 기능은 서로 다르지만 공통점이 있었다. 다로리에서는 이미 사람을 통해 해결되던 일들이 많았다. 차가 없을 때는 주변 사람에게 부탁하고, 일손이 필요할 때는 아는 사람을 통해 찾고, 필요한 정보도 지인을 통해 듣는 식이었다. 기존 주민에게는 익숙한 방식이지만, 새로 온 사람에게는 어디서부터 물어봐야 할지 모를 수 있다. 다로링크는 그 지점을 조금 줄여 진입장벽을 낮추는 기획으로 방향을 설정하였다.

코드보다 먼저 생각해야 했던 것들

저,,, 열심히 했어요,,,

　기능을 좁히고 나서는 본격적으로 개발에 들어갔다. 이번 글에서는 개발 멘토링에서 다뤘던 고민들과, 유저테스팅을 거치며 기능을 어떻게 고쳤는지를 위주로 적어보려고 한다. 실제 기능 구현 과정이나 기술적인 디테일은 분량이 꽤 될 것 같아서 다음 글에서 따로 다룰 예정이다.

(좌) 내가 작성한 사전 문서 (우) 멘토님이 정성껏 답변해주신 로그,,,🥹🥹

　팀 회의에서 기획에 충분한 시간을 들인 탓에 개발 후 유저 테스팅까지 충분한 시간이 나지 않을 것이라고 판단했고, 그래서 개발 사이클을 조금 빠르게 당기고자 했다. 그래서 게시글이나 채팅 기능을 만들면서 우리는 “일단 돌아가게 만들자"고 합의하고 개발에 돌입했다. 화면이 뜨고 글이 올라가고 메시지가 오가면 그걸로 됐다고 생각했던 것 같다.

　그런데 멘토링님께서는 “유저 입력값은 기본적으로 믿으면 안 된다"는 말을 해주셨다. XSS, SQL Injection 같은 개념을 모르고 있던 건 아니었지만, 우리가 만든 게시글 작성창이나 채팅창에 누군가 악성 스크립트를 넣을 수 있다는 걸 이렇게 구체적으로 생각해본 적은 없었다. 학교 과제로만 끝날 프로젝트였다면 대충 넘어갔을 수도 있었을 것 같다. 그런데 실제 사용자가 쓸 서비스라고 생각하니 더 신경써야 한다는 생각이 들었다. 그래서 입력값 벨리데이션 로직을 직접 구현하고 QA를 거치면서 실제 기능 테스트를 거쳤다. 작은 기능처럼 보여도 실 서비스라면 당연히 있어야 하는 부분을, 기획서에 적어두는 게 아니라 우리 손으로 코드로 만들어봤다는 게 의미 있게 느껴졌다.

　두 번째는 조금 다른 종류의 고민이었다. 멘토님께 라이드 셰어링 기능을 보여드렸는데, 카풀이 예전에 국내에서 서비스로 자리잡으려다가 택시업계의 반발로 무산된 적이 있다는 이야기를 해주셨다. 다로링크는 청도라는 특정 지역, 특정 생활 맥락에 한정된 서비스라 상황이 완전히 같지는 않겠지만, 라이드 셰어링이라는 기능 자체가 단순한 기술 문제가 아니라 법적, 사회적 이해관계와도 맞닿아 있을 수 있다는 걸 멘토님과 함께 짚어봤다.

　당장 답이 나오는 질문은 아니었다. 우리가 만드는 기능이 누군가에게는 지역 주민들끼리 서로 돕는 일로 보일 수 있지만, 더 큰 틀에서 보면 다른 산업과 충돌할 수 있는 지점이 있다는 것을 처음으로 생각해보게 됐다. 기술을 만들 때는 코드와 화면만 고민하면 되는 줄 알았는데, 이런 부분까지 함께 고려해야 한다는 걸 알게 된 것만으로도 도움이 되고, 또 내가 개발 프로세스에 있어 어떤 방면에 집중하는 사람인지 되짚어보게 되었다!

유저 테스팅과 UI 수정

　처음에는 사용자가 버스를 봤을 때 버튼을 누르면 시간과 위치가 자동으로 기록되고, 그 기록이 쌓이면 다른 사용자가 정류장별 정보를 확인할 수 있는 구조로 설계했다. 그런데 기존 주민 피드백을 받아보니 간단하지 않았다. 종이 시간표보다 편리할 것 같다는 의견도 있었지만, 동시에 어플 입력이 어렵다, 글씨 크기가 작다는 피드백도 나왔다. 학생층은 앱 사용과 기록 참여 의향이 비교적 높았지만, 노년층은 기록 참여 의향이 낮게 나왔다. 버튼 하나면 충분히 쉽다고 생각했던 게, 누군가에게는 앱을 켜고 위치 권한을 허용하고 버튼을 찾는 과정 자체가 장벽이었던 셈이다.

　그래서 직접 행복버스를 기점부터 종점까지 타면서 노선과 정류장을 조사·기록했다. 사용자가 직접 제보하지 않아도 기본 운행 정보를 먼저 볼 수 있도록 사전 데이터를 채워 넣었고, 정류장 위치를 지도 위에 더 명확하게 표시하여 시인성을 높였다. 컴퓨터 앞에서 노선표를 정리하는 것과, 실제로 그 정류장에 서서 “여기가 맞나” 싶은 순간을 직접 겪어보는 건 완전히 다른 일이었다.

　다른 기능들에서도 받은 피드백을 바탕으로 빠른 매칭보다 확인 과정을 더 중요하게 UX를 재설계하였다. 신청이 들어오면 바로 연결되는 것이 아니라, 작성자가 신청자를 확인하고 승인한 뒤에 채팅방이 만들어지는 흐름을 구현하였다. 이동처럼 신뢰가 필요한 상황에서는 “내가 연결을 선택할 수 있다"는 느낌이 작지만 중요하다고 판단했다. 돌이켜보면 그것이 바로 다로리에서 실제로 이루어지고 있는 과정이라는 생각이 들었다.

현장에서 직접 들은 이야기

　중간 발표에서 교수님께 “유저 테스팅이 있어야 할 것 같다”, “그래서 이 앱을 실제로 쓰느냐가 가장 중요하다"라는 피드백을 해주셨고, 시험 주간에 필드트립을 추가로 진행해서 다시 청도에서 실 테스팅을 진행하게 됐다. (다시 한 번 가장 바쁜 시기에 필드트립을 함께해 준 팀원들에게 감사를 전하며,,,🥺🩷)

세상 맑았던 청도의 하늘!

　기능별로 따로 받은 피드백 말고도, 실제 다로리 생활 맥락에 맞춘 실사용 테스트도 진행했다. 기능, 편리성, 친밀도 항목을 기준으로 반응을 봤고, 어떤 부분이 좋았고 어떤 부분이 걱정되는지도 함께 들었다.

　현장에서 여러 피드백도 받았지만, 교수님 말씀처럼 현장에서 확인하여 보니 다로링크가 완전히 뜬구름 잡는 서비스로 받아들여지지는 않았다는 점이 가장 다행스러웠다. 혼자 가기 애매한 거리를 함께 갈 수 있다는 점이 든든하다는 반응이 있었고, 늘 다니던 익숙한 길에서 큰 어려움 없이 다른 사람을 도울 수 있다는 점이 의미 있다는 피드백도 있었다. 물론 어플 입력이 어렵다, 글씨가 작다, 안전이 걱정된다, 기존 주민이 잘 안 쓸 것 같다는 의견도 여전히 나왔다. 그런데 화면이 없을 때는 추상적이었던 피드백이, 프로토타입이 생기니 “여기가 불편하다”, “이 흐름이 걱정된다"처럼 명확한 피드백으로 바뀌었다.

　결국 다로링크가 하려고 했던 일은 다로리에 사는 사람들이 이미 가진 내부 인프라와 데이터를 신규 귀촌인도 접근할 수 있는 생활 인프라로 바꾸는 일이었다. 그리고 그렇게 다로리에 들어온 귀촌인의 참여가, 다시 지역 공동체의 자원으로 돌아오는 인프라를 만드는 일이었다. 거창하게 들리지만 실제로 테스트하면서 들은 말들은 훨씬 구체적이었다. 기존 주민분은 “이 앱으로 기존 주민과 연결될 수 있을 것 같아요"라고 했고, 귀촌을 고민하던 분은 “이 앱이 있다면 이주 결정에 도움이 될 것 같아요"라고 해주셨다. 처음에는 “관계 기반 인프라”, “양방향 순환 구조” 같은 말로 포장하고 전달했지만, 실제로는 누군가의 이주 결정에 영향을 줄 수도 있는 일이라는 게 신기하면서도 묘하게 무겁게 다가왔던 것 같다.

　라이드 셰어링으로 기존 주민과 귀촌인이 자원을 나누고, 행복버스 아카이빙으로 흩어져 있던 교통 정보가 한곳에 모이고, 인재 풀 등록으로 아직 관계망에 들어가지 못한 사람도 자신을 알릴 수 있게 되는 것. 이 세 기능이 따로 통합되는 것이 아니라, 결국 한 사람이 다로리에 들어와서 정착하기까지의 여정을 같이 받쳐주는 구조였으면 좋겠다고 생각하게 되었다.

마치며

　이번 과정을 거치면서 개발이 기획을 그대로 옮기는 마지막 단계가 아니라는 것을 느꼈다. 기획서에 적힌 기능을 화면으로 만들면 끝나는 줄 알았는데, 실제로는 만들수록 다시 피드백하고 수정하고 테스팅하는 과정이 훨씬 중요하다는 것을 깨달았기 때문이다. 버스 제보 버튼을 만들면 누가 이 버튼을 누를 수 있을지를, 라이드 신청 기능을 만들면 사용자가 어떤 기준으로 상대를 확인할 수 있어야 하는지를 확인해야 좋은 서비스를 만들 수 있었다. 개인적으로 제일 좋았던 건, 내가 만든 서비스를 들고 직접 사람들을 만나러 다녔다는 점이었다.

　개발자로서도 여러모로 의미 있는 경험이었고, 덕분에 앞으로 어떤 서비스를 만들든 스크린 뒤에 있을 사용자를 즐거이 상상해 볼 수 있을 것 같아졌다. 동시에 사용자에게 조금 더 가까운 서비스를 만들고 싶다는 구체적인 소망도 갖게 되었다.

　끝!

테크포임팩트 캠퍼스 크리에이터 활동의 일환으로 제작된 콘텐츠입니다.