[뽀둥이 AX ③] 벡터 임베딩, 만들어보고 껐습니다

📝 한줄 요약

기억이 수백 장이 되니 "필요한 한 장"을 꺼내는 게 진짜 문제가 됐어요. 요즘 많이 쓰는 벡터 임베딩 검색을 실제로 만들어 붙이고 정확도를 재봤는데, 저희 문서에서는 기존 방식보다 낮게 나와서 껐어요. 지금 뽀둥이의 검색은 임베딩 없이 다섯 가지 신호를 RRF로 합쳐 돌아가요.

바쁘시면 이것만:

검색 정확도를 잴 골든셋(golden set)을 먼저 만들고, 그다음에 방법을 골랐어요
2026년 6월 실험에서 벡터 임베딩 41% vs BM25 + 제목 매칭 66% — 측정값이 그대로 결정이 됐어요
지금은 BM25·recency·그래프·제목·usage 다섯 신호를 점수가 아니라 순위로 합쳐요
검색이 망가진 사고 두 번 다 원인은 "내용"이 아니라 파일 수정 시각이었어요

📝 지난 이야기, 그리고 이번 주제

②편에서는 뽀둥이의 기억이 사는 집을 봤어요. 책상(자동 로드)·서랍(최근 14일)·창고(보관)의 3층에 별동 2개(교훈 카드·매뉴얼 위키) 구조요. 기록이 쌓이는 자리를 정해줬더니 다음 문제가 바로 따라왔어요.

"쌓아둔 건 좋은데, 필요할 때 그 한 장을 어떻게 꺼내지?"

지금 뽀둥이의 검색이 훑는 문서는 424개예요(2026년 8월 18일 기준). 이 중에 지금 이 대화에 필요한 서너 장만 골라 와야 해요. 이번 편 핵심 주제는 그거 하나, 검색이에요. 그리고 이 편에는 자랑보다 실패가 더 많이 나와요. 저희가 요즘 많이 쓰는 방법을 만들어놓고 껐거든요.

🗺️ 뽀둥이의 메모리 지식구조 한눈에 보기

처음 오신 분을 위한 30초 지도예요. 매 편 상단에 이 지도를 똑같이 두고, 그 편에서 다루는 곳에 ★를 찍어둘게요. 뽀둥이의 기억은 전부 폴더 속 텍스트 파일이고, 크게 여섯 부분이 맞물려 돌아가요.

책상 (자동 로드 문서) — 매 대화 시작 때 자동으로 읽는 정체성·규칙·현재 요약본·최근 기록 (②편)
서랍·창고 (일별 기록·아카이브) — 하루하루의 작업과 실패 기록, 14일 지나면 자동 보관 (②편)
교훈 카드 + 매뉴얼 위키 — 사고의 교훈을 담은 카드와, 반복 검증된 정본 규칙 (①·②편)
검색 엔진 ★ — 수백 장 기억에서 필요한 것만 골라 꺼내는 색인·검색 (③편)
안전장치 (게이트) — 자동화가 사고 치지 않게 막는 검증·잠금·롤백 (①·④편)
지식그래프 — 이 모든 연결을 한 장으로 보여주는 공개 지도 (⑤편)

이번 ③편은 ★ 찍힌 4번, 검색 엔진을 통째로 다뤄요.

🎬 장면: 엉뚱한 문서를 물어온 날

8월 초 어느 날이었어요. 뽀둥이한테 파트너스 제도 관련 규칙을 찾아달라고 했더니 전혀 상관없는 발송 규칙 문서를 1순위로 물어왔어요. 다른 질문에서도 비슷했어요. 토큰 절약 도구를 물었는데 3위에 디자인 규칙 문서가 끼어 있었고요.

이상해서 두 문서의 공통점을 찾아봤어요. 내용이 겹치는 것도 아니고 링크로 이어진 것도 아니었어요. 공통점은 딱 하나였어요.

둘 다 그날 제가 수정한 파일이었어요.

검색 품질이 "오늘 내가 뭘 편집했나"에 따라 매일 출렁이고 있었던 거예요. 어떤 날은 잘 찾고 어떤 날은 못 찾는데, 그 이유가 문서 내용과 아무 상관이 없었어요.

🤔 그런데 왜 검색을 직접 만들어야 했을까

