홍준기 님의 개발 블로그

복지드림 - RAG 마무리: 청킹 전략 개선

홍준기 — Fri, 12 Jun 2026 14:51:05 +0900

이번에는 기존 단순 오버랩 청킹 전략에서 개선하기 위해서 그냥 서비스를 통째로 청킹하는 것이 아닌 색션 별로 나누어 청킹하는 전략으로 개선해보았다. + 테스트 수정

청킹 전략 개선 - section-aware chunking

위에서 말했다시피 기존에는 단순히 서비스 전체를 오버랩을 두고 청킹하여서 청킹 안에서 여러 색션이 나올 수 있었다.

이렇게 되면 검색할 때 모든 청크를 다 보고 색션이 청크 안에 섞여있으므로 검색 정확도에 안 좋은 영향을 미칠 것이라고 생각하였기에, 청킹 전략을 개선하였다.

따라서 기존 복지 서비스에 있는 색션 별로 나누어서 청킹을 진행하였고, 청크의 개수가 그만큼 늘어났다. 한 청크 안에 여러 색션이 들어가 있는 경우가 대부분인에 이가 나눠졌기 때문이다. 기존 570개 청크에서 2,424개 청크로 늘어났다. 이 과정에서 색션이 나뉘면서 같은 서비스의 여러 청크가 결과를 독점하는 문제가 생겼고, serv_id 기준으로 중복을 제거도 진행했다.

재랭킹할 때도 섹션별로 가중치를 다르게 뒀다. target, criteria는 높게 / application, documents는 낮게. 신청방법만 열심히 설명한 서비스가 상위에 올라오는 걸 막기 위해서다.

검색 정확도 테스트 과정 수정

section-aware 청킹 전략 개선 이후 테스트를 해보는데 이전 테스트로는 얼마나 개선됐는지 제대로 확인이 안 되어서 테스트를 수정했다.

우선 나오는 서비스의 기대 수준을 3가지로 나누었다. 반드시 나와야하는 서비스, 나오면 좋은 서비스, 절대 나오면 안 되는 서비스.

이 수정을 통해서 사용자에게 맞는 서비스를 적절하게 추출하는지 그리고 사용자에게 명백히 맞지 않는 서비스를 추천하지 않는지 제대로 확인할 수 있도록 했다.

결과물

https://youtu.be/1f3tvKRrBN4?si=x_nTF3j9c4RSrl3l

시연 영상

RAG.html

0.07MB

공부할 겸 종프를 신청해서 주제도 완전히 바뀌어버리는 등 생각지 못한 방향으로 프로젝트가 진행됐지만 그 상황에서도 배울 것이 있었던 거 같다. 원래 기존에는 실력 향상을 목적으로 차근차근 종프를 진행해볼 계획이었지만 멘토님과의 회의를 통해 AI를 적극 활용하며 완성도를 더 높이자는 방향으로 갔다. 기술적인 측면보다는 AI 활용 측면에서 느낀 게 많은 거 같다.

AI 활용 후기

사실 지금까지 모든 과정을 내 스스로 생각해서 하지 않았고, 내가 잘 모르던 파트였기에 AI와 함께 대화하면서 진행하는 방식으로 나아갔다. 처음에는 이렇게 AI에게 다 물어보고 나는 확인만 하는 과정이 도움이 될지, 나의 실력 향상이 있을지 의문 투성이었다. 결론적으로는 이번 프로젝트에서는 AI에게 적정치보다 약간 더 의존한 게 있는 거 같다. 멘토님께서도 AI을 활용해서 결과물 퀄리티를 적극적으로 높이라고 하셨기에 열심히 써보았지만, 코드 주도권을 AI에게 조금 빼앗기니 코드 곳곳에 블랙박스가 생겼던 거 같다. 그래도 잘 돌아가긴 하지만 내가 처음하는 부분은 내가 한번 직접 구현해보는 시간을 가지는 게 필요하다고 생각했다. 이후 내가 해당 부분을 잘 알게 된다면 그 부분은 AI를 통해서 빠르게 구현 후 검증 하는 방식으로 넘어가고 내가 집중해야하는 부분에 시간을 더 쏟을 수 있게 하는 것이다. 내 생각에는 이런 방식으로 하는 게 옳은 거 같다. 그렇다고 이번 프로젝트가 실패한 거라곤 말할 수 없을 거 같다. 이렇게 단기간 안에 개괄적으로 RAG를 이해하고 구현할 수 있었던 건 AI가 있었기 때문이다. 다만 학생으로서 학습하는 방식으로는 이렇게 구현에 치중하기보다는 한번은 AI 없이 혼자하는 과정이 필요한 과정이라는 것이다. 물론 이게 종프1과 연계하여 그런 여유를 부릴 시간은 없었다. 앞으로 다음 프로젝트에서는 이 나의 지분과 AI의 지분을 적절히 조화하여 나의 실력 향상과 생산성을 둘다 조화롭게 잡을 정도로 구현해보아야겠다고 느꼈다. 한편으로는 이렇게 AI의 생산성을 보면서, 정말 내가 만들고 싶은 게 있다면 빠르게 결과물을 보고 싶다면 바이브 코딩으로 우선 구현해봐도 될 거 같다. 실력 향상이 아니라 나의 아이디어를 결과물로 빠르게 뽑고 싶을 땐.

복지드림 - RAG 리팩토링: API 필드 개선 및 필터링 로직 추가

홍준기 — Sat, 23 May 2026 16:07:53 +0900

이전 MVP단계까지 구현을 완료한 상태였고 이 글에서는 리팩토링한 내용을 기록해보겠습니다.

MVP 단계에서는 복지서비스 데이터를 일정 길이로 나누고, 오버랩을 둔 청킹 방식으로 ChromaDB에 저장했다. 이 방식으로 검색 API와 상세 조회 API까지 구현했고, 실제 대화 흐름에서 시스템 테스트도 진행해봤다.

리팩토링 필요성

시스템 테스트를 진행해보았는데. 전반적으로 사용자에게 맞는 서비스가 나온 것도 있었지만, 사용자의 status와 완전히 맞지 않는 서비스까지 같이 제공이 되는 문제가 있었다.

테스트 상황을 같이 보면, 사용자 입력 값을 아래와 같이 했다.

- 65년생, 만 61세
- 대구 거주
- 1인 가구
- 사별
- 자녀 없음
- 장애 등록 없음
- 비경제활동
- 저소득

이 조건으로 검색했을 때 다음과 같은 서비스가 추천되었다.

1. 가사·간병 방문 지원사업
2. 독거노인·장애인 응급안전안심서비스
3. 근로·자녀장려금
4. 생계급여
5. 자활근로

모든 반환된 서비스에 문제가 있는 건 아니었다. 그렇지만 일단 문제가 있는 부분은

- 우선 첫 번째로 65년생이지만 아직 만 61세인데 노인 관련 복지 서비스가 포함 됨(아마 65년생이 65세로 인식된 듯 함)

- 자녀가 없는데 자녀 관련 복지 서비스가 추천 됨

이는 사용자의 정보를 토대로 RAG에서 쿼리를 만들어 검색을 한 것이지만, 단순히 단어 검색을 통한 서비스 서치로만 끝내면 이렇게 충돌되는 서비스가 제공될 수 있다는 것이었다. 레그 검색에서 관련도가 있는 서비스를 검색해주고 있지만, 그 관련있는 서비스가 사용자의 조건에 맞는지는 필터링하지 못 하고있는 것이었다.

따라서 검색 결과를 그대로 랭그래프 쪽에 넘기는 건 사용자에게 불쾌한 경험이 될 것이라고 판단했고, 랭그래프 측은 합리적인 서비스라고 가정하고 로직을 실행하기에, 내 레그 쪽에서 로직 기반 필터링을 통해 사용자의 정보와 상반되는 서비스는 걸러내는 로직을 추가했다.

API 응답 필드 변경

기존 API 응답은 score 필드에만 의존하여 서비스를 판별했었는데 이를 개선하기 위해 적합성 관련 필드를 추가했다.

전체적인 로직의 시작은 동일하게 가져가나, 바로 랭그래프 측에 검색 결과를 반환하지 않고 사용자의 정보 기준으로 한번 더 검사한다. 이 과정에서 걸러지는 서비스가 있을 수 있기에 더 많은 서비스를 먼저 검색해서 가져오도록 했다.

검색 API 응답 필드

필드	설명
eligibility_status	사용자 조건 기준으로 충족 가능성 (likely, needs_more_info, unlikely)
eligibility_reasons	판단 이유
missing_fields	판단에 필요한데 사용자에게서 아직 받지 못한 정보
evidence	판단에 사용한 서비스 원문 근거

이 필드들을 바탕으로 사용자 조건과 명백히 충돌하는 서비스는 `unlikely`로 판단하고, 기본 추천 결과에서는 제외했다. 반대로 애매한 경우에는 제외하지 않고 `needs_more_info`로 내려주도록 했다.

상세 API 응답 필드

기존에 application_fields가 있었는데 실제로 해보니 의미가 모호한 거 같아서 이 필드를 제거하고 더 명확한 필드들도 분리했다.

변경	필드	개선
제거	application_fields	의미가 모호해 제거
추가	application_url	복지로 상세 페이지 URLa
추가	application_method	복지로의 신청 방법 원문
추가	application_forms	신청 서식 or 안내문 다운로드 파일들
개선	required_documents	원문에서 구비서류 라벨이 명확한 경우만 추출

여기서 application_forms와 required_documents의 구분이 살짝 헷갈릴 수 있는데 required_documents는 신청 시 필요한 서류 이름들이고, application_forms는 복지로에 있는 신청서식, 안내문, 같은 파일 다운로드 정보다.

필터링 로직

검색 후 사용자의 정보롤 바탕으로 충돌하는 서비스가 있는지 필터링을 진행 후 반환하도록 한다. 이를 토대로 명확히 충돌, 애매함, 충돌하지 않음 이렇게 3가지로 분류 후 충돌하는 건 제외하고, 애매한 건 같이 반환은 하되, 애매한 사유를 같이 제공하도록 했다.

개선 결과

개선 결과 해당 사용자 테스트에서

- 65년생, 만 61세
- 대구 거주
- 1인 가구
- 사별
- 자녀 없음
- 장애 등록 없음
- 비경제활동
- 저소득

