Cloud 함정 피하기-02. 간극 메우기

간극(Gap)의 문제 — 요구사항·구현 간극에서 Cloud Infra 간극으로

앞선 “Cloud 프로젝트가 실패하는 구조” 분석의 후속. 이번엔 프로젝트를 “간극을 메우는 일”로 재정의하고, on-premise의 전통적 간극과 Cloud가 새로 만들어낸 간극을 비교한다.

이전 Story:

• 01. 복잡성의 역전

1. 모든 프로젝트는 “간극 메우기”다

소프트웨어 프로젝트의 본질은 결국 간극을 메우는 일이다. 현업이 머릿속에 그리는 요구사항과, 실제로 동작하는 아키텍처·코드 사이에는 항상 거리가 있다. 프로젝트가 성공하느냐는 이 거리를 얼마나 정확하고 값싸게 좁히느냐에 달려 있다.

핵심은 간극 그 자체가 아니라 간극을 메우는 비용과 속도다. 메우는 루프가 빠르고 싸면 큰 간극도 관리되고, 루프가 느리고 비싸면 작은 간극도 프로젝트를 무너뜨린다.

2. 전통적(on-premise) 간극 — 요구사항 ↔ 아키텍처/코드

전통적인 on-premise 프로젝트에서 가장 큰 이슈는 현업의 요구사항과 실제 아키텍처·코드 사이의 간극이었다. 이건 사실상 1차원의 간극이다. 한쪽 끝에 “무엇을 만들 것인가(요구사항)”, 다른 쪽 끝에 “어떻게 구현됐는가(코드)”가 있다.

이 간극은 실제로 잘 관리될 수 있었다. 조건은 두 가지다.

1. 요구사항이 명확할 것
2. 그 간극을 AA/PL 등 중개자가 메우고 관리할 것

이 두 조건이 충족되면 기술적 이슈는 상당히 줄어든다. 간극이 사라지는 게 아니라, 메우는 책임 주체가 분명하고 메우는 루프가 작동하기 때문이다.

2.1 간극을 다루는 세 가지 정공법

전통적 환경에서 검증된 방법은 다음과 같다.

• 사전 검증 (프로토타이핑) — 간극이 실재하는지, 설계가 요구사항을 만족하는지 증명하는 가장 단순하고 강력한 방법. 프로토타입/PoC로 미리 부딪혀 보면, 말로만 합의된 요구사항이 실제 구현 가능한지가 드러난다. 간극을 코드로 한 번 통과시켜 보는 것이다.
• 가이드 제공 — 간극이 크면, 즉 개발자가 가야 할 방향을 모르면, 명시적 가이드로 길을 깔아 준다.
• 샘플 코드 제공 — 가이드보다 한 단계 강한 처방. “이렇게 짜라”를 글이 아니라 동작하는 예제로 준다. 개발자는 복사해서 변형만 하면 되므로 간극이 급격히 좁혀진다.

2.2 왜 이게 통했나

전통적 간극이 관리 가능했던 진짜 이유는 메우는 루프가 값쌌기 때문이다.

• 간극이 1차원(요구사항↔코드)이라 측정과 교정이 단순했다.
• 검증(프로토타이핑)이 로컬에서 빠르게 돌았다.
• 샘플 코드가 자기완결적이었다. 예제를 받으면 그 자리에서 컴파일하고 실행해 볼 수 있었다. 환경 의존성이 거의 없었다.
• 중개자(AA/PL)의 인지 범위 안에 간극 전체가 들어왔다. 한 사람이 요구사항과 코드를 동시에 쥘 수 있었다.

요약하면, 전통적 간극은 한 사람이 이해할 수 있고, 빠르게 검증되고, 값싸게 교정되는 간극이었다.

물론 현실적으로는 이런 문제조차 인지하지 못하고 실패한 프로젝트들이 부지기수이다.

3. Cloud가 추가한 새 간극 — 개발 ↔ Cloud Infra

Cloud 환경에서는 상황이 더 복잡하다. 요구사항↔코드 간극이 사라진 게 아니라, 그 위에 새로운 계층이 하나 더 얹혔다. 바로 개발(코드)과 Cloud Infra 사이의 간극이다.

        요구사항
           │   (전통적 간극 — 여전히 존재)
           ▼
        코드/도메인 로직
           │   (새 간극 — Cloud가 추가)
           ▼
   Cloud Infra (IAM·네트워킹·매니지드 서비스·YAML·보안 경계)

