특화프로젝트 회고 : 여러분 저 해냈어요 저 1등이라코요!!!

이번 SSAFY 특화프로젝트에서 우리 팀은
ALS 환자를 위한 시선 기반 AI 의사소통 플랫폼, EyeSpeak를 만들었다.

처음에는 그냥
“환자가 눈으로 선택해서 보호자와 소통할 수 있게 만들자!”
정도의 문장으로 시작했던 것 같은데, 막상 해보니까 전혀 간단하지 않았다.

시선 추적, 환자 모드 UX, 보호자 모드, 실시간 채팅, AI 추천 답변, TTS, 캘리브레이션, 발표 준비, 시연 준비, README 작성까지…

진짜 프로젝트 하나 안에 프로젝트가 몇 개 들어있는 느낌이었다.

준수선녀처럼 두괄식으로 말하자며
우리 팀은 본선에 진출했고,
발표 준비도 다시 했고,
최종적으로 1등을 했다.

(솔직히 말하면 진짜안될줄 알았음)

 

결과론적으로는 해냈다.

 

---

프로젝트 과정은 생각보다 훨씬 복잡했다

사실 결과만 보면
“본선 갔다”, “1등했다”, “잘 끝났다”로 정리할 수 있다.

그런데 프로젝트를 하는 동안은 전혀 그런 느낌이 아니었다.

처음에는 아이디어가 꽤 명확해 보였다.
ALS 환자가 눈으로 화면을 선택하고, 보호자와 소통할 수 있게 만드는 서비스.

말로만 들으면 구조가 단순해 보인다.

“환자 화면 만들고, 시선 추적 붙이고, 보호자 화면 만들고, 채팅 붙이고, AI 추천 답변 붙이면 되는 거 아닌가?”

하지만 실제로 구현을 시작하자마자 알게 됐다.

이건 그냥 기능을 하나씩 붙이는 프로젝트가 아니라,
환자가 실제로 사용할 수 있는 흐름을 계속 검증해야 하는 프로젝트였다.

---

초반: “어떻게 보여줄까?”보다 “어떻게 쓰게 할까?”가 더 어려웠다

프로젝트 초반에는 환자 모드 화면 구조를 잡는 것부터 쉽지 않았다.

일반적인 서비스라면 사용자가 마우스로 원하는 버튼을 누르면 된다.
하지만 EyeSpeak에서는 사용자가 손이 아니라 눈으로 선택해야 했다.

그래서 화면을 만들 때도 계속 고민해야 했다.

• 버튼은 몇 개까지 보여줘야 하지?
• 한 화면에 정보가 많으면 환자가 힘들지 않을까?
• 시선이 흔들리면 잘못 선택될 수도 있지 않을까?
• 선택 중이라는 피드백은 어떻게 보여줘야 하지?
• 뒤로가기는 항상 같은 위치에 있어야 하지 않을까?
• 환자가 실수했을 때 복구할 수 있어야 하지 않을까?

그냥 예쁜 화면을 만드는 게 아니라,
눈으로 조작 가능한 화면을 만들어야 했다.

이때부터 환자 모드의 6분할 구조, 뒤로가기 위치, 선택 피드백, 전역 메뉴 같은 것들을 계속 고민했다.

처음에는 “이 정도면 괜찮지 않을까?” 싶었던 화면도
실제로 시선 입력을 상상해보면 불편한 부분이 보였다.

그래서 초반에는 화면을 만드는 것만큼이나
사용자가 이 흐름을 따라갈 수 있을까?를 계속 생각했던 것 같다.

---

중반: 기능이 늘어나면서 흐름이 점점 복잡해졌다

중반부터는 기능이 하나둘 붙기 시작했다.

대화하기, 호출, 여가, 즐겨찾기, 몸과 마음 표현, 추천 답변, 직접 입력, 보호자 채팅, TTS까지.
처음에는 각각의 기능처럼 보였지만, 붙이다 보니 전부 연결되어 있었다.

