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

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

ADR 3

"무엇을 썼는가"보다 "왜 선택했는가"를 기록하기

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

ADR은 면접 답변이 아니라 운영 자산이다

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

인수인계 문서는 코드 설명서가 아니라 운영 지도다

문서화와 인수인계 시리즈 1/9프로젝트를 넘겨줄 때 가장 먼저 떠올리는 문서는 보통 README다. 설치 방법, 실행 방법, 폴더 구조, 주요 명령어를 적는다. README는 중요하다. 하지만 실제 운영 중인 시스템을 넘겨줄 때 README만으로는 부족하다.운영 중인 시스템에는 코드 밖의 정보가 많다. 어디에 배포되어 있는지, 어떤 API가 어떤 저장소를 보는지, 장애가 나면 어떤 로그를 봐야 하는지, 배포할 때 어떤 파일을 건드리면 안 되는지, 특정 기능이 느릴 때 어디부터 확인해야 하는지 같은 정보다.이런 정보는 코드만 읽어서는 바로 알기 어렵다. 그래서 인수인계 문서는 코드 설명서가 아니라 운영 지도여야 한다.문제 상황운영 콘솔 두 개를 정리하면서 비슷한 문제가 보였다.하나는 외부 입력과 공개 페이..