디지털 뜨개질이라고 아시나요
때로는 한 땀 한 땀 정성 들여 기워내야 할 때도 있답니다
01. 연휴에 뜨개질 했어요, 디지털 뜨개질..
앱 내 외국인 유저들의 후기 탐색 경험을 개선하기 위해 런칭된 기능이 있습니다. 이 기능이 빛을 발하려면 어드민에서 지정해줘야 하는 조건들이 있어요. 많은 양에 살짝 엄두가 안 나긴 했지만- 과거 실험을 통해 기대효과가 크게 검증되었던 기능이었기 때문에 서둘러 어드민 작업을 하기로 했습니다.
제가 봐야 하는 행은 6700개. 다 끝나고나서 계산해보니 총 7시간 정도 걸렸습니다. 사실 찡찡거리기엔 꽤나 할 만한 양이긴 했지만, 중간 중간 회의와 다른 실무가 있는 중에 완료하기엔 어려웠습니다. 단순 반복 작업이라 생각하니 우선순위가 점점 낮아지기도 했고요. 그래서 추석 연휴에 좋아하는 노래 플리 틀어놓고 머리 비울 겸 처리(?)했습니다.
여기도 사람 있어요자동화하지 않고 사람이 반복된 행위를 하는 것, 단순 판단을 유형화하지 않고 사람이 직접 하는 것... 디지털 뜨개질이라고 농담하기도 하는데요. 이런 종류의 작업, 아주 속된 말로 '짜치게' 인식됩니다. 특히 빠른 속도를 추구하는 IT 업계에선 더욱이 그런 것 같아요. 부끄럽지만 저는 여태 별 생각 없었고, 이런 작업을 할 일이 가끔 생길 때는 '머리 비우고 싶었는데 잘 되었네' 라고 생각하고 오히려 즐기면서까지 했던 것 같습니다.
그런데 이제는 나 혼자 작업하면 끝! 이 아니라 이것을 기반으로 제품(어드민 포함)을 만들고 이 제품을 동료, 고객들이 사용한다는 걸 더 실감해서인지 제법 진지한 자세로 디지털 뜨개질에 임하게 되었습니다. 그리고 배운 점을 이 글에 기록하려 합니다.
02. 개발로 올릴 수는 없는 거야?
사람이 직접 어드민으로 올리는 것보다 개발로 올리는 게 더 빠를 것 같죠, 실제로 대부분의 경우 그렇습니다만 이런 벌크 업로드에서도 주의해야 할 점이 있더라고요. 저도 몇 번 그런 작업을 요청드렸던 적이 있는데요, 언젠가 한 번은 수동 작업 대비 벌크 업로드의 공수가 얼마나 적은지 알고 싶어서 상세 작업 과정을 여쭌 적이 있습니다. 답해주신 내용을 들으며 옆에서 지켜보니 이 과정에도 결국 사람의 뜨개질이 필요하다는 것을 알게 되었어요.
사람이 작성해둔 데이터를 업로드에 필요한 포맷으로 변경해야 하고, 업로드 중간에 데이터 변경이 발생하면 안되니 수정 가능성을 차단/소통해야 하고, 데이터 수정 후 발생되어야 하는 이벤트 발행을 챙겨야 하고 etc..
벌크 업로드가 언제나 더 빠른 방법은 아닐 수도 있겠다는 생각이 들었습니다. 우리가 가정했던 정상적인 방법의 업로드가 아니니- 데이터 정합성이 정교하게 지켜져야 하는 상황에서는 오히려 더 피해야 하는 일이라는 것도 알게 되었고요. 어드민이 있을 때는 가급적 어드민을 사용하되, 벌크 업로드는- 일이 정말 급하고 많을 때 경우에 따라 취사선택하는 방법 정도로 생각하게 되었습니다.
또는 제가 수동으로 반복하는 행위 자체를 매크로로 만들 수는 없을까, 하고 짱구도 굴려보았는데요. 매크로 프로그램을 만들려면 컴퓨터에게 명확한 규칙을 알려줘야 하는데- 운영 데이터 특성상 사람의 판단이 필요한 부분들이 적지 않은 비중으로 존재했어요. (직접 뜨개질을 하다보니, 이렇게 판단이 필요한 것들도 어느 정도 유형화되었지만- 뜨개질 전에는 알 수 없는 부분이었습니다)
그리고 무엇보다, 떳떳한(?) 이유인지는 모르겠습니다만 '급했습니다'. 낮은 학습곡선으로 매크로 프로그램을 만든답시고 ui.vision (링크) 같은 외부 서비스를 이용하기엔 보안상 그럴 수 없었고, 직접 만들거나 사내에 요청하자니 시간이 없었습니다.
구구절절이었는데요, 여하튼 이런 이유로 인해 직접 반복 작업 뜨개질을 하게 되었습니다.
03. 패턴을 만들려면 결국 점이 필요하다
직접 해보니, 이번 뜨개질은 꼭 필요했던 작업이라는 생각이 들었습니다. '반복작업을 계속 할 수는 없으니 효율화가 필요하지~' 정도로 막연하게 생각했던 것이 구체화되는 중요한 계기가 되었거든요.
느낀 점이 휘발되기 전에 후다닥 공유효율화/자동화를 하려면 규칙이 필요하고, 규칙 그러니까 패턴을 만들려면 결국 점을 찍는 과정이 필요합니다. 몇 백번 반복할 때까진 잘 모르겠다가 1000번 정도 반복하고나니, 사람의 판단이 필요해 '애매하다'고 생각했던 것들도 어느 정도 유형화되었습니다. 유형화하는 과정에서- 너무 기준이 많아 헷갈린다 싶을 때 자문하게 되는 질문이 결국 가장 중요한 의사결정 기준이 된다는 것도 깨달았고요. "이 여러 메타정보 중에 유저에게 가장 중요한 정보가 뭐지?"가 그 질문이었는데요. 자문자답(;;) 하면서 나름 규칙으로 정의하고나니 그 다음 1000번이 더 빨라지더라고요. 이걸 이제 프로그램에게도 알려주면 되겠다 싶었습니다.
그리고 예상치 못했던 가장 큰 소득은- 운영 데이터를 하나하나 보면서 평소에는 크게 체감하지 못했던 고객 (파트너 병원 포함) 온도감을 느꼈다는 것입니다. '효율성'이라는 키워드만 생각하면, 여러 단계에 걸친 작업을 무조건 일원화하고 통으로 만드는 게 정답이라고 생각하게 되기 마련입니다.
그런데 실제로 파트너 병원들이 업로드하는 정보들을 살펴보니 다른 대안이 필요할 수 있겠다는 생각을 하게 되었습니다. 국적별 고객 특징을 고려해 파트너 병원들이 직접 정성껏 다원화하는 정보들이 존재했고 이것을 보존하는 선에서의 효율화가 필요하다는 걸 깨달았습니다.
그리고 파트너 병원들이 이런 정보를 준비하고 업로드하는 과정에서 어떤 것이 특히 어려울지에 대한 힌트도 얻을 수 있었습니다. 의도와 다르게 입력된 것으로 추정되는 정보들 대부분이 부자연스러운 번역에서 오는 것으로 보였거든요. 안 그래도 제품 로드맵을 구상 중이었는데 정말 중요한 인풋이 되었습니다. 채널톡 같은 VoC 로데이터를 보는 것도 같은 맥락인데- 사실 문의는 '문제 상황을 경험하고 인지한 고객이 기꺼이 자발적으로 먼저 찾아와주신' 아주 감사한 케이스이다보니 제가 원하는 만큼 충분한 인풋을 받기는 어렵습니다. 어려운 상황에 이미 적응해버린 대부분의 고객들이 숨겨져있는(?) 곳을 들추는 것이 정기적으로 필요하겠다는 생각을 하게 되었어요.
우리는 현실세계와 닮은 모습을 IT 제품에 구현하는 일을 합니다. '이런 정보를 보여주고 싶어!' 라고 결심하면 현실에서 그 정보를 가져오는 것이 선행되어야 합니다. 핸드폰, 모니터 앞에서 숫자로만 표현되며 납작해진 장면들을 다시 동글동글 굴려 입체적으로 만들면 사람들의 모습들이 보이는 것이 재미있기도 하고 이 일의 매력인 것 같기도 해요. 물론, 디지털 뜨개질의 감성(?)에 빠져 비효율에 숙달되는 일이 생기면 안되겠습니다만- 결국 사람 간의 일들을 사람들이 IT 제품으로 만든다는 사실을 잊지 않고 인간적인 태도로 일하고 싶다는 생각이 듭니다.
