te

Macbook M3를 기준으로 작성했습니다.

맥북에 윈도우를 실행하기 위해, LLM을 사용하며 질의응답한 내용을 문서로 정리하여 공유드립니다.

1. Windows ARM ISO 얻기​

하단의 링크에서 윈도우 iso 파일을 준비합니다. Microsoft Windows OS ARM64

2. UTM 설치​

https://mac.getutm.app/

1. UTM 공식 사이트(또는 Mac App Store/공식 릴리스)에서 UTM 앱 다운로드 → 애플리케이션 폴더로 드래그.
2. UTM 실행(보안 경고 나오면 시스템 환경설정 → 보안 및 개인 정보 → 허용).

3. 새 VM 만들기 — 권장 설정 (Step-by-step)​

1. UTM 열고 + Create a New Virtual Machine 클릭.
2. Virtualize 선택 (에뮬레이션 대신 가상화; Apple Hypervisor 사용).
   • 이유: 성능 향상. M3에서는 Virtualize → ARM64 타입으로 진행해야 함.
3. Operating System: Windows 선택.
4. Boot ISO: 앞서 받은 Windows 11 ARM64 ISO 파일을 지정(Attach).
5. System / CPU & Memory
   • CPU: 4 vCPU 이상 권장 (M3이면 4~8 할당 가능).
   • Memory: 8 GB 권장(가능하면 16GB).
6. Drives / Storage
   • New Drive → Disk type: qcow2 또는 raw (qcow2는 스냅샷·공간 효율에서 유리).
   • Size: 최소 64 GB 권장 (개발/툴 설치 고려).
   • 부팅 순서(Boot Order): **CD/DVD(ISO)**가 하드 디스크보다 먼저 오도록 설정(설치 미디어로 부팅해야 하므로).
7. Display
   • Display device: VirtIO GPU (또는 SPICE 관련 드라이버 옵션) 선택.
   • Enable SPICE/Display 기능(UTM UI에 따라 Display 추가).
   • 이 항목을 빠뜨리면 “Display output is not active” 같은 메시지가 뜰 수 있음 — 반드시 추가.
8. Network
   • NIC: virtio-net-pci (Shared Network / NAT) 선택 — 인터넷 연결 위해.
9. Sound / USB: 필요하면 추가(선택).
10. Advanced: QEMU arguments나 기타를 건들 필요는 없음(고급 사용자용).

저장 후 VM 생성 완료.

4. VM 시작 및 Windows 설치​

1. 생성한 VM 선택 → ▶ Start.
2. 부팅 시 Windows 설치 화면이 뜨면 평소대로 파티션 선택 → Windows 설치 진행.
   • 설치 중 드라이버 오류가 나면 UTM에서 virtio 드라이버/guest tools를 마운트해서 설치해야 함(아래 참고).
3. 설치가 끝나고 재부팅되면 Windows ARM 환경으로 진입.

5. 필수 게스트 도구(성능/통합 향상)​

설치 직후 아래 항목을 설치하면 그래픽, 네트워크, 커서/클립보드 공유 등이 정상 동작한다.

1. SPICE Guest Tools (Windows용)
   • SPICE 툴은 클립보드 공유, 개선된 그래픽/커서, 드래그 앤 드롭 등을 도와줌.
   • UTM에서는 보통 Spice Guest Tools 또는 SPICE 패키지를 mounting 옵션으로 제공하거나, 외부에서 설치 파일을 얻어 VM 내부에서 실행.
2. QEMU Guest Agent / VirtIO 드라이버
   • 네트워크(virtio-net), 블록 드라이버(virtio-blk), GPU(virtio-gpu) 등 드라이버가 빠지면 네트워크 안 되거나 성능 저하 발생.
   • UTM에서 제공하는 virtio ISO를 VM에 마운트한 다음 Windows에서 드라이버 설치(장치관리자 → 드라이버 업데이트 → ISO 경로 지정)하여 적용.

네트워크(virtio-net), 블록 드라이버(virtio-blk), GPU(virtio-gpu) 등 드라이버가 빠지면 네트워크 안 되거나 성능 저하 발생.

