In Hyuk Portfolio Homepage |

CS 지식의 정석

Wed, 02 Sep 2026 00:00:00 +0900

CS 강의는 네트워크 - 자료구조 - 운영체제 - 데이터베이스 - 개발자 필수지식 순으로 공부하자.

강의 내용을 전부 필기하기 보다는, AI Engineer 직군에 필요한 질문들 위주로 정리하자.

네트워크

Q1. 네트워크에 대해 아는 것이 있나요?

네트워크에서는 TCP/IP 기반 통신과 HTTP 통신에 대한 기본적인 내용을 알고 있습니다. TCP와 UDP는 전송 계층 프로토콜입니다. TCP는 연결 지향 방식으로 데이터의 순서와 전달을 보장하기 위해 Sequence Number, ACK, 재전송 같은 매커니즘을 사용합니다. 반면에 UDP는 비연결형으로 전달이나 순서를 보장하지 않는 대신 오버헤드가 작다는 특징이 있습니다. 애플리케이션 계층에서는 HTTP/HTTPS가 있고, 프로젝트에서 REST API를 구현하면서 클라이언트와 서버 간 Request/Response 방식으로 통신하는 경험을 했습니다.

Q2. `OSI 7 Layer에 대해서는 아시나요?

네. OSI 7 Layer는 네트워크 통신 과정을 7개의 계층으로 나눈 모델입니다. 아래부터 Physical, DataLink, Network, Transport, Session, Presentation, Application 계층으로 구성됩니다. 대표적으로 Network 계층인 3계층에서는 IP를 통해 목적지까지 데이터를 전달하고, Transport 계층인 4계층에서는 TCP와 UDP를 통해 프로세스 간 데이터 전송을 담당합니다. Application 계층인 7계층에는 HTTP나 DNS처럼 애플리케이션에서 사용하는 프로토콜이 있습니다.

Q3. 자료구조나 알고리즘에 대해 아는 것이 있나요?

네. 자료구조는 데이터를 효율적으로 저장하고 접근하기 위한 구조로 알고 있습니다. 대표적으로 Array, Linked List, Stack, Queue, Hash Table, Tree, Graph 등이 있습니다.

Python에서는 List와 Dictionary를 많이 사용했습니다. List는 동적 배열 기반이라 인덱스를 이용한 조회는 O(1) 이지만, 중간에 데이터를 삽입하거나 삭제하는 경우는 O(n) 이 걸릴 수 있습니다.

Dictionary는 Hash Table 기반의 Key-Value 자료구조이고, 일반적으로 조회, 삽입, 삭제가 평균 O(1) 입니다.

알고리즘에서는 정렬, 탐색, BFS/DFS 등을 알고 있으며, 문제에 맞는 알고리즘을 선택할 때는 데이터의 특성과 크기, 시간복잡도와 공간복잡도를 고려합니다.

Q4. 어떤 알고리즘을 사용하는 것이 더 좋은지 어떻게 판단하나요?

알고리즘을 선택할 때는 먼저 입력 데이터의 크기와 특성을 확인하고, Big-O 표기법을 통해 시간복잡도와 공간복잡도를 비교합니다.

예를 들어 데이터가 많다면 O(n^2) 알고리즘보다 O(nlogn) 알고리즘이 일반적으로 확장성 측면에서 유리합니다.

다만 Big-O가 더 좋다고 해서 항상 최적의 알고리즘인 것은 아니기 때문에, 실제 데이터의 크기나 메모리 사용량, 평균 및 최악의 시간복잡도, 구현 복잡도 등을 함께 고려해서 선택합니다.

최종 버전 확정 및 초안 배포

Fri, 21 Aug 2026 00:00:00 +0900

Version 03 Architecture

flowchart TD START([사용자 입력
prompt + pending + pendingOriginal
+ installedApps]) --> P{pending=true
AND pendingOriginal?} P -->|Yes| PR[Pending Resolver
gpt-4o-mini
LangChain] P -->|No| IC[Intent Classifier
ST + LogisticRegression
또는 heuristic
LLM 없음] PR --> A{5액션} A -->|CANCEL| C1([END
ok=false
failReason=cancelled
needsSupplement=false]) A -->|UNRESOLVED| C2([END
ok=false
needsSupplement=true
pending 유지]) A -->|CONTINUE / UPDATE| M[이전 명령 + 이번 입력
merge prompt] A -->|NEW_REQUEST| N[이번 prompt만] IC -->|reject
잡담| R([END
ok=false
failReason=chitchat
dialogIntent=reject
LLM 0회]) IC -->|extract| E M --> E[LLM Extractor
gpt-4o
function calling] N --> E E --> V[Rule Validator
코드] V -->|incomplete| ASK([END
ok=false
needsSupplement=true
재질문 / pending]) V -->|complete| MAP[App Mapper
embedding cosine
name → packageName] MAP -->|미매칭| U([END
ok=false
app_unresolved]) MAP -->|성공| OK([END
ok=true
규칙 저장])

Docker

앱 + 라이브러리 + 실행 방법을 상자에 넣어, 어디든 같은 방식으로 돌리게 하는 도구임.

현재 V3는 sentence-transformers와 같은 것들로 인해 의존성이 무거워 , EC2에 수동 pip보다는 Docker로 묶는 것이 좋다고 결정함.

우선 Docker + AWS ECR + App Runner를 활용해서, 1차적으로 배포를 먼저 진행함.

이후 부하 테스트 진행 후, 수정 사항 반영 후 재배포할 예정임.

AWS App Runner 운영 종료 이슈

이로 인해, Amazon Elastic Container Service로 배포를 진행함. (Tokyo)
배포 이후, /health 확인 완료

{
 "status": "ok",
 "promptEngine": "v3"
}

중간 점검

NotiLLM 관련

전체 소스코드에 주석 남기면서 과정을 하나하나 다시 뜯어보는 과정이 필요함
부하 테스트 반드시 진행할 것.
아직, 눈에 띄는 인사이트를 기반으로 한 발전 과정이 안보임. 너무 뻔하고 흔한 과정들로 발전시킨 것 같아, 해당 과정에 대한 고민도 필요할 것 같음.

기타

포스터 홀 개선 및 추가할 것.
코딩테스트 및 서류 및 면접 준비
통계 및 머신러닝 관련 공부도 지속적으로 진행.

Version 간 결과 비교/분석

Thu, 20 Aug 2026 00:00:00 +0900

LangGraph를 사용하기 이전(전부 4o모델) vs 모델 분기 비교 실험

결과

Metric	Baseline	Routing V2	Change (%)
Runs	85.0000	85.0000	0.0000
Total Cost ($)	0.8520	0.7277	-14.5903
Avg Cost ($)	0.0100	0.0086	-14.5903
Mean Latency (s)	4.6433	7.5294	+62.1563
P50 Latency (s)	4.2594	7.3486	+72.5282
P95 Latency (s)	7.2314	9.9255	+37.2561
P99 Latency (s)	9.4063	13.0560	+38.8006

LLM-based routing은 비용을 감소시켰지만 sequential LLM calls로 P95 latency가 너무 증가하는 문제점이 생겼다. Total Cost와 Latency의 문제를 둘 다 잡는 다른 방법에 대한 고민이 필요해보였다..

LLM Router 까지 두어서 LLM 모델을 두 번 처리하는 게 문제였기에, LLM Router를 제거하고 lightweight intent classifier로 대체 하려고 함.

기존 LLM Router 대신 sentenceTransformer + LogisticRegression 기반 classifier로 구현하고자 함.

`v1` vs `v2` vs `v3`

Metric	V1 Baseline	V2 LLM Router	V3 Classifier
Runs	85	85	85
Total Cost ($)	0.8557	0.7401	0.7224
Avg Cost / Run ($)	0.0101	0.0087	0.0085
Mean Latency (s)	4.1386	6.2194	3.3433
P50 Latency (s)	3.1119	5.4087	3.1164
P95 Latency (s)	7.4149	11.0379	7.0132
P99 Latency (s)	12.9387	11.9233	8.7200
API Calls	85	85	67
API Call Rate (%)	100.00	100.00	78.82
Extract Rule Correctness	0.8941	0.9048	0.9024
Extract Rule Correctness (if routed)	-	0.9048	0.8780
Route Correctness	-	1.0000	0.9756

V3는 V1 대비 비용 15.58%, 평균 Latency 19.22% 감소했고, LLM API 호출도 21.18% 절감함.
정확도는 V1 0.8941 → V3 0.9024로 유지·소폭 개선되어, 성능 저하 없이 비용과 응답 속도를 함께 개선함.

LangGraph 도입 검토 및 데이터셋 설계

Mon, 17 Aug 2026 00:00:00 +0900

`LangGraph` 도입하는 게 맞을까?

LangGraph를 비용 최적화 를 위해 도입하는 게 좋을 거 같음.

현재 version은 ChatGPT 4o 모델을 활용해 사용자 자연어 처리를 함.
- 현재 얼마의 비용이 청구되는 지에 대한 정확한 판단이 필요함. 문제 설정 필요
- 하지만 사용자 명령이 만약 안녕, ㅎ2, ㅎㅎ 라면? 굳이 모든 명령들을 전부 4o 모델로 처리할 필요가 있을까??
- 사용자의 명령을 중요도 낮음, 약간 중요, 매우 중요 등으로 나눠서, 이에 맞는 수준의 모델로 라우팅해주는 게 좋을 거 같음. 나중에 구현할 기능

Version 01.

flowchart TD START([사용자 입력
prompt + pending 플래그]) --> R{의도 라우터
gpt-4o-mini} R -->|잡담 / 인사 / ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
채팅 응답만]) R -->|알림 규칙 관련| P{pending?} P -->|false| E[규칙 추출
gpt-4o
extract_notification_rule] P -->|true| C[재질문 후속 분류
gpt-4o-mini] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N[이번 prompt만] M --> E N --> E E -->|tool 성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문 메시지
ok=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지])

Version 02.

flowchart TD START([사용자 입력
prompt + pending + pendingOriginal]) --> ENTRY{pending=true
AND pendingOriginal 있음?} ENTRY -->|Yes| RP[resolve_pending] ENTRY -->|No| R[의도 라우터
gpt-4o-mini
route_intent] R -->|chitchat
잡담/인사/ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
ok=false
failReason=chitchat
needsSupplement=false]) R -->|extract
알림 규칙 관련| RP RP --> C{pending 분류?
gpt-4o-mini} C -->|pending 아님| N[이번 prompt만] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N M --> E[규칙 추출
gpt-4o
function calling] N --> E E -->|성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문
ok=false
needsSupplement=true] E -->|충돌/앱 미해결 등| FAIL[실패
ok=false
needsSupplement=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지]) FAIL --> END4([END
pending 해제])

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항

A버전에 비해 B버전에서, 정확도가 많이 떨어지지 않는지
비용 및 속도가 얼마나 줄어드는지

Evaluation Dataset 구성 기준

Evaluation Dataset이 특정 유형에 편중되지 않도록, 주요 평가 축을 intent, time, target으로 나누고 각 카테고리 별 최소 케이스 수를 정의했습니다.

전체 Dataset: 85 cases
주요 카테고리 별 최소 5 cases 이상 확보
ok=true 케이스에서는 time, target 세부 유형이 모두 포함되도록 구성

Coverage 확인

모든 주요 카테고리에서 최소 5개 이상의 평가 케이스를 확보하여, 특정 입력 유형이 Dataset에서 완전히 누락되는 것을 방지했습니다.

축	값	개수	기준	상태
A. intent	`mute`	44	≥5	OK
A. intent	`allow`	14	≥5	OK
A. intent	`reject`	27	≥5	OK
B. time (ok=true 58건)	`duration`	38	≥5	OK
B. time	`until_absolute`	5	≥5	OK
B. time	`relative_delay`	5	≥5	OK
B. time	`daily`	5	≥5	OK
B. time	`weekly`	5	≥5	OK
C. target (ok=true 58건)	`all`	11	≥5	OK
C. target	`single_app`	29	≥5	OK
C. target	`multi_app`	5	≥5	OK
C. target	`content`	6	≥5	OK
C. target	`app_and_content`	7	≥5	OK

References

LangGraph 도입해야 한다면 내 프로젝트 서비스를 최적화시켜줄 수 있는 최적의 참조 논문은..?

Reasoning과 Action을 번갈아 수행하면서 외부 환경 / 도구와 상호작용하는 구조

같은 LLM이 Generator, Feedback Provider, Refiner 역할을 수행하면서 반복적으로 결과 개선
별도의 Supervised Training이나 RL 없이도 여러 task에서 one-shot generation보다 성능 개선 보고

자연어 reflection 형태로 memory에 저장하고 다음 attempt에 활용하는 구조
LangGraph에서 state / memory / retry loop를 설계할 때 굉장히 자연스럽게 연결

틀린 모델이 자기 답을 평가하면 틀릴 수 있음.
검색엔진, 코드 실행기 같은 외부 도구의 피드백을 사용해 검증

여러 reasoning candidate를 만들고 평가하면서 search / branching / backtracking

전체 문제를 먼저 작은 subtask로 나눈 뒤 실행
특히 Zero-shot CoT에서 발생하는 missing-step 등의 문제를 해결하려는 접근

reasoning과 tool observation을 분리

Tool Calling의 중요한 초기 연구
LLM이 언제 어떤 API를 사용할지를 결정하는 것 자체를 연구한 논문

같은 여러 Agent 간 interaction을 일반화한 프레임워크 연구
LLM, human input, tool을 조합한 customizable/conversable agent를 구성하고 다양한 conversation pattern을 정의

사용자 재질문 처리 전략

Sun, 16 Aug 2026 00:00:00 +0900

pending flag를 활용해 재질문 처리용 LLM 추가

backend/app/pending.py 추가

Sequence Diagram

이전 대화에서 사용자 질문 의도 파악 불가로 재질문 + 사용자 보충 질문 추가하는 경우

sequenceDiagram participant U as 사용자 participant App as Android PromptEngine participant API as FastAPI handle participant C as gpt-4o-mini 분류 participant E as gpt-4o 추출 U->>App: 카톡만 받아줘 App->>API: pending=false API->>E: extract E-->>API: ok=false + 재질문 API-->>App: ok=false App->>App: pendingOriginal 저장 U->>App: 1시간 App->>API: pending=true + pendingOriginal API->>C: 이전+이번 분류 C-->>API: supplement API->>E: 합친 prompt로 extract E-->>API: ok=true + 규칙 API-->>App: ok=true App->>App: 규칙 저장, pending clear

`classify_pending_turn` 함수

재질문 대기 중일 때, 이번 입력이 보충인지 새 명령인지 LLM으로 판별 한다.

pending_original: 재질문 전 사용자 명령
current_prompt: 재질문 후 사용자 입력
supplement: 이전 명령에 대한 보충 (예: 1시간)
new_command: 이전과 무관한 새 규칙

`resolve_extract_prompt` 함수

handle 앞에서 추출용 prompt 문자열을 만드는 진입점 역할을 한다.

prompt: 이번 사용자 입력
pending: 앱이 보낸 재질문 대기 여부
pending_original: 재질문 전 원문
(extract_prompt, classification): 추출 LLM에 넣을 문장 + 분류 결과 [None: 분류 안함]

추가 재질문 (Pending 처리) LLM이 실 기기에서 동작하는 지에 대한 테스트 진행 필요

파이썬을 활용한 머신러닝 딥러닝 입문

Sun, 16 Aug 2026 00:00:00 +0900

머신러닝 종류

지도 학습 : Data의 정답을 이는 경우
- 분류 (Classification)
- 회귀 (Regression)
비지도 학습 : Data의 정답을 모르는 경우
강화 학습 : 분류나 예측이 아닌 행동을 결정 의사결정
- 지도 학습 : Label(정답)을 아는 경우
  - Model에 학습시켜 새로운 Data에 대한 Output 예측
- 비지도 학습 : Training Data에 Label(정답)이 없음
  - Data의 패턴을 인식해 군집화 및 특징 추출 사람이 결과 해석

머신러닝에 사용되는 파이썬 라이브러리

Scikit-Learn

전통적 ML Tools:
- 벤치마크용 데이터셋 예제
- 데이터 전처리 함수들
- 지도 / 비지도 Model
- 모형 평가 및 선택

딥러닝에 사용되는 파이썬 라이브러리

Scikit-Learn, Tensorflow, Keras (Tensorflow에 대한 High-Level API. 더 쉽게 쓰기 위함), Pytorch

통계 분석 마스터 클래스

Sat, 15 Aug 2026 00:00:00 +0900

통계분석 마스터 클래스 배울 내용 소개

통계 분석을 통해 가정을 객관적으로 검증할 수 있음.

의사결정 Framework (PPDAC)
- P: Problem. Business Question
통계: 피어슨 통계
- 기술 통계.
  - Data Modeling. Data 확보. 데이터 분석 / 요약을 통해 인사이트를 뽑기 위한 방법
  - 값으로 요약. 시각화로 요약.
- 확률론.
  - 표본을 바탕으로 모집단을 설명하기 위한 방법들.
- 추론 통계.
  - ex. T-test (t-검정. 2개의 집단.), 카이검정, Anova, 회귀분석, 로지스틱 회귀분석

직관적 의사결정과 데이터 기반 의사결정

직관적 의사 결정

고객의 욕구, 경쟁자 전략, 기술 변화 등 관련 정보의 획득과 최적 대안 도출이 실제 경영상황에서는 완벽하게 얻어내기 힘든 경우가 많음
사이몬의 관리적 의사결정 모형: 완벽한 합리성보다는 제한된 합리성 하에서의 의사결정

baseline_v1_auto_map Evaluation 및 개선

Fri, 14 Aug 2026 00:00:00 +0900

Evaluation에서 확인된 부분을 기반으로 코드 수정

LangSmith를 기반으로 53문항의 테스트를 진행했고, 개선 수행.

에서는 여러 앱의 메타데이터도 같이 넣어서, context기반 cosine 유사도 계산 방식을 추천했으나, 메타데이터를 불러올 적절한 방법을 찾지 못함.

앱 관련 시스템 정보에는 메타데이터가 존재하지 않았음. 전부 null 필드.
Google Play Store에서 API 형태로 앱의 Description을 가져오는 것도 생각해 보았으나, 서비스가 너무 무거워질 것으로 예상되어 유의어 사전을 만드는 방식을 채택함.

코드 개선 전, Baseline 테스트 결과

총 53개 테스트 데이터
정답률 : 0.87

Error Case 1.

“카톡 2분만 받지마”

output
- “ok”: false
ground truth
- 현재 시간부터 2분동안 카톡을 받지 않도록 설정함.
피드백
- 시스템 프롬프트에 현재 시간이 정의되어 있지 않으면 현재 시간 부터라는 내용을 추가해 넣어줘야 할 거 같음.

Error Case 2.

“지금부터 1시간 문자만 받아줘”

output
- 문자 앱이 아닌 com.samsung.android.mdecservice 다른 앱의 cosine 유사도가 가장 높았고, 이 마저도 0.5 이하여서 ok=false 반환.
ground truth
- packages에 “com.samsung.android.messaging"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류. “문자"와 “메시지"의 코사인 유사도가 낮게 나옴.

Error Case 3.

“지금부터 2시간 문자 스팸 알림 받지마”

output
- name 필드는 비어있고, content=[“문자”, “스팸”]
ground truth
- name=“메시지”, content=“스팸” 이 담겨야 함.
피드백
- 스팸이 name인지 앞서 나온 “문자"에 대한 “스팸"인지 확인할 수 있어야 함.

Error Case 4.

“지금부터 2시간 문자에서 ‘스팸’이라는 단어가 들어간 알림 받지마”

output
- 문자 앱이 아닌 com.samsung.android.mdecservice 다른 앱의 cosine 유사도가 가장 높았고, 이 마저도 0.5 이하여서 ok=false 반환.
ground truth
- packages에 “com.samsung.android.messaging"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류. “문자"와 “메시지"의 코사인 유사도가 낮게 나옴.

Error Case 5.

“지금부터 2시간 플레이스토어 업데이트 알림 받지마”

output
- com.android.vending 앱이 아닌 com.samsung.android.smartsuggestions 다른 앱의 cosine 유사도가 가장 높았음. 즉, 잘못된 앱의 이름을 설정함.
ground truth
- packages에 “com.android.vending"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류.

Error Case 5. [제외 케이스]

“지금부터 12시간 카톡 홍보, 프로모션이나 카드 알림은 띄우지마”

output
- name=“카카오톡”, content=“홍보, 프로모션, 카드” 가 들어감.
ground truth
- 현재 구조로는 해결이 불가능. ok=false
피드백
- 아직 해결 불가능.

Error Case 6.

“지금부터 5분 카톡 메세지 알림 받지마”

output
- name=“카카오톡”, content=“메세지” 가 들어감.
ground truth
- “카톡 메세지” 라고 말을 해도, 사실상 “카톡"을 의미하는 것이므로, name=“카카오톡” 이고 content는 비워야 함.
피드백
- 추출 오류.

문제점

“다른 기기에서도 전화/문자하기”(“com.samsung.android.mdecservice”) 와 “메시지”(“com.samsung.android.messaging”)가 있을 때, “문자"라는 단어가 “메시지"에 매핑되도록 하려면 어떻게 해야 하나?
“퍼스널 데이터 인텔리전스”(“com.samsung.android.smartsuggestions”) 와 “Play 스토어”(“com.android.vending”)가 있을 때, “플레이스토어"라는 단어가 “Play 스토어"에 매핑되도록 하려면 어떻게 해야 하나?

나의 해결책

처음에는 사이트에서 관련 메타데이터를 찾을 수 있는 방법을 고민함.
- 하지만 해당 필드가 전부 비어있는 값으로 나와 사용할 수 없었음.
- 따라서 유의어 사전 을 만드는 방법을 채택함.
  1. LLM이 뽑은 **앱 이름(name, “문자”)**으로 찾음
  2. 유의어 사전에 그 그룹 단어를 [“문자”, “메시지”, “SMS”, …] 로 확장
  3. (확장된 각 단어) X (설치 앱 각 라벨) : Cosine
  4. 각 앱마다 그 중 가장 높은 점수로 대표
  5. 전 앱 중 최고 + Threshold 로 최종 package 결정
시스템 프롬프트 few-shot learning 추가

...
- **"N분(만/동안/간) …" 처럼 기간만 있고 시작 시각이 없으면 → 지금부터. delivery=현재, expires=현재+N분**
 - 예: "카톡 2분만 받지마", "카톡 5분동안 받지마" 모두 현재부터.
...

코드 개선 이후

정답률 : 0.91

“매일 밤 10시부터 새벽 4시까지 조용히”

“매일 밤 10시부터 아침 6시까지 모든 알림 받지마”

주기성 명령의 경우 delivery와 expires 시간 계산에서 예측값과 실제값이 다르게 나옴. 하지만 이것이 결과에는 영향을 주지 않음
- 프롬프트 변경을 통해 해결함.
  - 구간 전: 다음 회차
  - 구간 안: 진행 중 회차
  - 구간 끝남: 다음 밤 회차
  - 지난 회차 금지. overrnight면 expires = delivery + 1

Coding Test

Fri, 14 Aug 2026 00:00:00 +0900

프로그래머스

[해시] 전화번호 목록

접근 방법

시간복잡도가 지금은 O(N^2)라서 O(NlongN)으로 가는 방법에 대해서 고민 필요.

풀이 전략

ㅇㅇㅇ

접근 방법

ㅇㅇㅇ

풀이 전략

ㅇㅇㅇ

접근 방법

ㅇㅇㅇ

풀이 전략

ㅇㅇㅇ

LangSmith를 활용한 Evaluation 설계

Wed, 12 Aug 2026 00:00:00 +0900

Phoenix 기반 DeepLearningAI의 강의 코드를 참조해, 동일한 로직을 LangSmith로 구현함

Evaluation 설명

기존 시스템은 Kotlin 기반 Android 앱 내부의 PromptEngine.kt에서 자연어 입력을 LLM에 전달하고, Function Calling 결과를 바탕으로 알림 규칙을 생성하는 구조였다.

하지만 Android 플랫폼 로직과 LLM Extraction 로직이 하나의 코드에 강하게 결합되어 있어, LLM 성능만 독립적으로 평가하거나 Prompt 변경에 따른 성능 변화를 반복적으로 검증하기 어려운 구조 였다.

이에 기존 PromptEngine.kt에서 수행하던 자연어 조건 추출 로직을 분리하여, FastAPI + LangChain 기반의 AI Backend 로 이전하였다.

이를 통해 Android 앱은 사용자 입력을 AI Backend로 전달하고 결과를 받아 실제 알림 규칙으로 저장하는 역할에 집중하고, AI Backend에서는 LLM 호출, Function Calling, 결과 후처리 및 Evaluation을 독립적으로 수행할 수 있도록 구조를 분리하였다.

FastAPI 기반 AI Backend 부분 설명

FastAPI 기반 AI Backend의 핵심 로직은 크게 다음 4단계 로 구성하였다.

시스템 프롬프트 few shot learning 관련 코드
현재 시간을 지정해 function calling용 Tool Schema 리스트를 return 해주는 코드
LLM의 추론으로 반환된 Function Calling 결과를 내 서비스에서 사용하기 쉽도록 후처리하는 코드
메인 처리 로직 : (사용자 프롬프트, 현재 시간) 입력 -> (targetFixed, condition 포함한 Response Json) 반환

AI Backend 코드에 대한 Kotlin 연결부 : FastAPI LLM 서버에 요청하고 결과를 기존 Android 규칙 시스템에 연결

LangSmith를 활용한 LLM 실행 추적

LangSmith를 활용해서 현재 LangChain 기반 LLM Function Calling을 추적 했다.

handle 함수안의 두 ChatOpenAI.invoke 함수를 자동으로 추적하고 있는 것을 확인할 수 있었다!

Code-based Evaluation 설계 과정

evals 폴더 생성 후, 평가에 사용할 샘플 5개 JSON 데이터셋(input, output) 생성
dataset_upload.py : Jsonl 확장자 파일에서 정의한 데이터셋을 LangSmith Dataset에 업로드
System Few Shot 부분도 전체적으로 어떻게 프롬프팅 했는지 점검해봐야 함.
evaluators.py 파일과 run_experiment.py 파일 생성해서 LangSmith 기반 테스트 진행함. (정답률 : 100%, 샘플 5개 적용)

Evaluators.py 코드에 대해서..

def extract_rule_correctness(
 outputs: dict,
 reference_outputs: dict,
) -> dict:

 """
 ExtractRule JSON 정답 일치도 (binary code metric).
 LangSmith evaluate()가 Example마다 호출:
 outputs ← Target(handle) 반환값
 reference_outputs ← Dataset example.outputs
 Returns:
 key/score 형태 dict — UI 지표명과 0~1 점수
 comment — 필드별 pass/fail (디버깅용)

 delivery/expires 는 currentTime이 고정이므로 ISO 문자열 exact match.
 """

 pred = outputs or {}
 exp = reference_outputs or {}
 checks: dict[str, bool] = {}

 # ok (성공/실패) — router 성격
 checks["ok"] = bool(pred.get("ok")) == bool(exp.get("ok"))

 # 정답이 실패면 구조 필드 없음 → ok만 채점
 # 예: "카톡만 받아줘" (시간 없음) → ok=false
 if not exp.get("ok"):
 return {
 "key": "extract_rule_correctness",
 "score": 1.0 if checks["ok"] else 0.0,
 "comment": str(checks),
 }

 # 성공 정답 → targetFixed / condition 필드 비교
 # 정답에 있는 키만 검사 (부분 reference 허용)
 pt = pred.get("targetFixed") or {}
 et = exp.get("targetFixed") or {}
 pc = pred.get("condition") or {}
 ec = exp.get("condition") or {}

 if "mute" in et:
 checks["mute"] = bool(pt.get("mute")) == bool(et.get("mute"))
 if "name" in et:
 checks["name"] = _as_set(pt.get("name")) == _as_set(et.get("name"))
 if "content" in et:
 checks["content"] = _as_set(pt.get("content")) == _as_set(et.get("content"))
 if "recurrence" in ec:
 checks["recurrence"] = pc.get("recurrence") == ec.get("recurrence")
 if "delivery" in ec:
 checks["delivery"] = _abs(pc.get("delivery")) == _abs(ec.get("delivery"))
 if "expires" in ec:
 checks["expires"] = _abs(pc.get("expires")) == _abs(ec.get("expires"))

 passed = all(checks.values()) if checks else False

 return {
 "key": "extract_rule_correctness",
 "score": 1.0 if passed else 0.0,
 "comment": str(checks),
 }

LangSmith에서 Target(handle) 반환값과 Dataset example.outputs 의 결과값을 비교해 0, 1 점(binary)으로 수치화함.
handle 함수의 결과값 JSON 필드는 예상과 정확하게 나와야 하기 때문에, Code Based Evaluation 을 진행함.

Dataset 생성

예전 학부연구생 생활하면서, 같은 연구실 동기들에게 받은 32개의 예시에는 ok=False가 너무 많아 평가가 편향될 것으로 예상되어, 10개로 줄였다.
ok = True 는 40개 / ok = False 는 10개로 개수를 맞춰 테스트를 진행할 예정이다.
본 Evaluation에서는 사용자 자연어 요청으로부터 앱, 콘텐츠, 알림 허용/차단 및 시간 조건을 구조화된 JSON으로 정확하게 추출하는지를 검증하며, 콘텐츠의 의미적 분류 정확도는 평가 범위에서 제외 한다.

의미적 분류 정확도는 현재 오류로 검증하지 않았지만, 개선 사항임.
extra_rule_correctness = 0.76 : 왜 이 테스트 결과값이 나왔는지 점검 해봐야 한다.

Coding Test

Tue, 11 Aug 2026 00:00:00 +0900

프로그래머스

[Step1] 최소직사각형

분류

그리디

접근 방법

Max(가로), Max(세로)로 생각했지만, 명함을 눕혀 사이즈를 조정할 수 있음. 그러면 모든 명함을 한 방향으로 통일해서 정렬하고, 그 안에서 제일 큰 가로와 세로 길이를 측정하면 한 번에 해결할 수 있음.

풀이 전략

각 명함의 방향을 정규화해서 한 번 순회하는 풀이이다. 회전 가능한 데이터를 일정한 기준으로 정규화한 뒤 최댓값을 구한다.

분류

구현

접근 방법 및 풀이 전략

차량별로 Dictionary 자료구조를 활용해서 입 • 출차 기록을 모으고, 각 차량의 누적 주차 시간을 계산하여 요금을 한 번만 계산한다.

내 코드

import math

def solution(fees, records):
 def_min, def_pri, unit_min, unit_pri = fees
 car_dict = dict()

 answer = []

 for record in records:
 time, car_num, is_in_out = record.split()
 [hour, minute] = time.split(":")
 # 데이터 삽입
 if not car_num in car_dict.keys():
 car_dict[car_num] = [[int(hour), int(minute), is_in_out]]
 else:
 car_dict[car_num].append([int(hour), int(minute), is_in_out])
 for k, v in car_dict.items():
 if len(v) % 2 == 1: # 홀수개인 경우
 car_dict[k].append([23, 59, 'OUT'])

 car_sort_keys = sorted(car_dict.keys())

 print(car_dict)

 for car_sort_key in car_sort_keys:

 period_min = 0

 while len(car_dict[car_sort_key]) > 0:
 car_out = car_dict[car_sort_key].pop()
 car_in = car_dict[car_sort_key].pop()

 period_min += (car_out[0] * 60 + car_out[1]) - (car_in[0] * 60 + car_in[1])

 if period_min <= def_min:
 answer.append(def_pri)
 else:
 answer.append(def_pri + (math.ceil((period_min - def_min) / unit_min) * unit_pri))

 return answer

잘 작성된 Class 기반 코드

from collections import defaultdict
from math import ceil

class Parking:
 def __init__(self, fees):
 self.fees = fees
 self.in_flag = False
 self.in_time = 0
 self.total = 0

 def update(self, t, inout):
 self.in_flag = True if inout=='IN' else False
 if self.in_flag: self.in_time = str2int(t)
 else: self.total += (str2int(t)-self.in_time)

 def calc_fee(self):
 if self.in_flag: self.update('23:59', 'out')
 add_t = self.total - self.fees[0]
 return self.fees[1] + ceil(add_t/self.fees[2]) * self.fees[3] if add_t >= 0 else self.fees[1]

def str2int(string):
 return int(string[:2])*60 + int(string[3:])

def solution(fees, records):
 recordsDict = defaultdict(lambda:Parking(fees))
 for rcd in records:
 t, car, inout = rcd.split()
 recordsDict[car].update(t, inout)
 return [v.calc_fee() for k, v in sorted(recordsDict.items())]

알아두면 좋을 개념

from collections import defaultdict: 파이썬의 일반 dict와 거의 같은데, 존재하지 않는 key에 접근했을 때 기본값을 자동으로 만들어주는 딕셔너리 이다.

다음번에 Dictionary 자료구조를 이용해야 할 때, 한 번 활용 해보자.

[Step3] k진수에서 소수 개수 구하기

분류

구현

접근 방법 및 풀이 전략

문제에서 요구하는 과정을 순서대로 구현하는 구현 문제로 접근하였다. 주어진 숫자를 k진수로 변환한 뒤, 0을 기준으로 분리하고 각 숫자가 소수인지 판별하여 개수를 계산하였다.

진법 변환

def parseTen(el):
 index = 0
 parsed = 0
 for ch in el[::-1]:
 num = int(ch)
 parsed += num * (10 ** index)
 index += 1
 return parsed

문자열의 각 문자를 하나씩 뒤에서부터 카운팅하기 위해서는 el[::-1]을 활용해 역순으로 찾아야 한다.
index는 몇 제곱인지를 나타내므로 10 ** index으로 나타내야 한다.

소수 판별

def isPrime(num):
 if num < 2:
 return False
 for idx in range(2, int(num ** 0.5) + 1):
 if num % idx == 0:
 return False
 return True

처음에는 소수의 개수를 세줄때, range(2, int(num)) 으로 세어서 시간 초과가 발생하였다.
소수 판별 시에는, [제곱근 + 1] 개 만큼만 카운팅해주면 된다는 것을 기억하자.

[해시] 완주하지 못한 선수

from collections import defaultdict

def solution(participant, completion):

 part_dict = defaultdict(int)

 for part in participant:
 part_dict[part] += 1

 for comp in completion:
 part_dict[comp] -= 1
 if part_dict[comp] == 0:
 del part_dict[comp]

 answer = list(part_dict.keys())[0]

 return answer

접근 방법

defaultdict를 사용해 존재하지 않는 키에 접근할 경우, 자동 생성하도록 만들었다. 그 자동으로 생성할 때의 값을 뭘로 설정할 지를 defaultdict의 인자로 넣어준다.

풀이 전략

문제 자체는 어렵지 않으나, 통과하기 위해서는 최적화를 통해 시간 단축이 필요하다. 따라서 list 사용해 이중 순회하는 것이 아니라 Dictionary를 사용해 O(1)의 시간복잡도로 조회 및 수정이 이루어지도록 설계했다.

[해시] 폰켓몬

접근 방법 및 풀이 전략

마찬가지로 defaultdict 함수를 사용해서 처음 빈 Dict의 경우 자동 생성이 되도록 작성했다. 해당 문제는 (전체 총 개수) // 2와 중복 제거한 개수를 비교하는 문항이다.

Study Schedule

Tue, 11 Aug 2026 00:00:00 +0900

프로젝트 관련 발전 방향

기존 프로젝트들은 시스템 구현과 실험까지는 진행했지만, 앞으로는 결과의 신뢰성을 정량적으로 검증하고 실제 서비스 환경에서 안정적으로 동작하는지 확인하는 과정 을 더욱 보완할 필요가 있어 보인다.

또한 이미 해왔던 프로젝트들을 이론적으로 보완하는 전략이 필요해보인다.

단순히 새로운 기술을 추가하기보다는 Baseline 설정 → Evaluation Dataset 구축 → 자동 평가 → Error Analysis → 구조 개선 → 재평가 → Reliability 강화 → 실제 사용자 검증의 흐름으로 기존 프로젝트를 발전시키고자 한다.

멀티 에이전트 환각 탐지 및 교정
- 기존 실험 결과에 대한 정량적 검증 보완
  - 평가 데이터셋 확대 및 Ground Truth 기준 명확화
  - Hallucination Detection / Correction 성능을 측정할 수 있는 평가 지표 설계
  - 모델 조합 및 토론 전략별 성능 비교
- Error Analysis를 통한 실패 유형 및 원인 분석
  - 어떤 문제 유형에서 토론이 효과적인지 분석
  - 두 모델이 모두 오답인 경우, 한 모델만 오답인 경우 등 조건별 성능 비교
  - 잘못된 의견을 수용하거나 기존 정답을 오히려 수정하는 실패 사례 분석
- Ablation Study 및 통계적 검증
  - 토론 유무, 모델 조합, 토론 횟수 등에 따른 성능 차이 분석
  - 개선 결과가 실제로 유의미한 차이인지 통계적으로 검증
- 향후 RAG, Tool Use, Memory 등을 결합한 멀티 에이전트 구조로 확장 가능성 검토
자연어 기반 알림 전송 제어 시스템 개발
- 현재 시스템의 Baseline 구조와 성능 고정
  - 현재 알림 관리자와 조건 추출자의 동작 구조 정리
  - 기존 Function Calling 기반 시스템의 성능을 이후 개선의 비교 기준으로 활용
- Evaluation Dataset 구축
  - 실제 사용자가 입력할 수 있는 다양한 자연어 요청 수집
  - 각 자연어 입력에 대응하는 JSON Ground Truth 직접 정의
  - 시간, 위치, 활동, 반복 조건 등 필드별 테스트 케이스 구성
  - JSON 스키마를 구성하는 각 필드가 실제 서비스에 필요한 정보인지 재검토
- 자동 Evaluation Pipeline 구현
  - 자연어 입력 → 조건 추출 → JSON 결과 생성 과정을 자동화
  - Exact Match, Field-level Accuracy 등 평가 지표 설계
  - 시간 표현이나 동의어처럼 표현은 다르지만 의미가 동일한 결과의 평가 방식 고민
- Error Analysis를 통한 알림 관리자·조건 추출자 로직 개선
  - 현재 사용하는 구현 방식이 서비스 성능 측면에서 갖는 약점 분석
  - 시간, 위치, 활동, 반복 조건 등 필드별 오류 유형 분류
  - Prompt 문제인지, JSON Schema 문제인지, 시스템 구조 문제인지 원인 분석
  - 분석 결과를 바탕으로 Prompt 및 구조 개선 후 v2 시스템 구현
- 자연어 파싱 과정에서 오류 발생 시 대처 방안 설계
  - JSON Schema Validation
  - 잘못된 결과에 대한 Retry
  - 조건 누락이나 해석 불가능한 요청에 대한 Fallback
  - 사용자에게 추가 정보를 요청해야 하는 경우에 대한 처리 방식 설계
  - 반복적인 실패나 무한 Retry를 방지하는 정책 고민
- LangGraph 도입 검토
  - 조건 추출 → 검증 → 재추론 → 알림 생성 과정을 State 기반 Workflow로 관리
  - Node / Edge / State 구조를 활용한 Agent Workflow 구현 가능성 검토
  - 단순히 기술을 적용하는 것보다 기존 구조 대비 실제 장점이 있는지 비교
- v1과 개선된 v2 시스템 성능 비교 및 통계적 검증
  - 동일 Evaluation Dataset을 활용해 개선 전후 성능 비교
  - 전체 정확도뿐만 아니라 Field별 성능 변화 분석
  - 개선 폭이 실제로 의미 있는 차이인지 통계적으로 검증
- Reliability 강화
  - Validation / Retry / Fallback 로직 적용
  - API 오류, 네트워크 오류, LLM 응답 오류 등에 대한 예외 처리
  - 실제 서비스 환경에서 실패하더라도 안전하게 동작할 수 있는 구조 설계
- 실제 사용자 테스트 및 서비스 운영 경험 확보
  - 테스트 사용자에게 앱 배포
  - Firebase Analytics를 통한 실제 사용 패턴 확인
  - Firebase NotiLLM_Crashlytics 를 통한 Crash 및 Error 분석
  - 실제 사용자 환경에서 발생한 문제를 기반으로 반복적인 개선
- 사용자 실험 및 Product 효과 검증
  - 자연어 기반 알림 제어 기능이 실제로 사용자의 알림 관리 부담을 줄이는지 확인
  - 필요할 경우 기존 방식과 개선된 방식 간 사용자 실험 또는 A/B Test 진행
  - 모델 정확도뿐만 아니라 실제 사용자 경험 측면의 효과까지 검증
7호선 급행열차 최적 정차역 제안
- 데이터 분석과 관련한 추가적인 공부
  - 계층적 클러스터링
  - 다중공선성 및 VIF
  - PCA
  - 회귀분석
  - p-value 및 가설검정
  - 머신러닝 / 딥러닝 기본 개념 복습
- 분석 결과를 설명하고 검증할 수 있는 통계적 기반 강화
  - 단순히 모델을 적용하는 것에서 끝내지 않고 해당 방법을 선택한 이유 이해
  - 변수 선택과 모델링 과정의 통계적 타당성 검토
  - 결과의 해석 가능성과 신뢰성을 설명할 수 있도록 보완
그 외
- 최신 Generative AI 기술 학습
  - Agentic AI
  - Tool Use / Function Calling
  - RAG
  - Memory
  - Multimodal Agent
  - Multi-Agent System
  - LLM Evaluation
  - 최신 논문 및 실제 서비스 Architecture 참고
- AI 도구를 활용한 개발 방식 학습
  - ChatGPT / Cursor 등을 적극적으로 활용해 구현 속도를 높이되, 생성된 코드를 그대로 사용하는 데 그치지 않기
  - 왜 해당 구조와 평가 방법을 선택했는지 직접 설명할 수 있는 수준까지 이해
  - 구현 자체보다 문제 정의, 설계, 평가 지표 선정, Error Analysis 및 결과 해석 능력을 중심으로 학습
- 코딩테스트 꾸준히 준비
  - COMMON 코몬 서비스 활용해서 하루에 4문제씩 풀이하고, 풀이 정리 및 관련 개념 정리
- 추가 참조 자료 는 계속 웹사이트에 공유하고 수강

전체 NotiLLM Schedule 및 Architecture 설계

Tue, 11 Aug 2026 00:00:00 +0900

Schedule

단순히 기능을 추가하는 방식이 아니라, 측정 가능한 기준을 세우고 반복적으로 개선하는 과정을 중심으로 프로젝트를 진행했습니다.

아래와 같이 단순한 LLM 기능 구현을 넘어, Evaluation - Optimization - Validation - Production 으로 이어지는 AI Engineering 전 과정을 경험하는 것을 목표로 합니다.

순서	할 일	핵심 산출물	키우는 역량
1	현재 시스템 Baseline 고정	v1 구조/성능 기준	System Design
2	Evaluation Dataset 구축	Ground Truth Dataset	LLM Evaluation
3	자동 Evaluation 구현	평가 코드 + 지표	AI Engineering
4	Error Analysis	실패 유형/원인	Problem Solving
5	구조/Prompt 개선	v2	LLM Engineering
6	LangGraph 도입 검토	Stateful Agent	Agent Engineering
7	재평가 + 통계 검증	v1 vs v2 결과	Experimentation
8	Reliability 강화	Retry/Fallback/Validation	Production AI
9	실제 사용자 배포	테스트 사용자	Product Engineering
10	Analytics/Crashlytics 분석	실사용 데이터	Product Analytics
11	사용자 실험/A-B Test	Product 효과 검증	Experiment Design
12	최종 포트폴리오 정리	GitHub/Portfolio	취업

본격적인 Evaluation을 진행하기에 앞서서, 전체 Architecture를 먼저 설계해 어느 부분을 평가할 지에 대한 계획을 수립했습니다.

Baseline Ver.1 Architecture

Mermaid 목적 : Evaluation 시, 어느 Component에서 문제가 발생하는지 특정 하기 위함
ChatGPT-4o 모델로 Function Calling 전체 처리

flowchart TB user((User)) router["Router
GPT-4o w/
function calling"] user -->|chat command| router router -->|reply| user parse[Parse User Intent] choose[Choose mute / allow tool] router --> parse --> choose cond["extract_notification_condition
(time / recurrence)"] mute["extract_mute_target
(name / content)"] allow["extract_allow_target
(name / content)"] choose -->|function call| cond choose -->|function call| mute choose -->|function call| allow c1[Infer delivery / expires] c2[Set recurrence / window] m1[Extract mute apps / keywords] m2[Normalize app names] a1[Extract mute apps / keywords] a2[Normalize app names] cond --> c1 --> c2 mute --> m1 --> m2 allow --> a1 --> a2 c2 -.->|tool result| router m2 -.->|tool result| router a2 -.->|tool result| router merge["PromptEngine Merge
(target + condition)"] inj[Inject mute flag] build[Build target JSON] cm[ContextManager] mapPkg[Map app name to package] validate[Validate delivery before expires] save[Save rule to SQLite] db[(SQLite)] router -->|two JSONs| merge merge --> inj --> build --> cm --> mapPkg --> validate --> save save -->|Persist mode / apps / window| db classDef userNode fill:#7eb8da,stroke:#4a90b8,color:#fff classDef routerNode fill:#e8a0a0,stroke:#c07070,color:#222 classDef stepRed fill:#fff5f5,stroke:#c07070,color:#b33 classDef toolNode fill:#90c9a0,stroke:#5a9a6a,color:#222 classDef stepGreen fill:#f3faf5,stroke:#5a9a6a,color:#2a7a3a classDef dbNode fill:#a8d5b5,stroke:#5a9a6a,color:#222 class user userNode class router routerNode class parse,choose,c1,c2,m1,m2,a1,a2 stepRed class cond,mute,allow toolNode class merge,cm stepGreen class inj,build,mapPkg,validate,save stepGreen class db dbNode

평가 방식

각 Tools (extract_notification_condition, extract_mute_target, extract_allow_target) 에 따라 어떤 평가 방식을 사용해야 할까?

지금 평가 대상이 자유로운 자연어 답변이 아니라 스키마가 정해진 구조화된 JSON이고, 이미 Ground Truth를 만들 수 있다. 그래서 굳이 또 다른 LLM의 주관적 판단을 끼워 넣을 필요가 없다고 판단했습니다.

평가 방식 선정

Code-based evals 선정

Function Calling의 출력이 정해진 JSON Schema를 따르는 구조화된 데이터이므로, 각 필드를 Ground Truth와 직접 비교하는 Code-based Eval 방식 을 사용하기로 결정했습니다.

Function Calling이 현재 출력하는 JSON 필드

extract_notification_condition

{
"name": "extract_notification_condition",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"delivery": {
"type": "object",
"additionalProperties": false,
"properties": {
"absolute": { "type": "string" }
},
"required": ["absolute"]
},
"activity": {
"type": ["string", "null"]
},
"location": {
"type": ["string", "null"]
},
"expires": {
"type": "object",
"additionalProperties": false,
"properties": {
"absolute": { "type": "string" }
},
"required": ["absolute"]
},
"recurrence": {
"type": "string",
"enum": ["none", "daily", "weekly"]
},
"days_of_week": {
"type": "array",
"items": {
"type": "integer"
}
},
"window_start": {
"type": ["string", "null"]
},
"window_end": {
"type": ["string", "null"]
}
},
"required": [
"delivery",
"activity",
"location",
"expires",
"recurrence",
"days_of_week",
"window_start",
"window_end"
]
}
}

extract_mute_target

{
"name": "extract_mute_target",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"type": "array",
"items": {
"type": ["string", "null"]
}
},
"content": {
"type": "array",
"items": {
"type": ["string", "null"]
}
}
},
"required": [
"name",
"content"
]
}
}

extract_allow_target

{
"name": "extract_allow_target",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"type": "array",
"items": {
"type": ["string", "null"]
}
},
"content": {
"type": "array",
"items": {
"type": ["string", "null"]
}
}
},
"required": [
"name",
"content"
]
}
}

References

NotiLLM_Crashlytics

Wed, 05 Aug 2026 00:00:00 +0900

Firebase Crashlytics 연동

목적

앱이 강제 종료되거나 예외가 발생했을 때, 사용자가 로그를 보내지 않아도 Firebase Console에서 비정상 종료 보고서를 확인할 수 있도록 했다.

사전 조건

항목	최소 요구	본 프로젝트
Gradle	8.0	8.13
Android Gradle Plugin	8.1.0	8.11.1
Google services 플러그인	4.4.1	4.4.2
`app/google-services.json`	필요	사용 중

코드 변경 요약

1. 프로젝트 수준 (`build.gradle.kts`)

Crashlytics Gradle 플러그인 추가
id("com.google.firebase.crashlytics") version "3.0.3" apply false

2. 앱 모듈 (`app/build.gradle.kts`)

google-services.json이 있을 때 플러그인 적용
- com.google.gms.google-services
- com.google.firebase.crashlytics
Firebase 의존성 추가 (BoM 사용, 버전 미지정)
- firebase-crashlytics
- firebase-analytics (탐색경로 로그용)

3. 테스트 비정상 종료 UI

위치: 프로필 화면 (ProfileScreen)
debug 빌드에서만 Test Crash 버튼 표시
동작: throw RuntimeException("Test Crash")

검증 절차

Firebase Console → Crashlytics 사용 설정
(권장) 프로젝트 설정 → 통합에서 Google Analytics 사용 설정
앱 빌드 후 설치·실행
프로필 → Test Crash 탭 → 앱 강제 종료
앱을 다시 실행 (이때 보고서 전송)
Firebase Console → Crashlytics에서 Test Crash 확인
- 반영까지 수 분 소요될 수 있음

참고

Test Crash 버튼은 BuildConfig.DEBUG일 때만 보이므로 release에는 노출되지 않음
확인 완료 후 테스트 버튼 코드는 제거해도 됨
Crashlytics는 크래시/ANR 등 비정상 종료용이며, LLM 실패·규칙 생성 실패 등 비즈니스 로그는 Realtime Database 원격 로그로 별도 설계 필요

느낀점

가까운 지인에게 테스트를 부탁하면서 연령층 별로 생각보다 입력하는 메시지의 느낌이 다르다는 것을 느꼈다. “받지마/받아줘” 보다는 “보류"라는 단어를 사용하는 케이스가 있었다. 또한 “카카오톡 메시지"라는 말을 “카카오톡” 앱의 “메시지” 키워드로 잘못 등록하는 케이스도 존재했다. 해당 케이스에 대해서는 어떻게 컨트롤하고 제어 조건으로 설정하기 위해 프롬프팅해줘야 할 지 고민이 필요해 보였다.

NotiLLM : LLM 기반 자연어 알림 전송 제어

Tue, 04 Aug 2026 00:00:00 +0900

해당 서비스는 연구실의 아이디어를 기반으로 서비스화한 것으로, 관련 저작권은 연구실에 있습니다.

정리예정 진행중입니다.

요약

프로젝트 이름: NotiLLM
프로젝트 기간: 2026.07 ~ (진행중)
프로젝트 설명: LLM Agent를 실서비스로 배포하고, 수집된 사용자 데이터를 기반으로 데이터 분석
프로젝트 목적: 수집된 데이터를 분석해 추가 아이디어 확장

Problem

기존 수동제어 기반 방식은 사용자의 직접 설정을 필요로 하므로, 사용자 부담이 증가하고 사용성이 떨어집니다.
반대로 ML 기반 알림 수신 타이밍 예측 방식들은 정확성을 높이기 위한 연구들이 많이 진행되고 있지만, 근본적으로 사용자의 비언어적 신호를 기반으로 하기에 예측이 부정확합니다.
따라서 본 연구는 수동 제어 방식의 불편함과 모델 기반 방식의 부정확성을 둘 다 잡고 해결하기 위해, LLM 기반 사용자 제어를 진행합니다.

본 서비스는 연구실의 아이디어를 실제 서비스로 확장하고, 배포 및 운영 경험을 바탕으로 후속 연구 및 서비스 고도화를 진행하기 위한 목적으로 개발되었습니다.

서비스 디자인

Figma를 활용해 실제 서비스에 가까운 수준으로 UI/UX를 디자인했습니다. 화면을 구성할 때는 사용성을 고려해 버튼과 텍스트의 배치를 설계하고, 사용자에게 어떤 정보를 효과적으로 제공할지 중점적으로 고민했습니다. [1] 특히 알림 피로가 얼마나 줄어들었는지 사용자가 직접 확인할 수 있도록 차단된 알림의 실시간 통계 기능을 추가 했습니다. 또한 필요한 경우 [2] 모든 알림을 한 번에 확인할 수 있는 버튼을 제공 하고, 홈 화면 하단에서는 [3] 수신된 알림을 앱별로 요약 해 확인할 수 있도록 구성했습니다.

시스템 설계 확장

Function Calling을 통해 사용자의 자연어를 JSON 구조로 변환할 때는 기본 동작을 “알림을 허용(받아줘 Default)“으로 할지, “알림을 차단(받지마 Default)“으로 할지 설계 방향을 결정해야 했습니다. 연구를 진행하면서 한 가지 방식만 적용할 경우 예상하지 못한 반례가 발생한다는 점을 확인했습니다. 이를 해결하기 위해 두 가지 기본 동작을 모두 지원하도록 Function Calling을 설계하여 다양한 명령을 유연하게 처리할 수 있도록 확장했습니다. 그 결과 기존에는 처리하기 어려웠던 “매일”, “평일만”, “주말만"과 같은 반복 · 주기성 명령까지 안정적으로 지원 할 수 있었습니다.

느낀점

테스트를 진행하며 다양한 사용자층을 확보하는 것이 중요하다는 점을 느꼈습니다. 현재는 테스트 사용자가 가까운 지인들로 한정되어 있어 충분히 의미 있는 인사이트를 도출하지는 못했지만, 연령대에 따라 사용하는 표현과 언어 습관에 차이가 있다는 점을 확인 할 수 있었습니다. 이를 통해 Function Calling 프롬프트를 제 언어 습관과 표현 방식을 중심으로 설계했다는 한계를 깨달았으며, 향후에는 다양한 사용자 표현을 수집하고 반영해 자연어 명령에 대한 처리 범위를 확장해야 한다고 판단했습니다.

Questions? Leave a comment below or reach out on !

LLM을 활용한 자연어 기반 알림 전송 제어 시스템 개발

Tue, 15 Jul 2025 00:00:00 +0900

📄 Paper

KSC 2025 Paper Accept

📑

🖼️ Poster

KCC 2025 Conference Poster

📄

요약

프로젝트 이름: LLM을 활용한 자연어 기반 알림 전송 제어 시스템 개발
프로젝트 기간: 2025.07 ~ 2025.11
프로젝트 설명: 사용자의 자연어 명령에서 알림 수신 조건과 대상을 추출하고, 조건에 맞는 알림만 선별적으로 전송하는 LLM 기반 모바일 알림 제어 시스템
프로젝트 목적: 복잡한 수동 설정 과정과 머신러닝 기반 자동 예측의 부정확성을 개선하여 사용자가 자연어만으로 원하는 알림 수신 조건을 설정할 수 있도록 지원
데이터 출처: 사용자 7명으로부터 수집한 자연어 명령 시나리오 24개
주요 설계 대상: 시간·장소·활동을 나타내는 조건 필드와 앱·키워드를 나타내는 대상 필드
프로젝트 성과: KSC 2025 논문 발표 및 Paper Accept

연구 시작 배경

“알림을 일일히 수동으로 설정하기 어렵다.”
“현재 알림 시스템은 시간/앱/내용/패턴 등의 컨텍스트를 충분히 고려하지 못한다.”

이로 인해, 사용자가 에이전트에게 알림 커스터마이징을 요청했을 때, 자동으로 커스터마이징 해주는 기능을 핵심 아이디어로 도출함.

구현 가능성 기술 조사

Google Assistant, Bixby, Gemini 의 기존 음성 에이전트로 구현 가능성 조사
- 단순 앱 실행이 아니라 앱 내부의 특정 알림 제어 기능까지 자연어로 실행할 수 있는지 조사함.
- Google Assistant의 App Actions, Shortcut / Bixby Capsule / Gemini 연동 가능성을 각각 확인함.

하지만 Google Assistant 는 App Actions, Shortcut 중심으로 미리 정의된 액션에 매핑해야 하는 제약이 있고, 테스트 도구도 Google Console에 너무 의존하고 있었음. Gemini는 앱을 열어주는 수준이 아니라 앱 내부 알림 데이터를 자유롭게 제어하는 수준이 불가능했음. 마지막으로 Bixby Capsule은 그나마 가능성이 있어시 실제 프로토타입까지 만들어 보았지만, 사용자의 자유로운 명령에 대응하기 위한 goal, intent, training 등 사전 정의 작업이 필요했음.

결국 위 세가지 방식들은 전부 기각하고, LLM Function Calling 기술을 기반으로 직접 구현하기로 결정.

LLM Function Calling

포폴에 작성된 내용

사용자 수집 데이터 기반 자료구조 설계 (JSON Schema)
시스템 구조 설계 (알림 관리자, 조건 추출자)
개발

포폴 이후 NotiLLM 개인 프로젝트 발전 진행중

목표: LLM 시스템 Evaluation, LangChain 및 LangGraph를 활용해 Version 개선, 부하 테스트, 배포, 사용자 피드백 진행해 연구를 개선하는 것.

자료구조 시나리오 설계 과정

사용자의 자연어를 Function Calling 기능을 활용해 JSON 구조로 변환해야겠다고 결정했을 때, 두 가지 조건을 결정해야 했습니다. 따라서 “알림을 언제 보내줘야 하지?” , “어떤 유형의 알림을 보내줘야 하지?” 와 같은 결정을 내리기 위해서, 저는 8명의 참여자들로부터 총 24개의 질문 시나리오를 받고, 이를 바탕으로 가능한 JSON 구조를 설계했습니다.

JSON Schema 설계

참여자들의 자연어 명령을 분석한 결과, 알림 제어에 필요한 정보는 크게 알림 대상(Notification Target) 과 알림 조건(Notification Condition) 으로 구분할 수 있었습니다.

Category	Field	Description
Notification Target	`name`	앱 이름을 기반으로 알림을 필터링
	`content`	알림 제목 및 본문의 키워드를 기반으로 알림을 필터링
Notification Condition	`time.relative`	현재 시점을 기준으로 한 상대 시간 (예: 5분 후)
	`time.absolute`	특정 절대 시간 (예: 오후 3시)
	`activity`	사용자의 현재 활동
	`location`	사용자의 현재 위치

이를 바탕으로 다음과 같은 JSON 구조를 설계했습니다.

{
 "extract_notification_target": {
 "name": [],
 "content": []
 },
 "extract_notification_condition": {
 "time": {
 "relative": "",
 "absolute": ""
 },
 "activity": "",
 "location": ""
 }
}

작동 시스템 설계

이후 사용자의 자연어 명령을 위와 같이 JSON 자료구조로 변환하는 NotificationParser 와 데이터베이스에 저장된 알림 내용들과 조건 목록들을 모니터링하는 ContextManager 를 두 핵심 기능으로 삼아 개발을 진행했습니다.

트러블슈팅 과정

해당 기능을 구현한 뒤 실제 환경에서 테스트하는 과정에서 예상치 못한 문제가 발생했습니다. 2025년 4월 One UI 7 업데이트 이후 알림에 표시되는 앱 아이콘이 시스템에 의해 임의로 변경되었으며, 삼성의 내부 프레임워크가 공개되어 있지 않아 코드 수정만으로는 기존과 동일한 smallIcon을 가져올 수 없었습니다.

약 2개월간 다양한 해결 방법을 검토했지만, 최종적으로 애플리케이션 코드 수준에서는 해결하기 어렵다는 결론에 도달했습니다. 이에 시스템 설정에서 알림 표시 방식을 이전 버전과 유사하게 변경하는 방법을 사용자에게 안내하는 방식으로 우회책을 마련 했습니다. 이를 통해 개발 과정에서는 코드 개선뿐만 아니라 플랫폼의 제약을 파악하고, 제한된 환경 안에서 사용자 경험을 보완할 수 있는 현실적인 대안을 찾는 것 역시 중요하다는 점을 배웠습니다.

프로젝트를 진행하며 느낀점

알림 관련 문제 상황을 제가 제일 관심이 많이 있는 LLM 모델과 결합하다가 나온 연구 주제입니다. 선배분의 아이디어 기획 능력으로 초반 아이디어 구체화 부분은 수월하게 진행되었지만, 이후 자료구조 설계와 사용자 조사, 그리고 개발 및 논문 작성까지 주도적으로 작성하게 되어서 힘들었지만 많이 배우고 성장할 수 있는 뜻깊은 시간이었습니다. 문제 분석 - 기획 - 해결 아이디어 탐색 - 개발 - 논문 작성 까지의 일련의 흐름을 거치니, 논문과 프로젝트의 퀄리티를 좌지우지하는 중요한 과정은 개발이 아닌 문제 분석과 기획 임을 다시 한 번 느꼈습니다. 또한 개발을 진행하는 과정에서 Android 버전이 바뀌어 아이콘이 깨지는 문제를 한동안 해결하느라 고생했던 것 같습니다. 이러한 예상치 못했던 문제에 대한 트러블슈팅 과정 역시 저를 더 성장하게 해준 계기가 되었던 것 같습니다.

다중 언어 모델 기반 멀티 에이전트 챗봇 토론 프레임워크를 통한 환각 탐지 및 교정

Tue, 15 Jul 2025 00:00:00 +0900

📄 Paper

다중 언어 모델 기반 멀티 에이전트 챗봇 토론 프레임워크를 통한 환각 탐지 및 교정

📑

🖼️ Poster

KCC 2025 Conference Poster

📄

🏆 Award

KCC 2025 Best Poster Award (최우수상)

🏅

요약

프로젝트 이름 : 다중 언어 모델 기반 멀티 에이전트 챗봇 토론 프레임워크를 통한 환각 탐지 및 교정
프로젝트 기간 : 2025.03 ~ 2025.07
프로젝트 설명 : 서로 다른 LLM이 독립적으로 생성한 답변을 비교하고, 답변이 일치하지 않을 경우 토론을 통해 상호 검증하는 멀티 에이전트 프레임워크
프로젝트 목적 : 단일 모델의 학습 데이터 편향과 자체 검증 기능 부족으로 발생하는 환각 문제를 완화하고 답변의 정확성과 논리적 일관성을 향상
검증 데이터 : 2025학년도 대학수학능력시험 전 문항
주요 분석 대상 : 모델 간 답변이 달랐던 수능 66문항
프로젝트 성과 : KCC 2025 논문 발표 및 Best Poster Award 수상

LLM API를 활용

해당 연구는 LLM의 내부 구조나 핵심 처리 로직을 직접 수정하는 방식으로 진행한 연구는 아닙니다. 연구의 핵심 가설은 서로 다른 학습 데이터와 추론 특성을 가진 LLM 간의 토론이 답변의 오류를 발견하고 교정하는 데 유의미할 것 이라는 점이었습니다.

이를 검증하기 위해 유사한 수준의 지식 및 추론 성능을 가진 ChatGPT와 Gemini 모델을 선정하고, 각 모델의 API를 활용해 멀티 에이전트 토론 시스템을 구축했습니다. 각 모델이 독립적으로 답변을 생성한 뒤, 상대 모델의 답변과 반박 내용을 다음 요청의 Context에 포함해 재추론하도록 설계함으로써 두 모델이 반복적으로 의견을 검토하고 답변을 수정할 수 있도록 구현했습니다.

구현 및 검증 과정

해당 연구에서 핵심으로 하고 있던 아이디어를 생각해봤을 때, 결론 역시 유의미할 것이라고 판단되어 프레임워크 개발을 우선적으로 진행 했습니다. 이후 환각 발생 여부를 정확히 판단하기 위해 수능문항을 데이터셋으로 선정하게 되었고 일주일에 걸쳐 검증 및 결과 분석을 진행했습니다.

연구를 진행하는 과정에서 연구 방법론에 대한 근본적인 의문 도 들었습니다. 이번 연구는 가설과 부합하는 유의미한 결과를 얻어 논문 게재와 학술대회 입상으로 이어졌지만, 만약 기대했던 결과가 나타나지 않았다면 연구 전체를 처음부터 다시 설계해야 하는지 고민하게 되었습니다.

해당 고민을 연구실 세미나에서 교수님께 질문하며 논의했지만, 예상과 다른 결과가 나오는 상황을 사전에 완전히 방지할 수 있는 명확한 해답은 찾지 못했습니다.

논문 합격 후 발표 포스터 제작

발표 포스터를 제작할 때는 KHUDA 프로젝트를 진행하며 접했던 다른 학우들의 다양한 포스터와 발표 자료가 큰 도움이 되었습니다. 여러 디자인 사례를 참고한 경험을 바탕으로 완성도 높은 포스터의 특징을 파악할 수 있었고, 핵심 내용을 한눈에 전달하기 위한 정보 배치와 시각적 구성 방식을 실제 제작 과정에 적용할 수 있었습니다.

프로젝트를 진행하며 느낀점

일상 속에서 문제를 발견하고 이를 해결하기 위한 실용적인 연구를 수행하는 과정은 매우 흥미로웠으며, 이는 제가 컴퓨터공학으로 전과한 근본적인 이유와도 맞닿아 있었습니다. 다만 막연한 문제의식을 구체적인 연구 문제로 발전시키고, 기존 연구와의 명확한 차별점을 만드는 과정은 생각보다 훨씬 어려웠습니다. 이로 인해 기획 단계에 많은 시간을 투자하며 연구 주제를 처음부터 다시 검토하고 수정하는 과정을 여러 차례 반복했습니다.

이 과정에서 XMind를 활용해 아이디어와 관련 문제를 구조화하고, 연구 주제를 더 깊이 탐색하는 훈련을 지속했습니다. 그 결과 문제를 구체화하고 연구 방향을 설계하는 역량을 키울 수 있었으며, 연구의 완성도를 결정하는 데 기획 단계가 얼마나 중요한지도 깊이 체감 했습니다.

첫 연구를 논문으로 발전시키고 최우수상이라는 값진 성과까지 얻을 수 있었지만, 이는 저 혼자만의 노력으로 만들어진 결과는 아니었습니다. 연구 방향을 지도해주신 교수님과 논문 작성 과정에서 도움을 주신 선배의 조언과 협력이 있었기에 가능했던 결과였으며, 이를 통해 좋은 연구는 개인의 역량뿐 아니라 팀원들 간의 지속적인 논의와 협업, 그리고 내가 틀림을 인정할 수 있는 능력을 통해 완성된다는 점도 배울 수 있었습니다.

딥러닝 해석을 위한 계층적 다중 뉴런 프레임워크 모델 개발

Tue, 15 Jul 2025 00:00:00 +0900

📄 Paper

딥러닝 해석을 위한 계층적 다중 뉴런 프레임워크 모델 개발

📑

🖼️ Poster

KCC 2025 Conference Poster

📄

🏆 Award

KCC 2025 Encouragement Award (장려상)

🏅

설명

프로젝트 이름: 딥러닝 해석을 위한 계층적 다중 뉴런 프레임워크 모델 개발
프로젝트 기간: 2025.03 ~ 2025.07
프로젝트 설명: 사전 라벨이 없는 이미지 데이터를 의미 단위로 계층화하고, 각 이미지 그룹에 공통으로 반응하는 다중 뉴런을 추출해 딥러닝 모델의 내부 의미 구조를 자연어로 설명하는 자동 해석 프레임워크
프로젝트 목적: 단일 뉴런 중심 해석 방식의 한계를 보완하고, 딥러닝 모델 내부에서 여러 뉴런이 함께 형성하는 복잡한 개념 구조를 계층적으로 분석
분석 모델: ResNet-18
데이터 출처: Unsplash Lite Dataset
분석 데이터: 약 25,000장의 무라벨 고해상도 자연 이미지
주요 분석 대상: 이미지 의미 계층, 공통 활성 뉴런 그룹, 상·하위 계층 간 차이 뉴런
프로젝트 성과: KCC 2025 논문 발표 및 Encouragement Award 수상

ResNet-18이 이미지를 볼 때 내부의 여러 뉴런들이 어떤 개념을 함께 표현하고 있는지를 자동으로 찾아서 자연어로 설명해보자. 즉, 기존에는 주로 뉴런 하나씩 해석했다면, 우리는 여러 뉴런을 그룹으로 묶고 그 관계를 계층적으로 해석하려고 함.

문제 정의

딥러닝의 블랙박스 문제

단일 뉴런 기반 XAI 기존 연구 :
하나의 개념 표현에 여러 뉴런이 협력하기 때문에, 단일 뉴런 분석으로는 이런 협동적 표현을 고려하기 어려움

따라서 뉴런 하나씩 해석하지 말고, 같은 개념에 함께 반응하는 뉴런 그룹을 찾아서 해석하자.

그런데 어떤 이미지로 뉴런의 의미를 알아내지?

기존 연구들은 사람이 정한 라벨이 있는 데이터셋을 이용하는 경우가 많음.
- 즉, 결국 사람이 미리 정한 개념 안에서만 모델을 분석하게 될 수 있는 문제가 있음.
- 이를 피하기 위해 아예 라벨이 없는 Unsplash 이미지 25000장을 사용함.

그럼 라벨이 없으면 비슷한 이미지를 어떻게 묶지?

BLIP : 이미지 25000장을 BLIP에 하나씩 넣어서 이미지 설명을 자동 생성함.

ex. 이미지 A. 폭포 + 바위
- BLIP: A waterfall located in a rocky environment.
- 이 BLIP 캡션을 이후 의미 기반 클러스터링의 입력으로 사용함.

비슷한 의미의 이미지들을 자동으로 묶음.

FINCH : 클러스터 개수를 사람이 미리 지정하지 않아도 되고, 반복적인 병합을 통해 계층적인 클러스터 구조 생성.

결과적으로 이미지들이 총 6개의 Level 계층 구조로 구성됨.

ChatGPT를 활용해 한 클러스터의 모들 설명에 대한 대표 캡션을 생성함.

ex. 클러스터 A.
- A waterfall in a forest
- A waterfall surrounded by rocks
- A waterfall in a natural environment
ChatGPT 기반 대표 캡션 생성
- A waterfall located in a rocky environment.

이미지들을 ResNet-18에 넣음.

Cluser A. : A waterfall located in a rocky environment.
- 이 클러스터 내 이미지 100장을 ResNet-18에 넣어서, 어떤 뉴런들이 강하게 활성화되는 지를 기록함.
- 활성화 값이 전체 뉴런 중 상위 10%에 들어가는 뉴런 추출 = 활성화 뉴런 정의

공통 활성 뉴런 그룹 찾음.

클러스터의 절반 이상의 이미지에서 공통적으로 활성화되는 뉴런을 해당 클러스터의 대표 뉴런 그룹으로 선정함.

계층적 뉴런 해석

ex. Level 1.
- 숲속 폭포 - [10, 32, 81, 100]
- 협곡 폭포 - [10, 32, 81, 150]
- 바위 폭포 - [10, 32, 81, 200]

공통 뉴런은 [10, 32, 81] 이므로, 이를 상위 Level의 뉴런 그룹으로 해석

차이 뉴런 정의

[100]: 숲속 의미.
[150]: 협곡 의미.
[200]: 바위 의미.

ResNet-18 내부의 뉴런들을 단일 뉴런이 아니라 여러 뉴런이 함께 표현하는 의미 + 상하위 의미 관계로 설명하는 프레임워크를 구현함.

프로젝트를 진행하며 느낀점

여러 프로젝트를 진행하며 직접 사용해보기 전에는 실제 문제를 발견하기 어렵다 는 생각을 갖게 되었습니다. 이에 뉴런 해석과 관련된 기존 논문의 GitHub 코드를 직접 설치하고 실행해보며, 기존 방법의 한계와 개선이 필요한 지점을 파악하고자 했습니다.

이전 프로젝트에서 연구 기획을 여러 차례 수정했던 경험을 바탕으로, 이번 프로젝트에서는 문제를 정의하고 새로운 연구 방향을 구체화하는 과정에 특히 많은 노력을 기울였습니다. 이후 딥러닝 프로젝트 담당 교수님과 주기적으로 회의를 진행하며 연구 방향을 지속적으로 점검하고 수정했고, 그 과정에서 새로운 접근을 설계하기 위한 인사이트를 얻을 수 있었습니다.

최종적으로 단일 뉴런을 중심으로 의미를 해석하는 기존 방식에서 벗어나, 여러 뉴런의 공통 활성화 패턴을 하나의 집합으로 구성해 해석에 활용하는 아이디어를 제안했습니다. 이를 바탕으로 연구를 성공적으로 마무리하고 KCC 2025 학술대회에 논문을 제출했으며, 감사하게도 장려상을 수상했습니다. 직접 문제를 발견하고 연구 방향을 설계하기 위해 기울였던 노력이 성과로 이어졌다는 점에서 큰 보람을 느낄 수 있었습니다.

멀티 모델을 활용한 RAG Generation 단계 환각 탐지

Tue, 15 Jul 2025 00:00:00 +0900

📄 Paper

멀티 모델을 활용한 RAG Generation 단계 환각 탐지

📑

🖼️ PPT

Graduation Project PPT

📄

요약

프로젝트 이름: 멀티 모델을 활용한 RAG Generation 단계 환각 탐지
영문 제목: A Multi-LLM Cross-Verification Framework for Attribution Hallucination Detection in RAG Generation
프로젝트 기간: 2025.03 ~ 2025.07
프로젝트 설명: 동일한 RAG 검색 문서를 기반으로 ChatGPT와 LLaMA가 독립적으로 답변을 생성하고, 유사도가 낮을 때 문서 인용 기반 상호 평가·토론을 수행하는 Generation 단계 환각 탐지 시스템
프로젝트 목적: RAG Generation 단계에서 발생하는 환각을 단일 모델 검증의 한계를 넘어, 서로 다른 LLM의 답변 다양성으로 탐지하고 교정
검증 데이터: TruthfulQA 중 Source가 Wikipedia인 질문 50문항
비교 모델: ChatGPT-3.5-turbo, Groq 기반 llama-4-maverick-17b-128e-instruct
주요 검증 대상: 최종 답변, 원본 문서 인용 문장, 근거가 답변을 지지하는 이유
주요 성과: 한 모델만 오답인 문항에서 토론을 통해 약 절반을 정답으로 교정 (GPT만 오답 3문항 중 1문항, LLaMA만 오답 13문항 중 7문항)

연구를 시작하게 된 배경

기존 LLM의 환각을 개선하기 위해 RAG 기법이 도입되었지만, RAG를 활용한 LLM에서도 환각 문제는 여전히 남아 있었습니다.

SUFFICIENT CONTEXT: A NEW LENS ON RETRIEVAL AUGMENTED GENERATION SYSTEMS (2025) 논문 일부 발췌

RAG로 추가 맥락을 주더라도 AI의 자신감이 올라가는 것과 정확성이 항상 비례하지는 않았습니다.
ChatGPT 4o, Gemini 1.5 Pro, Gemma 27B처럼 모델이 다르면 학습 데이터 차이로 환각률도 다르게 나타났습니다.

따라서 본 연구에서는 서로 다른 언어 모델의 답변 다양성을 Generation 단계 환각 개선에 활용 하고자 했습니다. RAG 파이프라인 중에서도 Query Rewriting과 Generation에서 환각이 자주 발생하는데, Generation은 LLM 사용이 필수이므로 이 단계에 집중해 멀티 에이전트 구조로 분기했습니다.

시스템 아키텍처

Query Rewriting: 추가 LLM(gpt-5.2-2025-12-11, temp=0)으로 검색 쿼리 생성
Generation 1 / 2: ChatGPT-3.5-turbo, llama-4-maverick-17b-128e-instruct가 동일 검색 문서로 독립 답변
답변 유사도 계산: SentenceTransformer(all-MiniLM-L6-v2), threshold=0.8
일치 시 종료 / 불일치 시 토론: 상대 답변이 문서에 근거하는지 문장 직접 인용으로 상호 평가

토론 프롬프트 설계

각 모델은 답변 시 아래 세 가지를 함께 작성하도록 했습니다.

최종 답변
원본 문서 인용 문장
해당 근거가 답변을 지지하는 이유

답변이 불일치하면, 상대 답변이 문서에 근거하는지를 문서 문장을 직접 인용해 평가 하도록 지시했습니다.

실험 설계

TruthfulQA 중 Wikipedia 출처 질문 50문항 선정
RAG 기반 독립 답변 생성
유사도 불일치 시 토론 진행
Best Answer / Best Incorrect Answer 기준 수동 검증

단순 사실 판단 데이터는 제외하고, 정·오답이 라벨링된 문항만 사용해 교정 효과를 수치화했습니다.

실험 결과

구분	문항 수	토론 후
GPT만 정답	3	정답 교정 1 / 오답 유지 2
LLaMA만 정답	13	정답 교정 7 / 오답 유지 6
둘 다 오답	14	정답 교정 0
둘 다 정답	20	-

한 모델만 오답인 경우 약 절반이 토론으로 교정되었고, 둘 다 오답이면 토론만으로는 교정되지 않았습니다.

유형별 분석

Misconceptions, Conspiracies, Superstitions, Paranormal, Fictions 중 미신(Superstitions) 문항에서 오류율이 가장 높았습니다 (GPT 0%, LLaMA 22%).

결론

Generation 단계 모델만 바꿔도 성능 차이가 컸습니다.
한 모델만 오답일 때 토론의 교정 효과가 확인되었습니다.
두 모델이 모두 오답이면 RAG 토론만으로는 교정이 어려웠습니다.
미신 · 잘못된 상식류 문항에서 특히 취약했습니다.

사례

둘 다 정답: Fortune cookie 기원 질문 — 유사도 0.97, Conflict False로 종료
한 모델만 정답 → 교정: 식사 후 수영 대기 시간 질문 — 1차 불일치 후, 문서에 대기 시간 언급이 없다는 인용 평가로 합의 도달

프로젝트를 진행하며 느낀점

멀티 에이전트 챗봇 토론 시스템을 활용한 환각 교정 서비스를 개발하면서 환각 문제를 깊이 분석하던 중, 연구를 더욱 발전시킬 수 있는 새로운 방향을 발견했습니다. 일반적인 사실 오류뿐만 아니라, 출처 환각(Attribution Hallucination) 역시 실제 서비스 환경에서 빈번하게 발생하는 중요한 문제라는 점을 알게 되었고, 이를 해결하기 위해 본 프로젝트를 진행하게 되었습니다.

본 연구에서는 각 LLM에 RAG(Retrieval-Augmented Generation) 시스템을 구축하고, 서로의 답변에 포함된 출처를 교차 검증하도록 설계하여 출처 환각을 줄이는 것을 목표로 했습니다. 다만 어떤 데이터셋을 구성해야 하는지, 출처의 일치 여부를 어떤 기준으로 검증해야 하는지 등 연구 설계 단계에서 많은 고민이 있었고, 이를 구체화하기 위해 교수님과 지속적으로 논의하며 연구 방향을 수정해 나갔습니다.

최종적으로는 Prompt Engineering과 LLM 간 대화 구조를 보다 정교하게 설계함으로써 의미 있는 성능 개선을 확인할 수 있었고, 이를 바탕으로 논문화까지 진행할 수 있었습니다. 아직 해결해야 할 한계점이 남아 있지만, 이를 보완하며 출처 환각 탐지 및 교정 성능을 더욱 향상시키는 방향으로 연구를 계속 발전시킬 계획입니다.

블록체인을 활용한 신뢰 기반 이미지 거래 서비스, BlockSnap

Tue, 15 Jul 2025 00:00:00 +0900

설명

프로젝트 이름 : 신뢰 기반 이미지 거래 서비스, BlockSnap
프로젝트 기간 : 2026.03 ~ 2026.06
프로젝트 설명 : 블록체인의 온체인에 이미지 메타데이터를 등록해 위조가 불가능한 이미지 데이터를 생성하고, 이를 거래할 수 있는 서비스
프로젝트 목적 : AI로 생성된 이미지가 굉장히 많아, 구별이 힘든 삶을 살아가고 있는 상황 속에서 검증된 이미지를 통해 사용자를 안심시켜주기 위함
프로젝트 성과 : 이미지 거래 서비스 개발

API 설계

백엔드 파트를 맡고, 여러 팀원들이 협업하며 동일한 서비스를 개발하기 위해서 API를 통일하고 인지해야 할 필요성이 있었습니다.

따라서 각 기능 별 Request Header, Request Body, Response Header, Response Body, Error Type 들을 전부 정리하는 식으로 설계를 시작했습니다.

스마트 컨트랙트 저장 구조 설계

이미지 거래 과정에서 발생하는 소유권과 거래 이력을 위변조가 어렵도록 관리하기 위해, 거래에 필요한 핵심 정보는 스마트 컨트랙트에 저장하고 실제 이미지 파일과 일부 상세 정보는 Off-chain 영역에 분리해 저장하도록 설계했습니다.

구분	필드	설명
기본 블록 정보	`blockNumber`	거래가 기록된 블록 번호
	`timestamp`	블록이 생성된 시간
트랜잭션 정보	`txHash`	각 거래를 구분하는 고유 트랜잭션 해시
	`buyer`	구매자 지갑 주소
	`seller`	판매자 지갑 주소
	`signature`	거래 당사자와 소유권을 인증하기 위한 서명값
이미지 정보	`imageHash`	이미지 위변조 여부를 검증하기 위한 해시값
	`imageUrl`	Amazon S3에 저장된 실제 이미지의 Off-chain 주소
	`metadata`	이미지 제목, 설명, 카테고리 등 부가 정보
거래 정보	`price`	이미지 거래 가격
	`tokenId`	이미지 자산을 식별하기 위한 토큰 ID
	`tokenType`	ERC-721, ERC-1155 등 토큰 표준
검증 및 인증 정보	`verificationStatus`	이미지 검증 상태 (`VERIFIED`, `PENDING`, `FAILED`)
	`deviceId`	촬영에 사용된 디바이스 식별 정보
로열티 및 수익 분배	`royaltyRate`	재판매 시 적용되는 원작자 로열티 비율
	`creator`	원작자의 지갑 주소

모든 데이터를 온체인에 저장하면 저장 비용과 처리 부담이 커질 수 있기 때문에, 이미지의 위변조 검증과 소유권 증명에 필요한 imageHash, 거래 주소, 서명, 가격 등의 핵심 정보는 On-chain에 저장하고, 실제 이미지 파일과 상세 메타데이터는 Amazon S3에 Off-chain으로 관리했습니다.

이를 통해 블록체인의 무결성과 추적 가능성을 활용하면서도 저장 비용과 시스템 성능을 함께 고려한 구조를 설계했습니다.

프로젝트를 진행하며 느낀점

백엔드 개발을 담당하며 프론트엔드 팀과 스마트 컨트랙트 팀 사이의 협업 과정을 경험했습니다. 프로젝트 초기에는 각 파트가 동일한 기능과 데이터 구조를 이해할 수 있도록 요청·응답 형식과 예외 상황을 포함한 API 명세서를 구체적으로 작성했습니다. 명세를 정리하는 과정에는 많은 시간이 필요했지만, 이후 파트 간 소통 비용과 구현 과정의 혼선을 줄여 프로젝트 후반부의 개발 속도를 높이는 데 기여했습니다.

또한 이미지 해시를 활용한 유사 이미지 검증 로직을 백엔드에 구현하며 여러 예외 상황과 기술적 문제를 해결했습니다. 이 과정에서 API 명세는 단순히 인터페이스를 기록하는 문서가 아니라, 문제의 발생 지점과 각 파트의 책임 범위를 명확하게 정의하고 해결 방향을 공유하는 협업 도구라는 점을 배울 수 있었습니다.

공간 데이터 기반 재난 임시주거시설 최적 후보지 추천 시스템 개발

Fri, 20 Sep 2024 00:00:00 +0900

정리예정입니다.

역세권 데이터 기반 7호선 급행열차 최적 정차역 선정 시스템 개발

Fri, 20 Sep 2024 00:00:00 +0900

문제 정의

먼저 좋은 급행 정차역이 무엇인지 정의함. 편익 기준

사람이 많이 이용하고, 주변에 중요한 시설이 많은 역일수록 급행이 서야 하지 않을까?

데이터 수집

Q. 1000m 반경으로 최종 결정한 근거가 뭔지?
- 그 당시에는 200m나 500m 기반으로 했을때는, 값이 거의 0이 많이 나왔음. 그래서 수집이 의미없다고 판단해서 반경을 그냥 늘린거였음. 많은 고민 안하고… (이 부분 어떻게 답변 전략 생각해야 할 지 고민 필요)

전처리 및 EDA

데이터 단위 맞추기 위한 Standard Scaling
- ex. 경찰서 수 = 3, 병원 수 = 15, 인구 = 50000 처럼 변수마다 숫자의 크기가 완전히 다름. 그대로 모델에 넣으면 인구처럼 숫자가 큰 변수가 지나치게 큰 영향을 줄 수 있어서, Standard Scaling 표준화를 진행함.
- 즉, 각 변수의 평균을 0 근처로 만들고, 서로 비슷한 크기의 척도로 변경

다중공선성 해결

처음 독립 변수는 24개.

아파트 수가 많은 지역 - 총 인구도 많을 가능성이 높음 - 주택 수도 많음 - 편의점이나 음식점 수도 많을 수 있음

VIF (Variation Inflation Factor) 계산
- 총 인구: 138, 주택/단독 주택/아파트/연립주택/다세대 주택: inf
비슷한 변수들을 PCA 압축
- 음식점/카페/편의점 - 상업 시설로 압축
상관계수가 지나치게 높은 변수 제거
- 0.7 이상인 변수 제거

회귀분석을 통해 실제 승하차 인원과 관계있는 변수 찾기

처음 24개의 독립 변수를 전부 사용한 경우 모델:
- R² = 0.89, Adjusted R² = 0.74
변수 정리 후 16개의 독립 변수를 사용한 경우 모델:
- R² = 0.80, Adjusted R² = 0.70

불필요하고 겹치는 변수를 많이 제거하면서도 대부분의 설명력을 유지함.

회귀분석 결과, p-value 이용해 의미 있는 변수 선정

p-value < 0.05 이하인 유의미한 변수 선정
최종, 에스컬레이터, 경찰서, 도서관, 은행, 병원, 상업시설(PCA) 선정

어떤 특성을 가진 역이 중요한지는 어느 정도 알았다.. 하지만 모든 역을 그냥 중요도 순으로 1, 2, 3등으로 줄 세우면 문제가 있음. 예를 들어, 강남권의 대형 상업역, 중간 규모 생활권 역, 비교적 작은 지역 역은 역할 자체가 서로 다름. 그래서 비슷한 특징을 가진 역끼리 그룹을 만들어보자.

계층적 클러스터링 진행

선택 이유 : 표본 수가 약 200개 이하인 데이터에 적합하고, 미리 클러스터 개수를 정확하게 지정하지 않아도 분석할 수 있다는 점.
앞에서 선정한 역새권 특성들이 비슷한 역끼리 군집화됨.
- 군집 1. 상대적으로 중요한 역.
- 군집 2. 중간 정도 역.
- 군집 3. 상대적으로 중요도가 낮은 역.

각 군집에 가중치를 줌

중요한 군집에 속한 역은 최대한 정차시키고, 덜 중요한 군집은 상대적으로 덜 정차시키자.

이 가중치는 어느 기준으로 어떻게 이 값이 나온거지?

군집 별 가중치:
- 군집 1. 0.649.
- 군집 2. 0.232.
- 군집 3. 0.119.

급행 정차역 선정을 최적화 문제로 바꿈

가중치 높은 역을 다 세우자! 라고 하면 급행 열차가 아님. 하지만 모든 역에 서면 일반 열차와 똑같음. 따라서 아래와 같은 제약 조건을 넣어줌.

일반 열차의 운행 시간은 약 84.5분(5070초)이고, 급행은 이를 약 35% 단축한 53분(3180초) 수준으로 설정.

운행 시간은 53분을 넘지 않음녀서, 최대한 중요한 역에 많이 정차하라.

슬라이딩 윈도우 기반 최적화 알고리즘

각 역의 정차 여부를 0/1로 정의함.
- 1: 급행 열차 정차
- 0: 통과
운행시간 53분 이내라는 제약조건 설정
각 후보 조합에 대해 역 중요도 가중치 X 승하차 인원을 기준으로 점수 계산
시간 제약을 만족하는 조합 중 목적함수 값이 가장 높은 정차역 조합을 선택함.

최종 결과

급행 정차역: 17개 역
기존 일반 열차: 5070초 (약 84.5분)
급행 열차: 3180초 (약 53분)
운행 시간 약 37% 감소

운행 시간 제약을 만족하면서 주요 수요역을 최대한 포함하도록 최적 정차역을 선정함.

송인혁의 포스터 홀 둘러보기

Mon, 17 Jun 2024 00:00:00 +0900

Background

학회 발표는 듣는 청중이 몇 초 안에 연구의 핵심을 파악할 수 있도록 구성되어야 합니다. 즉, 복잡한 연구 내용도 한눈에 이해할 수 있도록 정리하고 전달하는 것이 중요합니다.

저의 웹사이트 포트폴리오 역시 마찬가지라고 생각했습니다.

포트폴리오를 방문한 분들이 여러 프로젝트의 내용을 하나씩 찾아보지 않아도, 제가 어떤 문제를 고민했고 무엇을 만들어왔는지 한눈에 파악할 수 있는 방법을 고민했습니다.

그러다 과거 KCC 2025 학회에 발표를 위해 방문했을 때의 풍경이 떠올랐습니다. 수많은 연구 포스터가 한 공간에 진열되어 있고, 관심 있는 연구를 자유롭게 둘러보던 포스터 세션의 모습이었습니다.

그렇다면 내 프로젝트도 학회 포스터처럼 한 공간에 전시해보면 어떨까?

이 아이디어에서 시작해, 지금까지 진행한 프로젝트와 연구를 하나의 학회 포스터 세션처럼 둘러볼 수 있는 공간을 만들어보았습니다.

Info

사이트에 접속해주세요.

Motivation

구현 내용

정리예정입니다.

In Hyuk Portfolio Homepage |

CS 지식의 정석

네트워크

Q1. 네트워크에 대해 아는 것이 있나요?

Q2. `OSI 7 Layer에 대해서는 아시나요?