예를 들어 환자가 문장을 선택하면
그 문장이 보호자에게 전달되어야 하고,
필요하면 TTS로 음성이 나와야 하고,
보호자 채팅이 오면 환자 화면에서 확인할 수 있어야 하고,
여가 화면을 보고 있다가도 대화 요청이 오면 흐름이 끊기지 않아야 했다.

그러니까 단순히 페이지를 만드는 문제가 아니었다.

기능과 기능 사이의 흐름을 맞추는 일이 계속 생겼다.

특히 환자 모드는 화면마다 입력 방식이 달라지면 안 됐다.
어떤 화면에서는 시선 선택이 되고, 어떤 화면에서는 안 되면 사용자가 혼란스러울 수밖에 없다.

그래서 기능을 만들면서도 계속 이런 걸 봐야 했다.

• 이 화면도 시선 선택 흐름을 따르는지
• 선택 피드백이 다른 화면과 같은지
• 뒤로가기 위치가 유지되는지
• 전역 메뉴가 어디서든 열리는지
• 보호자와의 상호작용이 환자 흐름을 방해하지 않는지

이때부터 프로젝트가 단순 구현이 아니라
전체 서비스 흐름을 계속 맞춰가는 작업이라는 게 확실히 느껴졌다.

---

중반 이후: “되는 기능”과 “쓸 수 있는 기능”은 달랐다

개발을 하다 보면 버튼이 눌리고, API가 연결되고, 화면이 넘어가면
일단 기능이 된 것처럼 보인다.

그런데 EyeSpeak에서는 그걸로 부족했다.

기능이 동작하는 것과
환자가 실제로 쓸 수 있는 것은 달랐다.

예를 들어 화면 이동은 되는데 시선으로 선택하기 어렵다면,
그건 우리 서비스에서는 완성된 기능이라고 보기 어려웠다.

문장은 출력되는데 환자가 어떤 문장을 선택 중인지 알기 어렵다면,
그것도 좋은 흐름은 아니었다.

그래서 중반 이후에는
“기능 구현 완료”보다
“환자 모드 안에서 자연스럽게 쓸 수 있는가”를 더 많이 보게 됐다.

이 과정이 생각보다 오래 걸렸다.

프론트에서 화면을 만들고,
AI 쪽 입력을 받고,
백엔드 API를 붙이고,
실제 시나리오대로 이동해보면
생각하지 못했던 빈틈이 계속 나왔다.

그때마다 화면을 다시 보고, 상태를 다시 보고, 흐름을 다시 맞춰야 했다.

---

후반: 핵심 기능이 흔들리니까 모든 게 같이 흔들렸다

후반에 가장 힘들었던 건 역시 시선 추적이었다.

우리 서비스에서 시선 추적은 부가 기능이 아니라 핵심 기능이었다.
환자가 눈으로 선택하는 서비스인데, 그 입력이 흔들리면 전체 서비스가 흔들릴 수밖에 없었다.

프론트에서는 AI가 보내주는 값을 받아서
어떤 셀을 보고 있는지,
어떤 버튼을 선택 중인지,
언제 선택 완료로 볼지 연결해야 했다.

그런데 후반까지도 이 값이 안정적으로 맞지 않거나,
캘리브레이션과 실제 런타임의 느낌이 다르거나,
AI와 프론트 중 어디서 최종 선택을 판단해야 하는지 애매한 순간들이 있었다.

그때마다 머릿속이 복잡해졌다.

“이건 AI 값이 이상한 건가?”
“프론트에서 다시 계산하다가 꼬인 건가?”
“좌표는 들어오는데 화면 매핑이 이상한 건가?”
“선택 이벤트는 왔는데 버튼이 못 받는 건가?”
“아니면 내가 뭘 잘못 연결한 건가?”

이 시기가 제일 힘들었다.

핵심 기능이 흔들리니까
환자 모드 UX도, 시연 준비도, 자신감도 같이 흔들렸다.

전날까지 핵심 기능이 마음처럼 안정되지 않았고,
솔직히 말하면 진짜 울고 싶었다.

아니, 실제로 집 가는 길에 운 적도 있다.

