멍발 이야기

SP(Stored Procedure, 저장 프로시저), 패치

멍발 — Mon, 30 Mar 2026 15:33:35 +0900

채용공고 JD에서 SP를 보고 궁금해서 찾아서 정리해보았다.

SP는 DB 내부에 저장된 프로그램으로 여러 SQL을 하나로 묶어서 실행할 수 있다.

(일종의 DB 안에서 돌아가는 함수랄까..)

함수 호출처럼 ①반복되는 로직을 재사용하거나 ②트랜잭션 처리하거나 ③비즈니스 로직 일부를 DB에서 처리할 때 사용한다.

-- 구조 예시
CREATE PROCEDURE GetUserOrders(IN userId INT)
BEGIN
    SELECT * FROM orders WHERE user_id = userId;
END;

※트랜잭션 처리

하나의 작업 단위를 묶어서 처리하는 것
ACID(Atomicity Consistency Isolation Durability, 원자성, 일관성, 격리성, 지속성)
데이터 무결성을 보장하기 위함
여러 SQL이 모두 성공하거나 모두 실패해야 한다.
Why? A → B한테 1000원을 송금했다. A 계좌에는 출금이 됐지만, B의 계좌에는 입금이 안됐다면?? 문제가 발생하니 입출금 둘 다 성공하면 COMMIT이 되도록, 하나라도 실패하면 ROLLBACK이 되도록 트랜잭션을 처리해야 한다.

※ 정산 배치(Batch job)

데이터를 한 번에 모아서 처리하는 것
실시간 ❌, 일괄 처리 ⭕
스케줄 기반으로 일정 시간마다 실행

성능 느린 SP를 개선하는 튜닝이나 복잡한 레거시 SP를 분석할 때 주로 AI를 사용한다고 한다.

Git으로 branch 따서 commit해서 pr 올려서 버전 관리하는 것처럼 DB도 버전 관리가 필요하다.

버전 관리로 인한 변경을 패치라고 한다.

Flyway, Liquidbase, Alembic과 같은 도구가 있고, 특히나 DB는 롤백이 어려우니 Migration Script 관리가 필수다.

요즘은 주로 SQL 쿼리문은 LLM이 생성을 해주고, SP대신 Airflow나 Spark 중심으로 처리하기도 한다. 하지만 여전히 금융이나 레거시 시스템은 SP 많이 사용한다.

BYOAI, AI가 전제인 시대, 우리는 무엇을 해야 할까?

멍발 — Fri, 13 Mar 2026 14:31:45 +0900

위 제목은 메가존클라우드의 BYOAI 흐름을 보면서 자연스럽게 떠오르는 질문이다.

AI를 내 직무에 어떻게 적용시키고, 관리하고 운영하고 확장할 것인지 기술 관점에서 정리해 보았다.

* BYOAI(Bring Your Own Artificial Intelligence) : 직원 개인이 필요와 선호로 하는 생성형 AI 도구를 회사 업무에 직접 가져와서 사용하는 것

1. BYOAI 시대, 개발자의 일하는 방식은 어떻게 바뀌나

조직 차원에서 통합 플랫폼을 제공하기 전에 이미 구성원들은 ChatGPT, Claude, Notion AI, GitHub Copilot 같은 도구를 쓰고 있다. “공식 도입”보다 “이미 쓰고 있는 걸 어떻게 관리할까”가 뒤따라오는 모양새다.

그러면 나는 내 직무를 어디까지 AI에게 맡길 것인가 ?

- 자동화 ?

- 초안 뼈대 ?

- task 단위의 프로세스 ?

AI를 활용하면서 “없이 못 사는 데모”로 소비하는 수준을 넘어서,나만의 “작은 운영 도구”로 자리 잡게 만드는 것이 첫 단계다.

2. AI가 99%를 담당하는 세상, 인간의 1%는 어디에 있을까

사실 이 질문은 AI 품질운영관리 직무 면접을 봤을 때 들었다. 이미 높은 정확도로 AI가 99%를 이루고 있는 세상에서 어떤 1%를 담당해야 할까?

문제 정의와 맥락 조율

“무엇을 자동화할 것인가, 무엇은 자동화하지 않을 것인가?”
“어떤 지표를 최적화해야 이 비즈니스/조직에 진짜 이익이 되는가?”
같은 모델이라도, 어떤 문제 정의와 KPI를 주느냐에 따라 완전히 다른 서비스가 나온다.

가치·윤리 판단

데이터 편향, 프라이버시, 공정성, 노동 구조 변화 같은 문제는 여전히 인간의 가치 판단이 필요하다.
“우리가 만든 시스템이 특정 집단을 일관되게 불리하게 만들고 있지 않은가?”, “설명 가능성 부족을 어디까지 허용할 것인가?” 같은 질문들.
- 여기서, 성인용 GPT가 나오고 있을 정도로 상업화되고 있는데, 기업에서 가치와 윤리 판단을 어느 선까지 지킬 수 있을까

서사와 설계

동일한 API/모델을 쓰더라도, 어떤 사용자 여정·스토리·UX로 엮느냐에 따라 제품의 생명력이 갈린다.
단순한 기능 조합이 아니라, “사용자가 왜 이 도구를 갈망하게 될지”를 설계하는 영역.

결국 모델을 만들고, AI를 사용하는 책임자는 '인간'이니 어떤 정답을 구해서 사람들에게 어떤 의미를 제공할 지 정하는 역할이 1%에 가까운 것 같다.

3. AI를 ‘관리’한다는 것: 거버넌스와 책임 구획

BYOAI 환경에서는 누구나 자기 도구를 들고 들어오기에, 조직은 “가치는 살리면서 리스크를 통제하는” AI 거버넌스가 중요해진다. 개발자 입장에서 AI 관리는 보통 다음 네 가지를 포함한다.

데이터/보안 경계 정의

어떤 데이터는 절대 외부 LLM에 넣지 않는다.
어떤 데이터는 사내 LLM·프록시를 통해서만 사용한다.
민감도 레벨에 따라 사용 가능한 AI 채널을 나누는 정책 설계.

품질 기준과 검증 루프

“AI가 내놓은 결과가 어느 정도면 ‘괜찮다’고 볼 것인가?”를 정의해야 한다.
예: 중요 보고서는 반드시 사람 2인 이상 검토, 특정 정확도/재현율 기준 미달 시 자동 알람 및 롤백, 휴먼-인-더-루프(HITL) 프로세스 적용 등.

로그와 추적 가능성

어떤 입력/프롬프트와 데이터 버전에서 어떤 결과가 나왔는지 추적할 수 있어야 한다.
모델 버전, 프롬프트 버전, 데이터 스냅샷, 시스템 컨피그를 함께 기록하는 형태의 “AI용 GitOps”가 필요하다.

책임 소재 정리

“AI가 그렇게 판단한 거라서…”로 끝나지 않는다.
어떤 의사결정은 시스템이, 어떤 의사결정은 사람이 최종 책임을 진다는 기준선을 미리 정의해야 한다.

마무리: “AI를 잘 쓰는 개발자”에서 “AI를 설계·운영하는 개발자”로

정리해 보면, BYOAI와 AI 네이티브 흐름 속에서

내 직무에서 어떤 작업을 AI에 맡길 것인지, 그리고 어느 수준까지 위임할 것인지.
AI가 대부분의 계산을 담당하는 세상에서, 나는 문제 정의·가치 판단·설계·관계라는 1%를 어떻게 키울 것인지.

위 2가지를 고민해보고 사용해야 한다고 본다.

참고자료

https://iting.co.kr/solution-air-studio-20260224/

ITing - AI를 써보기만 하는 조직과 운영하는 조직의 차이

이 글에서는 기업 내 AI 활용 현황을 점검해볼 수 있는 체크리스트부터, 실제 기업들과 진행한 AI 과제 도출 워크샵 사례, 그리고 기업 내 AI Control Tower 역할을 수행하는 AIR Studio까지 차례대로 살

iting.co.kr

https://www.megazone.com/resources/insight/report-byoai-20260224

