진짜_잘하고_싶거든요.zip

서론

1. 옵시디언으로 필기하다가 글이 통째로 사라졌다

옵시디언으로 강의 내용을 정리하던 중, 열심히 적은 내용이 갑자기 사라지고 제목만 남는 일이 생겼다. 노트를 지운 적도 없고 실수로 전체 선택 후 입력한 것도 아니었다. 마치 파일이 처음 만든 상태로 초기화된 것처럼 보였다.

아래는 문제가 생긴 노트의 화면이다. 강의 자료를 번호 목록으로 정리하던 중이었다.

당시에는 몰랐지만, 이 화면 오른쪽 아래 상태 표시줄에 이미 단서가 있었다. **빨간색 동기화 아이콘(빗금 표시)**이다. 이 아이콘이 원인을 찾는 출발점이 됐다.

2. 그래도 옵시디언을 계속 쓰고 싶은 이유

이런 일을 겪고도 다른 앱으로 갈아타지 않은 이유는 옵시디언의 장점이 분명하기 때문이다.

• 노트가 내 컴퓨터의 마크다운 파일로 저장된다. 앱이 사라져도 파일은 남고, 다른 편집기로도 열 수 있다.
• 마크다운, 코드 블록, 이미지를 기본으로 잘 지원한다. 개발 공부 기록에 잘 맞는다.
• 플러그인 생태계가 크다. 폴더 색상, Git 연동처럼 필요한 기능을 대부분 플러그인으로 붙일 수 있다.
• 본체가 무료다. 유료인 건 공식 동기화(Obsidian Sync) 같은 부가 서비스뿐이다.

특히 "파일이 내 것"이라는 점 ㅎㅎ

3. 문제 당시 상황: 볼트가 iCloud 안에 있었다

당시 내 옵시디언 볼트(노트 폴더)는 iCloud Drive 안에 있었다. 맥에서 옵시디언을 설치하고 기본 설정대로 만들면 이 위치가 되기 쉽다.

iCloud에 두면 별다른 설정 없이 기기 간 동기화가 된다는 장점이 있다. 하지만 이 편리함이 바로 글이 사라진 원인이었다.

본론 1. 싱크 오류 원인 찾고 해결하기

빨간 아이콘을 눌러 보니 나온 경고

상태 표시줄의 빨간 동기화 아이콘을 클릭하자 설정의 동기화 화면이 열리면서 아래 경고가 보였다.

이 화면에서 두 가지를 알 수 있었다.

1. 빨간 아이콘 자체는 문제가 아니었다. 코어 플러그인 "동기화(Obsidian Sync)"가 켜져 있는데, 원격 보관함에 연결돼 있지 않아서 뜨는 표시였다. 나는 Obsidian Sync를 쓰고 있지 않았다.
2. 진짜 원인은 iCloud였다. 옵시디언이 볼트가 iCloud로 동기화되고 있다는 것을 감지하고 있었다.

왜 iCloud에서 글이 사라질까

iCloud는 옵시디언 전용 동기화 도구가 아니라 범용 파일 동기화 서비스다. 그래서 다음과 같은 일이 생길 수 있다.

• 파일을 실시간으로 동기화하지 않고, 몇 초에서 몇 분 늦게 반영한다.
• "Mac 저장 공간 최적화"가 켜져 있으면 파일을 클라우드로 올려 두었다가 필요할 때 다시 내려받는다.
• 이 과정에서 클라우드에 남아 있던 예전 버전(제목만 있던 상태)이 지금 쓰고 있는 내용을 덮어쓸 수 있다.
• 아이폰이나 아이패드에서 같은 볼트를 열어 두었다면 충돌 가능성은 더 커진다.

노트를 새로 만들고 제목만 입력한 순간의 버전이 iCloud에 올라가 있다가, 본문을 열심히 쓰는 도중에 그 버전이 다시 내려와 덮어쓴 것으로 보인다.

해결 1. 사라진 내용 복구하기

옵시디언에는 파일 복원이라는 코어 플러그인이 있고, 기본으로 켜져 있다. 노트의 스냅샷을 몇 분 단위로 저장해 둔다.

1. 설정 → 파일 복원 → 스냅샷 보기
2. 사라진 노트("강의 자료")를 선택
3. 내용이 남아 있는 시점을 골라 복원하거나 복사

창을 닫기 전이라면 Cmd+Z로 바로 되돌릴 수도 있다.

해결 2. 쓰지 않는 동기화 플러그인 끄기

Obsidian Sync를 쓰지 않으니, 설정 → 코어 플러그인 → 동기화를 꺼서 빨간 아이콘을 없앴다.

해결 3. 볼트를 iCloud 밖으로 옮기기

근본적인 해결책은 볼트를 iCloud 밖으로 빼는 것이다. Finder에서 볼트 폴더를 찾아보니 이렇게 되어 있었다.

여기서 주의할 점이 두 가지 있었다.

• 폴더 이름 아래의 구름 아이콘은 파일이 아직 맥에 다 내려받아지지 않았다는 뜻이다. 이대로 복사하면 일부 파일이 빠질 수 있다.
• 사이드바를 보면 문서와 데스크탑도 iCloud 아래에 있다. "데스크탑 및 문서 폴더" 동기화가 켜져 있으면, 문서나 데스크탑 폴더로 옮겨도 여전히 iCloud 안이다. 그래서 홈 폴더로 옮겨야 한다.

옮긴 순서는 다음과 같다.

1. 볼트 폴더를 우클릭 → 다운로드된 상태로 유지를 누르고, 구름 아이콘이 사라질 때까지 기다린다.
2. 옵시디언을 Cmd+Q로 완전히 종료한다.
3. 볼트 폴더를 선택하고 Cmd+C로 복사한다. 드래그하면 iCloud에서 이동되어 버릴 수 있으니 복사·붙여넣기를 쓴다.
4. Finder에서 Cmd+Shift+H로 홈 폴더를 연다.
5. Cmd+Shift+N으로 Obsidian 폴더를 만들고, 그 안에 Cmd+V로 붙여넣는다.

그다음 옵시디언을 실행하면 보관함 선택 화면이 나온다.

왼쪽 목록을 보면 기존 볼트들이 모두 Mobile Documents/iCloud~md~obsidian 경로, 즉 iCloud 안에 있다. 여기서 보관함 폴더 열기 → 열기를 누르고 홈의 Obsidian/devqueenyeonju 폴더를 선택했다. "작성자를 신뢰합니까?" 창이 뜨면 신뢰를 눌러야 기존 플러그인이 그대로 켜진다.

새 위치에서 노트와 설정이 모두 그대로인 것을 확인한 뒤, 기존 iCloud 볼트는 목록에서 ··· → 목록에서 제거로 정리했다. 목록에서만 빠지고 파일은 삭제되지 않는다. iCloud 쪽 원본은 며칠 백업으로 남겨 두고 문제가 없으면 지울 예정이다.

본론 2. 왜 GitHub에 저장하기로 했나

볼트를 iCloud 밖으로 옮기면 충돌은 사라지지만, 이제 백업이 없는 상태가 된다. 그래서 대신할 저장 방식을 골라야 했다. 옵시디언 사용자들이 많이 쓰는 방법은 다음과 같다.

나는 Git + GitHub 방식을 골랐다. 이유는 세 가지다.

1. 무료다. GitHub 비공개 저장소는 무료로 만들 수 있다.
2. 변경 이력이 전부 남는다. 이번처럼 글이 사라져도 커밋 기록에서 원하는 시점으로 되돌릴 수 있다. 단순 동기화가 아니라 버전 관리가 된다.
3. 이미 익숙한 도구다. 개발할 때 매일 쓰는 Git을 노트에도 그대로 쓸 수 있다.

지금은 주로 맥에서만 노트를 쓰기 때문에, 모바일에서 불편하다는 단점은 크게 문제 되지 않았다.

본론 3. 볼트를 GitHub에 연결하고 자동 커밋 설정하기

1단계. GitHub에 비공개 저장소 만들기

GitHub에서 New repository를 눌러 저장소를 만든다.

• 이름: obsidian-dev
• 공개 범위: Private (노트에는 개인적인 내용이 들어가므로 반드시 비공개)
• README, .gitignore, license는 체크하지 않는다. 체크하면 첫 푸시 때 충돌이 난다.

2단계. 볼트를 Git 저장소로 만들기

터미널에서 옮긴 볼트 폴더로 이동해 Git을 초기화한다.

cd ~/Obsidian/devqueenyeonju
git init

git 명령어가 없다고 나오면 xcode-select --install로 먼저 설치한다.

3단계. 올리지 않을 파일 지정하기

.obsidian/workspace.json은 열려 있는 탭이나 창 배치처럼 수시로 바뀌는 파일이다. 커밋할 때마다 변경 사항으로 잡히고 기기 간 충돌을 일으키므로 제외한다.

cat > .gitignore << 'EOF'
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/
.DS_Store
EOF

4단계. 첫 커밋 후 GitHub에 올리기

git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/-ㅏㅣㅏ;ㅣㅓㅏ/obsidian-dev-lyj.git
git push -u origin main

5단계. Obsidian Git 플러그인 설치하기

여기까지는 수동으로 올린 것이고, 매번 터미널을 열 수는 없으니 자동화가 필요하다.

1. 옵시디언 설정 → 커뮤니티 플러그인
2. 제한 모드가 켜져 있으면 끄기
3. 탐색에서 "Git" 검색 → 제작자가 Vinzent인 플러그인 설치 → 활성화

Git 플러그인은 .obsidian 폴더 안에 설치되기 때문에, 이 설정도 GitHub에 함께 올라간다. 나중에 다른 PC에서 저장소를 clone하면 플러그인과 설정이 그대로 따라온다.

6단계. 자동 커밋 설정하기

설정 → 커뮤니티 플러그인 → Git → Automatic 화면에서 실제로 설정한 내용이다.

추가로 Git 설정 첫 화면의 Commit-and-sync 섹션에서 Push on commit-and-sync가 켜져 있는지 확인했다. 이게 꺼져 있으면 커밋만 되고 GitHub에는 올라가지 않는다.

7단계. 테스트

노트에 글자를 조금 추가하고 Cmd+P → Git: Commit-and-sync를 실행했다. GitHub 저장소에 vault backup: 날짜 형태의 커밋이 새로 생긴 것을 확인하면 연결 완료다.

대학 졸업 후 첫 회사를 정말 작은 스타트업의 개발자로 합류하게 되었다. 회사 입사는 25년에 입사하였다

1. 안정적인 직장이 아닌 스타트업을 선택하게 된 이유? 

그때 당시에 나는 안정적인 준공기업 류의 회사 합격, 일반적인 회사들도 있었다. 그때 당시에 나는 안정적인 환경보다 더 빡센 환경에서 빠른 성장을 하는게 더 나한테 필요하다고 생각했다. 사실 지방대나와 실력도 그럭저럭, 그냥 너무 평범한 학생이었고 무기가 필요했다. 

근데 당시 입사 24살의 나이에는 안정적인 선택보다 모험을 해보고 싶은 마음이 더 컸다.  

마침 그룹바이 라는 곳에서 제안이 왔고 커피챗 이후 자연스럽게 합류를 하게 되었다. 

그리고 무엇보다 제품이 너무 마음에 쏙 들었다.

내가 평소 관심있는 도메인이었고 고객에 대해 누구보다 쉽게 이해할 수 있을 거라는 자신감도 있었다..

당시 직무는 계약서는 프론트엔드개발자였고, 명함은 시스템 엔지니어였었다.

4명의 아주 작은 스타트업이었고, 정말 빠른 변화, 적응을 해야했었다. 

처음에는 기존 Poc 로 진행했던 제품을 기반으로 제대로 출시할 웹사이트 프론트엔드 개발이었고, 스펙은 firebase, next 였었다

사실 이 스펙들 모두 다 처음써봤다. 나는 node, java, python 같은 대학시절 프로젝트때 써본 스펙이 전부였지만 

크게 어려움없이 바로 썻던거 같다.

프론트엔드 개발자라 화면을 만드는 업무들과 주로 ai 관련된 프롬프트 엔지니어링, 오류가 발생했을때 qa 작업들, 새로운 기능을 만들때 미리 만들어보는 일들을 주로 담당했었다. 

솔직히 모든 일들이 처음이었고, 신입으로서는 너무 어렵고 배우는 시간보다 일단 해보면서 배운 시간이 컸던 거같다. 

처음에는 열심히만 하면 된다고 생각했고 진심으로 잘하고 싶은 생각에 이 악물고 밤새고 퇴근하고도 고민하고 스트레스가 컸던 거 같다. 

2. 신입이 스타트업 개발자로 어려웠던 점 

첫 번째로는 나이와 경력이 무려 20년 이상 나는 팀원들과 같이 하는데 의사사통이 힘들었다. 경험이 없어 시간을 낭비하기 일쑤였다. 

설득해야하는 일, 나의 상황을 설명해야하는 일이나 개발자라는 직무를 떠나 나는 회사가 처음인 사람이었다. 

