omo, omc 등의 하네스를 활용해 비약적인 생산성 증대를 이뤄내는 개발자들을 보며 비개발자 입장에서 하는 생각
요즘 혼자서 재밌는 프로덕트 열심히 깎고 계시는 Kevin Sohn님과 점심을 먹으면서 한 얘기들을 recap하는 차원에서 정리. 이 아저씨의 주장은:
"패럴리걸 수준의 지적 노가다는 기술적으로 대체 가능하다. 근데 진짜 문제는 검증을 스케일 가능하게 만드는 것이다."
법률이나 회계처럼 정답이 있는 영역은 AI가 잘함. 근데 마케팅이나 기획처럼 "그럴싸함의 범주가 넓은" 영역은 아직 어렵다는 거였음.
일부는 동의하고 일부는 아닌데, 퍼포먼스 마케팅 카피 A/B 테스트, SEO 콘텐츠 생성, 광고 소재 반복 생산 같은 영역은 AI가 이미 사람보다 낫거나 동등한 수준으로 쓰이고 있음. "그럴싸함의 범주가 넓다"는 게 약점이 아니라 오히려 대량 생산 후 검증이라는 새로운 워크플로우로 전환되고 있는 중이라는 생각을 했음.
비개발자 입장에서 주변 개발자들이 요즘 유행하는 오마이 머시기들이나 헤르메스 등의 최신의 하네스들 기반으로 하루 만에 앱을 띄우고, 2주면 프로덕트를 쉬핑하는 걸 보고 있다보면, 10x 생산성이라는 말이 과장이 아닌 것처럼 보이는 순간들이 있음. 그 정점이 지지난주 정도에 open claude를 보면서 고점을 찍었던 것 같고.. 근데 내 업무에서는 그런 레버리지를 못 느끼고 있었음. AI를 나름 꽤나 열심히 쓰는 편인데도
이 글은 답을 제시하는 글은 아니고... 답을 아직 모르기 때문에, 질문을 정확하게 세워보려는 시도 정도..로 써보는 글
개발자가 AI로 10배 빨라졌다는 건, 단순히 코딩을 알아서가 아님.
코딩에는 closed loop이라는 게 있음. 코드를 짜면 컴파일러가 틀렸는지 맞았는지를 즉시 알려줌. 테스트를 돌리면 통과/실패가 나옴. 이 루프가 자동이고, 빠르고, 명확함.
AI가 코드를 생성하고, 컴파일러가 검증하고, 에러가 나면 AI가 다시 고치고, 다시 검증. 이 사이클이 한 세션 안에서 수십 번 반복됨. 핵심은 "검증이 자동화되어 있다"는 것.
내 업무를 돌아보면 이런 식임. 마케팅 전략을 짜고, 제품 기획서를 쓰고, 유저 리서치를 분석하고, 의사결정을 내림. 이 중에 컴파일러처럼 "틀렸다/맞았다"를 즉시 알려주는 것이 하나도 없음.
기획서를 AI한테 쓰게 하면 그럴싸한 게 나옴. 근데 그게 좋은 기획서인지 나쁜 기획서인지를 자동으로 판별할 방법이 없음. 결국 사람이 읽고 "이건 좀 아닌데"라고 판단해야 함. 그 판단 자체가 주관적이고, 느리고, 스케일이 안 됨.
"평가 기준을 명시화하면 되지 않나?"라는 반론이 있을 수 있는데. 기획서 채점 루브릭을 만들어서 점수를 매기게 하면 closed loop처럼 돌릴 수 있다는 주장의 아티클도 봤음.
근데 그 점수를 누가 매기나. AI가 매기면 그 채점이 맞는지를 또 검증해야 함. 사람이 매기면 사람마다 다르게 매김. 컴파일러는 같은 코드를 넣으면 100번 돌려도 같은 결과가 나오는데, 기획서 채점은 같은 사람이 다른 날 매겨도 점수가 달라질 수 있음.
채점 자체가 검증 가능하지 않은 것.
이쯤에서 드는 생각은: "아직 좋은 평가 도구가 없어서 그런 건가, 아니면 이 종류의 업무는 원래 closed loop으로 만들 수 없는 건가."
"이 브랜드 컨셉이 타겟 소비자에게 먹힐까", "이 GTM 전략이 한국 시장에서 통할까"는 정답이 없는 게 아니라, 정답이 나중에야 드러날 수밖에 없는 종류의 문제라는 것임. 그것도 외부 변수에 의해서. 경쟁사가 뭘 하는지, 소비자 심리가 어떻게 변하는지. 평가에 필요한 변수가 루프 밖에 있음.
한 발 물러서 보면, 개발자의 10x라는 것도 의심해볼 여지가 있음.
"딸깍"으로 앱을 만든다는 건 초기 쉬핑 속도만 본 것일 수 있음. 아키텍처 판단, 기술 부채 관리, 유지보수는 여전히 사람이 해야 하고, 이 부분에서의 실수는 나중에 10배의 비용으로 돌아올 수 있음.
컴파일러가 잡아주는 건 "문법적으로 맞는지"이지 "설계가 좋은지"가 아님. 아키텍처 결정은 기획서 품질 판단과 비슷하게 주관적이고 장기적인 영역. 10x가 작동하는 건 loop이 닫히는 좁은 범위 안에서이고, 그 범위를 넘어서면 개발자도 같은 문제를 겪고 있음.
"비개발자는 안 되고 개발자는 된다"는 이분법이 정확하지 않을 수 있다는 것. 차이는 "loop이 닫히는 영역의 비율"인 것 같다는 생각으로 귀결됨.
"앞으로 사람의 역할은 일을 하는 게 아니라 평가 기준을 설계하는 것이 된다"는 주장이 있는데 방향은 그럴듯 하다고 생각함.
근데 좋은 평가 기준을 설계하려면, 그 업무에서 무엇이 좋고 무엇이 나쁜지를 이미 구분할 수 있어야 함. 즉, 해당 영역의 전문가여야 함.
AI가 일을 대체하고, 사람은 평가를 설계한다? 그 설계 역량은 결국 "일을 오래 해본 경험"에서 나오는 것인데, 일을 AI한테 넘기면 그 경험을 쌓을 기회가 줄어드는 역설이 생김.
평가 기준 설계가 미래의 핵심 역량이라면, 그 역량을 키우는 경로 자체가 AI에 의해 좁아지고 있는 건 아닌지 생각해볼만 함
비개발자가 AI로 10x를 내려면 개발자의 방법론을 그대로 따라가기는 구조적으로 어려움.
평가 함수 자체가 없는 경우가 대부분이고, 있다고 해도 그 평가의 검증까지 연쇄적으로 문제가 생김.
그러면 두 가지 방향이 가능한 것 같음.
하나는, 비개발자의 업무 중에서 loop을 닫을 수 있는 영역을 찾아서 거기부터 공략하는 것. 모든 업무가 아니라, 평가 기준이 명시화될 수 있는 부분만 AI에게 넘기는 것.
다른 하나는, closed loop이 아닌 다른 구조를 찾는 것. 개발자의 10x가 "빠른 반복"에서 오는 거라면, 비개발자의 10x는 "축적된 맥락"에서 올 수 있지 않을까. 맥락이 복리로 쌓이는 구조를 만들면 그 자체가 다른 형태의 레버리지가 되지 않을까.
정리해보면,
비개발자의 업무에서 검증 가능한 평가 기준을 만드는 게 왜 어려운가. 기술이 아직 못 따라온 건지, 아니면 이 종류의 업무가 원래 그런 건지. 평가 기준 설계가 미래의 핵심 역량이라면, 그 역량을 키우는 경로는 뭔지. 비개발자에게 개발자 방법론을 이식하는 게 맞는 방향인지, 아니면 완전히 다른 경로가 있는 건지.
나는 이 질문들에 대한 답이 아직 없지만, 근데 최소한 질문이 선명해지면, 삽질의 방향이 맞는지 정도는 확인할 수 있지 않을까.하는 생각임. 나는 이 질문들을 안고 직접 부딪혀보기 위해 내 나름의 하네스 v1을 깎아봤음 이름은 moondol 이고, (문돌이의 그 문돌 맞음) 한 두바퀴 정도 이터레이션 돌려보고 괜찮으면 다른 분들께도 공유해볼 예정..