안녕하세요! 그로스로그 입니다!😊 🌱
만드는 속도가 빨라지면 잘못된 방향으로도 빨리 갑니다. 세 분이 각자 다른 자리에서 같은 질문에 닿았습니다.
5기 2회차 두 번째 묶음입니다. 앞의 세 편이 "조용히 틀리는 것"을 다뤘다면, 이번 세 편은 "무엇을 향해 달릴 것인가"를 다룹니다.
01
🪑 [Growth Log] Vibe Coding의 시대가 끝나고 남는 것에 대하여
박예승 님
Michal Malewicz의 「Vibe Coding is OVER. Here's What Comes Next.」를 읽고 쓴 감상입니다. AI 도구가 퍼지면서 모든 제품과 웹사이트가 평균값으로 수렴하는 현상을 다뤄요.
저자가 짚은 핵심은 문제의 원인이 AI가 아니라는 것입니다. 기초 없이 빠른 길로 가려는 태도는 AI 이전에도 늘 있었고, AI는 그 집단을 넓혔을 뿐이라고요.
원저자가 제시한 다섯 가지 해법을 하나씩 옮기면서 자기 고민에 겹쳐 읽습니다. 마지막은
craft와 convenience의 대립 구도로 맺습니다.읽은 글을 요약한 게 아니라 자기 질문에 대입해 읽은 기록입니다.
조금 더 들어가 보면
원저자의 비유를 그대로 옮긴 대목이 인상적입니다. 지금 쏟아지는 결과물을 이케아의 LACK 테이블에 빗댔다고요. "기능은 하지만 영혼이 없고, 톱밥을 플라스틱으로 감싼 것처럼 겉만 그럴듯한 결과물"이라는 겁니다.
그리고 SaaS 랜딩페이지의 전형을 나열합니다 — 그라데이션 히어로 텍스트로 "Revolutionize Your Workflow", 루시드 아이콘이 들어간 세 개의 기능 카드, 스톡 이미지 후기 섹션, 중간 플랜이 "Most Popular"로 강조된 가격표. 글쓴이가 여기에 자기 관찰을 붙입니다. "생각해보면 나 역시 최근 보는 랜딩페이지들이 점점 구분되지 않는다는 인상을 받고 있었다."
📐 원인을 AI에 두지 않은 것
이 글이 흔한 AI 비관론과 갈라지는 지점입니다.
그리고 시대별로 같은 패턴이 있었다고 짚습니다. 2000년대 초반의 조악한 웹사이트, 2010년대의 플랫 디자인과 오토 레이아웃이 만든 "그럴듯해 보이는" 평균적 결과물, 그리고 2020년대의 AI 슬롭. 도구는 달라졌는데 태도는 한결같았다는 관찰이에요.
여기서 나온 문장 하나가 이 글의 중심에 있습니다.
⚡ 모두가 배리 앨런인 시대
글쓴이가 가장 좋아한다고 꼽은 문장도 옮겨 적었습니다.
플래시는 벽을 뚫을 수 있지만 어느 벽을 뚫어야 하는지는 알아야 한다는 겁니다. 어떤 벽 너머엔 용암이 있고 어떤 벽은 너무 두껍다고요.
그리고 자기 이야기로 넘어갑니다. 이 부분이 정직합니다.
속도를 성장으로 착각했다는 자기 진단입니다. 그 뒤에 이유를 붙여요 — "빠르게 많이 만드는 것이 목표가 되는 순간, 내가 가진 생각이나 맥락(context)은 결과물에 녹아들 틈이 없어진다."
📝 원문에서는 이렇게 정리합니다
다섯 가지 해법을 옮기면서 각각에 자기 반응을 답니다.
1. 무엇을 하는지 알고 시작할 것 — 문제 정의와 경쟁 분석, 예상되는 어려움까지 종이에 먼저 쓰고 나서 도구로 옮겨가라는 것. 이게 없으면 모든 요청이 "아이디어 슬롭 위에 디자인 슬롭과 코드 슬롭을 얹은 삼단 케이크"가 됩니다
2. 보는 눈을 기를 것 — 좋은 제품을 많이 보고 왜 좋은지를 집요하게 분석하기
3. 기본기는 거짓말을 하지 않는다 — 타이포그래피, 간격, 위계, 색채 이론처럼 지루한 것들. "비슷해 보이는 두 디자인이 왜 결과적으로 다르게 느껴지는지를 설명할 수 있어야 한다"
4. 속도를 늦출 것 — AI로 아낀 시간을 더 많이 만드는 데 쓰지 말고 더 잘 만드는 데 쓰라는 조언
5. 결정의 주인이 될 것 — 비판적 사고를 AI에 외주 주지 말 것. "실행은 맡길 수 있어도 계획은 내가 세워야 한다"
네 번째에 붙인 반응이 특히 눈에 남습니다.
경제적 논거도 함께 옮깁니다. 지금은 싸고 빠르게 찍어내는 게 이익이지만, 시장이 포화되고 소비자가 슬롭을 알아보기 시작하면 품질에 신경 쓴 쪽으로 옮겨간다는 것. "'빠르고 싸게, 일단 작동만 하면 된다'라는 전략의 유효 기간은 점점 줄어들고 있다"는 문장을 인상적이라고 적었습니다.
큐레이터 노트
읽은 글을 자기 질문 위에 포개어 읽은 기록이라 뽑았습니다.
아티클 리뷰는 대개 요약과 동의로 끝납니다. 이 글은 도입부에서 자기가 왜 이 글을 집었는지를 먼저 밝혀요.
그리고 자기 답을 먼저 냈다고 적습니다 — 결과물이 아니라 과정과 생각이라고요. 그 뒤에 원저자의 craft 개념과 만납니다. 순서가 이렇게 되어 있으니 "좋은 글이었다"가 아니라 "내 답과 겹쳤다"는 기록이 됩니다.
불편했던 지점을 감추지 않은 것도 좋았습니다. 원저자가 AI 결과물의 여섯 손가락을 비꼬는 대목에서 "이 비유가 불편하게 느껴졌지만, 그만큼 정확하다고 느꼈다"고 적었어요. 동의와 불편을 같이 적어두면 나중에 다시 읽었을 때 그때의 온도가 남습니다.
마지막 결심도 구체적입니다. "AI를 써서 더 많이 만드는 것이 아니라, AI를 활용하여 어떻게 생각하고 어떻게 구조를 만드는가를 기록하는 일" — 이건 성장일지를 쓰는 이유에 대한 답이기도 합니다.
02
🧗 AI 시대에 개발자는 사라지는가
송영록 님
"개발자가 사라진다"와 "아무것도 변하지 않는다" 두 극단이 모두 절반만 맞다는 데서 출발합니다. 실제 변화는 그 사이 어딘가에 있다고요.
핵심 구분은 코드를 짜는 능력과 소프트웨어를 만드는 능력은 다르다는 것. AI가 먼저 잠식하는 영역을 특징으로 정리하고, 개발자의 역할이 어디로 이동하는지를 여섯 가지로 나눕니다.
그중 여섯 번째가 이 글의 주장입니다 — 커뮤니케이션은 소프트 스킬이 아니라 AI 시대의 하드한 생산성 스킬이라는 것.
35분 분량의 긴 글인데 논지가 한 줄로 압축됩니다. 구현 비용은 내려가고, 정렬 비용의 가격은 올라간다.
조금 더 들어가 보면
글이 먼저 하는 일은 엉켜 있는 두 단어를 떼어놓는 것입니다.
그리고 이 구분이 왜 지금 더 중요한지를 답니다 — 구현이 쉬워질수록 구현 이전의 사고 과정이 더 본질적인 경쟁력이 되기 때문입니다.
🍽️ AI가 먼저 먹는 일에는 공통점이 있다
AI가 잘하는 일을 나열하는 대신 특징으로 묶은 것이 정확합니다.
이 기준으로 보면 CRUD API 반복 구현, UI 컴포넌트 초안, 테스트 스캐폴딩, 문서화 초안, 리팩토링 후보 제안, 에러 메시지를 단서로 한 1차 수정이 여기 들어갑니다. 목록을 외우는 게 아니라 기준을 갖게 되는 정리예요. 새로운 업무가 와도 네 조건에 대보면 됩니다.
⏩ 빨라져서 생긴 새 병목
이 글에서 가장 값어치 있는 관찰이 여기 있습니다.
예시가 구체적입니다. 팀이 "사용자 경험을 개선하자"라는 모호한 말을 하고 바로 AI를 붙이면 초안은 매우 빨리 나옵니다. 그런데 그 초안은 각자 다르게 상상한 "개선"을 반영해요. 누구는 응답 속도를, 누구는 UI를, 누구는 알림 정책을, 누구는 이탈률을 떠올립니다.
그리고 결정적인 한 줄.
느림이 안전장치 역할을 하고 있었다는 겁니다. 그게 사라졌으니 다른 장치가 필요해졌고요. 그래서 글은 생산성 문제를 이렇게 다시 씁니다 — "얼마나 빨리 만들 수 있는가"가 아니라 "얼마나 빨리 같은 그림을 보게 만들 수 있는가".
🎯 여섯 가지 역할
개발자의 가치가 이동하는 자리를 여섯으로 나눕니다.
1. 문제를 정의하는 사람 — "전에는 잘못된 아이디어를 구현하는 데 시간이 오래 걸려서 중간에 멈출 기회라도 있었지만, 지금은 잘못된 방향으로도 너무 빨리 갈 수 있다." 그래서 개발자는 무엇을 만들지 결정하는 필터가 되어야 합니다
2. 제약을 설계하는 사람 — 타입·테스트·스키마·권한 모델·트랜잭션 경계·API 계약이 전부 제약입니다. "AI는 이런 제약이 주어졌을 때 더 잘 동작한다. 반대로 제약이 느슨하면 그럴듯하지만 위험한 코드를 빠르게 양산한다"
3. 문맥을 연결하는 사람 — 무엇이 핵심 제약이고 무엇이 우연한 구현인지, 어떤 부채를 지금 갚고 어떤 건 미룰지 판단하는 일
4. 검증하고 책임지는 사람 — *"코드를 작성하는 사람"보다 코드를 믿어도 되는 상태로 만드는 사람
5. 운영과 현실을 이해하는 사람 — "AI는 로컬 성공을 잘 만든다. 하지만 서비스는 로컬 성공만으로 굴러가지 않는다"
6. 팀을 정렬시키는 사람
두 번째에 붙은 한 줄이 특히 실용적입니다. "테스트와 문서는 더 이상 후행 작업이 아니다. 그것들은 AI 이후 시대의 생산성 장치이자 안전장치다." 미루던 것의 성격이 바뀌었다는 이야기예요.
🗣️ 커뮤니케이션을 정렬 능력으로 다시 정의한 것
여섯 번째가 이 글의 주장입니다. 그리고 용어부터 다시 잡습니다.
그리고 그 능력을 다섯 항목으로 쪼갭니다 — 서로 다른 이해관계자가 같은 문제를 보게 만드는 능력, 모호한 요구사항을 충돌 없는 문장으로 바꾸는 능력, 설계 선택의 이유를 납득 가능하게 설명하는 능력, 지금 필요한 합의와 나중에 미뤄도 되는 합의를 구분하는 능력, 기술 언어와 비즈니스 언어를 오가며 번역하는 능력.
왜 지금 더 중요하냐에 대한 답이 간결합니다. "구현은 빨라졌지만, 사람들의 머릿속을 맞추는 일은 여전히 느리기 때문이다."
그래서 결론이 이렇게 됩니다. "AI는 커뮤니케이션을 덜 중요하게 만들지 않는다. 오히려 커뮤니케이션이 약한 팀과 강한 팀의 격차를 더 크게 벌린다."
📝 원문에서는 이렇게 씁니다
백엔드 이야기로 좁힌 대목에 구체적인 문장 예시가 나옵니다. 백엔드의 문제는 눈에 잘 보이지 않는다는 관찰에서 출발해요. 트랜잭션, 정합성, 동시성, 재시도, 메시지 전달 보장, 캐시 일관성, 배치 타이밍 같은 제약은 설명되지 않으면 전달되지 않고, 설명되지 않은 제약은 잘못된 기대를 만들고, 잘못된 기대는 장애나 일정 지연으로 돌아온다는 겁니다.
그래서 "보이지 않는 위험을 보이게 말할 수 있는 기술자"여야 한다고 하면서 실제 문장 네 개를 답니다.
"이건 기능은 간단해 보여도 멱등성을 보장하지 않으면 중복 처리 위험이 있습니다." "여기서는 즉시 일관성보다 최종 일관성을 택하는 편이 운영 비용이 낮습니다." "이번 스프린트에서는 구조를 완성하기보다 장애 가능성이 큰 지점부터 관측 가능하게 만들겠습니다." "이 변경은 API 스펙보다 데이터 계약 변화가 핵심이므로, 관련 소비자까지 같이 봐야 합니다."
그리고 이게 왜 단순한 설명이 아닌지를 붙입니다 — "팀의 기대를 조정하고, 잘못된 오해를 줄이고, 실패 비용을 미리 낮추는 행위다."
약해지는 개발자와 강해지는 개발자를 여섯 항목씩 대비시킨 목록도 실용적입니다. 그중 다섯 번째 쌍이 이 회차와 곧장 이어져요 — 약해지는 쪽은 "AI가 준 결과를 빠르게 수용하지만 느리게 검증"하고, 강해지는 쪽은 "AI를 '대신 생각해주는 존재'가 아니라 '빠르게 시도하게 해주는 존재'로 쓴다"고요.
큐레이터 노트
커뮤니케이션을 기술력 바깥이 아니라 안쪽에 놓은 글이라 뽑았습니다.
"AI 시대에 개발자는" 류의 글은 아주 많고 대개 비슷한 결론에 닿습니다. 이 글이 다른 건 주장을 검증 가능한 형태로 쪼갠 것이에요. AI가 잘하는 일을 네 가지 조건으로 정의하고, 역할 이동을 여섯으로 나누고, 커뮤니케이션을 다섯 항목으로 분해하고, 약해지는/강해지는 특징을 각각 여섯씩 대비시킵니다. 읽고 나서 자기를 대볼 수 있는 목록이 남습니다.
"소프트 스킬"이라는 말을 정면으로 반박한 것이 이 글의 태도를 보여줍니다.
마지막 문단이 특히 좋았습니다. 다섯 개의 질문을 던지고 — 당신은 정말 문제를 이해하고 있는가, 왜 그 구조를 선택했는가, 이 코드를 신뢰할 근거를 가지고 있는가, 시스템이 실패할 때 무엇이 무너질지 알고 있는가, 그리고 그 모든 것을 타인이 이해할 수 있는 언어로 설명할 수 있는가 — 이렇게 맺습니다.
AI가 새 문제를 만든 게 아니라 원래 있던 문제를 가려주던 시간을 없앴다는 진단입니다.
03
🎛️ GPU 멀티테넌트 추론 서빙의 공동 최적화 — DRS 논문 연구 분석
전병탁 님
IEEE TPDS 2026년 1월 논문을 분석한 글입니다. 하나의 GPU를 여러 AI 모델이 나눠 쓸 때 필요한 자원 할당과 요청 배치, 이 두 결정이 사실은 하나의 결합된 문제라는 걸 밝힌 연구예요.
논문이 제안한 DRS(Deep Reinforcement Scheduler)의 구조를 7단계 워크플로우로 풀고, MDP 정식화(State·Action·Reward)까지 정리합니다.
후반부가 이 글의 값어치입니다. 그대로 가져올 수 없는 이유를 짚고 제조 현장용으로 Reward를 다시 설계합니다.
논문 리뷰인데 "우리 현장에 옮기려면 무엇을 바꿔야 하는가"까지 갑니다.
조금 더 들어가 보면
논문의 주장은 단순합니다. 두 문제를 따로 풀면 안 된다는 것. 그런데 그걸 주장으로 두지 않고 실험 표 하나로 증명합니다.
| GPU 파티션 | BERT | ResNet50 | MobileNetV2 | DeepSpeech |
|---|---|---|---|---|
| 20% | 32 | 8 | 128 | 128 |
| 60% | 128 | 16 | 512 | 512 |
| 100% | 256 | 32 | 2048 | 1024 |
모델별 최적 배치 크기입니다. 여기서 세 가지가 드러나요.
· 스케일 이질성 — ResNet50의 최적 배치는 8~32인데 MobileNet은 128~2048입니다. 60배 차이. 단일 휴리스틱으로 전부 커버할 수 없습니다
· 곡선 형태가 제각각 — BERT는 포화형, DeepSpeech는 계단형, MobileNet은 지수적 증가. 선형 규칙이 성립하는 모델이 하나도 없어 데이터 기반 학습이 필요합니다
· 파티션 ↔ 배치 커플링 — 파티션이 바뀌면 같은 모델도 최적 배치가 즉시 바뀝니다. 두 결정을 함께 풀어야 한다는 실험적 근거
세 번째가 논문의 출발점이에요. 표 하나가 "따로 풀면 안 된다"를 대신 말합니다.
🔄 두 컨트롤러가 맞물리는 구조
DRS는 성격이 다른 두 부품을 씁니다.
· Memory Recap — 파티션 구간별 최적 배치 크기를 기록해두는 경량 캐시. 학습이 필요 없습니다. 새 구간에 들어가면 배치 2부터 시작해 지연이 개선되면 2배씩 늘리고, 악화되면 이전 최적값으로 즉시 복귀
· DDPG Controller — GPU 파티션 비율을 정하는 강화학습 에이전트
왜 DDPG냐에 대한 답이 명확합니다. GPU 파티션 비율은 1%~100%의 연속값이라 DQN 같은 이산 행동 알고리즘이 안 맞는다는 것. 문제의 성질에서 알고리즘이 따라 나온 순서예요.
그리고 이 둘이 맞물리는 방식이 Joint Optimization의 본질입니다.
파티션 변경 → 배치 재선택 → 새 처리량 → 상태 관측 → 다음 파티션
DDPG가 파티션을 바꾸면 Memory Recap이 맞는 배치를 적용하고, 그 결과가 다시 DDPG의 입력이 됩니다. 한 번의 추론 결과가 소프트웨어(배치 테이블)와 하드웨어(SM 분배)로 동시에 갈라져 2초 주기로 돕니다.
🎁 Reward 설계 — 이 글에서 가장 중요한 대목
MDP 정식화에서 Reward가 이렇게 잡혀 있습니다.
r = Σᵢ (hᵢ / eᵢ) hᵢ : 공유 환경에서의 실제 처리량 eᵢ : 단독 GPU 사용 시 최대 처리량
글이 붙인 설계 의도가 핵심입니다.
단순 처리량 합으로 뒀으면 시스템이 가벼운 모델만 밀어줬을 겁니다. 초당 처리 건수를 최대로 만드는 가장 쉬운 길이 그거니까요. 그러면 무거운 모델은 굶습니다. 나눗셈 하나를 넣어서 그 함정을 피한 거예요.
실험 결과가 그 설계의 효과를 보여줍니다.
| 모델 | 기본 | Heuristic | DRS |
|---|---|---|---|
| ResNet50 | 8.31초 | 1.92초 | 0.34초 |
| BERT | 6.78초 | 1.55초 | 0.42초 |
| Qwen2.5-3B (LLM) | 12.4초 | 4.15초 | 0.52초 |
가장 무거운 LLM에서 개선 폭이 제일 큽니다(최대 24배). 글이 그 이유를 답니다 — "기존 방식은 큐가 길어지는 무거운 모델에 자원을 더 줄 줄 모릅니다. DRS는 큐 길이와 JCT를 실시간 상태로 관찰하기 때문에, 뒤처지는 테넌트에게 자원을 재배분해 전체 균형을 맞춥니다."
📝 원문에서는 이렇게 다시 설계합니다
후반부가 이 글을 논문 요약에서 검토 자료로 바꿉니다. "논문을 그대로 제조에 가져올 수 없는 핵심 이유는 Reward 함수"라고 못 박고 다시 짭니다.
| 논문 원본 | 현장 맞춤형 | |
|---|---|---|
| State | 큐 길이·지연·처리량·JCT | + 불량 감지율 · 라인 UPH · 제품 코드 |
| Reward | Σ(hᵢ/eᵢ) — 처리량 중심 |
α·Thru + β·SLO − γ·Defect_Miss − δ·Lat_Viol |
그리고 이유를 한 줄로 답니다.
논문의 Reward는 처리량이 목적인 세계의 것입니다. 검사 라인은 다릅니다 — 빠르게 많이 검사해도 불량 하나를 놓치면 그 이득이 통째로 지워지죠. 같은 알고리즘, 다른 목적 함수입니다.
도입 방식도 단계로 쪼갰습니다.
Phase A (1~2개월) → Phase B (2~4주) → Phase C [Offline 사전학습] [Shadow Mode] [Safe Exploration] 과거 로그 기반 DDPG 제안만· Noise 제한 + 시뮬레이터에서 수동 승인 Kill Switch
Shadow Mode가 특히 좋습니다. 학습된 에이전트가 제안만 하고 실제 적용은 사람이 승인하는 구간이에요. 그리고 실제 운영에 들어가서도 Kill Switch를 남깁니다.
큐레이터 노트
논문의 결론이 아니라 논문의 전제를 옮긴 글이라 뽑았습니다.
논문 리뷰는 보통 "이런 결과가 나왔다"로 끝납니다. 이 글은 성능 숫자를 소개한 다음 "이 숫자가 나온 목적 함수는 무엇이었나"로 들어가요. 그리고 그 목적 함수가 자기 영역에서는 안 맞는다는 걸 짚고, 어디에 음수 가중치를 걸어야 하는지까지 적습니다.
Reward 설계 의도를 읽어낸 것이 이 글의 핵심 기여입니다. Σ(hᵢ/eᵢ)라는 수식에서 "왜 나눗셈인가"를 묻고, 단순 합이었다면 경량 모델만 유리했을 거라는 데까지 간 것이요. 수식을 읽는 게 아니라 수식이 막으려는 실패를 읽은 것입니다.
도입을 3단계로 쪼개고 Kill Switch를 남긴 것도 좋았습니다. 강화학습을 운영 환경에 넣는 건 위험한 일이에요. 학습된 정책이 이상한 행동을 할 수 있으니까요. Offline 사전학습 → Shadow Mode → Noise 제한 + Kill Switch는 되돌릴 수 있는 상태를 유지하면서 나아가는 설계입니다.
같은 회차의 다른 글과도 이어집니다. 앞의 MQTT 글이 데이터 수집 계층을 다뤘다면 이 글은 그 위에서 도는 추론 계층이에요. "센서 임계값 초과 → MQTT 이벤트 → AI 분석 → 운영자 조치"라던 파이프라인의 뒷단이 여기 있습니다. 두 편을 나란히 읽으면 한 사람이 그리는 그림의 아래층과 위층이 보입니다.
💡 세 편을 겹쳐 읽으며
에세이 한 편, 논고 한 편, 논문 분석 한 편입니다. 형식이 다 다른데 셋 다 같은 자리에서 멈춰 섭니다.
최적화가 강해질수록 목적 함수가 무거워진다
전병탁 님 글에서 이게 가장 노골적으로 드러납니다. DRS는 강력한 최적화기예요. 그런데 Reward를 단순 처리량 합으로 뒀으면 경량 모델만 밀어주는 시스템이 됐을 겁니다. 제조에 옮기면 또 달라져서, 불량 미검출에 가장 큰 음수 가중치를 걸어야 하고요. 알고리즘이 강할수록 목적 함수를 잘못 잡았을 때의 대가가 커집니다.
박예승 님 글의 "방향 없는 속도"가 같은 말입니다. 플래시는 벽을 뚫을 수 있지만 어느 벽인지는 정해줘야 해요.
송영록 님 글은 그 대가를 조직 단위로 셉니다. "잘못된 이해가 곧바로 코드와 화면과 API로 증식한다." 예전에는 구현이 느려서 중간에 멈출 기회가 있었는데 이제는 없다는 겁니다.
셋 다 도구가 나빠졌다고 말하지 않습니다. 도구가 좋아졌기 때문에 방향을 정하는 일의 가격이 올랐다고 말합니다.
느림이 하던 일을 무엇으로 대신할 것인가
이게 세 글이 실제로 답하는 질문입니다.
느림은 안전장치였어요. 구현이 오래 걸리니 그 사이에 "이게 맞나" 물어볼 시간이 있었고, 잘못된 방향이면 중간에 멈출 수 있었습니다. 그 시간이 사라졌으니 다른 장치를 명시적으로 만들어야 합니다.
· 송영록 님은 제약으로 답합니다. 타입·테스트·스키마·계약. "테스트와 문서는 더 이상 후행 작업이 아니다. AI 이후 시대의 생산성 장치이자 안전장치다"
· 전병탁 님은 단계와 스위치로 답합니다. Shadow Mode에서 제안만 받고, 운영에 들어가도 Kill Switch를 남깁니다
· 박예승 님은 먼저 쓰기로 답합니다. 문제 정의와 경쟁 분석을 종이에 쓴 뒤에 도구로 옮겨가라는 것
세 답이 다 "판단할 시간을 구조로 되돌려 놓는 것"입니다.
대신 생각하게 두지 않기
세 번째 공통점은 태도의 위치입니다.
박예승 님이 옮긴 다섯 번째 해법이 "결정의 주인이 될 것"이었습니다. "실행은 맡길 수 있어도 계획은 내가 세워야 한다."
송영록 님이 강해지는 개발자의 다섯 번째로 꼽은 것이 "AI를 '대신 생각해주는 존재'가 아니라 '빠르게 시도하게 해주는 존재'로 쓴다"였고요.
전병탁 님의 Shadow Mode는 그 원칙을 시스템으로 구현한 것입니다. 학습된 에이전트가 제안하고 사람이 승인합니다.
같은 원칙이 에세이에서는 결심으로, 논고에서는 역할 정의로, 논문 분석에서는 배포 단계로 나타났습니다.
이번 회차에서 가져갈 것
1. 목적 함수를 명시적으로 적어보기.
무엇을 최대화하고 무엇에 벌점을 줄 것인지요. 적어보면 대개 "그냥 빨리"였다는 게 드러납니다. α·처리량 + β·SLO − γ·불량미검출처럼 항이 여러 개가 되어야 정상인 경우가 많습니다.
2. 단순 합으로 두면 가벼운 쪽만 이긴다.
처리량을 그냥 더하면 경량 모델이 유리하고, 팀 성과를 건수로 세면 쉬운 일만 남습니다. 각자의 최대치 대비로 나누는 것만으로 균형이 잡히기도 합니다.
3. "성능을 개선해달라"는 요청은 그대로 받지 않기.
응답 시간인지, 처리량인지, DB 부하인지, 체감 속도인지 되묻습니다. AI는 이 모호함을 해결해주지 않고 그 위에 매우 그럴듯한 구현을 올려놓습니다.
4. 테스트와 문서를 후행이 아니라 안전장치로 다시 놓기.
구현이 빨라진 만큼 잘못된 코드도 빨리 들어옵니다. 제약이 느슨하면 그럴듯하지만 위험한 결과물이 양산됩니다.
5. 새 자동화를 넣을 땐 되돌릴 자리를 먼저 만들기.
제안만 받는 구간(Shadow Mode)을 두고, 운영에 들어가서도 Kill Switch를 남깁니다. 되돌릴 수 없는 상태로 먼저 가지 않는 것입니다.
6. 속도가 늘었을 때 그 시간을 어디에 쓸지 미리 정하기.
더 많이 만드는 데 쓰면 평균값에 가까워지고, 더 잘 만드는 데 쓰면 갈라집니다. 이건 저절로 정해지지 않아서 의식적으로 배분해야 합니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
좋은 글 남겨주신 박예승 님, 송영록 님, 전병탁 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.