저는 개발자가 아니지만 AI에게 실제 내부 도구 구축을 지시했습니다

몇 달 전 저는 앉아서 망가진 프로세스를 AI에게 조각조각 설명했고, 마침내 더 이상 망가지지 않게 만들었습니다. 저는 개발자가 아닙니다. 문서를 읽지도 않았습니다. 단지 실제로 작동할 때까지 멈추기를 거부했을 뿐입니다. 이것은 그 프로세스에 대한 이야기이며, 그것이 무엇을 대체했는지, 구축하는 데 무엇이 필요했는지, 그리고 최종 버전보다 더 좋게 만든 세 번의 실패 경험에 관한 것입니다.

문제점

제 업무 중 일부는 정기적으로 여러 사람 그룹으로부터 동일한 종류의 반복적인 정보를 수집하여, 승인을 위해 다른 곳으로 가야 하는 완성된 문서로 만드는 것을 포함합니다. 경비 보고서와 비슷한 것이라고 생각해보세요. 모두가 무언가를 작성하고 지출 증빙 자료를 첨부하며, 이 모든 것은 일관되고 완전한 형식으로 도착해야 합니다. 누군가가 손으로 정리할 필요가 있는 다섯 가지 약간 다른 버전이 아니어야 합니다.

그 '누군가'는 바로 저였습니다.

모두가 돕고 싶어 했지만, 일관된 형식이 없었기 때문에 각 사람의 정보는 조금씩 달랐습니다. 모든 제출물에는 수정해야 할 것이 2~3가지 있었습니다. 때로는 정보를 요청하는 왕래 이메일 체인을 거치며 응답을 기다리기도 했습니다.

첫 번째 해결책은 간단했습니다. 적어도 모두의 제출물을 일관된 형태로 받고 자동으로 저에게 이메일을 보내는 기본적인 온라인 양식이었습니다. 이것만으로도 제가 처리하는 시간을 약 절반에서 3분의 2까지 줄였습니다. 그것은 실제적인 개선이었습니다. 하지만 여기에는 명확한 한계가 있었습니다. 정보를 수집할 수는 있었지만, '생각'할 수는 없었습니다. 누군가가 제출한 것을 보고 실제로 완전한지 판단할 수 없었습니다. 아무것도 조립할 수 없었습니다. 그저 약간 더 정리된 원자재 더미를 저에게 건네주었고, 저는 여전히 나머지를 손으로 처리해야 했습니다.

제가 그냥 기성품을 사지 않은 이유

이러한 조합—무료이고 이미 신뢰할 수 있으며 새로운 가입자가 필요 없는—은 조직이 이미 사용하고 있는 Workspace/Office 생태계 내부에 무언가를 맞춤 구축하는 방향으로 이끌었고, 새로운 제품을 채택하기보다는 그렇게 했습니다.

실제로 어떻게 구축되었는지

솔직히 말씀드리고 싶은 부분이 있습니다. 왜냐하면 화려하게 들리는 버전보다 솔직한 버전이 다른 비개발자들에게 더 유용하다고 생각하기 때문입니다. 저는 코딩을 독학하지 않았습니다. AI 어시스턴트와 함께 앉아 문제를 설명했습니다. 제출하는 사람들이 무엇을 필요로 하는지, 최종 결과물이 어떻게 보여야 하는지, 기존 프로세스의 어떤 부분이 문제가 있었는지 등을 말했고, 우리는 그 과정 전체에 걸쳐 실제 제출물에 대조하며 조각조각 함께 구축해 나갔습니다.

그 과정에서 제 역할은 구문을 작성하는 것이 아니었습니다. '완료'가 실제로 무엇을 의미하는지 끊임없이 명확하게 유지하고, 기술적으로는 작동하지만 실제 문제를 해결하지 못하는 답변은 거부하는 것이었습니다.

제 문제는 컴퓨터에게 소리치고 싶을 때도 있었습니다. 왜냐하면 그것이 제 문제를 해결하지 못하거나, 혹은 해결하긴 했지만 저희 사용자들이 접근하거나 정보를 입력할 수 없는 방식으로만 해결하기 때문이었습니다.

여기가 바로 저의 문제 해결 능력이 시험대에 오르고 극한까지 확장된 부분입니다.

여기서 중요한 것은 어떤 프로그래밍 지식보다도 더 중요하다고 생각하는 실제 기술, 즉 프로세스를 충분히 잘 알고 그것에 대해 충분히 관심을 가져서 실제로 맞을 때까지 계속 '아직 아니에요'라고 말할 수 있는 능력이라고 생각합니다.

순탄치 않았습니다 — 세 번의 실제 실패

이 모든 것이 처음부터 완벽하게 작동한 것은 아닙니다. 세 가지 별개의 실패 사례가 눈에 띕니다. 왜냐하면 각각의 경험이 제가 사전에 질문할 수 없었을 무언가를 가르쳐 주었기 때문입니다.

1. 존재한다고 주장했지만 실제로는 없는 첨부 파일

