👉 “SQL은 내가 짠다. 대신 Java 객체와의 매핑은 MyBatis가 해준다.”

MyBatis를 사용하는 이유

✅ 장점

• SQL을 직접 작성 → 쿼리 제어력 최상

• 기존 DB, 레거시 SQL과 궁합이 좋음

• 복잡한 JOIN / 서브쿼리 처리에 강함

• 성능 튜닝이 쉬움

❌ 단점

• SQL을 직접 관리해야 함

• 코드량이 JPA보다 많음

• DB 종속적인 SQL이 될 가능성 있음

MyBatis vs JPA 간단 비교

MyBatis 전체 구조

Controller
   ↓
Service
   ↓
Mapper Interface (DAO)
   ↓
Mapper XML (SQL)
   ↓
Database (MSSQL)

MyBatis 핵심 구성 요소

1️⃣ Mapper Interface (DAO)

@Mapper
public interface UserMapper {
    int insertUser(UserDTO user);
    UserDTO selectUserById(Long id);
}

• SQL과 Java를 연결하는 인터페이스
• 실제 구현체는 MyBatis가 자동 생성

2️⃣ Mapper XML (SQL 작성 공간)

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
  PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="com.example.mapper.UserMapper">

    <insert id="insertUser" parameterType="UserDTO">
        INSERT INTO users (name, email)
        VALUES (#{name}, #{email})
    </insert>

    <select id="selectUserById" parameterType="long" resultType="UserDTO">
        SELECT *
        FROM users
        WHERE id = #{id}
    </select>

</mapper>

✔ SQL을 XML로 명확하게 분리 ✔ #{} → 파라미터 바인딩 (SQL Injection 방지)

3️⃣ DTO (Data Transfer Object)

@Getter
@Setter
public class UserDTO {
    private Long id;
    private String name;
    private String email;
}

• MyBatis는 Entity 개념이 없음
• 대신 DTO/VO로 데이터 전달

Spring Boot + MyBatis 설정

application.yml

mybatis:
  mapper-locations: classpath:/mapper/**/*.xml
  type-aliases-package: com.example.domain

MyBatis 동작 흐름 (중요 ⭐)

1️⃣ Controller에서 요청 2️⃣ Service에서 비즈니스 로직 처리 3️⃣ Mapper Interface 호출 4️⃣ Mapper XML의 SQL 실행 5️⃣ 결과를 DTO로 매핑 6️⃣ Service → Controller 반환

MyBatis 파라미터 처리

단일 파라미터

WHERE id = #{id}

객체 파라미터

WHERE name = #{name}
AND email = #{email}

여러 파라미터 (@Param)

UserDTO find(@Param("name") String name,
             @Param("email") String email);

WHERE name = #{name}
AND email = #{email}

동적 SQL (MyBatis의 강력한 기능)

조건에 따라 SQL 변경

<select id="findUser" resultType="UserDTO">
    SELECT * FROM users
    <where>
        <if test="name != null">
            AND name = #{name}
        </if>
        <if test="email != null">
            AND email = #{email}
        </if>
    </where>
</select>

✔ 필요할 때만 조건 추가 ✔ 복잡한 검색 조건에 매우 유리

MyBatis에서 insert 결과 확인

int count = userMapper.insertUser(user);

if (count > 0) {
    log.info("저장 성공");
}

• 반환값 = 영향받은 row 수
• 저장 성공 여부 판단에 자주 사용

MyBatis는 Repository가 없다?

✔ 맞다. MyBatis에서는 보통

Mapper = DAO = Repository 역할

즉, @Repository 대신 @Mapper 를 사용한다.

정리

• MyBatis는 SQL 중심 데이터 접근 프레임워크

• JPA보다 자유도와 성능 제어력이 뛰어남

• 실무, 운영 시스템에서 매우 많이 사용

• Spring Boot + MSSQL 조합에서 특히 강력

MSSQL(Microsoft SQL Server)은 마이크로소프트(Microsoft)에서 개발한 관계형 데이터베이스 관리 시스템(RDBMS)이다.

주로 기업용 시스템, 사내 인트라넷, Windows 서버 환경에서 많이 사용되며 대규모 트랜잭션 처리와 안정성을 강점으로 가진 DB이다.

✔ 줄여서 MS SQL, SQL Server라고도 부른다.

2️⃣ MSSQL의 기본 구성

MSSQL을 사용하면 보통 아래 구성으로 개발하게 된다.

🔹 SQL Server (DB 엔진)

• 실제 데이터를 저장하고 처리하는 핵심 서버

• 백엔드(Spring Boot 등)와 직접 연결되는 대상

🔹 SSMS (SQL Server Management Studio)

• MSSQL 전용 관리 도구

• 테이블 생성, 쿼리 실행, 데이터 확인, 인덱스 관리 등을 수행

  Spring Boot ── JDBC/JPA ── SQL Server ── 실제 데이터
                    ↑
                  SSMS
  

> 👉 실무에서는
- 개발자는 SSMS로 테이블 구조 확인
- 애플리케이션에서는 Spring Boot에서 쿼리 실행

---

## 3️⃣ MSSQL의 주요 특징
#### ✅ 1. 기업용 DB에 특화

- 금융, 공공기관, 사내 시스템에서 많이 사용

- 대용량 데이터 처리와 안정성이 강점

#### ✅ 2. Transact-SQL (T-SQL) 사용

- MSSQL 전용 SQL 문법 제공

- 변수 선언, 조건문, 반복문 가능
```sql
DECLARE @count INT;
SET @count = 10;

SELECT @count;

👉 MySQL에서는 거의 쓰지 않는 문법

✅ 3. Windows 친화적인 환경

• Windows Server + Active Directory와 궁합이 좋음

• 사내 계정 기반 보안 관리가 쉬움

✅ 4. 강력한 트랜잭션 관리

• BEGIN TRANSACTION

• COMMIT

• ROLLBACK

  BEGIN TRANSACTION;
  

INSERT INTO TB_USER VALUES ('test', '1234');

ROLLBACK;

---

## 8️⃣ MSSQL 기본 문법 (T-SQL 핵심 정리)

MSSQL은 표준 SQL + T-SQL(Transact-SQL) 문법을 사용한다.
MySQL과 비슷하지만 변수, 조건문, 트랜잭션, TOP, IDENTITY 같은 MSSQL 전용 문법이 많다.

#### 🔹 1. 데이터 조회 (SELECT)
```sql
SELECT * FROM TB_USER;

• 특정 컬럼 조회

  SELECT user_id, user_name
  FROM TB_USER;

• 조건 조회

SELECT *
FROM TB_USER
WHERE user_id = 'admin';

🔹 2. TOP (MSSQL 전용)

👉 LIMIT 대신 TOP 사용

SELECT TOP 10 *
FROM TB_BOARD
ORDER BY created_at DESC;

• MySQL 비교

-- MySQL
SELECT * FROM TB_BOARD LIMIT 10;

🔹 3. INSERT / UPDATE / DELETE

• INSERT

  INSERT INTO TB_USER (user_id, password, name)
  VALUES ('test', '1234', '홍길동');
  

- **UPDATE**
```sql
UPDATE TB_USER
SET name = '김철수'
WHERE user_id = 'test';

• DELETE

  DELETE FROM TB_USER
  WHERE user_id = 'test';

🔹 4. 변수 선언 (T-SQL 핵심)

👉 MSSQL에서 매우 자주 사용

DECLARE @userCount INT;

SET @userCount = (
    SELECT COUNT(*)
    FROM TB_USER
);

SELECT @userCount AS userCount;

✔ MySQL에는 거의 없는 문법 ✔ 프로시저, 동적 SQL, 배치 작업에서 필수

🔹 5. IF / ELSE 조건문

DECLARE @count INT;
SET @count = 5;

IF @count > 0
    PRINT '데이터 있음';
ELSE
    PRINT '데이터 없음';

🔹 6. 트랜잭션 (실무 핵심 ⭐)

BEGIN TRANSACTION;

INSERT INTO TB_ORDER VALUES ('order1', 1000);
INSERT INTO TB_PAYMENT VALUES ('pay1', 1000);

-- 문제가 없으면
COMMIT;

-- 오류 발생 시
ROLLBACK;

👉 Spring Boot의 @Transactional과 개념 동일

🔹 7. 자동 증가 컬럼 (IDENTITY)

CREATE TABLE TB_BOARD (
    board_id INT IDENTITY(1,1) PRIMARY KEY,
    title NVARCHAR(100),
    content NVARCHAR(MAX)
);

🔹 8. 날짜 함수

SELECT GETDATE();        -- 현재 날짜 + 시간
SELECT CONVERT(DATE, GETDATE()); -- 날짜만

🔹 9. NULL 처리 (IS NULL)

SELECT *
FROM TB_USER
WHERE phone IS NULL;

🔹 10. LIKE 검색

SELECT *
FROM TB_USER
WHERE name LIKE '%홍%';

🔹 11. JOIN

SELECT u.user_id, o.order_id
FROM TB_USER u
INNER JOIN TB_ORDER o
ON u.user_id = o.user_id;

🔹 12. 스키마(dbo)란?

SELECT *
FROM dbo.TB_USER;

• dbo = 기본 스키마
• 테이블 소유자 개념
• 명시하지 않으면 자동으로 dbo 사용됨

🔹 13. 대괄호 [] 문법

SELECT *
FROM [User];

✔ 예약어 사용 ✔ 공백 포함 컬럼명 ✔ 기존 테이블 스크립트에 자주 등장

4️⃣ MSSQL vs MySQL 차이

6️⃣ Spring Boot에서 MSSQL 사용 흐름

1. MSSQL + SSMS 설치
2. 데이터베이스 & 테이블 생성
3. Spring Boot에 JDBC 드라이버 추가
4. application.yml 또는 properties 설정
5. JPA / MyBatis / JDBC로 연동

   spring:
   datasource:
    url: jdbc:sqlserver://localhost:1433;databaseName=testdb
    username: sa
    password: ****
   

```

7️⃣ 정리

✔ MSSQL은 기업 환경에서 매우 많이 사용되는 DB ✔ T-SQL이라는 강력한 전용 문법 제공 ✔ Spring Boot와도 문제없이 연동 가능 ✔ 실무 백엔드 개발자라면 알아두면 반드시 도움 되는 DB

백엔드 개발을 공부하다 보면 가장 많이 듣게 되는 단어 중 하나가 바로 Spring Boot다. 그렇다면 Spring Boot는 정확히 무엇이고, 왜 이렇게 많이 사용될까?

이번 글에서는 Spring Boot의 개념, 등장 배경, 특징, 그리고 왜 사용하는지를 정리해본다.

Spring Boot란?

👉 Spring Framework를 더 쉽고 빠르게 사용하기 위해 만들어진 프레임워크이다.

기존 Spring은 강력하지만,

• 설정 파일이 많고

• 초기 환경 설정이 복잡하며

• 서버 설정까지 직접 해야 하는 경우가 많았다

이런 불편함을 해결하기 위해 등장한 것이 Spring Boot다.

Spring Boot가 등장한 이유

기존 Spring Framework의 문제점은 다음과 같았다.

• XML 설정 파일이 너무 많음

• 프로젝트 시작 전에 해야 할 설정이 많음

• 톰캣 같은 WAS를 따로 설치해야 함

• 작은 기능 하나 만드는데도 준비 과정이 김

👉 Spring Boot는 이 모든 과정을 자동화했다.

Spring Boot의 핵심 특징

1️⃣ 자동 설정 (Auto Configuration)

Spring Boot는 의존성만 추가하면 필요한 설정을 자동으로 처리해준다.

spring-boot-starter-web 추가
→ Tomcat 자동 설정
→ DispatcherServlet 자동 등록
→ MVC 설정 자동 완료

✔️ 개발자는 설정이 아니라 비즈니스 로직에만 집중하면 된다.

2️⃣ 내장 서버 (Embedded Server)

Spring Boot는 내장 Tomcat을 포함하고 있다.

java -jar app.jar

이 명령어 하나로 서버 실행 가능 ❗

✔️ 별도의 WAS 설치 불필요 ✔️ 배포가 매우 간단

3️⃣ Starter Dependency

Spring Boot는 자주 쓰는 라이브러리를 묶어서 제공한다.

✔️ 의존성 충돌 걱정 ↓ ✔️ 설정 시간 ↓

4️⃣ 설정의 단순화 (application.yml / properties)

과거 XML 설정 대신 application.yml 또는 application.properties 파일 하나로 설정 관리

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/test

✔️ 가독성 좋음 ✔️ 환경별 설정 분리 가능 (dev, prod)

Spring vs Spring Boot 차이

👉 요즘 Spring 개발 = 거의 Spring Boot

Spring Boot는 언제 사용될까?

• REST API 서버

• React / Vue와 연동되는 백엔드

• 사내 시스템 (인트라넷)

• 스타트업 MVP 개발

• 마이크로서비스 아키텍처

✔️ 실무 백엔드 개발의 표준이라고 봐도 무방하다.

간단한 Spring Boot 실행 구조

요청
 ↓
Controller
 ↓
Service
 ↓
Repository
 ↓
Database

Spring Boot는 이 구조를 가장 빠르게 만들 수 있도록 도와주는 도구다.

마무리

Spring Boot는

• Spring의 장점은 그대로 유지하면서

• 복잡한 설정을 제거하고

• 빠른 개발과 쉬운 배포를 가능하게 만든 프레임워크다.

👉 백엔드 개발을 시작한다면, Spring Boot는 거의 필수 선택지라고 할 수 있다.

스택(Stack)은 한쪽(top)에서만 원소의 삽입과 삭제가 이루어지는 자료구조입니다. 특징적으로 LIFO(Last-In-First-Out), 즉 후입선출 구조를 가집니다.

예시:

push A
push B
push C
pop → C

💡 가장 먼저 들어간 A는 가장 마지막에 꺼내질 수 있다.

※ 스택의 주요 연산

※ ADT 형식 예시

createStack()
push(item)
pop()
peek()
isEmpty()
remove()

※ 스택의 구현 방식

① 배열(Array)을 이용한 순차적 구현

• top 값으로 가장 위를 가리킨다.

• 초기 top = -1

• push 시 top++

• pop 시 top--

구조:

Stack[0] [1] [2] ... [n]
   ↑
  top

- 장점: 간단함 - 단점: 크기 제한 존재

② 연결리스트(Linked List)를 이용한 구현

• 메모리 동적 할당 가능

• top이 연결 리스트의 head 역할

구조:

top → Node(data, link) → Node → ...

• push: 새 노드를 top 앞에 삽입
• pop: top을 삭제 후 link를 top으로 변경
  - 장점: 크기 제한 없음
• - 단점: 구현 약간 복잡*

※ 스택의 대표적 활용

✔ 수식의 괄호 검사

{ [ ( ) ] }

• 여는 괄호 push

• 닫는 괄호 pop으로 비교

• empty & mismatch 판별

✔ 후위 표기법(Postfix) 계산

중위: A + B * C 후위: A B C * +

스택 단계:

1. 피연산자 push

2. 연산자 만나면 pop 두 번 → 연산 → push

✔ 실행 시간 스택 (추가 응용)

함수 호출 → 스택 push 함수 종료 → pop

• 활성화 레코드 관리

• 재귀 호출 시 스택 증가

✔ 미로 탐색 (DFS 방식)

좌표, 방향을 스택에 저장하며 백트래킹

📗 스택의 특징 정리

• 하나의 링크 필드를 가진 노드들이 모두 자기 후속노드와 연결되어 있는 노드 열
• 마지막 노드의 링크 필드는 리스트의 끝을 표시하는 null값을 가짐
• 별칭 : 선형 연결 리스트(linear linked list), 단순 연결 선형 리스트(singly linked linear list), 연결 리스트(linked list), 체인(chain)
• 단순 연결 리스트의 예

노드 구조 정의

● 원소 삽입 알고리즘

• 예) 리스트 L에 원소 “Han”을 “Cho”와 “Kim” 사이에 삽입
  1. 공백노드를 획득함. newNode라는 변수로 가리키게 함
  2. newNode의 data 필드에 “Han”을 저장
  3. “Cho”를 저장하고 있는 노드의 link 값을 newNode의 link 필드에 저장 (즉 “Kim”을 저장하고 있는 노드의 주소를 newNode의 link에 저장)
  4. “Cho”를 저장한 노드의 link에 newNode의 포인터 값 을 저장