중간보고를 어떻게 해야하고, 어떤 부분에서 혼자 의사결정 해야하고, 어떤 부분에서는 같이 회의를 해야하는지 개발자라는 일보다 이런 일들이 너무 어려웠었다. 

그리고 스타트업은 이런 신입을 가르칠 여력이 안된다. 아무리 대학시절 사회생활을 잘했고 평소 다양한 알바를 해봤다고 해서 회사에서 잘할거라는 것은 다른 이야기였다. 회사에서는 성과를 내야하는 집단이고 스타트업일 경우 효율이 더욱 중요하다. 

그래서 혼자서 일어나야 하고 깨우쳐야 하는데 나 같은 경우는 같은 20대도 없고, 여자도 유일했고 마음놓고 회사를 다니는게 점차 어려웠던 거 같다. 

그래도 나름 끝까지 포기하지 않고 항상 웃는 얼굴로 어떻게든 도전하겠다, 노력해보겠다 했던 마음을 이해해주셔서 끝까지 힘이 날 수 있었다. 

두번째로는 아직은 기술적 공백이 너무 크다는 것이다. 나름 개발하고 연구하는 행위가 좋았던 나였다. 회사를 다니면서는 사실 공부를 하는 시간은 거의 없었다. 어떻게든 해보면서 공부를 했던 거 같고 그 기술의 공백이 스타트업의 신입 개발자로서 더욱 헤매게 되는 일이었던 거 같다. 혼자서 공부해야하는 것도 잘알고 있다. 회사가 늦게 끝나고, 운동하고, 퇴근하고도 오늘 있었던 코드 오류없었는지 돌아보기도 벅찼던것 같다. 이 부분은 내 자신이 더 노력하면 될텐데 이런 생각도 하는데 정말 여유가 많이 없었다. 아마 돌아가도 똑같이 일처리하는데 정신이 팔렸을거 같다 ㅋㅋㅋ

3. AI 시대의 신입 개발자로서 

사실 이제는 기술은 ai 가 다 해결해준다. 오히려 사람은 정확한 문제정의, 어떤 것을 만들고 싶은지, 그리고 일을 구조적으로 해결하는 과정 자체가 더 큰 경쟁력이 될거 같다. 나는 이런것들이 너무 부족했었다.

사실 이제는 프레임워크가 어땠고, 어떤 기술이 좋고, 이 기술을 써봤다는 사실 좀 철지난 이야기가 아닐까 싶다. 

우리는 이 기술을 써봤다 -> 왜 이 기술을 선택했고, ai를 통해 수작업으로 했다면 많은 병목, 낭비를 이렇게 줄였다, 문제를 어떻게 접근했고, 어떤 부분을 시켰다. 

이런 방식으로 성장해야 할거 같다

공부를 하는 시간보다 기록을 하는 시간이 많아야 하는거 같다. 

하다못해 과거에는 성능이 느려? -> 병렬처리 해볼까? -> 병렬처리 부터 공부 시작 -> 하나씩 적용해보며 트러블 슈팅

요즘은 ai가 알아서 병렬처리 로직을 넣어서 해준다. 

그러다보면 벙렬처리는 나의 무기가 아닌거 같다.

나도 참 어려웠다. 너무 ai 에게 의존하다보면 정말 내것이 아무것도 없다. 

나도 이런 상황에서 많이 벗어나고 싶어서 항상 고민했고, 지금도 고민한다. 

지금까지 내린 결론은 ai 의 생산성을 가져가야하는 것은 맞다. 하지만 ai가 이렇게 한것에 대해 우리는 항상 의문점을 가지고 왜 이렇게 했는지, 그리고 해결한 것을 ai 가 아닌 내 손으로 기록하면서 되새김이라도 해보자는 것이다. 그리고 그것은 우리의 자산이 될거다 

아직은 이게 해결점이라고 생각하는데 다른 사람은 아닐 수도 있다. 그냥 개인적인 견해다

4. 퇴사를 결심한 계기? 

나는 항상 성장에 목마른 사람이다. 회사를 다니면서 짧은 시간에 정말 다양한 기술들, nosql의 firebase, 엘라스틱 검색엔진, next를 사용하다 보니까 프론트에서의 성능 개선, ai 프롬프트 엔지니어링, ai 의 할루시네이션에 대한 나의 내공도 생겼고 정말 다양한 점을 배울 수 있다는 것은 좋았다. 

하지만 너무 빠른 회사 안에서 나는 천천히 오래 가는 거북이같은 사람이라는 것을 알았다. 세상은 너무 다양한 사람이 있고 나는 꾀를 못부리는 사람이다. 천천히 하나씩 연구하는 행위를 좋아하면서 창의적인 행위를 선호한다. 

이런 긴박한 상황에서 어떻게든 빠르게 처리해야하는 업무 환경이 아직 내공이 없는 신입에게는 독이었던 거 같다. 자꾸 놓치고, 자책하고, 내 기준에 완벽함을 추구하던 습관들이 회사한테는 서로 좋은 영향이 아니었다고 생각한다. 

그리고 이렇게 일을 하다보니 점차 내것이 있나? 물론 배우는 것이 있지만 정말 그 깊이가 존재하나? 라는 의문이 커졌다. 

그래서 퇴사를 결심했다.  퇴사하고 너무 좋은 사람들, 내가 쏟아부은 애정들은 그대로 아직도 존재한다. 그래서 아쉬운 마음도 있고, 가끔 꿈에서도 나온다 ㅎㅋㅎㅎ 약간 첫사랑을 하고 끝난 느낌이랄까 ? 퇴사하고 여운이 꽤 오래갔다. 

하지만 작은 회사에서 한명, 한명의 역량을 꽤 중요하다 나의 성장도 중요했고, 회사의 성장도 기원하면서 더 좋은 팀원을 만나길 바란다. 

5. 퇴사후 2개월 

그래도 나름 이것저것 너무 한게 많아 사실 좋은 회사들에게 꽤 제안이 왔다. 한 10개? 가까이 회사에 제안이 왔고 면접도 실제로 보고 합격된 곳들도 있었다. (취업 안된다는 요즘 mz 말들은 좀 구라인듯 하다ㅇㅇ)

면접도 가끔 보면서 해외여행도 처음 가보고 그동안 무거웠던 마음의 짐을 내려놓고 힐링을 했다. 

혼자 생각하는 시간도 많이 가졌고 지금의 나는 회사를 가지 않기로 결심했다. 

나는 쉬면서 프리랜서로 일했고 첫달 수입은 약 330 수익을 얻었다. 우리의 선택지는 회사가 아니다. 꿈을 향해 가보자

그래서 회사보다 대학원을 선택하기로 했다. 

나는 한번쯤은 아무것도 하지 않고 공부와 연구만으로 시간을 채우는 기간을 겪고 싶었다. 대학시절도 항상 알바와 병행했고, 밤새서 짬내서 공부하는 시간들이 일쑤였다. 그래서 정말 절에 들어가서 공부해보고 싶은 미친 생각? 같은 것을 종종했다

마침 애정하는 교수님께서 대학원 추천서와 장학생, 연구비, 조교생활까지 모두 지원해준다고 했다!!

이거 완전 럭키비키자나~ 

퇴사 후 2개월 간 너무 많은 기회들이 있었다. 외국계 회사, 금융업, SI 도 있었고, 백엔드 개발, 컨설턴트, AX 등 너무 다앙한 직무제안

그 와중에 대학원 제안도 너무 감사한 일이었다. 사실 이 모든 기회들은 어쩌면 내가 졸업하고 큰 도전이었던 스타트업에서 개발자로 일을 하며 성장했기 때문이 아닐까? 그래서 너무 감사하게 생각하고 있다.

지금의 나는 돈이 중요한가?

나는 성장하고 싶은 사람이다. 

2년 뒤의 나를 기약하며 힘내자  

약 2달간의 방황을 마음에 새기면 따뜻하고 좋은 방황이었다. 이제는 선택이 끝났으니 다시 집중의 시간을 가져보겠다. 

1. 서론 

사이트를 만들고 배포를 하면 일반적으로 사이트가 바로 구글, 네이버 같은 검색엔진에 자동으로 나오는 줄 알았던 바보

최근 외주를 받으면서 웹사이트를 만들어주고 있다.

회사 사이트인데, 구글 검색, 네이버 검색에 최소한 보여야 하지 않나!

그래서 검색 시 사이트가 나오는 방법을 적용해보도록 한다.

1.1 기본 개념 

• SEO(Search Engine OPtimization) : 검색엔진 최적화

2. 본론

2.1. 검색엔진 (google, naver, bing) 사이트 노출 과정 

일단 크게 보면 사이트를 배포했다고 구글, 네이버같은 검색엔진에 노출되는 것이 아니다. 

검색엔진은 인터넷에 수 많은 사이트를 자동으로 찾아 내용을 읽고, 저장한 뒤, 사용자의 검색어에 맞는 페이지를 찾아 골라주는 과정을 거친다. 

2.1.1. 크롤링 

구글과 네이버같은 검색엔진들을 각각 검색로봇을 가지고 있다. (구글 검색봇은 googlebot, 네이버는 yeti) 

검색로봇은 다른 사이트의 링크, 사이트맵, 검색 도구에 등록된 정보를 바탕으로 웹사이트를 찾아온다. 검색봇이 내 사이트에 들어와서 각 페이지의 주소, 제목, 본문, 이미지 설명, 링크들을 읽는다!

이때 검색 봇의 접근이 막혀있다면 당연히 크롤링이 안되고, 검색 결과에 나타날 수 없을거다. 

+ robots.txt 이 파일을 만들어줘야 한다. 일종의 검색봇에게 어떤 페이지를 방문해도 되는지 알려주는 안내문이다. 

2.1.2 색인 생성 (크롤링 통해 읽은 내용을 검색 디비에 저장)

검색 봇이 페이지를 읽었다고 검색 결과에 바로 표시가 되는 것이 아님!

검색엔진은 읽어온 내용을 분석해 검색 디비에 저장할지 결정한다 - 색인생성(Indexing) 

예를 들어 재단 홈페이지에 '후원 안내' 페이지가 있다면, 검색엔진은 이 페이지가 어떤 주제의 페이지인지 파악하고 관련 검색어와 연결해 사용자들이 검색할떄 해당 사이트를 볼 수 있도록 하는 것이다. 그래서 페이지 제목과 본문이 명확하고, 다른 페이지와 내용이 중복되지 않게 하는 것이 중요하다!!

+ sitemap.xml 검색엔진이 색인을 만들기 쉽게 하기 하려면 사이트의 주요 페이지 목록을 담은 이 파일을 제공하는 것이 좋다 

2.1.3. 순위 결정: 검색어에 맞는 결과를 보여주는 과정

사용자가 '--재단의 봉사' 라고 검색하면 검색엔진은 수많은 관련 페이지 중에서 가장 관련성 높고 유용하다고 판단한 결과를 순서대로 보여주게 된다. 

단순 특정 단어가 많이 들어가는게 아니라 페이지 내용이 검색어와 잘 맞는지, 정보가 실제로 도움이 되느닞, 사이트가 모바일에서 잘 열리는지, 다른 신뢰할 만한 사이트에서 연결하고 있는지 등 여러 요소를 종합적으로 판단한다

종합적으로 보았을때 seo 는 검색엔진과 사용자 모두가 사이트 내용을 쉽게 이해하도록 만드는 작업이라고 볼 수 있다. 

(순위 결정은 참고로 검색엔진 상위 노출 로직과는 다른 이야기다.)

2.3. robots.txt, sitemap.xml 만들기

앞에서 크롤링과 색인 얘기를 했는데, 검색봇이 내 사이트를 제대로 읽어가게 하려면 결국 이 두 파일이 핵심이다. 하나씩 뭔지, 어떻게 만드는지 정리해본다.

2.3.1. robots.txt — 검색봇 출입 안내문

