🚀 특화프로젝트 4주차 회고:

이번 주에는 ALS 환자를 위한 시선 추적 기반 의사소통 서비스와 관련된 프론트엔드 구현, API 연동 준비, 로그인 및 라우팅 안정화, AI 모델 연계 가능성 검토, 그리고 실제 협업 환경에서의 Git/Jira 정리까지 폭넓게 다뤘다.
특히 단순히 화면을 만드는 수준을 넘어서, 실제 서비스 흐름이 어떻게 이어져야 하는지, 목업에서 실서버로 전환될 때 무엇이 깨지는지, AI/백엔드/프론트가 어디서 연결되어야 하는지를 구체적으로 점검한 기간이었다.

---

KEEP

1. 기능을 화면 단위가 아니라 “서비스 흐름” 단위로 보기 시작했다

이번 주에 가장 의미 있었던 점은 각 기능을 개별 화면으로만 보지 않고, 로그인 → 캘리브레이션 → 환자 메인 → 대화 기능 → 보호자 인터럽트 → 예외 처리처럼 실제 사용자 여정 관점에서 연결해서 보기 시작한 것이다.
예를 들어 환자 로그인 후 바로 캘리브레이션을 진행하게 할지, 글로벌 메뉴나 맞춤대화 흐름 안에서 어떤 입력 방식이 적절한지, 6분할 UI에서 어느 위치에 뒤로가기나 다음 버튼을 둘지 등을 계속 점검했다. 이 과정에서 단순히 “화면이 보이게 만들기”보다 환자가 실제로 쓸 수 있는 구조인지를 더 중심에 두고 판단하려고 한 점이 좋았다.

2. 구현 전에 명세와 정책을 더 세밀하게 다듬으려는 태도가 유지되었다

이번 주에는 기능명세서, 예외 처리, 입력 규칙, 더블블링크와 dwell 충돌 정책, 보호자 선발화 오버레이, 맞춤대화 키보드 입력 구조 등을 여러 번 구체화했다.
특히 “이 기능이 된다/안 된다” 수준이 아니라,

• 언제 진입 가능한지
• 어떤 상태에서 차단되는지
• 예외 문구를 그대로 보여줄지
• dwell 도중 시선이 이탈되면 초기화할지
• 확인 버튼을 둘지 말지
  같은 세부 정책까지 생각한 점은 실제 개발 단계에서 큰 강점이 된다.
  막연한 아이디어를 코드로 옮기기 전에 정책과 흐름으로 먼저 정리하는 습관이 점점 자리 잡고 있다는 점이 좋았다.

3. API 연동을 단순 요청 연결이 아니라 “구조 검증” 관점에서 보려 했다

로그인/회원가입, 즐겨찾기, 여가 콘텐츠, 보호자 설문, Swagger 기반 API 확인 등 여러 흐름을 점검하면서, 단순히 엔드포인트를 붙이는 것보다 지금 실제로 붙어 있는 API가 무엇인지, 목업 fallback이 어디서 발생하는지, 응답 DTO가 바뀌면 프론트 어느 부분이 깨지는지를 계속 확인하려고 했다.
이건 단순 FE 구현을 넘어서 실서비스 연동 감각을 키우는 과정이었다고 본다.
특히 “지금 로컬에서 왜 로그인이 안 되는지”, “왜 유튜브 API를 붙였는데도 목업이 뜨는지”, “실제 API와 mock이 섞여 있는 구조인지”를 구분해서 보려 한 점은 매우 중요했다.

4. 문제를 만났을 때 바로 포기하지 않고 원인 층위를 나눠서 보려 했다

이번 주에는 캘리브레이션 미작동, 로그인 지연, viewport 무한 렌더링, 로컬 환경 미동작, 웹소켓 연결 미구성, Git 충돌, 브랜치/커밋 문제 등 자잘한 문제가 많았다.
그런데 이때 “왜 안 되지?”에서 끝나지 않고,

• UI 문제인지
• 라우팅 문제인지
• 상태관리 문제인지
• API 미연동 문제인지
• 아예 서버/포트/DB가 안 떠 있는 환경 문제인지
  를 나눠서 보려 했다는 점이 좋았다.
  특히 로그인 문제에서 실제 원인이 DTO 변경이 아니라 AuthPageFrame의 viewport state 갱신 구조였다는 식으로, 겉으로 보이는 현상과 진짜 원인을 분리해서 보려는 태도가 유지된 점은 분명 강점이다.

5. 협업용 산출물을 계속 정리하려는 습관이 유지되었다