문제는 이 두 번째 간극이 첫 번째보다 메우기 훨씬 어렵다는 데 있다. 앞선 분석에서 말한 “부수적 복잡성의 폭발”이 바로 이 간극의 정체다. 동작하는 코드가 허무할 정도로 알맹이가 없는 이유도, 노력의 대부분이 이 두 번째 간극을 메우는 데 빨려 들어가기 때문이다.

3.1 두 간극의 구조적 차이

| 항목 | 전통적 간극 (요구사항↔코드) | Cloud 간극 (코드↔Infra) |
|------|------------------------------|---------------------------|
| 차원 | 1차원, 측정 단순 | 다차원(IAM·네트워크·매니지드 서비스·보안·비용) |
| 검증 비용 | 낮음 — 로컬 프로토타이핑 | 높음 — 살아있는 클라우드 환경 필요 |
| 피드백 속도 | 초~분 (inner loop) | 분~시간 (commit→CI→배포→확인, outer loop) |
| 샘플의 성질 | 자기완결적·복사 가능 | 환경 의존적·살아있어야 동작 |
| 중개자 적합도 | AA/PL이 전체를 쥠 | 한 사람의 인지 한계를 넘어섬 |
| 변질(drift) | 거의 없음 | 환경·정책·버전에 따라 상시 변질 |

핵심 차이는 마지막 두 줄이다. Cloud 간극은 한 사람이 끝까지 쥐기 어렵고, 일시적으로 메워 두어도 쉽게 변질된다.

3.2 매니지드 서비스가 키우는 간극 — 양날의 검

코드↔Infra 간극을 키우는 가장 큰 단일 요인이 매니지드 서비스(RDS·DynamoDB·SQS·Lambda·EKS 등)다. 매니지드 서비스는 운영 복잡성을 클라우드 제공자에게 넘겨주는 대신, 그 대가로 다른 복잡성을 개발자에게 떠넘긴다. 그래서 양날의 검이다.

먼저 좋은 쪽을 분명히 해야 한다. 매니지드 서비스가 제거하는 운영 부담(패치·백업·장애 복구·스케일링)은 실재한다. Kafka 클러스터를 직접 운영하느니 SQS를 쓰는 게 합리적인 경우가 많다. 제거하는 복잡성이 추가하는 복잡성보다 명백히 클 때는 쓰는 게 옳다.

문제는 그 “추가하는 복잡성”이 정확히 코드↔Infra 간극의 정체라는 데 있다. 다섯 가지로 정리된다.

| 문제 | 내용 | 간극에 미치는 영향 |
|------|------|---------------------|
| **바인딩 복잡성** | 서비스 자체는 관리되지만, 그걸 내 코드와 연결하는 IAM·VPC·엔드포인트·시크릿·환경별 설정은 여전히 내 몫 | "동작하는 코드는 알맹이가 없다" — 노력이 배선(plumbing)에 빨려 들어감 |
| **로컬 검증 불가** | DynamoDB·SQS는 살아있는 클라우드에 있어야 동작 → 노트북에서 프로토타이핑 어려움 | inner loop가 끊기고 검증이 느린 outer loop에 묶임 |
| **종속성(lock-in)** | 대개 벤더 고유 API·동작 → 한 번 깊이 박으면 교체 비용이 폭증 | 떠안은 lock-in이 미래의 부수적 복잡성으로 누적 |
| **블랙박스 디버깅** | 내부 구현이 가려져 있어, 장애 시 들여다볼 수 없는 경계 너머에서 문제가 발생 | 관측성이 서비스 경계에서 끊겨 원인 추적이 어려움 |
| **비용·동작의 비가시성** | 과금 모델·throttling·쿼터·SLA가 코드 밖에 숨어 있어 설계 시점에 안 보임 | 비용·한도 문제가 청구서나 운영 장애로 사후에 드러남 |

여기에 제공자발(發) 변질이 더해진다. 내가 코드를 안 건드려도, 클라우드 제공자가 서비스 버전·기본값·정책을 바꾸면 어제 동작하던 연결이 오늘 깨질 수 있다. 위 표의 “drift”가 매니지드 서비스에서는 내 통제 밖에서 일어난다.

정리하면 — 매니지드 서비스는 운영 복잡성을 줄여주는 대신, 바인딩·종속성·관측성·비용이라는 새 복잡성을 코드↔Infra 간극으로 밀어 넣는다. 그래서 도입은 “쓸까 말까”가 아니라 “이 서비스가 제거하는 복잡성이 추가하는 복잡성보다 명백히 큰가” 를 매번 따지는 판단 대상이어야 한다. 이 판단을 개인에게 맡기지 않고 플랫폼팀이 골든 패스 안에서 한 번 내려 두는 것이, 뒤(5장)에서 말할 해법의 핵심이다.

