StudyDad

생각을 내 것으로 만드는 기록 4/7나는 꽤 자주 안다고 생각했다.문서를 읽었고, 내용도 낯설지 않았다.내가 만든 글이었고, 내가 겪은 일이기도 했다.그래서 알고 있다고 생각했다.그런데 설명하려고 하면 막혔다.그때 알게 됐다.아는 것과 이해한 것은 달랐다.안다는 느낌은 빨리 왔다안다는 느낌은 생각보다 빨리 왔다.제목을 보면 대충 무슨 이야기인지 알 것 같았다.문단을 읽으면 흐름도 자연스러웠다.내가 직접 말했던 내용이 들어 있으면 더 그랬다.이건 내가 아는 이야기라고 생각했다.하지만 그건 익숙함에 가까웠다.내가 이미 본 문장을 다시 보는 느낌이었다.익숙하다고 해서 이해한 것은 아니었다.이해는 연결할 때 드러났다이해는 다른 곳에서 드러났다.문장 하나를 아는 것이 아니라, 문장 사이를 연결할 수 있는지에서 드..

생각을 내 것으로 만드는 기록 3/7읽을 때는 알 것 같았다.문장도 자연스러웠고, 흐름도 이상하지 않았다.이 정도면 됐다고 생각했다.그런데 문서를 잠깐 덮고 내가 이해한 흐름을 말하려고 하면 중간에서 막혔다.읽을 때는 지나갔던 부분이 말하려고 하면 걸렸다. 외워서 말하려는 게 아닌데도 그랬다.그때 이상했다.나는 읽었는데, 왜 설명하지 못할까.읽을 때는 쉬웠다읽는 동안에는 크게 어렵지 않았다.AI가 정리한 문장은 매끄러웠다.내가 말한 내용도 들어 있었다.틀린 말도 많지 않았다.그래서 검토하면서 고개를 끄덕였다.이 정도면 괜찮겠다고 생각했다.하지만 그건 문서를 보면서 한 판단이었다.문서가 옆에 있을 때는 흐름을 따라가면 됐다.내가 직접 흐름을 만들어야 하는 건 아니었다.설명하려고 하니 막혔다문서를 잠깐 덮고..

생각을 내 것으로 만드는 기록 2/7처음부터 많이 만들고 싶었던 건 아니었다.불안했다.그래서 만들었다.블로그 글을 만들었다.incident RCA 문서를 만들었다.Datadog 운영 가이드를 만들었다.온보딩 audit 자료도 만들었다.GitHub에는 repo가 하나씩 늘어났다.새 파일이 생기면 잠깐 괜찮아졌다.그런데 시간이 조금 지나면 다시 다른 것을 만들고 있었다.불안해서 만들었고, 만들어도 불안은 줄지 않았다.만들면 잠깐 안심이 됐다새 파일을 만들면 안심이 됐다.폴더가 생기고, README가 생기고, 커밋이 생기면 뭔가 정리된 것 같았다.특히 회사에 남은 시간이 정해져 있다는 생각이 컸다.지금 정리할 수 있을 때 정리해두어야 한다고 생각했다.그 생각 자체가 틀렸다고 보지는 않는다.지금 정리해둘 수 있..

생각을 내 것으로 만드는 기록 1/7권고사직 이후 나는 만드는 속도가 이상할 정도로 빨라졌다.블로그 글을 만들었다. incident RCA 문서를 정리했다. Datadog 운영 가이드도 만들었다. 온보딩 audit 자료도 만들었다. GitHub에는 관련 repo들이 하나씩 늘어났다.하나씩 보면 다 필요한 일이었다.그런데 이상한 점이 있었다.많이 만들었는데, 내 안에 들어오지는 않았다.문서는 있었다문서는 있었다.제목도 있었다.정리도 되어 있었다.파일명도 꽤 그럴듯했다.그런데 막상 누군가에게 설명하려고 하면 말이 바로 나오지 않았다. 분명 내가 만든 문서인데, 다시 열어보기 전에는 핵심이 떠오르지 않았다.처음에는 자료가 너무 많아서 그런 줄 알았다.그래서 더 정리했다. 폴더를 만들고, 파일명을 맞추고, 요약..

운영 콘솔 아키텍처 시리즈 9/9아키텍처 문서를 쓸 때 가장 쉬운 방식은 구성도를 그리고 사용한 기술을 나열하는 것이다.React, S3, CloudFront, API Gateway, Lambda, RDB, Express.이 정보도 필요하다. 하지만 시간이 지나면 더 중요한 질문이 남는다.왜 그렇게 했는가?문제 상황운영 콘솔은 한 번 만들고 끝나는 도구가 아니다. 기능이 추가되고, 사용자 범위가 바뀌고, 데이터가 늘고, 장애가 발생한다. 그때마다 처음 설계한 사람이 모든 맥락을 기억하고 있을 수는 없다.특히 다음 질문은 반복해서 돌아온다.왜 콘솔을 하나로 합치지 않았는가왜 RDB를 쓰지 않았는가왜 Lambda 앞에 API Gateway를 뒀는가왜 일부 API는 상주 서버로 처리했는가왜 리포트 생성을 비동..

