외주 프로젝트를 마무리하며: 운영 가능한 사이트를 만든다는 것

이번 외주 프로젝트는 나에게 단순히 웹사이트 하나를 만든 경험으로 끝나지 않았다.

처음에는 “홈페이지를 하나 만들어보는 프로젝트” 정도로 생각했다.
하지만 진행하면서 기획, 요구사항 정리, 프론트엔드 개발, 백엔드 개발, DB 연결, 배포, 도메인 설정, SEO, QA까지 모두 경험하게 되었다.

특히 이번 프로젝트는 AI의 도움을 받으며 진행한 부분도 많았다. 그래서 더더욱 결과물만 보고 넘어가고 싶지 않았다.

AI가 만들어준 코드를 그대로 사용하는 것이 아니라, 왜 이런 구조가 되었는지, 어떤 문제가 있었는지, 다음에는 어떻게 더 잘할 수 있을지 정리하는 과정이 필요했다.

이번 글은 프로젝트를 마무리하며 전체 과정을 돌아보는 회고다.

최종 구현 기능 정리

이번 프로젝트에서 최종적으로 구현한 기능은 다음과 같다.

메인 페이지
서비스 안내 페이지
견적문의 페이지
후기 페이지
자주 묻는 질문 페이지
관리자 페이지

처음에는 단순한 회사 소개형 홈페이지에 가까웠지만, 실제 운영을 고려하면서 기능이 점점 구체화되었다.

가장 핵심이 되는 기능은 견적 계산기였다.

사용자가 음식 서빙 도우미, 수의, 관, 서비스, 장의 차량 등의 옵션을 선택하면 기본 금액에 옵션 금액이 더해지고, 예상 견적이 실시간으로 계산되도록 만들었다.

견적 옵션은 Google Sheet에서 관리하도록 구성했다.
운영자가 가격이나 옵션명을 수정하고 싶을 때 개발자에게 요청하지 않고 직접 수정할 수 있도록 하기 위해서였다.

후기 기능도 구현했다.

회원가입 없이 이름, 비밀번호, 후기 내용을 입력하면 후기를 등록할 수 있게 했다.
사용자는 작성 시 입력한 비밀번호로 본인 후기를 삭제할 수 있고, 관리자는 관리자 페이지에서 전체 후기를 관리할 수 있도록 했다.

관리자 페이지에서는 후기 관리뿐 아니라 간단한 통계도 볼 수 있게 했다.

방문 수
견적 사용 수
후기 등록 수
누적 데이터
연도별 데이터
월별 데이터

배포는 프론트와 백엔드를 나누어 진행했다.

Frontend: Next.js / Vercel
Backend: Spring Boot / Render
Database: PostgreSQL / Supabase
견적 옵션 관리: Google Sheet
Domain/DNS: Gabia / Cloudflare

이렇게 정리해보면 처음 생각했던 것보다 훨씬 많은 요소가 들어간 프로젝트였다.

잘했다고 느낀 점

가장 잘했다고 느끼는 점은 일단 도전해봤다는 것이다.

처음부터 모든 걸 알고 시작한 프로젝트는 아니었다. 오히려 모르는 것이 훨씬 많았다.
배포도 익숙하지 않았고, 도메인 연결이나 CORS, 환경변수, Supabase, Render 설정도 직접 부딪히며 배워야 했다.

하지만 해보지 않았다는 이유로 피하지 않고, 하나씩 확인하면서 끝까지 가져간 점은 좋았다고 생각한다.

또 하나 잘했다고 느낀 점은 과정을 기록하려고 한 것이다.

개발을 하다 보면 당장 문제를 해결하는 데만 집중하게 된다.
그런데 시간이 지나면 왜 그런 선택을 했는지, 어떤 문제가 있었는지 금방 잊어버린다.

이번에는 외주 과정을 블로그 시리즈로 정리하면서 다시 복기할 수 있었다.

왜 이 기능이 필요했는지
왜 이 기술을 선택했는지
어디서 문제가 생겼는지
어떻게 해결했는지
다음에는 어떻게 개선할 수 있을지

이런 것들을 글로 정리하면서 나도 다시 이해하게 되었다.