1. 가사·간병 방문 지원사업
2. 독거노인·장애인 응급안전안심서비스
3. 근로·자녀장려금
4. 생계급여
5. 자활근로

기존 아웃풋에서 아래처럼 반환되도록 바뀌었다.

순위	서비스	적합성 필드
1	근로·자녀장려금	needs_more_info
2	생계급여(맞춤형 급여)	needs_more_info
3	입원 및 격리치료명령 결핵환자 부양가족생활보호비 지원	needs_more_info
4	차상위본인부담경감대상자지원	likely
5	청년월세 지원사업	needs_more_info

명백히 매치되지 않는 서비스(노인 서비스)를 제거하고 나머지 서비스들은 needs_more_info를 통해서 추가적인 정보를 필요로 한다.

여기서 likely와 needs_more_info 필드의 응답 차이점은

likely는 아래처럼 반환되지만

{
    "eligibility_status": "likely",
    "eligibility_reasons": [],
    "evidence": []
}

needs_more_info는 부족한 정보들과 함께 반환된다.

{
    "eligibility_status": "needs_more_info",
    "eligibility_reasons": [
      "자녀 또는 부양자녀 중심 기준이 있어 자녀 없음 조건 확인이 필요합니다.",
      "근로소득, 사업소득, 자활 또는 구직활동 기준 확인이 필요합니다."
    ],
    "evidence": [
      {
        "field": "slct_crit_cn",
        "text": "근로소득 또는 사업소득 또는 종교인소득이 있는 거주자로서..."
      }
    ]
}

이렇게 명백히 매치되지 않는 서비스는 반환하지 않도록 개선했다.

정리 및 다음 방향

+ 추가로 지금 청킹 전략도 단순한 오버랩 청킹이라서 이 부분도 개선할 예정이다. 복지서비스의 필드 구조를 살리는 section-aware 청킹으로 바꿔볼 예정이다.

이번에는 로직 필터링을 통해 터무니 없는 서비스를 제외시켜보았습니다. 다음에는 검색 정확도 향상을 위해 청킹 전략을 개선해보겠습니다.

카카오테크 캠퍼스 - 4기 Agentic AI 과정 합격

홍준기 — Sat, 9 May 2026 18:05:30 +0900

이번에 카테캠 4기에 지원하였다.

지원 계기

카테캠을 알게 된 이유 중 하나는 올해 초 학교 실리콘밸리 연수 프로그램에서 만난 분들 중 많은 사람들이 카테캠을 했었고, 또 도움이 많이 되었다고 하여 관심을 가지게 되었다.

그래서 커리큘럼과 후기를 보니 나의 성향과 잘 맞을 거 같아서 관심에서 정말 하고싶다라는 생각까지 가게 되었다.

기초를 다진 후 개인 프로젝트를 하며 멘토에게 피드백을 받으며 성장 후 2학기에 팀 프로젝트를 하는 과정이 맘에 들었음.

또한 올해 채울 학점도 얼마 없고 대외 활동을 하는 게 좋았었기에 이번 기회에 도전해보고 되면 열심히 참여해보고 싶었다.

자소서 제출

자소서 항목은 이번엔 다섯 항목이었는데, 웹 과정에서 Agentic AI 과정으로 바뀌었고 이에 한 항목이 추가된 듯하다.

지원 동기, 지원하기 위해 공부한 것, 본인의 강점과 단점, 협업하며 힘들었던 것, 생성형 AI 활용 경험이 있었다.

일반적인 내용보다는 나만의 이야기를 쓰라고 강조를 많이 한다.

추가적으로 노션 등에 기록한 포트폴리오 같은 걸 제출하는 게 가능했는데, 뭐라도 내자 싶어서 자격증, 개발 강의 수료증, 코테 공부 기록, 이전 깃허브 블로그 주소 등을 냈었다. 이 마음까지 닿았는진 모르겠다.

코딩 테스트

4월 15일까지 지원서 제출이어서 그전까지 PCCP 성적을 제출하면 코딩 테스트가 면제될 수 있었지만 이전 PCCP를 합격하지 못해 코딩 테스트를 봐야 했다.

지원서 제출 후 4월 19일에 한번 PCCP를 더 쳐봤는데 코테 만점 면제인 Lv.3을 받았다. 제출 못 한 게 아깝다.

코딩 테스트를 치르게 되었고, 25일 학교에서 쳤다.

기출문제보다 쉽게 나온 듯하긴 했다. PCCP보다 쉬운 난이도였던 거 같다. 그렇다고 다 맞은 건 아닙니다. ㅎ

모든 문제를 다 풀고 테스트 케이스가 맞긴 했는데, 4번 문제는 시간 복잡도를 충족하지 못 한 듯하다. 10^5개의 입력이어서 시간 복잡도가 N^2를 넘으면 안 되는데 스택을 쓰나 이중 반복문 도나 N^2의 풀이만 생각났고 결국 더 효율적인 걸 생각하지 못하고 제출해 버렸다. [주식 가격] 문제랑 비슷한 듯했었는데.

끝나고 찾아보니 단조 스택으로 푸는 문제였다고 한다. 나도 먼가 이런 식으로 풀려고 했던 거 같은데 나는 넣지 말아야 하는 것을 넣어서 반대로 풀려고 했던 거 같다. 좀만 더 깊게 생각해보면 됐었을 거 같기도 하고. 나의 실력 문제 인정한다.

그래서 결과적으로 1, 2, 3번을 풀고 4번은 테스트 케이스만 맞는 정도로 푼 거 같다.

이제 더 이상 나의 힘으로 할 수 있는 건 없기에 그저 기다렸다.

합격 결과

합격 결과가 5월 1일에 나온다고 해서 기다리고 있었고, 전날인 4월 30일에 도서관에 있었는데 갑자기 문자로 합격 여부가 메일로 발송됐다고 와서 놀랐다.

휴 진땀뺐네요

올해 목표 중 자격증은 다 땄고 이제 카테캠 열심히 해야겠다.

카테캠을 하면서 AI 활용 능력뿐만 아니라 기본기를 게을리하지 않고 기르고 싶다.

복지드림 - RAG API 구현 및 나의 하네스 엔지니어링 문제점

홍준기 — Tue, 28 Apr 2026 13:44:40 +0900

이번 글에서는 execute 파일을 실행 후 어떤 문제가 있었는지, 개선이 필요한 점을 알아보고 어떻게 API 개발이 완료됐는지 정리해보겠습니다.

지금 하네스 구조의 문제점

테스트 통과?

실제로 그냥 execute 파일을 실행해 보니까, 그냥 step by step 별로 플랜된 것들을 개발을 할 뿐이지, 발생한 오류는 일반적인 바이브코딩을 통해서 수정을 해야 했다. 지금 프로젝트의 하네스 엔지니어링은 그냥 계획 - 자동화 플랜이었을뿐이고 품질 보증은 되지 않았다. 검증 루프가 존재하지 않았다. 테스트만 했을 뿐이지 불확실성 해결 및 검증을 자동으로 해결해주지는 못했다. 내가 너무 단순화한 하네스 엔지니어링을 구성한 듯.

그리고 하면서 느낀 게 이런 하네스 제약 조건보다 스킬 사용 및 에이전트 구성을 통한 세션 관리를 먼저 배워야겠다고 생각했다. 기본적인 것도 이해하기 전에 그냥 유튜브 및 블로그를 통해서 하네스부터 보니까 제대로 효율이 나오지 않는 거 같다.

+ 그래서 이 프로젝트의 하네스 코드 + everything-claude-code에서 필요한 스킬을 몇 개 뽑아와서 다시 구성해보고 하려고 했는데 내가 클로드 코드에 대한 이해도가 아직 부족해서(에이전트 및 스킬 활용 등) 사용, 활용을 제대로 하지 못하였고 결국 이것도 그냥 크로스 체크 바이브 코딩이 되었다. 따라서 지금은 그냥 기본적인 기능을 잘 활용하는 것으로 하고 기본적인 걸 잘 활용하게 되면 추가로 하네스 엔지니어링까지 알아보는 방향으로 가야할 듯하다.

지금 핫한 하네스 엔지니어링을 막무가내로 구현하기보다는 엔트로픽 아카데미에서 제공하는 클로드 코드 강의를 보고 체계적이고 효율적인 클로드 코드 사용법을 익혀야할 필요성을 몸소 느꼈다. 기본적인 flow를 알아야 응용을 하지. 템트리도 잘 모르고 야스오 EQ궁 연습한 느낌이다. 기본으로 돌아가기를 해서 기교보단 기본 토대를 먼저 탄탄히 잡아야겠다.

클로드 코드 얘기는 여기까지 하고 우리 프로젝트 RAG 구현에 대해 정리해보겠습니다.

MVP 단계에서의 구현

지금 개발된 과정이

복지 서비스 데이터 수집 -> 청킹 -> 임베딩 -> ChromaDB 저장 -> 검색 API / 상세 조회 API 구현이다.

복지 서비스 데이터 수집

Playwright 사용

코드에서 브라우저를 제어할 수 있는 브라우저 자동화 도구. 이번에 처음 써봄. 브라우저 테스트, 크롤링 등을 할 수 있는데 지금 우리는 Python으로 크롤링하는데 사용할 것이다.

복지서비스 목록은 API로 가져왔고 상세 정보도 API로 정보를 가져와 디비를 구성하려고 했지만, 일일 호출 제한으로 모든 복지 서비스를 가져오려면 4일에 걸쳐 가져와야했다. 또한 그냥 HTML으로 가져오려고 하면 복지로는 자바스크립트로 렌더링을 하기 때문에 빈 내용만 온다. 그래서 Playwright로 사람처럼 브라우저에 접근해 데이터를 가져왔다.

청킹(Chunking)

가져온 데이터를 그냥 임베딩 모델에 넣을 수 없다. 그대로 넣기엔 입력 길이 제한이 있고, 검색 효과가 떨어진다. 또한 너무 청크 크기를 작게 한다고 해도 문맥을 파악할 단어가 부족해서 마찬가지로 검색 관련성이 떨어진다. 운영체제의 타임 슬라이스를 설정한다고 보면 될 거 같다.(적정 크기를 찾는 부분에서)

따라서 가져온 데이터에서 메타데이터는 제외하고 의미있는 텍스트를 남겨놓고 청킹을 했다.

