Code 빌드

손으로 오래 쓰게 만들지 않는 것이 PawRelay 제품화의 기준이었다

seunghyeonlab 2026. 6. 29. 19:12

hero

오늘의 결론은 분명했다. PawRelay는 기능을 더 많이 보여주는 방향보다, 사용자가 손으로 길게 입력하지 않아도 기록을 남길 수 있게 만드는 방향으로 계속 다듬어야 한다. 반려동물 돌봄 기록은 의욕이 많은 날보다 바쁜 날에 더 자주 쓰이기 때문에, 첫 접점에서 피로가 쌓이면 앱 자체가 아니라 기록 습관이 먼저 무너진다. 그래서 이번 기록에서는 버튼 중심 입력, 사진의 선택적 사용, 메모의 후순위라는 원칙을 다시 고정했다.

왜 입력을 줄이는 쪽이 더 중요한가

PawRelay에서 다루는 기록은 대단히 복잡한 문장보다 짧은 사실의 반복에 가깝다. 밥을 먹었는지, 물을 마셨는지, 산책을 했는지, 약을 먹었는지, 증상이 있었는지 같은 내용이 대부분이다. 이런 정보는 정교한 서술이 아니라 빠른 확인과 누적이 더 중요하다. 그런데 처음 설계를 잡을 때는 이런 항목도 자연스럽게 메모로 남길 수 있다고 생각하기 쉽다. 실제 사용 맥락에서는 그 가정이 자주 깨진다. 바쁜 순간에는 설명을 쓰는 일 자체가 진입 장벽이 되고, 기록을 미루게 만들며, 결국 앱을 열지 않게 된다.

그래서 이번 기준은 단순했다. 손으로 길게 입력해야 하는 순간을 최대한 줄인다. 밥, 물, 산책, 약은 먼저 탭으로 처리하고, 증상도 가능한 한 버튼으로 먼저 고른다. 사진은 필요한 경우에만 붙이고, 메모는 반드시 남겨야 하는 핵심 정보가 있을 때만 선택한다. 이 순서를 정한 이유는 입력 수단의 우선순위가 곧 제품의 우선순위라고 보기 때문이다. 가장 자주 쓰는 동작이 가장 적은 마찰을 가져야 하고, 그 위에 예외 정보가 얹히는 구조여야 한다.

이 판단은 단순히 UI를 덜 복잡하게 만들겠다는 취향이 아니다. 기록이 누락되는 지점을 줄이는 것이 제품의 본질이라고 봤기 때문이다. 사용자가 앱을 열었는데 할 일이 길어 보이면, 그 순간부터 "나중에"가 시작된다. 기록 습관은 그 미뤄짐에 아주 약하다. 그래서 이 프로젝트에서는 예쁘게 보이는 입력폼보다, 바쁜 사람도 끝까지 누를 수 있는 짧은 흐름을 우선한다.

버튼이 먼저여야 하는 이유는 무엇인가

문제는 항목 수가 아니라 입력 방식이었다. 같은 기록이라도 버튼 한 번으로 끝나는지, 문장을 직접 써야 하는지에 따라 체감 난이도가 크게 달라진다. 특히 반려동물 돌봄 기록은 한 번에 긴 설명을 쓰기보다 짧게 여러 번 쌓는 형태가 잘 맞는다. 오늘처럼 상태가 애매할 때는 더 그렇다. 완벽한 문장보다 지금 남길 수 있는 최소한의 기록이 더 가치 있다.

그래서 밥/산책/증상 같은 핵심 항목은 탭형 선택으로 두고, 상세 설명은 뒤로 미뤘다. 이렇게 하면 사용자는 먼저 사실만 남기고, 시간이 있을 때만 추가 설명을 붙일 수 있다. 이 순서는 제품 관점에서도 중요하다. 처음부터 모든 정보를 요구하면 기록률이 떨어지고, 반대로 핵심만 먼저 받으면 나중에 보완할 여지를 남길 수 있다. 기록 도구가 해야 할 일은 사용자에게 완전한 보고서를 강요하는 것이 아니라, 나중에 다시 확인할 수 있는 최소 신호를 안정적으로 쌓는 것이다.

