StudyDad

데이터와 리포트 설계 시리즈 2/8처음 리포트 다운로드 기능을 만들 때 가장 쉬운 방식은 동기 API다.사용자가 버튼을 누르면 API가 데이터를 조회하고, 엑셀을 만들고, 바로 파일을 응답한다.작은 데이터라면 이 방식도 괜찮다.하지만 데이터 범위가 넓어지고 생성 시간이 길어지면 동기 API 방식은 여러 문제를 만든다.가장 단순한 구조동기 방식은 이렇게 생겼다.사용자 클릭-> POST /api/reports-> DB 조회-> 엑셀 생성-> 파일 응답구현은 단순하다.프론트엔드도 요청 하나만 보내면 된다.서버도 파일을 만들어 바로 응답하면 된다.하지만 이 구조는 "작업이 짧게 끝난다"는 전제를 가진다.그 전제가 깨지면 문제가 시작된다.브라우저 대기 UX동기 API는 사용자가 요청이 끝날 때까지 기다려야 한다...

데이터와 리포트 설계 시리즈 1/8운영 콘솔에서 리포트 기능은 단순해 보인다.사용자는 조건을 선택하고 버튼을 누른다. 잠시 뒤 엑셀 파일을 내려받는다.겉으로 보면 "조회해서 파일로 만들면 되는 기능"처럼 보인다.하지만 실제로 만들어보면 리포트 기능은 단순 조회 API와 다르다. 데이터 조회, 집계, 파일 생성, 작업 상태, 저장, 다운로드, 실패 처리까지 함께 설계해야 한다.버튼 하나 뒤에 있는 일들사용자는 하나의 버튼을 본다.[리포트 다운로드]하지만 시스템 내부에서는 여러 단계가 이어진다.요청 파라미터 검증-> 작업 생성-> 데이터 조회-> 집계 또는 가공-> 엑셀 파일 생성-> 파일 저장-> 작업 상태 갱신-> 다운로드 URL 제공이 중 하나라도 실패하면 사용자는 파일을 받지 못한다.그래서 리포트 기..

문서화와 인수인계 시리즈 9/9기술 블로그를 쓰려고 하면 종종 막막해진다.무엇을 써야 할지, 어디까지 공개해도 되는지, 이미 다른 사람이 더 잘 설명한 기술을 다시 써도 되는지 고민하게 된다.그럴 때 가장 좋은 재료 중 하나가 내가 실제로 남긴 실무 문서다.HANDOVER, 아키텍처 문서, ADR, 용어집, 트러블슈팅 가이드, 배포 가이드에는 내가 어떤 문제를 겪었고 어떻게 판단했는지가 들어 있다.이 문서들이 쌓이면 단순 기록을 넘어 개인의 일하는 방식을 보여주는 자산이 된다.기술 블로그는 지식 자랑이 아니다기술 블로그를 단순히 "내가 아는 것을 설명하는 공간"으로 보면 부담이 커진다.이미 공식 문서가 있고, 더 깊은 전문가의 글도 많다.하지만 실무 글의 가치는 다른 곳에 있다.내가 어떤 조건에서 어떤 ..

문서화와 인수인계 시리즈 8/9실무에서 만든 문서는 좋은 블로그 재료가 된다.아키텍처 문서, HANDOVER, 트러블슈팅 가이드, 배포 가이드, 용어집에는 실제 경험이 들어 있다. 검색해서 만든 글보다 훨씬 구체적이고, 판단의 흔적이 남아 있다.하지만 내부 문서를 그대로 공개하면 안 된다.실제 회사명, 도메인, 리소스 이름, API 경로, 인증 방식, 장애 날짜, 운영 데이터가 노출될 수 있다. 그래서 공개 글로 바꾸기 전에 익명화 과정이 필요하다.공개할 수 있는 것과 없는 것먼저 구분해야 한다.공개해도 좋은 것은 보편적인 판단 기준이다.왜 콘솔을 분리했는가왜 S3와 CloudFront를 썼는가왜 Lambda와 상주 서버를 나눴는가왜 job table로 비동기 작업을 관리했는가왜 CORS를 Gateway..

문서화와 인수인계 시리즈 7/9배포 가이드를 쓰다 보면 명령어만 나열하기 쉽다.npm run buildaws s3 sync build/ ...aws cloudfront create-invalidation ...물론 명령어는 필요하다. 하지만 배포 가이드가 명령어 모음으로 끝나면 위험하다.좋은 배포 가이드는 "무엇을 실행할지"뿐 아니라 "언제 실행하고, 무엇을 조심하고, 어떻게 확인하고, 실패하면 어떻게 되돌릴지"를 설명해야 한다.문제 상황운영 콘솔 배포에는 여러 종류가 있었다.React SPA 빌드 후 S3 업로드CloudFront 캐시 무효화Lambda 함수 코드 업데이트Lambda Layer 유지EC2의 Node API 서버 배포Google Apps Script 배포API Gateway stage 배..