오버랩

이후 남겨둔 텍스트를 청크 단위로 자르는데, 이때 겹치는 부분이 있도록(오버랩 되도록) 자른다.

그런데 이런 방법에 의문이 들었다. 어차피 각 청크가 독립적으로 의미를 가져야한다면, 이전 청크와 연결시키는 목적의 오버랩이 아니라면, 그냥 청크의 크기를 늘리는 거랑 오버랩을 만드는 거랑 무슨 차이인 거지? 라고 생각했다.

-> 하지만 이렇게 오버랩을 하면 특정 단어는 오버랩 되어 두 개의 청크에 들어가고 이 단어가 검색이 되면 두 청크에 매칭이 되어 한 청크를 검색하는 것보다 충분한 문맥을 가지며 검색할 수 있다는 것이다. 또한 오버랩을 통해 청크 분리 경계에 걸친 문맥 손실을 방지할 수 있다. 한 문장 그대로가 의미가 있는 문장의 의미 손실을 방지할 수 있다는 것.

하지만 지금의 오버랩 구현은 MVP 수준의 낮은 문맥 보호 구현이고 아래의 두 가지 방식 중 하나로 후에 보정해야할 듯하다.

Sentence-aware chunking

문장 단위로 쪼개서 경계가 항상 문장 끝에 떨어지게 함. 오버랩 없이.

Parent-child chunking

작은 청크로 검색하고 반환할 때는 그 청크가 속한 부모 청크를 반환. 자식으로 검색하여 부모로 반환한다. 정확한 검색과 충분한 문맥의 답변을 챙기는 것.

따라서 한 복지 서비스가 여러 청크로 분리되어 임베딩 후 디비에 저장한다.

임베딩(Embedding)

모델은 한국어 특화 모델 [jhgan/ko-sroberta-multitask]을 사용했다

텍스트를 벡터로 변환하는 과정. 의미가 비슷한 단어는 백터 공간 상 비슷한 위치에 놓이게 된다.

-> 이게 가능한 이유는 딥러닝을 통한 학습임

이렇게 백터화하여 ChromaDB에 저장해놓으면, 검색 시 쿼리도 임베딩을 통해 벡터화하여 쿼리와 가까운 거리에 있는 벡터를 검색하는 것이다.

ChromaDB 저장

오픈 소스에다가 간편한 벡터디비인 ChromaDB를 사용했다. 우리 프로젝트에서는 충분하다고 판단.

API 구현

검색 API - POST /welfare/search

사용자 조건을 넘기면 관련 복지 서비스 top-k 목록을 반환한다.

상세 조회 API - GET /welfare/{serv_id}

검색 결과에서 받은 serv_id를 이용해 해당 서비스의 상세 내용을 조회한다.

LangGraph 쪽에서의 유스케이스 호출 순서

  1. [POST /welfare/search]를 통해 사용자에게 맞는 k개의 복지 서비스 검색
  2. 사용자가 여러 복지 서비스 중 지금 원하는 서비스를 선택하면 응답에서 serv_id 요청
  3. [GET /welfare/{serv_id}] 해당 복지 서비스 상세 정보 반환

search API가 POST 요청인 이유는 URL 파라미터로 사용자 정보를 넘기지 않기 위해서(민감한 개인 정보 관리)

요청과 응답 JSON

POST /welfare/search

  {
    "age": 65,
    "income_level": "저소득",
    "household_size": 1,
    "marital_status": "미혼",
    "has_children": false,
    "disability": false,
    "disability_severity": null,
    "employment_status": "실업",
    "region": "서울",
    "top_k": 5
  }

속성	타입	설명
age(필수)	int	- 복지 서비스는 연령 조건이 매우 중요 - 노인, 청년, 아동, 중장년 등 대상 구분의 기본값
income_level(필수)	string	- 복지 매칭에서 핵심적인 조건 - 허용 값: ["기초생활수급자", "차상위계층", "저소득", "일반"]
household_size	int \| null	- 1인 가구, 다인가구 등 가구 형태를 간접적으로 반영
marital_status	string \| null	- 한부모, 이혼, 사별 등 가족 상태와 연결되는 서비스를 찾을 때 사용 - 허용 값: ["미혼", "기혼", "이혼", "사별"]
has_children	boolean \| null	- 아동/양육 관련 복지, 교육비, 보육 지원을 찾는 데 필요
disability	boolean	- 장애인 대상 서비스 분기를 태우는 기본 플래그 - 기본값 false
disability_severity	string \| null	- 장애 관련 서비스는 경증/중증에 따라 세부 지원 내용이 달라질 수 있어 필요 - disability=true일 시에는 필수
employment_status	string \| null	- 취업, 실업, 비경제활동 여부에 따라 일자리/직업훈련/생계지원 계열 매칭에 영향을 준다.
region	string \| null	- 현재 구현에서는 hard filter가 아니라 query text에 포함되어 soft matching에 사용 - 즉 지역 관련 서비스 우선순위를 높이는 역할
top_k	int	- LangGraph가 몇 개의 후보를 받을지 결정 - 너무 적으면 후보 손실이 생기고, 너무 많으면 후처리 비용이 커짐 - (기본 값 5로 설정)

응답 JSON

  {
    "results": [
      {
        "serv_id": "WLF00001155",
        "serv_nm": "노인일자리 및 사회활동 지원사업",
        "serv_dgst": "어르신에게 다양한 일자리 및 사회활동을 지원합니다.",
        "department": "보건복지부",
        "score": 0.7282,
        "trgter_indvdl": ["노인", "저소득"],
        "intrs_thema": ["일자리", "생활지원"]
      }
    ]
  }

속성	타입	설명
serv_id	string	- 상세 조회 API로 이어갈 때 사용하는 핵심 식별자 - LangGraph는 반드시 이 값을 보관
serv_nm	string	- 사용자에게 보여줄 서비스 이름 - 후보 비교 시 가장 먼저 사용하는 필드
serv_dgst	string	- 서비스 요약 - LLM이 후보를 빠르게 읽고 판단할 때 사용
department	string	- 담당 부처
score	float (0.0 ~ 1.0)	- 벡터 검색 점수 - LangGraph가 후보를 정렬하거나 cutoff를 정할 때 참고
trgter_indvdl	string[]	- 대상자 분류 태그 - 사용자의 조건과 서비스 대상이 맞는지 빠르게 확인하는 보조 신호로 사용
intrs_thema	string[]	- 서비스 주제 분류 태그 - 주거, 생활지원, 일자리, 장애인복지 같은 카테고리 설명

상세 조회 응답

GET /welfare/{serv_id}

  {
    "serv_id": "WLF00001155",
    "serv_nm": "노인일자리 및 사회활동 지원사업",
    "serv_dgst": "어르신에게 다양한 일자리 및 사회활동을 지원합니다.",
    "tgtr_dtl_cn": "지원 대상 상세...",
    "slct_crit_cn": "선정 기준...",
    "alw_serv_cn": "서비스 내용...",
    "sprt_cyc_nm": "월",
    "srv_pvsn_nm": "현금지급",
    "trgter_indvdl": ["노인", "저소득"],
    "intrs_thema": ["일자리", "생활지원"],
    "application_url": "https://www.bokjiro.go.kr/...",
    "required_documents": [],
    "application_fields": []
  }

속성	타입	설명
serv_id	string	서비스 식별자
serv_nm	string	서비스 이름
serv_dgst	string	서비스 요약
tgtr_dtl_cn	string	지원 대상 상세
slct_crit_cn	string	선정 기준
alw_serv_cn	string	서비스 내용
sprt_cyc_nm	string	지원 주기 (예: 월, 년)
srv_pvsn_nm	string	지원 유형 (예: 현금지급, 서비스)
trgter_indvdl	string[]	대상자 분류 태그
intrs_thema	string[]	서비스 주제 분류 태그
application_url	string	복지로 신청 페이지 URL
required_documents	string[]	필요 서류 (현재 MVP에서 미구현, 항상 빈 배열)
application_fields	string[]	신청 항목 (현재 MVP에서 미구현, 항상 빈 배열)

이 다음에는 검색 정확도를 제대로 검증해보고 보완해야겠다.

Anthropic Academy - Claude Code 101 강의 복기

홍준기 — Mon, 27 Apr 2026 22:18:52 +0900

그냥 막 클로드 코드를 사용하면서 설치다가 클로드 코드를 제대로, 체계적으로 활용하고 있지 못 한 거 같아서 엔트로픽에서 클로드 코드 강의를 보고 복기해보았다.

이 강의 전에도 엔트로픽 아카데미에서 AI Fluency for students라는 강의를 봤었다.

학생이 어떻게 LLM을 사용해야 할지 알려주는 강의. 예전에 궁금해서 가장 먼저 봤던 강의다.

주변에서 AI를 사용하는 방법은 제각각이었고, 어떻게 AI에게 의존하지 않고 활용할 것인지, 어디까지는 AI를 활용하고 어디까진 제가 해야하는 건지 몰라서 찾아보았다. 이 강의를 보고 프롬프팅에 따라 AI가 과제 같은 걸 그저 대신해주는 생각의 외주화 도구가 될 수도 있고, 함께 공부하는 파트너가 될 수 있음을 느꼈다. 학습적인 측면에서 AI를 그저 답을 내주는 도구로 보는 것이 아닌, 질문하고 검증하며 함께 토론하는 파트너로서 활용하는 것이 올바른 편이라고 생각하게 됐다.

허나 학습 분야에서는 이런 식으로 함께 대화를 하며 학습하는 것이지, 실제 개발 등 각각 다른 활용 방면마다 AI를 적절히 사용하는 법이 있을테고, 각 방면에 맞게 올바르게 사용하는 것의 필요성을 느꼈다. 그래서 이번에는 개발 측면에서의 활용법. 클로드 코드 강의를 하나씩 보려고 한다.

클로드 코드 강의 목록

- Claude Code 101: 처음 볼 클로드 코드 입문 강의. 전체적인 오버뷰를 보여주는 듯.

- Claude Code In Action: 실제 개발에서 클로드 코드 활용 강의

- Introduction to Subagents: 서브에이전트 집중 강의

- Introduction to Agent Skills: 스킬 집중 강의

- Introduction to Model Context Protocol: MCP 집중 강의