• 리스트의 기존 원소들을 이동시킬 필요 없음
• 부수적인 link 필드를 위해 저장 공간을 추가로 사용

● 원소 삭제 알고리즘

• 예) 리스트 L에서 원소 “Han”을 삭제
  1. 원소 “Han”이 들어 있는 노드의 선행자 찾음 (“Cho”가 들어있는 노드)
  2. 이 선행자의 link에 “Han”이 들어있는 노드의 link 값을 저장

● 메모리의 획득과 반납

• 연결 리스트가 필요로 하는 두 가지 연산

  • 데이타 필드와 하나의 링크 필드를 가진 하나의 공백 노드 를 획득하는 방법
  • 사용하지 않는 노드는 다시 반납하여 재사용하는 방법

• 자유 공간 리스트 (free space list) 가 있는 경우

  • getNode()

  • 데이타와 링크 필드로 되어 있는 새로운 공백 노드를 가용 공간 리스트로부터 할당받아 그 주소를 반환하는 함수

    • returnNode()

  • 포인터 변수 P가 지시하는 노드를 가용 공간 리스트에 반 환하는 함수
  • 프로그래밍 언어에 따라 필요한 경우도 있고 필요하지 않은 경우도 있음
  • Java와 같이 사용하지 못하는 노드를 자동으로 관리해 주 는 언어에서도 사용자가 직접 관리할 필요가 있는 경우도 있음