[Report] BYOAI와 함께하는 스마트워크: 국내 기업 AI 활용 트렌드와 지속 가능한 성장을 위한 거버넌

국내 기업의 생성형 AI 활용이 빠르게 확산됨에 따라 BYOAI(Bring Your Own AI)에 대한 거버넌스 차원의 접근이 필요한 시점에 도달했습니다. 이 리포트는 기업이 준비해야 할 AI 거버넌스와 운영 전략

www.megazone.com

IT InfraStructure 기초_CS기술면접대비PDF

멍발 — Wed, 4 Mar 2026 17:51:51 +0900

※ LLM, 전공지식, 교재 등을 이용해서 정리한 내용입니다.

1. 시스템 아키텍처

IT 인프라의 전체적인 구조와 설계를 의미한다.

1) 집약형 아키텍처

모든 시스템 기능을 하나의 고성능 중앙 컴퓨터에서 처리하는 구조로, 은행의 계정계 시스템처럼 안정성과 일관성이 매우 중요한 기간 시스템에서 주로 사용한다.

장점
- 구성이 단순하고, 모든 자원이 한 곳에 있어서 관리가 편하다.
- 리소스 관리와 이중화를 통해서 높은 안정성과 성능 확보가 가능하다.
단점
- 고가의 대형 컴퓨터 도입 및 유지보수 비용이 많이 든다.
- 중앙 컴퓨터에 장애가 발생하면 전체 시스템이 마비된다.

집약형 아키텍처의 장단점을 설명하고, 어떤 시스템에 적합할지 설명해보아라.
집약형 아키텍처는 모든 처리를 중앙 서버에서 담당하여 관리가 편하고 데이터 일관성을 지키기 용이하다는 장점이 있다. 하지만, 확장성이 떨어지고 초기 도입 비용이 비싸다는 단점이 있다. 따라서 실시간 트랜잭션 처리의 무결성이 매우 중요한 은행 계정계 시스템이나 증권 거래 시스템 같은 곳에 적합하다.

2) 분할(분산)형 아키텍처

여러 대의 컴퓨터(서버)를 네트워크로 연결하여 각자 역할을 분담하고, 함께 협력하여 하나의 시스템처럼 동작하게 하는 구조이다. 대부분의 웹 서비스가 이 구조 사용 !

장점
- 저렴한 서버 여러 대로 구축할 수 있어 비용 효율적이다.
- 필요에 따라 서버를 추가하여 시스템을 쉽게 확장 가능하다.
- 서버 하나에 장애가 발생해도 다른 서버로 서비스를 계속할 수 있어 안정성이 높다.
단점
- 여러 서버를 관리해야 하므로 구조가 복잡하고 관리 포인트가 늘어난다.
- 데이터 동기화, 네트워크 지연 등 고려해야 할 점이 많다.
종류
- 수직 분할: 서버의 역할에 따라 분할하는 방식이다.
  - ex) 웹 서버, 애플리케이션 서버, DB 서버로 나누는 3계층 아키텍처
- 수평 분할: 동일한 역할을 하는 서버를 여러 대 두어 부하를 분산하는 방식이다.
  - ex) 웹 서버 10대 운영

최근 웹 서비스들이 대부분 분산 아키텍처를 채택하는 이유
분산 아키텍처는 저렴한 비용으로 시스템을 구축하고, 사용자가 급증했을 때 서버를 추가하는 방식으로 유연하게 확장이 가능하다.또한, 여러 서버에 부하를 분산시키고 일부 서버에 장애가 발생해도 서비스 중단 없이 운영할 수 있는 높은 가용성을 확보할 수 있다는 장점 때문에 널리 사용된다.

2. 서버 구성과 3계층 시스템

1) 서버의 기본 구성요소

CPU(중앙 처리 장치) : '두뇌', 모든 계산과 명령어 처리하는 담당
Memory(RAM) : CPU가 작업할 데이터를 임시로 저장하는 '작업공간', 속도가 빠르다.
I/O(Input/Ouput 장치) : 디스크(HDD, SSD) 등 데이터를 읽고 쓰거나 외부와 통신하는 장치
Bus : '통로', CPU, 메모리, I/O 장치 간에 데이터를 주고받는다. Bus의 대역폭(데이터 전송 능력)이 전체 시스템 성능에 큰 영향을 미친다.

2) 3계층 아키텍처(물데네전세표응)

분산 시스템에서 가장 보편적인 수직 분할 모델로, 시스템을 3개의 논리적인 계층으로 나눈 구조이다.

① 프레젠테이션 계층

역할: 사용자 와 가장 가까운 계층으로, 웹 브라우저 화면(UI)을 보여주고 사용자의 요청을 받는다.
처리: HTML, CSS, JavaScript 같은 정적 콘텐츠를 처리한다. 동적인 요청이 들어오면 애플리케이션 계층으로 전달한다.
Apache, Nginx

② 애플리케이션 계층

역할: 실제 비즈니스 로직을 수행하고, 데이터를 가공/처리하는 '몸통' 역할을 한다.
처리: 웹 서버로부터 받은 요청에 따라 동적 콘텐츠를 생성한다. 필요시 데이터 계층에 데이터 처리를 요청하고, 그 결과를 받아 웹 서버로 전달한다.
Tomcat, JBoss, Gunicorn

③ 데이터 계층

역할: 데이터를 효율적으로 저장, 관리, 검색한다.
처리: 애플리케이션 계층의 요청에 따라 데이터를 CRUD(생성, 읽기, 갱신, 삭제)한다.
MySQL, Oracle, PostgreSQL, MongoDB

3계층 아키텍처로 시스템을 구성했을 때의 장점
각 계층을 독립적으로 개발하고 관리할 수 있어 유지보수와 확장이 용이하다. 예를 들어, UI 디자인 변경은 프레젠테이션 계층만 수정하면 되고, 트래픽이 증가하면 웹 서버나 AP 서버만 선택적으로 증설할 수 있다. 데이터가 있는 DB 서버를 내부망에 두어 보안을 강화할 수 있다는 장점도 있다.

3. OS 필수 개념

1) 프로세스와 스레드

구분	프로세스 (Process)	스레드 (Thread)
정의	실행 중인 프로그램, 자원 할당의 단위	프로세스 내 실행 흐름의 단위
자원 공유	독립된 메모리 공간, 공유 안 함 (IPC 필요)	Stack을 제외한 메모리 공유 (Code, Data, Heap)
안정성	한 프로세스 장애가 다른 프로세스에 영향 없음	한 스레드 장애가 전체 프로세스에 영향 미침
통신 속도	IPC를 통해 통신하여 느림	메모리를 공유하므로 통신 속도가 빠름
생성/전환 비용	자원 할당이 필요해 무겁고 비용이 큼	자원을 공유하므로 가볍고 비용이 적음

프로세스와 스레드의 차이점을 설명하고, 멀티스레드를 사용하는 이유

프로세스는 독립된 자원을 할당받는 작업 단위이고, 스레드는 프로세스의 자원을 공유하며 실행되는 흐름의 단위라는 점이 다르다. 멀티 프로세스보다 멀티 스레드를 사용하면 자원을 공유하기 때문에 메모리를 절약할 수 있고, 스레드 간 통신 비용이 적으며, 컨텍스트 스위칭이 빨라 시스템 처리량을 높일 수 있다.

2) 커널

운영체제의 핵심으로, 하드웨어와 소프트웨어 사이의 중재자 역할을 한다. 항상 메모리에 상주하며 시스템의 모든 것을 제어한다.

주요 역할
- 프로세스 관리: 프로세스 생성, 종료, 스케줄링(CPU 시간 배분) 등을 담당한다.
- 메모리 관리: 각 프로세스에 메모리를 할당하고 회수하며, 가상 메모리를 관리한다.
- 파일 시스템 관리: 파일의 생성, 삭제, 읽기, 쓰기 등 디스크의 데이터 접근을 관리한다.
- I/O(입출력) 관리: 키보드, 디스크, 네트워크 카드 등 하드웨어 장치와의 통신을 제어한다.
- 시스템 콜 인터페이스: 응용 프로그램이 커널의 기능을 사용할 수 있도록 통로(System Call)를 제공한다.
- 보안 및 접근 제어: 사용자 권한을 확인하고 리소스에 대한 접근을 제어하여 시스템을 보호한다.

