Visual Studio Code(이하 VSCode)는 강력한 코드 편집기이자 다양한 확장 기능과 커스터마이징을 제공하는 도구입니다. 맥북 사용자라면 생산성을 높이기 위해 필수로 익혀야 할 단축키들이 있습니다. 이 글에서는 VSCode를 맥북에서 사용할 때 유용한 단축키들을 범주별로 정리하여 소개합니다.

📁 파일 탐색 및 기본 조작

📝 편집 관련 단축키

🔍 탐색 및 검색

📦 터미널 및 기타

💡 팁

• VSCode는 단축키 커스터마이징이 가능하므로 자주 사용하는 기능은 자신에게 맞게 바꾸는 것도 좋은 방법입니다.
• Cmd + P를 통해 빠르게 파일을 검색할 수 있습니다.
• Cmd + Shift + E로 탐색기 열기, Cmd + Shift + D로 디버깅 창을 여는 것도 유용합니다.

📚 참고: VSCode 공식 단축키 리스트 (macOS)

.gitignore : 사전 방지

이렇게 작성해 두면 커밋에서 파일들은 무시됩니다. 만약 경로 아래에 있는 파일들 전체를 무시하길 원한다면, 루트 기준 해당 파일 경로를 작성해 주면 됩니다.

/파일이름/

# 예시
/config/

하지만 이미 커밋해버린 상황...

브랜치를 들여다 보면 아래처럼 이미 쏙쏙 박혀있는 경우가 있죠

보통 이런 건 한 커밋에만 있는 게 아니죠, 그 전 커밋... 그 이후 커밋... 다 있어요.

해결 방법

1. 현재 파일 백업 (선택)

   # 새로 클론 받아두기
   git clone https://github.com/your-github/your-repository.git your-repository-clean
   cd your-repository-clean
   

새로 브랜치 백업

git checkout main #또는 대상 브랜치 git branch backup-before-config-clean

