35P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • AI 도입만으로 비즈니스 문제를 해결할 수 없으며, 비효율적인 프로세스를 자동화하면 단지 ‘쓰레기를 더 빨리 생산하는’ 결과로 이어짐
  • 기업들은 AI를 마법 지팡이처럼 착각하지만, AI는 조직을 더 똑똑하게 만드는 것이 아니라 단지 속도를 높이는 도구에 불과함
  • AI의 유일한 강점은 비정형 데이터 처리 능력이지만, 이런 데이터에 의존하는 프로세스 자체가 대개 비정형적이고 문서화되어 있지 않음
  • 따라서 AI를 적용하기 전에 프로세스를 설계하고 구조화해야 하며, 입력·변환·출력 단계를 명확히 정의해야 함
  • 기술은 변하지만 비즈니스 효율성의 원칙은 변하지 않으며, AI 성공의 핵심은 결국 프로세스 최적화에 있음

AI 전략이 아닌 비즈니스 프로세스 최적화

  • 기업들이 “AI 전략”을 논의하지만, 실제로 존재하는 것은 비즈니스 프로세스 최적화(BPO) 뿐임
    • AI는 비즈니스 문제를 해결하는 독립적 전략이 아니라, 이미 존재하는 프로세스를 가속화하는 도구임
    • 비효율적인 구조 위에 AI를 얹으면 문제를 더 빠르게 확대할 뿐임

‘마법 지팡이’ 착각

  • 많은 기업이 AI가 비효율을 자동으로 제거할 것이라 믿지만, 이는 잘못된 전제임
    • AI는 지능을 부여하지 않으며, 단지 결정의 속도만 높임
    • 잘못된 결정을 자동화하면 ‘빛의 속도로 어리석은 결정’을 내리는 시스템이 될 뿐임
  • 복잡한 승인 절차 같은 관료적 프로세스에 AI를 적용하면, 직원처럼 불만을 가진 로봇을 만드는 셈임

비정형 데이터의 함정

  • AI는 비정형 데이터 처리에 강점을 가진 최초의 기술임
    • 이메일, Slack 메시지, PDF, 이미지 등 기존 소프트웨어가 다루지 못한 데이터를 해석 가능
  • 그러나 이런 데이터에 의존하는 프로세스는 대부분 비정형적이고 비공식적
    • 예: 고객 불만 처리, 마케팅 캠페인 기획 등은 문서화되지 않고 경험 많은 직원의 머릿속에만 존재
    • 과거에는 컴퓨터가 처리할 수 없어 사람이 대신했기 때문에, 흐름도나 표준 절차(SOP) 가 존재하지 않음

설계되지 않은 것은 자동화할 수 없음

  • AI를 적용하려면 먼저 프로세스를 명확히 설계하고 구조화해야 함
    • 비정형 데이터를 다루기 위해서는 워크플로 자체에 구조를 부여해야 함
  • 이를 위해 다음 세 가지 질문이 필요함
    1. 트리거: 비정형 데이터는 어디서 발생하는가
    2. 변환: 사람이(또는 AI가) 그 데이터에서 무엇을 추출하거나 해석해야 하는가
    3. 출력: 결과는 ERP나 CRM 같은 구조적 시스템에 어떻게 반영되는가

속도와 지능의 차이

  • AI는 더 빠르게 만들 뿐, 더 똑똑하게 만들지 않음
    • 예시:
      • 기존 방식에서는 분석가가 50개의 계약서를 3일 동안 검토
      • AI 방식에서는 3분 만에 위험 조항을 추출
    • 프로세스 자체(검토→위험 식별→요약)는 동일하지만, AI가 작동하려면 명확히 정의된 절차가 필요함
    • ‘위험’의 의미를 판단하는 지능적 판단은 여전히 인간의 역할

결론: 프로세스가 전부다

  • AI 구세주를 찾는 대신, 화이트보드로 돌아가 가치사슬을 재점검해야 함
    • 특히 비정형 데이터가 얽힌 인간 중심의 복잡한 영역을 시각화하고 병목과 낭비를 찾아야 함
  • 프로세스가 단순하고 논리적이며 견고해진 뒤에야 AI를 가속 장치로 활용 가능
  • 기술은 변하지만, 비즈니스 효율의 원칙은 변하지 않음
  • 결국 핵심은 언제나 프로세스

(금융권 SI를 하고있음) 많은 개발자들에게 당신이 전문가인데, 고객이 해달라는데로 하지 말고 고객들에게 당신들은 이렇게 일 해야한다고 말하는 것은 어떤지 물어봄.