이렇게 정리하면서 남긴 판단 기준도 분명해졌다. 첫째, 주요 행동은 문장 입력보다 탭 입력이 우선이다. 둘째, 예외 상황은 메모로 받되 필수로 만들지 않는다. 셋째, 사용자가 처음 하루를 지나면서도 같은 흐름을 반복할 수 있어야 한다. 이 세 가지가 깨지면 기능 수는 늘어도 실제 사용성은 오히려 떨어진다.

이미지로 보여주기에도 이 구조는 명확하다. 한쪽에는 "탭으로 끝나는 기록"이 있고, 다른 한쪽에는 "메모가 먼저인 기록"이 있다. 전자는 빠르지만 최소 정보가 남고, 후자는 설명은 풍부해도 시작이 무겁다. PawRelay는 전자를 선택했다. 이 선택은 기능을 줄인 것이 아니라, 반복 사용이 가능한 형태로 압축한 것이다.

사진과 메모를 뒤로 보낸 것은 무엇을 포기한 걸까

사진과 메모를 뒤로 미뤘다고 해서 정보의 질을 포기한 것은 아니다. 오히려 반대다. 사진은 상황을 보강할 때만 붙이게 하고, 메모는 정말 필요할 때만 쓰게 해야 기록 전체가 덜 지친다. 모든 입력을 같은 무게로 두면 사용자는 각 항목을 완벽하게 채우려다가 시작도 못 한다. 사진을 기본값으로 강제하면 촬영이 부담이 되고, 메모를 기본값으로 강제하면 글쓰기가 부담이 된다.

이번 원칙에서 중요한 점은 "기록의 충분함"을 한 번에 달성하려 하지 않는다는 것이다. 핵심 상태는 탭으로, 예외와 보강은 선택으로 나눈다. 이렇게 나누면 오늘 남긴 기록이 아주 정교하지 않더라도, 다음 확인 시점에 다시 읽을 수 있는 바탕은 남는다. 그리고 그 바탕이 충분하면, 나중에 필요한 정보만 추가해도 된다. 제품은 한 번에 완성된 문서가 아니라, 반복해서 다시 열리는 습관에 가깝다.

이 판단을 하면서 보류한 것도 있다. 모든 케이스를 한 화면에서 설명하려는 욕심, 입력을 한 번에 완결시키려는 흐름, 그리고 상세 메모를 더 앞쪽에 배치하고 싶은 유혹이다. 하지만 그런 설계는 첫 사용성은 좋아 보여도 반복 사용에서는 손해가 크다. 우리는 지금 "설명 가능한 앱"보다 "다시 쓰게 되는 앱"을 만들고 있다. 이 둘은 비슷해 보여도 실제 제품 품질을 가르는 기준이 다르다.

테스터에게 무엇을 물어봐야 이 원칙을 검증할 수 있나

이번 기록에서 테스터 모집은 중심이 아니다. 다만 원칙이 맞는지 확인하려면 어떤 질문을 던져야 하는지는 분명하다. 기능 개수에 대한 반응보다, 첫날 이해도와 입력 피로를 봐야 한다. 사용자가 첫날에 바로 구조를 이해했는지, 밥/산책/증상 기록이 귀찮지 않았는지, 가족에게 설명하기 쉬웠는지가 핵심이다. 이 질문들은 단순한 만족도 조사보다 훨씬 실용적이다. 왜냐하면 제품이 실제로 사라지는 지점이 재미가 아니라 마찰이기 때문이다.

이때 확인해야 할 기준도 단순하게 잡는다. 첫째, 사용자가 기록을 시작하기 전에 어디를 눌러야 하는지 오래 고민하지 않는가. 둘째, 하루에 여러 번 남기는 행동이 부담으로 느껴지지 않는가. 셋째, 나중에 봤을 때 "왜 이렇게 기록했는지"를 최소한 이해할 수 있는가. 이 셋 중 하나라도 흔들리면, 버튼 중심 설계가 아니라 입력 방식 전체를 다시 봐야 한다.

앞으로도 이 원칙은 그대로 가져갈 생각이다. 새로운 기능이 생기더라도 먼저 물어볼 질문은 하나다. 이 기능이 사용자의 손글씨를 줄이는가, 아니면 늘리는가. 전자라면 남기고, 후자라면 보류한다. 기능을 더하는 것보다 중요한 것은, 바쁜 사람이 실제로 끝까지 쓸 수 있는가다. PawRelay가 제품이 되려면 바로 그 질문을 계속 통과해야 한다.


🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: Code 빌드
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독