2. git-filter-repo 설치
```bash
pip install git-filter-repo

3. 레포지토리 클린업

   # 맞는 프로젝트인지 경로 확인 후 작업 your-repo-clean
   git filter-repo --path 해당-폴더-이름/ --invert-paths

   --path 파일이름/ : 경로 디렉터리 안에 있는 모든 파일을 대상으로 함 --invert-paths :해당 경로만 제거하고 나머지는 유지함

4. 강제 푸시

   git push origin --force --all
   git push origin --force --tags

5. .gitignore에 추가

   /디렉토리/

번외) 지금 디렉토리에서 강제 실행

git filter-repo --force --path config/ --invert-paths

• 히스토리 손상 가능성 있음 : 백업 꼭 하고 진행할 것

살아나세요 용사여

1. VPC

Virtual Private Cloud

AWS 상에서 내가 원하는 네트워크 구조를 직접 설계하고, 격리된 공간에서 운영할 수 있도록 해주는 서비스

핵심 개념

• AWS 리전 내에서 내가 정의한 IP 대역(CIDR 블록)을 기준으로 구성
• 서브넷, 라우팅 테이블, 보안 그룹, 인터넷 게이트웨이, NAT 등 다양한 네트워크 구성 요소 포함
• 온프레미스와 연결(VPN/Direct Connect) 하거나, 다중 계정 연결(Transit Gateway) 도 가능

예시

VPC (10.0.0.0/16)
├── Subnet A (10.0.1.0/24)
└── Subnet B (10.0.2.0/24)

2. 서브넷

VPC 안에서 IP 주소 범위를 작게 나누는 단위

왜 나눌까

• 서로 다른 용도의 리소스를 격리
• 퍼블릭/프라이빗 서브넷 구분을 통해 보안 계층 구성
• 고가용성(HA)을 위해 여러 AZ(가용영역)에 분산 가능

퍼블릭/프라이빗 구분 기준

• 퍼블릭 서브넷: 인터넷 게이트웨이(IGW)에 연결된 서브넷
• 프라이빗 서브넷: IGW와 연결되지 않음. 대신 NAT Gateway를 통해 외부와 통신

3. 퍼블릭 vs 프라이빗 서브넷 상세 비교

퍼블릭은 외부에서 접속 가능한 리소스가 위치

프라이빗은 외부에서는 접근 불가, 내부 서비스 전용

4. NAT Gateway

프라이빗 서브넷에 있는 리소스가 외부로 나가는 통로

왜 필요한가?

• 프라이빗 서브넷에 있는 EC2 인스턴스나 Lambda가 외부 API 호출, 소프트웨어 업데이트, S3 접근 등 인터넷 연결이 필요한 경우가 많음
• 보안을 위해 직접 인터넷 게이트웨이를 연결하지는 않음
• 이때 NAT Gateway를 경유해 외부로 나갈 수 있음

핵심 특징

5. 실전 구조 예시: 3-Tier 아키텍처

📦 VPC (10.0.0.0/16)
├── 🌐 퍼블릭 서브넷 (10.0.1.0/24)
│ ├── EC2 웹 서버
│ └── 인터넷 게이트웨이 (IGW)
│
├── 🔒 프라이빗 서브넷 (10.0.2.0/24)
│ ├── EC2 백엔드 서버
│ └── NAT Gateway 연결
│
├── 🔐 프라이빗 서브넷 (10.0.3.0/24)
│ └── RDS DB 인스턴스

• 웹 서버는 외부에서 접속 가능
• 백엔드 서버는 외부에서는 접속 불가하지만, 외부로 요청은 가능
• DB는 백엔드 서버에서만 접근 가능

📌 실제로는 AZ 분산(다중 가용영역) 구성 권장

6. AZ(가용영역) 분산 구성

"하나의 서버실이 문제가 생겨도, 서비스는 계속되어야 한다."

🔹 AZ

• Availability Zone (가용영역) 의 약자
• 하나의 AWS 리전(예: ap-northeast-2, 서울)에는 2개 이상의 독립된 AZ가 존재
• 각 AZ는 전력, 네트워크, 냉각, 재난에 독립적인 물리적 데이터 센터

AZ 간에는 저지연, 고속 네트워크로 연결되어 있음

🔹 왜 분산해야 할까?

🔹 적용 예시: 2-Tier 웹 시스템

VPC
├── Subnet-A (ap-northeast-2a)
│ ├── EC2 Web 서버
│ └── RDS DB (멀티 AZ)
│
├── Subnet-B (ap-northeast-2c)
│ ├── EC2 Web 서버 (Auto Scaling)
│ └── Standby RDS

• EC2 Auto Scaling Group: 2개 AZ에 인스턴스 분산 배포
• RDS: 멀티 AZ 옵션 활성화 시 Active-Standby 구성
• ALB (Application Load Balancer)는 자동으로 다중 AZ 트래픽 분산

🔹 구성 전략

• 서브넷은 최소 2개 이상 (각기 다른 AZ에)
• Auto Scaling Group + ALB + 멀티 AZ RDS = 기본 고가용성 조합
• EC2, NAT Gateway, ALB 등 비용이 조금 더 들지만, 서비스 안정성 극대화

🔹 정리

"VPC 안에서 가용성 확보 = AZ 분산 설계가 기본이다"

• 단일 AZ → 비용은 적지만 리스크 큼
• 멀티 AZ → 구성은 복잡하지만 기업 서비스에서는 사실상 필수

7. 서브넷 간 통신과 라우팅 테이블의 실제 역할

🔹 라우팅 테이블(Route Table)이란?

VPC 내의 서브넷이 어디로 트래픽을 전달할지 결정하는 설정표

• 각 서브넷은 하나의 라우팅 테이블에 연결
• 라우팅 테이블은 여러 서브넷과 공유할 수 있음
• 트래픽 목적지(CIDR)와 대상(Target)을 명시

🔹 기본 구성 예시

퍼블릭 서브넷 라우팅 테이블:

Destination: 0.0.0.0/0 → Target: igw-abc123  # 인터넷 게이트웨이

프라이빗 서브넷 라우팅 테이블:

Destination: 0.0.0.0/0 → Target: nat-xyz789  # NAT Gateway

🔹 서브넷 간 통신

같은 VPC 내 서브넷끼리는 기본적으로 통신 가능

다만, 라우팅 테이블과 보안 그룹 설정이 맞아야 실질적 통신 가능

🔹 인터넷 접근은 라우팅 설정이 핵심

🔹 다중 AZ 구성 시 라우팅 전략

• 퍼블릭 서브넷이 여러 AZ에 걸쳐 있다면, 각 서브넷은 같은 라우팅 테이블을 공유하거나 각각의 라우팅 테이블을 가질 수 있음
• NAT Gateway가 특정 AZ에만 있을 경우, 해당 AZ의 프라이빗 서브넷에만 연결되는지 확인 필요

[ 퍼블릭 서브넷 ] --IGW-->
    EC2 Web

[ 프라이빗 서브넷 ] --NAT GW--> 인터넷
    EC2 App

[ 프라이빗 서브넷 ] --- 내부 통신 --->
    RDS DB

정리하면…

• 서브넷은 라우팅 테이블을 통해 외부/내부 목적지를 향해 통신
• IGW와 NAT Gateway 설정 여부에 따라 인터넷 사용 가능성 달라짐
• 보안 그룹 + 라우팅 테이블 조합이 실제 통신 가능 여부를 결정

8. 보안 그룹 vs 네트워크 ACL

실무에서는 대부분 SG로 제어하고, NACL은 특별한 보안 요구 시 사용

9. 마무리

• 퍼블릭 서브넷: 외부와 통신이 필요한 자원 배치
• 프라이빗 서브넷: 보호되어야 할 리소스 (DB 등) 배치
• NAT Gateway: 프라이빗 자원의 아웃바운드 전용 통로
• VPC 구성은 보안과 확장성을 위한 네트워크 설계의 핵심

10. VPC Peering이란?

서로 다른 VPC 간의 네트워크 연결을 직접 구성하는 방식

마치 하나의 VPC처럼 통신할 수 있도록 만들어주는 기능

🔹 VPC Peering의 정의

• VPC Peering은 두 개의 VPC 사이에 1:1 네트워크 터널을 만드는 것
• 서로 다른 VPC 내의 리소스 간에 프라이빗 IP로 직접 통신 가능
• 같은 계정, 다른 계정, 다른 리전 간에도 연결 가능

🔹 왜 필요한가?

💡 S3, RDS, EC2 등 모든 서비스에서 프라이빗 IP로 호출 가능

🔹 예시 구조

📦 VPC-A (10.0.0.0/16)
   └── Subnet-A (10.0.1.0/24)
       └── EC2-A

📦 VPC-B (192.168.0.0/16)
   └── Subnet-B (192.168.1.0/24)
       └── EC2-B

==> VPC Peering 연결 생성 후:
EC2-A → EC2-B (프라이빗 IP로 ping 가능)

🔹 설정 순서 요약

1. Peering 연결 생성
   • VPC A → VPC B 요청
   • 같은 계정/다른 계정 지정 가능
2. Peering 연결 승인
   • 상대 VPC 소유자가 수락해야 함
3. 라우팅 테이블 수정
   • 각 VPC의 라우팅 테이블에 상대 VPC CIDR 추가
4. 보안 그룹 설정
   • 통신 대상 포트를 보안 그룹에서 허용해야 정상 작동

🔹 라우팅 테이블 예시

VPC A 라우팅 테이블

Destination: 192.168.0.0/16 → Target: pcx-abc123

VPC B 라우팅 테이블

Destination: 10.0.0.0/16 → Target: pcx-abc123

pcx-abc123는 Peering Connection ID

🔹 주의 사항

✅ 언제 VPC Peering을 쓰면 좋을까?

• 단순히 2~3개의 VPC만 연결할 때
• 고속 통신이 필요한 내부 서비스 간 연결
• VPN이나 Transit Gateway 대신 가볍게 연결하고 싶을 때

❌ 언제는 피하는 게 좋을까?

• VPC 간 연결이 10개 이상으로 늘어날 때 → Transit Gateway 권장
• 리소스 공유가 복잡한 경우 (ex. Lambda ↔ EC2 ↔ RDS)
• CIDR이 중복될 가능성이 있는 경우

💡 요약:

"VPC Peering은 서로 떨어진 가상 사설망을 하나처럼 연결하는 안전한 통로"

구성 수가 많아질수록 확장성의 한계가 생기므로, 구조 설계 단계에서 필요성과 규모를 먼저 판단

참고

• AWS 공식 VPC 설명
• AWS 서브넷 및 라우팅 튜토리얼
• NAT Gateway 공식 문서
• draw.io - AWS 아키텍처 그리기
• VPC Hands-on 실습 가이드 (AWS)
• AWS 리전과 가용영역 개념
• 멀티 AZ 배포 아키텍처 예시 (AWS Well-Architected)
• VPC Peering 공식 문서 (AWS)
• VPC Peering 설정 튜토리얼
• VPC Peering vs Transit Gateway 비교

AWS에서 만든 Python SDK로, AWS의 다양한 서비스들을 제어/관리할 수 있다

import boto3

# client 방식 (low-level)
ec2_client = boto3.client('ec2')

# resource 방식 (high-level)
ec2_resource = boto3.resource('ec2')

대표 서비스별 세부사항 총정리!

(전체 서비스는 200개가 넘어요)

중간중간 커비는.. 제가 좋아해서.. 넣습니다.. 히히

직접 사용해 봅시다!

1. Python 설치 확인

   python --version
   # 또는
   python3 --version

   1-1. 없는 경우 Python 설치

2. 프로젝트 폴더 생성

   mkdir test
   cd test

3. 가상환경 생성

   python -m venv .venv

4. 가상환경 활성화

   .\.venv\Scripts\Activate.ps1       # Windows
   

source .venv/bin/activate # macOS/Linux

5. 필수 패키지 설치
```bash
pip install boto3 python-dotenv

