1편 — 비개발자가 첫 업무 시스템을 기획할 때 부딪히는 '벽'

 

 

Dev Story · 1편 — 기획의 벽

현장의 일은 머릿속에 다 있는데,
왜 '화면'으로는 안 옮겨질까

비개발자가 첫 업무 시스템을 기획할 때 부딪히는 벽 — 그리고 넘는 법

인트로에서 말씀드린 그 첫 시스템(현장 CRM) 이야기를 시작합니다. 현장 일은 10년째 손에 익어 눈 감고도 하는데, 막상 "이걸 시스템으로 만들자" 하니 첫 줄부터 막혔습니다.

1 다 아는데, 어디서부터 손대지?

저는 고가 장비 AS/CS와 물류 현장에서 일했습니다. 접수를 받고, 점검·수리를 맡기고, 부품을 갈고, 발송하고, 입금을 확인하고 — 이 흐름은 머릿속에 사진처럼 박혀 있습니다.

사실 저는 개발을 아예 모르던 사람은 아니었습니다. 프로그래밍 언어를 1년 6개월 공부했거든요. 그런데 그 시작부터가 만만치 않았습니다.

처음 6개월은 학원을 다녔는데, 좀 황당한 일이 반복됐어요. 2개월짜리 기초반을 다 들으면 그 반이 없어지고, 다른 언어 기초반을 또 2개월 듣고 나면 그 반도 없어지고. 그러더니 "이 정도면 중급반 가셔도 돼요" 해서 얼떨결에 올라간 중급반마저 사라졌습니다. 배움은 매번 처음으로 리셋되는데, 결제는 1년 치가 되어 있었죠.

학원비, 작은 돈 아니잖아요. 들인 시간은 더하고요. 그래서 따졌습니다. "처음 기초 2개월은 제대로 배운 걸로 치겠습니다. 그런데 나머지는 같은 걸 반복한 것뿐이지 않습니까. 그 2개월만 빼고 환불해 주세요." — 제가 CS로만 10년을 먹고산 사람입니다. 소비자보호법, 제가 좀 알죠. 결국 받아냈습니다.

그리고 남은 1년은 혼자 독학했습니다. 어설프게가 아니라 작정하고요 — HTML·CSS로 시작해 jQuery, PHP, MySQL, 자바스크립트, 부트스트랩까지. 폴더로 백 개가 넘는 분량을 "뼈대 외워야 한다, 월천 벌자" 되뇌며 갈아 넣었습니다. 그렇게 혼자 프론트부터 백엔드까지 훑고 나니, '언어'는 어느 정도 익혀지더라고요 — 정확히는 "아, 이게 이거구나" 하고 감을 잡은 정도까지요.

그런데 — 그렇게 다 배우고도, "직접 시스템으로 만들어보자"고 빈 화면을 켠 순간 손이 멈췄습니다. 일은 다 아는데, 그 일을 '화면'과 '데이터'로 옮기는 법을 모르겠더라고요. 코드를 어디서부터 쳐야 하는지도 막막했고요. 이게 비개발자가 만나는 첫 번째 벽입니다. 업무 지식이 부족해서가 아니라, 업무를 시스템의 언어로 번역하는 법을 모르는 거죠.

---

2 첫 번째 함정 — "엑셀을 그대로 옮기면 되지 않나?"

제가 가장 먼저 한 생각은 이거였습니다. "지금 쓰는 엑셀을 그대로 화면으로 만들면 되겠네." 그래서 엑셀의 칸을 하나하나 입력 칸으로 베끼기 시작했습니다. 그리고 금방 무너졌습니다.

엑셀은 자유롭고, 시스템은 구조를 요구합니다. 엑셀에선 한 칸에 "그 차 부품 없어서 보류, 사장님 통화함"이라고 막 적어도 됩니다. 시스템은 그걸 못 받아요 — "보류"는 상태인지, "부품 없음"은 사유인지, "통화함"은 기록인지 나눠줘야 합니다.

엑셀을 그대로 옮기려는 시도는, 사실 "정리되지 않은 머릿속을 그대로 옮기려는" 시도였습니다. 그게 안 되니 막막했던 거죠.

---

3 두 번째 함정 — 한 덩어리로 엉킨 정보

접수 한 건을 떠올려 보면, 그 안엔 너무 많은 게 엉켜 있습니다.

접수 1건 ├─ 누가 맡겼나 (고객) ├─ 무슨 장비인가 (장비) ├─ 증상이 뭔가 (분류) ├─ 어떤 부품을 썼나 (부품) ├─ 누가 처리하나 (담당자) └─ 지금 어디까지 왔나 (상태)

현장에선 이걸 한 줄에 다 적습니다. 그런데 시스템에선 "고객"과 "장비"와 "부품"이 각각 따로 살아야 합니다. 같은 고객이 또 맡길 수도, 같은 부품이 여러 건에 쓰일 수도 있으니까요. 한 덩어리를 어떻게 쪼개야 하는가 — 이게 두 번째 벽이었습니다.

---

4 AI와 함께 — 큰 '업무 흐름'(뼈대)부터 그리다