이렇게 있는데 이번 글에서는 Claude Code 101 강의를 먼저 보고 복기를 해보겠다.

Claude Code 101

1. What is Claude Code

이 챕터에서는 그냥 클로드 코드 짧게 소개하는 챕터였다.

클로드와의 차이가 뭐냐? 클로드 코드는 클로드라는 뇌에다가 명령어 사용, 파일 접근 등 같은 걸 할 수 있도록 몸을 달아준 느낌?

그저 질의응답이 아니라 실제로 기여해주는 Agent라고 볼 수 있다.

또한 클로드 코드는 사용자의 프롬프트를 충족할 때까지 루프를 돌며 계속 작업을 수행한다고

클로드 코드 매커니즘

그냥 참고

기본적으로 최신 기능이 터미널에 먼저 들어가기 때문에 터미널을 추천한다고 한다.
homebrew로 깔면 자동 업데이트가 안 되니 curl로 네이티브 인스톨러 설치 권장

2. Your first prompt

이 챕터에서는 음 설치하는 거 제외하면 다음 챕터 맛보기라서.

자동 승인 or 승인 요청 있다. 편한 거 쓰쇼

[쉬프트 + 탭] 하면 [자동 승인 / 플랜 모드] 변경 가능

여기서 핵심은 플랜 모드를 잘 활용해라!

3. Daily workflows

여기서는 클로드 코드 사용 가이드를 말해준다.

많은 사람들이 그냥 바로 코딩으로 들어가는데 Explore -> Plan -> Code -> Commit 순서로 하라고 한다.

가장 효율적인 토큰 사용 및 컨텍스트 관리 방법이라고

Explore(탐색)

막무가내로 시작 전 Plan mode로 readOnly를 통해 프로젝트 상황 보기

Plan(계획)

바로 코딩 시작 전 클로드 코드가 계획을 수립 받고 확인 받는 과정인데 이 과정에서 클로드가 모호한 부분을 사용자에게 추가로 물어볼 수 있고, 클로드 코드 계획에 오류가 있다면 수정할 수 있다. 이러면 코딩 과정에서 오류를 발견하는 것보다 컨텍스트 및 토큰 절약을 할 수 있고 탄탄한 토대를 가지고 구현에 들어갈 수 있다.

Code(구현)

계획을 토대로 개발에 들어간다.

Commit(커밋)

커밋 전 서브에이전트로 리뷰하기. 메인 에이전트로 코드 리뷰까지 하게 되면 이전 컨텍스트를 가지고 Bias한 리뷰를 할 수 있기에 컨텍스트가 없는 서브 에이전트를 하나 만들어서 새로운 시각을 가진 제 3자가 리뷰하도록 하라는 말이다.

Context Window(컨텍스트 윈도우)

클로드 코드의 메모리 같은 느낌?(그냥 메모리가 맞음) 클로드 코드 잘 쓰려면 컨텍스트 관리를 잘 해야한다고 한다.

세션의 컨테스트 윈도우가 다 차면 자동으로 컴팩트 됨

우리에게 이 컨텍스트를 관리?할 수 있는 세 명령어가 있는데

/compact

수동으로 세션의 컨텍스트 압축. 이전 대화 내용 기억하면서 계속 진행하고 싶을 때. 컴팩트를 하면 요약본이 남기에 디테일이 소실될 수 있음 당연히.

/clear

컨텍스트 다 지움. 기억을 지움. 이제 다른 기능 개발하거나 이전 대화에 편향된 결과를 받고 싶지 않을 때.

/context

현재 세션의 컨텍스트를 자세히, 시각적으로 확인 가능.

compacting vs clear

-> 한 기능 개발이 덜 끝났으면 컴팩트, 새 개발 부분이면 clear

따라서 클로드 코드의 컨텍스트를 잘 관리할 수 있어야 한다. 그러기 위해 우리는 클로드 코드에게 성공 기준을 명확히 프롬프트로 제공해야 한다. 명확한 프롬프트를 주지 않는다면 클로드 코드는 그걸 알아내기 위해 토큰을 더 많이 소비하며 더욱 Explore를 함 그만큼 컨텍스트도 더 차고 따라서 대충 짧은 프롬프트를 넣는 것이 디테일한 프롬프트보다 컨텍스트를 더 많이 잡아먹는다.

또한 해당 세션에서 사용하지 않는 MCP도 끄라고 한다. MCP도 컨텍스트를 차지하는데, 컨텍스트 윈도우는 한정되어 있기 때문에 컨텍스트를 잡아먹는 MCP를 너무 많이 켜놓으면 성능 저하.

서브에이전트를 사용하는 이유도 일을 시키고 요약만 받아오면 메인 세션의 컨텍스트 윈도우 관리 가능. 약간 추상화 같은 느낌? 일 시켜놓으면 서브에이전트가 수행 후 결과를 요약해주니 메인 세션은 더욱 전체적인 관점에서 작동 가능.

만약 컨텍스트를 없애도 남기고 싶은 것이 있다면 CLAUDE.md에다가 명시하면 된다. 시스템 프롬프팅을 저기 넣는 느낌. 예를 들어 CLAUDE.md에 구현 후 테스트를 매번 돌리라고 넣는 거. <- 참고로 이처럼 구현 단계에서는 테스트를 꼭 넣는 것이 좋다고.

4. Customizing Claude Code

CLAUDE.md 파일

매 세션을 처음 시작할 때마다 클로드 코드가 읽는 파일이다. 매 세션마다 처음에 정의해 주거나 말해줘야 하는 것들을 여기 적어놓으면 됨. /init 하면 클로드가 현재 프로젝트를 분석하여 CLAUDE.md 초안을 만들어준다.

처음부터 완벽하게 CLAUDE.md를 짜려고 하지 않아도 된다. 개발 도중 앞으로 계속 기억이 필요한 것들은 그때그때 CLAUDE.md에 넣어달라고 하기.

CLAUDE.md 안에 모든 내용을 적으려 하면 너무 길어지니 다른 문서를 참고하고 싶다면 [@파일경로] 이런 식으로 적어놓으면 찾아서 읽는다고

서브에이전트(Subagents)

컨텍스트 관리를 더욱 잘 할 수록 클로드 코드는 더 Productive하게 된다. 그러나 컨텍스트를 고려하지 않고 사용 시 많은 컨텍스트가 그저 코드 탐색, 웹사이트 검색 등으로 소비된다. 이 과정 중 헛발질한 것도 다 컨텍스트에 추가된다. 이런 과정들은 서브에이전트에 맡기면 다른 새로운 컨텍스트를 가진 세션을 만들어 실행하여 메인 세션과 컨텍스트를 분리하여 수행 후 결과만 반환할 수 있다. 메인 세션은 핵심 결과만 받고 그 과정에서 생성되는 컨텍스트는 생략할 수 있다는 거임. 약간 자판기 느낌인 듯?

/agents를 통해 내 에이전트를 커스터마이징하고 어떤 프롬프트가 실행될 때 에이전트를 불러올지 설정할 수 있다는데 우선 클로드 기본 에이전트부터 활용하고 나서 만들어보아야겠다.

기본적으로 특성 상황에서 기본 서브에이전트를 호출해서 실행하는 거 같은데 이런 패시브 상황 외에도 내가 판단하에 서브에이전트가 효율적일 거 같은 상황인 경우 호출할 수 있도록 해봐야 할 듯.

기본적으론 서브에이전트를 돌린다고 메인 세션에서 다른 걸 할 수 있지는 않다. 백그라운드 옵션을 키지 않으면 기본적으로 컨텍스트 분리만을 위한 서브에이전트 호출이 되어 기다려야 함.

메인에서도 병렬적으로 다른 걸 수행하고 싶으면 서브에이전트를 백그라운드에서 돌려달라고 해보자.

-> 컨트롤 + B를 누르면 서브에이전트를 백그라운드로 보낼 수 있다.

더 자세한 건 서브에이전트 강의에서..

스킬(Skills)

PR 리뷰라든가 반복적으로 하는 것들을 매번 설명하거나 복붙 하기도 귀찮은데 그걸 문서화해놓고 그걸 통해서 간단하게 자동화하는 것.

클로드는 Skill 문서의 이름과 description만 읽어 놓고 이 스킬이 언제 필요한지 판단하고 필요할 때 해당 스킬을 시전 한다.

그치만 그냥 / 명령어를 통해서 스킬을 직접적으로 호출하는 것도 가능.

자세한 건 스킬 강의에서..

MCP(Model Context Protocol)

외부 도구에 접근할 수 있도록 하는 MCP라는 프로토콜 원래는 이런 프로토콜이 없이 연결 방법이 다 제각각이었는데, 엔트로픽이 USB-C 타입과 같은 표준화된 방법인 MCP를 제시하였고 거의 표준으로 자리 잡고 있는 듯하다.

주의

MCP는 안 써도 켜놓기만 해도 해당 세션의 컨텍스트를 소모한다.

컨텍스트의 10% 이상을 MCP가 차지하게 되면 클로드 코드는 성능 저하를 막기 위해 도구 서칭 모드로 들어간다고. 적당히 쓰고 안 쓰는 MCP는 끄도록 하자.

자세한 건 MCP 강의에서..

Hooks

AI가 실수로라도 넘을 수 없는 가드레일 설정

CLAUDE.md에 있는 건 가끔 빼먹을 수 있는 Soft Rule이라고 하면 Hooks는 예외 없이 안 지킬 수 없는 Hard Rule이다.

그냥 유튜브랑 블로그로 주워들은 걸로 클로드 코드를 사용하려니까 제대로 사용하지 못하고 있는 거 같아서 봤는데 구조를 잡는데 큰 도움이 되었다. 기본적인 틀을 먼저 이해하고 심화 활용하는 방안으로 가야겠다.

실리콘밸리 연수 1주차 - 우물 안 개구리의 우물 밖 탐방

홍준기 — Wed, 22 Apr 2026 11:26:02 +0900

올해 초에 컴퓨터학부에서 하는 실리콘밸리 연수 프로그램에 운 좋게 합격하게 되어서 미국에서 3주 동안 지내고 왔었다.

첫 주와 셋째 주에는 실리콘밸리에서 AI workshop을 했고, 둘째 주에는 라스베가스에 잠시 다녀와서 CES에 참석했다.

