[소셜벤처창업 26-1] 회고록

기획

기획 및 유저 타겟팅 (3월 초)

기획과 관련된 건 주로 PM 역할이 독립적으로 담당했었기 때문에, 실제로 프로덕트 디자인에 참여할 일이 없을 거라 생각했었다. 이번 수업을 수강하면서 문제 인식 과정에 직접 참여하게 되어 인상 깊은 경험을 했다. 개발 파트를 맡아 (프론트, 백 및 배포 전반) 진행하였다. ‘사회적 포용’이라는 주제로 매칭되었고, 링크 이주민통번역협동조합의 김나현 사회혁신가님과 함께했다. 이주민 통번역이라는 주제였기 때문에, 맨 처음 이해관계자 맵을 작성할 때 이주민을 중심으로 한 맵을 그렸다. 그리고 이주민 자녀가 학업에 어려움을 겪을 것이라고 막연하게 가정한 채 문제 설정을 진행했다. 지금 돌아보면 이 출발점 자체가 우리가 현장을 모른 채 머릿속으로만 그린 그림이었다.

필드트립 (3월 말)

처음 가자마자 국밥 먹었다.

센터가 부산에 있어서 주말에 방문하게 되었다. 3월 29일에 방문했었는데, 해당 일은 잊지 못할 것 같다. 무조건 그 주에 방문해야 하는 상황이었어서, 어쩌다보니 생일날을 부산에서 보내게 되었다. (ㅜㅜ)

생일 축하

필드트립은 주제의 방향을 통째로 뒤엎는 계기가 됐다. 센터장님은 예산과 이주민 인권 문제가 제일 크다고 하셨는데, 이건 학생 입장에서 손댈 수 있는 영역이 아니라 정부가 정책으로 풀어야 하는 문제라고 판단했다. 그래서 큰 범위의 피봇팅을 진행했다. 그 와중에 “언제 어디서든 신뢰할 수 있는 언어 지원과 정보에 접근할 수 있었으면 좋겠다”는 말씀을 해주셨다. 현장에서는 정책 얘기에 묻혀 흘려들었는데, 돌아와서 곱씹어보니 이건 서비스로 풀 수 있는 문제였다. 정책으로 풀어야 할 거대한 문제들 사이에서, 우리가 실제로 손댈 수 있는 지점이 거기 있었던 것이다.

부산역에서 주저앉아 기차를 기다린 기억이 난다.

그래서 이주민이 ‘도움받는 사람’이 아니라 ‘주체’로 작동하고, 그 자립을 돕는 것을 팀 목표로 삼고 진행했다.

문제 정의의 공백 (4월 중순)

피봇팅 이후에도 문제 정의는 한동안 계속 흔들렸다. 가장 큰 긴장은 이거였다. 우리 서비스의 실제 주 사용자는 통번역가일 텐데, 정작 우리가 만들려는 건 이주민 중심이다. 주 사용자의 니즈가 반영된 게 맞나? 확인하려고 통번역 활동가 대상 서면 인터뷰(구글폼)를 돌렸는데 응답이 거의 오지 않았다. 어렵게 진행한 이은주 통번역사님 인터뷰에서는, 현재 과정에 특별한 불편을 못 느끼신다는 답이 돌아왔다. 사용자 인터뷰의 공백이 그대로 드러난 순간이었다. 결국 이주민 당사자를 인터뷰하지 못한 채로, 가설(이주민은 불편을 겪고, 통번역가를 도우면 이주민의 불편도 개선된다) 위에서 중간점검 발표를 했다. 다른 학교 팀들과 비교하니 차이가 분명했다. 한양대 쪽은 이미 기술 구현이 한참 앞서 있었고, 우리는 앞단(문제 정의)을 깊게 판 상태였다. 어느 쪽이 맞다기보다 교수님마다 진행 방식이 달랐던 것 같지만, 개발자 입장에선 “이제 좀 치고 나가야겠다”는 조급함이 컸다. 그래서 프로토타입을 먼저 구현하고 보여드렸던 기억이 난다.

개발 및 멘토링

특강 들으면서 개발을 진행했었다.. 마음이 급해서

