📋 목차
🤔 왜 아키텍처 성과는 '보이지 않는다'고 느껴지는가
영업직은 매출 숫자가 있다. 마케터는 전환율이 있다. 그런데 아키텍처를 설계한 엔지니어는 무엇으로 성과를 말하는가? 많은 개발자들이 "좋은 구조를 만들었는데 설명하기 어렵다"고 토로한다. 이 문제는 측정하지 않았기 때문이 아니라, 측정 시점과 기록 방식이 없었기 때문이다.
서버가 안 죽고, 응답이 빠르고, 비용이 줄면 — 사용자도, 경영진도 그냥 당연하게 여긴다. 성과를 기록하지 않으면, 당신이 한 일은 사라진다.
아키텍처 설계 성과를 기록하지 못하는 3가지 전형적인 이유가 있다.
📐 3가지 핵심 성과 축: 비용·속도·안정성
아키텍처 설계의 성과는 크게 세 가지 축으로 분류된다. 평가자(팀장, 임원)가 실제로 관심을 갖는 언어로 정리하면 다음과 같다.
어떤 지표를 먼저 기록해야 할까?
| 우선순위 | 지표 | 왜 중요한가 | 측정 도구 |
|---|---|---|---|
| 🥇 최우선 | 월 인프라 비용 | 경영진이 가장 즉각 이해하는 지표 | AWS Cost Explorer, GCP Billing |
| 🥈 중요 | API p95 응답시간 | 사용자 체감 품질과 직결 | Datadog, New Relic, Grafana |
| 🥉 보완 | 서비스 가용성 (%) | SLA 준수 여부로 신뢰도 증명 | PagerDuty, StatusPage |
| 🔖 추가 | DB 쿼리 실행시간 | 기술 심층 기여 증명용 | Slow Query Log, explain |
🧮 성과 수치화 공식 (예시 포함)
아키텍처 성과를 기록하는 데 가장 유용한 공식 4가지다. 각각 '비용 절감형', '속도 개선형', '안정성 향상형', '복합 환산형'으로 나뉜다.
📌 공식 1 — 비용 절감형
절감액(월) = 변경 전 비용 − 변경 후 비용
예시: EC2 인스턴스 최적화(c5.4xlarge → c6g.2xlarge) 후 월 AWS 비용 $3,200 → $1,850 → 월 $1,350 절감 (연간 약 $16,200)
📌 공식 2 — 속도 개선형
개선율(%) = (Before − After) ÷ Before × 100
예시: Redis 캐싱 레이어 도입 후 상품 조회 API p95 응답시간 890ms → 134ms → 84.9% 응답 속도 개선
📌 공식 3 — 안정성 향상형
가용성(%) = 정상 운영 시간 ÷ 전체 시간 × 100
예시: 멀티 AZ 아키텍처 전환 후 월간 서비스 가용성 99.1% → 99.97% → 장애 발생 시간 연간 約39시간 → 約2.6시간으로 단축
📌 공식 4 — 복합 환산형 (가장 강력)
비즈니스 임팩트 = 기술 개선 × 단위당 환산 기준
예시: 결제 API 응답속도 1.2s → 0.3s 개선 → 전환율 2.1%p 상승 (내부 A/B 데이터 기준) → 월 거래액 기준 약 +3.8억 원 기여 추정
✏️ Before/After 기록 실전 예시
실제 성과 평가 시즌에 제출할 수 있는 수준의 표현법을 Before/After로 비교한다. 동일한 작업이라도 기록 방식에 따라 평가자의 인식이 크게 달라진다.
Case 1 — 서버 아키텍처 재설계 (비용 절감)
❌ BEFORE — 기술 언어 나열
"모노리식 EC2 인스턴스를 ECS Fargate로 마이그레이션하고, ALB 기반 오토스케일링을 적용함."
✅ AFTER — 성과 언어 전환
"EC2 온디맨드 인스턴스를 ECS Fargate + 오토스케일링 구조로 전환하여, 월 AWS 비용 $4,100 → $2,350으로 $1,750(43%) 절감. 동시에 트래픽 피크 시 수동 스케일업 공수 제거 → 팀 운영 시간 월 약 8시간 절약."
Case 2 — 캐싱 레이어 도입 (속도 향상)
❌ BEFORE
"Redis를 캐시 레이어로 도입하고 TTL 정책을 설정함."
✅ AFTER
"Redis 캐싱 레이어 설계 및 적용으로 메인 피드 API 응답시간 p95 기준 870ms → 112ms(87% 단축). DB 조회 부하 70% 감소, 동시접속 임계치 800 RPS → 3,200 RPS로 4배 향상. 신규 마케팅 캠페인 기간 중 서비스 다운 0건 유지."
Case 3 — DB 분리 설계 (안정성 + 비용 복합)
❌ BEFORE
"Read Replica를 추가해 DB 읽기/쓰기 트래픽을 분리함."
✅ AFTER
"Aurora Read Replica 설계 적용으로 Primary DB CPU 사용률 89% → 34% 정상화. 이로 인해 고사양 인스턴스 다운그레이드 가능해져 월 RDS 비용 $2,100 → $1,300(38% 절감). 동시에 Slow Query 발생 건수 주간 기준 240건 → 17건으로 93% 감소."
🚫 흔한 실수 & 금지 표현 목록
기술적으로 훌륭한 작업을 했어도 다음 표현들을 사용하면 성과 평가에서 저평가받는다. 아래 패턴을 점검하라.
✦ 아키텍처 성과 기록의 황금 공식
[무엇을] 설계·변경하여 → [Before 수치] → [After 수치] → [비즈니스 임팩트]
예: "결제 서비스 API 아키텍처 재설계 → 응답시간 1,200ms → 280ms(77% 단축) → 결제 완료율 2.3%p 향상"
✅ 아키텍처 성과 기록 체크리스트
설계 작업 착수 전/후, 성과 평가 제출 전 각각 점검해야 할 항목이다.
🔵 설계 착수 전 (Baseline 확보)
🟢 설계 완료 후 (성과 수집)
🟠 성과 평가 제출 전 (표현 점검)
✦ 핵심 정리
- ✦ 아키텍처 성과는 '비용 절감 · 속도 향상 · 안정성 확보' 3축으로 정리하고, 최소 2가지 이상 제시해야 입체적 기여자로 인정받는다.
- ✦ 설계 착수 전 반드시 Baseline(Before 수치)을 측정·보관하라. 이 데이터가 없으면 성과가 아무리 커도 수치로 증명할 수 없다.
- ✦ 황금 공식: [무엇을] 설계·변경 → [Before 수치] → [After 수치] → [비즈니스 임팩트]. 이 4단계 구조를 갖추면 평가자가 즉시 이해한다.
- ✦ "개선했습니다" "절약했습니다" 같은 동사 단독 표현은 금지. 반드시 수치 + 비율 + 기간을 함께 기록하라.
- ✦ 비즈니스 임팩트(전환율, 거래액 기여)로 연결할 수 있으면 가장 강력하다. 단, 근거 없는 추정은 신뢰도를 오히려 깎는다.
IT·개발자 성과 관리 시리즈
다음 글도 함께 읽어보세요