지금이라도 그때의 일들을 회고 느낌으로 적어놓으려한다. 내 인생에서 한번 갈까 말까 한 미국에 3주 동안 있었으니, 이번 기회에 학교에서 가게 된 만큼 가서 어떤 일이 있었는지 기록해봅시다.

신청

신청은 컴퓨터학부 홈페이지에 올라와서 그래도 도전은 해보자라는 마음가짐으로 신청해놨다. 예전까지만 해도 2학년 SW진로설계 시간 때 교수님께서 말씀하시는 걸 들으면 실리콘밸리 프로그램은 정말 영어 잘하고 특출난 사람이 가는 건 줄 알았다. 이번에 나는 도전하였다는 이유로 운 좋게 이번에 된 듯하다. 신청 후 면접도 그리 길게 보지는 않았지만 각 사람마다 두 개정도의 질문을 받았다. 여기에 가고 싶은 이유를 영어로 말하기, 그리고 또 베트남과 이 미국 실리콘밸리 프로그램을 두 개 다 지원한 이유? 이런 걸 물어봤었다. 첫 질문은 유창하진 못 했지만 그냥 말했고, 두 번째 질문은 작년 여름 인도 인턴십을 갔다 왔고 그 경험에서 느낀 점을 기반으로 말했던 거 같다.

이후 합격자에 발표에 내 이름이 있었을 땐 정말 엥 내가 됐다고? 하는 느낌이었다. 토익 성적을 미리 따놓길 잘했는 거 같기도 하고. 이왕 된 거 감사하게 그리고 최선을 다해 경험하자는 마음가짐으로 갔다와야겠다고 생각했다.

출발 전

종강 후에 가기 전까지는 쉬어야지 하면서 진짜 빈둥빈둥 했다 말그대로. 한 일주일을 유튜브도 질릴 만큼 보면서 쉬다가 출발했다.

이후 출발 후 같이 가는 다른 사람들과대화해 보니나는 참 멀었다라는 생각이들 만큼다들 열심히 사는 사람밖에 없다. 나는 뭘 믿고 그렇게 살았나 싶을 정도?

또한 혼자서 하는 것보다 이렇게 같이 경험하니 더 많은 걸 배우고 견문을 넓힐 수 있었던 거 같다. 이런 프로그램의 묘미가 또 열심히 사는 다른 사람들과 함께 시간을 보낼 수 있는 거 아닐까? 여기서 다들 친해지면 좋겠다고 생각했다. 그렇다고 주눅 들지말고 나도 적극적으로 근자감을 가지고 임해야겠다고 느꼈다. 척하다 노력하다 보면 되는 데까지 갈 수도 있으니까.

엄청난 거리

도착

첫날에는 아침에 도착 후 호텔에 짐을 풀고 교수님과 함께 밥을 먹고(아직도 감사합니다 편재호 교수님) 산호세 주립대를 사부작 산책 했다. 이것만 하고 시차 때문에 너무 피곤해서 숙소에 들어가서 바로 잤다. 리얼 피곤했다.

첫 주 숙소와 밥입니다^^

편재호 교수님의 지니 강의

다음날에는 산호세 주립대를 본격 탐방하고 산호세 교실에서 편재호 교수님의 강의를 들었다.

기술적인 강의는 아니었지만 감명 깊게 들었다. 이런 얘기가 재밌었다. 마인드에 대한 강의. 당신에게 지니가 있다면 어떤 소원을 빌겠습니까?라는 것이 교수님의 질문이었다.

사실 교수님이 이 질문을 쇼츠에서 감명 깊게 보고 AI를 활용해 이 주제를 강의로 만들었다고 한다. 이 말을 듣고 AI 활용은 저렇게 하는 것이구나 생각했다. 이렇게 자신이 AI를 활용하는 방법을 슬며시 보여주는 부분이 멋진 듯 ㄷㄷ. 나도 저렇게 활용하고 싶다는 생각이 들게 하는 거 같다. 유튜브 영상을 단순히 감명 깊게 보고 끝내는 것이 아니라 이 인사이트를 우리에게 알려주기 위해 만드신 걸 보고 더욱 AI 활용 능력의 필요성이 와닿았다.

https://youtube.com/shorts/KBaWk-GxgBU?si=JSNK04NMaZwFZV89

해당 쇼츠 영상

암튼, 안성재가 한 말이 굉장히 Bullet Point인데 자기는 지니가 있어도 아무 소원을 빌지 않을 것이라고 한다. 왜냐하면 자신은 지금 자기가 어릴 적 꿈꾸던 많은 것들을 이뤘는데 돌이켜보니 이 꿈들을 이루기 위해 노력하고 힘들어했던 그 과정이 굉장히 소중하고 값진 것이었던 거 같기 때문이라고 한다. 그렇기에 그저 말만 하면 이루어지는 지니의 소원을 통해 이루어도 금방 질려서 다시 불행해 질 것이라고.

외적 동기(목적)를 위해 사는 게 아니라 내적 동기(과정에 대한 즐거움)에 따라 살아라는 말인가? 목적을 이미 이룬 자가 하는 멋있는 말이기도 하다만, 나도 결국 본인 마음가짐에서 나온다고 생각한다. 마음이 행동이 되고 행동이 습관이 되고 습관이 성격이 되고 성격이 운명이 되니까?

이런 마음가짐에 대한 이야기는 결국 현재에 집중(혹은 즐기기)하라고 한다. 술 취한 코끼리 길들이기란 책에서도 '빗자루질을 하더라도 최선을 다하라' 이런 말처럼. 인간의 특성상 목적만 보고 현재에 살지 않으면 인생이 재미없어지는 건 맞는 듯. 나도 현재에 머무려고 더 노력해야겠다. 평생을 현재에 머물면 인생 전체를 즐기게 되는 거니까. 또한 현재에 머문다고 미래를 준비하지 말라는 말은 아님. 그치만 나한테 지니가 있었으면 소원을 개벅벅 빌었을 듯.

산호세 주립대 사진들(날씨가 좋죠? ㅎㅎ)

윤성희 대표님의 AI 강의

평일에는 윤성희 대표님께서 AI에 대해 강의를 해주셨다. 언어 모델의 역사와 작동 원리 등에 대해서 배웠는데, 인상 깊은 내용을 짧게 남겨보겠다.

https://sungheeyun.github.io/#sem-2026-jan <- 윤성희 대표님 블로그

Welcome to Sunghee’s Home!

I am Sunghee Yun.

sungheeyun.github.io

번역 트레이닝과 요약 트레이닝은 다르지 않다.

LLM 관점에서는 번역을 위한 트레이닝과 요약을 위한 트레이닝은 다르지 않다는 것이다. 겉으로 드러나는 결과물은 다르지만 결국 언어를 이해한다는 공통된 목적을 바탕으로 학습하므로 두 과정의 본질은 같다는 설명. 처음 접하는 관점이라 흥미로웠습니다.

인간의 입장에서는 다른 언어로 바꾸는 번역과 글을 압축하는 요약은 좀 다른 거라고 생각이 되는데, LLM의 동작 방식 측면에서는 내어놓는 결과물은 다르지만 결국 언어를 이해해야하는 본질이 같으니 그렇다는 거 같다.

이처럼 다른 느낌이라고 생각했던 것을 인간의 관점으로 바라보지 않고 AI의 관점에서 보면 같은 본질로 진행될 수 있다는 관점, LLM의 관점을 생각해본다는 것이 새로운 시각되었다.

할루시네이션에 대하여

대표님께서는 우리에게 할루시네이션이 없앨 수 있는 문제인지 아닌지 생각해와보라고 하셨다.

이때 나의 생각은 할루시네이션을 없애면 LLM은 더이상 LLM으로서의 매력을 느끼지 못할 성능을 보일 듯하다는 것이다. 단순히 정답만을 안전하게 제시하게 된다면, 현재의 LLM이 보여주는 창의성과 확장성은 크게 제한될 것이라 느꼈다. 그저 정답만 알 수 있는 LLM 사전 같은 느낌이 된다는 거죠.

예를 들어 전체적인 사용자의 만족도 측면에서 아마존의 상품 추천 알고리즘처럼 95%의 사용자가 만족하는 답변을 얻고 5%의 사용자가 할루이네이션을 통해 잘못된 정보를 얻었다고 해서 그 할루시네이션을 고치기 위해 LLM의 과감한 상품 추천 제공 기능을 죽이고 소극적이게 사용자에게 비슷한 상품만 추천한다면 싫어하는 5%의 사람은 줄 수 있지만 95%의 만족도의 깊이가 그보다 더 줄어들 것이라고 생각.

사람에게 틀렸다고 뭐라하면 기가 죽어서 안전빵인 답변만 하며 소극적인 의견 제시가 되어버리는 거처럼 LLM도 할루시네이션이 발생할 수 있는 과감한 단어 선택을 배제한다면 현재 LLM으로서의 매력을 잃게 될 것이라 생각했다.

그렇다면 과감한 단어 선택을 통해 만든 글이 주관적인 영역이면 창의성이 되는 거지만, 객관적인 영역이었다면 틀린 사실이 된다는 건데 그럼 객관적 사실 측면에서는 과감한 단어 선택을 줄이면 되는 것 아닌가? 라는 생각도 들긴 하는데, AI가 객관적인 것과 주관적인 것을 구별하지 못하는 확률적 도약을 하기 때문에 안 되지 않나 싶다. 그냥 확률적으로 그럴싸한 문장을 뱉는 거니까.

지금의 AI는 자신감 있게 말하는 사람, 근자감 있는 사람이다. 그러니 LLM의 말이 맞는 말인지는 아직까지 본인이 판단해야 할 영역이라고 생각한다. 그렇기에 질문 분야의 전문성, 기본기는 여전히 중요하다고 생각한다.

따라서 아직 AI는 도구이고, 책임성과 전문성은 인간이 챙겨야 할 부분이 있는 듯하다.

AI에 대해 덧붙이는 생각

나도 지금 AI 혁명이 어느 때도 없었던 시기라고 생각한다. 그러다 보니 지금 다들 AI를 활용하는 법을 시대의 흐름에 따라서 익히고 또 다른 것이 나오면 익히고를 계속 반복하고 있는데 나는 이런 상황에서 원숭이 꽃신 동화가 생각난다.

