StudyDad

운영 콘솔 아키텍처 시리즈 9/9아키텍처 문서를 쓸 때 가장 쉬운 방식은 구성도를 그리고 사용한 기술을 나열하는 것이다.React, S3, CloudFront, API Gateway, Lambda, RDB, Express.이 정보도 필요하다. 하지만 시간이 지나면 더 중요한 질문이 남는다.왜 그렇게 했는가?문제 상황운영 콘솔은 한 번 만들고 끝나는 도구가 아니다. 기능이 추가되고, 사용자 범위가 바뀌고, 데이터가 늘고, 장애가 발생한다. 그때마다 처음 설계한 사람이 모든 맥락을 기억하고 있을 수는 없다.특히 다음 질문은 반복해서 돌아온다.왜 콘솔을 하나로 합치지 않았는가왜 RDB를 쓰지 않았는가왜 Lambda 앞에 API Gateway를 뒀는가왜 일부 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였다.콘솔은 이 데이터를 더 보기 좋게 보여주고, 공개 가능한 일부 데이터를 외부에 노출하면 됐다. 데이터 규모는 크지 않았고, 변경도 특정 시점에 몰렸다. 초당 수..

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