운영 우수성 - DevOps 패턴 | 패턴 |

운영 우수성 - DevOps 패턴

잘 설계된 운영적 우수성에 대해 자세히 알아보기 → DevOps Practices

패턴

찾을 위치	유사성
버전 관리 설정	✅ 모든 메타데이터는 관련 없는 파일을 제외하도록 구성된 Salesforce DX 프로젝트 구조를 사용하여 Git 소스 형식으로 저장됩니다. 모든 팀 구성원이 중앙 저장소에서 복제
스크래치 조직 사용	✅ 개발자는 기능 작업을 위해 소스에서 임시 스크래치 조직을 만들고, 변경 사항을 버전 제어로 다시 커밋하고, 기능이 완료된 후 스크래치 조직을 폐기합니다.
커밋 메시지	✅ 커밋할 때마다 변경 사항 및 이유를 명확하고 간결하게 설명하는 메시지가 포함됩니다. 메시지는 팀 규칙을 따릅니다(예: “feat:”, “fix:”, “docs:”).
변경 추적	✅ 정확한 변경 사항이 표시된 작성자 ID, 타임스탬프, diff를 사용하여 버전 관리에서 캡처된 모든 메타데이터 수정
코드 검토 프로세스	✅ 모든 프로덕션 바운드 변경 사항은 병합 전에 검토 승인이 필요한 가져오기 요청을 통해 진행됩니다. 선언적 구성은 코드와 동일한 검사를 받습니다.
롤백 절차	✅ 이전 버전은 Checkout 또는 리버트 작업을 통해 Git 내역에서 복구할 수 있습니다. 팀은 비프로덕션에서 테스트한 롤백 절차를 문서화했습니다.
감사 내역	✅ 규정 준수 요구 사항 및 보안 조사를 지원하는 버전 관리에 보존된 전체 변경 내역
분기 전략	✅ 팀 크기 및 릴리스 주기에 적합한 일관적인 Git 분기 모델(GitFlow, GitHub 플로 또는 트렁크 기반), 문서화 및 적용
조직 기반에서 마이그레이션	✅ 솔루션 수명 주기 초반에 완료된 소스 중심 개발으로 전환한 후 조직 기반 개발에 대한 습관이 견고해집니다.
.gitignore 구성	✅ 리포지토리는 생성된 파일, 사용자별 설정, 자격 증명을 제외하며, 버전을 지정하려는 소스 파일만 포함합니다.

안티 패턴

찾을 위치	불만 사항
신뢰할 수 있는 소스로의 조직	⚡️ 개발은 버전 관리로 메타데이터를 내보낸 후 공유된 Sandbox에서 직접 수행되며, 조직과 버전 관리가 서로 다르므로 배포 실패가 발생합니다.
부적합한 .gitignore	⚡️ 리포지토리에 생성된 파일, 사용자별 설정, 대규모 이진 또는 자격 증명이 포함되며, 리포지토리를 압축하고 보안 노출이 발생할 수 있습니다.
모호한 커밋 메시지	⚡️ “버그 수정” 또는 “업데이트”와 같은 확정은 변경 사항 또는 이유에 대한 컨텍스트를 제공하지 않으며 감사 조사 및 향후 서비스 점검을 방해합니다.
자주 발생하지 않는 대규모 확정	⚡️ 개발자는 매일 여러 번 소규모 증분 커밋 대량 변경 집합을 커밋하는 대신 주간에 커밋합니다. 검토하기 어려움, 실패를 분리하기 어려움
기본에 직접 커밋	⚡️ 개발자가 검토 및 유효성 검사를 우회하여 기본/프로덕션 지점에 직접 변경 사항을 푸시하며 품질 게이트 제거
분기 전략 없음	팀에 일관된 분기 모델이 없으며, 개발자가 임의의 지점 이름 및 병합 패턴을 만들고 혼동 및 병합 충돌을 야기합니다.
Git의 이진 파일	⚡️ Git로 커밋된 대용량 이진 파일(PDF, 비디오, 보관)은 리포지토리 크기 증가 및 복제 작업 속도 저하
자격 증명 확정	⚡️ 버전 관리에 커밋된 API 키, 암호, 통합 자격 증명 또는 보안 토큰, 이후 커밋에서 제거한 후에도 보안 취약성 생성
병합 충돌 무시	⚡️ 분석 없이 한 측면을 수락하여 해결된 병합 충돌, 변경 사항 손실 또는 버그 도입
확정 확인 없음	⚡️ 팀은 커밋된 메타데이터가 실제로 의도한 변경 사항을 나타내는지 확인하지 않습니다. 메타데이터 형식 오류 또는 의도하지 않은 변경 사항이 발생하지 않습니다.