솔직히 처음엔 검색을 따로 만들 생각이 없었어요. ②편에서 본 것처럼 뽀둥이의 기억은 전부 폴더 속 텍스트 파일이라, 필요하면 파일 이름으로 찾거나 단어로 훑으면 될 줄 알았거든요.

그런데 세 가지 벽에 차례로 부딪혔어요.

첫째, 매번 전부 읽힐 수는 없어요. ①편에서 말한 컨텍스트 윈도우(context window), AI가 한 번에 읽을 수 있는 양은 한정돼 있어요. 문서가 424개인데 이걸 다 올리면 정작 오늘 할 일을 담을 자리가 없어요. "찾아서 그것만"이 아니면 구조 자체가 성립을 안 해요.

둘째, 단어가 정확히 겹쳐야만 찾혀요. 제가 "메일 보내기 전에 뭐 확인하지?"라고 물었을 때 문서에는 "발송 전 검증"이라고 적혀 있으면요. 사람은 같은 말인 걸 아는데, 단어를 그대로 맞춰보는 방식은 이걸 못 찾아요.

셋째, 가장 중요한 게 위로 안 와요. 단어가 겹치는 문서가 30개 나오는 건 안 찾는 것만큼이나 쓸모없어요. 뒤로 밀린 문서는 결국 안 읽히니까요. "찾기"보다 "줄 세우기"가 진짜 문제였어요.

검색을 만들기로 하고, 만들기 전에 한 가지를 먼저 했어요. 이게 이번 편에서 가장 중요한 부분이에요.

📏 방법을 고르기 전에 골든셋부터 만들었어요

검색을 만들 때 흔한 함정이 "좋아 보이는 방법을 먼저 고르는 것"이에요. 저희는 순서를 뒤집었어요. 뭘 쓸지 정하기 전에, 잘하는지 채점할 방법부터 만들었어요.

실제 업무에서 나올 법한 질문과 그 질문에 나와야 하는 정답 문서를 짝지어 목록으로 만들어요. "메일 보내기 전에 점검하는 습관" 하면 발송 규칙 문서가 나와야 한다는 식으로요. 이렇게 정답이 정해진 평가용 질문 묶음을 골든셋(golden set)이라고 불러요. 지금까지 53개를 모았어요(8월 18일 기준).

채점 기준도 하나로 못 박았어요. 상위 3개 안에 정답이 들어 있나, 검색 평가에서 흔히 쓰는 hit@3 지표예요. 아래로 밀린 문서는 실제로 잘 안 읽히니까 품질 기준선을 여기에 뒀어요.

이 53건은 튜닝할 때 폭넓게 재보는 평가용이에요. 그리고 이것과 별개로, 초기에 만든 12문항을 코드에 따로 고정해 회귀 게이트로 써요. 검색 결과에 기대어 스스로 파일을 고치는 자동 적용 작업이 돌기 전에 이 12문항을 돌리고, 7개 미만이면 그 작업을 막아요. 평가용은 넓게 보고, 게이트는 절대 안 바뀌는 고정 문항으로 좁게 지키는 구조예요.

골든셋이 생기니 그다음부터는 논쟁이 필요 없었어요. 방법 A와 방법 B 중에 뭐가 좋냐를 두고 얘기할 게 아니라, 둘 다 돌려보고 hit@3을 비교하면 되니까요. 이 회귀 게이트는 검색만 지키는 게 아니에요. 점수가 기준선 아래로 떨어지면, 검색 결과에 기대어 스스로 파일을 고치는 자동 적용 작업이 멈춰요(④편에서 자세히 다뤄요).

🧪 많이 쓰는 방법을 직접 만들어보고 껐어요

요즘 AI 검색이라고 하면 벡터 임베딩(vector embedding)이 대표적인 선택지예요. 글의 의미를 숫자 목록(벡터)으로 바꿔서, 비슷한 의미끼리 가까운 자리에 놓는 방식이에요. 이러면 "메일"과 "이메일"처럼 단어가 달라도 의미가 비슷하면 찾아지죠. 앞에서 말한 둘째 벽을 정면으로 푸는 방법이에요.

당연히 이걸 써야 한다고 생각해서 만들었어요. 2026년 6월에, 인터넷 연결이나 외부 유료 서비스 없이 노트북 안에서만 도는 가벼운 임베딩 모델을 붙였어요. 그때 있던 문서를 전부 벡터로 바꿔놓고 골든셋을 돌렸죠. 당시 골든셋은 지금보다 작은 12문항이었어요.

