[5기_9 ②] 만들려는 것이 있어서 배운다 — 프로젝트가 부른 AI 개념, GPU 실측 프로파일링, SQL에서 판다스로 🌱

GL 5기 성장일지 9회차 큐레이션

안녕하세요! 그로스로그 입니다!😊 🌱

필요해서 배운 개념, 검증하려고 만든 측정 도구, 쓰려고 그린 데이터 파이프라인입니다.

5기 큐레이션의 마지막 회차입니다. 세 분 다 만들려는 것이 먼저 있었고, 공부가 그 뒤를 따라갔어요.

 

01

🤖 프롬프트 골프 프로젝트를 위한 핵심 AI 및 아키텍처 개념 가이드

문세웅 님

이런 내용이에요
프로젝트에 AI를 붙여야 하는데 지식이 부족해서, 필요한 개념을 그때그때 습득하며 정리한 가이드입니다.
이유가 첫 줄에 있어요 — "지식의 휘발을 막기 위해 개념을 정리 해둬야겠다."
LLM 기초부터 프롬프트 엔지니어링 기법, 그리고 보안 개념까지. 각 항목에 "프로젝트 활용"이 붙습니다.

개념 정리인데 쓸 자리가 정해진 채로 쓰였습니다.

조금 더 들어가 보면

이 글의 형식이 특이합니다. 개념마다 두 줄이 붙어요.

1.1 Large Language Model (LLM)
개념 : 수천억 개의 매개변수를 바탕으로 대규모 텍스트 데이터를 학습하여 인간의 언어를 이해하고 생성하는 초거대 인공지능 모델
프로젝트 활용 : 플레이어가 입력한 프롬프트를 바탕으로 FE 코드(HTML/CSS/JS), DB 쿼리(SQL), API 명세(OpenAPI YAML) 등 다양한 도메인의 아티팩트를 생성하는 데 활용

개념과 활용이 한 세트입니다. 그래서 정의를 읽고 나면 바로 "우리 프로젝트에서는 이렇게 쓴다"가 따라와요.

멀티모달리티 항목도 마찬가지입니다.

"GPT-4o와 같은 멀티모달 모델을 통해 생성된 웹 화면이나 이미지를 비전(Vision) 기술로 직접 시각 평가하고, 원본 타깃 이미지와의 유사도를 정량 점수로 환산한다."

멀티모달을 채점 도구로 쓴다는 발상입니다. 생성된 화면을 사람이 보고 평가하는 대신 모델이 원본과 비교해 점수를 매기는 것이죠. 개념을 알기만 한 게 아니라 자기 문제에 대응시킨 상태입니다.

📝 원문에서는 이렇게 정리합니다

프롬프트 엔지니어링 부분이 실용적입니다. 기법을 셋으로 나눕니다.

· Role-Based Prompting — 특정 역할을 부여해 답변의 전문성을 높이는 기법

· Few-Shot Prompting — 입출력 예시를 하나 이상 제시해 원하는 출력 형식과 규칙을 학습시키는 기법

· Context & Format Specification — 제약 조건·입력 배경·출력 형태(JSON, Markdown 등)를 정교하게 지정

셋의 목적이 조금씩 다릅니다. 역할은 답변의 결을 정하고, 예시는 형식을 정하고, 명세는 경계를 정해요. 프롬프트를 짤 때 무엇이 부족한지에 따라 어느 기법을 쓸지 고를 수 있게 됩니다.

큐레이터 노트

쓸 자리를 적어둔 개념 정리라 뽑았습니다.

AI 개념 정리 글은 아주 많습니다. 대부분 정의로 끝나요. 이 글은 항목마다 "프로젝트 활용"을 붙입니다. 그래서 나중에 다시 읽을 때 "이걸 왜 정리했더라"가 안 생깁니다.

정리한 이유를 첫 줄에 적은 것도 좋았습니다 — "지식의 휘발을 막기 위해." 프로젝트를 하며 급하게 익힌 것들은 끝나면 사라지는데, 그걸 알고 미리 붙잡아둔 것이죠.

필요가 먼저 있었다는 것이 이 글의 성격입니다. 커리큘럼을 따라간 게 아니라 프로젝트가 요구한 순서대로 배웠어요. 그래서 목록이 교재와 다르고, 대신 실제로 쓰이는 것들만 남았습니다.

원문 읽으러 가기  ↗velog.io/@moonsyang/GrowthLog-%EC%84%B1%EC%9E%A5%EC%9D%BC%…

 

02

