저는 세상의 모든 조직이 적어도 부분적으로는 프로세스 최적화 (Process Optimization)에 집중하고 있다는 느낌을 받습니다. 이는 시장 상황이 좋지 않을 때 자주 발생하는 현상입니다. 요즘은 이 모든 과정에 AI라는 관점이 더해졌고, 그에 따른 비현실적인 기대치들도 뒤따르고 있습니다.

이에 대해 완전히 준비된 상태로 임하기 위해, 저는 이 분야의 절대적인 고전 두 권인 'The Toyota Way'와 'The Goal'을 다시 읽기로 했습니다. 대학 시절 이 두 권의 책을 모두 읽었지만, 다시 읽어보니 이러한 프로세스 최적화 연습의 상당수가 본질적으로 너무 단순하며, 무엇에 집중해야 하는지를 종종 오해하고 있다는 사실을 깨달았습니다.

시각적 병목 현상 (The visual bottleneck)

제가 무엇을 의미하는지 보여드리겠습니다.

gantt
    title Project Timeline
    dateFormat YYYY-MM-DD
    section Scoping
    Feature exploration :s1, 2024-01-01, 10d
    Budget scoping :s2, after s1, 3d
    Legal :s3, after s1, 10d
    Documenting :s4, after s3, 5d
    section Development
    Exploration :d1, after s4, 25d
    Software Development :d2, after d1, 70d
    Documentation :d3, after d2, 5d
    section Deployment
    Deployment :dp1, after d2, 5d
    Hyper-care :dp2, after dp1, 10d

이것은 데모를 위한 Gantt 차트이며, 보통은 BPMN을 확인하게 됩니다. Gantt 차트를 보여드리는 것이 요점을 더 쉽게 전달할 수 있기 때문입니다.

이 Gantt 차트를 살펴보면 무엇이 가장 많은 시간을 차지하는지 즉시 알 수 있습니다. 바로 소프트웨어 개발 (Software Development)입니다. 만약 당신의 과업이 프로젝트 처리량 (Throughput)을 개선하는 것이라면, 그곳이 첫 번째 정착지가 될 것입니다. 그리고 그것은 옳은 방향입니다.

하지만 문제는 제가 보통 사람들이 이 문제를 해결하는 방식에서 발견하는 지점입니다. 문제를 해결하기 위해 사람을 투입하거나, 혹은 단순히 AI가 이를 훨씬 더 빠르게 만들어 줄 것이라고 가정해 버립니다.

사람들이 일반적으로 하지 않는 것은 이것이 왜 이렇게 오래 걸리는지를 살펴보는 것이며, 더 중요한 것은 다음과 같습니다: 긴 소요 시간 (Long duration)이 반드시 그곳에서 문제가 시작된다는 것을 의미하지는 않습니다.

상류 단계에서의 문제 해결 (Solving the issue upstream)

우리는 지금 소프트웨어 개발에 대해 이야기하고 있지만, 이는 당신이 원하는 것보다 더 오래 걸리는 모든 프로세스에 적용 가능합니다.

모든 소프트웨어 개발자는 단순히 타이핑을 더 빨리 한다고 해서 프로젝트 속도를 높일 수 없다는 사실을 알고 있습니다. 만약 그랬다면 우리 모두 타이핑 레슨을 받고 있었을 것입니다.

소프트웨어 개발은 문제를 컴퓨터가 이해하고 자동으로 해결할 수 있는 솔루션 (Solution)으로 변환하는 과정입니다. 가급적이면 보안이 유지되고 확장 가능한 (Scalable) 방식으로 말이죠.

그와 같은 일을 수행하려면 문제에 대한 전체적인 개요가 필요합니다. 기능 명세서나 범위 정의서 (Feature or Scope documents)를 활용하거나 (폭포수 (Waterfall) 모델을 따르는 경우), 도메인 전문가 (Domain experts)와 지속적인 반복 (Iteration)을 거쳐야 합니다 (애자일 (Agile) 방식의 경우).

이 부분이 종종 소프트웨어 개발 속도를 늦추는 원인이 됩니다. 모호하고 제목만 적힌 기능 요청 (Feature request)이 실제로 무엇을 의미하는지 파악하려고 애쓰는 과정 말입니다.

“판매가 완료되면 사용자에게 메일을 발송한다”는 것은 무엇을 의미할까요? 좋습니다, 메일을 보낼 수는 있습니다. 하지만 메일에 무엇이 포함되어야 할까요? 만약 판매 프로세스에 문제가 발생한다면, 그래도 에러 메일을 보내야 할까요? 판매는 언제 완료된 것으로 간주할까요?

그냥 AI를 투입하면 된다