기본 연산

● 리스트 생성 알고리즘

• 앞의 두 함수를 사용한 리스트 생성 알고리즘

• 리스트 생성 알고리즘을 점 표기식으로 작성한 경우

● 노드 삽입 알고리즘

• 리스트 L의 첫번째 노드로 data 값이 x인 노드를 삽입

• 원소값이 x인 노드를 p가 가리키는 노드 다음에 삽입

  • (a) L이 공백 리스트인 경우
  • (b) P가 null인 경우
  • (c) L과 p가 null이 아닌 경우

• 리스트 L의 마지막 노드로 원소값 x를 첨가

● 노드 삭제 알고리즘

• 리스트 L에서 p가 가리키는 노드의 다음 노드를 삭제

• 리스트에서 마지막 노드를 삭제하는 프로그램

  • currentNode와 previousNode의 동작 과정 － currentNode 포인터가 어떤 노드를 가리키면 previousNode 포인 터는 currentNode가 가리키는 노드의 바로 직전 노드를 가리키도록 함 － currentNode가 리스트의 마지막 노드를 가리키게 될 때 previousNode는 마지막 두 번째 노드를 가리키게 됨

● 리스트 역순 알고리즘

• 리스트를 역순으로 만드는 알고리즘

● 리스트 연결 알고리즘

