런닉스(Lernix)를 회고하며 4

최신 기술보다는 상황에 맞는 효율과 리스크의 균형을 잡는 판단이 중요하다는 것을 배웠습니다.

이 글은 런닉스 마지막 프로젝트를 마치며 남기는 회고입니다.

이번 과정은 기술적으로도 협업적으로도 계속 선택을 요구했습니다.
저는 ‘프로덕트를 끝까지 완성시키는 것’에 책임감을 두고, 매 순간 팀/일정/단계에 맞는 가장 안전하고 빠른 선택을 기준으로 의사결정했습니다.

---

챌린지 포인트

관리자 개념 도입 및 백오피스 구축

수강생 → 강사로 이어지는 기존 흐름을 유지하면서도, 서비스 정책에 맞게 “신청/승인” 과정으로 구체화하려면 운영자가 사용할 관리자 기능(백오피스)이 필요하다고 판단했습니다.

백오피스는 단순한 화면이 아니라 접근 플로우/가드/권한까지 포함한 운영 정책이었고, 아래 3가지를 중심으로 설계했습니다.

• /admin/* 영역은 로그인 + 권한(역할) 기반으로 접근 제한
• 딥링크/새로고침에서도 UX가 깨지지 않도록 라우팅 구조 정리
• 승인 요청 화면은 단순 탭 UI가 아니라 URL 상태 동기화 + 데이터 신뢰성 관점에서 설계

또한 추후 확장성을 고려해, 화면 단위가 아닌 “흐름/정책 단위”로 구조를 잡았습니다.
초대 기반 권한 부여는 MVP 범위에서 제외하고, 접근/라우팅/상태 동기화부터 고정했습니다.

QA 문서를 통한 개선 사이클 확보

서비스 안정화를 목표로 QA 문서를 체계적으로 활용했습니다. QA 문서는 아래 기준으로 분리해 관리했습니다.

• 기능
• 우선순위(P0~P4)
• 작업 항목
• 담당(역할)
• 출처(내부 QA/사용자 제보)
• 환경
• 검수 상태(접수/진행중/해결완료)

구조를 이렇게 잡아두니 현황 파악과 우선순위 정리가 쉬워졌고, QA 자체의 피로도도 줄었습니다.
결과적으로 QA는 단순한 “검수”가 아니라 ‘실패를 예측 가능하게 만드는 과정’이라는 걸 체감했습니다.

배포 검증과 릴리즈 노트 작성

릴리즈 노트는 단순히 “뭘 했는지 적는 문서”가 아니라,
이번 버전에 무엇이 포함되는지 / 무엇이 제외되는지 / 현재 상태가 어떤지를 팀이 같은 기준으로 바라보게 만드는 도구였습니다.

릴리즈 노트를 통해 정보를 동기화하면서 배포 버전의 범위가 고정되었고, 디버깅이 추측에서 확인으로 넘어가는 속도가 빨라졌습니다.

배포 환경에서의 검증도 사실상 필수였습니다.

• 배포 환경에서 API 호출 실패(CORS)
• HTTPS 페이지에서 HTTP 리소스 호출로 인한 차단(Mixed Content)
• 이미지 로딩 정책(예: Next/Image 도메인 제한) 같은 프레임워크/보안 정책 이슈

배포 과정에서 터진 이슈들을 해결하며, 네트워크 전제(보안/정책/환경 차이)에 대한 이해가 프론트에도 필수라는 걸 다시 확인했습니다.

다음에는 이 이슈들을 후반에 몰아 맞지 않도록, 프리뷰/스테이징 환경에서 먼저 검증하고 빠르게 피드백 루프를 도는 방식을 기본 루프로 두려 합니다.

핵심 플로우 안정화

프로덕트의 “완주”는 결국 핵심 플로우가 끝까지 끊기지 않는 것이라고 생각했습니다. 그래서 아래 흐름을 중심으로 안정화했습니다.

• 강좌 등록 플로우 안정화: 입력/검증/업로드/실패 케이스 정리
• 시청 페이지 리빌드: 권한/접근/재생 흐름 재정리
• 장바구니 및 상태 흐름 정리: 사용자 액션 → 상태 반영 → 재조회/동기화 기준 정리
• 가드/권한 정책 설계: 역할 기반 접근 제어의 최소 가드레일 정의

---

비동기 협업을 겪어보며

협업의 질은 “소통을 많이 했는가”가 아니라, 정렬을 확인하는 신호를 팀이 얼마나 자주/명확히 주고받는가로 결정된다는 걸 배웠습니다.

정렬 신호를 보강하는 최소한의 싱크는 필요하다

이번 과정에서는 문서(명세/QA), PR 코멘트, 슬랙 공유를 중심으로 진행하면서 정보가 남고 속도가 나는 협업을 경험했습니다.

• QA 문서와 API 명세가 남아 있어 후반에 스펙이 흔들려도 합의 지점을 복구할 수 있었고
• 배포 후 실시간 배포/변경사항 공유 덕분에 배포 환경 이슈의 원인 범위를 빠르게 좁힐 수 있었고
• 결과적으로 “추측으로 디버깅하는 시간”이 줄고, “확인하고 해결하는 속도”가 빨라졌습니다.

다만 비동기 협업의 특성상 진행 중에 “지금 같은 그림을 보고 있다”는 정렬 신호(OK 사인 / 우선순위 확인 / 리스크 공유)가 눈에 덜 보일 때가 있었습니다.

그래서 비동기의 장점은 살리되, 짧은 OK / 리스크 공유 / 결정 로그 같은 정렬 신호를 최소한으로 보강해야 한다는 걸 배웠습니다.

같은 목표라도 ‘완주 정의’를 한 번 더 확인해야 한다

프로젝트 기간이 짧다 보니, 중반까지는 종종 완료 기준 부재 / QA 누락 / 배포 검증 부족이 흔들림의 시작점이 되곤 했습니다.

따라서 이번에는 “새 기능을 늘리는 것”보다 핵심 플로우를 끝까지 완성(안정화·QA·릴리즈)시키는 걸 우선순위로 두었습니다.

다음부터는 아래 기준을 초반에 합의하는 것에서 끝내지 않고, 진행 중에도 계속 확인 가능한 형태로 문서화해두려 합니다.

• 이번 릴리즈의 Scope IN/OUT
• Done Definition(완료 기준)
• 우선순위(P0 기준)
• 변경 발생 시 업데이트 규칙(누가/어디에/어떻게)

협업은 개인의 역량이 아니라 시스템으로 안정화된다

현업에서는 조직 문화에 따라 비동기가 많을 수도, 대면 싱크가 많을 수도 있습니다. 중요한 건 두 상황 모두에서 일할 수 있는 방식과 규칙을 갖추는 것이라고 느꼈습니다.

협업은 누군가가 “더 노력해서” 좋아지는 게 아니라, 팀의 시스템(기록/공유/정렬 방식)과 리딩 문화가 만들어주는 안정감으로 굴러간다는 점을 배웠습니다.

---

결국 가져가야 할 가치

프로덕트와 피쳐의 개발 단계에 맞는 적절한 수준의 엔지니어링을 지향하고, 오버엔지니어링을 지양하자.

프론트엔드 리드로서

좋은 리딩이란 결국 “내가 다 챙기는 것”이 아니라, 내가 없어도 팀이 돌아가게 만드는 것에 가깝다고 생각합니다.

완벽하게 개발하려는 욕심보다는, 프로덕트의 성공을 위해 지금 필요한 완주와 리스크 관리를 더 중요하게 봤습니다.
또한 동료들이 이 과정에서 함께 경험을 가져갈 수 있도록, 가능한 한 기준과 맥락을 공유하려고 했습니다.

그리고 이런 리딩 방식은 개인의 역량에만 기대면 흔들리기 쉽기 때문에, 공식화된 규칙(Release Criteria / Decision Log / QA 운영 방식)으로 팀에 남겨야 한다는 결론을 얻었습니다.

개발자에서 엔지니어로서

런닉스를 통해 “기술 스택”보다 “오너십”이 더 중요한 포트폴리오가 된다고 확신하게 됐습니다.
어떤 기술을 썼는지보다, 프로덕트를 완성시키기 위해 어떤 판단을 했는지가 더 오래 남았습니다.

특히 이번 프로젝트에서 저는 아래 지점들을 중심으로 고민했습니다.

• 상태/데이터 흐름(서버·클라 경계 포함)
• 변경에 강한 구조(마이그레이션 대비)
• 운영 관점 디버깅(로깅/재현/관찰 가능성)
• 권한/가드 기반 UX 설계
• QA/Mocking으로 안정화 루프 구축

개인과 팀의 생산성을 높이기 위해

돌고돌아 입아프지만, AI를 잘 활용해야 합니다.

프로덕트의 품질과 새로운 피쳐를 동시에 가져가야 하는 상황에서, 반복 작업은 자동화하고 검증/체크 포인트를 명확히 해서 확보한 시간을 아래 같은 지점에서의 사용자 경험에 더 투자해야 한다고 느꼈습니다.

• 최적화
• 통신 설계
• 상태 관리
• 엣지 케이스 대응

---

마치며

런닉스를 통해 기술적으로도, 협업적으로도 경험이 남는 프로젝트를 할 수 있었습니다.
매 단계 다른 상황에서 판단하고 대응했던 경험이 큰 자산으로 남았습니다.
이 경험을 토대로 앞으로도 사용자에게 닿는 결과를 끝까지 책임지는 엔지니어링을 이어가고 싶습니다.

읽어주셔서 감사합니다.