TF 속 개발자와 실무자의 동상이몽

기업에서는 Dx, Ax를 위해 기획을 시작한다.

그리고 기획이 마무리될 즈음, 보다 좋은 시스템을 구축하기 위해 TF를 구축한다.

'프로그램을 사용할' 실무자와 '프로그램을 만들' 개발자들이 한자리에 모여 회의를 하는 것이다.

지금 하는 업무의 비효율을 없애자는 주제로 TF가 시작되고, 6개월쯤 지나면 다시 엑셀 파일을 주고받기 시작한다.

결국 ERP에서 다운받은 엑셀 파일을 가공하던 업무가,

새로 만든 시스템에서 다운받은 엑셀 파일을 가공하는 업무로 바뀌는 경우가 많다.

제약회사를 다니며, 엑셀을 잘한다는 이유로 그러한 TF에 참여한 적이 몇 번 있었다.

성공으로 끝난 경우도 있지만, 실패했던 적이 더 많았던 것 같다.

실패의 공통점은 이렇다.

1. 1. 솔루션은 매번 그럴듯했고,

2. 2.발표 자료도 깔끔했다.

3. 3. 처음에는 새 시스템을 그대로 쓰지만, 시간이 지나면 그 출력물을 다시 엑셀에서 가공하기 시작한다.

문제는 새로운 시스템이 아니다.

같은 회의실에 앉은 개발자와 실무자가, 사실은 완전히 다른 세계를 보고 있다는 것이다.

#개발자가 보는 풍경

개발자는 무(無)에서 유(有)를 생각하면서 기획한다.

새 시스템, 새 워크플로우, 새 데이터 구조. 그게 그들의 훈련된 사고법이다.

회의에서 개발자는 화이트보드에 박스를 그린다.

데이터가 어디서 들어와서, 어떻게 흘러서, 어디로 나가는지를 그린다.

더 나아가 데이터는 어떻게 유지·관리될지, 누가 어디까지 손댈 수 있을지를 꼼꼼하게 정의하며 완성도를 높여간다.

이게 잘못된 게 아니다. 사실 시스템을 만들려면 이렇게 그릴 수밖에 없다.

문제는 데이터가 왜 필요하고, 왜 이걸 더해서 봐야 하는지에 대한 고민이 없다는 것이다.

#실무자가 보는 풍경

같은 회의실에 앉은 실무자는 화이트보드를 보면서 다른 생각을 한다.

"이번 주 금요일까지 임원 보고 가야 하는데. "

"영업부서에서 어제 또 잘못 보낸 엑셀 어떻게 합치지. "

"이 시스템 들어오기 전까지의 취합은 누가 하지."

실무자는 무에서 유를 생각하지 않는다. 지금 처한 일을 우선적으로 생각한다.

이번 달 정산은 새 시스템과 무관하게 끝나야 하고, 그 책임은 회의실의 개발자가 아니라 실무자에게 있다.

빈 화면에서 우리 회사에 필요한 시스템을 만드는 경험 또한 충분하지 않다.

고민을 해서 시스템을 생각할 때 취합 메일은 계속 도착하며, 당연히 이러한 취합을 자동화하는 것이 필요하다고 느끼는 것이다.

근본적으로 취합을 없앨 고민은 여기에서 누락되게 된다.

#두 세계가 만나면 무슨 일이 생길까?

두 세계가 만나도 충돌하지 않는다. 충돌하면 차라리 낫다.

두 세계는 합의된 것처럼 보이는 합의를 한다.

실무자가 말한다. "지금 이 취합이 너무 오래 걸려서요."

개발자가 받는다. "그럼 이걸 빠르게 만드는 시스템을 만들죠."

아무도 취합이 왜 존재하는가를 묻지 않았다.

실무자는 취합을 더 빠르게 해달라고 부탁했고, 개발자는 더 빠른 취합 도구를 약속했다.

6개월 뒤, 더 빠른 도구가 들어왔지만 취합은 그대로다. 단지 빨라졌을 뿐이다.

그리고 취합은 보고받는 사람과 상황에 따라 관점이 매번 달라진다.

시간이 지나면 자연스럽게 새로운 취합을 원하게 되고, 그때 개발자는 "초기에 없던 취합이라, 개발하려면 OO개월이 걸려요"라고 답한다.