# 선택 설치
pip install requests

#설치된 패키지 저장
pip freeze > requirements.txt

6. .env 파일 생성

   .env

AWS_ACCESS_KEY_ID=your_access_key            # 계정 키 입력
AWS_SECRET_ACCESS_KEY=your_secret_key        # 계정 시크릿키 입력
AWS_REGION=ap-northeast-2                    # 계정 리전

주의! .env 파일은 절대 커밋하지 않도록 .gitignore에 추가하세요!

7. test.py 코드 작성

   import os
   import boto3
   from dotenv import load_dotenv
   

.env 파일에서 환경 변수 로드

load_dotenv()

aws_access_key = os.getenv("AWS_ACCESS_KEY_ID") aws_secret_key = os.getenv("AWS_SECRET_ACCESS_KEY") aws_region = os.getenv("AWS_REGION")

EC2 client 생성

ec2 = boto3.client( "ec2", aws_access_key_id=aws_access_key, aws_secret_access_key=aws_secret_key, region_name=aws_region )

S3 client 생성

s3 = boto3.client( "s3", aws_access_key_id=aws_access_key, aws_secret_access_key=aws_secret_key, region_name=aws_region )

EC2 인스턴스 조회

def list_ec2_instances(): print("🖥 EC2 인스턴스 목록:") response = ec2.describe_instances() for reservation in response["Reservations"]: for instance in reservation["Instances"]: print(f"- Instance ID: {instance['InstanceId']}, State: {instance['State']['Name']}")

