다시 설계한다면 무엇을 바꿀까

기술 실무 설계 시리즈 8/8

좋은 설계는 영구적인 정답이 아니다.

당시의 조건에서 합리적이었던 선택도 시간이 지나면 다시 볼 수 있다.

사용자가 늘고, 작업량이 늘고, 보안 요구사항이 바뀌고, 운영 인력이 달라지면 설계도 달라져야 한다.

그래서 설계 회고에는 "다시 설계한다면 무엇을 볼 것인가"가 필요하다.

지금 구조가 틀렸다는 뜻은 아니다

다시 설계한다는 말은 현재 구조가 틀렸다는 뜻이 아니다.

현재 구조는 당시 조건에서 합리적일 수 있다.

예를 들어 작은 운영 콘솔에서는 다음 선택이 충분히 현실적이다.

• React SPA를 S3와 CloudFront에 배포
• 이벤트성 작업은 Lambda
• 잦은 조회는 상주 API 서버
• 결과 파일은 object storage
• 초기 자동화는 Apps Script와 Sheets 활용
• job table로 비동기 작업 관리

하지만 이 구조에도 다음 단계가 있다.

1. EC2에서 ECS/Fargate로

상주 API 서버를 EC2 + Docker로 운영하는 것은 작은 규모에서 단순하다.

하지만 다음 조건이 생기면 ECS/Fargate를 검토할 수 있다.

• 컨테이너가 여러 개로 늘어난다.
• 무중단 배포가 필요하다.
• 오토스케일링이 필요하다.
• 단일 EC2 장애가 부담된다.
• 서버 패치 책임을 줄이고 싶다.

처음부터 ECS를 쓰지 않아도 된다.

하지만 Docker image 기반으로 운영해두면 나중에 이동하기 쉽다.

2. RDS Proxy 도입

Lambda가 RDS를 자주 호출하면 connection 문제가 생길 수 있다.

작업량이 적을 때는 괜찮지만 동시 실행이 늘어나면 DB connection count가 부담이 된다.

이때 RDS Proxy를 검토한다.

검토 조건:

• Lambda 동시 실행이 늘어난다.
• RDS connection이 불안정하다.
• connection storm이 우려된다.
• 상주 서버로 옮기기 애매한 워크로드가 있다.

3. WAF와 API 인증 강화

프론트엔드 CloudFront에 WAF를 붙였다고 API까지 보호되는 것은 아니다.

API Gateway 직접 URL이나 origin 직접 접근 경로는 별도 보안 정책이 필요할 수 있다.

다시 설계한다면 다음을 더 일찍 점검할 수 있다.

• API Gateway 인증
• API Key 또는 IAM
• Lambda Authorizer
• WAF 적용 범위
• origin 직접 접근 제한
• CORS와 인증의 경계

보안은 화면 접근 제한만으로 끝나지 않는다.

4. 비동기 작업에 Queue 도입

초기에는 Lambda 비동기 호출이나 단순 job table로 충분할 수 있다.

하지만 작업량이 늘면 queue가 필요해질 수 있다.

검토 조건:

• 리포트 요청이 특정 시간에 몰린다.
• worker 동시 실행 수를 제어해야 한다.
• 실패 작업을 보존해야 한다.
• 재시도와 DLQ가 필요하다.
• API와 worker 결합도를 낮추고 싶다.

queue는 복잡도를 늘리지만 작업 흐름을 더 안정적으로 만든다.

5. 공통 패키지화

처음부터 공통화를 하지 않는 것은 좋은 선택일 수 있다.

하지만 반복이 충분히 관찰되면 공통 패키지를 만들 수 있다.

후보:

• UI primitive
• 에러 처리
• 날짜/숫자 포맷
• API response 타입
• 배포 체크리스트
• 문서 템플릿

다만 인증, 권한, 데이터 접근처럼 도메인 의존성이 큰 영역은 여전히 신중해야 한다.

6. 관측성 강화

초기에는 CloudWatch Logs와 기본 metric만으로 충분할 수 있다.

하지만 장애 분석이 반복되면 관측성을 강화해야 한다.

검토 후보:

• API Gateway access log 표준화
• Lambda structured logging
• request id 전파
• CloudFront log 분석
• X-Ray tracing
• 리포트 job metric
• 알림 설정

로그는 많을수록 좋은 것이 아니라 연결될수록 좋다.

7. 파일 lifecycle 정책

리포트 파일과 감사 백업은 시간이 지나면 쌓인다.

처음에는 신경 쓰지 않아도 되지만, 일정 기간이 지나면 정책이 필요하다.

검토할 것:

• 파일 보관 기간
• 오래된 파일 삭제
• storage class 전환
• 민감 데이터 포함 파일 만료
• 감사 백업 보존 기준

파일을 생성하는 기능에는 삭제 정책도 포함되어야 한다.

8. 문서 자동화와 최신성

문서는 만들기보다 유지가 어렵다.

다시 설계한다면 문서 최신성을 더 쉽게 확인하는 장치를 둘 수 있다.

예를 들어:

• 배포 스크립트와 문서 링크 연결
• 리소스 목록 자동 생성
• README에서 관련 문서 인덱스 제공
• ADR 업데이트 기준 정의
• 장애 후 트러블슈팅 문서 업데이트 체크

문서도 운영 시스템의 일부로 봐야 한다.

하지 않은 선택도 기록하기

설계 회고에서 중요한 것은 "다음에 할 것"만이 아니다.

"지금은 하지 않은 것"도 기록해야 한다.

예를 들어:

• 지금은 ECS를 쓰지 않는다.
• 지금은 RDS Proxy를 쓰지 않는다.
• 지금은 WebSocket 대신 polling을 쓴다.
• 지금은 S3 JSON으로 충분하다.
• 지금은 수동 invalidation으로 충분하다.

그리고 이유를 함께 남긴다.

이 기록이 있어야 나중에 같은 논의를 반복하지 않는다.

정리

다시 설계한다면 무엇을 바꿀지 생각하는 것은 현재 설계를 부정하는 일이 아니다.

오히려 현재 설계의 유효 범위를 명확히 하는 일이다.

좋은 설계는 정답이 아니라 조건부 결정이다.

지금은 단순한 구조가 맞지만, 어떤 조건이 되면 다음 단계로 갈지 알고 있어야 한다.

설계 회고는 다음 설계의 입력값이다.

하지 않은 선택과 다시 검토할 조건까지 문서화할 때, 작은 운영 도구도 더 오래 버틸 수 있다.

함께 볼 GitHub 저장소

• practical-system-design-playbook