피봇팅 때문에 기획이 여러 번 바뀌었고, 그에 따라 디자인 수정이 밀리면서 개발도 함께 늦어졌다. 기획 → 디자인 → 개발이 순서대로 막혀버리는 전형적인 상황이었다. 팀원들이 개발에 관여하지 않는 상황이라, 최대한 소통을 잘 하기 위해서 문서화도 소홀히 하지 않으려고 했던 것 같다. https://safe-thyme-99b.notion.site/home-33bf21863f67809c9246d08704b5c8bd?source=copy_link 에 모든 걸 정리하여 설명했었다.

원래 백엔드만 해왔는데, 이번엔 프론트엔드도 해보고 싶어서 자원했다. 결과적으로 프론트·백엔드·인프라·AI 연동·배포·UT 환경까지 전부 혼자 맡았는데, 그 부담에 대한 거부감은 크지 않았다. 오히려 한 사람이 풀스택을 다 쥐고 있으니 기획이 바뀔 때마다 빠르게 따라붙을 수 있었다. 대신 새벽 작업이 반복됐다.

4월 말, 일단 만들어서 보여주기로 했다.

4월 25일에는 마음이 급해져서 프로토타입을 먼저 제작했었고,

5월

이 시기에 기술 스택을 확정하고 트러블슈팅을 반복했다.

기술 스택과 선정 배경

• 이주민이 별도 앱 설치 없이 모바일에서 바로 쓸 수 있도록 PWA로 만들었다. iOS는 사파리 ‘홈 화면에 추가’, 안드로이드는 삼성 인터넷·크롬의 ‘홈 화면에 추가’로 앱처럼 쓰도록 안내했다.
• 인증 서버를 직접 구축하는 리소스를 아끼고 프로토타입을 빠르게 검증하려고 Supabase를 택했다. 이번에 새로 써보는 스택이었다.
• 기획 단계 특성상 DB 구조가 자주 바뀔 게 뻔해서, Flyway로 스키마 버전 관리를 선제적으로 깔았다.
• AI는 처음엔 Claude API를 고려했다가 Gemini API(저비용 모델)로 갔다. 핵심 작업이 복잡한 추론이 아니라 의료 문장을 항목 단위로 쪼개는 수준이라, 비싸고 똑똑한 모델을 쓸 이유가 없었다. 오히려 너무 똑똑한 모델은 없는 정보를 스스로 붙이는(hallucination) 경향이 있어서, 가벼운 모델이 이 태스크엔 더 안전하고 정확했다. 토큰 단위 과금이라 사용량이 늘어도 만 원도 안 들 규모였고, 덕분에 30만 원 활동비 중 15만 원 선에서 개발을 끝낼 수 있었다.

6월

리팩토링을 이어가며 6월 6일즈음에 MVP 1차 개발을 마무리했다.

MVP 범위

초기 기획은 훨씬 넓었지만, 학기 내 구현 가능한 범위로 좁혔다. 최종적으로 세 역할(센터장·통번역가·이주민)을 중심으로 아래 기능을 MVP로 선정했다. 핵심 차별점은 이주민이 의사에게 직접 보여주는 의료 대본을 전체화면(/scripts/[id]/present)으로 띄우는 기능이었다. ‘이주민이 주체가 된다’는 목표가 가장 직접적으로 드러나는 화면이다. 부위별(머리·코·입·목·눈·가슴 등) 분류로 증상을 고르고, 진료 내용을 AI가 모국어로 구조화해 보여주는 흐름이다.

2차 개발 및 트러블슈팅, QA를 반복하며 발표날에 최종 완성을 했던 기억이 난다.

배포와 브랜딩

처음엔 도메인을 안 사서 배포할 때마다 Vercel 주소가 바뀌는 게 불편했다. 서비스명이 Cura(라틴어로 돌봄·치유·배려)로 확정되고 나서 cura-ewha.kr(이후 www.cura-ewha.kr)을 구매해 붙였다.

사용자 테스트(UT) 환경을 직접 만들다

UT 관련 공지

팀원들과 함께 해서 공지문도 작성했었다. #### 📋 이주민 의료정보 플랫폼 Cura — 사용자 테스트 참여 안내 안녕하세요. 저희는 이화여자대학교 「소셜벤처창업」 수업을 수강 중인 뽀용뽀용팀입니다. 카카오임팩트 Tech for Campus 프로젝트의 일환으로, 이주민 환자들이 병원 진료 이후에도 자신의 건강 정보를 쉽게 확인하고 관리할 수 있도록 돕는 의료정보 플랫폼 Cura(큐라) 를 개발하고 있습니다. 이번 테스트에서는 화면이 쓰기 편한지뿐 아니라, 이 서비스가 실제로 한국 생활과 병원 이용에 도움이 될지 여러분의 솔직한 의견을 듣고 싶습니다. #### 참여 방법 (약 10~15분) 1. Cura 직접 체험하기