S3 버킷 조회

def list_s3_buckets(): print("\n🪣 S3 버킷 목록:") response = s3.list_buckets() for bucket in response["Buckets"]: print(f"- {bucket['Name']}")

실행

if name == "main": list_ec2_instances() list_s3_buckets()

8. 실행
``` bash
python test.py

🎉 실행 결과 예시

🖥 EC2 인스턴스 목록:
- Instance ID: i-0123456789abcdef0, State: running
- Instance ID: i-0abcdef1234567890, State: stopped

🪣 S3 버킷 목록:
- my-project-logs
- static-assets-kwon

가능한 전체 서비스 확인하는 법

import boto3

print(boto3.session.Session().get_available_services())

특정 서비스의 전체 메서드 확인하는 법

import boto3

client = boto3.client('ec2')
print(dir(client))

잘 따라오셨나요? boto3 초기화 시 Session을 사용하는 방식도 추후에 다루어 보겠습니다!

.

.

https://us-east-1.console.aws.amazon.com/console/home?region=us-east-1

우선 회원가입을 진행하고, free trial을 갖고 로그인을 한다. 12개월 한정 기간 사용 가능한 10달러가 주어진다.

• 참고 현재 내 대시보드를 보면 금액이 청구된 것으로 보이는데, 실제 청구서에 들어가보면 아래와 같다.

그러니 돈이 찍혔더라도 청구서에 들어가 꼼꼼히 확인하자.

참고로 AWS는 뉴비에게 친절하다.. 문의로 "나 돈나와써 몰라써 ㅜㅜ" 하면 대개는 청구를 삭제해준다(카더라)

1. 검색창에 EC2 검색 후 대시보드 접속

2. 오른쪽 "인스턴스 시작" 선택

3. 이름 지정, Amazone Linux 선택

4. 아키텍처 맞게, 인스턴스 t3.micro 선택

무료플랜에 적용돼서 선택한 것이고, 추후 시스템이나 프로젝트에 따라 스펙이 다르게 선택 가능하다.

5. 새 키 페어 생성 선택 이름을 적어주고, 파일 형식을 SSH로 선택 후 아래 키 페어 생성을 누른다. 다운로드가 뜰텐데 저장해두면 된다.

6. 남은 선택지 확인 딱히 손댈 것은 없고, 용도에 따라 아래 체크를 변경하면 된다. 아직 용도 확정이 안되었으면 일단 그대로 진행.

7. 가장 적은 용량으로 선택

8. 생성! 오른쪽에 있다.

이렇게 생성한 것의 상태는 "실행중" / "정지" / "중지" 세가지가 있는데 중지하지 않는 한 계속 비용이 발생한다는 점을 명심할 것!

우선 깃헙 메인 간판부터 꾸며본다.

마크다운 형식 / .md 파일

https://github.com/builtkwon

깃헙 프로필에 들어오면 제일 먼저 보이는 README.md 이러쿵 저러쿵 써보았는데, 확실히 꾸밈자를 조금 알고 나니 깔끔한 것 같다.

우선 .md 확장자에 대해 설명하자면, Markdown이라고 텍스트 꾸미기 위한 문서 형식 정도로 알면 된다.

깃헙에서 각 게시물을 Repository/레포지토리/레포 라고 한다. 레포지토리마다 README.md 파일이 생성된다. 프로젝트나 GitHub 리포지토리를 설명하는 대표 문서가 된다. 그리고 GitHub는 리포지토리의 최상단에 있는 README.md를 자동으로 렌더링해서 보여줌

대표적인 문법

1. 제목/Heading

# H1 제목 (가장 크다)
## H2 제목
### H3 제목
#### H4
##### H5
###### H6 (가장 작다)

2. 굵게/기울임/취소선

**굵게**  
*기울임*  
~~취소선~~

3. 리스트

3-1. 순서 없는 리스트

- 항목 1
- 항목 2
  - 하위 항목

3-2. 순서 있는 리스트

1. 첫 번째
2. 두 번째

4. 구분선

---

5. 링크/이미지

[링크텍스트](https://example.com)

![이미지설명](이미지주소)

6. 코드

6-1. 인라인 코드

`코드`

6-2. 여러줄 코드

```python
def hello():
    print("Hello, world!")```

7. 인용문

> 인용문입니다.

8. 표/table

| 제목1 | 제목2 |
|-------|-------|
| 내용1 | 내용2 |
| 내용3 | 내용4 |

9. 체크박스/todo list

- [x] 완료된 일
- [ ] 아직 안 한 일

10. 이모지

:smile: :rocket: :fire:

참고. html도 함께 사용 가능

<b>굵은 글씨</b>
<details>
  <summary>접을 수 있는 영역</summary>
  여기에 자세한 내용을 씁니다.
</details>

. . .

재미있는 잔디심기 으쌰으쌰 시작합니다~