그래도 멈출 수는 없었다.

어떻게든 발표 때 보여줄 수 있는 흐름을 만들어야 했고,
환자 모드의 핵심 시나리오가 끊기지 않게 해야 했고,
팀 전체가 만든 결과물을 잘 보여줘야 했다.

그래서 후반에는 완벽한 고도화보다는
핵심 시나리오를 안정적으로 보여주는 것에 집중했다.

---

이 과정에서 제일 크게 느낀 것

이번 프로젝트를 하면서 가장 크게 느낀 건
서비스는 기능 목록대로 완성되는 게 아니라는 점이었다.

기능 명세서에 있는 항목을 하나씩 체크한다고 해서
바로 좋은 서비스가 되는 건 아니었다.

특히 EyeSpeak처럼 AI, 실시간 입력, 환자 UX가 섞인 서비스는
각 파트가 따로 완성되는 것보다
서로 연결됐을 때 자연스럽게 동작하는지가 훨씬 중요했다.

AI가 값을 잘 줘도 프론트가 그 값을 제대로 소비하지 못하면 안 되고,
프론트 화면이 잘 만들어져도 입력 흐름이 불안정하면 안 되고,
백엔드 API가 있어도 실제 사용자 시나리오와 맞지 않으면 다시 조정해야 했다.

결국 프로젝트 중반 이후부터는
“내 화면만 잘 만들면 된다”가 아니라
“이 서비스가 처음부터 끝까지 하나의 흐름으로 보이는가”를 계속 봐야 했다.

이게 힘들었지만, 가장 많이 배운 부분이기도 했다.

---

그래도 팀이 끝까지 끌고 갔다

힘든 순간이 많았지만, 그래도 우리 팀은 끝까지 했다.

누구 하나 대충 넘기지 않았고,
각자 맡은 부분을 계속 붙들고 있었고,
안 되는 부분이 있으면 어떻게든 해결하려고 했다.

나도 중간중간 멘탈이 많이 흔들렸지만,
팀원들이 각자 자리에서 계속 해주고 있었기 때문에
나도 놓을 수 없었다.

결과론적으로 해냈다고 말할 수 있는 건,
정말 다들 미친 듯이 했기 때문이라고 생각한다.

기능이 늦게 붙어도,
흐름이 꼬여도,
시연이 불안해도,
계속 다시 보고 다시 맞췄다.

그래서 최종 결과가 좋았을 때 그냥 기쁜 것보다
“그래도 우리가 한 게 헛되지 않았구나”라는 생각이 더 컸다.

 

---

내가 맡았던 일

이번 프로젝트에서 나는 프론트엔드, 그중에서도 주로 환자 모드 화면과 시선 입력 UX를 맡았다.

처음에는 화면을 만들고 API를 연결하면 될 줄 알았다.
그런데 막상 해보니까 환자 모드는 일반적인 웹 화면과 완전히 달랐다.

보통 웹 서비스에서는 사용자가 마우스로 버튼을 누른다.
하지만 EyeSpeak에서는 사용자가 손이 아니라 눈으로 선택해야 했다.

그래서 단순히 버튼을 배치하는 게 아니라,
사용자가 지금 어디를 보고 있는지,
선택 중인지,
선택이 완료됐는지,
실수했을 때 다시 돌아갈 수 있는지까지 계속 고려해야 했다.

나에게 주어진 공간은 최대 6칸이였다...정말이지 한 창의력 한다고 생각했는데..진짜 어려웟다

특히 환자 모드는 기능이 많았다.

대화하기, 호출, 여가, 즐겨찾기, 몸과 마음 표현, 추천 답변, 직접 입력 등
각 기능이 따로 있는 것처럼 보였지만, 실제로는 전부 하나의 흐름 안에서 이어져야 했다.

화면마다 시선 선택 방식이 달라지면 안 됐고,
선택 피드백도 일관적이어야 했고,
뒤로가기나 전역 메뉴 같은 공통 UX도 계속 유지되어야 했다.