결과가 예상과 달랐어요.

벡터 임베딩만 썼을 때 hit@3: 41%
기존 BM25 + 제목 매칭: 66%

한참 들여다봤어요. 제 해석은 이래요. 뽀둥이의 문서는 제가 직접 쓰고 다듬은 한국어 실무 문서예요. "발송내역", "리워드 검수", "게이트" 같은 구체적인 용어가 정확히 그 자리에 박혀 있어요. 이런 글에서는 의미를 뭉뚱그려 비슷한 걸 찾는 방식보다 단어를 정확히 맞춰보는 방식이 잘 맞았던 것 같아요. 다만 이건 결과를 보고 붙인 제 해석이지, 원인을 따로 분리해서 실험한 건 아니에요. 확실한 건 점수 차이 하나예요.

한 가지는 분명히 해둘게요. 임베딩이 나쁘다는 뜻이 전혀 아니에요. 문서가 훨씬 많아지거나 여러 사람이 제각각 다른 표현으로 쓴 글이 쌓이면 결과가 뒤집힐 수도 있다고 봐요. 이건 저희가 재본 게 아니라 가설이고요. 그래서 코드는 지우지 않고 켤 수 있는 형태로 남겨뒀어요. 지금은 임베딩 모델도 안 깔려 있고 변환해둔 벡터도 없어서 실제 신호는 완전히 꺼진 상태고, 다시 쓰려면 모델 설치부터 해야 해요.

💡 여기서 배운 것 — 많이 쓰는 방법을 안 쓴 게 아니라, 만들어서 재보고 껐어요. 저희 문서·저희 질문에서는 hit@3 기준 41% 대 66%였고요. 이 숫자가 없었으면 저희도 그냥 남들 하는 대로 갔을 거예요. 직접 재봤기 때문에, 저희 문서에 안 맞는 방법을 계속 쓰는 일을 피할 수 있었어요.

🔎 그래서 지금은: 다섯 신호를 RRF로 합쳐요

임베딩을 끄고 나니 남은 질문은 하나였어요. 단어만 보는 검색으로 어떻게 정확도를 올릴까. 답은 "다른 관점의 신호를 여러 개 붙이는 것"이었어요. 지금 뽀둥이는 문서 하나를 볼 때 다섯 가지를 따로 재고, 그 다섯 개의 판단을 마지막에 합쳐요. 하나씩 왜 생겼는지 볼게요.

신호 1. BM25 — 문제: 흔한 말이 다 걸린다 → 해결: 드문 단어에 무게를 준다

"발송"처럼 여기저기 나오는 말로 검색하면 절반이 걸려요. 흔한 단어는 낮게, 드문 단어는 높게 쳐서 점수를 매기는 계산법이 필요한데, 검색엔진들이 오래 써온 표준이 BM25예요. 단어를 그대로 맞춰본다고 해서 렉시컬(lexical) 검색이라고도 불러요. 이게 기본 축이에요.

신호 2. recency — 문제: "어제 그거"를 못 찾는다 → 해결: 최근 문서를 앞으로, 단 약하게

실무 질문의 상당수가 "어제 그거", "지난주 그 건"이에요. 그래서 최근에 손댄 문서를 조금 앞에 두는 신호를 넣었어요. 최신성을 뜻하는 recency라고 불러요. 다만 일부러 약하게 눌러놨는데, 앞의 장면에서 본 그 사고 때문이에요. 자세한 얘기는 아래에서 할게요.

신호 3. 그래프 — 문제: 어느 게 중요한 문서인지 모른다 → 해결: 들어오는 링크를 센다

뽀둥이 문서끼리는 서로 링크로 이어져 있어요. 그 문서를 가리키는 링크, 즉 인바운드 링크(inbound link)를 세면 "여기저기서 참조되는 문서"가 드러나요. 웹에서 링크를 많이 받는 페이지가 중요한 페이지인 것과 같은 원리예요.

신호 4. 제목 매칭 — 문제: 본문에 스친 말이 과대평가된다 → 해결: 제목 일치를 따로 센다