📈 LLM 서빙 엔진 실측 프로파일링과 nano-vLLM 프로젝트 회고록

김류흔 님

이런 내용이에요
nano-vLLM 서빙 엔진의 내부를 직접 계측하는 프로파일러를 구축한 프로젝트 회고입니다.
목표가 분명합니다 — "어림잡은 지표가 아닌, 100% GPU 실측 기반의 모니터링 시스템"을 만들어 최적화 효과를 정량 검증하는 것.
그런데 이 글의 절반이 리더로서의 반성입니다. 기획안 확정이 늦어 팀 작업 분배가 잘 안 됐다고 적어요.

기술 성과와 운영 실패를 같은 글에 적은 기록입니다.

조금 더 들어가 보면

실험 설계가 먼저 나옵니다.

Target Model     Qwen3-0.6B
Serving Engine   nano-vLLM  (대조군: HF Transformers DynamicCache)
Target Scenario  긴 공통 컨텍스트(Prefix) 질의 응답

대조군을 둔 것이 핵심입니다. nano-vLLM만 재면 "빠르다"는 말밖에 못 하는데, 대조군이 있어야 얼마나 빠른지가 나옵니다.

그리고 시나리오를 긴 공통 프롬프트가 반복되는 상황으로 잡았어요. Prefix Caching의 효과를 보려면 그런 조건이 필요하니까요. 측정하려는 것에 맞춰 시나리오를 설계한 것입니다.

🔧 측정 파이프라인을 직접 만든 것

프로파일러 구축 대목이 실무적입니다.

"단발성 배치 프로파일링 스크립트 실행 특성상, 프로세스 종료 시 시계열 데이터가 유실되는 문제를 방지하기 위해 Pushgateway를 중계 기지로 채택하고, request_index 기반의 Gauge 라벨링과 Grafana 자동 프로비저닝 대시보드 파이프라인을 구축했습니다."

문제 → 선택 → 이유가 한 문장에 들어 있습니다. 배치 스크립트는 끝나면 죽는데 그러면 수집된 데이터도 사라지니, 중계 기지(Pushgateway)를 두어 먼저 밀어 넣는 구조를 택한 것이죠.

측정하려다 보니 측정 인프라부터 만들어야 했던 상황입니다.

📝 원문에서는 실패도 적습니다

글의 후반부가 「리더로서의 솔직한 반성과 작업 분배에 대한 회고」입니다.

"프로젝트 초기 방향성을 잡는 과정에서 실질적인 기획안을 7월 11일에야 확정 짓게 되었습니다. 이로 인해 지난주까지 과제 수행이 다소 유기적이지 못했으며, 팀원 간 효율적인 Task 분배가 이루어지지 못했습니다."

날짜까지 적었습니다. 그리고 그 지연이 무엇을 망쳤는지를 연결해요 — 기획이 안 정해지니 나눌 일이 안 정해졌고, 그러니 팀이 유기적으로 못 움직였다는 것.

그다음 절의 제목이 이 글에서 가장 값어치 있는 부분입니다.

「다시 프로젝트를 진행한다면?」 — 최적화 주제별 분배 포맷

그리고 실제로 다시 설계합니다. 최적화 기법별 독립 격리(Ablation) 측정 프레임워크라는 큰 틀을 세우고, 그 안에서 파트를 나눠요 — CUDA Graph 최적화 파트, Continuous Batching & 다중 사용자 환경 파트처럼요.

반성에서 멈추지 않고 대안 설계까지 간 것입니다. "다음엔 잘하겠다"가 아니라 다음엔 이렇게 나누겠다는 구체적인 형태로요.

큐레이터 노트

성과와 실패를 같은 글에 적은 회고라 뽑았습니다.

프로젝트 회고는 대개 한쪽으로 기웁니다. 성과 보고이거나 반성문이거나요. 이 글은 앞쪽에서 프로파일러 구축과 실측 검증을 다루고, 뒤쪽에서 리더로서 무엇을 놓쳤는지를 적습니다. 두 부분이 같은 무게로 있어요.

"다시 한다면"을 설계로 답한 것이 특히 좋았습니다. 기획 확정이 늦었다는 반성 뒤에, Ablation 프레임워크라는 틀을 제시하고 그 안에서 역할을 나눕니다. 반성이 다음 프로젝트의 설계도가 된 셈이죠.

대조군을 둔 실험 설계도 짚어두고 싶습니다. 최적화 이야기는 "빨라졌다"로 끝나기 쉬운데, 무엇과 비교해서 얼마나를 재려고 대조군과 시나리오를 먼저 정했어요. 앞선 회차에서 이분이 "어림잡은 지표가 아닌"이라고 적은 것이 여기서 실물이 됩니다.