아시는 분? ㅎㅎ

너구리가 맨발로 다니던 원숭이에게 꽃신을 선물하는데, 원숭이는 그 꽃신을 계속 신고 다녔고 꽃신을 신고 다닌 것에 너무 익숙해져 꽃신 없이 맨발로는 다닐 수 없게 되는 내용이다.

나는 지금 현재 우리가 원숭이고 꽃신이 AI일지도 모른다고 생각한다(물론 정확한 비유는 아닐 수도 있지만). 원숭이는 결국 꽃신 없이 다닐 수 없게 되어 너구리의 종노릇을 하며 지내게 된다. 원숭이가 이렇게까지 된 이유는 꽃신에 의존하게 되었기 때문이다. 우리는 이를 반면교사 삼기 위해서 AI에 의존하지 않고 활용하는 법을 배워야 한다고 생각한다. 이 말은 AI를 사용하는 능력뿐만 아니라 기본기까지 겸비하는 개발자가 되어야 한다는 것이다.

지금 AI 활용하는 법을 익히는 것도 물론 해야하지만 결국 기본기가 튼실하면 언제라도 새로운 방법론을 금방 따라갈 수 있는 토대를 갖추는 것이라 생각한다.(하체가 튼튼하면 쇼크 상태에서도 잘 버틸 수 있어요 같은 느낌)

혹시 나중에 위 너구리처럼 우리가 AI 없이 살지 못할 때 부담되는 토큰세를 요구하게 된다면, AI를 지금만큼 자유롭게 사용하지 못한다면, 결국에는 AI 활용은 해야하는 건 맞지만 AI를 효율적으로 사용할 수 있는 기본기 있는 개발자가 되어야할 거 같다고 생각. 기본기와 AI 활용 능력은 양자택일이 아니라 양자겸비.

나중에 AI를 뺏긴다고 지금 AI 활용 능력을 키울 필요가 없다는 것이 아니라 나중에 지금보다 한정된 AI 호출에도 효율적이고 체계적인 AI 활용(그러니까 만약 지금보다 AI 사용의 기회비용이 커진다면)을 할 수 있는 능력이 도움이 되지 않을까?라는 생각이다 그러니까 기본적인 개발 지식도 필요하고. 망상을 좀 했는데, 이렇지 않다고 해도 필요 역량은 같을 듯하다.

뻘소리 그만하고 돌아댕긴 거 보여드릴게요.

탐방

이렇게 AI 워크숍 말고도 이번 주에 기업 탐방도 해보았습니다. 사실 구글 애플은 그냥 스토어지만.

PLUG AND PLAY & Apple Visitor Center

밴쳐캐피탈인 플러그앤플레이도 방문했다. 여기서 네트워킹을 정말 활발하게 한다고 한다.

슬쩍 보이는 애플 본사

인텔 & 구글 스토어

인텔은 직접 제품을 테스팅하는 곳까지 들어가서 보는 투어까지 했다. 게스트로 들어가서 이런 거까지 보는 게 흔치 않은 기회였던 거 같다. 안에서 인텔이 메타나 인스타그램에도 제공하는 서버 같은 게 어떤 테스트 과정을 거치는지 설명해주셨다. 데이터 센터에 꼽힌 네모난 거 안이 어떻게 생긴지 알 수 있었다. 여기서 그리고 안에 빈 공간의 이유와(규격화 및 확장성). 이후 인텔 스토어에서 슬림 무선 충전기를 고민하다가 샀는데 지금은 제 책상 위에서 잘 쓰고 있네요.

인텔 탐방 이후 구글 스토어에 들려서 자전거 타고 돌아다녀보았다. 기념품은 딱히 살만한 게 없었음.

인텔과 구글 스토어 사진

음식

햄버거를 많이 먹었다.

많이 안 먹으면 둘이서 하나 먹어도 될 양의 음식들도 많았다.

인앤아웃이 맛있더라구요 저는

잡 사진

이밖에 스탠프드 대학교 탐방도 했다. 샌프란시스코에 구글 자율주행차량 웨이모가 많이 돌아다니더라. 앱으로 탈 수 있다고 하던데 타볼라다가 결국 못 탔다.

사진들 중 로댕의 칼레의 시민이라는 작품도 있었다. 영국군이 항복을 권유하며 도시 전체 사람 대신 처형될 6명을 데려오라 했다고 한다. 도시를 위해 솔선수범하여 목숨을 포기하기를 자처한 사람들이다. 작품 설명을 보면 위풍당당한 모습일 거 같지만 얼굴 보면 후회 좀 한 듯하다.(위키피디아 보면 다행히 처형 당하지 않았다고 하네요^^)

스탠포드 대학교 사진들(날씨가 안 좋네요 ㅎㅎ)

Pier 39에 가고 샌프랜시스코를 돌아다녔다.

저기 밑에 있는 섬이 알카트라즈라는 교도소였다고 한다!! ㅎㄷㄷ

샌프란시스코 나들이

주말에는 교수님과^^ 페블 비치쪽을 드라이브도 했다.

숲이 곰 나올 거 같이 생겼네요

이밖에 미국에서 느낀 점

미국에서는 사람들이 정말 네트워킹을 중요시하고 또 적극적으로 하는 것을 몸소 느꼈다. 인터넷과 원격 환경이 잘 갖춰져 있음에도 불구하고 사람들이 물리적으로 모이는 눈에 보이지 않는 이유가 있었다. 인터넷에 모든 정보가 있는 것도 아니라는 것을. 기술 발전 속에서도 사람 간의 연결과 환경이 여전히 중요한 요소라는 점을 느꼈고 미국에서는 사람들이 정말 적극적으로 서로 연결되려고 하고 있었다. 나도 링크드인을 이번 프로그램을 통해 깔게 되었다. 여기서는 우연한 만남이 기회가 되게 하고 인생이 되게 하는 가능성을 사람들은 만들어놓는다.

또한 외국에 나가는 것이 그렇게 먼 선택지가 아닐 수도 있음을 우리나라 밖으로 시야를 넓히는 게 좋은 거 같다. 영어의 중요성도.

마무리

미국에서 하는 다양한 활동과 경험도 정말 좋았고, 여기 있으면서 느꼈던 건데 여기 온 다른 사람들은 다들 대단한 사람들이었다. 나는 운 좋게 와서 주변 사람들에게 많은 걸 배웠던 거 같았다.

저희 경북대 컴퓨터학부의 정말 좋은 프로그램이라서 다들 기회가 되면 해보셨으면 하네요.

2주차 라스베가스도 나중에 되면 회고해보려구요.

복지드림 - RAG 구현 하네스 엔지니어링 기반 다지기

홍준기 — Tue, 21 Apr 2026 19:57:53 +0900

이번 프로젝트의 목표: 직접 코딩하지 않고 하네스 엔지니어링을 통해 바이브 코딩, 자동 검증을 통해 RAG를 구현하며 그 과정에서 얻은 AI 사용 스킬 및 기본 개념 정리

이번 종프에서 급하게 주제를 바꾸게 되었다.(Surfit은 다음에 따로 하는 걸로 ㅎ)

멘토님과 미팅을 해본 결과 이전 주제 기술적 깊이가 지금 AI 시대에 아쉬운 기술 스택이었다는 것이다. 우리가 그저 기본기를 배우기 위해 고안안 주제여서 맞는 말이었다. 멘토님은 지금 클로드 코드를 사용하여 최고의 아웃풋을 뽑는 것이 중요하다고 하셨다. 또한 여러 AI 기술들을 프로젝트에 넣는 것도(멀티 에이전트, 로컬 LLM, 하네스 엔지니어링 등) 그래서 멘토님의 말씀에 따라서 프로젝트의 수준을 올리기 위해 주제를 재선정하였다.

우리가 재선정한 주제는 취약 계층을 위한 복지 서비스 자가진단 AI 에이전트였다. 기본적으로 취약 계층이 자신이 어떤 혜택을 받을 수 있는지 조차 모른 채 그냥 지내는 분들이 많다고 생각했기 때문이다. 그래서 간단한 채팅 형태를 통해(나중에 음성 기능 추가?) 자신이 받을 수 있는 복지 서비스를 정리해주고, 이를 신청하기 쉽도록 가이드를 제공해주는 에이전트를 고안하였다. 이 과정에서 사용자에게 맞는 복지 서비스 안내, 가이드, 초안 작성, 리포트 작성 등 서비스를 멀티 에이전트를 도입하여 제공해줄 계획이다. 추가로 사용자의 개인정보 보호를 위한 로컬 LLM, 정확한 복지 서비스 제공을 위한 RAG 등을 사용할 계획을 구상하였다.

또한 멘토님의 말씀이 지금 기본기는 당연한 가져야하고, 이제부터는 AI를 최대한 활용해보는 경험과 능력이 중요하다고 하셨다. 바이브 코딩을 이번 프로젝트에 적극 활용하고 하네스 엔지니어링도 적용해보라고 하셨다. 원래 종프에서 기본기를 쌓을 생각이었는데 주제를 변경하면서 최대한 바이브 코딩으로 좋은 산출물을 내는데 힘 써봐야겠다고 생각했다. 기본기는 따로 공부하는 걸로!!

나도 느끼는게 AI를 잘 활용하려면 기본기는 뒷받쳐져야 하는 거 같다. 약간 군대에서 소대장이라고 주특기 못 하면 안 되는 그런 느낌? AI가 뭘 하는지 파악을 할 수 있고, 또한 어떤 부분을 잘못 진행하고 있는지 파악 할 수 있는 능력은 여전히 필요할 거 같다. 그러나 이 기본기와 AI 활용 능력이 양자택일의 문제가 아니고 둘다 함유하는 것이 앞으로의 개발자가 가져야할 방향인 듯하다.

그래서 이왕 바이브 코딩으로 진행할 거면 시대의 흐름에 맞는 방식으로 해보고 싶다.

하네스 엔지니어링

멘토님에게 하네스 엔지니어링을 사용해서 해보라는 말씀을 듣고 저번에 유튜브에서 그냥 넘겼던 하네스 엔지니어링 영상이 생각나서 봐보았다. 이젠 그저 프롬프팅으로 AI에게 명령하는 것이 아니라 AI가 안 지키면 안 되는 법규들을 만들어 AI가 해당 제약 조건 안에서 움직이도록 하는 것이다. 하네스 엔지니어링은 이처럼 AI에게 하네스(마구)를 달아 통제한다는 말이다. 우리가 개입 안 하고 알아서 조절하게 해서 인간 병목 없애는 게 포인트 ㅎ