본문 어딘가에 한 번 나온 단어와 아예 제목에 박힌 단어는 무게가 달라야 하잖아요. 검색어가 제목에 들어 있는지를 별도 신호로 세요. 이 신호 하나를 추가한 게 체감상 가장 컸어요.

신호 5. usage — 문제: 안 쓰는 문서가 계속 올라온다 → 해결: 실제로 꺼내 쓴 기록을 반영

검색 결과로 나와서 실제로 읽힌 기록이 쌓여요. 이 사용 이력을 usage 신호로 반영해 자주 쓰이는 문서를 조금 올려줘요. 쓸수록 잘 찾아지는 셈이죠. 다만 기록이 너무 적을 때는 아예 끄게 해뒀어요. 표본이 적으면 "자주 쓰는 문서"가 아니라 "우연히 몇 번 나온 문서"를 밀어올리거든요.

다섯을 합치는 법 — 문제: 점수 단위가 제각각 → 해결: 점수 대신 순위를 합친다

여기서 중요한 선택이 하나 있었어요. 다섯 신호를 어떻게 합칠까요?

단순하게는 점수를 다 더하면 돼요. 그런데 신호마다 점수의 척도와 분포가 완전히 달라요. BM25는 문서마다 값이 크게 벌어지는데 recency는 0과 1 사이에 몰려 있거든요. 원점수를 그대로 더하면 범위가 큰 신호가 나머지를 다 먹어요. 범위를 맞추는 정규화를 거쳐 더하는 방법도 있지만 저희는 다른 쪽을 택했어요.

각 신호가 자기 기준으로 등수를 매기게 하고 그 등수를 합쳐요. 여러 신호에서 고르게 상위권인 문서가 최종 상위로 올라오는 방식이에요. 이걸 RRF(Reciprocal Rank Fusion)라고 불러요. 점수 단위를 억지로 환산하지 않아도 된다는 게 큰 장점이에요.

다만 순위로 합친다고 안전해지는 건 아니에요. 어떤 신호가 잘못된 순위를 내면 그 잘못이 그대로 최종 결과에 섞여 들어와요. 바로 다음에 나올 사고 두 건이 정확히 그 경우였고, 그래서 신호마다 가중치를 다르게 주고 골든셋으로 계속 감시해요.

신호마다 가중치가 달라요

다섯 신호를 동등하게 취급하지 않아요. 지금 가중치는 이렇게 잡혀 있어요.

BM25 1.0 · 그래프 1.0 · usage 1.0
제목 매칭 1.1 (가장 세게)
recency 0.3 (가장 약하게)

recency만 유독 낮죠. 이 값도 감이 아니라 측정에서 나왔어요. 2026년 8월 8일에 가중치를 바꿔가며 당시 골든셋 50문항으로 재본 hit@3이에요.

recency를 BM25와 동등하게(1.0) 두면: 28%
절반(0.5)으로 낮추면: 34%
0.3으로 낮추면: 40%
아예 끄면(0.0): 40%

여기서 재밌는 건 마지막이에요. 꺼도 40%로 똑같아요. 그럼 끄면 되지 않냐 싶은데 안 껐어요. 점수가 더 오르지도 않는데 기능 하나를 통째로 없앨 이유는 없다고 봤거든요. 다만 솔직히 말하면, recency를 껐을 때 "어제 그거" 같은 질문이 실제로 얼마나 나빠지는지는 따로 재보지 않았어요. 전체 hit@3이 같다는 것까지만 확인하고 0.3을 남긴 거예요.

💡 여기서 배운 것 — 신호를 더 넣는 것보다 중요한 게 신호마다 가중치를 정하는 일이었어요. 그리고 가중치를 정하려면 골든셋이 먼저 있어야 해요. 잴 방법이 없으면 가중치는 결국 취향 싸움이 되거든요.

📊 이 구조가 바꾼 것 — Before vs After

Before — 검색 엔진이 없을 때는:

필요한 문서 경로를 사람이 알려주거나, AI가 폴더를 헤매야 함
문서가 늘수록 "있는데 못 찾는 기억"이 같이 늘어남
검색이 잘 되는지 나쁜지를 판단할 기준 자체가 없음
방법을 바꿔도 좋아졌는지 나빠졌는지 모름

After — 다섯 신호 RRF 뒤에는:

