Good coder

[APM-AWS-3] PHP를 통한 웹서버 구축 (로그인/홈페이지 접속) - 코드포함

coder_ — Mon, 20 Oct 2025 16:30:46 +0900

APM 구축이 완료되었으므로 html, php 를 활용하여 페이지를 만들어보려고 합니다. MySQL 에는 users, users_pw 테이블을 생성하여 id 와 pw 를 따로 분리하여 저장하도록 구성했습니다. pw 는 password_hash 를 사용하여 만들었습니다.

프로젝트 구조

/var/www/html/
├── assets/                  # 정적 리소스
│   ├── img/                 # 이미지 파일
│   └── style.css            # 전역 스타일시트
│
├── inc/                     # 공통 include 파일 (모듈)
│   ├── auth.php             # 로그인 세션 체크 및 접근 제어
│   ├── config.php           # DB 환경 설정 (비공개)
│   ├── db.php               # PDO 연결용 DB 핸들러
│   ├── header.php           # 공통 헤더 (HTML head, nav 등)
│   └── footer.php           # 공통 푸터
│
└── public/                  # 실제 접근 가능한 웹 루트
    ├── index.php            # 메인 페이지 (로그인 후 접근)
    ├── login.php            # 로그인 폼 및 처리
    └── logout.php           # 로그아웃 처리

소스코드

config.php (db 정보)

db 정보를 저장할 변수 정의

<?php
define('DB_NAME', 'apmdb');
define('DB_USER', 'apmdb');
define('DB_PASS', 'password');
define('DB_DSN', 'mysql:unix_socket=/var/run/mysqld/mysqld.sock;dbname=' . DB_NAME . ';charset=utf8mb4');

db.php (db 연결)

config.php 에서 db 정보 불러옴
new PDO 클래스를 생성하여 MtSQL 서버와 연결
Options
- ERRMODE_EXCEPTION : SQL 에러가 나면 예외(throw) 발생 -> 에러 디버깅
- FETCH_ASSOC : fetch() 시 결과를 연관 배열로 반환 -> $row['userid'] 형태
- EMULATE_PREPARES => false : MySQL 의 실제 prepared statement 사용 -> SQL 인젝션 방지

<?php
require_once __DIR__ . '/config.php';

try {
    $pdo = new PDO(DB_DSN, DB_USER, DB_PASS, [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
        PDO::ATTR_EMULATE_PREPARES => false,
    ]);
} catch (PDOException $e) {
    error_log('DB Connection failed: ' . $e->getMessage());
    http_response_code(500);
    exit('Internal Server Error');
}

login.php (로그인 로직 및 페이지 html)

로직 : post 요청으로 id/pw 전송 -> users 테이블에 계정 존재 여부 확인 -> db에 저장된 pw 와 입력한 pw 를 password_verify 를 사용하여 비교 -> 맞으면 session 시작 및 저장 -> 틀리면 error 에 저장 후 로그인 페이지에서 에러문구 표기

db 와 연결
session_start() 로 세션 관리
$_SESSION 에 userid 저장

<?php
require_once __DIR__ . '/../inc/auth.php';
require_once __DIR__ . '/../inc/db.php';

if($_SERVER['REQUEST_METHOD'] === 'POST') {
        $id = $_POST['id'] ?? '';
        $pw = $_POST['pw'] ?? '';
        $stmt = $pdo->prepare('SELECT * FROM users WHERE userid = ? LIMIT 1');
        $stmt->execute([$id]);
        $user = $stmt->fetch();

	if ($user) {
		$stmt = $pdo->prepare('SELECT password_hash FROM users_pw WHERE userid = ? LIMIT 1');
        	$stmt->execute([$id]);
		$pwRow = $stmt->fetch();

		if ($pwRow && password_verify($pw, $pwRow['password_hash'])) {
			$_SESSION['user'] = $id;
			header('Location: /');
			exit;
		} else {
			$error = '아이디 또는 비밀번호가 잘못되었습니다';
		}
	} else {
                $error = '아이디 또는 비밀번호가 잘못되었습니다';
        }
}

Index.php (로그인 후 접속하는 홈페이지)

auth.php 에서 생성한 require_login() 함수를 통해 세션 체크

<?php
require_once __DIR__ . '/../inc/auth.php';
require_login();  // 로그인 안 된 상태면 login.php로 리다이렉트
include __DIR__ . '/../inc/header.php';
?>
<!doctype html>
<html lang="ko">
<head><meta charset="utf-8"><title>메인 페이지</title></head>
<body>
  <h1>환영합니다, <?=htmlspecialchars($_SESSION['user'])?>님!</h1>
</body>
</html>

auth.php (세션 체크)

session_status() 를 통해 상태 체크
- PHP_SESSION_DISABLED : 세션이 비활성화된 경우
- PHP_SESSION_NONE : 세션이 존재하지만 비활성 상태인 경우. 즉 세션이 있지만 session_start() 가 호출되지 않은 상태
- PHP_SESSION_ACTIVE : 세션이 활성 상태인 경우
$_SESSION['user'] 가 비어 있으면 login.php 페이지로 이동

<?php
if (session_status() === PHP_SESSION_NONE) {
    session_start();
}

function require_login() {
    if (empty($_SESSION['user'])) {
        header('Location: login.php');
        exit;
    }
}

[APM-AWS-2] MySQL 설치 / Lightsail (Ubuntu)

coder_ — Mon, 20 Oct 2025 15:55:47 +0900

[APM-1] AWS Lightsail 에 Ubuntu 24.04 / Apache2/ PHP 설치

모의해킹을 위한 WEB, WAS 서버를 구축합니다. 우선 서버 Instance 생성, Apahce, PHP 설치 를 진행한다.서버 환경AWS LightsailLightsail 은 저렴한 서비스는 3개월 무료로 사용할 수 있다. APM 서버 자체가 가볍

bob-data.tistory.com

이전에 APM 구조중 Apache2, PHP 서버를 설치했습니다. 이번에는 MySQL을 설치 합니다.

Lightsail 에서 가장 저렴한 (Ram - 512MB, vCpu - 1) 을 사용하였는데, MySQL 설치중 메모리가 부족하여 원활한 설치가 진행되지 않는 문제가 발생했습니다. 그래서 한 단계 업그레이드 진행했습니다. 제 기준 (Ram - 1GB, vCpu - 2) 를 사용하였습니다.