robots.txt는 사이트 루트(https://내도메인/robots.txt)에 위치하는 텍스트 파일로, "이 페이지는 봐도 되고, 이 페이지는 보지 마"를 검색봇에게 알려주는 규칙이다. 강제성은 없고 봇들이 "매너로" 지켜주는 약속에 가깝지만, 구글봇/네이버 예티 같은 정상적인 검색봇은 대부분 이 규칙을 따른다.

< 기본 문법> 

User-agent: *          # 모든 검색봇에게 적용
Allow: /                # 기본적으로 전체 허용
Disallow: /login        # 로그인 페이지는 크롤링 금지
Disallow: /admin/*      # /admin/으로 시작하는 모든 경로 금지

Sitemap: https://내도메인/sitemap.xml   # 사이트맵 위치도 여기 알려줌

• User-agent: 규칙을 적용할 봇 (*는 전체)
• Allow / Disallow: 허용/차단할 경로
• Sitemap: 사이트맵 파일 위치를 여기 적어주면 검색봇이 사이트맵을 더 쉽게 찾아감

왜 필요?

로그인 페이지, 회원가입 페이지, 글쓰기(작성/수정) 페이지처럼 관리자만 접근하는 페이지나 검색 결과에 노출될 필요가 없는 페이지는 여기서 막아주는 게 좋다. 안 그러면 검색봇이 의미 없는 페이지까지 긁어가면서 정작 중요한 페이지(소개, 사업 안내 등) 크롤링에 쓸 리소스가 분산된다

Next.js(App Router)에서 만드는 법 (나는 next 를 사용하기에 이를 반영한다.)

정적 사이트라면 public/robots.txt 파일을 직접 만들어 넣으면 끝이지만, Next.js App Router를 쓰고 있다면 app/robots.ts 파일 하나로 동적으로 생성할 수 있다 이는 본인 프레임워크에 맞게 설정하면 될거다

// app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: [
        "/login",
        "/signup",
        "/gallery/new",
        "/notice/new",
      ],
    },
    sitemap: "https://내도메인/sitemap.xml",
  };
}

2.3.2. sitemap.xml — 사이트 주요 페이지 목록표

sitemap.xml은 사이트에 있는 페이지 URL들을 목록으로 정리해서 검색엔진에게 "우리 사이트엔 이런 페이지들이 있어요"라고 미리 알려주는 파일이다. 검색봇이 링크를 타고 하나하나 찾아다니는 것보다 훨씬 빠르고 정확하게 페이지를 발견하게 해준다.

< 기본 문법 >

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://내도메인/about</loc>
    <lastmod>2026-08-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

• loc: 페이지 URL (필수)
• lastmod: 마지막 수정일
• changefreq: 이 페이지가 얼마나 자주 바뀌는지 (daily, weekly, monthly, yearly 등 — 참고용이라 검색엔진이 100% 따르진 않음)
• priority: 사이트 내에서 이 페이지의 상대적 중요도 (0~1)

Next.js(App Router)에서 만드는 법
마찬가지로 app/sitemap.ts 파일 하나로 처리할 수 있다.

// app/sitemap.ts
import type { MetadataRoute } from "next";

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    { url: "https://내도메인", changeFrequency: "weekly", priority: 1 },
    { url: "https://내도메인/about", changeFrequency: "monthly", priority: 0.8 },
    { url: "https://내도메인/notice", changeFrequency: "daily", priority: 0.8 },
    // ...
  ];
}

중요! 

어떤 게시물의 상세 페이지처럼 관리자가 계속 새로 등록하는 페이지는 위처럼 하드코딩하면 새 글이 올라올 때마다 파일을 고쳐줘야 한다. 이럴 땐 sitemap.ts를 async function으로 만들어서, 빌드/요청 시점에 DB(Supabase 등)에서 목록을 직접 가져와 자동으로 URL 목록을 만들면 된다. !!

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const notices = await fetchNoticesFromDB(); // DB에서 공지 목록 조회

  const noticeEntries = notices.map((notice) => ({
    url: `https://내도메인/notice/${notice.id}`,
    lastModified: notice.updated_at,
  }));

  return [
    { url: "https://내도메인", priority: 1 },
    ...noticeEntries,
  ];
}

이렇게 되면 새 글이 올라올때마다 내가 sitemap 파일을 수동으로 수정할 필요 없이 사이트맵에 자동으로 반영된다. 

정적 페이지(메뉴 구조)만 새로 추가되거나 삭제될 때는 이 파일을 직접 손봐줘야 한다는 점은 기억하자..! 수정하기 전에 항상 확인하기

2.4. 구글 서치 콘솔 등록

1. 구글 서치 콘솔 사이트에 들어감 

https://search.google.com/search-console/welcome

2. 웹사이트 추가 버튼을 클릭하면 아래 같은 창이 뜸

그럼 이 url 접두어 란에 

배포한 서비스 url 을 그대로 입력해주고 계속 버튼 클릭

3. 소유권 확인 창

넘어가면 위와 같은 소유권 확인이라는 창이 뜬다

이때 제공해준 html 파일을 다운로드 받아면 

 google-site-verification: --------

이런 코드를 받게 되는데

이 다운받은 파일은 프로젝트의 public/ 경로 아래에 추가해준다.

이는 인증 파일을 만든 것이고 나는 next.js를 사용해서 개발중이기 때문에 /public 폴더는 루트 경로로 서빙되니 배포되면 이 경로로 접근이 가능해진다. 

4. 배포한다.

5. 확인

 그 다음은 인증파일이 배포가 되었고, 완료 버튼을 누른 후 다시 구글 서치 콘솔로 돌아와 메뉴바에 있는 sitemap 경로를 제출해주면 됩니다

그 후 위에 검색창에 사이트 url 을 입력하면 구글이 페이지를 어떻게 보고 있는지 확인하는 것으로, 실제로 검색결과 db에 등록이 되어있는지 확인하는 방법이에요

보니 아직 등록이 안되었다고 한다. 이럴때는 오른쪽의 "색인 생성 요청" 클릭한 이후로 기다리면 된다. 

2.5. 네이버 서치어드마이저 등록 

구글 검색에 등록하는 것은 완료가 되었다. 이제는 네이버 검색엔진에 등록해보겠다. 

1. 네이버 서치어드마이저에 들어와 로그인부터 해준다.

https://searchadvisor.naver.com/

로그인이 되었다면 옆에 웹마스터도구 클릭

2. 사이트 등록

배포된 주소 사이트 링크를 넣어주고 화살표 버튼을 클릭

3. 소유권 확인

여기서도 파일 업로드 방식으로 진행한다

저기 1번에 있는 초록색 글씨로 확인 파일 버튼을 클릭하면 동일하게 

naver-site-verification: ---

이런 키값들이 있을거다 

이것도 동일하게 public/ 경로 아래에 파일을 만들고 붙여주면 된다. 그리고 동일하게 배포!

5. 사이트 맵 등록

소유권 확인까지 끝났으면 사이트가 이렇게 등록이 되었을 거다.

해당 사이트 링크를 클릭하면 이런 사이트 관리 페이지 이동이 된다.

사이드바에서 요청에 사이트맵 제출 란을 들어가서 

전체 도메인을 포함한 ..../sitemap.xml 을 입력하고 확인하면 끝난다

7. 수집 확인

이제 마지막이다. 요청에서 웹사이트 수집에서 다시 url을 넣어주고 확인만 하면 끝난다. 구글의 색인 생성 요청과 같은 절차라고 보면 된다.

그럼 끝 ! 검색엔진에서 몇시간 후에 확인하면 사이트가 잘 노출되는 것을 확인할 수 있다.

이게 뭐선일 

커서 잘만 쓰다가 갑자기 이런 인식 오류가 났다 

1.  커서 인증 문제 

내 상황은 회사 노트북이 갑자기 안됐고, 집 개인 노트북으로 했을때는 정상적으로 작동을 했다. 그래서 계정의 문제는 아닌거 같았다. 

해봤던 방법으로는..

1. 커서 삭제하고 다시 깔기 ㅋㅋ

2. 재로그인, 재부팅 

3. 세션 초기화해서 커서 최근 내용 날리기 

등등 별 방법은 다 했는데 안됐다 

그래서 커서 지원팀한테 메일보냄 !!! 

처음인데 답장이 진짜 빨리온다 ㅎㅎ

support@cursor.sh

이 메일로 보내면 된다. 문제가 생겼을 떄 내가 커서에 요청했던 아이디가 보이는데 그것과 함께 보내면 된다. 

2.  커서 지원팀에 메일 보내기 

Hello Cursor Support,

Cursor works perfectly on my other laptop with the same account and hotspot network.

However, on this specific MacBook, I always get:
"Unauthorized request. User is unauthorized"

I have already:
- Reinstalled Cursor (clean uninstall)
- Cleared all cache, logs, preferences
- Deleted Keychain credentials
- Restarted macOS multiple times
- Logged out from all devices

Please reset or re-authorize this device ID on your server.

Request ID:
9fㅇㄴㅇㅁ

Thank you.

답장이 진짜 바로 왔다. 

30분도 안되서 바로 답장이 왔다

ㅎㅎㅎㅎㅎ홀리몰리

역시 계정 문제는 아니었고!!!

3. 해결법

그렇다 나 오늘 회사에서 검색엔진 테스트 한다고 회사 노트북 자체의 시간을 테스트 시간으로 변경을 했었다.. 

기기 시간이 바뀌면서 커서 사용에서 요청할때 동기화 이슈가 있었던 것같다...

몰랐다 기기 시간이 커서에 영향이 있을지는...

그래서 다시 맥북 시간을 자동인식 원래 시간으로 돌린 후 재부팅하니까 됐다 ㅠㅠ

커서 사용할때 노트북 시간을 함부로 조정하지말자...! 조정해도 다시 돌려놔야한다...!!

1. 동기 

나는 스타트업에서 next 풀스택 개발을 한다. 요즘은 검색엔진 작업을 주로 한다

자꾸 뭐가 뭐였는지 기본적인 개념들을 정리 안한 상태에서 개발하다 보니 헷갈리고 까먹고 뒤죽박죽 멍텅구리다

그래도 검색엔진 사용해 현재 서비스까지 배포하면서 이거는 알면 좋아가 아니라

이건 외워야해 하는 거 정리할거다. 검색엔진은 일종의 네이버라고 생각하면 된다. 네이버도 결국 어떤 키워드로 검색을 하고, 우리의 디비에서 어떤 필드에서 어떤 키워드로 검색해서 추출해 데이터들을 가져올지 결정한다. 

작은 필드 타입, 값들 하나가 검색엔진에서 보여지는 화면에 데이터의 수를 가름한다ㅠ 눈물의 검색엔진 개발이었음 ㅠㅠ 

그래도 해야지 ? 

2. 구조

POST my_index/_search
{
  "size": 50,
  "from": 0,
  "_source": ["title", "content", "Date"],
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "토마토" } }
      ],
      "filter": [
        { "range": { "postDate": { "gte": 20250101, "lte": 20250131 } } }
      ]
    }
  },
  "sort": [
    { "Date": "desc" },
    { "timestamp": "desc" }
  ],
  "aggs": {
    "by_mart": {
      "terms": { "field": "supermarket.keyword", "size": 10 }
    }
  }
}

보통은 엘라스틱 서버에 이렇게 쿼리 요청을 보내게 된다. 그럼 이 구조에 맞게 응답을 주게 된다. ( 워워 진정하자 구조만 보자 ) 

내부 구조를 크게 나누면

• top-level 파라미터: size, from, _source, sort, track_total_hits, timeout, collapse...등등 
• query DSL (검색 조건): query 안의 bool, must, filter, should, must_not, match, term, range 등 : 키워드가 어떤 방식으로 조회할 것인지 볼 수 있다(띄어쓰기를 포함할것인지, 정확히 매칭할 것인지, 이 키워드가 포함되면서 어떤 필드에 필터를 적용할 것인지 등을 매칭해주는 것이다) 
• aggs (집계): aggs 안의 terms, date_histogram, cardinality … : 일종의 제일 많이 언급된 것 이런 집계적인 조회를 할 수 있다
• 필드와 매핑: text, keyword, date, long 등의 타입과 .keyword 서브필드

요렇게 나누고 뜯어보자 

3. 개념

3.1. 문서 / 필드 / 매핑 개념

• index : RDBMS로 치면 테이블 비슷한 단위 (디비에 테이블을 만들어야 조회를 하는거 처럼 이게 인덱스)
• document(문서) : 테이블의 row 느낌. JSON 하나가 문서.
• field(필드) : row의 column 같은 것.

매핑 : 각 필드가 어떤 타입인지 정의를 하는 설정이라고 보면 된다 

• text : 풀텍스트 검색용 (문장 검색), 분석기(analyzer)로 잘게 쪼개서 단어 단위로 색인, 그래서 부분검색이 가능,  match, multi_match, query_string, bool_prefix 등에서 검색할 때 사용 (나중에 설명) , 한국어 최적화된 nori(나중에 설명) 를 쓸때 사용한다고 함
• keyword : 정확값 / 집계 / 정렬용, text랑 다르게 쪼개지 않고 전체 문자열 그대로 저장 (term 쿼리, terms 쿼리, terms aggregation, sort에 사용)
• date : 날짜/시간 (range 쿼리 필수)
• long, integer, double : 숫자형
• boolean 

좀 헷갈렸던 부분 !!!!!!!

보통은 엘라스틱에서 문자열 필드를 만들면 이런 매핑을 볼 수 있다. 

"product": {
  "type": "text",
  "fields": {
    "keyword": { "type": "keyword", "ignore_above": 256 }
  }
}

 - product : 이 자체의 type: text (nori 같은 한글분석기로 토큰을 쪼개서 풀텍스트 검색용으로 쓰는 필드) , match, multi_match 등에 사용된다. 

- product.keyword : 이것의 타입은 type: keyword 

(문자열 전체를 쪼개지 않고 그대로 저장한 것), (정확한 비교, 집계, 정렬에 사용된다)

"terms": {
  "product.keyword": ["냉장고", "에어컨"]
}

product 배열 필드가 사실 디비에 저장이 되어 있을때  엘라스틱에서는 product는 text라서 집계, 정렬에 바로 못쓴다. 그래서 product.keyword로 바꿔서 써야하는 것이다. 

왜 .keyword가 필요?

만약 content: "토마토 주스보다 토마토 케찹이 좋아 멋쟁이 토마토"

1. content 는 text로 토마토, 주스보다, 케찹 뭐 이렇게 단어들로 분석된다. (그래서 주스가 포함된 글을 검색하기에 좋다(match, multi_match)

2. content.keyword 는 keyword로 "토마토 주스보다 토마토 케찹이 좋아 멋쟁이 토마토" 통째로 한 덩어리로 저장된다. 

이것을 term, terms로 검색을 하면 문장이 완전히 똑같은 경우에만 매칭된다. 

- 일반적으로 제목, 본문 같은 것보다 제품명, 위치 같은 필드에 .keyword가 유용할 거 같다. 

- 특징으로는 분석기에 적용이 안되기 때문에 오타, 띄어쓰기, 대소문자 그대로 본다(그래서 집계, 정렬, 정확 필터에 사용하기 좋은 것이다. 너무 많이 언급했다 힘들다)

3.2. top-level 파라미터

• size : 한번에 몇개 가져올지 (사과가 들어간 문서를 몇개 가져올지 엘라스틱에서는 1만개를 최대로 권장함 )
• from : 페이지네이션 (앞에를 몇개를 건너뛸지 ) - page 1: from: 0, size: 20/ page 2: from: 20, size: 20 (만약에 1만개의 카드리스트를 뿌린다고 할때 1만개를 보여주는게 아니라 페이지네이션을 결정해도 좋다는 것이다. 몇페이지까지만 부르고 뭐 이런 방식 -> 이거 나도 프론트에서 데이터를 몇 만개를 뿌릴떄 애용했다 ㅎㅎ) 
• sort : 정렬 (위에서부터 우선순위다) - text 타입 필드는 정렬 /집게에 직접 사용안됌 (반드시 creadAt.keyword 처럼 .keyword 필드를 사용해야한다-> 아래 예시를 들어보겠음)

"sort": [
  { "date": "desc" },
  { "timestamp": "desc" },
  { "createdAt.keyword": "asc" }
]

• _source : 어떤 필드를 가져올지 ( 응답에 포함할 필드를 지정해서 네트워크 비용을 줄일 수 있다)
• track_total_hits : total count 정확도 (기본적으로 1만개 이상이면 "relation": "gte"  로만 알려준다) , 정확한 전체 개수가 필요할 때 true 또는 충분히 큰 숫자를 주어서 해당 키워드로 검색된 문서 수를 알자
• timeout : "2s" -> 2초 넘으면 중간까지만 결과 반환한다.
• terminate_after : 샤드에서 각 몇건까지 검색할지 제한( 성능/속도 튜닝용임) 아 샤드 개념 정리는 따로 작성해야징

3.3. Query DSL !! (쿼리라는 도메인에 특화된 dsl - 도메인 특화 언어) 

엘라스틱 검색 조건을 표현하기 위해 만든 json 기반 언어라고 생각하며 됌. (검색조건을 전달하기 위해 사용한 '검색 전용 json 문법 체계'

이게 찐이다 여기를 일단 잘 알아야한다. 

-  bool?  :  여러 개의 쿼리를 논리적으로 조합하는 컨테이너 

and, or, not 같은 논리(부울) 연산을 수행하기 위한 쿼리 컴바이너(조합기) 이다. 그래서 이름도 불쿼리!

엘라스틱에서는 기본적으로 단일쿼리는 하나의 조건만 검색하지만 실제로는 항상 여러 조건을 붙여져서 검색하게 된다. 예를 들어 제품 필드에 '토마토' 가 포함되면서 date 는 최근 일주일 범위이고, 장소 필드는 서울이라고 하면 이런 조합들을 만들기 위해서는 공식 컨테이너 bool 이 필요한 것이다. 

그래서 bool 이 없이도 검색을 할 수도 있지만 이러면 단일 쿼리 검색이 되니까 노잼 쿼리가 되는 것 ~ query 아래에는 bool 만 오는게 아니라 엘라스틱의 모든 쿼리 타입이 올 수 있다 하지만 bool을 쓰면 여러 조건을 조합할 수 있다. match/mulit_match/term/range도 단독으로 올 수 있긴 한데 걍 같이 쓰는게 편한거 같다

3.3.1.  bool 의 내부 구조 (핵심만 4가지 타입)

타입 더 많음 ;;

"bool": {
  "must": [],
  "filter": [],
  "should": [],
  "must_not": []
}

각각의 불리언 논리연산을 수행한다고 보면 됌. 

(1) must 

 - and 조건 ( 점수 존재 - 가중치가 있다 어떤 것이 더 매칭률이 높은 문서인지 라고 생각하면 될듯)

 - 텍스트를 검색할 때 (match, mulit_match - 아래 설명) 이런 조건을 넣는데 이때 점수 계산이 필요한 조건은 여기에 들어간다. 

(위에 3.1. 매핑 타입에서 설명했듯이 텍스트는 정확한 쿼리 검색이 아니라 전체 텍스트에서 검색하려는 단어를 찾는 것이기 때문에 점수 매칭에 적용된다고 보면 된다. 반대로 .keyword 는 텍스트와 다르게 검색한 단어와 정확한 단어를 찾아서 보여준다.)

 - 캐시를 적게 사용한다.

 - 텍스트 검색에 좋고, 날짜/정확한 값은 별로임 

(2) filter 

 - and 조건( 점수 없음 : must 에 검색할 단어를 넣었고, 필터는 검색한 단어로 찾은 문서들 중에 내가 넣고 싶은 조건들을 넣는 부분이라고 보면 된다. 그래서 점수가 없고 반드시 만족해야할 조건이 된다.) 

 - 캐시를 많이 사용되서 빠르고, 성능 최적화의 핵심이다. 

 - 텍스트 검색 안됌 

 - 날짜/ 정확한 값에 좋음 

(3) shold 

 - OR 조건 ( 이 조건을 만족하면 좋다) 라는 뜻이고 

 - 예를 들어 제품 필드에 토마토가 들어가는 것은 must에 넣고 type필드에 싱싱함 이라는 키워드가 포함되면 더 좋다 이런 느낌임

"should": [
  { "match": { "type": "싱싱" }},
  { "match": { "type": "국내산" }}
],
"minimum_should_match": 1

- minimum_should_match 옵션 ! : or 조건이 여러 개 있을때 그 중 최소한 '몇 개' 를 만족해야 문서를 검색 결과에 포함시킬 지 결정한다. should는 기본적으로 있으면 점수는 올려주지만 맞지 않아도 된다. 선택조건이기 때문에 (하지만 should 안에 조건을 최소 1개는 만족해야 문서를 포함하기 위해서는 저렇게 1을 포함해주면 된다!) -> 숫자 말고 퍼센트도 됨 ㅎㅎ 후뚜루 마뚜루 조건에 쓰기 좋음 

"query": {
  "bool": {
    "must": [
      { "match": { "product": "냉장고" } }
    ],
    "should": [
      { "match": { "content": "저렴" } },
      { "match": { "content": "가성비" } }
    ],
    "minimum_should_match": 1
  }
}

제품에 냉장고는 반드시 있어야 하고 본문에는 저렴, 가성비가 하나라도 나와야 한다. 

(4) must_not 

- 말 그대로 not 조건 (제외조건)

"must_not": [
  { "term": { "유통기한": "지남" } }
]

+ bool은 조합기 일 뿐이다. bool 은 직접 검색을 하지 않는다. bool 내부에 match, term, range, query_string 등이 실제 쿼리를 넣어 조합하는역할이다

"query": {
  "bool": {
    "must": [
      { "multi_match": { "query": "대파", "fields": ["냉장고","냉동고"] } }
    ],
    "filter": [
      { "range": { "Date": { "gte": 20250101, "lte": 20251231 } } },
      { "terms": { "source": ["국내산","중국산"] } }
    ]
  }
}

bool(상자), must/filter (칸), match/term (조건) : bool은 and 조합(must + filter), or조함(should), not 조합(must_not)

3.3.3. term/terms 타입 

: 정확한 값을 찾는 쿼리라고 보면된다 "정확 매칭 쿼리" (Nori 같은 분석기없이 원본 문자열 그대로 완벽히 일치하는 문서만 매칭한다)

term 는 "토마토 주스보다 토마토 케찹이 좋아 멋쟁이 토마토" 이 전체 문자열 그대로 비교하는데 사용된다. 

대소문자, 띄어쓰기, 중간에 오타 이런것도 다 매칭이 안된다. 

그래서 keyword 타입에 써야한다 !!!! 

!!!!!!!!!!!!! text 필드는 분석되서 조각나기 때문에 term으로 비교하면 절대 거의 안맞음 !!!!!!!1

{ "term": { "product.keyword": "생수 500ml" } } 

terms는 복수 형태로 여러 값 중에 하나라도 같으면 매칭이 된다. 

{
  "terms": {
    "sesson": ["spring", "winter"]
  }
}

구분 term terms

{ "terms": { "products.keyword": ["냉장고", "에어컨"] } }

products: ["선풍기", "전자렌지", "냉장고"] -> 하나라도 있으면 매칭이 된다. 

- term/terms 는 점수 계산을 안하기 때문에 필터로 사용해야한다. 

- term/terms는 query 단게 (문서 검색시 ) , 필터링 하는 단계에서 사용한다. rdb에서 where 조건 역할

- term/terms는 집계(agg) 할때 사용된다. (문서 그룹핑하고 그 갯수를 세는 단계, sql 의 group by 역할임)

https://dev-leeyjstar.tistory.com/entry/Spring-boot-AWS-S3-Presigned-URL%EB%A1%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EA%B4%80%EB%A6%AC-1-S3-%EC%84%A4%EC%A0%95

1. 구현 이유

위에 1편에 이어서 작성한다. 나는 일단 s3를 만들기 위해 버킷을 생성했고 나는 IAM Role 방식으로 ec2 인스턴스에 role을 부여해 자동인증을 함으로서 ec2에 접근이 가능하도록 하는 방식으로 구현을 하려고 세팅을 했다. 

하지만 실제 개발을 하고 로컬에서 테스트를 하기 위해서는 결국 테스트용 Iam 을 만들고 access key를 발급받아서 테스트를 해야한다. 

테스트가 다 되면 다시 원래 했던 방식으로 돌릴것이다. 

즉 

로컬 : Access Key 방식 : 로컬에서만 키를 설정 (application-local.yml)

ec2 : iam role 방식 : 키 생략 (application-prod.yml)

아무튼 그 과정을 기록한다.. 

2. Iam 사용자를 생성

1. iAM 콘솔에서 사용자 추가를 한다. 

2. 사용자 이름은 s3-local-test 이렇게 했다. 

3. 권한은 AmazonS3FullAccess 로 했다 

4. access key 발급 (설명테그는 생략)

5. 키 다운한다. 한번만 보여지기 때문에 꼭 저장 잘 해야함 

이 키를 env 안에 넣어주면 된다. 

3. profile 환경 분리 

자.. 현재 나는 application.yml 에 설정들을 하면서 이걸 배포용, 개발용 다 공통으로 사용하고 있었다. 

하지만 지금은 s3 를 설정하면서 로컬에서는 Access Key를 등록해서 인증하는 방식을 사용할 것이고 실제 배포되었을 때는 ec2에 자동 등록이 되어 있는 IAM ROLE 을 사용할 것이다. 이런 분리된 환경에서의 설정을 해보자 

일단 

credentials? aws 인증 정보(자격증명 )

cloud:
  aws:
    credentials:
      access-key: AKIAxxxxxxxx
      secret-key: wJalrxxxxxxxx

aws 리소스를 사용할 수 있는 비밀번호 같은 것

1. 기존에 사용하던 application.yml 에 항상 공통되는 설정을 해준다. 버킷명, 공통 도메인 등등 (region, bucket)

2. application-local.yml 에는 s3 secret key만 설정해준다 (credentials 설정을 넣어줌)

3. application-prod.yml 에는 iam role이 자동 인증 작동되도록 키가 없는 버전으로 설정을 해주면 된다. (credentials 설정을 빼줌) 

사실 일반적으로는 prod 파일을 만들어줘야한다. 환경에 따라 오버라이딩이 필요한 설정이 있다면 만들어줘야 한다. 

지금 내 상황에서는 cloud.aws.region, bucket 같은 설정이 공통 yml 에 설정이 되어 있고

로컬 버전에만 credentials 설정을 해주면 되고 운영 버전에는 credentials를 빼면 되기 때문에 굳이 파일이 없어도 되는것.

하지만 일반적으로 application-prod.yml을 두는 이유는 나중에 운영에서만 바꾸고 싶은 설정이 있을 수 있기 때문이다. 

예를 들어 db url, 로그 레벨을 운영에서는 info로 하고 로컬에서는 debug로 할수 있다. api 키 같은 것도 달라질 수 있어서 운영용 application-prod.yml을 두는게 일반적이다. 하지만 나는 사이드프로젝트이고 지금은 생각해봐도 달라질 설정이 없을 거 같다. 

그리고 그떄 필요하면 파일을 만들면 되지 않을까 싶다 굳이 지금 만들 필요가 있을까...

그래서 안만든다.

3. 1. application.yml : 프로파일, aws 버킷과 리전을 설정했다. 

spring:
  application:
    name: recipe

  profiles:
    active: ${SPRING_PROFILES_ACTIVE:local} # 기본적으로 로컬 프로파일을 활성화

  sql:
    init:
      mode: ${SQL_INIT_MODE:always}

  cloud:
    aws:
      region:
        static: ap-northeast-2
    s3:
      bucket: recipic-bucket

3. 2. application-local.yml : 키 설정

cloud:
  aws:
    credentials:
      access-key: ${AWS_ACCESS_KEY}
      secret-key: ${AWS_SECRET_KEY}

3.3. git action 워크플로우 수정 

로컬에는 위에처럼 application.yml에 있는 local이 적용되서 사용되지만 실제 배포를 할 떄는 워크플로우의 .env 파일 기반의 실행하면 자동으로 spring 이 application-prod.yml 또는 default로 설정을 사용하게 된다. 

spring은 appilcation.yml에 적인 active: local보다도 환경변수로 전달된 spring_profile_active 값을 우선 적용한다. 

- name: 📝 Create .env file
  run: |
    echo "SPRING_PROFILES_ACTIVE=prod" >> .env
    echo "APP_DOMAIN=${{ secrets.APP_DOMAIN }}" >> .env
    echo "JWT_SECRET=${{ secrets.JWT_SECRET }}" >> .env
    ...

4. 코드 

4.1. sdk 추가  (build.gradle)

implementation 'software.amazon.awssdk:s3'

4.2. s3Config.java

import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import software.amazon.awssdk.auth.credentials.AwsBasicCredentials;
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.auth.credentials.ProfileCredentialsProvider;
import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.presigner.S3Presigner;

@Configuration
public class S3Config {

    @Value("${cloud.aws.region.static}")
    private String region;

    @Value("${cloud.aws.s3.access-key:}")
    private String accessKey;

    @Value("${cloud.aws.s3.secret-key:}")
    private String secretKey;

    @Bean
    public S3Presigner s3Presigner() {
        S3Presigner.Builder builder = S3Presigner.builder()
                .region(Region.of(region));

        if (!accessKey.isEmpty() && !secretKey.isEmpty()) {
            // 로컬 환경: Access Key와 Secret Key를 사용
            builder.credentialsProvider(StaticCredentialsProvider.create(
                    AwsBasicCredentials.create(accessKey, secretKey)));
        } else {
            // EC2 환경: IAM Role을 자동 감지
            builder.credentialsProvider(DefaultCredentialsProvider.create());
        }

        return builder.build();
    }
}

- S3Presinger는 aws sdk에서 제공하는 클래스 중 하나로 presigned url을 생성하는 데 사용된다. 

4.3. service 

import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.*;
import software.amazon.awssdk.services.s3.presigner.S3Presigner;
import software.amazon.awssdk.services.s3.presigner.model.*;

import java.net.URL;
import java.time.Duration;
import java.util.UUID;

@Service
@RequiredArgsConstructor
public class S3Service {

    private final S3Presigner s3Presigner;

    @Value("${cloud.aws.s3.bucket}")
    private String bucket;

    
     //  S3에 이미지 업로드용 Presigned URL 발급 (PUT 방식)
     
    public String generateUploadPresignedUrl(String folder, String originalFileName) {
        // 고유한 파일 경로 생성
        String key = folder + "/" + UUID.randomUUID() + "-" + originalFileName;

        // S3에 업로드할 파일 요청 정보
        PutObjectRequest objectRequest = PutObjectRequest.builder()
                .bucket(bucket)
                .key(key)
                .contentType("image/jpeg")
                .build();

        // Presigned URL 발급 요청
        PresignedPutObjectRequest presignedRequest = s3Presigner.presignPutObject(
                r -> r.putObjectRequest(objectRequest)
                      .signatureDuration(Duration.ofMinutes(5))
        );

        return presignedRequest.url().toString(); // 프론트가 이 URL로 업로드하게 됨
    }

    
     // S3에 있는 이미지 조회용 Presigned URL 발급 (GET 방식)
     
    public String generateViewPresignedUrl(String key) {
        // 조회 요청 정보 생성
        GetObjectRequest getObjectRequest = GetObjectRequest.builder()
                .bucket(bucket)
                .key(key)
                .build();

        // Presigned GET URL 발급
        GetObjectPresignRequest getObjectPresignRequest = GetObjectPresignRequest.builder()
                .signatureDuration(Duration.ofMinutes(10))
                .getObjectRequest(getObjectRequest)
                .build();

        PresignedGetObjectRequest presignedGetObjectRequest =
                s3Presigner.presignGetObject(getObjectPresignRequest);

        return presignedGetObjectRequest.url().toString();
    }

    // S3에서 이미지 삭제
     
    public void deleteFile(String imageUrl) {
        String key = extractKeyFromUrl(imageUrl);

        S3Client s3 = S3Client.builder()
                .region(Region.AP_NORTHEAST_2)
                .credentialsProvider(DefaultCredentialsProvider.create())
                .build();

        s3.deleteObject(DeleteObjectRequest.builder()
                .bucket(bucket)
                .key(key)
                .build());
    }

    /**
     *  S3 URL에서 Key 추출
     * ex: https://bucket.s3.amazonaws.com/folder/abc.jpg → folder/abc.jpg
     */
    private String extractKeyFromUrl(String url) {
        int idx = url.indexOf(".amazonaws.com/") + ".amazonaws.com/".length();
        return url.substring(idx);
    }
}

