[함께 걷기 전에] 로그를 하다보면 발생하는 현상들

아니 뭐 열심히 하면 어떻게든 되겠지~

첫 번째. 로그를 하다보면 발생하는 현상

1. 로그를 모르면 어떤 문제가 발생하나요?

2. 문제의 원인을 살펴봅시다

3. 로그를 못 할때의 위기와 잘 할 때의 기회

4. 해결방법은 이렇게 하시면 됩니다. 

할 일이 많은 오늘, 아침일찍 출근하려 했지만 어제 밤 11시 퇴근 후 집에서 지친몸을 달래줄 겸 맥주한 캔을 마신다는게 과하게 달래줘버렸습니다. 그렇게 마시고 잔게 몇 년만인지 모를 정도의 숙면을 취했는지, 덕분에 늦잠에서 몸을 힘들게 일으켜 헐래벌덕이는 심정으로 회사를 향해 달려가는 중입니다. 

도착시간은 10시 15분, 평소 출근시간보다 15~20분 늦게 도착한 내 자리의 노트북을 켜며 가방을 내려놓습니다. 어제 야근 때 힘겹게 작성하던 google spread sheet 화면이 보입니다. 아, 지겨운 이 시트를 어떻게 정리해야 할지 방향이 보이기는 커녕 왠지 어젯밤 숙면 속에 잠시 뭍어놓았던 싫증이 스믈스믈~ 올라오기 시작합니다. 

처음 행동로그를 개발땐 이런 상황을 예상하지 못했거든요. 기획자 겸 신규기능을 담당하는 PO(product owner)가 요청한 미팅에 참석한 저는 당황할 수 밖에 없었습니다. 미팅 초대 메일에는 '로그미(log me)'이라는 제목과 일시만 적혀있었고, 로그를 담당하게 된 저와 PO만 있었기 때문입니다. 일반적으로 분석가와 개발담당자분이 함께 참석하거든요. 에너지 넘쳐보였던 PO와는 첫 미팅인데, 필요한 로그를 한시간 넘게 설명하며, 모두 필요한 로그이니 다 개발해야 한다고 중요성을 강조하는 미사어구들로 넘쳐나는 요청을 받아내기 부담스러웠습니다. 

끝없는 요청사항들 듣느라 귀에서 피가 나는 로그담당자

1시간여의 미팅을 마칠때 즈음, 이 내용들을 문서로 정리된게 있을까요?라고 물으니 오늘 다 설명했고, 나중에 기회되면 작성할테니 우선 이 내용으로 진행해달라는 당찬 요청이 전부였습니다. 불안한 미래가 잠시 스쳐 지나갑니다만, 일단 알았다고 한 저는 미팅때의 찜찜했던 예상대로 로그개발이 완료될 때까지 그 문서는 전달받지 못했습니다.  

미팅내용을 차곡차곡 정리한 저는 어떻게 할까 고민하다 일단 회의록을 작성하고, 요청사항을 최대한 수용하는 방향으로 로그개발 요청을 위한 문서를 confluence에 작성했습니다. 이를 근거로 JIRA를 생성하여 개발자에게 개발요청을 한거죠. Android와 iOS, Web 개발자에게 각각 개발을 요청했고, 결과를 기다렸습니다. 2주가 지나 3주차가 될때 즈음, Android 개발자로부터 다음 sprint로 넘어갔다는 JIRA의 알림만 오기에 언제 진행할 수 있냐고 물었더니, "급한거에요?"라는 물음이 먼저왔습니다. 이상하다 싶어 iOS와 Web개발자의 JIRA 티켓들을 확인해보니 제안받음(suggested) 상태로 진행되지 않고 있었습니다. Android 개발자에게 이런저런 상황설명을 하며 간곡하게 호소하자 다음 sprint에 진행하겠다는 확답을 받을 수 있었죠. 이를 핑게로 iOS와 Web도 개발날짜를 맞춰야 배포날짜도 맞출 수 있다고 얘기해서 로그개발을 진행할 수 있었습니다. 거의 4주차가 다가오는 시점인에 말이죠.

