SF AI 메이커 문화, 조직 안의 1인 빌더, 그리고 랄프 루프
30분씩 세 주제를 다루고, 마지막 30분은 Socar 업무 케이스 클리닉으로 씁니다.
가까이서 본 SF AI 메이커 문화 및 기업 동향
AX가 실패하는 구조적인 이유와 조직에서 1인 빌더 따라하기
코딩 에이전트가 랄프와 루프로 수렴한다
Q&A / Socar 케이스 클리닉
도구 사용량, 좌석 수, 데모 개수는 중간 신호일 뿐입니다.
SF는 token-maxing을 먼저 지나 outcome-maxing으로 넘어갔다.
AX 실패는 조직 안에서도 SI를 반복할 때 생긴다.
코딩 에이전트는 /goal, harness, loop engineering으로 수렴한다.
토큰을 얼마나 쓰느냐가 아니라, 그걸로 어떤 성과가 났느냐를 묻기 시작했습니다.
엔진과 업무 연동이 높을수록 같은 모델 사용이 더 큰 비용 절감처럼 느껴집니다.
SF 쪽은 엔진과 도구 연동 밀도가 더 높아 같은 자동화가 더 자주 업무에 붙습니다.
토큰 단가는 같아도 사람 시간이 줄어드는 체감 폭이 커집니다.
체감 절감이 크면 개인과 조직 모두 더 과감하게 실험합니다.
에이전트를 어떻게 써야 일을 잘하는지에 대한 논의가 빠르게 확산됩니다.
Claude, Codex, Hermes로 자신의 삶과 일을 더 많이 자동화하려는 욕구는 공통입니다.
Claude와 Codex를 더 많이 쓰고, Hermes류 자동화로 삶을 정리합니다.
몇 달 먼저 token-maxing 실험을 하고, 이제 outcome-maxing으로 이동하고 있습니다.
어떻게 하면 직원들이 AI를 더 많이 쓰게 만들까?
어떻게 하면 토큰을 많이 써서 일을 더 많이 하게 만들까?
사용량을 조직 변화의 선행 지표로 볼 수 있을까?
반발은 컸지만, 리더들은 이 숫자가 필요하다고 봤습니다.
직원별 Claude, Codex 토큰 사용량을 합산해 순위를 보여주는 방식이 등장했습니다.
공개 직후 평가와 감시로 받아들여져 반발이 컸습니다.
매니저들은 평가에 쓰지 않겠다고 수습했지만 불신은 남았습니다.
그럼에도 시스템이 유지되는 이유는 사용량을 과도기 관리 지표로 보기 때문입니다.
사용량 쏠림은 곧 생산성 쏠림이 아닙니다.
많이 쓰는 사람이 훨씬 높은 생산성을 내고 있을 수 있다.
1등이 2등과 3등 합만큼 쓰지만, 사실은 잘못된 루프에서 토큰을 낭비할 수 있다.
토큰 사용량은 시작 신호이지 성공 지표가 아닙니다.
잘못된 루프는 생산성이 아니라 비용만 키웁니다.
다음 질문은 '얼마나 썼나'가 아니라 '무엇이 개선됐나'입니다.
성과를 내려면 AI가 풀 병목을 먼저 골라야 합니다.
매출, 비용, 리드타임, 오류율, 고객 경험 중 무엇을 움직일지 정합니다.
AI가 풀어야 할 병목이 코딩인지, 커뮤니케이션인지, 고객 이해인지 분리합니다.
성공 기준을 사용량이 아니라 업무 결과와 증거로 둡니다.
반복 가능한 업무 루프로 남지 않으면 일회성 데모에 그칩니다.
오히려 AI가 가장 먼저 해결한 것은 비교적 해결하기 쉬운 층이었습니다.
코드 초안, 스크립트, 슬라이드, 이메일, 반복 작업 실행
요구사항을 뾰족하게 만들고 고객의 진짜 문제를 이해하는 일
코드가 완벽하지 않아도 고객 문제를 정확히 풀면 성공합니다.
코드를 잘 써도 고객의 문제를 잘못 이해하면 성과가 없습니다.
AX도 결국 내부 고객의 문제를 얼마나 정확히 푸느냐의 문제입니다.
슬라이드, 메일, 분석, 코딩이 모두 에이전트 작업으로 이동합니다.
문서, 폴더, 대화, 로그, 화면 상태가 모델 입력이 됩니다.
AI가 브라우저, 파일, 코드, 검색, 캘린더를 직접 다룹니다.
슬라이드, 코드, 리포트, 답장, 자동화가 한 번의 작업으로 생성됩니다.
못하던 일을 하게 되는 Zero to One 체감이 생깁니다.
무거운 사용자는 Claude Max 기준 월 8,000달러 규모의 사용량을 만들 수 있습니다.
Codex도 강하게 쓰면 월 14,000달러 규모의 사용량이 가능합니다.
개인 한 명이 월 2,000만 원 이상의 토큰을 소비하는 상황은 이미 현실입니다.
엔터프라이즈 API 비용은 이미 사용량 현실을 더 직접적으로 반영합니다.
OpenAI와 Anthropic도 무한히 큰 할인을 지속하기 어렵습니다.
기업은 고성능 모델을 원하지만 비용 구조를 같이 설계해야 합니다.
성능과 비용의 차이가 기업 운영 전략을 바꿉니다.
특정 업무에서는 1/5, 잘 맞으면 1/10 수준의 비용 구조가 가능합니다.
데이터 경계와 반복 업무에서는 충분히 좋은 로컬 모델이 의미를 갖습니다.
가장 어려운 판단과 높은 가치 업무에는 여전히 Claude, Codex, Gemini가 필요합니다.
업무별 품질 바와 비용 바에 따라 모델을 다르게 써야 합니다.
OpenResearch, Sakana AI 같은 흐름은 여러 모델을 조합해 성능을 끌어올립니다.
Mythos, Fable급 품질을 더 낮은 비용으로 만들려는 실험이 늘고 있습니다.
기업은 완제품 구매만이 아니라 이 접근에서 운영 원리를 배워야 합니다.
모델을 고르는 권한과 교체 가능성이 경쟁력이 됩니다.
Claude, Codex, DeepSeek, Gemini, GLM, local model을 바꿔 끼울 수 있어야 합니다.
모델별로 잘 먹히는 프롬프트, 도구, 검증 루틴을 미리 깎아야 합니다.
특정 벤더에 종속되지 않을 때 가격 협상력이 생깁니다.
조직만의 하네스는 우리 업무를 가장 잘 만드는 시스템을 조직 안에서 설계하는 일입니다.
제품을 잘 만드는 것만으로는 부족합니다.
그 제품을 가장 잘 만들 수 있는 내부 코딩 에이전트를 설계해야 합니다.
조직만의 open Claude Hermes가 생산성의 상한을 결정합니다.
AI 과도기에는 생산성 상승과 사고 방지가 동시에 필요합니다.
조직 전체가 AI로 더 많은 일을 끝낼 수 있는 구조를 만듭니다.
AI 결과물일수록 더 꼼꼼히 리뷰하고, 데이터와 권한의 하방을 지킵니다.
GPT나 Claude를 완전히 대체하려는 것이 아닙니다.
바이오, 신체 데이터, 규제 산업에서는 일부 주도권을 내부에 남겨야 합니다.
ICML 리서치 해커톤도 이 문제의식에서 이어진 선택입니다.
SF에서 배울 것은 토큰을 많이 쓰는 문화가 아니라 outcome을 따지는 문화입니다.
기업 AI 트렌드는 frontier 단일 숭배에서 모델 라우팅과 조직 하네스로 이동합니다.
Socar가 복제할 것은 도시 분위기가 아니라 빌더 루프와 검증 리듬입니다.
외부 파트너가 내부 직원을 위한 툴을 만들어주는 구조라면 병목은 그대로 남습니다.
고객 문제를 정확히 풀면 SI도 성공합니다.
고객의 문제를 제대로 이해하고, 요구사항을 끌어내고, 운영까지 책임집니다.
도메인 이해 없이 만드는 일에만 집중하고, 고객은 요청자로 남습니다.
문제를 가진 사람과 만드는 사람이 분리되면 병목이 그대로 남습니다.
현업은 사용자가 되고 요구사항을 던지는 사람이 됩니다.
AI를 잘 쓰는 팀이나 외부 파트너가 대신 만듭니다.
도메인, 예외, 톤, 책임 소재가 회의록 사이에서 사라집니다.
내부 툴은 생기지만 업무 루프는 바뀌지 않습니다.
우리 일은 고정 플로우로 박아두기엔 단순하지 않습니다.
정해진 스텝을 순서대로 실행합니다.
예외, 승인자, 고객 톤, 조직 맥락, 최신 문서가 매번 달라집니다.
그때그때 어떤 업무 스텝이 필요한지 판단합니다.
필요 없는 스텝을 생략하거나 새로운 스텝을 추가합니다.
메모리, 파일, 검색, 도구 호출로 조직 맥락을 붙이기 쉽습니다.
툴이 아니라 맥락을 읽고 갱신하는 구조가 중요합니다.
반복되는 규칙, 팀 선호, 금지사항을 남깁니다.
매번 사람에게 묻지 않고 내부 문서와 로그를 먼저 찾습니다.
메일, 캘린더, 파일, 코드, 브라우저를 직접 다룹니다.
다음 스텝을 고정하지 않고 현재 맥락에 맞춰 선택합니다.
어떤 맥락으로 이 업무를 해야 하는지 도메인 담당자가 압니다.
고객과 어떤 톤으로 소통해야 하는지도 담당자가 압니다.
누구를 의사결정에 포함해야 하는지도 담당자가 압니다.
적절한 툴이 있으면 도메인 사람이 직접 만드는 것이 빠릅니다.
비개발자도 자기 업무를 소프트웨어 조각으로 만들 수 있습니다.
대표나 C레벨이 에이전트를 자유롭게 쓰는 것도 성공적인 AX입니다.
대규모 프로젝트일수록 초반 절반 이상이 문제 정의에 쓰입니다.
고객에게서 요구사항을 끌어내는 능력이 프로젝트를 좌우합니다.
고객은 도메인 지식을 명확히 전달해야 합니다.
개발 시간도 실제로는 요구사항 해석 시간인 경우가 많습니다.
그리고 남은 절반도 단순 개발만은 아닙니다.
미팅을 반복하며 무엇을 만들지 명확히 합니다.
만든 것을 보고 '말한 것은 맞지만 필요한 것은 아니다'를 수정합니다.
요구사항을 뾰족하게 만드는 가장 좋은 방법은 빨리 만들어 보는 것입니다.
결과물을 보면 내 요구사항이 얼마나 뭉툭했는지 바로 알 수 있습니다.
한 시간의 직접 이터레이션이 한 달의 시간과 비용을 아낄 수 있습니다.
코덱스에게 말하고, 보고, 고치고, 다시 실행합니다.
5분 안에 초안 만들기
결과를 보고 요구사항 고치기
실제 샘플로 다시 실행하기
증거와 예외를 기록하기
회사 업무는 관성적으로 하던 방식이 가장 빠르고 정확하게 느껴집니다.
재미와 몰입이 있어 AI 활용이 잘 붙습니다.
오늘의 할 일이 급해서 새 루프를 만들 시간이 사라집니다.
교육보다 중요한 것은 실제 자기 문제에 붙어 있는 시간입니다.
업무를 멈추고 루프를 만드는 시간을 따로 잡습니다.
장난감 예제가 아니라 자기 팀의 실제 문제를 가져옵니다.
결과가 좋아 보이는지보다 실제 업무 샘플에서 통하는지 봅니다.
성공한 것은 스킬, 위키, 템플릿으로 남깁니다.
AI 시대의 워크숍은 지식 전달보다 문제 해결이어야 합니다.
가장 좋은 방식은 실제 문제를 들고 와서 만드는 해커톤입니다.
Ralphthon은 이 몰입 시간을 조직 안에 강제로 만드는 포맷입니다.
참가자가 자기 문제를 들고 들어왔습니다.
강의가 아니라 바로 만들고 검증하는 시간이었습니다.
결과물이 남아 다음 팀의 출발점이 되었습니다.
실제로 조직 안에서 깔끔한 SOT가 복리로 쌓여야 합니다.
사람과 LLM이 함께 읽고 쓸 수 있는 Single Source of Truth가 필요합니다.
깔끔한 문서가 복리로 쌓여야 합니다.
개념은 알려졌지만 조직별 구현법은 아직 뾰족하지 않습니다.
위키는 도구가 아니라 운영 습관과 루프의 결과물입니다.
팀별 위키와 LLM-readable 문서 확인
서로의 아이디어 공유
해커톤으로 직접 구현
좋은 팀끼리 구조화해 프로젝트 런칭
AX는 외주 프로젝트가 아니라 내부 업무 루프의 재설계입니다.
현업이 빌더가 되지 않으면 AI는 더 빠른 SI가 됩니다.
조직은 1인 빌더가 몰입하고 검증할 시간과 안전장치를 줘야 합니다.
여기는 coding-agent-convergence deck의 흐름을 그대로 가져오고 deep-interview를 붙입니다.
/goal 대동단결: Codex와 Claude Code가 목표 세션으로 모입니다.
범용 툴 밖의 하네스: LazyCodex와 Gajae-Code가 workflow를 명시합니다.
Loop Engineering: 자동화 버튼이 아니라 품질을 지키는 루프 설계가 핵심입니다.
코딩 에이전트의 중심 인터페이스가 한 번 답하는 프롬프트에서 증거가 나올 때까지 이어지는 목표로 바뀝니다.
좋은 목표는 더 오래 일하라는 말이 아니라, 끝났다고 말할 조건을 정하는 문장입니다.
완료 조건, 증거, 제약, 막힘 보고가 한 문장 안에 있어야 합니다.
어떤 상태가 끝인가
무엇을 보면 완료를 믿을 수 있는가
무엇을 깨면 안 되는가
막히면 무엇을 보고해야 하는가
목표 등록
작업 실행
증거 확인
완료 또는 blocked 보고
사용자는 긴 대화가 아니라 완료 조건을 원합니다.
조건이 만족될 때까지 멈추지 않는 세션 감각이 생깁니다.
성공하면 어떤 테스트와 산출물로 확인했는지 남깁니다.
목표가 끝나면 루프가 정리되고 다음 목표로 넘어갑니다.
실행 불가능하면 시도, 증거, 필요한 입력을 남기고 멈춥니다.
실행하고, 점수화하고, 확인하고, 계속할지 멈출지 결정합니다.
새로 만들어진 하네스는 goal, plan, evidence를 더 명확하게 보여줍니다.
사용자는 절차를 모두 쓰는 사람이 아니라 목표를 거는 사람이 됩니다.
Codex는 깊게 일하는 worker로 세팅됩니다.
검증 기본값, memory, planning, evidence가 하네스에 설치됩니다.
레포의 맥락과 작업 규율을 시작점에 설치합니다.
바로 구현하지 않고 계획과 비판을 먼저 만듭니다.
목표, 실행, 검증, 보고를 루프로 묶습니다.
완료 주장을 산출물과 테스트 흔적으로 바꿉니다.
추측 전에 인터뷰하고 모호성을 낮춥니다.
구현 전에 계획하고 비판합니다.
승인된 목표를 증거와 함께 끝까지 실행합니다.
병렬성이 도움이 될 때만 tmux worker를 붙입니다.
Shape: 코드를 건드리기 전에 요구사항과 경계를 만듭니다.
Act: 계획을 만들고 승인된 범위 안에서 실행합니다.
Prove: 끝난 작업을 희망이 아니라 증거로 남깁니다.
범용 AI 위에 조직별 작업 규율을 얹는 층이 생깁니다.
chat, code, browser, file, search, agents까지 계속 넓어집니다.
interview, plan, goal, execute, verify 같은 좁은 품질 루틴을 강제합니다.
885 lines, public interview workflow body
greenfield research hook before asking
opted-out answer synthesis hook
researcher, contrarian, simplifier review hook
"AI can build anything. The hard part is knowing what to build."
"what are you assuming?"를 묻는 요구사항 에이전트입니다.
AX에서 중요한 이유: 현업의 시작점은 보통 명세가 아니라 흐린 업무 고통입니다.
한 번에 하나만 묻습니다.
가장 약한 clarity dimension을 겨냥합니다.
코드베이스나 사실은 먼저 조사하고 묻습니다.
매 답변 뒤 ambiguity를 공개합니다.
threshold와 명시 승인 전에는 실행하지 않습니다.
1 - (goal x 0.40 + constraints x 0.30 + criteria x 0.30)
1 - (goal x 0.35 + constraints x 0.25 + criteria x 0.25 + context x 0.15)
모순, 회피, 범위 확장, 내부 불일치가 생기면 점수가 다시 나빠질 수 있습니다.
기본 0.05, 프로젝트/유저 설정으로 override 가능합니다.
상세한 답변 하나가 전체 명확성처럼 보이는 착시를 막습니다.
상위 컴포넌트를 먼저 잠그고, 각 컴포넌트의 약한 차원을 따로 봅니다.
Socar 업무로 치면 정산, 고객응대, 차량운영, 데이터추출을 한 덩어리로 묶지 않는 것입니다.
Researcher: 외부와 내부 사실 근거가 부족한 지점을 찾습니다.
Contrarian: 규모, 제약, 전제의 과장을 찌릅니다.
Simplifier: 더 작은 문제로 줄일 수 있는지 봅니다.
모든 active component와 unresolved trigger를 확인합니다.
에이전트가 임의로 답한 부분을 다시 봅니다.
최종 목표를 한 문장으로 재진술해 확인합니다.
spec은 pending approval로 남고 실행은 별도 승인입니다.
/goal과 하네스가 가능해지면 다음 질문은 어떤 루프를 만들 것인가가 됩니다.
레버리지 지점이 프롬프트 문장에서 루프 구조로 옮겨졌을 뿐입니다.
자동 루프에 의존하면 품질이 하향 나선에 빠질 수 있습니다.
사람은 검증 지점과 중단 조건을 설계해야 합니다.
도구 이름은 달라도 작업 단위는 goal + evidence + loop로 수렴합니다.
끝났다고 말할 수 있는 상태, 증거, 제약을 씁니다.
interview, plan, goal, execute, verify를 명시합니다.
자동 루프가 품질을 망치지 않도록 리뷰와 QA를 설계합니다.
/goal은 개발 명령이 아니라 운영 단위가 됩니다.
현업의 흐린 업무 고통을 실행 가능한 spec으로 바꾸는 과정이기 때문입니다.
'보고서가 매번 너무 오래 걸려요'
입력, 예외, 승인자, 출력, 증거, 성공 기준
Interview: 도메인 담당자의 모호성을 낮춘다
Plan: 제약과 성공 기준을 계획으로 만든다
Execute: 작은 샘플에서 실행한다
Verify: 증거와 로그로 종료한다
코딩 에이전트의 핵심은 코드 생성 능력이 아니라 목표 계약과 검증 루프입니다.
랄프와 루프는 개발자의 도구가 아니라 조직 실행 단위입니다.
AX는 이 루프를 현업 업무에 이식할 때 성과가 납니다.
실제 업무 하나를 업무 고통 -> 질문 -> goal contract -> evidence로 바꿉니다.
참석자의 실제 업무 고통 한 문장을 받습니다.
성공 기준, 입력, 예외, 승인자, 출력물을 묻습니다.
그 자리에서 goal contract 초안으로 다시 씁니다.
다음 5일 안에 확인할 증거와 샘플을 정합니다.
업무 고통
질문
Goal contract
Evidence
매주 반복되지만 손이 많이 가는 업무를 한 문장으로 적습니다.
끝났다고 말할 상태를 동사와 산출물로 씁니다.
파일 수, 샘플 수, 시간 절감, 오류 감소처럼 확인 가능한 증거를 씁니다.
하지 않을 일, 건드리지 않을 데이터, 승인자를 같이 씁니다.
내 업무에서 반복되지만 결과 기준이 분명한 일은 무엇인가?
그 일이 성공했다고 말하려면 어떤 증거가 필요한가?
내가 직접 만들 수 있는 가장 작은 프로토타입은 무엇인가?
후보 업무 2-3개를 빠르게 받습니다.
하나를 골라 deep-interview식 질문을 합니다.
goal contract와 evidence를 화면에서 같이 씁니다.
각자 자기 업무에 적용할 한 줄 템플릿을 적습니다.
Socar의 기회는 AI 도구를 많이 쓰는 회사가 아니라 각 팀에 1인 빌더가 생기는 회사가 되는 것입니다.