• 두개의 리스트 L1과 L2를 하나로 만드는 알고리즘

● 원소 탐색 알고리즘

• 데이타 값이 x인 노드를 찾는 알고리즘

• 데이타 값이 x인 노드를 찾는 알고리즘의 Java 구현

● 리스트 출력 알고리즘

• 연결 리스트의 프린트

💻 예제 프로그램

● ListNode 클래스

• data 필드와 link 필드를 가진 객체 구조를 정의
• 이 필드들을 초기화시키기 위해 생성자 정의

● LinkedList 클래스

• 실제 연결 리스트를 정의
• head 필드 : private, ListNode 타입으로 선언, 연결 리스트의 첫 번째 노드를 가리킴

● LinkedList 생성의 예

• LinkedList L = new LinkedList();

• L에 노드가 연결되어 있는 경우

◆ 단순 연결 리스트의 처리

git에 하나의 폴더만 commit하려 했는데 다른 폴더들까지 같이 올라간 상황

또는

commit 메시지는 하나의 폴더에 관련한 내용인데 실제로 다른 파일까지 push된 상황

⚙️ 해결 방법

1. 최근 commit만 취소하고, 수정사항은 유지

git reset --soft HEAD~1

• 최근 1개의 commit을 되돌림

• 수정한 파일들은 그대로 유지됨

• 즉, “commit만 취소” 상태

2. DS_08만 선택해서 다시 commit

git reset        # 모든 파일을 unstaged 상태로 되돌림
git add '폴더'    # 업로드를 원하는 폴더만 staging
git commit -m "DS_08 문제 해결"

4. GitHub에 강제 반영 (push -f)

git push -f

⚠️ -f(force)는 원격 저장소의 기록을 덮어쓰므로, 혼자 작업할 때만 사용하는 게 안전하다.

정리: reset 옵션의 차이

결론

