🚀 특화프로젝트 3주차 회고: 아이디어를 실제 구조로 바꾸기 시작한 한 주

아이디어를 실제 구조로 바꾸기 시작한 한 주

이번 주는 단순히 “이런 기능이 있으면 좋겠다” 수준에서 머무르지 않고,
ALS 환자를 위한 안구 추적 기반 의사소통 서비스를 실제로 어떤 구조로 구현할지 더 구체적으로 다듬어 본 시간이었다.

처음에는 기능 단위로 생각했던 것들이, 정리하다 보니 결국 다 하나의 흐름으로 이어져 있었다.
환자가 어떤 화면을 먼저 보게 되는지, 어떤 방식으로 선택하는지, 실수했을 때 어떻게 되돌아갈 수 있는지, 얼굴이 검출되지 않거나 추적이 흔들릴 때는 어떤 예외 처리가 필요한지까지 생각해야 했다.
그래서 이번 주는 단순히 화면 몇 개를 그리는 시간이 아니라, 서비스를 실제 사용자가 쓸 수 있는 형태로 구체화해 가는 시간에 더 가까웠다.

---

👀 이번 주에 가장 의미 있었던 것

가장 의미 있었던 건,
서비스 방향을 훨씬 더 실제 사용성 중심으로 구체화해 나갔다는 점이다.

이번 주에는 메인 화면 구조, 하위 화면 흐름, 예외 상황, 인터랙션 방식 같은 것들을 계속 세부적으로 다듬었다.
특히 6분할 화면 구조, 뒤로가기 버튼 위치, 더블 블링크 오버레이, dwell 시간, 얼굴 미검출이나 추적 불안정 같은 상황까지 하나씩 짚어 보면서,
“이 기능이 있으면 좋다”가 아니라 **“환자가 실제로 이 화면을 보고 선택할 수 있을까?”**를 기준으로 계속 생각하려고 했다.

이 과정에서 느낀 건,
안구 추적 기반 서비스는 단순히 기술이 된다고 끝나는 게 아니라는 점이었다.
버튼 하나의 위치, 분할 수, 오버레이 방식 같은 것도 전부 사용성과 직결되기 때문에,
작아 보이는 선택 하나도 꽤 중요하다는 걸 다시 느꼈다.

---

📝 문서화가 생각보다 큰 역할을 했다

이번 주에 좋았던 또 하나는,
기획을 계속 문서화하는 흐름을 놓치지 않았다는 점이다.

상태 정의서, 예외 및 실패 처리 명세, 화면별 인터랙션, 라우팅 구조, 데이터 구조 초안처럼
개발 전에 필요한 문서들을 하나씩 정리하다 보니
처음에는 막연하게 떠다니던 아이디어가 점점 구현 가능한 설계 형태로 내려오는 느낌이 들었다.

머릿속으로는 “이렇게 하면 될 것 같은데?” 싶었던 것들도
막상 문서로 적기 시작하면 빠진 조건이나 충돌하는 부분이 보이기 시작했다.
그래서 문서 작업은 단순히 기록하는 일이 아니라,
아이디어를 검증하고 구조를 정리하는 과정에 더 가까웠다.

중간발표를 준비하면서도
단순히 화면만 보여주는 게 아니라
왜 이 서비스를 해야 하는지, 누구를 위한 서비스인지, 어떤 문제를 해결하려는지까지 연결해서 생각하게 됐다.
덕분에 이번 주에는 기능 하나하나보다도, 서비스 전체를 하나의 흐름으로 바라보는 시각이 조금 더 생긴 것 같다.

---

😵 이번 주에 어려웠던 점

이번 주에 가장 크게 느낀 어려움은
내가 머릿속으로는 분명하게 그리고 있는 화면 구조나 사용 방식을
처음부터 정확하게 전달하는 데 시간이 걸렸다는 점이다.

특히 환자용 화면처럼 제약이 분명한 구조는
내가 생각한 형태에서 조금만 달라져도 다시 수정해야 하는 경우가 많았다.
그러다 보니 비슷한 설명을 반복하게 되는 순간도 있었고,
내가 중요하게 생각하는 기준을 더 빠르고 더 명확하게 전달하는 방식이 필요하다는 걸 느꼈다.

