Author: AZAZA

  • Feature Bloat, 기능팽만증이라는 독-스타트업을 위한 나만의 교양

    🚀 기능 과잉(Feature Bloat), 사업을 망치는 가장 쉬운 방법

    프로젝트를 진행하면서 원점으로 되돌아가는 경험을 한 적이 있으신가요? 최근 저 또한 비슷한 상황을 겪었습니다. 많은 기획자들이 범하는 실수 중 하나는 상부 보고나 투자 유치를 위한 과도한 포장입니다. 본래의 기능을 단순하고 효과적으로 만들기보다, 차별화 전략이라는 이름 아래 덕지덕지 기능을 추가하다가 본질을 잃어버리고 맙니다.

    기능이 많아질수록 기획은 복잡해지고, 이를 개발하는 조직은 시간이 지날수록 점점 더 지쳐갑니다. 기획 단계에서 검증되지 않은 기능들이 포함되면서, 결국 제품은 시장에서 외면받거나 유지보수조차 어려운 상태에 빠지고 맙니다. “이 기능이 있으면 투자받을 수 있을 거야.”

    “이건 차별화 요소니까 꼭 넣어야 해.”

    이런 논리로 무리한 기능을 추가하다 보면 어느새 프로젝트는 누더기가 되어, 스스로 풀 수 없는 문제 속에 좌초되고 맙니다.


    Feature Bloat(기능 과잉)은 단순한 개발 실수를 넘어, 비즈니스 자체를 좌초시키는 가장 흔한 함정 중 하나라고 생각합니다. 저는 이를 스타트업의 성장 과정에서 반복적으로 발생하는 심리적 패턴과 연결해서 바라봅니다.

    1. Feature Bloat가 발생하는 심리적 원인

    (1) “더 많은 기능이 더 좋은 제품이다”라는 착각

    많은 스타트업이 “우리는 경쟁사보다 더 많은 기능을 제공해야 한다”라는 생각에 사로잡힙니다. 하지만 제품의 경쟁력은 기능의 개수가 아니라, 고객이 원하는 핵심 문제를 얼마나 잘 해결하는지에 달려 있습니다.

    ❌ “우리 제품은 올인원(All-in-One) 솔루션이다!”

    ✅ “우리 제품은 이 문제를 가장 효과적으로 해결하는 솔루션이다!”

    Apple이 iPhone을 처음 출시할 때, 당시의 스마트폰들은 물리 키보드를 기본적으로 갖추고 있었습니다. 하지만 Apple은 키보드를 과감히 제거하고 터치스크린에 집중했습니다. 기능을 줄였지만, 고객이 원하는 본질적인 경험을 극대화하는 데 성공한 사례입니다.

    (2) 기획자와 경영진의 욕망: 포장하려는 본능

    경영진과 기획자는 투자자와 시장의 관심을 끌기 위해 “이 기능이 있으면 더 돋보일 것”이라는 생각을 하게 됩니다. 그러면서 기능이 계속 추가되고, 핵심 가치가 희미해지기 시작합니다.

    “이 기능이 있으면 투자받을 수 있을 거야.”

    “이 기능이 우리만의 차별화 포인트가 될 거야.”

    이러한 논리가 계속해서 기능을 덧붙이게 만듭니다.

    문제는 이렇게 추가된 기능 대부분이 실제 사용자의 문제를 해결하는 것이 아니라, 내부 논리로 만들어진 것이라는 점입니다. 결국 제품이 누더기가 되고, 개발팀은 끝없는 기능 추가와 유지보수로 지쳐갑니다.

    (3) “고객이 요청했으니까 넣어야 한다”는 착각

    고객 피드백을 수집하는 것은 매우 중요합니다. 하지만 “고객이 원한다고 다 만들어야 하는가?“라는 질문을 던져봐야 합니다.

    고객의 피드백은 개별적인 요구사항일 뿐, 시장 전체의 니즈를 반영하는 것은 아닙니다. 고객이 진짜 원하는 것은 더 많은 기능이 아니라, 더 쉬운 해결책일 가능성이 높습니다.

    “A 고객이 이 기능을 원한다고 해서 만들었는데, B 고객은 정작 필요 없다고 하네?”

    “이제 기능이 너무 많아져서 오히려 사용하기 어려워졌어.”

    이런 상황이 반복되면, 결국 아무도 만족하지 못하는 제품이 되고 맙니다.

    스타트업에서 중요한 것은 모든 고객을 만족시키려는 것이 아니라, 명확한 고객층을 정의하고 그들에게 가장 적합한 솔루션을 제공하는 것입니다.


    2. Feature Bloat를 방지하는 법: 핵심 질문 3가지

    저는 첫 스타트업 경험에서 이러한 현상을 직접 겪었고, 이후 많은 조직과 프로젝트팀에서도 같은 문제를 목격했습니다. 그리고 하나의 명확한 해답을 찾았습니다.

    🎯 기능을 덜어내고, 고객에 집중하십시오.

    기능 과잉(Feature Bloat)은 스타트업과 제품 개발에 있어 가장 치명적인 함정입니다. **“더 많은 기능이 곧 좋은 제품이다”**라는 착각을 버려야 합니다.

    기능을 추가하기 전에 반드시 아래 세 가지 질문을 던져야 합니다.

    (1) 이 기능이 고객의 가장 큰 문제를 해결하는가?

    •  만약 해결하지 않는다면, 추가할 이유가 없습니다.
    • 고객의 진짜 문제를 파악하지 않고 기능을 넣으면, 결국 아무도 사용하지 않는 기능이 됩니다.

    (2) 이 기능이 비즈니스 목표에 부합하는가?

    • “재미있을 것 같다”는 이유로 기능을 추가하면 안 됩니다.
    • 투자 유치나 단기 마케팅 효과를 위해 기능을 넣는 것도 위험합니다.

    (3) 이 기능 없이도 고객이 가치를 느낄 수 있는가?

    • 만약 이 기능이 없다고 해서 제품의 핵심 가치가 무너지지 않는다면, 추가할 필요가 없습니다.
    • 오히려 기능을 덜어내면서 더 좋은 사용자 경험을 제공할 수 있는지 고민해야 합니다.

    3. 기능 과잉이 초래하는 문제

    (1)  개발 속도 저하 & 유지보수 부담 증가

    • 불필요한 기능 추가로 개발 일정이 늘어나고, 유지보수에 과도한 리소스가 소모됩니다.
    • 제품이 복잡해지면서 새 기능을 추가할 때마다 기존 시스템과의 충돌 위험이 커집니다.

    (2) 사용자 경험(UX) 저하

    • 고객이 원하는 핵심 기능이 아니라 “회사 내부의 논리”로 만들어진 기능들이 쌓이면, 정작 사용자는 혼란을 느낍니다.
    • 많은 기능을 제공한다고 해서, 고객이 만족하는 것은 아닙니다. 오히려 간결하고 직관적인 경험을 선호합니다.

    (3)  비즈니스 방향성 상실

    • 사업 계획이 기능 중심으로 변질되면, 진짜 중요한 시장과 고객 문제 해결이 뒷전으로 밀립니다.
    • “우리 서비스는 뭐가 핵심인가?“라는 질문에 명확한 답을 할 수 없다면, 이미 기능 과잉에 빠진 것입니다.

    4. 해결책: Lean 개발과 본질에 집중하기

    (1) 고객 중심 개발

    • 기능 추가 전에 반드시 고객 인터뷰와 데이터를 기반으로 검증하십시오.
    • MVP(Minimum Viable Product)를 통해 **“이 기능이 정말 필요한가?”**를 빠르게 판단하십시오.
    • “Nice-to-have”가 아니라 “Must-have” 기능만 우선 적용하십시오.

    (2) Lean 개발 방식 적용

    • Build → Measure → Learn 주기를 짧게 반복하며, 꼭 필요한 기능만 추가하십시오.
    • KPI 기반 개발: “이 기능이 실제 비즈니스 성과에 어떤 영향을 미치는가?“를 수치로 평가하십시오.
    • Scope Control: 기능을 추가하는 것이 아니라, 불필요한 기능을 제거하는 것이 더 중요합니다.

    (3) 마케팅 관점에서 접근

    • 핵심 기능을 강조하고, **“이 제품은 무엇을 해결하는가?”**를 한 문장으로 설명할 수 있어야 합니다.
    • 너무 많은 기능을 홍보하면 고객은 오히려 혼란을 느낍니다. 명확한 메시지와 USP(Unique Selling Proposition)를 설정하십시오.
    • 초기 고객층(Early Adopters)이 가장 필요로 하는 기능에 집중하십시오.

    🎯 결론: 본질에 집중하십시오.

    기능을 추가하는 것은 어렵지 않습니다. 그러나 불필요한 기능을 제거하는 것이야말로 가장 용기 있는 선택입니다.

    비즈니스에서 중요한 것은 많은 기능이 아니라, 고객이 정말로 원하는 가치를 제공하는 것입니다.

    “Less is More.”

    적은 기능이 오히려 더 강력한 무기가 됩니다.

    👉 지금 여러분의 프로젝트는 핵심 가치를 유지하고 있습니까? 불필요한 기능을 과감하게 버릴 준비가 되었습니까?

  • 약한 연결고리를 찾아 혁신하는 전략-스타트업을 위한 나만의 교양

    디커플링(Decoupling)

    오늘은 디커플링(Decoupling) 전략에 대해 깊이 있게 탐구해보려 합니다. 디커플링은 단순한 비용 절감이 아니라, 기존 산업의 가치사슬(Value Chain)을 분리하여 새로운 시장 기회를 창출하는 전략입니다. 이를 통해 기존 산업을 혁신하고, 때로는 시장 자체를 재편할 수도 있습니다.

    1. 가치사슬 디커플링이란?

    디커플링이란 기존 산업에서 하나의 흐름으로 연결된 가치사슬을 분해하여 특정 단계(약한 연결고리)를 제거하거나 새로운 방식으로 재구성하는 것을 의미합니다. 이 과정에서 기업은 기존 시장의 틀을 깨고, 고객에게 더 나은 경험을 제공할 수 있습니다.

    디커플링의 대표적 사례

    테슬라(Tesla): 자동차 유통에서 딜러를 제거하고 온라인 직접 판매 → 전통적인 자동차 딜러 시스템 붕괴
    넷플릭스(Netflix): DVD 유통 단계를 없애고 스트리밍 서비스를 제공 → 전통적인 방송 및 미디어 업계에 혁신
    핀테크 기업(Wise, 카카오뱅크): 기존 은행의 복잡한 절차를 제거하고 모바일 기반 금융 서비스 제공 → 기존 은행 점포의 역할 축소

    이처럼 디커플링은 특정 가치사슬의 ‘약한 연결고리’를 찾아 새로운 비즈니스 모델을 만드는 방식입니다.

    2. 디커플링 3가지 방식

    디커플링 방식은 크게 3가지로 나눌 수 있습니다.

    ① 가치 창출과 가치 잠식 활동을 분리하기

    • 기업이 창출하는 핵심 가치와 불필요한 비용(유통, 중개자 등)을 분리하여 본질적인 서비스에 집중하는 전략입니다.
    • 예시: 테슬라는 자동차 판매에서 딜러를 제거함으로써 불필요한 마진을 없애고, 고객에게 직접 판매하여 가격 경쟁력을 확보했습니다.

    ② 가치에 대한 부과(Attachment to Value) 디커플링 하기

    • 기존 제품이나 서비스에서 반드시 따라오던 요소(불필요한 기능, 수수료 등)를 제거하는 전략입니다.
    • 예시: 넷플릭스는 DVD 패키지 및 물리적 유통 과정을 제거하고 온라인 스트리밍만 제공함으로써 비용을 절감하고, 고객 경험을 단순화했습니다.

    ③ 부가 요소(Additional Value) 분리

    • 기존에 포함되어 있던 부가 요소(유지보수, 인프라, 중개자 등)를 분리하여 새로운 시장 기회를 창출하는 방식입니다.
    • 예시: SaaS(Software as a Service) 모델은 소프트웨어 구매 시 유지보수 비용을 없애고, 클라우드 기반으로 전환하여 지속적인 서비스 업데이트를 제공하는 형태로 변화했습니다.

    3. 디커플링의 핵심: 약한 연결고리 찾기

    디커플링을 하려면 기존 가치사슬에서 ‘약한 연결고리’를 찾아야 합니다. 약한 연결고리는 고객의 불만이나 불편함에서 비롯될 가능성이 높습니다.

    고객 불만을 체계적으로 분석하기

    불만 유형설명디커플링 기회
    접근성 문제고객이 서비스에 쉽게 접근하지 못함원격 서비스, 비대면 솔루션
    비용 부담불필요한 비용(유통 마진, 유지보수 등) 발생SaaS 모델, 중개자 제거
    경험 및 편의성 불만절차가 복잡하고 사용하기 어려움AI 자동화, 간편 UI 도입
    신뢰성 문제서비스 품질이 낮거나 불안정함AI 기반 모니터링, 클라우드 전환

    고객의 불만을 구조적으로 정리하면 디커플링을 통해 혁신할 수 있는 기회가 더욱 명확해집니다.

    고객 불만을 체계적으로 분석하는 방법

    📌 (1) 고객 여정 분석 (Customer Journey Mapping)

    고객이 제품/서비스를 사용하는 전 과정을 단계별로 분석

    각 단계에서 고객이 겪는 불편함을 찾아 약한 연결고리를 발견

    예를 들어, 고객이 전통적인 은행을 이용하는 과정을 분석해보면:

    1️⃣ 지점 방문 → 대기 시간 길음

    2️⃣ 계좌 개설 → 신분증 + 종이 서류 제출 필요

    3️⃣ 송금 → 수수료 비쌈

    4️⃣ 대출 심사 → 승인까지 시간이 오래 걸림

    디커플링 기회: “카카오뱅크” 같은 비대면 은행 모델이 위의 모든 약한 연결고리를 제거할 수 있음!

    📌 (2) 고객 피드백 데이터 분석

    • 고객 리뷰, VOC(Voice of Customer), 소셜미디어 데이터를 활용하여 주요 불만사항을 수집

    • AI 기반 데이터 분석을 활용하여 반복적으로 나타나는 패턴을 파악

    예시:

    • 고객 불만 데이터에서 “고객센터 연결이 어렵다”는 피드백이 많다면 → AI 챗봇 자동 응대 도입

    📌 (3) 경쟁사 분석

    • 경쟁사의 고객들이 불만을 느끼는 부분을 분석하여 디커플링 기회를 포착

    • 기존 기업들이 쉽게 해결하지 못하는 문제를 새로운 방식으로 해결

    예시:

    • 전통적인 호텔 고객들이 “체크인이 복잡하다”는 불만이 많다면 → 에어비앤비의 디지털 체크인 시스템 도입 기회

    4. 디커플링을 시도하면 경쟁자의 반응은?

    디커플링을 통해 기존 시장에서 고객을 빼앗아올 경우, 경쟁사는 크게 4가지 대응 전략을 사용할 가능성이 있습니다.

    ① 적극적 반격 (Aggressive Retaliation)

    • 기존 기업이 가격 인하, 법적 대응, 정부 로비 등을 통해 강력하게 반격할 가능성이 있음.
    • 예시: 기존 자동차 제조업체들이 테슬라의 직접 판매 방식을 방해하기 위해 특정 지역에서 딜러 판매 법규를 강화.

    ② 가치사슬 재구성 (Rebuilding Value Chain)

    • 기존 기업이 디커플링된 요소를 따라가거나 새로운 방식으로 대응.
    • 예시: 기존 은행들이 핀테크 기업의 위협을 줄이기 위해 모바일 금융 서비스를 자체적으로 구축.

    ③ M&A 및 협업 (Mergers & Acquisitions)

    • 기존 기업이 혁신 스타트업을 인수하거나 협력하여 경쟁력을 유지.
    • 예시: 페이스북(메타)이 인스타그램, 왓츠앱을 인수하여 SNS 시장 지배력 유지.

    ④ 시장 세분화 및 니치 마켓 공략

    • 기존 기업이 특정 고객층(프리미엄 시장, 저가 시장 등)을 집중 공략하여 차별화.
    • 예시: 스타벅스는 프리미엄 고객층을, 맥도날드(McCafe)는 저가 커피 시장을 공략.

    경쟁사의 대응을 예상하면 디커플링 전략을 보다 정교하게 설계할 수 있습니다.

    5. 결론: 디커플링은 반드시 수익과 연결되지 않는다

    디커플링 전략이 반드시 단기적인 수익 증가로 이어지는 것은 아닙니다. 경우에 따라 비용이 증가할 수도 있지만, 장기적으로 시장을 선점하고 경쟁력을 확보하는 전략적 도구로 활용됩니다.

    단기적인 비용 증가 가능 → 새로운 가치사슬 구축 비용 증가 (예: 클라우드 전환, 물류 혁신)
    장기적인 시장 점유율 확대 → 경쟁자를 약화시키고 고객 충성도 확보
    브랜드 이미지 개선 → 지속 가능성, 혁신 기업으로 포지셔닝

    디커플링은 단순한 비용 절감이 아니라, 산업을 재구성하고 미래의 시장 리더가 되기 위한 전략적 도구입니다. 디커플링을 통해 고객의 불편을 해결하고, 시장의 변화를 선도하는 기업이 될 수 있습니다. 🚀

  • Python을 사용하여 Google 뉴스 RSS를 블로그에 자동 포스팅하기

    Google 뉴스 RSS를 가져와서, WordPress 블로그에 자동으로 포스팅하는 과정을 정리해 드릴게요.

    1️⃣ Python 및 환경 설정

    📌 1. Python 설치

    Mac에서는 기본적으로 Python이 설치되어 있지만, 최신 버전이 필요할 수도 있습니다.

    brew install python

    설치 후 버전을 확인하세요.

    python3 --version

    출력 예시: Python 3.13.1

    (3.6 이상이면 OK)

    📌 2. 가상 환경(venv) 설정

    가상 환경을 만들어 프로젝트를 격리하는 것이 좋습니다.

    mkdir rss_to_blog
    cd rss_to_blog
    python3 -m venv venv
    source venv/bin/activate  # 가상 환경 활성화

    source venv/bin/activate를 실행하면 (venv)가 터미널 앞에 붙어야 합니다.

    📌 3. 필요한 패키지 설치

    pip install feedparser requests

    • feedparser → RSS 피드를 가져오기 위한 라이브러리

    • requests → WordPress API 호출을 위한 HTTP 라이브러리

    2️⃣ Google 뉴스 RSS 가져오기

    Python 코드로 Google 뉴스 RSS를 가져와봅니다.

    📌 Google 뉴스 RSS URL 예시

    import requests
    import feedparser
    
    rss_url = "https://news.google.com/rss?hl=ko&gl=KR&ceid=KR:ko"
    
    # 브라우저처럼 보이도록 User-Agent 설정
    headers = {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
    }
    
    # RSS 요청 보내기
    response = requests.get(rss_url, headers=headers)
    feed = feedparser.parse(response.content)
    
    # RSS 데이터 확인
    print("✅ 받아온 뉴스 개수:", len(feed.entries))
    
    for entry in feed.entries[:5]:  # 최신 5개 기사 출력
        print(f"제목: {entry.title}")
        print(f"링크: {entry.link}")
        print(f"게시 날짜: {entry.published}")
        print("-" * 40)

    실행

    python3 rss_test.py

    ✅ 정상 실행되면 최신 뉴스 5개가 출력됩니다.

    3️⃣ WordPress API를 이용해 블로그에 자동 포스팅

    📌 1. WordPress REST API 설정

    WordPress에서 API를 사용하려면 Application Password를 발급받아야 합니다.

    1. WordPress 관리자 페이지로 이동 (https://your-wordpress-site.com/wp-admin)

    2. 사용자 → 내 프로필 (Users → Your Profile)

    3. Application Passwords 섹션에서 새 비밀번호 생성

    (예: RSS Auto Poster)

    4. 발급된 비밀번호를 저장해 둡니다.

    📌 2. WordPress에 자동 포스팅하는 Python 코드

    RSS에서 뉴스 데이터를 가져와 WordPress 블로그에 자동으로 게시하는 코드입니다.

    import requests
    import feedparser
    from requests.auth import HTTPBasicAuth
    
    # ✅ Google 뉴스 RSS URL
    rss_url = "https://news.google.com/rss?hl=ko&gl=KR&ceid=KR:ko"
    
    # ✅ WordPress REST API 설정
    WP_URL = "https://your-wordpress-site.com/wp-json/wp/v2/posts"
    WP_USERNAME = "your_username"  # WordPress 관리자 계정
    WP_APP_PASSWORD = "your_application_password"  # 발급받은 비밀번호
    
    # ✅ RSS 요청 보내기
    headers = {"User-Agent": "Mozilla/5.0"}
    response = requests.get(rss_url, headers=headers)
    feed = feedparser.parse(response.content)
    
    # ✅ 최신 뉴스 3개 포스팅
    for entry in feed.entries[:3]:
        post_title = entry.title
        post_content = f"<p><a href='{entry.link}'>기사 원문 보기</a></p>"
    
        # WordPress API 요청 데이터
        post_data = {
            "title": post_title,
            "content": post_content,
            "status": "publish"  # 'draft'로 하면 검토 후 게시 가능
        }
    
        # ✅ WordPress API 요청
        wp_response = requests.post(WP_URL, json=post_data, auth=HTTPBasicAuth(WP_USERNAME, WP_APP_PASSWORD))
    
        if wp_response.status_code == 201:
            print(f"✅ 게시 성공: {post_title}")
        else:
            print(f"❌ 게시 실패: {wp_response.text}")

    📌 실행

    python3 rss_to_wordpress.py

    ✅ 성공하면 블로그에 뉴스가 자동으로 게시됩니다.

    4️⃣ 자동 실행 (스케줄링)

    뉴스를 정기적으로 자동 포스팅하려면 cron을 설정합니다.

    📌 1. crontab 설정

    crontab -e

    📌 2. crontab에 추가

    매일 오전 9시에 실행하고 싶다면:

    0 9 * * * /Users/bigeyes0218/Developments/rss_to_blog/venv/bin/python3 /Users/bigeyes0218/Developments/rss_to_blog/rss_to_wordpress.py

    ✅ 이제 매일 오전 9시에 Google 뉴스가 자동으로 블로그에 게시됩니다!

    🚀 최종 정리

    단계설명
    1Python 및 가상 환경 설정 (venv)
    2feedparser를 이용해 Google 뉴스 RSS 가져오기
    3WordPress REST API를 이용해 자동 포스팅
    4crontab으로 정기 실행 자동화

    ✅ 이제 Python을 이용해 Google 뉴스 → WordPress 블로그 자동 포스팅이 완성되었습니다! 🚀😊

  • Certbot 자동 갱신 방법

    AWS Route 53을 사용하고 있다면 와일드카드 인증서를 자동 갱신하려면 DNS 인증(DNS-01 Challenge)을 자동화해야 합니다. Certbot이 Route 53을 통해 자동으로 DNS TXT 레코드를 추가하도록 설정하면 수동 입력 없이 인증서 갱신이 가능합니다.

    1. AWS IAM 역할 및 권한 설정

    Certbot이 Route 53에서 DNS 레코드를 추가할 수 있도록 AWS IAM에서 적절한 권한을 부여해야 합니다.

    1. IAM 사용자 생성 또는 기존 사용자를 사용

    2. 해당 사용자에 Route 53 권한을 부여 (JSON 정책 추가):

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "route53:ChangeResourceRecordSets",
                    "route53:GetChange",
                    "route53:ListHostedZones",
                    "route53:ListResourceRecordSets"
                ],
                "Resource": "*"
            }
        ]
    }

    3. AWS 액세스 키 및 시크릿 키 설정

    • ~/.aws/credentials 파일을 생성하고 아래와 같이 입력:

    [default]
    aws_access_key_id = YOUR_AWS_ACCESS_KEY_ID
    aws_secret_access_key = YOUR_AWS_SECRET_ACCESS_KEY

    2. Certbot Route 53 플러그인 설치

    Certbot이 Route 53을 사용하도록 플러그인을 설치해야 합니다.

    sudo apt install python3-certbot-dns-route53 -y

    3. Certbot을 사용하여 자동화된 인증서 갱신 설정

    기존에 수동으로 발급했던 인증서를 갱신할 때는 다음과 같이 Route 53을 활용하여 자동화할 수 있습니다.

    sudo certbot certonly --dns-route53 \
    -d openhealthcare.com -d *.openhealthcare.com

    이제 Certbot이 자동으로 Route 53에 TXT 레코드를 추가하고 인증을 진행할 것입니다.

    4. 자동 갱신 스케줄링 (crontab)

    Certbot이 자동으로 인증서를 갱신하도록 cron 작업을 추가합니다.

    sudo crontab -e

    다음 줄을 추가하여 매일 새벽 3시에 Certbot이 실행되도록 설정합니다.

    0 3 * * * certbot renew --dns-route53 --quiet

    이제 Route 53을 통한 DNS 인증을 자동화하여 와일드카드 인증서 갱신을 자동으로 수행할 수 있습니다! 🚀

    1. crontab이 잘 작성되었는지 확인하는 방법

    crontab이 정상적으로 등록되었는지 확인하려면 다음 명령어를 실행하세요.

    crontab -l

    위 명령을 실행하면 현재 등록된 crontab 작업들이 출력됩니다. 예를 들어, 다음과 같이 나오면 정상적으로 등록된 것입니다.

    0 3 * * * certbot renew --dns-route53 --quiet

    2. crontab 실행 로그 확인 방법

    crontab이 실행되었는지 확인하려면 syslog 또는 journalctl을 확인할 수 있습니다.

    1) /var/log/syslog에서 실행 내역 확인 (Ubuntu)

    grep CRON /var/log/syslog | grep certbot

    위 명령어를 실행하면 certbot과 관련된 crontab 실행 로그가 출력됩니다.

    2) journalctl로 확인 (systemd 기반 OS)

    journalctl -u cron --since "1 hour ago"

    위 명령어는 최근 1시간 동안의 cron 실행 기록을 확인하는 방법입니다.

    3. crontab이 정상적으로 실행되고 certbot이 실행되었는지 확인

    certbot의 로그 파일을 직접 확인할 수도 있습니다.

    sudo cat /var/log/letsencrypt/letsencrypt.log | grep "renew"

    만약 갱신이 실행되었다면 로그에 관련 정보가 남아 있을 것입니다.

    4. crontab이 실행되지 않는 경우 해결 방법

    ✅ 권한 문제 해결

    일반 사용자 계정이 아닌 root 권한으로 실행해야 하는 경우가 있습니다. sudo crontab -e를 사용하여 root 권한으로 crontab을 수정하면 해결될 수 있습니다.

    ✅ 절대 경로 사용

    crontab은 환경 변수를 로드하지 않기 때문에 certbot의 절대 경로를 사용해야 합니다. which certbot 명령을 실행하여 certbot의 경로를 찾고, 이를 crontab에 반영하세요.

    0 3 * * * /usr/bin/certbot renew --dns-route53 --quiet

    ✅ cron 서비스가 실행 중인지 확인

    cron이 제대로 실행 중인지 확인하려면 다음 명령을 실행하세요.

    sudo systemctl status cron

    만약 inactive (dead) 상태라면 다음 명령어로 다시 시작하세요.

    sudo systemctl start cron
    sudo systemctl enable cron

    5. 테스트 실행

    crontab이 정상적으로 실행되는지 확인하기 위해 다음과 같은 테스트를 해볼 수 있습니다.

    1) 바로 실행되는 테스트 cronjob 추가

    테스트를 위해 1분마다 실행되도록 설정한 후 결과를 확인해 보세요.

    * * * * * echo "Crontab is working" >> /tmp/crontab_test.log

    1~2분 후 다음 명령어를 실행하여 로그가 생성되었는지 확인합니다.

    cat /tmp/crontab_test.log

    2) certbot 갱신을 수동 실행하여 확인

    sudo certbot renew --dry-run

    위 명령어를 실행하여 인증서 갱신이 정상적으로 작동하는지 확인할 수 있습니다.

    ✅ 결론

    1. crontab -l로 등록 여부 확인

    2. grep CRON /var/log/syslog | grep certbot로 실행 로그 확인

    3. sudo certbot renew –dry-run으로 certbot이 정상적으로 작동하는지 확인

    4. sudo systemctl status cron으로 cron 서비스 실행 상태 확인

    5. 절대 경로를 사용하여 crontab을 설정하면 오류 방지 가능

    이제 자동 갱신이 잘 동작하는지 확인할 수 있습니다! 🚀

  • Docker, Nginx, WordPress, Certbot 셋업 – 가난한 개발자의 AWS Free tier 최대활용해서 웹서비스 구축 도전기 – 2

    안녕하세요! 지난 포스팅에서 AWS Free Tier를 활용해 EC2와 RDS를 설정하는 과정을 다뤘는데요. 이번에는 Docker, Nginx, WordPress, 그리고 SSL 인증서 발급까지 한 번에 설정하는 과정을 공유해보려고 합니다. AWS Free Tier에서 최대한 비용을 절감하면서 웹서비스를 구축하는 것이 목표입니다. 😊

    특히, 이번 포스팅에서는 제 도메인 www.azaza.me에 WordPress 블로그를 직접 셋업한 경험을 바탕으로 진행됩니다. 만약 여러분도 저처럼 저렴한 비용으로 블로그를 운영하고 싶다면 도움이 될 거예요!


    1. AWS EC2에 Docker 설치

    먼저 EC2 인스턴스에 Docker를 설치합니다. 현재 EC2에서 운영체제로 Ubuntu 24.04.1을 사용하고 있다고 가정하겠습니다.

    sudo apt update -y
    sudo apt install docker.io -y
    sudo systemctl enable docker
    sudo systemctl start docker
    sudo usermod -aG docker $USER

    설치 후, 현재 쉘에서 로그아웃 후 다시 로그인하면 docker 명령어를 root 권한 없이 사용할 수 있습니다.

    docker --version

    위 명령어로 Docker가 정상적으로 설치되었는지 확인합니다.


    2. Docker Compose 설치

    Docker Compose를 사용하면 여러 컨테이너를 쉽게 관리할 수 있습니다. 다음 명령어를 실행하여 설치합니다.

    sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
    sudo chmod +x /usr/local/bin/docker-compose
    docker-compose --version

    Docker Compose가 정상적으로 설치되었는지 확인하세요.


    3. docker-compose.yml 파일 생성

    SSL 설정되지 않은 초기 버전의 docker-compose.yml은 다음과 같습니다. 이 yml 파일은 SSL 인증서 발급 후 수정이 필요합니다.

    services:
      wordpress:
        image: wordpress:6.7.2-php8.1-fpm-alpine
        container_name: wordpress_fpm
        environment:
          WORDPRESS_DB_HOST: ${WORDPRESS_DB_HOST}
          WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
          WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
          WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
        volumes:
          - ./wp-data:/var/www/html
        deploy:
          resources:
            limits:
              memory: 512M
              cpus: "0.5"
        restart: always
    
      nginx:
        image: nginx:alpine
        container_name: nginx_server
        ports:
          - "80:80"
          - "443:443"
        volumes:
          - ./wp-data:/var/www/html
          - ./nginx-config:/etc/nginx/conf.d
        depends_on:
          - wordpress
        restart: always
      certbot:
        image: certbot/certbot
        container_name: certbot
        volumes:
          - ./certbot/www:/var/www/certbot
          - ./certbot/conf:/etc/letsencrypt
        depends_on:
          - nginx
        command: certonly --webroot --webroot-path=/var/www/certbot --email your@email.address --agree-tos --no-eff-email -d azaza.me -d www.azaza.me

    WORDPRESS_DB_HOST, WORDPRESS_DB_NAME, WORDPRESS_DB_USER, WRODRPESS_DB_PASSWORD 값은 .env에서 관리하면 됩니다.


    4. Nginx 설정 (default.conf)

    아래는 Nginx default.conf 설정 파일입니다. HTTPS는 HTTP 구동을 확인하고 셋업을 진행했습니다. SSL 인증서 발급 후 수정이 필요합니다.

    server {
        listen 80;
        server_name azaza.me www.azaza.me;
    
        location /.well-known/acme-challenge/ {
            root /var/www/certbot;
            allow all;
        }
    
        location / {
            default_type text/plain;
            return 200 "Hello Azaza";
        }
    }

    5. SSl 인증서 발급 받기

    아래 명령어를 실행하여 certbot이 SSL을 발급할 수 있게 합니다. certbot 컨테이너를 실행하면 설정한 volume에 인증서가 마운트됩니다.

    docker-compose up -d

    6. docker-compose.yml nginx 컨테이너 ssl 설정 추가

    먼저 Nginx 컨테이너를 종료시켜 줍니다.

    docker-compose down nginx

    그리고 docker-compose.yml 파일의 Nginx 서비스 블록에 아래 코드를 추가합니다.

    services:
      wordpress:
        image: wordpress:6.7.2-php8.1-fpm-alpine
        container_name: wordpress_fpm
        environment:
          WORDPRESS_DB_HOST: ${WORDPRESS_DB_HOST}
          WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
          WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
          WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
        volumes:
          - ./wp-data:/var/www/html
        deploy:
          resources:
            limits:
              memory: 512M
              cpus: "0.5"
        restart: always
    
      nginx:
        image: nginx:alpine
        container_name: nginx_server
        ports:
          - "80:80"
          - "443:443"
        volumes:
          - ./wp-data:/var/www/html
          - ./certbot/www:/var/www/certbot #추가!!!
          - ./certbot/conf:/etc/letsencrypt #추가!!!
          - ./nginx-config:/etc/nginx/conf.d
        depends_on:
          - wordpress
        restart: always
    
      certbot:
        image: certbot/certbot
        container_name: certbot
        volumes:
          - ./certbot/www:/var/www/certbot
          - ./certbot/conf:/etc/letsencrypt
        depends_on:
          - nginx
        command: certonly --webroot --webroot-path=/var/www/certbot --email seokieys@gmail.com --agree-tos --no-eff-email -d azaza.me -d www.azaza.me

    Nginx volume에 certbot 인증서 관련 파일을 마운트합니다.

    7. nginx conf에 ssl 적용하기

    이제 Nginx에 발급받은 SSL 인증서를 적용하고 http에 대한 호출을 https로 Redirection 설정을 추가합니다.

    server {
        listen 80;
        server_name azaza.me www.azaza.me;
        return 301 https://www.azaza.me$request_uri;
    }
    
    server {
        listen 443 ssl;
        http2 on;
        server_name azaza.me;
    
        ssl_certificate /etc/letsencrypt/live/azaza.me/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/azaza.me/privkey.pem;
    
        location / {
            return 301 https://www.azaza.me$request_uri;
        }
    }
    
    server {
        listen 443 ssl;
        http2 on;
        server_name www.azaza.me;
    
        ssl_certificate /etc/letsencrypt/live/azaza.me/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/azaza.me/privkey.pem;
    
        root /var/www/html;
        index index.php index.html index.htm;
    
        location / {
            try_files $uri $uri/ /index.php?$args;
        }
    
        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass wordpress_fpm:9000;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_keep_conn on;
        }
    
        location ~ /\.ht {
            deny all;
        }
    }

    8. docker 재시작

    다음과 같은 커멘드를 사용하여 docker를 다시 시작하면 모든 설정이 완료되고, 사용하는 워드프레스에 https를 사용할 수 있게 됩니다.

    docker-compose up -d

    6. 마무리

    이제 AWS Free Tier에서 Docker, Nginx, WordPress, 그리고 SSL 인증서까지 적용한 웹 서비스를 구축했습니다. 🎉

    요약

    • EC2에 Docker와 Docker Compose 설치
    • docker-compose.yml을 활용해 WordPress (FPM), Nginx, Certbot 실행
    • Nginx에 80포트로 certbot을 이용한 SSL 인증서 발급
    • docker-compose.yml에 Certbot 인증서를 Nginx에 마운트
    • Nginx default.conf 설정을 통해 HTTPS 리디렉션 및 PHP-FPM 처리 구성

    이 모든 과정은 www.azaza.me 블로그를 직접 운영하면서 겪은 경험을 바탕으로 정리한 것입니다. 지난 포스팅에서는 EC2와 RDS 설정을 다뤘고, 이번에는 WordPress와 관련된 설정을 중점적으로 소개했습니다. 저와 같은 가난한(?) 개발자분들께 유용한 정보가 되었으면 좋겠네요! 앞으로도 AWS Free Tier를 최대한 활용하는 방법을 계속 공유할 예정이니 많은 관심 부탁드립니다! 🚀

  • AWS 기본 구성하기 – 가난한 개발자의 AWS Free tier 최대활용해서 웹서비스 구축 도전기 – 1

    가난한 개발자에게 AWS Free Tier는 그야말로 축복 같은 존재입니다. 무료로 클라우드 인프라를 경험하고, 실제로 서비스까지 구축해볼 수 있는 기회죠. 하지만, 이 Free Tier의 ‘뽕’을 제대로 뽑아보겠다는 마음으로 시작하면 예상치 못한 난관이 곳곳에 도사리고 있습니다.

    AWS는 웹서비스를 쉽게 구축할 수 있는 다양한 옵션을 제공합니다. 그중 Lightsail은 단순한 워드프레스 블로그나 포트폴리오 사이트를 올리기에 적합합니다. 그러나 확장성과 성능 측면에서 한계가 명확하죠. 서비스가 성장하며 트래픽이 늘어날수록 Lightsail은 개발자의 발목을 잡게 됩니다.

    다음으로 떠오르는 선택지는 AWS의 대표 서비스인 **EC2(Elastic Compute Cloud)**입니다. EC2는 웹 서버, 애플리케이션 코드, 데이터베이스(DB), 스토리지 등을 자유롭게 구성할 수 있는 강력한 도구입니다. 그러나 Free Tier의 t2.micro 인스턴스(1 vCPU, 1GB RAM) 하나로 웹 서버와 DB를 함께 돌리는 건 상당히 도전적인 일입니다. 1GB의 메모리는 웹서버와 DB의 동시 실행을 버티기에는 턱없이 부족하죠.

    “그럼 여러 개의 Free Tier EC2 인스턴스를 만들면 되지 않을까?”

    물론 가능합니다. 하지만 AWS는 단순히 ‘무료로 서버 여러 대를 돌려보는 곳’이 아닌, 확장성과 유연성을 고려한 클라우드 인프라 설계를 위한 서비스입니다. 우리는 ‘최소한의 비용으로 최대한 AWS의 강점을 활용할 수 있는 구조’를 고민해야 합니다.


    1. WordPress 구축을 위한 AWS Free Tier 활용 전략

    이 글에서는 AWS Free Tier를 최대한 활용하여 WordPress를 구축한 경험을 공유하려 합니다. WordPress를 설치하고 운영하기 위해서는 다음과 같은 서비스가 필요합니다.

    (1) WordPress 구축에 필요한 주요 구성 요소

    • Nginx – 웹 서버
    • PHP – WordPress 실행 환경
    • WordPress – 콘텐츠 관리 시스템(CMS)
    • MariaDB – 데이터베이스
    • Docker를 설치하여 운영 환경을 구축할 예정

    이러한 서비스를 실행하기 위해 AWS에서 제공하는 Free Tier 리소스를 최대한 활용했습니다.

    (2) AWS Free Tier에서 활용한 서비스

    서비스 이름역할Free Tier 제공량
    EC2웹 서버(Nginx, PHP, WordPress)t3.micro 750시간 (Ubuntu 24.04.1 LTS)
    RDS데이터베이스 (MySQL)db.t3.micro 750시간
    S3정적 파일 저장5GB 저장소
    CloudFront콘텐츠 전송 최적화50GB 데이터 전송 / 200만 요청
    Route 53도메인 관리❌ Free Tier 없음
    ACMSSL 인증서 발급✅ CloudFront와 함께 사용 시 무료

    💡 Route 53은 Free Tier가 제공되지 않지만, 도메인 등록과 DNS 관리가 필요하기 때문에 추가 비용이 발생할 수 있습니다.

    • Route53 기본 호스팅존 : $0.50/월
    • Route53 쿼리 요청 비용: $0.40~0.60/100만 쿼리

    Route53 가격은 위 처럼 상당히 저렴합니다.(Route53 가격 확인하기 🔗) 쿼리가 얼마나 많아질지는 모르겠지만 초기 웹서비스 구축 단계에서는 상당히 저렴할 것으로 생각됩니다.


    2. VPC, EC2 그리고 RDS 시작하기

    그렇다면, 어떻게 설계를 하지? 웹서비스를 구축할 때 가장 먼저 고민해야 할 부분은 네트워크 설계입니다. 특히, 보안과 확장성을 고려한 VPC(가상 사설 클라우드) 구성이 중요합니다.

    (1) VPC 및 Subnet 구성

    먼저, VPC 내부의 Subnet을 어떻게 나눌지 고민했습니다.

    • EC2(Nginx Web Server)Public Subnet에 배치
    • RDS(MariaDB)Private Subnet에 배치

    여기서 중요한 점은 웹 서버(EC2)는 인터넷과 연결되어야 하지만, DB(RDS)는 외부에서 직접 접근할 필요가 없다는 것입니다.

    (2) Internet Gateway 설정

    웹 서버는 인터넷과 통신해야 하므로, Public Subnet을 **Internet Gateway(IGW)**와 연결합니다. 반면, RDS가 위치할 Private Subnet은 외부 네트워크와 직접 연결되지 않도록 구성합니다.

    (3) EC2와 RDS 간 통신

    웹 서버(Nginx)와 데이터베이스(MariaDB)가 정상적으로 통신할 수 있도록 설정해야 합니다. 이를 위해:

    • EC2와 RDS를 같은 Route Table에 연결
    • 두 인스턴스에 같은 보안 그룹(Security Group) 적용
    • EC2의 Shell을 통해서만 RDS에 접근 가능하도록 설정

    이렇게 하면 외부에서는 직접 RDS에 접근할 수 없고, 오직 EC2를 통해서만 데이터베이스에 연결할 수 있는 구조가 됩니다. 즉, 웹 서버가 해킹당해도 DB 자체가 바로 노출되지 않아 보안성을 확보할 수 있습니다.


    3. EC2 Free Tier에서 Docker 설치하기

    (1) EC2 Free Tier에서 Docker, 과연 가능할까?

    다음 단계로 Docker를 활용해 웹 서비스를 구성해보았습니다. 하지만 고민이 하나 있었습니다.

    과연 EC2 Free Tier(t2.micro)에서 Docker가 원활하게 실행될 수 있을까?

    t2.micro 인스턴스는 1 vCPU, 1GB RAM을 제공하는 가장 기본적인 무료 인스턴스입니다. 여기서 Docker를 사용해 Nginx와 WordPress를 컨테이너로 운영하려고 했습니다. 하지만 사양을 고려했을 때 몇 가지 문제점이 예상되었습니다.

    • 메모리 부족: 1GB RAM은 WordPress와 Nginx 컨테이너를 실행하기에 충분하지 않을 가능성이 높음.
    • 응답 지연: 트래픽 증가 시 메모리 부족으로 인해 속도가 느려지고, 컨테이너가 비정상적으로 종료될 가능성 있음.
    • DB 부담 감소: RDS(MariaDB)를 사용해 DB를 EC2에서 분리했지만, 여전히 웹서버의 컴퓨팅 리소스가 부족할 수 있음.

    (2) 해결책: 스왑 메모리 설정!

    메모리 부족 문제를 해결하기 위해 스왑 메모리(Swap Memory) 를 설정했습니다.

    스왑 메모리를 쉽게 설명하면, RAM이 주방 테이블이라면, 스왑 메모리는 냉장고와 같습니다.

    주방 테이블에서 요리 재료를 바로 손질하면 빠르지만, 공간이 한정적이죠. 공간이 부족할 때는 재료를 냉장고에 넣어 두었다가 필요할 때 다시 꺼내서 사용할 수 있습니다.

    마찬가지로, RAM이 부족하면 일부 데이터를 스왑 메모리(디스크)로 옮겼다가 필요할 때 다시 불러오는 방식으로 운영됩니다. 다만, 냉장고에서 재료를 꺼내는 과정이 테이블 위에서 바로 손질하는 것보다 시간이 걸리듯, 스왑 메모리는 RAM보다 속도가 느리다는 단점이 있습니다.

    이런 방식으로 EC2의 부족한 메모리를 보완해 Docker 컨테이너가 안정적으로 실행될 수 있도록 설정했습니다.

    AWS Free Tier에서 제공하는 t2.micro 인스턴스는 기본적으로 8GB의 EBS 스토리지를 제공합니다. 이를 활용해 2GB의 스왑 메모리를 생성했습니다.

    # 2GB 스왑 파일 생성
    sudo fallocate -l 2G /swapfile
    # 권한 변경(보안 설정)
    sudo chmod 600 /swapfile
    # 스왑 활성화
    sudo mkswap /swapfile
    sudo swapon /swapfile
    # 재부팅 후에도 유지되도록 설정
    echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab
    # 스왑 활성화 확인
    free -h

    (3) Docker 설치하기

    이전 단계에서 RAM 부족 문제를 해결하기 위해 스왑 메모리를 설정했습니다. 이제 본격적으로 Docker를 설치해보겠습니다.

    우분투 24.04.1에서는 기본 패키지 관리자(apt)를 통해 Docker를 설치할 수 있습니다. 하지만, 안정적인 운영을 위해 공식 저장소에서 최신 버전의 Docker를 설치하는 방법을 선택했습니다.

    1) 패키지 업데이트 및 의존성 설치

    Docker 설치 전에 시스템 패키지를 최신 상태로 업데이트하고, Docker 실행에 필요한 의존성 패키지를 먼저 설치합니다.

    sudo apt update -y && sudo apt upgrade -y
    sudo apt install -y apt-transport-https ca-certificates curl software-properties-common gnupg

    2) Docker 공식 GPG 키 등록

    Docker의 공식 저장소를 신뢰할 수 있도록 GPG 키를 등록합니다.

    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

    등록된 GPG 키가 정상적으로 추가되었는지 확인하려면 다음 명령어를 실행합니다.

    gpg --show-keys /usr/share/keyrings/docker-archive-keyring.gpg

    3) Docker 공식 저장소 등록

    공식 Docker 패키지를 설치할 수 있도록 Docker 저장소를 시스템에 추가합니다.

    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
      https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list

    4) Docker 엔진 설치

    Docker 엔진 및 관련 패키지를 설치합니다.

    sudo apt update -y
    sudo apt install -y docker-ce docker-ce-cli containerd.io

    5) Docker 서비스 시작 및 자동 실행 등록

    Docker를 설치한 후, 서비스를 시작하고 부팅 시 자동으로 실행되도록 설정합니다.

    sudo systemctl start docker
    sudo systemctl enable docker

    6) Docker 설치 확인

    설치된 Docker의 버전 및 실행 정보를 확인합니다.

    docker --version
    docker info

    7) Docker 권한 설정(루트 권한 없이 실행)

    기본적으로 Docker는 루트(root) 사용자 권한이 필요합니다. 하지만 매번 sudo를 입력하지 않도록, 현재 사용자를 Docker 그룹에 추가하여 일반 사용자 권한으로 실행할 수 있도록 설정합니다.

    # 현재 사용자 확인
    whoami
    
    # docker 그룹에 사용자 추가
    sudo usermod -aG docker $(whoami)
    
    # 변경 사항 반영을 위해 로그아웃 후 재로그인 필요
    exec sudo su -l $(whoami)
    
    # docker 명령어 테스트
    docker ps

    8) Docker Compose 설치

    WordPress를 컨테이너 기반으로 운영하려면 Docker Compose가 필요합니다.

    Docker Compose는 여러 컨테이너를 손쉽게 관리할 수 있도록 도와주는 도구입니다.

    # 최신 버전 설치
    sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" \
      -o /usr/local/bin/docker-compose
    
    # 실행 권한 부여
    sudo chmod +x /usr/local/bin/docker-compose
    
    # 설치 확인
    docker-compose --version

    이것으로 EC2의 설정은 끝났습니다. 이제 RDS를 준비해야합니다.


    4. AWS RDS Free tier로 MariaDB 생성하기

    웹 서비스의 데이터베이스로 Amazon RDS의 MariaDB를 사용합니다. AWS Free Tier를 활용하기 위해 RDS Console에서 데이터베이스를 생성할 때 다음과 같은 설정을 적용했습니다.

    (1) Free Tier 템플릿 선택

    RDS 콘솔에서 “Create database” 버튼을 클릭합니다. Templates 옵션에서 “Free tier” 를 선택하여 무료 사용 혜택을 적용합니다.

    (2)EC2에서만 DB 접근 가능하도록 설정

    보안을 강화하기 위해 데이터베이스가 웹 서버(EC2)에서만 접근 가능하도록 구성합니다.

    • “Connect to an EC2 compute resource” 옵션 선택
    • RDS와 EC2가 동일한 VPC 내에서 안전하게 연결됨

    (3) 외부 접근 차단 (Public Access: No)

    데이터베이스를 외부에서 직접 접근할 수 없도록 설정합니다.

    • “Public access” 옵션을 “No” 로 설정
    • 이 설정을 통해 RDS는 인터넷에서 직접 접속할 수 없으며, EC2에서만 접근 가능

    이제 MariaDB가 안전하게 EC2와 연결되었으며, 외부에서는 접근할 수 없는 구조가 완성되었습니다.

    다음 단계에서는 EC2에서 MariaDB에 연결하고 Docker를 사용하여 WordPress와 연동하는 과정을 살펴보겠습니다! 


    이 모든 것을 Free Tier 내에서 구현하며, 확장성까지 고려한 인프라 설계를 함께 살펴보겠습니다. 무료지만 제대로, 가난하지만 스마트하게 AWS 클라우드 서비스의 진수를 경험해보시죠!

  • 안녕!

    이 블로그는 제 일상, 생각, 그리고 흥미로운 발견들을 기록하기 위해 시작합니다.

    프로그래밍과 IT 프로젝트에서 얻은 경험과 배움, 그리고 가족과 함께하는 소소한 일상을 담아보려 합니다.

    스타트업에서의 도전과 실패, 다양한 프로젝트를 통해 느낀 점들, 글로벌 비즈니스를 위한 열정, 그리고 제 관심사와 고민들을 이곳에 기록하려고 해요.

    이 블로그를 통해 하루하루를 정리하며, 나 자신을 더 깊이 이해하고 싶습니다. 언젠가 이 글들이 가족, 친구, 동료들과 함께 지난 시간을 돌아보는 작은 창이 되기를 기대합니다.

    미래에도 내가 나답게 살아갈 수 있기를 바라며, 첫 페이지를 이렇게 열어봅니다.