품앗이 위키

무엇을 지을지

25 min read

무엇을 지을지

현장 AX에서 문제를 잘못 잡는 자리

현장 AX에서 무엇을 만들지 정하다가 표적을 잘못 잡았던 자리를 모았습니다. 사례는 품앗이가 함께 일한 의료복지사협·로컬푸드 협동조합·생협 매장 현장에서 나왔고, 조직 이름과 사람 이름, 업체 이름, 금액은 지웠습니다. 일하는 순서 자체는 AX란 무엇인가 4절에, 방향을 경영전략에서 잡는 이야기는 사회연대경제에서 AX의 의미 1절에 있습니다.

요지

현장 AX에서 가장 비싼 실수는 기술이 아니라 표적을 잘못 잡는 데서 나옵니다. 그 조직이 지금 무엇으로 일하는지, 데이터가 어디 있는지, 시간이 어디에 드는지, 왜 그 일을 하려는지를 먼저 재고 나서 무엇을 지을지 정합니다. 재기 전에 설계부터 하면, 상대가 「그건 이미 됩니다」라고 정정해 주는 일이 되풀이됩니다.

1. 병목을 재기 전에는 자동화를 설계하지 않는다

작업 기록에 따르면, 한 의료복지사협 원장이 매달 4~5시간씩 하는 청구 정비를 돕기로 했습니다. 품앗이는 8일 동안 네 번 제안했고 네 번 모두 빗나갔습니다. 심사 기준을 미리 분류해 주겠다고 하자 청구 프로그램이 이미 한다는 답이 왔습니다. 판단을 돕겠다고 하자 판단이 아니라 손이 문제라는 답이 왔고, 나머지 두 번도 같은 모양이었습니다.

나중에 재 보니 4.5시간을 1,800건으로 나누면 건당 9초였습니다. 원장은 복사와 단축키로 이미 최적화를 끝낸 상태였습니다. 9초를 5초로 줄이려고 파일 해석과 화면 매크로를 짜고, 수가가 바뀔 때마다 고치는 비용이 절감보다 컸으니, 처음부터 성립하지 않는 설계였습니다.

  • 「N시간 걸린다」를 들으면 그 N을 쪼개기 전에는 아무것도 설계하지 않습니다. 무엇에 몇 %가 드는지, 건당 몇 초인지부터 셉니다.
  • 건당 시간이 이미 짧으면 병목은 속도가 아니라 건수입니다. 답은 자동화가 아니라 건수를 줄이는 쪽에 있습니다.
  • 상대가 「자동화가 가능한 부분은 이것」이라고 한 말을 「가장 큰 부분」으로 읽지 않습니다. 가능성과 비중은 서로 다른 축이기 때문입니다.
  • 상대가 「그건 이미 하고 있다」를 두 번 말하면 그때는 표적이 아니라 접근 방식이 틀린 것이니 표적만 바꿔 다시 던지지 않습니다. 이 현장에서는 「품앗이가 조사해서 결과를 배달한다」는 방식이 틀렸고, 원장에게는 이미 자기 업무 AI가 있었습니다.

「왜 하려 하시나요」를 먼저 묻습니다. 8일째에 원장이 말한 진짜 목적은 시간 단축이 아니라 「언젠가 나를 대신할 사람의 시스템」, 곧 승계였습니다. 목적이 승계면 만들 물건이 달라집니다. 빠른 도구가 아니라, 그 사람의 판단이 밖에 쌓이는 형태가 필요하고, 그 이야기는 아래 7절에 이어집니다.

2. 1단계의 수확은 있는데 못 쓰던 데이터를 꺼내는 것

현장 기록에 따르면 한 로컬푸드 직매장 협동조합은 신청서와 사전 파악으로는 온라인 채널이 밴드·카톡 채널·블로그뿐이었습니다. 실측하니 전산이 이미 두 겹이었습니다. 매장 판매 프로그램에 96만 행, 5년 9개월치가 매장 PC 안의 데이터베이스에 있었고, 회계 프로그램에 34.7만 행, 12년치가 업체 서버에 있었습니다. 조합이 「우리는 아직 디지털이 아니다」라고 느낀 까닭은 데이터가 없어서가 아니라 스스로 꺼내 볼 수 없어서였습니다.

조직이 쓰는 프로그램마다 세 칸을 잽니다.

칸묻는 것
자리데이터가 우리 기계에 있나, 남의 기계에 있나
출구꺼내는 수단이 있나
구조칸 이름까지 같이 오나