이를 보고 유명하다던 하네스 엔지니어링 ECC(everything-claude-code) 레포를 봐보았다. 그런데 요건 엄청난 거 같긴 하지만 에이전트가 뭐 몇 개라 했더라? 36개인가? 엄청 많고 기능이 많아서 내 프로젝트에 적용하기엔 배보다 배꼽이 더 커지는 거 같았다(오버 엔지니어링). 그래서 저 ECC를 들고 바로 내 프로젝트에 적용하기보다, 내 프로젝트 규모에 맞게 적용하며 이해할 수 있는 좀 더 간단한 하네스 엔지니어링을 구성해볼 수 있도록 다른 것을 찾아보았다.

그래서 유튜브 하네스 엔지니어링 영상을 하나 보고 하네스를 만들어서 시작해보았다.

https://youtu.be/AQOvNx87Urs?si=Xbmpx-XYagi2bb9x

보니까 하네스 엔지어링 자체가 지금 내 역할 부분에 쓰기에 살짝 오바인 거 같기는 한데 공부할 겸 해보는 것도 좋겠죠^^ 그리고 이 영상에서 wispr flow라고 음성 -> 텍스트 변환 쓰는 거 보고 써봤는데 리얼 맛도리더라구요^^ 다들 써보세요

핵심은 프로젝트 개발을 step 별로 분류해서 먼저 문서화를 해놓고 이를 클로드가 하나씩 실행하며 도메인 개발을 진행하는 것이다. 클로드가 진행할 step을 정의, 다른 규칙들 또한 문서화해놓고 실행을 하면 클로드가 정의된 규칙들을 지켜가며 코드 작성 및 자가 수정을 통해 개발이 진행된다는 것이다.

암튼 프로젝트 내용으로 먼저 가봅시다.

클로드가 만들어준 초기 아키택쳐 구조

위의 아키택쳐 구조를 만들기 위해서 역할 분담을 진행하였고, 나는 RAG 구축을 담당하기로 하였다. 랭그래프와의 API 통신을 통해서 사용자에게 적절한 복지 서비스를 검색해서 반환해주어야 할 듯하다.

RAG(Retrieval-Augmented Generation)

뭔지 간단하게 비유를 하자면?

사람(LLM)이 시험을 치르는데 시험지(사용자의 요청)에 있는 답란에 자기가 생각해서 맞다고 하는 걸 그냥 적는 것이 아니라 옆에 있는 오픈북(RAG)를 참고하여 정확한 답을 시험지에 적는 것이라고 보면 될 거 같다.

최신 정보를 학습하지 못하였을 때 RAG를 가지고 최신성을 확보하는 것도 많지만 우리 프로젝트에서는 정확성 확보에 좀 더 중점을 뒀다고 볼 수 있겠다. 구체적인 문서 내용까지 LLM이 확실하게 아는 것이 아닐 수 있으니 말이다. 따라서 나는 이 정확한 오픈북 RAG를 만드는 것이 이번 프로젝트에서의 역할이다.

바이브 코딩으로 구현한다고 해도 내가 신경써야할 요소들이 몇 가지 있다.

1. 청킹

데이터를 자르는 단위.

ChromaDB에 저장을 하는 단위인데 이를 적절한 단위로 선정해야 정확하면서 효율적으로 답변을 할 수 있는 거 같다. 너무 크면 비효율적이고 너무 작으면 맥락 손실(오버헤드 발생 같은 느낌? 오버랩 있잖아). 운영체제 프로세스 스케줄링에서 타임 슬라이스를 적절히 정하는 것처럼 여기서도 청크의 크기를 적절히 정해야하는 듯하다.

초기 청크 크기

밑에 청크 오버랩은 뭐 종이를 붙인다고 하면, 두 종이를 이으려고 풀을 바르는데 풀 바르는 겹치는 부위를 몇 퍼센트로 할지 같은 느낌? 일반적으로 20%정도가 권장 사항이라고 해서, 우리 프로젝트에서 20%로 진행할 것이다.

2. 임베딩 모델

자른 청크를 유사도 검색이 가능하도록 백터 변환. 의미가 비슷한 문장이 비슷한 백터 공간에 위치하도록 하는 것이다.

우선 우리 프로젝트에서는 한국어에 특화된 소버린 AI [jhgan/ko-sroberta-multitask] 모델이 있다고 해서 우선 이 모델을 사용해볼 예정이다. 높은 한국어 정확도와 보안상 우리 로컬에서 독립적으로 구동할 수 있기에. 청크 크기를 클로드가 1000으로 설정 해놓았던데, 이 모델의 최대 청크 크기가 512 토큰이라고 해서 한국어 기준으로 우선 250자 정도로 수정하였다. 최악의 경우(들어오는 한글이 다 2.5 토큰)를 고려하면 180자 정도가 맞지만, 너무 청크가 작으면 맥락이 줄어들어 답변 품질이 떨어질 수 있으니 우선 250자로 설정을 했다. 이 부분에서는 worst case를 너무 고려하기보다는 해보고 문제가 생기면 조정하는 방식이 더 합리적일 거 같다는 생각이다. 오버랩도 있고 하니까 문제가 없지 않을까 싶다.

3. 검색(Retrieval)

ChromaDB에 저장되는 형식은 아래와 같다.

구성요소	설명
id	청크 고유 식별자
document	임베딩 대상 텍스트(청크값, 250자, 후에 디버깅 용 등)
embedding	document를 백터화한 숫자 배열(검색에 사용)
metadata	해당하는 복지 서비스의 원본 데이터(응답용)

검색을 할 때 사용자의 쿼리 텍스트와 embedding에 대한 유사도 검색을 통해 해당하는 청크를 찾고 metadata를 반환하는 것이다. 메타데이터는 한 복지 서비스에 해당하는 여러 청크들이 있어도 한 메타데이터를 참조하는 것(JOIN 해서)은 아니고 성능을 위해 각 청크마다 복사된 메타데이터를 가지고 있는게 권장된다고. 성능 위해 반정규화 같은 느낌

띠리사 위의 것들을 고려하며 내가 해야할 것들이

1. 랭그래프 쪽에서 JSON으로 사용자 데이터 받기

2. 쿼리 텍스트로 변환

3. 임베딩 모델로 쿼리를 백터 변환(임베딩)

4. 해당 백터를 ChromaDB에 검색(Retrieval), 유사도 검색

5. 가장 가까운 청크 k개 반환

6. metadata를 랭그래프에 JSON으로 반환

그래서 지금까지는 하네스 엔지니어링 구조 확립을 위해 step 설계 및 문서화를 하였는데, 어떻게 정의하였는지 봐봅시다.

Step	내용
0-project-setup	프로젝트 뼈대 구성(디렉토리, 패키지, 설정 파일 등)
1-models	복지 서비스 데이터 모델 정의(WelfareRaw, SearchResult 등)
2-db-layer	ChromaDB 클라이언트 초기화 및 컬렉션 관리
3-embedding-layer	한국어 임베딩 모델 연동
4-crawler	공공데이터 API로 복지 서비스 데이터 수집
5-pipeline	수집 데이터 청킹 -> 임베딩 -> ChromaDB 저장
6-retriever	사용자 쿼리 백터화 -> ChromaDB 유사도 검색 -> 결과 반환
7-api-layer	랭그래프와 통신하는 FastAPI 엔드포인트 구성

현재 위처럼 스탭 설계 및 문서화를 완료하였다. 다음 글에서는 하네스 엔지니어링 자동화를 실행하고 클로드가 각 스탭을 구현하고 자가 검증하는 과정을 공유해보겠습니다 + API 협의 내용

PCCP 후기 - 불합격 후 Lv3

홍준기 — Sun, 19 Apr 2026 13:56:25 +0900

오늘 세 번째 PCCP 시험을 치렀다.

사실 부끄럽지만 이전에 쳤었는데 불합격이 나왔다. 처음 PCCP를 칠 때 2레벨은 나오겠지. ㅋㅋ라고 하며 쳤었는데, 0레벨이 나와서 진짜 좀 충격적이었다.

알고리즘을 그래도 꾸준히 풀었는데, 이렇게 0레벨이 나왔다는 게 나의 공부 방법을 한번 되돌아보게 되는 계기가 되었었다. 그래서 PCCP에 불합격하고 나서, 테스트 케이스 추가에 유독 신경 쓰고 허겁지겁 풀지 않으려고 한다.

사실 PCCP를 치게 된 게 카테캠 코딩 테스트 면제를 위해서 시작했던 건데, 그건 저번 PCCP까지가 마지막 기회였다. 그런데 계속 도전한 이유는 음 충격적이기도 하고, 뭐라 해야 될까? 나름 오기라고 해야 될까? 내가 불합격이라고? 하는 오기 때문에 이번 세 번째 시험까지 치루었다. 감정 실린 시험이라고 볼 수 있죠.

괴짜가족 이사람 급으로 현실 부정

어제 정처기 실기가 있어서 공부를 제대로 하지 못해서 아 취소할까 생각도 했지만(5만원 ㅎ) 다행스럽게 합격이 나왔다.

마음을 비우니까 더 잘 쳐지네요^^

이번 PCCP 문제 성적으로는 730점을 받았는데, 750점까지가 3레벨이다. 3번까지는 금방 풀 수 있었고 마지막 문제에서 중복 처리까지 했었다면 4레벨이 나올 수 있었을 거 같은데 좀 아쉽스. 마지막 문제 나는 해시 셋에 정수 배열을 넣어서 중복 체크를 할려고 했었는데 생각해 보니까 자바에서 정수 배열은 무조건 다른 객체로 취급되어서 중복 체크를 할 수가 없었다. 그래서 다른 방법을 생각해보려 했지만, 시간이 얼마 남지 않아 좀 살짝 당황했었고 ㅎ, 결국 중복 처리를 못 한 4번 문제를 제출하게 되었다. 아, 중간에 그냥 멍 때리고 가만히 있었는데 좀 더 열심히 생각할걸.