설치 방법: UTM VM 설정 → Drives → New Drive → Import 또는 Attach에서 SPICE/virtio ISO 선택 → Windows 내부 탐색기에서 실행(.exe) / 장치관리자에서 수동 설치.

6. 권장 리소스/설정 (성능·안정성)​

• CPU: min 4 vCPU, 권장 6~8(여유 메모리 대비)
• Memory: 8~16 GB
• Disk: 64GB 이상, 가능하면 qcow2
• Network: Shared (NAT)으로 설정 후 내부 Windows에서 인터넷 작동 여부 확인
• 스냅샷: 중요한 변경 전 스냅샷(또는 VM 파일 백업) 권장

7. 라이선스 & Windows 업데이트​

• Insider Preview는 제한된 기간 동안 무료로 사용 가능하지만, 정식 라이선스 정책은 MS 정책 따름.
• Windows Update 통해 최신 드라이버·보안 업데이트 적용.

XAMPP 와 HeidiSQL를 사용해야 하는 강의를 들었는데, VM 리눅스 환경과 호환이 좋지 않았습니다. 여러 차례 vm 재설치, 리눅스 재설치 등 삽질을 좀 했습니다. 실습 환경을 그대로 재현하는 건 빠르게 포기하고, debian-linux에서 강의에서 봤던 것과 유사한
AMP 웹 서버 환경 구성과 데이터베이스 관리 툴 dbeaver 을 사용하는 방법을 기록합니다.

❓LAMP Stack (Linux + Apache + MySQL + PHP)

LAMP 스택은 개발자가 웹 사이트와 웹 애플리케이션을 빌드하는 데 사용하는 4가지 소프트웨어 기술의 번들입니다. LAMP는 Linux(운영 체제), Apache(웹 서버), MySQL(데이터베이스 서버), PHP(프로그래밍 언어)의 두문자어입니다. 이 4가지 기술 모두 오픈 소스이므로 커뮤니티에서 유지 관리되며 누구나 무료로 사용할 수 있습니다. 개발자는 LAMP 스택을 사용하여 웹 콘텐츠를 생성, 호스팅 및 유지 관리합니다. LAMP 스택은 오늘날 일반적으로 사용하는 많은 웹 사이트를 지원하는 널리 사용되는 솔루션입니다.

https://aws.amazon.com/ko/what-is/lamp-stack/

Environment​

VM : VMware Fusion OS : Kali Linux debian-12-arm

uname -a
Linux kali-blue 6.12.38+kali-arm64 
#1 SMP Kali 6.12.38-1kali1 (2025-08-12) aarch64 GNU/Linux

1. install devilbox​

xampp를 대체할 오픈 소스 프로젝트 devilbox 를 VM에 설치했습니다. 설치 방법은 레포 README에 잘 설명되어 있습니다.

https://github.com/cytopia/devilbox

# devilbox kali linux에 설치
git clone https://github.com/cytopia/devilbox 
cd devilbox
cp env-example .env # 환경 변수는 공유하면 안됩니다

devilbox는 도커 컴포즈에서 실행됩니다.

칼리 리눅스에 docker와 docker-compose를 우선 설치해야 합니다.

sudo apt install docker.io

docker 와 docker compose 를 모두 설치했다고 가정하고,
devilbox 를 실행합니다:

docker compose up httpd php mysql

devilbox 를 사용한 이유는 :

1. xampp 를 대체할 만한 오픈 소스를 찾고 있었고,

2. devilbox 로 LAMP 개발 환경을 만들어보고 싶었고,

3. (칼리) 리눅스와 도커를 익히기에도 좋을 것 같았습니다.

4. 격리된 컨테이너 단위로 취약점 테스트를 수행하는 것이 좋지 않을까 싶었습니다.

