Jun's TID

리엑트에 너무 적응 해버린건가? JSP로 웹단을 개발할 때는 절대 이런 생각을 못 했는데... 요즘은 npm start. 엔터를 치고 물 한 잔 마시고 와도 여전히 로딩 바가 돌고 있으면 참... 너무 느리구나 생각이 든다. React 개발을 몇 년째 해오면서 CRA(Create React App)는 당연한 시작점인 줄 알았다. 하지만 프로젝트 규모가 커질수록 개발 서버 구동 시간은 기하급수적으로 늘어난다. 코드 한 줄 고치고 저장했을 뿐인데 브라우저 반영까지 3초, 5초... 흐름이 뚝뚝 끊긴다. 결국 참다못해 Vite(비트)로 갈아탔다. 그리고 깨달았다. "아, 도구가 문제였구나." 하지만 Vite로 바꾸고 개발 서버가 빨라졌다고 해서 끝난 게 아니다. 2023년에 내가 블로그에 썼던 '코드 스플..

개발자라면 누구나 한 번쯤 겪는 지긋지긋한 순간이 있다. "아, 배포하기 후달린다... 너무 번거롭고 무섭다.." 개인 프로젝트를 단순히 공부 목적으로 진행하는 것이 아닌, 내 서비스로 세상에 내놓기 위해서는 단순히 코드만 옮기는 게 끝이 아니다. DB 데이터 이관, SSL 인증서 발급, 그리고 무엇보다 내가 잠든 사이에도 코드가 배포될 수 있는 자동화(CI/CD)가 필요했다. (그냥 FTP로 파일을 옮기고, 재시작하기? 뭐 뇌 빼고 진행하기에는 이것만한게 없지만, 그랬다간 나중에 트래픽 몰릴 때 손가락만 빨게 될 게 뻔하다.) 오늘은 AWS EC2 인스턴스 하나에 Docker Compose를 박고, Nginx로 대문을 세우고, GitHub Actions로 자동화 도로를 깐 전체 과정을 기록하려고 한다...

제발 사람을 믿지 말고 시스템을 믿어라 사람은 실수를 한다. 특히 피곤하면 더 한다. 하지만 기계는 지치지 않는다. CI/CD는 거창한 게 아니다. "내가 하던 노가다를 스크립트로 짜서 GitHub한테 시키는 것"이다. 구현할 프로세스는 다음과 같다.내 컴퓨터에서 GitHub로 코드를 Push한다.GitHub Actions가 깨어나서 도커 이미지를 Build하고 레지스트리에 Push한다.GitHub Actions가 내 서버에 SSH로 접속해서 최신 이미지를 Pull & Run 한다.이 아름다운 파이프라인을 파일 하나로 만들어보자.본론: 배포 파이프라인 구축 (Core Knowledge)GitHub Actions는 .github/workflows 폴더 안에 있는 YAML 파일을 읽어서 동작한다. 프로젝트 ..

지난 글에서 docker-compose로 로컬 개발 환경을 구축하는 방법을 정리했다. 하지만 내 컴퓨터에서만 잘 돌아가는 서비스는 그냥 '자기만족'일 뿐이다. 이제 이 잘 만든 컨테이너를 서버로 옮겨서 전 세계 사람들이 접속하게 만들어야 한다. FTP로 소스 코드 올리고 서버에서 npm install 하던 시절은 이제 그만 잊자. (그거 하다가 밤샌 날이 며칠인가..) "로컬에선 되는데 서버에선 안 돼요"의 종말신입 시절, 배포 날만 되면 식은땀이 흘렀다. 로컬에서는 기가 막히게 돌아가던 코드가 서버에만 올리면 에러를 뿜었다. 알고 보니 서버의 Node.js 버전이 달랐거나, 실수로 라이브러리 설치를 하나 빼먹었기 때문이었다. "아니, 내 컴퓨터 환경을 그대로 서버에 복사해 넣을 순 없나?" 도커가 ..

수동으로 띄우는 건 미친 짓이다 출근 전 혼자 서비스를 만들 때였다. 아침에 일어나서 코딩 좀 하려는데, DB 띄우고, Redis 띄우고, 백엔드 띄우고, 프론트엔드 띄우는 데만 5분이 걸렸다. 순서라도 틀리면 에러가 뿜어져 나왔다. "이걸 매번 손으로 치라고 만든 건 아닐 텐데." Docker Compose는 여러 개의 컨테이너를 정의하고 실행하기 위한 도구다. docker-compose.yml이라는 파일에 "우리 서비스는 이러이러한 애들이 필요해"라고 적어두면, 도커가 알아서 순서대로 띄워주고, 서로 연결해주고, 죽으면 살려준다. 마치 오케스트라의 지휘자 같다.실전 아키텍처 구현 (Core Knowledge)말로 설명하는 것보다 코드를 보는 게 빠르다. 가장 전형적인 Web 3-Tier Arc..