소프트웨어 개발의 자동화 (AI 생성 코드)에 대해 제가 계속 듣고 있는 주장 중 하나는, 개발 단계를 그냥 건너뛰고 소프트웨어 개발자가 프로젝트 매니저 (Project Manager)가 되면 된다는 것입니다. 소프트웨어 개발을 둘러싼 AI 논의들은 실제로 이 문제를 완벽하게 보여줍니다.

많은 사람들이 AI 개발의 결과물이 다음과 같기를 기대합니다:

gantt
    title Project Timeline
    dateFormat YYYY-MM-DD
    section Scoping
    Feature exploration :s1, 2024-01-01, 10d
    Budget scoping :s2, after s1, 3d
    Legal :s3, after s1, 10d
    Documenting :s4, after s3, 5d
    section Development
    AI development :d1, after s4, 3d
    section Deployment
    Deployment :dp1, after d1, 5d
    Hyper-care :dp2, after dp1, 10d

하지만 실제로는 그렇게 작동하지 않습니다. 여기서 우리는 이전과 정확히 동일한 상류 (Upstream) 문제를 마주하게 됩니다.

네, AI는 코드를 빠르게 생성할 수 있습니다 (그것이 좋은 것인지에 대해서는 논란의 여지가 있습니다). 하지만 그것이 올바른 코드를 생성한다는 의미는 아닙니다.

인간 대 AI 개발의 비교에서, 사람들은 AI가 제 역할을 하기 위해 필요한 가이드 (Handholding) 과정을 항상 무시합니다. 실제로는 다음과 같은 모습에 훨씬 더 가깝습니다:

gantt
title Project Timeline
dateFormat YYYY-MM-DD
section Scoping
Feature exploration :s1, 2024-01-01, 10d
Budget scoping :s2, after s1, 3d
Legal :s3, after s1, 10d
Documenting :s4, after s3, 40d
section Development
AI development :d1, after s3, 40d
section Deployment
Deployment :dp1, after d1, 5d
Hyper-care :dp2, after dp1, 10d

아마도 이러한 설정이 기존의 작업 방식에 비해 더 빠를 수도 있습니다. 하지만 저는 이것이 불공평한 비교라고 생각합니다. 이런 방식으로 일하려면 도메인 전문가(Domain expert)와 제품 전문가(Product expert)의 훨씬 더 깊은 관여가 필요합니다. 이러한 관여는 아주 작은 세부 사항까지 모든 기능(Feature)과 버그 수정(Bug fix) 사항을 글로 작성하는 것을 의미합니다.

이것은 바로 소프트웨어 개발자들이 직업을 시작한 이래로 계속해서 간청해 온 바로 그것입니다: 문제에 대한 상세한 개요와 최종 결과물이 어떤 모습이어야 하는지에 대한 상세한 설명입니다.

만약 인간 개발자에게도 지금과 동일한 양의 기능/범위(Feature/Scope) 문서화 자료를 제공한다면, 여러분의 생산성 또한 급격히 치솟는 것을 보게 될 것입니다.

실제로 프로세스 속도를 높이는 법

프로세스 속도를 높이고 싶다면, 실제로 일을 해야 하는 사람들이 그 일을 수행할 수 있는 모든 수단을 갖추고 있는지 확인해야 합니다.

이는 만약 법무 승인 프로세스가 느리게 진행되고 있다면, 법무 승인 프로세스를 시작하는 데 무엇이 필요한지 살펴보아야 한다는 것을 의미합니다. 만약 법무팀이 미비한 서류 때문에 다섯 명의 서로 다른 사람들을 쫓아다녀야 하는 상황이라면, 부서에 변호사를 더 추가한다고 해서 해당 프로세스의 속도가 빨라지지는 않을 것입니다.

『더 골(The Goal)』이 주는 큰 교훈 중 하나는 다음과 같습니다: "병목 지점(Bottlenecks)은 예측 가능하고 고품질인 입력값(Inputs)을 받아야 한다."

저는 이것이 프로세스 자동화(Process automation)의 첫 번째 단계가 되어야 한다고 생각합니다.

[Business-Layer]에서의 추가 읽을거리...

제가 팀들을 찾아가 프로세스 매핑(Process mapping)과 표준 운영 절차(SOP, Standard Operating Procedures)에 대해 이야기할 때마다, 저는 부정할 수 없는 양의 ...를 목격합니다.

게시물 읽기 | 저는 살면서 다섯 개의 엔터프라이즈 아키텍처(Enterprise architecture) 사무국 구축에 참여했습니다. 어떤 곳은 제가 이끌었고, 어떤 곳은 단순히 일원이었습니다.

만약 ...

Read Entry 개발자였을 때, 우리 좌절감의 절반은 기술 부채 (technical debt) 때문이었고, 나머지 절반은 마감 기한으로 간주되는 추정치 (estimates) 때문이었습니다.

We …

Read Entry