4.4. controller

import lombok.RequiredArgsConstructor;
import njb.recipe.service.S3Service;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequiredArgsConstructor
@RequestMapping("/s3")
public class S3Controller {

    private final S3Service s3Service;

    /**
     *  업로드용 Presigned URL 발급
     * 프론트에서 파일 업로드 전에 요청
     */
    @GetMapping("/presigned-upload")
    public ResponseEntity<String> getPresignedUploadUrl(
            @RequestParam String folder,
            @RequestParam String fileName
    ) {
        String presignedUrl = s3Service.generateUploadPresignedUrl(folder, fileName);
        return ResponseEntity.ok(presignedUrl);
    }

    /**
     * 조회용 Presigned URL 발급
     * 프론트에서 비공개 이미지 조회 시 요청
     */
    @GetMapping("/presigned-view")
    public ResponseEntity<String> getPresignedViewUrl(
            @RequestParam String key // 예: ingredient/uuid-filename.jpg
    ) {
        String viewUrl = s3Service.generateViewPresignedUrl(key);
        return ResponseEntity.ok(viewUrl);
    }

    /**
     * 이미지 삭제 (서버가 직접 삭제 요청)
     */
    @DeleteMapping("/file")
    public ResponseEntity<Void> deleteImage(@RequestParam String imageUrl) {
        s3Service.deleteFile(imageUrl);
        return ResponseEntity.noContent().build();
    }
}

