Spring Boot MVP 배포 전 체크리스트 15가지 — 출시 전에 이것만 확인하세요

Spring Boot 프로젝트가 로컬에서 실행된다고 해서 바로 배포할 수 있는 건 아니었습니다.

 

Security Lens를 만들고 실제로 배포하면서 PORT, 환경변수, 파일 업로드, 보안, README처럼 기능 구현과는 조금 다른 문제를 계속 만났습니다.

 

최근에는 Claude에게 웹앱 제작을 맡겨보면서 비슷한 생각을 또 했습니다.

앱을 만드는 속도는 빨라졌는데,

 

“이걸 실제로 세상에 내놓아도 되는가?”를 확인하는 일은 여전히 남아 있었습니다.

그래서 다음 MVP를 배포할 때 제가 다시 확인하려고 15개로 정리했습니다.

완벽한 운영 서비스 체크리스트라기보다,

 

“일단 MVP를 밖으로 내보내기 전에 이것만은 보자.”

에 가깝습니다.

---

빠르게 보는 15가지

☐ Java 버전이 맞는가
☐ PORT가 배포 환경에 맞는가
☐ localhost가 남아 있지 않은가
☐ API Key가 코드에 들어가 있지 않은가
☐ DB 정보가 환경변수로 분리되어 있는가
☐ Git에 민감한 파일이 올라가 있지 않은가
☐ 실패하는 API 요청도 확인했는가
☐ 파일 업로드 제한이 있는가
☐ 파일명과 저장 경로를 안전하게 처리하는가
☐ 로그에 민감정보가 남지 않는가
☐ 사용자 입력을 그대로 신뢰하지 않는가
☐ 응답이나 파일에 불필요한 정보가 포함되지 않는가
☐ 실제 배포 URL에서 다시 테스트했는가
☐ README만 봐도 프로젝트를 이해할 수 있는가
☐ 지금 출시를 막는 문제가 정말 남아 있는가

 

---

실행 환경

1. Java 버전이 맞는가

로컬에서는 잘 실행되는데 다른 PC나 배포 환경에서 갑자기 실행되지 않는다면 Java 버전부터 확인해볼 만합니다.

최소한 다음은 확인합니다.

• Project SDK
• Gradle JVM
• build.gradle 또는 pom.xml
• JAVA_HOME
• 배포 환경의 Java 버전

저도 새 개발환경을 구성하면서 IntelliJ의 Java 버전이 서로 다르게 설정된 문제를 다시 확인했습니다.

→ IntelliJ Java 버전 안 맞을 때 확인할 곳 | Project SDK·Gradle JVM·JAVA_HOME

---

2. PORT를 코드에 고정하지 않았는가

로컬에서는 보통 Spring Boot를 8080 포트에서 실행합니다.

하지만 Railway 같은 배포 환경에서는 플랫폼에서 전달하는 PORT를 사용해야 할 수 있습니다.

Security Lens를 Railway에 배포하면서 저도 이 부분을 수정했습니다.

server.port=${PORT:8080}

 

이렇게 하면 배포 환경에서는 지정된 PORT를 사용하고, 로컬에서는 기본값 8080을 사용할 수 있습니다.

---

3. localhost가 남아 있지 않은가

개발할 때는 자연스럽게 이런 주소를 사용합니다.

http://localhost:8080

 

문제는 배포하고 나서도 설정 어딘가에 이 값이 남아 있을 때입니다.

배포 전에는 이런 곳을 봅니다.

• API 호출 주소
• DB 주소
• Redirect URL
• CORS 설정
• 파일 경로

프로젝트 전체에서 localhost를 한 번 검색해보는 것도 꽤 유용합니다.

---

환경변수와 Secret

4. API Key를 코드에 직접 넣지 않았는가

테스트할 때는 편해서 이런 식으로 넣고 싶을 때가 있습니다.

String apiKey = "sk-...";

 

하지만 GitHub에 올라가는 순간 이야기가 달라집니다.

API Key나 Token은 환경변수로 분리합니다.

openai.api.key=${OPENAI_API_KEY}

 

실제 값은 Railway 같은 배포 플랫폼에서 따로 관리합니다.

---

5. DB 접속 정보도 분리했는가

API Key뿐 아니라 DB 정보도 같습니다.