실무자는 "일단 보고해야 하니, 내가 양식 만들지 뭐"라며 다시 엑셀을 연다. 취합 업무는 그렇게 다시 고개를 든다.

자동화는 취합을 줄이는 일이 아니라, 취합이 왜 존재하는지 묻는 일이어야 한다.

데이터를 모으는 시스템이 아니라 데이터를 관리하는 시스템을 목표로 해야 한다.

이 과정에서 확장과 유연함을 고려한다면, 시스템으로서의 수명을 늘릴 수 있다.

데이터 이야기를 잠깐하면,

자동화의 9할은 데이터 정리, 1할이 코드다.

하지만 실무에서는 같은 포맷으로, 같은 키(key)로, 일정 기간 이상 쌓인 데이터가 없다.

쉽게 말해, 거래처는 하나지만 거래처 이름은 여러 개다.

"○○병원", "○○병의원", "○○ 의원" — 한 거래처가 세 가지 표기로 존재한다.

컬럼 순서가 담당자마다 다르다.

작년 자료는 3개의 파일에 저장되어있다.

작년매출.xlsx, 작년매출 (1).xlsx, 작년매출_24012412.xlsx

실제로 내가 봤던 데이터는 이렇다.

서울대병원, 서울대학교병원, 국립서울대병원, 서울병원, 서울대

(이 중 4개는 같은 병원, 1개는 다른 병원이었다.)

실무자는 보고를 위해 데이터가 필요하다. 이번 주 보고만 끝나면 되니, 컬럼 통일이나 키 관리 같은 건 우선순위에서 밀린다.

그런데 개발자는 키부터 정의하기 시작한다.

이렇게 만들어진 키로 개발을 시작하고 1달 정도 지나면, 이제 실무에서는 예외가 발생하기 시작한다.

"이게 같은 거래처이긴 한데, 실적은 각각 다르게 잡아야 해요."

거래처는 1개지만, 거래처A와 거래처B가 이렇게 탄생하게 된다.

#lean이 안 되는 이유

스타트업 책에서 말하는 lean start는 단순하다. 작게 시작하고, 빠르게 검증하고, 틀리면 빨리 바꾼다.

영업현장에서 이게 잘 안 되는 이유는 두 세계의 합의 때문이다.

작게 시작하자고 하면 실무자는 "지금" 업무를 기준으로 답변한다.

빠르게 검증하자고 하면 "지금" 데이터를 기준으로 검증한다.

결국 시스템이 완성되는 D-Day에는, "과거" 기준으로 답변되고 검증된 시스템이 새로운 시스템이라는 이름으로 나오게 된다.

#두 세계를 잇는 자리

자동화는 도구의 문제도, 사람의 문제도 아니다. 두 세계가 만나는 자리에 누군가 서 있느냐의 문제다.

그 자리에 서려면 양쪽 언어를 다 알아야 한다. 코드도 짜봐야 하고, 이번 주 보고도 해봐야 한다.

나는 스무고개를 많이 하는 편이다. 실무자에게 업무 흐름에 대한 설명을 듣고, 이렇게 물어본다.

"숫자만 들어와요?" → "음수는 안 들어와요?" → "소수점은 없겠네요?"

[수량]이라는 컬럼 하나를 정의하기 위해 이렇게 물어보면,

실무자는 '뭐 이런 당연한 걸 물어봐요?'라는 표정이고, 개발자는 굉장히 만족한다.

테이블 명세를 보고, FK/PK를 살펴보며 집계의 범위를 최대한 확장해 나가면,

개발자는 "이렇게 할거면 따로 테이블을 만드는 게 낫다"며 커피를 사러 간다.

실무자는 "이런 것도 바로 나와요?"라며 신기해한다.

TF나 Lean Start라는 방법론 자체가 문제는 아니다. 다만 이런 시스템을

왜 사람들이 쓰는지, 왜 이 업무가 필요한지, 왜 시스템을 만드는지.

이 근본적인 고민을 바탕으로 실무자와 개발자 사이의 거리를 좁혀나간다면, 더 좋은 시스템이 나온다.

결국 서로의 관점의 차이를 인정하고, 소통이 중요하다.

AI와의 소통은 '문제를 먼저 인식' 한 후여야 한다.

정확한 문제를 인식하기 위해서는

현장에서 TF가 '왜' 를 생각하는 것이 필요하다.