커널이 무엇이며, 왜 사용자 프로그램이 직접 하드웨어에 접근하지 않고 커널을 통해야만하는 이유
커널은 운영체제의 핵심으로, 하드웨어 자원을 관리하고 보호하는 역할을 한다. 커널은 시스템 콜이라는 정해진 통로를 통해서만 자원 접근을 허용하고, 이를 중재하고 관리함으로써 시스템의 안정성과 보안을 보장한다.

4. 웹 통신 흐름(www.naver.com 접속 과정)

사용자가 웹 브라우저 주소창에 www.naver.com을 입력하고 엔터를 치는 사이 나타나는 과정

멘토링 때 받은 질문인데, 전공 시간에 배운 내용이지만 답변을 제대로 못 했던..

1) 도메인 해석(Domain Name System)

브라우저는 www.naver.com이라는 도메인 이름의 실제 IP 주소를 알아야 한다.
먼저 브라우저 캐시, OS 캐시, 라우터 캐시 순으로 IP 주소가 저장되어 있는지 확인한다.
캐시에 없다면, 설정된 DNS 서버에 www.naver.com의 IP 주소를 물어본다.
DNS 서버는 125.000.000.000과 같은 IP 주소를 알려준다.

2) TCP/IP 연결(3-Way Hand shake)

주고받는 흐름만 이해하면 쉽다 !

브라우저(클라이언트)는 알아낸 네이버 서버의 IP 주소로 TCP 연결을 요청한다.
클라이언트 → 서버: "연결하고 싶어." (SYN)
서버 → 클라이언트: "받을 준비됐어." (SYN+ACK)
클라이언트 → 서버: "오케이, 이제 데이터 보낼게." (ACK)

3) HTTP 요청 및 처리

* 정적 콘텐츠 (로고 이미지 등): 웹 서버가 직접 해당 파일을 찾아 즉시 응답

* 동적 콘텐츠 (로그인 정보, 실시간 뉴스 등): 웹 서버는 요청을 AP 서버(WAS)로 전달

클라이언트 → 웹 서버: 연결된 통로를 통해 "네이버 메인 페이지(HTML)를 보여줘"라는 HTTP 요청 메시지를 보낸다.
웹 서버: 요청을 받고, 이것이 정적 콘텐츠인지 동적 콘텐츠인지 판단한다.
AP 서버: 요청을 처리하기 위해 비즈니스 로직을 수행합니다. 만약 데이터가 필요하면 DB 서버에 요청한다.
DB 서버: AP 서버의 요청에 따라 데이터를 조회하거나 변경한 후, 그 결과를 AP 서버에 반환한다.
AP 서버: DB 서버로부터 받은 데이터와 비즈니스 로직을 조합하여 최종적인 HTML 파일을 동적으로 생성한 후, 웹 서버로 전달한다.

4) HTTP 응답 및 렌더링

웹 서버 → 클라이언트: AP 서버로부터 받은 동적 콘텐츠(HTML)나 자신이 가지고 있던 정적 콘텐츠를 HTTP 응답 메시지에 담아 브라우저로 보낸다.

브라우저: 응답으로 받은 HTML 파일을 해석(파싱)하여 화면에 그리고(렌더링), 사용자는 네이버 메인 화면을 보게 된다.

5. 가상화 & 도커 컨테이너

가상화: 하나의 물리적 서버 위에 하이퍼바이저라는 소프트웨어를 이용해 여러 개의 독립적인 가상 컴퓨터(Virtual Machine)를 만드는 기술로, 각 VM은 자신만의 독립된 OS를 가진다.

도커 컨테이너 : OS 수준의 가상화 기술로, 호스트 OS의 커널을 공유하며, 애플리케이션과 그 실행에 필요한 라이브러리 등만 격리하여 실행하는 기술이다.

VM과 도커의 차이점을 설명하고, 어떤 상황에서 도커를 사용하는 것이 더 유리할까
VM은 하이퍼바이저 위에서 독립된 Guest OS를 실행하는 반면, 도커는 호스트 OS의 커널을 공유한다. 이로 인해 도커는 VM보다 훨씬 가볍고, 빠르며, 하나의 서버에 더 많은 애플리케이션을 배포할 수 있다. 특히 MSA(마이크로서비스 아키텍처) 환경에서 각 서비스를 독립적으로 빠르게 개발, 배포, 확장해야 할 때 도커 컨테이너를 사용하는 것이 매우 유리하다.

IT_인프라_면접_가이드.pdf

4.01MB

취준은 너무 어려워: 1월 마지막주 회고

멍발 — Tue, 10 Feb 2026 15:48:48 +0900

이제 시작한지 약 2주밖에 안 됐지만, 앞으로 위해 KPT 회고를 진행하고자 한다.
글을 보다가 파란색 밑줄로 표시된 부분은 링크가 포함된 부분이니, 혹시 궁금하다면 들어가서 읽어보는 걸 추천한다.

KEEP

2025.01

SK네트웍스 FAMILY AI CAMP 부트캠프가 끝나고 내가 생각했던 2026년은 많이 다르긴 하다. 사회경험을 많이 쌓을 줄 알았지만 금턴이란 말이 나오듯이
인턴도 요즘은 들어가기 힘든 취업 상황이 와버렸다. 특히나 아직도 수많은 개발자 지망생들이 몰려오고 있는 것을 알 수 있다.

서류를 수십장 넘게 써야 1-2곳 서류 합격이 오는 상황이라 이미 직감하고 체험형 인턴도 좋으니
서류를 많이 쓰고 있는 점은 잘하고 있다고 생각이 든다.
특히나, 면접 경험이 부족한 나에게 기회를 주는 곳을 잡아서 가야하기에 1차 서류 합격에 간절했던 것 같다.

PROBLEM

그러나 현실은 쉽게 다가오지 않았다.
면접 기회조차 받을 수 없도록 1차 합격률은 낮고, 지원자는 최소 천 명 이상이다.
자소서를 보면서 느낀거는 글을 잘 쓰진 않는 듯
그리고 지금은 초반이라 마스터 자소서 작성하기 위해서 포트폴리오 정리하느라 개발에는 시간을 거의 못 썼다.
그나마 코테 준비하면서 알고리즘 공부한 정도..
부족한 상황에서 자소서 컨설팅이 큰 힘이 됐다. 다른 사람의 자소서를 많이 읽고 봐도 형식은 갖추되, 결국 나만의 차별점이 있는 내용이 나와야 하니 정말 머리를 많이 썼다.

또한 도메인을 다양하게 준비하다 보니, 도메인 지식 쌓는 것도 부족했던 것 같다.

TRY

노션에 목표 겸 할 것을 적다보니, 이제 거의 대학교 졸업한 샘이고, 앞으로는 코딩테스트, 자기소개서, 프로젝트 개선에 집중해서 준비할 것 같다.
적어도 하루에 2시간은 개발하면서 감 버리지 않도록 하고, 합격자 분들과 스펙을 비교해봤을 때 어학이 필요하다고 생각하여 오픽까지 추가로 준비해야겠다.
그리고 웨비나를 들으면서 느낀 건데 계속해서 변화하는 기술에서 관심을 놓치 않는게 정말 중요한 것 같다. 뿐만 아니라 넓게 보려고 하는 것도 필요하다고 생각이 든다.

Data Lakehouse부터 Multi-Agent 구축까지, 성공적인 AI 도입을 위한 데이터 엔지니어링 청사진 그리기 오픈 세미나

멍발 — Thu, 29 Jan 2026 21:30:03 +0900

AI 에이전트 시대, 살아남는 '풀스택 데이터 엔지니어'의 길