다시 정리하자면 Ubuntu 24.04 에 MySQL 8.0 을 설치합니다.

MySQL 설치

MySQL 설치 후 로컬에서도 접속하기 위해 포트 및 방화벽을 특정 ip 한정 오픈했습니다. 작업을 진행하며 고려한 사항은 다음과 같습니다.

CRUD 용 mysql db 계정 생성
특정 ip port, firewall 오픈

# 1. 패키지 목록 갱신
sudo apt update

# 2. MySQL 서버 설치 noninteractive 는 자동으로 설치를 진행하도록 해준다.
sudo DEBIAN_FRONTEND=noninteractive apt install -y mysql-server

# 3. 설치 후 서비스 상태 확인
sudo systemctl status mysql --no-pager

# 4. 기본 보안 설정 (비밀번호 설정 등)
sudo mysql_secure_installation

MySQL 접속

# root 계정으로 접속, 비밀번호를 설정하지 않았다면 비밀번호 입력하라고 합니다.
# 아무 설정이 없다면 sudo mysql 로 그냥 진입 가능 합니다.
sudo mysql -u root -p

# 생성할 db 전용 CRUD 계정 생성 SQL 명령어
CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
# WITH mysql_native_password 를 통해 공개된 키 교환을 허락하지 않도록 하는 것이다.
CREATE USER 'appuser'@'localhost' IDENTIFIED WITH mysql_native_password BY '비밀번호입력';
# 만약 외부에서도 사용할 거라면 'appuser'@'localhost' 대신 'appuser'@'%' 로 입력
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost'; 
FLUSH PRIVILEGES;

# 접속 테스트
mysql -u appuser -p
# → 비밀번호 입력
mysql> SHOW DATABASES;
mysql> USE appdb;
mysql> CREATE TABLE test (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));
mysql> INSERT INTO test (name) VALUES ('hello');
mysql> SELECT * FROM test;

MySQL 외부 접속 허용 설정 (서버 사이드)

외부 로컬에서 db 툴 (dbeaver)를 사용하여 접속을 하려고 한다.

# MySQL 설정 파일 수정
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

# 다음 라인 수정
bind-address = 127.0.0.1 

# 아래와 같이 수정
bind-address = 0.0.0.0

# 저장 후 mysql 재시작
sudo systemctl restart mysql

# 내 ip 방화벽 열기
# UFW: 내 IP만 열어둔 상태 확인
sudo ufw status
# 없으면 추가 (예: 내IP가 1.2.3.4라면)
sudo ufw allow from 1.2.3.4 to any port 3306 proto tcp

# 방화벽 열어주기 특정 port
sudo ufw allow 3306/tcp

MySQL 은 정상 설치 되었으며, dbeaver 를 통해 로컬 환경에서도 정상 접속 가능합니다.

[APM-AWS-1] Apache2-PHP 설치 / Lightsail Ubuntu 24.04

coder_ — Thu, 16 Oct 2025 16:16:17 +0900

모의해킹을 직접 해보기 위해서는 웹서버가 필요합니다. 가장 기초적인 APM (Apache-PHP-MySQL) 구조를 활용합니다. 이 포스트에서는 모의해킹을 위한 WEB, WAS 서버를 구축합니다.

우선 서버 Instance 생성, Apahce, PHP 설치 를 진행합니다.

서버 환경

AWS Lightsail
Lightsail 은 저렴한 서비스는 3개월 무료로 사용할 수 있다. APM 서버 자체가 가볍기 때문에 최저 사양으로 사용하기로 결정했다. 앱인 설치된 것도 할 수 있지만, Apache, PHP, MySQL 모두 직접 설치해보고 설치과정에서 발견할 수 있는 취약점이 있지 않을까 해서 직접 설치하기로 결정했다. 참고로 LAMP 는 SSL 자동구성, Linux, Apache, PHP, MariaDB 가 설치되어 있고, phpMyAdmin, PHP 기본 모듈이 포함 되어 있다고 한다. (편하게 하려면 이거 설치하는게 좋을듯 합니다.)

SSH 키를 통한 접속
인스턴스를 생성하고 나면 SSH 키를 다운 받을 수 있다. 이 SSH 키를 통해 해당 서버에 접속을 할 수 있으니 잘 관리해야 한다. 키를 다운로드하고 나면 Windows 에서는 Putty 를 통해, Mac OS 에서는 Terminal 에서 접속할 수 있다. Mac 의 경우 해당 키 파일에 chmod 600 권한을 줘야 한다.

APM 설치

Apache2 설치

Apahce 는 웹 서버로 HTTP 통신을 지원해준다. 우선 Apache 설치는 명령어만 따라 치면 돼서 설치가 어렵지는 않다. Apache 설정 값들은 config 에서 직접 수정해줘야 하니, 나중에 SSL 이나 추가로 설정값 바꿔야 하면 직접 바꿔주면 된다.

# 시스템 업데이트
sudo apt update
sudo apt upgrade -y

# Apache2 설치
sudo apt install -y apache2

# Apache 서비스 상태 확인
sudo systemctl enable --now apache2
sudo systemctl status apache2 --no-pager

# 방화벽(ufw)에 http/https 오픈
sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 'Apache Full'   # 80, 443 허용
sudo ufw enable
sudo ufw status verbose

http://server_ip 접속하면 Apache2 페이지로 접속이 된다. Apache2 는 기본적으로 /var/www/html 경로를 바라보고 있다. 해당 경로에 있는 index.html 파일을 보여주고 있는 것이다. 추후에 경로 수정이 필요하면 /etc/apache2/sites-available/000-default.conf 파일에서 수정해주면 된다.

Options Indexes FollowSysmLinks
디렉터리 안에 index.html, index.php 와 같은 기본 파일이 없을 때 파일 목록을 자동으로 브라우저에 보여줄지
Options -Indexes +FollowSymLinks : 파일 목록 막고 링크 허용 / 보안 신경 쓰면 설정
AllowOverride All
.htaccess 파일 엑세스 허용 .htaccess 는 각 폴더 안에 둘 수 있는 Apache 설정 파일이다. (접근차단, Redirect 등)
Require all granted
디렉터리에 접근 가능 설정

PHP 설치

php 는 명령어 한줄이면 쉽게 설치 가능하다.

# php install
sudo apt install -y php libapache2-mod-php php-mysql php-cli php-curl php-gd php-mbstring php-xml php-zip

# 버전확인
php -v

