❗️ 우연히 찾아온 기회
우연히 실제 서비스 운영을 보조할 기회가 생겨서 약 반 년 정도 보조를 하고 있습니다.
말은 운영 보조인데 이게 엄밀히 말하면 코드 작성(리팩토링)이나 데이터베이스 관리 운영은 아니고 Customer Service에 가까운 의미의 운영 업무입니다. 다만 이 포스트를 기술 블로그에 작성한다는 것에서 알 수 있듯이 일반적으로 생각하는 CS 직원보다는 직접 DB 또는 코드를 사용자 요청에 따라 확인하고 결과로 반환하는 어떻게 보면 고객센터 + 데이터 분석의 업무를 경험해보았다라고 할 수 있습니다.
그래서 데이터분석을 하면서 느낀 몇 가지 사항들을 글로 남겨보려고 합니다.
먼저 이 실제 서비스는 다음과 같은 특성을 갖고 운영되고 있습니다.
- 일평균 이용자는 100 ~ 200명, 동시 접속은 보통 90 ~ 110 사이
- 주 이용자 층은 초등학생 고학년 ~ 대학생 남성
- 컴퓨터공학 또는 개발 지식을 아는 이용자가 제법 있음
- 주어진 권한은 깃허브 코드 열람 & DB read-only
- 라이브 서비스 형태에 가까움
요약을 해보자면 특정 층만 이용하는 소규모 라이브 서비스이려나요?
📝 글쓰기 그리고 국어 실력
주업무가 DB 데이터 분석 후 이 결과를 문의자에게 돌려주는 업무였습니다. 그렇다보니 대부분의 상황이 기술적 용어를 모르는 일반인들에게 설명을 해야하다보니 주로 다음과 같은 어려움들이 있었습니다.
- raw 데이터나 기술 용어를 사용할 수 없으므로 일반적인 용어로 번역해 답변하는 과정을 거쳐야한다.
- 중학생 이하 저연령대 문의자의 경우 문의 답변을 한 번 더 쉽게 풀이해서 답변을 작성해야한다.
- 모든 정보가 아닌 필요한 정보만 공개해야 한다. (아주 중요!)
- 당연하지만 실제 고객이므로 감정을 빼고 원칙에 따라 예의바르게 이야기해야 한다.
답변 자체는 금방 도출이 되는데 이를 각 제약 조건에 맞게 수정해서 답변하는 과정에 적지 않은 시간이 소모 되었습니다. 문단 구조를 신경써야했는데, 대부분의 사람들이 3줄 이상이 되는 순간 그냥 본인이 읽고 싶은 단어, 문장 일부만 읽고 좋을대로 해석해버리고 그게 사실인양 퍼져나가는 일이 비일비재해서 적절한 분량에 위 제약 조건을 다 지키느라 참 어려움이 많았습니다.
그리고 언론 등을 통해 "문해력 문제"가 간간히 떠오르는 걸 몇 번 봐왔는데, 실제로 접해보니까 생각보다 요즘 어린 친구들이 사용하지 않는 한자 단어가 훨씬 많구나하고 느끼기도 했습니다. 막 언론에서 떠드는 것 만큼 심각하진 않고 그냥 일상에서 사용하는 한자어 외의 것을 사용하면 아예 뜻을 알지 못해서 다시 설명해야하는 그런정도?
단순히 문의 외에도 서비스 품질 개선을 위한 데이터 분석도 하다보니 문서 작성에도 적지 않은 시간을 소모하게 되면서 글을 정말 많이 쓴 것 같았습니다.
그래도 부족한 국어 실력과는 별개로 글 쓰는 행위(와 문서 작성) 자체는 좋아하는 업무라서 나름 질리지 않고 재밌게 했던 것 같습니다.
💽 실전 데이터베이스 분석
설계의 중요성
엄청 간략하게 게시판 시스템을 예를 들면 사용자, 작성글, 댓글을 생성 시점에 저장하면 됩니다. 이 데이터들은 해당 시간에 발생한 변함 없는 사실로 저장이 됩니다.
제가 업무를 본 서비스는 라이브 서비스 형태를 취하고 있었기 때문에 (생성 시점에 저장해도 되는 정보도 많았지만) 특정 시점/이벤트마다 저장하는 "스냅샷" 형태로 기록을 하고 있었습니다. 그래서 어떠한 정보를 얻기 위해서는 스냅샷의 흐름이나 타 테이블과의 연관 데이터들을 수집해 정보의 파편들을 모아 결론을 내야하는 과정이 반드시 필요했습니다.
당연히 모든 시점 모든 상황을 저장하면 이상적이겠지만 그것은 물리적/비용적으로 불가능에 가까운 이야기입니다.
그렇기 때문에 일정 시점/이벤트 마다 저장된 스냅샷의 흐름 그리고 스냅샷과 연관된 기타 자료들을 보고 "유추"를 해 사실을 알아내어 결과를 도출하는 식으로 데이터 분석이 이루어집니다.
이 유추의 정확도를 높이면서 효율적으로 저장(공간, 비용 절감 등)을 하기 위해서는 테이블, 뷰, 컬럼을 정말 잘 설계해야 함을 실전을 통해 느끼게 되었습니다.
다행히 설계가 잘 된 데이터베이스에서 업무를 보는 환경이라서 따로 컬럼/테이블 추가 요청할 필요도 없었고, 유추의 정확도가 나쁘지 않게 유지될 수 있었습니다.
지옥의 SELECT
read-only 권한만 부여받아서 사실 SELECT 구문밖에 쓸 수 없었긴 했지만, 정말 다양한 SELECT 구문을 구사해보는 귀중한 경험이 되었던 것 같습니다.
SELECT * FROM tablename을 해버리면 조회 성능도 떨어지고, 원하는 결과를 도출하기까지 추가 과정이 발생하기 때문에 필요한 컬럼 그리고 가능한 상세한 추가 조건들을 명시함으로서 조회하게 되는 스킬을 배우게 되었습니다.
물론 현재는 거의 조회 구문이 패턴화가 되어서 미리 작성해둔 구문에 전달하는 인자(uuid 등)만 바꿔서 확인하면 해결되는 경우가 많습니다.
데이터와 실제의 괴리감
스냅샷 저장과 라이브 서비스라는 특성에서 오는 가장 큰 어려움이 아니었나 싶습니다.
예를들어 사용자가 1부터 10까지 세는 작업을 할 때 서버는 짝수 단위마다 스냅샷으로 저장한다고 가정합니다.
이때 5에서 어떤 요인으로 인해 문제가 발생해 작업이 취소된다면 다음과 같은 상황이 발생합니다.
- 사용자는 실제로 5까지 작업을 수행했음
- 데이터는 짝수마다 저장하므로 데이터 상으로는 4까지만 작업을 했다고 표시됨
(예시를 위해 트랜잭션 등의 보호 정책은 아무것도 없다고 가정합니다.)
위처럼 예시 실제 사용자가 겪은 문제와 기록된 데이터의 괴리가 발생합니다. 여러 데이터를 참조해서 결론을 뽑는다 쳐도 결국 99%의 진실이 아닌 99%의 진실에 가까운 유추 형태이기 때문입니다.
약관을 통해 이용자가 장애 발생 시의 증빙 자료를 첨부하도록 유도하고 있으나, 장애가 발생했을 때 첨부를 위한 자료를 마련하는게 현실적으로는 쉬운 일이 아니라는 점 때문에 자료를 첨부하지 못하는 경우가 훨씬 많습니다. 정확하게는 약관을 안 읽어서 약관대로 처리하면 무조건 항의가 들어옵니다.
아무래도 어떤 장애 발생 시 실제로 클라이언트측의 오류라고 하더라도 관련 지식이 없는 경우는 "이건 서버 잘못인데"라고 생각해버리는게 당연하니까요.
이러한 스냅샷 방식의 특성 그리고 실제와의 차이로 인해 데이터 분석에서 큰 어려움들을 많이 겪게되었던 것 같습니다.
⛔️ 서버가 아파요
역시 가장 난감한 경우는 서버가 다운되어서 서비스가 멈추는 경우가 아닐까 싶습니다.
단순 개발이나 서버 운영이었으면 그에 따른 대응만 하면 되겠지만, 제가 맡은 업무는 사람을 상대하는 CS가 주업무이기 때문에 서버가 아프게되면 화난 고객분들을 상대해야하는 어려운 업무가 시작됩니다.
특히 이 일을 더 어렵게 만드는 것은 장애가 언제 발생할 지 모른다는 것... 자다가도 생기고 예측불허하다는 점이 아닐까 싶습니다.
서버가 다운되면 고개를 조아려라
메모리 릭, 네트워크 전송 지연 등 서버는 정말 다양한 이유로 성능 저하 또는 다운이 됩니다. 터지는 이유, 터지는 부분도 정말 가지각색이라 참 어려운 것 같습니다. 어떨 때는 이용자분의 호기심이 서버에 부하를 일으켜서 터져버리는 경우도 있었고요.
사유야 어쨌든 서버가 다운되면 열심히 사과문을 작성하고 보상 처리를 준비합니다. 케이스마다 보상 처리 방안이 조금씩 달라서 일괄 처리가 어렵기 때문에 여러모로 더욱 집중을 해야했습니다.
한 번 정도 부득이하게 제가 직접 다운된 서버를 찾고 재부팅하는 식으로 서버를 재시작해본 경험이 있었습니다. 생각보다 절차가 간단하면서도 터졌더라도 아무튼 실제로 운영되는 서비스를 kill하고 재시작하는 거라 손발 덜덜 떨며 터미널에 명령어를 입력했었던 작은 추억도 하나 남았습니다.
공포의 디도스
그동안 디도스는 강의나 뉴스에서 듣고, 이용하면 사이트/기능이 디도스로 다운되었대라는 학습자, 소비자 입장에서만 당해봤는데 서비스 제공자의 일원으로써 당하니까 정말 정신이 쏙 빠져버리는 공격이었습니다.
앞선 문단의 경우와는 다르게 디도스는 임시 완화 되었다고 해도 0시간, 심할 때는 0일 동안 반복적으로 지속되면서도 언제 어떻게 디도스 공격으로 다운될 지 모르기 때문에 더 공포스러운 것 같습니다. 계속 언급했듯이 호스팅 서버 업체 사용하고 있고 업체 상대로 들어오는 공격인지라 운영측에서 대비할 수단이 별로 없기도 하고요.
⌨️ 코드 읽는 법이 늘다...?
CS를 했는데 왜 코드 읽는 법이 늘어?라는 의문이 생길 수도 있으신데요.
이 기회가 지인으로부터 제안받은 내용이었고 해당 지인이 제가 컴퓨터공학 전공 그리고 관련 지식이 어느정도 있음을 알고 있었습니다. 그리고 애초에 1인 운영으로 기획된 서비스인데 해당 지인의 여러 상황을 고려 했을 때 1인 운영을 하면 "아 이거 금방 망할 수도 있겠다" 싶어서 도움을 자청하기도 했습니다.
그래서 기획이나 자료로 쓸 수 있는 문서같은게 없어서 DB도 직접 오픈해보고 필요한 경우 깃허브 접근 권한을 통해 코드 확인하고 정제해서 답변을 하거나 문서를 작성하는데 사용했습니다.
처음에는 Kotlin이나 DDD 아키텍쳐에 익숙하지 않아서 많이 헤메었었는데, 한 두 번 보기 시작하니까 아키텍쳐 구조의 패턴, 주로 필요한 정보가 모인 코드 부분이 반복되어서 이제는 필요 시 금방금방 찾을 수 있게 되었습니다.
팀플이나 협업에서 타인이 작성한 일부 코드 읽는 법은 많이 해봤는데 100% 타인이 작성한 프로젝트 코드를 읽는 것은 또 처음이라 좋은 경험이 되었던 것 같습니다.
값진 경험
지인에게 도움을 주고자 자청했던 일에서 "라이브 서비스 운영 보조 및 DB/코드 열람"이라는 여러모로 귀중한 경험을 할 수 있었습니다.
velog 쪽은 기술 블로그이기에 기술 관련된 쪽만 나열했지만, 기술적인 부분 외에도 다양한 경험들을 할 수 있었습니다. 기획적인 부분이라던가, CS적인 부분 그리고 인적 관리 등 소규모 서비스였지만 다양한 분야의 경험들을 시식해 볼 수 있었습니다.
귀중한 기회를 통해 기술적으로 배운 부분들을 앞으로의 일에 잘 녹여서 잘 활용해보도록 해야겠습니다.