패키지 설치 도중에 VM 디스크 공간이 부족해
시스템 부하가 걸린 순간이 몇번 있었는데, 용량을 늘려 gparted로 할당도 해보고
df -h , du -sh /* 로 용량도 확인하면서 리눅스 fs를 여러 면으로 탐색했습니다.

VM에서 메모리가 부족하여 docker compose up 을 했더니

도커 이미지 pulling과정에서 시스템이 다운되었습니다 😅

로컬호스트에 설치된 devilbox를 확인할 수 있습니다.

다음으로 dbeaver 를 설치하도록 하겠습니다. snap 패키지 설치 이후 다음 명령어로 쉽게 다운받을 수 있습니다.

sudo snap install dbeaver-ce

.deb 인스톨러 설치 방법은 아래와 같습니다.

https://dbeaver.io/download/

.deb 파일이 다운됩니다. 이 파일에 적절한 권한 설정을 해준 뒤 루트 권한으로 설치파일을 apt 대신 dpkg로 실행합니다. 이 부분을 잘 몰라서 시간 소요가 조금 있었습니다.

sudo chmod +x ./dbeaver-{version}-installer.deb
dpkg -i ./dbeaver-{v}-installer.deb

❓dpkg

dpkg와 apt 차이가 궁금해서 검색한 내용을 정리합니다.

• dpkg: .deb 파일을 직접 설치/삭제하는 저수준(low-level) 패키지 관리 도구

  • .deb 파일을 설치 및 삭제하는 기본 도구
  • 로컬에 있는 .deb 파일만 설치 가능
  • 의존성 문제 자동으로 해결하지 못함

• apt: dpkg의 기능을 활용하며 의존성 문제를 자동으로 해결하고 원격 저장소에서 패키지를 다운로드하는 고수준(high-level) 도구

  • dpkg를 기반으로 작동하는 고수준 도구
  • 원격 저장소에서 패키지를 자동으로 다운로드 및 설치 가능
  • 의존성 문제 자동으로 해결함

• 일반적으로 더 편리한 apt를 사용하고, dpkg는 특정 상황에서 사용

npm vs yarn 같은 패키지 매니저 비교로 이해하니 한결 수월합니다. 개인적으로 apt , dpkg 명령어를 잘 모르고 사용하면서 의존성 문제가 많이 생겼던 것 같습니다.

다운로드 완료 이후, 명령어dbeaver 를 입력하면, 브라우저로 DBeaver 웹 UI가 실행됩니다.

xamppp 의 데이터베이스 조회/조작과 거의 동일한 기능을 제공합니다.

이제 상단의 메뉴바에서 Database > Connect를 실행하여 로컬 MySQL과 연결합니다.

사실 devilbox 에도 myAdminPHP 웹 UI를 제공합니다. 여기에서 데이터베이스를 조회/조작할 수 있습니다.

KT Cloud TECHUP 사이버 보안 과정의 첫 팀 프로젝트로 오픈 소스 파이썬 라이브러리를 개발했습니다.

프로젝트 개요​

결과 링크:

• s2n Github
• PyPi S2N
• Docker Hub - opens2n/s2n-docker

팀 구성:

• 5인으로 이루어진 팀이며, 제가 리드 역할을 맡았습니다.
• 2명의 컴퓨터 관련 전공자와 저를 포함한 3명의 비전공자로 구성됐습니다.
  • 비전공자 팀원 두 분에겐 첫 개발 프로젝트였습니다.

프로젝트 기간:

• 총 5주
• Sprint 1 : 2025/11/03 ~ 2025/11/16
• Sprint 2 : 2025/11/17 ~ 2025/12/01

역할

각 팀원의 관심사와 목표에 따라 스프린트 별로 내부 팀을 나누었습니다.

• Sprint 1: 인프라팀 / 코어팀
• Sprint 2: 라이브러리팀 / 클라우드팀

저는 인프라-라이브러리 팀에 속하였으나,
팀 리드로서 팀 서포트 및 여러 일을 맡았습니다.

s2n 취약점 스캐너 라이브러리​

소개​

s2n은 파이썬 오픈소스 취약점 스캐너입니다.

• PyPi에 등록 및 배포가 되어있어, 파이썬 환경에서 패키지를 다운받아 실행할 수 있습니다.
• CLI 기능을 제공하여 파이썬과 여러 환경에서 실행 가능합니다.
  • Docker 이미지 또한 배포되어 있어, 컨테이너 환경에서도 실행할 수 있습니다.
• XSS, CSRF, SQL Injection 등 7종의 주요 공격 기법 취약성을 스캔할 수 있습니다.
• 타겟 URL을 입력하여 취약점을 스캔합니다.
  • DAST 방식으로 런타임 취약점을 점검합니다.
• 스캔 대상에 실질적인 피해를 주지 않는 안전한 방식을 고려했습니다.
• 스캔 결과를 JSON, HTML로 Export하거나 콘솔을 출력할 수 있습니다.

기여​

s2n을 개발하면서 제가 기여한 부분은 다음과 같습니다:

• 시스템 설계 및 주요 인터페이스 개발
• CSRF 플러그인 개발 및 플러그인 전반 코드 컨벤션 적용하여 리팩터링
• 스캔 엔진 인증 모듈, CLI 인터페이스 개선 및 유지보수
• 플러그인 전반의 Pytest 작성 및 conftest로 공용 모킹 모듈 작성
• 배포 파이프라인에 테스트 적용 및 유지보수
• CI/CD 배포 파이프라인 개발 및 유지보수
• Docker Image 개발 및 자동 배포 환경 구축
  • dev : Github Container Registry 배포 (s2n:dev)
  • main : Docker Hub 퍼블릭 레지스트리 배포 (opens2n/s2n-docker:latest)

작업 PR​

시스템 설계 및 동작 원리​

위 설계도는 s2n의 전체 구조를 한눈에 보여주는 시스템 아키텍처입니다.

1. 사용자가 CLI 혹은 코드 레벨에서 Scanner 객체를 호출하여 인자를 입력하고
2. 스캐너가 입력을 받아 플러그인을 통해 분석을 수행한 뒤
3. 리포트를 출력하기까지의 흐름을 중심으로 구성했습니다.

• 코드 레벨과 CI/CD 환경에서 실행될 수 있도록 CLI 인터페이스까지 설계 단계에서 고려했습니다.
• 동적 분석(DAST)을 기반으로, 실행 흐름에서 생성되는 request 인스턴스를 공용 모듈이 중앙에서 관리하도록 설계했습니다. 이를 통해 세션과 인증을 일관되게 처리할 수 있도록 구조를 정리했습니다.

가장 바깥에는 사용자가 진입하는 Entry Point가 있습니다. CLI에서 URL과 설정, 플러그인을 직접 지정하거나, Python 패키지로 Scanner 클래스를 불러와 사용할 수 있습니다.

입력된 요청은 Core System을 통해 처리됩니다. 코어 영역은 스캐너의 핵심 로직이 모여 있는 부분으로, 설정 관리, 인증 처리, 로깅, HTTP 요청 관리, 크롤링, 세션 유지 등
실제 스캐닝 과정에 필요한 공통 기능이 모두 이 계층에 포함됩니다. 스캔 과정 중 발생하는 집계, 에러, 인증, 세션 관리 등의 처리가 이 코어 시스템을 통해 조율됩니다.

실제 취약점 탐지는 Plugin System에서 이루어집니다.

플러그인 매니저가 필요한 플러그인을 로드하고 실행 파이프라인을 구성하면, SQL Injection, XSS, CSRF 등을 포함한 다양한 플러그인이 타겟 URL에 대해 검사를 수행합니다. 설계 초기부터 확장 가능한 구조를 염두하여,새로운 플러그인을 추가하는 것이 가능하게끔 개발했습니다.

스캔 과정에서 발생할 수 있는 오류들은 Error Handling 시스템에서 통합적으로 다룹니다. 네트워크 오류, 인증 문제, 플러그인 실행 오류 등을 분류하고 적절히 대응하여 스캐너 전체가 중단되지 않고 동작하도록 했습니다.

최종적으로 결과는 Reporting System에서 다양한 형식으로 출력됩니다. JSON, HTML, 콘솔 출력, CSV 등 사용 목적에 맞추어 결과를 가공하며, 특히 HTML 리포트는 대시보드 형태로 시각적 확인이 가능합니다.

팀 협업​

팀원 과반이 프로젝트 경험이 부족하였기에, 자연스럽게 리드를 맡게 되었습니다.
사실 어떤 직함이나 역할을 갖고 리드 역할을 한 것은 처음이었기에, 꽤 도전적인 경험이었습니다.
(프로젝트를 진행하면서, 전직장에서 FE 챕터 리드님이 고생하시던 모습이 자주 떠올랐습니다.)

팀을 리드하면서 스스로 지키자고 세웠던 원칙은 다음과 같습니다:

• 경험이 더 있다고 팀원들에게 오만하게 굴지 말것
• 과정과 결과를 기록할 것
• 누구든 자유롭게 의견을 낼 수 있도록 할 것
• 나를 포함한 한 사람의 의견에 프로젝트가 좌우되게 하지 않을 것
• 팀 전원이 하고 싶은 일을 하도록 조율할 것
• 모르는 부분이 있으면 누구나 질문하고, 성실히 답할 것
• 즐거운 분위기를 유지할 것

혼자서 오랫동안 취업 준비를 해서 그런지, 다양한 배경의 팀원들과 함께하여 무척 즐거웠습니다.
이번 프로젝트를 통해 개발을 처음 시작할 때의 열정이 떠올라 보람찼습니다.

노션 기록과 문서화​

현직에 있을 때도 결과와 과정의 문서화를 중시하던 편이라,
팀원 모두에게 문서 기반으로 작업하도록 요청하였습니다.

Github PR​

오픈 소스를 만드는 프로젝트이기에, Git과 Github 활용이 중요했습니다. 이번 기회에 깃 관련 경험이 적은 팀원들 위해 매뉴얼 작성과 간단한 세션을 진행했습니다.
결과적으로, 팀원 전원이 PR을 1회 이상 작성하였고, 브랜치를 병합했습니다.

바쁘게 작업을 하다보면 일일히 회고를 작성하기 어렵습니다.
PR 단위로 작업을 한 뒤, 문서를 작성하여 작업 이력을 활용할 수 있습니다.
팀 규칙으로 PR 작성을 ruleset으로 정하였고, PR 템플릿을 작성했습니다.

프로젝트 초기에 브랜치 전략을 실제 업무 현장처럼 다소 복잡하게 구성했는데,
추후 4시간동안 꼬인 커밋을 리베이스로 정리하면서 후회도 했습니다.
하지만 고생한만큼 반복하여 발생하던 깃 충돌 문제를 해결할 수 있었습니다.
이후 깃 브랜치 전략을 main - dev - 작업 브랜치 3단계로 단순화하였습니다.

트러블 슈팅 및 기술적 도전​

Github s2n PR 리스트

작업의 모든 과정을 PR로 기록했습니다.
pull_request_template.md를 작성하여 팀원 전원이 자신이 올린 PR을 설명하도록 팀 규칙을 정했습니다. 개발 과정에서 기억에 남고 학습이 되었던 PR 내용을 간략히 설명하면 다음과 같습니다.

일관된 개발 환경 구축​

• https://github.com/s2n0n/s2n/pull/43
• https://github.com/s2n0n/s2n/pull/4

파이썬 경험도 많지 않고, 도커 또한 경험이 많지 않았기에 서툴렀던 점이 많았습니다.
스스로 학습도 해가며, 팀원들에게 도움이 되도록 PR문서에 매뉴얼도 함께 작성했습니다.

1. Python 버전 및 .venv 통합 (PR #43) 팀원별 Python 버전이 달라 실행 오류가 발생하던 문제를 해결하기 위해 Python 3.11.14 + 통일된 가상환경(.venv) 기반의 개발 환경을 표준화했습니다.

• 모든 팀원이 pyenv로 동일한 버전을 설치하도록 매뉴얼화
• setup_venv 스크립트를 통해 한 번에 .venv 생성 및 활성화
• 코드 에디터(vscode, PyCharm 등)의 프로젝트 전역 Python 경로를 .envs/python/.venv로 통합
• .gitignore를 정리하고 불필요한 항목 제거, 환경 관련 폴더만 정확히 제외하도록 구조 개선
• 추가로 학습 내용에 대해 글 작성 뒤 팀원들에게 공유 : venv 학습 문서

팀 리드로서 프로젝트 초반에 신경써야할 부분이었지만, 뒤늦게라도 작업하여 반복된 (주로 린트) 문제를 해결할 수 있었습니다.

2. 로컬 DVWA 환경 구축 (PR #4) 보안 스캐너를 테스트하기 위한 DVWA(Local Damn Vulnerable Web App) 환경을 직접 구성했습니다. Docker 기반으로 누구나 동일한 환경에서 취약점 스캔 실험을 할 수 있도록 설계했습니다.

• .envs/dev 경로에 DVWA용 docker-compose.yml, Dockerfile 작성
• 실행/중지를 위한 스크립트(run_dvwa.sh, stop_dvwa.sh)를 개발
• .env.dev 파일을 이용해 팀원 간 환경 변수를 통일
• 팀원들은 bash run_dvwa.sh 한 번으로 DVWA를 실행하고, 동일 주소에서 테스트 가능

이 작업을 통해 팀 전체가 동일한 취약점 테스트 환경을 공유할 수 있게 되었습니다.

Docker Image 멀티 플랫폼​

이미지 배포 이후, Vagrant로 linux debian을 실행하였는데, 다음과 같은 에러가 났습니다.

PR-93 링크

에러 원인을 확인해보니, 컨테이너 이미지를 단일 아키텍처(ARM)에서만 제공할 경우, AMD에서 실행할 수 없다는 문제가 있었습니다. 이를 해결하기 위해서 배포 스크립트의 docker 이미지 빌드 단계를 수정했습니다. (자세한 내용은 위의 PR 링크에 기록했습니다.) docker buildx를 활용하여 멀티 플랫폼 이미지를 자동으로 빌드하도록 CI/CD 파이프라인을 개선하는 작업이었습니다.

기여한 내용은 다음과 같습니다:

• GitHub Actions 워크플로우에 setup-buildx-action을 추가하여 멀티 아키텍처 빌드 환경 구성
• linux/amd64, linux/arm64 대상 이미지 빌드 및 Docker Hub로 자동 푸시 설정
• Dockerfile을 멀티 스테이지로 개선하여 이미지 크기 최적화
• 이미지 실행 시 Python 의존성이 정상적으로 동작하도록 런타임 환경 검증

이 과정을 통해 팀원들 모두 M1/M2 환경에서도 문제 없이 s2n을 실행할 수 있게 되었고, 프로젝트의 배포 범위와 활용성을 크게 늘린 의미 있는 작업이었습니다.

신경쓰지 못한 부분이었는데, 실제 사용을 해보면서 알 수 있어 좋았습니다.

Pytest​

PR-83 링크

프로젝트가 커질수록 수동 테스트만으로는 기능 안정성을 보장하기 어려웠습니다. 이에 pytest 기반의 자동 테스트 환경을 구축하여 플러그인 동작과 핵심 스캐너 로직을 검증할 수 있도록 했습니다. 이 과정에서 코드 전반에 일정한 패턴을 적용하도록 리팩터링을 함께 진행했습니다.

주요 작업 내용은 다음과 같습니다:

• 프로젝트 구조에 맞춰 tests/ 디렉토리 구성 및 기본 테스트 스켈레톤 작성
• 스캐너 핵심 엔진, 유틸리티 함수, 플러그인 로딩 로직 테스트 케이스 구현
• Mocking을 활용해 HTTP 요청/응답을 가짜 객체로 처리하여 안전하게 테스트하도록 구성
• CLI 실행 결과를 캡처하여 정상적으로 출력되는지 검증하는 테스트 추가
• GitHub Actions에서 pytest가 자동 실행되도록 CI 통합

긴 글 읽어주셔서 감사합니다!

VMware Fusion의 GUI로 매번 칼리 리눅스를 실행하는게 번거로워,
Vagrant를 통해 CLI로 칼리 리눅스를 실행해보고자 합니다.

Mac M3 Sequoia 최신 버전을 기준으로 작성했습니다.

Vagrant​

Vagrant는 가상 머신(VM)을 생성하고 관리하는 하이퍼바이저^Hypervisor를 사용하여 개발 환경을 자동화 및 관리해주는 도구입니다. 관련 글
VM 실행 환경을 Ruby 파일로 설정하고, vagrant ssh로 vm 환경과 터미널로 연결하여 사용할 수 있습니다. 사용 목적은 개인적으로 Kali Linux에서 거의 대부분 작업을 CLI로 하고 있어 번거롭게 느껴진 부분이 많았기 때문입니다.

Steps​

1단계​

사전 준비

VMware Fusion 설치: VMWare Fusion을 다운로드 받아 설치합니다.

• Rosetta 설치 (Mac ARM 환경): M1/M2/M3 등 ARM 기반 Mac의 경우, Rosetta를 먼저 설치해야 합니다.

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

• Vagrant 설치: Homebrew를 사용하여 Vagrant를 설치합니다.

brew install vagrant

• vagrant-vmware-utility: vmware fusion을 vagrant에서 실행하기 위해 필요합니다.
• Vagrant-vmware-desktop 플러그인 설치: Vagrant와 VMware를 연결하기 위한 플러그인을 설치합니다.

brew install --cask vagrant-vmware-utility
vagrant plugin install vagrant-vmware-desktop 

2단계​

Vagrant 설정 및 실행

VMware Fusion 실행: 처음 실행 시 시스템 설정에서 VMware를 허용해야 할 수 있습니다.

Vagrantfile 생성: Vagrantfile은 가상 머신의 설정 파일로, Ruby로 작성됩니다. 프로젝트 디렉토리에서 vagrant init 명령어로 생성합니다. 아래 명령어로 Kali Linux 전용의 Vagrantfile을 생성합니다.

vagrant init kalilinux/rolling

Box 지정: Vagrantfile에서 사용할 운영체제 이미지를 지정합니다. 가상 머신 생성 및 실행: vagrant up 명령어를 실행하여 가상 머신을 생성하고 시작합니다. 이후 SSH 접속 vagrant ssh 명령어로 생성된 가상 머신에 접속할 수 있습니다

vagrant up
vagrant ssh

vagrant up으로 kalilinux/vagrant.box를 받는 것이 생각보다 오래 걸립니다. vagrant 실행이 완료되면, VM Fusion이 열립니다.

이 문서는 팀 프로젝트에서 AWS 협업 과정을 기록하기 위해 작성했습니다.

• AWS 클라우드 환경을 IaC 기반으로 구축하기 위한 CI/CD 파이프라인을 설계를 다룹니다.

프로젝트 개요 Project Overview​

AWS 클라우드 구축: EC2 서버앱 + RDS + S3 + Cloudformation

두번째 스프린트에서 프로젝트 목적은 클라우드 보안 체계 및 시스템 수립이었습니다.
프로젝트 기간이 많이 남지 않아 Web Socket을 이용한 간단한 실시간 채팅앱을 MVP로 목표했으며,
학습 목적을 고려해 (채팅앱에는 일반적이진 않은) 여러 AWS 기능을 구성했습니다.

• Region : 서울 Seoul (ap-northeast-2)
• IAM: 1개의 루트 계정과 각 팀원들에게 적절한 IAM 권한을 설정했습니다. (MFA를 사용합니다.)
• VPC: Public Subnet과 Private Subnet으로 나누어 외부에 노출되어선 안될 기능을 프라이빗 서브넷에 두었습니다.
  • ACL: 보안을 위한 적절한 ACLAccess Control List과 보안 그룹 Security Group(sg)을 설정했습니다.
• Route 53: DNS로 상용 중인 AWS 인스턴스를 라우팅하기 위해 사용했습니다.
• EC2: t3.micro, Python/Flask로 빌드된 서버앱을 배포하기 위해 사용했습니다.
  • Docker: 브랜치 병합 시 Github Actions 환경의 CI 단계에서 파이썬 앱을 도커 이미지로 빌드한 뒤, Github Container Registry에 배포합니다.
  • EC2-Runner: 이미지 배포가 끝난 뒤, 새 버전의 이미지를 pull하여 새로운 컨테이너로 교체합니다.
• RDS: MySQL 데이터베이스로 채팅 메타데이터, 세션 등을 저장합니다.
  • AWS 튜토리얼에도 명시되었듯이, 일반적으로 실시간 기능에는 DynamoDB, Lambda, Firehose 등을 조합하여 사용합니다. 이번 프로젝트에선 파이썬 Flask을 학습하고, EC2에서 컨테이너를 활용하기 위해 사용했습니다.
• Application Load Balancer: 분산할 만큼 큰 트래픽은 없지만, 학습 목적을 위해 추가했습니다. Cloudwatch, S3와 연동하여 로그 수집을 하고 있습니다.
• Cloudformation: Cloudwatch 기능으로부터 AWS 경고 이벤트 알람 기능과 S3 로그 저장 및 다양한 기능을 코드Infra As Code로 관리하기 위해 사용했습니다.
• Cloudwatch: 로그 수집, 실시간 보안 및 장애 이벤트에 대응하기 위해 사용했습니다.
• S3: 웹앱의 프론트엔드 배포와 로그를 수집하여 저장하기 위해 사용했습니다.

현재 구성된 AWS의 간략한 유저 플로우와 기능들을 다이어그램으로 표현하면 다음과 같습니다.

시스템 다이어그램 System Diagram​

배포 파이프라인 설계​

클라우드 구성과 웹앱/DB 등 배포를 진행하면서 여러 작업자들이 영향도Effect가 있는 작업을 진행하면서, 간단한 프로젝트임에도 복잡도가 크게 상승하는 것이 느껴졌습니다.

이러한 문제 상황의 근본 원인은 Git과 같은 형상 관리 없이, AWS 웹 콘솔 대시보드에서 작업이 분산되고 트래킹 없기 때문이 아닐까 생각이 들었습니다.

이에 대한 해결책으로 Github Repo와 클라우드 구성을 코드로 연동하자고 제안하였습니다.
사실 저를 포함한 팀원 다수가 AWS에 대해 경험이 부족한 상태였고, 제가 그나마 기여할 수 있는 것이 Github Actions로 CI/CD 파이프라인을 개발하는 것이라는 생각이 들어, 이 작업을 담당하게 되었습니다.

팀원들의 이해를 돕기 위해, 현재 프로젝트 레포와 AWS를 연동하기 위한 배포 파이프라인 설계도를 먼저 작성했습니다.

Github Project Repo 구성​

aws-web-app
  ├── backend // 파이썬 백엔드 앱
  ├── cloudformation // cloudwatch 구성 yaml
  ├── db_schema // rds 스키마
  ├── frontend // s3에 배포될 프론트엔드 코드
  │   ├── public
  │   └── src
  ├── lambda // 파이썬 코드로 이루어진 람다 함수
  └── scripts // aws ec2에서 실행되는 쉘 스크립트

Github Actions​

AWS 설정을 코드로 관리하기 위한 Github Actions CI/CD 파이프라인의 순서도를 작성했습니다.

해당 배포 파이프라인은 팀원과 협업으로 이룰 수 있었습니다. 이 과정에서 코드 리뷰를 진행하였고, 팀원들 모두 학습할 수 있도록 협업하였습니다.

성과 Accomplishment​

새롭게 배운 내용과 협업에서 느낀 점이 많았습니다. 간단히 정리하자면 다음과 같습니다:

• AWS 배포 파이프라인 설계 및 개발과 IaC의 필요성을 절감할 수 있었습니다.
  • 여러 작업자가 Session Manager, 웹 UI 대시보드, ssh 연결 등으로 작업하면서 변동사항의 트래킹이 어려운 점을 절감했습니다.
  • 설정 오류 등으로 장애 발생 시 원인을 파악하는 것이 무척 까다롭게 느껴졌기 때문에, Github과 연동을 신경썼습니다.
• 문서화의 중요성을 느꼈습니다. 코드의 형상 관리 차원과 함께, 추상적이고 난이도가 높을 수 있는 클라우드 개발을 협업하는데 있어 문서와 아키텍처 설계도가 큰 도움이 되었습니다.