아이디를 줬더니
5편에서 직원한테 아이디를 줬다고 했다.
그 다음 날, 직원이 실제로 로그인하는 걸 옆에서 봤다.
내가 몇 달을 만든 화면이 나오는데, 이상하게 내가 더 긴장됐다. 직원은 가볍게 이것저것 눌러보는데 나는 옆에서 숨을 죽이고 있었다.
반응은 담담했다. "아, 되네요." 정도.
그런데 그 담담함이 오히려 좋았다. 대단하다는 반응보다 "되네요"가 실제로 쓸 수 있다는 뜻이니까.
쓰게 만드는 건 다른 문제다
문제는 그다음이었다.
아이디를 줬다고 해서 직원이 매일 들어와서 쓰는 건 아니다. 나는 사업주니까 "이거 써라" 하면 쓰긴 한다. 근데 그건 강제지, 자발이 아니다.
강제로 쓰게 하는 건 쉽다. 내가 사장이니까.
그런데 쓰고 싶게 만드는 건 완전히 다른 문제다.
클릭이 많으면 안 쓴다. 화면 이동이 잦으면 안 쓴다. PC 앞에 앉아야만 할 수 있으면 더 안 쓴다. 현장 직원은 돌아다니면서 일하는데, 앉아서 입력하라는 건 업무를 하나 더 얹는 거다.
결국 핸드폰에서 최대한 많은 걸 할 수 있게 만들어야 한다는 결론에 도달했다. PIN 번호만 누르면 로그인되고, 화면 하나에서 대부분의 일이 끝나는 구조.
내 머릿속과 현실은 다르다
나는 이 병원의 원장이고, 행정도 나름 안다고 생각했다.
근데 실제 직원 동선을 따라가 보면, 내가 만든 로직이 안 맞는 경우가 있었다.
물품 요청함이 대표적이었다.
나는 이런 흐름을 만들었다. 직원이 물품을 요청하면 내가 허락을 하고, 구매를 하고, 구매 완료를 누르는 3단계 프로세스.
그런데 실제로는? 내가 허락만 누르면 끝이었다. 구매는 어차피 사무장이 알아서 하고, 완료 확인까지 시스템에서 할 필요가 없었다.
3단계를 만들었는데 1단계만 쓰이는 거다.
재고관리도 비슷했다. 약품마다 유통기한 관리 수준을 나누는 Tier라는 걸 만들었는데, 내가 생각한 관리 단위와 실제 직원이 처리하는 단위가 달랐다. 머릿속에서는 깔끔하게 떨어지는 구조였는데 현장에서는 미세하게 안 맞는 거다.
그런데 웃긴 건, 이렇게 데이터를 만지작거리다 보니 2월에 있었던 주문 실수가 발견됐다. 시스템 없었으면 그냥 묻혔을 건데, 재고 수량이 안 맞아서 찾아보니 나온 거다. 의도하지 않은 순기능이었다.
아, 내가 생각한 "있으면 좋겠다"와 현장에서 "실제로 쓰는 것"은 다르구나.
이런 게 한두 개가 아니었다. 나는 도메인 전문가라서 행정을 안다고 생각했지만, 실제로 행정을 하는 사람은 내가 아니었다. 그 미세한 차이를 하나하나 조정해 가는 중이다.
엑셀은 끝나지 않는다
5편에서 엑셀 한 번 터졌다고 했는데, 그게 끝이 아니었다.
엑셀 파서 라이브러리 자체가 공통적으로 문제를 일으켰다. 한 라이브러리 쓰다가 안 돼서 바꾸고, 그것도 Windows 엑셀이랑 호환이 안 돼서 또 바꾸고.
그리고 더 근본적인 문제가 있었다. EMR마다 엑셀 형식이 다르다는 거다. 우리 병원 EMR이 뱉는 엑셀과 다른 병원 EMR이 뱉는 엑셀은 컬럼 순서도 다르고, 이름도 다르고, 날짜 형식도 다르다.
SaaS면 여러 병원이 쓸 텐데, 병원마다 엑셀을 따로 맞춰줄 수는 없는 노릇이다.
그래서 방식을 바꿨다. 엑셀에 있는 글자를 먼저 규칙으로 자동 인식하고, 그래도 못 찾으면 LLM한테 넘기는 구조로.
약품명이 여기 있는 것 같은데? 하고 AI가 알아서 찾아준다.
이렇게 바꾸니 EMR 형식이 달라도 대부분 알아서 매칭됐다. 이건 솔직히 좀 뿌듯했다.
소름 끼치는 순간이 있었다
운영 중에 한 번 등골이 서늘해진 적이 있다.
클로드 코드가 만든 코드의 테넌트 관리가 약하다는 걸 알게 됐다. 테넌트라는 건 쉽게 말해 "A병원 데이터는 A병원만 봐야 하고, B병원 데이터는 B병원만 봐야 한다"는 격리 구조다.
그래서 OpenAI의 Codex라는 도구로 교차 검증을 해봤다. 클로드가 만든 코드를 다른 AI한테 "이거 보안 구멍 없어?" 하고 검사시킨 거다.
결과가 안 좋았다. 격리가 미흡한 코드가 여러 군데서 발견됐다.
의료 데이터를 다루는 시스템이다. 격리가 미흡하다는 건 "좀 불편하다" 수준이 아니라 사고로 이어질 수 있는 문제다.
전체 코드를 다 검수하는 데 꽤 오랜 시간이 걸렸다. 기능 만들 시간에 보안 구멍을 메우고 있으니 진도는 안 나가고, 하지만 이건 건너뛸 수 있는 게 아니었다.
바이브 코딩으로 빠르게 만드는 건 좋은데, AI가 만든 코드를 그냥 믿으면 안 된다는 걸 이때 확실히 깨달았다. AI끼리 교차 검증하는 것도 방법이다.
안정화되니 또 만들고 싶어진다
보안도 잡고, 직원 피드백도 반영하고, 엑셀도 고치고. 운영이 조금씩 안정화되기 시작했다.
그러니까 또 다른 게 하고 싶어진다.
환자 정보를 수집하고 싶어졌다. 어떤 환자가 언제 왔고, 무슨 치료를 받았는지. 이걸 쌓으면 재방문 패턴이 보일 거고, 그러면 마케팅도 할 수 있고, 환자 관리도 더 잘할 수 있다.
그래서 새 모듈을 만들기 시작했다. 운영 안정화와 신규 개발을 동시에 하는 거다.
이거 욕심인가?
솔직히 모르겠다. 운영만 하고 있으면 지루하고, 새로 만들고 있으면 운영이 불안하고. 이 균형을 어떻게 잡는 건지 아직 답을 못 찾았다.
만드는 것과 쓰게 하는 것
5편까지는 "만드는 이야기"였다.
6편부터는 "쓰게 하는 이야기"다.
만드는 건 나 혼자 밤새면 됐다. 근데 쓰게 하는 건 다른 사람의 습관과 동선을 이해해야 한다. 내가 좋다고 생각한 프로세스가 현장에서는 과잉이고, 내가 별거 아니라고 생각한 클릭 한 번이 직원한테는 귀찮음이다.
코드를 짜는 시간보다 옆에서 지켜보는 시간이 더 중요해지기 시작했다.
다음 편에서 계속.