- 조회용 url 발급 ,,, s3 버킷에 저장할 수 있는 presigned url을 발급받아서 저장을 했다. 하지만 굳이 비공개로 해서 조회용 presigned url까지 발급할 필요가 있을까라는 의문점이 들었다. 

- 보안적인 측면을 생각하면 비공개로 하는게 맞을 거 같아서 코드상의 구현을 했다. 하지만 일단 s3 버킷은 퍼블릭 읽기 허용으로 바꿔서 접근 가능 할 수 있게 하는게 좋겠다. 나중에 뭐 바꾸면 되니까.. 지금은 이게 더 편리할 거 같다. 

5. 테스트 

서버 실행 후

5.1. s3에 업로드용 presigned url이 잘 발급되는지 보자

- param에 값을 잘 넣어준다. 이때 저렇게 폴더 이름을 넣어주면 s3 버킷 내에 폴더 아래로 이미지가 저장이 된다. 

https://recipic-bucket.s3.ap-northeast-2.amazonaws.com/ingredint/9aeabㅇㄹㄴㅇㄹㄴㅇㄹㄴㅇㄹ.testing.jpg?X-Aㄴㅇㅇㄹㄴㅇㄹㄴㅇㄹㄴㅇ

뭐 이런식으로 presigned.url이 날라온다. 

5.2. presignedURL로 s3에게 이미지 저장 요청하기 (put)

- 요청 url을 아까 받은 presignedURL로 저장하고 싶은 이미지를 put 요청을 하면 200응답을 확인할 수 있다. 

내 버킷 아래에 아까 param으로 넣었던 폴더 경로 밑에 이미지가 저장된 것이 보인다. 

저장 요청이 됐으면 이미지를 프론트에서는 <img src={imageUrl}> 바로 이미지를 띄울 수 있는 것이 좋다. 

그래서 s3에 저장된 이미지를 바로 받을 수 있게 s3를 퍼블릭으로 열어두면 된다. 

여기서 생겼던 트러블 슈팅은 따로 기록.... 하겠다..

.

.

.

일단 파일 업로드를 위한 presigned URL을 발급을 받았을 때 이것은 서명된 url로 "?" 물음표 뒤에 붙어 있는 값들은 aws에서 발급한 access key, signature 같은 것들이다. 

그래서 실제로 프로트에서 img 테그를 통해 이미지를 조회할 때는 split('?')[0] 를 사용해서 쿼리 스트링을 제거하고 수순한 이미지 주소만 가져다가 사용하면 된다. 

그래서 백엔드 디비 서버에 이미지 주소 경로를 저장할때도 순수 이미지 주소만 저장해주면 된다. 

이거는 굳이 넣지 않겠다. 그냥 디비 crud니까..

그래서 https://recipic-bucket.s3.ap-northeast-2.amazonaws.com/ingredint/9aeabㅇㄹㄴㅇㄹㄴㅇㄹㄴㅇㄹ.testing.jpg?X-Aㄴㅇㅇㄹㄴㅇㄹㄴㅇㄹㄴㅇ

이렇게 presigned URL 응답으로 준 값에 ?만 제거하고 검색을 하면 이미지에 퍼블릭 접근이 가능해서 조회를 할 수 있게 된다. 

아무 화면 캡처에서 저장했더니 ㅎㅎ 이렇다..ㅎ

1. 구현 이유 

현재 사이드 프로젝트에서 백엔드 spring boot jpa 개발을 맡고 있다. 

이미지 crud를 구현하는 것을 목표로 s3를 활용해서 이미지를 관리하고자 한다.  전에는 naver cloud platform에서 제공해주는 스토리지를 사용한 적이 있는데 aws의 버킷은 처음 사용한다. 그래서 기록하고자 함

현재 프로젝트는 ec2서버에 git action을 활용해 cicd가 구현이 되어있다. 완전히 배포된 게 아니라 개발 버전으로 cicd로 구축해서 프론트와도 편하게 연동하고 만들었다. 

2. 개념 

2.1 aws s3(Simple Storage Service)? 

아마존에서 제공하는 오브젝트 스토리지 서비스로 파일(이미지, 문서, 동영상 등)을 버킷에 저장하는 것을 말한다.

2.2 Bucket ? 

"object를 관리하는 컨테이너로 파일시스템"

s3에서 데이터를 저장할 수 있는 컨테이너 역할을 하는 공간이다. 파일을 저장하기 위해 버킷안에 저장을 해야하고 이때 사용하는 버킷의 이름은 고유해야한다. 

버킷 단위로 접근해서 접근 정책, cors 설정, 버전관리 등을 할 수 있다. 

2.3 Object ? 

s3에서 실제로 저장되는 파일(이미지 파일, 텍스트 파일, pdf, json ,,, etc) -> 파일과 파일 정보로 구성된 저장돤위

구성요소

1. key : 오브젝트의 "파일 경로 + 이름" : images/user/logo.png 이런거 

2. value : 실제 파일 데이터 (바이너리 형태로 저장된다)

3. metadata : 오브젝트의 속성 정보 (content-type, content-lenght,,)

3. s3 설정

크게 버킷생성, 버킷 권한 (cors 설정 같은거 프론트에서 접근하기 위해), IAM Role 설정(spring/ec2 등에서 접근위함) 

3.1 버킷 생성 

1. s3 접속

https://console.aws.amazon.com/s3/

2. 버킷 생성 클릭 

3. 설정

3.2 버킷 권한 설정

spring 서버가 s3에 직접 get, put 등등 요청을 하는 백엔드 중심 구조에서는 cors 설정이 필요없다. 

예를 들어 MultipartFile -> controller -> s3 Service 이런 식을 말한다. 전에 내가 ncp에서 오브젝트 스토리지를 사용했을 때 이런 방식을 고수했다. 하지만 이번 s3를 사용할때는 프론트에서 직접 s3에 업로드를 하는 방식을 취할 것이다. (이 부분은 아래에서 더 자세히)

아무튼 프론트에서 직접 접근하기에 cors 설정을 해줘야한다. 

생성한 버킷 -> 권한 탭 -> cors 규칙 추가 -> 사진과 같이 json 형태로 추가해주면 된다. 

3.3 IAM 권한 설정

s3는 퍼블릭한 서비스로도 사용할 수 있지만 대부분의 경우는 사용자의 개인적인 저장공간이 된다. 민감한 사용자의 파일이 저장되는데 이거를 쉽게 접근할 수 있으면 안된다. 그래서 IAM(Identity and Access Management)을 사용해서 제어할 수 있다. 

