StudyDad

정산 업무를 하다 보면 문제는 꼭 복잡한 계산에서만 생기지 않는다.오히려 더 자주 생기는 문제는 기준이 흩어져 있을 때 발생한다.수수료율은 엑셀 어딘가에 있고, 예외 거래는 메신저에 남아 있고, 환불 반영 여부는 별도 파일을 열어봐야 한다. 파트너별 지급액은 매달 새로 집계하고, 월마감 체크는 담당자의 기억에 의존한다.처음에는 이 방식도 굴러간다.거래량이 적고, 담당자가 모든 맥락을 알고 있고, 예외가 많지 않을 때는 큰 문제가 없어 보인다. 하지만 거래가 늘고, 환불이 쌓이고, 수수료 정책이 많아지면 정산은 금방 불안정해진다.정산 오류는 대부분 “엑셀을 못해서” 생기는 것이 아니다.기준이 한 곳에 정리되어 있지 않고, 검토 흐름이 없고, 변경 이력이 남지 않아서 생긴다.정산 업무에서 먼저 정리해야 할 ..

자동화 워크플로우 시리즈 3/8스프레드시트를 데이터 원천으로 쓴다고 하면 불안하게 들릴 수 있다.개발자 입장에서는 데이터베이스가 더 자연스럽다. 스키마가 있고, 권한이 있고, 쿼리가 있고, 트랜잭션도 있다.하지만 모든 운영 자동화에 RDB가 필요한 것은 아니다.특정 조건에서는 Google Sheets가 Source of Truth, 즉 원천 데이터 저장소 역할을 할 수 있다.중요한 것은 스프레드시트를 무작정 쓰는 것이 아니라, 어떤 조건에서 가능한지 명확히 아는 것이다.Source of Truth란 무엇인가Source of Truth는 같은 정보가 여러 곳에 있을 때 "원본으로 인정하는 곳"이다.운영 자동화에서는 데이터가 여러 곳에 복제될 수 있다.폼 응답스프레드시트S3 JSON운영자 화면공개 페이지월별..

자동화 워크플로우 시리즈 2/8운영 시스템을 만든다고 하면 입력 화면부터 직접 만들고 싶어진다.회원 인증을 붙이고, 신청 폼을 만들고, 검증 로직을 넣고, 데이터베이스에 저장하고, 관리자 화면에서 조회하게 만드는 방식이다.하지만 모든 입력 흐름에 직접 만든 화면이 필요한 것은 아니다.특히 외부 사용자가 간단한 신청 정보를 제출하는 업무라면 Google Forms 같은 도구가 충분히 좋은 입력 도구가 될 수 있다.문제 상황외부 사용자가 특정 기간에 신청 정보를 제출해야 하는 업무가 있었다.입력 항목은 정해져 있었고, 제출량은 폭발적으로 많지 않았다. 운영자는 제출된 내용을 확인하고, 이후 상태를 관리해야 했다.이 상황에서 선택지는 두 가지였다.첫 번째는 신청 화면을 직접 만드는 것이다.두 번째는 Googl..

자동화 워크플로우 시리즈 1/8운영 자동화를 시작할 때 가장 먼저 떠올리는 것은 도구다.폼을 만들까, 스프레드시트를 쓸까, 관리자 페이지를 만들까, 자동화 스크립트를 붙일까, 아니면 처음부터 데이터베이스와 백엔드를 갖춘 시스템을 만들까.하지만 자동화는 도구에서 시작하면 자주 실패한다.먼저 봐야 할 것은 업무 흐름이다.누가 입력하고, 누가 확인하고, 어떤 기준으로 상태가 바뀌고, 결과가 누구에게 공개되는지부터 정리해야 한다. 그다음에야 어떤 도구가 충분한지 판단할 수 있다.문제 상황신청을 받고, 내부에서 확인하고, 일정이나 결과를 공개하는 업무가 있었다.처음부터 완전한 백오피스 시스템을 만들 수도 있었다. 로그인, 신청 화면, 관리자 화면, 상태 관리, 데이터베이스, 알림, 공개 페이지를 모두 직접 구현하..

데이터와 리포트 설계 시리즈 8/8작은 운영 콘솔의 리포트 시스템은 단순하게 시작할 수 있다.job table을 만들고, worker를 비동기로 실행하고, 결과 파일을 object storage에 저장한다.이 정도면 많은 내부 도구에는 충분하다.하지만 시간이 지나면 다시 검토할 지점들이 생긴다.좋은 설계는 처음부터 모든 것을 넣는 것이 아니라, 나중에 무엇을 볼지 알고 시작하는 것이다.현재 구조기본 구조는 다음과 같다.POST /api/reports-> job 생성-> worker 비동기 실행-> 파일 생성-> object storage 업로드-> job 완료-> polling으로 상태 확인이 구조는 단순하고 이해하기 쉽다.하지만 작업량이 늘거나 실패 대응이 중요해지면 개선 후보가 생긴다.1. 전용 Qu..

