[2026 ABC 프로젝트 멘토링 8기] 프로젝트 3주차

 

ABC 프로젝트 멘토링 8기

프로젝트 3주 차 — 서버 선정, API 통합 전략, 그리고 공공데이터 & RAG 개발

2026.06 지엔소프트(주) × 유클리드소프트

 

00

들어가며

3주 차부터는 본격적으로 프로젝트 개발에 들어갔다. 1~2주 차가 방향을 잡고 개념을 다지는 시간이었다면, 이번 주는 실제로 돌아가는 프로토타입을 제작하기 시작한 첫 주였다.

이번 주의 과제는 크게 세 가지였다. 첫째는 Claude를 상시 구동할 서버를 어떻게 마련할 것인가, 둘째는 AI를 어떤 방식으로 붙일지 정하는 API 통합 전략, 셋째는 분담된 역할에 따라 내가 맡은 공공데이터 & RAG 파트 개발이었다. 인프라부터 아키텍처, 실제 구현까지 한 주 안에 전부 손을 댄 셈이라 꽤 바쁘게 진행되었다.

이번 주 태스크: 서버 선정 → API 통합 전략 → 공공데이터 & RAG 개발

01

서버 — Claude를 상시 돌릴 서버 찾기

우리에게는 Claude를 상시 구동할 서버가 필요했다. 개발과 시연 양쪽을 모두 만족시켜야 했기 때문에 단순히 성능 좋은 머신 하나로 끝나는 문제가 아니었다. 내부망에서의 개발 편의성, 외부 시연 가능 여부, 그리고 비용까지 동시에 따져야 했다. 선택지는 크게 세 가지로 나뉘었다.

① Xquare 온프레미스

교내 데브옵스 동아리 서버 대여. 내부망 사용. 외부 시연 제약.

② AWS / Cloudflare

클라우드. 학생 플랜 활용. 토큰 비용 부담으로 보류.

③ 로컬 · 라즈베리파이 채택

API 콜 중심 서비스라 사양 충족. 현재 방식으로 선택.

① Xquare — 교내 데브옵스 동아리 서버

내가 다니는 대덕소프트웨어마이스터고에는 Xquare라는 데브옵스 전문 동아리가 있다. 여기서 서버를 대여할 수 있는데, AWS 같은 클라우드 서비스가 아니라 직접 물리 장비를 운용하는 온프레미스 개념이다. 성능과 자유도 면에서는 충분한 선택이지만 결정적인 제약이 있었다. Xquare는 교내 동아리라 학교 내부망을 사용하는데, 교육망 정책상 외부에서의 시연이 불가능했다. 개발은 되지만 중간발표나 최종 시연 때 외부에서 프로젝트를 보여줄 수 없다는 문제가 있었다.

② AWS / Cloudflare — 클라우드 활용

다음은 AWS, Cloudflare 같은 클라우드 서비스를 쓰는 방법이었다. 평소 개발과 학습·테스트는 로컬에서 진행하고, 외부 시연이 필요한 순간에만 학생 플랜의 기본 토큰을 활용해 클라우드로 띄우는 방식을 고안했다. 평소엔 비용을 아끼고 필요할 때만 쓰는 구조라 나쁘지 않은 선택이지만, 결국 토큰 비용 문제가 될 수 있다고 생각했다. AI 호출이 누적되면 학생 플랜 한도로는 감당이 어렵다고 판단해 일단 보류하기로 했다.

③ 로컬 PC · 라즈베리파이 — 현재 채택

마지막은 로컬 PC나 노트북, 혹은 라즈베리파이로 직접 서버를 여는 방식이었다. 우리 서비스는 무거운 모델을 직접 돌리는 게 아니라 API 콜로 AI를 호출하는 구조라서, 서버가 감당할 연산 부하 자체가 크지 않았다. 그렇다 보니 라즈베리파이 정도의 사양으로도 충분히 요건이 맞았고, 비용 부담도 거의 없었다. 임베디드 전공자로서 라즈베리파이를 다뤄본 경험이 있다는 점도 한몫했다. 결국 현재 단계에서는 이 방식을 채택했다.

