내부 도구에서 충분히 좋은 설계를 판단하는 기준

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

내부 운영 도구를 만들 때 가장 어려운 질문 중 하나는 이것이다.

어디까지 설계해야 충분한가?

너무 단순하게 만들면 나중에 운영 문제가 생긴다.

반대로 처음부터 대규모 서비스처럼 만들면 개발 속도와 유지보수 비용이 과해진다.

내부 도구에는 내부 도구에 맞는 "충분히 좋은 설계" 기준이 필요하다.

완벽한 설계는 목표가 아니다

운영 도구는 대개 제한된 시간 안에 만들어진다.

대규모 사용자 트래픽보다 특정 업무를 안정적으로 처리하는 것이 목표다.

그래서 완벽한 설계보다 중요한 것은 다음이다.

• 업무를 막지 않는가
• 문제가 생겼을 때 복구 가능한가
• 담당자가 바뀌어도 이해할 수 있는가
• 변경이 필요한 곳이 좁은가
• 지금 규모에서 운영 부담이 과하지 않은가

완벽함보다 복구 가능성이 더 중요할 때가 많다.

기준 1. 사용자 수가 아니라 업무 영향도

내부 도구는 사용자가 적다.

하지만 업무 영향도는 클 수 있다.

따라서 설계 수준은 사용자 수만으로 정하면 안 된다.

다음 질문을 본다.

• 이 도구가 멈추면 어떤 업무가 멈추는가
• 수동으로 대체할 수 있는가
• 대체한다면 시간이 얼마나 걸리는가
• 월말이나 특정 기간에 중요도가 올라가는가
• 외부 사용자에게도 영향이 있는가

사용자가 적어도 업무 영향도가 크면 더 안정적인 설계가 필요하다.

기준 2. 변경 빈도

변경이 잦은 영역은 단단한 경계가 필요하다.

예를 들어:

• 리포트 형식이 자주 바뀐다.
• 입력 항목이 자주 바뀐다.
• 운영 정책이 자주 바뀐다.
• 화면 구성은 바뀌지만 데이터 원천은 안정적이다.

변경이 잦은 부분과 안정적인 부분을 분리하면 유지보수가 쉬워진다.

반대로 모두 한 덩어리로 묶으면 작은 변경도 전체 배포로 이어진다.

기준 3. 장애 영향 범위

충분히 좋은 설계는 장애가 나지 않는 구조가 아니다.

장애가 나도 영향 범위가 제한되는 구조다.

예를 들어:

• 프론트엔드 배포 문제가 API를 망가뜨리지 않는다.
• 리포트 worker 실패가 대시보드 조회를 막지 않는다.
• 공개 페이지 오류가 내부 운영 화면에 영향을 주지 않는다.
• 데이터 동기화 실패가 원천 데이터를 훼손하지 않는다.

장애를 완전히 피할 수는 없다.

하지만 장애가 어디까지 번질지는 설계할 수 있다.

기준 4. 운영 인력

운영할 사람이 얼마나 있는지도 중요하다.

운영 인력이 적다면 복잡한 인프라보다 단순한 매니지드 서비스를 쓰는 것이 낫다.

예를 들어:

• 정적 프론트엔드는 S3 + CloudFront
• 이벤트성 작업은 Lambda
• 단순 데이터 캐시는 S3 JSON
• 복잡한 오케스트레이션은 나중에 검토

기술적으로 더 멋진 구조보다 운영할 수 있는 구조가 낫다.

기준 5. 보안 요구사항

내부 도구라고 해서 보안을 가볍게 보면 안 된다.

오히려 내부 도구에는 운영 데이터나 민감한 정보가 들어갈 수 있다.

다음 질문을 봐야 한다.

• 내부 사용자만 접근해야 하는가
• 외부 공개 페이지가 있는가
• 공개 데이터와 내부 데이터가 분리되어 있는가
• API는 프론트엔드 접근 제한과 별도로 보호되는가
• 쿠키나 인증 정보가 cross-origin 요청에 포함되는가

보안은 나중에 붙이는 장식이 아니다.

도메인, API, 데이터 응답 구조와 함께 설계해야 한다.

기준 6. 비용보다 운영 복잡도

클라우드 비용은 눈에 보인다.

하지만 운영 복잡도는 잘 보이지 않는다.

월 몇 달러를 아끼려고 사람이 매번 수동 배포하거나, 장애 때마다 콘솔을 뒤져야 한다면 실제 비용은 더 클 수 있다.

충분히 좋은 설계는 비용과 운영 복잡도를 함께 본다.

• 고정비를 줄인다.
• 사람이 반복 확인할 일을 줄인다.
• 배포 절차를 단순화한다.
• 로그 위치를 문서화한다.
• 복구 경로를 만든다.

기준 7. 다음 단계가 열려 있는가

처음부터 완전한 구조를 만들 필요는 없다.

하지만 나중에 바꿀 수 있어야 한다.

예를 들어:

• EC2 + Docker로 시작하되 ECS로 옮길 수 있게 이미지 기반으로 둔다.
• S3 JSON으로 시작하되 데이터 규모가 커지면 DB 전환 조건을 문서화한다.
• Lambda로 시작하되 DB connection 문제가 생기면 RDS Proxy를 검토한다.
• 수동 배포로 시작하되 배포 절차를 문서화해 자동화 여지를 남긴다.

충분히 좋은 설계는 현재에 맞으면서 다음 이동 경로가 보이는 설계다.

정리

내부 도구에서 충분히 좋은 설계는 완벽한 설계가 아니다.

다음 조건을 만족하는 설계다.

• 업무를 안정적으로 처리한다.
• 장애 영향 범위를 제한한다.
• 변경이 잦은 부분을 분리한다.
• 운영 인력이 감당할 수 있다.
• 보안 경계를 놓치지 않는다.
• 비용과 운영 복잡도를 함께 본다.
• 나중에 바꿀 조건을 알고 있다.

작은 운영 도구에는 작은 도구에 맞는 설계 기준이 필요하다.

그 기준을 세우면 과한 설계와 부족한 설계 사이에서 더 현실적인 선택을 할 수 있다.

함께 볼 GitHub 저장소

• practical-system-design-playbook