운영 콘솔 아키텍처 시리즈 8/9관리자 페이지를 만들다 보면 CORS 에러를 자주 만난다. 로컬에서는 되는데 배포하면 안 되고, GET은 되는데 POST는 안 되고, 쿠키를 보내면 갑자기 막힌다.CORS는 브라우저가 까다롭게 구는 문제가 아니다. 브라우저 보안 모델이다. 특히 React SPA처럼 정적 파일 도메인과 API 도메인이 분리된 구조에서는 CORS와 쿠키 인증을 처음부터 같이 설계해야 한다.문제 상황운영 콘솔은 console.example.com에서 서빙된다. API는 api.example.com에 있다. 두 주소는 host가 다르므로 서로 다른 origin이다.브라우저의 origin은 세 가지로 결정된다.scheme + host + port따라서 다음 두 주소는 다른 origin이다.http..

운영 콘솔 아키텍처 시리즈 7/9운영 콘솔에는 버튼을 누르면 파일을 만들어 내려받는 기능이 자주 있다. 엑셀, CSV, 집계표, 분석 리포트 같은 것들이다. 처음에는 단순하게 생각하기 쉽다.사용자가 요청한다. 서버가 데이터를 조회한다. 파일을 만든다. 응답으로 내려준다.작은 데이터라면 이 방식도 괜찮다. 하지만 작업이 수 초에서 수십 초 걸리기 시작하면 동기 HTTP 요청 안에서 끝내는 방식은 금방 한계에 부딪힌다.문제 상황리포트 생성은 다음 특성을 가졌다.여러 테이블에서 데이터를 조회한다.파일 생성 시간이 데이터 양에 따라 달라진다.브라우저가 응답을 기다리는 동안 사용자는 아무것도 알 수 없다.API Gateway나 프록시에는 timeout이 있다.실패했을 때 어디까지 진행됐는지 추적해야 한다.동기 A..

운영 콘솔 아키텍처 시리즈 6/9서버리스는 운영 부담을 크게 줄여준다. 트래픽이 없을 때 비용이 거의 없고, 갑작스러운 요청도 자동으로 확장된다. 그래서 운영 콘솔을 만들 때 모든 API를 Lambda로 만들고 싶어질 수 있다.하지만 모든 요청이 Lambda에 잘 맞는 것은 아니다. 반대로 모든 요청을 상주 서버로 처리하는 것도 답은 아니었다.문제 상황운영 리포트 콘솔에는 성격이 다른 API가 섞여 있었다.하나는 대시보드나 목록 조회처럼 짧고 자주 호출되는 API다. 내부 운영자가 화면을 이동할 때마다 호출되고, 응답은 빠를수록 좋다. 내부 인증 쿠키를 확인하고, RDB 커넥션 풀을 사용해 여러 집계 쿼리를 실행한다.다른 하나는 리포트 생성처럼 드물지만 오래 걸리는 API다. 사용자가 버튼을 누르면 수 ..

운영 콘솔 아키텍처 시리즈 5/9Lambda를 HTTP로 호출하려면 가장 단순한 방법은 Lambda Function URL이다. 별도 게이트웨이 없이 함수에 HTTPS URL을 붙일 수 있다. 작은 API라면 이 방식이 충분할 때도 많다.그런데 운영 콘솔의 API 앞에는 API Gateway를 뒀다. 단순히 "원래 그렇게 하니까"가 아니라, 브라우저 기반 콘솔에서 필요한 운영 기능을 한곳에서 처리하기 위해서였다.문제 상황운영 콘솔 API는 브라우저에서 호출된다. 정적 SPA는 console.example.com에서 서빙되고, API는 api.example.com 또는 클라우드 API 도메인에서 제공된다. 이 순간 CORS가 발생한다.또한 API는 하나의 엔드포인트가 아니었다. 동기화, 조회, 리포트 생성..

운영 콘솔 아키텍처 시리즈 4/9운영 도구를 만들 때 가장 먼저 데이터베이스를 떠올리는 경우가 많다. 목록이 있고, 상태가 있고, 조회 화면이 있으면 자연스럽게 RDB 테이블을 설계하게 된다.하지만 모든 운영 콘솔에 데이터베이스가 필요한 것은 아니다. 어떤 경우에는 데이터베이스를 추가하지 않는 것이 더 단순하고 안전한 결정이 될 수 있다.문제 상황신청 관리 콘솔의 데이터 원천은 이미 외부에 있었다. 외부 파트너는 폼 도구로 신청했고, 운영자는 스프레드시트에서 데이터를 검수하고 상태를 관리했다. 스프레드시트가 사실상 Source of Truth였다.콘솔은 이 데이터를 더 보기 좋게 보여주고, 공개 가능한 일부 데이터를 외부에 노출하면 됐다. 데이터 규모는 크지 않았고, 변경도 특정 시점에 몰렸다. 초당 수..