IAM을 설정하는데는 두가지 방식이 있다. 첫번째는 Access Key를 만들어서 .yml에 설정하는 방식으로 spring 서버에서 직접 s3에 접근할때 사용한다.  두번째는 IAM Role 방식으로 ec2 인스턴스에 iam role을 부여해서 자동인증을 함으로서 ec2에서 직접 접근한다고 보면 된다. 

보통 다른 블로그나 글들을 보면 첫번째 방식인 access key 방식을 자주 사용하는거 같다. 아무래도 yml에 키 저장해서 바로 쓸 수 있어서가 아닐까..? 싶다

전자 같은 경우는 키 노출 위험도 있지만 로컬. ci/cd 환경에서 구축이 편한거 같다. 하지만 키 만료되면 교체해야하고 보안적인 리스크가 존재한다. 후자는 ec2에만 부여된 권한이기에 키 자체가 없어 안전하다 하지만 ec2 내부에서만 동작하기 로컬이나 cicd 환경에서는 잘 안될 수도 있다는 점이다. 그래도 유지보수 측면에는 키 만료 걱정도 없고 역할만 유지하면 되서 aws 에서 권장하는 방식이라고 한다. 

 내 프로젝트 현재 상황 : git actions은 단지 ec2에 ssh로 접속해 jar 파일을 배포하고 실행하면서 cicd를 구축했다. 그래서 s3 접근은 ec2에 배포된 spring 서버가 수행을 하기 때문에 ec2에 IAM role만 있다면 자동으로 접근이 가능할거 같아 후자를 선택했댜. 

하지만 혹시나 로컬이나 테스트 중에 필요하다면 추가 블로그를 작성해야겠다

1. IAM 역할 생성 

2. 신뢰할 수 주체 선택에서 

 - aws 서비스 

 - ec2 선택

3. 권한 정책에 아래를 추가

4. 역할 이름은 자유롭게

5. ec2 인스턴스에 role 연결

기존에 쓰고 있는 ec2에 연결하면 된다. 이거는 따로 설명하지 않겠다.

ec2 인스턴스 - 작업 - 보안 - iam 역할 수정 - 위에서 만든 역할 선택 후 저장하면 된다. 

6. 테스트

s3 버킷에 접근이 가능한지, s3 버킷이 존재하는지 확인해보자.

일단 ssh 로 ec2에 들어와서 aws cli 부터 설치한다. 

# 1. AWS CLI 설치 파일 다운로드
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# 2. unzip 설치 (압축 풀기 도구)
sudo apt update && sudo apt install unzip -y

# 3. 압축 해제
unzip awscliv2.zip

# 4. AWS CLI 설치
sudo ./aws/install

# 5. 설치 확인
aws --version

그 다음에 임의로 텍스트 파일을 생성해 존재유무를 봐보자 

ubuntu@ip-000-00-00-00:~$ echo "hello recipic" > test.txt
ubuntu@ip-000-00-00-00:~$ aws s3 cp test.txt s3://recipic-bucket/test.txt --region ap-northeast-2
upload: ./test.txt to s3://recipic-bucket/test.txt
ubuntu@ip-000-00-00-00:~$ aws s3 ls s3://recipic-bucket/ --region ap-northeast-2
2025-04-16 16:01:05         14 test.txt

참고로 텍스트 파일을 생성하고 테스트를 안하면 아무것도 출력이 안된다 (에러가 아니라 s3 버킷은 존재하지만 파일이 없는 상태 의미)

4. Presigned URL ? 

말 그대로 미리 서명된 url..? "s3 객체에 접근할 수 있는 임시 서명된 url" 이다. 

이 url을 가진 사람은 IAM인증이 없어도 일정 시간동안 요청이 가능하다. 그래서 스프링 서버는 url을 생성해서 프론트에 주면 클라이언트는 그 url에 직접 이미지를 업로드하거나 조회를 한다. 

aws 공식문서를 참고하면 개념적 설명이 잘 되어 있다.

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/PresignedUrlUploadObject.html

이 방식을 사용하는 이유 ? 

전에 ncp의 오브젝트 스토리지를 사용했을 때는 서버를 거치는 방식을 사용했었다. 그래서 직접 mulipart file 방식으로 직접 받고 사용해보니 서버에서 복잡한 서비스 로직을 구현해야 했다. 

당시에 구현했던 글이 있어 참고한다. 

https://dev-leeyjstar.tistory.com/entry/%ED%8A%B8%EB%9F%AC%EB%B8%94-%EC%8A%88%ED%8C%85-ncp-Object-Storage-OOS-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%98%AC%EB%A6%AC%EA%B8%B0-%EC%88%98%EC%A0%95%ED%95%98%EA%B8%B0

이 방식이 성능, 확장성, 서버 부하, 보안 측면에도 기존에 구축했던 방식보다 더 나은 방식인 것 같다. 

4.1 로직 

앞서 말한 것 처럼 presigned url은 s3에 대해 제한시간동안 요청을 허용하는 서명된 url로 서버는 이 url을 생성해서 클라이언트에게 전다라하고 클라이언트는 이 url을 활용해 직접 s3에 요청을 보낸다. 

1. 이미지 업로드 

시나리오는 회원 정보를 새롭게 저장한다고 해보자

🔁 전체 흐름