# libapache2-mod-php 를 설치하면 자동으로 Apache 에 PHP 모듈이 로드 된다.
sudo systemctl restart apache2

우선 APM 중 AP 까지만 설치했다. 다음에는 우선 MySQL 연결 이전에 로그인 기능을 추가해보자.

Teams 휴가 시스템 구축 - Microsoft 365 (Automate 자동화, Power Apps 연동)

coder_ — Thu, 10 Jul 2025 21:25:20 +0900

Microsoft 365 기반 휴가 신청 및 승인 자동화 시스템 구축 기록

휴가 시스템 다이어그램

직장 내에서 휴가를 관리하는 일은 생각보다 복잡한 작업인 것 같습니다. 누가 언제 휴가를 갔는지, 대기 중인 요청은 어떤 것인지, 승인자는 어떻게 확인하고 처리할 수 있는지 등 여러 절차가 수작업으로 진행되면 누락이나 중복, 혼선이 발생하기 쉽습니다.

우리 회사는 이전까지 노션을 활용해 팀원들의 연차 및 휴가 일정을 공유해왔습니다. 모두가 자유롭게 수정 가능한 구조였기 때문에, 다른 사람의 휴가 일정을 확인하는 데에는 편리했지만 승인 절차가 없고, 데이터 변경의 위험성이 있다는 점에서 개선이 필요했습니다.

이런 문제를 해결하고자, Microsoft 365의 다양한 앱을 연동하여 휴가 신청과 승인 절차를 자동화하는 시스템을 구축하게 되었습니다.

시작하기에 앞서 Microsoft 365 Business 계정 이상 라이선스가 있어야 이용하실 수 있습니다.

시스템 개요

본 시스템은 Microsoft Forms, Power Automate, Excel Online, SharePoint List, Power Apps, Teams 등 M365 생태계 안의 툴들을 연결해 구현했습니다.

휴가 신청은 Forms에서 이루어지고,
신청 데이터는 Excel Online과 List에 저장되며,
Power Automate가 전체 흐름을 자동으로 제어합니다.
사용자 인터페이스는 Power Apps를 통해 제공하며,
모든 접근과 알림은 Teams를 통해 연결됩니다.

사용한 도구 및 역할

Forms	사용자의 휴가 신청 입력
Excel Online	신청 내역 및 휴가 현황 데이터 관리
MS List	Power Apps와 연동되는 구조화된 데이터 저장소
Power Apps	사용자에게 휴가 현황 및 신청 내역 UI 제공, 휴가 취소 기능
Power Automate	신청–승인 전 과정 자동화, 승인 여부에 따른 분기 처리, 알림 전송
Teams	신청 탭, 알림, 승인 요청 등 사용자 접근성과 커뮤니케이션 채널 역할

프로세스 요약

Power Apps
사용자는 Power Apps를 통해 본인의 휴가 현황 및 신청 내역을 확인하고, 승인 대기 중인 휴가 신청을 취소할 수 있습니다.
Power Apps UI 휴가 현황 체크
Forms (휴가 신청)
사용자는 Teams 탭에서 Forms로 휴가 신청서를 작성합니다.
휴가 신청 Forms
Power Automate Flow 작동
- Forms 데이터를 수신하여 자동 플로우 시작
- 신청 내역을 Excel Online 및 SharePoint List에 기록
- 신청 상태에 따라 승인 요청 프로세스 시작
- 승인 절차 중 사용자가 신청을 취소할 경우 예외 처리 로직 적용
- 승인자에게 Teams 알림 및 승인 요청 전송
- 승인 여부에 따라 데이터 업데이트 및 사용자 알림
  - 승인: Excel 및 List 업데이트 + Teams 알림 + Outlook 메일 + 캘린더 등록
  - 거절: 동일하게 Teams 및 메일 알림
휴가 데이터 관리
- Excel Online 으로 데이터 적재,
- Excel Online <-> SharePoint List 데이터 주기적으로 동기화 (Automate 사용)

도입 후기

Microsoft의 통합 생태계는 기대 이상이었습니다. 단순히 Excel이나 SharePoint List에 데이터를 저장하면, 그 데이터를 Power Apps, Automate, Teams 등 다양한 앱과 연결해 UI 생성, 승인 처리, 알림 전송 등 거의 모든 작업을 코드 없이 구현할 수 있었습니다.

특히 사용자의 입장에서도 접근성이 좋고, 별다른 교육 없이도 직관적인 인터페이스를 통해 쉽게 적응할 수 있었던 점이 인상적이었습니다. 한 번 구축해두면 운영이 매우 효율적이고 안정적이라는 것도 큰 장점이었습니다.

추가로 생각해볼 개선점

캘린더(Outlook/Google) 자동 등록은 현재 단순 구현 상태인데, 사용자 개별 동기화를 고려한 고도화가 필요함
Power Apps에서 휴가 신청도 함께 받는 구조로 통합하면 UI 일원화 가능
연차 통계, 사용률 분석 기능 추가 시, Power BI 연동 고려 가능

휴가 시스템 로직

[CI/CD] GCP 서버 CI/CD 파이프라인 구축 (Github Actions)

coder_ — Fri, 27 Jun 2025 18:20:37 +0900

운영 중인 백엔드 시스템에 CI/CD를 도입하면서, 코드 배포의 시간을 50% 이상 단축할 수 있었습니다.

1. 프로젝트 환경 구성

현재 시스템은 다음과 같은 구조로 운영되고 있습니다:

로컬 개발 환경 → Bastion Host → Portal Server
개발된 코드는 GitHub를 통해 관리되며, Bastion Host를 거쳐 Portal Server에 배포됩니다.
- 기존 구조: Local (.war 파일 mvn build) -> .war 파일 Bastion Host 전송 -> .war 파일 Portal Server 전송 -> 배포
보안 강화 구조 (GCP Private IP + IAP)
Portal 서버는 GCP 내부 네트워크에 위치하고 있으며, 외부에서 직접 접근할 수 없고, IAP(Identity-Aware Proxy)를 통해서만 접속이 가능합니다. 모든 배포 작업은 IAP 터널링을 통해 Bastion Host를 경유합니다.

2. 의존성 이슈 대응 (googlebigquery)