어떻게든 JIRA의 상태가 개발 완료로 전환되어서 로그검증을 하게 되었습니다. 저 혼자서 Android, iOS, Web을 모두 검증하는데, 검증 방법은 개발자분에게 물어물어 얻은 정보들을 바탕을 어렵지 않게 확인할 수 있었습니다. 개발자분들은 로그개발에 익숙하지 않았던지 누락된 정보가 종종 있었고, 이들을 한땀 한땀 발견해서 JIRA로 수정요청을 했습니다. 이런 수정요청의 반복작업을 1주일 내내 3개의 platform(Android/iOS/Web)을 대상으로 마쳤고, 드디어 모든 문제를 해결해다는 뿌듯한 마음으로 금요일 저녁 12시에 퇴근을 할 수 있었습니다. 개발자분들이 고집은 있지만, 그래도 하겠다고 한 약속은 지키는 분들이구나 싶은 마음으로 다음주 월요일에 드디어 로그가 고객들에게 제공하는 패치에 반영된다는 설레인 마음을 안고 토요일 이른 새벽에 택시를 타고 집으로 향했습니다. 

한 주의 피곤에 절여진 몸과 마음은 주말이 어떻게 지나갔는지 생각할 틈도 없이, 월요일 아침 출근 후 배포 현황을 모니터링 했습니다. 월요일 오전 10시부터 배포인데, 점심시간 마치고도 배포율이 10% 미만이면 1주일은 지나야 70~80%까지 올라갈것 같았습니다. 일단 고객 대부분이 발생시키는 데이터가 적재되어야 사용은 회사 동료들이 신뢰하고 사용할 수 있으므로 95% 이상 배포율에 도달하는 2주 경과된 후의 시점에 데이터분석을 시도하기로 마음 먹었습니다. 그 전까지의 데이터는 일부 고객에 해당하는 샘플 데이터에 한정하기로 가정했습니다. 그 샘플링 데이터를 살펴보는데, 허허허~ 예상치 못한 문제들이 하나 둘씩 나오네요. 

로그의 누락이 발생하는 거였는데요. 가장 중요한 결제완료 페이지인데, 운영DB인 주문DB의 수치보다 70%정도만 남는거였습니다. 100건 중 30건 정도가 데이터가 빠지는거죠. 버전으로 구분해서 정확히 살펴봤는데, 쿼리가 잘못된걸까 싶어 재확인했지만 결과는 같았습니다. 이번엔 platform 별로 확인했는데 Web과 iOS는 정상적으로 나오지만, Android만 누락이 발생하는 거였어요. Android 담당자에게 검증한건데 데이터가 안 남는 이유를 묻자 로그검증 데이터는 수정했지만 다른 기능검증에 문제가 있어서 일부 수정을 했는데, 그때 로그 전송 코드가 수정된거 같다는 의견을 한참 후에야 알려주더군요. 아~ 이거 어떻게 하죠. 

Android의 결제완료는 다음 배포에 수정하기로 하고, iOS와 Web의 데이터로만 확인할 수 밖에 없었습니다. 결제완료가 중요한 페이지이므로 iOS의 데이터를 살펴보는데, 흐름이 조금 이상하게 보였습니다. 일부 로그의 순서가 맞지 않았어요. 자세히 들여다보니 처음 도착한 페이지에서는 문제가 없는데 여러 페이지를 돌아다니면 페이지 구분정보(Page ID)의 순서가 뒤바뀌는 현상이 발생을 했습니다. 이 문제를 찾는데도 3시간 넘게 걸렸는데, 결국 로그의 발생 위치가 뒤바뀌면서 활용이 가능할지 막막해지기 시작했습니다. 이런 큰 문제가 왜 전에는 몰랐는지도 이해 되지 않았어요. 

Web의 데이터를 살펴봤습니다. 그나마 의도한대로 잘 남아서 다행이긴 했습니다만, 여러개의 상품을 주문한 고객의 데이터에서 이상한 현상이 있었습니다. 하나의 컬럼에 한개의 값이 들어가야 하는데, 여러개의 값이 쉼표(comma)로 구분해서 들어간거였어요. 그 이유를 물어보니 비즈로직 상 여러개의 상품ID를 담도록 허용하기 때문에 그런 상황까지 고려해서 추가한거라며 개발자는 생각해서 넣어준건데 그걸 이해할 수 없냐고 오히려 불편한 표정을 지었습니다. 저는 몰랐어요. 로그담당하는 입장에서 서비스가 동작하는 순서와 이해도가 부족했던거였습니다. 기획자로부터 듣지도 못한걸 개발자로부터 배포 후에 알게 된겁니다. 코드개발에 바빴던터라 설명하고 협의할 틈 없이 개발자의 해석대로 값이 들어간거죠. 그나마 사용을 할 수는 있을거란 희망을 갖고 Android와 iOS를 살펴보니 Android는 Web과 동일한데 쉼표(comma)가 아닌 underbar('_')로 구분해서 여러 상품ID를 추가했고, iOS는 첫 번째 상품만 담은겁니다. 아~ platform 간 협의되지 않은걸 각각의 개발자가 넣은 값을 어떻게든 활용해야만 하는 상황이 된겁니다.

