나의 잡다한 노트 및 메모

ARG vs. ENVARG (Build-time Argument)빌드 시점에만 사용할 수 있는 변수입니다.도커 이미지를 빌드할 때, 빌드 명령어(docker build)에 --build-arg 옵션을 통해 값을 전달할 수 있습니다.빌드가 완료되면 해당 값은 최종 이미지에 남지 않습니다.주로 빌드 프로세스에서만 필요한 정보를 전달할 때 사용합니다.ENV (Environment Variable)런타임과 빌드 시점 모두에서 사용할 수 있는 변수입니다.최종 컨테이너 이미지에 포함되어, 컨테이너가 실행될 때도 환경 변수로 남습니다.주로 애플리케이션 실행 시 필요한 설정이나 경로, 옵션 등을 지정할 때 사용합니다.

도커(Docker) 이미지를 이용해 개발 환경(dev), QA(품질 테스트 환경), 운영 환경(prod) 등 여러 스테이지(Stage)를 분리하고, 각 환경마다 인증이나 설정이 달라질 수 있다는 점을 설명하고 있습니다. 그리고 이를 환경 변수(ENV) 관리를 통해 효율적으로 제어할 수 있다는 내용을 담고 있습니다.아래에서 좀 더 구체적으로 살펴보겠습니다.1. 스테이지(환경) 구분일반적으로 애플리케이션 개발 과정에서는 다음과 같은 환경을 분리합니다:Dev(개발 환경):개발자들이 코드를 작성하고, 로컬 또는 개발 서버에서 실행하는 환경배포 자동화나 CI/CD 파이프라인 등을 테스트해볼 수 있음QA(품질 보증 환경 / 테스트 환경):QA 팀이나 자동화 테스트가 실제 프로덕션 환경과 유사한 조건에서 테스트를 진..

가상화는 물리적인 장비(서버, 스토리지, 네트워크 등)를 논리적으로 분리하여 여러 개의 독립적인 환경(가상 머신, 가상 스토리지 등)을 만들어 내는 기술 1. 물리적 장비와 가상화물리적 장비:전통적으로 한 서버에는 하나의 운영체제와 애플리케이션만 실행했습니다. 이 경우 서버의 모든 자원이 한 가지 용도로만 사용되죠.가상화의 개념:하나의 물리 서버를 여러 개의 가상 머신(Virtual Machine) 으로 나눌 수 있습니다. 각 가상 머신은 독립적으로 운영체제와 애플리케이션을 실행할 수 있어, 물리 서버의 자원을 여러 용도로 동시에 활용할 수 있습니다. 2. 가상화의 장점자원 효율성:물리적 서버 한 대를 여러 가상 머신으로 분할하면, 자원을 보다 효율적으로 사용할 수 있습니다. 즉, 한 서버의 CPU, 메..

DMZ용 가상 스위치와 Trust용 가상 스위치는 가상화 환경에서 네트워크를 분리하고 보안을 강화하기 위해 사용하는 논리적 네트워크 장치입니다.DMZ용 가상 스위치:DMZ(Demilitarized Zone)는 외부(인터넷)와 내부 네트워크 사이에 위치한 중간 영역입니다. DMZ에 위치한 서버들은 외부 접속을 허용하지만, 내부 네트워크와는 격리되어 있어 보안 위협을 최소화할 수 있습니다. DMZ용 가상 스위치는 이러한 DMZ 영역에서의 트래픽을 관리하며, 외부 사용자와의 통신을 담당합니다.Trust용 가상 스위치:Trust(신뢰) 영역은 내부 네트워크, 즉 보안이 확보된 신뢰할 수 있는 환경을 의미합니다. Trust용 가상 스위치는 내부 시스템 간의 통신이나 데이터 교환을 위해 사용되며, DMZ와 달리 외..

IT 분야에서 QA(Quality Assurance)를 수행하기 위해서는 테스트 전략과 프로세스, 커뮤니케이션 능력, 도메인 지식, 그리고 다양한 툴 활용 능력 등이 필요합니다. 단순히 툴을 잘 다루는 것도 중요하지만, 품질 보증을 위한 체계적인 접근법과 조직 내 협업이 함께 이루어져야 보다 효과적입니다. 아래는 QA를 하기 위해 필요한 요소들을 정리한 내용입니다.1. QA 기본 지식 및 프로세스 이해소프트웨어 개발 생명주기(SDLC)에 대한 이해애자일(Agile), 워터폴(Waterfall), 스크럼(Scrum) 등 다양한 프로세스에서 QA의 역할을 이해해야 합니다.초기 기획 단계부터 QA가 참여(Shift-left)하여 요구사항 분석 및 결함 예방에 기여할 수 있어야 합니다.테스트 전략(Test St..

Full-TC (Full Test Cases)**와 **탐색적 검증 (Exploratory Testing)**은 QA(품질 보증)에서 소프트웨어의 품질과 안정성을 확인하기 위한 두 가지 접근 방식이다. Full-TC (Full Test Cases)정의:미리 작성된 테스트 케이스들을 기반으로 시스템의 모든 기능을 체계적으로 검증하는 방법입니다.특징:사전 계획: 요구사항과 명세를 바탕으로 상세한 테스트 시나리오와 절차가 미리 정의됩니다.재현 가능성: 동일한 테스트 케이스를 여러 번 실행할 수 있어, 회귀 테스트나 반복적인 검증에 유리합니다.포괄적 검증: 모든 기능과 시나리오에 대해 예상된 결과를 확인하여, 빠진 부분 없이 검증하는 것을 목표로 합니다. 탐색적 검증 (Exploratory Testing)정의:..

1. 응답 비교 (Response Comparison)의미:새로운 시스템과 기존 시스템이 동일한 요청에 대해 동일하거나 예상 가능한 응답을 반환하는지 확인하는 방식입니다.목적:두 시스템 간의 기능적 동등성을 검증하여, 새로운 시스템의 동작이 올바른지 확인합니다.2. 표본 검사 (Sample Testing)의미:전체 트래픽 중 일부(표본)를 선택하여 새로운 시스템에 보내보고, 결과를 분석하는 방법입니다.목적:전체 시스템에 영향을 주지 않으면서 새로운 시스템의 성능, 안정성, 오류 발생 여부를 사전에 점검합니다. 3. A/B 비율 조정 (A/B Ratio Adjustment)의미:전체 사용자 트래픽을 두 그룹으로 나누어 일부는 기존 시스템, 일부는 새로운 시스템으로 라우팅하는 방식입니다.목적:점진적으로 새로..