같은 조합 안에서도 이 세 칸은 프로그램마다 갈립니다. 그 조합은 판매가 우리 기계, 회계가 업체 서버였습니다. 업체 화면의 백업 버튼은 데이터만 주고 구조는 주지 않았으니, 「백업했다」와 「우리가 읽을 수 있다」는 다른 칸입니다. 그 회계 프로그램 약관은 「데이터는 이용자 PC에 있으니 보호 책임은 이용자에게」라고 적었지만 실제 데이터는 업체 서버에 있었습니다. 뒤집어 읽으면, 주기적 백업이 이용자 의무로 적혀 있으니 조합이 사본을 쥐는 것은 약관이 요구하는 일입니다.

반복 백업은 실무자 손에 맡기지 않습니다. 그 현장에서는 월 1회 백업 버튼을 챔피언에게 맡길 뻔했습니다. 사람 손 한 번으로 접속 정보를 얻어 매일 자동으로 돌게 바꾸는 쪽이 맞습니다. 유일본을 먼저 확보하는 이유와 방법은 데이터베이스 구축의 의미 3절에 있습니다.

블랙박스 앱에서 우리 데이터를 꺼낼 때는 사람이 보는 화면을 그대로 읽는 길부터 봅니다. 한 의료복지사협 원장이 검진 프로그램에서 날마다 손으로 엑셀을 내려받던 일을 자동으로 바꾸려다가, 품앗이는 한 시간 넘게 설정 파일과 쿠키와 실행 중인 프로그램의 메모리를 뒤졌습니다. 서버가 로그인 정보를 메모리에만 두고 여러 조각으로 묶어 확인했기 때문에 조각을 떼어 재현하는 길은 서버가 막았습니다. 그런데 그 프로그램의 바로가기 실행 인자에 접근성 기능을 켜는 설정이 이미 붙어 있었습니다. 원장이 로그인해 보고 있는 화면의 목록을 접근성 트리로 그대로 읽자 1분에 끝났습니다. 재로그인도, 원장 손도 필요 없었습니다. 그 실행 인자를 먼저 봤다면 한 시간을 아꼈을 것입니다.

3. 지금 무엇으로 일하고 있나가 설계의 출발점이다

새 시스템을 그리기 전에 「지금은 이 일을 무엇으로 하고 있나」를 묻습니다. 자료에 현행 방식이 적혀 있으면 그것이 1순위 후보입니다. 현행이 있다는 사실과 현행이 좋다는 평가는 다른 층입니다. 한 의료복지사협의 외근 원격접속 건에서 품앗이는 이미 기록에 있던 현행 방식을 평가로 탈락시키고 새 설계를 세웠다가 접었습니다. 그 경위는 조직 기계에 원격으로 닿기 5절과 전진배치 개발자 FDE 2절에 있고, 여기에는 거기서 남은 판별 하나만 적습니다. 요구하는 사람이 「바로」, 「그것만 있으면」이라고 말하면 그 사람은 이미 작동하는 것을 보고 있습니다.

「안 쓴다」는 신고를 적응 문제로 듣지 않습니다. 한 생협 매장에서 만들어 둔 발주 화면을 직원이 쓰지 않았고, 설명은 「새 화면에 적응하느니 하던 대로 하는 게 낫다」였습니다. 그 도구의 마지막 기록을 보니 다섯 달 전에 멈춰 있었습니다. 다섯 달 전 코드를 고치다 품목 이름을 엉뚱한 칸에서 읽게 되어 발주 문구가 빈 값이 됐고, 문자·카톡·이메일 버튼이 전부 쓸모없어진 상태였습니다. 발주처 연락처도 52곳 가운데 전화번호가 있는 곳이 한 곳뿐이었습니다. 「적응 부담」은 고장 난 도구를 쓰려다 포기한 경험이 말로 나온 것이었습니다.

  • 그 도구의 마지막 기록일, 마지막 수정, 의존하는 데이터가 채워진 비율부터 봅니다.
  • 사람의 설명이 틀린 것이 아니라 원인의 층이 다를 뿐입니다. 반박하지 말고 데이터로 층을 하나 더 보여 드립니다.

운영 양식의 칸 뜻은 추측하지 않습니다. 매장 일일 결산 화면을 만들며 종이 양식의 「손익금」 칸을 배치와 회계 상식으로 「시재 과부족」이라 짐작하고 자동 계산을 넣었습니다. 실제로는 택배비나 잔돈 기부처럼 판매기에서 나간 돈을 손으로 적는 칸이었습니다. 준비금이 늘 같은 금액이라는 것도 묻지 않고 바꿀 수 있는 입력칸으로 만들어 과부족이 엉뚱하게 나왔습니다. 현장에 물으면 1초면 끝날 일이었습니다.

4. 「누가 관리하나」는 밖에서 보이지 않는다