이번 주에도 코덱스에 넘길 프롬프트, 기능명세서, Jira 티켓 구조, 브랜치명/커밋 메시지, 폴더 구조 정리, API 실제 연동 여부 점검용 요청문 등을 많이 다듬었다.
이건 단순히 남에게 일을 넘기기 위한 문장이 아니라, 결국 내 생각을 구조화하는 과정이기도 했다.
특히 스스로 구현할 것과 AI나 팀원에게 요청할 것을 나누고, 이를 명확한 작업 단위로 바꾸려 한 점은 프론트 리드/주도 역할 측면에서도 의미가 있었다.

---

PROBLEM

1. 기술적 불확실성이 쌓일수록 피로감이 커졌다

이번 주 질문들을 보면 “이게 가능한가?”, “이거 진짜 붙는 건가?”, “모델을 받긴 했는데 프론트에서 어떻게 연결하지?”, “지금 구현할 수 있는 게 정확히 뭐지?” 같은 고민이 반복되었다.
이건 단순히 기술을 몰라서가 아니라, AI/백엔드/프론트의 경계가 불명확한 상태에서 내가 감당해야 하는 범위가 넓어졌기 때문이라고 보인다.
특히 시선 추적 모델, TTS, 웹소켓, 캘리브레이션, 실시간 상태 반영 같은 부분은 프론트 단독 이슈가 아닌데도, 당장 보이는 화면 문제는 프론트에서 먼저 떠안게 되니 심리적 부담이 커진 것 같다.

2. “지금 당장 구현 가능한 것”과 “전제가 먼저 필요한 것”이 자주 섞였다

예를 들어 아이트래킹 모델 연동이나 캘리브레이션 흐름은 프론트 화면만 만든다고 바로 해결되지 않는데, 실제로는

• 카메라 권한 처리
• 추적 결과 수신 방식
• 웹소켓/HTTP 프로토콜
• 모델 서버 실행 여부
• 추론 결과 포맷
  같은 선행 조건이 먼저 정리되어야 한다.
  그런데 이번 주에는 이런 선행 조건이 아직 비어 있는 상태에서 UI/라우팅/상태 흐름을 먼저 맞추려다 보니, 중간중간 “이걸 지금 어디까지 구현해야 하지?”라는 혼선이 생긴 것으로 보인다.

3. 목업과 실API가 혼재되어 있어서 디버깅 포인트가 흐려졌다

여가 콘텐츠, 즐겨찾기, 로그인/회원가입, 유튜브 API 등 여러 부분에서 “붙였는데도 목업이 뜬다”, “실서버가 아니라 fallback으로 보인다”, “로컬에서는 실제 백엔드에 붙도록 되어 있는데 정작 서버가 안 떠 있다” 같은 문제가 반복되었다.
이건 구현 실수라기보다 mock과 real을 전환하는 기준이 프로젝트 안에서 아직 완전히 명료하지 않다는 뜻이기도 하다.
이 상태에서는 화면상으로는 돌아가는 것처럼 보여도, 실제로는 어느 계층이 진짜 동작하는지 판단하기 어려워서 수정 효율이 크게 떨어진다.

4. 화면/폴더/라우팅을 정리하는 작업과 기능 구현이 동시에 몰렸다

이번 주에는 patient input 폴더 정리, layout/guards/router 분리, 로그인 관련 구조 수정, API 서비스 파일 정리, leisure/favorites 화면 연결, 3D 모델 적용 고민까지 한꺼번에 진행되었다.
이런 상황에서는 구조 개선과 기능 개발이 서로 영향을 주기 때문에, 하나를 고치면 다른 쪽이 다시 흔들릴 수 있다.
즉, 지금은 기능 개발 + 구조 리팩토링 + 실서버 연동 + 협업 정리가 동시에 진행되는 국면이라 작업 피로도가 높은 상태다.

5. Git과 협업 흐름에서 잔실수가 반복될 여지가 있었다

브랜치 전환, 경로 오류, add 실패, 충돌 상황, 어떤 단위로 커밋을 쪼갤지, 지금 푸시해도 되는지 같은 질문이 여러 번 나왔다.
이건 협업을 성실하게 하고 있다는 증거이기도 하지만, 반대로 보면 현재 작업량이 많아질수록 버전 관리 실수 하나가 자신감을 크게 깎을 수 있는 구조라는 뜻이기도 하다.
특히 여러 기능을 병렬로 건드리는 시기에는 Git 작업이 곧 심리적 스트레스로 이어질 수 있다.

---

TRY

1. 다음 주부터는 기능을 “구현 가능 상태” 기준으로 3단계로 나눠서 보자