원문 읽으러 가기  ↗velog.io/@telap111/LLM-%EC%84%9C%EB%B9%99-%EC%97%94%EC%A7%…

 

03

🐼 [Build] raw 데이터를 SQL과 판다스로 구조화하기 시작한다

김노석 님

이런 내용이에요
SQL 공부를 1차로 마무리하고 다음 단계로 넘어가는 기록입니다. 책 한 권을 끝까지 봤다고요.
그런데 다음 단계를 "판다스 문법 배우기"로 잡지 않습니다. "여러 곳에 흩어져 있는 raw 데이터를 분석 가능한 구조로 바꾸는 일"이라고 적어요.
그리고 머릿속에 있는 흐름을 파이프라인으로 그려둡니다.

[Build] 연재답게, 정한 것을 만들기 시작하는 지점입니다.

조금 더 들어가 보면

SQL을 마친 소감이 담담합니다.

"책 한 권을 끝까지 봤고, 데이터가 테이블 안에서 어떻게 저장되고, 연결되고, 조회되는지는 기본 흐름을 한 번 지나왔다."

"한 번 지나왔다"는 표현이 정확합니다. 다 안다고 하지 않고, 흐름을 훑었다고만 적어요.

그리고 다음 단계를 정의하는 대목이 이 글의 핵심입니다.

"이제 하려는 것은 단순히 SQL 문법을 더 외우는 일이 아니다. 여러 곳에 흩어져 있는 raw 데이터를 분석 가능한 구조로 바꾸는 일이다."

도구를 더 배우는 게 아니라 문제를 정한 것입니다. 문법을 더 외우는 것과 흩어진 데이터를 구조로 바꾸는 것은 다른 일이니까요.

🔗 파이프라인을 먼저 그린다

그리고 머릿속에 있는 흐름을 그대로 적습니다.

raw data
→ database
→ SQL query
→ pandas dataframe
→ analysis table
→ report
→ AI analysis
→ action plan

여덟 단계짜리 지도입니다. 지금 서 있는 자리(SQL query)와 다음 걸음(pandas dataframe)이 그 안에 있고, 끝에는 action plan이 놓여 있어요.

이 그림이 있으면 판다스를 왜 배우는지가 분명해집니다. 그냥 다음 도구라서가 아니라, SQL query와 analysis table 사이를 잇는 자리이기 때문이죠. 그리고 그 끝이 보고서와 실행 계획이라는 것도요.

📝 원문에서는 이렇게 시작합니다

첫 실행 항목도 구체적입니다.

"먼저 raw 데이터를 그대로 파일 단위로만 보지 않고, 테이블 구조로 바꿔야 한다."

파일 단위에서 테이블 구조로. 흩어진 파일을 그대로 두면 매번 열어서 찾아야 하지만, 테이블로 바꾸면 질의할 수 있게 됩니다. 앞서 배운 SQL이 여기서 쓰이는 것이죠.

문장을 한 줄씩 끊어 쓰는 형식은 이번에도 같습니다. [Decide]에서 정한 것이 [Build]에서 실행되는 구조도 이어지고요.

큐레이터 노트

다음 단계를 도구가 아니라 문제로 정의한 글이라 뽑았습니다.

공부 계획은 대개 도구 목록이 됩니다. "SQL 다음엔 판다스, 그다음엔 시각화" 하는 식으로요. 이 글은 "단순히 SQL 문법을 더 외우는 일이 아니다"라고 먼저 선을 긋고, 무엇을 하려는지를 적습니다. 흩어진 데이터를 분석 가능한 구조로 바꾸는 일이요.

파이프라인을 미리 그린 것이 이 글에서 가장 쓸모 있는 부분입니다. 여덟 단계 중 지금 어디에 있는지가 보이고, 각 도구가 어느 자리를 맡는지도 정해집니다. 이러면 공부하다 길을 잃지 않아요.

그리고 그 파이프라인 끝이 report → AI analysis → action plan이라는 것도 짚고 싶습니다. 데이터를 다루는 목적이 분석 자체가 아니라 행동이라는 것이니까요.

이분의 [Decide] 글들을 5기 큐레이션에서 여러 번 소개했는데, 이번엔 [Build]입니다. 정하는 글과 만드는 글이 짝을 이루며 이어지는 연재의 모습이 5기 마지막 회차에 놓인 것도 잘 어울립니다.

