patchnotes

인수 테스트(User Acceptance Testing, UAT)란 소프트웨어가 요구사항 명세대로 구현되었는지 최종적으로 확인하는 과정이다. 이는 개발의 마지막 단계에서 비즈니스 요구사항을 충족하는지 검증하는 절차로, 제품의 출시 여부를 결정하는 핵심 단계이다.그러나 UAT의 자동화는 다음과 같은 이유로 난이도가 높다.사용자 참여: 실제 사용자의 행위를 모방해야 하므로 시나리오가 복잡하다.환경의 일치성: 개발, 스테이징, 프로덕션 환경이 미세하게 다를 경우 테스트 신뢰도가 하락한다.릴리스 준비: 애플리케이션의 버전 관리와 배포 준비 과정이 선행되어야 한다.이러한 문제를 해결하기 위해서는 동일한 바이너리(아티팩트)가 파이프라인의 모든 단계에서 사용됨을 보장해야 하며, 이를 위해 아티팩트 리포지토리와 컨테이..

서론배경오늘날 소프트웨어 개발 환경은 급변하는 비즈니스 요구사항에 맞춰 빠른 개발 주기와 안정적인 배포가 필수적인 요소로 자리 잡았다. 과거의 '빅뱅 통합(Big Bang Integration)' 방식은 개발 후반에 코드를 일괄 통합함으로써 피드백이 지연되고 오류 수정에 많은 비용이 소모되는 단점이 있었다. 이러한 문제를 해결하기 위해 등장한 것이 DevOps와 CI/CD(지속적 통합/지속적 배포) 개념이다.목적본 리포트에서는 CI/CD 도구 중 가장 널리 사용되는 오픈 소스 자동화 서버인 Jenkins(젠킨스)의 개념과 특징, 아키텍처를 분석하고, 최신 트렌드인 쿠버네티스(Kubernetes) 환경 및 DevSecOps에서의 활용 방안을 고찰해보고자 한다.CI/CD와 Jenkins의 개요CI/CD의 정..

1. 쿠버네티스(k8s) 개요쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈소스 시스템이다. 도커(Docker)와 같은 컨테이너 기술로 만들어진 애플리케이션들을 대규모 환경에서 효율적으로 운영할 수 있도록 돕는 클러스터 관리 시스템이다.k8s는 사용자가 추구하는 상태(Desired State)를 선언하면, 현재 상태를 지속적으로 모니터링하여 목표 상태를 유지하려고 노력하는 선언적(Declarative) 구조를 가지고 있다.2. 쿠버네티스 클러스터 구성 요소k8s 클러스터는 크게 마스터 노드(Master Node)와 워커 노드(Worker Node)로 구성된다.2.1. 마스터 노드 (컨트롤 플레인)클러스터 전체를 관리하고 제어하는 중심부이다.API 서버: 클러스터의 프론트엔드..

1. 서론: 풀 사이클(Full Cycle) 개발과 파이프라인의 이해현대의 소프트웨어 개발은 단순히 코드를 작성하는 것을 넘어, 개발된 코드가 실제 사용자에게 전달되고 운영되는 전체 과정을 포괄한다. 이를 풀 사이클 개발이라고 하며, 이 과정의 핵심은 개발부터 배포까지의 흐름을 효율적으로 연결하는 파이프라인의 구축이다. 본 보고서에서는 전통적인 인도 프로세스의 한계를 극복하기 위한 CI/CD 방법론과 이를 실현하는 핵심 도구인 도커(Docker)를 중심으로 웹 개발 파이프라인 구축에 대해 논한다.2. 소프트웨어 인도 프로세스의 변화2.1 전통적인 인도 프로세스와 한계과거의 소프트웨어 인도는 '개발(Development) → 품질 보증(QA) → 운영(Operation)'이라는 순차적이고 분절된 단계를 거..

오늘은 오픈소스를 활용하여 실질적인 '채용(Career)'과 연결하고, 나아가 직접 프로젝트를 이끄는 '저작자(Author)'가 되는 과정을 다룬다.1. 오픈 소스를 활용한 커리어 전략개발자가 오픈 소스 활동을 하는 본질적인 이유는 '필요에 의해서'이지만, 이 과정에서 축적된 경험은 채용 시장에서 강력한 무기가 된다. 입사 지원 시 단순한 스펙 나열을 넘어 구체적인 역량을 증명하는 방법을 알아본다.글로벌 협업 능력 (Collaboration)교내 팀 프로젝트나 소규모 스터디와 달리, 오픈 소스는 전 세계 개발자와 비동기적으로 소통한다.어필 포인트: 얼굴을 보지 않고 텍스트(영어)만으로 논리적인 토론을 거쳐 코드를 반영시킨 경험은 커뮤니케이션 능력을 증명한다.사례: "PR 과정에서 메인테이너가 성능 이슈를..