패턴

찾을 위치	유사성
개발자 Sandbox	✅ 개별 개발자는 기능 작업, 단위 테스트, 빠른 반복에 Developer Sandbox를 사용합니다. 각 개발자에게 전용 환경이 있습니다.
Developer Pro Sandbox	✅ 관리 패키지를 개발하거나 높은 저장소 제한이 필요한 팀은 공동 작업을 위해 Developer Pro Sandbox를 사용합니다.
부분 복사 Sandbox	✅ 통합 테스트는 데이터 템플릿을 통해 구성된 대표 데이터 샘플(개체당 레코드 10,000개)이 있는 부분 복사 Sandbox를 사용합니다.
Sandbox 전체 복사	✅ 성능 테스트, 프로덕션 유사 스테이징, 데이터 마이그레이션 유효성 검사 - 전체 프로덕션 데이터 및 구성이 포함된 전체 사본 Sandbox 사용
데이터 민감도 컨트롤	✅ 전체 복사 sandbox 액세스 권한은 프로덕션 데이터를 필요로 하는 역할로 제한됩니다. Shield Platform Encryption 데이터 마스킹은 적절한 경우 비프로덕션 사용에 적용됩니다.
통합 끝점 구성	✅ 각 Sandbox 계층이 외부 통합을 위해 해당 테스트 끝점에 연결되며, 프로덕션 통합은 Sandbox에서 연결되지 않습니다.
환경별 구성	✅ 통합 아키텍처는 사용자 정의 메타데이터 유형 또는 사용자 정의 설정을 사용하여 환경당 끝점 URL, 자격 증명 및 기능 플래그를 외부화합니다.
새로 고침 후 자동화	✅ Sandbox 새로 고침은 통합 자격 증명, 테스트 데이터 시드, 기능 플래그 상태 및 이메일 전달 가능성을 비롯한 Sandbox별 설정을 복원하는 자동화된 Salesforce CLI 스크립트를 트리거합니다.
일정 새로 고침	✅ Sandbox 새로 고침 일정 문서화 및 통신, 활동이 적은 기간 동안 계획된 새로 고침으로 팀 중단 최소화
데이터 템플릿	✅ 부분 복사 Sandbox는 참조 무결성을 유지하는 개체 전체에서 대표 데이터를 선택하는 잘 설계된 데이터 템플릿을 사용합니다.
명명 규칙	✅ Sandbox는 목적, 소유자, 새로 고침 주기를 나타내는 명확한 명명 규칙을 따릅니다(예: “dev-integration-q2”, “uat-release-2-4”).

안티 패턴

