지각해서 Keynote 2개 놓침
(앞부분 모두 생략)
Marp: 발표자료도 markdown slide
“디테일한 구현은 AI가 담당. 자연어로 완성된 모습을 정의하는데 집중” AI지원 개발, LLM 페어 프로그래밍
고속 개발 사이클(저비용 아이디어 검증. MVP 개발의 가속화) 요구사항 정의와 솔루션 설계에 집중.
제안서 대신에 동작하는 프로토타입을 사용. 소인수로 대규모 개발 –> 적은 커뮤니케이션 비용으로 억제
코드베이스 인식 능력의 진화 - LLM으로 코드를 탐색해서 읽은 다음 단계적으로 구현 Language Server를 사용하는 것보다 효율적. (주석 등을 포함한 context 형성)
지식관리 - 프로젝트 관리, 문서화 능력 (오케스트레이션 필요)
급속한 확산. 가트너 보고서(품질과 개발자 만족도 상승) 도구와 프로세스 발전(현재 상태에 고정된 것이 아니라 계속 새롭게 바뀌고 있다는 점에 주의. 과정 중에 있다…)
PRD - 작업 분할 - TDD 구현 - 배포 Full CI/CD 적용.
Spec-driven은 새로운게 아니다. 기존의 개발자도 이게 없으면 개발이 불가.
나중에는 소스코드가 자산이 아니라 부채가 되지 않을까? 여러 AI 툴들이 CLI를 제공하고 있는데, CLI의 headless모드를 사용해서 명령어를 지시하도록 지원. 자동화 편의성에 대한 고려
문서화, 테스트 자동화, 리뷰, IaC, CI/CD, Ops 고도화가 지원되지 않으면 바이브 코딩은 대량의 쓰레기 코드를 생성
소프트웨어 레벨이 충분하지 않으면 안된다. 바이브 코딩으로 레벨업을 할 수 없나?
사람이 읽기 힘든 코드는 AI도 읽기 힘들다. 문제가 생겼을 때 롤백할 수 있는 코드를 반드시 가지고 있어야 한다. (checkpoint를 이동할 수 있도록)
AI가 쉽게 접근 가능한 형태로 만들어서 소스코드/문서 저장소 형태로 관리.
모든 작업에서 프로세스를 지켜나갈 것.
PRD 문서로부터 손쉽게 생성할 수 있도록 만들기. 여러 프로젝트에 재활용.
앞으로의 과제는 리뷰. 사람에 의한 수동 리뷰가 병목으로 등장. 리뷰/검증을 어디까지/어느정도 수준으로 자동화할 것인가 <– 코딩 레벨을 나누는 중요한 척도. 원칙을 세우고 지킬 수 있도록 프롬프트 전략 수립.
문제 해결에 대한 Demo, Issue 처리를 공개할 수 있는 시간 부여 - 업무 만족도. Context의 크기를 작게 유지할 수 있는 구조를 잡아야 한다. Clean context 상태에서 바로 작업할 수 있는 구조.
고민했던 부분들. Prototyping - Design - Coding - Testing
우유 사고 아보카도 있으면 6개 사와 -> 우유 6개. computational 하게만 보면 문제 없어 보이지만, 당연하게 생각하는 상식 너머에는 여러 맥락들이 존재. - 요구사항의 이해
맥락은 우리가 인지하고 있는 것 이상으로 중요하다. AI Agent도 요구사항을 받았을 때, 분석/해석하고 작업을 수행해야하기 때문에 매우 중요.
prompts, history, policy, memory, code index
memory, history에 의해서도 컨텍스트도 커질 수 있음. code index가 너무 커지면 조회가 어려워진다. context가 너무 복잡해지는 상황.
context의 확장 가능성: filesystem + web + database + metric + log + tools 너무 많은 확장 가능성은 요구사항에 맞게 context를 구성하기 어렵게 만든다. 이 부분을 다루는 것이 context engineering. 모델 성능이외에도 중요한 부분.
Context Engineering <-> Foundational Components
GeekNews에 많이 있음
시스템이 커지고, 코드 품질 관리가 안되고, 기술부채가 증가하는 상황. 적절한 context를 찾기 어려워지는 문제 + 한번 안좋은 context가 생성되었을 때 발생하는 부정적 피드백 확산.
Context 잘 관리하면서 팀 전체 생산성 올리기
Zero context 또는 매우 단순한 context에서 시작하므로 잘될 수밖에 없다. Userflow의 단순화, 여러 Web 기반 서비스들의 체험장벽 하락 등.
구현 방법에 대한 아이디어, 힌트를 얻고 싶을 때. 핵심 로직의 획득과 재사용.
기획자/디자이너도 같이 쓰면 좋지 않을까? -> Vibe Design 시작점
일반적인 디자인 과정: 아이디어 구상 / 스케치, 와이어프레임, 시각 디자인 / 목업, 인터랙티브 프로토타입 제작, 구현. 이 과정에서 여러 경로로 피드백 반복. (ex. 예상과 다른 동작 발생시 조정)
Vibe Design에서는? 시안 12개 만들어 줘 -> 구현을 먼저 시작하고 아이디어 구상으로 넘어간다. 인터랙티브 디자인 아이디어를 먼저 검증하고 피드백한다는 부분이 장점.
Figma 디자이너의 Vibe Design.
구현 - 와이어프레임 - 피드백 진행
구조 전환
디자이너가 바로 v0 링크를 전달 -> 가져다 쓰세요. 바로 배포로 전달. 피드백하기에도 좋다. 엔지니어는 예외처리, 안전성 등
Q. 우리 제품 위에서 어떻게 동작하지? 실제 데이터로 상호작용 확인 가능한가?
디자이너들에게 로컬 개발환경 셋업 지원. 1:1 온보딩 진행. 로컬환경 셋업을 할 수 있는 스크립트 제공. –> PR 올리는 디자이너. 고치고 싶은 부분이 눈에 많이 보이는데, 개발자가 병목이던 부분을 직접 해소할 수 있도록.
DB schema를 수정하는 디자이너(???). sql, prisma 수정 의존성이 없고, 적은 context를 사용하는 작업은 충분히 Vibe 가능. 리뷰만 꼼꼼하면 된다.
다같이 Vibe Coding하는 날을 정해서 운영. 우선순위는 낮아서 처리하지 못하는 Task들을 Vibe Coding으로 해치우는 날. - 노하우 공유
Context 관점으로 접근하는게 중요. 큰 작업도 작게 나눠서 요청하기.
질문(Ask)을 먼저 시작. 다이어그램 요청. –> 대화 이력은 context가 된다. 답변을 하기 전에 먼저 생각을 하도록 요구. “Chain of Thought”
구현방법을 알고 있어도 그 방법을 개선할 수 있을지 물어보는 것 추천. 작업량이 많다면 하나씩 요청. 피드백을 해줄 것.
직전 대화가 다음 답변에 영향을 미친다는 점에 주의. 맥락이 다르다면 새로운 세션을 생성하는 것을 추천. 필요한 Context가 있다면 되묻게 하기.
디렉토리를 이동해서 질문하거나, 탐색 디렉토리 직접 알려주기. 공식문서 제공.
프롬프트 엔지니어링에서 고려하는것? Rules & Memory. 템플릿을 사용하되 남용하지 않도록 사용. (자신의 팀과 프로젝트에 맞는 형태로 작성. 템플릿을 통해서 공부할 수 있는 부분은 있음)
코드 품질과 유지보수성의 중요성:
Vibe Coding을 계속 하다보면 복잡해지고, 복잡한 시스템에서는 Context 구성이 어렵다. 계속 개선한다.
Q. Architecture + Design Pattern을 Vibe의 context로 제공할 수 있을까?
Context window가 아무리 커도, 한번에 넣기에는 불가능하거나 비효율적인 경우가 많음. 실수는 빨리 발견해야 한다.
테스트가 실패해서 안도해본 경험. 맥락을 빠르게 알 수 있는 도구.
켄트 백 인터뷰?
QA Bot 만들기? 자연어로 QA 리스트 작성. Cursor에게 전달해서 테스트를 작성하도록 요청. 만들어진 테스트 리뷰하고 돌려보고 피드백 -> 다시 QA리스트 작성.
현재 발표자 팀에서 다음 단계로 고민하고 있는 주제.
Context의 확장 가능성. DB, Metric, Lob, Jira, Slack에 접근하도록 하고, 자연어 질문을 했을 때 검색하도록 지시. 이후에는 Ticket, Notification, GitHub Issue로 Digest.
소프트웨어를 사용해서 결정론적으로 문제를 해결하려고 했는데 비결정론적인 해결방법(AI)을 사용하게 되었다.
(Q&A는 자리비움 문제로 생략)
현재 Claude Code 쓰는 분? 책이 작성 중. 한빛미디어에서 책이 나올거라서, 이번 발표는 시간관계상 동기부여에 초점.
한국의 trend는 어떨까? 최근에 Codex CLI가 잠깐 오르고 있는 모양새. Claude Code 사용자 - 8월 중순부터 성능저하의 체감. 품질 저하 논란, 원인 등
Heavy 사용자들 8월 중순에 주간 사용량 제한이 도입됨. Claude Code 불만이 발생한 상황에서 다른 CLI 도구의 홍보. Gemini의 경우 IDE 연동을 많이 하는 중.
크게 3가지 레이어
코드 밖의 영역에서는 Presentation 관련이 많이 회자되는 것 같다. Skywork, GenSpark 등.
2023 GitHub Copilot -> 2024 Cursor IDE -> 2025 Claude Code(+ MAX 요금제) -> ?
기업들은 열심히 도입 중(Google의 25% 공식 발표). 카카오는 현재 AI 마일리지 시험중. 3달간 진행했을 때, Cursor -> Claude Code 변화. 내부 설문조사 결과, 평균 70% 정도. Heavy 사용자는 99%로 응답하기도.
AI가 변화시키고 있는 개발환경. 우리는 이제 다른 일을 한다.
AI와 병렬적으로 일을 하는 것을 시연할 예정.
비어있는 폴더에서 Claude 호출. 기본 Tool 14개. MCP 설정 없이 진행.
한빛미디어 사이트에서 신간목록을 가져와서 마크다운 파일 저장. (권한 요청)
기존 부분과 무엇이 다를까? 1 prompt로 세부 task들을 계획에서, todo list의 depth를 깊이 설정해서 업무를 수행.
6월에는 업무에 활용해볼 목표로 JIRA 이슈 기반 작업을 수행.(JIRA MCP)
Commit이 추가되면, GitHub Action에서 Secret key를 사용해서 Claude Code를 수행. 보안 문제를 위해 PR을 직접 만들지는 않음 PR이 생성된 후에는 Review action 수행.
사내 해커톤으로 AI 심사 시스템 제작
GitHub history를 기반으로 개발시간 추정 -> 몇차례 조정 후 48시간 개발
책: 생성물이 아무리 빨리 나와도, 환각 문제가 있으므로 교정이 필요함. GitHub에 star 많이 달리더라…
“나만의 AI 유튜브 번역기”를 파이썬으로 만들기. YouTube 링크를 넣으면 자막추출 등 수행
오프라인 행사에서 AI 활용: 행가 기획(Gemini), 사이트 제작(Claude Code)과 운영. 홍보영상과 포스터(Gemini, Veo3)등 공지사항 등(GPT-4, Claude Code)
9월. 바이브 코딩 세미나 참가. 초보인 척 참가. VR 도전.
AI Track + Vibe Coding Track 구성에서 어딘지 잘 모르겠더라. 반반 섞여있음. 잠깐 홍보: LINE ABC Studio, ABC User Feedback 오픈소스 등
질문답변 x 언어 x AI 바이브코딩 시대에 최적화된 경험.
언젠가부터 경영을 강요받은 엔지니어: 경영진 <-> 개발자 관점차이
경제 개념의 틀: 투자 - 기대효과 - 산출물 - 성과 - 투자를 돈이 떨어질 때까지 무한반복
투자+기대효과 –산출물–> 성과: 이 모든 것들을 감싸고 있는 비용의 언어. “비용대비 효과”를 증명하는 것의 무한반복.
2023년부터 시작된 본질의 시대: 지르기만 할수는 없다. 비용 개념이 중요해졌다. 중요하다고 생각하는 것보다도 훨씬 더. 변동비, 고정비
왜 IT 서비스는 산업혁명이었나? 제조업과 비용구조(비용곡선)가 완전히 다르다. 일정 수준의 scale 까지는 고정비를 굳힐 수 있음. 모멘텀(최적생산성)이 오면 그때 단계적으로 높아짐.
그런데 AI 시대는? 이용량에 비례해서 토큰값이 나간다. 품질과 비용의 상관관계가 깨진다. 좋은 답을 얻기전까지 낭비도 발생함. 그런데 안할수도 없고…
MLOps->LLMOps로 패러다임 변화: Microsoft 자료
경영진: AI시대 비용을 낮출 구석은 결국 생산비용 절감으로 달성하는 것인가? 인프라 등에서 비용깎기는 한계가 있다. 기획-디자인/개발-배포-운영프로세스의 비용을 낮출수 있는가? Q. AI를 쓰면 1명이 할 수 있지 않나? -> 실제로 일어나고 있다.
무슨 생각을 할까
경영진은 ‘효과’가 비슷할 것이라는 고정관념이 있다. 임팩트 대비 비용을 줄이면 되지 않나?라는 생각의 근원. 효과를 훨씬 키우는 방향으로 얘기해보면 어떻지? 효과는 무엇인가? 모호하다.
회사의 가치는 무엇이고 어떻게 말할 수 있는가? 언어화, 가시화, 생산성, 재생산성 4개로 보는 것을 제안함.
시니어만 채용한다면(통계적으로는 분명 그렇다). 시니어의 정의가 뭘까? 경력 많음? 부하 직원에게 시킨 적 있음? 매일 커밋 많이 했음?
친절한 설명, 좋은 질문, 명확한 기대 = 위임을 잘함 = 시니어다움
이론에 근거한 좋은 질문? 평가받는 수단은 적지만 (LLM) 원리는 이해하자.
“케라스 창시자에게 배우는 딥러닝”. 발췌
프롬프트 엔지니어링의 압축 - 좋은 질문 스택오버플로우 참고
엔지니어의 레벨을 반영한 질문
Ask 모드에서 최적화 또는 아키텍처에 대한 맥락 준비 후 사용. 배경은 고정적(그리고 알고있는 부분). 목표 설정. 해결 방법 발굴/선택(몰랐던 영역의 범위)
위에 4가지를 사용해서 경영진의 문법으로 대화
Vibe Coding을 한다? 더 진한 엔지니어링의 시대 경영과 효율의 언어로 말하고 만들 줄 아는 엔지니어 -> 행복한 코딩 life.
홍보: A.X 에이닷엑스. HuggingFace에 모델 공개되어 있음.
확장되는 LLM 생태계(Vertical LLM)
직접 만드는 사람들이 늘어날 것으로 예상하고, 발표를 준비함. A.X의 개발 타임라인과 일치함.
LLM의 지식을 “사람”이 “유용”하게 사용할 수 있도록 만든다.
목적성 부여. 포맷팅.
system, user, assistant 등의 special token을 사용해 포맷(턴, 역할 등)을 부여. SFT(Supervised Fine-Tuning)
학습하고자 하는 포맷의 데이터 확보. 다음 토큰에 대한 예측
ex) LLM의 function-call기능: search를 수행하고 포맷을 정리해서 반환하도록 tools 태그 삽입
SFT만으로 학습은 충분하지 않다.
창작의 영역은 어렵지만, 여러 답변 중에 선택하도록 만드는 것은 해낼 수 있다. 모델이 학습을 통해서 A, B가 아니라 더 좋은 답변 C를 만들어내도록 만들자.는 개념.
o1, Deepseek에서 Reasoning, Reinforced Learning
프롬프트 엔지니어링 화두: Chain of thought step by step.
응답의 과정에서 중간에 정리하는 것.
Reasoning Model Process
Alignment Tuning을 다시 살펴보면… 선호도(Preference)는 다 다른다. 인간 군상의 평균정도의 선호도? 부정확하다. RM 학습에 영향을 주고, 학습 불안정 및 성능 저하가 발생한다.(잘못된 피드백. 리워드 해킹)
RLVR(Reinforced Learning with Verifiable Reward)
LLM Training Cycle에 대해서.
인터넷에 있는 데이터는 이미 고갈되었다. 더 키우고 싶다면 만들어내는 과정이 필요.
Longer & Precise Reasoning 고등교육 -> 전문 수학자 -> 새로운 Math Theorem 발견
LLM 구조상 length가 길어질수록 context 소실 등 취약점이 발생하므로, 이 부분을 눈여겨본다.
학습은 다 열려있다. 데이터를 만드는 것이 문제. 어디서 얻어오고, 어떻게 생성해서 공급할 것인가?
고품질 합성 데이터를 생성하는 것이 Frontier 모델 개발의 주요 상품이 될 것으로 예상. 원클릭 데이터 생성/학습.
5년차, Tech Lead, Team Lead. 허허벌판?에서 Document AI 만드는 이야기.
Document Parse: Chart, Table을 추출. multi-page table, nested table, forms 등등
Key-value 추출. (schema를 추출하거나, 원하는 schema에 맞게 value 추출)
모델의 관점보다는 서빙하는 개발자 관점에서 제품의 흐름을 살펴보면. 처음에는 제품이 없고, 미션이 있었다. (Easy to apply) OCR 전문가들이 있으니, 잘하는 것부터. 문서 AI를 해볼까? 쉬운 MLOps + 문서 정보 추출 모델
OCR Pack
Base OCR 모델 - 고객은 서비스 - 사용하면서 인입되는 데이터를 가지고 base model의 fine tuning 하는 선순환. Data flywheel을 쉽게 경험할 수 있는 제품을 만드는 것은 쉽지 않다. 데이터 저장, 어노테이션 툴, 데이터 버저닝, 모델 저장, fine-tuning에 대한 eval, 배포 pipelining 등…
팀 인원이 많지 않았다. 처음에는 화면 없이 PIC 지정해서 접근. 크런치 해서 데모 진행 –> 첫 고객
요구사항 반영하면서 개선: 처리량 20배. 팀 역량도 퀀텀점프.
개발팀이 직접 AI on-premise(제안서-유지보수) 경험. full-stack AI 엔지니어 역량의 발판.
제품이 크고 복잡. 개발/유지보수 힘듬. 설치도 오래 걸린다. 설치 워크샵을 진행했는데, 1일 안에 설치한 사람이 없었다.
Base model 성능이 너무 좋아지니까 Data Flywheel이 무의미할 정도가 된다.(선순환 이전에 순환의 필요성 없어짐. 오히려 fine-tuning후 성능이 저하되기도 함.)
고객은 더 단순하게 간단한 추론 기능만 원하기도 했었다. (처음부터 잘되는 모델 받아서 쓰겠다.) 더 단순한 제품의 필요성. 대량의 문서를 강건하게 처리하는 추론 서비스에 대한 기획
더 단순한 OCR Pack 중에서 API를 서빙해서 SaaS화 성공.
From scratch. 모델 서빙 고도화부터 시작. 기능을 대부분 빼고 추론 기능에 집중하니 고객이 더 증가.
솔루션으로 온프레미스 고객에게 배포하기에는 부족한 느낌. 운영을 위한 툴 추가. 모니터링 툴. 어드민 툴. 스토리지, 인증/권한 관리. 라이선스. 데모. 추가하면서 온프레미스 엔터프라이즈 제품으로 성장.
엔터프라이즈 사업을 위한 새로운 팀 구성
솔라박스 효과: 운영 효율화, 설치시간을 day 단위에서 minute 단위로. 고객사에 나가는 오픈소스들의 버전 관리. 표준화된 매뉴얼 -> 파트너사에 이관리 쉬운 방향으로 발전 Enterprise 대량 생상 확장성 확보.
RAG 급부상으로 Document Parse 모델 관련 유입량이 증가. SaaS에서는 야생(malformed)의 문서들이 많았다. 처리하다가 panic 발생
사용량이 많아지니 cgo로 인해 메모리 안정성 문제 발생.
문서처리 컴포넌트를 별도 분리. 언어제약을 해소(Python 라이브러리 기반으로 제공, Go는 fallback을 지원)
1000 페이지 문서 처리에 대한 요구
이외에도 다양한 개선
1일 300만 처리 가능 제품으로. 제품과 팀의 성장
Scalability 확보에 노력 중. (100 -> 1000)
글로벌 스케일로 확장하는 것이 목표. 채널 다양화(여러 마켓플레이스 등록으로 매출 증가) 기존 모델들을 활용한 Application 개발 -> 매출.
풀어야 하는 재밌는 문제들이 많이 있음.(고도화)
더 크게 가려면? (1000 -> 10000)
AI 기술로 ‘개인’의 능력이 증강 되는 시대, ‘팀’은 어떤 의미를 가져야 하는가?
개발팀이 없는 상태로 들어와서, 채용과 함께 개발문화를 만들어나가야 하는 상황.
지식으로 쌓은 전문성의 가치가 폄하. AI 기술에 대한 FOMO(Fear Of Missing Out)는 증가하는 대혼돈. 좀 속상하더라.
사람바다 바이브 코딩에 대해서 정의를 다르게 하던데…. AI의 도움을 받아서, 자연어 대화로 코딩. 코드를 보고 안보고는 개인의 자유. 자연어 사용이 중요한 포인트.
바이브 코딩 때문에 개발자가 사라질까? 개발자는 어떤 일을 하는 사람들이지?
소프트웨어 엔지니어
유사역할?
자연어 = 컴퓨터와 소통할 수 있는 새로운 추상화 레벨
내가 만드는 프로그램은 어느정도 수준의 추상화로 구현이 가능한가? AI Assisted Programming Book - Oreilly 이미지
그렇다고 저수준 언어를 사용하지 않는 것은 아니다.
나중에는 코딩할때 AI를 쓰는게 너무 당연해져서 100% 수제작 코드는 그저…?
개발지식이 없을 때와, 개발지식이 있을 때 지시 능력은 여전히 차이가 있다. (더 구체적이고, 더 적절한 요구사항을 반영)
디버깅과 오류 분석: 오류가 발생했을 때 보다 구체적인 해결방안의 탐색
현 개발자들은 Vibe Coding이 아니라, Vibe Engineering을 해야 한다. 그렇기 때문에 공부할 것들이 더 늘어난다… CSE, Programming Language 특성을 공부했던 것처럼, LLM 동작 원리나 기술 활용법도 추가됨.
LLM이 잘 할수있는 일, 잘 못하는 일의 구분.
경쟁력을 어떻게 확보할 것인가? 엔지니어로써 Trade-off의 판단과 적절한 기술의 선택 능력. Hard, Soft 모두 필요.
개인적으로 프롬프트 엔지니어링은 소프트스킬에 가까운 것 같다.
아는만큼 보인다 == 모르면 안보인다
코드 작성에 대한 사람들의 관점을 바꿀수는 없다. 하지만 생산성은 높여야 하고…
많은 기업에서 신규 채용을 하기보다는 기존 개발자에게 생산성을 요구함. 분명히 증대된 부분도 있지만…(코드 작성 관련) 의사결정/프로세스에 다른 인간이 개입하는 순간: 커뮤니케이션 병목
바이브 코딩이 1인 프로토타이핑 제품에서 가장 생산성 & 성과가 좋은 이유. 인간이 최대한 개입하지 않도록 프로세스 재편이 필요.
사람들은 자신들의 의사소통 능력을 심각하게 과대평가하는 경향이 있다.
Product Manager <-> Product Engineer <-> Full-stack Engineer
결국 개발자 역할이 일을 더 주도적으로 해야하는 형태로 변화.
FE, QA를 기다리지 않고 개발, 검증, 배포.
아무리 훌륭한 개발자도 모든 것을 알수는 없다. 개발 생태계는 이미 복잡. 어떤 industry 였는지 배경. 각기 다른 전문 분야에 대해 T자형 역량을 가진 Product Engineering 팀이 필요. 일정수준 이상의 능력과 지식이 필요.
시니어라고 다 아는게 아니다. 주니어 시니어 나눌 필요X. 전문성 향상, 책임감있는 마인드를 통해 시너지를 발생시키는 것이 중요하다고 생각.
불완전성에 대한 인정. 능력치를 가진 인간과 AI가 협력. 능력들의 곱셈.