• 실수로 잘못 commit/push해도 git reset --soft HEAD~1 → 필요한 파일만 add → git push -f 순서로 해결 가능하다.

• 특히 혼자 작업 중이라면 force push도 문제없지만, 협업 중이라면 git revert를 사용하는 게 안전하다.

1. GitHub 준비

1. GitHub 계정 로그인
2. 새 저장소 만들기 → https://github.com/new
3. 저장소 이름 입력
4. “Initialize with README” 체크 해제!
5. “Create Repository” 클릭

→ 저장소 주소 예: https://github.com/사용자명/"저장소이름".git

2. IntelliJ에서 Git 활성화

1. File → Open → D:\자료구조 선택

2. 상단 메뉴 → VCS → Enable Version Control Integration...

3. Git 선택 → OK

4. 프로젝트 루트에 .git 폴더가 생기면 성공

터미널에서 확인:

git status

3. .gitignore 설정 (필수)

불필요한 파일이 올라가지 않도록 필터 역할을 합니다

📄 프로젝트 루트에 .gitignore 생성 후 아래 내용 추가:

# IntelliJ 설정
.idea/
*.iml
out/

# Eclipse (겸용)
bin/

# Java 빌드 결과물
*.class

# OS 자동 생성 파일
.DS_Store
Thumbs.db

# 기타
*.zip
*.log

4. GitHub 연결 (최초 1회만)

하단 Terminal 탭에서 아래 명령어 입력

git branch -M main
git remote add origin https://github.com/<계정명>/"저장소이름".git

5. 터미널로 커밋 & 푸시

• 변경 확인

  git status

• 변경 파일 추가

  git add .

• 커밋 메시지 작성

  git commit -m "내용"

• GitHub에 업로드

  git push -u origin main //main branch에 업로드

이후에는 git push만 써도 됩니다

6. 이후 반복 루틴

새 파일 추가나 수정 후엔 이 3줄만 입력하면 됩니다!!!

git add .
git commit -m "내용"
git push

※ 커밋 메시지 규칙 정리

7. 커밋 로그 확인

git log --oneline

결과 예시:

b1a2c3d feat: 큐 구현 코드 추가
d2e3f4a feat: 스택 기능 완성

💡 자주 쓰는 Git 명령 요약표

📗 최종 요약

1. VCS → Enable Version Control → Git
2. .gitignore 생성
3. git add .
4. git commit -m "메시지"
5. git push

IntelliJ와 Git을 연동해두면, 앞으로의 프로젝트 관리가 훨씬 깔끔해집니다.

“default 보안그룹이 있는데, 왜 내가 건드린 launch-wizard-1만 적용될까?”

그리고 AWS에서 EC2를 처음 배포할 때 가장 많이 겪는 문제가 바로 이겁니다.

“Nginx까지 설치했는데 http://<EC2 퍼블릭 IP> 접속이 안 돼요!”

저도 이번에 웹서버 구축 프로젝트를 EC2에 직접 배포하면서 이 문제를 정확히 겪었고, 결국 원인과 구조를 이해하게 됐습니다.

이 글에서는 ✅ 보안그룹의 기본 원리 ✅ default vs launch-wizard 차이 ✅ 제가 겪은 실제 트러블슈팅 과정 위 3가지를 정리해보겠습니다.

💡 1. 보안그룹(Security Group)이란?

AWS의 보안그룹은 EC2 인스턴스 단위의 방화벽입니다. 즉, “이 인스턴스가 어떤 트래픽을 주고받을 수 있는가?”를 결정합니다.

• 인바운드(Inbound) → 외부 → EC2 (예: 브라우저 접근, SSH 연결)

• 아웃바운드(Outbound) → EC2 → 외부 (예: apt install, API 요청 등)

보안그룹이 허용하지 않은 트래픽은, 서버에서 Nginx가 잘 돌아가도 외부에서 절대 접근할 수 없습니다.

2. EC2 생성 시 보안그룹 연결 원리

AWS는 EC2를 생성할 때 자동으로 하나의 보안그룹을 연결합니다. 이때 어떤 그룹이 연결되는지는 EC2 생성 시 옵션에 따라 달라집니다.

3. default vs launch-wizard 비교표

💥 4. 실제 트러블슈팅 사례: “Nginx 접속 안 됨”

🧩 문제 상황

AWS EC2 인스턴스에 Nginx를 설치하고 sudo systemctl status nginx로 확인해보면 active (running) 상태. 포트도 0.0.0.0:80으로 잘 열려 있음.

그런데도 브라우저에서 http://<퍼블릭 IP> 접속 시 아무 응답이 없음.

ssh -i "gangwonfocus-key.pem" ubuntu@<Public IP>
curl http://localhost     # 정상 동작

즉, 서버 내부에서는 잘 뜨는데 외부에서는 접속 불가 상태였습니다.

🔍 원인 분석

AWS 보안그룹 인바운드 규칙을 확인했는데, HTTP(80), HTTPS(443), SSH(22)가 모두 허용돼 있었음. 그래서 처음엔 "보안그룹 문제는 아니다"라고 착각.

하지만 인스턴스 상세 탭을 다시 보니, 실제로 적용된 보안그룹 이름이 launch-wizard-1 이었습니다. 그런데 내가 설정했던 규칙은 default 보안그룹이었습니다.

