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

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 토큰이 유효한 것이 넘어온다는 것..? 인거 같다

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

오늘의 학습 키워드 : 투포인터 

1. 문제 : 백준 2559 수열 

2. 내 풀이 

1. 일단 n, k 입력 받고 n이 전체 수열의 크기만큼 배열 정해서 입력받았다. 

2. i를 플래그 기준으로 범위만큼의 값의 누적합을 비교하는 방식을 사용하려고 했다. 

but, 생각해보니 i를 기준으로 k 범위만큼의 합을 구할때 만약 k범위 안에 값이 입력받은 배열의 범위를 벗어나면 어쩌지? 

그래서 범위만큼을 더 할 때 범위를 벗어나면 누적합을 구하는 루프를 break로 벗어나게 했다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class CT0404 {

    public static void main(String[] args) throws IOException{
       //온도를 측정한 전체 날짜 수 2 <= n <= 100,000
        //합을 구하기 위한 연속적인 날짜 수  1 <= k <= n

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());
        int k = Integer.parseInt(st.nextToken());
        int max = Integer.MIN_VALUE;

        st = new StringTokenizer(br.readLine());
        int[] temperarr = new int[n];
        for (int i=0; i<n; i++) {
            temperarr[i] = Integer.parseInt(st.nextToken()); // n크기 만큼 온도 배열 입력받기
        }


        for(int i=0; i<n; i++) {
            int sum = 0;
            for(int j=0; j<k; j++) {
                // 연속된 날짜 수
                if(i + j >= n) break;
                sum += temperarr[i+j];
            }
            max = Math.max(max, sum);
        }

        System.out.println(max);
    }
}

.

.

.

.

시간 초과다

3. 다른 풀이 

3.1  슬라이딩 윈도우를 적용한 코드 

 // 1. 처음 k일의 합 구하기
        int sum = 0;
        for (int i = 0; i < k; i++) {
            sum += temperarr[i];
        }

        int max = sum;

 // 2. 슬라이딩 윈도우로 합 갱신
        for (int i = k; i < n; i++) {
            sum = sum - temperarr[i - k] + temperarr[i];
            max = Math.max(max, sum);
        }

슬라이딩 윈도우 : 고정된 크기의 윈도우(구간)를 배열 위에서 한칸씩 이동시키켜 계산하는 방법

여기의 핵심 아이디어는 처음 k구간 sum으로 계산 후 -> sum - arr[왼쪽 끝] + arr[오른쪽 새 원소] 

방식으로 고정 크기의 윈도우를 유지하며 합의 값을 구하는 방식이었다. 

슬라이딩 윈도우를 사용해야 하는 상황 

- 배열에서 고정된 길이의 최대/최소 합 구하기 

- 문자열에서 고정된 길이의 패턴 찾기 

3.2 투 포인터를 적용한 코드 

int start = 0, end = 0, sum = 0;
int max = Integer.MIN_VALUE;

while (end < n) {
     sum += temperarr[end]; // end가 가리키는 값 추가

     // 현재 구간이 k개일 때
     if (end - start + 1 == k) {
          max = Math.max(max, sum);
          sum -= temperarr[start]; // start가 가리키는 값 제거
          start++; // 구간 시작점 앞으로 이동
     }
	end++; // 끝 포인터 이동
}

투 포인터 : 두개의 포인터(인덱스)를 사용해서  조건을 만족하는 부분 구간을 탐색하는 알고리즘 , 슬라이딩 윈도우와 비슷하지만 조건을 만족하는 '가변 길이' 구간을 찾을 때 유용하다. 

시작포인트와 끝 포인트를 같게 한다.

일단 마지막 포인터 (end)를 기준으로 while 루프를 돌린다. 이때 n을 넘지 않게 조건을 줘서 처음 내가 코드를 작성했을때 고려했던 부분이 여기에 반영이 됐다. 