4. 왜 전통적 처방이 Cloud 간극엔 그대로 안 통하나

전통적 정공법(프로토타이핑·가이드·샘플 코드)을 Cloud 간극에 그냥 적용하면 효과가 반감된다.

4.1 프로토타이핑이 어렵다

전통적 프로토타이핑은 로컬에서 값싸게 돌았다. 하지만 Cloud 간극을 검증하려면 IAM·네트워킹·매니지드 서비스가 살아있는 환경이 필요하다. 강력한 보안과 로컬-운영 패리티의 부재 때문에, 간극을 “한 번 통과시켜 보는” 행위 자체가 느린 outer loop에 묶인다. 검증 루프가 비싸지면, 간극을 미리 증명하는 가장 강력한 무기가 무력화된다.

4.2 샘플 코드만으론 부족하다

전통적 샘플 코드는 자기완결적이었다. 받아서 바로 돌렸다. 하지만 Cloud의 샘플은 죽은 코드 조각만으론 동작하지 않는다. Terraform 한 조각, Lambda 핸들러 한 조각을 줘도, 그 뒤의 IAM 정책·VPC·시크릿·파이프라인이 없으면 실행되지 않는다. 게다가 정책·버전·환경이 바뀌면 어제 동작하던 샘플이 오늘 깨진다(drift). 정적 샘플 코드는 Cloud 간극 앞에서 살아있지 못한 표본이 된다.

4.3 중개자(AA/PL)의 한계

전통적 간극은 AA/PL의 인지 범위 안에 통째로 들어왔다. 하지만 Cloud 간극은 도메인 지식만으론 메울 수 없다. 인프라·보안·네트워킹·비용까지 동시에 쥐어야 하는데, 이건 한 사람의 인지 한계(cognitive load)를 넘어선다. “you build it, you run it”을 모든 팀에 강제하면서 프론트엔드 개발자조차 IAM 롤과 Terraform 상태를 만지게 된 상황이, 바로 이 간극이 개인에게 전가된 결과다. 그래서 AA/PL 위에 TA(Technical Architect)와 플랫폼이라는 새 중개 계층이 필요해진다.

5. Cloud 간극을 메우는 방법 — 전통 처방의 “살아있는” 업그레이드

해법은 전통 처방을 버리는 게 아니라, 실행 가능하고 살아있는 형태로 격상시키는 것이다. 1:1로 대응시키면 다음과 같다.

| 전통 처방 | Cloud 간극용 격상판 |
|-----------|----------------------|
| 사전 검증 (프로토타이핑) | 워킹 스켈레톤 + 로컬 패리티 + thin-slice 배포 |
| 샘플 코드 | 골든 패스 / 스캐폴딩 (살아있는 실행 가능 템플릿) |
| 가이드 | 셀프서비스 IDP + 가드레일(기본값으로 박힌 보안) |
| AA/PL 중개 | 플랫폼팀이 간극을 구조적으로 흡수 |

5.1 프로토타이핑 → 워킹 스켈레톤 + thin slice

말단 기능 하나를 요구사항부터 인프라까지 세로로 한 번 관통시키는 얇은 슬라이스(walking skeleton)를 먼저 만든다. 두 간극을 동시에 한 번 통과시켜 보는 것이다. 그리고 LocalStack·Testcontainers·에뮬레이터로 로컬 패리티를 확보해, 검증 루프를 다시 값싸게 만든다. 이게 앞선 분석의 “inner loop 복원”과 정확히 같은 처방이다.

5.2 샘플 코드 → 골든 패스 / 스캐폴딩

Cloud에서 “샘플 코드 제공”의 올바른 형태는 골든 패스(golden path)다. CNCF는 이를 “빠른 프로젝트 개발을 위해 잘 통합된 코드와 역량의 템플릿화된 조합”으로 정의한다. Spotify가 ‘Golden Path’, Netflix가 ‘Paved Road’로 부르는 그것이다.

전통적 샘플 코드와의 결정적 차이는 살아있다는 점이다. 개발자가 포털에서 “새 서비스” 하나를 고르면, 보일러플레이트 코드·디렉터리 구조·CI/CD 파이프라인·관측성·시크릿·기본 보안이 한꺼번에 배선된 채로 생성된다. 죽은 예제가 아니라, 그 자리에서 production까지 굴러가는 표본이다. 길 위에 있는 한 보안과 관측성이 “공짜로” 따라온다. 스캐폴더(Backstage, 사내 CLI)가 이걸 자동화한다.