배포 과정에서 googlebigquery-jdbc 관련 외부 의존성이 Maven 중앙 저장소에서 정상적으로 다운로드되지 않는 문제가 있었습니다.
이 문제는 해당 라이브러리 .jar 파일을 프로젝트 레포에 직접 포함시키는 방식으로 해결했습니다. 완전한 자동화에는 다소 한계가 있었지만, CI 파이프라인 내 의존성 충돌은 방지할 수 있었습니다.

3. CI 파이프라인 구성 (GitHub Actions)

트리거 조건

test, production 브랜치로 Pull Request가 생성될 때 자동으로 동작합니다.
브랜치별로 설정된 프로파일(dev, prd)에 따라 빌드 환경이 구분됩니다.

주요 작업 흐름

코드 체크아웃 및 Java 환경 설정
- GitHub Actions에서 Temurin JDK 11 설치
Maven 빌드 실행
- mvn clean install -Pdev 혹은 -Pprd로 WAR 파일 생성
Google Cloud 인증 및 SSH 연결
- 서비스 계정 키를 활용한 인증
  - Github 레포지토리 Settings > Secrets and variables > Actions > New repository secret 생성 -> yml 파일에서 사용
- IAP 터널을 통해 Bastion Host에 WAR 파일 전송
Bastion Host에서 배포 스크립트 실행
- 사전에 작성된 deploy_dev.sh 또는 deploy_prod.sh 실행
- 해당 스크립트는 내부 Portal 서버로 WAR 파일을 복사하는 역할 수행

name: Deploy WAR to Bastion (production)

on:
  pull_request:
    branches: [production]

jobs:
  deploy:
    name: Build and Deploy to Production
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: '11'

    - name: Build WAR using Maven
      run: mvn -B clean install -Pprd

    - name: Set up Google Cloud SDK
      uses: google-github-actions/auth@v2
      with:
        project_id: service-account
        credentials_json: ${{ secrets.key }}
        export_default_credentials: true

    - name: Activate service account for gcloud CLI
      run: |
        gcloud auth activate-service-account --key-file="${GOOGLE_APPLICATION_CREDENTIALS}"
        gcloud config set account service-account@service-account.iam.gserviceaccount.com

    - name: Transfer WAR to Bastion Host via IAP
      run: |
        gcloud compute scp target/file.war bastion-host:/home/service-account/ \
          --zone=asia-northeast3-a \
          --tunnel-through-iap \
          --project=service-account

    - name: Run deployment script on Bastion
      run: |
        gcloud compute ssh bastion-host \
          --zone=asia-northeast3-a \
          --tunnel-through-iap \
          --project=dmdashboard-prod \
          --command="bash /home/service-account/deploy_prod.sh"

Github Repository secrets

4. CD (배포 자동화) 전략

보안상의 이유로, 최종 WAS 배포는 자동화하지 않고 운영자가 수동으로 수행하도록 했습니다.
WAR 파일만 전달된 상태에서, 직접 Tomcat을 재시작하거나 웹 애플리케이션을 교체하는 식으로 운영 환경에 반영합니다.

이렇게 설계한 이유는 다음과 같습니다:

운영 서버 접근 권한 최소화
실시간 장애 대응 여지를 확보
배포 승인 및 리스크 확인 프로세스 유지

이번 CI/CD 구축을 통해 배포 시간과 실수를 줄이고, 운영 안정성을 높일 수 있게 되었습니다.

[GCP] Bastion Host VM 서버 구축 (Proxy, OS Login)

coder_ — Sun, 27 Apr 2025 13:08:47 +0900

GCP 환경에서 직접 VM에 외부에서 접근하는 것은 보안상 위험이 있어, 안전한 방법을 찾게 되었습니다. 특히, Cloud IAP(Identity-Aware Proxy)를 활용해 외부 IP 오픈 없이도 SSH 접속을 가능하게 하려는 요구가 있었고, 이를 위해 Bastion Host를 설정하게 되었습니다. Bastion Host는 관리용 VM으로 최소한의 보안 구성을 갖추어 내부 자원에 대한 안전한 접근 통로 역할을 합니다.

1. Bastion Host VM 설정

VM 생성 방법

Compute Engine → VM 인스턴스 → ‘인스턴스 만들기’ 선택

주요 설정 값

이름: bastion-host-dev
리전/존: 서비스 환경과 동일한 리전 선택 (예: asia-northeast3-a)
머신 타입: e2-medium (1vCPU, 4GB RAM)
부팅 디스크: Debian GNU/Linux 11 (기본값)
네트워크: 전용 VPC 또는 default VPC 사용
방화벽:
- HTTP, HTTPS 체크 해제
- IAP를 통한 SSH 터널링 허용 (35.235.240.0/20 대역의 22번 포트 Ingress 허용)

추가 설정

Metadata
- enable-oslogin=TRUE
보안
- Project-wide SSH keys 비활성화
- OS Login 2단계 인증(2FA) 활성화

2. Bastion Host Service 계정 생성

서비스 계정 생성

IAM & Admin → 서비스 계정 → '서비스 계정 만들기'
이름: bastion-host-sa
역할:
- Compute Instance Admin (v1)
- Service Account User

VM에 서비스 계정 연결

Bastion Host VM 수정 → 서비스 계정 → bastion-host-sa 선택

3. 로컬에서 Bastion Host로 접속

접속 명령어

gcloud compute ssh bastion-host-dev \
  --project=[PROJECT_ID] \
  --zone=asia-northeast3-a \
  --tunnel-through-iap

--tunnel-through-iap 옵션으로 Cloud IAP를 통한 보안 터널링
접속 전 gcloud auth login, gcloud config set project [PROJECT_ID] 필수

4. Bastion Host에서 Dev VM 접속

Bastion Host 내부에서 Dev VM으로 SSH 접속

ssh [DEV_VM_USER]@[DEV_VM_INTERNAL_IP]

[DEV_VM_INTERNAL_IP]는 같은 VPC 내 프라이빗 IP 주소 사용
Bastion Host와 Dev VM은 서로 통신 가능해야 함 (VPC/Subnet 설정 확인)

5. Bastion Host를 Proxy로 Cloud SQL MySQL 접속

Cloud SQL Auth Proxy 설치

curl -o cloud-sql-proxy https://dl.google.com/cloudsql/cloud-sql-proxy.linux.amd64
chmod +x cloud-sql-proxy
sudo mv cloud-sql-proxy /usr/local/bin/

Proxy 실행

cloud-sql-proxy [INSTANCE_CONNECTION_NAME] \
  --private-ip \
  --port=3306