+ 지금 생각해보니 걍 문자열로 좌표 값 저장해서 넣었어도 된 거 같은데 생각이 짧았다 ㅇㅈ

약간 4레벨까지 뭔가 얻을 수 있었는데, 못한 것 같아서 아쉽지만, PCCP는 일단 여기서 마무리해야 될 것 같다.(비싸욧)

카테캠 서류 제출 기간이 끝나서 더 이상 이 PCCP 성적을 제출할 수 는 없지만.

뭐 카테캠 덕에 자격증 하나 더 땄다고 생각해야겠다. 난 그냥 불합격으로 이걸 넘길 수 없는 오기 때문에 한 번 더 쳤다. 뭔가 부숴버리고 싶었다. 불합격으로 남기기 싶지 않았음. 결국 3레벨을 어찌저찌 획득하긴 하였다.

이렇게 카테캠 코테 만점 처리 성적을 받았는데, 카테캠 코테에서 문제를 못 풀면 웃기겠다. 올해 지금까지 정처기 필기랑 실기, SQLD랑 PCCP를 했는데, 올해 초는 자격증의 기간이었던 것 같다.

이제 남은 한 해는 나의 실제 개발 역량을 키우는 데 집중해야겄다.

김영한 스프링 핵심 원리 - 기본편 복기

홍준기 — Fri, 10 Apr 2026 01:16:20 +0900

약 3주 정도 전에 본 거 같은데 도움이 너무 되었지만 점점 기억에서 없어져 가는 거 같아 다시 복기 할 겸 강의 후기를 작성해보려고 한다.

이번 강의 한 줄 평: 기존 코드를 변경하지 않고 유연한 코드 변경을 하게 해주는 스프링. 꼈다 끼웠다.

1. 객체 지향 설계와 스프링

우선 첫 번째 색션에서는 어떻게 스프링이 탄생하게 되었는지에 대한 이야기를 해준다.

기본 복잡하고 사용하기 어렵고 비싼 서버를 사용하다가 진절머리난 로드 존슨이라는 분이 스프링을 만들어내게 된 서사를 들었다.

힘든 겨울이 지내고 나온 것이라고 하여 스프링(spring)이라고 하였나? 재밌다.

기존에는 책으로 출발하였는데 이게 오픈소스 프로젝트가 되고 점점 커져 스프링이 되었다고 한다.

옛날 이야기 듣듯이 들었다.

이후 스프링 개념 정의. 스프링과 스프링 부트의 차이점을 설명해주고

객체 지향의 특징을 여러 비유, 자동차라는 인터페이스와 테슬라, 아반떼와 같은 구현체들로 비유하며 설명해주었다. 현실 세계에 있는 객체 지향 구현법? 이랑 비유를 들어줘서 잘 와닿았다. 공연 무대. 로미오 역할이 인터페이스, 연기하는 사람이 구현.

이렇게 역할과 구현으로 구분하는 개념을 잘 확립할 수 있었다.

결국 스프링이 구현체가 변경되더라도 이 구현체와 연결되어 있는 다른 코드를 변경하지 않고 깔끔하고 쉽게 다형성을 관리해주는 단순 라이브러리가 아니라 Ioc(Inversion of Control)까지하는 프레임워크라는 것이다.

어떠한 제한 상황, 변화된 상황이 오더라도 깔끔하고 유연하게 대처할 수 있도록 하는 것인 듯하다.

2. 스프링 핵심 원리 이해1 - 예제 만들기

이 색션에서는 함께 순수 자바 코드를 한땀씩 짜보며 스프링이 없던 시절 결국 다다를 DIP 원칙과 OCP 원칙 준수의 불가능함을 보여주고 스프링의 필요성을 몸소 느끼게 해준다.

역할과 구현을 각각 구현하고 단일 책임의 원칙(SRP)을 잘 준수하며 코드 작성을 진행을 하지만 결국에는 구현체를 바꿔야할 시에 직접 코드를 수정해야하는 OCP 원칙 위배와, 결국 구현체에 의존하고 있는 DIP 원칙 위배를 보여준다.

3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

AppConfig라는 공연 기획자를 만들었다.

기존에는 배우가 다른 배우까지 섭외를 해야했지만 이제 배우(구현체)를 섭외하는 사람들 따로 배정하여 각 배우들은 자신의 연기에만 집중할 수 있도록 한 것이다.

변경이 필요한 코드를 AppConfig로 따로 빼두어 같이 관리하여 이 파일을 제외하고는 OCP를 만족할 수 있도록 하였다.

지금은 순수 자바로 구현하여서 구현체 변경시 AppConfig를 변경해야하지만 스프링 프레임워크 사용시 Ioc를 통해서 스프링이 자동으로 사용하는 구현체를 스프링 컨테이너에 빈으로 등록하여 OCP를 만족하며 코드를 작성할 수 있도록 해준다.

4. 스프링 컨테이너와 스프링 빈

이 색션에서는 공연 관리자(AppConfig), 스프링 컨테이너가 스프링 빈(배우)들을 어떻게 관리하고 있는지 내부 구조를 설명해주고 있다.

~~여긴 잘 기억 안 남 ㅎ~~

5. 싱글톤 컨테이너

이 색션에서는 스프링의 기본 빈 등록 방식인 싱글톤 패턴 설명으로 스프링 빈을 싱글톤 패턴으로 관리하여 하나의 객체를 사용하여 요청들에 효율적으로 응답하는 방법을 보여준다.

그러나 하나의 객체를 공유하는 만큼 Stateless는 지켜야함을 말해준다.

6. 컴포넌트 스캔

이 색션에서는 컴포넌트 스캔을 통해서 스프링 빈을 스프링 컨테이너에 자동 등록하는 법을 알아보았다 기존에는 AppConfig에서 수동으로 코드를 작성하여 등록해야했지만 @Component 어노테이션을 통해 자동화에 다다랐다.

또한 이를 @Autowired 어노테이션을 통해 스프링 컨테이너에 있는 스프링 빈 의존 관계 자동 주입을 하는 법도 알아보았다.

7. 의존 관계 자동 주입

이번 챕터에서는 다양한 의존 관계 주입 방법이 있지만 어떤 상황에 어떤 것이 가장 좋은 방법이 될지 알아보았다.

기본적으로는 스프링에 너무 의존하지 않고 불변성(final 사용)을 지키는 생성자 주입이 정석적이고 좋은 방법이라고 생각하면 될 듯하다.

필드 주입도 비슷하게 쓸 수 있을 것 같지만 스프링에서는 빈 생성 단계와 의존 관계 주입 단계가 나눠져 있기 때문에 final 속성을 달지 못해 불변성을 확보할 수 없다.

참고로 생성자 주입을 하게 되면 빈 생성 단계에서 의존 관계 주입이 발생한다.

8. 빈 생명주기 콜백

이 색션에서는

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존 관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

이 스프링 생명 주기에서 초기화 콜백, 소멸전 콜백에 대해 다루고 있다.

기본적으로 객체에 대한 초기화를 생성자에서 다 해서 생성자에게 무리를 주지 말고(생성자 주입을 하지 말라는 건 아님, 모든 걸 생성자에서 하지 말라는 말) 초기화 작업 같은 건 초기화 콜백에서 하라는 말이다.

또한 소멸전 콜백도 사용해 스프링 빈이 적절히 잘 종료될 수 있도록 해야한다.

9. 빈 스코프

마지막 색션에서는 스프링 컨테이너의 기본 싱글톤 패턴의 빈 관리말고 다른 빈 스코프에 대해서 알아본다.

싱글톤 패턴은 시작 후 끝나기 전까지 쭉, 프로토타입은 요청시에만 잠시 나타나는 일회성 빈, 그리고 웹 스코프는 요청이 들어올 때 잠시 생성되는 빈인데 서버 시작 시 해당 요청(고객)을 받을 담당원 빈 같은 것이다. 그래서 요청을 처리할 담당원을 연결해줄 프록시가 필요하다 <- HTTP 요청이 들어오면 담당원 연결해줄 수 있도록 대기해야함.

또한 싱글톤 패턴과 함께 프로토타입을 쓸 때의 주의점. 즉 싱글톤 빈이 프로토타입 빈을 주입 받게 되면 프로토타입처럼 일회성으로 계속 객체를 생성해야하지만, 싱글톤 패턴에 주입되어 계속 유지되는 현상이 있는데 이를 해결하는 Provider를 알아보았다. 이는 미리 프로토타입 빈을 싱글톤에 주입시켜 놓는 것이 아니라 필요할 때마다 컨테이너에서 가져와 생성하도록 해주는 대리인 역할이다.

강의 중 인텔리제이 단축키 꿀팁

커멘드 + X: 해당 줄 제거

커멘드 + D: 해당 줄 복사

커멘드 + 쉬프트 + 엔터: 문장 마무리

옵션 + 엔터: 뭐 안 된다 싶으면 이거

옵션 + 커멘드 + v: 함수에서 나온 값 받을 변수 생성

커멘드 + E: 이전 파일

출처: https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard?cid=325969

공공데이터포털 - 국제방송교류재단_뉴스기사API 활용하기

홍준기 — Tue, 31 Mar 2026 15:12:27 +0900

팀 프로젝트에서 외부에서 뉴스 정보를 가져오는 API를 살펴보고 있었다.

기존에는 네이버 뉴스 API를 통해서 뉴스 정보를 받아오려고 했는데 네이버 뉴스 API는 내용을 summary로 약 200자만 제공해서 해당 뉴스 내용을 정확히 파악할 수 없었다.

적은 양의 description 뉴스 원문을 들어가서 보지 않는 이상 정확한 정보를 얻을 수 없을 듯 함

빅카인즈나 딥서치 뉴스 API는 유료 구독을 해야하는 거 같아 지금 단계에서 바로 적용해보기는 좀 그랬다. 다른 API를 찾아보았다.

https://www.data.go.kr/index.do

그러다 공공데이터에서 뉴스 원문을 제공해주는 국제방송교류재단_뉴스기사API를 발견했다.

이 API를 활용한 후기는 거의 찾아볼 수 없었다.

해당 API 설명

파라미터로는 위처럼 3개가 있다(검색은 안 되는 듯)

이 API가 제공해주는 것으로

- 영어 원문 풀 스크립트 제공

https://www.data.go.kr/data/15108015/openapi.do