앞으로 세 번의 프로젝트를 더 거쳐 서비스 ‘런피(LernP)’를 만들어갈 예정입니다.
이 글은 그중 첫 번째 프로젝트에서 제가 개발을 리드하며 겪은 기술/비즈니스적 변화와 협업 방식에 대한 회고입니다.
처음으로 서비스 전체 흐름을 책임지는 역할에 가까운 프로젝트였기에, 더 많이 부딪혀 보자는 마음으로 임했습니다.
챌린지 포인트
좋은 아키텍처는 한 번에 완성되는 구조가 아니라, 같이 쓰면서 계속 다듬어 가는 방향성에 가깝다고 느꼈습니다.
마이그레이션과 스택 재설계
기존 HTML + CSS + JS + LocalStorage 기반 프로젝트를
React + Vite + CSS Modules + Firebase 스택으로 마이그레이션했습니다.
그 과정에서 라우팅 설계, 인증/인가, 데이터 구조를 처음부터 다시 바라볼 수 있었습니다.
Next.js의 편의성에 익숙하다 보니, 라우터 설정과 설계를 충분히 하지 않으면 권한 처리·에러 핸들링에서 문제가 커질 수 있다는 점을 순수 React 환경에서 다시 한 번 느꼈습니다.
Vite를 사용하면서 번들링 과정에 대한 이해도 넓어졌고, Firestore와 Firebase Authentication을 통해 NoSQL 구조 설계 및 인증/인가 플로우 구현을 경험했습니다.
최소한의 변경으로 대응 가능한 데이터 구조
프론트에서 다루기 편한 객체 구조이면서도, 데이터베이스 입장에서는 빠르게 조회 가능한 스키마 사이의 균형을 고민했습니다.
- 추후 마이그레이션이 필요해질 때
- 서버 개발자와 API로 통신하게 될 때
- NoSQL → RDB 전환 가능성이 생겼을 때
프론트 입장에서 최소한의 데이터 구조 변경으로 대응 가능한지를 기준으로 설계했습니다.
DX를 고려한 폴더 구조 설계
프로젝트가 커질수록 폴더 구조가 깊어지거나, 반대로 한 폴더 안에 파일이 쌓이기 쉽다고 느꼈습니다.
이를 방지하기 위해, 상위는 도메인 단위로 나누고 도메인 내부는 역할(페이지/컴포넌트/로직/유틸) 기준으로 묶는 구조로 설계했습니다.
UX를 고려한 수강생 -> 강사 전환 플로우
사용자 입장에서 자연스럽고 서비스 정책 변화에도 유연한 플로우를 만들고자 했습니다.
모두 수강생으로 시작한 뒤 필요 시 강사 권한을 부여하는 방식이 사용자 유입 장벽을 낮춘다고 판단했습니다.
강사는 “수강생으로서” 런피의 기능을 대부분 경험한 뒤, 자연스럽게 “수강생 → 강사”로 전환되는 흐름을 가지게 됩니다.
- 가입 직후 →
['USER'] - 강사 승인 후 →
['USER', 'INSTRUCTOR']
이렇게 한 사용자가 여러 역할을 동시에 가질 수 있도록 해 두면, 추후 기능 단위 권한으로 쪼개기에도 유리하다고 봤습니다.
라우팅과 에러 핸들링을 통한 권한 처리
권한 처리를 설계할 때는
- 누가 어떤 페이지에 접근할 수 있는지
- 접근 불가 사용자는 어디로 리다이렉트할지
- 그 과정에서 어떤 UI(안내 메시지, 컴포넌트)를 보여줄지
를 함께 고려했습니다.
들어온 뒤에 막는 것이 아니라, 애초에 들어올 수 있는 경로를 제한하는 방식으로 접근했고, 이를 위해 라우팅 가드 패턴을 도입했습니다.
추후에는 Error Boundary를 도입해, 네트워크 오류나 예측하지 못한 런타임 오류에서도 공통 에러 화면과 복구 경로를 제공하는 구조로 확장할 예정입니다.
전역 상태 최소화
이번 프로젝트에서는 전역 상태 관리 도구를 당장 도입할 필요는 없다고 판단했습니다.
인증 상태는 Firebase Auth 리스너와 커스텀 훅으로 관리하고, 대부분의 데이터는 Firestore 쿼리 결과를 화면 단위에서 가져오는 방식으로 처리했습니다.
- 서버 상태와 클라이언트 상태가 만나는 지점(공유 사용자 정보, 강좌 목록, 필터/수강 상태 등)을 어떻게 관리할지
- 라우팅 경계 vs 섹션 단위 로딩 전략을 어떻게 가져갈지
이 두 지점은 다음 프로젝트에서 직접 실험하고, 기준을 세워 볼 예정입니다.
티키타카 맞춰가기 위해
관례적이고 이상적인 플로우에 기대기보다는, 주어진 상황에서 최선의 선택을 빠르게 의사결정해야 합니다.
신뢰 자산 쌓기
이전 팀 프로젝트인 KILLPO(킬포)를 통해 기한을 지키는 습관과 기본적인 신뢰가 팀에 얼마나 크게 작용하는지를 깨달았습니다.
- 정해진 기한 지키기
- 말한 것을 실제 행동으로 보여주기
- 팀에 안정감을 주는 동료가 되기
이번에도 이 세 가지를 의식적으로 실천하려고 했습니다.
이상과 현실 밸런스 맞추기
주어진 시간 안에서 팀이 이해할 수 있는 수준의 안정적인 구조를 목표로 했습니다.
- 팀 전체 일정 안에서 안정적으로 마무리하는 것
- 완벽한 구조보다는 마감 내에 안정적인 구조
- 실험적인 시도보다는 팀이 이해할 수 있는 선택
위의 세 가지를 우선순위로 두고 의사결정을 했습니다.
문제 해결력을 기르도록 도와주기
개발 리드를 하면서 어떻게 같이 성장하게 도와줄 수 있는지가 더 중요하다고 느꼈습니다.
그래서 동료들과 문제를 어떻게 쪼갤지, 어디서부터 찾아볼지, 어떤 기준으로 선택할지를 함께 고민하려고 했습니다.
단순히 정답을 알려주는 것보다, 문제를 풀어 가는 방식을 나누는 데 더 집중했습니다.
하나씩 찾아가는 기준들
서로에게 어떤 병목이 있었는지, 앞으로 어떻게 개선하면 좋을지 이야기하는 시간을 가졌고, 그 과정이 팀 A의 터닝 포인트가 되었습니다.
이슈를 정의하는 것도 이슈였다
무엇이 진짜 문제인지, 어디까지가 개인 스타일이고 어디부터가 팀 룰의 영역인지 헷갈리는 순간이 있었습니다. 각자가 이해하는 이슈 범위도 달라, 같은 내용을 반복하거나 결론이 흐릿해지는 경우도 있었습니다.
그래서 이슈를 먼저 언어화하기로 했습니다.
- 회의 신청하기
- 노션에서 새 회의록 작성하기
- 회의록 안건 섹션에 이슈별로 “무엇을, 어떻게 하고 싶은지”를 한 문장으로 정리하기
- 이 내용을 바탕으로 회의 진행하기
문서화 및 회의 시간은 절반 이상 줄었고, 그 과정에서 느끼는 부담도 함께 줄었습니다.
도메인 단위와 작업 단위는 항상 같지 않다
초기에는 작업을 도메인 단위로 나눴습니다.
작업 분배를 수평적으로 설계했지만, 실제 흐름은 수직적인 구간이 많았고 일부 구간에서는 개발보다 테스트를 기다리는 시간이 더 길어졌습니다.
도메인 내부의 ‘우선 개발 기능’과 도메인 간 ‘선행 조건’을 미리 정의하지 않았던 것이 병목의 원인 중 하나였습니다.
그래서 앞으로는 작업 단위를 분리할 때는 어떤 기능이 선행되어야 하는지, 어떤 기능은 병렬로 가능한지를 먼저 분석한 뒤 작업을 시작하려고 합니다.
규칙은 필요성을 체감해야 작동한다
저희는 초기에 코드 컨벤션, Notion 문서화 방식, 회의록, PR 작성 기준, 데일리 스크럼 규칙 등 협업 기준을 먼저 만들어 두고 출발했습니다.
하지만 진행될수록 규칙의 필요성을 느끼는 정도가 서로 달라지면서,
어떤 규칙은 자연스럽게 쓰이고 어떤 규칙은 피로감으로 느껴지는 경우도 있었습니다.
그래서 지금은 형식보다 먼저 “왜 이 규칙이 필요한가”를 팀 전체가 함께 이해하고, 실제로 도움이 된다고 느껴지는 규칙만 남겨가는 것을 목표로 하고 있습니다.
그래서 다음 액션은?
시간을 항상 아끼기 위해 노력해야 한다.
결국 소통을 잘하는 개발자가 되어야 한다
코드를 잘 짜는 것도 중요하지만, 결국 소통을 잘하는 개발자가 좋은 팔로워이자 리더가 된다고 생각합니다.
- 내가 하고 있는 일을 미리 명확하게 공유하고 (얼리 쉐어)
- 막힌 지점에서 도움을 요청하고 (얼리 피드백)
- 다른 사람의 속도와 상황을 고려해 말하는 것 (수평 커뮤니케이션)
이 세 가지를 항상 염두에 두려고 합니다.
좋은 문서화 기준 찾기
문서화를 하다가 “피로감이 큰 문서화가 과연 좋은 문서화일까?”라는 질문이 들었습니다.
- 무엇을 기록해야 ‘미래의 나와 팀’을 도와주는지
- 어디까지 문서화하고, 어디부터는 구두 공유로 충분한지
남은 세 번의 프로젝트에서 팀만의 “좋은 문서화 기준”을 찾아가고자 합니다.
AI를 시간을 아껴주는 구간에 배치하기
저희는 디자이너 없이 디자인 시스템과 보일러플레이트 코드를 만들면서 AI를 적극 활용했습니다.
AI가 제안한 방향이 맥락과 어긋날 때도 있었고, 프롬프트 작성·수정에도 시간이 든다는 점을 느꼈습니다.
앞으로는 어디까지를 AI에 맡기고 어디부터는 사람이 직접 고민할지에 대한 기준을 더 세밀하게 나누어 균형 있게 활용하는 연습을 해 보려고 합니다.
데모도 사용자 경험의 일부로 보기
데모 데이 때 라이브 시연 위주로 진행하다 보니, 폼 입력 등으로 흐름이 늘어지는 구간이 있었습니다.
다음 프로젝트부터는 짧은 데모 영상과 시연용 데이터를 미리 준비해, 발표 시간에는 핵심 플로우에 집중하는 방식으로 개선하려 합니다.
마치며
첫 번째 프로젝트를 통해 “협업”이라는 단어를 이전보다 훨씬 구체적으로 떠올리게 되었습니다.
이 회고가 앞으로 세 번 더 이어질 런피 여정의 기준점이 되었으면 합니다.
읽어주셔서 감사합니다.
잘 읽었습니다. 😊