내가 가장 좋아하는 프로세스와 문서화 관련 일화 중 하나임
헤지펀드에서 일할 때 매일 저녁 다음 거래일을 준비하는 18단계 절차 중 7단계가 실패했음
나는 그 단계를 문서화하고 여러 사람에게 보여줬는데, 모두가 “7단계 문서가 잘못됐다”는 데는 동의했지만 “7단계가 실제로 무엇을 해야 하는가”에 대해서는 전혀 합의가 안 됐음
이 경험을 통해 단순히 ‘지금 일어나는 일을 글로 적는 것’ 만으로도 사람들이 실제 프로세스를 이해하고 합의하는 데 큰 진전이 생긴다는 걸 깨달았음
예전에 시장 데이터 시스템 문서를 쓸 때도 “그거 복잡하지 않다”던 사람들이 완성된 문서를 보고 “생각보다 복잡하네”라고 했던 기억이 있음
사람들이 현재 상태를 문서화하는 일과 개선 논의를 구분하지 못하는 것이 미치게 함
“지금은 7단계가 실제로 무엇을 하는지 적는 시간이지, 어떻게 바꿀지 논의할 때가 아니다”라고 말해도 자꾸 섞여버림
일단 잘못된 방식이라도 하나로 정리해두고, 나중에 고치는 게 맞다고 생각함
나도 7단계 논의에 참여한 적이 있는데, 그 경험은 정말 영혼이 빠지는 느낌이었음
결국 “문서화하지 말자”는 결론이 나왔는데, 그게 오히려 더 문제였음
문서화는 합의의 기준선을 만들어주고, 새로 합류한 사람들도 불필요한 세부 논쟁 없이 일할 수 있게 해줌
이제는 명확한 프로세스 없이 큰일을 하는 건 상상도 못함
이 이야기가 AI의 역할 ― 즉 가속화와 자동화 ― 에 대한 글의 논지와 닮아 있음
어떤 CEO의 5단계 제품 프로세스가 떠오름
요구사항을 제대로 설계하고 책임자를 명시함
불필요한 기능을 과감히 삭제함
단순화 및 최적화
가속화
자동화
AI는 이 중 ‘언제’ 투입되어야 하는지가 명확해야 함
많은 사람들이 이 순서를 거꾸로 적용해서 실패함
글쓰기 자체가 불과 맞먹는 수준의 인류 최고의 도구라고 생각함
너무 과소평가되고 있지만, 인류 발명품 중 상위 5위 안에 들어야 함
Feynman의 알고리즘이 떠오름 — 문제를 적고, 깊이 생각하고, 해답을 적는 것임
“AI로 엉망인 비즈니스 프로세스를 금으로 바꿀 수 없다”는 문장이 인상적이었음
결국 AI 전략이란 건 없고, 존재하는 건 비즈니스 프로세스 최적화뿐임
소프트웨어 개발에서도 비슷한 말이 있음 — “기술 부채가 아니라 조직 부채”라는 표현처럼, 사회적 문제를 기술로 해결하려는 착각이 많음
Fortune 300 기업에서 9천만 달러를 들여 Business Process Redesign을 시도했지만 실패했음
이름을 잘못 붙인 게 문제였다고 생각함 — ‘Redesign’이 아니라 ‘Design’이었어야 함
고객 번호 통합 시도가 완전히 꼬여서 결국 새 번호를 부여하면서도 옛 번호를 계속 쓰는 혼란이 생김
이런 회사가 AI를 도입했다면 어떤 혼돈이 벌어졌을지 상상됨
AI 전략이 존재하긴 함 — ‘제품이 아니라 허상을 파는 사람들’ 에게만 해당됨
“Here’s the hard truth” 같은 표현은 LinkedIn식 말투처럼 느껴져서 좀 거슬림
대부분의 기업 문제는 적절한 인력과 교육으로 해결 가능하지만, 그걸 하지 않기 때문에 아무것도 해결되지 않음
수십 년간의 비용 절감과 인력 감축으로 프로세스가 망가졌고, 이제는 대기업조차 제대로 작동하지 않음
AI 기업들이 이런 폐허 위에서 데이터를 삼켜 LLM 결과물로 되돌려주며 돈을 벌고 있음
대기업에서의 프로세스에 대해 복잡한 감정을 가짐
평균적인 사람들에게서 좋은 결과를 끌어내는 데는 유용하지만, 뛰어난 사람들에게는 오히려 족쇄가 됨
그래서 나는 뛰어난 인재들에게는 예외 권한을 주는 게 현실적이라고 봄
그들이 빠르게 움직이고 집중할 수 있도록 절차 일부를 면제해주는 식임
아직도 이런 접근이 프로세스 자체에 대해 무엇을 의미하는지 고민 중임
Agile Manifesto의 “People over process”를 떠올림
자주 발생하는 케이스에는 명확한 프로세스를 두되, 뛰어난 엔지니어가 빠르게 대응할 수 있는 탈출구도 필요함
‘락스타’들에게는 별도의 sandbox 환경을 주는 게 좋지만, 그 결과물이 결국 조직 프로세스로 들어와야 하기에 완전한 분리는 어려움
평균 품질을 끌어올리면 천장이 낮아지는 구조적 문제임
락스타가 필요하다는 건 나쁜 프로세스의 신호임
좋은 프로세스는 락스타가 더 빠르게 일할 수 있게 도와야 함
문서 작업을 프로세스로 착각하는 관리가 문제임
프로세스는 게으른 사람들로부터 시스템을 보호함
엉망인 요청과 비협조적인 행동이 반복되면 결국 절차를 강제할 수밖에 없음
창의적인 시도가 줄어들더라도, 무질서의 비용이 더 큼
“대기업에서 평균 수준의 프로세스조차 혁신처럼 느껴진다”는 말에 공감함 ServiceNow 폼 하나 세우는 것조차 진전으로 여겨지는 현실임
“AI는 비정형 데이터를 다루는 첫 기술”이라는 문장이 좋았음
비정형 데이터를 다루는 프로세스는 대체로 비정형적이라는 요약이 마음에 듦
하지만 왜 그런 프로세스가 쉽게 구조화되지 못하는지에 대한 설명이 부족함
외부 세계나 다른 팀과의 비정형 상호작용, 혹은 너무 다양한 변동성 때문임
경험 많은 프로세스 설계자는 이런 ‘반정형적 경계’ 를 인정하고 주의 깊게 관찰함
AI도 이런 원칙을 따라야 함 — 시스템 범위를 과도하게 확장하지 말고, 작은 구조화된 프로세스들이 비정형 환경 속에서 떠다니게 해야 함
인간 간의 자연어 커뮤니케이션이 포함된 프로세스도 충분히 구조화될 수 있음
구조화된 데이터가 없던 시절에도 잘 돌아가던 회사들이 많았음
검색 분야에서 13년간 일하며 느낀 건, 경영진이 항상 ‘유행 기술’로 비용 절감을 꿈꾸지만 실제로는 더 깊은 투자가 필요하다는 점임
그래서 컨설턴트들이 등장함
“기존 기술은 문제지만 새 이름으로 포장된 기술이 진짜 절감 효과를 준다”고 말하면서 새로운 유행을 팔기 시작함
20년간 프로세스 자동화를 해오며 느낀 건, 정의되지 않은 프로세스를 자동화하려 하면 실패한다는 것임
요구사항을 정의하는 과정이 오히려 회사를 더 명확하게 만드는 경우도 있었지만, 대부분은 그걸 회피함
대신 툴에 유연성을 더하려다 결국 아무 쓸모 없는 도구가 되어버림
나도 지금 그런 상황을 겪고 있음
다른 팀이 데이터 처리 워크플로우를 단순화하는 도구를 원하지만, 현재 프로세스 문서조차 없음
결국 우리가 그들의 프로세스를 역으로 분석해야 하는 상황이 됨
여러 회사에서 ERP를 도입하는 걸 봤는데, 기존 프로세스를 그대로 옮기려다 커스터마이징 지옥에 빠짐
예산과 일정은 항상 초과했음
이 글은 핵심을 정확히 짚었다고 느낌 너무 많은 프로세스는 문제지만, 구조 자체는 항상 필요함
AI는 구조화된 데이터를 잘 다루므로, 완전한 자유보다는 적절한 구조의 균형이 중요함 관련 링크
문서화는 생각을 명확히 하는 데 매우 유용함
반복하던 일을 글로 적는 순간 불필요한 단계를 줄이는 아이디어가 떠오름
지금은 내 비즈니스 운영의 일부를 AI에 넘기려 하고 있음
작은 전자상거래 브랜드를 인수할 때, LLM이 초기 분석을 맡도록 6페이지짜리 프롬프트를 만들어 사용 중임
이 경험을 통해 LLM의 지능보다 구조화된 작업 설계가 경제적 가치를 만든다는 걸 깨달았음
다만 아직 웹 브라우징과 파일 업로드를 자동으로 처리해줄 에이전트가 없어 완전 자동화는 어려움
Hacker News 의견
내가 가장 좋아하는 프로세스와 문서화 관련 일화 중 하나임
헤지펀드에서 일할 때 매일 저녁 다음 거래일을 준비하는 18단계 절차 중 7단계가 실패했음
나는 그 단계를 문서화하고 여러 사람에게 보여줬는데, 모두가 “7단계 문서가 잘못됐다”는 데는 동의했지만 “7단계가 실제로 무엇을 해야 하는가”에 대해서는 전혀 합의가 안 됐음
이 경험을 통해 단순히 ‘지금 일어나는 일을 글로 적는 것’ 만으로도 사람들이 실제 프로세스를 이해하고 합의하는 데 큰 진전이 생긴다는 걸 깨달았음
예전에 시장 데이터 시스템 문서를 쓸 때도 “그거 복잡하지 않다”던 사람들이 완성된 문서를 보고 “생각보다 복잡하네”라고 했던 기억이 있음
“지금은 7단계가 실제로 무엇을 하는지 적는 시간이지, 어떻게 바꿀지 논의할 때가 아니다”라고 말해도 자꾸 섞여버림
일단 잘못된 방식이라도 하나로 정리해두고, 나중에 고치는 게 맞다고 생각함
결국 “문서화하지 말자”는 결론이 나왔는데, 그게 오히려 더 문제였음
문서화는 합의의 기준선을 만들어주고, 새로 합류한 사람들도 불필요한 세부 논쟁 없이 일할 수 있게 해줌
이제는 명확한 프로세스 없이 큰일을 하는 건 상상도 못함
어떤 CEO의 5단계 제품 프로세스가 떠오름
AI는 이 중 ‘언제’ 투입되어야 하는지가 명확해야 함
많은 사람들이 이 순서를 거꾸로 적용해서 실패함
너무 과소평가되고 있지만, 인류 발명품 중 상위 5위 안에 들어야 함
“AI로 엉망인 비즈니스 프로세스를 금으로 바꿀 수 없다”는 문장이 인상적이었음
결국 AI 전략이란 건 없고, 존재하는 건 비즈니스 프로세스 최적화뿐임
이름을 잘못 붙인 게 문제였다고 생각함 — ‘Redesign’이 아니라 ‘Design’이었어야 함
고객 번호 통합 시도가 완전히 꼬여서 결국 새 번호를 부여하면서도 옛 번호를 계속 쓰는 혼란이 생김
이런 회사가 AI를 도입했다면 어떤 혼돈이 벌어졌을지 상상됨
수십 년간의 비용 절감과 인력 감축으로 프로세스가 망가졌고, 이제는 대기업조차 제대로 작동하지 않음
AI 기업들이 이런 폐허 위에서 데이터를 삼켜 LLM 결과물로 되돌려주며 돈을 벌고 있음
대기업에서의 프로세스에 대해 복잡한 감정을 가짐
평균적인 사람들에게서 좋은 결과를 끌어내는 데는 유용하지만, 뛰어난 사람들에게는 오히려 족쇄가 됨
그래서 나는 뛰어난 인재들에게는 예외 권한을 주는 게 현실적이라고 봄
그들이 빠르게 움직이고 집중할 수 있도록 절차 일부를 면제해주는 식임
아직도 이런 접근이 프로세스 자체에 대해 무엇을 의미하는지 고민 중임
자주 발생하는 케이스에는 명확한 프로세스를 두되, 뛰어난 엔지니어가 빠르게 대응할 수 있는 탈출구도 필요함
평균 품질을 끌어올리면 천장이 낮아지는 구조적 문제임
좋은 프로세스는 락스타가 더 빠르게 일할 수 있게 도와야 함
문서 작업을 프로세스로 착각하는 관리가 문제임
엉망인 요청과 비협조적인 행동이 반복되면 결국 절차를 강제할 수밖에 없음
창의적인 시도가 줄어들더라도, 무질서의 비용이 더 큼
ServiceNow 폼 하나 세우는 것조차 진전으로 여겨지는 현실임
“AI는 비정형 데이터를 다루는 첫 기술”이라는 문장이 좋았음
비정형 데이터를 다루는 프로세스는 대체로 비정형적이라는 요약이 마음에 듦
외부 세계나 다른 팀과의 비정형 상호작용, 혹은 너무 다양한 변동성 때문임
경험 많은 프로세스 설계자는 이런 ‘반정형적 경계’ 를 인정하고 주의 깊게 관찰함
AI도 이런 원칙을 따라야 함 — 시스템 범위를 과도하게 확장하지 말고, 작은 구조화된 프로세스들이 비정형 환경 속에서 떠다니게 해야 함
구조화된 데이터가 없던 시절에도 잘 돌아가던 회사들이 많았음
검색 분야에서 13년간 일하며 느낀 건, 경영진이 항상 ‘유행 기술’로 비용 절감을 꿈꾸지만 실제로는 더 깊은 투자가 필요하다는 점임
“기존 기술은 문제지만 새 이름으로 포장된 기술이 진짜 절감 효과를 준다”고 말하면서 새로운 유행을 팔기 시작함
20년간 프로세스 자동화를 해오며 느낀 건, 정의되지 않은 프로세스를 자동화하려 하면 실패한다는 것임
요구사항을 정의하는 과정이 오히려 회사를 더 명확하게 만드는 경우도 있었지만, 대부분은 그걸 회피함
대신 툴에 유연성을 더하려다 결국 아무 쓸모 없는 도구가 되어버림
다른 팀이 데이터 처리 워크플로우를 단순화하는 도구를 원하지만, 현재 프로세스 문서조차 없음
결국 우리가 그들의 프로세스를 역으로 분석해야 하는 상황이 됨
Fred Brooks의 “No Silver Bullet”을 인용하고 싶음
링크
여러 회사에서 ERP를 도입하는 걸 봤는데, 기존 프로세스를 그대로 옮기려다 커스터마이징 지옥에 빠짐
예산과 일정은 항상 초과했음
이 글은 핵심을 정확히 짚었다고 느낌
너무 많은 프로세스는 문제지만, 구조 자체는 항상 필요함
AI는 구조화된 데이터를 잘 다루므로, 완전한 자유보다는 적절한 구조의 균형이 중요함
관련 링크
문서화는 생각을 명확히 하는 데 매우 유용함
반복하던 일을 글로 적는 순간 불필요한 단계를 줄이는 아이디어가 떠오름
지금은 내 비즈니스 운영의 일부를 AI에 넘기려 하고 있음
작은 전자상거래 브랜드를 인수할 때, LLM이 초기 분석을 맡도록 6페이지짜리 프롬프트를 만들어 사용 중임
이 경험을 통해 LLM의 지능보다 구조화된 작업 설계가 경제적 가치를 만든다는 걸 깨달았음
다만 아직 웹 브라우징과 파일 업로드를 자동으로 처리해줄 에이전트가 없어 완전 자동화는 어려움