결과는 상상하는 것과 같음.

Hacker News 의견
  • 내가 가장 좋아하는 프로세스와 문서화 관련 일화 중 하나임
    헤지펀드에서 일할 때 매일 저녁 다음 거래일을 준비하는 18단계 절차 중 7단계가 실패했음
    나는 그 단계를 문서화하고 여러 사람에게 보여줬는데, 모두가 “7단계 문서가 잘못됐다”는 데는 동의했지만 “7단계가 실제로 무엇을 해야 하는가”에 대해서는 전혀 합의가 안 됐음
    이 경험을 통해 단순히 ‘지금 일어나는 일을 글로 적는 것’ 만으로도 사람들이 실제 프로세스를 이해하고 합의하는 데 큰 진전이 생긴다는 걸 깨달았음
    예전에 시장 데이터 시스템 문서를 쓸 때도 “그거 복잡하지 않다”던 사람들이 완성된 문서를 보고 “생각보다 복잡하네”라고 했던 기억이 있음

    • 사람들이 현재 상태를 문서화하는 일과 개선 논의를 구분하지 못하는 것이 미치게 함
      “지금은 7단계가 실제로 무엇을 하는지 적는 시간이지, 어떻게 바꿀지 논의할 때가 아니다”라고 말해도 자꾸 섞여버림
      일단 잘못된 방식이라도 하나로 정리해두고, 나중에 고치는 게 맞다고 생각함
    • 나도 7단계 논의에 참여한 적이 있는데, 그 경험은 정말 영혼이 빠지는 느낌이었음
      결국 “문서화하지 말자”는 결론이 나왔는데, 그게 오히려 더 문제였음
      문서화는 합의의 기준선을 만들어주고, 새로 합류한 사람들도 불필요한 세부 논쟁 없이 일할 수 있게 해줌
      이제는 명확한 프로세스 없이 큰일을 하는 건 상상도 못함
    • 이 이야기가 AI의 역할 ― 즉 가속화와 자동화 ― 에 대한 글의 논지와 닮아 있음
      어떤 CEO의 5단계 제품 프로세스가 떠오름
      1. 요구사항을 제대로 설계하고 책임자를 명시함
      2. 불필요한 기능을 과감히 삭제함
      3. 단순화 및 최적화
      4. 가속화
      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년간 프로세스 자동화를 해오며 느낀 건, 정의되지 않은 프로세스를 자동화하려 하면 실패한다는 것임
    요구사항을 정의하는 과정이 오히려 회사를 더 명확하게 만드는 경우도 있었지만, 대부분은 그걸 회피함
    대신 툴에 유연성을 더하려다 결국 아무 쓸모 없는 도구가 되어버림

    • 나도 지금 그런 상황을 겪고 있음
      다른 팀이 데이터 처리 워크플로우를 단순화하는 도구를 원하지만, 현재 프로세스 문서조차 없음
      결국 우리가 그들의 프로세스를 역으로 분석해야 하는 상황이 됨
  • Fred Brooks의 “No Silver Bullet”을 인용하고 싶음
    링크

  • 여러 회사에서 ERP를 도입하는 걸 봤는데, 기존 프로세스를 그대로 옮기려다 커스터마이징 지옥에 빠짐
    예산과 일정은 항상 초과했음

  • 이 글은 핵심을 정확히 짚었다고 느낌
    너무 많은 프로세스는 문제지만, 구조 자체는 항상 필요함
    AI는 구조화된 데이터를 잘 다루므로, 완전한 자유보다는 적절한 구조의 균형이 중요함
    관련 링크

  • 문서화는 생각을 명확히 하는 데 매우 유용함
    반복하던 일을 글로 적는 순간 불필요한 단계를 줄이는 아이디어가 떠오름
    지금은 내 비즈니스 운영의 일부를 AI에 넘기려 하고 있음
    작은 전자상거래 브랜드를 인수할 때, LLM이 초기 분석을 맡도록 6페이지짜리 프롬프트를 만들어 사용 중임
    이 경험을 통해 LLM의 지능보다 구조화된 작업 설계가 경제적 가치를 만든다는 걸 깨달았음
    다만 아직 웹 브라우징과 파일 업로드를 자동으로 처리해줄 에이전트가 없어 완전 자동화는 어려움

    • Selenium 같은 도구로 그 사전 작업을 자동화할 수 있지 않겠냐는 제안을 받음