특히 AI의 도움을 받은 프로젝트였기 때문에 더더욱 정리가 필요했다.
AI가 코드를 만들어줬다고 해서 내가 이해하지 못하면 내 경험으로 남기 어렵다.
그래서 기능별로 구조를 다시 보고, 배포 과정도 다시 정리했다.

이 과정 자체가 좋은 복습이 되었다.

어려웠던 점

가장 어려웠던 부분은 배포였다.

로컬에서 기능이 잘 동작한다고 해서 운영 환경에서도 그대로 되는 것은 아니었다.
Vercel, Render, Supabase, Cloudflare, Gabia가 각각 어떤 역할을 하는지 이해해야 했다.

프론트엔드는 Vercel에 배포하고, 백엔드는 Render에 배포했다.
DB는 Supabase를 사용했고, 도메인은 Gabia에서 구매한 뒤 Cloudflare로 DNS를 관리했다.

처음에는 이 구조가 복잡하게 느껴졌다.

프론트 주소는 어디에 연결되는지
백엔드 API 주소는 어디에 넣어야 하는지
DB 연결 정보는 어디에 저장해야 하는지
CORS는 왜 막히는지
도메인은 왜 바로 연결되지 않는지
HTTPS는 어디서 적용되는지

이런 부분들을 하나씩 확인해야 했다.

AI의 도움을 받아 설정을 진행했지만, 결국 운영하려면 내가 전체 흐름을 이해해야 했다.
문제가 생겼을 때 어디를 확인해야 하는지 모르면 유지보수를 할 수 없기 때문이다.

또 하나 어려웠던 점은 기획이었다.

처음부터 상세한 기획서가 있었던 것은 아니었다.
클라이언트도 개발자가 아니기 때문에 “어떤 기능이 필요하다”를 명확한 개발 요구사항으로 말하기 어려웠다.

그래서 대화를 통해 계속 확인해야 했다.

견적문의는 어떤 방식이어야 하는지
후기는 회원가입 없이 작성해도 되는지
관리자는 어떤 기능을 봐야 하는지
가격은 누가 수정할 것인지
배포 후 유지보수는 어떻게 할 것인지

이 과정을 겪으면서 개발 전에 요구사항을 정리하는 것이 얼마나 중요한지 알게 되었다.

아쉬운 점

아쉬운 점도 분명히 있다.

가장 크게 느낀 것은 내가 더 많은 지식과 경험을 가지고 있었다면 구조를 더 단단하게 잡을 수 있지 않았을까 하는 점이다.

이번 프로젝트는 AI의 도움을 많이 받았다.
물론 AI를 활용하는 것도 하나의 능력이라고 생각한다.
하지만 내가 더 많은 배경지식을 가지고 있었다면, 더 빠르게 판단하고 더 명확하게 설계할 수 있었을 것 같다.

예를 들어 백엔드 구조, 인증 방식, 배포 전략, 로그 관리, DB 백업 같은 부분은 더 깊게 공부할 필요를 느꼈다.

이번 프로젝트에서는 규모에 맞게 단순한 구조를 선택했지만, 다음에는 조금 더 백엔드다운 요소를 넣어보고 싶다.

관리자 인증 개선
로그인 토큰 방식 적용
DB 백업 정책 정리
운영 로그 관리
더 체계적인 예외 처리
테스트 코드 작성

이런 부분까지 경험하면 프로젝트의 완성도도 더 올라갈 것 같다.

클라이언트에게 넘기기 전 QA 체크

실제 운영 사이트로 넘기기 전에는 QA에 신경을 많이 썼다.

AI로 1차 점검을 하고, 내가 직접 2차로 확인하는 방식으로 교차 검증을 했다.

단순히 “화면이 보인다”가 아니라, 실제 사용자가 사용할 흐름대로 확인했다.

홈 화면이 정상적으로 보이는지
모바일에서 레이아웃이 깨지지 않는지
견적 옵션이 정상 로딩되는지
옵션 선택 시 총액이 정확히 계산되는지
후기 등록이 되는지
후기 삭제가 되는지
비밀번호가 틀렸을 때 안내가 나오는지
관리자 로그인이 되는지
관리자에서 후기를 삭제할 수 있는지
통계가 표시되는지
도메인 접속이 정상인지
HTTPS가 적용되었는지
네이버 서치어드바이저 진단이 통과되는지

