시즌2 2편 — 회사는 카톡과 엑셀, '한 사람의 손'으로 굴러가고 있었다

 

 

Dev Story · 시즌2 2편 — 카톡과 엑셀

회사는 카톡과 엑셀,
'한 사람의 손'으로 굴러가고 있었다

개발하는 사람으로 입사해 처음 본 풍경 — 그리고 그걸 시스템에 담기까지

1편에서 말했듯, 저는 이번엔 시스템 만드는 사람으로 이 회사에 들어왔어요. 그리고 첫 출근에서 본 풍경에 — 솔직히 좀 기가 찼습니다. 이 회사는 카톡과 엑셀, 그리고 '한 사람의 손'으로 굴러가고 있었거든요.

1 이번엔 '내가 아는 회사'가 아니었다

시즌 1의 회사는 제가 10년을 다닌 곳이었어요. 그래서 문제가 뭔지, 일이 어떻게 도는지 손바닥 보듯 알았죠. CRM도 그래서 만들 수 있었고요.

그런데 이번은 정반대였어요. 저는 이 회사를 전혀 모르는 채로, 시스템을 만들러 새로 들어온 사람이었습니다. 회사가 실제로 어떻게 일하는지도, 그 엑셀이 뭔지도 — 입사하고서 처음 봤어요.

그나마 다행은 1편에서 말한 국내외 물류 경험이었어요. 차가 어떻게 들어오고 나가는지, 수출 흐름 자체는 빨리 알아들었죠. 하지만 "이 회사가 실제로 어떻게 굴러가는지"는, 옆에서 직접 보고 물어가며 배워야 했습니다.

---

2 카톡 + 엑셀 + 한 사람의 손

제가 상상한 '회사 시스템'은 그럴듯한 무언가였어요. 그런데 실제로 본 건 그게 아니었습니다.

먼저 그 엑셀. 제가 예전에 다루던 함수 가득한 엑셀이 아니라, 그냥 칸+칸-칸 수준의 덧셈·뺄셈에, 항목만 끝도 없이 많은 — 사실상 '칸이 엄청 많은 텍스트 문서'에 가까웠어요.

더 놀란 건 운영 방식이었습니다.

• [관리]라고 부르는 직원 한 명이 영업 5~10명을 담당해요.
• 영업들이 카톡으로 보내주는 내용을, 관리가 엑셀에 하나하나 수기로 옮겨 적습니다.
• 그 입력의 유일한 출발점이 '메신저'였어요. 카톡으로 와야 시작되고, 안 오면 아무 일도 일어나지 않죠.

정보의 출발점은 '카톡', 저장소는 '엑셀', 처리는 '사람 손' — 그게 회사의 시스템 전부였어요.

---

3 예를 들면, 차 한 대 사 오는 과정

실제 '매입'(차를 사들이는 일)이 어떻게 도는지 보면, 이 구조가 한눈에 들어와요.

영업: 바이어 컨펌→ 카톡으로 관리에게→ 관리: 엑셀 기입 + 매도자 입금→ 영업에 회신→ 영업: 차량 인수

영업이 바이어에게 차량 컨펌을 받으면, 그 내용을 카톡으로 관리에게 넘겨요. 관리는 그걸 엑셀에 옮겨 적고, 차를 파는 사람에게 입금한 뒤, 영업에게 다시 알려주죠. 그럼 영업이 그 차를 가져옵니다.

차 한 대가 움직이는 모든 단계가 카톡으로 오가고, 한 사람이 받아 적는 구조였어요.

---

4 기가 찼던 이유 — 누락·오류가 '예외'가 아니라 '구조'

이 모습을 보고 제가 놀란 건, 일을 못해서가 아니에요. 구조 자체가 사고를 부를 수밖에 없었기 때문이에요.

• 카톡은 흘러가요. 바쁘면 묻히고, 위로 밀려요. 그러니 누락은 운이 아니라 시간문제였어요.
• 한 사람이 5~10명 몫을 다 받아 적으니, 오타·빠뜨림·중복이 안 생기는 게 이상한 거였죠.
• 정산도 그 수기 숫자 위에서 맞추니, 애초에 "정확하다"고 믿기가 어려웠어요.

그래서 인적 오류가 얼마나 숨어 있을지 짐작조차 안 됐어요. 누가 게을러서가 아니라, 그렇게 일하면 누구라도 실수할 수밖에 없는 구조였던 거예요.

---

반응형

5 그래서 — 시스템에 담았다

제가 한 일은 결국, 이 '카톡 + 엑셀 + 사람 손'을 시스템으로 옮기는 거였어요. 핵심은 세 가지였습니다.

이전 — 카톡 + 수기 엑셀

출발점이 흘러가는 메신저. 한 사람이 수기 입력. 같은 숫자를 손으로 여기저기 옮김. 누락·오류가 구조적.

이후 — 시스템

입력은 시스템 안에서. 단계가 빠지면 다음으로 못 넘어감(누락 차단). 한 번 넣은 값을 모든 화면이 공유.

