C-LAB / B-LAB

"주간 운영 회의 중, 한 팀원분이 이슈를 설명하다가 이런 말을 했다.

이건 B-Lab에서는 반영됐는데, C-Lab에는 아직 안 먹은 상태예요.

회의에 익숙한 사람들은 고개를 끄덕였지만,
처음 듣는 사람 입장에서는
‘B-Lab? C-Lab?’이 순간적으로 헷갈릴 수 있는 표현이었다.

이 글에서는,
현업에서 자주 쓰이지만 문서로는 잘 정리되지 않은
B-Lab / C-Lab이라는 용어가
실제로 어떤 맥락에서 쓰이는지 정리해보려고 한다"

 

1) 한 줄 정의

• B-Lab (Business / Build Lab): 개발·구성 변경을 자유롭게 하는 환경
• C-Lab (Certification / Control / Check Lab): 운영 반영 전 “검증·승인”을 받는 환경(운영 유사)

2) 왜 굳이 나누나

현업에서 사고 나는 패턴이 뻔해서 그래.

• 개발자가 편하게 바꾸는 환경(B)에서 곧바로 운영 반영하면
  → 권한/보안/성능/데이터 정합성/감사에서 터짐
• 그래서 운영과 유사한 조건(C)에서
  → 검증(기능+성능+보안+정합성) + 변경 이력 관리를 하고
  → 마지막에 운영 반영(P)로 간다

즉 리스크를 단계적으로 줄이는 파이프라인이야.

3) B-Lab 상세 (개발/구성 변경 중심)

목적

• 신규 기능/스키마/배치/연동/API 정책 등을 빠르게 만들고 바꿔보는 곳

특징

• DDL/설정 변경이 비교적 자유로움
• 테스트 데이터(가짜/샘플) 위주, 또는 부분 마스킹 데이터
• 장애나 리소스 튐에 비교적 관대(“개발 환경이니까”)

운영 관점 체크포인트

• “돌아가긴 하는데” 운영 기준(성능/보안/감사/장애대응) 만족은 별개
• 개발 편의 때문에 운영에서 금지되는 설정이 들어가기 쉬움
  (예: 느슨한 권한, 로그 과다/부족, 임시 인덱스, 캐시 설정)

4) C-Lab 상세 (운영 전 검증/승인 중심)

목적

• 운영 반영 직전 최종 검증
  (Certification/Control/Check 라고 부르는 이유가 여기)

특징

• 운영과 최대한 유사
  • DB 스키마/권한/인덱스/파라미터
  • WAS/JVM 옵션
  • 네트워크 경로, 방화벽 룰
  • 인증서/키스토어/트러스트스토어 구성
• 변경 권한이 제한적(승인/절차 필요)
• 테스트도 “기능만”이 아니라:
  • 성능(부하)
  • 장애/재기동
  • 보안(암호/권한/접근통제)
  • 감사/로그 적정성
    를 본다

운영 관점 체크포인트

• C-Lab에서 통과 못하면 운영 반영하면 안 됨(원칙상)
• “C-Lab에서 OK”가 곧 “운영에서도 동일하게 재현 가능”을 의미하도록 맞추는 게 목표

5) B → C → P 흐름 (현업에서 실제로 이렇게 말함)

예시로 DB 변경이 있다고 치면:

1. B-Lab: 개발자가 테이블/인덱스/프로시저 수정 + 기능 확인
2. C-Lab: 동일 스크립트/릴리스 패키지로 적용 + 부하/권한/정합성 검증
3. P-Lab/운영(PRD): 승인된 릴리스 패키지로 운영 반영

중요 포인트는 **“수작업 재현”이 아니라 “릴리스 산출물(스크립트/패키지)로 동일 적용”**이야. 그래야 환경만 다르고 결과가 같아짐.

6) 오라클(DB)에서 특히 많이 쓰는 이유

오라클은 “환경 차이”가 결과에 크게 영향 줘.

• 파라미터/통계/실행계획 차이
• 인덱스 유무
• 권한/시노님/DB Link
• Character set/NLS
• 데이터량 차이(특히 성능)

그래서 C-Lab은 보통:

• 운영과 같은 스키마/권한/오브젝트 구조
• 운영 유사 데이터(마스킹/샘플링)
• 운영 유사 파라미터
  를 목표로 맞춘다.