한 의료복지사협 홈페이지를 넘겨받으며 「업체가 관리했다」는 말 한 줄을 근거로 도메인·메일·네임서버·웹서버 넷을 전부 업체 몫으로 잡고 인계 요청문을 세 판 썼습니다. 확인해 보니 넷 가운데 둘은 업체 손에 있지 않았습니다. 도메인은 업체가 아니라 20년 넘게 한 개인 계정에 그대로 있었고, 메일은 조합 명의 계정이었습니다. 그대로 보냈다면 「우리가 이미 가진 것을 내놓으라」는 문서가 나갈 뻔했습니다.

DNS 조회나 서버 응답 머리글로 알 수 있는 것은 「어떤 서비스가 붙어 있나」까지입니다. 「그 계정을 누가 쥐고 있나」는 밖에서 보이지 않고, 로그인해서 소유자 정보를 봐야 나옵니다. 앞의 것은 기계가 답한 실측이고 뒤의 것은 사람 말 한 줄인데, 둘을 같은 표에 같은 확신으로 적으면 추론이 실측의 신용을 빌려 씁니다.

  • 「관리 주체」 칸은 로그인으로 확인하기 전까지 「미확인」으로 두되, 서비스 이름은 채워도 됩니다.
  • 확인 순서는 소유자 정보 화면, 결제 주체, 관리자 계정입니다.
  • 업체에 보내는 요청문 첫 항을 「아래 가운데 귀사가 관리하시는 것이 무엇인지 알려 주십시오」로 둡니다. 파악한 구성을 그대로 보여 주고 「관리하지 않는 항목은 어디에 물으면 되는지만 알려 달라」를 붙이면, 틀려도 무례가 되지 않고 상대가 목록을 채워 줍니다.

요청문을 누가 보내는지, 무엇을 요청하는지는 도메인 회수와 사이트 직접 관리 4절에 있습니다.

5. 업체 종속의 진짜 벽은 화면이 아니라 규제기관 연동이다

「업체 프로그램을 우리 앱으로 바꾸면 안 되나」를 따질 때 대개 화면·입력·결과 관리를 다시 만드는 비용만 보는데, 그 층은 쌉니다. 앞 절의 검진 프로그램에서 그 층은 화면 읽기로 이미 우리 손에 들어와 있었고, 진짜 벽은 규제기관 연동이었습니다. 국가건강검진은 결과를 공단에 표준 규격으로 보내고 청구해야 하고, 검진기관은 지정과 평가를 받습니다. 업체가 실제로 파는 것은 그 규격을 구현하고, 공단이 규격을 바꿀 때마다 끝없이 따라가며 청구 사고까지 책임지는 일입니다. 한 업체가 이 연동을 진료 프로그램에 무상으로 끼워 주는 것은 그만큼 유지보수 짐이 크다는 방증입니다. 코드 체계가 공공데이터로 공개돼 있어도 벽은 한 번의 개발이 아니라 그 뒤의 영구 추종입니다.

층성격
① 화면·데이터싸고, 우리 것이다
② 규제기관 연동·청구영구 유지보수와 책임이 붙는다
③ 법정 판정·서식기준을 기관이 정한다

셋을 갈라서 잽니다. 현실에서 나은 답은 대개 규제 연동은 업체에 두고, 그 위의 수집·분석·관리·집계 화면을 우리 것으로 쌓는 것입니다. 전송 경로가 어떻게 생겼는지는 공개 문서보다 그 조직이 쥔 실무 계정 화면에 있으니 거기서 확정합니다. 업체 프로그램이 파는 것이 배관이라는 이야기는 앱 뜯어보기, 표·손·망 3절에 있습니다.

업체 프로그램의 품질이 의심되면 소스 열람이나 기술 자료 제출을 계약 조건으로 요청합니다.

6. 옛것을 옮기는 일은 결정 사항이 아니다

한 의료복지사협 홈페이지를 새로 지으며 옛 사이트의 소식지 67건, 견학 신청 폼, 직원용 관리 화면을 「복원할까요」로 결정 대기 목록에 올렸는데, 물을 일이 아니었습니다. 이관 프로젝트에서 옛것을 옮기는 것은 기본값이고, 물을 것은 버릴 이유가 있을 때의 「이건 버릴까요」뿐입니다.

결정 대기 목록이 부풀면 정리된 보고처럼 보이지만, 실은 내 할 일을 상대 책상에 올려놓은 것입니다. 그 목록에는 그날 이미 닫힌 항목도 남아 있었고, 설명 없이 이름만 적힌 항목도 있었습니다. 목록에 올리기 전에 세 가지를 묻습니다.

  1. 내가 가진 것, 곧 계정·사본·데이터로 되는가
  2. 그 항목이 이미 닫히지 않았는가
  3. 상대가 이 항목을 읽고 무엇을 판단할 수 있는가

