by
Aug 07. 2021
도그냥의 목적 있는 SQL 활용 이야기
서비스기획자/PM/PO, 프로덕트팀의 효율을 위해서일 때는 쓰는게 좋더라
"과장님, 이런 경우 있는 지 좀 찾아봐주세요!!"
이제 '데이터가 있으면 개발이 가능하고 데이터가 없으면 개발이 불가능하다'는 초보적인 지식이 싹트던 꼬꼬마 주니어 시절에 거의 하루가 멀다하고 김대수 팀장님(당시 과장님)의 자리에 찾아가서 징징 거리며 이런 케이스는 있냐 이런 데이터는 있냐 매일 물어보던 시절이 있었다. 아예 쪼그만 포장마차 의자 같은걸 가져다 놓고 이른바 개발자 뒤에 '병풍'을 치고 앉아있으면,, 지금도 신입 기획자 시절의 나를 업어 키웠다고 주장하시는(?) 대수팀장님은 Orange라는 프로그램을 켜서 가장 먼저 이런 걸 치고는 했었다..
select
아무 것도 모르는 마법주문같은 orange와 select가 SQL 이라는 것을 알게 된 것은 정말 한참이나 뒤였다. 그리고 기획자에게 DB 조회 권한을 주지 않았던 회사 탓에 나는 한참이나 연차가 성장하고 나서도, GA나 내부 데이터 파일을 다운로드 받아서 가공하거나 백오피스의 데이터를 받아서 가공해서 사용했고 직접 DB를 조회할 일이 없었다. 종종 직접 보지 못하는 답답함이 있었다고 하지만, 그렇다고 기획에 제약이 될 정도의 상황은 아니었다. 이미 BI나 데이터 애널리스트나 개발자에게 요청만 해도 데이터를 받을 수 있는 방법 등이 있었기 때문이었다.
SQL로 프로덕트팀 운영 효율을 높일 수 있다면!!
주니어들이 나에게 자주 묻는다. 'SQL 자격증은 기획자에게 얼마나 중요한가요? 취업에 도움이 되나요?' 솔직히 말해서 나는 여전히 당락을 결정할만한 요인은 아니라고 생각한다. 보통 기획을 담당하는 사람이 SQL을 쓴다고 하면 '지표'관리 이야기나 데이터를 통해서 문제점을 막 찾아내고 개선을 증명하고 그런 종류를 생각한다. 하지만 그런 복잡하고 중요한 내용을 다룰 때에는 프로페셔널한 수준이면 모르겠는데 떠뜸떠뜸대면서 직접 데이터를 뽑는 것은 바보같은 짓일 수 있다. 게다가 지금 나의 회사처럼 내부에 데이터 애널리스트가 상시 대기하고 더 의미있는 데이터를 찾아주기 위해서 목적을 물어보며 자문까지 해주는 상황에서 그걸 굳이 직접 만들려고 것은 비효율이라고 생각한다. (아무도 없으면 어쩔 수 없지만, PM은 그냥도 할 일이 차고 넘친다. 데이터의 추출 과정보다는 데이터를 이용한 프로덕트에 관한 의사결정 고민에 시간을 몰두해야한다.)
하지만, 그럼에도 기획자가 SQL을 직접 사용하면 편리한 점이 있었다. (뿌듯하다거나 그런 얼토당토한 이야기는 아니다) 이 장점은 '프로덕트팀 운영에 있어서 효율'에 관점에서 의미가 있다.
케이스 1) ERD 현행화를 독촉하지 않아도 개발과 싱크를 맞출 수 있다.
서비스가 고도화되다보면 ERD(DB의 데이터 테이블에 컬럼에 대한 정의와 데이트 컬럼간 연관관계를 분석해놓은 다이어그램)은 계속해서 진화한다. 칼럼이 계속해서 늘어나고, 일부는 기준이 변경되고 이름이 바뀌기도 한다. 정체되어 있지 않다는 것은 개발도 서비스도 계속 변화를 달려가고 있다는 훌륭한 신호다.
나는 구축 프로젝트와 운영 프로젝트에 골고루 시간을 보냈었는데, 구축 과정과 직후에 ERD는 정확하다. 그래서 그 때 컬럼이나 데이터 컬럼에 정의된 코드를 알아두는 것만으로도 굉장히 도움이 된다. 그런데 운영되는 서비스는 컬럼이 이미 변화된 것도 많은데 ERD는 현행화 된게 없어서 기획하면서 다시 데이터의 코드들의 케이스를 물어보거나 아니면 ERD를 수정해달라고 독촉해야했다. 개발자도 나도 모두가 마음이 불편해지는 순간이다.
기획자가 SQL을 직접 다룰 수 있다면, 아주아주 기초적으로 데이터 테이블의 모든 칼럼이 무엇인지 불러올 수만 있어도 이 문제는 아주 획기적으로 줄어든다. 예를 들어 나같은 경우에는 상품 DB를 그냥 SQL로 조회해서 칼럼들이 무엇이 있고, 현재 운영중인 데이터에는 어떤 케이스들이 존재하는지 내 눈으로 확인하고 궁금한 점은 코드로 물어볼 수 있다. 변경된 내용에 대해서 매번 DB에 그런게 있는지 없는지 물어보지 않아도 된다. 직접 조회해보고 내가 생각하는게 맞냐고 물어보는게 훨씬 빠르다.
가장 좋은 점은 개발하기도 바빠 죽겠는 개발자들이 ERD 현행화할 시간에 그냥 개발건 하나를 더 신경쓸 수 있다는 점이고, 두번째로 좋은 점은 데이터에 있는 코드로 질문하고 대화하기 때문에 기획을 담당하는 사람도 프로덕트에 대해서 더 많이 관심이 있다는 것을 팀원들에게 보여줄 수 있어서 좋고, 이 모든 상황 속에서 데이터를 물리적으로 바라봐야하는 기획자의 데이터 이해도도 높일 수 있기 때문에 1석 3조다.
여기서 필요한 SQL 수준이란? select하고 from으로 데이터 테이블 지정할 수 있으면 되는 정도다. 난 어린 시절 김대수 팀장님옆에서 Orange를 너무 들여다본 덕분인지 SQL을 딱히 공부하지 않고 이런 정도는 흉내낼 수 있었다. 맨날 봐서 눈에 익은 select여.... (나에게 있어서는 김대수 팀장님이 feasibility의 아버지이신 것, 인정합니다!! )
케이스 2) 현업과의 소통시점에 바로바로 데이터 확인하며 논의할 수 있다.
현업에서 개선 요청을 할 때 또는 사용 중 오류로 예상되는 신고가 들어와서 당황할 때, SQL과 잘 정리된 데이터들이 준비되어 있다면 즉시 대응할 수 있는 범위가 늘어난다.
예를 들어서 현업에서 "특정 결제수단의 UI를 개선해주세요"라고 말했다고 쳐보자. 특정한 결제수단에 대해서 얼마나 많은 사람들이 쓰는지만 볼 수 있어도 이 중요도의 경중을 따질 수 있다. 이 정도는 일정 기간내 전체 주문수에서 특정 결제수단을 사용한 주문수의 비율과 결제 거래액을 다른 결제수단과 비교해서 이 요청의 중요도를 바로 판단할 수 있다. 너무너무 많은 사람들이 쓰는 결제수단이라면 나 역시 심각하게 받아들이고 그 요구사항을 바로 받아올 수 있고, 만약에 봤는데 5%도 안쓰는 결제수단이다라고 하면 긴급도는 높지 않기에 나 역시 긴급하게 반응하지 않아도 된다.
이렇게 즉석에서 데이터를 간단하게 체크해서 소통하면 업무상 효율성이 생긴다.
문제해결을 위해서 가뜩이나 바쁜 메이커들을 불러들이지 않아도 된다. 중요도에 대해서 판단해보지도 않고, UI 문제를 해결하기 위해서 디자이너나 개발자에게 질문을 하는 순간부터 메이커들의 시간은 낭비된다. 그리고 요청을 한 뒤에 해결해줄지 말지 전전긍긍 기다려야 하는 현업도 기다림의 시간을 확실하게 단축시킬 수 있어서 좋다.
그래서 실무 현업 기획자 도그냥이 현장에서 SQL이 얼마나 필요하고 중요하냐를 대답한다면 이렇게 생각한다.
기획을 위해서는 'SQL보다는 쌓여있는 진짜 데이터'를 알아야 한다.
하지만 SQL을 툴로 잘 써서 프로덕트팀의 효율을 높인다면, 그것은 장점이다.
