독스루는 영어 문서 중심의 학습 환경에서 발생하는 정보 접근 격차를 해소하기 위해 기획한 협업 기반 번역·학습 플랫폼입니다.
혼자 번역하고 학습하는 구조에서 오는 고립감과 낮은 지속성을 문제로 인식했고, 번역 과정을 커뮤니티 기반 학습 경험으로 전환하는 것을 목표로 했습니다.
프로젝트 초반, 기능 구현에 집중할 경우 구조가 빠르게 복잡해질 수 있다고 판단했습니다.
특히 번역·댓글·인증·상태 관리가 얽히는 구조에서 공통 기준 없이 개발이 진행되면 유지보수가 어려워질 가능성이 높았습니다.
이에 저는 초기 단계에서부터 확장성과 재사용성을 고려한 구조 설계를 우선했습니다.
Next.js 기반 페이지 단위 구조를 정리하고, axios 인스턴스와 인터셉터를 공통화해 인증 및 에러 처리 로직을 일관되게 관리하도록 설계했습니다.
또한 TanStack Query를 공통 hooks로 분리해 서버 상태 관리 로직의 중복을 제거했고, 데이터 패칭 흐름을 명확히 정의했습니다.
이 경험을 통해 빠른 구현보다 유지보수 가능한 구조 설계가 장기적으로 더 큰 효율을 만든다는 점을 체감했습니다.
요구사항에 명시된 기능만 구현하는 방식으로는 번역 학습 플랫폼의 몰입도를 충분히 높이기 어렵다고 판단했습니다.
번역이라는 행위는 반복적이고 단조로울 수 있기 때문에, 사용자가 자신의 활동을 확인하고 참여를 지속할 수 있는 장치가 필요하다고 보았습니다.
이에 댓글 무한 스크롤과 마이페이지 기능을 직접 기획하고 구현했습니다.
단순 기능 추가가 아니라, 사용자가 자신의 번역 활동을 확인하고 피드백을 주고받으며 학습을 이어갈 수 있는 흐름을 설계하는 데 초점을 두었습니다.
이 과정을 통해 저는 요구사항을 충족하는 개발자가 아니라, 서비스 완성도를 고민하는 개발자로 한 단계 성장했다고 느꼈습니다.
OAuth 연동 과정에서 프론트엔드와 백엔드 간 redirect 흐름이 정상적으로 동작하지 않는 문제가 발생했습니다.
문제를 단순 오류로 보지 않고, 인증 토큰 전달 방식과 쿠키 설정이 인증 흐름 전반에 영향을 준다는 점에 주목했습니다.
백엔드와 협업해 setCookie 옵션을 재정의하고, redirect 흐름을 전체적으로 재설계하여 새로고침 이후에도 인증 상태가 유지되도록 개선했습니다.
이 경험을 통해 인증은 단순 기능이 아니라, 사용자 경험 전체를 좌우하는 설계 문제라는 점을 배우게 되었습니다.
팀 프로젝트에서는 기능 구현 속도만큼 협업 구조가 중요하다고 판단했습니다.
Git Flow 브랜치 전략을 도입하고, Husky Git Hook을 활용해 네이밍 컨벤션과 공통 로직 기준을 강제했습니다.
또한 Playwright 기반 테스트 자동화를 시도하며, 기능 중심 개발에서 테스트 기반 사고로 확장했습니다.
이를 통해 개인의 구현 능력뿐 아니라, 팀 전체의 생산성을 높이는 구조를 설계하는 경험을 할 수 있었습니다.
OAuth 기반 로그인 구현 과정에서, 로그인 이후 프론트엔드와 백엔드 간 redirect가 정상적으로 동작하지 않는 문제가 발생했습니다.
특히 로그인은 성공했지만, 새로고침 시 인증 상태가 유지되지 않는 불안정한 흐름이 반복되었습니다.
초기에는 단순 redirect URL 설정 문제로 보였지만, 원인을 분석한 결과 인증 토큰 전달 방식과 쿠키 옵션 설정이 일관되지 않은 구조적 문제임을 확인했습니다.
즉, 문제는 "OAuth 오류"가 아니라 인증 상태 유지 전략이 명확히 설계되지 않은 것이었습니다.
저는 문제를 "동작하게 만드는 것"이 아니라, 인증 흐름을 전체적으로 재정의하는 방향으로 접근했습니다.
이를 통해 인증을 개별 기능이 아닌 하나의 흐름으로 설계했습니다.
이 경험을 통해 인증은 단순 API 연동 문제가 아니라, 사용자 경험 전체를 지탱하는 구조 설계 문제라는 점을 배웠습니다.
이후 기능 구현 시에도 개별 기능이 아닌 전체 흐름을 먼저 정의하는 기준을 갖게 되었습니다.
링크 미리보기 기능 구현 과정에서 외부 요청이 CORS 정책에 의해 차단되는 문제가 발생했습니다.
클라이언트에서 직접 요청하는 방식이 구조적으로 제한된다는 점을 인식하고, Next.js API Route를 활용해 서버 단에서 요청을 우회 처리하도록 설계했습니다.
이를 통해 브라우저 정책에 의존하지 않는 안정적인 요청 구조를 구성할 수 있었습니다.
→ 문제를 "에러 수정"이 아니라 요청 구조 재설계 문제로 접근한 경험이었습니다.
초기에는 페이지 단위로 상태를 관리했으나, 인증 및 사용자 정보가 여러 컴포넌트에 분산되며 복잡성이 증가했습니다.
Zustand를 도입해 사용자 정보를 전역 상태로 통합 관리하고, 회원 상태에 따른 리다이렉트 로직을 구조화했습니다.
이를 통해 인증과 UI 상태 간 결합도를 낮추고, 흐름을 명확히 분리할 수 있었습니다.
→ 상태 관리는 편의가 아니라 구조 설계의 문제임을 체감했습니다.
이번 프로젝트를 통해 저는 프론트엔드 개발이 단순히 화면을 구현하는 일이 아니라, 구조를 설계하고 흐름을 정의하는 일이라는 점을 체감했습니다.
공통화 전략을 통해 코드 중복을 줄이고 유지보수성을 개선했으며, OAuth 인증 흐름과 상태 관리 구조를 재설계하면서 사용자 경험을 안정적으로 유지할 수 있는 기반을 마련했습니다.
특히 요구사항에 명시되지 않은 기능이라도 서비스 완성도에 필요하다고 판단되면 직접 제안하고 구현하며, 기능 구현을 넘어 서비스 전체 흐름을 고민하는 역할을 수행했습니다.
이 프로젝트를 통해 빠르게 구현하는 것보다 확장 가능하고 일관된 구조를 설계하는 것이 장기적으로 더 큰 효율을 만든다는 기준을 갖게 되었습니다.
또한 프론트엔드 리드로서 기술 선택의 이유를 팀원들에게 설명하고 합의를 이끌어내는 과정 속에서, 개인의 구현 능력뿐 아니라 팀 전체의 생산성을 높이는 구조를 설계하는 경험을 할 수 있었습니다.
이후 프로젝트에서는 "이 기능이 동작하는가?"보다 "이 구조가 유지 가능한가?"를 먼저 질문하며 설계하고 있습니다.
팀원들이 실제로 작성해준 피어 리뷰입니다.
Next.js
페이지 단위 구조화와 SSR 기반 렌더링 전략을 활용해, 초기 설계 단계부터 확장성과 렌더링 책임을 명확히 나누기 위해 선택했습니다.
TypeScript
프론트엔드와 백엔드가 동시에 개발되는 환경에서 타입 불일치로 인한 런타임 오류를 사전에 방지하고, 협업 안정성을 확보하기 위해 도입했습니다.
TanStack Query
서버 상태를 단순히 fetch하는 것이 아니라, 캐싱·재요청·에러 흐름까지 구조적으로 관리하기 위해 사용했습니다.
Zustand
인증 상태와 사용자 정보를 전역적으로 관리하며, UI 흐름과 상태를 분리해 구조적 일관성을 유지하기 위해 선택했습니다.
Axios (fetch-adapter)
Next.js 환경에서 네트워크 요청을 일관되게 관리하면서도, 프레임워크의 렌더링 최적화 특성을 해치지 않도록 구성하기 위해 적용했습니다.
Playwright
기능 구현 이후 수동 검증에 의존하지 않기 위해 테스트 자동화를 시도하며, 사용자 흐름 단위의 안정성을 확보하기 위해 도입했습니다.
Git Flow · Husky
브랜치 전략과 커밋 규칙을 구조화해 협업 과정에서 발생할 수 있는 충돌과 품질 저하를 사전에 방지하기 위해 적용했습니다.