데이터와 리포트 설계 시리즈 7/8운영 콘솔에서 데이터베이스를 쓴다고 해서 모든 쿼리가 같은 성격은 아니다.화면 조회를 위한 쿼리와 리포트 생성을 위한 쿼리는 다르다.운영 데이터와 리포트 데이터도 다르다.이 차이를 무시하면 대시보드가 느려지거나, 리포트 생성이 운영 DB에 부담을 주거나, 정산성 데이터의 기준이 흔들릴 수 있다.운영 화면의 데이터운영 화면의 데이터는 빠르게 보여주는 것이 중요하다.예를 들어:오늘의 요약최근 주문상태별 건수점포 또는 사용자 목록간단한 필터 조회이런 데이터는 사용자가 화면에서 반복적으로 본다.응답 시간이 중요하고, 쿼리는 자주 실행된다.따라서 connection pool, index, pagination, cache 같은 요소가 중요하다.리포트 데이터리포트 데이터는 성격이 다..

Volume 01. 나와 아이의 내면늦은 밤, 학원 공부를 마치고 돌아온 아들이 방으로 들어가고 난 후, 거실에는 아내와 나 둘만 남았다.식탁 등 아래에서 차를 마시던 아내가 문득 한숨을 내쉬며 조심스럽게 속마음을 털어놓았다.“여보, 요즘 OO이가 학교에서 친구들이랑 잘 지내는지 모르겠어. 집에 와서 물어봐도 그냥 다 똑같다고만 하잖아. 우리 애 혹시 겉도는 건 아닐까 걱정돼.”아내의 걱정은 깊고 애틋했다. 하지만 가만히 듣고 있다 보니 한 가지 사실이 눈에 들어왔다.아내는 지금 자신이 여자아이로 학창 시절을 지나오며 익숙하게 배웠던 관계의 기준으로 중학생 아들의 세상을 바라보고 있었다. 아주 가깝고 촘촘하게 마음을 나누어야 안전하고 괜찮은 친구 관계라고 여기는 엄마의 가이드라인이었다.그 이야기를 들으며..

데이터와 리포트 설계 시리즈 6/8운영 콘솔에는 통계 화면이 자주 등장한다.월별 매출, 주문 수, 사용자 수, 처리 건수, 리포트 합계 같은 지표를 보여준다.처음에는 화면이 열릴 때마다 원천 데이터를 조회해서 실시간 집계하면 된다고 생각할 수 있다.하지만 운영 통계는 매번 실시간으로 계산하는 것이 항상 좋은 선택은 아니다.반복 조회되는 통계는 미리 계산해두는 편이 더 안정적일 수 있다.문제 상황운영자는 대시보드에서 월별 통계를 자주 확인한다.통계는 여러 원천 데이터를 조합해서 계산해야 한다.데이터 범위가 넓거나 쿼리가 복잡하면 매번 화면 조회 시 집계하는 방식은 부담이 된다.특히 다음 문제가 생길 수 있다.대시보드 로딩이 느려진다.DB에 반복적인 집계 부하가 생긴다.같은 월 통계를 여러 사용자가 반복 조..

Volume 01. 나와 아이의 내면저녁을 먹고 온 가족이 거실에 모여 앉은 시간, 우리 집의 풍경은 그리 여유롭지 못하다.아직 아이만의 방이 따로 없다 보니 거실은 온 가족의 쉼터이자 아이의 공부방이 된다. 조그만 상 앞에 앉아 노트북으로 챗GPT 창을 띄워놓고 있는 아이. 학교에서 내어준 수행평가 과제를 채우기 위해서다.하지만 곁에서 아이가 자판을 두드리는 모습을 가만히 보고 있으면 마음이 복잡해진다. 질문을 던지고 답변을 받아 적는 아이의 손길에 아무런 생기가 없기 때문이다.당장 제출해야 할 숙제 앞에서 마음이 급해진 탓인지, 아이의 질문은 점점 짧고 기능적으로 변해갔다. 화면에 뜨는 텍스트를 자기 말로 다시 생각해보기보다 그대로 옮겨 적는 모습은, 기술을 영리하게 활용한다기보다 숙제의 빈칸을 서둘..

데이터와 리포트 설계 시리즈 5/8비동기 리포트 생성에서는 사용자가 작업 상태를 알아야 한다.가장 단순한 방법은 polling이다.프론트엔드가 일정 간격으로 상태 API를 호출한다.GET /api/jobs/{jobId}완료되면 다운로드 URL을 보여준다.Polling은 오래된 방식처럼 보일 수 있다. WebSocket이나 Server-Sent Events가 더 세련되어 보일 수도 있다.하지만 내부 운영 도구에서는 polling이 충분히 좋은 선택일 때가 많다.polling이란 무엇인가Polling은 클라이언트가 주기적으로 서버에 상태를 묻는 방식이다.예를 들어 2초마다 job 상태를 확인한다.0초: IN_PROGRESS2초: IN_PROGRESS4초: IN_PROGRESS6초: COMPLETE구현은 단순..