특히 반응형 UI는 여러 번 수정했다.

PC에서는 괜찮아 보여도 모바일에서 이미지가 잘리거나, 슬라이드가 화면 밖으로 넘어가거나, 텍스트가 어색하게 줄바꿈되는 문제가 있었다. 이런 부분을 하나씩 확인하면서 수정했다.

QA를 하면서 느낀 점은, 기능을 만드는 것만큼 “깨지지 않게 만드는 것”도 중요하다는 것이다.

포트폴리오로 남길 수 있는 포인트

이번 프로젝트는 포트폴리오로도 의미가 있다고 생각한다.

단순히 클론 코딩이나 개인 연습 프로젝트가 아니라, 실제 클라이언트 요구사항을 바탕으로 만든 운영 사이트였기 때문이다.

포트폴리오에서 어필할 수 있는 포인트는 다음과 같다.

클라이언트 요구사항을 기능 명세로 정리한 경험
Next.js와 Spring Boot를 분리한 풀스택 구조
Google Sheet를 견적 옵션 관리 도구로 활용한 점
PostgreSQL/Supabase를 이용한 후기 및 통계 데이터 저장
관리자 페이지 구현
Vercel, Render, Cloudflare, Gabia를 통한 실제 배포
CORS, 환경변수, HTTPS, 도메인 연결 경험
네이버 서치어드바이저 등록 및 SEO 기본 설정
실제 운영 전 QA 체크리스트 작성

특히 “왜 이렇게 만들었는가”를 설명할 수 있다는 점이 중요하다.

포트폴리오에서 단순히 사용 기술만 나열하면 설득력이 약하다.
하지만 어떤 요구사항이 있었고, 왜 이 기술을 선택했고, 어떤 문제를 만났고, 어떻게 해결했는지를 설명하면 훨씬 좋은 프로젝트가 된다.

이번 블로그 시리즈도 그런 목적으로 정리하고 있다.

다음 외주에서 개선하고 싶은 점

다음 외주 프로젝트를 하게 된다면 가장 먼저 기획과 요구사항 정리를 더 단단하게 하고 싶다.

이번에는 진행하면서 기능이 구체화된 부분이 많았다.
다음에는 초반에 더 많은 질문을 던져서 범위를 명확히 정리하고 싶다.

예를 들어 이런 질문들을 먼저 정리할 수 있을 것 같다.

관리자가 직접 수정해야 하는 데이터는 무엇인가?
회원 기능이 필요한가?
사용자 입력 데이터는 어디에 저장할 것인가?
통계는 어느 정도까지 필요한가?
유지보수 범위는 어디까지인가?
배포 비용은 어느 정도까지 가능한가?

또 백엔드에 대한 경험을 더 쌓고 싶다.

이번 프로젝트에서는 필요한 만큼의 백엔드 기능을 구현했지만, 다음에는 인증, 권한, 로그, 테스트, 배포 자동화 같은 부분을 더 체계적으로 다뤄보고 싶다.

AI를 활용하더라도 내가 구조를 이해하고 판단할 수 있는 범위를 넓히는 것이 목표다.

회고

이번 외주 프로젝트는 완벽한 프로젝트는 아니었지만, 나에게는 꽤 큰 경험이었다.

처음에는 막연하게 시작했지만, 끝까지 진행하면서 실제 운영 가능한 사이트를 만들기 위해 얼마나 많은 요소를 확인해야 하는지 알게 되었다.

기획이 부족하면 개발 중에 계속 흔들리고, 배포 구조를 모르면 운영 단계에서 막히고, QA를 소홀히 하면 사용자가 바로 불편을 느낄 수 있다.

이번 프로젝트를 통해 개발은 단순히 기능을 구현하는 일이 아니라는 걸 배웠다.

사용자가 사용할 수 있게 만들고, 운영자가 관리할 수 있게 만들고, 문제가 생겼을 때 다시 확인할 수 있게 만드는 것까지가 하나의 프로젝트였다.

다음 프로젝트에서는 이번 경험을 바탕으로 더 단단하게 시작하고 싶다.

기획 단계에서 더 많이 질문하고, 기술 선택의 이유를 더 명확히 하고, 배포와 운영까지 고려한 구조를 처음부터 설계해보고 싶다.