현장이 있는 사람이 업무 도구를 직접 만들면

팀원이 녹음 파일을 올렸습니다. 분석 결과가 나왔는데 이름 옆 점수가 이상해요. 내용을 따라가 보니 다른 사람이 쓰던 공용 계정으로 들어간 기록이 섞여 있었습니다.

화면은 정상이에요. 업로드도 성공했고 결과표도 나왔고요. 그런데 그 점수로 누군가에게 피드백을 하면 엉뚱한 사람을 고치게 됩니다.

도구를 소개하는 화면에는 이런 장면이 잘 안 나와요. "업로드하고 분석 결과를 확인하세요"라고 쓰면 충분해 보이니까요. 현장에서는 파일을 누가 올리는지, 계정이 없는 사람의 기록은 어디로 가는지, 실패한 분석을 누가 다시 돌리는지가 제품의 일부입니다.

현장을 아는 사람이 도구를 직접 만들면 제일 먼저 얻는 건 개발 속도가 아니었어요. 기능 이름 뒤에 숨어 있던 운영 장면을 더 이상 남의 일처럼 넘길 수 없다는 것이었습니다.

저도 처음에는 직접 만들면 우리 방식에 딱 맞는 도구가 생길 거라고 생각했어요. 실제로는 우리 방식의 좋은 점뿐 아니라 임시방편과 구멍까지 같이 보였습니다. 그게 직접 만드는 일의 진짜 장점이면서 가장 불편한 부분이었어요.

현장의 말이 기능 이름으로 번역됩니다

현장에서는 "결과가 이상해요", "자꾸 안 열려요", "직원들이 안 써요" 같은 말이 옵니다. 외부에서 들으면 하나의 오류처럼 보여요. 직접 쓰는 사람은 그 앞뒤를 더 물을 수 있습니다.

누가 어떤 기기에서 했는지, 바로 전에 계정을 바꿨는지, 실패한 뒤 다시 눌렀는지, 일이 바쁜 시간에도 같은 절차를 지킬 수 있는지 봐요. 그러면 "분석 정확도를 높인다"보다 "공용 계정으로 들어가지 않게 한다"가 먼저일 수 있습니다. "알림을 더 보낸다"보다 앱을 열지 않아도 오늘 할 일이 보여야 할 수 있고요.

그러면서 번역이 짧아져요. "사용률이 낮아요"라는 말이 "업무가 시작되는 순간에는 휴대폰을 꺼낼 수 없어서, 앱을 나중에 열겠다고 미뤄요"로 바뀝니다. 이제 기능을 고를 수 있어요. 교육을 더 할지, 입력 단계를 줄일지, 다른 화면에 정보를 보낼지 판단할 수 있으니까요.

개발을 모르는 사람이 앱을 만들기로 한 이유도 기술을 직접 다 하겠다는 선언보다 이 번역을 놓치지 않기 위한 선택에 가깝습니다. 현장 문장을 제품 문장으로 옮길 사람이 필요했어요.

완료와 복구가 다른 일이라는 걸 보게 돼요

도구를 만들 때는 새 기능이 정상 작동하면 완료라고 말하기 쉽습니다. 현장에서는 그전에 실패한 일이 그대로 남아 있는데도요.

업로드 오류를 고쳐도 어제 실패한 파일이 자동으로 성공하지는 않아요. 계정 구조를 바로잡아도 이미 다른 사람에게 섞인 기록은 분리해야 하고요. 알림 오류를 고쳐도 놓친 약속은 다시 잡아야 합니다.

직접 쓰면 배포와 복구를 한 문장으로 묶기 어려워져요. 그래서 작업을 요청할 때 둘을 따로 적습니다.

• 앞으로 같은 문제가 생기지 않게 하는 일
• 이미 잘못된 상태를 찾아 되돌리는 일

첫 번째만 끝내면 개발은 완료처럼 보여도 운영은 안 끝나요. 두 번째만 하면 오늘은 조용하지만 내일 다시 생기고요. 둘 다 있어야 합니다.

이 구분은 기획서에 완료 기준을 쓰는 법과 이어져요. "고쳤다"가 아니라 새 기록과 이전 기록이 각각 어떻게 보여야 하는지를 적어야 합니다.

기록이 사람 평가에서 과정 대화로 옮겨 갑니다

도구가 없을 때는 피드백이 인상으로 흐르기 쉬워요.

"요즘 응대가 예전 같지 않아요."

받는 사람은 자기 전체가 평가받았다고 느낍니다. 무엇을 바꿔야 할지도 모호하고요.