원문 읽으러 가기  ↗www.nsklog.dev/devlog/2026-07-18-build-heron-automata-sql-…

💡 세 편을 겹쳐 읽으며

개념 가이드, 프로젝트 회고, 학습 계획입니다. 세 편 다 만들려는 것이 먼저 있고 공부가 그 뒤를 따라간 기록이에요.

필요가 순서를 정한다

문세웅 님은 "프로젝트에 AI를 접목해야하는데, AI 관련 지식이 부족하기 때문에 필요한 개념을 그때그때 습득하면서" 정리했습니다. 커리큘럼이 아니라 프로젝트가 순서를 정한 것이죠.

김류흔 님은 최적화 효과를 검증하려다 보니 프로파일러부터 만들게 됐습니다. 재고 싶은 게 있었고, 잴 도구가 없어서 만든 순서예요.

김노석 님은 아예 파이프라인을 먼저 그리고 그 안에서 판다스의 자리를 정합니다. 다음 도구라서 배우는 게 아니라 그 자리가 비어 있어서 배우는 겁니다.

목적이 먼저 있으면 배울 것의 목록과 순서가 저절로 정해집니다.

다시 한다면 어떻게 할지를 적었다

두 번째 공통점은 다음을 위한 형태로 남긴 것입니다.

김류흔 님의 「다시 프로젝트를 진행한다면?」이 가장 명시적입니다. 기획 지연을 반성하고 끝내는 대신 Ablation 프레임워크라는 틀을 세워 역할 분배까지 다시 설계했어요.

문세웅 님은 "지식의 휘발을 막기 위해" 정리했다고 적습니다. 지금의 나보다 나중의 나를 위한 기록이죠.

김노석 님의 파이프라인도 같습니다. 여덟 단계를 그려두면 몇 달 뒤에도 어디쯤인지 알 수 있으니까요.

측정할 수 있게 만들어놓고 시작한다

세 번째는 이 회차와 앞선 8회차가 함께 보여주는 것입니다.

김류흔 님은 대조군(HF Transformers DynamicCache)과 시나리오(긴 공통 프리픽스)를 먼저 정했습니다. 문세웅 님은 멀티모달을 유사도 정량 점수를 매기는 데 씁니다. 김노석 님의 파이프라인 끝에는 report가 있고요.

만들기 전에 "무엇으로 잘됐다고 할 것인가"를 정해둔 것입니다.

이번 회차에서 가져갈 것

1. 개념 정리에 "우리 프로젝트에서는" 한 줄 붙이기.

정의만 적으면 나중에 왜 정리했는지 모릅니다. 쓸 자리를 같이 적어두면 다시 읽을 때 바로 연결됩니다.

2. 프롬프트 기법은 부족한 게 뭐냐에 따라 고르기.

답변의 결이 안 맞으면 역할 부여, 형식이 안 맞으면 예시 제시, 범위가 안 맞으면 제약·출력 형태 명세입니다.

3. 성능 개선은 대조군 없이 못 잰다.

"빨라졌다"가 자료가 되려면 무엇과 비교해서 얼마나가 있어야 합니다. 시나리오도 재려는 기법에 맞춰 설계하세요.

4. 단발성 스크립트의 지표는 프로세스와 함께 사라진다.

Pushgateway 같은 중계 지점을 두면 종료 후에도 남습니다. 측정하려면 측정 인프라부터 필요할 때가 있어요.

5. 기획 확정이 늦으면 분배가 늦고, 분배가 늦으면 팀이 못 움직인다.

리더의 지연은 본인 일정이 아니라 팀 전체의 일정을 밉니다.

6. 반성은 다음 설계로 적기.

"다음엔 잘하겠다"가 아니라 "다음엔 이런 틀로 이렇게 나누겠다"까지 가야 다음에 쓸 수 있습니다.

7. 공부 계획을 도구 목록이 아니라 파이프라인으로 그리기.

raw data → … → action plan처럼요. 각 도구가 맡을 자리가 정해지면 왜 배우는지가 분명해집니다.

---

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.

좋은 글 남겨주신 문세웅 님, 김류흔 님, 김노석 님께 감사드립니다! 😊

5기 큐레이션은 여기까지입니다. 아홉 회차 동안 스물여덟 분의 기록을 소개했습니다. 각자 다른 자리에서 쓴 글인데 모아 놓으니 한 기수가 무엇을 지나왔는지가 보이네요. 좋은 기록 남겨주신 모든 멤버분들께 감사드립니다! 🌱

- 에디터 · 성장일지 큐레이터 -

---

※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.