• 출발점을 '카톡'에서 '시스템'으로 — 흘러가 묻히는 메신저 대신, 시스템에 단계별로 기록. 빠진 단계가 있으면 다음으로 못 넘어가게 해서 누락을 원천 차단.
• 같은 숫자는 한 번만 — 사람이 손으로 옮겨 적던 걸 없애고, 한 번 넣은 값을 필요한 화면이 전부 같이 보게(단일 출처). 옮겨 적다 틀릴 일이 사라져요.
• 정산은 규칙으로 자동 — 사람이 머리로 맞추던 정산을, 흐름으로 박았어요.

1차 정산→ 2차 정산(실비 확정)→ 환차 반영→ 다음 달 이월

1편에서 말한 그 흐름이에요. 거래가 끝나면 1차 정산, 한 달쯤 뒤 말소비·탁송비 같은 실비가 확정되면 2차, 거기에 환차까지 반영해서, 남은 차액을 다음 달로 이월. 예전엔 이걸 사람이 일일이 다시 들춰 맞췄지만, 이제는 실비만 넣으면 차액·환차·이월이 알아서 따라옵니다.

※ 정산 계산의 구체적인 계수·비율·세율 같은 실제 숫자는 회사 영업 비밀이라 가립니다. 여기선 '흐름과 왜'만 다뤄요.

솔직히 이 시스템을 제가 한 줄 한 줄 코딩한 건 아니에요. 구현은 AI 팀이 했고, 저는 "이 회사는 이렇게 일하고, 여기서 누락이 나고, 그러니 이 단계는 이렇게 막아야 한다"는 업무의 규칙과 의도를 정했어요. 제 일은 '현장이 돌아가는 방식이 시스템에 제대로 담겼는가'를 검수하는 거였습니다.

---

6 이번 편의 산출물 — 수기·메신저 업무를 시스템으로 옮길 때

카톡과 엑셀로 굴러가던 일을 시스템으로 옮길 때, 제가 실제로 짚었던 기준이에요.

☑ 카톡·수기 업무 → 시스템 이전 체크리스트

☐ 정보의 출발점이 '흘러가는 메신저'인가? → 시스템 안 기록으로 옮긴다

☐ 누락이 생기는 지점이 어디인가? → 단계가 빠지면 다음으로 못 넘어가게 막는다

☐ 같은 숫자를 사람이 손으로 옮겨 적나? → 한 번만 넣고 모두가 같이 보게(단일 출처)

☐ 그 일이 '한 사람'에게만 의존하나? → 규칙으로 박아 누가 해도 같게

☐ 한 번에 안 끝나는 계산(1차·2차·정정)이라면, 그 단계가 흐름으로 들어가 있나?

---

7 AI가 갈린 지점 / 사람이 결정한 지점

🤝 AI는 만들 줄 알지만, '이 회사가 어떻게 도는지'는 몰랐다

이번 편의 핵심: AI 팀은 "시스템을 어떻게 만들지"는 잘 알아요. 하지만 "이 회사는 카톡 한 줄로 차가 움직인다"는 건 코드 어디에도 안 적혀 있어요. 그건 제가 옆에서 보고, 묻고, 물류 경험으로 읽어내서 알려줘야 했습니다.

작은 결정 하나 — 정산액을 저장할까, 매번 계산할까: 미리 저장하면 목록 정렬이 빠르지만, 나중에 환율·비용을 고치면 저장된 값이 옛날 값으로 남아 틀어져요. 매번 계산하면 늘 최신이고요. → 결정은 "평소엔 매번 계산, 거래가 확정되면 그 순간 값을 박제해 잠근다." "우리 회사 돈은 확정되면 안 바뀐다"는 건 코드가 아니라 업무를 아는 사람의 판단이었어요.

그래서: 저는 코드를 짠 사람이 아니라, 흩어진 카톡·수기 엑셀을 '업무 프로세스'로 정리해 시스템에 담은 사람이었어요. 구현은 AI 팀이, 그 그림은 사람이.

---

핵심 한 줄 요약 — 카톡과 엑셀 편

이번 입장10년 다닌 회사(S1)와 달리, 개발하러 새로 와서 처음 본 회사

실제 모습카톡 + 함수 없는 수기 엑셀 + 관리 1명이 영업 5~10명 받아적기

매입 흐름영업 컨펌→카톡→관리 기입·입금→영업 회신→차량 인수

왜 위험누락·인적오류가 '예외'가 아니라 '구조'

해결출발점을 시스템으로 · 누락 차단 · 단일 출처 · 정산 자동(1·2차·환차·이월)

사람의 몫"이 회사가 실제로 어떻게 도는지"를 읽어 규칙으로 옮김

다음 편보안 — 평문으로 둘 뻔한 개인정보를 배포 전에 막다

Tags

#업무자동화 #ERP #엑셀 #메신저관리 #누락방지 #정산 #단일출처 #비개발자 #AI협업 #시스템설계 #웹개발 #티스토리

▼ 티스토리 태그 입력란 복사용

업무자동화, ERP, 엑셀, 메신저관리, 누락방지, 정산, 단일출처, 비개발자, AI협업, 시스템설계, 웹개발, 티스토리