최근 업무 자동화와 AI 에이전트에 대한 세미나를 참여하게 되었다. 이번 세미나에서는 에이전트가 내 업무를 대신해주면 내 자리는 어떻게 될까 하는 두려움도 잠시, 기술의 한계를 명확히 알고 이를 제어하는 능력이 곧 미래의 경쟁력임을 깨달은 시간이었습니다.

업무 자동화를 위한 에이전트를 만들수록 내 자리가 위태로워지는 것 같은 아이러니한 상황이 점점 오고 있다. 또, 모데링 커질수록 발생하는 환각을 어떻게 제어하고, 엔지니어로서 어떤 경쟁력을 갖춰야 하는지 세미나를 통해 듣게 되었다.

왜 Multi-Agent인가 ?

단일 모델에서는, 거대 모델 하나에 모든 역할을 맡기면 환각 현상이 심해지기 때문에, 역할별로 에이전트를 분리해서 만들어야 한다. Supervisor 체계를 통한 중앙제어 즉, 각 에이전트에게 명확한 페르소나와 임무를 부여해서 정확도를 높이는 전략을 사용하는 것을 알고 있자.

데이터 파이프라인의 실무적인 접근

데이터가 단순히 DB에 쌓이는 것이 아니라, 파이프라인을 타고 들어와서 벡터화되어 저장되는 과정의 중요성을 살펴보게 되었다. 특히 Snowflake와 같은 SaaS 솔루션을 기반으로 시멘틱 뷰를 구성하여, 데이터의 맥락을 에이전트에게 전달하는 방식은 실무에서 즉각적으로 도입해 볼 만한 강력한 방법론이었습니다.

취업적인 측면에서도 예전에는 기술적인 구현도 중요하지만, 결국 어떤 문제를 해결할 것인가가 핵심이기에 도메인의 깊이를 보는 것 같다. 엔지니어의 자리가 없어지는 것이 아니라, 도메인 지식을 바탕으로 더 고도화된 시스템을 설계하는 설계자로 진화해야 한다. 에이전트가 내 자리를 대신할까 봐 걱정하기보다, 에이전트를 자유자재로 부릴 수 있는 설계자가 되는 것. 그것이 지금 제가 준비해야 할 '풀스택 데이터 엔지니어'의 본질이라는 확신이 들었다.

추가로 보면 좋을 자료

https://aws.amazon.com/ko/blogs/tech/data-pipeline-for-datalake-and-ml-with-snowflake/

Amazon S3 데이터 레이크와 기계학습을 위한 Snowflake 통합 파이프라인 플랫폼 구축하기 | Amazon Web Ser

인공지능과 기계학습 기술의 상용화로, 기업들은 대량의 데이터를 효과적으로 수집, 저장, 관리할 필요성을 점차 인식하고 있습니다. 데이터 레이크(Data Lake)는 이러한 필요성에 부응하여, 다양

aws.amazon.com

https://www.samsungsds.com/kr/insights/the-evolution-and-future-of-licensing-models.html

AI 에이전트 시대의 비즈니스: 라이선스 모델의 진화와 미래 | 인사이트리포트 | 삼성SDS

AI 에이전트가 라이선스 패러다임에 미치는 역설적인 영향과, 이를 극복하기 위한 새로운 비즈니스 모델의 필요성을 심층적으로 분석합니다.

www.samsungsds.com

메가존클라우드 AWS re:Connect 2026 Webinar 후기

멍발 — Thu, 22 Jan 2026 17:20:05 +0900

참여 배경: AWS 외면할 수 없던 이유

부트캠프에서 Final Project를 진행하며 그토록 궁금해왔던 AWS DATA PIPELINE을 직접 설계하고 구현하게 되었다.

AWS를 처음 하면서 든 기대감도 있지만, '이거 잘못 누르면 비용 폭탄 맞는거 아니야?'라는 걱정도 있었지만..!

Automation Infrastructure의 개념과 사람이 반복적으로 운영하던 코드를 넘기는 구조에 흥미를 느껴서 이번 웨비나에 참여하게 되었다.

이번 웨비나는...

단순히 개발자용 웨비나가 아니라 앞으로 클라우드 환경에서 일하게 될 사람을 위한 웨비나에 가까워다. 기술 → 운영 → 비즈니스 의사결정으로 이어지는 흐름으로 AI가 어디까지 자동화가 가능하고, 사람은 어느 지점에서 책임을 지고, 중소기업에서 투가지용과 향휴 유지비용에서 어느정도 효과가 있을지 알 수 있었다.

Q&A에서 가장 많이 배운 포인트 정리

1. Bedrock vs RAG vs Nova Forge - 'AI 커스터마이징 레벨 차이'

RAG(Retrieval Augmented Generation)은 모델 그대로 질문 시 외부 문서를 붙여서 참고하는 방식의 말그대로 문서를 기반으로 증강시켜 찾는 것이며,

Fine-tuning은 모델의 가중치를 수정하여 특정 스타일과 업무에는 강해지지만 재앙적 망각(새로운 데이터/작업(Task)를 학습하면서, 이전에 배운 기존 지식을 잃어버리는 현상)의 리스크가 있지만,

Nova Forge는 모델 학습 중간 단계에서 기업 데이터를 직접 통합하여 기존 추론 능력은 유지시키면서 비즈니스 맥락을 강화시킬 수 있다고 하였다.

이 Q&A를 보면서 단순히 RAG를 써봤어요!가 끝이 아니라, 왜 RAG를 썼고, 왜 Fine-tuning이 아닌지를 설명할 수 있어야 한다는 사실을 다시 생각하게 되었다.

2. AI Agent - '자동화의 한계는 기술이 아닌 책임'

AI Agent가 안정적으로 할 수 있는 일과 반드시 사람이 개입해야 하는 일의 기준은?

AI가 잘하는 영역은 통합 데이터 기반 최적화이며 스케줄링, 초안 생성, 반복 작업이다. 여기서 사람은 안전, 신뢰, 최종 책임을 져야 하는데 AI가 다 해주고 신뢰한다는 마인드보단, 제안자 역할로 받아들여야 한다.

강사님께서 말씀하셨듯이 LLM은 숫자, 연산 능력이 뛰어나지만, 이 기술을 사용할 것인가는 사람에게 맡겨져 있다.

3. 보안 자동화 - '자동으로 바뀌는 건 코드가 아닌 PR'

IAM, 네트워크 보안 설정을 AI가 직접 바꾸는 것이 아닌, 문서화된 PR로 생성해서 Git History로 Audit Trail를 확보해서 최종 병합은 사람 승인을 본다면 통제 가능한 자동화가 되면서 Rollback도 가능하다.

PR은 사람과 사람간 체크인 줄 알았는데 AI도 개입한다면 2번에서 말한 것도 가능하면서 보안에도 신경쓸 수 있는 기회가 될 것 같다.

그동안 AWS 써봤어요, ETL 파이프라인을 만들어봤어요에서 끝나는 것이 아니라, 왜 그 선택을 하게 되었고 운영과 책임 구조를 설명할 수 있어야 한다는 것을 알게 되었다. 그리고 KIRO에 대한 내용도 나왔었는데, 6개월 간 KIRO를 사용해보면서 Task 단위로 분리하는데 생산성은 이미 체감했지만, 하나의 Task에서 발생한 변경 사항이 다음 Task에 설계 의도까지 포함해서 정확히 반영되는지에 대한 의구심은 들었따. KIRO도 단순 작업 나열이 아니라 하나의 Pipeline으로 Task 간 명확한 input/output을 정의하고 변경 시 영향받는 Task 범위를 명시하면 변경이 안전하게 전달되는 구조로 사용될 수 있지 않을까하는 생각도 들었다.

[플레이데이터 SK네트웍스 Family AI 캠프 18기] 6개월 이수 완료

멍발 — Fri, 16 Jan 2026 23:59:54 +0900

012