하나라도 걸리면 그것은 목록이 아니라 내 할 일입니다. 진짜 결정 사항으로 남는 것은 돈이 나가는 일, 대외 관계가 걸린 일, 되돌리기 어려운 일, 그 사람만 아는 사실입니다. 설명하지 못하는 항목은 올리지 않습니다. 초안을 써서 보여 드리는 것이 먼저입니다.

7. 암묵지는 「작업 내내 녹음」이 아니라 「유형당 한 번」

1절의 원장이 바란 승계를 위해, 청구할 때 녹음기를 켜 두고 평소처럼 혼잣말을 해 달라고 설계해 보냈습니다. 원장은 해 보려 했지만 작업이 늦어져 잘 안 됐다고 했습니다. 정밀한 작업 도중에 생각을 소리 내 말하는 방식은 본인이 버리게 됩니다.

그 일이 이미 가진 분류 축을 단위로 삼습니다. 이 현장에서는 청구 프로그램의 사전 점검 메시지 유형이 그 축이었습니다. 유형마다 1~2분씩 한 번 녹음하면, 유형이 20개일 때 토막 20개가 되고 그것이 규칙 후보 20줄이 됩니다. 「왜 그렇게 고치나」가 시스템 자료에 이미 있으면 사람에게 묻지 않습니다. 사전 점검의 지적 사유와 수정 전후 명세서를 건마다 붙이면 「이 사유가 뜨면 이렇게 고친다」가 그대로 규칙이 됩니다. 사람에게 따로 물을 것은 시스템이 잡지 못한 수정뿐입니다.

흐름도를 먼저 그려 보내지 않고 현장 말을 먼저 듣습니다. 그 현장에서는 설계 노트를 하루에 다섯 번 고쳐 보냈습니다. 기록이 어떤 꼴로 남는지, 내보낼 수 있는지, 누가 맡는지 세 가지를 먼저 물었다면 한 번에 끝났을 것입니다. 이렇게 모은 규칙과 사례는 설계 노트 한 장이 아니라 그 조직 위키의 규칙·사례 노드로 쌓습니다. 사람에게 입력 노동을 떠넘기지 않는다는 기준은 사람은 병목이 아니다에 있습니다.

8. 하드웨어 견적은 시장 국면부터

「예산 얼마면 이 AI 모델을 돌릴 컴퓨터를 새 부품으로 조립할 수 있나」라는 질문에 평소 감각으로는 넉넉하다고 답할 만한 예산이었습니다. 2026년 가을에 실측하니 불가능했습니다. 메모리 반도체 회사들이 생산 라인을 AI 서버용 메모리로 돌리면서 소비자용 메모리 값이 평시의 다섯 배를 넘었고, 그래픽카드 하나가 예산을 넘었습니다. 실제 답은 따로 있었는데, 그 모델은 이미 갖고 있던 GPU 서버에서 돌고 있었으니 추가 비용은 0원이었습니다.

하드웨어 구매·조립 견적은 다음 순서로 봅니다.

  1. 시장 국면부터 확인합니다. 공급 충격 구간에서는 같은 예산의 구매력이 몇 배씩 달라집니다.
  2. 이미 있는 기계와 서버로 되는지 확인합니다.
  3. 그래도 모자랄 때 비로소 부품 조합을 짭니다.

공급 충격 구간에서는 「안 사는 것」과 「중고」가 정상 답안입니다. 신품 조건을 기계적으로 지키면 오히려 손해입니다. 여러 조직이 한 대를 같이 쓰자는 제안은 공동 AI 서버 제안에 있습니다.

일곱 줄로 줄이면

  1. 「N시간 걸린다」는 건당 몇 초인지로 쪼갠 뒤에 설계한다.
  2. 「무엇을 줄이고 싶으신가요」보다 「왜 하려 하시나요」를 먼저 묻는다.
  3. 프로그램마다 데이터의 자리·출구·구조 세 칸을 잰다.
  4. 「안 쓴다」는 신고는 그 도구의 마지막 기록일부터 본다.
  5. 「누가 관리하나」는 로그인으로 확인하기 전까지 「미확인」이다.
  6. 업체를 갈아 치울지 따지기 전에 규제기관 연동 층을 따로 잰다.
  7. 옮기는 일은 묻지 않고 하고, 묻는 것은 버릴 때뿐이다.

관련 노드

작성: 품앗이 · 2026-10-22 · 의료복지사협·로컬푸드 협동조합·생협 매장 현장 기록 기준

그래프 뷰

백링크