즉, 규칙은 default에 추가했지만, EC2는 launch-wizard-1을 사용 중이라서 실제로는 아무 트래픽도 허용되지 않았던 것!

✅ 해결 방법

1. EC2 → 보안 탭 → launch-wizard-1 클릭

2. 인바운드 규칙에 다음 항목 추가

   유형(Type)	프로토콜	포트	소스(Source)
   HTTP	TCP	80	0.0.0.0/0
   HTTPS	TCP	443	0.0.0.0/0
   SSH	TCP	22	0.0.0.0/0

3. 저장 후 브라우저에서 다시 접속 “Welcome to nginx!”

💬 배운 점

• EC2 인스턴스가 어떤 보안그룹에 연결되어 있는지 항상 확인할 것.

• 규칙을 잘못된 그룹(default 등)에 추가해봤자 아무 효과 없음.

• 보안그룹 이름이 launch-wizard-1, launch-wizard-2 처럼 자동 생성될 수 있으니 의미 있는 이름으로 바꿔두면 헷갈리지 않는다.

5. 보안그룹 관리 팁

보안그룹 이름은 서비스별로 명확하게 바꿔주자! 예시:

이름만 봐도 역할이 드러나게 하면, 나중에 CI/CD, RDS 연결, HTTPS 설정할 때 훨씬 깔끔하게 관리됩니다.

결론

• AWS EC2 생성 시 자동 연결되는 보안그룹은 대부분 launch-wizard-#

• default는 내부 통신용이며 외부 접근 불가

• 포트(80, 22, 443 등) 허용은 EC2가 실제로 연결된 보안그룹에 해야 함

• 보안그룹을 잘못 설정해도 AWS는 별다른 에러를 주지 않기 때문에, 접속 불가 문제 발생 시 항상 “인스턴스 → 보안 탭 → 실제 그룹 이름”부터 확인!

StringTokenizer은 Java에서 문자열을 특정 구분자(delimiter)를 기준으로 잘라주는 클래스입니다. split() 메서드와 비슷하지만, 더 가볍고 빠른 동작을 위해 만들어졌습니다.

🔹 기본 사용법

import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) {
        String str = "apple,banana,orange";

        // 구분자: ","
        StringTokenizer st = new StringTokenizer(str, ",");

        while (st.hasMoreTokens()) {
            System.out.println(st.nextToken());
        }
    }
}

출력

apple banana orange

🔹 주요 메서드

🔹 split()과의 차이점

🔹 활용 예시 (코딩테스트)

import java.io.*;
import java.util.StringTokenizer;

public class FastInput {
    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        int T = Integer.parseInt(br.readLine());

        for (int i = 0; i < T; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine(), " ");
            int A = Integer.parseInt(st.nextToken());
            int B = Integer.parseInt(st.nextToken());
            System.out.println(A + B);
        }
    }
}

장점

• 입력값이 공백 단위로 구분될 때 빠르게 처리 가능

• 별도의 배열 선언 없이 순차적으로 값 꺼내기 가능

🔹 언제 쓰면 좋을까?

• 입력 데이터가 공백 또는 단순 구분자로 구분될 때

• 빠르고 가벼운 파싱이 필요할 때

• 코딩테스트에서 split() 대신 빠른 성능이 필요할 때

📗정리

• StringTokenizer는 문자열을 구분자 단위로 잘라주는 클래스

• split()과 다르게 순차 접근만 가능하지만, 속도가 빠름

• 코딩테스트에서 입력 처리 최적화할 때 자주 사용

코딩테스트에서 입력 속도가 느려서 시간 초과를 겪은 적 있나요? 자바의 기본 입력 도구인 Scanner는 편리하지만 속도가 느려서 대량 입력에는 불리합니다. 이때 사용하는 것이 바로 BufferedReader입니다.

🔍 BufferedReader란?

• 자바에서 문자 기반 입력을 버퍼링하여 효율적으로 읽어들이는 클래스

• InputStreamReader와 함께 사용하여 System.in(표준 입력)을 읽음

• 코딩테스트에서는 빠른 입력 처리를 위해 사실상 필수

  BufferedReader는 문자 입력 스트림을 버퍼링(buffering)해서 읽는 클래스입니다. 즉, 한 글자씩 읽는 대신 버퍼(임시 메모리 공간)를 이용해 대량으로 읽어와서 성능을 높여줍니다. 보통 InputStreamReader와 함께 사용하여 콘솔 입력(System.in)을 효율적으로 읽습니다.

🛠️ 기본 구조

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

🧩 주요 메서드

✨ 사용 예시

🔹 한 줄 입력 받기

import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        String input = br.readLine(); // 한 줄 입력
        System.out.println("입력값: " + input);
    }
}

🔹 여러 정수 입력 받기

String[] numbers = br.readLine().split(" ");
int a = Integer.parseInt(numbers[0]);
int b = Integer.parseInt(numbers[1]);

System.out.println(a + b);

⚡ BufferedReader vs Scanner

🚀 정리

• BufferedReader = 빠른 입력 처리용 클래스

• readLine()으로 문자열 입력 → 필요 시 split()과 Integer.parseInt()로 변환

• flush()는 입력이 아니라 출력 스트림에서만 사용

• 코딩테스트에서는 Scanner 대신 BufferedReader + StringBuilder/BufferedWriter 조합이 정석

