Test Double 소프트웨어 테스트에서 실제 객체를 대신하여 사용되는 테스트용 객체를 말합니다. 이것은 마치 영화에서 위험한 장면을 연기하는 스턴트 더블과 비슷한 개념이다. 실제 구현체를 사용하기 어렵거나 비용이 많이 드는 상황에서 테스트를 용이하게 만들어주는 중요한 기법. 목적: 테스트 대상 코드를 외부 요인으로부터 격리 테스트 속도 개선 예측 불가능한 요소 제거 특정 상황 시뮬레이션 감춰진 정보 획득 장점: 외부 의존성 제거로 인한 테스트의 안정성 향상 테스트 실행 속도 개선 특정 시나리오 테스트 용이성 증가 아직 개발되지 않은 컴포넌트의 동작 시뮬레이션 가능 주의사항: ...
SOC 2 SOC 2(Service Organization Control 2)는 미국공인회계사회(AICPA)가 개발한 서비스 기업의 데이터 보안 및 개인정보 보호 관리 체계를 검증하는 국제 인증 제도이다. 특히 클라우드 서비스, SaaS 기업 등 고객 데이터를 처리하는 조직의 신뢰성을 평가하는 핵심 기준으로 자리 잡았다. SOC 2 인증의 핵심 요소 신뢰 서비스 기준(Trust Service Criteria): SOC 2는 다음 5가지 원칙을 기반으로 한다. 보안(Security): 무단 접근 방지(방화벽, 암호화, MFA 등). 가용성(Availability): 서비스 중단 최소화 및 복구 체계(재해 복구 계획, 성능 모니터링). 처리 무결성(Processing Integrity): 데이터 처리의 정확성 및 오류 감지(로그 관리, 감사 추적). 기밀성(Confidentiality): 민감 정보 보호(접근 권한 제한, NDA). 개인정보 보호(Privacy): GDPR 등 개인정보 처리 규정 준수. 인증 유형: ...
Payment Card Industry Data Security Standard (PCI DSS) PCI DSS(Payment Card Industry Data Security Standard)는 신용카드 결제 과정에서 카드 소유자의 데이터를 안전하게 보호하기 위해 주요 글로벌 카드 브랜드(Visa, MasterCard, American Express, Discover, JCB)가 공동으로 제정한 국제 보안 표준이다. 이 표준은 카드 정보의 저장, 처리, 전송을 수행하는 모든 조직이 준수해야 하며, 이를 통해 카드 결제 산업의 데이터 보안을 강화하고 사기 및 데이터 유출을 방지하는 것을 목표로 한다. 2025년 3월 기준 PCI DSS v4.0은 기존 버전 대비 64개 신규 요구사항을 추가했으며, 특히 이메일 기반 공격 방지를 위한 DMARC 정책과 API 보안 강화 조치가 주목받고 있다. 조직들은 연간 1회 이상의 전체 시스템 진단과 분기별 외부 취약점 스캔을 통해 규정 준수를 유지해야 한다. ...
소프트웨어 라이선스 (Software License) 소프트웨어의 사용, 수정, 배포에 대한 권리와 제한을 정의하는 법적 도구 라이센스는 크게 오픈소스 라이센스와 상용 라이센스로 나눌 수 있다. 라이센스 종류 주요 특징 소스코드 공개 의무 상업적 사용 특허권 보호 대표적인 소프트웨어 GPL v3 가장 엄격한 카피레프트 필수 가능 있음 Linux Kernel, GCC AGPL v3 네트워크 서비스도 소스 공개 필수 가능 있음 MongoDB(~2018) LGPL v3 라이브러리 링크 허용 수정시에만 필수 가능 있음 FFmpeg MPL 2.0 파일 단위 카피레프트 수정시에만 필수 가능 있음 Firefox Apache 2.0 특허권 명시적 허용 선택적 가능 있음 Android, Spring MIT 가장 자유로운 라이센스 선택적 가능 없음 jQuery, Node.js BSD MIT와 유사한 허용적 라이센스 선택적 가능 없음 PostgreSQL Proprietary 모든 권한 제한 불가 제한적 있음 Windows, Oracle 라이센스들의 주요 특징 GPL (GNU General Public License) ...
DevSecOps DevSecOps는 DevOps 철학에 보안(Security)을 통합한 접근 방식으로, 소프트웨어 개발 라이프사이클 전반에 걸쳐 보안을 고려하고 구현합니다. 이 방법론은 개발팀, 보안팀, 운영팀 간의 협업을 강화하여 보안을 “나중에 추가하는 것"이 아닌 “처음부터 구축하는 것"으로 전환합니다. DevSecOps의 기본 원칙 보안 내재화(Security as Code): 인프라 및 보안 구성을 코드로 관리하여 버전 관리, 자동화, 재현성을 확보 지속적인 보안 테스트: CI/CD 파이프라인에 보안 테스트를 통합하여 빠른 피드백 주기 확보 공유 책임: 보안은 특정 팀만의 책임이 아닌 모든 이해관계자의 공동 책임 자동화 중심: 수동 보안 테스트 대신 자동화된 보안 검증 도구 활용 프로세스 개선: 지속적인 피드백을 통한 보안 프로세스 개선 협업과 투명성: 팀 간 시너지와 정보 공유 촉진 DevOps vs DevSecOps 측면 DevOps DevSecOps 초점 개발과 운영의 통합, 빠른 배포 개발, 운영, 보안의 통합, 안전한 빠른 배포 보안 고려 시점 주로 후속 단계 초기 단계부터 지속적으로 보안 책임 주로 보안팀 모든 팀 구성원 보안 테스트 주로 수동, 개발 후 자동화, 개발 중 지속적으로 배포 속도 빠름 안전하게 빠름 DevSecOps 구현 단계 1. 계획 및 요구사항 단계 위협 모델링 및 리스크 평가 보안 요구사항 정의 규제 준수 요구사항 식별 2. 코드 작성 단계 보안 코딩 표준 적용 IDE 내 보안 플러그인 활용 코드 저장소 액세스 제어 3. 빌드 및 테스트 단계 종속성 검사 (SCA - Software Composition Analysis) 정적 애플리케이션 보안 테스트 (SAST) 컨테이너 및 인프라 스캔 4. 배포 전 검증 단계 동적 애플리케이션 보안 테스트 (DAST) 침투 테스트 보안 구성 검증 5. 배포 단계 불변 인프라 원칙 적용 보안 배포 게이트웨이 암호화 및 키 관리 6. 모니터링 및 운영 단계 실시간 보안 모니터링 이상 행동 감지 취약점 관리 및 패치 DevSecOps 도구 소스 코드 분석 SonarQube Checkmarx Veracode Snyk Code 컴포넌트 분석 Snyk Open Source OWASP Dependency-Check WhiteSource Sonatype Nexus IQ 컨테이너 보안 Aqua Security Sysdig Secure Trivy Clair 인프라 보안 Terraform/CloudFormation 보안 검증 AWS Config Chef InSpec Ansible Security Automation 동적 분석 OWASP ZAP Burp Suite Netsparker Acunetix 보안 모니터링 Splunk ELK Stack Sumo Logic Datadog Security Monitoring DevSecOps 도입 과제와 해결 방안 문화적 도전 과제: 전통적으로 분리된 팀 간의 저항 해결 방안: 교육, 인센티브, 점진적 변화, 경영진 지원 기술적 도전 과제: 보안 도구 통합 및 자동화의 복잡성 해결 방안: 현재 CI/CD 파이프라인과 호환되는 도구 선택, 단계적 도입 프로세스 도전 과제: 보안 요구사항과 빠른 배포 사이의 균형 해결 방안: 리스크 기반 접근 방식, 품질 게이트 정의 스킬 도전 과제: 개발자의 보안 지식, 보안 전문가의 개발 지식 부족 해결 방안: 크로스 트레이닝, 보안 챔피언 프로그램, 지식 공유 DevSecOps 성공 지표 평균 취약점 해결 시간: 취약점 발견부터 해결까지 소요 시간 보안 결함 밀도: 코드 또는 배포 단위당 발견된 보안 결함 수 자동화된 보안 테스트 비율: 전체 보안 테스트 중 자동화된 비율 보안 사고 발생률: 배포 또는 시간 단위당 보안 사고 수 개발자 보안 참여도: 보안 교육, 코드 리뷰, 취약점 해결 참여도 규제 준수율: 필요한 규제 요구사항 충족 비율 DevSecOps 모범 사례 변화는 점진적으로: 모든 것을 한 번에 변경하려 하지 말고 단계적 접근 자동화에 집중: 가능한 많은 보안 검증 자동화 빠른 피드백 중요: 문제 발견 시 즉시 피드백 제공 교육에 투자: 모든 팀원의 보안 인식과 기술 향상 게임화 활용: 보안 경쟁, 해커톤, 버그 바운티 등으로 참여 유도 실패로부터 학습: 실패를 비난하지 않고 개선 기회로 활용 가시성 제공: 보안 메트릭과 현황 대시보드로 투명성 확보 DevSecOps의 미래 DevSecOps는 계속 발전하고 있으며, 다음과 같은 추세가 나타나고 있습니다: ...
Model-View-ViewModel Pattern 1. 태그 MVVM, Software-Architecture, Pattern, UI-Development 2. 분류 구조 분석 현재 구조의 “Software Engineering > Design and Architecture > Architecture Styles and Patterns > Architecture Styles > Structural > Layered Architecture” 분류는 MVVM (Model-View-ViewModel)의 핵심적 특성을 잘 반영하지만, 더 세분화하면 다음처럼도 볼 수 있음. 이유 MVVM은 관심사 분리(Separation of Concerns), UI와 데이터 로직의 구조적 분리, 재사용성 증진 등 실질적으로 “Presentation Layer Pattern"으로 묶을 수 있음. MVVM은 MVC (Model-View-Controller), MVP (Model-View-Presenter)와 동일 선상에 있는 패턴이므로, “Presentation Patterns” 또는 “UI Architectural Patterns"로 추가 분류해도 적합함. ...
MVP (모델-뷰-프리젠터, Model-View-Presenter) 1. 적절한 태그 정리 Model-View-Presenter UI-Architecture Presentation-Pattern Design-Pattern 2. 현재 구조의 분류 적합성 분석 현재 분류 구조에서 “Software Engineering > Design and Architecture > Architecture Styles > Layered Architecture > Presentation Patterns”에 MVP (모델-뷰-프리젠터, Model-View-Presenter)가 포함된 것은 매우 적합함. MVP는 MVC(모델-뷰-컨트롤러, Model-View-Controller), MVVM(모델-뷰-뷰모델, Model-View-ViewModel) 등과 함께 대표적인 Presentation Layer(프레젠테이션 계층, 프레젠테이션 레이어) 패턴이기 때문임. 더욱 세분화가 필요하다면 “UI Architecture Patterns” 또는 “Presentation Layer Patterns”와 같은 하위 카테고리로 구체화할 수 있으나, 현재 구조도 충분히 합리적임. ...
MVC (Model-View-Controller) MVC(Model-View-Controller) 는 1979 년 Trygve Reenskaug 가 Smalltalk 환경에서 제안한 아키텍처 패턴으로, 애플리케이션을 Model(데이터와 로직), View(UI 표현), Controller(입력 및 흐름 제어) 로 분리해 개발 효율성과 유지보수성을 높인다. 각 구성 요소는 책임이 명확히 분리되어 있어 테스트 용이성, 모듈화, 병렬 개발을 가능하게 하며, Ruby on Rails, Spring MVC, Django 등 다양한 프레임워크에서 활용된다. 특히 웹, 데스크톱, 모바일 환경에서 광범위하게 적용되며, UI 일관성 유지를 위해 Observer 패턴이 활용되기도 한다. 단, 소규모 프로젝트에선 과도한 구조가 될 수 있으며, Django 는 MTV(Model-Template-View) 구조로 변형되어 사용된다. ...
GoF GoF(Gang of Four) 디자인 패턴은 소프트웨어 개발에서 자주 발생하는 문제들에 대한 검증된 해결책을 제공한다. 1994 년 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 가 저술한 “Design Patterns: Elements of Reusable Object-Oriented Software” 에서 처음 소개되었다. 이 패턴들은 객체지향 소프트웨어 설계에서 재사용성, 확장성, 유지보수성을 향상시키는 데 중요한 역할을 한다. GoF 패턴은 크게 생성 (Creational), 구조 (Structural), 행동 (Behavioral) 패턴으로 구분된다. 생성 패턴은 객체 생성 방식을 추상화하고, 구조 패턴은 클래스/객체 조합을 최적화하며, 행동 패턴은 객체 간 상호작용을 관리한다. 2025 년에는 AI 기반 자동 패턴 적용과 클라우드 네이티브 환경에서의 활용이 확대되고 있다. ...
Platform Engineering 플랫폼 엔지니어링은 소프트웨어 개발 팀이 자율적으로 인프라를 관리하고 애플리케이션을 배포할 수 있도록 지원하는 내부 플랫폼을 구축하는 것을 목표로 한다. 이러한 플랫폼은 표준화된 도구 체인, 자동화된 워크플로우, 셀프 서비스 기능을 제공하여 개발자의 생산성을 높이고 운영 효율성을 향상시킨다. 2025년 기준으로 DevOps의 진화된 형태로 인식되며, 클라우드 네이티브 환경에서의 효율적인 소프트웨어 개발 생태계 구축에 핵심 역할을 한다. 핵심 개념 Product Thinking: 플랫폼을 제품처럼 설계하여 사용자(개발자) 경험 최적화 내부 개발자 플랫폼(IDP): 개발자 셀프 서비스 기능을 제공하는 도구 및 워크플로우의 집합 골든 패스(Golden Path): 개발자가 따르도록 설계된 선호되는 워크플로우와 표준 셀프 서비스 인프라: 개발자가 운영팀 지원 없이 필요한 리소스를 직접 프로비저닝할 수 있는 능력 개발자 경험(DX): 개발자가 작업을 수행하는 동안 경험하는 전체적인 사용 경험 플랫폼 추상화(Platform Abstraction): 복잡한 기술적 세부 사항을 단순화된 인터페이스로 숨기는 과정 도구 통합(Tool Integration): 다양한 개발, 테스트, 배포 도구를 일관된 플랫폼으로 통합 목적 개발자 생산성 향상 운영 복잡성 감소 일관된 애플리케이션 개발 및 배포 환경 제공 표준화된 보안 및 규정 준수 적용 조직의 기술 혁신 가속화 기술 부채 감소 시장 출시 시간(Time-to-Market) 단축 인프라 비용 최적화 -> 개발자의 인지 부하 감소 및 본업 집중 지원하고 조직 전체의 표준화와 자동화를 통한 운영 효율성 향상. ...