초기에 실제로 제출된 자료를 받았는데, 그 사람이 첨부한 것이 완성된 문서 안에 실제로 포함되어 있지 않았습니다. 도구는 기술적으로 파일이 존재했다고 기록했고 — 심지어 그렇게 말하는 줄까지 작성했습니다 — 하지만 그것을 어딘가에 실제로 삽입하거나 첨부한 적은 단 한 번도 없었습니다. 그것은 자신만만하고, 구체적이며, 완전히 거짓된 주장이었습니다. 이것이 바로 위험한 종류의 버그입니다. 충돌(crash)이나 오류 메시지(error message)가 아니라, 그저 조용하고 그럴듯해 보이는 데이터 손실인 것입니다.

수정 사항은 패치가 아니라 규칙 변경이었습니다. 이제 시스템이 파일을 실제로 임베드했음을 증명할 수 없는 한 어떤 것도 '포함됨'으로 표시될 수 없게 되었고, 모든 첨부 파일은 썸네일이나 시간이 지나면 조용히 만료될 수 있는 링크가 아니라 최종 문서에 전용 페이지를 갖게 되었습니다.

이 순간에는 해결책이 이론적으로는 작동할 것 같았지만, 실제 라이브 상황에서는 그렇지 않았다는 것이 분명했습니다.

2. 괜찮아 보였으나 아무것도 하지 않은 링크

저는 도구로 연결되는 간단한 보조 페이지를 만들려고 했습니다. 로고와 버튼, 그리고 명확한 콜투액션(call to action) 하나만 배치하는 식이었죠. 제가 시도해 본 첫 번째 플랫폼에서는 아름답게 렌더링되었습니다. 그러고 나서 그 버튼을 클릭했습니다. 아무 일도 일어나지 않았습니다. 두 번째 플랫폼을 시도했을 때도 같은 결과였습니다. 완벽하게 보였지만, 클릭하면 죽었습니다. 세 번째 시도가 필요했고, 각 플랫폼이 임베드된 콘텐츠를 실제로 어떻게 샌드박스(sandbox)하는지에 대한 상당한 조사가 이루어진 후에야 저는 그 플랫폼 자체의 네이티브 빌딩 블록을 사용하고 주입형 커스텀 코드를 사용하는 대신 접근 방식을 찾았는데, 이것이 링크를 신뢰성 있게 클릭 가능하게 유지하는 유일한 방법임이 밝혀졌습니다.

제가 미쳐가고 있었던 걸까요? 저였을까요? 브라우저였을까요? 사용자였을까요? 또 저였을까요? 무언가가 작동하지 않는 이유를 알아내지 못할 때 얼마나 좌절스러운지 정확하게 전달할 수가 없습니다.

3. 시간이 지나며 조용히 구식이 된 설명서

저는 사람들이 도구를 사용하는 데 도움을 주기 위해 초기에 단계별 가이드를 만들었습니다. 그러자 도구가 계속 개선되었는데—이는 좋은 일이었지만—가이드가 그에 맞춰 개선되지 않았습니다. 제가 실제로 다시 살펴봤을 때도 여전히 이전 버전의 인터페이스를 보여주고 있었습니다. 해결책은 '가이드를 패치하는 것'이라기보다는 '수동으로 관리하는 것을 멈추는 것'이었습니다. 저는 가이드가 조용히 썩어가는 스냅샷이 아니라, 항상 도구의 실제적이고 현재 버전에서 새로 생성되도록 프로세스를 재구축했습니다.

이제 작동하는 방식

완성된 버전은 이전 프로세스가 수동으로 처리해야 했던 복잡한 문제들을 해결합니다. 누가 제출하는지 알고 예측 가능한 내용을 채워 넣고, 아무것도 불완전하게 제출되지 않도록 강제하며(누락된 첨부 파일을 나중에 추적할 필요가 없습니다), 여러 파일 형식을 자동으로 단일하고 일관된 완성 문서로 변환하고, 누군가 '제출' 버튼을 누르는 순간 그 완성 문서를 전달합니다. 제가 수동으로 할 작업은 전혀 남지 않았습니다.

실제 핵심 요약

저는 처음에는 조금 더 나은 양식을 만들려고 했습니다. 하지만 결국 모두의 접촉 횟수를 줄이고 원래 것보다 더 좋은 결과를 만들어내는 프로세스를 갖게 되었습니다. 우리가 완성한 것은 다음과 같습니다: 모든 여행자의 홈 오피스를 자동으로 채우고, 제출 시 주소 자동 채우기를 통해 여러 번의 출장을 처리하며, 비용 지출 건마다 영수증을 요구하여 제출할 수 있게 하고, 누군가 '제출' 버튼을 누르는 순간 제출 준비가 된 패키지를 이메일로 보내주는 무료이며 모바일 친화적인 도구입니다.

이 모든 것은 웹 앱의 google script를 사용하여 구축되었으며(저는 이것이 가능하다는 것을 이전에는 몰랐습니다), 모든 것을 원활하게 조립합니다. 저는 양식을 만들려고 시작했지만, 접촉 횟수는 줄이고 더 많은 것을 성취하는 프로세스를 얻게 되었습니다.

혹시 문제를 해결하려고 시작했다가, 원래 찾으려 했던 것보다 훨씬 더 좋은 해결책을 얻은 경험이 있으신가요?