이번 글에서는 JWT가 무엇이고, 왜 필요한지, 어떻게 사용하는지 정리해보겠습니다.

📌JWT(Json Web Toekn) 정의

JWT(Json Web Token) 는 웹 표준(RFC 7519)으로 정의된 인증 및 정보 교환을 위한 토큰 형식입니다.

• JSON 포맷으로 데이터를 담습니다.

• 전자서명(Signature) 을 포함해 위·변조를 방지합니다.

• 서버가 세션을 직접 저장하지 않아도 되므로 Stateless 인증 방식에 활용됩니다.

즉, 클라이언트가 JWT를 가지고 있으면 서버는 추가 DB 조회나 세션 저장소 없이도 사용자의 신원을 확인할 수 있습니다.

1. JWT 구조

JWT는 Header.Payload.Signature 형태의 세 부분으로 구성됩니다.

xxxxx.yyyyy.zzzzz

### 2. JWT 동작 과정
1. 로그인 요청 → 사용자가 ID/PW를 서버에 전달

2. 토큰 발급 → 서버가 사용자 정보를 확인 후 JWT 생성, 클라이언트에 전달

3. 인증 요청 → 클라이언트가 API 요청 시 Authorization: Bearer <JWT> 헤더에 담아 전달

4. 서버 검증 → 서버는 비밀키로 JWT 서명(Signature) 검증 후 권한 체크

5. 응답 → 정상 요청이면 데이터 반환

👉 세션/쿠키 기반 인증과 달리 서버가 상태(state)를 저장하지 않기 때문에 Stateless 인증이라고 부릅니다.

### 3. JWT의 장점

- Stateless: 서버에 세션 저장소가 필요 없음

- 확장성: 마이크로서비스, 다른 도메인 간 인증에 용이

- 보편성: OAuth2, OpenID Connect 등 다양한 인증 표준에서 활용

### 4. JWT의 단점

- 토큰 크기: Payload에 많은 정보를 넣으면 크기가 커짐 → 네트워크 부담

- 무효화 어려움: 발급된 토큰은 만료 전까지 유효 → 강제 로그아웃 처리 어려움

- 보안 취약성: 토큰 탈취 시 그대로 사용 가능 → 반드시 HTTPS 필요
>  💡 보안 고려사항
  - 토큰 저장 위치
      - localStorage: 간단하지만 XSS 공격에 취약
    - HttpOnly Cookie: 보안성 ↑, 하지만 CORS 설정 필요
  - 토큰 만료 시간 설정
    - Access Token 짧게, Refresh Token 길게 → 재발급 전략 필요
  - HTTPS 필수
    - 평문 전송 시 토큰 탈취 위험


### 5. JWT의 활용 예시

- 웹/모바일 로그인 인증

- OAuth2 기반 SNS 로그인 (구글, 네이버, 카카오)

- API 서버 간 통신 인증 (Microservice 환경)

- Refresh Token 전략으로 장기 세션 유지

  <br>

## 📗정리
> JWT는 현대 웹 서비스에서 인증의 핵심 요소입니다.
하지만 만능은 아니며, 적절한 만료 정책, 저장 전략, Refresh Token 운용 등을 함께 고려해야 안전한 인증 시스템을 만들 수 있습니다.

1. 기본 개념

📌 JSP (Java Server Pages)

• 서버 사이드 렌더링(SSR) 기술.

• HTML 코드 안에 Java 코드를 삽입하여 동적으로 페이지를 생성.

• 요청이 올 때마다 서버에서 JSP를 컴파일/실행하여 HTML을 생성한 뒤 브라우저에 전달.

📌 React

• 클라이언트 사이드 렌더링(CSR) 기반의 자바스크립트 라이브러리.

• 컴포넌트 단위로 UI를 구성하며, 데이터 변화에 따라 브라우저에서 즉각적으로 UI 갱신.

• SPA(Single Page Application) 개발에 특화.

2. 렌더링 방식

📌 JSP (Java Server Pages)

요청(Request) → 서버에서 JSP 처리 → HTML 완성 → 브라우저에 전달. (새로운 페이지 요청마다 서버와 통신)

📌 React

최초에 빈 HTML + JS 번들 로드 → 이후에는 브라우저에서 Virtual DOM을 이용해 필요한 부분만 갱신. (빠른 UI 업데이트, 서버 요청 최소화)

3. 개발 패러다임

📌 JSP (Java Server Pages)

• 전통적인 MVC 패턴에서 View 역할을 담당.

• Java 코드와 HTML이 섞여서 유지보수가 어려워질 수 있음.

• ** 서버 중심 개발.**

📌 React

• 컴포넌트 기반 개발: UI를 재사용 가능한 작은 단위로 분리.

• 상태 관리(State, Props)를 통한 동적 렌더링.

• ** 클라이언트 중심 개발.**

4. 성능 및 사용자 경험

📌 JSP (Java Server Pages)

• 매 요청마다 페이지 전체 새로고침 → UX가 무겁고 느리게 느껴질 수 있음.

• 초기 로딩은 빠르지만, 자주 이동하는 경우 비효율적.

📌 React

• 초기 로딩 시 JS 번들 크기 때문에 무거울 수 있음.

• 하지만 이후엔 부분 갱신(빠른 UI 반응) 덕분에 UX가 우수.

5. 활용 사례

