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

 

ABC 프로젝트 멘토링 8기

프로젝트 2주차 — 이론 학습 & 2차 멘토링, 그리고 하네스 엔지니어링 환경 구축

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

00

들어가며

2주차는 한마디로 ‘기초를 다지고 방향을 굳히는 주’였다. 1주차 사전교육에서 방향성을 잡았다면, 이번 주에는 프로젝트에 실제로 들어가는 핵심 기술들을 하나씩 직접 공부하면서 개념을 배우는 만드는 시간을 가졌다.

동시에 멘토님과 두 번째로 만나 식사를 겸한 회의를 진행했고, 그 자리에서 프로젝트의 서버 인프라, 역할 분담에 대해서 구체적인 합의를 마쳤다. 그리고 그 합의를 바탕으로 본격적인 개발의 토대가 될 AI 하네스 엔지니어링 환경 구축에 처음 손을 대기 시작했다.

이번 주 학습 키워드: 이미지 라벨링 → RAG → 파인튜닝 → 멀티모달 AI

01

이미지 라벨링 — 모델 성능은 결국 데이터에서 갈린다

이미지 라벨링은 AI가 학습할 수 있도록 이미지에 ‘정답’을 달아주는 작업이다. 사람이 보기엔 그냥 고양이 사진이지만, 모델 입장에서는 누군가 ‘여기부터 여기까지가 고양이’라고 표시해주지 않으면 아무 의미 없는 픽셀 덩어리일 뿐이다.

라벨링 방식도 목적에 따라 나뉜다. 이미지 전체에 하나의 클래스를 다는 분류용 라벨, 객체 위치를 사각형으로 잡는 바운딩 박스(Object Detection), 픽셀 단위로 영역을 구분하는 세그멘테이션(Segmentation)까지, 무엇을 만들 것인지에 따라 라벨의 형태와 비용이 완전히 달라진다는 점이 인상적이었다.

공부하면서 가장 크게 와닿은 건 ‘라벨링 품질이 곧 모델 품질’이라는 점이었다. 아무리 좋은 모델 구조를 써도 라벨이 부정확하면 결과는 무너진다. 그런데 이 작업이 전부 수작업이라 시간과 비용이 어마어마하게 든다. 지엔소프트의 Vision AI 파이프라인에서 우리가 노리는 병목 지점도 바로 여기였고, 이걸 멀티모달 AI로 자동·반자동화하는 게 이번 프로젝트의 핵심 가치라는 게 분명해졌다.

실제로 이미지 라벨링 자동화를 하는 것에 대한 가치가 높다고 생각하기에, 이번 프로젝트에 대해 더욱 진심으로 임하게 되었다.