물론 라즈베리파이가 확정된 방안은 아니다. 트래픽이나 동시 처리량이 늘어나면 다시 클라우드나 온프레미스 서비스로 전환될 가능성이 있다. 다만 프로토타입 단계에서 가장 빠르고 싸게 동작하는 환경을 확보할 수 있었다.

02

API 통합 — 어떻게 AI를 붙일 것인가

다음 문제로는 API AI 서비스에 관련된 문제였다. AI를 어떤 방식으로 우리 서비스에 붙일 것인가. 크게 두 갈래였다. 외부 모델을 API로 호출하는 방식과, 서버에서 모델을 직접 구동하는 방식.

API 호출 방식 채택

인프라 부담이 적고 최신 모델을 바로 활용. 비용은 호출량에 비례. 프로토타입 속도에 유리.

직접 구동 방식

비용을 통제하고 데이터 주권 확보. 다만 고사양 서버와 운영 부담이 큼.

회의를 통해 우리는 API 호출 방식으로 개발 방향을 잡았다. 라즈베리파이 서버로도 충분히 굴러가는 구조였고, 짧은 기간 안에 동작하는 결과물을 만들어야 하는 우리 팀 상황에서는 인프라에 발목 잡히지 않는 게 더 중요했다.

비용 문제와 현재의 임시 선택 — Gemini Key

다만 현실적인 벽이 있었다. Claude API는 품질이 좋지만 비용 부담이 있었다. 그래서 개발 초기 단계인 지금은 비용 효율을 고려해 Gemini API Key를 사용해 기능을 검증하고 있다. 핵심 로직을 먼저 안정화한 뒤, 모델은 나중에 교체하면 되는 구조로 설계해 두었다.

계획상으로는 다음 달에 Claude API Key와 Codex API Key를 추가로 결제해 키를 통합하고, 그때부터 프로젝트에 전면적으로 도입할 예정이다. 지금의 Gemini는 어디까지나 검증용 임시 AI이다, 그렇기 때문에 모델을 바꿔 끼워도 흔들리지 않게 호출 레이어를 추상화해 두는 데 신경을 썼다.

MCP & Skill, 그리고 워크플로우 자동화

단순 API 호출에서 그치지 않고, 1~2주 차에 배운 MCP와 Skill을 적극적으로 끼워 넣기로 했다. MCP로 외부 도구와 데이터 소스를 연결하고, Skill로 반복되는 작업 흐름을 표준화하면, AI가 단발성 응답기가 아니라 작업을 수행하는 에이전트로 동작한다. 여기에 더해 반복 파이프라인을 묶기 위한 n8n 도입도 검토 중이다. 노드 기반으로 자동화 흐름을 시각적으로 구성할 수 있어, AI 호출과 데이터 처리 단계를 깔끔하게 엮을 수 있을 것으로 기대하고 있다.

에이전트가 일을 ‘끝까지’ 하게 만들기 — Goal · Loop · Context

에이전트 구조를 설계하면서 가장 중요하게 본 세 가지는 목표(Goal), 반복(Loop), 맥락 기억(Context)이었다. 명확한 목표를 주고, 그 목표가 달성될 때까지 도구 호출과 검증을 반복하며, 이전 단계의 맥락을 잃지 않고 이어가게 만드는 것. 이 세 가지가 맞물려야 AI가 중간에 길을 잃지 않고 작업을 완결한다는 걸 실습하며 체감했다.

Claude에서 Goal과 Loop Skills를 추가하고, AI가 이전 대화의 context를 잊지 않도록 context 저장용 MCP도 추가하였다.

허브 디자인 & 이미지 속 객체 찾기 데모 