1. 프론트에서 이미지 선택
2. 백엔드 /api/s3/presigned-url?type=memberprofile&fileName=itsme.jpg 호출
3. Presigned PUT URL을 응답받음 (정해놓은 유효시간 동안만 )
4. 프론트는 해당 URL에 PUT 요청으로 s3에 이미지 업로드
5. 업로드 성공 → URL에서 ? 이전 경로만 잘라서 S3 이미지 경로 확보
6. /api/memberprofile 등록 API에 imageUrl 포함해서 전송
7. 백엔드는 DB에 저장 (imageUrl 컬럼
   -> 결론적으로는 회원정보를 저장하기 전에 미리 이미지를 s3에 저장해놓고 저장해 놓은 경로를 받아서 회원 정보를 디비에 저장할때 이 경로도 같이 저장해놓으면 회원 디비에 회원의 이미지까지 같이 저장이 된다. 

📌 참고사항

• 업로드 URL은 PUT 방식
• S3 URL 저장 시 ? 쿼리 파라미터 제거: presignedUrl.split('?')[0]

2. 이미지 조회 

시나리오는 등록된 회원의 이미지를 조회하는 것

🔁 전체 흐름

1. 클라이언트가 GET /api/memberprofile/{id} 호출
2. 백엔드는 DB에서 imageUrl 조회
3. 응답 JSON에 포함해서 전달
4. 프론트에서 <img src={imageUrl} />로 출력

📌 참고사항

• 이미지 URL은 S3 주소 그대로 사용 가능 (버킷이 public-read 또는 CloudFront 연동이면 더 빠름)
• S3가 비공개 버킷이라면 조회용 Presigned GET URL도 발급해야 함

3.이미지 수정 

시나리오는 회원의 이미지를 바꾸고 싶을 때 

🔁 전체 흐름

1. 프론트: 새 이미지 선택
2. 백엔드에 Presigned PUT URL 요청 (새 파일 이름으로)
3. 프론트에서 새로운 URL로 이미지 업로드
4. 업로드 성공 후:
   • 이전 이미지 URL S3에서 삭제 요청 (선택적)
   • 새로운 이미지 URL을 포함한 /api/memberprofile/{id} 수정 API 호출
5. 백엔드는 imageUrl 컬럼을 새 URL로 업데이트

📌 참고사항

• 기존 이미지 삭제 여부는 서비스 정책에 따라 다름
• 이전 이미지 key 파싱 필요: https://bucket.s3.amazonaws.com/folder/abc.jpg → folder/abc.jpg

4. 이미지 삭제 

시나리오는 회원 정보를 삭제하면서 이미지가 같이 삭제되도록

🔁 전체 흐름

1. 프론트: /api/memberprofile/{id} 삭제 API 요청
2. 백엔드:
   • DB에서 해당 재료의 imageUrl 조회
   • S3 DeleteObject 요청
   • 재료 정보 DB에서 삭제

📌 참고사항

• Presigned URL은 필요 없음 (서버에서 직접 삭제 처리)
• S3의 key는 imageUrl에서 버킷 주소를 제거해서 추출

만약 회원 자체 삭제가 아니라 이미지만 삭제한다면 위에 3번처럼 수정하는 방식으로 삭제할 에정이다. 

코드 적인 구현은 2편에서 to be continue..

오늘의 학습 키워드 : 이분 탐색 , 파라메트릭 서치

1. 문제 : 백준 16401 과자 나눠주기

2. 내 풀이 

이분 탐색에 대한 개념은 알고 있었지만 파타메트릭 서치(이분탐색의 하위개념)에 대해서는 알지 못했다. 

그래서 공부를 좀 하느라 시간이 걸렸다. 

파라메트릭 서치 같은 경우는 "최적화문제"를 "결정 문제"로 바꿔서 해결하는 알고리즘이다. 이 개념은 유튜브 보고 이해를 했다..

결론적으로는 이분 탐색같은 경우는 입력받은 배열 같이 특정 값을 찾아 반절씩 쪼개면, 파라매트릭 서치는 배열이 아니라 내가 원하는 정답

- 이분 탐색 : 특정값을 찾는 문제 (배열안에 target 값 찾기 )

- 파라매트릭 서치 : 최대 몇 까지 가능? 최소 몇까지? 이런 느낌이다. 

- 이분탐색을 풀 때 처럼 파라매트릭 서치도 템플릿은 비슷하다(left, right, mid정하는 그런거,,)

처음에는 입력받은 배열 안에서 탐색을 하려고 하니까 머리가 안돌아갔다. 그래도 좀 공부를 하다보니 이해가 됐다. 

애초에 탐색하려는 범위가 과자의 길이 입력받은 값들이 아니라 결국 여기서 제일 큰 과자의 길이가 max가 되고 1~max 사이의 값 중에서 탐색을 하면 된다. 정답 후보는 이거다. 그리고 입력받은 과자의 길이들은 mid(target)값을 구할때 과자의 개수(cnt)를 구하는데 활용이 된다. 

시간복잡도 = O(N log(N))

3.코드 

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;
public class CT0414 {
    static int left = 1;
    static int right = 0;
    static int mid =0;
    public static void main(String[] args) throws IOException {
       BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
       StringTokenizer st = new StringTokenizer(br.readLine());
       int M = Integer.parseInt(st.nextToken()); //조카 수
       int N = Integer.parseInt(st.nextToken()); //과자 수
       int[] lenarr = new int[N]; // 과자의 각 길이를 담을 배열 선언


       st = new StringTokenizer(br.readLine());
       for(int i=0; i< N; i++) {
           lenarr[i] = Integer.parseInt(st.nextToken());
           right = Math.max(right, lenarr[i]); // 제일 큰 값이 들어가게 됌
       }

       int result = 0;
       while(left <= right) {
           mid = (left + right) / 2;
           int cnt = 0; // 과자를 나눴을 때 과자의 개수
           for (int i = 0; i < N; i++) {
               cnt = cnt + lenarr[i] / mid;
           }
           
// 이 부분에서 조쿰 오류가 났었다
//           if (cnt < M) { // 조카 수 < 과자 수 (과자 길이 중어야함)
//               right = mid - 1;
//           } else if (cnt > M){ // 조카 수 > 과자 수 (과자 기링 늘려도 됌)
//               left = mid + 1;
//           } else {
//               break;
//           }

//개선된 코드
           if(cnt < M) {
               right = mid - 1;
           } else {
               result = mid;// 조건 만족하긴 하지만 더 크게 만족하는 값을 찾기 위해
               left = mid + 1;
           }
       }

       System.out.println(result);


    }


}

- 풀고 나서 보니까 테스트 케이스에서 답이 어떤것은 맞고 틀렸다..

- 조건문에서 아무래도 조건만 맞는다고 끝이 아니라 결국 더 큰 값을 만족해야하기 떄문에 mid값을 보관하고 한번 더 탐색해서 더 만족하는 값을 구할 수 있게 했다. 

1. 구현 이유 

현재 사이드 프로젝트를 진행하면서 spring boot 백엔드를 맡고 있다. 

현재까지의 인프라는 aws rds로 디비 관리를 하고 있고, ec2 + git action 로 cicd를 구현해 git branch의 dev 브랜치에 개발 코드가 병합되면 자동 배포가 되도록 설정했다. 그리고 aws route 53으로 도메인까지 설정을 완료한 단계이다. 

거의 프로젝트의 기능 구현은 완성이 마무리 되고 있는 단계에서 https 설정하는 역할을 맡게 되었다. 

항상 이 부분은 다른 분들이 해봐서 이 설정을 하는 것에 꼼꼼히 알지는 못했다. 

그래서 처음할떄 꼼꼼히 알아보고 해보고 싶어 기록을 한다. 

2. HTTPS란 ? 

http(HyperText Transfer Protocol) ? 

: 웹에서 데이터를 주고 받기 위한 비보안 통신 프로토콜이다. 

- 클라이언트와 서버간 요청과 응답을 통해 html, json, 이미지 등 다양한 형식의 데이터를 주고받는다. 

- 기본적으로 80번 포트를 사용한다. 

- http는 데이터를 평문(암호화 전 상태)으로 전송하기 때문에 중간에 사용자의 데이터를 가로채거나 쉽게 노출될 가능성이 있다. ! 

- 그리고 우리가 좀 고도화된 서비스를 이용할때 http로만 된것을 사용하면 api 서비스가 제한될 가능성도 매우 높다 

예를 들어 위치정보 api, 카메라, 마이크 사용, 백그라운드 작업을 도와주는 서비스 워커, Oauth(외부 인증)같은 서비스도 http 에서는 제한이 된다. 무엇보다 브라우저에서 http 사이트에 대해 주의 요함, 안전하지 않음 메시지를 표시하기에 사용자 신뢰도가 하락되며 위조 사이트로 오해받을 수 있다는 점이다. 

그럼 언제 개발단계에서 https를 쓰는게 좋을까..?

- 초기 단계에서는 로컬에서 http로 작업해도 좋지만 외부 api, oauth, 결제, 미디어 접근 같은 고도화된 기능들을 사용할 떄는 개발환경부터 https 적용을 권장한다고 한다. 

-  나도 지금 파이어베이스 fcm(알림) 기능을 구현하면서 프론트 - 백 연동 과정에서 테스트를 할때 막힘없이 하기 위해 지금 하는 것도 있다.. ㅎ

https (HyperText Transfer Protocal Secure) ? (http Secure/Http over SSL)

: http에 보안계층(ssl/tls) 암호화를 추가한 보안 프로토콜이다.  

- 데이터를 주고 받기 전에 암호화된 통신 채널을 만들고 나서, 그 채널을 통해 데이터가 전달된다. 

- 사용자가 브라우저로 웹사이트에 접속할 때 데이터가 암호화되어 전송하기 때문에 중간에 도청이나 위번조를 방지할 수 있다. 

- 기본적으로 443 포트를 사용한다. 

- 주소창에 https:// 로 시작하게 되며 자물쇠 아이콘이 뜬다 ㅎ이로서 사용자가 안심하고 사용하며 신뢰성을 높일 수 있다. 

- seo 향상 : 구글도 https로 적용된 사이트를 더 우선적으로 보여준다. 

- 암호화과정으로 약간 느릴 수 있다. (비해 http가 약간 더 빠르다고 하는데 잘 모르겠다)

- 프론트 같은 경우는 api 호출 시 https가 아니면 브라우저가 막을 수 도 있다. 

https의 동작 원리 (ssl/tls 과정) 

1. 클라이언트가 서버에게 요청 : 사용자가 "https://example쏼라쏼라.com"에 접속 

2. 서버가 인증서(SSL 인증서)를 보낸다. : 서버는 자신이 신뢰할 수 있는 서버라는 걸 증명하기 위해 디지털 인증서를 보낸다. 

3. 클라이언트가 인증서 유효성 확인 : 브라우저는ㄴ 인증서의 유효성을 검증한다(발급기관, 유효기간, 도메인 일치 등)

4. 대칭키 생성을 위한 공개키 암호화 : 클라이언트는 임의의 대칭키(세션 키)를 생성하고 서버의 공개키로 그 대칭키를 암호화해서 서버로 전송한다. 

5. 서버는 비밀키로 복호화 : 서버는 자신의 비밀키로 그 암호화된 대칭키를 복호화하다. 이제 양쪽은 동일한 대칭키를 공유하게 된 것이다.

6. 데이터 암호화 통신 시작 : 이후부터 클라이언트와 서버는 공유된 대칭키로 데이터를 주고 받는다. 

3. Nginx ? 

가볍고 빠른 고성능 웹서버,,, 단순히 웹 서버 역할을 넘어서 리버스 프록시 , 로드 밸러스, 캐시 서버로 활용된다는 것,,,

웹 서버(web server) 

사용자의 요청(http)을 받아서 정적인 리소스(html, css, 이미지 등)를 직접 클라이언트에게 전달해주는 프로그램.

사용자가 https://example.com/index.html 을 요청하면 -> 웹 서버가 index.html 파일을 찾아서 사용자에게 직접 응답한다

대표적으로 아파치, nginx, 등등 

- 클라이언트에게 직접 응답 

- 정적파일들이 리소스 

- index.html 서빙

리버스 프록시 서버 (Reverse Proxy Server)

중간에 있는 서버로 사용자의 요청을 받아서 실제 백엔드서버로 전달하고 백엔드가 처리한 응답을 다시 사용자에게 중계하는 역할이라고 생각하면 된다. (클라이언트 요청을 받아 백엔드 서버에 전달 & 응답 중계)

사용자가 https://example.com/login 요청 -> nginx가 먼저 요청을 받고 -> 내부에 있는 스프링 서버(localhost:8080)으로 넘김 -> 스프링 서버가 로그인 처리 후 응답 -> nginx가 그 응답을 다시 사용자에게 전달 

- 클라이언트 요청을 대신 처리 

- 동적 처리 백엔드와 연결이 리소스

- /login 요청 -> spring 서버에 전달 : 앞단에서 대신 요청을 받아서 뒤에 숨어있는 백엔드 서버에 전달해주는 중간자 역할

로드 밸런서 : 여러 서버에 트래픽을 균등하게 분산 

https 처리 : ssl 인증서를 설치해서 https 종단점을 제공

캐시 서버 : 자주 요청 되는 리소스르 미리 저장해 빠르게 저장 

왜 Nginx가 필요할까? 

위에서 말한 두가지를 모두 할 수 있다

1. 웹 서버와 백엔드 분리 

스프링 서버는 8080 포트로 일반적으로 구성된다. 하지만 우리가 도메인을 연결하고 싶은 것은 80(http), 443(https)포트이다. 

여기서 nginx가 중간에서 요청을 받아 스프링 서버에 전달해준다. 

2. https를 쉽게 구성 가능 

nginx에 ssl 인증서 설정만 하면 바로 https지원이 가능하다 

3. 부하 분산 

여러 백엔드 서버가 있다면 요청을 나눠 줄 수도 있다. 

과정 

1. 도메인에 ssl 인증서를 연결 : https를 사용하려면 ssl/tls 인증서가 필요하다. 이 인증서를 통해 "내 도메인은 신뢰해"를 증명

  - 인증서는 보통 Let's Encrypt같은 무료 기관에서 발급받고, Nginx에 설정한다. 

2. 443 포트로 들어온 https 요청 : 클라이언트는 https:domain.com으로 접속하는데 이 요청은 443포트로 들어와 nginx가 리스닝중

3. nginx가 받아서 ssl 암호화 해제 (복호화) : 클라이언트는 인증서의 공개키로 암호화된 요청을 보낸다. niginx는 설정된 개인키를 이용해 복호화를 진행한다. (암호화된 Https ->평문http 전환)  "ssl termination", "offloading" 이라고 부른다고 한다. 

4. 내부 서버(spring)에 http로 전달 : 복호화된 평문 요청은 내부 백엔드 서버로 http 프로토콜로 전달된다. -> 이게 위에서의 리버시 프록시 역할이다 (여기서 nginx는 실제 백엔드 서버의 존재를 숨기고 대신 통신을 중계) -> 스프링 서버가 서비스 로직을 처리 후 응답을 다시 nginx에 전달

5. 응답도 다시 브라우저에 https 전달 : 응답을 받은 nginx는 클라이언트에게 https형식으로 암호화해서 전달한다. 이때도 인증서를 이용

브라우저 <-> Nginx : https(암호화된 통신 )

Nginx <-> Spring : http(내부 평문 통신)

Nginx : 암호해제 + 프록시 역할 

.

.

이렇게 되면 백엔드 서버는 Https 처리 안해도 되고, 설정이 간단해지면서 nginx로 ssl 인증서 관리, https 연결, 포트 오픈 등의 모든걸 전담한다. 

4. 설정 

1. ec2 서버에 nginx 설치 

- nginx(웹 서버 역할), ec2(내 서비스가 돌아가는 컴터), nginx설치 (이 서버가 https 요청을 처리할 수 있게 준비하는 과정

- ec2 서버가 웹 서버가 역할을 하기 위함

- ssl 인증서는 nginx 설치된 ec2 서버에 발급 및 설정하면 된다. 

sudo apt install nginx //설치
sudo systemctl status nginx // 설치 확인

2. ec2 인바운드 규칙 확인 80, 443, 22 포트 열어두기 

3. Nginx Proxy 설정 

설정 파일 열고 

sudo nano /etc/nginx/sites-available/default

도메인은 이미 route53에서 설정해줬던 도메인 넣어주면 된다. 

그리고 아래처럼 테스트 했을 때 ok 가 뜨면 끝

sudo nginx -t

4. Cerbot 설치 

sudo apt install certbot python3-certbot-nginx

참고로 여기서 보이는 python3은 프로젝트가 spring이랑은 아무 상관이 없다 ! 

나도 엥 왜 파이썬? 이랬는데 의미없음.

5. SSL 발급 

sudo certbot --nginx -d api.recipic.shop

하면 이메일 같은거 입력하고 약관 동의 yes 하면 끝난다!!

그리고 기존에 사용했던 스웨거에 https 들어가보면 정상적으로 접속이 된다 !

1. 구현 동기 

현재 냉장고 관리를 주제로 사이드 프로젝트를 진행하면서 냉장고 안에 재료들이 유통기한이 임박할 때 알림을 해주는 기능을 구현하고자 했다. 

그리고 나 같은 경우는 앱프로젝트가 아니라 웹 기반 구현이기 때문에 처음에 초기 fcm 설정할 때만 웹일 경우는 조금 다르게 해야했다. 

환경은 spring boot , jpa, react를 사용하고 있고 개발 버전을 공유하기 위해 gitaction으로 cicd가 개발 버전으로 자동 배포가 되어 있는 상태다. 이때 겪었던 트러블 슈팅도 기록하겠다. 

2. 이론 

2.1 FCM (Firebase Cloud Messaging) 이란? 

구글에서 제공하는 무료 푸시 메시징 서비스이다. 

웹, 앱 등 다양한 플랫폼에서 서버-> 클라이언트로 알림 메시지를 전송할게 해준다. 

- fcm token : fcm 서버가 특정 기기(브라우저 또는 앱) 으로 알림을 보내기 위해 사용하는 고유 식별자이다. 집 주소처럼 이 토큰을 활용해서 해당 디바이스로 메시지를 전달한다고 생각하면 된다. 이 토큰은 유효기간이 바뀔 수 있어서 재발급이 가능하다. 

발급 후에 디비의 멤버 테이블에 저장해서 알림을 보낼때마다 사용할 것이다. 

- 포그라운드 : 사용자가 앱을 현재 열고 있는 상태로 쉽게 생각하면 이미 사용자가 웹사이트를 보고 있는 상태라고 생가하면 된다. 

이때는 onMessage() 방식으로 처리하면 된다. 리액트 앱에서 직접 알림을 처리하면 된다. 

- 백그라운드 : 앱이 열려 있지 않거나 꺼져있는 상태이다. 비활성화 상태에서는 firebase-messaging-sw.js로 서비스 워커를 통해 브라우저가 자체적으로 알림을 띄워준다. 

- 서비스 워커 : 브라우저에 등록되어 있는 백그라운드 작업자 스크립트로 앱이 꺼져 있어도 알림을 받을 수 있게 한다. 

2.2 구조

1. 클라이언트가 접속하면 

2. 리액트 서버에서 파이어베이스에게 해당 브라우저에 고유 fcm 토큰을 요청한다. 

3. 토큰이 발급되면 스프링 백엔드 서버로 토큰을 전송하고 

4. 백엔드에서는 알림을 보낼려고 하는 시점들을 서비스 로직을 구현하고 

5. 알림을 보내고 싶을 때 firebase에게 요청을 한다. 

6. firebase는 백엔드가 요청한 fcm 토큰을 가지고 해당 디바이스에게 알림을 전송해준다. 

3. 구현 

일단 파이어베이스 콘솔에서 프로젝트를 추가하고 웹 앱을 등록해줘야 한다. 

앱등록하는 방법은 검색해보면 잘 나와있고 그냥 너무 간단해서 넘긴다. 

3.1 fcm 토큰을 발급받기 (react)

- VAPID 키 : fcm은 웹 푸시 알림을 위해 브라우저와 통신하는데 이때 vapidkey라는 공개키를 요구한다. 

처음에는 안보일 수도 있는데 이때는 Generate Key pair 를 눌러 인증서를 생성하면 된다. 

프론트에서 토큰 발급할 때 필요한 것 

파이어베이스 프로젝트 설정 - 클라우드 메시징

서비스 워커 설정 이 파일은 꼭 public/ 폴더 아래 경로에 있어야 된다고 한다. 

이 초기화 코드들을 파이어베이스 설정에서 일반 탭에 가면 초기화 코드를 볼 수 가 있다. 

firebase-messaging.tsx 

import { initializeApp } from "firebase/app";
import { getMessaging, getToken } from "firebase/messaging";

const firebaseConfig = {
  apiKey: "",
  authDomain: "",
  projectId: "",
  storageBucket: "",
  messagingSenderId: "",
  appId: "",
  measurementId: "",
};

const app = initializeApp(firebaseConfig);
const messaging = getMessaging(app);

export const requestFcmToken = async () => {
  try {
    const permission = await Notification.requestPermission();
    if (permission !== "granted") {
      console.log("알림 권한 거부됨");
      return null;
    }

    const token = await getToken(messaging, {
      vapidKey:
        " 아까 파이어베이스에서 발급 받은 키 넣으삼",
    });

    console.log("✅ FCM 토큰:", token);
    return token;
  } catch (error) {
    console.error("❌ FCM 토큰 발급 실패", error);
    return null;
  }
};

App.tsx

import React, { useEffect } from "react";
import { requestFcmToken } from "./firebase-messaging";
import { getMessaging, onMessage } from "firebase/messaging";
import { initializeApp } from "firebase/app";

function App() {
  const firebaseConfig = {
    apiKey: "",
    authDomain: "",
    projectId: "",
    storageBucket: "",
    messagingSenderId: "",
    appId: "",
    measurementId: "",
  };

  // Firebase 앱 & 메시징 초기화
  const app = initializeApp(firebaseConfig);
  const messaging = getMessaging(app);

  // 포그라운드 메시지 수신 핸들러 등록
  useEffect(() => {
    onMessage(messaging, (payload) => {
      console.log("📩 포그라운드 메시지 수신:", payload);

      if (payload.notification) {
        const { title, body } = payload.notification;
        new Notification(title ?? "알림", { body: body ?? "" });
      }
    });
  }, [messaging]);

  // FCM 토큰 발급 버튼 동작
  const handleGetToken = async () => {
    const token = await requestFcmToken();
    if (token) {
      alert(`FCM 토큰:\n${token}`);
    }
  };

  return (
    <div style={{ padding: 20 }}>
      <h1>📬 FCM 테스트 앱</h1>
      <button onClick={handleGetToken}>FCM 토큰 받기</button>
    </div>
  );
}

export default App;

이렇게 두가지 코드로 테스트를 진행했다. 

.

.

.

결과 버튼을 누르면 내 브라우저에 토큰이 잘 넘어온게 보인다

3.2  fcm 토큰 브라우저에 알람 보내기 

설정 

1. 백엔드에서도 env 환경변수 추가한다.

2. 의존성 추가 

implementation 'com.google.firebase:firebase-admin:9.2.0'

3. firebase 콘솔에서 서비스 계정 키를 다운해야한다. 

설정 - 서비스 게정 - 새키 발급 

serviceAccountKey.json 이 파일이 다운로드가 되는데 

src/main/resources/firebase/ 경로 밑에 넣어주면 된다. 

FirebaseConfig.java : sdk 초기화, env에 저장된 환경변수 설정 등을 한다. 

package njb.recipe.global.config;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import jakarta.annotation.PostConstruct;
import lombok.extern.slf4j.Slf4j;
import org.springframework.context.annotation.Configuration;
import io.github.cdimascio.dotenv.Dotenv;

import java.io.ByteArrayInputStream;
import java.io.IOException;

@Slf4j
@Configuration
public class FirebaseConfig {

    @PostConstruct
    public void initialize() {
        try {
            Dotenv dotenv = Dotenv.configure().directory("./").load();

            String privateKey = dotenv.get("FIREBASE_PRIVATE_KEY");
            if (privateKey != null) {
                privateKey = privateKey.replace("\\n", "\n");
            } else {
                log.error("❌ FIREBASE_PRIVATE_KEY is not set in .env file");
                return;
            }

            String clientEmail = dotenv.get("FIREBASE_CLIENT_EMAIL");
            if (clientEmail == null) {
                log.error("❌ FIREBASE_CLIENT_EMAIL is not set in .env file");
                return;
            }

            String projectId = dotenv.get("FIREBASE_PROJECT_ID");
            if (projectId == null) {
                log.error("❌ FIREBASE_PROJECT_ID is not set in .env file");
                return;
            }

            String serviceAccountJson = String.format(
                "{\n" +
                "  \"type\": \"service_account\",\n" +
                "  \"project_id\": \"%s\",\n" +
                "  \"private_key_id\": \"%s\",\n" +
                "  \"private_key\": \"%s\",\n" +
                "  \"client_email\": \"%s\",\n" +
                "  \"client_id\": \"%s\",\n" +
                "  \"auth_uri\": \"%s\",\n" +
                "  \"token_uri\": \"%s\",\n" +
                "  \"auth_provider_x509_cert_url\": \"%s\",\n" +
                "  \"client_x509_cert_url\": \"%s\"\n" +
                "}",
                projectId,
                dotenv.get("FIREBASE_PRIVATE_KEY_ID"),
                privateKey,
                clientEmail,
                dotenv.get("FIREBASE_CLIENT_ID"),
                dotenv.get("FIREBASE_AUTH_URI"),
                dotenv.get("FIREBASE_TOKEN_URI"),
                dotenv.get("FIREBASE_AUTH_PROVIDER_X509_CERT_URL"),
                dotenv.get("FIREBASE_CLIENT_X509_CERT_URL")
            );


            FirebaseOptions options = FirebaseOptions.builder()
                .setCredentials(GoogleCredentials.fromStream(new ByteArrayInputStream(serviceAccountJson.getBytes())))
                .setProjectId(projectId)
                .build();

            if (FirebaseApp.getApps().isEmpty()) {
                FirebaseApp.initializeApp(options);
                log.info("✅ Firebase SDK initialized successfully");
            } else {
                log.info("ℹ️ Firebase SDK already initialized");
            }
        } catch (IOException e) {
            log.error("❌ Firebase SDK initialization failed: {}", e.getMessage(), e);
        } catch (Exception e) {
            log.error("❌ Unexpected error during Firebase SDK initialization: {}", e.getMessage(), e);
        }
    }
}

FcmController.java

package njb.recipe.controller;

import njb.recipe.dto.token.FcmNotificationRequestDTO;
import njb.recipe.dto.token.FcmTokenRequestDTO;
import njb.recipe.global.jwt.CustomUserDetails;
import njb.recipe.service.FcmService;
import njb.recipe.service.MemberService;
import org.springframework.http.ResponseEntity;
import org.springframework.security.core.annotation.AuthenticationPrincipal;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/fcm")
public class FcmController {

    private final MemberService memberService;
    private final FcmService fcmService;

    public FcmController(MemberService memberService, FcmService fcmService) {
        this.memberService = memberService;
        this.fcmService = fcmService;
    }
// 여기는 fcm token 을 저장하는 부분
    @PutMapping("/token")
    public ResponseEntity<String> updateFcmToken(@AuthenticationPrincipal CustomUserDetails userDetails, @RequestBody FcmTokenRequestDTO fcmToken) {
        String memberId = userDetails.getMemberId();
        memberService.updateFcmToken(memberId, fcmToken);
        return ResponseEntity.ok("FCM token updated successfully");
    }
// 알림 요청
    @PostMapping("/send-test-notification")
    public ResponseEntity<String> sendTestNotification(@RequestBody FcmNotificationRequestDTO request) {
        return fcmService.sendNotification(request);
    }
}

fcm token을 리액트에서 받으면 디비에 저장하는 부분은 따로 설명안하겠다. 그냥 받으면 멤버 엔티티에 넣어주면 된다. 

DTO

package njb.recipe.dto.token;

public class FcmNotificationRequestDTO {
    private String fcmToken;
    private String title;
    private String body;

    // 생성자
    public FcmNotificationRequestDTO(String fcmToken, String title, String body) {
        this.fcmToken = fcmToken;
        this.title = title;
        this.body = body;
    }

    // 기본 생성자 추가
    public FcmNotificationRequestDTO() {
        // 필드 초기화가 필요하다면 여기에 추가
    }

    // Getter 및 Setter
    public String getFcmToken() {
        return fcmToken;
    }

    public void setFcmToken(String fcmToken) {
        this.fcmToken = fcmToken;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getBody() {
        return body;
    }

    public void setBody(String body) {
        this.body = body;
    }
}

FcmService.java

package njb.recipe.service;

import com.google.firebase.messaging.FirebaseMessaging;
import com.google.firebase.messaging.Message;
import com.google.firebase.messaging.Notification;
import com.google.firebase.messaging.FirebaseMessagingException;
import com.google.firebase.messaging.MessagingErrorCode;

import njb.recipe.dto.token.FcmNotificationRequestDTO;

import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Service;
import lombok.extern.slf4j.Slf4j;

@Service
@Slf4j
public class FcmService {
    // fcm에게 푸시 전송

    public ResponseEntity<String> sendNotification(FcmNotificationRequestDTO request) {
        // 메시지 구성
        Message message = Message.builder()
            .setToken(request.getFcmToken())
            .setNotification(Notification.builder()
                .setTitle(request.getTitle())
                .setBody(request.getBody())
                .build())
            .build();

        try {
            // 메시지 전송
            String response = FirebaseMessaging.getInstance().send(message);
            log.info("Fcm 푸시 전송 성공: {}", response);
            return ResponseEntity.ok("Fcm 푸시 전송 성공: " + response);
        } catch (FirebaseMessagingException e) {
            String errorMessage = "Fcm 푸시 전송 실패: " + e.getMessage();
            if (e.getMessagingErrorCode() == MessagingErrorCode.INVALID_ARGUMENT) {
                errorMessage = "유효하지 않은 FCM 토큰: " + request.getFcmToken();
                log.error(errorMessage);
                return ResponseEntity.status(400).body(errorMessage);
            }
            log.error(errorMessage, e);
            return ResponseEntity.status(500).body(errorMessage);
        } catch (Exception e) {
            String errorMessage = "Fcm 푸시 전송 실패: " + e.getMessage();
            log.error(errorMessage, e);
            return ResponseEntity.status(500).body(errorMessage);
        }
    }
}

여기서는 fcm 코드가 유효한지 체크하는 것도 넣어줬다 

.

.

.

테스트 

dto 형식으로 스웨거든 api 테스트 할 수 있는걸로 뭐든 하면 된다. 

브라우저에 알림이 온걸 확인할 수 있다...!!!!

4. 트러블 슈팅 

4.1 git action ci/cd 중에 오류 

나는 개발 버전을 자동화된 배포를 해놓고 개발을 하고 있다. 

그래서 개발한 것을 dev 브랜치에 올리면 개발 버전이 자동 배포가 된다. 

문제는 gitaction에서 파이어베이스 env 환경 변수를 설정할때 오류가 났었다. 

아 뭐가 문제였냐면.....git action에서 환경변수 값들을 secrets 키에 넣어줄 떄 바로 아래 키가 문제였다. 

이 키 같은 경우는 파이어베이스에서는 "" 쌍따옴표까지 같이 들어가야하고 줄바꿈 \n도 같이 들어가야 한다. 

근데 단순히 복붙해서 gitaction secrets 키 안에 넣으니 인코딩 이슈로 문제가 났었다. 

그래서 해결 방법은 base64로 인코딩 해서 넣은 후 git action 빌드할 때 필요한 워크플로우 파일에서 다시 base64를 해석하는 방식으로 했다. 그러니까 다행히 저 쌍따옴표와 줄바꿈 이슈는 해결이 됐다 

echo "📦 Decoding FIREBASE_PRIVATE_KEY from base64..."
            echo '${{ secrets.FIREBASE_PRIVATE_KEY }}' | base64 -d > decoded_key.pem
            ENCODED_KEY=$(cat decoded_key.pem | sed ':a;N;$!ba;s/\n/\\n/g')
            echo FIREBASE_PRIVATE_KEY="$ENCODED_KEY" >> .env
            rm decoded_key.pem

이 코드다... 이렇게 워크플로우 파일을 수정해서 해결했다 ㅠㅠ

4.2  갑자기 키 오류..?

POST https://fcm.googleapis.com/v1/projects/njbproject-39407/messages:send
{
  "error": {
    "code": 404,
    "message": "Requested entity was not found.",
    "status": "NOT_FOUND",
    "details": [
      {
        "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError",
        "errorCode": "UNREGISTERED"
      }
    ]
  }
}

알림 요청을 했을때 파이어베이스에서 키가 유효하지 않다며 404에러가 났었다

홀리 ... 이게 뭔가 했다...

삽질 끝에 알게 된 것은,,, 내가 프론트에서 fcm 토큰을 요청을 할때 로컬 3000번 포트로 처음에 요청을 해서 토큰을 받았었다. 

근데 잠시 다른 프로젝트 서버 열어볼 일이 있어서 그  프론트 서버를 3000번으로 열고 해당 fcm 테스트용 프론트 서버를 3001로 열었었다. 그러니까 fcm토큰이 기존에 받았던거랑 다르게 날라왔었다. 

그냥 아무 생각없이 다른 토큰으로 요청을 해보니까 이런 오류가 난것이다.. 

결론은 프론트 서버 포트를 동일하게 유지해야만 디바이스에 해당하는 fcm 토큰이 유효한 것이 넘어온다는 것..? 인거 같다

아무튼 문제는 해결됐으니 다행이다...