찾을 위치	불만 사항
공유 개발 Sandbox	⚡️ 모든 개발자가 서로 변경 사항을 덮어쓰는 단일 공유 Sandbox에서 작업하며 배포 가능 상태에 대한 혼동을 유발합니다.
더 이상 사용되지 않는 Sandbox	⚡️ 샌드박스는 몇 달 동안 새로 고쳐지지 않았으며, 프로덕션 구성과 크게 다릅니다. 대표적이지 않은 환경에서 테스트로 인해 배포 실패가 발생합니다.
전체 사본의 데이터 거버넌스 없음	⚡️ 프로덕션 PII, 금융 데이터, 전체 개발 팀이 액세스 제어 또는 데이터 마스킹 없이 액세스할 수 있는 HIPAA 데이터가 포함된 전체 복사 Sandbox
Sandbox의 프로덕션 통합	⚡️ Sandbox가 프로덕션 통합 끝점에 직접 연결되어 프로덕션 데이터 또는 외부 시스템에 영향을 미치는 테스트 트랜잭션 위험 발생
수동 새로 고침 후 구성	⚡️ Sandbox를 새로 고치려면 수동 재구성 복원 설정을 수행해야 합니다. 오버헤드는 필요에 따라 빈번하게 Sandbox를 새로 고치는 것이 좋지 않습니다.
Sandbox 문서 없음	⚡️ 팀에 Sandbox 목적, 새로 고침 일정, 데이터 콘텐츠 또는 액세스 절차에 대한 문서가 부족합니다. 개발자가 어떤 용도로 사용할 환경을 추측합니다.
단일 환경 유형	⚡️ 팀은 모든 목적으로 하나의 Sandbox 유형(일반적으로 Developer 또는 Full Copy)만 사용하며 활동당 적절한 Sandbox 전략의 이점이 누락됨
Sandbox 호어딩	⚡️ 개인 또는 프로젝트에 할당되고 더 이상 필요하지 않은 경우 릴리스되지 않는 Sandbox, 사용 가능한 라이센스에도 불구하고 인공적 부족
테스트 데이터 부족	⚡️ Sandbox의 테스트 데이터는 프로덕션 데이터 특성(볼륨, 관계, 가장자리 사례)을 나타내지 않습니다. 비현실적인 환경에서의 테스트는 프로덕션 문제를 놓치지 않습니다.

패턴

찾을 위치	유사성
소스 커밋 단계	✅ 개발자가 컨텍스트 및 근거를 설명하는 명확한 커밋 메시지와 함께 Git의 기능 분기에 변경 사항을 커밋합니다.
정적 분석 단계	✅ Salesforce 코드 분석기는 보안 취약성(OWASP 상위 10개), 성능 안티 패턴(루프의 SOQL, 루프의 DML), 코드 품질 문제(복잡성, 중복) 및 총괄자 제한 위험에 대한 Apex 스캔하며, 즉각적인 사용자 의견을 제공하는 작업을 초 단위로 실행합니다.
단위 테스트 단계	✅ Apex 테스트는 간단한 스크래치 조직 또는 전용 통합 sandbox에서 비즈니스 논리 및 총괄자 제한 준수 검증을 실행합니다. 적절하게 분리된 테스트는 5분 이내에 완료됩니다.
확인 배포 단계	✅ 변경 사항 커밋 없이 테스트를 실행하는 유효성 검사 전용 배포에 대해 –checkonly 플래그가 있는 Salesforce CLI 사용하여 통합 Sandbox에 메타데이터 배포
통합 테스트 단계	✅ 자동 테스트는 테스트 데이터 관리를 사용하여 공유 통합 환경에 대한 다중 구성 요소 워크플로, 외부 통합 계약, 플랫폼 이벤트 플로, 비동기 처리 체인의 유효성을 검사합니다.
보안 스캔 단계	✅ 추가 보안 도구가 하드 코딩된 자격 증명, 취약한 종속성, CRUD/FLS 위반, 규정 준수 정책 위반, 중요 결과 중단 구축을 검색합니다.
UAT 배포 단계	✅ 모든 자동화된 게이트를 전달하는 변경 사항은 비즈니스 확인을 위해 사용자 승인 테스트 환경에 배포됩니다. 배포는 자동화되거나 변경 위험에 따라 수동 승인이 필요할 수 있습니다.
프로덕션 배포 단계	✅ UAT 승인 후 자동화된 원클릭 실행, 포괄적인 로깅, 즉시 롤백 기능을 통해 변경 사항이 프로덕션에 배포됩니다.
파이프라인 실행 시간	✅ 일반적인 변경 사항에 대해 종단간 파이프라인이 15분 이내에 완료되어 빠른 사용자 의견을 제공하며, 대규모 배포 또는 광범위한 테스트 도구 모음의 경우 시간이 더 길어집니다.
아티팩트 구축	✅ 파이프라인은 규정 준수 및 문제 해결을 위해 배포 패키지, 테스트 결과, 보안 스캔 보고서, 실행 로그를 유지합니다.
파이프라인 툴링	✅ 팀은 플랫폼 네이티브 CI/CD에 Salesforce DevOps Center 사용하거나 외부 플랫폼과 통합합니다(GitHub 작업, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT).
실패 알림	✅ 파이프라인 실패는 신속한 해결을 지원하는 진단 컨텍스트를 통해 작성자 및 관련 채널을 커밋하기 위한 알림을 트리거합니다.
지점 보호	✅ 기본/프로덕션 지점 보호: 병합 전에 CI 검사 및 승인된 검토 전달 필요, 직접 커밋 방지
환경 프로모션	✅ 각 단계에서 확인을 통해 정의된 프로모션 경로(개발 → 통합 → UAT → 프로덕션)를 통한 플로 변경