모든 서비스의 메인 허브인 홈 웹사이트 디자인 초안을 제작하였다. 웹 디자인은 사용자의 UX/UI를 고려하여 진행하였고, 메인 컬러를 블루로 선정하여 간단한 슬로건과 함께 제작하였다. 

 

그다음으로 API 통합 구조가 잡히자, 가장 먼저 만든 검증용 데모가 이미지 속 객체 찾기였다. 사진을 입력하면 그 안의 객체를 인식해 위치와 종류를 짚어주는 흐름인데, 1주 차부터 이야기해 온 멀티모달 처리와 이미지 라벨링 자동화의 가장 첫 구현 단계였다. 작은 데모였지만 자연어 / 이미지 분기 처리를 실제로 돌리며 개발이 잘 진행됨을 확인할 수 있었다.

이는 실제로 인터넷에서 찾은 포트홀 이미지를 직접 라벨링을 진행한 사진이다.

03

역할 분담 개발 — 내가 맡은 공공데이터 & RAG

이번 개발에서 내가 맡은 파트는 공공데이터 연계와 RAG였다. 2주 차에 RAG 개념을 한 번 정리해 둔 덕분에, 이해한 대로 개발 플로우는 제작하고 체계적이게 개발할 수 있었다.

먼저, RAG 이론을 확실히 다지고 시작했다

개발에 들어가기 전 RAG의 동작 흐름을 다시 한번 손으로 정리했다. 문서를 청크(chunk) 단위로 쪼개고, 임베딩으로 벡터화해 벡터 DB에 저장하고, 질문이 들어오면 의미적으로 가까운 청크를 검색해 프롬프트에 함께 넣어 답하게 하는 구조이다. 이를 이해하고 어디서 품질이 갈리는지를 분석하여 모델의 정확도를 높일 수 있다.

RAG v1 — 사용자가 넘긴 데이터 안에서만 답한다

첫 버전(v1)의 목표는 단순하고 명확했다. 사용자가 직접 넘겨준 데이터만 가지고 그 안에서 분석하고 질의응답하는 것. 모델이 자기가 학습한 일반 지식으로 넘겨짚는 게 아니라, 오직 주어진 자료에 근거해서만 답하게 만드는 방식이다. 사용감으로 치면 NotebookLM과 비슷한 결이다.

이렇게 출처를 사용자가 제공한 문서로 한정하는 방식을 흔히 폐쇄형(closed-domain) RAG 또는 소스 그 라운딩(source-grounded) 질의응답이라고 부른다. 답변이 항상 근거 문서에 묶여 있어 환각이 크게 줄고, 답변이 어느 자료에서 나왔는지 출처를 그대로 추적할 수 있다는 게 가장 큰 장점이었다.

현재 데모버전에서는 특별한 UX/UI 없이 기능만을 테스팅하기 위한 구조이다.

해당 이미에서 왼쪽에 파일을 업로드하면 오른쪽에서 파일에 관련되어 자연어로 질의응답을 할 수 있는 구조이다.

확장 — 직접 추가, 그리고 인터넷 검색까지

v1이 닫힌 자료 안에서만 도는 구조였다면, 다음 단계로 두 가지 확장을 붙였다. 하나는 사용자가 자료를 직접 추가할 수 있게 한 것, 다른 하나는 필요시 인터넷 검색으로 외부 정보까지 끌어오게 한 것이다. 이렇게 되면 폐쇄형에 머물지 않고, 가진 자료가 부족할 때 바깥에서 근거를 보강하는 개방형(open-domain) 흐름으로 자연스럽게 넓어진다. 공공데이터 API와 묶으면 최신 데이터를 그때그때 검색해 붙이는 RAG의 장점을 이용할 수 있다.

 이번 버전은 Claude로 생성한 간단한 UX/UI를 기반으로 웹 문서 추가 및 사용자 문서 추가 기능을 포함하는 버전이다.

개발하며 만난 문제와 개선