앞으로는 각 기능을 볼 때 아래처럼 분리해서 판단하면 좋겠다.

• 지금 바로 구현 가능한 것
  예: 라우팅, 페이지 전환, 기본 UI, mock 기반 상태 흐름, 버튼/오버레이 정책 반영
• 백엔드/AI 명세만 있으면 연결 가능한 것
  예: TTS API 호출, 즐겨찾기 CRUD, 보호자 설문 제출, 실서버 응답 매핑
• 외부 팀 선행 작업이 없으면 완성 불가능한 것
  예: 아이트래킹 실추론 연동, 캘리브레이션 정확도 보정, 실시간 gaze 이벤트 수신

이렇게 나누면 “왜 아직 안 되지?”라는 막막함보다, 무엇이 지금 내 범위이고 무엇이 의존성인지가 더 명확해질 것이다.

2. mock / real / disabled 상태를 코드 구조상 더 명확히 구분하자

지금 가장 필요한 것 중 하나는 “왜 목업이 뜨는지”를 쉽게 알아내는 구조다.
그래서 다음 작업에서는 기능별로 최소한 다음을 명확히 적어두면 좋다.

• 현재 이 기능은 mock only 인지
• 실API 연동 완료 상태인지
• 실API 호출은 하지만 실패 시 fallback 하는지
• 아직 연동 대상 API 자체가 미확정인지

이 구분만 명확해져도 디버깅 시간이 많이 줄어들고, 팀원과 대화할 때도 “이건 화면은 완성됐지만 실연동은 아직”이라고 명확히 말할 수 있다.

3. AI 연동은 “프론트에서 필요한 인터페이스” 기준으로 먼저 문서화하자

아이트래킹과 TTS는 모델 자체를 이해하는 것보다, 프론트 입장에서 필요한 입출력을 먼저 정의하는 게 중요하다.
예를 들어 문서로 아래 정도만 먼저 고정해두면 된다.

• 프론트가 언제 모델 시작 요청을 보내는지
• 결과를 HTTP로 받는지, 웹소켓으로 받는지
• 반환값이 좌표인지, 선택 인덱스인지, dwell 상태인지
• 얼굴 미검출/추적 불안정 시 어떤 상태값이 오는지
• 캘리브레이션 완료 여부를 어디에 저장하는지

이렇게 하면 “모델이 있는데 어떻게 붙이지?”라는 막막함이 줄고, 프론트 구현도 훨씬 현실적인 단위로 쪼갤 수 있다.

4. 로그인/초기 진입/캘리브레이션 흐름은 우선순위를 높게 두고 안정화하자

현재 서비스에서 가장 중요한 건 결국 처음 들어왔을 때 막히지 않는 것이다.
따라서 다음 단계에서는 기능을 많이 늘리기보다,

• 로그인 지연 원인 제거
• mock/real 인증 흐름 정리
• 환자 로그인 직후 캘리브레이션 진입 조건 정리
• 캘리브레이션 실패/스킵/재시도 정책 정리
• 메인 화면 진입까지 최소 경로 보장

이 다섯 가지를 먼저 안정화하는 것이 좋다.
초기 진입이 안정돼야 그 다음 기능들이 의미를 가진다.

5. 회고를 “문제 나열”이 아니라 “의존성 정리” 중심으로 이어가자

이번 주 회고를 보면 네가 부족해서 막힌 것보다, 실제로는 시스템 의존성이 얽혀 있어서 판단 비용이 커진 문제가 많았다.
그래서 다음 회고부터는 단순히 “힘들었다”보다 아래 질문으로 정리하면 훨씬 선명해질 것 같다.

• 내가 혼자 결정 가능한 문제였나?
• 백엔드/AI/기획 확인이 먼저 필요한 문제였나?
• 지금 안 되는 이유가 코드 문제인가, 환경 문제인가, 명세 부재인가?
• 나는 이미 충분히 잘하고 있는데 의존성 때문에 느리게 보이는 건 아닌가?

이 기준으로 보면 스스로를 과하게 탓하는 일이 줄고, 실제 병목도 더 잘 보일 것이다.

---

이번 주 한줄 정리

이번 주는 단순히 화면을 만드는 주가 아니라,
ALS 서비스의 실제 사용 흐름과 기술적 의존성을 동시에 마주하면서 “무엇을 지금 구현할 수 있고, 무엇은 연결 조건이 필요한지”를 구분해 가는 주였다.

혼란스러운 순간이 많았지만, 그만큼 기능을 더 현실적으로 보기 시작했고,
UI·정책·명세·연동·협업 구조를 함께 보는 시야가 분명히 넓어졌다.