문서 424개에서 상위 몇 개만 골라 꺼내옴, 인덱스는 30분마다 자동 갱신
고정 회귀 게이트 12문항 — hit@3이 7 미만이면 검색 기반 자동 적용 작업이 정지
방법 선택이 토론이 아니라 측정으로 결정됨 (임베딩 기각이 그 결과)
외부 서비스·유료 API 없이 노트북 안에서 전부 처리

숫자마다 잰 시점이 달라서 표시해뒀어요. 문서 424개·골든셋 53문항·인덱스 22MB는 8월 18일 현재 스냅샷이고, 임베딩 41% 대 66%는 6월 실험(12문항), recency 가중치 비교는 8월 8일(50문항) 값이에요. hit@3은 저희 문서·저희 질문으로 잰 값이라 다른 곳에서 그대로 나온다는 뜻은 아니에요. "검색 속도 몇 % 개선" 같은 수치는 이번에도 안 썼어요. 재본 적이 없거든요.

😫 부딪힌 것들 — 검색을 두 번 망가뜨린 건 내용이 아니었어요

브랜치 정리 한 번에 자동 작업이 통째로 멈췄어요

7월 10일의 일이에요. 코드 작업하다가 다 쓴 git 브랜치 네 개를 정리했어요. 파일 내용은 하나도 안 바뀌었고요.

그런데 다음 날 아침, 뽀둥이가 스스로 파일을 고치던 자동 적용 작업들이 조용히 차단돼 있었어요.

원인을 따라가 보니 이랬어요. 브랜치를 정리하면 내용이 안 바뀐 파일도 수정 시각(mtime)이 "방금"으로 갱신돼요. 그게 190개였어요. recency 신호가 이걸 그대로 믿고 순위를 뒤집었고, hit@3이 12문항 중 8개 맞히던 게 6개로 떨어졌어요. 기준선이 7개였거든요.

그런데 이 골든셋은 자동 작업의 안전장치로도 쓰이고 있었어요(④편에서 자세히 다뤄요). 점수가 기준선 아래니까 안전장치가 "지금은 검색을 믿을 수 없다"고 판단하고, 검색 결과에 기대어 스스로 파일을 고치는 그 작업들을 막아버린 거죠. 사람이 직접 하는 작업이나 다른 자동화까지 멈춘 건 아니에요.

무서웠던 건 저절로 낫지 않는다는 점이었어요. RRF는 등수로 합치는 방식이라 시간이 지나도 그대로거든요. 로그를 파보기 전에는 아무도 몰랐어요.

지금은 브랜치를 전환하면 mtime을 원래대로 되돌리는 훅이 자동으로 돌아요. 증상이 아니라 원인 지점을 막았어요.

그리고 8월, 같은 계열이 또

앞의 장면에서 본 그 사고예요. 이번엔 대량 조작도 아니었어요. 평소처럼 파일 두세 개 편집한 것만으로 검색이 출렁였어요. 앞 사고를 겪고도 "그건 브랜치 정리가 문제였지"라고 좁게 이해했던 게 화근이었어요. recency 가중치를 0.3으로 낮춘 게 이때 나온 조치예요.

같은 원인이 다른 규모로 두 번 왔어요. 한 번 고쳤다고 그 계열이 끝난 게 아니더라고요.

아직 못 고친 것 — 한글을 섞으면 영어 단어가 묻혀요

지금도 남아 있는 한계예요. 뽀둥이의 검색은 한국어를 두세 글자씩 잘라서 색인해요. 이렇게 글자를 n개씩 끊어 쪼개는 방식을 n-gram이라고 하는데, 한글 단어 하나가 조각 여러 개로 불어나요. "레지스트리" 하나가 조각 일곱 개가 되는 식으로요.

문제는 영어 이름을 같이 검색할 때예요. 8월 11일에 재본 결과예요.

aitk 만 검색: 1위
aitk 스킬 레지스트리: 4위
aitk 지피터스 AI 툴킷 팀 스킬: 상위 6개 밖

키워드를 더 붙였는데 더 못 찾아요. 영어 단어 하나가 한글 n-gram 아홉 개에 파묻히는 거예요. 문서 본문을 세 배로 늘려도 순위는 그대로였어요.

지금 대응은 솔직히 "그렇게 검색하지 않기"예요. 영어 이름으로 찾을 땐 그것만 넣으라는 규칙을 카드로 남겨뒀어요. 근본 해결은 아직이에요.

