지난 시간에는 타입스크립트의 기본적인 선언과 타입 시스템의 원리에 대해 알아보았습니다. 이번에는 타입스크립트가 내부적으로 타입을 어떻게 분류하고, 어떤 기준으로 서로 호환되는지 '타입 계층도'를 통해 깊이 있게 파고들어 보겠습니다.타입스크립트를 이해하는 가장 중요한 관

TypeScript는 단순히 타입을 붙이는 것을 넘어, 코드의 안정성을 높이고 개발자의 실수를 미연에 방지하는 강력한 도구입니다. 기본적인 선언 방법부터 실무 활용 팁까지 정리해 보겠습니다. 1. 기본적인 타입 선언 방법 타입 별칭 (Type Alias) 가장 많

타입스크립트를 배우는 가장 첫 번째 단계는 변수에 "타입의 이름표"를 붙이는 것입니다. 자바스크립트의 유연함에 타입스크립트의 단단함을 더해주는 핵심 기본 타입들을 예제와 함께 알아보겠습니다. 출처: 한 입 크기로 잘라먹는 타입스크립트(TypeScript)https:/

타입스크립트 프로젝트의 핵심 설정 파일인 tsconfig.json 을 제대로 활용하면 개발 효율과 코드의 안정성을 동시에 잡을 수 있습니다. 실무에서 가장 자주 쓰이고 중요한 옵션들을 예제와 함께 정리했습니다.아래는 실무에서 흔히 쓰이는 주요 옵션들을 모은 예시 설정입

기존의 JavaScript는 자유롭다는 장점이 있지만 동적 타입이라는 이유로 타입 관련 버그가 굉장히 많이 발생했습니다. 실행(런타임)을 해야지 타입이 결정되기 때문에 VS Code 같은 에디터에서 자동완성, 리펙토링을 지원하기 어려웠습니다. 버그를 잡기 어려울 뿐만

이전 포스트(Git 연동 & Webhook, 브랜치/PR 트리거 설계)에서 Jenkins와 GitHub Webhook 연동으로 develop 브랜치 PR merge 시 자동 트리거 설정을 완료했습니다. 이번 글에서는 FastAPI 프로젝트를 Docker 이미지로 빌드

이전 포스트(Git 연동 & Webhook, 브랜치/PR 트리거 설계)에서 Jenkins와 GitHub Webhook 연동으로 develop 브랜치 PR merge 시 자동 트리거 설정을 완료했습니다. 이번 글에서는 Spring Boot 프로젝트를 Docker 이미지로

이전 포스트에서 Jenkins와 GitHub Webhook을 연동해 develop 브랜치로의 PR merge 시 파이프라인을 트리거하는 설정을 완료했습니다. 이번 글에서는 이를 바탕으로 React + Vite 프로젝트를 대상으로 한 Docker 기반 CI/CD 배포 파

젠킨스 파이프라인은 CI/CD 프로세스를 코드로 정의하는 기능입니다. 이전글에서 설명한 것 처럼 GitHub Webhook 등의 이벤트가 발생하면 젠킨스가 자동으로 해당 파이프라인 코드를 실행합니다. Jenkins에서 파이프라인을 생성할 때 보면 두 가지 옵션이 있습니

Git 저장소에서 발생하는 이벤트를 Jenkins로 전달하려면, 먼저 Git 저장소에 Webhook을 등록해 두어야 합니다. Webhook은 push, pull_request, PR closed 등의 이벤트가 발생했을 때 미리 지정한 URL로 HTTP 요청을 보내주는

Jenkins로 CI/CD를 설계할 때는 “빌드를 어디서 하고, 어떤 형태의 결과물을 어디서 어떻게 실행할 것인가”를 먼저 정리하는 것이 좋습니다. 본글에서 실무에서 자주 쓰이는 세 가지 패턴을 중심으로 정리하려고 합니다. 해당 패턴들은 배포 서버 구조, 보안(아웃바운

Jenkins는 빌드, 테스트, 배포까지 소프트웨어 개발 과정을 자동화해 CI/CD 파이프라인을 구성할 수 있게 해주는 오픈 소스 자동화 서버입니다. Java 기반으로 동작하며, Git과 같은 버전 관리 시스템, 빌드 도구, 배포 도구와 연동해 코드 변경 시점마다 자동

외부 JAR를 Spring Boot에서 사용한다는 것은, 어느 시점의 classpath에 그 JAR를 올릴지 선택하는 문제입니다. 시점마다 목적과 설계 포인트가 달라지며, 특히 Docker 환경에서는 “언제, 어디에 복사해서 classpath에 태울지”를 명확히 하는

도커 기반 개발에서는 애플리케이션의 컴파일, 테스트, 패키징 단계를 어디서 수행하느냐에 따라 빌드 산출물의 위치와 관리 방식이 크게 달라집니다. 이 글에서는 컨테이너 내부 빌드와 호스트 빌드 방식의 구조, 장단점, 선택 기준을 정리합니다.내부 빌드 (in-contain

도커에서 “마운트(mount)”는 컨테이너 내부 디렉터리를 컨테이너 외부 저장소(호스트 파일 시스템 또는 도커가 관리하는 볼륨)와 연결해서 데이터를 영속화·공유하는 메커니즘을 뜻합니다.애플리케이션 컨테이너는 언제든지 삭제·재생성될 수 있기 때문에, 로그·DB 데이터·업

현대에 있어서 모바일 애플리케이션 환경이 점점 더 복잡해졌습니다. 때문에 기존의 REST 방식은 필요한 데이터만 가져오기 위해 엔드포인트를 제작하거나, 여러 번 반복했어야 했고, 또한 불필요한 데이터가 오는 오버페칭(Overfetching)도 불가피했습니다.데이터 요금