또 하나는 기획 범위가 생각보다 훨씬 넓었다는 점이다.
처음에는 화면 구조만 정리하면 될 줄 알았는데,
실제로는 상태 정의, 예외 처리, 인증 방식, 역할 분기, STT 저장 단위, 호출 흐름, 추천 구조까지 전부 연결되어 있었다.
하나를 정리할수록 같이 확정해야 하는 항목들이 계속 늘어났고,
그래서 “정리하면 할수록 해야 할 일이 더 많아지는 느낌”이 꽤 강했다.

중간발표 준비와 실제 설계를 동시에 진행하다 보니
우선순위가 흔들릴 때도 있었다.
더 깊게 정리하고 싶은 부분은 많았지만 발표 일정은 정해져 있었고,
그래서 지금 꼭 필요한 것과 나중으로 미뤄도 되는 것을 계속 구분해야 했다.
생각보다 그 판단이 쉽지 않았다.

---

🧩 아직 더 고민이 필요한 부분들

기능 네이밍과 정보 구조도 아직은 완전히 매끄럽지 않다고 느꼈다.

즐겨찾기, 필요소통, 키보드, 보호자와의 대화, STT 소통처럼
모든 기능이 결국 “소통”과 연결되어 있는데,
사용자 입장에서 봤을 때 이 기능들이 어떻게 묶이고 어떻게 이해되는지가 완전히 정리된 상태는 아니었다.
기능을 만드는 것도 중요하지만,
사용자가 이 기능들을 어떤 기준으로 받아들일지를 더 자연스럽게 정리할 필요가 있다는 생각이 들었다.

그리고 안구 추적 정확도, 응시 시간, 얼굴과 카메라 거리, 작은 눈 인식, 시선 흔들림 보정 같은 요소들은
아무리 기획으로 많이 생각해도 결국 실제 테스트를 해봐야 감이 오는 부분이었다.
이건 문서만으로 확신하기 어려운 영역이라,
기획과 함께 작은 단위의 검증도 병행해야 한다는 걸 느꼈다.

---

🔥 다음에는 이렇게 해보고 싶다

다음에는 화면 논의를 시작하기 전에
절대 바뀌면 안 되는 조건들부터 먼저 고정해서 정리해야겠다고 느꼈다.

예를 들어 6분할 고정, 뒤로가기 위치, 클릭 방식, 오버레이 방식, 웹 비율, 환자용 제약 같은 기준을
처음부터 분명하게 정리해 두면
수정 횟수를 줄이고 원하는 방향으로 더 빠르게 갈 수 있을 것 같다.

또 발표용으로 필요한 범위와 실제 개발용으로 끝까지 가져가야 하는 범위를
조금 더 분리해서 볼 필요도 있다.
이번 주에는 기획적으로 필요한 것과 발표에서 보여줘야 하는 것을 함께 끌고 가다 보니
생각이 계속 확장되는 느낌이 있었는데,
앞으로는 지금 당장 발표에 필요한 것, 개발 전에 꼭 확정해야 하는 것, 후순위로 미뤄도 되는 것을 나눠서
우선순위를 더 분명하게 가져가고 싶다.

그리고 다음 단계에서는
핵심 사용자 흐름부터 먼저 단단하게 잠가야겠다는 생각도 들었다.
로그인과 회원가입, 환자 진입, 메인 6분할, 호출과 소통, 여가 기능, 예외 처리처럼
핵심 플로우를 먼저 확실히 잡아두고 그 위에 세부 기능을 붙이는 방식이 더 효율적일 것 같다.

문서 작업도 각각 따로 정리하는 데서 끝내지 않고,
상태 정의서와 예외 처리 문서, 화면 설계, API 명세가 서로 충돌하지 않도록
같이 연결해서 보는 습관이 필요하다고 느꼈다.

마지막으로,
안구 추적처럼 체감이 중요한 기능은 오래 고민만 하기보다
작은 PoC라도 빠르게 돌려보면서
dwell 시간, 인식 속도, 스무딩, 거리 민감도 같은 기준값을 실제로 확인하는 방향으로 가면 더 좋을 것 같다.

---

한 줄 회고

이번 주는 아이디어를 단순히 떠올리는 단계를 넘어,
루게릭 환자를 위한 안구 추적 기반 의사소통 서비스를 실제로 구현 가능한 구조로 구체화해 나간 한 주였다.