그리고 구간이 성립이 될때만 시작 포인트를 옆으로 이동, 아니면 구간 성립(또는 구간 확장 - 다음 구간 이동의미)을 위한 끝 포인트 이동하는 방식이다. 이렇게 해서 누적합의 최대값을 구한다. 

4. 회고

단순히 맞는게 중요한게 아니라 시간 복잡도를 따지는게 어렵다 생각의 확장이 필요하다

1. ci/cd 파이프라인이란

CI/CD(Continuous Integration/Continuous Deployment) 파이프라인은 코드 변경 사항을 자동으로 빌드, 테스트, 배포하는 과정을 의미한다.

1.1 CI(Continuous Integration, 지속적 통합)

• 개발자가 코드를 변경하면 이를 자동으로 빌드하고 테스트하는 과정을 의미하며, 작은 코드 변경을 자주 통합하여 코드 충돌을 줄이고, 버그를 조기에 발견하는 것이 목표다.
• CI에서는 코드가 push될 때 테스트를 실행하여 코드의 안정성을 검증한다.

1.2 CD(Continuous Deployment 또는 Continuous Delivery, 지속적 배포)

• Continuous Deployment (지속적 배포) : 코드 변경 사항이 자동으로 테스트를 거친 후, 자동으로 운영 서버(Production)에 배포되는 과정, 코드 변경이 검증되면 별도의 수동 승인 없이 배포된다.
• Continuous Delivery (지속적 제공) : 코드 변경 사항이 자동으로 준비되지만, 최종 배포는 사람이 승인하는 방식입니다.

CI/CD는 개발자가 코드를 변경하면 자동으로 테스트하고 배포하여, 더 빠르고 안정적인 배포 환경을 구축하는 것이 목표이다. 

지금 나는 실제 배포 버전이 아닌 개발버전에서의 cicd를 구축하는 과정에 있다. 개발 과정에서는 자주 변경되는 코드들을 쉽게 홥치고 이를 바로 프론트엔드와 공유를 용이하게 하기 위해 개발용cicd를 구축하고 있다. 

2. ci/cd 파이프라인의 구성 요소 

2.1 workflow(워크플로우)

ci/cd의 전체적인 작업 흐름을 정의하는 자동화된 프로세스이다. 

github에 올려놓은 레포지토리에 .github/flows/ 폴더 아래에 yml 파일을 작성해 작업흐름을 만들면 된다.

워크플로우는 특정 이벤트가 발생했을 때 실행된다

2.2 event (이벤트)

워크플로우가 실행하는 트리거(trigger, 실행조건) 이다. 

예를 들어 우리는 ci/cd 환경을 구축하는 것이기에 코드 변경사항을 푸시해서 올렸다고 가정해보자. 그럼 새로운 변경사항으로 이벤트가 발생한 것이다. 이처럼 워크플로우가 실행되는 '이벤트' 그 자체라고 생각하면 될 듯 하다. 

대표적인 이벤트는 아래 같은 걸들..?

• push → 코드가 특정 브랜치로 푸시되었을 때 실행
• pull_request → PR이 열리거나 병합될 때 실행
• schedule → 정해진 시간마다 실행 (예: 매일 자정에 실행)
• workflow_dispatch → 수동으로 실행
• release → 새로운 릴리즈가 생성될 때 실행

2.3 job (잡)

; 한 개의 워크플로우는 여러개의 잡(job, 작업단위)로 구성될 수 있다. 잡은 순차적(병렬)으로 처리된다. 

워크플로우에서 이벤트에 따라 처리하는 작업들을 정의하는 것으로 job끼리는 의존관계도 가질 수 있다(선행으로 어떤거 할지 .. 이런거)

2.4 step (스텝)

: 잡 내에서 실행되는 개발 작업으로 이 step은 shell 에서 동작하는 cli와 동일하게 실행된다. 정의한 step 순서대로 실행되며 step 데이터를 공유할 수도 있다. 

2.5 runner(러너) , Artifact(아티팩트)