데이터 분석가(Data Analysis)를 꿈꾸면서 늘 들려왔던 소식은 '통계학과 위주로 뽑는다' 였다. 직무 역량이 부족해서 포기하려던 참에 위와 같은 모집 공고들을 보면서 데이터 분석에 AI 기술이 들어가면 EDA와 Modeling를 동시에 접해서 부족했던 점을 보완할 수 있지 않을까 싶은 생각이 들면서, 위와 같은 직무도 재밌겠다는 생각이 들어, 단순한 데이터 분석 교육이 아닌, AI, 데이터 엔지니어링, 서비스 개발을 모두 경험할 수 있는 과정을 통해 한 발짝 나아가야겠다고 다짐을 했다.

그래서 선택한 곳이 SK네트웍스 Family AI Camp x 플레이데이터 엔코아(6개월) 부트캠프였다.

이때부터 내 목표는 단순히 그래프를 그리고 인사이트를 얻는 분석가가 아니라, AI 모델을 설계하고, 데이터 파이프라인 위에 올릴 수 있는 분석가가 되는 것 !!!

012

오프라인으로 진행되다보니 무엇보다 늘어지지 않고 규칙적으로 출퇴근해서 부지런해졌다 !!

혼자 고민하면서 지낼 4학년 2학기를 같이 교육하는 사람들과 지내다보니 훨씬 더 재밌고 지하 1층에 구내식당도 있어서 잘 챙겨먹고, 정부 사업이다보니 6개월의 여정은 정해진 커리큘럼을 따르면서 다니게 되었다.

Phase 1. Setting, Python & SQL

- 개발 환경 세팅

- Python 자료구조, 함수, 클래스, 예외처리

- MySQL, DDL/DCL

- Crawling

대학교에서는 조교님께서 미리 다 설치를 해주셨고, 기존에 알고있던 것도 아닌 새로운 개발환경을 세팅할 때 노트북에 따라 랜덤하게 설치가 안 될 수도 있다는 후기를 들어서 정신을 바짝 차리고 했지만 결국 나도 Docker 세팅에서 식은땀을 흘렸다. 그때는 세팅 하나 잘못하면 나중에 사용할 때 흠이 될까봐 걱정돼서 따로 티스토리에 세팅 방법을 작성해놓고, 노션에도 정리해놓았다. 구글링해서 찾아보는 것도 추천 !

SQL 설계와 쿼리문을 작성할 줄 아는 것도 모델링만큼 중요하다..!

Phase 2. 데이터 분석

- Numpy, Pandas

- EDA

- Maplotlib, Seaborn

결측치와 이상치를 어떻게 처리하는지 전략의 중요성과 시각화해서 인사이트를 뽑아낼 줄 아는 것도 설득시키는 주요 도구라는 것을 깨달았다.

Phase 3. ML

- 지도학습

- Scaling, Feature Engineering

- 모델 평가, 앙상블

- HPO

타이타닉 데이터를 통해 자체 경진대회를 진행했을 때 ML을 할 때는 도메인, 데이터 info, Feature Engineering, 데이터 설계가 중요하다는 것을 알았다. 최종 프로젝트에서도 ML을 담당했었는데 주식 데이터처럼 실거래가 데이터를 이용해서 분류하는 모델링을 진행했었다. 분류모델을 진행했을 때 F1-Macro와 혼동행렬로 Score를 판별했는데 혼동행렬의 오차율을 줄일 수 있었던 방법은 무엇이 있었는지, 실제 거래액을 통해 AI가 판단까지 해줄 수 있다면 더 데이터를 더 활용할 수 있지 않았을까 하는 아쉬움이 조금 남았다. (물론, 파이널 피드백과 팀원의 의견을 재수용해서 다시 도전해볼 생각 !)

Phase 4. DL

- PyTorch Workflow

- CNN, RNN, LSTM

- NLP, 형태소 분석

- S2S, Transformer

딥러닝은 수학과 설계와 인내심의 끝이라고 생각한다. 하지만, GPU 환경이 잘 세팅된다면 생산성 있게 나올 모델이다. GPU 생산량과 함께 나아간다면 충분히 활용 가능성이 높은 기법이라고 생각하여 어렵지만 배워둬야 할 기술이라고 생각한다. 토이프로젝트에서 CTR-GCN 기반으로 딥러닝 모델을 다루게 되었는데 이미 구현된 코드 베이스 기반으로 실험을 진행했지만, 모델 구조 자체를 완전히 이해하기 어려웠고, 어떤 레이어가 학습되는지조차 명확하게 파악하지 못한 상태였다. Full Fine-tuning을 했는지 FC layer만 건드렸는지 정확하게 파악도 못 했었다. 딥러닝 결과는 잘 나왔지만, 결과보단 과정의 설계와 이해가 훨씬 중요하다는 것을 뒤늦게 깨달아서 논문 기반으로 아키텍처 다이어그램을 직접 그려보고, 각 블록의 역할을 수식과 코드로 동시에 이해해야 겠다고 생각했다. GPU 인프라와 함께 성장되는 기술인만큼 지금 배우지 않으면 뒤쳐질 수밖에 없는 영역이니 어렵지만 반드시 설계해보고 통제해봐야 한다.

Phase 5. LLM

- PEFT, LoRA

- Runpod

- LLM Fine-tuning

- LLM Evaluation

Pahse 6. LangChain & RAG

LLM은 단순 API 호출 영역이 아니라 시스템의 설계로 비용, 속도, 성능의 트레이드 오프를 모두 고려해야 해서 처음에는 설계하는데 시간도 오래걸리고 감도 안 잡혀서 정말 머리를 쥐어 뜯었다. 어떻게 해야 답변 속도를 빠르게 할 수 있을지 Human-in-the-loop 최고..

Phase 7. Dokcer / Web / AWS

- Docker, Linux

- Django, JS

- AWS

Project Story - 토이부터 단위를 거쳐 파이널까지

012

총 4회차의 단위 팀프로젝트를 거치고, 개별적으로 팀을 꾸린 토이 프로젝트와 마지막 파이널 프로젝트까지 프로젝트는 총 6개 진행하게 되었다. 팀으로 많이 진행됐던 프로젝트이기에 git을 이용한 협업을 많이 배우고 빠르게 익혀놔야겠다고 생각해서 정리해놓은 git 커맨드 내용을 공유해보겠다.

https://booming-lyric-dbc.notion.site/Git_team-2aa23a44f76a8043bfdddc0f279e04ec?source=copy_link

Git_team | Notion

1. 프로젝트 최초 세팅

booming-lyric-dbc.notion.site

생존법칙 발견

0123456

하루종일 앉아서 노트북의 LLM과 대화하고 있으니 생존 법칙 몇 가지 깨달았다. 이게 왜 안 되지..? 머리 터지겠다라는 생각이 들 땐 귀여운 것을 보고, 하늘도 보고, 커피를 마시면서 산책을 해보자~

https://github.com/yheeeon/SKN18-FINAL-1TEAM

GitHub - yheeeon/SKN18-FINAL-1TEAM

Contribute to yheeeon/SKN18-FINAL-1TEAM development by creating an account on GitHub.

github.com

LLM을 이용한 추천 시스템- 서울특별시 부동산 매물 추천 'Gozip' 파이널 프로젝트를 무사히 마무리하며 6개월 과정을 이수했다. 단순한 이론이나 실습 교육이 아닌 사고방식을 완전히 바꿔주었고 내가 무엇을 하고 싶은지 알 수 있었던 시간이었다.

데이터 분석가이지만, AI를 다룰 수 있는 사람, 그리고 데이터를 설계할 수 있는 사람이 되고 싶다면 다시 복습해보자~~

모두 취준이나 하는 일 다 잘 되길 바라면서 청년 복지, 취준, AI 관련 정리한 사이트도 공유해드립니다 ~

https://booming-lyric-dbc.notion.site/TIPS-2ea23a44f76a80798791c235dea9d786?source=copy_link

TIPS | Notion

※ url 다를 수 있습니다

booming-lyric-dbc.notion.site

RAG, VectorDB

멍발 — Sun, 19 Oct 2025 22:20:30 +0900

RAG?

1. 개념

찾아보고 답할 수 있도록 도와주는 검색 비서 역할

외부 지식 저장소(Vector DB) 등 관련 정보를 검색해서 LLM에 추가로 제공한 뒤, 정확하고 최신의 답변을 생성하는 구조