최선의 데이터가 없으면 차선의 데이터로 멋진 통찰력을 찾자는 이상적인 목표를 마음에 되세겼습니다. 데이터를 테이블에 적재 후 가장 기본적인 방문자 현황인 DAU(daily active use)를 확인했습니다. 다행이 이 정보는 잘못되기 어려웠기에 바로 확인할 수 있었고, 2주 동안의 배포현황이 DAU의 변화로 확연하게 확인할 수 있었습니다. 휴~ 다행이었고 왠지 뿌듯한 기분마저 들었습니다. 상품ID는 iOS를 제외하고 복수상품정보를 담았으므로 문자열 정보에 해당하는 테이블 처리를 했는데, 이상하게 적은 수치가 확인되었습니다. iOS는 한 상품만 담았으므로 예상보다 적을 수 밖에 없는데, 그 예상보다 한참 낮아서 고민하다 쿼리로 iOS의 상품ID를 자세히 확인한 결과 value type이 정수(integer)였습니다. 저의 요청사항에 value type을 정수로 기재했지만, 여러 상품을 담을 수 있는 예외조건때문에 iOS를 제외하고 Android와 Web은 문자열(string)으로 변경해서 보낸거고, iOS는 integer로 유지한겁니다. 이걸 확인하는데만 1시간이 넘게 걸렸네요. 쿼리가 복잡하긴 하지만 그래도 상품정보는 문제없이 확보할 수 있게 되었습니다. 

분명히 배포전에 모든 로그별로 검증을 했는데도 이런 문제가 발생을 하다니, 할 말이 없었습니다. 두 달에 걸쳐서 배포한 로그가 활용하기 어려운 정보라고 팀장님께 얘기를 할 수 있을까요. 이번 배포는 망했으니 대충 보면 안되나요라는 말을 건네고 싶은 마음뿐이었습니다. 일은 일대로 한건데, 결과는 말 그대로 참혹했습니다.

위에 참혹한 현상은 팀장님께 사실대로 보고했고, 잘 대응해보자라는 대승적인 의견을 말씀해주셨습니다. 제가 하는 일에 큰 관심이 없는 팀장님은 착하신 분이라 문제가 생겨도 크게 나무라고 하시진 않으십니다. 그나마 다행인걸까요. 연말 평가는 큰 문제없으면 중간은 가겠지만, 팀에 보탬이 되는 성과를 내기는 커녕 요청받은 데이터를 제대로 활용하지 못한다는 불평들이 쌓일까 걱정이 됩니다.

자리에 돌아와서 노트북을 다시 바라봅니다. 다양한 시행착오를 경험하며 제가 개발요청한 내용들을 문서화시킨다고 나름의 방식으로 정리했지만 혼자 담당하는 로그업무가 바빠서 정리의 구성과 방법이 깔끔하진 못했습니다. 여러 사람들에게 공유해야 할지 모르니 잘 정리해야겠단 생각만 있었을 뿐 실행을 시간이 지나면 챙기지 못한채로 방치가 되었던거죠. 시간이 흐르면서 정리할 양이 증가하게 되고 그렇게 저의 손에서 멀어짐이 불안함으로 전환되는 시점이다 싶을때였는데요. 

예전의 데이터에 문제가 발생했습니다. 이상한 값이 나오고 있었던거에요. 주문시도 페이지에서 상품판매자의 유형이 의류, 컴퓨터/휴대폰과 같은 구분정보였는데, 지난 주 배포한 버전부터 이 값들이 삼성, 애플과 같은 브랜드명으로 나오는것이었어요. 개발자에게 이런 문제를 얘기하니 우리는 요청한대로 개발했고, 문제가 있다면 JIRA로 수정요청을 해달라는 짧은 JIRA 댓글 뿐이었습니다. 과거의 문서를 찾아봤는데, 아~ 이런.... 제가 기록한 내용을 보고도 이해가 되지 않았습니다. 대충 써놓은것도 있고, 바빠서 기록을 하지 않아 상황이 파악되지 않는것이였죠. 어쩔 수 없이 기존의 상품판매자 유형을 추가해서 다음 배포 때 반영하기로 했습니다. 쿼리 로직만 또 복잡하게 되겠네요. 문서기록을 뒤로 미룬 댓가를 혹독히 치루게 되었습니다.