안티 패턴

찾을 위치	불만 사항
수동 배포	⚡️ 변경 집합 또는 Salesforce CLI 명령을 통해 수동으로 배포된 변경 사항 - 일관되지 않은 단계, 인적 오류, 누락된 단계, 감사 추적 부족
정적 분석 없음	⚡️ 파이프라인은 Salesforce 코드 분석기 또는 유사한 도구를 건너뛰고, 보안 취약점, 성능 안티 패턴, 코드 품질 문제는 프로덕션에 도달합니다.
테스트 부족	⚡️ 파이프라인은 통합 테스트를 실행하거나 주요 사용자 플로를 확인하지 않고 최소 75% 적용 범위만 확인합니다. 회귀 실패
보안 스캔 없음	⚡️ 파이프라인은 하드 코딩된 자격 증명, 취약한 종속성 또는 CRUD/FLS 위반을 스캔하지 않습니다. 프로덕션 또는 보안 검토에서 발견된 보안 문제
느린 파이프라인 실행	⚡️ 포괄적인 파이프라인은 45~60분 이상 소요되므로 자주 커밋하고 사용자 의견 루프가 느려지지 않으며, 개발자는 빈번하게 커다란 변경 사항을 누적합니다.
무시된 파이프라인 실패	⚡️ 팀이 마감일을 충족하기 위해 파이프라인 실패를 무시하거나 재정의합니다. 품질 게이트는 실제 제어가 아닌 극장이 됩니다.
테스트 환경 패리티 없음	⚡️ CI/CD는 구성, 제한 또는 데이터 특성이 프로덕션과 다른 환경에서 유효성을 검사합니다. 유효성 검사를 통과해도 프로덕션 성공은 보장되지 않습니다.
롤백 기능 누락	⚡️ 파이프라인은 배포를 자동화하지만 자동 롤백을 제공하지 않습니다. 잘못된 배포로 복구하려면 수동 긴급 절차가 필요합니다.
배포 로그 없음	⚡️ 포괄적인 로깅 없이 배포 실행, 문제 해결 또는 배포 감사가 어려워짐
All-or-nothing 테스트	⚡️ 파이프라인은 모든 변경 사항에 대해 모든 테스트를 실행하며, 문서 업데이트에도 30분 테스트 도구 모음이 실행됩니다.

패턴