[INSTANCE_CONNECTION_NAME]: project:region:instance 형식
--private-ip 옵션 필수 (Private IP로 연결)

로컬에서 Bastion Host를 통한 DB 접속

mysql -h 127.0.0.1 -P 3306 -u [DB_USER] -p

localhost로 접속하면 Bastion Host를 통해 Cloud SQL과 연결됨

이렇게 설정하면 외부 노출 없이 Bastion Host를 통한 안전한 접속 경로를 구축할 수 있습니다. 추가로, Bastion Host에는 최소한의 권한만 부여하고, 정기적인 접속 로그 점검이 권장됩니다.

[GCP] Google Cloud Armor 적용 (feat. Custom Error page - Cloud Storage)

coder_ — Sun, 23 Mar 2025 12:54:23 +0900

서비스를 운영하다 보면 내부 시스템을 외부에 노출시켜야 하는 상황이 생긴다. 특히 클라이언트사 담당자들이 접근하는 운영/통계용 대시보드는 접근 권한을 세밀하게 제어해야 할 필요가 있는데, GCP 환경에서 Google Cloud Armor를 활용한 IP 기반 접근 제어를 구현하게 되었다.

이 글은 Cloud Armor를 활용하여 특정 IP만 접근 가능하도록 구성하고, 허용되지 않은 IP는 커스텀 에러 페이지로 유도하는 구성 방법을 상세히 정리한 실전 가이드이다.

왜 Cloud Armor를 도입했는가

Cloud Armor를 도입한 이유는 명확하다. 운영 중인 VM이 퍼블릭하게 노출되어 있고, 이 서비스에 접근 가능한 IP를 고객사 내부망으로 제한하고자 했기 때문이다.

GCP의 VM 방화벽 기능으로도 IP를 제어할 수 있지만, 다음과 같은 이유로 Cloud Armor를 선택했다:

VM 수준이 아닌 LB(Load Balancer) 수준에서 제어 가능
커스텀 에러 페이지 리디렉션 구성 가능
향후 WAF, DDoS 대응까지 고려한 확장성 보유

1. Cloud Armor 생성

목적: 특정 IP만 허용하고, 허용되지 않은 IP의 요청을 차단하여 403 에러를 반환하도록 설정

단계별 설정

GCP 콘솔 → 네트워크 보안 → Cloud Armor 이동
"보안 정책(Security Policy) 생성" 클릭
정책 이름 설정: 예) dev-access-policy
정책 규칙 추가:
- 허용할 IP 추가 → ALLOW 설정
- 차단할 모든 IP 추가 → DENY (403) 설정
정책 저장 후 Load Balancer의 백엔드 서비스에 적용
- 예: dev-web-loadbalancer-backend

결과: 지정된 IP 이외의 접근은 모두 403 Forbidden 반환

2. Load Balancer 선택 & 설정

목적: Cloud Armor가 적용된 Load Balancer에서 차단된 요청이 발생하면, 특정 에러 페이지로 리디렉션

단계별 설정

GCP 콘솔 → 네트워크 서비스 → Load Balancing 이동
기존 Load Balancer 선택 (예: dev-loadbalancer)
백엔드 서비스(Backend Service) 확인
- dev-web-loadbalancer-backend가 Cloud Armor와 연결되어 있는지 확인
라우팅 규칙 수정:
- 예: dev.example.com 도메인 확인
- Cloud Armor 정책 적용 확인

결과: 허용된 IP는 정상 접속, 차단된 IP는 403 Forbidden 발생

3. Cloud Storage에 403 에러 페이지 추가 후 공개 설정

목적: 차단된 사용자가 403 Forbidden 페이지를 보도록 설정

단계별 설정

GCP 콘솔 → Cloud Storage 이동
새 버킷 생성 (예: dev-error-page-bucket)
403.html 파일 업로드 (커스텀 메시지 작성)
파일 공개 설정:
- allUsers에게 READER 권한 부여

결과: Public URL 을 통해 접근 가능

4. Load Balancer에 백엔드 버킷 추가 후 dev 환경에 적용

목적: Cloud Armor에서 403 응답이 발생하면, Cloud Storage의 403 페이지로 리디렉트

1) 백엔드 버킷 추가

GCP 콘솔 → Load Balancing 이동
"백엔드 구성" 탭 클릭
"새 백엔드 버킷 생성"
- 이름: dev-error-page-bucket-backend
- Cloud Storage 버킷 선택: dev-error-page-bucket
- Cloud CDN 여부 설정 (선택)
저장 및 배포

결과: Load Balancer가 정적 페이지를 서빙할 수 있음

2) dev 환경에 403 경로 추가

Load Balancer → 라우팅 규칙 편집
호스트 및 경로 규칙 추가:
- 호스트: error-dev.example.com
- 경로: /403.html
- 백엔드: dev-error-page-bucket-backend
저장 및 배포

3) 정책에 403 커스텀 오류 페이지 적용

defaultCustomErrorResponsePolicy:
  errorResponseRules:
    - matchResponseCodes:
      - 403
      path: '/403.html'
  errorService: https://www.googleapis.com/compute/v1/projects/my-gcp-project/global/backendBuckets/dev-error-page-bucket-backend

결과: Cloud Armor가 차단한 요청은 /403.html 페이지로 자동 리디렉트됨

VM 방화벽과의 차이점

처음엔 단순히 VM 방화벽으로도 IP를 제한할 수 있지 않을까 생각했지만, 운영 VM에 직접 방화벽을 적용하면 배포 시 마다 규칙을 변경해야 하고, 커스텀 에러 페이지를 구성할 수 없다는 점이 문제였다.

Cloud Armor는 LB 앞단에서 트래픽을 차단하기 때문에 서비스 자체에 부담을 주지 않으며, UX를 고려한 안내 페이지 제공까지 가능하다. 여기에 DDoS 대응과 WAF 설정까지 고려할 수 있는 구조라, 확장성과 보안성을 모두 만족시킬 수 있는 선택이었다.

DDoS 방어	✅ Google Edge Network에서 차단	❌ VM까지 트래픽이 도달 후 차단
IP Spoofing 대응	✅ 네트워크 계층에서 차단	❌ VM 내부에서만 적용됨
SQL Injection / XSS 방어	✅ WAF 기능 제공	❌ 수동 설정 필요
L7 공격 방어	✅ 웹 애플리케이션 공격 차단 가능	❌ L4 레벨에서만 차단

