20250804 Spring Boot + Vue 프로젝트 회고록

Spring Boot + Vue 프로젝트 회고록– 에러 로그, AI 도구, 그리고 나의 성장 에러 로그와 함께 성장한 3일이번 사이드 프로젝트에서는 Spring Boot와 Vue.js를 붙여서 기자단 캠페인 플랫폼을 만들었다.간단한 CRUD만 구현하면 되는 줄 알았지만, 막상 붙여보니 예상치 못한 에러들이 계속 터졌다.처음 겪는 에러도 많았고, 설정 꼬임도 잦았다.이번 회고는 그런 문제들을 어떻게 해결했는지, 그리고 Cursor AI와 Gemini CLI 같은 AI 도구를 사용하면서 어떤 경험을 했는지를 함께 정리한 기록이다.

프로젝트 구성:

프로젝트 구프론트엔드: Vue 3 (Vite + Axios)백엔드: Spring Boot 3.xDB: H2 (개발용)인증: JWT빌드 시스템: Maven → Gradle 전환사용 툴: Cursor AI, Gemini CLI, ChatGPT

개발 중 겪은 주요 이슈들

1. Maven 플러그인 인식 안 됨처음 프로젝트를 Maven으로 시작했는데, 아래 같은 에러가 발생했다.

No plugin found for prefix ‘spring-boot’

No plugin found for prefix ‘spring-boot’결론은 pom.xml에 실수로 잘못된 태그가 들어 있었던 것. Maven은 XML 문법이 틀리면 조용히 빌드가 안 되기 때문에 찾는 데 시간이 걸렸다.파일을 새로 작성하면서 해결했는데, 이때부터 “Gradle로 바꿔야겠다”는 생각이 슬슬 들기 시작했다.

1. 8080 포트 충돌

Port 8080 was already in use

이건 자바 프로세스가 꺼지지 않아서 발생했다. PowerShell에서 다음 명령어로 해결했다.

Get-Process java

Stop-Process -Force

1. 로그인 403 (Forbidden)로그인 API를 호출했는데 계속 403이 떴다.JWT 필터가 모든 요청에 적용되면서, 로그인 요청까지 막아버리고 있었다.Security 설정에서 로그인과 회원가입 관련 URI만 필터에서 제외시켜서 해결.

1. ECONNREFUSED – 프론트와 백 연결 실패 원인: 주소 문제프론트가 백엔드에 요청을 보냈는데,IPv6 주소인 ::1:8080으로 보내고 있었고, 백엔드는 IPv4만 리스닝하고 있어서 연결이 안 됐다.

connect ECONNREFUSED ::1:8080

백엔드 설정에서 address를 0.0.0.0으로 열고,프론트 proxy 주소를 127.0.0.1로 변경해서 해결했다.

1. 로그인 계정 오류처음엔 admin@example.com으로 로그인하려 했는데 안 됐다.확인해보니 실제로 DataInitializer.java에서 만들어진 계정은test@example.com / password123이었다.해당 계정으로 로그인하니 정상 작동했다.

2. 캠페인 조회 시 500 에러캠페인 상세 페이지를 요청했더니 500 에러 발생.원인은 단순했다.ID=1 캠페인이 DB에 없었다.H2 콘솔에 접속해서 테이블 확인하고 수동으로 더미 데이터를 추가해서 해결했다.

3. 이미지 로딩 실패

GET https://via.placeholder.com/300x200 net::ERR_NAME_NOT_RESOLVED

이미지 주소로 사용하던 placeholder.com이 막혀 있었고,대체로 picsum.photos를 사용하고, 로딩 실패 시 fallback 이미지로 처리했다.

Cursor AI와 Gemini CLI 사용 후기

Cursor AICursor는 IntelliJ보다 훨씬 가볍고, AI 코드 보조 기능이 강력하다.특히 에러 메시지를 복붙해서 코드 안에서 바로 답변 받는 기능이 굉장히 직관적이었다.대부분의 문법 오류나 설정 문제는 Cursor에서 바로 해결 실마리를 얻었다.장점: 빠른 피드백, 코드 컨텍스트 유지됨, Copilot보다 명확한 답변단점: 복잡한 설정 이슈(Spring Security나 JWT 인증 흐름)는 정확도 떨어짐

정리하자면, 코드 레벨 디버깅용으로는 최고.하지만 복잡한 백엔드 로직 구조 설계에는 추가 설명이 필요했다.

Gemini CLI는 로컬 터미널 환경에서 빠르게 질문하고 결과를 볼 수 있다는 점이 장점이었다.간단한 개념 확인, 오류 코드 해석, config 파일 예시 요청 등에 유용했다.장점: CLI에 최적화, 짧은 명령어 기반, 개념 요약 빠름단점: 실시간 코드 맥락 이해력은 떨어짐

정리하자면, “도우미”로는 훌륭하지만, “전담 해결사”는 아님.Copilot이나 Cursor처럼 코드 문맥까지 고려한 처리는 부족했다.

Gradle로 전환한 이유이 프로젝트에서 가장 잘한 결정 중 하나는 Maven에서 Gradle로 갈아탄 것이다.처음엔 익숙해서 Maven을 썼지만,의존성 버전 충돌 디버깅빌드 속도설정 유연성이 세 가지 면에서 Gradle이 훨씬 나았다.특히 build.gradle.kts로 구조를 잡으면서 설명하기 쉬운 빌드 구조를 만들 수 있었다.앞으로는 Gradle 기반으로 프로젝트를 시작할 계획이다.

지금 상태 점검백엔드: Gradle 기반으로 정상 기동프론트–백 연결: IPv4로 통일, 정상 작동JWT 로그인: 정상 작동캠페인 상세 조회: 데이터 없을 경우 예외 처리 필요이미지: fallback 적용했으나 여전히 placeholder 문제 있음

느낀 점 & 회고이번 프로젝트는 에러에 부딪히는 시간이 대부분이었다.근데 그만큼 설정 파일 하나, 필터 한 줄, 포트 번호 하나가 시스템 전체를 막을 수 있다는 걸 제대로 체감했다.또, 처음에는 에러가 생기면 일단 검색부터 했지만,이번엔 Cursor AI나 Gemini CLI를 써서 빠르게 로그를 해석하고 실험적으로 시도할 수 있었다.AI가 모든 걸 해결해주는 건 아니었지만, 반복적인 디버깅 시간을 확실히 줄여준 건 맞다.

“내가 직접 문제를 해결하는 느낌은 살리고, 불필요한 구글링은 덜고”이게 이번 프로젝트에서 AI 도구를 쓰며 가장 만족스러웠던 부분이다.

다음 작업 목록캠페인 ID 조회 시 404로 graceful 처리기본 이미지 서버 자체적으로 구성JWT 인증 흐름 좀 더 명확히 정리Gradle 기반 멀티 모듈 구조 연습

이런 경험 하나하나가 쌓이면서,이제는 프로젝트보다 설정이 무섭지 않게 됐다.다음 프로젝트에선 더 빠르게 구조 잡고, 더 적은 에러로 개발할 수 있을 것 같다.