여기엔 80–20 경험칙이 있다. 골든 패스는 80%의 일반적 작업을 덮고, 나머지 20%의 특수 케이스는 “off-road”로 열어 둔다. 길을 강제(mandate)가 아니라 권장으로 둬야, 베테랑이 필요할 때 인프라 밑단으로 내려갈 수 있다. 추상화가 밑단을 완전히 가려 버리면 그 자체가 또 다른 부수적 복잡성이 된다.

5.3 가이드 → 셀프서비스 + 가드레일

정적 문서 가이드는 Cloud 간극 앞에서 금방 낡는다. 대신 셀프서비스 IDP(내부 개발자 플랫폼)로 길을 깐다. 핵심은 가드레일을 체크리스트가 아니라 기본값으로 박는 것이다. Netflix의 Wall-E처럼, “보안 모범사례를 하라”고 말하는 게 아니라 길에 올라타면 이미 적용돼 있게 만든다. 따라야 할 규율을 개인의 의지에 맡기지 않는다.

5.4 AA/PL 중개 → 플랫폼팀의 구조적 흡수

가장 근본적인 변화다. Cloud 간극은 개인 중개자가 메우기엔 너무 넓으므로, 간극 자체를 플랫폼팀이 흡수한다(Team Topologies의 플랫폼팀 모델). 개발자가 코드↔Infra 간극과 매번 1:1로 싸우는 대신, 플랫폼팀이 그 간극을 한 번 메워서 골든 패스라는 형태로 제품화해 모두에게 제공한다. 인프라가 “보이지 않는 상품”이 되는 것이 목표다.

업계 데이터도 이 방향을 가리킨다 — 2025년 기준 플랫폼 엔지니어링 도입이 과반을 넘었고, 성숙한 플랫폼팀은 개발자 인지 부하를 40~50% 낮췄다는 보고가 나온다. 간극을 개인에서 플랫폼으로 옮기는 것이 실제로 측정 가능한 효과를 낸다는 뜻이다.

6. 간극 관점 점검 체크리스트

• [ ] 요구사항이 명확한가, 그리고 그 간극을 책임지고 메우는 주체(AA/PL)가 분명한가
• [ ] 요구사항↔코드 간극을 프로토타이핑으로 사전 검증했는가
• [ ] 코드↔Infra 간극을 워킹 스켈레톤(thin slice)으로 세로 관통해 봤는가
• [ ] 개발자에게 주는 샘플이 죽은 조각인가, 아니면 살아있는 골든 패스인가
• [ ] 보안·관측성이 체크리스트인가, 기본값(가드레일)으로 박혀 있는가
• [ ] 골든 패스가 80%를 덮고, 나머지 20%는 off-road로 열려 있는가 (강제가 아니라 권장인가)
• [ ] Cloud 간극을 개인이 매번 메우는가, 플랫폼팀이 한 번 메워 제품화하는가
• [ ] 검증 루프가 값싼가 — 로컬 패리티로 inner loop가 살아 있는가

7. 요약

전통적 on-premise 프로젝트의 핵심 이슈는 요구사항↔아키텍처/코드의 1차원 간극이었고, 이건 명확한 요구사항 + AA/PL의 중개 + 프로토타이핑(검증) + 가이드·샘플 코드(교정)로 값싸게 관리됐다.

Cloud는 이 간극을 없애지 않고, 그 위에 코드↔Cloud Infra라는 두 번째 간극을 얹었다. 이 새 간극은 다차원이고, 검증이 비싸고, 샘플이 살아있어야 동작하고, 한 사람의 인지 한계를 넘어서고, 메우는 즉시 변질된다. 그래서 전통 처방이 그대로는 통하지 않는다.

해법은 전통 처방을 폐기하는 게 아니라 “실행 가능하고 살아있는” 형태로 격상하는 것이다.

1. 프로토타이핑 → 워킹 스켈레톤 + 로컬 패리티 : 두 간극을 세로로 한 번에 관통하고, 검증 루프를 다시 값싸게.
2. 샘플 코드 → 골든 패스 / 스캐폴딩 : 죽은 예제가 아니라 production까지 굴러가는 살아있는 표본.
3. 가이드 → 셀프서비스 IDP + 가드레일 : 규율을 의지가 아니라 기본값으로.
4. 개인 중개 → 플랫폼팀의 구조적 흡수 : 간극을 개인에서 플랫폼으로 이전.

한 문장으로: 간극의 차원이 하나 늘었고, 그 새 간극은 개인이 아니라 플랫폼이 “살아있는 길”의 형태로 메워야 한다.