spring.datasource.url=${DB_URL}
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

 

다음 값들이 코드나 공개 저장소에 들어가 있지 않은지 확인합니다.

• DB URL
• Username
• Password
• 외부 서비스 Token

---

6. Git에 올라가면 안 되는 파일이 올라가 있지 않은가

.gitignore에 추가했다고 끝나는 건 아닙니다.

이미 Git에서 추적 중인 파일일 수도 있기 때문입니다.

 

공개하기 전에 GitHub 저장소를 브라우저에서 직접 한 번 보는 편이 좋았습니다.

특히 확인하는 파일은:

.env
application-secret.properties
API Key가 들어간 테스트 파일
로그
인증 관련 파일

 

Git 자체가 아직 익숙하지 않다면 최근 정리한 글도 있습니다.

→ Windows에서 Git 설치부터 GitHub push까지 | config·init·remote·-M·-u 정리

---

API와 파일 처리

7. 성공하는 요청만 테스트하지 않았는가

기능을 만들고 나면 성공 케이스부터 보게 됩니다.

하지만 실제 사용자는 항상 정상적인 값만 넣지는 않습니다.

최소한 이런 경우를 한 번 확인합니다.

• 필수값 누락
• 잘못된 형식
• 존재하지 않는 데이터
• 외부 API 실패
• 예상보다 큰 요청

실패했을 때 내부 오류가 그대로 노출되는지도 같이 봅니다.

---

8. 파일 업로드 제한이 있는가

Security Lens는 이미지와 문서를 업로드받는 기능이 있었기 때문에 이 부분을 꽤 신경 썼습니다.

최소한 확인한 것은:

• 허용 확장자
• 파일 크기
• Content-Type
• 비정상 파일
• 실패 처리

확장자가 .jpg라고 해서 실제 파일도 정상적인 이미지라고 바로 믿지는 않는 편이 좋습니다.

---

9. 파일명과 저장 경로를 그대로 믿고 있지 않은가

사용자가 전달한 파일명을 그대로 저장 경로에 사용하는 것도 확인해야 합니다.

저장할 때는 직접 안전한 파일명을 생성하거나 변환하고, 사용자가 저장 경로를 결정할 수 없도록 하는 편이 좋습니다.

파일 업로드 기능이 없다면 이 항목은 넘어가도 됩니다.

---

보안과 개인정보

10. 로그에 민감정보가 찍히지 않는가

개발 중에는 값을 확인하기 위해 로그를 많이 남깁니다.

배포하기 전에는 다시 확인합니다.

• Password
• API Key
• Token
• 전화번호
• 이메일
• 개인정보
• 전체 Request Body

Security Lens를 만들면서 오히려 이런 부분을 더 많이 의식하게 됐습니다.

---

11. 사용자 입력을 그대로 신뢰하고 있지 않은가

사용자가 입력한 값을 그대로 HTML에 출력하거나 SQL에 사용하는 부분이 없는지도 확인합니다.

대표적으로:

• XSS
• SQL Injection

Spring이나 라이브러리가 도와주는 부분도 많지만, 실제 입력값이 어디로 들어가는지는 한 번 직접 확인하는 편이 좋습니다.

---

12. 응답이나 파일에 불필요한 정보가 포함되지 않는가

서비스가 사용자에게 보여줄 필요가 없는 값까지 반환하고 있지는 않은지 확인합니다.

예를 들면:

• 내부 ID
• 디버깅 값
• 서버 정보
• 불필요한 개인정보
• 이미지 메타데이터

Security Lens를 만들면서 이미지에는 화면에 보이는 것 외에도 EXIF 같은 정보가 들어갈 수 있다는 걸 다시 확인했습니다.

---

실제 배포

13. localhost가 아니라 실제 배포 URL에서 다시 테스트했는가

로컬에서 잘 된다고 운영 환경에서도 반드시 된다는 보장은 없었습니다.

배포 후 실제 주소에서 최소한 다음은 다시 눌러봅니다.

• 첫 화면
• 주요 API
• DB 저장
• 파일 업로드
• 외부 API
• 에러 처리

가능하면 모바일 화면에서도 한 번 확인합니다.

---

14. README만 보고도 프로젝트를 이해할 수 있는가

프로젝트를 만든 사람인 나는 모든 맥락을 알고 있습니다.