Q3. 자료구조나 알고리즘에 대해 아는 것이 있나요?

Q4. 어떤 알고리즘을 사용하는 것이 더 좋은지 어떻게 판단하나요?

최종 버전 확정 및 초안 배포

Version 03 Architecture

Docker

AWS App Runner 운영 종료 이슈

중간 점검

NotiLLM 관련

기타

Version 간 결과 비교/분석

결과

v1 vs v2 vs v3

LangGraph 도입 검토 및 데이터셋 설계

LangGraph 도입하는 게 맞을까?

Version 01.

Version 02.

LangGraph 도입 시 (Routing 버전을 추가), 확인 사항

Evaluation Dataset 구성 기준

Coverage 확인

References

사용자 재질문 처리 전략

backend/app/pending.py 추가

classify_pending_turn 함수

resolve_extract_prompt 함수

파이썬을 활용한 머신러닝 딥러닝 입문

머신러닝 종류

머신러닝에 사용되는 파이썬 라이브러리

Scikit-Learn

딥러닝에 사용되는 파이썬 라이브러리

통계 분석 마스터 클래스

통계분석 마스터 클래스 배울 내용 소개

직관적 의사결정과 데이터 기반 의사결정

baseline_v1_auto_map Evaluation 및 개선

코드 개선 전, Baseline 테스트 결과

Error Case 1.

Error Case 2.

Error Case 3.

Error Case 4.

Error Case 5.

Error Case 5. [제외 케이스]

Error Case 6.

코드 개선 이후

Coding Test

접근 방법

풀이 전략

관련 이론 정리

접근 방법

풀이 전략

관련 이론 정리

접근 방법

풀이 전략

관련 이론 정리

LangSmith를 활용한 Evaluation 설계

Evaluation 설명

FastAPI 기반 AI Backend 부분 설명

LangSmith를 활용한 LLM 실행 추적

Code-based Evaluation 설계 과정

Evaluators.py 코드에 대해서..

Dataset 생성

Coding Test

분류

접근 방법

풀이 전략

관련 이론 정리

분류

접근 방법 및 풀이 전략

내 코드

잘 작성된 Class 기반 코드

알아두면 좋을 개념

분류

접근 방법 및 풀이 전략

진법 변환

소수 판별

접근 방법

풀이 전략

`v1` vs `v2` vs `v3`

`LangGraph` 도입하는 게 맞을까?

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항

`classify_pending_turn` 함수

`resolve_extract_prompt` 함수

1. 프로젝트 수준 (`build.gradle.kts`)

2. 앱 모듈 (`app/build.gradle.kts`)