찾을 위치	유사성
기능 플래그	✅ 사용자 정의 메타데이터 유형 또는 사용자 정의 설정 구성 뒤에 기능이 비활성화되어 있는 고위험 변경 사항 배포, 사용자 노출 없이 프로덕션에서 테스트, 세그먼트에 점진적인 롤아웃, A/B 테스트, 구성 변경을 통한 즉각적인 롤백 지원
기능 플래그 범위	✅ 중요 비즈니스 프로세스, 성능에 민감한 작업 또는 새로운 통합 패턴에 영향을 미치는 고위험 변경 사항에 대해 예약된 기능 플래그(일부 기능에 플래그가 필요하지 않음)
Canary 배포	✅ 비즈니스에 중요한 변경 사항이 먼저 소규모 사용자 하위 집합에 릴리스됩니다(권한 집합 또는 사용자 특성 필터링을 통해 5~10%). 롤아웃을 확장하기 전에 성공률, 성과, 오류 비율을 측정하기 위해 24시간에서 48시간 동안 집중적으로 모니터링되는 캐나리아 코호트
배포 창	✅ 사용량이 적은 기간 동안 예약된 배포는 이벤트 모니터링 API 사용 로그로 실제 트래픽 패턴을 표시하며, 최대 사용량, 월말 마감, 분기말 마감, 주요 비즈니스 이벤트를 피합니다.
배포 커뮤니케이션	✅ 이해당사자에게 예상 기간, 영향을 받는 기능, 롤백 결정 시간 표시 막대 등 배포 기간에 대한 사전 알림이 전송됩니다.
롤백 절차	✅ 각 배포 유형에 대해 문서화 및 테스트된 롤백 절차, 필요한 경우 팀에서 롤백을 30분 이내에 실행할 수 있음
롤백 테스트	✅ 복구 기능을 보장하는 중요 배포 전에 비프로덕션 환경에서 확인된 롤백 절차
배포 확인	✅ 배포 후 연기 테스트는 릴리스 직후 중요한 사용자 플로, 통합 끝점, 주요 기능을 확인합니다.
변경 조정	✅ 변경 사항이 여러 시스템에 적용되거나 Salesforce 및 외부 플랫폼에서 동기 릴리스가 필요한 경우 배포 전략 조정
배포 중 모니터링	✅ 배포 기간 동안 활성화된 고급 모니터링 및 배포 후 관찰 기간(24시간~48시간)에서 오류 비율 급증, 성능 저하 또는 사용자 플로 실패를 모니터링
통합을 위한 파란색-녹색 패턴	✅ Salesforce가 사용하는 외부 서비스 프런팅은 두 가지 프로덕션 유사한 환경을 유지하며, 먼저 비활성 상태로 배포하고 유효성 검사 후 트래픽을 전환하는 파란색 배포를 사용합니다.

안티 패턴

찾을 위치	불만 사항
빅뱅 배포	⚡️ 많은 기능, 리팩터링, 변경 사항이 포함된 대규모 릴리스는 점진적 롤아웃 없이 동시에 배포되며, 모든 사용자에게 즉시 영향을 미칩니다.
최대 시간 배포	사용량이 가장 높고 문제의 사용자 영향이 극대화된 비즈니스 시간(중간, 월말, 분기말) 동안 예약된 릴리스
롤백 계획 없음	⚡️ 문서화 및 테스트된 롤백 절차 없이 배포가 진행되며, 문제가 발생하면 팀에서 복구를 해결합니다.
다음으로 기능 토글	⚡️ 고위험 변경 사항에 대해 사전에 설계하지 않고 문제 발생 시 반응형으로 추가되는 기능 플래그, 롤백 옵션을 전체 배포 취소로 제한
배포 확인 없음	⚡️ 배포 후 연기 테스트 없이 프로덕션에 배포된 변경 사항, 팀에서 배포가 성공했다고 가정하고 계속 진행됨, 사용자가 몇 시간 후에 발견한 문제
테스트되지 않은 롤백 절차	⚡️ 롤백 절차는 문서화되었지만 비프로덕션에서는 테스트되지 않았습니다. 실제 사고 중 절차가 실패하거나 부적합함
동시 다중 시스템 변경 사항	⚡️ 동기화 또는 호환성 테스트 없이 Salesforce 및 외부 시스템 전체에서 조정된 변경 사항 배포, 통합 실패 발생
모니터링 개선 사항 없음	⚡️ 배포 기간 동안 고급 모니터링 없이 배포 진행, 사전 예방 경고가 아닌 사용자 컴플레인을 통해 감지된 문제
주말 배포	⚡️ 온콜 적용 범위가 감소하고 공급업체 지원 가용성이 제한된 경우 금요일 저녁 또는 주말에 주요 릴리스 배포