• 이주민 환자용 → https://www.cura-ewha.kr/ut?role=patient
• 통번역가용 → https://www.cura-ewha.kr/ut?role=interpreter 2. 모국어 설문 작성하기 (체험 후, 아래 안내 내용도 폼 안에 동일 언어로 담겨 있습니다) #### Cura에서 체험할 수 있는 기능 병원에 다녀온 뒤 이런 경험, 있으셨나요? 의사 선생님 말씀을 다시 확인하고 싶었던 적, 약을 어떻게 먹어야 할지 헷갈렸던 적, 한국어가 어려워 하고 싶은 말을 제대로 전하지 못했던 적. Cura는 이런 어려움을 줄이고, 자신의 건강 정보를 스스로 이해하고 관리할 수 있도록 만들었습니다.
• 진료 기록 확인 — 진단 내용, 약 복용 방법, 검사 결과를 모국어로 한곳에서 확인
• 의료 대본 — 병원에서 하고 싶은 말을 미리 준비하고 증상 설명 연습
• 긴급전화 — 응급상황 시 필요한 기관 연락처를 빠르게 확인

  설문 내용은 서비스 개선 목적으로만 사용되며, 개인정보는 수집하지 않습니다. 여러분의 의견은 앞으로 더 많은 이주민들이 한국에서 스스로 건강을 관리하는 데 큰 힘이 됩니다. 참여해 주셔서 감사합니다! — 뽀용뽀용팀 드림 UT는 통번역가 대상 실시간 인터뷰(구글미트, 시나리오 기반)와 이주민 대상 자율 사용 후 설문(언어별 구글폼: 러시아어·베트남어·중국어·필리핀어)으로 나눠 진행했다. 통번역가분들은 부산 센터 소속이라 실시간으로, 이주민은 직접 만나기 어려워 폼으로 받았다. 테스트 마찰을 줄이려고 개발 쪽에서 두 가지를 준비했다.

  1. 로그인 우회 링크 — /ut?role=patient, /ut?role=interpreter로 접속하면 미리 세팅한 환자·통역가 계정으로 바로 진입하게 했다. 회원가입·센터 등록 플로우를 건너뛰어, 평가 대상인 핵심 기능에 곧장 닿게 하기 위함이었다.
  2. 세션 녹화(rrweb) — 사용자가 화면에서 무엇을 눌렀는지 자동으로 기록되게 붙였다. 인터뷰 때 음성은 따로 녹음했지만, 행동 자체는 녹화로 남겨 어디서 막히는지 볼 수 있었다. UT에서 나온 피드백 중 기억에 남는 것:

• 중국어 응답자들이 진료보고서 화면이 한국어로 떠서 이해를 못 했다고 했다. 언어를 중국어로 설정해도 일부 화면이 한국어로 나오는 i18n 버그가 있었고, 급히 고쳤다.
• AI 번역이 매 멘트가 달라, 처음엔 길게 쓴 진료 내용을 핵심 단어만(예: “위염”) 남기고 뭉뚱그렸다. 프롬프트에 “의료통번역가처럼 전문성 있게 번역해줘” 식으로 역할·기준을 명시하니 품질이 안정됐다.
• 긴급전화 기능에 “어차피 한국어로 말을 못 하니 도움이 안 될 것 같다”는 의견이 있었다. 실제로는 112(영어·중국어 통역), 119(다누리 콜센터 등), 긴급신고 바로앱(영어·중국어·베트남어·필리핀어)처럼 외국어 신고가 가능한 채널이 있어서, 그걸 언어별로 표시해주는 방향으로 보완했다.

  기타 트러블슈팅

  낯선 배포 조합(Railway + Supabase + Vercel)이다 보니 평소 AWS에서 안 겪던 이슈를 새로 만났다. 1. Railway 콜드 스타트 / 응답 지연 — 초기엔 백엔드 응답 대기시간이 길었다. 리전을 바꿔도 개선이 더뎌서 한때 AWS EC2 이전을 고민했다. 저가 티어 인스턴스의 콜드 스타트 특성이 원인이었다. 2. HikariCP ↔ Supabase PgBouncer 충돌 — Supabase PgBouncer(트랜잭션 모드)는 커넥션을 트랜잭션 단위로 재할당하기 때문에, Hibernate의 server-side prepared statement 캐시가 깨졌다. prepareThreshold=0으로 끄고 커넥션 풀 파라미터를 조정해 해결했다. (커밋 3d0d81e, 4fc70d2) 3. 인증 플로우 무한 루프 — 카카오 로그인과 전화번호(SMS) 인증 회원가입을 붙이는 과정에서 콜백·리다이렉트 처리가 꼬여 무한 루프가 났다. (커밋 43266d1) UT 때는 매번 인증받는 부담을 줄이라는 피드백을 받아, 전화번호 입력만으로 진입하는 방향으로 간소화했다. 4. JWT role 동기화 — Supabase JWT는 발급 시점의 스냅샷이라, 역할(app_role)이 바뀌어도 토큰 만료 전까지 옛 값을 들고 있었다. 매 요청마다 DB 기준으로 역할을 보정하도록 처리했다. 5. Vercel 빌드 환경변수 — NEXT_PUBLIC_*는 빌드 타임에 번들에 박히는 특성 때문에 GitHub Secrets와 Vercel 대시보드 양쪽에 등록해야 했다. 한쪽만 넣으면 빌드는 통과하는데 런타임에서 값이 비어 한참 헤맸다. 6. i18n 누락 — 언어를 중국어로 설정해도 진료보고서 등 일부 화면이 한국어로 떴다. UT에서 바로 드러나 급히 고쳤다. 7. AI 번역 품질 — 가벼운 모델이라 긴 진료 내용을 핵심 단어만 남기고 뭉뚱그리는 경우가 있었다. 프롬프트에 역할·기준을 명시해 품질을 안정화했다. 8. 매칭 구조 변경 — 통번역가:이주민 매칭을 N:N에서 N:1로 변경했다. (커밋 0fb48a7) 9. rrweb 세션 녹화 도입·정리 — UT용으로 세션 녹화를 붙였다가, 로직을 정리하며 일부 걷어냈다. (커밋 2888cf1, 6eb52d0)

  성과

성과발표회에서 혁신기술상으로 마무리했다. 발표는 기획 6분, 개발 4분 정도로 나눠 서버 구조와 프론트 구현을 설명하고, 시연은 영상으로 보여줬다. 팀원 모두 서비스를 계속 다듬어 나가고 싶어 해서, 후속 작업 방향을 멘토 측에 문의해둔 상태다. 혼자 다 맡는 게 부담일까 걱정했는데, 막상 해보니 기획·디자인의 잦은 변경을 개발이 실시간으로 흡수할 수 있다는 게 솔로 풀스택의 가장 큰 장점이었다. 동시에, 사용자 인터뷰의 공백 같은 건 개발 속도로는 메울 수 없는 종류의 문제라는 것도 배웠다. 좋은 서비스는 잘 만드는 것만큼이나, 누구의 문제를 푸는지를 끝까지 붙들고 있는 데서 나온다. 사실 발표 전날에는 9시간 정도 학교에서 (12시에 나왔다) 준비를 했다. 장표 제작, 코드 수정, 대본 낭독 및 시간 조정까지 했었는데, 결과가 좋으니 뿌듯하기도 (노력한 만큼 보상을 받은 기분이었어서…)

핑크머리가 참 눈에 많이 띈다

서비스는 아직 진행 중

발표는 끝났지만 서비스를 닫진 않았다. 팀원 모두 Cura를 계속 다듬고 싶어 했고, 무엇보다 발표 전 UT에서 “사용자 인터뷰의 공백”을 끝내 메우지 못한 게 마음에 남았다. 통번역가 인터뷰는 했지만 이주민 당사자는 폼으로밖에 받지 못했고, 그마저 응답이 충분치 않았다. 그래서 지금은 실제 환자분들이 직접 써보고 남겨주는 피드백을 모으는 단계다. 앞으로 서비스를 이어나갈 방안을 모색하고, 최대한 보전할 계획이다.