LLM의 문제점인 학습된 지식에만 의존하는 것이 아닌, 새로운 지식을 추가(증강)해서 LLM이 올바른 답변을 할 수 있도록

R(Retraieval): 어딘가에서 요청된 무언가를 가져오는 것 “검색”
A(Augmented) : 원래 것에 덧붙여서 좋아지게 함 “증강”
G(Generation) : 프롬프트(사용자의 질문)에 대한 응답을 텍스트로 생성함

2. 워크플로우

① 사용자가 질문(prompt 보냄) → 이 Query(질문)은 시스템으로 전달

② 시스템은 Query(질문) 내용을 분석해서 지식 저장소(Vector DB)에서 관련 문서/단락을 검색

검색 방식 : 문장 임베딩 → 벡터 유사도 검색

저장소 예시: FAISS, Chroma, Pinecone, Elasticsearch

③ 증강된 컨텍스트(관련 정보) 가져오기

검색 결과로 가장 관련성이 높은 텍스트 조각을 가져옴 = “증강된 컨텍스트”

LLM에게 추가로 참고자료를 붙여주는 과정

④ Prompt + Query + 증강된 컨텍스트 → LLM에 전달

질문 + 참고자료(검색된 관련 텍스트)를 함께 입력 받으면 → LLM이 구체적이고 근거 있는 답변 만듦

⑤ LLM이 최종 답변 생성 → 사용자에게 전달

LLM은 증강된 컨텍스트를 참고해서 최종적으로 자연어로 된 답변 생성해서 사용자에게 전달

“검색 기반의 근거 있는 응답”

3. 특징

확장성: LLM 모델 사이즈와 훈련 비용을 줄여서 지식 빠르게 확장 가능
정확성: 검색 기반의 사실성 있는 답변
제어 가능성: 정보 검색 + 맞춤화 가능, 질문의 의도를 측정해서 답변을 종합할 때 검색을 하면 근거있는 요소 참조 가능
설명 가능성: 모델이 예측하는데로 참조 역할
범용성 : QA, 요약, 대화 등 파인튜닝과 커스터마이즈(맞춤) 가능

4. 패러다임

“간단한 검색 및 생성 방식”

인덱싱
- 데이터 인덱싱
  - 파일 형식(pdf, html, word) → text 변환
- 청크 분할
  - tex → chunk(작은 조각)으로 분할
- 임베딩 및 인덱스 생성
  - text → 벡터 변환 → 유사성 계산
  - 사용자 질문 시 대량의 corpus를 실시간으로 인코딩 실시
  - corpus 청크와 임베딩 → key-value 쌍 형태로 저장
검색
- 사용자 입력 → 벡터 변환 → 벡터와 문서 블록의 벡터간 유사성 계산 → 상위 K 문서 블록 선택
생성
- 질문과 관련 문서 결합해서 new prompt 생성 → LLM이 이 정보를 기반으로 질문 답변

5. RAG 유무에 따른 LLM

RAG가 있으면 최신 정보, 문서 기반 답변, 정확도 향상 가능, 없으면 학습된 지식만으로 답변

구분 LLM 단독 RAG + LLM

지식 범위	사전 학습 지식만	문서 기반 최신 정보 활용 가능
정확성	최신 정보/특정 도메인 질문에서 낮음	검색 기반 참조 → 정확도 향상
문서 기반 QA	불가 또는 추정적	문서 기반 상세 답변 가능
확장성	모델 업데이트 필요	문서 추가만으로 확장 용이

4-1. Naive RAG

1️⃣Document Loaders

다양한 형태의 문서를 RAG 전용 객체로 불러들이는 모듈

문서 데이터 수집 → 사용 가능한 형식으로 변환

Page_content : 문서의 내용

Metadata : 문서 위치, 제목, 페이지 넘버 등

사용처: 웹 크롤링으로 특정 주제의 기사, 논문 수집 및 분석하여 요약 정보 생성

  기업 내부 문서 저장소에 필요한 문서 빠르게 검색 및 관련 정보 추출하여 보고서 자동 작성

2️⃣Text Splitters

토큰 제한이 있는 LLM이 여러 문장을 참고해서 답변 가능하도록 문서 분할

※ LangChain

긴 문서를 작은 단위인 청크(Chunk)로 나누는 텍스트 분리 도구 지원

청킹: 텍스트 분리 작업 → why? LLM 모델의 입력 토큰 개수가 정해져 있기 때문.

분할 목적
- 독립적인 의미의 청크로, 문장, 구절, 단락 등 문서 구조 기준으로 분할
- 청크의 크기 직접 조정 가능, 입력 크기와 비용 등을 고려해서 앱에 적합한 최적의 크기 결정 ← 단어 수, 문자 수 등을 기준으로 분할
분할 과정
- 문서 구조 파악: 문서의 헤더, 푸터, 페이지 번호, 섹션 제목 등을 식별하는 과정을 포함해서 문서 구조 파악
- 단위 선정: 페이지별, 섹션별, 문단별 등 문서 내용과 목적에 따라 단위 선정
- 단위 크기 선정: 문서를 몇 개의 토큰 단위로 나눌 것?
- 청크 오버랩: 분할된 끝 부분에서 맥락이 이어지도록 일부 겹쳐서 분할

CharacterTextSplitter
- 텍스트 청크로 분할하는 코드

from langchain_text_splitters import CharacterTextSplitter

text_splitter = CharacterTextSplitter(
    # 텍스트를 분할할 때 사용할 구분자를 지정합니다. 기본값은 "\n\n"입니다.
    separator="\n\n",
    # 분할된 텍스트 청크의 최대 크기를 지정합니다.
    chunk_size=250,
    # 분할된 텍스트 청크 간의 중복되는 문자 수를 지정합니다.
    chunk_overlap=50,
    # 텍스트의 길이를 계산하는 함수를 지정합니다.
    length_function=len,
    # 구분자가 정규식인지 여부를 지정합니다.
    is_separator_regex=False,
)

유의사항

문서를 \n으로 split
split 문서가 chunk_size 넘지 않으면 합치기
chunk_size가 아무리 작아도 \n으로 자른 단위가 최소 chunk가 됨
chunk_overlap의 기준은 글자 단위가 아닌, \n으로 자른 문단 기준이 됨
RecursiveCharacterTextSplitter최대 길이 초과하면 더 작은 단위로 나눌 수 있음순서
- \n 기준으로 split
- split한 문장이 chunk_size보다 크면 \n기준으로 자름
- \n 기준으로 자른 문장이 chunk_size보다 크면 “ “기준으로 자름
- ” “ 기준으로 자른 문장이 chunk_size보다 크면 “”기준으로 자름
작아질 때까지 문자 목록의 순서대로 텍스트 분할(단락 > 문장 > 단어순)
구분자 하나로 텍스트를 분리하는 것이 아닌, 여러 레벨의 구분자를 정의해서 텍스트를 나눔

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    # 청크 크기를 매우 작게 설정합니다. 예시를 위한 설정입니다.
    chunk_size=250,
    # 청크 간의 중복되는 문자 수를 설정합니다.
    chunk_overlap=50,
    # 문자열 길이를 계산하는 함수를 지정합니다.
    length_function=len,
    # 구분자로 정규식을 사용할지 여부를 설정합니다.
    is_separator_regex=False,
)

구분	사용 상황	특징
CharacterTextSplitter	텍스트가 짧고 단순할 때	빠르고 단순한 구분자 기반 분할
RecursiveCharacterTextSplitter	긴 텍스트나 복잡한 구조일 때	문맥 유지, 여러 구분자 활용, 길이 제한 조절 가능

TokenTextSplitter
- 텍스트를 토큰 수 기반으로 청크 생성 시 유용함
- OpenAI API는 해당 모델의 토크나이저 기준으로 분할 가능
SemanticChunker
- 의미적 유사성에 따라 텍스트를 분할함
- 텍스트를 문장 단위로 분할 → 3개 문장씩 그룹 → 임베딩 공간에서 유사한 문장 병합
- chunker는 문장을 분리할 시점을 결정해서 작동함 “Breakpoints”
- 분리 방식은 백분위수(Percentile)기반으로 분리
- 지정한 breakpoint_threshold_amout 표준편차보다 큰 차이가 있는 경우 Standard Deviation으로 분할