GitHub를 처음 보는 사람은 그렇지 않습니다.

그래서 README에는 최소한 이런 내용을 넣는 편입니다.

• 프로젝트가 무엇인지
• 왜 만들었는지
• 주요 기능
• 기술 스택
• 실행 방법
• 필요한 환경변수
• 배포 주소
• 현재 한계

Security Lens를 만든 뒤 Case Study 형태로 README를 다시 정리했던 것도 같은 이유였습니다.

---

마지막 체크

15. 그래서 지금 출시해도 되는가

MVP를 만들다 보면 계속 고칠 게 보입니다.

이것도 추가해야 하나?

이것도 고치고 내놓는 게 낫지 않을까?

 

저도 Security Lens를 만들면서 어디까지 구현해야 하는지 계속 고민했습니다.

그래서 마지막에는 질문을 조금 단순하게 합니다.

지금 출시 자체를 막는 문제가 있는가?

• 핵심 기능이 동작하지 않는가
• 개인정보나 보안에 큰 문제가 있는가
• 사용자가 사용할 수 없을 정도의 오류가 있는가
• 데이터에 문제가 생길 가능성이 큰가

그게 아니라면 나머지는 출시 후 고칠 수 있는지도 봅니다.

MVP라면 어느 순간에는

 

“더 만들기”보다 “내놓기”를 선택해야 했습니다.

---

Claude에게 웹앱을 만들어보라고 해보니

최근에는 이 질문이 더 재미있어졌습니다.

Claude에게 웹앱 제작을 맡겨보니 생각보다 훨씬 빠르게 결과물이 나왔습니다.

그런데 결과물을 보고 가장 먼저 든 생각은:

이 정도면 개발자가 없어도 되나?

 

였습니다.

막상 직접 수정하고 실행하고 배포할 준비를 해보니 이야기가 조금 달라졌습니다.

AI가 만드는 속도는 빨라졌지만,

• 환경은 맞는지
• 코드가 왜 동작하는지
• Secret은 안전한지
• 실제 배포 환경에서도 되는지
• 어디까지 믿어도 되는지

를 판단하는 일은 그대로 남아 있었습니다.

제가 Claude에게 실제로 앱을 만들어보라고 했던 과정은 여기 정리했습니다.

→ Claude로 웹앱 만들기: 직접 시켜보니 어디까지 가능했나 | RE:개발자 #16

---

그리고 요즘 조금 달라진 생각

개발을 처음 시작한 이유도 지금과 꽤 달랐습니다.

처음부터 개발 자체에 거창한 의미가 있었던 건 아니었습니다.

 

그런데 계속 만들고, 실패하고, 다시 공부하다 보니 왜 아직 이 일을 하고 있는지를 다시 생각하게 됐습니다.

→ 생계 때문에 개발을 시작했다. 그런데 왜 아직 개발하고 있을까 | RE:개발자 #15

 

기술 체크리스트와는 조금 다른 글이지만, 지금 제가 왜 계속 직접 만들어보려고 하는지에 대한 이야기입니다.

---

Spring Boot MVP 출시 전 점검도 한번 실험해보려고 합니다

이 체크리스트를 정리하다 보니 궁금한 게 하나 생겼습니다.

다른 사람이 만든 Spring Boot MVP를 보면
출시 전에 어떤 부분이 가장 많이 빠져 있을까?

 

그래서 나중에 이 체크리스트를 기준으로 작은 Spring Boot MVP 출시 전 점검 Beta를 실험해볼 생각입니다.

배포 설정, 환경변수, 기본 보안, API, 파일 처리, README 등을 보고

 

지금 무엇부터 고치면 좋을지 우선순위를 정리하는 정도부터 시작하려고 합니다.

 

아직 상품부터 만들 생각은 없습니다.

실제로 이런 점검을 원하는 사람이 있는지부터 확인해보려고 합니다.

수요가 확인되면 따로 공개하겠습니다.

지금은 저도 다음 MVP를 배포하기 전에 이 15개부터 다시 확인할 생각입니다.

 

혹시 직접 만든 Spring Boot MVP를 배포하기 전에 이런 점검을 받아보고 싶은 분이 있다면 댓글로 알려주세요. 실제로 필요로 하는 분들이 있는지부터 확인해보고 싶습니다.