StudyDad Loop 제품을 만들며 배운 운영과 설계를 기록합니다.

FamBlend를 중심으로 실제 구현, 운영 메모, GitHub 포트폴리오를 연결해 쌓아가는 StudyDad의 작업 기록입니다.

반응형

전체 글 179

아들에게 무엇을 남겨야 할지 모르겠던 어느 날

Volume 01. 나와 아이의 내면밤 10시 반, 셔틀버스에서 내린 아이가 지친 발걸음으로 들어선다.하지만 집은 곧바로 쉼터가 되지 못한다. 가방을 내려놓기 무섭게 아이는 다시 책상 앞에 앉는다. 학원 숙제와 학교 공부가 기다리고 있고, 그 옆에는 아내가 자리를 잡고 앉는다.두 사람 사이에는 이내 날카로운 말들이 오고 간다. 피곤함에 겨워 조는 아이를 보며, 하루 종일 일과 가사에 지친 아내의 목소리도 함께 높아진다.“집중 안 해? 아까 오자마자 게임을 하더니, 끝내놓고 했어야지.”아이는 짜증이 섞인 눈으로 모니터를 노려본다. 수행평가를 붙잡고 끙끙대는 아이와 이미 방전되어 버린 엄마 사이에 깊은 감정의 골이 서서히 드러난다. 밤이 깊어갈수록 방 안은 피로와 원망으로 무겁게 가라앉는다.그렇게 밤 12시..

Job table로 리포트 작업 상태 관리하기

데이터와 리포트 설계 시리즈 3/8오래 걸리는 리포트 생성을 비동기로 처리하려면 작업 상태를 저장할 곳이 필요하다.메모리에 상태를 들고 있으면 안 된다.서버가 재시작될 수 있고, Lambda는 실행 환경이 유지된다는 보장이 없으며, 운영자는 나중에 작업 이력을 확인해야 한다.그래서 job table이 필요하다.job table의 역할job table은 리포트 생성 작업의 기록장이다.사용자가 리포트를 요청하면 먼저 job row를 만든다.worker는 이 job을 처리하면서 상태를 갱신한다.프론트엔드는 job id로 상태를 조회한다.job table이 있으면 작업은 추적 가능한 단위가 된다.기본 상태 모델처음에는 단순한 상태만으로도 충분하다.PENDINGIN_PROGRESSCOMPLETEFAILED각 상태..

오래 걸리는 엑셀 생성을 동기 API로 처리하면 생기는 문제

데이터와 리포트 설계 시리즈 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 연결이 실패한다.배포했는데 이전 화면이 계속 보인다.이런 문제는 원인이 하나가 아니다. 화면이 ..

정산 업무를 엑셀로 관리할 때 가장 먼저 정리해야 하는 것

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

부업 종합소득세 신고 전에 확인할 5가지

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

돈/세금 2026.05.26
반응형