💬 이 경험에서 뽑은 팁 3가지

골든셋을 먼저 만드세요 — 방법을 고르기 전에 "잘하는지 어떻게 알지"부터 정하세요. 질문 10개와 정답 문서만 있어도 시작이 돼요. 이게 없으면 모든 개선이 느낌이 되고, 느낌은 남의 말에 집니다.
유행은 후보일 뿐, 정답은 아니에요 — 남들이 다 쓰는 방법이라도 내 데이터에서 재보세요. 저희는 재봤더니 껐어요. 반대로 나올 수도 있고, 그건 재봐야만 알아요.
검색이 이상하면 내용 말고 조건을 의심하세요 — 저희 사고 두 번 다 원인이 문서 내용이 아니라 파일 수정 시각이었어요. RRF 결과는 여러 신호가 섞인 값이라, 엉뚱한 축이 순위를 흔들고 있을 수 있어요.

❓ 이런 게 궁금하실 것 같아요

Q. 그럼 RAG(관련 문서를 먼저 찾아 AI 답변에 넣어주는 방식)나 벡터DB(임베딩 벡터를 저장·검색하는 데이터베이스)는 필요 없다는 건가요?

전혀 아니에요. 저희 규모(문서 424개)에 저희 문서 성격(직접 쓴 한국어 실무 문서)에서 그랬다는 거예요. 문서가 훨씬 많아지거나 여러 사람이 제각각 쓴 글이 섞이면 결과가 바뀔 수 있다고 보는데, 그건 아직 저희가 재본 게 아니라 가설이에요. 하고 싶은 말은 "쓰지 마세요"가 아니라 "쓰기 전에 재보세요"예요.

Q. 골든셋 53문항은 어떻게 만들었나요?

실제로 제가 뽀둥이한테 던졌던 질문에서 뽑았어요. 같은 뜻을 다른 말로 바꾼 것도 같이 넣었고요. "이메일 발송 전 검증 순서"와 "메일 보내기 전에 점검하는 습관"을 둘 다 넣는 식으로요. 표현이 달라도 같은 문서가 나와야 쓸 만한 검색이니까요.

Q. 임베딩을 껐으면 비슷한 말로 검색하면 못 찾는 거 아닌가요?

맞아요. 그게 이 선택의 대가예요. 대신 제목 매칭과 그래프 신호로 상당 부분을 메웠고, 그 조합이 골든셋에서 더 높게 나와서 그쪽을 택했어요. 완벽한 선택이 아니라 재봤을 때 더 나은 쪽을 고른 거예요.

Q. 이 검색 만드는 데 돈이 드나요?

안 들어요. 외부 검색 서비스도 유료 API도 안 써요. 전부 제 노트북 안에서 돌아가고, 어느 문서에 어떤 말이 들어 있는지 미리 정리해둔 목록, 그러니까 인덱스(index, 색인) 파일이 22MB 정도예요. 30분마다 자동으로 다시 만들어지고요.

🚀 다음 편 예고 — ④ 자동화의 안전벨트

이번 편 사고 이야기에서 계속 스쳐 지나간 게 하나 있어요. hit@3이 기준선 아래로 떨어지자 자동 적용 작업이 스스로 멈춰 섰다는 대목이요. 그게 뽀둥이한테 붙어 있는 안전장치예요. 자동화를 어디까지 믿고 맡기는지, 뭘 기준으로 스스로 멈추게 했는지, 실제로 막히고 되돌려진 기록들 — ④편에서 이어갈게요.

📋 재사용 가능한 프롬프트

프롬프트: 내 AI 검색에 골든셋 만들기

내 문서 폴더에서 검색이 잘 되는지 채점할 골든셋을 만들어줘.
① 내가 실제로 자주 묻는 질문 10개를 뽑아
② 각 질문마다 "이 문서가 나와야 정답"인 파일을 지정해
③ 같은 뜻을 다른 표현으로 바꾼 질문도 각각 하나씩 더 추가해
④ 이 목록으로 검색을 돌려서 상위 3개 안에 정답이 든 비율(hit@3)을 계산해줘
앞으로 검색 방식을 바꿀 때마다 이 골든셋을 다시 돌려서 점수를 비교해줘.
점수가 떨어지면 그 변경은 되돌려.

📣 24기 대기자 모집이 시작되었습니다!