📌 JSP (Java Server Pages)

• 예전 기업용 웹 애플리케이션, 관리자 페이지 등.

• 서버 렌더링 기반이라 SEO(검색 엔진 최적화)에는 유리.

📌 React

• 최신 웹 서비스(네이버, 카카오, 넷플릭스 등).

• 사용자와 상호작용이 많은 SPA 개발에 적합.

📄 React vs JSP 비교 표

📝 결론

JSP는 서버에서 완성된 HTML을 내려주는 서버 사이드 렌더링 방식이고, React는 브라우저에서 동적으로 화면을 그려주는 클라이언트 사이드 렌더링 방식입니다. JSP는 전통적인 MVC 구조와 잘 맞고, React는 컴포넌트 기반 SPA 개발에 특화되어 있습니다. 즉, JSP는 서버 중심, React는 클라이언트 중심이라고 이해하면 쉽습니다.

대표적으로 Fetch API와 Axios가 많이 사용되는데, 이 둘의 차이를 정리해보겠습니다.

📌 Axios란?

• 외부 라이브러리 (설치 필요: npm install axios)
• Fetch보다 다양한 기능을 지원
• JSON 자동 파싱, 에러 자동 처리, 요청/응답 인터셉터 등 실무에서 많이 사용됨

👉 예시:

import axios from "axios";

axios.get("/api/user")
  .then(response => {
    console.log(response.data);
  })
  .catch(error => {
    console.error(error);
  });

📌 Fetch API란?

• 브라우저에 기본 내장된 HTTP 요청 기능
• 추가 설치 없이 바로 사용 가능
• ES6부터 공식적으로 제공됨

👉 예시:

fetch("/api/user")
  .then(response => {
    if (!response.ok) {
      throw new Error("HTTP Error: " + response.status);
    }
    return response.json();
  })
  .then(data => console.log(data))
  .catch(err => console.error(err));

🛠️ Axios vs Fetch 차이 정리

💡왜 Axios를 더 많이 쓸까?

• 인터셉터(Interceptor): 요청 전/후 가로채서 공통 로직 적용 가능 (ex. JWT 토큰 자동 첨부)
• 에러 처리 간편: 400, 500 에러도 catch로 바로 감지 가능
• 브라우저 호환성: 다양한 브라우저 지원
• 코드 가독성: 짧고 직관적인 코드 작성 가능

🔍 정리하자면

• 간단한 요청 → Fetch로도 충분
• 실무/프로젝트 규모가 크다 → Axios 추천

✍🏼 결론:

"Fetch는 가볍고 기본적인 요청에 적합하고, Axios는 실무에서 확장성과 편리성을 고려할 때 더 많이 사용된다."

GitHub 저장소에서 localletter-frontend 폴더에 화살표 아이콘이 붙어 있었고, 클릭해도 코드가 보이지 않았다.

git ls-files -s localletter-frontend
160000 c085f971aae08fa5eeeb787ab869a473d5a30f77 0       localletter-frontend

로컬에서 확인해보니, 해당 폴더가 서브모듈로 잘못 커밋된 상태였다.

• 160000 → 서브모듈(gitlink) 모드
• .gitmodules 파일이 없어 연결이 깨진 상태

2. 원인

• 과거에 git submodule add 또는 비슷한 실수로 폴더를 서브모듈로 커밋함

• .gitmodules 파일이 삭제되어 원격 연결 정보가 사라짐

• 깃허브에서 화살표 표시 후 다른 저장소로 연결하려 함 → 폴더 내용 확인 불가

3. 해결 과정

(1) 서브모듈 추적 제거

# 서브모듈 추적 제거 (파일은 그대로 유지)
git rm --cached localletter-frontend

# .gitmodules에서 해당 섹션 삭제 (있다면)
[ -f .gitmodules ] && git add .gitmodules

# 로컬 서브모듈 메타데이터 삭제
rm -rf .git/modules/localletter-frontend

(2) 일반 폴더로 커밋

git add localletter-frontend
git commit -m "Convert frontend from submodule to regular directory"

(3) push 시 거절 오류 발생

$ git push
To https://github.com/Choi-sh01/WebServer-Project.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/Choi-sh01/WebServer-Project.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
# ! [rejected] main -> main (fetch first)

→ 원격에 내가 없는 최신 커밋이 있어서 non-fast-forward 거절

(4) 원격 변경 반영 후 푸시

# 현재 브랜치가 main인지 확인
git branch

# 원격 최신 가져오기
git fetch origin

# 원격 main 위로 내 변경을 재배치(충돌 최소화)
git pull --rebase origin main

git push

4. 배운 점

• 160000 모드는 서브모듈의 대표적인 표시
• .gitmodules가 없는데 폴더가 서브모듈로 보이면, 연결이 깨진 상태
• 깃허브에서 서브모듈 → 일반 폴더 전환은 git rm --cached로 추적만 제거 후 다시 커밋
• push 거절 시 무조건 force push가 아니라, 먼저 pull/rebase로 병합하는 습관이 안전

5. 참고 명령어

# 서브모듈 상태 확인
git submodule status
git ls-files -s <폴더명>

# 서브모듈 제거 → 일반 폴더 전환
git rm --cached <폴더명>
rm -rf .git/modules/<폴더명>
git add <폴더명>
git commit -m "Convert submodule to folder"
git push