그래서 내가 한 일은 단순히 “화면을 만들었다”기보다는,
환자 모드가 실제 서비스처럼 동작할 수 있도록
화면 구조, 입력 흐름, 상태 변화, 예외 흐름을 계속 맞추는 일에 가까웠다.

 

힘들었던 점도 많았지만, 그래도 내가 잘했다고 생각하는 부분도 있다.

첫 번째는 사용자 입장에서 계속 보려고 했던 것이다.

EyeSpeak는 일반적인 서비스가 아니라
ALS 환자를 위한 의사소통 보조 서비스였다.

그래서 “기능이 된다”보다 더 중요한 게 있었다.

실제로 쓸 수 있어야 했다.

화면이 예뻐도 시선으로 선택하기 어렵다면 의미가 없고,
기능이 많아도 환자가 흐름을 따라가기 어렵다면 좋은 서비스라고 보기 어려웠다.

그래서 계속 이런 걸 생각했다.

“이 화면에서 환자가 헷갈리지 않을까?”
“시선 이동이 너무 많지 않을까?”
“선택 실수가 났을 때 다시 돌아갈 수 있을까?”
“보호자와의 소통 흐름이 끊기지 않을까?”
“이 기능이 진짜 환자에게 필요한 방식으로 제공되고 있을까?”

두 번째는 끝까지 붙들고 갔다는 것이다.

중간에 막히는 부분도 많았고,
어떤 문제는 원인을 찾는 데 오래 걸렸고,
발표 전까지도 불안한 부분이 계속 있었다.

그래도 놓지는 않았다.

환자 모드 흐름을 정리했고,
시선 입력 UX를 맞췄고,
AI 값이 화면 선택으로 이어지도록 계속 확인했고,
시연 가능한 상태까지 끌고 갔다.

완벽했다고 말할 수는 없지만,
끝까지 해냈다는 점은 스스로 인정해주고 싶다.

 

그렇게 프로젝트가 끝나는 줄 알았는데,
우리 팀은 본선에 진출했다.

좋았다.
진짜 행복했다.

그런데 동시에 이런 생각이 들었다.

“아… 이거 끝난 게 아니구나.”

밤새서 준비했었다 발표도 근데 당장 이틀뒤가 본선 발표란다.

본선에 갔다는 건
이제 한 번 더 제대로 보여줘야 한다는 뜻이었다.

그래서 발표 준비도 다시 해야 했고,
시연 흐름도 다시 정리해야 했고,
우리 서비스의 핵심 가치를 더 잘 보여줄 수 있도록 다듬어야 했다.

특히 EyeSpeak는 그냥 화면만 보여주면 되는 서비스가 아니었다.
시선 추적 기반 서비스였기 때문에, 실제로 눈으로 선택하는 흐름이 보여야 했다.

그런데 시연은 항상 무섭다.

연습할때는 됐는데 발표장에서는 안 될 수 있고,
방금까지 됐는데 갑자기 안 될 수 있고,
카메라, 조명, 네트워크, 캘리브레이션 같은 외부 변수도 많았다.

특히 발표시간이 촉박한데 오류가 난다?  그러면 이제 사고다 나의 기특하고 기특한 예린이의 발표를 망칠 수도 있다는 것이다.

그래서 본선 준비 기간은
개발이 끝난 뒤의 여유 시간이 아니라,
서비스를 한 번 더 보여줄 수 있는 형태로 다듬는 시간이었다.

발표 자료도 다시 보고,
시연 순서도 다시 맞추고,
어떤 장면에서 우리 서비스의 가치가 가장 잘 보일지 계속 고민했다.

 

그리고 이번 프로젝트에서 기억에 남는 것 중 하나는 README였다.

처음에는 README가 제대로 정리되어 있지 않았다.
하지만 프로젝트가 끝나고 나면 결국 남는 건 코드만이 아니었다.

이 프로젝트가 어떤 서비스인지,
무슨 문제를 해결하려고 했는지,
어떤 기능이 있는지,
어떤 기술을 사용했는지,
어떤 흐름으로 동작하는지 정리된 문서도 필요했다.