마무리

이번 구성은 단순한 접근 제한을 넘어서, 사용자에게 명확한 안내 메시지를 제공하고 내부망 IP만 접근할 수 있도록 구성하는 실전형 아키텍처이다.

Cloud Armor를 통해 IP 기반 접근 제어를 구현하고, 커스텀 에러 페이지로 사용자 경험까지 챙기는 설정이 필요한 상황이라면, 이 글이 충분히 도움이 될 것이다.

[Apache upgrade] 2.4.55 -> 2.4.60 version 업그레이드 (CentOS 7.9.2009)

coder_ — Thu, 26 Dec 2024 21:33:12 +0900

Apache 2.4.55 버전이 보안 검사에서 이슈가 많이 발생해서 2.4.60 버전으로 업그레이드 하기로 결정했다. 서버는 CentOS 7.9.2009 다. 신경 써야 될 부분도 있었는데, 기존 Apache 는 유지 시키고 새 경로에 Apache 를 설치 했다. (문제 생길시 바로 되돌리기 위해)

아래는 꼭 신경 써야 하는 내용들이다

apr, apr-util 설치
로드 밸런싱을 사용한다면 mod_jk 도 설치 해야한다. (이 경우는 yum update 를 하는게 아니라면 workers.properties 파일을 생성하고 거기에 로드밸런싱 설정 값을 넣어 줘야 한다.)

적용하는데 어렵지는 않지만 서비스 중인 서버라면 서비스가 멈추지 않도록 계획을 잘 짜야 한다.

1. Apache 버전 확인

현재 설치된 Apache 버전 확인:

httpd -v
httpd -V

출력 예시:

Server version: Apache/2.4.55 (Unix)
Server built:   Jan 17 2023 16:57:1

2. Apache 다운로드 및 설치 준비

1. Apache 소스 다운로드

Apache 최신 버전을 Apache 공식 다운로드 페이지에서 다운로드.

wget https://downloads.apache.org/httpd/httpd-2.4.60.tar.gz

2. 서버로 파일 전송

다운로드한 파일을 서버로 전송 (SCP 또는 SFTP 사용 가능):

scp httpd-2.4.60.tar.gz user@<서버IP>:/usr/local/src

3. 압축 해제 및 디렉토리 이동

cd /usr/local/src
tar -xvf httpd-2.4.60.tar.gz
cd httpd-2.4.60

4. 필수 패키지 설치

yum groupinstall -y "Development Tools"
yum install -y gcc gcc-c++ make pcre pcre-devel expat expat-devel

3. Apache APR 및 APR-Util 설치

1. 다운로드

wget https://downloads.apache.org/apr/apr-1.7.5.tar.gz
wget https://downloads.apache.org/apr/apr-util-1.6.3.tar.gz

2. 압축 해제 및 이동

tar -xvf apr-1.7.5.tar.gz
tar -xvf apr-util-1.6.3.tar.gz
mv apr-1.7.5 srclib/apr
mv apr-util-1.6.3 srclib/apr-util

3. 구조 확인

ls srclib

출력 예시:

apr
apr-util

4. Apache 컴파일 및 설치

./configure 실행

./configure --prefix=/usr/local/apache2 --enable-so --enable-ssl --with-mpm=event --with-included-apr

컴파일 및 설치

make
make install

설치 확인

/usr/local/apache2/bin/httpd -v

5. 포트 변경 후 테스트

1. 포트 변경

/usr/local/apache2/conf/httpd.conf 파일에서 Listen 값을 수정:

Listen 8081

2. Apache 실행

/usr/local/apache2/bin/apachectl start

3. 테스트

curl -I http://127.0.0.1:8081

출력 예시:

HTTP/1.1 200 OK

6. 기존 Apache에서 새 Apache로 전환

1. 기존 Apache 중지

systemctl stop httpd

2. 포트 변경

/usr/local/apache2/conf/httpd.conf에서 Listen 값을 80으로 변경:

Listen 80

3. 새 Apache 재시작

/usr/local/apache2/bin/apachectl restart

4. 테스트

curl -I http://127.0.0.1

7. 필요 없는 파일 정리

rm -rf /usr/local/src/httpd-2.4.60
rm -rf /usr/local/src/httpd-2.4.60.tar.gz

[GIT] Git Flow - 가장 쉬운 깃 브랜치 전략 (생애 첫 기술 발표 영상)

coder_ — Thu, 3 Oct 2024 13:22:25 +0900

1. Git Flow란 무엇인가?

Git Flow는 소프트웨어 개발 프로세스에서 효율적인 브랜치 관리와 협업을 돕는 브랜치 전략입니다. 개발, 테스트, 배포 등의 단계에서 코드의 안정성을 확보하고, 여러 개발자 간 협업을 체계적으로 할 수 있게 해줍니다. Git Flow는 feature, develop, release, hotfix, main(또는 prod)와 같은 브랜치 구조를 사용하여 명확한 워크플로우를 제공합니다.

2. Git Flow의 주요 브랜치 규칙

Git Flow는 다섯 가지 주요 브랜치로 작업을 나누며, 각 브랜치는 특정 목적과 규칙을 가지고 있습니다.

1) `main` 브랜치 (`prod`)

목적: 운영 서버에 배포되는 안정적인 코드를 관리합니다.
규칙: main에는 항상 릴리스된 코드만 포함되어야 하며, 직접 작업이 아닌 다른 브랜치(release, hotfix)에서 병합됩니다.

2) `develop` 브랜치

목적: 배포 준비를 위한 다음 릴리스 버전을 개발합니다. 새로운 기능이 모두 develop에서 통합되고 테스트됩니다.
규칙: develop에는 반드시 prod에 배포할 예정인 코드만 병합해야 합니다. 아직 검증되지 않은 기능이나 임시 코드가 들어가면 안 됩니다.

3) `feature` 브랜치

목적: 개별 기능 또는 버그 수정을 개발합니다.
규칙: 항상 develop 브랜치에서 파생되어 개발하고, 완료되면 다시 develop에 병합합니다. 브랜치 이름은 feature/로 시작하며, 기능을 설명하는 이름이나 이슈 번호를 붙여 일관성을 유지합니다.
- 예: feature/DS-212, feature/user-authentication

4) `release` 브랜치

