SF AI 메이커 문화, 조직 안의 1인 빌더, 그리고 랄프 루프
세 개의 30분 블록과 Q&A 클리닉
5m · Opening: AX는 SI가 아니다
30m · 가까이서 본 SF AI 메이커 문화 및 기업 동향
30m · AX가 실패하는 구조적인 이유와 조직에서 1인 빌더 따라하기
25m · 코딩 에이전트가 랄프와 루프로 수렴한다
30m · Q&A / Socar 케이스 클리닉
도구 사용량, 좌석 수, 데모 개수는 중간 신호일 뿐입니다.
SF는 도시가 아니라 반복 충돌 시스템이다.
AX 실패의 병목은 코딩이 아니라 도메인 번역과 운영이다.
코딩 에이전트는 goal, evidence, loop로 수렴한다.
복제 대상은 장소가 아니라 루프입니다.
같은 사람이 같은 주제를 반복해서 부딪히는 밀도
House of AI, Founders Inc., coworking, hacker house, residency
demos, private dinners, enterprise AI events, small builder meetups
superconnectors, operators, investors, community hosts
YC, HF0, AI Grant, fellowships, residency cohorts
AI coworking + enterprise event + member routing
표면은 공간이지만 실제 가치는 선별과 체류 시간입니다.
기업 행사는 단순 대관이 아니라 신뢰와 인재 접점을 만듭니다.
Socar가 배울 것은 인테리어가 아니라 반복 제작 리듬입니다.
아이디어 회의보다 작동하는 조각이 대화의 출발점이 됩니다.
기획서, 보고, 승인, PoC
demo, repo, user feedback, iteration
로컬, 오픈웨이트, 라우팅은 운영 리스크 대응입니다.
데이터 경계가 업무 가능성을 결정합니다.
특정 API, 정책, 비용, 장애에도 핵심 업무가 멈추면 안 됩니다.
쉬운 반복 업무는 품질 기준을 넘는 가장 싼 성공 모델로 처리합니다.
범용 지능보다 업무별 품질 바와 라우팅이 중요합니다.
툴 호출, 권한, 상태, 로그가 왜 중요한지 직접 압니다.
질문을 던지는 대신 완료 조건과 증거를 던집니다.
자기 업무를 작은 소프트웨어 조각으로 재구성하기 시작합니다.
한 명의 천재보다 반복 충돌하는 다수의 실험자가 중요합니다.
같은 문제를 푸는 사람이 계속 만납니다.
실패한 실험이 빠르게 공유되고 폐기됩니다.
좋은 데모와 나쁜 데모를 많이 보며 눈높이가 올라갑니다.
사람, 자본, 고객, 도구가 빠르게 연결됩니다.
빌더 루프를 사내 업무 환경에 맞게 이식해야 합니다.
도시 분위기, 이벤트 수, 유명인 네트워크
문제 선택, 빠른 제작, 실제 업무 검증, 기록과 재사용
작고 실제적인 업무에서 시작합니다.
업무 고통을 찾는다
담당자가 직접 만든다
실제 데이터로 검증한다
성공 루프를 문서화한다
SF는 AI를 더 많이 쓰는 곳이 아니라 더 자주 만드는 곳입니다.
기업 AI 트렌드는 모델 성능 경쟁에서 운영 라우팅 경쟁으로 이동합니다.
Socar의 첫 과제는 내부 빌더 밀도를 만드는 것입니다.
AI가 코드를 잘 써도 SI의 병목은 원래 코딩이 아니었습니다.
사용량은 늘 수 있지만 업무 구조는 그대로 남습니다.
좌석, 교육, 데모, 사용량
문제 정의, 권한, 검증, 운영, 재사용
현업은 처음부터 정확한 명세를 갖고 있지 않습니다.
무엇이 중요한 업무인지 내부 사람이 압니다.
실제 업무에는 계정, 승인, 데이터 접근, 책임 소재가 붙습니다.
로그, 롤백, 예외 처리, 지속 개선이 없으면 자동화는 빚이 됩니다.
요구사항은 외주화되고 도메인 지식은 회의록에 갇힙니다.
AI는 빠른 코더가 되지만 문제를 고르는 사람은 그대로 느립니다.
성과는 PoC 단계에서 멈추고 운영 루프로 넘어가지 못합니다.
n8n식 고정 플로우는 예외와 맥락 앞에서 쉽게 깨집니다.
운영에는 승인, 로그, 회수, 모니터링, 품질 기준이 필요합니다.
에이전트 루프는 다음 행동을 고르지만, 그 자유도만큼 검증 구조가 필요합니다.
좌석당 비용이 아니라 태스크당 성공 비용을 봐야 합니다.
사용량이 아니라 성공한 태스크 수와 태스크당 가치를 봐야 합니다.
쉬운 일은 싸게 많이, 어려운 일은 비싸도 확실히 해결하는 라우팅이 필요합니다.
Value = successful tasks x value per task
attempted tasks x cost per attempt
successful tasks x value per task
acceptance criteria met / attempts
reusable context captured / successful task
Clarify: 흐린 업무 고통을 명세로 바꾼다
Prototype: 완성품 전에 작동하는 초안을 만든다
Test: 업무 지표와 실제 샘플로 검증한다
Package: 성공한 루프를 스킬, 템플릿, 문서로 남긴다
리더는 문제, 권한, 보상, 안전장치를 설계해야 합니다.
'다들 AI 좀 써보세요'
'이 지표를 움직일 업무 루프를 직접 만들어봅시다'
한 구성원이 자기 업무에서 실제 성과를 보는 순간
반복 업무, 파일 정리, 보고, 수작업 대조
담당자가 직접 에이전트와 초안을 만든다
시간 절감, 오류 감소, 재사용 가능성
동료가 같은 구조를 복제한다
흐린 요청: 내 다운로드 폴더를 보고 내가 뭘 하는지 분석해줘.
Clarify 후: 기간, 제외 정보, 파일 유형, 출력 형식, 검증 기준을 잠급니다.
Goal 후: 반복 업무 후보 5개와 자동화 가능성, 근거 파일 수, 개인정보 제외 로그를 남깁니다.
대규모 전환보다 작은 성공 루프를 먼저 만듭니다.
업무 고통 10개 수집, 지표가 있는 것만 남김
Clarify 인터뷰로 명세화
프로토타입 제작
실제 업무 샘플로 검증
evidence review와 재사용 패키징
AX는 외주 프로젝트가 아니라 내부 업무 루프의 재설계입니다.
현업이 빌더가 되지 않으면 AI는 더 빠른 SI가 됩니다.
조직은 1인 빌더가 안전하게 실험할 권한과 검증 구조를 줘야 합니다.
프롬프트보다 완료 조건과 증거 루프가 중요해집니다.
Goal contract: 끝났다고 말할 수 있는 상태
Harness workflow: interview, plan, execute, verify
Loop engineering: 점수화, 중단 조건, 재시도 정책
실행하고, 점수화하고, 확인하고, 계속할지 멈출지 결정합니다.
완료 조건, 증거, 제약, 블로커 보고가 함께 있어야 합니다.
어떤 상태가 끝인가
무엇을 보면 완료를 믿을 수 있는가
무엇을 깨면 안 되는가
막히면 무엇을 보고해야 하는가
memory, planning, execution, verified completion을 Codex 안에 설치
deep-interview -> ralplan -> ultragoal의 작은 외부 하네스
deep-interview: 모호성을 수학적으로 낮춘다
ralplan: Planner, Architect, Critic 합의로 계획을 다듬는다
ultragoal: 승인된 목표를 증거와 함께 끝까지 실행한다
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로 남고 실행은 별도 승인입니다.
현업의 흐린 업무 고통을 실행 가능한 spec으로 바꾸는 과정이기 때문입니다.
'보고서가 매번 너무 오래 걸려요'
입력, 예외, 승인자, 출력, 증거, 성공 기준
Interview: 도메인 담당자의 모호성을 낮춘다
Plan: 제약과 성공 기준을 계획으로 만든다
Execute: 작은 샘플에서 실행한다
Verify: 증거와 로그로 종료한다
프롬프트를 길게 쓰면 다 된다고 믿는 것
계획 없이 바로 실행시키는 것
검증 없는 자동 루프를 무한히 돌리는 것
코딩 에이전트의 핵심은 코드 생성 능력이 아니라 목표 계약과 검증 루프입니다.
랄프와 루프는 개발자의 도구가 아니라 조직 실행 단위입니다.
AX는 이 루프를 현업 업무에 이식할 때 성과가 납니다.
실제 업무 하나를 Clarify -> Goal -> Evidence로 바꿉니다.
업무 고통을 한 문장으로 받습니다.
성공 기준과 예외를 질문합니다.
Goal contract로 다시 씁니다.
evidence와 다음 실험을 정합니다.
내 업무에서 반복되지만 결과 기준이 분명한 일은 무엇인가?
그 일이 성공했다고 말하려면 어떤 증거가 필요한가?
내가 직접 만들 수 있는 가장 작은 프로토타입은 무엇인가?
Socar의 기회는 AI 도구를 많이 쓰는 회사가 아니라 각 팀에 1인 빌더가 생기는 회사가 되는 것입니다.