여기서 AI를 쓰기 시작했습니다. 코드를 짜달라고 한 게 아니라, 제 현장 일을 처음부터 끝까지 '흐름'으로 풀어서 설명했습니다. 한 건이 어떻게 들어와서 어떻게 끝나는지를요. 실제로 이렇게 적었습니다.

고객 문제 발생 → CS 연결 → 접수 → 택배 → 도착 → 물류에서 접수 처리 → AS 엔지니어 배당 → AS(점검·수리) → 유/무상 판단 → 고객 안내 → 입금 → 입금 확인 → 제품 발송

이렇게 전체 흐름(뼈대)을 쭉 세우고 나니, 막막함이 풀렸습니다. 화면이 저절로 이 순서대로 정리됐거든요. 그다음엔 각 단계에 곁가지를 붙였습니다 — "부품이 없으면?", "무상 보증이면?", "고객이 수리를 거절하면?" 같은 예외들이요.

기능(버튼·화면)부터 그리지 말고, 일이 흘러가는 큰 줄기(뼈대)부터. 곁가지는 그 다음에.

저는 처음에 "무슨 버튼, 무슨 화면"부터 생각하느라 막혔던 건데, 시작점은 일의 흐름이었던 겁니다. AI는 이 흐름을 같이 정리해 주고, 제가 빠뜨린 곁가지를 되물어 준 팀이었고요.

---

반응형

5 벽을 넘은 세 가지 도구

막막함을 풀어준 건 거창한 기술이 아니라, 세 가지 단순한 관점이었습니다.

• ① 업무 흐름(뼈대)을 먼저 한 줄로 — 곁가지는 나중에 — 위처럼 "문제 발생 → … → 발송"을 쭉 세우고, 예외는 곁가지로 붙입니다. 큰 줄기가 서면 화면이 그 순서대로 정리됩니다.
• ② '저장할 것'과 '할 일'을 나눈다 — 계속 두고 쓰는 것(고객·장비·부품)은 데이터로 저장하고, 한 번씩 일어나는 일(접수한다·수리한다·발송한다)은 행동(버튼·기능)으로 만듭니다. 엉킨 한 덩어리가 이 둘로 갈리면 쪼개집니다.
• ③ "누가 보나"로 화면을 나눈다 — 같은 정보라도 접수 담당과 수리 담당이 볼 화면은 다릅니다. 이 관점이 나중에 역할별 화면 · 엑셀 보고서 없애기로 이어집니다(인트로에서 말한 그 핵심이요).

결국 기획의 벽은 "내가 머릿속에 뭉쳐 놓은 일"을 업무 흐름(뼈대) · 저장할 것과 할 일 · 보는 사람으로 풀어내는 작업이었습니다. AI는 답을 준 게 아니라, 제가 아는 걸 꺼내 정리하도록 질문해 준 팀이었고요.

---

6 이번 편의 산출물 — 기획 체크리스트

비개발자가 처음 업무 시스템을 기획할 때, 막히면 이 다섯 가지를 점검해 보세요. 제가 벽을 넘을 때 쓴 그대로입니다.

☑ 첫 업무 시스템 기획 체크리스트

☐ 업무 한 건의 업무 흐름(시작 → 끝, 뼈대)을 한 줄로 그렸는가?

☐ 저장할 것(데이터)과 할 일(행동)을 따로 적어봤는가?

☐ 그 화면을 누가 보는지(역할)를 정했는가?

☐ 혹시 엑셀을 '그대로' 옮기려 하고 있진 않은가?

☐ 한 번에 다 말고, 현장이 진짜 매일 쓰는 최소 범위부터 시작하는가?

---

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

🤝 이번 편의 결정

AI가 권한 것: "이왕 만들 거면 처음부터 확장 가능한 완전한 데이터 구조를 잡으세요." — 나중에 고생 안 하려면 지금 제대로.

사람이 결정한 것: 저는 "현장이 당장 매일 쓰는 최소부터"를 택했습니다. 완벽한 구조를 먼저 그리다간 첫 화면도 못 띄우고 지칠 게 뻔했거든요. 쓰면서 키우기로.

왜: 1인 개발에선 '완성도'보다 '일단 굴러가서 피드백을 받는 것'이 먼저였습니다. (이 선택이 훗날 어떤 빚을 남겼는지는 다음 편들에서 솔직히 풀어볼게요.)

---

핵심 한 줄 요약

기획의 벽업무는 아는데, 그걸 화면·데이터로 '번역'하는 법을 모르는 것

함정 1엑셀을 그대로 옮기려는 시도 (구조 없는 정보)

함정 2한 덩어리로 엉킨 정보를 못 쪼갬

돌파구업무 흐름(뼈대) · 저장할 것과 할 일 · 누가 보나

AI의 역할답이 아니라, 아는 걸 꺼내 정리하게 한 질문

다음 글2편 — 하드코딩 탈출(공통코드), 손으로 박은 값들의 역습

Tags

#기획 #업무시스템 #비개발자 #요구사항분석 #데이터모델링 #CRM #현장경험 #AI협업 #업무흐름 #업무자동화 #웹개발 #티스토리

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

기획, 업무시스템, 비개발자, 요구사항분석, 데이터모델링, CRM, 현장경험, AI협업, 업무흐름, 업무자동화, 웹개발, 티스토리