목적: 배포 준비가 완료된 코드를 마지막으로 검증하고, 버그 수정 및 안정화 작업을 합니다.
규칙: develop 브랜치에서 생성하며, 모든 검증 작업이 끝나면 main과 develop에 병합합니다. 브랜치 이름은 release/로 시작하고 버전 번호를 포함합니다.
- 예: release/v1.0.0

5) `hotfix` 브랜치

목적: 운영 중인 main에서 긴급한 버그를 수정합니다.
규칙: main 브랜치에서 파생되어 작업하고, 수정이 완료되면 main과 develop에 모두 병합합니다. 브랜치 이름은 hotfix/로 시작합니다.
- 예: hotfix/loginError, hotfix/payment-issue

3. 왜 Git Flow를 지켜야 하는가?

명확한 워크플로우: 각 브랜치의 역할과 작업 흐름이 명확하게 구분되므로, 협업 시 발생할 수 있는 혼란을 방지합니다.
코드 안정성 확보: develop과 release를 통한 검증 프로세스를 거치므로, 배포되는 코드의 안정성을 보장할 수 있습니다.
독립적인 기능 개발: feature 브랜치를 통해 독립적으로 기능을 개발하고 테스트할 수 있습니다. 다른 기능에 영향을 주지 않고 필요한 기능만 선택적으로 배포할 수 있습니다.
긴급 대응: hotfix 브랜치를 통해 운영 환경에서 발생한 긴급한 문제를 신속하게 해결하고, 배포할 수 있습니다.

4. Git Flow 관리 방법

Git Flow를 제대로 관리하기 위해서는 몇 가지 원칙과 규칙을 따라야 합니다.

1) 브랜치의 명확한 규칙 설정

브랜치 이름에 접두사를 붙여 역할을 명확히 구분합니다 (feature/, hotfix/, release/).
일관성 있는 브랜치 네이밍 규칙은 작업의 목적과 상태를 쉽게 파악할 수 있도록 돕습니다.

2) 병합 전략

feature → develop 병합: 기능 개발이 완료되면 develop 브랜치에 병합하여 테스트합니다.
develop → release 병합: 배포 준비가 완료되면 release 브랜치를 만들어 최종 검증을 진행합니다.
release → main 병합: release 브랜치의 최종 검증이 완료되면 main에 병합하고, 배포합니다. 동시에 release 브랜치를 develop에도 병합하여 최신 상태를 유지합니다.
hotfix → main 및 develop 병합: 운영 환경의 긴급한 버그를 수정할 때는 hotfix 브랜치를 만들어 작업하고, 수정이 완료되면 main과 develop에 병합하여 두 브랜치의 싱크를 유지합니다.

3) 커밋 관리

커밋 메시지를 명확하게 작성하여 변경 사항을 추적할 수 있도록 합니다. 예를 들어, 이슈 번호와 함께 "Fix login error (issue #123)"와 같이 작성합니다.
기능 단위로 커밋: 각 커밋은 가능한 작은 기능 단위로 작성하여, 필요 시 선택적으로 병합하거나 되돌릴 수 있도록 합니다.

4) CI/CD와 연계

Continuous Integration/Continuous Deployment (CI/CD) 도구를 활용하여 develop, release, main 브랜치에 병합될 때 자동으로 테스트를 실행하고, 코드 품질을 검증합니다. 이를 통해 버그를 조기에 발견하고 배포 안정성을 확보할 수 있습니다.

5. Git Flow의 한계와 보완점

복잡성: 브랜치가 많아질 수 있으므로, 브랜치 관리가 복잡해질 수 있습니다. 이를 보완하려면 팀원 간의 명확한 규칙과 커뮤니케이션이 중요합니다.
동기화: develop과 main 브랜치의 싱크를 주기적으로 맞춰야 하며, 특히 긴급 수정(hotfix) 후에는 이 작업을 꼭 수행해야 합니다.

6. 결론

Git Flow는 소프트웨어 개발의 모든 단계에서 발생하는 다양한 요구 사항을 충족하기 위한 체계적인 브랜치 전략입니다. 이 방식의 핵심은 각 브랜치의 역할을 명확히 규정하고, 이를 엄격히 지키는 것입니다. 이렇게 함으로써 협업 과정에서 혼란을 줄이고, 안정적인 코드를 배포할 수 있습니다.

Git Flow를 통해 브랜치 관리가 체계적으로 이루어지면, 팀 전체의 개발 효율성이 높아지고, 배포 시 발생할 수 있는 위험을 최소화할 수 있습니다. 규칙을 지키는 것은 단순히 브랜치 관리의 편의를 넘어, 소프트웨어 품질을 높이는 가장 효과적인 방법입니다.

[javascript] var, let, const 비교 및 사용법

coder_ — Wed, 18 Sep 2024 14:11:23 +0900

현대적인 JavaScript 개발에서는 const를 기본으로 사용하고, 값이 변경되어야 하는 경우에만 let을 사용한다. var는 스코프와 호이스팅 문제로 인해 사용을 지양하는 것이 일반적이다.

const의 사용 권장: 불변성을 유지하여 코드의 안정성과 예측 가능성을 높인다.
let의 보조적 사용: 변경이 필요한 변수에 한해 사용한다.

1. var

스코프(scope): 함수 스코프를 가진다. 즉, 함수 내에서 선언된 변수는 함수 전체에서 접근 가능.
호이스팅(hoisting): 변수 선언이 스코프의 최상단으로 끌어올려짐. 그러나 초기화는 선언 위치에서 이루어지므로, 선언 이전에 변수를 참조하면 undefined를 반환.
재선언 가능: 동일한 스코프 내에서 같은 이름의 변수를 재선언할 수 있음.

적절한 사용 상황

레거시 코드 유지보수: 기존에 작성된 ES5 이전의 코드나 레거시 시스템을 다룰 때 var를 사용.
함수 스코프 활용: 함수 내부 전체에서 변수가 필요할 때 var를 사용할 수 있다.

// ex1
function example() {
  console.log(a); // undefined
  var a = 1;
  console.log(a); // 1
}

// ex2
function example() {
  if (true) {
    var message = 'Hello';
  }
  console.log(message); // 'Hello'
}

2. let

스코프(scope): 블록 스코프를 가진다. {}로 감싸진 블록 내에서만 유효.
호이스팅(hoisting): 선언은 호이스팅되지만, 초기화는 호이스팅되지 않는다. 따라서 선언 이전에 변수를 참조하면 ReferenceError가 발생.
재선언 불가: 동일한 스코프 내에서 같은 이름의 변수를 재선언할 수 없다.

