• 

  KNU-Matzip

  학생들의 맛집 정보를 한곳에 모아, 제공하는 서비스

  2025.09 ~ 2025.11

  Tech Stack

  

• 

  Reev

  개인과 모임이 성찰을 통해 함께 성장하는 회고 서비스

  2025.01 ~ 2025.07

  Tech Stack

  

• 

  택시팟 (Taxi-Mate)

  택시를 함께 이용할 학생들을 모집하는 서비스

  2024.06 ~ 2024.10

  Tech Stack

  

개발자뿐 아니라 다양한 직군이 함께 고민하는 문제일 것입니다. 공통적으로는 AI로 인한 생산성 향상에 대한 기대와 함께, 대체 가능성에 대한 불안도 동시에 느끼는 것 같습니다.

• 폰트 리소스 경량화를 통한 LCP 73% 개선 (5.9s → 1.6s)

  📌 Lighthouse · 웹폰트(.woff2) 전환 및 서브셋 적용

  서비스 초기 로딩 속도가 느리다는 문제를 해결하는 과정에서, 폰트 리소스 최적화를 통해 LCP(Largest Contentful Paint)를 크게 개선한 경험이 있습니다.

  원인

  Lighthouse 성능 측정 결과, LCP가 5.9초까지 지연되고 있었으며, 주요 원인이 6.7MB에 달하는 대용량 폰트 파일임을 확인했습니다. 초기 설정 과정에서 웹 최적화 포맷(.woff2)이 아닌 로컬 설치용 폰트(.ttf)가 그대로 적용되어 있었던 것이 문제였습니다.

  조치

  • 폰트 포맷을 웹 최적화 형식(.woff2)으로 변경하여 용량을 6.7MB에서 2.1MB로 약 69% 감소
  • 실제 서비스에서 자주 쓰이는 한글 2,350자와 필수 기호만 포함하는 서브셋 폰트 적용으로 불필요한 데이터 제거

  결과

  최종적으로 폰트 용량을 1.4MB까지 줄이며 약 79% 경량화에 성공했고, LCP를 5.9초에서 1.6초로 약 73% 단축시킬 수 있었습니다.

  이 경험을 통해 성능 문제는 단순한 설정 변경이 아니라, 병목 지점을 정확히 측정하고 단계적으로 개선하는 과정이 중요하다는 것을 배웠습니다.

• 데이터 캐싱에 따른 정합성 훼손 해결

  📌 모임(팟) 참여 기능 · 캐시와 서버 상태 불일치

  프로젝트에서 사용자들이 모임(팟)에 참여할 수 있는 기능을 개발하던 중, 상세 페이지에서 데이터 캐싱으로 인해 정합성 문제가 발생했고, 이를 해결하는 과정에서 백엔드 개발자와 의견 충돌을 겪었습니다.

  배경

  당시 페이지 로딩 속도를 개선하기 위해 상세 페이지 데이터를 일정 시간 캐싱하고 있었습니다. 하지만 이로 인해 서버의 최신 상태가 즉시 반영되지 않는 문제가 발생했습니다. 예를 들어, 사용자가 모임에 참여했음에도 화면에는 여전히 참여 전 상태로 보이거나, 이미 정원이 초과된 상황에서도 참여 가능한 것처럼 표시되는 등 실제 데이터와 UI 간 불일치가 발생했습니다.

  의견 차이

  이 문제의 원인을 캐싱으로 판단한 백엔드 개발자는 정합성을 위해 캐싱을 제거하자는 입장이었고, 저는 캐싱을 제거할 경우 동일한 데이터를 반복 요청하게 되어 서비스 성능이 저하될 수 있다고 보았습니다.

  훼손 시나리오

  • 참여 상태 인지 어려움

    팟 참여 후 다시 진입 시 캐시된 데이터로 인해 UI가 업데이트되지 않아 참여 여부 파악이 어려웠습니다.

  • 데이터 불일치

    3/4 상태에서 사용자 A가 먼저 참여하고 B가 뒤늦게 요청하면, B는 실패 응답을 받지만 화면에는 여전히 3/4로 표시되는 문제가 있었습니다.

  해결 방법

  서로의 관점을 공유하며 해결 방안을 논의한 끝에, 캐싱을 유지하되 캐싱 시간을 최소화하고, 사용자가 모임에 참여하는 순간에는 refetch를 통해 서버의 최신 데이터를 즉시 반영하는 방식으로 합의했습니다.

  이를 통해 데이터 정합성을 확보하고, 캐싱으로 얻는 이점은 유지하면서 불필요한 네트워크 요청 증가와 사용자 경험 저하를 방지할 수 있었습니다.

  이 경험을 통해 협업에서는 단순히 각자의 방식을 고수하기보다, 문제의 원인을 명확히 정의하고 서로의 기준을 이해한 뒤 균형점을 찾아가는 과정이 중요하다는 것을 깨달았습니다. 이후에는 기능 구현 전 데이터 처리 방식과 같은 핵심 전제를 먼저 공유하며 협업을 진행하고 있습니다.

• 사용자 전환 비용을 간과해 유입에 실패했던 택시팟 경험

  📌 사용자 행동 기반 제품 설계의 중요성 학습

  사용자의 문제를 해결하는 서비스를 만들고자 했지만, 실제 사용자 선택을 고려하지 못해 실패를 경험한 적이 있습니다.

  배경

  재학 중인 대학에서는 대중교통 접근성이 낮아 학생들이 택시를 함께 타기 위해 500명 규모의 오픈 채팅방을 사용하고 있었습니다. 메시지 탐색의 비효율과 과도한 알림 문제를 해결하고자 ‘택시팟’ 서비스를 개발했지만, 기대와 달리 사용자 유입이 거의 발생하지 않았습니다.

  실패 원인

  초기에는 기능 부족을 원인으로 생각했지만, 실제 문제는 사용자의 행동을 충분히 고려하지 않은 제 판단에 있었습니다. 이미 많은 학생들이 익숙하게 사용하고 있는 카카오톡을 떠나 새로운 서비스로 이동해야 한다는 전환 비용을 간과했고, 신뢰성을 높이기 위해 도입한 실명 기반 소셜 로그인 또한 오히려 진입 장벽으로 작용했습니다.

  학습한 점

  이 경험을 통해 문제 해결에서 중요한 것은 기능의 완성도가 아니라, 사용자가 실제로 행동할 수 있는 환경을 설계하는 것이라는 점을 깨달았습니다.

  이후 적용

  이후 ‘KNU-Matzip’ 프로젝트에서는 이러한 실패를 반영해, 소셜 로그인은 유지하되 랜덤 닉네임 시스템을 도입해 부담을 낮추고, 초기 참여를 유도하는 구조를 설계했습니다.

  그 결과 MAU 300명을 달성하며 실제 사용자 유입을 만들어낼 수 있었습니다.