create-danver-app 으로 초기 설정 시간 단축
들어가며 내 목표는 여러 개의 서비스를 빠르게 만들고, 그중 사용자 반응이 좋은 서비스에 집중하는 것이다. 그러나 매번 새 프로젝트를 시작할 때마다 초기 설정 과정에 많은 시간을 소모하고 있었다. 반복되는 작업의 비효율을 줄이고자 create-danver-app을 만들게 되었다. 아이디어는 create-react-app에서 얻었다. 하나의 명령어로 프로젝트의 초기 환경 설정을 간편하게 마칠 수 있다는 점에서 큰 효율성을 느꼈으며, 이를 내 프로젝트에도 적용하여 생산성을 높이고자 했다. 구현 계획 , 등 템플릿 이름을 활용해 다양한 프로젝트 템플릿을 손쉽게 선택하고 설치할 수 있도록 지원한다. 템플릿의 기본 환경은 React, Vite, TailwindCSS, TypeScript로 구성한다. 배포 방식으로는 는 Cloudflare Pages를 이용하며, 는 개인 Harbor 레지스트리에 Docker 이미지를 올리고, GitHub Actions 및 Docker Swarm으로 배포한다. 프로젝트의 표준 폴더 구조를 사전에 제공한다. 초기 테스트를 위한 샘플 API 및 페이지를 포함한다. 손쉬운 자동 배포를 위한 기본 배포 스크립트를 제공한다. 공개 프로젝트의 특성상 보안 관리를 위해 secret 값은 파일에 키(KEY)만 미리 생성한다. 표준 API 응답(response) 타입을 미리 지정한다. 기본적인 파일을 제공하여 불필요한 파일이 Git에 올라가지 않도록 관리한다. 진행 과정 새 디렉토리 생성 Node.js 초기화 옵션을 통해 기본값으로 package.json을 생성한다. 필요한 패키지 설치 템플릿 폴더에 복사할 파일을 저장 템플릿 폴더에 있는 파일들이 그대로 복사되는 구조이기 때문에, 이후에는 각 템플릿을 구성하면 마무리된다. 아래는 디렉토리 구조이다. 로컬 테스트 설정 package.json에 다음 내용을 추가하고 명령어를 실행하여 로컬 환경에서 바로 명령어를 테스트할 수 있다. 모든 코드는 공개되어 있습니다. 이해하기 어려운 내용이 있으면 Github에서 코드를 확인할 수 있습니다. npm 저장소 링크도 함께 공유합니다. 기타 메모 은 패키지를 로컬에 영구적으로 설치하는 방식이지만, 은 임시 디렉토리에 설치하여 사용 후 자동 삭제하는 방식으로, 패키지 관리 부담을 덜어준다. npm은 public 저장소는 무료로 제공하나, private 저장소 사용 시 비용이 발생하므로 프로젝트의 공개 여부와 비용을 고려해 관리 방식을 결정할 필요가 있다.
Danver Business 기획 및 디자인
1인 개발자로서 내가 선택한 전략은 여러 개의 앱과 웹 서비스를 개발한 후, 반응이 좋은 서비스에 집중해서 키워나가는 것이다. 현재 안드로이드와 iOS 사업자 계정 등록을 위한 DUNS 번호 발급을 기다리고 있다. 이 기다림의 시간을 효율적으로 보내기 위해, PostHog를 활용한 서비스 모니터링 대시보드를 만들어 보기로 했다. 처음에는 PostHog 자체에서 모든 분석과 모니터링을 끝내려 했지만, 여러 프로젝트 데이터를 한눈에 보고 관리하는 데는 한계가 있었다. 그래서 다음과 같은 구조로 대시보드를 설계하기로 했다. 이 서비스를 만드는 궁극적인 목표는 내가 운영하는 수많은 앱과 웹 서비스를 이 페이지 하나에서 빠르게 확인하고 관리할 수 있도록 하는 것이다. 또한 앞으로 여러 가지 서비스를 계속 만들어야 하므로 초기 설정을 반복하지 않도록, 이라는 도구를 개발하여 백엔드와 프론트엔드 모두에 대해 미리 만들어진 템플릿과 배포 스크립트를 빠르게 적용할 수 있도록 할 계획이다. 1단계: PostHog를 활용한 모니터링 디자인 개발 시작 전, Figma를 통해 미리 디자인과 UI를 구성하여 개발 단계에서 시행착오를 줄일 계획이다. 데이터 수집 데이터는 PostHog를 이용해서 각 서비스의 프론트엔드와 백엔드에서 이벤트 형태로 수집한다. 각 프로젝트 별로 PostHog에서 새로운 프로젝트를 생성한다. Danver Business 대시보드 주소: business.danver.io 역할: PostHog로부터 MAU, DAU, LTV, 발생한 매출 등 핵심 지표를 정기적으로 불러와서 캐싱한다. 발생한 매출에 포함되는 내용은 광고, 인앱결제, 구독이다. LTV를 계산하는 이유는 구글 애즈 광고를 돌려서 사용자를 유입시킬 때 광고비 산정에 필요하기 때문이다. 여러 서비스의 지표를 한눈에 볼 수 있게 대시보드 형태로 제공한다. 더 자세한 분석이 필요할 때는 각 서비스의 PostHog 프로젝트 대시보드로 연결해 자세히 조회한다. Danver-business 웹페이지 기술 스택 및 배포 방식 React, Vite, TypeScript, TailwindCSS를 이용해 모바일 반응형으로 개발한다. Cloudflare Pages를 이용해 무료로 정적 사이트로 자동 배포한다. 백엔드 서버 API endpoint 및 배포 방식 주소: https://business-api.danver.io Go 언어를 이용해 개발한다. Docker-swarm을 이용해 배포한다. Harbor와 Github Actions를 이용해 자체 서버에 자동 배포한다. SSL 인증서 관리 이미 설치된 Traefik을 이용하여 SSL 인증서를 자동 발급하고 HTTP 요청은 HTTPS로 자동 리다이렉트한다. 관리자 계정 관리 현재는 관리자만 사용할 수 있도록 관리자 계정만 수동으로 생성한다. DB Schema Users 테이블: id, pw(hashed), is_admin Projects 테이블: user_id, 프로젝트 이름, 생성일, 상세 대시보드 링크, 앱스토어 링크, 플레이스토어 링크, 서비스 링크 Project_metrics 테이블: project_id, dau, mau, revenue_total, ltv, created_at, recorded_date 필요한 웹 페이지 구성 로그인 페이지 대시보드 페이지 (각 프로젝트 별 주요 지표 조회 역할) 프로젝트 추가, 수정, 삭제 기능은 모달(Modal)로 처리한다. 2단계: 슬랙을 통한 매일 아침 요약 알림 매일 아침 각 프로젝트의 주요 내용을 정리하여 슬랙을 통해 요약본을 전달한다. 3단계: 실시간 오류 및 사용자 리뷰 모니터링 자체 호스팅한 Sentry를 통해 실시간으로 오류를 감지하고, 중요한 오류가 발생했을 때 빠르게 대처할 수 있도록 한다. 앱스토어와 플레이스토어에 올라온 사용자 리뷰를 정기적으로 확인하여 부정적인 리뷰에 신속히 대응할 수 있게 한다. 4단계: CS 및 건의사항 관리 CS와 건의사항을 채팅이 아닌 티켓 형태로 받아 처리할 수 있는 시스템을 개발한다. 1인 개발자로서 시간이 부족하기 때문에 채팅 형태의 대응이 어려워 티켓 시스템을 채택했다. 이를 통해 각 서비스에서 별도의 CS 기능을 개발하지 않고도, 제공된 링크를 통해 사용자가 쉽게 티켓을 작성할 수 있도록 지원한다.
PostHog를 무료로 사용하는 방법, 셀프 호스팅
들어가며 앱 서비스를 1인으로 개발하고 운영하다 보면, 사용자 반응을 빠르게 분석하고 대응하는 게 매우 중요하다. 내가 원했던 것은 간단했다. 서비스마다 어떤 지표가 잘 나오는지 한눈에 보고, 반응이 좋은 서비스에 더욱 집중하는 것이었다. 나는 PostHog라는 오픈소스 분석 도구를 선택했다. PostHog는 사용자 이벤트 기반의 제품 분석 도구로, 특히 셀프 호스팅을 지원하기 때문에 비용 걱정 없이 자체 서버에 배포할 수 있다는 장점이 있다. 이번 글에서는 PostHog를 셀프 호스팅으로 구축하며, 내가 중점적으로 분석하고자 했던 것들을 기록한다. 내가 분석하고자 했던 주요 지표: 사용자 활성도: DAU(일간 사용자), MAU(월간 사용자) 매출 분석: 광고 수익, 인앱 결제, 정기구독 등 서비스별 매출 사용자 가치(LTV) 분석 유입 경로 분석과 리텐션(잔존율) 이 글을 통해 비슷한 목표를 가진 분들이 쉽게 PostHog 셀프 호스팅 환경을 구성할 수 있기를 바란다. 설치 방법 설치 방법은 docker-compose를 통해 진행되며, 서버 환경은 Ubuntu 서버를 기준으로 설명한다. 설치 방법은 공식 문서에 자세히 나와있다. 아래 명령어를 통해 설치 파일을 다운로드하고 실행할 수 있다. 트러블 슈팅 현재 버전은 아래 이미지처럼 처음 작동시 plugin server에서 에러가 발생하는 버그가 있다. 이에 대한 해결 방법은 Github Issue에 나와있다. 현재 버전을 그대로 사용하지 말고, 작동하는 버전 태그를 사용해서 다운로드 하면 해결된다. 나 역시 그렇게 설치했고, 이제 사용해보려 한다. 마치며 셀프 호스팅의 가장 큰 장점은 비용 걱정 없이 무제한으로 데이터를 분석하고 활용할 수 있다는 점이다. 1인 개발자로서 내가 관리하는 여러 앱 서비스의 사용 행태를 분석하고, 반응이 좋은 서비스에 집중할 수 있는 인사이트를 얻었다. 이번에 구축한 PostHog 분석 환경이 앞으로 내 서비스의 성장을 가속화하는 기반이 되길 기대한다.
Sentry를 무료로 사용하는 방법, 셀프 호스팅
들어가며 Sentry는 실시간 오류 모니터링 서비스로 잘 알려져 있습니다. 그런데 사실 Sentry는 오픈소스 프로젝트이기도 해서, 굳이 클라우드 요금제를 쓰지 않고도 Self-Hosted Sentry 가이드를 참고하면 누구나 쉽게 배포해 사용할 수 있습니다. 도커 컴포즈(docker-compose.yml) 구성 파일을 공식적으로 제공하기 때문에, 가이드에 따라 설치 스크립트를 실행하면 30분 내외로 작동하는 환경을 구축할 수 있었습니다. 이 방식은 비용 절감 외에도 여러 이점이 있어, 여기서 셀프 호스팅의 장단점을 간단히 정리해보려고 합니다. 장점 보안적 이점 소스맵 등의 민감 정보가 외부 클라우드에 노출되지 않습니다. 회사 내부 서버에 모든 오류 로그가 저장되므로, 내부 보안 정책이나 개인정보 보호 측면에서 추가적인 안심 요소가 있습니다. 비용 절감 (무료 이용) 클라우드 Sentry를 사용하면 이벤트(오류) 발생량에 따라 비용이 늘어날 수 있습니다. 셀프 호스팅은 서버만 확보되어 있다면 별도의 사용량 요금을 내지 않아도 됩니다. 이벤트가 많아져도 추가 과금이 없어, 대규모 프로젝트에서는 큰 이점이 됩니다. 온전한 내 데이터 확보 모든 데이터를 직접 소유·관리하기 때문에, 보안 외에도 로그 분석, 백업/복구 정책 등을 자유롭게 설정할 수 있습니다. 단점 운영 및 유지보수 부담 오류가 발생하거나 서버가 다운되면, 직접 원인을 파악하고 해결해야 합니다. 도커 환경, DB(예: PostgreSQL, Redis), 버전 업그레이드, SSL 인증서 갱신 등도 스스로 챙겨야 합니다. 클라우드 전용 기능 제한 Sentry 클라우드 서비스에서는 Performance Monitoring, Discover, 다양한 Integrations 같은 고급 기능을 제공하는데, Self-Hosted 버전에는 제한되거나 구성 과정이 더 복잡할 수 있습니다. 필요 기능이 클라우드 요금제에만 포함되어 있다면, 셀프 호스팅으로는 사용이 어려울 수 있습니다. 설치 방법 Sentry 공식 문서에서 제공하는 셀프 호스팅 가이드를 따르면 어렵지 않게 설치할 수 있습니다. 아래는 기본적인 설치 순서를 간략히 요약한 예시입니다. 레포지토리 Clone git clone 명령어로 Sentry 공식 self-hosted 저장소를 다운로드합니다. 설치 스크립트 실행 ./install.sh를 실행하면, 도커 컨테이너 구동에 필요한 이미지 다운로드와 초기 설정(환경 변수, DB 마이그레이션, 키 생성 등)이 자동으로 진행됩니다. 서버 구동 docker compose up --wait 명령어로 모든 컨테이너를 실행합니다. 설치가 정상적으로 끝났다면, 브라우저에서 http://<서버 도메인 혹은 IP>:9000 등을 통해 Sentry 대시보드에 접근할 수 있습니다. 마무리하며 Sentry 셀프 호스팅은 운영 비용을 크게 줄이면서도, 보안 측면에서 강점을 가질 수 있는 방법입니다. 다만, 관리·운영의 책임이 전적으로 팀에 있으므로, 어느 정도 DevOps 역량이 필요합니다. 프로젝트 규모나 회사 내부 정책, 예산, 기능 요구사항 등을 따져보고, 클라우드 vs. 셀프 호스팅 중 가장 적합한 방식을 선택하시길 바랍니다.
Nominatim을 이용해서 주소 경위도 변환 하기
들어가며 이번에 만들고 있는 개인 앱에서 주소를 위·경도로 변환하거나, 반대로 위·경도를 주소로 바꿔야 하는 기능이 필요해졌습니다. 처음에는 많은 개발자들이 그렇듯 구글 지도 API를 고려했는데, 1,000회 호출당 5달러라는 과금 체계가 부담이 되었습니다. 예를 들어 하루 1,000번씩 호출만 해도 한 달에 150달러(약 20만 원) 정도가 나오니, 테스트나 초기 운영 단계에서조차 비용 압박이 상당했죠. 반면, 네이버 지도 API는 1,000회에 500원으로 훨씬 저렴하지만 국내 서비스에 특화되어 있기 때문에 글로벌 타겟이라면 사용할 수 없다는 한계가 있습니다. 이런 고민 끝에, 오픈 스트리트맵(OpenStreetMap) 데이터를 활용해 무료로 주소 변환을 할 수 있는 Nominatim을 직접 호스팅하기로 결정했습니다. 구글이나 네이버와 달리 사용량에 따른 추가 과금이 없고, 전 세계 지도 정보를 바탕으로 원하는 대로 커스터마이징할 수 있다는 점이 가장 큰 장점입니다. 물론 초기 셋팅(서버 구축, 데이터 인덱싱, 운영 노하우) 과정이 번거롭긴 하지만, 한 번 경험해 두면 나중에는 훨씬 수월하게 적용할 수 있어 장기적인 운영 비용을 크게 절감할 수 있으리라 기대합니다. Nominatim 소개 Nominatim은 오픈스트리트맵(OpenStreetMap) 프로젝트에서 제공되는 주소 검색(Geocoding) 및 역지오코딩(Reverse Geocoding) 엔진이다. 간단히 말해 "장소 이름이나 주소를 위·경도로 바꿔주고, 위·경도를 주소로 바꿔주는" 소프트웨어라고 생각하면 된다. 작업 순서 작업은 사실 별거 없었다. 도커로 이미지를 다운로드해서 띄우면 처음에 자동으로 초기화 과정을 진행하고 마무리되면 바로 사용할 수 있다. 다만, 전 세계 지도 데이터를 가지고 있다보니 원본 파일 용량만 80GB로 방대하다. 전체 OSM 파일 다운로드 (80GB) 원본 파일의 용량은 80GB이지만, 사용하기 위해 DB에 초기화하면 800GB로 증가하므로 주의할 것 Docker.compose에 작성하기 이렇게 docker-compose를 띄우면 약 20\~30분 후에 서버가 사용할 수 있는 상태가 된다. 새롭게 알게 된 것 용량이 너무 큰 경우 필요에 따라 데이터를 필터링해서 줄일 수 있다. 나는 행정 지역 단위로도 충분했기에 이렇게 필터링하자 80GB의 데이터가 1GB로 줄었다. 이렇게 용량을 줄이는 것이 중요한 이유는 1GB의 필터링된 데이터 조차도 DB에 입력하면 40GB로 늘어나기 때문이다. 행정구역 단위로 필터링 최초에 실행할경우 원본 지도 데이터를 이용해서 초기화하는 작업이 진행되는데 이때 많은 정보가 DB에 입력되므로, 네트워크 연결을 사용하지 말 것. 기존 대비 속도가 10배이상 느려질 수 있다. 도커 스웜을 사용하고 있어서 nfs를 사용해서 설정했는데, 30분이면 끝나는 작업이 4시간 이상 소요되었고, 이마저도 중간에 I/O 에러가 발생해서 끊어지는 문제가 발생했다. 마무리 확실히 활용할 수 있는 개인 서버가 생기니까 서비스 개발이 여러모로 더 편해진 것 같다. 이 정도의 서비스를 오픈소스로 하루만에 띄워서 사용할 수 있음에 감사하다.
포트원(Portone) PG사 계약 후기
들어가며 다국어 블로그 서비스인 DLog를 운영하면서, 구독 기반의 유료 기능을 제공하고 싶었습니다. 이를 위해 신용카드 정기결제 기능이 필요했고, 필연적으로 PG사와의 계약이 요구되었습니다. 여러 방법을 고민하던 중, 포트원을 활용하면 PG사가 변경되더라도 동일한 코드를 그대로 사용할 수 있다는 점을 알게 되었고, 이는 매우 큰 장점이었습니다. 포트원은 PG사와 개발자 사이의 중간다리 역할을 안정적으로 해주는 인상을 받았습니다. 이 글에서는 실제로 포트원을 통해 토스페이먼츠와 계약하고 정기결제 시스템을 구축한 과정을 공유해보려 합니다. 포트원(Portone)을 선택한 이유 다양한 PG사 선택 가능 일반 카드 결제, 정기 결제, 간편결제, 해외결제, 본인 인증 등 다양한 결제 서비스가 가능하며, 포트원에서 폭넓게 지원하고 있습니다. 문서화가 잘 되어 있음 공식 개발자 문서에 연동 방법이 잘 정리되어 있고, 실제 연동 과정 중 어려움이 있을 때에도 빠르고 친절한 답변을 받을 수 있었습니다. 실제 계약에 필요한 서류 📄 사업자 등록증 PG사와 계약을 위해 필수로 요구되는 서류입니다. 저 역시 사업자를 등록했고, 사무실이 없어 집 주소를 등록했는데, 집 주소가 공개되는 단점 또한 있었습니다. 추후에 사무실이나 비상주 사무실을 얻어서 변경하면 됩니다. 통신판매업 신고 웹/앱으로 구독 상품을 판매하려면 통신판매업 신고가 필요했습니다. 정부24에서 할 수 있으며, 매년 1월에 약 4만원의 비용을 지불해야 합니다. 환불 정책 URL 환불 기준 및 절차를 명시한 페이지를 서비스에 포함시켜야 하며, 이 문서의 URL을 PG사에 제출해야 합니다. [\[예시\]](https://blog.danver.io/policies/refund) 토스페이먼츠 계약 진행 포트원을 통해 토스페이먼츠와 계약을 진행하면서 가장 좋았던 점은 명확한 가이드와 빠른 피드백이었습니다. 제 경우, 보통 1\~2일 이내에 답변을 받을 수 있었고, 담당자의 안내에 따라 차근차근 진행하면 큰 어려움 없이 빠르게 절차를 마칠 수 있었습니다. 신청부터 계약 완료까지 약 일주일 이내로 모든 과정이 마무리되었고, 처음 PG사 계약을 진행했던 제게도 충분히 따라갈 수 있을 만큼 친절한 흐름이었습니다. 이번 경험을 통해 PG사 계약 절차를 익힐 수 있었고, 다음에 새로운 서비스를 런칭할 때는 훨씬 더 빠르고 수월하게 진행할 수 있을 것 같다는 자신감도 얻게 되었습니다. 정기 결제 방식 제가 신청한 서비스는 신용카드 정기 결제였고, 이를 구현하는 방식은 크게 두 가지로 나뉘었습니다. 하나는 빌링키 방식, 다른 하나는 API를 통한 직접 결제 방식입니다. 빌링키 방식 사용자가 토스페이먼츠의 결제 위젯을 통해 카드 정보를 입력하면, 카드 정보는 토스페이먼츠에서 안전하게 보관되고, 저희 쪽에는 결제에 사용할 수 있는 빌링키만 제공됩니다. 카드 정보를 직접 저장하지 않기 때문에 보안 부담이 적고 PG사 심사 및 계약도 비교적 간단하고 빠릅니다. API 직접 결제 방식 이 방식은 카드 정보를 직접 저장하거나 전달받아 결제를 처리하는 구조입니다. 결제 위젯을 사용하지 않아 UI/UX를 유연하게 구성할 수 있다는 장점이 있지만, 보안 요건이 매우 까다롭고, PCI-DSS 등의 보안 인증 요건을 충족해야 할 수도 있습니다. 현재 DLog 블로그는 빌링키 방식을 사용하고 있으며, 초기 설정이 간단하고 빠르게 구현 가능한 점에서 유리하다고 판단했습니다. 다만, 두 가지 방식을 모두 경험해보고 싶어 추후에는 API 방식으로도 테스트해볼 계획입니다. --- 앞으로 또 궁금한 것 새로운 서비스를 런칭할 때 포트원 가입비나 심사비용을 다시 내야 하는지 하나의 PG사 계약으로 여러 서브 도메인 서비스에 정기결제를 적용할 수 있는지
Github Self-hosted runner 사용 후기
Github Actions란?! Github Actions는 Github에서 제공하는 CI/CD 도구이다. 코드 변경이 일어났을 때 자동으로 특정 작업을 수행할 수 있다. 예를 들어 코드가 푸시될 때 테스트를 자동으로 실행할수도 있고, 새벽마다 데이터를 백업할 수도 있다. 이 때 사용할 수 있는 서버를 제공해주는데 ubuntu, windows, macOS 등 다양한 OS를 빌려서 사용할 수 있다. 물론 월마다 사용할 수 있는 무료 시간이 제한되어 있고, 그 이상을 사용하려면 돈을 지불해야 한다. Self-hosted runner란? Self-hosted runner란 서버를 빌려서 사용하는 것이 아니라 내가 제공하는 서버에서 스크립트를 실행할 수 있는 기능이다. 왜 굳이 내 서버에서 스크립트를 실행하는걸까? 그 이유는 아래와 같다. 비용 절감 내 서버에서 실행하기 때문에 무료로 시간 제한 없이 사용할 수 있다. 더 빠른 실행 속도 Github-hosted runner는 매번 인스턴스를 새로 띄워야해서 지연 시간이 있고, 종종 많은 사용자가 사용할 때는 대기 시간도 있다. 또한, 성능 좋은 서버가 있다면 더 높은 성능으로 실행할 수 있다. 로컬 네트워크나 내부 자원에 접근할 수 있다. 사내 DB, 프라이빗 서버 등은 외부 runner가 접근할 수 없는데 내 서버이기 때문에 로컬 환경에 자유롭게 접근할 수 있다. 하드웨어를 내 마음대로 설정할 수 있다. CPU, GPU, Memory 등을 제한 없이 자유롭게 구성할 수 있기 때문에 더 다양한 용도로 사용할 수 있다.
Github Actions를 이용한 스케줄링
DLog 블로그 서비스를 시작하면서 가장 걱정됐던 부분은 바로 데이터베이스 백업이었다. MongoDB Atlas 같은 클라우드 서비스를 사용하고 있다면 자동 백업이 제공되겠지만, 나는 온프레미스 환경에서 MongoDB를 운영하고 있었기 때문에 직접 백업 시스템을 구축해야 했다. 처음에는 간단하게 Ubuntu의 cron 명령어를 이용해 정기적으로 mongodump를 실행하도록 설정했다. 하지만 어느 순간부터 이 스케줄링이 더 이상 작동하지 않았고, 이를 미처 파악하지 못한 채 DB 마이그레이션을 진행하다 보니 일부 데이터가 유실되는 아찔한 상황을 겪었다. 이후 “절대 꺼지지 않을 백업 시스템”이 필요하다고 판단했다. 고민 끝에 선택한 방법은 GitHub Actions의 schedule 기능을 이용하는 것이었다. 이 방식은 다음과 같은 장점이 있다: 서버가 꺼지거나 재부팅되어도 영향을 받지 않는다 GitHub Actions 자체가 안정적으로 돌아간다 백업 로그가 GitHub에 남기 때문에 문제 발생 시 빠르게 원인 파악이 가능하다 이제는 매일 정해진 시간에 mongodump로 백업한 아카이브 파일을 생성하고, 이를 AWS S3에 업로드하도록 설정해두었다. 불안했던 백업이, 이제는 신뢰할 수 있는 자동화된 시스템으로 바뀌었다.
Docker Swarm, Traefik을 이용한 서버 관리
들어가며 개인 프로젝트를 운영하면서 여러 개의 서비스를 관리하게 되었고, 이를 위해 매달 발생하는 AWS 비용이 점점 부담으로 다가왔다. 수익이 없는 초기 단계에서는 고정 지출을 줄이는 것이 중요했기에, 비교적 저렴한 미니 서버 3대를 직접 구매해 셀프 호스팅 환경을 꾸리기로 했다. 그동안은 단일 서버 위에서 Docker Compose만으로 서비스를 구성해왔지만, 서버가 여러 대가 되자 Compose 방식에는 분명한 한계가 있었다. 특히 CPU와 메모리 사용량을 기준으로 컨테이너를 수동으로 배치해야 했고, 확장성이나 관리 측면에서도 비효율이 컸다. 이를 해결하기 위해 도입한 것이 Docker Swarm이다. Swarm은 여러 대의 서버를 하나의 클러스터처럼 구성할 수 있게 해주고, 서비스 단위로 유연한 배포와 확장을 지원한다. 여기에 Traefik을 함께 사용하면 각 서비스마다 Nginx 설정을 따로 하지 않아도 되고, HTTPS 인증서도 자동으로 발급 및 갱신되므로 운영 부담이 크게 줄어든다. 혼자서 개발하고 운영을 병행하는 나에게 Docker Swarm과 Traefik은 복잡한 인프라를 간결하게 유지할 수 있는 좋은 선택지였다. 이 글에서는 실제로 어떻게 구성했는지 그 과정을 정리해보려 한다. 하드웨어 구성 미니 서버 사양 소개 이번에 구축한 서버는 Asrock DeskMini X300 베어본을 기반으로 구성된 미니 PC 3대입니다. 크기는 작지만, 서버용으로 충분한 성능을 낼 수 있어 셀프 호스팅 환경에 잘 맞는 선택이었습니다. 각 서버의 주요 사양은 다음과 같습니다. 모델 : Asrock DeskMini X300 CPU : Ryzen 5600G RAM : 64GB HDD : 1TB SSD 쿨러 : \[NOCTUA\] NH-L9a-AM4 (저소음 쿨러) 이 구성은 개인 서비스 10\~20개 정도를 컨테이너로 돌리기에 충분한 성능을 제공하며, RAM과 SSD 용량이 넉넉해서 무거운 서비스도 여유롭게 운영할 수 있습니다. 3대를 구매했습니다. 24시간 집에서 운영되는 상황을 고려해서 저소음 쿨러를 구매해서 장착했습니다. (이전에 회사에서 서버를 운영했던 경험이 도움이 되었습니다. 어찌나 시끄럽던지..) 전력 소비도 일반 데스크탑 대비 적은 편이라, 24시간 항상 켜져 있는 홈 서버로도 적합합니다 네트워크 장비 소개 현재 사용하는 인터넷 회선은 KT 기가 인터넷이며, KT의 특징 중 하나는 모뎀의 각 LAN 포트마다 별도의 공인 IP를 제공한다는 점입니다. 이를 활용해 서버 3대를 각각 독립적으로 외부에서 접근 가능하도록 구성했습니다. 네트워크 장비는 다음과 같은 TP-Link Omada 시리즈로 구성되어 있습니다: 라우터: TP-Link ER605 스위치: TP-Link TL-SG2210P (2.5Gbps 지원, PoE) 컨트롤러: TP-Link OC200 무선 AP: TP-Link EAP650 (Wi-Fi 6) 이 장비들은 모두 Omada SDN 시스템으로 통합 관리되며, VLAN 구성 및 트래픽 모니터링, 포트 단위 제어가 가능한 환경을 제공합니다. 서버 1대 KT 모뎀에 직접 연결해서 공인 IP 부여 Harbor Docker 레지스트리, DB, 문서 시스템 등 고정 서비스 운영 서버 2대 Docker Swarm으로 클러스터 구성 여러개의 개인 서비스를 컨테이너 단위로 분산 운영 이러한 구성 덕분에 Harbor에서 이미지를 관리하면서, 나머지 서버에서는 유연하게 서비스 배포/확장/관리를 수행할 수 있는 구조를 완성했습니다. 처음에는 3대 모두를 클러스터로 구성해서 모든 서비스와 인프라를 통합하려 했지만, Harbor와 같은 복잡한 서비스를 Docker Swarm 환경에서 안정적으로 운영하는 데 제약이 있었고, 더 유연한 구성을 위해 현재와 같이 역할을 분리하게 되었습니다. 장점 Traefik을 이용한 쉬운 트래픽 관리 Traefik을 도입하면서 가장 편리했던 점은 트래픽 관리가 훨씬 단순해졌다는 것입니다. 기존에는 각 서비스마다 Nginx 설정을 수동으로 작성하고, SSL 인증서도 수작업으로 발급받아야 했습니다. 하지만 Traefik은 다음과 같은 기능을 자동으로 처리해줍니다: Let’s Encrypt를 통한 HTTPS 인증서 자동 발급 및 갱신 docker-compose.yml의 라벨 설정만으로 도메인 연결, 리다이렉트, 포트 지정 가능 기본 제공되는 대시보드로 현재 라우팅 상태와 서비스 상태를 시각적으로 모니터링 가능 1인 개발자 입장에서는 설정을 반복하지 않아도 되는 점이 굉장히 큰 장점이었습니다. 손쉬운 확장 Docker Swarm을 사용하면 새로운 서비스를 배포하거나 확장할 때 훨씬 간단합니다. 새로운 워커 노드를 클러스터에 등록하기만 하면, Swarm이 자동으로 컨테이너를 가용 자원에 따라 분배해줍니다. 즉, 더 이상 “이 서비스는 이 서버에서 돌려야지”라고 고민할 필요 없이, Swarm이 알아서 컨테이너를 배포하고 자원을 분산해줍니다. 무중단 배포 (Rolling Update) update_config 설정을 통해 기존 서비스를 중단하지 않고 새로운 버전으로 교체할 수 있습니다. Swarm은 기존 컨테이너를 내리기 전에 새로운 컨테이너를 먼저 띄우고, 정상 동작을 확인한 뒤 기존 인스턴스를 종료합니다. 서버가 2대 이상일 경우, 새 컨테이너를 다른 노드에 먼저 배치하기 때문에 실제 서비스 이용자는 전혀 눈치채지 못한 채로 배포가 이루어집니다. 서비스 격리 및 롤백 기능 각 서비스는 독립적인 컨테이너로 격리되어 실행되기 때문에 문제가 생긴 특정 서비스만 빠르게 수정하거나 롤백할 수 있습니다. 예를 들어 이미지 업데이트 후 문제가 발생했다면 아래 명령어 한 줄로 이전 상태로 복구할 수 있어, 빠르고 안전한 운영이 가능합니다. Traefik 기반의 동적 라우팅 Traefik은 도커 라벨을 기반으로 자동으로 라우팅을 구성해줍니다. docker-compose.yml에 몇 줄만 추가하면, 도메인, 경로, HTTPS 적용까지 자동으로 처리됩니다. 이는 수동 설정이 많은 Nginx와 달리, 서비스가 추가되거나 이름이 바뀌어도 라우팅 구성을 다시 손댈 필요가 없다는 점에서 큰 장점입니다. 마무리하며 혼자서 개발하고 운영을 모두 맡아야 하는 1인 개발자에게 가장 중요한 건, 복잡한 인프라를 단순하게 유지하는 것이라고 생각합니다. 이번에 Docker Swarm과 Traefik을 활용해 서버를 구성하면서 느낀 건, 굳이 복잡한 툴이나 클라우드 환경이 아니더라도 스스로 충분히 잘 동작하는 인프라를 만들 수 있다는 자신감이었습니다. 물론 처음 구성할 땐 시행착오도 있었고, 특히 Docker Swarm에 대한 실전 자료가 많지 않아서 헤맸던 부분도 있었지만, 직접 구성하고 테스트하며 쌓은 경험은 어떤 문서보다 강력한 기반이 되어주었습니다. 누군가는 "굳이 Docker Swarm을 쓰느냐"라고 할 수도 있지만, 개발부터 배포, 운영까지 혼자서 해야 하는 상황에서는 간결함, 자동화, 유지보수 용이성이 가장 큰 장점이자 무기라고 생각합니다.
ChatGPT 크롬플러그인 제작
시작하게 된 이유 ChatGPT Pro 모델을 사용하면서 답변을 받기까지 약 1분이 걸리는 점이 불편했다. 기다리는 동안 새로운 궁금증이 떠오르지만, 답변이 끝나야만 다음 질문을 할 수 있어 종종 질문을 잊어버리곤 했다. 이 문제를 해결하기 위해, 질문을 끊임없이 이어갈 수 있으면서도 답변이 순차적으로 진행되는 시스템을 직접 만들어보기로 결심했다. ChatGPT Queue 링크 기능 연속 질문 등록 우측 상단 팝업에서 언제든지 새로운 질문을 추가할 수 있다. Add 버튼을 누르면 질문이 큐에 등록되며, 현재 진행 중인 답변이 마무리되면 자동으로 다음 질문이 처리된다. 질문 관리 기능 진행 중인 질문을 삭제할 수도 있고, 전체 질문 목록을 한눈에 확인할 수도 있다. 개발 과정 및 일정 기능 자체는 단순했기 때문에 개발을 빠르게 진행할 수 있었고, 약 3일 만에 마무리한 것으로 기억한다. 가장 어려웠던 부분은 크롬 플러그인 제작 방식을 이해하는 것이었다. 플러그인이 어떻게 동작하는지, 어떤 설정이 필요한지, 그리고 크롬에서만 지원하는 권한과 API를 익히는 과정이 핵심이었다. 이 부분만 해결되니, 구현 자체는 빠르게 진행할 수 있었다. 마무리하며 크롬 플러그인을 처음 만들어봤지만, 직접 개발해보니 다음에 유사한 기능이 필요할 때 훨씬 쉽게 접근할 수 있을 것 같다는 자신감이 생겼다. 새로운 도전은 늘 어렵지만, 직접 해보면 생각보다 더 의미 있는 경험이 되는 것 같다.
한 대의 서버에서 다중 서비스 운영하는 법
들어가며 인디해커로 여러 개의 서비스를 운영하며 수익화를 시도하고 있지만, AWS 서버 이용 요금이 부담이 됐다. 더 저렴한 대안을 찾던 중, 집에서 사용하지 않던 게임용 PC를 서버로 활용해보기로 했다. 이 PC는 약 5년 전, 200만 원 정도 들여 맞춘 장비인데, 같은 사양을 AWS에서 사용하려면 최소 월 60만 원 이상이 필요하다. 게다가 내가 운영하는 서비스들은 대부분 유저가 없어 트래픽을 거의 사용하지 않는다. 그렇다면 이 서버에서 Docker를 활용해 여러 서비스를 효율적으로 운영할 수 있지 않을까? 구성 단계별로 접근하면 이해하기 쉽다. 우선 가장 기본적인 구성을 살펴보자. 1\. Ubuntu 서버에 Docker로 여러 서비스 실행 Ubuntu 서버에서 각 서비스를 Docker 컨테이너로 실행한다. Nginx를 이용해 트래픽을 적절하게 분배한다. 이렇게만 해도 외부 접속 없이 사내 네트워크 수준의 서비스 운영이 가능하다. 2\. Nginx를 활용한 서비스 구분 Nginx 설정 파일에서 server_name을 사용해 각 서비스를 분리하면, 트래픽을 적절한 Docker 컨테이너로 라우팅할 수 있다. 예제 설정: 3\. 외부에서 IP로 접속 가능하도록 설정 외부에서 직접 서버에 접근하려면 공인 IP를 서버에 연결해야 한다. 공유기를 사용하는 경우, 포트 포워딩을 설정해 외부 트래픽을 서버로 유도한다. 설정 예제: 공유기에서 80, 443 포트를 서버로 포워딩 4\. 도메인 연결 (AWS Route 53 등 활용) AWS Route 53 같은 서비스를 이용하면 IP 대신 도메인 주소를 사용할 수 있다. DNS 설정에서 A 레코드를 집 네트워크의 공인 IP로 설정하면 된다. 5\. CNAME을 활용한 IP 변경 대응 고정 IP가 없는 경우, CNAME 레코드를 활용하면 IP 변경 시에도 손쉽게 대응할 수 있다. 예를 들어, api.example.com을 myserver.example.com(고정 도메인)으로 연결하면, 실제 IP 변경 시 myserver.example.com의 A 레코드만 수정하면 된다. 6\. HTTPS 적용 (Let’s Encrypt 활용) Let’s Encrypt를 사용하면 무료로 SSL 인증서를 발급받을 수 있다. Certbot을 이용해 자동 갱신을 설정하면, 별도 비용 없이 안전한 HTTPS 환경을 유지할 수 있다. 기본적인 SSL 설정 예제: 결론 여기서 모든 세부 설정을 다루진 않았지만, 비용 절감을 위해 로컬 PC를 서버로 활용하는 방법이 충분히 가능함을 보여주고 싶었다. AWS는 확장성과 안정성이 뛰어나지만, 초기 비용 부담이 크다. 반면 로컬 PC를 활용하면 비용을 아끼면서도 여러 개의 서비스를 직접 운영할 수 있다. 이 방식은 개인 프로젝트나 소규모 서비스 운영에 적합하다. 처음에는 이렇게 운영하다가, 트래픽이 증가하고 수익이 보장되면 AWS 같은 클라우드 환경으로 확장하는 것이 좋은 전략인 것 같다.
수강신청 사이트 Tupick 개발
만든 이유 수강신청이 가능한 웹사이트 Tupick을 개발하게 되었다. 개발 기간도 짧을 것 같고, 다양하게 쓰일 것 같아서 가볍게 제작했다. 일정 개발 시작부터 마무리까지 총 1주일이 소요되었다. 서비스 규모에 비해 빠르게 개발을 완료할 수 있었던 가장 큰 이유는 AI의 도움 덕분이다. CURSOR IDE의 Composer 기능을 활용해 코딩의 방향을 지시하는 방식으로 진행하니 개발 시간이 크게 단축되었다. 이 과정에서 CURSOR IDE API 사용 비용으로 약 36달러(기본 구독료 20달러 + 추가 비용 16달러)를 지출했지만, 절약된 시간을 고려하면 충분히 가치 있는 투자였다. 기술스택 SEO가 중요한 서비스가 아니므로 React를 프론트엔드 프레임워크로 선택했다. 개발 생산성을 높이기 위해 TypeScript, TailwindCSS, Vite를 함께 활용했다. 백엔드는 가볍고 성능이 뛰어난 Go와 MongoDB를 조합해 구축했다. CI/CD는 GitHub Actions를 이용해 Docker 이미지를 빌드하고, 개인 Harbor 도커 레지스트리에 업로드한 후, 이를 집에 설치한 로컬 서버에서 실행하는 방식으로 구성했다. AWS를 사용하면 더 편리하겠지만, 비용 부담이 커서 기존 게임용 PC를 초기화한 후 Proxmox 위에 Ubuntu를 설치하고, UPS를 연결해 운영하고 있다. 서비스 소개 아래는 예시로 만든 수강신청 이벤트 화면이다. 각 프로그램마다 정해진 인원을 할당할 수 있으며, 링크를 공유해 참가자들의 신청을 받을 수 있다. 또한, 동시 신청으로 인한 충돌을 방지하는 기능이 포함되어 있어 안정적인 운영이 가능하다. 주최자는 신청 시 받을 데이터 항목을 자유롭게 설정할 수 있어, 다양한 형태의 이벤트에 맞춰 활용할 수 있다. 아래 예시에는 이름만 입력받도록 설정되어 있지만, 이메일, 전화번호 등 추가 정보를 받을 수도 있다. 신청자 목록은 웹 페이지에서 실시간으로 확인할 수 있으며, 엑셀 파일로 다운로드하여 별도로 관리하는 것도 가능하다. 또한, 복제 기능을 활용하면 기존 템플릿을 그대로 복사해 새로운 수강신청을 받을 수 있다. 특히 매주 반복되는 수강신청을 운영해야 하는 경우 매우 유용한 기능이다. 스트레스 테스트 진행 수강신청 사이트는 동시에 많은 사용자가 몰릴 경우 성능 저하가 발생할 수 있다. 이를 확인하기 위해 k6을 이용한 HTTP 스트레스 테스트를 진행했다. 테스트 시나리오: 동시 접속 인원을 100명 → 500명 → 1000명 순으로 증가 결과: 웹사이트가 약간 느려지는 현상은 있었지만, 별다른 오류 없이 정상적으로 작동했다. 추가적인 트래픽 증가에도 안정적인 서비스를 유지할 수 있도록 지속적으로 최적화를 진행할 예정이다. 마무리하며 예전에는 하나의 서비스를 개발하는 데 시간이 훨씬 더 오래 걸렸고, 반복적인 작업에 쉽게 지치는 경우가 많았다. 하지만 AI 기술의 발전 덕분에 이제는 그런 작업들이 훨씬 수월해졌다. 나는 인디 해커(Indie Hacker)로서 여러 서비스를 운영하고 싶은 목표가 있다. 과거에는 높은 서버 비용과 긴 개발 기간이 걸림돌이 되어 쉽게 도전하지 못했지만, 인프라가 준비되고 개발 생산성이 향상되면서 하나씩 장애물이 사라지고 있다. 경제적으로 독립하는 길이 멀어 보였지만, 이렇게 꾸준히 서비스를 만들고 운영하다 보면 그 목표도 점점 가까워질 것이라는 확신이 든다.
블로그 디로그 서비스 개발 리뷰
블로그 개발을 시작한 이유 기존에 GitHub Pages 기반으로 운영하던 개발 블로그가 있었지만, 직접 블로그를 만들어보기로 했다. GitHub에 코드를 푸시하는 방식으로 글을 업로드하는 것이 번거로웠기 때문이다. 직접 개발하면 블로그를 관리하면서 겪었던 불편함을 효과적으로 개선할 수 있을 것이라 생각했다. 예를 들어, 방문자의 언어에 따라 블로그 콘텐츠를 다르게 제공하는 기능을 구현할 수 있다. 영어권 사용자에게는 영어로, 한국 사용자에게는 한글로 자동 번역된 콘텐츠를 보여주는 방식이다. 이전에는 번역 API의 품질이 만족스럽지 않아 어려움이 있었지만, ChatGPT의 발전으로 이제는 높은 품질의 번역이 가능해졌다. 또한, 직접 개발하고 운영하는 서비스의 즐거움도 큰 이유 중 하나다. 소프트웨어는 완성된 형태로 머무르지 않고, 계속해서 개선되는 과정 속에 있다. 직접 개발해두면 사용하면서 느낀 불편함을 즉시 해결하고, 필요한 기능을 자유롭게 추가하며 발전시킬 수 있다. 이런 점에서 블로그를 직접 만들고 운영하기로 결정했다. 개발 일정 개발 시작부터 마무리까지 총 2주가 소요되었다. 서비스 규모에 비해 빠르게 개발을 완료할 수 있었던 가장 큰 이유는 AI의 도움이다. CURSOR IDE의 Composer 기능을 활용하여 코딩의 방향을 지시하는 방식으로 진행하니 개발 시간이 크게 단축되었다. CURSOR IDE API 사용 비용으로 약 40달러(기본 구독료 20달러 + 추가 비용 20달러)를 지출했지만, 절약된 시간을 고려하면 충분히 가치 있는 투자였다. 기술 스택 SEO가 중요한 블로그 서비스인 만큼, SSR이 강력하게 지원되는 Next.js를 프론트엔드 프레임워크로 선택했다. 또한, TypeScript와 TailwindCSS를 함께 적용해 개발 생산성을 극대화했다. 백엔드는 가볍고 성능이 뛰어난 Go와 MongoDB를 조합해 구축했으며, 향후 Redis를 도입해 더욱 효율적으로 개선할 계획이다. CI/CD는 GitHub Actions를 활용해 Docker 이미지를 빌드하고, 개인 Harbor 도커 레지스트리에 업로드한 뒤, 이를 집에 설치한 로컬 서버에서 실행하도록 구성했다. AWS를 사용하면 더 편리하겠지만, 비용 부담이 커서 기존 게임용 PC를 초기화한 후 Proxmox 위에 Ubuntu를 설치하고, UPS를 연결해 운영하고 있다. 이미지 리소스는 AWS CloudFront와 S3를 연동해 서빙하고 있다. 사용한 주요 라이브러리 TipTap (오픈소스 에디터 라이브러리)\ 일반적인 마크다운 에디터는 왼쪽에서 마크다운을 입력하고, 오른쪽에서 미리보기를 제공하는 방식이다. 하지만 TipTap을 사용하면 노션(Notion)처럼 스타일을 바로 적용하며 편집할 수 있어 더욱 직관적인 사용자 경험을 제공한다. next-i18next (다국어 지원 라이브러리)\ Next.js에서 다국어 기능을 쉽게 구현할 수 있도록 도와주는 대표적인 라이브러리이다. 현재 프로젝트에서는 구글 스프레드시트에서 번역 데이터를 관리하여 사용하고 있다. 서비스 기능 소개 스타일이 적용된 편집 기능 블로그 서비스의 핵심은 콘텐츠이므로, 콘텐츠 작성 및 수정 기능이 직관적이고 사용하기 편리해야 한다. 개발자뿐만 아니라 일반 사용자도 쉽게 사용할 수 있도록 TipTap 라이브러리를 활용해 스타일이 적용된 에디터를 지원한다. 또한, 단축키 기능을 추가하여 예를 들어 Confluence처럼 E 키를 누르면 편집 페이지로 이동하는 등의 편리한 기능을 제공해 사용자 경험을 향상시켰다. 자동 번역 수준 하나의 글을 여러 언어로 자동 번역할 수 있다면, 작성자는 더 쉽게 다양한 국가의 사람들과 소통할 수 있다. 이를 통해 글 작성자의 편의성을 높이는 것이 목표다. 각 게시글 상단에는 지원하는 언어 목록이 표시되며, 사용자가 원하는 언어를 선택하면 미리 번역된 콘텐츠가 제공된다. 사용자 이름 기반 주소 설정 유튜브처럼 <<https://blog.danver.io/@0921pig>> 형태로 각 블로그에 사용자 이름(username)으로 접근할 수 있도록 설정했다. 이를 통해 더 직관적이고 이해하기 쉬운 URL 구조를 제공하려고 노력했다. 향후에는 사용자가 직접 커스텀 도메인을 설정할 수 있는 기능도 지원할 계획이다. 마무리하며 2주라는 짧은 시간 동안 혼자 개발한 프로젝트인 만큼 아직 부족한 점이 많다. 직접 사용하면서 발견한 개선 포인트를 정리하고, 꾸준히 보완해 나갈 계획이다. 다만, 관리해야 할 프로젝트가 많아지면서 놓치는 부분이 생길까 걱정도 된다. 이를 보완하기 위해 ClickUp을 활용해 프로젝트 일정을 체계적으로 관리해보려 한다. 효율적으로 진행하면서, 블로그를 더욱 발전시켜 나가는 과정 자체를 즐기고 싶다. 🚀
Vercel 팀 환경변수와 프로젝트 환경변수
팀 레벨의 환경변수? 개발을 하다보면 보안상의 이유로 코드에 저장할 수 없는 특별한 값들이 있습니다. 비밀번호나 Access Token 같은 경우가 이에 해당합니다. 그래서 환경변수로 저장해서 배포할 때 그 값을 불러올 수 있는데, 프로젝트 레벨의 환경변수만 있는 줄 알고 있었는데, 팀 레벨의 환경변수도 있었습니다. 팀 레벨의 환경변수에 저장하면 팀에 포함된 모든 프로젝트에서 값에 접근할 수 있는데, 관리에 유용했습니다. 기본적으로 환경변수를 사용하려면 아래처럼 프로젝트 -> Settings -> Environment Variables에 들어가면 프로젝트에서 사용할 환경변수를 저장할 수 있습니다. 문제는 이 값은 하나의 프로젝트에서만 사용될 수 있습니다. 다른 프로젝트에서도 이 값이 필요하면 똑같이 만들어줘야 합니다. 저는 Github package에 접근할 수 있는 token을 이곳에 저장했는데 프로젝트 개수가 5개가 되니 같은 환경변수를 5번이나 만들어야 했습니다. 더 큰 문제는 추후에 토큰이 expire되어서 수정해야 하는 경우가 다가오면 프로젝트마다 저장된 각각의 환경변수를 모두 바꿔야하는 것이 걱정이었습니다. 공식 문서도 공유합니다. 더 자세한 내용은 이곳에서 살펴볼 수 있습니다.
create-next-app with template
들어가며 웹 개발을 할 때 어떤 기술들로 구성하는지는 매번 달라지는 것이 보통이지만, 그럼에도 불구하고 개발자마다 항상 사용하는 설정들이 있습니다. 저를 예를 들면 다국어는 i18n을 사용하고, API 캐싱은 React Query를 사용합니다. 프로젝트를 처음 설정할 때 생각보다 시간이 많이 걸리기 마련인데, 이런 설정들을 미리 템플릿화해두면 시간도 아끼고 초기 시행착오를 줄일 수 있습니다. 어떻게 사용하나요? Next.js를 사용하시는 개발자라면 create-next-app 명령어를 아실겁니다. 공식 문서에서 제공하는 기능이니까요. 이 명령어를 사용하면 프로젝트 이름, TypeScript 사용 여부 등을 쉽게 설정할 수 있습니다. 그리고 문서를 자세히 살펴보면 오늘 말씀드릴 example 옵션을 찾아볼 수 있습니다. repo url을 옵션으로 함께 써주면 그대로 구성을 해줍니다. 미리 자주 사용하는 설정들을 Github에 push 해두고, repo의 url을 함께 입력하면 시간을 절약할 수 있습니다. 사용 예시 간단한 기능이지만, 저처럼 작은 프로젝트를 계속 만드는 개발자라면 특히 유용합니다. Next.js도 이곳에서 여러개의 템플릿을 제공하고 있습니다. 아래와 같은 형태로 템플릿을 생성할 수 있습니다. 형태 예시 더 나아가서 이대로도 충분합니다만, 혹시나 여러개의 템플릿을 가지고 계시다면 좋은 방법이 있습니다. 공식 Repo를 보면 하나의 Repo 안에 여러개의 템플릿이 있습니다. Github에 template repo를 생성하시고,폴더마다 자신만의 템플릿들을 추가해보세요. 예를 들면, SPA (Single Page Application), Mobile App 등 많은 템플릿을 만들어둘 수 있겠네요. 이때는 --example-path \[path-to-example\] 옵션을 추가해주시면 됩니다. 형태 예시 실행 결과
MongoDB serverelss로 비용 절약하기
MongoDB Serverless란? MongoDB 개발사는 공식 홈페이지에서 MongoDB 클라우드 서비스를 제공하고 있습니다. 이곳에 사용료만 지불하면 개발사가 관리해주는 DB를 사용할 수 있습니다. 다양한 모델이 있는데 그중에 Serverless 모델에 대해 얘기하려 합니다. 이는 사용한 트래픽 만큼 금액을 지불하는 서비스입니다. 반대로 말하면 트래픽이 없으면 금액을 지불하지 않는다는 이야기입니다. 아래는 요금표입니다. \언제 사용하면 좋을까요? 초기 프로젝트는 대부분 트래픽이 거의 없습니다. 트래픽이 거의 없는 이 서비스를 위해 DB를 계속 켜두는 것은 솔직히 금전적으로 부담스럽습니다. 수익도 없는데 한달에 2만원씩 꼬박꼬박 청구되는 금액을 보다보면 서비스를 내려야하나 고민될텐데, 서버리스 모델을 사용하게 되면 이런 고민을 하지 않아도 됩니다. 초기 서비스는 저장된 데이터도 거의 없고, 읽기 쓰기도 거의 없습니다. 위의 요금표를 보시면 이런 경우에 한달에 1달러를 낼 일도 없습니다. 저 역시 서비스를 시작한 9월부터 11월까지 한푼도 내지 않고 있습니다. \단점이 있나요? 네, 있습니다. 서버리스 모델의 특성상 사용하지 않으면 서버가 꺼지기 때문에, 트래픽이 계속 없다가 접속을 시도하면 처음에만 1\~2초 정도의 딜레이가 있습니다. 딜레이도 길지 않아서 저는 불편함을 느끼지 못했습니다. 또 다른 단점은 서비스의 규모가 커지면 항상 켜져 있는 전용 서버 대비 요금이 비싸질 수 있습니다. 제가 서버리스 모델을 추천하는 이유는 트래픽이 거의 없는 초기에 금액을 아낄 수 있기 때문입니다. 서비스의 규모가 커지면 금액을 비교해보시고 전용서버로 옮기시는 것을 고려해보시기 바랍니다.
Proxmox 사용 후기
Proxmox를 처음 접하다 예전에 쓰던 데스크탑이 창고에 방치돼 있었는데, 최근 AI 공부를 하다 보니 서버가 하나 필요해졌다. 그래서 이 데스크탑을 서버로 활용해보기로 마음먹었다. 하지만 단순히 우분투 하나만 설치해서 쓰기엔 뭔가 아쉬웠다. 특히 한국에서는 은행 같은 서비스를 이용할 때 윈도우가 필요한 순간이 종종 있다. “어떻게 하면 둘 다 만족할 수 있을까?” 고민하다가 Proxmox라는 가상화 플랫폼을 알게 됐다. 한 후기에서 이런 말이 인상 깊었다: “단 하나의 OS만 설치해서 쓰더라도 Proxmox는 좋은 선택이다.” 이 말에 이끌려, 큰 기대 없이 한 번 써보기로 했다. Proxmox 설치 방법 설치 과정은 놀랄 만큼 간단했다. Proxmox 설치 파일 다운로드: Proxmox 공식 웹사이트에서 ISO 파일을 다운로드. USB 부팅 디스크 만들기: 파일을 USB에 담고 데스크탑을 부팅. 간단한 설치 과정 진행: 윈도우를 설치하는 것처럼 직관적인 과정을 따라가면 끝! 설치가 완료된 후, Proxmox의 관리자 페이지에 접속하니 깔끔하고 직관적인 웹 기반 인터페이스가 나타났다. 초보자인 나도 금방 적응할 수 있을 만큼 잘 설계돼 있었다. Proxmox가 주는 장점 Proxmox를 직접 사용해보니 다음과 같은 점들이 정말 좋았다: 여러 개의 OS를 원하는 사양으로 구성 가능 한 대의 서버에서 우분투, 윈도우 등 다양한 운영체제를 동시에 실행할 수 있었다. 각 OS마다 원하는 사양(CPU, RAM 등)을 자유롭게 설정할 수 있어 유연했다. 쉽게 삭제하고 다시 설치 가능 실수로 잘못 설정했더라도 VM(가상머신)을 손쉽게 삭제하고 다시 만들 수 있었다. 부담이 적어서 여러 실험을 해볼 수 있었다. 컨테이너 지원 (아직 시도 전) Proxmox는 LXC 컨테이너를 지원해서 더 가볍고 효율적인 환경도 구축할 수 있다. 컨테이너 기술을 활용하면 서버 자원을 훨씬 효율적으로 사용할 수 있을 것 같았다. 활용 계획 Proxmox를 통해 직접 서버를 구성하니, AWS와 같은 클라우드 요금을 절감할 수 있을 것 같았다. 초기 투자만으로도 다양한 환경을 실험할 수 있어 비용 면에서 큰 이점이 있었다. 앞으로 AI 모델 테스트, 웹 개발 환경 구축, 그리고 미디어 서버로 활용할 계획이다. 마무리 Proxmox는 초보자도 부담 없이 접근할 수 있는 훌륭한 가상화 플랫폼이었다. 단순히 OS를 하나 설치해 쓰는 것보다 훨씬 유연하고, 서버를 효율적으로 활용할 수 있게 해준다. 창고에서 잠자고 있는 PC가 있다면, Proxmox로 새로운 생명을 불어넣어 보길 추천한다. 한번 사용해보면 왜 사람들이 Proxmox를 추천하는지 알게 될 것이다.
Cafe24 쇼핑몰 코드를 Git과 FTP로 관리하는 방법
들어가며 개발 인력이 부족한 회사에서 Cafe24로 쇼핑몰을 운영하는 것은 생산성 측면에서 정말 좋은 방법이다. 독립형 쇼핑몰처럼 입맛대로 운영하는 것이 가끔 어려울 때도 있지만, 최소의 비용으로 빠르고 부족함 없이 시작할 수 있다. 그러나 개발자의 입장에서 Cafe24의 코드는 수정할때마다 항상 불안함을 느꼈다. 일반적인 개발에서 보통 수정한 코드에 문제가 있으면 쉽게 되돌리면서 개발을 진행할 수 있다. 그러나 Cafe24는 FTP에 파일을 직접 업로드하기 때문에 Git으로 소스 관리하는 것이 생각만큼 쉽지는 않다. 이를 FTP와 Git으로 극복한 내용을 담아보았다. 어떻게 해결했을까 FTP의 두가지 방법 FTP에는 크게 2가지 방법이 있다. 첫번째는 서버에 직접 접속해서 코드를 변경하는 방법. 두번째는 로컬에 있는 코드를 수정하고 서버와 동기화 하는 방법이다. 첫번째 방법을 사용할때는 Git으로 소스를 관리하는 방법이 어렵다. 그러나 두번째 동기화 방법에서는 로컬에 있는 코드를 Git으로 쉽게 관리할 수 있다. 쉽게 사용할 수 있는 도구로 Visual Studio Code에는 SFTP 플러그인이 있고, IntelliJ Ultimate에는 기본적으로 설치되어 있는 FTP 기능을 사용하면 된다. 이 글에서는 intelliJ를 기준으로 설명하겠다. 작업 먼저 Cafe24 쇼핑몰에 FTP를 사용하기 위한 권한을 신청해야 한다. 카페24 관리자 페이지에서 \[디자인\] -> \[디자인 FTP\] 에서 신청하고, 접속 정보를 받을 수있다. IntelliJ에서 FTP로 연결하기 메뉴 Tools -> Deployment -> Configuration에 들어가서 연결 정보를 입력한다. 좌측 상단 + 버튼을 눌러 SFTP를 선택합니다. 서버의 닉네임을 지정합니다. SSH Configuration 우측에 ... 버튼을 누릅니다. Cafe24에서 받은 FTP 접속 정보를 입력합니다. Mappings 탭을 눌러서 Deployment path에 / 를 입력합니다. 이 경로에 FTP 파일들이 다운받아지고, 동기화가 이뤄집니다. 이제 connection 탭에서 Test Connection을 눌러봅니다. 정상적으로 연결이 되면 아래와 같이 성공 메시지가 뜹니다. 가장 먼저 해야 하는 것은 Cafe24에 있는 쇼핑몰 코드를 가져오는 것입니다. \[Tools\] -> Deployment -> Download from \[서버 닉네임\]을 눌러 코드를 다운받습니다. 이제 코드가 다운로드되고 볼 수 있습니다. 이번에는 로컬에서 파일이 수정되면 서버에도 자동으로 업로드되도록 자동 동기화 기능을 설정합니다. \[Tools\] -> \[Deployment\] -> \[Automatic Upload\]를 눌러서 해당 옵션을 활성화 합니다. 기타 이렇게 설정해두었으면 Git으로 코드를 관리할 수 있을 것 입니다. 혹시나 누군가가 임의로 코드를 수정해서 문제가 발생하면 Git으로 코드를 되돌리고 저장을 누르면 서비스를 쉽게 복구할 수 있습니다.
CloudWatch + Lambda + S3로 로그 수집하기
들어가며 서버리스로 웹 서비스를 구현하고 있다. 서버리스는 사용한만큼 돈을 내는 서비스이기 때문에 사용자가 얼마나 API를 사용했는지 측정하고 싶었다. 가장 쉬운 방법은 API를 호출할 때마다 DB에 기록하는 방법이지만 이는 비효율적이다. 그래서 리서치를 하다가 CloudWatch에 쌓인 로그를 일정 시간마다 긁어서 처리한 후에, 처리 된 정보만 DB에 저장하기로 했다. 서버리스에서 API는 API Gateway + Lambda를 통해 실행된다. 그리고 API 호출 중에 생성된 모든 로그는 특별한 조치를 하지 않아도 자동으로 Cloudwatch에 기록된다. 이를 1시간마다 S3로 이동하도록 설정했다. 그리고 이동이 끝나면 S3에서는 1시간치의 로그를 읽어서 API 호출 횟수를 정리해서 DB에 저장하면 끝이다. 이렇게 구성한 이유는 아래와 같다. CloudWatch의 로그를 S3로 옮긴 이유는 S3의 보관 비용이 CloudWatch보다 저렴하기 때문이다. 1시간마다 유저 사용량을 계산해서 DB에 저장하는 이유는 별거 없다. 내 서비스 대시보드에서 유저마다 사용량을 보여줄 때 최소 단위가 1시간이기 때문이다. 진행방법 CloudWatch에 저장된 로그를 S3로 옮길때는 aws-sdk에서 지원하는 CloudWatch.createExportTask를 사용했다. cron 스케줄 표현식을 이용해서 1시간마다 Lambda를 실행해서 간단하게 이동시켰다. 로그는 분석과 관리를 쉽게 하기 위해 JSON 형태로 저장했다. lambda-log 라이브러리를 이용해서 JSON으로 저장했다. 그 이후는 간단하다. 로그 파일을 원하는대로 분석해서 필요한 형태로 가공해서 저장하면 끝이다. 하고나면 별거 없지만, AWS의 권한 문제, Lambda 로그가 어떤 형태로 CloudWatch에 저장되는지를 알아보는데 시간을 많이 사용했다.
개인 사이트에 Disqus 댓글 추가하기
들어가며 블로그에 댓글이 있으면 좋겠다는 생각이 들었다. 내가 쓴 글에 사람들의 반응을 확인할 수 있는 것은 블로그를 지속하게 하는 동기부여 역할도 하니까 말이다. 직접 구현할까 하다가, 지금은 외부 서비스인 Disqus를 사용해보기로 했다. 하지만 아마 곧 걷어내고 직접 만든 댓글을 사용하게 될 것 같다. 기능 자체는 충분히 훌륭하지만, 어느 순간이 되면 광고가 달리기 때문이다. 그럼에도 한번 설치해보기로 생각하는 이유는 머리로 아는 것과 직접 사용해봤을 때 알게되는 것이 다르기 때문이다. 이번 기회를 통해 경험해보고, 추후에는 나만의 댓글 시스템을 만들어야겠다. 진행 과정 Disqus 홈페이지에 가입해야 한다. 이곳에서 내 사이트의 댓글들을 관리할 수 있다. Disqus 내에서 site를 만든다. Website Name은 다른 site와 구분지을 수 있는 값이다. 외부에 노출되는 주소는 아니므로 대충 지어도 상관은 없다. 결제 플랜을 선택하라고 나오는데, 나는 무료로 사용할 것이기 때문에 하단에 있는 Basic을 선택한다. Ad-supported란, 광고가 노출된다는 뜻이다. 사실 당연하다. 서비스를 무료로 운영할 수는 없기 때문이다. 다음은 플랫폼을 선택한다. 내 블로그는 Next.js를 사용해서 만들어졌으니 이 목록에는 없었다. 그래서 맨 하단에 I don't see my platform listed, install manually with Universal Code를 선택했다. 그 다음 페이지에서 아래처럼 설치 방법이 나와있기는 하지만, 이를 사용하지는 않을 것이다. Next.js는 React 기반으로 만들어졌기 때문에 React 라이브러리를 사용할 수 있다. React에서 사용할 수 있는 disqus-react 라이브러리를 설치한다. 설치 방법은 readme 파일에 친절하게 나와있다. 순서대로 따라만 하면 되기에 어렵지 않을 것이다. 설치가 끝나고, 블로그를 보니 아래처럼 댓글창이 생겼다. \겪은 문제 설치 방법이 쉽다고는 했지만, 순탄하지는 않았다. Super expression must either be null or a function 에러 메시지는 Next.js 13을 사용할 때 겪을 수 있는 문제다. 댓글은 사용자의 클릭과 같은 Action이 이루어지는 곳이므로 'use client'를 상단에 작성해야 한다. (Next.js 13 규칙) 블로그 하단에 댓글창이 나타나지 않는 문제를 겪었다. 연결이 끝났을거라 생각했는데 댓글이 나올 자리에 밑줄만 하나 있고, 댓글창이 나타나지 않았다. 콘솔 log에 Refused to load the script 'https://danver-blog.disqus.com/embed.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'unsafe-inline' giscus.app analytics.umami.is". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. 라는 메시지가 있었다. CSP 문제였기에, 아래 이미지처럼 필요한 값들을 헤더에 추가해서 해결했다. 맺으며 Disqus 댓글 설치가 잘 끝났다. 당분간 이걸로 버티다가, 시간이 될 때 자체 댓글 시스템을 만들어보고자 한다. 바라는 것은 나 혼자만 사용하지 않고, 다른 사용자에게도 팔아보고 싶은데 과금모델이 고민이다. 어떻게 요금 방식을 설정해야 적당한걸까. 사례를 찾아보고, 스스로도 생각해봐야겠다.
검색엔진에 한글 웹사이트 등록하기
검색엔진에 웹사이트를 등록해야 할까? 저는 이 개발 블로그를 운영하고 있습니다. 당연히 제가 쓴 글을 많은 사람들이 읽어주기를 원합니다. 많은 사람들이 이 블로그를 읽을수록 더 많은 광고 수익이 제게 오기 때문입니다. 하지만 제가 글을 많이 써도 사람들은 제가 글을 썼다는 것을 알지 못합니다. 알지 못하는 곳에 갈 수 있을리가 없지요. 그래서 검색엔진에 제 사이트를 등록해서 검색했을 때 제 블로그가 노출되도록 해야합니다. 그러려면 검색엔진에 제 사이트를 등록해야 합니다. 등록을 하면, 제가 새롭게 글을 쓸 때마다 검색엔진이 내용을 긁어서 저장하고 있다가, 누군가 관련 내용을 검색했을 때 제 페이지를 노출시킬겁니다. 귀찮은데요? 만약 검색엔진마다 등록하는 것이 귀찮다면 하지 않으셔도 됩니다. 다른 방법도 있기 때문이죠. 바로 광고를 하는 겁니다. 구글 애즈와 같은 광고사에 사이트를 등록하고, 사람들에게 사이트 정보가 노출될때마다 돈을 지불하셔도 됩니다. 말을 조금 다시 생각해보면 검색엔진에 사이트를 등록하는 것은 무료로 내 타겟들에게 마케팅을 할 수 있게 해주는 겁니다. 검색엔진이 무료로 내 블로그를 홍보해주는 것과 내가 내 돈을 내고 광고를 하는 것. 무엇을 선택하시겠습니까? 저는 검색엔진에 사이트를 등록하는 방법을 택하겠습니다. 어느 검색엔진에 등록해야할까요? 이 블로그에 있는 현재까지의 글은 모두 한글입니다. 그래서 국내 사용자들이 사용하는 검색엔진 통계를 찾아봤습니다. 네이버, 구글, 다음, 마이크로소프트가 상위 97%를 차지하고 있습니다. 그러니 이 4가지 검색엔진에 등록하면 될 것 같습니다. \구글 구글에 사이트를 등록하려면, Google Search Console을 통해 등록할 수 있습니다. 사이트를 등록하신 후에 왼쪽 메뉴 Sitemaps에 들어가셔서 현재 페이지의 사이트맵을 등록하시면 됩니다. 사이트맵이란 해당 사이트에 어떤 페이지들이 있는지 모두 알려주는 지도입니다. 제 사이트의 사이트맵은 이곳에서 보실 수 있습니다. 다만 꼭 알아두셔야 하는 것은 사이트맵은 하루에 1번정도 구글이 가져가면서 새로운 페이지가 추가되었는지 확인하지만, 바로바로 업데이트 되는 것이 아닙니다. 오늘 등록한 사이트는 검색엔진 결과에 노출될때까지 최대 2주까지 시간이 소요될 수 있습니다. 저는 새로운 글을 쓰면 일주일 정도 후에 구글 검색 결과에 노출되는 것을 확인했습니다. 나중에 사이트 트래픽이 많아지면 빠르게 긁어갈수도 있지만, 작은 규모의 웹사이트는 일반적으로 시간이 걸린다고 보시면 됩니다. \네이버 네이버에 사이트를 등록하려면 네이버 서치어드바이저에서 등록하실 수 있습니다. 로그인 후에 우측 상단에 웹마스터도구를 들어가시면 사이트를 등록할 수 있습니다. 이후 왼쪽 메뉴 중에 요청 -> 사이트맵 제출을 통해 사이트맵을 제출할 수 있습니다. 네이버는 아직 저 역시 등록요청한지 얼마 되지 않아서 실제로는 어느정도 걸리는지 알 수가 없네요. 구글과 비슷할거라 생각합니다. \다음 다음에 사이트를 등록하려면 Daum 검색등록 에서 가능합니다. 이곳은 로그인하지 않아도 등록할 수 있는 것이 신기했습니다. 좋았던 점은 검색엔진 등록이 금방 끝납니다. 1\~2일 내에 바로 검색엔진에 노출되었습니다. \MS Bing 마이크로소프트의 검색엔진 Bing은 Bing 웹마스터 도구을 통해 사이트를 등록할 수 있습니다. 신기했던 점은 Google Search Console에 등록했던 설정을 그대로 가지고 올 수 있었습니다. 도메인 소유권 인증과 같은 절차를 덕분에 패스할 수 있었습니다. 이후에 왼쪽 메뉴에서 사이트맵을 눌러 바로 등록했습니다. \맺으며 이렇게 마무리되었습니다. 이제 남은 것은 그저 기다리는 것입니다. 지금은 블로그의 컨텐츠가 모두 한글이라 국내 사람들에게 초첨을 맞췄지만, 앞으로 영어로도 글을 작성한다면 해외 유저들이 사용하는 검색엔진에도 등록하게 될 것 같습니다. 그때가 빨리 왔으면 좋겠네요.
메타태그를 쉽게 볼 수 있는 Metatags.io
메타태그란 메타태그란 해당 웹페이지에 대한 정보를 담고 있는 태그이다. 좀 더 정확히 이야기하면, 이 페이지의 제목은 무엇인지, 썸네일은 무엇인지 등을 개발자가 헤더에 작성해두면 검색엔진이나 외부 서비스에서 참고하는 용도이다. 예를 들어 아래 처럼 슬랙에 이미지를 공유했을 때 사이트의 이름, 제목, 내용, 썸네일 등이 나오고 있는데 모두 메타태그에 저장된 내용을 가지고 오는 것이다. 메타태그 내용은 웹페이지의 헤더에 포함되어 있다. 예를 들어, og:title, og:description, og:image 등이 위 슬랙 메시지에서 컨텐츠를 구성하고 있음을 알 수 있다. 나 역시 이 부분을 신경쓰지 못해서 블로그 글을 공유했을 때 나타나는 이미지가 TailwindBlog 라고 나타나고 있다. \메타태그 볼 때 흔히 겪는 어려움 메타태그가 잘 구성되어있는지 볼 때 쉽게 사용할 수 있는 방법은 텔레그램이나, 슬랙, 카카오톡 등에 한번 보내보는 것이다. 하지만 이 방법은 문제가 하나 있다. 많은 서비스에서 이 메타태그는 효율성을 위해 한번 저장해두면 상당기간 캐싱해둔다. 개발 중에 잘 적용되어있는지 수정하면서 보려고 하면, 언제나 수정 전에 값이 한동안 계속 나타난다. 나 역시 이런 문제로 고민하다가 직장동료의 추천으로 metatags.io 라는 사이트를 알게 되었다. 유용하다는 생각이 들어서 추천한다. 사이트 소개 metatags.io 사이트의 사용법은 단순하다. 접속하게되면 검색창이 있는데, 메타태그를 확인하고 싶은 사이트의 주소를 넣고 버튼을 누르면 끝이다. 그러면 잠시 후에 유명한 서비스에서 어떻게 메타태그가 나오는지 확인할 수 있다. 구글, 트위터, 페이스북, 링크드인, 핀터레스트, 슬랙에서 어떻게 보여지는지 쉽게 볼 수 있다. 맺으며 이미 알고 있다면 별거 아닌 내용이지만, 모르는 사람에게는 참 유용한 기능이다. 무엇보다 개발자가 아니더라도 쉽게 사용할 수 있어서 많은 사람들이 잘 사용했으면 좋겠다.
서버리스 웹사이트가 Cold start에 빠지지 않도록 warm-up 하기
상황 서버 시간을 조회하는 댄버 서버시간 프로젝트를 배포하다가 몇분간 접속하지 않다가 접속하면 약 4초 정도 지연되었다가 화면이 나타나는 Cold start 현상을 보게되었습니다. Vercel을 통한 서버리스 배포는 비용 부담이 적어서 자주 사용해야 하는데 유저에게 불편을 주는 긴 로딩은 피하고 싶었습니다. 해결 방법을 검토하다가 Tobin님의 Speeding up AWS Amplify NextJS First Render + Cold Start: An Unexpected Result 글을 보고 해결할 수 있었습니다. 콜드 스타트를 해결하는 서버리스 웜업 방법을 필요로 하는 개발자가 많이 있을 것 같아 과정을 공유합니다. 적용 방법 warm-up은 한마디로 요약하면 사이트가 잠들기 전에 계속 불러서 깨우는 것입니다. 약 5분 정도 아무도 접속하지 않는 웹 사이트는 깊이 잠드는 Cold 상태가 됩니다. 그러니 잠들기 전에 한번 더 불러서 깨우면 다시 또 5분간 깨어있게 됩니다. 이를 반복해서 항상 깨어있는 서버리스 웹사이트를 만들 수 있습니다. AWS Route53 콘솔에 접속해서 왼쪽 메뉴에서 Health checks에 들어가면 사이트가 살아있는지 주기적으로 체크하는 Health check 를 생성할 수 있습니다. Create health check를 눌러서 아래와 같은 옵션으로 생성해주세요. 그럼 끝입니다. 금액은 Health check 한개당 약 1달러/월 라고 합니다. 자세한 정보는 참고 블로그 글을 통해 확인하실 수 있습니다. 이 글이 도움이 되기를 바랍니다. 참고 자료 https://medium.com/aws-tip/speeding-up-aws-amplify-nextjs-first-render-cold-start-and-images-an-unexpected-result-36a416d69615
일회용 이메일 서비스 개발 및 리뷰
프로젝트 소개 일회용 이메일이란, 내 이메일 주소를 알려주고 싶지 않을 때 사용합니다. 또, 신뢰할 수 없는 사이트에 회원가입 할 때 스팸메일로부터 내 이메일을 보호할때도 사용할 수 있습니다. 저는 개발 테스트를 할 때 이런 서비스를 알게되었습니다. 테스트를 위해 수많은 이메일이 필요했는데, 한번 사용하고 버릴 이메일이라서 번거롭게 Gmail을 여러개 만드는 것은 부담스러웠습니다. 이 서비스를 이용하면 쉽게 이메일을 통해 회원가입과 이메일 인증을 하고, 또 필요없어지면 과감히 새로운 이메일로 교체할 수 있었습니다. 시작 이유 개인 프로젝트로 일회용 이메일 서비스를 선택한건 유지보수의 부담이 적기 때문입니다. 이메일의 기술구조는 수십년간 변하지 않았습니다. 그리고 앞으로도 큰 변화가 없을거라 생각합니다. 한번 만들어두기만 하면, 유지보수에 대한 부담 없이 꾸준히 수익화할 수 있기 때문에 개인 프로젝트 주제로 적절하다고 판단했습니다. 제작 과정 일회용 이메일 서비스를 구글에 검색해보면 정말 여러가지 서비스가 있음을 알 수 있습니다. 흔한 서비스이기 때문에 누군가 작성한 가이드 글이 있을거라 생각했습니다. AHEM server의 개발자인 Oren Geva님이 작성한 How To Setup Your Own Disposable Email Server 가이드를 찾았습니다. 가이드의 저자가 만든 오픈소스 AHEM (Ad-Hoc-Email-Server) server는 node.js로 만들어진 메일서버입니다. 가이드를 따라 메일서버를 AWS Lightsail에 구축했고, 정상 작동을 SMTP Test Tool 툴을 이용해서 확인했습니다. 메일 서버에서 사용할 도메인을 구입했습니다. 일회용 이메일 서비스는 길어야 하루, 짧은 기간만 이메일 사용하기 때문에 도메인을 매년 바꿔도 문제없습니다. 그래서 할인 받아 각각 500원에 1년동안 사용할 수 있는 도메인을 구입했습니다. 1년 후에는 하나에 49,000원의 비용이 지불해야 연장할 수 있지만, 애초에 연장할 생각이 없습니다. 도메인 주소를 메일 서버로 연결해야 하기 때문에, 도메인에 DNS 정보를 설정했습니다. MX record를 바로 서버 주소로 연결하고 싶었지만, MX record는 IP주소를 허용하지 않기 때문에, 중간에 mail.redmail.shop을 끼워넣었습니다. 이렇게 하면 MX record는 mail.redmail.shop 주소를 가리키고, 이 주소는 서버 주소인 15.165.14.244를 가리키게 됩니다. 등록하고 반나절이 지난 뒤에 Gmail에서 메일 서버로 이메일이 정상적으로 넘어왔습니다. 메일서버와 프론트를 연결할 API를 만들어야 하는데, AHEM server의 좋은 점은 Github readme 파일을 보면 아시다시피, 이미 API가 만들어져있습니다. 그래서 메일 서버를 연결한 것만으로 백엔드 구축이 마무리되었습니다. 마지막으로 웹을 Next.js로 구축하면서 개발을 마무리했습니다. 이미 초기 셋팅이 템플릿화 되어 있고, 디자인 라이브러리도 자동으로 연결되어 있어서 개발은 금방 끝났습니다. 사용한 기술 웹 : Next.js, Typescript, TailwindCSS 다국어화 : next-i18next (번역), Google sheet를 이용한 번역 텍스트 관리 배포 : Vercel을 통한 자동 배포 백엔드 : 오픈소스 AHEM server on AWS lightsail DB : MongoDB 좋았던 것들 오픈소스를 활용해서 백엔드 구축을 빠르게 마무리할 수 있어서 좋았습니다. 또 어렵게만 느껴졌던 메일서버가 코드를 살펴보니 생각보다 단순해서 다음에는 직접 구축할 수도 있을 것 같다고 생각했습니다. 주제 선정이 좋았다고 생각합니다. 개발 난이도는 낮지만, 유지보수 부담이 적어서 이런 사이즈의 프로젝트를 여러개 찾아보고 싶습니다. 진행하면서 겪었던 실패 AHEM server에는 CORS 처리가 되어 있지 않아서, 코드를 수정해야 했습니다. cptkuk91님의 Node.js 기본 CORS 문제 해결하기 글을 참고했습니다. Linux에서 1024포트까지는 관리자 권한이 있어야 사용할 수 있습니다. 제가 사용할 SMTP 포트는 25번이라서, 권리자 권한을 사용해서 메일 서버 서비스를 실행했습니다. AHEM server는 정말 오래전에 만들어진 프로젝트입니다. 그래서 최신 Node.js에서는 돌아가지 않습니다. Node.js 10.x 버전을 설치해서 진행했습니다. 비용을 절약하기 위해 AWS EC2가 아닌 AWS Lightsail을 사용했습니다. Lightsail은 기본적으로 요금도 절반이고, 처음에는 3개월을 무료로 사용할 수 있습니다. 다만 Lightsail은 AWS의 다른 서비스에 연결하기 어려워서 HTTPS 인증서를 Let's encrypt를 통해서 직접 설정해야했습니다. 이 Let's encrypt는 무료이지만 90일마다 연장을 해야하는 단점이 있습니다. 추후에는 자동으로 연장하는 설정을 하기로 계획하고, 마무리했습니다. 맺으며 오픈소스를 적절히 활용한 사례라서 좋습니다. 바퀴를 다시 만들지도 않았고, 이미 만들어진 바퀴를 잘 활용해서 개발을 3일만에 마무리할 수 있었습니다. 지금까지는 프론트로 웹만을 사용했는데, 이제부터는 앱도 만들어보려고 합니다. 이미 서버가 만들어져있기 때문에 앱은 더 빠르게 제작할 수 있을 것 같습니다. 서비스는 https://tmpmail.danver.io 에서 확인하실 수 있습니다. 참고자료 How To Setup Your Own Disposable Email Server Self-hosted disposable email addresses with AHEM 이메일의 발송 원리 (feat. SMTP, POP3, IMAP) AWS, EC2 nvm 설치 후 'sudo: node: command not found' 해결 방법 SMTP Test Tool
댄버 서버시간 프로젝트 개발 과정 및 후기
프로젝트 소개 이 프로젝트는 서버의 시간을 최대한 정확하게 알려주는 서비스입니다. 인기가 많은 티켓과 수강신청은 보통 열리자마자 수초내에 마감됩니다. 그래서 시간이 되자마자 빠르게 신청을 해야 합니다. 하지만 문제는 모든 서버의 시간이 미묘하게 다릅니다. 어떤 곳은 2초가 빠르고, 어떤 곳은 1초가 느립니다. 그 이상 차이가 나는 경우도 많이 있습니다. 미리 서버의 시간을 체크하고, 수강신청을 하는 것은 이제 필수입니다. 시작 이유 어떤 프로젝트를 진행할까 고민하다 깨달은 것이 있습니다. 1인 개발자의 제품은 리소스가 많은 기업과는 달라야 합니다. 1인 개발자는 자금도 부족하고, 개발에 사용할 수 있는 리소스도 부족합니다. 그러니 상품성을 조금 포기하더라도 더 적은 리소스를 사용하는 제품을 만들어야 합니다. 그래야 지속할 수 있습니다. 수강신청이나 티켓팅에 많이 사용되는 서버시간 조회 사이트는 백엔드의 부담이 거의 없습니다. Verecl을 통해 배포하면 추가적인 배포 비용도 들지 않기 때문에 광고를 통한 작은 수익화라도 이루어진다면 내가 자는 순간에도 조금씩 돈을 벌어줄 수 있습니다. 한번 만들어두면 특별한 문제 없이 계속 굴러가는 웹사이트는 1인 개발을 하는 제게 좋은 주제였습니다. 제작 과정 처음 진행하는 프로젝트라서 미리 계획을 짜고 시작했습니다 타겟 : 연령대 10 \~ 30, 공연 예매 또는 수강 신청하는 사람들. 개발 기간 : 2주로 잡았습니다. 1주차에는 핵심 기능만 작동하는 MVP 버전을 만들고, 2주차에 채팅 추가 및 아래처럼 부족한 부분을 채웠습니다. 한번에 완성하지 않고 단계를 나누는 이유는 MVP 버전이 미리 배포하고, 개선할 때 저는 가장 능률이 좋기 때문입니다. 2\. 프로젝트의 규모에 비해 일정을 길게 잡은 이유는 앞으로 이 정도 사이즈의 작은 프로젝트를 여러개 배포할 예정이기 때문입니다. 매번 바닥부터 만들기보다는 템플릿과 필요한 라이브러리를 미리 만들어두고, 다음 프로젝트에 활용할 수 있게 하는 것을 목표를 두었습니다. Next.js 템플릿을 만들었습니다. (i18n, svgr, react-query, tailwindcss 등을 미리 셋팅했습니다.) 디자인 시스템 프로토타입을 제작했습니다. 버튼이나 Input과 같은 자주 사용하는 컴포넌트를 미리 만들어서 Github packges에 배포해서 사용할 수 있도록 했습니다. 도메인은 구입하지 않고 서브도메인에 연결했습니다. 광고 수익이 들어올지도 불투명한 프로젝트에 매달 도메인 비용을 낼 수는 없었습니다. (https://servertime.danver.io 를 사용했습니다.) Route53을 이용해서 Vercel serverless의 cold start 문제를 Warm-up 한 것. 어떤 일을 할지 세세하게 나눠놓는 것이 일하기에 편해서 미리 카드를 만들었습니다. 하나의 카드를 끝낼 때마다 클리어 표시를 하고 통에 담으면서 하루동안 얼마나 많은 일을 처리했는지 매일 체크하면서 관리했습니다. 책상 앞에 구글홈을 두고, 25분씩 일하고 5분 쉬는 것을 반복했습니다. 같은 자세로 오랫동안 일하면 몸에 무리가 옵니다. 조금씩 자주 스트레칭을 해주면 그런 문제 없이 오랜 시간 집중할 수 있기 때문에 구글홈의 도움을 받습니다. 포모도로 타이머도 써보고, 여러가지 방법을 써봤지만 가장 편합니다. 일을 시작할 때 "헤이 구글, 25분 타이머" 라고 이야기해주면 정확히 25분 뒤에 알려주기 때문에 편히 시간 관리를 할 수 있습니다. 번역 텍스트는 구글 스프레드시트에서 관리했습니다. 한눈에 보기 편하고, 추후에 친구들에게 번역 요청을 할 때 편하기 때문입니다. 스프레드 시트에 작성하고, 명령어를 통해 다운로드 받아 i18n에 맞게 변환합니다. 8\. 디자인 시스템은 Github Packages를 통해 배포해서 사용하고 있습니다. NPM과 달리 Github Packages는 Private packages를 일정 범위까지는 무료로 사용할 수 있습니다. 9\. Vercel을 통해 웹을 배포했는데, 서버리스 특성상 몇분 사용을 멈추면, Cold start가 발생합니다. Route 53 Health Check를 활용해서 30초마다 리퀘스트를 때려서 항상 빠르게 접속할 수 있도록 설정했습니다. 이 부분은 아래 블로그 글을 참고했습니다. https://medium.com/aws-tip/speeding-up-aws-amplify-nextjs-first-render-cold-start-and-images-an-unexpected-result-36a416d69615 사용한 기술 웹 : Next.js, Typescript, TailwindCSS 다국어화 : next-i18next (번역), Google sheet를 이용한 번역 텍스트 관리 채팅 : Firebase Realtime Database 소리 재생 : use-sound 라이브러리 (https://github.com/joshwcomeau/use-sound) 배포 : Vercel을 통한 자동 배포 백엔드 : Next.js API route Backend 좋았던 것들 Github Packges를 통해 라이브러리를 처음 배포하고 사용한 것 프론트와 백엔드 모두에 자동배포를 적용해서 코드에만 집중할 수 있도록 한 것. (1인 개발의 문제인 리소스 부족을 조금이나마 도울 수 있다) Firebase Realtime database를 이용해서 채팅 서비스를 무료로 쉽게 만들어낸 것 (하루 다운로드 360MB 까지는 무료) 앞으로 내가 사용할 기술의 방향을 정한 것. 돈을 버는 것에 새롭고 더 좋은 기술은 의외로 필요하지 않다. 기술보다는 비즈니스가 더욱 중요하므로. 기술을 배우고 시행착오를 해결하는 시간에 하나의 프로젝트를 더 만드는 것을 선택했다. 퇴사 후 내가 주어진 시간은 6개월. 그 안에 결과를 내고 싶다. 진행하면서 겪었던 실패 정확한 시간 추측이 불가능 이 서비스의 핵심은 서버의 정확한 시간을 알아내는 것인데 여기에는 한계가 있습니다. 웹에서는 언제나 딜레이가 있는데, 네트웍 상황에 따라서 그 시간이 매번 다르기 때문입니다. CORS 문제로 인해 사용자의 디바이스가 아닌 Vercel 서버에서 티켓팅 사이트로 신호를 보내는 것에도 문제가 있습니다. 더 나은 방법을 찾기 까지는 지금 방법 그대로 사용하기로 했습니다. Amplify로 Next.js 배포 Vercel에 광고를 달면 유료 플랜 (월 $20)을 구매해야 합니다. 이런 문제가 없는 AWS Amplify를 통해 배포를 시도했지만, locale detection에 어려움이 있어서 포기했습니다. middleware로 도전했지만, 순조롭지 않았습니다. 정해진 일정이 있으므로, 추후에 해결되면 다시 시도해볼 예정. Ad sense 승인실패 컨텐츠 부족으로 실패했습니다. 더 많은 컨텐츠를 추가해야 합니다. 이 부분은 차라리 블로그를 통해 광고 승인을 받는 방법으로 변경합니다. 루트 url에 대해 승인을 받으면 서브도메인은 승인 없이 사용할 수 있기 때문에 블로그를 통해 승인 받고 앞으로 만들어지는 프로젝트에는 처음부터 광고를 삽입 할 예정입니다. \맺으며 간단한 사이트이지만 계획했던 대로 결과물을 만들어낸 것에 만족합니다. 또 다음 프로젝트를 빠르게 만들 수 있도록 여러 기반을 만들어둔 것이 뿌듯합니다. 앞으로는 생각이 조금 달라질 것 같습니다. 이제 새로운 서비스의 MVP버전은 작은 규모라면 하루만에 만들어서 배포할 수도 있기 때문에 출근하면서 길을 걷다가도 아이디어가 떠오르면 바로 시도해볼 수 있을 것 같습니다. 언젠가 완성하고 싶은 목록 언어 번역을 다른 사용자로부터 도움 받을 수 있는 환경 구축. 하나의 언어를 추가하면 그 언어를 사용하는 사람만큼 검색에 노출될 확률이 증가합니다. 이를 위해 언어 번역 도움을 받을 수 있는 방법을 고민해보고 싶습니다. 앞으로 제가 만들 어떤 서비스든 활용할 수 있기 때문입니다.
인프런 사이드 프로젝트 밋업 후기
요즘 퇴사 후에 여러 사이드 프로젝트를 개발하고 있다. 다른 사람들은 어떻게 하고 있을까 라는 궁금증에 인프런에서 진행되었던 사이드 프로젝트 밋업에 참가했다. 이번 모임에는 사이드 프로젝트에 대해 알고 싶어하는 많은 디자이너, PM, 개발자가 참여했다. 다양한 이유로 참석한 사람들 내게 사이드 프로젝트는 돈을 버는 것이 목적이다. 다른 사람들은 어떨까? 궁금해서 물어보고 다녔다. 누군가는 즐거움을 위해, 누군가는 취업에 필요한 포트폴리오를 만들기 위해 프로젝트를 찾고 있었다. 사이드 프로젝트를 하고 싶었는데, 어떻게 해야할지 막막해서 다른 사람들의 도움을 구하기 위해 참석한 사람들도 있었다. \사이드 프로젝트 경험에 대한 발표들 첫 발표는 베이킹을 하는 지인을 위해 팀을 꾸려 직접 레시피를 관리할 수 있는 앱을 만든 이재영님의 발표였다. 최근에도 꾸준히 앱을 업데이트 하고 있는 모습이 자신의 프로덕트에 애정을 가지고 있는 것 같아 보기 좋았다. 두번째는 밈을 좋아하는 전정민님이 팀과 함께 만든 서비스 그밈이라는 서비스에 대한 발표였다. 사이드 프로젝트는 팀원들 각자의 목표가 다르고 강제성도 없다보니 그들을 어떻게 하나로 뭉치고, 계속 나아갈 수 있는지에 대한 이야기를 들었다. 앞에 계셨던 분은 발표를 들고 팀을 이끌어 나가는 모습에 감명을 받았던 것 같았다. \발표를 들으면 느꼈던 나의 생각 내가 느끼기에 근본적인 한계도 있는 것 같아 보였다. 개발 프로덕트는 완성되면 끝이 아니라, 끊임없는 유지 보수를 필요로 한다. 하지만 수익이 창출되지 않고, 강제성도 없다면 지속적인 유지 보수는 불가능하다. 함께 팀으로 활동하던 개발자가 없어진다면 문제가 발생해도 손을 댈 수 없어 결국 내려지지 않을까? 또 대부분의 개발 프로덕트는 기본적으로 서버 비용이 발생한다. 재정적인 상황이 괜찮을 때는 문제가 되지 않지만, 상황이 조금 어려워질때는 이 작은 비용조차 '서비스를 내려야 하나?' 라는 고민을 하게 만들 수 있을 것 같았다. 하지만 즐거움을 목표로 하기에 더 다양한 프로덕트가 만들어 질 수 있는 것 같기도 하다. 세상에 없는 서비스를 마음 맞는 사람들이 모여 한번 만들어 보는 것, 그 자체로 설레게 하는 매력이 있으니까. 사람들과 대화가 정말 좋았다 서비스를 만들어보고 싶어하는 사람들의 모임이라 각자가 가진 에너지가 참 좋았다. 누군가는 손을 들어 팀원을 찾고 있었고, 누군가는 매력적인 프로젝트를 탐색하고 있었다. 회사에서 우리가 만드는 프로젝트는 대부분 비슷하고, 마음이 없어도 해야하는 것이기에 지치기도 한다. 하지만 사이드 프로젝트는 마음이 있을때만 모여서 만들기 때문에 다들 웃고 있는 표정이 기억에 남는다. 나는 수익이 발생할 경우 분배를 어떻게 해야하는지에 대한 궁금증을 묻고 다녔는데 좋은 대답을 얻어서 뿌듯했다. 작은 프로젝트를 여러개 만들고 있는 내 상황에 맞는 답은 목표한 수치 달성시 이후 협의 였다. 대부분의 프로젝트는 충분한 수익을 발생시키기조차 어렵다. 그러니 처음에 어느정도 수치를 정하고, 그 목표를 도달하게 되면 앞으로의 순수익을 어떻게 나눌지 정하면 된다는 것이었다. 이 답변 덕분에 다른 사람들과 협업을 시작할때도 망설이지 않고 걱정하지 않고 시작할 수 있을 것 같아서 좋았다. 팀원을 찾는 방법 사이드 프로젝트를 원하는 사람들이 가장 걱정하는 것은 팀원을 찾는 방법일 것 같다. 인프런 사이트에서 팀 프로젝트를 같이 할 사람들을 찾을 수 있다. 아래에 해당하는 사람들이라면 모두에게 도움이 되지 않을까 생각해본다. 평소에 해보지 않았던 사이드 프로젝트를 통해 모두가 각자의 커리어에서 한계단 씩 꾸준히 올라갈 수 있게 되기를 바란다. 이력서에 넣을 포트폴리오가 필요한 사람 즐거움을 위해 사이드 프로젝트를 찾고 있는 사람 성장을 위해서 도전해 볼 분야를 찾고 있는 사람
인디메이커로 일하며 동기부여 받기
들어가며 인디메이커(Indie maker)란 혼자서 프로덕트를 만드는 1인 기업을 의미한다. 인디메이커, 1인개발, 인디해커 다양하게 불리며 그냥 1인기업이라는 뜻이다. 개발자 중에 이 분야의 유명한 사람은 levelsio라는 분이 있는데, 자신이 만든 프로덕트로 한달에 $220,000 을 벌고 있다. 그의 트위터 계정에 수익이 공개되어 있고, 자신이 가진 생각 들을 끊임없이 나누고 있다. 1인 기업의 단점은 결국 혼자서 한다는 것이다. 특히 혼자서 일을 진행해야하기 때문에 격려해줄 사람도 없고, 끌어줄 사람도 없다. 이럴 때 비슷한 일을 하는 사람들의 커뮤니티가 큰 도움이 된다. levelsio가 운영하는 텔레그램 커뮤니티가 있다. 이곳에서 궁금한 것들을 질문할 수도 있고, 다른 사람들은 어떤 생각을 가지고 있는지 읽어볼 수도 있다. 내가 사용하는 또 다른 방법은 트위터(지금은 X)에서 levelsio를 팔로우하는 것이다. 그를 팔로우하면 비슷한 인디해커들을 많이 추천해주는데, 매일 전업으로 개발하시는 분들을 많이 찾을 수 있기 때문에 자주 소통하면 동기부여를 주고 받을 수 있다. 한가지 팁을 주자면 수익을 발생시키고 있는 분들은 levelsio처럼 자신의 수익을 공개하고 있다. 프로필 설명에 사이트 주소와 MRR (월 반복 수익)이 있다면 인디해커를 제대로 하고 있다고 생각해도 된다. 내가 찾은 방법은 이 정도이다. 혼자서 일하는 것은 자유도도 높고, 하고 싶은 일을 할 수 있지만 외롭고 버거울 때도 있다. 창업 동아리도 좋고, 비슷한 커뮤니티도 좋다. 계속 서로를 격려하면서 나아갈 수 있는 곳을 찾는다면, 좀 더 멀리 나아갈 수 있을 것이다.
Harbor 사용 후기
Docker를 써야만 했다. Docker라는 것은 참 신기하다. 없어도 충분히 할 수 있었고, 진입장벽도 높아서 신입 때는 “이걸 왜 사용해야 할까?“라는 의문이 떠나질 않았다. 하지만 학습이 끝나고 사용해야 하는 이유를 느끼게 되자, 이제는 Docker 없는 개발자의 삶을 상상하기 어려워졌다. 처음 약간의 진입장벽만 넘으면, 마치 넓은 평야가 펼쳐지듯 허들을 넘어야 할 이유는 충분했다. 이번에 AI 관련 수업을 들으면서 Hugging Face에 있는 수많은 모델들을 내가 만든 서비스에 녹여내고 싶었다. 그래서 집에서 운영 중인 PC에 Docker로 각 서비스를 운영하기로 했다. 하지만 문제는 비용이었다. 현재 직장을 쉬며 공부 중이라 수입이 없어, 최대한 비용을 아껴야 했다. Docker Hub 구독으로 Private Repository를 사용하기엔 부담스러웠고, 대안을 찾아 나섰다. 가장 먼저 알게 된 방법은 docker-registry를 설치해 자신의 로컬 PC에서 직접 운영하는 것이었다. 하지만 더 살펴보다가 Harbor라는 오픈소스 서비스를 알게 되었고, 여러 가지 관리 기능까지 제공한다는 점에서 큰 매력을 느꼈다. 그래서 바로 사용해보기로 했다. Harbor 설치 방법 arbor 설치는 기본적으로 다음 단계를 따랐다. 네트워크 지식이 부족한 탓에 처음엔 약간 애를 먹었지만, 덕분에 많은 것을 배웠다. Docker 및 Docker Compose 설치 Harbor는 컨테이너로 구동되기 때문에, 우선 Docker와 Docker Compose가 설치되어 있어야 한다. 설치 명령어는 다음과 같다. Harbor 설치 파일 다운로드 Harbor의 설치 파일은 Harbor 공식 GitHub에서 다운로드할 수 있다. 아래 명령어로 최신 버전을 다운로드하고 압축을 해제했다. 설정 파일 수정 설치 디렉토리 안에 있는 harbor.yml 파일을 수정했다. 주로 변경한 항목은 다음과 같다: hostname: Harbor 서버의 IP 주소 또는 도메인. https 설정: SSL 인증서를 적용하고 싶다면 관련 경로 설정. Harbor 설치 및 실행 설정을 마친 후, 다음 명령어로 Harbor를 설치하고 실행했다. Harbor 웹 접속 설치가 완료되면 브라우저에서 http:// 또는 https:// 으로 접속해 Harbor 웹 UI에 로그인할 수 있다. 기본 계정은 아래와 같다: • 아이디: admin • 비밀번호: Harbor12345 (설치 중 변경 가능) Harbor 사용 후기 Harbor의 웹 UI는 깔끔하고 직관적이었다. 사용해보며 느낀 장점은 다음과 같다: Private Repository 관리가 간편하다 Docker 이미지를 Private Repo로 저장하고 관리할 수 있어, 외부 의존도를 줄이고 보안도 강화할 수 있었다. 사용자 및 프로젝트 관리 기능 팀 협업 환경에서도 유용할 것으로 보인다. 사용자 권한을 세분화할 수 있어, 여러 사람이 사용할 때도 안전하게 운영 가능하다. Webhook과 보안 정책 특정 조건에 따라 Webhook을 설정하거나 이미지 보안 검사를 수행할 수 있는 기능이 매력적이었다. 개인 프로젝트뿐만 아니라 상용 프로젝트에도 충분히 활용 가능해 보였다. 아쉬운 점 처음 설치 과정에서 네트워크와 포트 설정 문제로 약간의 시행착오가 있었다. 특히 방화벽 설정이나 SSL 인증서 적용은 초보자에겐 약간 복잡하게 느껴질 수 있다. 관리 기능이 많다 보니 처음엔 모든 옵션을 이해하는 데 시간이 필요했다. 결론 Harbor는 Docker Registry의 강력한 대안이었다. 특히 비용을 아끼고 싶지만, 관리 기능도 놓치고 싶지 않은 사람들에게 완벽한 솔루션이다. 개인 서버에 Docker Private Repo가 필요하다면 한 번 도전해볼 만하다. 직접 설치하고 운영하면서 배우는 재미도 있으니, 관심 있다면 꼭 한 번 시도해보길 추천합니다