오픈 소스의 법적 토대가 되는 '라이선스(License)'를 깊이 있게 다룬다.1. 오픈 소스 판별의 핵심: 라이선스 유무오픈 소스 소프트웨어(OSS)를 학습할 때 가장 먼저 명심해야 할 점은 "소스 코드가 공개되어 있다고 해서 모두 오픈 소스는 아니다"라는 사실이다. 깃허브(GitHub)의 퍼블릭(Public) 레포지토리는 누구나 코드를 볼 수 있지만, 라이선스가 명시되지 않았다면 타인이 이를 자유롭게 사용, 수정, 배포할 권한이 없다.즉, 라이선스 파일(LICENSE)이 존재해야 비로소 오픈 소스로서의 법적 효력을 갖는다.라이선스가 없는 프로젝트를 발견했을 때코드가 유용하거나 학습 가치가 높음에도 라이선스가 없는 경우가 있다. 이 경우 저작권법에 의해 '모든 권리는 저작자에게 있음(All Rights..

1. 오픈 소스 생태계 구성원오픈 소스 프로젝트는 단순히 코드를 작성하는 사람뿐만 아니라 다양한 역할의 구성원이 모여 유지된다.저작자 (Author): 프로젝트를 처음 시작하고 만든 사람(또는 단체)이다. 프로젝트의 창시자로서 초기 비전을 제시한다.메인테이너 (Maintainer): 프로젝트의 방향성을 설정하고 지속적으로 관리하는 핵심 인력이다. 이슈를 관리하고, 다른 사람의 코드를 검토하며, 프로젝트의 품질을 유지하는 역할을 한다. (저작자가 메인테이너를 겸하는 경우도 많다.)커미터 (Committer): 프로젝트 저장소(Repository)에 대한 쓰기 권한(Write Access)을 가진 사람이다. 들어온 PR(Pull Request)을 리뷰하고 최종적으로 병합(Merge)할지 결정한다. 프로젝트 ..

오픈 소스와 깃허브 관련 기능깃허브 오픈 소스 가이드깃허브는 오픈 소스를 더욱 효과적으로 관리할 수 있도록 다양한 기능을 제공한다. 프로젝트를 시작하는 방법부터 기여까지 상세한 정보를 깃허브에서 제공하는 GitHub Open Source Guide에서 확인할 수 있다. 또한, 오픈 소스의 법적 측면과 프로젝트 진행 시 알아야 할 중요 지침도 포함되어 있다.오픈 소스 프로젝트의 문서 구조주요 문서LICENSE.md 또는 LICENSE.txt프로젝트에 적용되는 오픈 소스 라이선스를 명시하는 문서로, 최상위 디렉토리에 위치한다.README.md프로젝트의 목적, 사용 방법, 설치 방법 등을 설명하고, 사용자와 기여자로 하여금 프로젝트를 이해할 수 있도록 돕는 문서다.추가 문서COPYRIGHT.txt프로젝트의 저..

1. 개발 문화: '공유'가 만든 생태계오픈 소스를 논하기 전, 개발 문화를 먼저 이해해야 오픈 소스의 탄생 배경을 명확히 알 수 있다. 개발 생태계에는 다양한 문화가 존재하지만, 그중 핵심은 '공유'이다.현대의 수많은 혁신적인 앱과 도구들은 개발자들이 서로의 지식과 문제 해결 방법을 공유하는 문화 덕분에 탄생할 수 있었다. 개발자들은 스택오버플로우(Stack Overflow)나 OKKY 같은 커뮤니티에서 정보를 나누고, 깃허브(GitHub)를 통해 자신이 구현한 코드를 전 세계에 공개한다. 이러한 공유 문화를 통해 소프트웨어는 폐쇄적인 환경을 넘어 다양한 방향으로 진화하고 성장할 수 있었다.2. 오픈 소스 소프트웨어(OSS)란?OSS(Open Source Software)란 소스 코드가 공개되어 누구나..

1. 모킹 서버 (Mocking Server) with MSW프론트엔드에서 모킹하는 이유프론트엔드 개발을 진행하다 보면 백엔드 API가 아직 완성되지 않아 개발이 지연되는 상황(Blocker)이 발생한다. 이때 모킹(Mocking)은 없는 것을 있는 것처럼 임시로 만들어 개발 흐름을 끊기지 않게 해 준다.단순히 변수에 가짜 데이터를 담아 사용하는 것을 넘어, 실제 네트워크 요청과 응답 과정을 시뮬레이션해야 하는 이유는 다음과 같다:병렬 개발 가능: 백엔드 개발이 완료될 때까지 기다리지 않고 프론트엔드 로직(데이터 페칭, 에러 핸들링 등)을 미리 구현할 수 있다.엣지 케이스 테스트: 서버에서 재현하기 힘든 에러 상황(500 에러, 네트워크 지연 등)을 쉽게 시뮬레이션하여 견고한 애플리케이션을 만들 수 있다..