이런 상황에서 오랜만에 모습을 드러낸 PO 분이 그룹웨어 대화창으로 문자를 보냈습니다. 배포된 데이터는 언제 확인할 수 있냐고 말이죠. 중요하다고 한참 강조할 땐 언제고 2개월정도가 지난 이 시점에 물어보는 행동이 왠지 삐딱한 의심의 시선으로 보게 되더군요. 하지만, 친절한 자세가 비지니스 소통의 기본이라는 마음을 되세기며 일부 부족하지만 원하는 사항은 일정부분 확인하실 수 있을거라고 짧지만 바라는 답변일거라는 생각으로 응답했습니다. 

임원분의 리포트요청이 왔습니다. 그 다음은 어떻게 되었을까요. 대략 여러분이 생각하는 그 상상이 맞을겁니다. 이렇게 데이터의 정합성이 낮아지는 신뢰성 문제가 발생한 로그는 전체 로그의 효용가치를 훼손합니다. 데이터의 품질이 낮아지는거죠. 누락만 없으면 분석하는데 번거로울 뿐이지 문제는 없지 않을까라는 식의 사고는 데이터 활용의 크나큰 허들을 만드는 데 일조하는 역할이라고 보셔도 과장이 아닙니다. 상세한 문서화 작업을 전제한다고 하더라도, 다양한 구성원들이 데이터 사용할 때 마다 문서를 꼼꼼하게 읽고 사용해야 한다는 전제 자체가 부담으로 작용되기 때문입니다. 아무리 문서를 잘 작성해도 문서는 개인의 주관성이 개입되어 읽는 이의 잘못된 해석도 배제할 수 없는 점도 있구요. 데이터 사용 전 숙지해야 할 내용을 문서에 기록한다면, 여러사람이 사용하는 문서 그 자체의 한계가 데이터 활용의 제약으로 전환되어 오히려 넘기 어려운 허들로 자리잡을 수 있습니다. 데이터로 의사결정한다는 기업에서 흔히 나타나는 현상이라고 보시면 됩니다.

대부분의 기업들은 비즈니스 의사결정에 필요한 객관적인 데이터 지표로 불확실성을 줄이기 위해 로그작업을 통해 데이터를 얻습니다. 이러한 의사결정들은 매번 데이터분석 결과를 기다리는게 아니라 주요 정보의 변화들은 모니터링 지표(metric)로 만들어 관리하는데요. 지표가 부정확질 경우 잘못된 의사결정이 발생하여 잘못된 서비스의 발전 방향을 적시에 바로잡지 못해 고객이 이탈하여 매출의 하락 문제로 확대될 수 있습니다. 결국 이러한 문제의 반복은 회사의 잘못된 운영으로 직결되고, 마치 사람의 몸에 차곡 차곡 쌓여가는 피로가 건강에 미치는 영향과 같습니다. 

데이터는 객관적인 의사결정에 도움을 제공하는 도구입니다만, 이 도구가 양날의 검인 점을 잘 알아야 합니다. 정확하지 못해 데이터의 신뢰성이 낮을 경우 원하지 않은 결정을 할 수도 있기 때문인데요. 신뢰성은 결국 미션이 부여된 담당 조직, 로그의 구조적인 설계, 그리고 꾸준한 운영의 노력이 수반되어야 합니다. 그렇지 않으면 데이터는 매일같이 쌓이지만 어떻게 사용해야 할지 모르는 양날의 검이 될 수 있기때문입니다. 북한이 남한을 점령하지 못하는 이유가 대한민국의 사춘기 중학생들이 어디로 튈지 몰라 예측할 수 없다다는 농담처럼, 잘못된 고객의 분석은 잘못된 방향의 의사결정을 어디로 이끌게 될지 모르는거죠. 

저는 로그에서 이런 문제들을 해소하기 위해 우리는 무엇을 어떻게 해야 하는가에 대한 내용들을 정리하였습니다. 수 많은 기업들이 자기만의 방식으로 고객의 행동로그를 만들고 활용하는데, 이 책이 더 이상의 시행착오가 발생하지 않도록 조금이나마 도움되길 바라는 마음으로 저의 경험과 생각들을 한문장씩 차곡 차곡 적어 가겠습니다.