패턴

찾을 위치	유사성
단위 테스트 적용 범위	✅ 비즈니스 규칙, 가장자리 사례, 오류 경로, 총괄자 제한 접근 방식을 확인하는 유의미한 테스트 적용 범위, 75%의 최소 요구 사항을 크게 초과
단위 테스트 품질	✅ 테스트는 플랫폼 기능이 아닌 비즈니스 논리의 유효성을 검사하며, 잘 작성된 단위 테스트는 빠르고(밀리초), 분리(공유 상태 없음), 집중(각 테스트가 하나의 동작을 확인함)
데이터 전략 테스트	✅ 테스트에서 일반적인 테스트 데이터에 @TestSetup 메서드를 사용하고, 가능한 경우 테스트에서 SOQL 쿼리를 피하고, 정적 자원을 로드하는 데 Test.loadData()를 사용합니다.
모의 외부 종속성	✅ 단위 테스트는 테스트 스풀 및 종속성 삽입을 사용하여 외부 콜아웃을 모의하여 실제 HTTP 요청 없이 빠르게 실행할 수 있습니다.
통합 테스트	✅ 대표적인 테스트 데이터를 사용하여 Sandbox에서 실행되는 트리거, 플로, 플랫폼 이벤트, 배치 작업, 외부 콜아웃 간 상호 작용을 확인합니다.
통합 테스트 신뢰도	✅ 통합 테스트는 반복 가능하고 결정적이며, 플랫폼 이벤트 재생 ID 및 배치 작업 폴링과 같은 동기화 메커니즘을 통해 해결되는 단계별 실패
종단간 테스트	✅ 자동 브라우저 테스트(Selenium, Playwright, Provar)는 사용자가 상호 작용하는 동안 UI를 통해 시스템을 실행하는 비즈니스에 중요한 플로에 대한 전체 사용자 여정을 확인합니다.
E2E 테스트 포커스	✅ E2E 테스트는 실행 속도가 느려짐(테스트당 분) 및 UI 변경으로 인한 더 높은 서비스 점검 부담으로 인해 가장 중요한 사용자 경로에 초점을 맞춥니다.
로드 테스트	✅ Salesforce 로드 테스트 서비스 또는 타사 도구를 사용하여 실질적인 동시 사용자 로드 및 데이터 볼륨에서 성능 확인, 총괄자 제한 문제, 잠금 충돌, 성능 저하 표시
테스트 주기 로드	✅ 주 릴리스 전에 정기적으로(분기별) 테스트를 로드하여 현재 생산량 3배~5배의 성능을 확인합니다.
피라미드 테스트	✅ 균형 잡힌 테스트 분포: 많은 단위 테스트(백, 분), 적은 통합 테스트(수십, 분), 적은 E2E 테스트(20분 미만), 빠른 사용자 의견(기본), 포괄적인 검증(상단)
테스트 격리	✅ 테스트는 서로 종속되지 않으며, 임의의 순서로 실행할 수 있으며, 각 테스트는 시스템을 정리된 상태로 남기거나 @TestSetup을 사용하여 일관된 시작 지점을 유지합니다.
음수 테스트 사례	✅ 테스트는 오류 처리의 유효성 검사, 확인 규칙 적용, 권한 적용, 불량한 조건에서 우수한 성능 저하
총괄자 제한 테스트	✅ 테스트는 특히 SOQL 쿼리 제한, DML 제한, CPU 시간, 힙 크기 등 총괄자 제한에 근접하는 동작을 확인합니다.
연속 테스트 실행	✅ CI/CD 파이프라인을 통해 커밋할 때마다 테스트가 자동으로 실행되며 테스트에 실패하면 높은 환경으로 배포되지 않습니다.

