StudyDad

AI 장애 분석 포스트모템 시리즈 1/9Datadog에서 GET /heartbeat trace 하나가 30초 timeout 경계에 붙어 있는 화면을 보고 있었습니다. 같은 시점에 JVM Old Gen이 올라와 있었습니다.초기 단서: 일부 GET /heartbeat span이 30초 timeout 경계에 붙어 있었습니다.이 스크린샷 한 장을 Claude Code에 붙여두고 원인을 물어보려고 했습니다. 그런데 프롬프트를 어떻게 써야 하나 잠깐 고민하다가 이상한 점이 보였습니다. AI가 볼 수 있는 건 이 화면 한 장뿐이었습니다.프롬프트보다 먼저 막힌 지점먼저 Datadog API Key와 Application Key를 환경변수로 붙였습니다. /api/v1/validate는 성공했습니다. metric quer..

자동화 워크플로우 시리즈 8/8자동화의 목표는 사람이 하지 않아도 되는 일을 줄이는 것이다.하지만 좋은 자동화는 사람을 완전히 배제하지 않는다.오히려 실패했을 때 사람이 어디를 보고, 무엇을 다시 실행하고, 어떤 상태로 되돌릴 수 있는지 준비해둔다.자동화는 언젠가 실패한다. 네트워크가 끊길 수 있고, API가 실패할 수 있고, 스크립트 제한에 걸릴 수 있고, 원천 데이터가 잘못될 수도 있다.그래서 자동화 시스템에는 수동 복구 경로가 필요하다.문제 상황스프레드시트 기반 자동화 흐름은 여러 계층을 지난다.폼 제출-> 스프레드시트 기록-> Apps Script 실행-> API 호출-> Lambda 처리-> S3 JSON 저장-> 화면 반영이 중 하나만 실패해도 화면 데이터가 갱신되지 않거나, 공개 데이터가 오..

자동화 워크플로우 시리즈 7/8운영 자동화에서 자주 놓치는 지점이 있다.내부에서 보는 데이터와 외부에 보여줄 데이터는 같지 않다.같은 원천에서 만들어졌더라도 공개 화면에 나가는 데이터는 반드시 별도로 가공해야 한다.화면에서 숨기는 것만으로는 충분하지 않다. API 응답이나 JSON 파일에 포함된 정보는 사용자가 개발자 도구로 볼 수 있다.문제 상황운영자는 신청 데이터를 자세히 봐야 한다.신청자 정보, 내부 상태, 검토 메모, 처리 결과, 예외 여부 같은 정보가 필요하다.하지만 외부 사용자에게 공개해야 하는 정보는 훨씬 제한적이다.예를 들어 공개 페이지에는 일정, 신청 가능 여부, 집계 결과, 가격 범위, 상태 정도만 보여주면 될 수 있다.이때 내부 데이터를 그대로 내려주고 화면에서 일부 필드를 숨기면 위..

자동화 워크플로우 시리즈 6/8운영 자동화에서 데이터를 파일로 저장할 때 흔히 하나의 JSON만 만들고 싶어진다.data.json처음에는 충분해 보인다. 화면은 최신 데이터만 읽으면 되고, 동기화할 때 파일을 덮어쓰면 된다.하지만 운영하다 보면 최신 데이터 하나만으로는 부족하다.언제 어떤 데이터가 동기화되었는지, 월별로 어떤 상태였는지, 문제가 생겼을 때 어디로 되돌아가야 하는지 알 수 있어야 한다.그래서 최신 데이터, 월별 스냅샷, 감사 백업을 나눠 저장하는 구조가 필요하다.문제 상황스프레드시트를 원천 데이터로 두고, 화면 제공을 위해 JSON 파일을 생성해야 했다.필요한 데이터는 하나가 아니었다.운영자 화면이 읽는 최신 데이터월별 화면이나 기록을 위한 스냅샷외부 사용자에게 보여줄 공개용 데이터동기화 ..

자동화 워크플로우 시리즈 5/8Google Apps Script에서 AWS S3로 파일을 직접 업로드할 수도 있다.이론적으로는 가능하다. AWS Signature Version 4 서명을 직접 만들고, S3 PUT 요청을 보내면 된다.하지만 운영 자동화에서는 "가능하다"와 "좋은 선택이다"가 다르다.나는 Apps Script가 S3에 직접 쓰는 방식보다, API Gateway와 Lambda를 경유해 S3 저장을 위임하는 구조가 더 낫다고 봤다.문제 상황스프레드시트의 데이터를 가공해 JSON 파일로 저장해야 했다.이 JSON은 운영자 화면과 공개 페이지에서 읽을 데이터였다.구조는 단순해 보인다.Sheets-> Apps Script-> S3 JSON-> Console/Public page여기서 선택지는 두 ..

자동화 워크플로우 시리즈 4/8Google Sheets를 운영 데이터의 원천으로 두면 자연스럽게 Google Apps Script를 쓰게 된다.폼 제출 이벤트를 받을 수 있고, 시트 데이터를 읽고 쓸 수 있으며, 외부 API도 호출할 수 있다.이 정도면 작은 운영 자동화에서는 충분히 비즈니스 로직 엔진 역할을 할 수 있다.하지만 Apps Script는 만능 백엔드가 아니다. 잘 맞는 역할과 넘기면 안 되는 역할을 구분해야 한다.Apps Script가 자연스러운 위치스프레드시트 중심의 업무에서 Apps Script는 데이터 가까이에 있다.예를 들어 다음 작업을 하기에 좋다.폼 제출 시 후처리입력값 정리상태값 업데이트특정 조건의 행 필터링운영자용 메뉴 추가외부 API 호출JSON 데이터 생성정기 동기화 실행..

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

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

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