3️⃣ Vector Database

벡터를 고차원 포인트로 저장 및 검색

N차원 공간에서 가장 가까운 이웃을 빠르게 조회 가능

VectorDB vs RDB

구분	Vector DB : 의미 기반 검색용	RDB : 데이터 관리용
데이터 구조	텍스트·이미지 등에서 추출된 고차원 벡터(임베딩) 저장	행(Row)과 열(Column)로 구성된 표 형태
검색 방식	유사도 기반 검색 (의미가 비슷한 벡터 찾기)	정확한 값 일치 검색 (WHERE id=1)
주요 기능	가까운 이웃 검색(KNN), 범위 검색, 벡터 간 거리 계산	트랜잭션, 조인, 필터링 등
적합한 용도	AI 검색, 추천 시스템, RAG 등 맥락 기반 응용	금융, ERP, 전통적 데이터 관리
성능 및 확장성	비정형 데이터(고차원) 처리에 빠르고 확장성 높음	구조적 데이터에 최적화

VectorDB Embedding

text, image, mp4 → 벡터 형태로 변환
고차원 공간 → 저차원 공간 변환(차원 축소 시에도 data 정보와 패턴 보존)
동작 원리
- ① 인덱싱
  - 벡터를 알고리즘**(Random Projection, Product Quantization, Loclity-sensitive hashing, Hierarchical Navigable Small World**)으로 인덱싱하여 빠른 검색이 가능하도록 데이터 구조에 벡터를 매핑시킴
- ② 쿼리
- 유사도 메트릭(코사인 유사도, 유클리디안 거리, 내적)을 이용하여 가장 가까운 벡터 찾기
  - 코사인 유사도: 두 벡터간 각도 측정하여 유사성 판단, 얼마나 같은 방향인지, -1 ~ 1(유사성 ↑) 사이
  - 유클리디안 거리: 두 벡터 간 직선 거리 측정, 0 이상으로 거리 짧을수록 유사성 ↑
  - 내적 : 두 벡터 간 곱셈 연산으로 유사성 측정, 유사한 방향이면 +
  ③ 후처리
  - 최종 최근접 이웃 검색 후 후처리하여 최종 결과 반환
  - 벡터 검색 전 필터 적용 가능 → 사전 필터링, 사후 필터링
  - 사전 필터링: 벡터 검색 전 메타데이터 필터링 수행하여 검색량 줄임 but, 오버헤드 발생하여 쿼리 실행 느려짐
  - 사후 필터링: 벡터 검색 후 메타데이터 필터링 수행 → 연관된 모든 결과 추출 but, 오버헤드 발생하여 쿼리 실행 느려짐

※ Vector DB 요약

역할: 문서나 데이터를 벡터로 변환 후 저장 → 의미 기반 유사도 검색
구성 요소:
1. Vector Storage: 임베딩 벡터 저장
2. Indexing: 유사도 검색 가속(HNSW, IVF 등)
3. Similarity Search Engine: 쿼리 벡터와 저장 벡터 유사도 계산
4. Metadata Storage: 문서 정보, 필터링용 메타데이터 저장
데이터 추출 과정:
1. 문서 전처리 → 텍스트 분할
2. 임베딩 생성 → 벡터화
3. VectorDB 저장
4. 쿼리 → 벡터 변환 → Top-K 유사 문서 검색

4-2. Advancecd RAG

for 검색 및 생성 질 향상을 위한 사전 및 사후 검색 방법 포함

검색 전 절차(Pre-Retrieval Process)
- 데이터 인덱싱 최적화
- 임베딩
| 활용 사례 | • 의미 검색: 벡터 표현으로 유사한 텍스트를 검색 • 문서 분류: 특정 카테고리나 주제에 맞게 분류 • 텍스트 유사도 계산: 두 텍스트 간 거리 계산해서 유사성 평가 | | --- | --- | | 메소드 | - embed_documents : 문서 객체를 입력 받아 → 각 문서를 벡터 공간에 임베딩 주로, 대량의 텍스트 데이터를 뱊치 단위로 처리할 때 사용
- embed_query: 단일 텍스트 쿼리를 입력 받아 → 쿼리를 벡터 공간에 임베딩 사용자의 검색 쿼리 임베딩해서 문서 집합 내 쿼리와 유사한 내용 찾기 | | 모델 제공자 | - OpenAI : 텍스트의 임베딩 벡터 생성하는 API 제공
- Hugging Face : Transformers 라이브러리로 오픈소스 임베딩 모델 제공
- Google : Gemini, Gemma 등 언어 모델에 적용되는 임베딩 모델 제공 |
for 인덱싱 최적화 및 임베딩 → 검색 결과의 관련성 & 정확성 ↑
검색 후 절차(Post-Retrieval Process)검색 결과로 나온 문서를 한꺼번에 LLM에 제공하면 context window 크기 초과할 수 있어서 후처리 필요
- 순위 다시 매기기(ReRank) : 검색 결과 중 관련성이 가장 높은 프롬프트의 앞부분으로 재배치
- 프롬프트 압축(Prompt Compression): 후처리 시 중요하지 않은 맥락은 압축, 중요 문단은 강조
DB에서 검색된 주요 문맥과 질의 결합해서 LLM에 입력하는 과정
RAG 파이프라인 최적화
- 하이브리드 검색: 키워드 / 의미론적 / 벡터 검색과 같은 혼합 검색
- 재귀적 검색 및 쿼리 엔진: 초기 검색 단계 시 더 작은 문서 블록 획득하여 주요 의미 포착 → 후반 단계에서 많은 맥락 정보를 가진 더 큰 블록을 언어 모델에 제공
- HyDE: LLM이 생성한 문장이 사용자의 질의보다 임베딩 공간에 더 가까울 수 있음
효율성 + RAG 검색 시 맥락적 정보의 풍부함 균형 달성

4-3. Modular RAG

검색 모듈
- 특정 시나리오에 맞춰 LLM이 생성한 코드, SQL 등을 이용해서 직접 검색 수행
- 외부 검색 엔진, 텍스트 데이터, 테이블 데이터, 지식 그래프를 데이터 소스로 활용 가능
메모리 모듈
- 메모리 기능으로 검색 개선 → 현재 입력과 유사한 기억 찾음
추가 생성 모듈
- 중복 및 잡음 문제 대응, LLM 활용해서 검색을 위한 문서 별도 생성
태스크 적용 모듈
- 다운스트림 작업 적응하도록 조정
- zero-shot-promt or zero-shot-query 사용
정렬 모듈
- 별도의 학습 가능한 어댑터 추가해서 질의-텍스트 간 정렬 문제 해결
- PRCA, AAR, RRR 방법
검증 모듈
- 실제 문서와 질의 간 관련성 평가

IntrodutionLLM, LLM fine tuning

멍발 — Sun, 19 Oct 2025 22:11:58 +0900

1-1. Intordution LLM

임베딩

개념: 두 텍스트 사이의 관련성을 측정에 사용하도록 텍스트를 숫자로 표현

사용처: 검색, 클러스터링, 추천, 변칙 검색, 분류 작업

OpenAI

GPT-4o mini: 빠르고 가벼운 작업을 위한 저렴하고 지능적인 소형 모델

DALL-E 모델: 텍스트 설명 기반으로 이미지 생성

OpenAI 응용

clinet = OpenAI() # OpenAI 모듈로 생성된 인스턴스

LLM Chat의 주요 파라미터

항목 설명 주요 값/범위 의미 및 활용 포인트