안티 패턴

찾을 위치	불만 사항
적용 범위 테스트	⚡️ 비즈니스 규칙 또는 가장자리 사례의 유효성을 검사하지 않고 75%의 최소 적용 범위를 달성하기 위해 작성된 테스트, 어설션이 없거나 소소한 코드 경로를 테스트하는 테스트
플랫폼 기능 테스트	⚡️ 테스트는 Salesforce가 비즈니스 논리 확인 대신 레코드 또는 SOQL 쿼리 작업을 저장하는지 확인합니다. 플랫폼 보증에 대한 노력이 낭비됩니다.
모의 전략 없음	⚡️ 단위 테스트는 외부 시스템에 대한 실제 콜아웃을 만듭니다. 테스트는 느리고 외부 시스템 가용성에 비해 취약하며 API 제한을 사용합니다.
소극적 테스트 실패	⚡️ 실행 타이밍, 데이터 상태 또는 테스트 실행 순서에 따라 테스트가 예측할 수 없게 통과하거나 실패합니다. 팀은 실패를 무시하고 테스트가 통과될 때까지 다시 실행하는 방법을 학습합니다.
통합 테스트 없음	⚡️ 단위 테스트만 존재하며, 팀은 트리거, 플로, 플랫폼 이벤트, 배치 작업이 올바르게 함께 작동하는지 확인하지 않습니다.
수동 E2E 테스트만 해당	⚡️ 각 릴리스 전에 수동으로 확인된 중요 사용자 플로, 자동화된 E2E 테스트 없음, 수동 테스트가 실패한 경우 프로덕션에서 발견된 회귀
로드 테스트 없음	⚡️ 실질적인 동시 부하에서 성능이 확인되지 않았습니다. 총괄자 제한 문제, 잠금 충돌 또는 성능 저하가 프로덕션에서 발견됨
데이터 종속성 테스트	⚡️ 테스트는 조직에 있는 특정 레코드에 따라 다르거나 특정 사용자 구성으로 추정되며, Sandbox가 새로 고침되거나 구성이 변경되면 중단됩니다.
음수 테스트 사례 없음	⚡️ 테스트는 행복한 경로 시나리오에만 유효성을 검사하며, 오류 처리, 유효성 검사 적용 또는 권한 검사를 테스트하지 않으며, 실패 모드는 발견되지 않습니다.
테스트 건너뛰기	⚡️ 실패한 테스트가 @isTest에서 코멘트 해제되고 수정되지 않고 건너뛰었습니다. 더 많은 테스트가 무시되면 테스트 도구 모음이 시간에 따라 저하됩니다.

패턴