(참고 블로그 : https://kr.appen.com/blog/image-annotation/)

02

RAG — 모델이 모르는 걸 답하게 하기

RAG(Retrieval-Augmented Generation)는 LLM이 학습하지 않은 최신 정보나 사내·도메인 데이터를 외부 지식베이스에서 검색해 답변에 끌어다 쓰게 하는 기법이다. 모델 자체를 다시 학습시키지 않고도 답변의 범위를 넓혀줄 수 있다는 게 핵심이다.

동작 흐름은 생각보다 직관적이었다. 문서를 잘게 쪼개 임베딩(벡터)으로 바꿔 벡터 DB에 저장해 두고, 질문이 들어오면 의미적으로 가까운 조각을 검색한 뒤, 그 내용을 프롬프트에 함께 넣어 모델이 근거를 보고 답하게 한다. 덕분에 할루시네이션이 줄어들고, 데이터 출처 추적도 가능해진다.

이 부분은 우리 프로젝트의 공공데이터 연계 구상과 바로 맞물렸다. 공공 API로 받아온 최신 데이터를 모델에 학습시키는 대신, RAG로 그때그때 검색해 붙이면 데이터가 바뀌어도 모델을 다시 손볼 필요가 없다. 임베디드에서 펌웨어를 다시 굽지 않고 외부 설정값만 바꿔 동작을 바꾸는 것과 비슷한 감각이라 이해가 빨랐다.

(참고 블로그 : https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/)

03

파인튜닝 — 모델 길들이기

파인튜닝은 이미 학습된 모델에 특정 도메인·태스크 데이터를 추가로 학습시켜, 우리가 원하는 형태로 행동을 고정시키는 작업이다. RAG가 지식의 범위를 넓히는 거라면, 파인튜닝은 특정 분야 성능을 향상하는 것이었다.

이는 방식도 폭이 넓었다. 모델 전체 파라미터를 다시 학습시키는 풀 파인튜닝은 효과가 크지만 비용과 데이터 요구량이 부담스럽고, 그래서 요즘은 LoRA 같은 PEFT(일부 파라미터만 효율적으로 학습) 기법이 많이 쓰인다는 걸 알게 됐다. 적은 자원으로도 도메인에 맞춰 모델을 조정할 수 있다는 점이 우리처럼 자원이 한정된 팀에게는 특히 중요한 포인트였다.

RAG

최신·외부 지식을 검색해 답변에 주입. 데이터가 자주 바뀌거나 출처가 중요할 때 유리. 모델 재학습 불필요.

파인튜닝

정해진 형식·말투·작업 패턴을 모델에 각인. 일관된 출력이 필요할 때 유리. 학습 데이터와 비용이 필요.

둘은 경쟁 관계가 아니라 역할이 다른 도구였다. 지식 확장은 RAG로, 특정 분야 성능 상향은 파인튜닝으로라는 기준을 잡고 나니, 우리 프로젝트에서 어느 지점에 무엇을 써야 할지가 훨씬 선명해졌다.

(참고 블로그 : https://kr.appen.com/blog/fine-tuning/)

04

멀티모달 AI — 텍스트 너머, 이미지까지 함께 이해하기

멀티모달 AI는 텍스트뿐 아니라 이미지, 음성, 영상 등 서로 다른 형태(modality)의 데이터를 함께 입력받아 통합적으로 이해하는 모델이다. 우리 프로젝트 이름에 ‘멀티모달’이 붙은 이유가 바로 이것이고, 이번 주 학습의 종착점이기도 했다.

특히 이미지와 자연어를 동시에 다루는 비전-언어 모델(Vision-Language Model)을 보면서, 사진을 던지면 그 안의 내용을 설명하고 질문에 답하는 흐름이 프로젝트의 ‘자연어 / 사진 분기 처리’ 구조와 그대로 겹친다는 걸 확인했다. 입력 성격에 따라 처리 경로를 나누고, 무거운 작업은 로컬에서 전처리해 흘려보낸다는 우리 아키텍처가 결국 멀티모달의 전형적인 패턴이었던 셈이다.

이론 학습을 마치며

이미지 라벨링으로 데이터의 중요성을 잡고, RAG로 지식을 붙이는 법을, 파인튜닝으로 모델을 길들이는 법을, 멀티모달로 이 모든 걸 하나로 묶는 법을 배웠다. 따로 떨어져 있던 개념들이 프로젝트라는 하나의 목표 아래에서 서로 연결되는 게 보였다.

무엇보다 ‘어떤 문제에 어떤 기술을 써야 하는가’를 판단하는 기준이 생겼다는 점이 가장 큰 수확이었다. 이제 멘토님과의 회의에서 나온 방향에 이 기준을 대보며 설계를 채워갈 차례였다.

 

2차 멘토링

 

05

멘토링 — 식사 자리와 함께한 회의

이번 주에는 모교 출신 선배이신 멘토님과 식사 자리를 가지며 두 번째 멘토링을 진행했다. 1차 때보다 한결 편한 분위기에서 이런저런 이야기를 나누다 보니, 자연스럽게 프로젝트 회의로 이어졌다. 밥을 먹으며 시작한 대화가 그대로 가장 밀도 높은 설계 회의가 됐다.

프로젝트 정체성과 저장소

먼저 우리 프로젝트의 정체성을 다시 정리했다. 멀티모달 AI 업무지원 플랫폼, 코드네임 llm-job-support. 자연어와 이미지를 함께 처리하는 멀티모달 구조를 핵심으로 삼고, 작업 공간은 DSM-Pixel GitHub Organization 산하 저장소에 통일하기로 했다.

AI 서버 인프라 확보

로컬 LLM을 직접 구동하려면 물리 서버가 필요했다. 교내 AI실 PC 대여 방안을 선생님께 문의해 서버를 확보하기로 했고, 확보되면 개발 목적으로 교내망에서 운용하되 외부 접근이 필요할 때는 Tailscale을 연동해 안전하게 쓰기로 정했다. 서버에서 돌릴 로컬 LLM 후보로는 Qwen, Kimi, LLaMA 등을 두고, 실제 사양이 확정되면 구동 가능한 모델을 선별하기로 했다.

아키텍처 — API 콜 기반 멀티모달 분기

AI 연동은 API 콜 방식으로만 요청하는 것을 원칙으로 잡았다. 입력이 자연어인지 이미지인지에 따라 처리 흐름을 분기하고, 대용량 데이터는 로컬 LLM 단에서 먼저 전처리 한 뒤 후속 처리로 넘겨 외부 API 호출의 비용과 부하를 줄이는 구조다. 공공데이터를 활용할 때는 한국 공공 API를 정리해 둔 오픈소스 자원을 래핑해 가져다 쓰기로 했다. 이번 주에 공부한 RAG와 멀티모달 개념이 이 설계에 그대로 들어맞아서, 이론과 실제가 맞물리는 게 스스로도 신기했다.

06

향후 계획과 역할 분담

회의 후반부는 각자 진행할 역할을 정하는 시간이었다.

1. 서버 자원 확보 사용 가능한 서버 자원을 최대한 끌어모으고, 대여 컨택을 진행한다.
2. 구동 가능 LLM 선정 확보한 서버 사양에 맞춰 실제로 돌릴 수 있는 로컬 LLM을 탐색·선정한다.
3. 요구 명세 정리 플랫폼이 무엇을 해야 하는지 requirements를 명확히 문서화한다.
4. 디자인 용역 의뢰 정리된 명세를 기반으로 외부 디자인 인력에게 화면·UX 설계를 맡긴다.
5. AI 모델 연동 구현 디자인 산출물을 기준으로 AI 연동이 가능한 형태로 내부 로직을 구현한다.

07

AI 하네스 엔지니어링 환경 구축

회의에서 정한 개발 방식의 핵심은 1차 멘토링에 이어 다시 강조된 하네스 엔지니어링이었다. AI가 결과물을 곧바로 동작 가능한 상태로 뱉어내도록, 명세와 실행 환경을 먼저 단단히 갖춰두는 접근이다. 이번 주부터 직접 환경을 세팅하며 기록을 남기기 시작했다.

Codex CLI 하네스 구축

Git 저장소에 따라 파일을 clone하여 local vsc ide에서 하네스 엔지니어링 구축을 위한 클로드 설정을 마쳤다.

Claude CLI 하네스 구축 (Claude Code)

하네스 엔지니어링 환경 구축은 Claude code cli 환경에서 간단한 프롬포트로 진행할 수 있었다.

모델은 Opus 4.8을 사용하였다.

여담으로 Fable 5버전은 미국 정부 지침에 따라 미국 외에 사용자는 사용에 제한이 생겼다.

(Claude Fable5 version news : https://zdnet.co.kr/view/?no=20260613201028)

Opus 4.8 주력 + 환경 구축

AI는 알아서 권한을 받고, 사용자에게 문제 재정의를 부탁하며 스스로 환경을 구축했다.

---

AI는 스스로 각 권한에 대해 접근하며 하네스 엔지니어링 환경을 구축했다.

---

모든 환경 구축을  마친 Claude Code cli 환경 화면이다.

토큰 스페어 Codex cli 구축

Claude Code cli의 토큰 부족을 대비하여 Codex cli 환경도 미리 구축해 두었다.

2주차를 마치며

이번 주를 지나며 가장 크게 느낀 건, 이론과 실제가 따로 노는 게 아니라는 점이었다. 이미지 라벨링·RAG·파인튜닝·멀티모달을 공부한 내용이 멘토링 회의에서 결정한 아키텍처에 그대로 박혀 들어가는 걸 직접 봤다. 개념을 알고 회의에 임하니, 멘토님의 설명이 흘려듣는 정보가 아니라 ‘내 손으로 만들 설계도’로 읽혔다.

또 하나, 좋은 결과물은 좋은 환경에서 나온다는 걸 다시 확인했다. 임베디드에서 회로와 디버깅 환경을 먼저 잡듯, AI 개발도 하네스 환경과 명세가 먼저라는 논리가 이해되기 시작했다.

다음 주부터는 이번에 구축한 하네스 환경을 토대로, 본격적인 프로젝트 프로토타입 구현에 들어가고자 한다.

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