기록이 있으면 한 장면을 고를 수 있어요.

"이번 대화에서는 손님이 고민을 말한 뒤 바로 상품 설명으로 넘어갔어요. 다음에는 그 고민을 한 번 확인하고 설명을 붙여 볼까요?"

도구가 사람을 더 정확히 평가해서가 아닙니다. 같은 장면으로 돌아갈 수 있게 해줘서예요. 데이터로 직원을 코칭하는 법과 직원 상담 품질을 관리하는 법은 점수를 줄 세우는 방법보다 이 대화를 만드는 방법에 가깝습니다.

다만 기록이 생겼다고 자동으로 공정해지지는 않아요. 계정이 섞이거나, 표본이 적거나, 기록되지 않은 일이 많으면 숫자도 거짓말을 합니다. 현장을 아는 사람은 "이 점수가 누구의 어떤 상황에서 나왔는가"를 의심해야 해요.

낭만을 걷어내면 남는 이야기들

현장 사람이 직접 만든다는 말에는 낭만이 붙기 쉽습니다. 필요한 것을 가장 잘 아니까 좋은 제품이 저절로 나올 것처럼 보이거든요. 제가 겪은 건 더 복잡했어요.

"현장을 잘 알면 좋은 도구를 만들 수밖에 없다." 현장 지식은 강합니다. 사용자가 어느 순간 귀찮아하고, 어떤 말로 문제를 설명하며, 실패 뒤 무엇을 하는지 빨리 볼 수 있으니까요. 하지만 익숙함은 맹점도 만들어요. 우리 팀이 늘 해온 임시 절차를 당연한 것으로 넣고, 새 사용자는 모르는 내부 용어를 화면에 쓰고, 교육하면 된다고 생각하게 됩니다. 그래서 현장 지식은 정답이 아니라 가설의 출발점으로 써야 해요. 내가 잘 아는 장면을 적되, 처음 쓰는 사람이 같은 흐름을 이해하는지 봐야 합니다. 반대로 현장을 모르는 사람이 만들 수 없다는 뜻도 아니에요. 관찰하고 질문하고 실제 사용 장면을 검증하면 배울 수 있습니다. 거리는 불리함이지만, 익숙함에 묻힌 전제를 발견하는 장점도 있고요.

"직접 만들면 외주보다 싸고 빠르다." 구매 비용이나 전달 시간을 줄일 수는 있어요. 작은 수정을 바로 해볼 수 있고요. 하지만 만드는 시간이 공짜는 아닙니다. 본래 해야 할 일을 미루고 밤마다 오류를 확인한다면 비용이 다른 장부로 옮겨갔을 뿐이에요. 결제, 문의 대응, 장애 복구, 사용 안내까지 운영 부담도 생기고요. 저는 직접 만들기의 가치를 무조건 싼 선택으로 보지 않습니다. 시장에 있는 도구로 중요한 장면이 해결된다면 사서 쓰는 편이 나아요. 직접 만들어야만 얻는 차이가 무엇인지 분명할 때 선택해야 합니다. 사장님을 위한 AI 활용법도 모든 것을 만들자는 이야기가 아니에요. 반복과 초안을 맡기되, 실제로 아픈 문제부터 고르자는 이야기입니다.

"내가 사용자니까 사용자 조사는 필요 없다." 내가 겪는 문제를 가장 자세히 알 수는 있어요. 초기 제품을 시작하기 좋은 조건입니다. 하지만 나는 한 사람이에요. 도구를 익히는 속도, 쓰는 기기, 실수를 두려워하는 정도가 다른 사람과 같지 않습니다. 만든 사람은 버튼이 어디 있는지 이미 알고 있어서 처음 쓰는 사람의 멈춤을 못 보고요. 내가 사용자라는 사실은 조사 대상이 하나 이미 있다는 뜻이지, 모든 사용자를 대표한다는 뜻이 아니에요. 옆에서 실제로 쓰는 모습을 보고 설명 없이 멈추는 자리를 기록해야 합니다.

"직접 만든 도구는 우리 방식에 정확히 맞아야 한다." 처음에는 맞는 말처럼 들려요. 그런데 모든 예외를 그대로 기능으로 넣으면 도구가 우리 조직의 복사본이 됩니다. 오래된 승인 단계, 중복 입력, 사람마다 다른 표현까지 제품에 굳어버려요. 도구를 만들 때는 현장을 반영하는 일과 현장을 고치는 일을 나눠야 합니다. 정말 필요한 차이인지, 아직 정리하지 못한 운영 문제인지 물어보세요. 기능으로 덮기 전에 과정을 줄일 수 있는지도 보고요. 직접 만드는 사람의 가장 큰 권한은 추가보다 삭제일지 모릅니다. 접은 기능과 그 이유를 남기면 "할 수 있지만 하지 않은 것"이 판단으로 남아요.