문서화와 인수인계 시리즈 6/9장애가 나면 사람은 급해진다. 어디를 봐야 할지 기억나지 않고, 이전에 해결했던 문제도 다시 검색하게 된다. 로그 위치를 찾다가 시간을 쓰고, 같은 명령어를 다시 조합한다.그래서 트러블슈팅 문서는 장애가 난 뒤 쓰면 늦다.물론 실제 장애를 겪은 뒤 보강되는 부분은 있다. 하지만 최소한 자주 발생할 수 있는 증상과 확인 순서는 미리 정리해두는 것이 좋다.문제 상황운영 콘솔에서 반복적으로 나올 수 있는 문제는 대체로 정해져 있다.화면이 로딩되지 않는다.API 호출이 CORS 오류로 실패한다.데이터가 갱신되지 않는다.다운로드 작업이 끝나지 않는다.Lambda가 timeout 된다.DB 연결이 실패한다.배포했는데 이전 화면이 계속 보인다.이런 문제는 원인이 하나가 아니다. 화면이 ..

정산 업무는 단순히 금액을 더하고 빼는 일이 아니다.카테고리별 수수료율이 다르고, 예외 거래가 있고, 부분 환불이 있고, 공급가와 부가세를 나눠야 한다. 월마감 전에는 빠진 거래가 없는지도 확인해야 한다.문제는 이런 기준들이 보통 한 곳에 모여 있지 않다는 점이다.수수료율은 누군가의 기억에 있고, 예외 거래는 메신저에 남아 있고, 환불 반영 여부는 별도 파일을 봐야 한다. 파트너별 지급액은 매달 새로 피벗을 만들고, 월마감 체크는 구두로 끝나는 경우도 많다.이렇게 운영하면 정산은 언젠가 흔들린다.정산 업무를 엑셀로 관리해야 한다면, 최소한 아래 항목은 먼저 구조화해야 한다.카테고리별 수수료 규칙예외 거래 기준환불 반영 방식공급가와 부가세 분리 기준파트너별 지급액 계산 방식월마감 체크리스트정산 기준 변경 ..

3.3% 원천징수·연말정산·기한후신고 체크포인트 정리부업 수익이 있으면 3.3% 원천징수가 있었더라도 종합소득세 신고 대상 여부를 한 번 더 확인해보는 것이 좋습니다.특히 블로그 광고 수익, 외주 수익, 플랫폼 정산금, 전자책·강의 수익처럼 여러 형태의 부업 소득이 섞여 있다면 소득 유형과 지급 내역에 따라 확인 방식이 달라질 수 있습니다.실제로는 소액이라 괜찮겠지, 3.3%를 이미 떼였으니 끝난 것 아닐까, 직장인은 연말정산 했으니 별도 신고가 없겠지라고 생각했다가 뒤늦게 자료를 다시 정리하는 경우도 적지 않습니다.이 글에서는 부업 종합소득세와 관련해 많이 헷갈리는 체크포인트 5가지를 정리해보겠습니다.※ 본 글은 일반적인 종합소득세 확인 흐름을 설명한 정보성 콘텐츠입니다.실제 신고 대상 여부와 세액 판..

문서화와 인수인계 시리즈 5/9프로젝트 문서에 용어집이 필요한가?처음에는 과해 보일 수 있다. CORS, Lambda, CloudFront, API Gateway 같은 용어는 검색하면 정의가 나온다. 공식 문서도 있고, 블로그 글도 많다.하지만 프로젝트 안에서의 용어집은 일반 사전과 역할이 다르다.일반 사전은 "무엇인가"를 설명한다.프로젝트 용어집은 "이 프로젝트에서 왜 중요한가"를 설명한다.문제 상황운영 콘솔 문서를 정리하면서 여러 기술 용어가 반복해서 등장했다.CORSpreflightAPI GatewayLambda Function URLLambda LayerCloudFrontCache TTLinvalidationSSO cookiewithCredentialsSource of Truthjob tablec..

문서화와 인수인계 시리즈 4/9아키텍처 결정 기록, 흔히 ADR이라고 부르는 문서는 거창해 보인다. 대규모 조직이나 플랫폼 팀에서나 쓰는 문서처럼 느껴질 수도 있다.하지만 작은 운영 도구를 만들 때도 ADR은 필요하다.이유는 단순하다. 시간이 지나면 왜 그렇게 만들었는지 잊어버리기 때문이다.코드는 최종 결과만 보여준다. 하지만 그 결과에 도달하기까지의 선택지, 제약, 포기한 것, 다시 검토해야 할 조건은 코드에 남지 않는다.문제 상황운영 콘솔을 만들면서 여러 결정을 내려야 했다.React SPA를 어디에 배포할 것인가API 앞에 Gateway를 둘 것인가Lambda만 쓸 것인가, 상주 서버도 둘 것인가RDB를 둘 것인가, 파일 기반 저장소로 충분한가오래 걸리는 엑셀 생성은 동기 API로 처리할 것인가CO..