건설 장비는 입주 전에 치워야 한다 집을 짓는다고 상상해보자. 공사할 때는 크레인, 시멘트 트럭, 인부들의 작업복이 필요하다. 하지만 집이 다 지어지고 입주할 때, 거실 한복판에 크레인을 놔두고 사는 사람은 없다. 소프트웨어 빌드도 똑같다. 애플리케이션을 '만들 때(Build)' 필요한 도구와, '실행할 때(Run)' 필요한 도구는 다르다.빌드: 타입스크립트 컴파일러(tsc), C++ 컴파일러(gcc), 전체 라이브러리, 테스트 도구실행: 컴파일된 결과물(.js, binary), 최소한의 런타임초보 시절엔 이 두 가지를 하나의 이미지에 다 때려 넣는다. 그러니 이미지가 뚱뚱해질 수밖에 없다. Multi-stage Build는 "공사장에서 완성품만 쏙 빼서, 깨끗한 새집으로 옮기는 기술"이다.원리와 구..

빌드 스크립트는 단순한 텍스트 파일이 아니다 구글에 "Node.js Dockerfile", "Python Dockerfile"을 검색하면 수천 개의 예제가 쏟아진다. 대부분 그걸 복사해서 프로젝트 루트에 넣고 빌드 버튼을 누른다. 운 좋게 돌아가면 다행이지만, 조금만 커스텀하려고 하면 막막해진다. "왜 내 이미지는 1GB가 넘지?" "왜 코드 한 줄 고쳤는데 빌드가 5분이나 걸리지?" 이 질문의 답은 Dockerfile 안에 있다. Dockerfile은 이미지를 만드는 설계도이자, 서버 구성을 자동화하는 스크립트다. 이 설계도의 문법과 순서를 이해해야 효율적인 이미지를 만들 수 있다. 가장 대중적인 Node.js 애플리케이션을 예시로 작성법을 해부한다.Dockerfile 문법 해부 (Core Kno..

서론: 편안함과 성능은 반비례한다 도커를 처음 접했을 때, 가장 당황스러웠던 건 팬 소음이었다. 도커만 켜면 조용하던 맥북이 비행기 이륙 소리를 내며 뜨거워졌다. "가볍다며? 왜 이렇게 무거워?" 이유는 간단했다. 도커는 리눅스 기반 기술이다. 윈도우나 맥에서 돌리려면, 눈에 보이지 않는 리눅스 가상 머신(Linux VM)을 하나 띄우고 그 위에서 도커를 돌리기 때문이다. 즉, 도커 자체는 가볍지만, 도커를 돌리기 위한 판(VM)이 무겁다. 대부분 공식 홈페이지에서 Docker Desktop을 받아 설치하고 끝낸다. 하지만 그렇게 기본 설정으로 쓰다가는 IDE가 버벅이고 브라우저 탭이 멈추는 경험을 하게 된다. 이번 글은 내 컴퓨터 자원을 지키면서 도커를 현명하게 설치하는 방법을 정리한다.OS별..

개발자라면 누구나 겪는 악몽이 있다. 입사 첫날, 패기 넘치게 프로젝트를 클론(Clone) 받았다. npm install 혹은 pip install을 쳤다. 그리고 쏟아지는 빨간 에러들. "어? 제 컴퓨터에선 되는데요?" 사수의 이 무심한 한마디. 원인은 뻔하다. 내 컴퓨터엔 파이썬 3.9가 깔려있는데 서버는 3.8이고, 라이브러리 버전이 충돌 나고, OS 환경 변수가 다르고... 이거 맞추느라 코딩은 시작도 못하고 퇴근 시간이 다가온다. 이 '환경의 차이(Environment Discrepancy)'를 없애기 위해 등장한 구세주가 바로 도커(Docker)다. 도커는 "내 컴퓨터 환경 그대로를 박제해서 어디서든 똑같이 돌리겠다"는 야망을 가진 도구다. 단순한 유행이 아니라, 이제는 없으면 개발 못 하..

이제 퇴사를 앞두고 진짜 1인 개발자로 새 시작을 위해 사업자 등록을 하고 AWS에 Start up Credit을 좀 받아보려고 한다. 사업자 등록을 위해서 비상주 오피스를 하나 계약하려고 하는데, 그래도 명색이 1인 사업자인데, gmail.com을 쓰자니... 뭔가 마음에 안들어서, 가비아에서 내 사업자명에 맞춘 도메인을 하나 사서 AWS WorkMail에 연결하여 딱 ceo를 이름으로 박았다..ㅋㅋ 이 과정을 블로그에 좀 적어보려고 한다.1. 가비아 도메인 구매 & AWS WorkMail 조직 생성가장 먼저 할 일은 역시 도메인 쇼핑이다. 가비아에서 slowflowsoft.com을 구매했다. 그리고 AWS 콘솔로 넘어가 WorkMail 서비스를 켠다.AWS Console -> WorkMail 검색C..