그렇지만 우리는 바로 본선준비를 한다고 리드미를 만들 시간이 없었다

이틀 안에 모든 걸 해결해야했다.

솔직히 말하면 README 작성도 생각보다 오래 걸렸다.

기능 시연 이미지도 정리해야 했고,
서비스 설명도 써야 했고,
기술 스택도 정리해야 했고,
팀원 역할과 프로젝트 구조도 보기 좋게 맞춰야 했다.

README는 단순히 “문서 하나 작성”이 아니라,
프로젝트를 처음 보는 사람이 이해할 수 있게 다시 설명하는 작업이니...

그래도 만들고 나니까 마음이 편해졌다.

프로젝트 GitHub 링크

EyeSpeak GitHub Repository
https://github.com/hyeryeongeda/eyespeak

---

그래서 1등이라는 결과가 더 크게 느껴졌다

처음부터 모든 게 잘 풀린 프로젝트는 아니었다.

기획도 계속 다듬어야 했고,
환자 모드 UX도 계속 고민해야 했고,
AI와 프론트 연결도 쉽지 않았고,
핵심 기능은 마지막까지 불안했고,
본선에 가서는 발표와 시연도 다시 준비해야 했다.

그래서 최종적으로 1등을 했을 때,
그냥 “와 1등했다!”라는 느낌만 있었던 건 아니었다.

물론 좋았다.
진짜 좋았고 행복했지.

그런데 그보다 먼저 든 생각은
“아… 그래도 우리가 한 게 헛되지 않았구나”였다.

완벽해서 받은 결과는 아니었다고 생각한다.

하지만 끝까지 포기하지 않았고,
문제가 생겨도 다시 맞췄고,
팀원들이 각자 맡은 부분을 계속 붙들고 갔기 때문에 받을 수 있었던 결과라고 생각한다.

선녀들 최고

---

이번 프로젝트를 통해 배운 것

이번 프로젝트를 하면서 가장 크게 배운 건
기능을 만드는 것과 서비스를 완성하는 것은 다르다는 점이었다.

기능 하나하나는 만들 수 있다.
버튼도 만들 수 있고, 화면도 만들 수 있고, API도 붙일 수 있다.

하지만 그 기능들이 실제 사용자 흐름 안에서 자연스럽게 이어지는지는 또 다른 문제였다.

특히 EyeSpeak처럼
AI, 실시간 입력, 환자 UX, 보호자 소통이 함께 들어가는 서비스는
각 파트가 따로 잘 되는 것만으로는 부족했다.

서로 연결됐을 때 자연스럽게 동작해야 했다.

AI가 값을 잘 줘도 프론트가 제대로 소비하지 못하면 안 되고,
화면이 잘 만들어져도 시선 입력 흐름이 불안정하면 안 되고,
API가 있어도 실제 사용자 시나리오와 맞지 않으면 다시 조정해야 했다.

다음에 비슷한 프로젝트를 한다면,
초반부터 더 빨리 연결하고,
더 빨리 검증하고,
AI와 프론트 사이의 기준을 더 명확하게 잡고 싶다.

이번에는 늦게 깨달아서 힘들었던 부분들이 있었지만,
그래도 그만큼 확실하게 배웠다.

---

마무리

이번 특화프로젝트는 정말 힘들었다.

진짜 힘들었다.

중간중간 멘탈도 많이 흔들렸고,
전날까지도 불안했고,
집 가는 길에 울 정도로 막막했던 순간도 있었다.

하지만 그래도 끝까지 했다.

본선도 갔고,
발표 준비도 다시 했고,
시연도 준비했고,
README도 만들었고,
결국 1등도 했다.

완벽한 프로젝트는 아니었다.
아쉬운 점도 많았다.

하지만 그래서 더 기억에 남을 것 같다.

이번 프로젝트는 나에게
힘들었지만 끝까지 해낸 프로젝트,
많이 흔들렸지만 많이 배운 프로젝트,
그리고 결과까지 좋아서 정말 다행이었던 프로젝트로 남을 것 같다.