찾을 위치	유사성
보장 검토	✅ 모든 프로덕션 관련 변경 사항은 병합 전에 승인이 필요한 가져오기 요청을 통해 코드 검토를 통해 진행됩니다. Apex, Aura, LWC, 플로, 확인 규칙, 권한 집합, 공유 규칙을 포함합니다.
기준 점검 목록 검토	✅ 보안(CRUD/FLS 적용, 입력 검증), 성능(불량 처리, SOQL 최적화), 총괄자 제한 준수(처리 패턴, 반복 방지), 유지 관리 가능(명명, 문서, 복잡성), 테스트 적용 범위(유의미한 테스트, 가장자리 사례), 아키텍처 일관성(설계 패턴, 우려 사항 분리)을 포함하는 명시적인 체크리스트
크기 제한 검토	✅ 의미 있는 변경 사항의 400줄 미만으로 유지된 요청 가져오기를 통해 철저한 검토가 가능합니다. 큰 기능은 개별적으로 검토하고 독립적으로 배포할 수 있는 작은 증분 변경 사항으로 분할됩니다.
시기 검토	✅ 영업일 이내에 완료된 검토 - 개발 동력을 유지하고 빠른 사용자 의견을 제공합니다. 검토 지연 시 컨텍스트 전환 오버헤드 발생
자동화된 사전 검토 확인	✅ 정적 분석, 단위 테스트, 보안 스캔은 사람이 검토를 요청하기 전에 자동으로 실행되며, 자동 확인은 기계적 문제를 파악하므로 검토자가 설계 및 비즈니스 논리에 집중합니다.
배포된 검토 책임	✅ 지체 지점을 방지하고 Knowledge 공유하기 위해 팀에 배포된 코드 검토 책임, 하위 개발자가 상위 코드를 검토하고 검토 중에 자체 코드를 설명합니다.
댓글 품질 검토	✅ 검토자는 구체적이고 실행 가능한 사용자 의견을 제공하며, 근거가 있으면 필수 변경 사항(차단 문제)과 제안 사항(유용한 개선 사항)을 구분할 수 있습니다.
문서 검토	✅ 당겨 요청 설명은 변경 사항, 변경 이유, 수행된 테스트, 특별한 배포 고려 사항 또는 롤백 절차에 대해 설명합니다.
선언적 구성 검토	✅ 플로, 확인 규칙 및 권한 변경 사항은 코드와 동일한 심층적인 검토를 받습니다. 구성은 아키텍처적이며 면밀하게 검토해야 합니다.
댓글에 대한 팔로우업	✅ 병합 전에 처리된 모든 검토 댓글, 답변된 질문, 구현된 변경 사항 또는 제안이 채택되지 않은 이유에 대한 이유 제공

안티 패턴

찾을 위치	불만 사항
코드 검토 안 함	⚡️ 동료 검토 없이 프로덕션 지점에 직접 적용되는 변경 사항, 기본 결함 감지 메커니즘 제거
고무 스탬핑	⚡️ 검토자는 변경 사항을 실제로 검사하지 않고 몇 초 내에 가져오기 요청을 승인합니다. 검토가 품질 대신 확인란 준수가 됩니다.
단일 검토자 병목	⚡️ 코드를 검토할 권한이 있는 한 명의 선임 개발자만; 병목과 단일 실패 지점을 만듭니다; Knowledge 집중되지 않고 배포
대량 가져오기 요청	⚡️ 여러 기능에 걸쳐 수천 개의 변경 행이 포함된 가져오기 요청, 면밀한 검사로 이어지는 철저한 검토 불가능
지연된 검토	⚡️ 가져오기 요청은 며칠 또는 몇 주 동안 검토되지 않으며, 개발자가 컨텍스트를 잃고 다른 작업으로 이동하고, 개발자가 미니 컨텍스트를 전환한 경우 검토 댓글이 도착합니다.
검토 기준 없음	⚡️ 팀에 검토자가 검사해야 하는 항목에 대한 명시적인 기준이 부족하며, 검토 품질은 검토자에 따라 매우 다릅니다. 일부 검토자는 스타일에 집중하고 다른 검토자는 논리에 집중하며 종합적은 없습니다.
테스트 없이 검토	⚡️ 검토자는 분기를 가져오고 로컬에서 테스트하거나 자동 테스트 통과를 확인하지 않고 코드 검사를 기반으로 변경 사항을 승인합니다.
무시된 자동 확인	⚡️ 검토자는 정적 분석, 보안 검사 또는 단위 테스트에 실패했어도 가져오기 요청을 승인하며, 자동화된 품질 게이트의 목적을 무시합니다.
적 검토 문화	⚡️ 검토는 공동 작업 품질 향상 대신 개인적인 비판이나 경쟁 운동으로 바뀌며 학습 및 심리적 안전을 방지합니다.
선언적 검토 없음	⚡️ 플로, 확인 규칙, 권한 집합 및 공유 규칙은 검토 없이 배포되며 Apex 코드가 검토되며 선언적 구성에서 품질 격차가 발생합니다.