러너는 github actions에서 워크플로우를 실행하는 서버로 github에서 제공해주는 클라우드 러너를 사용하거나 ec2같은 셀프호스티드 러너도 설정할 수 있다(참고로 내가 쓴 ec2는 러너 방식이 아니다! 프로젝트 정책에 따라 알아서 잘 하면 될듯) 

아티팩트는 cicd 과정에서 생성된 빌드 파일, 로그 등을 저장하는 기능이다. 

3. ci/cd 흐름

3.1 흐름 

1. 개발자가 github에 코드를 push  : dev 브랜치에 코드가 푸시 

2. github action이 실행 : workflows폴더 안에 만든 yml 파일에 정의된 작업이 1번의 푸시 작업으로 인한 이벤트를 감지하고 자동으로 실행된다. 

3.github actions가 ec2에 ssh로 접속하여 배포한다. : ec2 설정할때 가져온 ssh 비밀키를 github action에 환경변수로 넣어줌으로서 접속이 가능해진다. 

4. ec2 서버에서 애플리케이션 실행 (즉 ec2는 github actions에서 배포된 최신 애플리케이션이 실행되는 서버라고 생각하면 된다) 

3.2 ec2 생성, ssh로 접속할 것 

ssh로 안하면 중간에 빌드 오류가 났었던거 같다

1편에서 aws ec2를 일단 구축했다

https://dev-leeyjstar.tistory.com/entry/ec2-git-action-%EA%B0%9C%EB%B0%9C-%EB%B2%84%EC%A0%84-cicd-%ED%94%84%EB%A6%AC%ED%8B%B0%EC%96%B4-ec2-%EC%83%9D%EC%84%B1-1

https://dev-leeyjstar.tistory.com/entry/%ED%8A%B8%EB%9F%AC%EB%B8%94-%EC%8A%88%ED%8C%85-ec2-ssh-%EC%A0%91%EC%86%8D-%EC%98%A4%EB%A5%98-Permission-denied-publickey

4. github 설정 

4.1 env 환경변수 설정

프로젝트를 진행하면 레포에 올라가지 않는 .env 파일안에 환경변수들을 넣어줘야한다. 

setting - secrets and variableds 탭 - actions 항목에 본인의 env 환경변수들을 넣어준다. 

참고로 레포는 본인 레포여야만 settings를 할 수있다. 협력자나 그런건 환경변수를 적용할 수 없다 

4.2 ssh 키 생성 

github actions가 ec2에 접속할 수 있도록 새로운 ssh 키를 생성하고 github에 등록을 해야한다!!

일단 ec2 서버에 ssh 로 접속해서 들어온다. 

ssh-keygen -t rsa -b 4096 -f ~/.ssh/github_deploy -N ""

• -t rsa: RSA 알고리즘 사용
• -b 4096: 4096비트 길이의 키 생성
• -f ~/.ssh/github_deploy: 키 파일을 ~/.ssh/github_deploy 로 저장
• -N "": 패스프레이즈 없이 생성

이제 2개의 파일이 생성됨:

• ~/.ssh/github_deploy (🔒 개인 키)
• ~/.ssh/github_deploy.pub (🔑 공개 키)

공개키를 ec2의 authorized_keys에 추가한다(github actions의 접속을 허용해주는 것)

cat ~/.ssh/github_deploy.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

• ~/.ssh/github_deploy.pub 내용을 ~/.ssh/authorized_keys에 추가 → EC2에서 SSH 접근을 허용
• chmod 600 ~/.ssh/authorized_keys → 보안 강화를 위해 권한 설정

ec2에서 생성한 개인키(github_deploy)를 github에 등록해야한다. 그럼 이 키를 github actions가 ec2에 ssh로 접속할 때 사용하게 되는 것이다. 

ubuntu@ip-000-00-00-00:~cat ~/.ssh/github_deploy
-----BEGIN OPENSSH PRIVATE KEY-----
.
.
.
.
-----END OPENSSH PRIVATE KEY-----

b