현장의 문제를 제품 요구로 바꾸는 순서

먼저 불만을 그대로 적어요. "안 써요", "결과가 이상해요", "너무 번거로워요" 같은 말이요.

그다음 마지막으로 일이 정상적이었던 지점을 찾습니다. 로그인까지 됐는지, 파일 선택까지 갔는지, 결과를 본 뒤 멈췄는지. 사람의 태도를 추측하기 전에 행동이 끊긴 자리를 찾는 거예요.

이후 임시방편을 적어요. 다른 계정을 빌렸는지, 메신저로 대신 보냈는지, 종이에 적어 뒀는지. 임시방편은 기능 아이디어이기도 하지만 운영 위험의 신호이기도 합니다.

마지막으로 도구가 해결할 것과 운영이 해결할 것을 나눠요. 계정 생성이 늦는다면 버튼을 더 만드는 것보다 계정을 누가 언제 준비할지 정하는 일이 먼저일 수 있어요. 화면이 복잡하다면 교육보다 입력을 줄이는 쪽이 먼저일 수 있고요.

"이 기능이 생기면 누가 어떤 행동을 안 해도 되나요?"

이 질문에 답하기 어려우면 멋진 기능일 수는 있어도 현장 문제와는 거리가 있습니다.

기능을 고친 뒤에는 원래 불만을 말한 사람에게 다시 가져가세요. 만든 사람이 대신 눌러 주지 않고, 아무 설명 없이 같은 일을 해보게 합니다. 멈추면 사용자가 서툰 게 아니라 요구로 번역되지 않은 장면이 남은 거예요. 반대로 문제없이 끝나도 며칠 뒤 바쁜 시간에 다시 쓰는지 봐야 하고요. 조용한 시연에서 되는 것과 업무 중에 살아남는 건 다르니까요.

"직접 만든다"를 지나치게 넓히지 않으려면

사장이 모든 코드를 직접 만져야 한다는 뜻은 아닙니다. 문제 장면을 적고, 우선순위를 고르고, 결과를 확인하는 것도 만드는 일에 포함돼요. AI나 개발자에게 구현을 맡겨도 현장의 판단을 놓치지 않을 수 있습니다.

반대로 화면을 직접 만들었다고 제품의 안전까지 이해했다는 뜻도 아니에요. 돈과 개인정보, 권한, 외부 정책처럼 실패 비용이 큰 영역은 현장 감각만으로 승인하면 안 됩니다. AI에게 맡기면 안 되는 판단에서 다룬 것처럼 공식 기준과 별도 검토가 필요해요.

직접 만들기의 목표도 "내가 원하는 모든 것"이 되면 끝이 없어요. 현장에 있는 문제 하나가 실제로 줄었는지 확인해야 합니다. 업로드 실패가 줄었는지, 공용 계정이 사라졌는지, 피드백 문장이 장면 중심으로 바뀌었는지 봐요.

도구가 우리 일을 닮는 것만으로는 부족합니다. 우리 일이 어디서 꼬이는지 드러내고, 그 꼬임을 조금 줄여야 해요.

자주 묻는 질문

코딩을 몰라도 직접 만든다고 말할 수 있나요?

그럴 수 있어요. 해결할 장면과 완료 기준을 정하고, AI나 개발자가 만든 결과를 실제 흐름으로 검수한다면 제품 판단을 직접 하는 겁니다. 코드를 모두 쓰는 일과 제품을 만드는 일은 같지 않아요.

현장 직원이 기능을 계속 요청하면 전부 넣어야 하나요?

요청 뒤의 막힘을 먼저 보세요. 기능이 없어 생긴 문제인지, 권한과 절차가 불명확해서 생긴 문제인지 나눠야 합니다. 같은 문제를 줄이는 더 작은 방법이 있다면 그쪽을 먼저 시험해도 돼요.

우리 조직에 맞춘 도구가 다른 곳에서도 쓸 수 있을까요?

바로 일반화하면 위험합니다. 내부 용어와 임시방편을 걷어내고, 다른 곳에서도 반복되는 문제 장면이 무엇인지 확인해야 해요. 우리 방식의 복사본이 아니라 문제의 원리를 남겼을 때 범용성이 생깁니다.