순조로웠다고는 했지만, 실제로 돌려보니 예상과 다른 지점들이 곳곳에서 튀어나왔다. 그중 기억에 남는 몇 가지를 문제와 개선으로 정리했다.

문제

청크를 너무 크게 잘랐더니 검색은 되는데 답변에 불필요한 내용까지 섞여 핵심이 흐려졌다.

 

 

 

개선

청크 크기와 겹침(overlap)을 조정해 한 조각이 하나의 의미 단위에 가깝게 끊기도록 다듬었다. 청크가 너무 크면 한 조각에 여러 주제가 섞여, 검색은 돼도 답변에 관계없는 내용까지 딸려 들어와 핵심이 흐려졌다. 그래서 문단 경계로 끊고 한 조각 크기(size)를 줄여, 한 청크가 하나의 의미 단위에 가깝게 잘리도록 다듬었다. 대신 경계에서 맥락이 끊기지 않게 약간의 겹침(overlap)을 둬, 잘린 문장이 정보를 잃지 않도록 했다.

문제

질문과 의미는 비슷한데 표현이 다른 문서가 검색에서 누락되는 경우가 있었다.

 

 

개선

검색 결과 상위 후보 수를 늘리고, 가져온 근거를 다시 한번 추려 답변에 넣는 단계를 추가했다. 실제로 TOP_K와 rank를 이용하여 문제를 해결하였다. 키워드가 정확히 일치하지 않아도 뜻이 비슷하면 찾도록 의미검색인 임베딩을 더해, 표현이 달라도 누락되지 않게 했다. 처음부터 좁게 4개만 뽑지 않고 후보를 넉넉히 8개까지 넓게 가져와 놓쳤을 문서를 일단 후보에 포함시켰다. 그 후보들을 다시 한번 관련도로 리랭킹을 통해 답변에 알맞은 4개만 답변 근거로 사용했다.

문제

근거 문서에 없는 질문에도 모델이 그럴듯하게 지어내는 환각이 간헐적으로 발생했다.

개선

근거가 부족하면 ‘자료에서 찾을 수 없다’고 답하도록 프롬프트를 강하게 묶고, 인터넷 검색으로 보강하는 경로를 열어 두었다. 실제로 AI API call 방식으로 개발을 진행하다보니 프롬포트를 구성하는 방식도 중요한 것을 알게되었다. 프로토타입을 제작할 때 포트홀과 같은 도로 관리 AI를 구상하고 개발하다보니 프롬포트 역시 그쪽으로 치우쳐진 모습이다.

실제 개발된 문서에서 Claude cli로 테스트를 진행한 결과 답변 context를 무려 60% 이상 줄이는 모습을 보여주었다.

이 과정을 거치며 RAG는 검색만 붙이면 완성되는 것이 아니라, 청크 설계부터 검색 정확도, 근거를 다루는 방식까지 디테일이 품질을 만든다는 걸 배웠다. 2주 차에 정리한 이론이 실제 코드 위에서 하나씩 검증되는 게 개발 내내 재미있었다.

3주차를 마치며

이번 주는 실제 개발을 하는 데에 중요하게 작용하는 것들을 정하는 중요한 시기였다. 어떤 서버를 둘지, AI를 어떻게 붙일지, 어떤 모델을 임시로 쓸지, 개발을 하면서 보다 합리적인 선택을 하는 데에 집중했다.

동시에 내가 맡은 RAG 파트가 실제로 동작하는 걸 보면서, 이론으로만 알던 개념을 실제로 제작해 보니 개발을 하는 데에 더욱 동기부여가 되었다.

다음 주부터는 이번에 잡은 인프라와 API 구조 위에서, 각자 맡은 파트를 합쳐 프로젝트 프로토타입을 본격적으로 완성해 나갈 예정이다.

#ABC프로젝트멘토링 #유클리드소프트 #고용노동부 #대한상공회의소 #미래내일일경험사업