저 명령어를 하면 아래와 같이 begin으로 시작해서 end로 끝나는 키가 출력되는데 이 키를 github의 환경변수로 넣어주면 된다.

엄청 중요한거....! 저거 그대로 다 복사해야한다...! ---- Begin 부터 End의 ---- 이거까지 다 복사해서 넣어야 된다는 점을 매우 중요\

난 이걸로 엄청 삽질했다 아무리 해도 안되길래 ㅠㅠ

아무튼 env 환경변수들을 넣어준 곳에 EC2_SSH_KEY 라는 이름으로 저 키를 넣어주면 끝난다. 

5. workflow yml 파일 생성 

레포 - actions 탭에서 - 파란색 "set up a workflow yourself " 누르면 yml 파일 생성할 수 있는데 여기서 워크플로우를 만들어주면 된다. 

name: Deploy to EC2                                       # 워크플로우 이름: "Deploy to EC2"

on:
  push:
    branches:
      - dev                                             # 'dev' 브랜치에 push될 때 실행

jobs:
  deploy:                                               # 'deploy' 작업 정의 (EC2 배포 작업)
    runs-on: ubuntu-latest                              # 최신 Ubuntu 환경에서 실행

    env:                                                # 환경변수 설정 (GitHub Secrets에서 값을 가져옴)
      JWT_ACCESS_EXPIRATION: ${{ secrets.JWT_ACCESS_EXPIRATION }}  # 액세스 토큰 만료 시간
      JWT_REFRESH_EXPIRATION: ${{ secrets.JWT_REFRESH_EXPIRATION }}  # 리프레시 토큰 만료 시간
      JWT_SECRET: ${{ secrets.JWT_SECRET }}                          # JWT 암호화에 사용되는 비밀키
      MAIL_USERNAME: ${{ secrets.MAIL_USERNAME }}                    # 메일 서비스 사용자 이름
      MAIL_PASSWORD: ${{ secrets.MAIL_PASSWORD }}                    # 메일 서비스 비밀번호
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}                  # OpenAI API 키
      LOCAL_DB_URL: ${{ secrets.LOCAL_DB_URL }}                      # 로컬 데이터베이스 URL
      LOCAL_DB_USERNAME: ${{ secrets.LOCAL_DB_USERNAME }}            # 로컬 데이터베이스 사용자 이름
      LOCAL_DB_PASSWORD: ${{ secrets.LOCAL_DB_PASSWORD }}            # 로컬 데이터베이스 비밀번호
      GOOGLE_CLIENT_ID: ${{ secrets.GOOGLE_CLIENT_ID }}                # 구글 OAuth 클라이언트 ID
      GOOGLE_CLIENT_SECRET: ${{ secrets.GOOGLE_CLIENT_SECRET }}        # 구글 OAuth 클라이언트 비밀키
      KAKAO_CLIENT_ID: ${{ secrets.KAKAO_CLIENT_ID }}                  # 카카오 OAuth 클라이언트 ID
      KAKAO_CLIENT_SECRET: ${{ secrets.KAKAO_CLIENT_SECRET }}          # 카카오 OAuth 클라이언트 비밀키
      NAVER_CLIENT_ID: ${{ secrets.NAVER_CLIENT_ID }}                  # 네이버 OAuth 클라이언트 ID
      NAVER_CLIENT_SECRET: ${{ secrets.NAVER_CLIENT_SECRET }}          # 네이버 OAuth 클라이언트 비밀키

    steps:
      - name: 📥 Checkout source code                  # 소스 코드 체크아웃 단계
        uses: actions/checkout@v3                       # GitHub 제공 checkout 액션 사용

      - name: 🛠 Setup JDK 17                           # JDK 17 설정 단계
        uses: actions/setup-java@v3                      # GitHub 제공 setup-java 액션 사용
        with:
          distribution: 'temurin'                      # Temurin 배포판 선택
          java-version: '17'                           # Java 버전 17 사용

      - name: 📦 Build with Gradle (Skip Tests)         # Gradle 빌드 단계 (테스트는 건너뜀)
        run: |
          chmod +x gradlew                             # gradlew에 실행 권한 부여
          ./gradlew clean build -x test                # 테스트 건너뛰고 클린 빌드 실행
          echo "🔍 Checking build/libs/ directory..."   # 빌드 결과물 디렉토리 확인 메시지 출력
          ls -lh build/libs/ || exit 1                  # build/libs/ 디렉토리 내용 확인, 없으면 종료

          # 'plain'이 포함되지 않은 첫 번째 JAR 파일을 선택하여 변수에 저장
          JAR_FILE=$(ls build/libs/*.jar | grep -v 'plain' | head -n 1)
          if [[ -z "$JAR_FILE" ]]; then                # JAR 파일이 없으면 에러 메시지 출력 후 종료
            echo "🚨 No valid JAR file found in build/libs/. Build failed!"
            exit 1
          fi

          # JAR 파일 크기 확인 (10MB 이상이어야 함)
          FILE_SIZE=$(stat --format=%s "$JAR_FILE" 2>/dev/null || stat -f%z "$JAR_FILE")
          if [[ $FILE_SIZE -lt 10485760 ]]; then        # 파일 크기가 10MB 미만이면 빌드 실패 처리
            echo "🚨 JAR file size is too small ($FILE_SIZE bytes). Build failed!"
            exit 1
          fi

          echo "✅ JAR file found: $JAR_FILE ($FILE_SIZE bytes)"  # 유효한 JAR 파일 확인 메시지 출력

      - name: ✅ Run Tests (Optional, Allow Failure)   # 테스트 실행 단계 (실패해도 계속 진행)
        continue-on-error: true                         # 테스트 실패 시에도 다음 단계로 진행
        run: |
          ./gradlew test                               # 프로젝트 테스트 실행

      - name: 🏗 Setup SSH Key                          # SSH 키 설정 단계
        run: |
          echo "${{ secrets.EC2_SSH_KEY }}" > private_key.pem  # GitHub Secrets에서 EC2 SSH 키를 파일로 저장
          chmod 400 private_key.pem                      # SSH 키 파일의 권한을 읽기 전용(400)으로 설정

      - name: 🔍 Test SSH Connection                    # SSH 연결 테스트 단계
        run: |
          ssh -o StrictHostKeyChecking=no -i private_key.pem ubuntu@"본인 ip" "echo '✅ SSH connection successful!'"  # EC2 서버에 SSH 연결 후 성공 메시지 출력

      - name: 📂 Transfer JAR file to EC2               # 빌드된 JAR 파일을 EC2로 전송하는 단계
        run: |
          JAR_FILE=$(ls build/libs/*.jar | grep -v 'plain' | head -n 1)  # 유효한 JAR 파일을 다시 선택하여 변수에 저장
          scp -i private_key.pem "$JAR_FILE" ubuntu@"본인 ip":~/app/spring-boot-app.jar  # SCP를 사용하여 JAR 파일 전송

      - name: 🚀 Deploy to EC2                          # EC2에 배포 및 실행 단계
        run: |
          ssh -o StrictHostKeyChecking=no -i private_key.pem ubuntu@"본인 ip" <<EOF
            echo "📂 Checking and creating app directory..."  # 애플리케이션 디렉토리 확인 및 생성 메시지 출력
            mkdir -p ~/app                                     # ~/app 디렉토리 생성 (이미 있으면 무시)
            cd ~/app                                           # 작업 디렉토리를 ~/app으로 변경

            echo "📝 Creating .env file on EC2..."             # EC2에서 .env 파일 생성 시작 메시지 출력
            echo "JWT_ACCESS_EXPIRATION=$JWT_ACCESS_EXPIRATION" > .env  # .env 파일에 각 환경변수 저장 (덮어쓰기)
            echo "JWT_REFRESH_EXPIRATION=$JWT_REFRESH_EXPIRATION" >> .env
            echo "JWT_SECRET=$JWT_SECRET" >> .env
            echo "MAIL_USERNAME=$MAIL_USERNAME" >> .env
            echo "MAIL_PASSWORD=$MAIL_PASSWORD" >> .env
            echo "OPENAI_API_KEY=$OPENAI_API_KEY" >> .env

            echo "LOCAL_DB_URL=$LOCAL_DB_URL" >> .env
            echo "LOCAL_DB_USERNAME=$LOCAL_DB_USERNAME" >> .env
            echo "LOCAL_DB_PASSWORD=$LOCAL_DB_PASSWORD" >> .env

            echo "GOOGLE_CLIENT_ID=$GOOGLE_CLIENT_ID" >> .env
            echo "GOOGLE_CLIENT_SECRET=$GOOGLE_CLIENT_SECRET" >> .env
            echo "KAKAO_CLIENT_ID=$KAKAO_CLIENT_ID" >> .env
            echo "KAKAO_CLIENT_SECRET=$KAKAO_CLIENT_SECRET" >> .env
            echo "NAVER_CLIENT_ID=$NAVER_CLIENT_ID" >> .env
            echo "NAVER_CLIENT_SECRET=$NAVER_CLIENT_SECRET" >> .env

            echo "🔍 Checking .env file on EC2..."           # 생성된 .env 파일 내용 확인 메시지 출력
            cat .env                                          # .env 파일 내용 출력

            echo "🔄 Exporting environment variables from .env"  # .env 파일의 환경변수 내보내기 시작
            set -o allexport                                  # 모든 변수를 자동으로 환경변수로 내보내도록 설정
            source .env                                       # .env 파일의 변수들을 현재 셸에 적용
            set +o allexport                                  # 자동 내보내기 옵션 해제

            echo "🔍 Checking if a Java application is running..."  # 기존 실행 중인 애플리케이션 확인 메시지 출력
            RUNNING_PID=\$(pgrep -f 'spring-boot-app.jar' || true)  # 실행 중인 spring-boot-app.jar 프로세스 PID 검색
            if [[ ! -z "\$RUNNING_PID" ]]; then               # 기존 애플리케이션이 실행 중이면
              echo "🚀 Stopping previous application..."      # 기존 애플리케이션 종료 메시지 출력
              kill -9 "\$RUNNING_PID"                         # 강제 종료
            fi

            echo "📦 Deploying new application..."           # 새 애플리케이션 배포 시작 메시지 출력
            nohup java -jar spring-boot-app.jar > log.txt 2>&1 &  # 백그라운드에서 새 애플리케이션 실행 (로그는 log.txt에 저장)

            echo "✅ Deployment complete. Checking application logs..."  # 배포 완료 후 로그 확인 메시지 출력
            sleep 5                                          # 애플리케이션 실행 대기 (5초)
            tail -n 20 log.txt                               # log.txt 파일의 마지막 20줄 출력하여 상태 확인
          EOF                                               # 원격 SSH 세션 종료 표시

나 같은 경우는 설정을 최대한 간단하게 하고 싶어서 ci, cd를 하나의 파이프라인으로 실행을 했다. 

빌드와 배포까지 바로 이루어지기에 개발자 개입없이 자동으로 최신 버전이 배포가 된다. 운영서버까지 바로 할수 있다. 

하지만 배포 안정성이 낮아질 수 있고 테스트가 실패되면 배포가 중단 될 가능성이 있다. 그래서 ci, cd를 분리하는 게 안정성을 따지면 좋을 거 같다 하지만 난 실제 서비스 운영이 아니고 일단 개발용이고 하니 최대한 간단하고 빠르게 하고 싶어 통합해서 사용했다 

yml 파일에 만든 워크 플로우로 잡안에 있는 스텝들이 순차적으로 잘 실행되어 올바르게 실행된 것을 볼 수 있다. 

초록색으로 잘 뜨면 ec2 서버에서도 확인해보자 

.jar 프로세스가 정상 실행중이라고 한다 ㅎㅎ