적절한 사용 상황

변경 가능한 변수: 값이 변경될 수 있는 변수를 선언할 때 사용.
블록 스코프 필요 시: 조건문, 반복문 등의 블록 내에서 변수가 필요할 때 let을 사용.

// ex1
{
  console.log(b); // ReferenceError
  let b = 2;
  console.log(b); // 2
}

// ex2
for (let i = 0; i < 5; i++) {
  // i는 이 블록 내에서만 유효.
}
console.log(i); // ReferenceError: i is not defined

3. const

스코프(scope): let과 동일하게 블록 스코프를 가진다.
상수 선언: 선언과 동시에 초기화해야 하며, 이후 값 변경이 불가능.
호이스팅(hoisting): let과 동일하게 동작.
재선언 불가: 동일한 스코프 내에서 재선언 가능.

적절한 사용 상황

상수 선언: 변경되지 않는 값을 선언할 때 사용.
객체와 배열의 참조 고정: 객체나 배열을 선언하고 참조를 변경하지 않을 때 사용.

// ex1
{
  const c = 3;
  c = 4; // TypeError: Assignment to constant variable.
}

// ex2
const PI = 3.14;
PI = 3.1415; // TypeError: Assignment to constant variable.

const user = { name: 'Alice' };
user.name = 'Bob'; // 가능 (프로퍼티 변경)
user = {}; // TypeError: Assignment to constant variable.

전역 변수와 지역 변수의 활용

전역 변수

var로 선언된 전역 변수: 함수 밖에서 var로 선언하면 전역 객체의 프로퍼티로 추가된다.
let과 const로 선언된 전역 변수: 스크립트의 최상위 레벨에서 선언되며, 전역 스코프를 가진다. 그러나 전역 객체의 프로퍼티는 아니다.

var globalVar = 'var';
let globalLet = 'let';
const globalConst = 'const';

console.log(window.globalVar); // 'var' (브라우저 환경)
console.log(window.globalLet); // undefined
console.log(window.globalConst); // undefined

지역 변수

함수 스코프 지역 변수: 함수 내에서 선언된 var, let, const는 함수 내부에서만 접근 가능하다.
블록 스코프 지역 변수: let과 const로 선언된 변수는 해당 블록 내에서만 유효.

function scopeTest() {
  var a = 1;
  let b = 2;
  const c = 3;

  if (true) {
    var a = 4; // 같은 함수 스코프 내에서 재선언 및 값 변경
    let b = 5; // 새로운 블록 스코프
    const c = 6; // 새로운 블록 스코프
    console.log(a, b, c); // 4, 5, 6
  }

  console.log(a, b, c); // 4, 2, 3
}

scopeTest();

Good coder

[APM-AWS-3] PHP를 통한 웹서버 구축 (로그인/홈페이지 접속) - 코드포함

프로젝트 구조

소스코드

config.php (db 정보)

db.php (db 연결)

login.php (로그인 로직 및 페이지 html)

Index.php (로그인 후 접속하는 홈페이지)

auth.php (세션 체크)

[APM-AWS-2] MySQL 설치 / Lightsail (Ubuntu)

MySQL 설치

MySQL 접속

MySQL 외부 접속 허용 설정 (서버 사이드)

[APM-AWS-1] Apache2-PHP 설치 / Lightsail Ubuntu 24.04

서버 환경

APM 설치

Apache2 설치

PHP 설치

Teams 휴가 시스템 구축 - Microsoft 365 (Automate 자동화, Power Apps 연동)

Microsoft 365 기반 휴가 신청 및 승인 자동화 시스템 구축 기록

시스템 개요

사용한 도구 및 역할

프로세스 요약

도입 후기

추가로 생각해볼 개선점

[CI/CD] GCP 서버 CI/CD 파이프라인 구축 (Github Actions)

1. 프로젝트 환경 구성

2. 의존성 이슈 대응 (googlebigquery)

3. CI 파이프라인 구성 (GitHub Actions)

트리거 조건

주요 작업 흐름

4. CD (배포 자동화) 전략

[GCP] Bastion Host VM 서버 구축 (Proxy, OS Login)

1. Bastion Host VM 설정

VM 생성 방법

주요 설정 값

추가 설정

2. Bastion Host Service 계정 생성

서비스 계정 생성

VM에 서비스 계정 연결

3. 로컬에서 Bastion Host로 접속

접속 명령어

4. Bastion Host에서 Dev VM 접속

Bastion Host 내부에서 Dev VM으로 SSH 접속

5. Bastion Host를 Proxy로 Cloud SQL MySQL 접속

Cloud SQL Auth Proxy 설치

Proxy 실행

로컬에서 Bastion Host를 통한 DB 접속

[GCP] Google Cloud Armor 적용 (feat. Custom Error page - Cloud Storage)

왜 Cloud Armor를 도입했는가

1. Cloud Armor 생성

단계별 설정

2. Load Balancer 선택 & 설정

단계별 설정

3. Cloud Storage에 403 에러 페이지 추가 후 공개 설정

단계별 설정

4. Load Balancer에 백엔드 버킷 추가 후 dev 환경에 적용

1) 백엔드 버킷 추가

2) dev 환경에 403 경로 추가

3) 정책에 403 커스텀 오류 페이지 적용

VM 방화벽과의 차이점

마무리

[Apache upgrade] 2.4.55 -> 2.4.60 version 업그레이드 (CentOS 7.9.2009)

1. Apache 버전 확인

2. Apache 다운로드 및 설치 준비

3. Apache APR 및 APR-Util 설치

4. Apache 컴파일 및 설치

5. 포트 변경 후 테스트

6. 기존 Apache에서 새 Apache로 전환

7. 필요 없는 파일 정리

[GIT] Git Flow - 가장 쉬운 깃 브랜치 전략 (생애 첫 기술 발표 영상)

1. Git Flow란 무엇인가?

2. Git Flow의 주요 브랜치 규칙

1) main 브랜치 (prod)

2) develop 브랜치

3) feature 브랜치

4) release 브랜치

5) hotfix 브랜치

3. 왜 Git Flow를 지켜야 하는가?

4. Git Flow 관리 방법

1) `main` 브랜치 (`prod`)

2) `develop` 브랜치

3) `feature` 브랜치

4) `release` 브랜치

5) `hotfix` 브랜치