messages	지금까지의 대화 메시지 목록	—	대화의 문맥을 구성함
frequency_penalty	기존 단어 빈도에 따른 반복 억제	-2.0 ~ 2.0	값이 높을수록 중복 표현 감소
max_tokens	생성할 최대 토큰 수	모델별 제한 내	응답 길이 제어
n	생성할 선택지(결과) 수	기본 1	1로 유지 시 비용 최소화
presence_penalty	새로운 주제 도입 확률 조정	-2.0 ~ 2.0	값이 높을수록 새로운 내용 생성 증가
response_format	출력 형식 지정	예: { "type": "json_object" }	JSON 모드 등 출력 구조 제어
seed	결과의 재현성 확보	임의 정수	같은 시드로 유사한 결과 생성 가능
temperature	출력의 무작위성 조절	0 ~ 2	높을수록 창의적, 낮을수록 일관적
top_p	핵심 샘플링(확률 기반 선택)	0 ~ 1	높은 값 → 다양성 증가 (보통 temperature와 함께 사용하지 않음)
stop sequence	모델의 토근 생성을 중지시키는 문자열		모델 응답의 길이와 구조 제어 가능

message
- 시스템 메시지: 챗봇에세 일종의 역할 부여
- 사용자 메시지: 사용자에게 전달할 내용
Streaming
- 실시간으로 데이터 송수신하는 프로세스
- 대화형 모델이 토큰 단위로 응답 생성, 사용자는 모델 응답 생성 과정을 실시간으로 볼 수 있음
이전 대화 기억하도록

주요 항목 설명

messages	대화 내역을 담는 리스트 (system, user, assistant 역할 구분)
stream=True	모델이 토큰 단위로 실시간 응답을 전송
response_format={"type": "json_object"}	모델 출력이 JSON 형식으로 보장됨
message_history	이전 대화를 기억하기 위한 히스토리 저장
print(chunk_content, end="")	스트리밍된 토큰을 실시간으로 출력
final_answer	전체 응답 텍스트를 조합하여 저장

LLM

Encoder - BERT

Decoder - GPT, BARD, LaMDA, LLaMA

Encdoer & Decoder - TS, BART

sLLM(small Large Language Model)

적은 매개변수와 훈련 데이터로 가성비 좋은 성능

모델 용량 적음

※ LLM 종류

Llama2

Llama3

Vicuna

KULLM, KoAIpaca : 한국어 파생 모델

Claude 3 : Haiku < Sonnet < Opus

SciSpace : 논문 작성 유용

Deepseek LLM

Hugging Face Transformers 기반의 LLM(언어모델)

항목 설명

model_id	사용할 언어모델의 이름 (예: "beomi/llama-2-ko-7b")
AutoTokenizer	문장을 모델이 이해할 수 있는 토큰(숫자)으로 변환
AutoModelForCausalLM	문장 생성용 언어모델 클래스
messages	system, user 역할을 포함한 대화 메시지 리스트
apply_chat_template()	대화형 프롬프트를 모델 입력 형식으로 변환
generate()	입력 토큰을 기반으로 새 텍스트(응답)를 생성
temperature, top_p	생성 다양성과 창의성 제어
eos_token_id	생성 종료 토큰 설정
decode()	숫자(토큰)를 사람이 읽을 수 있는 문자열로 변환

Caching(캐싱)

데이터를 한 번 계산하거나 생성한 뒤, 그 결과를 임시로 저장했다가, 같은 요청이 들어왔을 때 다시 계산하지 않고 재사용 함.

2-1. PEFT - Promp Learning.ipynb

prompt

hard prompting

자연어 형태의 이산적인 값

soft prompting

실수로 이뤄진 연속적인 값

언어 모델에서 사용

prompt based learning

cf) 보통 NLP는 pre-train로 추가 학습 데이터를 사용해서 Fine-tune을 거쳤지만

prompt based learning은 어떻게 언어모델의 입력값을 디자인해야 하는가. → 추가 파인튜닝 없이 사전학습 모델이 새로운 테스크 수행 가능하도록

*zero-/few-shot learning : 파인튜닝 없이 언어모델 사용 ← 추가 학습 데이터가 적을 때 사용

model tuning vs prompt tuning

model tuning
- 각 작업(task)마다 모델 전체를 새로 학습시켜서 테스크별로 모델이 따로 존재
→ 비용 / 시간 / 모델 용량 큼
prompt tuning
- 하나의 기본 모델을 그대로 두고, 각 작업마다 작은 프롬프트만 따로 학습시킴
→ 모델 전체를 건드리지 않고, 작업별 작은 프롬프트만 학습시켜서 가볍고 빠름
Fine-tuningex) 번역용, 요약용, 텍스트용 Transformer 별로 각 존재
→ 성능은 좋지만, 모델이 너무 많고 학습 비용이 큼
작업마다 전체 Transformer 모델을 새로 학습시킴
prefix-tuning
- 기존의 사전학습 모델은 그대로 두고 앞부분에 작은 Prefix(작업 힌트)만 붙임
ex) 번역 작업엔 번역용 prefix, 요약 작업에는 요약 prefix
→ 모델은 하나만 유지되고, prefix라는 작은 추가 파라미터만 학습되어 메모리와 시간 절약

요약

구분 수정 범위 학습량 속도 모델 수 특징

Model Tuning	모델 전체	매우 큼	느림	여러 개	전통적 방법
Prompt Tuning	입력 프롬프트 일부	작음	빠름	1개	텍스트 기반
Fine-tuning	Transformer 전체	큼	느림	여러 개	완전 학습
Prefix-tuning	입력 앞부분(Prefix)	매우 작음	빠름	1개	효율적 학습

prompt engineering vs prompt tuning

prompt engineering즉, 원하는 답변을 유도하도록 내용에 맞는 프롬프트를 작성
모델을 바꾸지 않고, 입력 문장(prompt)을 똑똑하게 설계해서 원하는 답변을 끌어냄
prompt tuninginput text 앞부분에 추가된 addition k토큰들만 dwonstream 태스크에서 학습 → 각 태스크마다 prompt 들을 저장해서 인퍼런스에서 mixed-task로 사용
사람이 프롬프트를 작성하지 않아도, 모델이 스스로 최적의 프롬프트를 학습하도록 함

PEFT(Parameter-Efficient Fine-Tuning)

입력 시퀀스 앞에 학습 가능한 연속적인 prefix 추가하는 방법

학습 가능한 prefix + 입력 토큰들

필요성 : 메모리 효율성, 멀티태스크 지원, 빠른 학습과 배포

PromptTuningConfig

임베딩 레벨에서 학습 가능한 가상 토큰을 추가하는 방법

<aside>

예제

필요 라이브러리 설치
라이브러리 import
dataset 로드
모델과 토크나이저 로드
PromptTuningConifg 설정

- `task_type`: 태스크 유형 (CAUSAL_LM 등)
- `num_virtual_tokens`: 가상 토큰 개수
- `token_dim`: 토큰 차원 크기
- `num_transformer_submodules`: 트랜스포머 서브모듈 수
- `num_attention_heads`: 어텐션 헤드 수
- `num_layers`: 레이어 수

데이터 전처리
학습 설정
모델 학습 시작
학습된 모델로 추론 </aside>

3-1. GGUF(Georgi Gerganov Unified Format)

딥러닝 모델 저장용 단일 파일 모맷(메타데이터, 텐서 데이터 저장)

LLM 모델 파라미터를 가볍고 효율적으로 저장하고 불러오기 위해 설계

즉, 여러 LLM 저장 방식을 하나로 통합한 표준 언어 모델 포맷

GGUF 파일 구조

구성 요소	설명
Header	버전, 모델 크기, 토큰 개수 등 기본 정보
Metadata	모델 이름, 학습 세부정보, vocab 등
Tensor Data	실제 모델 파라미터 (가중치)
Quantization Info	어떤 방식으로 압축(양자화)했는지에 대한 정보

양자화 관계(GGUF는 양자화 모델 저장에 최적화!)

비트 수	설명	용도
16bit (FP16)	고정밀 모델 (기본)	GPU 훈련용
8bit (Q8)	메모리 절약, 약간의 속도 향상	중간 수준
4bit (Q4_K_M, Q4_0)	고속, 저메모리 (최대 75% 절약)	로컬 실행용 (예: 노트북, Raspberry Pi 등)