Woojin Devlog RSS Feed

[Spring] Spring Security

Fri, 19 Jun 2026 00:00:00 GMT

Spring Security

1. Spring 기반 보안 설정 처리

Spring Security는 Spring 기반 애플리케이션에서 인증(Authentication) 과 권한/인가(Authorization) 를 처리하기 위한 보안 프레임워크이다. 웹 애플리케이션에서 사용자는 단순히 로그인만 하는 것이 아니라, 로그인 이후 자신이 가진 권한에 따라 접근 가능한 기능이 달라져야 한다. 예를 들어 일반 사용자는 게시글 조회만 가능하고, 관리자는 게시글 등록, 수정, 삭제까지 가능해야 한다.

2. 인증과 권한

2.1 인증 Authentication

인증이란 - 사용자가 누구인지 확인하는 과정이다.
- 아이디 & 비밀번호 입력
- 로그인 성공
- 서버가 해당 사용자를 인증된 사용자로 판단

2.2 권한 Authorization

권한은 인증된 사용자가 어떤 기능을 사용할 수 있는지 판단하는 과정
- 로그인한 사용자가 게시판 상세 페이지에 접근할 수 있는가?
- 로그인한 사용자가 글쓰기 페이지에 접근할 수 있는가?
- 로그인한 사용자가 관리자 페이지에 접근할 수 있는가?
사용자의 권한(ROLE)에 따라 접근 가능한 프로세스를 제어하는 것이 권한 처리 이다.

3. Security를 사용하지 않는 전통적인 인증/권한 처리

Spring Security를 사용하지 않는 경우에는 보통 session을 직접 사용한다.
세션기반 방식에 대한 설명은 아래 링크 참조
- 세션과 JWT 방식

기존 방식의 문제

모든 페이지마다 session 체크 코드가 반복된다.
권한 변경 시 여러 JSP와 Controller를 수정해야 한다.
URL 접근 제어가 분산된다.
권한이 많아지면 관리가 복잡해진다.
보안 관련 처리가 개발자 코드에 흩어진다.

4. Spring Security를 사용하는 이유

Spring Security를 사용하면 인증과 권한 처리를 하나의 설정 파일에서 통합적으로 관리할 수 있음.

즉, Spring Security는 보안 처리를 Controller나 JSP에 흩어놓지 않고, 보안 설정 파일에서 중앙 집중식으로 관리하게 해준다.

통합 관리의 의미

Spring Security를 사용하면 다음 항목을 한 곳에서 관리할 수 있음.
- 사용자 인증, 권한 관리
- URL 접근 관리
- 로그인 페이지 설정
- 로그아웃 처리
- 세션 만료 처리
- 권한 없는 사용자 접근 처리

flowchart LR
    A[로그인 성공] --> B[Authentication 객체 생성]
    B --> C[SecurityContext에 저장]
    C --> D[Session을 통해 인증 상태 유지]
    D --> E[요청마다 Security Filter가 권한 확인]

[Spring] Maven 기반 Spring MVC 프로젝트에 MyBatis 연동하기

Thu, 18 Jun 2026 00:00:00 GMT

1. 개요

이번 글에서는 Maven 원형 기반의 Spring MVC 프로젝트에 Mybatis를 연동하는 과정을 정리한다.

Spring MVC 프로젝트에서 DB 접근 코드를 직접 JDBC로 작성하면 Connection, PreparedStatement, ResultSet과 같은

처리 관련 BoilerPlate가 생긴다. MyBatis를 활용하면 SQL의 경우 직접 XML Mapper에 분리할 수 있다.

1.1 프로젝트 구조

Maven 기반 Spring MVC 프로젝트의 기본 구조는 다음과 같다.

SpringMVC_Basic05_Maven
├── pom.xml
└── src
    └── main
        ├── java
        │   ├── controller
        │   ├── service
        │   ├── dao
        │   │   └── NoticeDao.java
        │   └── vo
        │       └── Notice.java
        ├── resources
        │   └── mapper
        │       └── NoticeDao.xml
        └── webapp
            └── WEB-INF
                ├── web.xml
                ├── views
                └── spring
                    ├── root-context.xml
                    └── servlet-context.xml

MyBatis Mapper XML 파일은 일반적으로 src/main/resources/mapper 아래에 둔다.

2. pom.xml에 의존성 추가

Spring MVC 프로젝트에서 MyBatis를 사용하려면 다음과 같은 의존성이 필요하다.

<dependencies>
    <!-- Spring MVC -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>5.3.39</version>
    </dependency>

    <!-- MyBatis -->
    <dependency>
        <groupId>org.mybatis</groupId>
        <artifactId>mybatis</artifactId>
        <version>3.5.16</version>
    </dependency>

    <!-- MyBatis Spring 연동 -->
    <dependency>
        <groupId>org.mybatis</groupId>
        <artifactId>mybatis-spring</artifactId>
        <version>2.1.2</version>
    </dependency>

    <!-- Spring JDBC -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-jdbc</artifactId>
        <version>5.3.39</version>
    </dependency>

    <!-- Oracle JDBC Driver -->
    <dependency>
        <groupId>com.oracle.database.jdbc</groupId>
        <artifactId>ojdbc11</artifactId>
        <version>23.3.0.23.09</version>
    </dependency>

    <!-- Servlet API: Tomcat이 제공하므로 provided -->
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>4.0.1</version>
        <scope>provided</scope>
    </dependency>

    <!-- JSTL -->
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>jstl</artifactId>
        <version>1.2</version>
    </dependency>
</dependencies>

Tomcat 9버전과 Spring 5 기반의 프로젝트의 경우 javax.servlet 계열을 사용해야한다.
- Tomcat 10 이상은 jakarta.servlet 계열을 사용하므로 기존 Spring MVC Legacy 프로젝트와 충돌할 수 있다.

2.1 DB 연결 설정

Spring 설정 파일에 DataSource를 등록해야한다.

아래 예시는 Oracle DB 기준이다.

  <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
  <property name="driverClassName" value="oracle.jdbc.OracleDriver"/>
  <property name="url" value="jdbc:oracle:thin:@//localhost:1521/FREEPDB1"/>
  <property name="username" value="username"/>
  <property name="password" value="password"/>
  </bean>

2.2 SqlSessionFactoryBean 설정

MyBatis는 SqlSessionFactory를 통해 SQL 실행 객체를 생성한다.
Spring 에서는 SqlSessionFactoryBean을 등록하여 MyBatis와 Spring을 연결한다.

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource"/>
  <property name="mapperLocations" value="classpath:/mapper/*.xml"/>
</bean>

Spring 설정파일

일반적인 Spring 설정파일은 아래와 같다.

src/main/webapp/WEB-INF/spring/root-context.xml
src/main/webapp/WEB-INF/spring/appServlet/servlet-context.xml

[Spring] MVC 어노테이션 기반 요청 처리 흐름 정리

Tue, 16 Jun 2026 00:00:00 GMT

1. 개요

이 글에서는 Spring MVC에서 어노테이션을 이용해 컨트롤러와 서비스 객체를 등록하고, 하나의 URL에 대해 GET 요청과 POST 요청을 분리해서 처리하는 흐름을 정리한다. 또한 JSP form에서 전달된 요청 파라미터가 NewArticleCommand 객체에 자동으로 바인딩되는 과정과, 기존 Servlet 방식과의 차이도 함께 정리한다.

2. Controller 어노테이션

@Controller
@RequestMapping("/article/newArticle.do")
public class NewArticleController {

  @GetMapping
  public String form(){
    return "article/newArticleForm";
  }

  @PostMapping
  public String submit(NewArticleCommand command){
    return "article/newArticleSubmitted";
  }
}

@Controller는 해당 클래스를 Spring MVC의 컨트롤러로 등록하는 어노테이션이다.
@RequestMapping은 컨트롤러가 처리할 공통 요청 URL을 지정한다.
이 예제에서는 /article/newArticle.do 요청을 NewArticleController가 처리한다.

3. GET 요청과 POST 요청 분리

Spring MVC에서는 하나의 URL을 기준으로 하더라도 HTTP Method에 따라 서로 다른 메서드가 실행되도록 분리할 수 있다.

@GetMapping

@GetMapping
public String form(){
  return "article/newArticleForm";
}

@GetMapping은 GET 방식 요청을 처리한다.
사용자가 브라우저에서 /article/newArticle.do 주소로 처음 접근하면 GET 요청이 발생한다. 이때 form() 메서드가 실행되고, 게시글 작성 폼 화면을 반환한다.

@PostMapping

@PostMapping
public String submit(NewArticleCommand command){
  return "article/newArticleSubmitted";
}

@PostMapping은 POST 방식 요청을 처리한다.
사용자가 게시글 작성 폼에서 제목과 내용을 입력한 뒤 전송 버튼을 누르면 POST 요청이 발생한다. 이때 submit() 메서드가 실행되고, 입력된 데이터를 처리한 뒤 작성 완료 화면을 반환한다.
즉, 같은 URL인 /article/newArticle.do를 사용하더라도 요청 방식에 따라 다음과 같이 동작이 분리된다.

4. View 이름 반환과 ViewResolver

Controller 메서드의 반환 타입이 String이면, Spring MVC는 반환값을 View 이름으로 해석한다.

@GetMapping
public String form(){
  return "article/newArticleForm";
}

주의
- 위 코드에서 반환한 문자열은 실제 JSP 파일의 전체 경로가 아니다. 단순한 View 이름이다.
Spring MVC에서는 InternalResourceViewResolver가 View 이름을 실제 JSP 경로로 변환한다.

<bean id="internalResourceViewResolver"
      class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  <property name="prefix" value="/WEB-INF/views/" />
  <property name="suffix" value=".jsp" />
</bean>

위 설정이 있을 경우, Controller에서 반환한 View 이름은 다음과 같이 변환됨.

article/newArticleForm
↓
/WEB-INF/views/article/newArticleForm.jsp

5. Service 계층 & @Service

게시글 작성, 회원가입, 주문 처리와 같은 핵심 로직은 Service 계층에서 처리하는 것이 일반적임.


package com.service;

import com.model.NewArticleCommand;
import org.springframework.stereotype.Service;

@Service
public class ArticleService {

  public ArticleService(){
    System.out.println("ArticleService 생성자 호출");
  }

  public void writeArticle(NewArticleCommand command){
    // DAO가 있다고 가정한다.
    // DAO dao = new DAO();
    // dao.insert(command);

    System.out.println("글쓰기 작업 완료 : " + command.toString());
  }
}

@Service는 해당 클래스가 Service 계층의 클래스임을 나타내는 어노테이션이다.
Spring은 컴포넌트 스캔 범위 안에서 @Service가 붙은 클래스를 찾아 Bean 객체로 등록한다.
- 단, @Service를 붙였다고 무조건 Bean으로 등록되는 것은 아니다. 반드시 컴포넌트 스캔 대상 패키지 안에 있어야 한다.

<context:component-scan base-package="com" />

위 설정이 있다면 com 패키지 아래에 있는 @Controller, @Service, @Repository, @Component가 붙은 클래스를 Spring이 자동으로 탐색한다.

따라서 ArticleService는 직접 new ArticleService()로 생성하지 않아도 Spring Container 안에 Bean 객체로 생성된다.

6. 기존 Servlet 방식과 Spring MVC 방식 비교

기존 Servlet

NewArticleCommand article = new NewArticleCommand();

article.setParentId(Integer.parseInt(request.getParameter("parentId")));
article.setTitle(request.getParameter("title"));
article.setContent(request.getParameter("content"));

기존 Servlet 방식에서는 요청 파라미터를 직접 꺼내고, 객체를 생성한 뒤 setter를 이용해 값을 넣어야 했다.
또한 JSP로 데이터를 전달할 때도 직접 request 영역에 데이터를 저장해야 했다.

View로 이동할 때도 RequestDispatcher를 직접 사용했다.

RequestDispatcher dispatcher =
  request.getRequestDispatcher("/WEB-INF/views/article/newArticleSubmitted.jsp");
  dispatcher.forward(request, response);

Spring MVC 방식

NewArticleCommand Model 정의

package com.model;

import lombok.Data;

@Data
public class NewArticleCommand {
  private int parentId;
  private String title;
  private String content;

}

Service단

@PostMapping
public String submit(NewArticleCommand command){
  articleService.writeArticle(command);
  return "article/newArticleSubmitted";
}

Spring MVC는 요청 파라미터 이름과 NewArticleCommand 객체의 필드 이름을 비교해서 값을 자동으로 넣어준다.

흐름 정리


flowchart LR
    A["사용자 GET 요청<br/>/article/newArticle.do"] --> B["NewArticleController form 메서드 실행"]
    B --> C["View 이름 반환<br/>article/newArticleForm"]
    C --> D["ViewResolver"]
    D --> E["/WEB-INF/views/article/newArticleForm.jsp"]
    E --> F["사용자 form 입력 후 POST 전송"]
    F --> G["NewArticleController submit 메서드 실행"]
    G --> H["NewArticleCommand 객체 자동 바인딩"]
    H --> I["ArticleService writeArticle 호출"]
    I --> J["View 이름 반환<br/>article/newArticleSubmitted"]
    J --> K["/WEB-INF/views/article/newArticleSubmitted.jsp"]

정리

Spring MVC의 어노테이션 기반 설정을 사용하면 요청 처리 흐름을 선언적으로 작성할 수 있다.

@Controller는 요청을 처리하는 컨트롤러 클래스를 등록한다.

@RequestMapping은 공통 요청 URL을 지정한다.

@GetMapping과 @PostMapping은 HTTP Method에 따라 실행될 메서드를 분리한다.

@Service는 비즈니스 로직을 담당하는 Service 계층의 클래스를 Bean으로 등록하기 위해 사용한다.

Controller는 생성자 주입을 통해 Service 객체를 전달받는다. 이를 통해 Controller와 Service의 역할을 분리할 수 있다.

또한 Spring MVC는 form에서 전달된 요청 파라미터를 Command 객체에 자동으로 바인딩한다. 따라서 기존 Servlet 방식처럼 request.getParameter(), 객체 생성, setter 호출, RequestDispatcher.forward()를 반복해서 작성하지 않아도 된다.

결과적으로 Spring MVC는 요청 매핑, 객체 생성, 의존성 주입, 데이터 바인딩, View 이동을 프레임워크 차원에서 처리해준다. 이를 통해 개발자는 핵심 로직과 계층 간 역할 분리에 더 집중할 수 있다.

[Spring] MVC 파일 업로드 처리 흐름 정리

Tue, 16 Jun 2026 00:00:00 GMT

1. 개요

게시판 기능을 구현하다 보면 글 작성과 함께 이미지를 업로드해야 하는 경우가 있다. 예를 들어, 사용자가 게시글을 작성하면서 사진을 첨부하면, 서버는 사용자가 입력한 내용, 작성자 정보뿐만 아니라 첨부한 파일도 함께 처리해야 한다.

주의할 점: DB에 직접 저장하지 않을 것

1.1 일반적인 파일 업로드 처리

실제 파일 -> 웹 서버의 특정 폴더 혹은 AWS s3와 같은 파일 저장소에 저장
파일 관련 정보 -> DB에 저장

예를 들어, 사용자가 1.jpg 파일을 업로드했다고 가정한다. 실제 이미지 파일은 서버의 /upload 폴더에 저장하고, DB에는 다음과 같은 정보만 저장한다.

파일명: 1.jpg
파일 크기: 12500 byte
파일 타입: image/jpeg
저장 경로: /upload/1.jpg

즉, DB에는 파일 자체가 아니라 파일을 찾기 위한 정보를 저장한다.

1.2 파일 업로드 처리 구조

파일 업로드 기능은 두 가지로 나눌 수 있다.

I/O 작업
- 업로드된 파일을 서버의 특정 경로에 저장
DB 작업
- 저장된 파일의 이름, 경로, 크기, 타입 등을 DB에 저장

이때 파일이 서버에 정상적으로 저장되어야 하고, 그 후에 DB에 파일 정보를 insert 해야 한다.

1.3 파일 업로드 처리 흐름

flowchart LR
    A[사용자 파일 업로드] --> B[Spring MVC Controller에서<br>파일 객체 받기]
    B --> C[파일명, 크기, 타입 등<br>파일 정보 추출]
    C --> D[웹 서버의 upload 폴더에<br>실제 파일 저장]
    D --> E[DB에 파일 정보 저장]
    E --> F[결과 페이지 이동]

1.4 파일에 직접 저장하지 않는 이유

파일을 DB에 직접 저장할 수 있다. 예를 들어 BLOB 타입을 사용하면 이미지나 파일 데이터를 DB에 저장할 수 있다.
하지만, 일반적인 게시판에서는 파일 자체를 DB에 저장하기보다는, 파일은 별도의 저장소에 저장하고 DB에는 파일 정보만 저장하는 방식을 많이 사용한다.

2. Spring MVC에서 파일 업로드를 위한 DTO

Spring MVC에서는 일반 form 데이터뿐만 아니라 파일 객체도 DTO로 받을 수 있다.
예를 들어 다음과 같은 Photo DTO를 만들 수 있다.

package com.model;

import org.springframework.web.multipart.commons.CommonsMultipartFile;

@Data
public class Photo {

    private String name;
    private int age;

    // DB에 저장할 파일명
    private String image;

    // 실제 업로드된 파일 객체
    private CommonsMultipartFile file;
}

2.1 file 멤버 필드의 역할

private CommonsMultipartFile file;

file은 사용자가 업로드한 실제 파일 데이터를 받기 위한 필드이다.
- JSP form에 다음과 같은 input이 존재한다고 가정하자.
```
  private CommonsMultipartFile file;
```
- 이때, name = "file"과 DTO의 필드명 file이 동일하기 때문에 Spring이 자동으로 파일 객체를 바인딩해준다.

2.2 Controller 자동 바인딩

@PostMapping
public String submit(Photo photo) {
    CommonsMultipartFile file = photo.getFile();
    return "";
}

컨트롤러에서 다음과 같이 받을 수 있다.

2.3 JSP form 작성

파일 업로드를 하기 위해서는 form 태그에 반드시 enctype="multipart/form-data"를 설정해야한다.

<form action="${pageContext.request.contextPath}/image/upload.do"
      method="post"
      enctype="multipart/form-data">

    이름: <input type="text" name="name"><br>
    나이: <input type="text" name="age"><br>
    이미지: <input type="file" name="file"><br>

    <button type="submit">업로드</button>
</form>

전체 흐름

사용자가 form에서 파일 선택
multipart/form-data 방식으로 서버에 전송
Spring이 DTO의 CommonsMultipartFile 필드에 파일 객체 자동 바인딩
Controller에서 파일 객체 추출
서버의 upload 폴더에 실제 파일 저장
저장된 파일명을 DTO의 image 필드에 세팅
DB에는 파일명, 경로, 크기, 타입 등 메타데이터 저장

[Spring] 소프트웨어 개발과 관심사의 분리

Thu, 11 Jun 2026 00:00:00 GMT

소프트웨어 개발과 관심사의 분리

1. 소프트웨어 설계의 핵심

소프트웨어 설계는 미래의 변화에 대비하는 작업이다.

애플리케이션은 시간이 지나면서 계속 변화한다.

요구사항 변경
DB 변경
고객사별 환경 차이
기능 추가 및 수정
유지보수 비용 증가

따라서 좋은 코드는 변화에 대응하기 쉬운 코드여야 한다.

2. 관심사의 분리

관심사란?

관심사는 클래스나 메서드가 담당하는 역할 또는 책임을 의미한다.

예를 들어 UserDao 클래스에는 다음과 같은 관심사가 섞여 있다.

UserDao
├── DB 연결 작업
├── 데이터 작업(add, get)
└── 자원 해제 작업

3. 기존 UserDao의 문제점

문제 1. DB 연결 코드 중복

add(), get() 메서드마다 DB 연결 코드가 반복된다.

Class.forName("oracle.jdbc.OracleDriver");
Connection c = DriverManager.getConnection(...);

이런 코드가 여러 메서드에 중복되면 다음과 같은 문제가 생긴다.

DB 접속 정보가 바뀌면 여러 곳을 수정해야 한다.
코드가 길어지고 가독성이 떨어진다.
유지보수가 어려워진다.
실수로 일부 메서드만 수정하지 못할 수 있다.

4. 해결 방법 1: 리팩토링

중복된 관심사는 하나로 모은다.

DB 연결 코드를 getConnection() 메서드로 분리한다.

private Connection getConnection() throws ClassNotFoundException, SQLException {
    Class.forName("oracle.jdbc.OracleDriver");
    return DriverManager.getConnection(url, user, password);
}

이후 add(), get()에서는 공통 메서드를 사용한다.

Connection c = getConnection();

5. 리팩토링이란?

리팩토링은 외부 동작은 그대로 유지하면서 내부 구조를 개선하는 작업이다.

즉, 사용자가 보는 기능은 변하지 않지만 코드 구조를 더 좋게 바꾸는 것이다.

리팩토링 목적

중복 제거
가독성 향상
유지보수성 향상
변경에 강한 구조 만들기

6. 예외 처리와 자원 해제

DB 연결, PreparedStatement, ResultSet 같은 자원은 사용 후 반드시 해제해야 한다.

rs.close();
ps.close();
c.close();

자원을 사용하는 쪽에서 예외를 강제 처리하도록 하는 것이 일반적이다.

throws ClassNotFoundException, SQLException

1.2 요구사항 변화

새로운 요구사항

소프트웨어를 여러 고객사에 판매해야 하는 상황이 발생했다.

고객사마다 사용하는 DB가 다르다.

N사 -> Oracle 사용
D사 -> MySQL 사용

문제는 DB마다 연결 방식이 다르다는 점이다.

또한 사장님(가상 시나리오)의 요구사항은 다음과 같다.

UserDao 클래스의 핵심 소스는 외부에 노출되면 안 된다.

변경되는 부분과 유지되는 부분

유지되어야 하는 코드

UserDao의 핵심 기능은 그대로 유지되어야 한다.

add()
get()

변경되는 코드

DB 연결 방식만 고객사마다 달라진다.

getConnection();

즉, 변화하는 부분은 DB 연결 코드이고, 변화하지 않는 부분은 데이터 처리 로직이다.

해결 방법 2: 상속 사용

구조

UserDao를 추상 클래스로 만들고, DB 연결 메서드를 추상 메서드로 만든다.

UserDao 추상 클래스
├── add()
├── get()
└── getConnection() 추상 메서드

각 고객사는 UserDao를 상속받아 자신에게 맞는 DB 연결 방식을 구현한다.

NUserDao -> Oracle 연결 구현
DUserDao -> MySQL 연결 구현

예시 구조

UserDao
├── NUserDao
└── DUserDao

UserDao는 공통 로직을 담당한다.

add()
get()

각 하위 클래스는 DB 연결 로직만 담당한다.

getConnection()

Program 코드 변경

사용자는 필요한 DB에 맞는 DAO 객체를 선택해서 사용한다.

UserDao dao = new NUserDao();

또는

UserDao dao = new DUserDao();

상속 방식의 문제점

문제 1. 자바는 단일 상속만 지원한다

자바 클래스는 하나의 클래스만 상속할 수 있다.

class NUserDao extends UserDao{}

이미 UserDao를 상속하고 있으면 다른 클래스를 추가로 상속할 수 없다.

문제 2. 부모와 자식 클래스의 결합도가 높다

상속 관계에서는 부모 클래스와 자식 클래스가 강하게 연결된다.

부모 클래스가 변경되면 자식 클래스도 영향을 받을 가능성이 높다.

부모 클래스 변경
-> 자식 클래스 영향
-> 유지보수 부담 증가

즉, 상속은 코드 재사용에는 도움이 되지만, 구조가 강하게 묶이는 문제가 있다.

다음 개선 방향

상속 관계를 줄이고, 더 유연한 구조로 바꿔야 한다.

핵심은 다음과 같다.

상속 관계를 파괴하자.
그러면서도 고객사별 DB 연결 요구사항은 만족하자.

이를 위해 생각해야 할 개념은 다음 두 가지다.

is-a 관계

상속 관계이다.

NUserDao is a UserDao

즉, NUserDao는 UserDao의 한 종류라는 의미이다.

has-a 관계

포함 관계이다.

UserDao has a ConnectionMaker

즉, UserDao가 DB 연결 기능을 직접 상속받는 것이 아니라, DB 연결 객체를 내부에 가지고 사용하는 구조이다.

Spring이 선호하는 구조

Spring은 상속보다 다음 구조를 선호한다.

인터페이스 + 다형성 + 조합

즉, 변하는 부분을 인터페이스로 분리하고, 실제 구현체는 외부에서 주입받는 방식이다.

이 구조는 이후 Spring의 핵심 개념인 다음 내용으로 이어진다.

DI, Dependency Injection
의존성 주입

정리

현재까지의 흐름

1. UserDao 안에 DB 연결 코드가 중복됨
2. getConnection() 메서드로 분리하여 리팩토링
3. 고객사마다 DB 연결 방식이 달라지는 요구사항 발생
4. 상속을 이용해 고객사별 DAO 구현
5. 하지만 상속은 단일 상속과 강한 결합 문제가 있음
6. 상속 대신 인터페이스와 다형성을 사용하는 구조로 개선 필요

[Project Review] Zustand 활용기

Sun, 07 Jun 2026 00:00:00 GMT

들어가며

RentSignal은 왼쪽 패널에서 지역과 지표를 선택하면 오른쪽 Kakao Map이 즉시 반응하는 구조다.

예를 들어 다음과 같은 상호작용이 있다.

홈의 추천 지역을 클릭하면 해당 동의 폴리곤을 지도에 표시한다.
지하철 접근성 순위를 클릭하면 해당 구를 확대하고 강조한다.
정보 탭에서 전월세 지수, 안전도, 편의시설을 선택하면 지도 오버레이가 변경된다.
프로필과 추천 페이지는 동일한 로그인 사용자 정보를 사용한다.

이 상태를 각 컴포넌트의 useState와 props만으로 관리하면 패널, 레이아웃, 지도 사이에 긴 props 전달 구조가 생긴다. RentSignal에서는 이런 문제를 줄이기 위해 Zustand를 사용했다.

현재 프로젝트의 Zustand 스토어는 크게 두 가지다.

스토어	역할
`userStore`	로그인 사용자 정보 조회, 저장, 초기화
`mapOverlayStore`	지도에 표시할 폴리곤, 마커, 노선, 선택 지역 관리

Zustand를 선택한 이유

이 프로젝트에서 필요한 전역 상태 관리는 복잡한 비즈니스 로직보다 멀리 떨어진 컴포넌트 사이의 상태 공유에 가깝다.

Zustand는 다음 이유로 현재 구조에 잘 맞았다.

별도의 Provider 없이 어디서든 스토어를 사용할 수 있다.
상태와 액션을 하나의 파일에 간결하게 정의할 수 있다.
selector를 사용해 필요한 상태만 구독할 수 있다.
TypeScript 타입을 스토어 계약으로 활용하기 쉽다.
지도처럼 React 외부 객체를 제어할 때 명령을 전달하는 중간 계층으로 사용하기 좋다.

프로젝트에서는 zustand@5와 React 19를 사용하고 있다.

전체 데이터 흐름

지도 관련 상태는 패널 컴포넌트가 변경하고, Map 컴포넌트가 이를 구독하여 실제 Kakao Map 객체에 반영한다.

flowchart LR
  A["Home / Info 패널"] -->|"액션 호출"| B["mapOverlayStore"]
  B -->|"selector 구독"| C["Map 컴포넌트"]
  C -->|"Polygon / Marker 생성"| D["Kakao Map"]
  C -->|"effect cleanup"| E["기존 오버레이 제거"]

핵심은 Zustand에 Kakao Map 인스턴스나 폴리곤 객체 자체를 저장하지 않는다는 점이다.

스토어에는 아래처럼 지도에 무엇을 표현할지 설명하는 직렬화 가능한 데이터를 저장한다.

export type ConvenienceMapPin = {
  name: string;
  latitude: number;
  longitude: number;
};

export type SubwayLinePolyline = {
  lineName: string;
  color?: string;
  path: {
    latitude: number;
    longitude: number;
  }[];
};

실제 kakao.maps.Polygon, kakao.maps.Marker 등의 객체는 Map 컴포넌트의 ref에서 관리한다.

1. 사용자 상태 관리

userStore는 사용자 정보와 사용자 정보를 갱신하는 액션을 함께 관리한다.

interface User {
  name: string;
  imageUrl: string;
  role: string;
}

interface UserStore {
  user: User | null;
  fetchUser: () => Promise<void>;
  clearUser: () => void;
}

export const useUserStore = create<UserStore>((set) => ({
  user: null,

  fetchUser: async () => {
    const profile = await getMyProfile();
    set({ user: profile });
  },

  clearUser: () => set({ user: null }),
}));

비동기 액션을 스토어에 둔 이유

fetchUser 내부에서 사용자 조회 API를 호출하고 결과를 바로 저장한다. 사용하는 컴포넌트는 API 응답 구조나 저장 방식을 알 필요가 없다.

const user = useUserStore((state) => state.user);
const fetchUser = useUserStore((state) => state.fetchUser);
const clearUser = useUserStore((state) => state.clearUser);

이 패턴은 다음 화면에서 재사용된다.

Profile: 사용자 정보를 표시하고 로그아웃 시 상태를 초기화한다.
Recommend: 사용자 권한을 확인해 로그인 또는 휴대전화 인증 모달을 연다.
PhoneModal: 인증 완료 후 사용자 정보를 다시 조회한다.

로그아웃 흐름도 단순하다.

const handleLogout = async () => {
  await logout();
  clearUser();
  navigate("/");
};

서버의 로그아웃 처리와 클라이언트 사용자 상태 초기화를 분리하면서도, UI에서는 하나의 명확한 흐름으로 사용할 수 있다.

2. 지도 오버레이 상태 관리

mapOverlayStore는 사용자 인터페이스와 지도 사이의 통신 채널 역할을 한다.

대표 상태는 다음과 같다.

상태	지도 표현
`rentIndexItems`	전월세 지수 오버레이
`consumerIndexItem`	소비자 심리지수 권역 폴리곤
`subwayIndexItems`	구별 지하철 역세권 지수
`safetyIndexItems`	구별 안전도 오버레이
`selectedHomeRecommendationName`	홈 추천 동 폴리곤
`selectedHomeSubwayRanking`	홈 지하철 순위 구 폴리곤
`selectedTransportNeighborhoodName`	선택한 교통 추천 동
`subwayLinePolylines`	지하철 노선
`subwayStationMarkers`	지하철역 마커
`conveniencePins`	편의시설 위치 마커

스토어 액션 이름은 set, select, clear로 역할을 구분했다.

setSubwayIndexItems: (items) => set({ subwayIndexItems: items }),
clearSubwayIndexItems: () => set({ subwayIndexItems: [] }),

selectTransportNeighborhood: (name) =>
  set({ selectedTransportNeighborhoodName: name }),
clearSelectedTransportNeighborhood: () =>
  set({ selectedTransportNeighborhoodName: null }),

이름만 보아도 목록 전체를 설정하는지, 하나를 선택하는지, 상태를 정리하는지 알 수 있다.

3. 패널에서 지도에 명령 전달하기

홈의 추천 지역 카드를 클릭하면 컴포넌트가 직접 Kakao Map을 조작하지 않는다. 대신 선택한 지역명을 스토어에 저장한다.

const selectHomeRecommendation = useMapOverlayStore(
  (state) => state.selectHomeRecommendation,
);

<RecommendationCard
  neighborhoodName={recommendation.dongName}
  onClick={() => selectHomeRecommendation(recommendation.dongName)}
/>

Map 컴포넌트는 선택 상태만 구독한다.

const selectedHomeRecommendationName = useMapOverlayStore(
  (state) => state.selectedHomeRecommendationName,
);

상태가 바뀌면 effect에서 GeoJSON을 기준으로 폴리곤을 생성하고 지도를 이동한다.

useEffect(() => {
  if (!isMapReady || !mapRefInstance.current) return;

  drawSelectedHomeRecommendationPolygon(
    mapRefInstance.current,
    selectedHomeRecommendationName,
  );

  return () => {
    clearSelectedHomeRecommendationPolygons();
  };
}, [isMapReady, selectedHomeRecommendationName]);

이 구조 덕분에 패널은 무엇을 선택했는지만 알고, 지도는 어떻게 그릴지만 책임진다.

4. 상호 배타적인 선택 상태

홈에서는 추천 동 폴리곤과 지하철 순위 구 폴리곤이 동시에 남아 있으면 사용자에게 혼란을 줄 수 있다.

이를 컴포넌트에서 각각 정리하지 않고 스토어 액션에서 처리했다.

selectHomeRecommendation: (name) =>
  set({
    selectedHomeRecommendationName: name,
    selectedHomeSubwayRanking: null,
  }),

selectHomeSubwayRanking: (item) =>
  set({
    selectedHomeSubwayRanking: item,
    selectedHomeRecommendationName: null,
  }),

추천 지역을 선택하면 지하철 순위 선택이 해제되고, 지하철 순위를 선택하면 추천 지역 선택이 해제된다.

이처럼 서로 영향을 주는 상태는 액션 내부에서 함께 변경하면 UI 컴포넌트마다 동일한 정리 로직을 반복하지 않아도 된다.

5. selector로 필요한 상태만 구독하기

스토어 전체를 가져오는 대신 각 컴포넌트가 필요한 값이나 액션만 selector로 구독한다.

const conveniencePins = useMapOverlayStore(
  (state) => state.conveniencePins,
);

const clearConveniencePins = useMapOverlayStore(
  (state) => state.clearConveniencePins,
);

이 방식의 장점은 다음과 같다.

컴포넌트의 의존성이 코드에 명확하게 드러난다.
관련 없는 상태 변경으로 인한 렌더링을 줄일 수 있다.
테스트하거나 리팩터링할 때 사용하는 상태 범위를 빠르게 파악할 수 있다.

특히 여러 지도 기능을 한 컴포넌트에서 처리하는 현재 구조에서는 선택적 구독이 중요하다.

6. 화면 상태와 전역 상태를 구분하기

모든 상태를 Zustand에 넣지는 않았다.

예를 들어 API 로딩 여부, 에러 메시지, 현재 탭처럼 특정 화면에서만 사용하는 상태는 로컬 useState로 관리한다.

const [isLoading, setIsLoading] = useState(false);
const [errorMessage, setErrorMessage] = useState("");
const [currentRankings, setCurrentRankings] = useState([]);

반면 조회 결과를 지도에서도 사용해야 할 때만 필요한 데이터 형태로 변환해 전역 스토어에 전달한다.

const rankings = await fetchRentIndexRankings(residenceType);

setCurrentRankings(rankings);
setRentIndexMapItems(
  rankings.map((item) => ({
    ...item,
    type: "CURRENT",
  })),
);

정리하면 기준은 다음과 같다.

한 컴포넌트 안에서만 필요하다면 useState
서로 멀리 떨어진 패널과 지도에서 공유한다면 Zustand
URL로 표현해야 하는 화면 상태라면 React Router
서버 캐시, 재시도, stale 관리가 중요하다면 서버 상태 라이브러리 검토

Zustand를 모든 상태의 저장소로 사용하지 않고, 컴포넌트 경계를 넘는 클라이언트 상태에 집중했다.

7. cleanup이 중요한 이유

지도 오버레이는 React DOM 요소가 아니기 때문에 컴포넌트가 사라진다고 자동으로 제거되지 않는다.

따라서 상태를 초기화하는 것과 실제 Kakao Map 객체를 제거하는 작업이 모두 필요하다.

스토어 상태 정리

useEffect(() => {
  return () => clearSubwayIndexMapItems();
}, [clearSubwayIndexMapItems]);

지도 객체 정리

const clearSubwayIndexOverlays = () => {
  subwayIndexOverlaysRef.current.forEach((overlay) => {
    overlay.setMap(null);
  });

  subwayIndexOverlaysRef.current = [];
};

useEffect(() => {
  drawSubwayIndexOverlays(mapRefInstance.current, subwayIndexItems);

  return () => {
    clearSubwayIndexOverlays();
  };
}, [isMapReady, subwayIndexItems]);

이 cleanup이 빠지면 탭을 이동하거나 다른 지역을 선택했을 때 이전 폴리곤과 마커가 지도에 계속 남을 수 있다.

8. Zustand를 사용하며 얻은 효과

Props drilling 제거

패널에서 발생한 클릭 이벤트를 MainLayout을 거쳐 Map까지 전달할 필요가 없어졌다.

UI와 지도 구현 분리

패널은 선택 상태를 만들고, 지도는 해당 상태를 시각화한다. 두 영역의 책임이 분리됐다.

지도 기능 확장 용이

새로운 지도 기능을 추가할 때 아래 흐름으로 확장할 수 있다.

스토어에 표현 데이터를 위한 타입과 상태를 추가한다.
상태를 변경하는 액션과 초기화 액션을 추가한다.
패널에서 액션을 호출한다.
Map에서 상태를 구독하고 effect로 오버레이를 그린다.
effect cleanup에서 기존 지도 객체를 제거한다.

상태 변화 추적 용이

selectHomeRecommendation, setConveniencePins처럼 도메인이 드러나는 액션명을 사용해 어떤 사용자 행동이 지도 변경으로 이어지는지 파악하기 쉬워졌다.

9. 현재 구조에서 개선할 점

현재 방식은 잘 동작하지만 기능이 늘면서 mapOverlayStore와 Map.tsx가 커지고 있다.

지도 도메인별 slice 분리

다음처럼 역할별 slice로 나누는 방식을 고려할 수 있다.

mapOverlayStore
├── homeOverlaySlice
├── rentIndexOverlaySlice
├── transportOverlaySlice
├── safetyOverlaySlice
└── convenienceOverlaySlice

하나의 스토어를 유지하더라도 타입과 액션 생성 로직을 파일별로 나누면 변경 범위를 줄일 수 있다.

전체 초기화 액션 추가

라우트 이동 시 여러 clear 액션을 각각 호출하는 대신 아래와 같은 액션을 둘 수 있다.

clearAllMapOverlays: () =>
  set({
    rentIndexItems: [],
    subwayIndexItems: [],
    safetyIndexItems: [],
    selectedHomeRecommendationName: null,
    selectedHomeSubwayRanking: null,
    conveniencePins: [],
  });

다만 모든 화면 전환에서 전체 초기화가 필요한 것은 아니므로, 실제 라우트 정책을 정한 뒤 도입하는 편이 좋다.

서버 상태와 클라이언트 상태 분리

현재 userStore의 fetchUser는 API 호출과 전역 상태 저장을 함께 처리한다. 규모가 커져 캐싱, 중복 요청 제거, 재시도가 필요해지면 TanStack Query 같은 서버 상태 도구와 역할을 나눌 수 있다.

이 경우 Zustand는 로그인 사용자 스냅샷이나 UI 선택 상태를 담당하고, 서버 응답 캐시는 Query가 담당하게 된다.

지도 렌더링 훅 분리

Map.tsx의 effect와 draw 함수가 계속 늘어난다면 아래처럼 기능별 훅으로 분리할 수 있다.

useHomeMapOverlay
useRentIndexMapOverlay
useTransportMapOverlay
useConvenienceMapOverlay

Zustand 구독과 Kakao Map 객체 생명주기를 기능 단위로 묶으면 Map 컴포넌트는 지도 초기화와 조합에 집중할 수 있다.

마무리

RentSignal에서 Zustand는 단순한 전역 변수 저장소보다 패널의 사용자 선택을 지도 렌더링 명령으로 전달하는 연결 계층에 가깝다.

이번 구조에서 중요했던 원칙은 다음과 같다.

스토어에는 Kakao Map 객체가 아니라 표현에 필요한 데이터를 저장한다.
컴포넌트는 selector로 필요한 상태만 구독한다.
화면 전용 상태와 전역 공유 상태를 구분한다.
상호 배타 상태는 스토어 액션에서 함께 처리한다.
상태 초기화와 지도 객체 cleanup을 모두 구현한다.

Zustand의 장점은 코드가 짧다는 데만 있지 않다. 어떤 상태가 컴포넌트 경계를 넘어야 하는지 정하고, 상태를 만드는 영역과 사용하는 영역의 책임을 분리할 때 가장 큰 효과를 얻을 수 있었다.

[JS] Event

Tue, 26 May 2026 00:00:00 GMT

JavaScript Event 정리

JavaScript에서 **이벤트(Event)**는 사용자의 동작이나 브라우저의 상태 변화에 반응하여 특정 코드를 실행하는 방식이다.

예를 들어 사용자가 버튼을 클릭하거나, input에 커서를 올리거나, 페이지 로딩이 끝났을 때 JavaScript 함수를 실행할 수 있다.

참고: W3Schools - JavaScript Events

1. 대표적인 HTML Events

Event	발생 시점
`onchange`	HTML 요소의 값이 변경되었을 때
`onclick`	사용자가 HTML 요소를 클릭했을 때
`onmouseover`	마우스가 HTML 요소 위로 올라갔을 때
`onmouseout`	마우스가 HTML 요소 밖으로 나갔을 때
`onkeydown`	사용자가 키보드 키를 눌렀을 때
`onload`	브라우저가 페이지 로딩을 완료했을 때

onload 이벤트가 발생한 이후에는 HTML의 정적 요소들이 메모리에 올라와 있다고 볼 수 있다. 따라서 페이지가 모두 준비된 뒤 실행해야 하는 초기 작업을 처리할 때 사용한다.

2. 주요 Event 예제

1) `onload`

onload는 페이지 로딩이 끝난 뒤 실행된다.

<body onload="bodyLoad()">

function bodyLoad() {
  console.log("loading ....");

  const data = document.myform.money.value;
  console.log(isNaN(data));
}

위 코드에서는 페이지가 모두 로딩된 후 bodyLoad() 함수가 실행된다. 이후 name="money"인 input 값을 가져와 숫자인지 확인한다.

2) `onfocus`

onfocus는 input 요소에 커서가 들어왔을 때 발생한다.

<input type="text" id="myinput" onfocus="focusFunc()">

function focusFunc() {
  document.getElementById("myinput").style.background = "gold";
}

입력창을 클릭하거나 선택하면 해당 input의 배경색이 gold로 변경된다.

3) `onblur`

onblur는 input 요소에서 커서가 빠져나갔을 때 발생한다.

<input type="text" id="myinput" onblur="blurFunc()">

function blurFunc() {
  document.getElementById("myinput").style.background = "white";
}

선택이 해제되면 input의 배경색이 다시 white로 변경된다.

4) `onchange`

onchange는 select, input 등의 값이 변경되었을 때 발생한다.

<select name="sel" onchange="selectTag()">

function selectTag() {
  const value = document.myform.sel.value;
  alert(value);
}

select 태그에서 다른 option을 선택하면 selectTag() 함수가 실행되고, 현재 선택된 값이 alert로 출력된다.

3. `this`의 활용

이벤트 함수에 this를 전달하면 이벤트가 발생한 요소 자신을 함수의 인자로 넘길 수 있다.

<input
  type="text"
  onmouseover="changeColor(this)"
  onmouseout="changeColor2(this)"
>

function changeColor(obj) {
  console.log(obj);
  obj.style.backgroundColor = "gold";
}

function changeColor2(obj) {
  console.log(obj);
  obj.style.backgroundColor = "white";
}

동작 흐름은 다음과 같다.

input 위에 마우스를 올리면 onmouseover 이벤트가 발생한다.
changeColor(this)가 실행된다.
여기서 this는 현재 이벤트가 발생한 input 태그를 의미한다.
input 태그가 obj 매개변수로 전달된다.
obj.style.backgroundColor = "gold"가 실행되어 배경색이 변경된다.

4. 핵심 요약

Event	발생 시점	실행 함수	역할
`onload`	페이지 로딩 완료	`bodyLoad()`	초기 실행 작업
`onfocus`	input에 커서 진입	`focusFunc()`	배경색 변경
`onblur`	input에서 커서 이탈	`blurFunc()`	배경색 원복
`onchange`	select 값 변경	`selectTag()`	선택값 출력
`onmouseover`	마우스가 요소 위로 진입	`changeColor(this)`	이벤트 대상 스타일 변경
`onmouseout`	마우스가 요소 밖으로 이탈	`changeColor2(this)`	이벤트 대상 스타일 원복

5. 전체 코드

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JavaScript Event</title>
  <script>
    function bodyLoad() {
      console.log("loading ....");

      const data = document.myform.money.value;
      console.log(isNaN(data));
    }

    function focusFunc() {
      document.getElementById("myinput").style.background = "gold";
    }

    function blurFunc() {
      document.getElementById("myinput").style.background = "white";
    }

    function selectTag() {
      const value = document.myform.sel.value;
      alert(value);
    }

    function changeColor(obj) {
      console.log(obj);
      obj.style.backgroundColor = "gold";
    }

    function changeColor2(obj) {
      console.log(obj);
      obj.style.backgroundColor = "white";
    }
  </script>
</head>
<body onload="bodyLoad()">
  <form action="#" name="myform">
    <input
      type="text"
      id="myinput"
      name="myinput"
      onfocus="focusFunc()"
      onblur="blurFunc()"
    >

    <br>

    <select name="sel" onchange="selectTag()">
      <option value="A">AA</option>
      <option value="B">BB</option>
      <option value="C">CC</option>
      <option value="D">DD</option>
    </select>

    <br>

    <input
      type="text"
      onmouseover="changeColor(this)"
      onmouseout="changeColor2(this)"
    >

    <br>

    <input type="text">
    <br>
    <input type="text" value="1000" name="money">
  </form>
</body>
</html>

정리

JavaScript 이벤트는 HTML 요소에서 발생하는 동작을 감지하고, 그에 맞는 함수를 실행하기 위해 사용한다.

특히 this를 함께 사용하면 이벤트가 발생한 요소를 직접 제어할 수 있기 때문에, 여러 요소에 같은 함수를 적용할 때 유용하다.

[Spring] JWT란? (세션과 비교)

Sun, 24 May 2026 00:00:00 GMT

1. JWT란?

JWT는 JSON Web Token의 약어로, JSON 형식의 정보를 안전하게 주고받기 위한 토큰이다. 웹 애플리케이션에서는 주로 로그인 이후 사용자를 식별하기 위한 인증 수단으로 사용된다.

서버는 사용자가 로그인에 성공하면 JWT를 발급하고, 클라이언트는 이후 요청마다 이 토큰을 함께 보낸다. 서버는 전달받은 토큰의 서명을 검증한 뒤, 해당 요청이 인증된 사용자의 요청인지 판단한다.

2. JWT를 편지에 비유하기

JWT는 편지에 비유하면 이해하기 쉽다.

Header: 편지 봉투
Payload: 편지의 내용
Signature: 누가 작성했는지 확인할 수 있는 서명

편지 봉투에는 이 편지가 어떤 형식인지, 어떤 방식으로 서명되었는지가 적혀 있다. 편지 내용에는 전달하고 싶은 정보가 들어 있다. 마지막으로 서명은 이 편지가 중간에 조작되지 않았는지 확인하는 역할을 한다.

3. JWT의 구조

JWT는 .을 기준으로 세 부분으로 나뉜다.

Header.Payload.Signature

각 부분은 Base64Url 방식으로 인코딩된다. 즉, JWT는 암호화된 값이 아니라 인코딩된 값이다. 따라서 Payload에 비밀번호나 주민번호 같은 민감한 정보를 넣으면 안 된다.

4. Header

Header에는 토큰의 타입과 서명 알고리즘 정보가 들어간다.

{
  "alg": "HS256",
  "typ": "JWT"
}

alg: 서명에 사용할 알고리즘
typ: 토큰 타입

JWT는 서명 알고리즘을 하나로 강제하지 않는다. 따라서 어떤 알고리즘으로 서명했는지 Header에 명시해야 한다. 이것이 JWT에 Header가 필요한 이유다.

5. Payload

Payload에는 서버와 클라이언트가 주고받을 데이터가 들어간다. Payload에 들어가는 각각의 값을 Claim이라고 한다.

{
  "sub": "1",
  "name": "woojin",
  "role": "USER",
  "iat": 1716537600,
  "exp": 1716541200
}

Claim은 말 그대로 "주장"이라는 의미다. Payload에 적혀 있는 정보는 누구나 디코딩해서 볼 수 있기 때문에, 그 내용을 곧이곧대로 믿으면 안 된다. 서버는 반드시 Signature를 검증한 뒤에 Payload의 내용을 신뢰해야 한다.

자주 사용되는 Claim은 다음과 같다.

Claim	의미
`sub`	토큰의 주체, 보통 사용자 ID
`iat`	토큰 발급 시간
`exp`	토큰 만료 시간
`iss`	토큰 발급자
`aud`	토큰 대상자

6. Signature

Signature는 Header와 Payload가 변조되지 않았는지 검증하기 위한 값이다.

예를 들어 HMAC SHA256 방식을 사용하면 다음과 같은 흐름으로 서명을 만든다.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

클라이언트가 토큰을 서버로 보내면, 서버는 같은 방식으로 다시 서명을 계산한다. 그리고 토큰에 포함된 Signature와 서버가 계산한 Signature가 일치하는지 비교한다.

일치하면 토큰이 변조되지 않았다고 판단할 수 있고, 일치하지 않으면 잘못된 토큰으로 처리한다.

7. JWT는 어디에서 사용될까?

JWT는 다음과 같은 상황에서 사용할 수 있다.

Authentication
Information Exchange
Authorization
Single Sign-On
Server-to-server communication

이 중에서 가장 많이 사용되는 분야는 Authentication, 즉 인증이다.

8. Authentication 방식

웹 애플리케이션에서 인증 상태를 유지하는 대표적인 방식은 Cookie 기반 Session 방식과 JWT 방식이다.

Cookie 기반 Session 방식은 서버가 인증 상태를 Session Table에 저장하고, 클라이언트는 Session ID를 Cookie로 보관하는 방식이다.

Client에서 사용자가 로그인을 시도한다.
Application Server는 로그인한 사용자에 대한 Session 정보를 저장한다.
Server는 생성된 Session ID를 응답으로 반환한다.
Client는 Session ID를 Cookie에 저장하고, 이후 요청마다 Cookie를 함께 보낸다.

이 방식은 서버가 세션 상태를 직접 관리하기 때문에 구현이 직관적이다. 하지만 다음과 같은 문제가 생길 수 있다.

사용자 정보를 얻기 위해 매 요청마다 Session ID를 기준으로 Session Table을 다시 조회해야 한다.
사용자가 여러 기기에서 로그인할수록 Session Table의 데이터가 증가한다.
서버가 여러 대로 늘어나면 세션 공유를 위해 별도 저장소나 Sticky Session 전략이 필요해질 수 있다.

8.2 JWT Authentication

JWT 방식은 서버가 세션 상태를 저장하지 않고, 인증에 필요한 정보를 토큰에 담아 클라이언트에게 전달하는 방식이다. 클라이언트는 이후 요청마다 JWT를 Authorization 헤더에 담아 보낸다.

서버는 토큰의 Signature와 만료 시간을 검증한 뒤, Payload에 담긴 Claim을 바탕으로 사용자를 식별한다. 이 방식은 서버가 세션을 저장하지 않아도 되기 때문에 Stateless 인증에 적합하다.

9. Spring에서 JWT를 사용하는 흐름

Spring Security 기반 애플리케이션에서 JWT 인증은 보통 다음 흐름으로 동작한다.

사용자가 아이디와 비밀번호로 로그인 요청을 보낸다.
서버는 사용자 정보를 확인한다.
인증에 성공하면 Access Token을 발급한다.
클라이언트는 이후 요청마다 Authorization 헤더에 토큰을 담아 보낸다.
서버는 JWT 필터에서 토큰을 추출하고 검증한다.
토큰이 유효하면 SecurityContext에 인증 정보를 저장한다.
Controller에서는 인증된 사용자로 요청을 처리한다.

Authorization: Bearer <access-token>

JWT는 세션을 서버에 저장하지 않아도 되기 때문에 Stateless 인증 방식에 적합하다. 특히 SPA, 모바일 앱, MSA 구조에서 자주 사용된다.

10. JWT 사용 시 주의할 점

JWT는 편리하지만 몇 가지 주의할 점이 있다.

Payload는 암호화가 아니라 인코딩이므로 민감 정보를 넣지 않는다.
Access Token의 만료 시간을 너무 길게 잡지 않는다.
토큰 탈취에 대비해 Refresh Token 전략을 함께 고려한다.
서버는 반드시 Signature와 만료 시간을 검증해야 한다.
로그아웃과 강제 만료 처리가 필요한 경우 별도 저장소나 블랙리스트 전략이 필요할 수 있다.

11. 정리

JWT는 Header, Payload, Signature로 구성된 토큰이다. Header는 서명 방식, Payload는 Claim, Signature는 변조 여부 검증을 담당한다.

Spring Security에서 JWT를 사용하면 서버가 세션을 저장하지 않아도 인증 상태를 처리할 수 있다. 다만 JWT는 한 번 발급되면 만료 전까지 유효하므로, 만료 시간과 Refresh Token, 토큰 폐기 전략을 함께 설계해야 한다.

🗒️ 참고자료 & 사이트

jwt.io 사이트

참고영상

JWT | 생활코딩

[001] Front-Back 정리

Wed, 20 May 2026 00:00:00 GMT

Front-Back 구조 정리

1. Client

Client는 사용자가 직접 보는 화면을 담당한다.
현대 웹에서는 React, Vue, Angular 같은 프레임워크를 사용해 SPA 방식으로 구현하는 경우가 많다.

2. SPA 방식

SPA(Single Page Application)

SPA는 최초에 하나의 HTML 페이지를 로드한 뒤, 필요한 데이터만 서버에서 받아와 화면 일부를 동적으로 갱신하는 방식이다.

대표 기술은 다음과 같다.

React
Vue
Angular

SPA의 특징

1. 동적 콘텐츠 로딩

필요한 데이터만 서버에서 비동기적으로 가져와 화면을 업데이트한다.
페이지 전체를 새로고침하지 않기 때문에 빠른 사용자 경험을 제공할 수 있다.

2. 클라이언트 사이드 라우팅

화면 이동을 서버가 아닌 클라이언트의 JavaScript가 처리한다.
즉, URL은 바뀌지만 서버에서 새로운 HTML 페이지를 매번 받아오지는 않는다.

3. 상태 관리

사용자 인터페이스의 상태를 클라이언트에서 관리한다.
예를 들어 로그인 상태, 입력값, 선택된 메뉴, 장바구니 상태 등을 클라이언트에서 유지할 수 있다.

4. 재사용 가능한 컴포넌트

SPA는 컴포넌트 단위로 화면을 구성한다.
따라서 UI를 재사용하기 쉽고, 유지보수성과 확장성이 높다.

3. MPA 방식

MPA(Multi Page Application)

MPA는 사용자가 페이지를 이동할 때마다 서버가 새로운 HTML 페이지를 렌더링해서 클라이언트에게 전달하는 방식이다.

전통적인 서버 사이드 렌더링 방식에 가깝다.

대표 기술은 다음과 같다.

JSP
FreeMarker
Mustache

MPA의 특징

페이지 이동 시 서버에 새로운 페이지를 요청한다.
서버가 View를 생성해서 응답한다.
페이지마다 HTML을 새로 받아오기 때문에 화면 전환 시 새로고침이 발생한다.
MVC 모델에서 View 단을 담당하는 역할을 한다.

4. SPA와 MPA의 차이

구분	SPA	MPA
화면 처리	클라이언트에서 처리	서버에서 처리
페이지 이동	JavaScript 라우팅	서버에 새 페이지 요청
렌더링 위치	주로 클라이언트	주로 서버
서버 역할	API 제공 중심	HTML 렌더링 포함
사용자 경험	빠르고 부드러움	페이지 전환 시 새로고침
대표 기술	React, Vue, Angular	JSP, FreeMarker, Mustache

5. SPA 도입 이후 WAS의 역할 변화

SPA 방식에서는 View 처리를 클라이언트가 담당한다.
따라서 서버는 HTML 페이지를 직접 만들어주는 역할보다 데이터를 제공하는 API 서버 역할에 집중하게 된다.

즉, WAS의 역할이 단순해진다.

주요 역할은 다음과 같다.

데이터 조회
데이터 생성
데이터 수정
데이터 삭제
인증 및 인가 처리
비즈니스 로직 처리

결국 서버는 CRUD 중심의 API를 제공하게 된다.

6. Server 구조

서버 구조는 크게 Monolithic 방식과 MSA 방식으로 나눌 수 있다.

구분	Monolithic	MSA
구조	하나의 거대한 애플리케이션	기능별로 분리된 독립 서비스
배포	전체 시스템을 한 번에 배포	서비스별 독립 배포
확장성	전체 애플리케이션을 복제	특정 서비스만 개별 확장
데이터베이스	단일 DB 공유	서비스별 독립 DB 사용
장애 격리	하나의 장애가 전체 장애로 이어질 수 있음	장애 전파 가능성이 상대적으로 낮음
초기 개발	구조가 단순하고 빠름	설계와 인프라가 복잡함

7. Monolithic Architecture

Monolithic은 하나의 애플리케이션 안에 모든 기능이 포함된 구조이다.

예를 들어 다음 기능들이 하나의 프로젝트 안에 모두 들어간다.

회원 관리
상품 관리
주문 관리
결제 관리
배송 관리

장점

초기 개발이 쉽다.
구조가 단순하다.
배포 과정이 비교적 간단하다.
서비스 간 통신 비용이 적다.

단점

프로젝트가 커질수록 유지보수가 어려워진다.
일부 기능 수정도 전체 애플리케이션 배포가 필요할 수 있다.
특정 기능에 장애가 발생하면 전체 시스템에 영향을 줄 수 있다.
기능별 독립 확장이 어렵다.

8. MSA Architecture

MSA는 하나의 큰 애플리케이션을 여러 개의 작은 서비스로 분리하는 구조이다.

예를 들어 다음과 같이 나눌 수 있다.

회원 서비스
상품 서비스
주문 서비스
결제 서비스
배송 서비스

각 서비스는 독립적으로 개발, 배포, 운영될 수 있다.

장점

서비스별 독립 배포가 가능하다.
특정 서비스만 확장할 수 있다.
장애 격리가 가능하다.
팀별로 서비스를 나누어 개발하기 좋다.

단점

서비스 간 통신 구조가 복잡하다.
트랜잭션 관리가 어렵다.
인증/인가 처리가 복잡해질 수 있다.
인프라 운영 난이도가 높다.
로그 추적과 장애 분석이 어려워질 수 있다.

9. MSA의 주요 문제점

1. 트랜잭션 문제

Monolithic 구조에서는 하나의 DB를 사용하기 때문에 하나의 트랜잭션으로 여러 작업을 처리하기 쉽다.

하지만 MSA에서는 서비스마다 DB가 분리되어 있기 때문에 하나의 요청이 여러 서비스에 걸쳐 처리될 경우 트랜잭션 관리가 어려워진다.

예를 들어 주문 서비스와 결제 서비스가 분리되어 있다면 다음 문제가 발생할 수 있다.

주문은 생성되었지만 결제는 실패한 경우
결제는 성공했지만 주문 상태 변경이 실패한 경우
배송 요청은 생성되었지만 재고 차감이 실패한 경우

이런 문제를 해결하기 위해 Saga 패턴, 보상 트랜잭션, 이벤트 기반 처리 등을 사용할 수 있다.

2. 인증 문제

MSA에서는 여러 서비스가 분리되어 있기 때문에 사용자 인증 정보를 각 서비스에서 어떻게 검증할지가 중요하다.

일반적으로 JWT를 사용해 인증 정보를 전달한다.

JWT 기반 인증 흐름은 다음과 같다.

사용자가 로그인한다.
인증 서버가 JWT를 발급한다.
클라이언트는 요청마다 JWT를 함께 보낸다.
각 서비스는 JWT를 검증한 뒤 요청을 처리한다.

하지만 서비스가 많아지면 다음 문제가 생길 수 있다.

각 서비스마다 JWT 검증 로직이 중복될 수 있다.
토큰 만료 처리와 재발급 처리가 복잡해질 수 있다.
권한 정보가 변경되었을 때 기존 토큰과 불일치가 발생할 수 있다.
API Gateway에서 인증을 처리할지, 각 서비스에서 처리할지 설계가 필요하다.

핵심 요약

SPA 구조에서는 View를 Client가 담당하고, Server는 데이터 API 제공에 집중한다.
따라서 WAS는 CRUD 중심의 API 서버 역할을 하게 된다.

Server 구조는 크게 Monolithic과 MSA로 나뉜다.
Monolithic은 구조가 단순하고 초기 개발이 빠르지만, 규모가 커질수록 유지보수가 어렵다.
MSA는 서비스별 독립 배포와 확장이 가능하지만, 트랜잭션과 인증 같은 분산 시스템 문제가 발생한다.

[JPA] Intellij Dynamic Web project 생성

Wed, 20 May 2026 00:00:00 GMT

서론

IntelliJ IDEA에서 JSP/Servlet 기반의 Dynamic Web Project를 생성하는 과정을 정리한다. Eclipse에서는 Dynamic Web Project 메뉴를 통해 바로 생성할 수 있지만, IntelliJ에서는 Jakarta EE 템플릿과 Tomcat 실행 설정을 함께 잡아줘야 한다.

환경

IntelliJ IDEA 2025.3.1.1
JDK 11
Apache Tomcat 10.1.55

프로젝트 생성

새 프로젝트를 생성할 때 Jakarta EE를 선택하고 템플릿은 웹 애플리케이션으로 지정한다. Servlet, web.xml, index.jsp가 포함된 기본 웹 프로젝트 구조를 만들 수 있다.

애플리케이션 서버는 미리 연동해 둔 Tomcat 10.1.55를 선택한다. Tomcat이 아직 등록되어 있지 않다면 새로 만들기를 눌러 Tomcat 설치 경로를 지정한 뒤 다음 단계로 넘어간다.

Jakarta EE 버전은 JDK 11과 호환되는 버전으로 선택한다. 여기서는 Jakarta EE 10을 기준으로 진행하고, 설정이 끝나면 생성 버튼을 눌러 프로젝트를 만든다.

프로젝트가 생성되면 우측 상단의 실행 버튼을 눌러 Tomcat 서버를 실행한다. 기본 애플리케이션 컨텍스트는 보통 /{프로젝트명}_war_exploded 형태로 잡힌다.

애플리케이션 컨텍스트 경로 수정

컨텍스트 경로를 변경하려면 상단 메뉴에서 실행 > 구성 편집으로 이동한다. 이후 등록된 Tomcat 서버 설정을 선택하고 서버 탭을 확인한다.

배포 설정에서 애플리케이션 컨텍스트 값을 원하는 경로로 수정한다. 예를 들어 /로 설정하면 http://localhost:8080/에서 바로 프로젝트를 확인할 수 있다.

정리

IntelliJ에서 Dynamic Web Project를 만들 때는 Jakarta EE 템플릿을 사용하고, Tomcat 서버와 배포 아티팩트를 함께 설정해야 한다. 기본 컨텍스트 경로가 길게 생성될 수 있으므로, 실습이나 테스트 목적이라면 실행 구성에서 컨텍스트 경로를 간단하게 바꿔두는 것이 편하다.

[Data Modeling] 데이터 모델링 2일차 - 정규화, 반정규화

Thu, 07 May 2026 00:00:00 GMT

📍 연관 포스팅

[Data Modeling] 데이터 모델링 1일차 - 개념/논리/물리 모델링과 ERD 기초

[Data Modeling] 데이터 모델링 2일차 - 정규화, 반정규화

1. 들어가며

이번 글에서는 데이터 모델링에서 속성과 식별자를 정의하는 방법을 복습하고, 정규화와 반정규화의 핵심 개념을 정리한다. 1일차에서 엔티티와 관계를 도출하는 흐름을 봤다면, 2일차에서는 테이블 구조를 더 안정적으로 만드는 방법과 성능을 위해 의도적으로 구조를 바꾸는 방법을 다룬다.

속성의 유형
슈퍼타입과 서브타입
재귀적 관계
복합키와 대체키
정규화
반정규화
컬럼/테이블 반정규화 패턴

2. 모델링 속성과 식별자 복습

데이터 모델링에서 엔티티를 도출한 뒤에는 각 엔티티가 가져야 할 속성과 식별자를 정의해야 한다. 속성은 엔티티를 설명하는 세부 데이터이고, 식별자는 엔티티의 인스턴스를 유일하게 구분하는 기준이다.

2.1 Attribute

속성은 크게 기초 속성, 추출 속성, 설계 속성으로 나눌 수 있다.

유형	의미	예시
기초 속성	엔티티가 업무적으로 원래 가지고 있는 속성	이름, 생년월일, 주소
추출 속성	기초 속성으로부터 계산, 집계, 가공해서 얻을 수 있는 속성	총금액, 평균점수, 누적금액
설계 속성	실제 업무에는 없지만 시스템 효율을 위해 설계자가 부여하는 속성	순번, 코드, 상태값

추출 속성과 설계 속성은 편리하지만 데이터 중복과 무결성 문제를 만들 수 있다. 따라서 단순히 조회가 편하다는 이유만으로 추가하기보다는, 정합성을 유지할 방법까지 함께 설계해야 한다.

2.2 데이터 모델링 과정

데이터 모델링은 보통 다음 흐름으로 진행된다.

업무 요구사항 분석
핵심 엔티티 도출
엔티티 간 관계 정의
속성 정의
식별자 정의
정규화 수행
물리 모델 변환
성능 요구사항에 따른 반정규화 검토

3. 슈퍼타입과 서브타입

슈퍼타입과 서브타입은 공통 속성과 개별 속성을 분리해서 표현하는 모델링 방식이다. 슈퍼타입은 공통 속성을 가지는 상위 엔티티이고, 서브타입은 특정 유형에만 필요한 속성을 가지는 하위 엔티티다.

예를 들어 상품이라는 공통 개념 아래에 온라인상품, 오프라인상품, B2B상품 같은 유형이 있을 수 있다. 이때 상품명, 가격, 재고처럼 공통으로 필요한 속성은 상품에 두고, 유형별 속성은 각 서브타입에 둔다.

3.1 포함 관계 제약조건

서브타입 관계를 실제 테이블에 반영할 때는 제약조건을 통해 최소 하나의 유형에 속하도록 강제할 수 있다.

CREATE TABLE product (
  product_id   VARCHAR(10) PRIMARY KEY,
  product_name VARCHAR(100) NOT NULL,
  price        DECIMAL(10,2),
  stock        INT DEFAULT 0,
  online_yn    CHAR(1) DEFAULT 'N',
  offline_yn   CHAR(1) DEFAULT 'N',
  b2b_yn       CHAR(1) DEFAULT 'N',
  CONSTRAINT chk_at_least_one
    CHECK (online_yn = 'Y' OR offline_yn = 'Y' OR b2b_yn = 'Y')
);

위 제약조건은 하나의 상품이 온라인, 오프라인, B2B 중 최소 하나의 채널에는 반드시 속하도록 보장한다.

4. 재귀적 관계

재귀적 관계는 하나의 엔티티가 자기 자신과 관계를 맺는 구조다. 같은 테이블 안에서 특정 행의 FK가 다시 같은 테이블의 PK를 참조한다.

대표적인 예시는 직원과 직속 상사의 관계다. 직원도 같은 직원 테이블에 존재하고, 직속 상사도 같은 직원 테이블에 존재한다.

erDiagram
    direction LR
    EMPLOYEE ||..o{ EMPLOYEE : "감독"

    EMPLOYEE["직원"] {
        int employee_id PK "직원번호"
        int manager_employee_id FK "직속상사직원번호"
        string employee_name "직원명"
        date hired_at "입사일"
    }

재귀적 관계를 설계할 때는 최상위 데이터의 FK를 NULL로 허용할지, 별도의 루트 데이터를 둘지 같은 규칙도 함께 정해야 한다.

5. 복합키와 대체키

식별자를 설계할 때는 복합키를 사용할지, 순번 기반의 대체키를 사용할지 결정해야 한다. 실무에서는 순번키 + UNIQUE 복합키 패턴을 많이 사용한다. 순번키로 참조를 단순하게 만들고, 업무적으로 중복되면 안 되는 조합은 UNIQUE 제약조건으로 보장하는 방식이다.

5.1 복합키를 고려할 때

복합키는 관계 자체가 식별자가 되는 경우에 적합하다. 특히 M:N 관계를 해소하기 위한 중간 테이블에서 자주 사용한다.

관계 자체가 키인 경우
중간 테이블
변경 가능성이 거의 없는 경우
좋아요, 수강신청, 주문상세 같은 데이터

erDiagram
    direction LR
    MEMBER ||--o{ COURSE_ENROLLMENT : "신청"
    COURSE ||--o{ COURSE_ENROLLMENT : "포함"

    MEMBER["회원"] {
        int member_id PK "회원번호"
        string member_name "회원명"
    }

    COURSE["강의"] {
        int course_id PK "강의번호"
        string course_name "강의명"
    }

    COURSE_ENROLLMENT["수강신청"] {
        int member_id PK, FK "회원번호"
        int course_id PK, FK "강의번호"
        date enrolled_at "신청일"
    }

5.2 순번키를 고려할 때

순번키는 대부분의 일반 엔티티에 적합하다. 업무 속성이 바뀔 가능성이 있거나, 외부 테이블에서 자주 참조되는 테이블이라면 대체키를 두는 편이 관리하기 쉽다.

대부분의 일반 테이블
식별 속성 변경 가능성이 있는 경우
확장 가능성을 고려해야 하는 경우
회원, 주문, 게시판, 상품 같은 데이터

6. 정규화

정규화는 1972년 E. F. Codd가 제안한 이론으로, 데이터를 체계적으로 구조화해서 중복을 줄이고 이상현상을 제거하기 위한 방법이다. 정규화는 데이터 무결성을 높이는 방향의 설계다.

6.1 정규화가 필요한 이유

정규화가 필요한 이유는 크게 두 가지다.

엔티티를 구성하는 속성 간 중복을 제거해 데이터베이스를 최적화한다.
속성 간 함수 종속성 때문에 발생하는 이상현상을 제거한다.

이상현상은 다음 세 가지로 나눌 수 있다.

이상현상	의미
입력 이상	불필요한 데이터가 있어야만 원하는 데이터를 입력할 수 있는 문제
수정 이상	같은 의미의 데이터를 여러 곳에서 모두 수정해야 하는 문제
삭제 이상	특정 데이터를 삭제할 때 보존해야 할 정보까지 함께 사라지는 문제

예를 들어 주문 테이블에 제품 정보까지 함께 저장되어 있다면, 주문이 발생해야만 제품 정보를 등록할 수 있다. 또한 제품의 재고 수량이 여러 주문 행에 중복 저장되어 있다면, 재고를 바꿀 때 여러 행을 모두 수정해야 한다. 특정 제품의 마지막 주문 내역을 삭제하면 제품 정보까지 사라지는 문제도 생길 수 있다.

6.2 제1정규형

제1정규형은 모든 속성이 원자값을 가져야 한다는 규칙이다. 하나의 컬럼에 여러 값을 넣거나 반복 속성을 두면 안 된다.

모든 속성은 하나의 값만 가진다.
복수 값을 가지는 속성은 별도 엔티티로 분리한다.
반복되는 컬럼은 행으로 전환한다.

6.3 제2정규형

제2정규형은 기본키 전체에 종속되지 않는 속성을 분리하는 단계다. 특히 복합키를 사용하는 테이블에서 부분 종속이 발생할 수 있다.

예를 들어 주문번호 + 제품번호가 PK인 주문상세 테이블에 제품명이 들어 있다면, 제품명은 전체 키가 아니라 제품번호에만 종속된다. 이 경우 제품명은 제품 테이블로 분리해야 한다.

6.4 제3정규형

제3정규형은 일반 속성에 종속되는 속성을 분리하는 단계다. 즉, 기본키가 아닌 속성에 다른 속성이 종속되는 이행 종속을 제거한다.

현업에서는 보통 제3정규형까지 진행한 뒤, 성능 요구사항에 따라 반정규화를 검토하는 경우가 많다.

6.5 BCNF

BCNF는 결정자가 후보키가 아닌 경우를 제거하는 더 강한 정규화 형태다. 다수의 주식별자가 복잡하게 얽힌 경우 추가로 검토할 수 있다.

7. 반정규화

반정규화는 조회 성능을 높이거나 운영 편의성을 확보하기 위해 정규화된 구조를 의도적으로 일부 중복시키는 설계다. 정규화가 무결성을 우선한다면, 반정규화는 성능과 사용성을 위해 무결성 관리 비용을 감수하는 선택이다.

반정규화를 적용할 때는 반드시 다음 질문을 해야 한다.

어떤 조회 성능 문제가 있는가?
조인을 줄이는 것 외에 인덱스로 해결할 수 있는가?
중복 데이터의 정합성은 어떻게 보장할 것인가?
Trigger, 계산 컬럼, 배치, 애플리케이션 로직 중 어떤 방식으로 동기화할 것인가?

8. 컬럼 반정규화

컬럼 반정규화는 테이블은 유지하되, 조회 성능이나 복구 편의성을 위해 컬럼을 추가하는 방식이다.

대표적인 유형은 다음과 같다.

중복 컬럼 추가
파생 컬럼 추가
이력 컬럼 추가
PK 컬럼 분리
데이터 복구를 위한 컬럼 추가

8.1 중복 컬럼 추가

지점명은 업무지점 테이블에 존재하지만, 사원정보를 조회할 때마다 지점명까지 자주 필요하다면 사원정보에 지점명을 중복 저장하는 방식을 검토할 수 있다.

정규화된 구조는 다음과 같다.

erDiagram
    direction LR
    BRANCH ||..o{ EMPLOYEE_INFO : "소속"

    BRANCH["업무지점"] {
        int branch_id PK "지점번호"
        string branch_name "지점명"
        string location "지점위치"
        string phone_number "전화번호"
    }

    EMPLOYEE_INFO["사원정보"] {
        int employee_id PK "사원번호"
        string employee_name "이름"
        string phone_number "연락처"
        int branch_id FK "지점번호"
    }

반정규화를 적용하면 사원정보에 지점명을 중복 저장한다.

erDiagram
    direction LR
    BRANCH ||..o{ EMPLOYEE_INFO : "소속"

    BRANCH["업무지점"] {
        int branch_id PK "지점번호"
        string branch_name "지점명"
        string location "지점위치"
        string phone_number "전화번호"
    }

    EMPLOYEE_INFO["사원정보"] {
        int employee_id PK "사원번호"
        string employee_name "이름"
        string phone_number "연락처"
        int branch_id FK "지점번호"
        string branch_name "지점명"
    }

이렇게 하면 조회 시 조인을 줄일 수 있지만, 업무지점의 지점명이 변경될 때 사원정보의 지점명도 함께 갱신해야 한다.

8.2 파생 컬럼 추가

주문 총금액은 주문상세의 수량과 제품 단가를 통해 계산할 수 있다. 원칙적으로는 조회 시 계산할 수 있지만, 대부분의 조회에서 총금액이 필요하고 계산 비용이 크다면 주문 테이블에 총금액을 저장할 수 있다.

정규화된 구조는 다음과 같다.

erDiagram
    direction LR
    ORD ||--o{ ORDER_PRODUCT : "포함"
    PRODUCT ||--o{ ORDER_PRODUCT : "주문됨"

    ORD["주문"] {
        int order_id PK "주문번호"
        date ordered_at "주문날짜"
    }

    ORDER_PRODUCT["주문제품상세"] {
        int order_id PK, FK "주문번호"
        int product_id PK, FK "제품번호"
        int quantity "수량"
    }

    PRODUCT["제품"] {
        int product_id PK "제품번호"
        string product_name "제품이름"
        int unit_price "단가"
    }

반정규화를 적용하면 주문 테이블에 총금액 컬럼을 추가한다.

erDiagram
    direction LR
    ORD ||--o{ ORDER_PRODUCT : "포함"
    PRODUCT ||--o{ ORDER_PRODUCT : "주문됨"

    ORD["주문"] {
        int order_id PK "주문번호"
        date ordered_at "주문날짜"
        int total_amount "총금액"
    }

    ORDER_PRODUCT["주문제품상세"] {
        int order_id PK, FK "주문번호"
        int product_id PK, FK "제품번호"
        int quantity "수량"
    }

    PRODUCT["제품"] {
        int product_id PK "제품번호"
        string product_name "제품이름"
        int unit_price "단가"
    }

파생 컬럼을 저장할 때는 계산된 컬럼을 사용해 정합성을 확보할 수 있다.

ALTER TABLE emp ADD (totalsum NUMBER)
GENERATED ALWAYS AS (sal + NVL(comm, 0));

8.3 누적합 컬럼 주의

공사비 누적처럼 행 단위로 누적합을 저장하는 방식은 RDB 설계에서는 피하는 것이 좋다. 특정 중간 행의 공사비가 변경되면 이후 모든 누적값을 다시 계산해야 하기 때문이다.

erDiagram
    direction LR
    CONSTRUCTION_WORK["공사내역"] {
        int work_id PK "공사번호"
        date worked_at "공사일자"
        int cost "공사비"
        int accumulated_cost "공사비누적"
    }

누적합은 조회 시 윈도우 함수나 집계 쿼리로 계산하는 편이 안전하다.

8.4 최근 등록 여부 컬럼

직원의 차량 이력을 관리할 때 최근 등록 차량만 자주 조회한다면, 매번 Top N Query를 사용하는 대신 최근등록여부 컬럼을 둘 수 있다. 새 차량 이력이 등록되면 기존 최근 값은 N으로 바꾸고, 새 이력은 Y로 저장한다.

erDiagram
    direction LR
    COMPANY_EMPLOYEE ||..o{ EMPLOYEE_CAR_HISTORY : "보유이력"

    COMPANY_EMPLOYEE["회사직원"] {
        int employee_id PK "직원번호"
        string employee_name "직원명"
        date hired_at "입사일"
    }

    EMPLOYEE_CAR_HISTORY["직원차량이력"] {
        int car_history_id PK "차량이력번호"
        int employee_id FK "직원번호"
        string car_number "차량번호"
        string car_year "연식"
        string car_type "차종"
        date registered_at "등록일자"
        string latest_yn "최근등록여부"
    }

이 방식도 조회 성능은 좋아지지만, 최신 여부를 갱신하는 로직이 반드시 필요하다.

8.5 PK 분리 컬럼 반정규화

차량번호 안에 지역 정보가 포함되어 있더라도, 지역별 조회가 자주 발생한다면 지역을 별도 컬럼으로 분리할 수 있다. 이는 PK에 포함된 의미를 조회 성능을 위해 컬럼으로 분리하는 반정규화다.

erDiagram
    direction LR
    CAR["차량"] {
        string car_number PK "차량번호"
        string car_type "차종"
        string car_year "연식"
        string color "색상"
    }

    CAR_WITH_REGION["차량2"] {
        string car_number PK "차량번호"
        string car_type "차종"
        string car_year "연식"
        string color "색상"
        string region "지역"
    }

8.6 데이터 복구를 위한 컬럼 추가

현재 주소만 저장하면 주소 변경 이력을 복구하기 어렵다. 이전 값을 보관해야 하는 요구사항이 있다면 이전주소 같은 컬럼을 추가할 수 있다.

erDiagram
    direction LR
    CUSTOMER["고객"] {
        int customer_id PK "고객번호"
        string customer_name "고객명"
        string grade "등급"
        string address "주소"
        string previous_address "이전주소"
    }

단, 이력이 여러 건 필요하다면 이전주소 컬럼 하나를 추가하기보다 주소 이력 테이블을 별도로 두는 방식이 더 적절하다.

9. 테이블 반정규화

테이블 반정규화는 컬럼이 아니라 테이블 구조 자체를 조정하는 방식이다.

대표적인 방식은 다음과 같다.

관계 병합
테이블 분할
중복 테이블 추가
통계 테이블 추가
이력 테이블 추가
부분 테이블 추가

9.1 슈퍼타입과 서브타입 유지

슈퍼타입과 서브타입을 그대로 분리하면 공통 속성과 개별 속성을 명확히 나눌 수 있다.

erDiagram
    direction LR
    STUDENT ||..o| UNDERGRADUATE : "구체화"
    STUDENT ||..o| GRADUATE : "구체화"

    STUDENT["학생"] {
        int student_id PK "학번"
        string student_name "이름"
        date birth_date "생년월일"
        string phone_number "전화번호"
    }

    UNDERGRADUATE["학부생"] {
        int student_id PK, FK "학번"
        int grade "학년"
        string student_club "학회"
    }

    GRADUATE["대학원생"] {
        int student_id PK, FK "학번"
        string advisor "지도교수"
        string research_area "연구분야"
    }

이 방식은 정규화 관점에서 명확하지만, 학생의 전체 정보를 조회할 때 조인이 필요하다.

9.2 1:1 One To One

서브타입별 테이블에 공통 속성까지 모두 포함하는 방식이다. 학부생과 대학원생을 완전히 별도 테이블로 관리한다.

erDiagram
    direction LR
    UNDERGRADUATE["학부생"] {
        int student_id PK "학번"
        string student_name "이름"
        date birth_date "생년월일"
        string phone_number "전화번호"
        int grade "학년"
        string student_club "학회"
    }

    GRADUATE["대학원생"] {
        int student_id PK "학번"
        string student_name "이름"
        date birth_date "생년월일"
        string phone_number "전화번호"
        string advisor "지도교수"
        string research_area "연구분야"
    }

유형별 조회는 단순하지만, 공통 속성이 중복된다.

9.3 All In One Single Type

모든 속성을 하나의 테이블에 넣고 학생 유형에 따라 필요한 컬럼만 사용하는 방식이다.

erDiagram
    direction LR
    STUDENT["학생"] {
        int student_id PK "학번"
        string student_type "학생유형"
        string student_name "이름"
        date birth_date "생년월일"
        string phone_number "전화번호"
        int grade "학년"
        string student_club "학회"
        string advisor "지도교수"
        string research_area "연구분야"
    }

조인이 없어 조회가 단순하지만, 특정 유형에만 필요한 컬럼은 NULL이 많아질 수 있다.

10. 정리

정규화는 데이터 중복과 이상현상을 줄이기 위한 기본 원칙이다. 반정규화는 정규화 원칙을 일부 깨더라도 조회 성능이나 운영 편의성을 확보해야 할 때 선택하는 설계다.

중요한 것은 반정규화를 적용할 때마다 데이터 무결성을 어떻게 유지할 것인지 함께 결정하는 것이다. 중복 컬럼, 파생 컬럼, 최근 여부 컬럼은 모두 성능에는 도움이 될 수 있지만, 갱신 로직이 없으면 데이터 정합성을 깨뜨릴 수 있다.

따라서 모델링 단계에서는 정규화를 먼저 적용하고, 실제 조회 패턴과 성능 요구사항을 확인한 뒤 필요한 부분에만 반정규화를 적용하는 것이 좋다.

[Data Modeling] 데이터 모델링 1일차 - 개념/논리/물리 모델링과 ERD 기초

Wed, 06 May 2026 00:00:00 GMT

📍 연관 포스팅

[Data Modeling] 데이터 모델링 1일차 - 개념/논리/물리 모델링과 ERD 기초

[Data Modeling] 데이터 모델링 2일차 - 정규화, 반정규화

1. 들어가며

이번 글에서는 데이터 모델링의 기본 흐름과 ERD를 작성할 때 자주 만나는 설계 포인트를 정리한다. 데이터 모델링은 단순히 테이블을 만드는 작업이 아니라, 업무에서 관리해야 하는 데이터를 구조화하고 관계를 명확히 정의하는 과정이다.

실습 도구는 자유롭게 선택해도 되지만, 수업에서는 ERD Cloud와 ERD Editor를 기준으로 개념을 정리했다.

데이터 모델링의 단계
식별 관계와 비식별 관계
M:N 관계 해소
속성의 유형
설계 속성과 파생 속성
슈퍼타입과 서브타입
회사/직원/프로젝트 예제와 설문지 프로젝트 예제

2. 데이터 모델링의 전체 흐름

데이터 모델링은 보통 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링 순서로 진행된다. 각 단계는 목적이 다르기 때문에 처음부터 컬럼 타입이나 인덱스를 고민하기보다, 먼저 업무에서 어떤 데이터가 필요한지 파악하는 것이 중요하다.

2.1 개념 데이터 모델링

개념 데이터 모델링은 업무에서 관리해야 하는 핵심 엔티티를 추출하고, 전체 데이터 모델의 골격을 만드는 단계다. 이 단계에서는 상세 컬럼보다는 엔티티와 엔티티 사이의 관계를 파악하는 데 집중한다.

핵심 엔티티 추출
전체 데이터 모델의 골격 생성
개체-관계 다이어그램 작성

2.2 논리 데이터 모델링

논리 데이터 모델링은 개념 모델링에서 정의한 엔티티와 관계를 바탕으로 상세 속성을 정의하는 단계다. 이 단계에서는 식별자를 확정하고, 정규화와 같은 상세화 과정을 수행한다.

엔티티별 상세 속성 정의
식별자 확정
정규화 수행
트랜잭션 인터페이스 설계

2.3 물리 데이터 모델링

물리 데이터 모델링은 실제 사용할 DBMS의 특성과 구현 환경을 고려해 스키마를 구체화하는 단계다. 논리 모델을 실제 테이블, 컬럼, 인덱스 구조로 변환한다.

컬럼의 데이터 타입과 크기 정의
인덱스 정의
성능을 고려한 역정규화 검토
목표 DBMS에 맞는 스키마 도출

3. Entity와 Relationship 설계

3.1 Entity 도출

엔티티는 업무에서 독립적으로 관리할 필요가 있는 데이터의 집합이다. 예를 들어 회사 관리 시스템에서는 회사, 부서, 직원, 프로젝트, 부양가족 등이 엔티티 후보가 될 수 있다.

엔티티를 도출할 때는 다음 질문을 기준으로 판단하면 좋다.

업무에서 독립적으로 관리해야 하는 대상인가?
여러 개의 인스턴스가 존재할 수 있는가?
속성을 가질 수 있는가?
다른 엔티티와 관계를 맺는가?

3.2 식별 관계와 비식별 관계

식별 관계와 비식별 관계는 부모 엔티티의 키가 자식 엔티티에서 어떤 역할을 하는지에 따라 구분된다.

식별 관계: 부모 테이블의 키가 자식 테이블로 전이되었을 때, 자식 테이블의 기본키에 포함되는 관계
비식별 관계: 부모 테이블의 키가 자식 테이블로 전이되었지만, 자식 테이블의 일반 외래키로만 사용되는 관계

ERD에서는 보통 식별 관계를 실선, 비식별 관계를 점선으로 표현한다. 예를 들어 부서와 사원이 있을 때, 사원이 반드시 부서의 키를 자신의 기본키로 포함해야 하는 구조라면 식별 관계가 된다. 반대로 사원 테이블이 별도의 사원번호를 기본키로 가지고, 부서번호는 소속을 나타내는 외래키로만 사용된다면 비식별 관계가 된다.

3.3 M:N 관계 해소

관계형 데이터베이스에서는 M:N 관계를 직접 표현하기 어렵기 때문에, 보통 중간 테이블을 만들어 1:N 관계 두 개로 분해한다.

예를 들어 책과 저자의 관계를 생각해보면, 한 권의 책은 여러 저자를 가질 수 있고 한 명의 저자도 여러 책을 쓸 수 있다. 이 경우 책과 저자 사이에 책_저자 같은 연결 테이블을 둔다.

erDiagram
    direction LR
    BOOK ||--o{ BOOK_AUTHOR : "포함"
    AUTHOR ||--o{ BOOK_AUTHOR : "참여"

    BOOK["책"] {
        int book_id PK "책ID"
        string book_name "책이름"
    }

    AUTHOR["저자"] {
        int author_id PK "저자ID"
        string author_name "저자이름"
    }

    BOOK_AUTHOR["책_저자"] {
        int book_id PK, FK "책ID"
        int author_id PK, FK "저자ID"
    }

다만 조회 성능을 이유로 연결 테이블에 책이름, 저자이름 같은 값을 함께 저장하고 싶어질 수 있다. 하지만 이는 책 이름이 책 ID에 종속되고, 저자 이름이 저자 ID에 종속되는 구조이므로 2정규형을 위반한다.

성능 때문에 반정규화를 선택할 수는 있지만, 이 경우 데이터 중복과 무결성 문제가 발생한다. 저자 이름이 변경되었을 때 중복 저장된 값이 함께 변경되지 않으면 데이터 정합성이 깨진다. 반정규화를 적용해야 한다면 Trigger, 계산 컬럼, 배치 작업 등으로 정합성을 유지할 방법을 함께 설계해야 한다.

4. Attribute 설계

속성은 엔티티의 성질, 분류, 수량, 상태, 특성 등을 나타내는 세부 항목이다. 엔티티가 어떤 데이터를 보관해야 하는지 구체화하는 단계에서 속성을 정의한다.

4.1 기본 속성

기본 속성은 해당 엔티티가 업무적으로 원래 가지고 있는 속성이다. 예를 들어 직원 엔티티의 직원명, 주소, 급여, 성별, 생년월일 등은 기본 속성에 해당한다.

4.2 설계 속성

설계 속성은 원래 업무에는 존재하지 않지만, 시스템의 효율성이나 식별을 위해 임의로 추가하는 속성이다. 대표적으로 코드, 일련번호, 순번 같은 값이 있다.

예를 들어 고객센터 장애 조치 이력을 관리한다고 가정해보자. 한 고객에게 여러 번 방문할 수 있는데, 방문일자를 기본키에 포함하면 같은 날 여러 번 방문하는 경우를 표현하기 어렵다. 방문일시를 분 단위까지 늘릴 수도 있지만, 키 값이 길어지고 관리가 복잡해진다.

이럴 때 방문 순번 같은 설계 속성을 추가하면 중복을 방지하면서 방문 이력을 안정적으로 식별할 수 있다.

erDiagram
    direction LR
    CUSTOMER ||--o{ VISIT : "요청"

    CUSTOMER["고객"] {
        int customer_id PK "고객번호"
        string customer_name "고객명"
    }

    VISIT["방문"] {
        int customer_id PK, FK "고객번호"
        int visit_seq PK "방문순번"
        datetime visited_at "방문일시"
        string visit_content "방문내용"
    }

4.3 파생 속성

파생 속성은 다른 속성이나 다른 테이블의 데이터로부터 계산하거나 변형해서 얻을 수 있는 속성이다. 파생 속성은 데이터 중복과 무결성 문제를 만들 수 있기 때문에 가급적 적게 정의하는 것이 좋다.

예를 들어 사원 테이블에 부양자수 컬럼을 저장하는 경우를 생각해볼 수 있다. 부양자수는 부양가족 테이블에서 COUNT(*)로 계산할 수 있는 값이므로 파생 속성이다.

erDiagram
    direction LR
    EMPLOYEE ||--o{ DEPENDENT : "가짐"

    EMPLOYEE["사원"] {
        int employee_id PK "사원번호"
        string employee_name "사원명"
        int dependent_count "부양자수"
    }

    DEPENDENT["부양가족"] {
        int employee_id PK, FK "사원번호"
        string dependent_name PK "부양가족명"
        string relationship "관계"
    }

사원.부양자수를 별도 컬럼으로 저장하면 부양가족 데이터가 추가, 수정, 삭제될 때마다 함께 갱신해야 한다. 만약 실제 부양가족은 3명인데 사원 테이블의 부양자수가 2명이라면 데이터 정합성이 깨진 상태가 된다.

따라서 부양자수는 기본적으로 조회 시점에 계산하는 것이 적절하다. 성능상 반드시 저장해야 한다면 Trigger, Computed Column, 배치 작업 등을 통해 정합성을 유지해야 한다.

5. 설계 시 주의해야 할 문제

5.1 중복 속성 문제

방문1일시, 방문1내용, 방문2일시, 방문2내용처럼 반복되는 속성을 컬럼으로 계속 추가하는 방식은 좋지 않다. 방문 횟수가 늘어날 때마다 테이블 구조를 변경해야 하고, 조회와 관리도 어려워진다.

이런 경우 반복되는 속성을 별도의 엔티티로 분리해야 한다. 방문은 고객에 종속된 반복 데이터이므로 방문 테이블을 따로 만들고, 고객과 방문을 1:N 관계로 설계하는 것이 적절하다.

5.2 파생 속성의 정합성 문제

파생 속성은 편리하지만 정합성 문제가 발생하기 쉽다. 다른 테이블에서 계산 가능한 값을 컬럼으로 저장하면, 원본 데이터가 변경될 때 파생 컬럼도 함께 갱신되어야 한다.

따라서 파생 속성을 저장할 때는 다음 기준을 함께 검토해야 한다.

조회 성능상 정말 저장이 필요한가?
원본 데이터 변경 시 파생 값을 어떻게 갱신할 것인가?
Trigger, 계산 컬럼, 배치 작업 중 어떤 방식이 적절한가?
데이터 불일치가 발생했을 때 검증할 수 있는가?

5.3 반정규화와 성능 사이의 균형

정규화는 데이터 중복을 줄이고 무결성을 높이는 데 도움이 된다. 하지만 모든 조회에서 여러 테이블 조인이 반복되면 성능 문제가 발생할 수 있다.

예를 들어 책 ID, 저자 ID, 책 이름, 저자 이름을 자주 조회해야 한다면 책, 저자, 책_저자 세 테이블을 매번 조인해야 한다. 이 경우 성능 요구사항에 따라 일부 값을 중복 저장하는 반정규화를 검토할 수 있다.

다만 반정규화는 정규화 위반을 의도적으로 감수하는 설계다. 따라서 성능 이점과 데이터 무결성 비용을 함께 판단해야 한다.

6. 슈퍼타입과 서브타입

슈퍼타입과 서브타입은 공통 속성과 개별 속성을 분리하기 위한 모델링 방식이다. 슈퍼타입은 공통사항을 추상화한 부모 엔티티이고, 서브타입은 구체적인 유형을 나타내는 자식 엔티티다.

예를 들어 사원이라는 공통 개념 아래에 기술직과 관리직이 있을 수 있다. 사원 테이블에는 모든 사원이 공통으로 가지는 속성을 두고, 기술직과 관리직 테이블에는 각 유형만 가지는 속성을 둔다.

배타적 관계는 슈퍼타입의 하나의 인스턴스가 여러 서브타입 중 반드시 하나의 서브타입에만 속하는 관계를 말한다. 즉, 어떤 사원은 기술직이거나 관리직이며 동시에 두 유형에 속하지 않는 구조다.

7. 실습 ERD 정리

7.1 회사-부서-직원-프로젝트 예제

다음은 회사, 부서, 직원, 프로젝트, 지역, 부양가족을 기준으로 정리한 ERD 예제다. 직원과 프로젝트는 M:N 관계이므로 직원_프로젝트 연결 테이블로 해소한다.

erDiagram
    direction LR
    COMPANY ||--o{ DEPARTMENT : "구성"
    DEPARTMENT ||..o{ EMPLOYEE : "소속"
    EMPLOYEE ||..o| DEPARTMENT : "관리"
    DEPARTMENT ||..o{ LOCATION : "위치"
    DEPARTMENT ||..o{ PROJECT : "관리"
    EMPLOYEE ||--o{ EMPLOYEE_PROJECT : "참여"
    PROJECT ||--o{ EMPLOYEE_PROJECT : "포함"
    EMPLOYEE ||--o{ DEPENDENT : "가짐"
    EMPLOYEE ||..o{ EMPLOYEE : "감독"
    PROJECT ||..|| LOCATION : "위치"

    COMPANY["회사"] {
        int company_id PK "회사번호"
    }

    DEPARTMENT["부서"] {
        int department_id PK "부서번호"
        int company_id PK, FK "회사번호"
        int manager_employee_id FK "관리자직원번호"
        string department_name "부서명"
        int employee_count "부서내직원수"
        date manager_started_at "관리자근무시작일"
    }

    LOCATION["지역"] {
        int location_id PK "지역ID"
        int department_id FK "부서번호"
        string location_name "지역명"
    }

    PROJECT["프로젝트"] {
        int project_id PK "프로젝트번호"
        int department_id FK "부서번호"
        int location_id FK "지역ID"
        string project_name "프로젝트명"
    }

    EMPLOYEE["직원"] {
        int employee_id PK "직원번호"
        int supervisor_employee_id FK "직속상사직원번호"
        int department_id FK "부서번호"
        string resident_number "주민번호"
        string employee_name "직원명"
        string address "주소"
        int salary "급여"
        string gender "성별"
        date birth_date "생년월일"
    }

    EMPLOYEE_PROJECT["직원_프로젝트"] {
        int employee_id PK, FK "직원번호"
        int project_id PK, FK "프로젝트번호"
        int work_hours "근무시간"
    }

    DEPENDENT["부양가족"] {
        string dependent_name PK "부양가족명"
        int employee_id PK, FK "직원번호"
        string gender "성별"
        date birth_date "생년월일"
        string relationship "관계"
    }

7.2 설문지 프로젝트 예제

설문지 프로젝트에서는 설문지, 설문지항목, 설문지문항을 엔티티로 도출할 수 있다. 하나의 설문지는 여러 항목을 가지고, 하나의 항목은 여러 문항을 가진다.

erDiagram
    direction LR
    SURVEY ||--o{ SURVEY_ITEM : "포함"
    SURVEY_ITEM ||--|{ SURVEY_OPTION : "구성"

    SURVEY["설문지"] {
        int survey_id PK "설문지번호"
        string title "제목"
        date created_at "작성일자"
        date started_at "설문지시작일"
        date ended_at "설문지종료일"
        string is_closed "설문지작성마감여부"
        string description "설명"
    }

    SURVEY_ITEM["설문지항목"] {
        int question_id PK "문제번호"
        string question "문제"
        int survey_id FK "설문지번호"
    }

    SURVEY_OPTION["설문지문항"] {
        int survey_id PK, FK "설문지번호"
        int question_id FK "문제번호"
        int option_id "문항번호"
        string option_content "문항내용"
    }

8. 오늘의 회고

데이터 모델링에서 중요한 것은 테이블을 빠르게 만드는 것이 아니라, 업무 규칙을 데이터 구조로 정확하게 표현하는 것이다. 특히 M:N 관계 해소, 식별 관계와 비식별 관계 구분, 파생 속성의 저장 여부는 실제 설계에서 자주 고민해야 하는 부분이다.

정규화는 데이터 무결성을 지키기 위한 기본 원칙이고, 반정규화는 성능 요구사항 때문에 선택하는 예외적인 설계다. 따라서 반정규화를 적용할 때는 중복 데이터의 정합성을 어떻게 유지할지까지 함께 설계해야 한다.

참고자료

DB - 개체 간의 관계들

[008] 자바 인터페이스 정리

Mon, 13 Apr 2026 00:00:00 GMT

개선된 for문


for (타입 변수명 : 배열이나컬렉션) {
    // 반복 실행할 코드
}

// 1차원 배열 
int[] scores = {90, 80, 70, 100};
int sum = 0;

for (int score : scores) {
    sum += score;
}

// 다차원 배열 
int[][] matrix = { {1, 2}, {3, 4} };

for (int[] row : matrix) {     // 1. matrix에서 1차원 배열(행)을 꺼냄
    for (int value : row) {    // 2. 꺼낸 행에서 실제 값(int)을 꺼냄
        System.out.print(value);
    }
}

인터페이스

인터페이스는 소프트웨어 설계 최상위 단계
인터페이스는 무에서 유를 창조

인터페이스란?

약속, 규칙, 규약, 표준을 만드는 행위를 말함

표준이란?

아이폰의 C타입 충전
볼트를 조일 때 오른쪽
엘리베이터의 상승 버튼 (삼각형)등

ISO(International Organization for Standardization) 표준 : 국가

인터페이스는 약속(규약)만 존재하며, 구현부는 존재하지 않는다.

추상클래스와 인터페이스의 공통점

스스로 객체를 만들 수 없다. (구현부가 존재하지 않는다. - new 연산자 사용 불가 )
- 차이점 ?
  
  추상 (완성 + 미완성의 결합) , 인터페이스 (미완성 자원)
추상클래스 extends

인터페이스 implements
```
class Car extends AbClass{}  //상속
class Car extends Object implemenets Ia {}  // 구현
// Car는 Object를 상속하고, Ia를 구현한다. 
```
둘 다 추상자원 (실행 블럭이 없다) → 미완성 자원

⇒ 강제적 구현 이 목적이다. → 재정의 (override) 해야 함.
다른점

다중상속 : 인터페이스는 다중 상속(구현)

약속의 범위는 작게 하는 것이 좋다 . (재사용성 높게 하기 위함)
- 인터페이스끼리는 서로 상속이 가능 ⇒ 약속을 더 크게(?)
- 인터페이스 구현하는 입장에서 보면 다중 구현
```
// Ia, Ib, Ic
class Text extends Object implements Ia, Ib, Ic {
	
}
```
인터페이스는 (상수를 제외한 나머지는 추상함수 ) > JDK8 (default, static)
- 초급 개발자의 시선에서 바라보면,
  1. 인터페이스는 [다형성] 입장으로 접근 (70 ~ 80 % 해결) ; 인터페이스는 부모 타입
  2. 서로 연관성이 없는 클래스를 하나로 묶어주는 역할⭐️⭐️⭐️
    - 같은 부모를 가지므로..
  3. 자바 만든 아저씨 >> JAVA API 당신이 설계한 왠만한 것들을 만들어줄게 >> 수많은 인터페이스 활용
  4. 인터페이스의 해석은 (~able ; ~할 수 있는)으로 해석됨.
    - 날 수 있는
    - 수리할 수 있는
    - 먹을 수 있는
  5. 객체간 연결 고리 (객체간 소통의 역할 ) : 다형성의 원리로 접근

interface summary

실제 구현부를 가지고 있지 않다. > 실행 블럭이 없다.
Interfacte Iable { void move(int x, int y); }
JAVA API → Collection > List, Set, Map을 이해해야 함

#1 Interface 생성

interface Ia {
	// 상수 구현 
	// public static final int VERSION = 1; -> 컴파일러는 인터페이스가 가지고 있는 모든 자원을 상수로 취급함
	int VERSION = 1; // 앞에 public static final이 생략됨. 
	
	// 추상 함수 
	// public abstract void run();
	void run(); // 앞에 public abstract 컴파일러가 자동으로 붙임 
	
}

#2 Ia와 Ib는 같음

interface Ia {
	public static final int AGE = 100;
	public static final String GENDER = "남";

	public abstract String print();

	public abstract void message(String str);
}

interface Ib {
	int AGE = 100;
	String Gender = "남";

	String print();

	void message(String str);
}

#3 Interface 구현부 > 상속 & Override

class Test2 extends Object implements Ib, Ic {

	@Override
	public String print() {
		// TODO Auto-generated method stub
		return null;
	}

	@Override
	public void message(String str) {
		// TODO Auto-generated method stub

	}

}

public class Ex03_Interface {

	public static void main(String[] args) {
		Test2 test2 = new Test2();

		Ib ib = test2;

		System.out.println(ib.AGE);
		System.out.println(ib.Gender);
		System.out.println(ib.toString());
	}

}

Quiz. 인터페이스에서

정답

해설 : 모든 참조 타입은 Object 메서드를 사용할 수 있도록 허용한다.

인터페이스 타입도 자바의 참조 타입이기 때문에, Object의 자원을 사용할 수 있다.

[OOP] 템플릿 메서드 패턴 정리

Mon, 13 Apr 2026 00:00:00 GMT

1. 템플릿 메서드 패턴이란?

작업의 뼈대는 미리 정해두고 구체적인 단계는 자식 클래스에서 구현하게 만든 패턴.

상위 클래스에서 실행 프로세스의 순서를 정의하고, 그 일부 단계를 abstract 메서드나 상속 가능한 메서드로 비워둔다.
- 알고리즘의 뼈대
- 자식이 건들이지 못하도록 final 로 선언함
하위 클래스에서는 해당 상위 클래스를 오버라이딩 세부 로직을 채우는 방식

구조

Template Method : 알고리즘의 전체 흐름을 정의 (변경 불가)
Primitive Operations (추상 메서드): 하위 클래스가 구현해야 하는 부분
Hook (선택적 메서드) : 기본 구현이 있지만, 필요시 오버라이드 가능

2. 언제 사용하나?

알고리즘 구조가 동일할 때 but. 일부 단계만 다를때
순서를 강제해야할 때
- 파일 처리 로직 (열기 → 읽기 → 닫기)
- 게임 턴 처리
  
  [턴 시작] → [행동 선택] → [행동 수행] → [결과 처리] → [턴 종료]
- Spring Framework의 JdbcTemplate
  1. 커넥션 생성
  2. 쿼리 실행 (개발자가 정의)
  3. ResultSet 처리 (개발자가 정의)
  4. 커넥션 반환
- API 요청 처리
  1. 요청 검증
  2. 인증 / 인가 체크
  3. 비즈니스 로직 실행
  4. 응답 생성
  5. 로깅
- 로그 / 트랜잭션 처리
  1. 트랜잭션 시작
  2. 비즈니스 로직 실행
  3. 커밋 or 롤백
  4. 로그 기록
코드의 중복을 줄이고 싶을 때
확장을 제어하고 싶을 때

1. 추상 클래스 (부모)

알고리즘의 뼈대를 정의함.

공통 로직은 직접 구현하고, 달라지는 로직은 추상 메서드로 비워둠

abstract class CaffeineBeverage {
    // 템플릿 메서드: 실행 순서를 정의하며, 자식이 오버라이드 하지 못하도록 final 선언
    final void prepareRecipe() {
        boilWater();
        brew();
        pourInCup();
        addCondiments();
    }

    // 공통 로직
    void boilWater() {
        System.out.println("물 끓이는 중...");
    }

    void pourInCup() {
        System.out.println("컵에 붓는 중...");
    }

    // 상세 구현은 자식에게 맡김
    abstract void brew();
    abstract void addCondiments();
}

2. 구체 클래스 (자식)

부모가 비워든 메서드를 상황에 맞게 구현

class Coffee extends CaffeineBeverage { // 자식은 추상화(부모) 클래스를 상속 받음
    
    @Override
    void brew() {
        System.out.println("필터를 통해 커피를 우려내는 중...");
    }

    @Override
    void addCondiments() {
        System.out.println("설탕과 우유를 추가하는 중...");
    }
}

class Tea extends CaffeineBeverage {
    @Override
    void brew() {
        System.out.println("찻잎을 우려내는 중...");
    }

    @Override
    void addCondiments() {
        System.out.println("레몬을 추가하는 중...");
    }
}

3. 메인 실행부

public class Main {
    public static void main(String[] args) {
        CaffeineBeverage coffee = new Coffee();
        CaffeineBeverage tea = new Tea();

        System.out.println("--- 커피 준비 ---");
        coffee.prepareRecipe(); // 

        System.out.println("\n--- 차 준비 ---");
        tea.prepareRecipe();
    }
}

3. 템플릿 메서드의 장/단점

장점

코드 중복 제거
알고리즘 구조 통일
확장성 용이 (OCP 만족)
상위 클래스가 흐름 통제

단점

상속 기반 → 유연성 제한
클래스 수 증가
런타임 변경 어려움 (컴파일 시 결정됨)

4주차 - 네트워크

Sun, 12 Apr 2026 00:00:00 GMT

🌐 HTTP 상태 코드(Status Code) 핵심 요약

HTTP 상태 코드는 클라이언트가 보낸 요청에 대해 서버가 어떤 상태인지 알려주는 3자리 숫자이다. 각 앞자리에 따라 대략적인 상태를 파악할 수 있다.

1xx (Informational) : 정보 전달

서버가 요청을 받았으며, 해당 프로세스를 계속 진행 중임을 의미한다.

100 Continue: 요청의 시작 부분이 서버에 수용되었으니, 나머지 요청을 계속 보내도 좋다는 것을 뜻한다.

2xx (Successful) : 성공

서버가 클라이언트의 요청을 성공적으로 수신하고 처리했음을 의미한다.

200 OK: 요청이 성공적으로 완료되었음을 나타낸다.
201 Created: 요청이 성공적이었으며, 그 결과로 새로운 리소스가 서버에 생성되었다.

3xx (Redirection) : 리다이렉션

요청을 완료하기 위해 클라이언트 측에서 추가적인 조치가 필요함을 의미한다.

301 Moved Permanently: 요청한 리소스의 URI가 영구적으로 변경되었음을 의미한다.
- 예: 서버가 /api에서 제공하던 서비스를 /api2로 변경했을 때, 기존 경로로 들어온 요청에 이 코드를 반환하여 새 주소를 안내한다.

4xx (Client Error) : 클라이언트 오류

클라이언트의 요청에 잘못된 문법이 있거나 요청을 처리할 수 없는 경우 발생한다.

400 Bad Request: 서버가 클라이언트의 요청을 이해할 수 없음을 뜻한다. (잘못된 파라미터 등)
401 Unauthorized: 해당 요청을 위해 클라이언트의 인증(ID/PW 등) 절차가 필요함을 의미한다.
404 Not Found: 요청받은 콘텐츠를 서버에서 찾을 수 없음을 나타낸다. (잘못된 URL 경로 등)

5xx (Server Error) : 서버 오류

클라이언트의 요청은 유효했으나, 서버가 요청을 처리하는 과정에서 오류가 발생했음을 의미한다.

500 Internal Server Error: 서버 내부의 문제로 인해 요청을 처리할 수 없는 범용적인 에러 상황이다.
502 Bad Gateway: 게이트웨이 또는 프록시서버가 정해진 Timeout 시간동안 클라이언트의 요청을 처리하지 못함
503 Service Unavailable: 서버가 현재 점검 중이거나 과부하로 인해 일시적으로 응답을 할 수 없는 상태이다.

HTTP 메서드

GET : 데이터 조회 (Retrieve)

주로 서버로부터 정보를 조회하기 위해 사용하며, 모든 요청 데이터가 URL에 노출되는 특징을 가진다.

데이터 전달 방식: URL의 쿼리 스트링(Query String)을 통해 데이터를 전달한다.
- 길이 제한: URL을 기반으로 하기 때문에 약 2,000자의 길이 제한이 존재한다.
상태 코드: 요청 성공 시 일반적으로 200 OK를 반환한다.
캐싱 가능: 동일한 요청에 대해 브라우저가 결과를 캐싱할 수 있어 응답 속도가 빠르다.
보안성: URL에 파라미터가 그대로 노출되어 브라우저 기록(History)에 남으므로, 비밀번호 등 민감한 정보 전달에는 적합하지 않다.
데이터 타입: ASCII 문자열 형식의 데이터만 보낼 수 있다.

POST : 데이터 처리 및 생성 (Create)

새로운 리소스를 생성하거나 업데이트할 때 사용하며, 대량의 데이터를 안전하게 보낼 수 있다.

데이터 전달 방식: URL이 아닌 HTTP 메시지의 Body에 데이터를 담아 전달한다.
길이 제한: 데이터 크기에 대한 별도의 제한이 없어 대용량 파일 전송도 가능하다.
보안성: 요청 파라미터가 URL에 노출되지 않아 브라우저 기록에 남지 않는다. (단, 암호화를 하지 않으면 패킷 분석을 통해 내용을 볼 수 있으므로 HTTPS 사용이 권장된다.)
데이터 타입: 문자열뿐만 아니라 바이너리 데이터, JSON, 이미지 등 모든 유형의 데이터를 보낼 수 있다.
캐싱 불가: 서버의 상태를 변경하는 작업이 많으므로 기본적으로 캐싱을 하지 않는다.
사용 사례: 사용자 가입, 로그인, 게시글 작성 등 민감한 정보나 큰 데이터를 보낼 때 사용한다.

PUT : 리소스의 전체 교체

대상 리소스를 새로운 데이터로 완전히 대체하는 방식

전체 데이터 전송: 업데이트하려는 리소스의 모든 필드값을 보내야함.
덮어쓰기: 만약 요청 시에 특정 필드를 생략하고 보낼 경우,
- 서버에 따라 해당 필드가 삭제되거나 null로 업데이트 될 수 있음.
리소스 생성: 요청한 URI에 리소스가 존재하지 않을 경우, 서버 설정에 따라 새로운 리소스를 생성하기도 함.
멱등성(Idempotent): 동일한 요청을 여러 번 보내도 결과가 항상 같음

PATCH: 리소스의 부분수정

리소스를 전체 교체하지 않고, 변경이 필요한 특정 필드만을 수정하는 방식

일부 데이터 전송 : 수정하고 싶은 데이터만 담아서 보냄
효율성: 전체 데이터를 보낼 필요가 없으므로 네트워크 대역폭을 절약할 수 있음
비멱등성 가능성: 구현 방식에 따라 여러 번 요청했을 때 결과가 달라질 수 있어 주의가 필요

비교 예시

만약 사용자 데이터가 "id": 1, "name": "woojin", "age": 25"} 일 때,

메서드	요청 데이터 (Body)	결과
PUT	`{ "name": "Flash" }`	`{ "id": 1, "name": "Flash" }` (나머지 정보 삭제/초기화 위험)
PATCH	`{ "name": "Flash" }`	`{ "id": 1, "name": "Flash", "age": 20 }` (이름만 변경됨)

따라서,

리소스의 전체를 갈아치우고 싶다면 PUT, 특정 일부만을 고치고 싶다면 PATCH를 사용해야 한다.

네트워크를 이루는 장치의 이해

레이어별 네트워크 장치

어플리케이션 계층 : L7 스위치
전송 계층: L4 스위치
인터넷 계층(네트워크 계층) : 라우터, L3 스위치
데이터 링크 계층 : L2 스위치, 브리지
물리 계층 : NIC, 리피터, AP

# 1 어플리케이션 계층 - L7 스위치

L7 스위치란? 로드밸런서라고도 하며, 서버의 부하를 분산하는 기기다.

서버 이중화, 보안에 강점이 있다.
IP, Port, url, 헤더, 쿠키 등을 기반으로 트래픽을 분산한다.
헬스 체크를 통해 장애가 발생한 서버를 확인하고 해당 서버로 트래픽을 보내지 못하게 하는 역할을 한다.
- 헬스 체크란?
  
  TCP를 일정 시간 마다 전송하여, 응답을 확인함.
  
  참고) AWS에서 L7 스위치를 이용한 로드 밸런싱은 ALB라는 컴포넌트를 통해서 하며 L4 스위치를 이용한 로드밸런싱은 NLB 컴포넌트를 통해 구축한다.

# 2 전송 계층 - L4 스위치

L4 스위치란?

앞서 설명한 로드밸런서의 특징인 트래픽 분산 등을 할 수 있다.

패킷의 IP 주소와 Port 번호를 참고하여 적절히 트래픽 분산을 할 수 있다.
전송계층의 TCP, UDP 등의 헤더를 기반으로 우선순위를 판단해서 분산이 가능하다.
L7와 같이 헬스체크가 가능함.

# 3 인터넷 계층 - 라우터, L3 스위치

라우팅이란?

하나 이상의 네트워크 경로를 선택하는 프로세스를 말함.

이 라우팅을 하는 장비를 라우터(Router)라고 함.
다른 네트워크에 존재하는 장치끼리 서로 데이터를 주고 받을 때 **“패킷소모 최적화”, “경로 최적화”**하는 장비

L3 스위치란?

L2 스위치의 기능과 라우팅을 하는 장비이다.

라우팅 테이블을 참조해서 IP 패킷에 IP주소를 담아 보낸다.

# 2 전송 계층 - L4 스위치

L4 스위치란?

앞서 설명한 로드밸런서의 특징인 트래픽 분산 등을 할 수 있다.

패킷의 IP 주소와 Port 번호를 참고하여 적절히 트래픽 분산을 할 수 있다.
전송계층의 TCP, UDP 등의 헤더를 기반으로 우선순위를 판단해서 분산이 가능하다.
L7와 같이 헬스체크가 가능함.

# 3 인터넷 계층 - 라우터, L3 스위치

라우팅이란?

하나 이상의 네트워크 경로를 선택하는 프로세스를 말함.

이 라우팅을 하는 장비를 라우터(Router)라고 함.
다른 네트워크에 존재하는 장치끼리 서로 데이터를 주고 받을 때 **“패킷소모 최적화”, “경로 최적화”**하는 장비

L3 스위치란?

L2 스위치의 기능과 라우팅을 하는 장비이다.

라우팅 테이블을 참조해서 IP 패킷에 IP주소를 담아 보낸다.
- 라우팅 테이블
- IP 주소
- IP 패킷

# 4 데이터 링크 계층

데이터 링크 계층은 이더넷 프레임을 통해 에러 확인, 흐름 제어, 접근 제어를 담당하는 계층을 말한다.

L2 스위치

L2 스위치는 장치들의 MAC 주소를 MAC 주소 테이블을 통해 관리함.

해당 테이블을 기반으로 인터넷 계층에서 받은 패킷을 기반으로 이더넷 프레임을 만들어 목적지 MAC 주소로 패킷을 보내주는 역하을 한다.
- MAC 주소 테이블
- MAC 주소
- 이더넷 프레임

브리지

브리지(bridge)는 두 개의 근거리 통신망(LAN)을 상호 접속할 수 있도록 하는 통신망 연결 장치를 말한다.

통신망의 범위를 확장하고 LAN을 기반으로 하나의 통신망을 구축할 때 쓰임.

유선 LAN #1. 전이중화 통신, CSMA/CD

전이중화(full duplex)란?

양쪽 장치가 동시에 송수신할 수 있는 방식을 말한다. 동축케이블, 광케이블 등을 기반으로 만들어진 유선 LAN을 이루는 이더넷은 IEEE802.3 프로토콜을 기반으로 전이중화 통신을 쓴다.

IEEE802.3

이더넷프레임은 어떤 구조를 기반으로 할 것인지, 케이블의 최대 전송량, 어떤 케이블만이 가능하도록 할 것인지 등을 정한 규칙을 말함.

전이중화 통신

양쪽 장치가 동시에 송수신할 수 있는 방식, 송신로와 수신로를 나눠서 데이터를 주고 받을 수 있다.

CSMA/CD

이전에는 유선 LAN에 ‘반이중화 통신’ 중 하나인 CSMA/CD(Carrier Sense Multiple Access with Collision Detection) 방식을 썼다. 이 방식은 회선을 사용하는 지를 파악한 후 사용하지 않는 다면 데이터를 보내고 충돌이 발생한다면 일정 시간 이후 재전송 하는 방식을 말한다.

유선 LAN #2 케이블

트위스트페어 케이블

트위스트 페어 케이블은 2가지로 나뉜다.

STP: 실드처리 한 케이블
UTP: 실드처리를 안한 케이블

광섬유 케이블

레이저를 이용해 통신하며 보통 100Gbps의 데이터를 전송하는 케이블

코어 : 빛의 굴절률이 높은 부분
클래딩 : 빛의 굴절률이 낮은 부분
- 다른 밀도를 가지는 유리나 플라스틱 섬유 기반으로 제작
- 한번 들어간 빛이 내부에서 계속 반사하며 전진하여 반대편 끝까지 가는 원리를 이용함

무선 LAN #1 반이중화통신, CSMA/CA, 와이파이

무선랜은 IEEE802.11 표준 규격을 따르며 반이중화 통신을 사용한다.

반이중화 통신

반이중화 통신은 양쪽 장치는 서로 통신할 수 있지만, 동시에는 통신할 수 없으며 한 번에 한 방향만 통신할 수 있는 방식을 말함.

CSMA/CA

반이중화 통신 중 하나로 장치에서 데이터를 보내기 전에 일련의 과정을 기반으로 사전에 최대한 충돌을 방지하는 방식을 말함.

반이중화 통신 과정

사용중인 채널이 있다면, 다른 채널을 감지하다 유후 상태인 채널 발견
프레임 간 공간 시간인 IFS(InterFrame Space)시간만큼 기다림
프레임을 보내기 전 $0$ ~ $2^{K-1}$ 사이에서 결정된 랜덤 상수를 기반으로 결정된 시간만큼 기다린 뒤 프레임을 보냄
- 프레임을 보낸 뒤 제대로 송신되었고 ACK 세그먼트를 받았다면 마무리
- 받지 못하였을 경우,
  
  $k=k+1$ 을 하며 이 과정을 반복함
- 반복하다가 k가 정해진 Kmax보다 더 커지면, 해당 프레임 전송은 abort

[알고리즘] 투포인터 정리

Fri, 03 Apr 2026 00:00:00 GMT

투포인터(Two Pointers) 패턴 정리

참고자료

Two Pointers in 7 minutes | LeetCode Pattern Sliding Window in 7 minutes | LeetCode Pattern

1. 투포인터란 무엇인가?

투 포인터는 데이터 구조(주로 배열이나 연결 리스트)에서 두 개의 변수(포인터)를 사용하여 데이터의 위치를 가리키고, 특정 조건에 따라 이 포인터를 이동시키며 문제를 해결하는 기법

2. 투포인터의 3가지 주요 전략

1) 수렴형 포인터(Converging Pointers)

방향 : 양 끝에서 시작하여 가운데로 이동
용도 : 양 끝 요소를 비교해야할 때 유용
대표 예
- 회문(Palindrome) 체크, 양 끝 문자를 비교하며 같으면 안으로 이동, 다르면 즉시 종료

수렴형 포인터 템플릿

def converging_pointers(arr, target):
    # 1. 배열 정렬 (원본 배열을 변경하거나 sorted(arr) 사용)
    arr.sort()

    # 2. 포인터 초기화
    left = 0
    right = len(arr) - 1

    # 3. 두 포인터가 만날 때까지 반복
    while left < right:
        current_sum = arr[left] + arr[right]

        if current_sum == target:
            # 정답을 찾은 경우
            print(f"Found: {arr[left]}, {arr[right]}")
            return (arr[left], arr[right])
        
        elif current_sum < target:
            # 합이 타겟보다 작으면 값을 키우기 위해 left를 오른쪽으로 이동
            left += 1
        else:
            # 합이 타겟보다 크면 값을 줄이기 위해 right를 왼쪽으로 이동
            right -= 1
            
    print("No pair found.")
    return None

백준 - 3273 두 수의 합

n = int(input())
arr = list(map(int, input().split()))
x = int(input())

arr.sort()

# print(arr)

left = 0
right = n - 1
count = 0

while (left < right):
    # print("left", left, "right", right)
    currentSum = arr[left] + arr[right]
    # print("currentSum", currentSum)
    if (currentSum == x):
        count += 1
        left += 1
        right -= 1
    elif currentSum < x:
        left += 1
    else:
        right -= 1

print(count)

2) 평행 포인터(Parallel Pointers)

방향 : 같은 시점에서 같은 방향으로 이동
용도 : 슬라이딩 윈도우가 대표적 예시
- 포인터 중 하나는 탐색(Right)
- 다른 하나는 제약 조건 유지(Left)의 역할
  
  ⇒ 하위 배열이나 하위 문자열을 찾을 때 사용

3) 트리거 기반 포인터 (Trigger-based Pointers)

방향 : 한 포인터가 먼저 움직이고, 특정 조건이 충족되면 두 번째 포인터가 움직이기 시작
대표 예시 : 연결 리스트에서 ‘뒤에서 n번째 노드’ 찾기
- 첫 번째 포인터를 n만큼 먼저 보낸 후, 두 포인터를 이동시키면 첫 포인터가 끝에 도달했을 때 두 번째 포인터가 목표 지점에 있게 됨

3. 슬라이딩 윈도우

두 개의 포인터를 사용하여 데이터 구조 위에서 윈도우를 정의하고 이 윈도우를 옆으로 밀어가며 하위 배열이나 하위 문자열을 효율적으로 탐색하는 기법

1) Fixed Sliding Window

특징 : 윈도우의 크기 (K)가 미리 정해져 있으며 탐색 내내 일정하게 유지됨
작동 방식
1. 처음 K 개의 요소로 초기 윈도우 설정
2. 한 칸씩 이동하며 새로운 요소는 추가하고, 윈도우를 벗어나는 옛날 요소는 제거
3. 결과를 업데이트

백준 - 2559 수열

n, k = map(int, input().split())
arr = list(map(int, input().split()))

curret_val = sum(arr[:k])
max_val = curret_val

for i in range(k, n):
    curret_val += arr[i] - arr[i-k]
    max_val = max(max_val, curret_val)
print(max_val)

2) Dynamic Sliding Window

문제의 조건에 따라 윈도우의 크기가 늘어나거나 줄어듦
작동 방식
1. right 포인터를 이동하며 윈도우를 확장
2. 만약 조건을 위반할 경우,
  1. left 포인터를 이동시켜 조건이 만족될 때까지 윈도우를 축소시킴
3. 윈도우 내에서 최대/최소 길이등을 계산함

3주차 - 네트워크

Thu, 02 Apr 2026 00:00:00 GMT

참고자료

HTTP 1 Vs HTTP 2 Vs HTTP 3!

사용자가 HTTP 요청을 하게 되면 헤더와 바디를 주고 받는다.

헤더: 바디를 설명하는 정보를 포함한 정보 묶음
- 헤더는 콜론(:)으로 구분되는 key-value 형태로 설정됨
- HTTP 요청을 할 때 3가지 헤더인 일반헤더, 요청헤더, 응답헤더가 자동으로 생김
바디 : 주고받고자 하는 컨텐츠 본문 (json, html, image)

일반헤더 (General Header)

요청한 URL, 요청 메서드, 해당 자원을 요청할 때 해당 자원의 출처를 나타내는 URL을 노출시킬 지 말지를 정하는 보안정도가 설정되어 있는 Referrer Policy 등이 들어감.

Request URL : 요청한 대상의 주소
Request Method : 요청 방식 (GET, POST, PUT, DELETE 등)
Status Code : 서버의 처리 결과 상태
- Status Code
Referrer Policy : 보안을 위해 이전 페이지의 주소를 어디까지 노출할지 결정하는 정책

요청헤더 (Request Header)

Host : 요청이 전송되는 도메인 명
User-Agent : 요청을 보내는 클라이언트의 정보
Accept: 클라이언트가 처리할 수 있는 미디어 타입
- 예: text/html , application/json

응답헤더 (Response Header)

서버가 클라이언트에게 보낼 때, 서버 자체의 정보나 응답 데이터의 특성을 설명함

Content-Type : 바디에 담긴 컨텐츠의 종류
- 예: text/html ; charset=utf-8
- 이를 통해 브라우저는 데이터를 어떻게 렌더링할 지 결정함
Set-Cookie : 서버가 클라이언트에 쿠키를 저장하라고 명령할 때 사용
Cache-Control : 해당 응답을 얼마나 오랫동안 캐시(임시 저장)해도 되는 지 지시
Server: 응답을 처리한 서버 소프트웨어의 정보 (예: Apache , nginx)
Access-Control-Allow-Origin: CORS(Cross-Origin Resource Sharing)와 관련된 보안 정책으로, 어떤 도메인의 접근을 허용할지 명시.

HTTP/1.0과 1.1의 차이

HTTP/1.0: 단기 커넥션(Short-lived Connections)

HTTP/1.0은 기본적으로 한 번의 연결에 하나의 요청만 처리한다는 원칙을 가지고 설계되었다.

작동방식 (3-way handshake → 데이터 요청 / 응답 → 연결 종료)
1. TCP 연결 : 클라이언트와 서버가 3-Way Handshake를 통해 연결을 맺는다.
2. 요청/응답: 클라이언트가 HTML 파일을 요청하고, 서버가 응답한다.
3. 연결 종료: 응답이 끝나면 즉시 TCP 연결을 끊는다.
4. 반복: 만약 HTML 안에 이미지가 3개가 있다면, 해당 과정을 3번 더 반복함
문제점 : RTT의 증가
- **RTT(Round Trip Time)**란? 패킷이 왕복하는데 걸리는 시간을 의미함
- 지연시간(Latency) 발생 : 매번 연결을 새로 맺어야함, 따라서 실제 데이터를 주고 받는 시간보다 연결을 설정(Handshake)하는데 드는 시간이 더 길어지는 상황이 발생함
- 서버 부하 : 수 많은 클라이언트가 매번 연결을 맺고 끊으면 서버의 CPU와 메모리 자원들을 빠르게 소모하게 됨
정리
- HTTP/1.0은 수명이 짧은 연결이다.
- HTTP 요청은 자체 요청에서 완료된다
- 각 HTTP 요청당 TCP 핸드셰이크가 발생되며 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었다.
- 한 번 연결할 때마다 TCP 연결을 계속해야하므로 RTT가 늘어나는 문제점이 있다.

HTTP/1.1

HTTP/1.0의 RTT 증가 문제점을 해결하기 위해 HTTP/1.1이 나오게 됨

1. Keep-alive default

데이터를 요청할 때마다 TCP 연결을 하는게 아닌 한번 연결 하면, 계속 데이터를 주고 받을 수 있도록 함.

keep-alive 옵션을 기본 옵션으로 유지

2. 호스트 헤더

HTTP/1.0은 서버가 하나의 호스트만 가진다고 가정하기 때문에 HTTP/1.0은 헤더에 호스트를 포함하지 않음

때문에, HTTP/1.0은 IP 하나당 하나의 호스트만 가질 수 있었음
하지만, HTTP/1.1은 헤더에 특정 호스트를 포함할 수 있게 변경되었고 항상 호스트를 포함해서 요청하도록 변경됨

3. 대역폭 최소화 (Chunking) : 다운로드 이어받기 가능

HTTP/1.0은 어떠한 파일을 다운로드 받다가 연결이 끊기면 다시 다운로드 받는 것이 불가능 했음
- 예를 들어, HTTP/1.0에서는 10KB 파일을 다운로드 받는다고 했을 때, 5KB까지 다운 받고 이후의 데이터를 받는 것은 불가능했음.
  - 하지만, HTTP/1.1에서는 Ragne:bytes=5000- 라는 헤더를 추가하여 다운로드 재개 요청을 할 수 있도록 바뀜

4. 파이프라이닝(Pipelining)

응답을 기다리지 않고 여러 요청을 연속해서 보낼 수 있게 됨

예시)

Client가 Server단에 이미지를 2개를 요청할 때, 응답에 관계없이 GET요청을 보낼 수 있음

But. HTTP/1.1의 한계 : HOL(Head-of-Line) Blocking 문제

왜 발생하나?

HTTP/1.1은 이전 버전의 비효율을 해결하기 위해 파이프라이닝(Pipelining)을 도입하였음. 응답을 기다리지 않고 여러 요청을 연속해서 보내는 방식.

하지만,

응답은 반드시 요청받은 순서대로 보내야한다. 라는 제약사항이 존재함

서버는 클라이언트가 요청한 순서를 기억했다가 그 순서에 맞춰 응답을 돌려줘야하기 때문
어떻게 해결했나?
- Domaing Sharding (도메인 분할)
  - 브라우저는 한 도메인당 연결 수 (보통 6개)를 제한함
    - 이를 우회하기 위해 static1.example.com, static2.example.com 처럼 여러 서브도메인을 만들어 연결 개수를 강제로 늘림
- Image Sprite (이미지 스프라이트)
  - 수십개의 작은 아이콘을 하나의 커다란 이미지 파일로 합쳐서 요청 횟수 자체를 1번으로 줄임
- Code Bundling
  - 여러 개의 JS/CSS 파일을 하나로 합쳐서 전송 효율을 높임

HTTP/2와 HTTP/3의 차이

HTTP/2

HTTP/2의 도입 배경 & HTTP/1.1의 한계

HTTP/1.1의 성능 저하 문제(HOL)를 해결하기 위해, 구글의 SPDY 프로토콜을 바탕으로 탄생

HOL : 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능저하 현상을 의미

어떻게 해결했나?

바이너리 포맷 계층 (Binary Framing)
- 텍스트 대신 이진 형식(Binary)으로 프레임 단위로 데이터를 쪼개어 전달하여 처리 속도가 빨라짐
Multiplexing (다중화)
- 하나의 연결에서 여러 요청과 응답을 동시에 주고 받을 수 있어 HOLB 문제를 소프트웨어 수준에서 해결
- 단일 TCP연결의 여러 스트림에서 여러 HTTP 요청과 응답을 보낼 수 있다.
  - HTTP/1.1에서는 병렬 요청을 하려면 다중 TCP 연결을 통해 진행하고, TCP 연결 하나당 병렬 요청은 불가능했다.
  - HTTP/2.0에서는 리소스를 작은 프레임 단위로 나누고 이를 스트림으로 프레임을 전달한다.
    - 각각의 프레임은 (스트림 ID / 청크 크기를 나타내는 프레임이 추가)
Header Compression (HPACK)
- 중복되는 헤더 정보를 압축하여 전송 데이터량을 크게 줄임
Server Push
- 클라이언트가 요청하지 않아도 서버가 필요한 리소스를 미리 밀어넣어 줄 수 있음

HTTP/3

TCP의 태생적 한계를 극복하기 위해 구글이 개발한 QUIC 프로토콜을 사용

→ TCP를 여전히 사용하기 때문에 RTT로 인한 지연시간 문제는 여전히..(HTTP/2)

UDP 기반(QUIC) 연결 설정 과정을 대폭 단축하여 첫 패킷 전송까지의 시간을 줄임
HOLD 문제 해결
- TCP 패킷 하나만 유실되어도 전체가 멈추지만, HTTP/3는 유실된 패킷이 포함된 스트림만 영향을 받고 나머지는 정상 작동
연결 유지
- 와이파이에서 LTE로 네트워크 환경이 바뀌어도 IP주소가 아닌 ‘Connection ID’를 사용

HTTPS와 TLS #1. 암호화(대칭, 비대칭)

암호화란?

평문을 암호문으로 바꾸어 데이터의 기밀성과 무결성을 보장하는 기술

대칭 암호화 (Symmetric)
- 특징: 암호화와 복호화에 같은 키를 사용
- 장점 : 속도가 빠름
- 단점 : 탈취 위험
- 대표 알고리즘 : AES-128
비대칭 암호화 (Asymmetric)
- 특징 : 공개키와 개인키의 쌍을 사용
- 공식 : 공개키 암호화 → 개인키로만 복호화 가능
- 장점 : 키 전달 문제 해결
- 단점 : 계산 복잡도가 높은 편이라 속도가 느림
- 대표 알고리즘 : RSA, DH(Diffie–Hellman), ECDHE

AES (대칭 암호화)

AES(Advanced Encryption Standard)는 스크램블을 사용한 대칭키 암호화 알고리즘

→ 10 라운드에 걸쳐 각 라운드마다 스크램블 등의 연산으로 데이터 암호화

스크램블?
- 현재 상태의 키를 XOR 연산으로 더하는 단계
[참고] AES는 AES-128, AES-192, AES-256이 있고 그 중 AES-128가 가장 빠르고 가벼우며 많이 쓰이는 알고리즘이다. AES-128는 HTTPS, TLS 통신, 파일 암호화 (ZIP, RAR) 등에 사용됨

RSA, DH(Diffie–Hellman) ; 비대칭 암호화

ex)

A가 B에게 비밀 메시지를 보내려면 → B의 공개키로 암호화
이 메시지는 오직 B의 개인키로만 복호화할 수 있음 즉, A는 암호화만 하고, B만 읽을 수 있음

HTTPS와 TLS #2. TLS 핸드셰이크

TLS 핸드셰이크 과정

크게 두 가지 핵심 역할을 수행함

키 교환 (Key Exchange)
- 클라이언트와 서버가 만난 적 없지만, 똑같은 대칭키를 나누어 가져야할 때 사용
  - ECDHE(Elliptic Curve Diffie–Hellman Ephemeral)
전자 서명 (Digital Signature)
- 해당 서버가 진짜가 맞음 (인증서 위조되지 않음)을 증명할 때사용
  - ECDSA

1. ClientHello

클라이언트는 서버에게 먼저 ClientHello 메시지를 보낸다.

클라이언트가 지원하는 TLS 버전 목록
클라이언트가 지원하는 Cipher Suites 목록

클라이언트 랜덤값 (난수로 세션 키 생성에 사용됨)
클라이언트 측 ECDHE 공개키

2. ServerHello

서버는 클라이언트의 메시지를 분석한 후 다음과 같은 과정을 진행

클라이언트와 공통으로 지원하는 TLS 버전 중 가장 높은 버전 선택
클라이언트가 제안한 Cipher Suites 중 서버가 지원하는 Cipher Suites 선택
ServerHello 메시지를 보내면서 다음을 포함
- 선택된 TLS 버전
- 선택된 Cipher Suites
- 서버 랜덤값
- 서버측 ECDHE 공개키

3. 그 후 메시지들이 이어짐

Encrypted Extensions: SNI, ALPN
Certificate
CertificateVertify

4. Finished

클라이언트와 서버는 각각 Finished 메시지를 교환합니다. 이후의 통신은 세션키로 암호화되며, 이후 모든 통신은 AES 같은 대칭 암호화 방식으로 보호

ECDHE – 타원곡선 암호화

ECDHE에서 먼저 DH는 Diffie-Hellman을 의미

Diffie-Hellman 알고리즘은 서로 공개값 공유, 비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘

Diffie – Hellman 키 교환 방식

A = g^a \text{ mod } p

해당 식으로부터 $A, g, p$ 를 알아도 $a$ 를 계산하는 것 힘듦
- 예)
  
  $g=5, p=23, A= 8$ 이라고 할 때,
  
  $a$ 를 찾기 위해서는 brute force로 전부 연산해야함.

TLS에서 ECC를 사용하는 이유 (RSA와 비교)

비교 항목	RSA (과거 표준)	ECC (현대 표준)
보안 원리	큰 수의 소인수분해	타원곡선 이산로그 문제
키 사이즈	3072 bit (매우 큼)	256 bit (매우 작음)
보안 강도	보통	매우 높음
연산 속도	무거움 (배터리 소모↑)	가볍고 빠름 (모바일 최적화)

<현대퓨처넷 11기 채용연계형 부캠> 지원 & 합격 후기

Tue, 31 Mar 2026 00:00:00 GMT

서론

교육 후기나, 면접 후기가 많이 없는 것 같아서 조금이나마 도움이 될 수 있지 않을까 하고 적게 되는 후기.

졸업을 앞두고 취준에 대한 고민이 많았는데 사실 도메인을 정하지 않아서 어떤 회사로 가면 좋을지, 내가 회사를 골라가는게 맞는 지에 대한 걱정이 많았다.

또, 프로젝트를 하나의 기술 스택으로 정한게 아니라 내 입맛대로 골라서하다보니.. 특출나게 1군이라고 할만한 기술스택이 없었다.

서류작성

최종 면접 때 작성해둔 자기소개서를 바탕으로 이루어지기 떄문에 '특기' 문항까지도 고려해서 작성하는 것이 좋을 것 같다.

문항

[React] useRef와 상태 끌어올리기 (#09-2)

Tue, 31 Mar 2026 00:00:00 GMT

📍 연관 포스팅

React - 객체 상태를 활용한 조건부 렌더링 구현 (#09-1)

React - useRef와 상태 끌어올리기 (#09-2)

Github

🔗 09-project-management-app

서론

입력 폼에서 데이터를 가져올 때, 모든 키 입력마다 상태를 업데이트하는 대신 "저장" 버튼을 누르는 시점에만 값을 읽어오고 싶다면 Ref 사용하자

-> 왜냐면 상태 변화를 계속 팔로업할 필요가 없으니까..

사실 useState로도 구현 가능하지만 왜 useRef를 사용해야할까?

useState 와 useRef의 차이

비교 항목	useState (제어 컴포넌트)	useRef (비제어 컴포넌트)
리렌더링	값이 바뀔 때마다 발생 (매 키입력 시)	발생하지 않음
실시간 검사	가능 (글자 수 제한, 입력 즉시 경고 등)	불가능 (버튼을 누르는 시점에만 확인 가능)
UI 동기화	입력값에 따라 UI가 즉시 변함	저장 전까지 UI 변화 없음
추천 상황	복잡한 유효성 검사, 실시간 피드백 필요 시	단순한 데이터 수집, 성능 최적화 필요 시

1. useRef를 이용한 입력값 수집

useState를 쓰면 코드가 복잡해질 수 있는 상황에서 useRef를 사용하면 DOM 요소에 직접 접근하여 필요할 때만 값을 가져올 수 있다.

import { useRef } from 'react';

const title = useRef();
const description = useRef();
const dueDate = useRef();

function handleSave() {
  const enteredTitle = title.current.value;
  const enteredDescription = description.current.value;
  const enteredDueDate = dueDate.current.value;
  
  // 수집된 데이터를 상위 컴포넌트로 전달
  onAdd({
    title: enteredTitle,
    description: enteredDescription,
    dueDate: enteredDueDate
  });
}

2. 커스텀 컴포넌트에 Ref 전달하기 (`forwardRef`)

내장 HTML 태그(input, textarea)가 아닌 커스텀 컴포넌트에 ref 속성을 넘기려면 React의 forwardRef를 사용해야 한다.

import { forwardRef } from 'react';

const Input = forwardRef(function Input({ label, textarea, ...props }, ref) {
  return (
    <p>
      <label>{label}</label>
      {textarea ? (
        <textarea ref={ref} {...props} />
      ) : (
        <input ref={ref} {...props} />
      )}
    </p>
  );
});

forwardRef로 감싼 컴포넌트는 두 번째 인자로 ref를 전달받으며, 이를 내부의 실제 DOM 요소에 연결할 수 있다.

3. 상태 끌어올리기: App에서 데이터 관리

생성된 프로젝트 데이터는 사이드바와 상세 화면 모두에서 필요하므로, 가장 공통 분모인 App 컴포넌트에서 상태를 관리한다.

// App.jsx
function handleAddProject(projectData) {
  setProjectsState(prevState => {
    const newProject = {
      ...projectData,
      id: Math.random() // 간단한 ID 생성
    };

    return {
      ...prevState,
      projects: [...prevState.projects, newProject] // 기존 배열 복사 후 새 프로젝트 추가
    };
  });
}

// ...렌더링 부분
<NewProject onAdd={handleAddProject} />

4. 입력 타입 최적화 (Date Picker)

사용자로부터 정확한 날짜 형식을 받기 위해 input의 type 속성을 활용한다.

<Input type="text" ref={title} label="Title" />
<Input textarea ref={description} label="Description" />
<Input type="date" ref={dueDate} label="Due Date" />

type="date"를 설정하면 브라우저 내장 데이트 피커(Date Picker)가 활성화되어 편리하게 날짜를 선택할 수 있다.

💡 요약 및 핵심 포인트

Ref vs State: 실시간 유효성 검사가 필요 없다면 useRef가 렌더링 최적화와 코드 간결성 면에서 유리하다.
forwardRef: 커스텀 컴포넌트를 설계할 때 외부에서 제어할 수 있도록 forwardRef를 적용하는 습관을 들이자.
불변성 유지: 상태 배열을 업데이트할 때는 [...prevState.projects, newProject]와 같이 기존 데이터를 복사하여 불변성을 지켜야 한다.

5. 데모

다음 단계: 데이터 저장 로직은 완성되었다. 다음에는 입력값이 비어있을 때 경고를 띄우는 **유효성 검사(Validation)**와 모달(Modal) 창 구현 방법을 알아보자.

[React] 객체 상태를 활용한 조건부 렌더링 구현 (#09-1)

Mon, 30 Mar 2026 00:00:00 GMT

📍 연관 포스팅

React - 객체 상태를 활용한 조건부 렌더링 구현 (#09-1)

React - useRef와 상태 끌어올리기 (#09-2)

Github

🔗 09-project-management-app

새로운 프로젝트를 생성하거나 목록을 보여주는 등의 복잡한 UI 전환을 효과적으로 관리하기 위해서는 상태(State) 설계가 매우 중요하다. 이번 포스팅에서는 useState를 사용해 여러 상태를 하나의 객체로 관리하고, 이를 바탕으로 화면을 조건부로 렌더링하는 방법을 정리한다.

1. useState의 핵심 개념

useState란 무엇인가?

useState는 함수형 컴포넌트에서 **상태(State)**를 관리할 수 있게 해주는 React Hook이다. 상태가 변하면 React는 해당 컴포넌트를 **리렌더링(Re-rendering)**하여 변경된 UI를 화면에 즉시 반영한다.

const [state, setState] = useState(initialValue);

state: 현재 상태 값.
setState: 상태를 업데이트하는 함수.
initialValue: 상태의 초기값.

🧐 왜 상태를 '객체'로 관리할까?

단순히 boolean 값을 여러 개 만드는 대신, 하나의 상위 컴포넌트(App)에서 객체 형태의 상태를 관리하면 데이터의 흐름을 파악하기 훨씬 수월하다.

연관 데이터의 그룹화: 프로젝트 목록(projects)과 현재 선택된 프로젝트(selectedProjectId)는 논리적으로 연결된 데이터이다. 이를 하나로 묶으면 상태 관리의 흐름이 명확해진다.
상태 업데이트의 효율성: 여러 개의 useState를 개별적으로 쓰는 대신, 하나의 객체만 업데이트하여 관련 데이터를 한 번에 제어할 수 있다.

2. 상태 설계: undefined vs null 전략

이번 구현에서는 selectedProjectId의 상태값에 따라 앱의 현재 "모드"를 결정한다.

const [projectsState, setProjectsState] = useState({
  selectedProjectId: undefined, 
  projects: [] 
});

undefined: 초기 상태. 아무 프로젝트도 선택되지 않았고, 추가 중도 아닌 대기 화면(Fallback) 상태를 의미한다.
null: 'Add Project' 버튼을 눌러 새로운 프로젝트를 생성하려는 입력 폼 상태를 의미한다.
ID (string/number): 특정 프로젝트를 클릭하여 상세 내용을 보고 있는 상태를 의미한다.

단순히 true/false만 사용했다면 세 가지 이상의 상태를 표현하기 어려웠겠지만, 이처럼 값의 타입을 다르게 가져감으로써 화면 제어를 깔끔하게 처리할 수 있다.

3. 상태 변경과 함수형 업데이트

상태를 업데이트할 때는 이전 상태(prevState)를 보존하는 것이 핵심이다.

'함수형 업데이트'가 필요한 이유

React에서 상태 업데이트는 비동기적으로 일어날 수 있다. 따라서 최신 상태를 안전하게 가져와 다음 상태를 계산하기 위해서는 prevState를 인자로 받는 콜백 함수를 사용하는 것이 가장 안전하다.

function handleStartAddProject() {
  setProjectsState(prevState => {
    return {
      ...prevState, // 기존의 projects 배열 등 이전 상태 복사
      selectedProjectId: null, // 새 프로젝트 작성 모드로 전환
    };
  });
}

4. 컴포넌트 간 통신과 조건부 렌더링

Props를 통한 함수 전달

상태를 변경하는 함수(handleStartAddProject)를 하위 컴포넌트로 전달하여 버튼 클릭 시 상위 컴포넌트의 상태가 바뀌도록 연결한다.

// App.jsx 내부
<ProjectSidebar onStartAddProject={handleStartAddProject} />
<NoProjectSelected onStartAddProject={handleStartAddProject} />

조건부 렌더링 로직

상태값에 따라 어떤 컴포넌트를 변수에 담을지 결정한다. if-else 문을 사용하여 가독성을 높인다.

let content;

if (projectsState.selectedProjectId === null) {
  content = <NewProject />;
} else if (projectsState.selectedProjectId === undefined) {
  content = <NoProjectSelected onStartAddProject={handleStartAddProject} />;
}

return (
  <main className="h-screen my-8 flex gap-8">
    <ProjectSidebar onStartAddProject={handleStartAddProject} />
    {content}
  </main>
);

5. 핵심 요약

상태의 의미 분화: undefined와 null을 구분하여 앱의 다중 모드(대기, 생성, 상세)를 효과적으로 제어한다.
함수형 업데이트와 전개 연산자: 객체 상태를 변경할 때는 ...prevState를 통해 기존 데이터를 유지해야 한다.
컴포넌트 구조화: 부모의 상태 변경 함수를 자식에게 전달함으로써 UI의 일관성을 유지한다.

6. 코드

App.jsx

import { useState } from "react";
import NewProject from "./component/NewProject";
import ProjectSidebar from "./component/ProjectSidebar";
import NoProjectSelected from "./component/NoProjectSelected.jsx";
function App() {
  const [projectsState, setProjectsState] = useState({
    selectedProjectId: undefined, // neither adding a new project nor have a project selected
    project: [],
  });

  function handleStartAddProject() {
    setProjectsState((prevState) => {
      return {
        ...prevState,
        selectedProjectId: null,
      };
    });
  }

  let content;

  if (projectsState.selectedProjectId === null) {
    content = <NewProject />;
  } else if (projectsState.selectedProjectId === undefined) {
    content = <NoProjectSelected onStartAddProject={handleStartAddProject} />;
  }

  return (
    <main className="flex flex-row h-screen gap-8 my-8">
      {/* <h1 className="my-8 text-5xl font-bold text-center">Hello World</h1>
       */}
      <ProjectSidebar onStartAddProject={handleStartAddProject} />
      {/* <NoProjectSelected onStartAddProject={handleStartAddProject} /> */}
      {content}
    </main>
  );
}

export default App;

데모

Project가 Selected 되지 않은 상태면
- NoProjectSelected 화면
'Create new project' 버튼을 클릭
- selectedProjectId가 null : 새프로젝트 추가
- selectedProjectId가 {어떤 값} : {어떤 값} 프로젝트 상세 보기

Javascript Core Concept

Sun, 29 Mar 2026 00:00:00 GMT

JavaScript 핵심 개념 및 실행 환경 정리

1. JavaScript의 다양한 실행 환경

JavaScript는 더 이상 브라우저에만 국한되지 않는 강력하고 유연한 언어입니다.

브라우저 (Browser): JS가 처음 만들어진 고전적인 환경 (90년대 시작).
서버 사이드 (Node.js / Deno): 브라우저 외부에서도 JS 코드를 실행할 수 있게 해주는 런타임 환경.
모바일 앱 (Mobile): React Native나 Capacitor 같은 기술을 사용하여 iOS 및 Android 앱 제작 가능.

2. HTML에 JavaScript를 추가하는 방법

HTML 문서 내에서 <script> 태그를 사용하는 방식은 크게 두 가지로 나뉩니다.

1) 인라인 방식 (Inline Approach)

특징: <script> 태그 사이에 직접 코드를 작성.
단점: 코드가 길어지면 HTML 파일이 복잡해지고 유지보수가 어려움. 주로 아주 짧은 스크립트에만 사용.

2) 외부 파일 임포트 방식 (External Files) - 권장

특징: 별도의 .js 파일을 만들고 HTML에서 불러오는 방식.
장점: 프로젝트 유지보수가 쉽고 코드가 깔끔해짐.
방법: ```html

3. `<script>` 태그의 주요 속성 (Attributes)

브라우저가 스크립트를 처리하는 방식을 제어하기 위해 중요한 속성들이 있습니다.

속성	설명
`src`	불러올 JavaScript 파일의 경로를 지정합니다.
`defer`	HTML 파싱이 모두 끝난 후 스크립트를 실행하도록 합니다. HTML 요소가 로드되기 전에 스크립트가 실행되어 에러가 발생하는 것을 방지합니다.
`type="module"`	파일을 자바스크립트 모듈로 취급합니다. 이 설정을 통해 `import`와 `export` 구문을 사용할 수 있게 됩니다. (현대적인 프로젝트에서 필수)

4. React와 빌드 프로세스 (Build Process)

실제 React 프로젝트를 진행할 때는 우리가 직접 HTML에 <script> 태그를 일일이 추가하는 일이 거의 없습니다.

이유: React 프로젝트는 보통 빌드 프로세스를 거치기 때문입니다.
자동화: 빌드 도구가 우리가 작성한 여러 JS 파일들을 최적화하고, 최종 HTML 파일에 필요한 <script> 태그를 **자동으로 주입(Inject)**해 줍니다.

💡 요약 및 다음 단계

JS는 브라우저뿐만 아니라 서버, 모바일에서도 쓰이는 범용 언어다.
HTML에 스크립트를 넣을 때는 유지보수를 위해 외부 파일 형식을 사용한다.
type="module"을 사용하면 파일 간에 코드를 주고받는 import/export가 가능해진다.

강의 내용을 바탕으로 JavaScript의 import와 export 핵심 개념을 블로그에 올리기 좋게 Markdown 형식으로 정리해 드립니다.

5. Import & Export 정리

React와 같은 현대적인 자바스크립트 프로젝트에서는 코드를 유지보수하기 쉽게 여러 파일로 나누어 관리합니다. 이때 파일 간에 변수나 함수를 공유하기 위해 사용하는 핵심 키워드가 바로 export와 import입니다.

1. Named Export (이름을 내보내기)

가장 기본적인 방식입니다. 한 파일에서 여러 개의 변수나 함수를 내보낼 때 유용합니다.

내보낼 때 (util.js): 변수나 함수 앞에 export 키워드를 붙입니다.
```
export let apiKey = "abc123cryptic";
export let abc = "someValue";
```
가져올 때 (app.js): 중괄호 { } 안에 내보낸 이름을 그대로 적습니다.
```
import { apiKey, abc } from './util.js';
```

💡 참고: React 빌드 시스템을 사용하면 확장자(.js)를 생략할 수 있지만, 순수 자바스크립트 환경(Vanilla JS)에서는 파일 경로 뒤에 .js를 반드시 붙여야 한다.

2. Default Export (기본 내보내기)

한 파일당 단 하나만 존재할 수 있는 특별한 내보내기 방식입니다. 주로 파일의 메인 기능을 내보낼 때 사용합니다.

내보낼 때 (util.js): default 키워드를 사용하며, 이름 없이 값만 전달할 수 있습니다.
```
export default "abc123cryptic";
```
가져올 때 (app.js): 중괄호 { } 없이 원하는 이름으로 자유롭게 정의하여 가져옵니다.
```
import apiKey from './util.js'; // 이름을 myKey 등으로 바꿔도 무방함
```

3. 유용한 활용 팁

Alias 사용하기 (이름 변경)

가져오는 파일 내에서 변수명이 중복되거나 마음에 들지 않을 때 as 키워드로 이름을 바꿀 수 있습니다.

import { abc as content } from './util.js';
console.log(content); // util.js의 abc 값을 출력

모든 요소를 객체로 묶어서 가져오기

파일 안의 모든 export 항목을 하나의 객체로 그룹화하여 가져올 수 있습니다.

import * as util from './util.js';

console.log(util.apiKey);
console.log(util.default); // default export는 .default로 접근

4. 주의사항 (Type Module)

브라우저에서 직접 이 문법을 사용할 때는 <script> 태그에 type="module" 속성을 추가해야 합니다.

<script src="app.js" type="module"></script>

React 프로젝트에서는 빌드 도구(Webpack, Vite 등)가 파일을 하나로 합쳐주기 때문에 이 속성을 직접 관리할 필요가 없습니다.

정리하자면:

여러 개를 내보낼 땐 Named Export { }
하나의 메인을 내보낼 땐 Default Export
가져올 때 이름 변경은 as
모두 한 번에 가져올 땐 * as

2주차 - 네트워크

Sat, 28 Mar 2026 00:00:00 GMT

38. 네트워크 기초 #1

네트워크란?

노드와 링크가 서로 연결되어 있으며 리소스를 공유하는 집합을 의미함.

노드 : 서버, 라우터, 스위치 등 네트워크 장치
링크 : 유선 또는 무선과 같은 연결매체 (와이파이나 LAN)

트래픽

특정 시점에 링크 내에 흐르는 데이터의 양

트래픽이 많아졌다 → 흐르는 데이터가 많아졌다.
처리량이 많아졌다. → 처리되는 트래픽이 많아졌다.

대역폭(bandwidth)

주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수 (최대 트래픽)
- 대역폭이 높을 수록
  - 사용자에게 빠른 서비스를 서빙할 수 있음.
대략적인 최대 동시 접속자 수 유추의 척도가 됨.

Q. 100Mbps 라는 대역폭을 가진 서버가 존재하고, 한 사용자당 100kbps로 동영상 파일을 요청한다고 가정할 때, 최대 동시 접속자 수는?

\frac{100 \text{ Mbps}}{100 \text{ kbps}} = {\text{약 1000명}}

RTT(Round Trip Time)

왕복지연시간은 신호를 전송하고 해당 신호를 수신확인에 걸린 시간을 더한 값이자 어떤 메시지가 두 장치 사이를 왕복하는 데 걸린 시간

39-40. 네트워크 기초 #2~3. 네트워크 토폴로지

네트워크 토폴로지

토폴로지란? 노드와 링크가 어떠한 구조로 연결되어 있는 지를 도식화한 것.

버스 토폴로지

회선 하나에 여러 개의 노드가 연결된 구조

하나의 중앙 통신 회선을 백본 또는 버스라고 부름

장점
- 설치 비용 적음
- 유지보수 쉬움
- 한 노드에 장애 발생해도 전체 네트워크에 영향 안줌
단점
- 회선에 많은 트래픽이 생기면 정체 현상 발생 가능 (패킷 손실율 높음)
- 회선이 망가지먼 전체 네트워크에 영향을 줌
- 패킷 도청(스니핑)이나 위조(스푸핑) 등의 보안 위협에 취약

스타 토폴로지

하나의 중앙 노드(허브나 스위치)를 중심으로 여러 개의 말단 노드가 별 모양 처럼 각각 독립적인 구조로 연결 된 구조

모든 통신은 항상 중앙 노드를 통해서만 이루어짐

노드의 추가 및 삭제가 간단

장점
- 모든 통신이 중앙 노드를 통과하므로 방화벽, 침입 탐지 시스템(IDS)등 보안 장비를 중앙에 집중 적용 가능
단점
- 중앙 노드 에러 시에 큰 문제 발생

트리 토폴로지

계층 구조를 가진 토폴로지 → 트리형태

장점
- 리프 노드로의 확장 용이
- 리프노드의 에러는 나머지 부분의 영향을 미치지 않음
단점
- 특정 노드 트래픽 집중시 그 하위 모든 노드이 병목 현상 발생 가능
- 로프 노드에 문제 생기면 전체 네트워크 문제 발생

링 토폴로지

장점
- 노드 고장 위치 쉽게 파악 가능
- 각 노드가 앞 뒤 두 노드랑만 연결되므로 이론상으로 추가 및 삭제가 용이하지만
  - 실제 물리적 네트워크에서는 일시적 중단 발생할 수 있으므로 이중 링 설계 필요
단점
- 데이터 전송시 다른 노드들을 거쳐야하므로 전송지연(latency)가 발생 가능

메시 토폴로지

Full Mesh : 모든 노드가 서로 1:1로 연결된 구조
Partial Mesh: 일부 노드만 연결된 구조
장점
- 안정성이 높음
  
  → 한 노드에 장애가 나도 다른 노드에 영향을 주지 않음
- 트래픽 분산 가능
단점
- 기본적으로 연결되는 회선(링크)가 많기 때문에 초기 구축 비용, 설계 비용, 관리 비용이 많아짐

41. 네트워크 기초 #4. 병목 현상과 네트워크 토폴로지의 필요성

병목현상

병목(bottleneck)현상은 네트워크에서 트래픽이 특정 구간에 집중되어 데이터 흐름 속도가 제한되는 상황을 말한다. → 핫스팟이라고도 함.

병목현상 원인

대역폭 부족 : 라우터, 스위치, 특정 링크가 감당할 수 있는 트래픽보다 많은 데이터가 몰릴 때
- 예) 본사와 지사 간 연결 선이 100Mbps로 제한되어 있는데, 동시에 여러 지사에서 대용량 파일을 전송하면 포화상태 발생
서버/애플리케이션 처리 능력 한계 : 서버 CPU, 메모리, 스레드 풀 부족으로 패킷 처리가 지연
네트워크 토폴로지 문제(구조 문제): 여러 클라이언트가 하나의 경로를 공유할 때 특정 구간에서 발생

토폴로지의 필요성

토폴로지를 파악함으로써 병목현상을 해결하는 척도

💬 어떻게 해결?

위 그림처럼 중간에 로드 밸런서 부분에서 병목현상이 일어난다는 것을 파악, 서버, DB로 부터 회선을 더 추가하여 병목현상 해결 가능

42. 네트워크 기초 #5. 유니캐스트 / 멀티캐스트 / 브로드 캐스트

유니캐스트

1:1 통신을 말함. (가장 일반적인 통신)

예 ) HTTP

멀티캐스트

1:N 통신,

다만 연결된 모든 노드들에게 데이터를 전달하지는 않고 특정 그룹에게만 데이터를 전달함

브로드캐스트

1:N 통신,

그룹이 아닌 연결되어있는 모든 노드에게 데이터를 전달함.
- 예) ARP

43. 네트워크 분류 : LAN, MAN, WAN

네트워크는 LAN, MAN, WAN 순으로 분류됩니다. LAN이 가장 작은 단위, WAN이 가장 큰 단위이며 보통은 반경, 속도의 크기를 기반으로 분류

LAN

LAN(local area network, 근거리 통신망)은 MAN, WAN보다 높은 안정성, 속도를 가짐.

보통 허브나 스위치로 연결된 네트워크

MAN

MAN(metropolitan area network, 대도시 통신망)은 도시와 도시의 통신망을 뜻하며 2개 이상의 LAN이 연결되어 구성됨

라우터, 브리지 등으로 연결됨

WAN

WAN(wide area network)은 국가와 국가와의 통신망을 뜻함.

→ 인터넷이라고도 함.

→ 수많은 라우터를 거쳐 다른 국가와도 연결되는 범위를 말함.

44. TCP/IP 4계층 #1 개요

TCP / IP 4계층은 장치들이 인터넷 상에서 데이터를 주고받을 때 쓰는 프로토콜의 집합입니다. 4계층 혹은 7계층으로 나누어집니다.

애플리케이션 계층(Application)

애플리케이션 계층은 OSI 7계층 또는 TCP/IP 4계층 모델에서 가장 최상단에 위치한 계층이다.

사용자가 웹사이트를 열거나 이메일을 보내는 등의 작업을 수행할 때, 그 데이터를 어떻게 보내야 하는지 결정하는 프로토콜들이 모여있는 계층
HTTP, HTTPS, SMTP, SSH, FTP, SSH가 대표적

전송 계층(Transport)

TCP, UDP가 대표적이며 애플리케이션계층에서 받은 메시지를 기반으로 세그먼트(TCP) 또는 **데이터그램(UDP)**으로 데이터를 쪼개고 데이터가 오류없이 순서대로 전달되도록 도움을 주는 계층

인터넷 계층(network)

IP, ICMP, ARP가 대표적이며 한 노드에서 다른 노드로 전송 계층에서 받은 세그먼트 또는 데이터그램을 패킷화하여 목적지로 전송하는 역할

링크 계층(link) – Network Access 계층

링크 계층은 전선, 광섬유, 무선 등으로 데이터가 네트워크를 통해 물리적으로 전송되는 방식을 정의

데이터링크 + 물리 계층을 합친 계층

메시지 전송과정 예시

Checksum (체크섬)

체크섬은 데이터를 전송할 때 오류가 발생했는지 확인하기 위해 덧붙이는 추가 데이터 조각이며 “받은 데이터가 손상됐는지 판별하는 값

각 계층에 따라 사용되는 체크섬 알고리즘이 다름

사용 위치	체크섬 알고리즘
IPv4 헤더	1의 보수합
TCP/UDP 헤더	1의 보수합
Ethernet 프레임(FCS)	CRC-32

1의 보수합

모든 데이터를 16비트 단위로 더한 뒤, 그 합의 1의 보수를 취해 체크섬으로 사용한다는 것.

수신 측은 데이터 + 체크섬의 합이 0xFFFF가 되는지 검사하여, 데이터가 손상되었는 지를 판별

🧐 1의 보수란?

1의 보수는 이진수의 모든 비트를 반전 시킨 값

0 → 1로, 1 → 0으로 바꿈

01001011

10110100

🧐 순환캐리

1의 보수합을 계산할 때는 단순히 16비트 이상으로 넘치는 값을 잘라내는 것이 아닐, 넘친 비트(carry)를 다시 아래쪽으로 더해줌. 이것을 순환 캐리(end-around carry)라고 함.

16진수 0xFFFF는 10진수로는 65535이며 2진수로는 16비트가 모두 1인 1111 1111 1111 1111를 의미한다.

🧐 CRC(Cyclic Redundancy Check)

원본 데이터에 0을 다항식 차수만큼 덧붙이고 해당 비트를 왼쪽부터 차례대로 XOR 기반 이진 나눗셈을 수행한다.

45. TCP/IP 4계층 #2. MTU & MSS

MTU

MTU는 네트워크 계층에서 IP 패킷 전체 크기(헤더 + 데이터)의 최대값이고 보통 1500바이트임.

MSS(Maximum Segment Size)는 TCP에서 페이로드 최대 크기만을 가리킴.

데이터는 전송 전에 패킷 단위로 쪼개진다. 이때 MTU를 기준으로 크기가 결정된다.

따라서 네트워크 경로에 있는 어떤 장치의 MTU보다 패킷의 크기가 클 경우, 해당 패킷은 더 작은 단위로 분할되어 전송된다.

패킷이 분할 되지 않는 경우

패킷은 항상 분할되지는 않음.

→ IP 버전에 따라 MTU에 따라 분할되거나 분할되지 않을 수 있음

IPv6

패킷의 크기가 MTU보다 클 경우, 라우터가 해당 패킷을 폐기하고 Packet Too Big ICMPv6 메시지를 보냄

IPv4

IPv4 헤더에는 flags라는 필드가 있는데 여기서 bit이 1이되면 “Don’t Fragment” 플래그가 활성화된다는 의미

46. 애플리케이션 계층 (application)

HTTP, SMTP, SSH, FTP가 대표적이며 웹 서비스, 이메일 등 서비스를 실질적으로 사람에게 제공하는 층이다.

HTTP

HTTP(Hypertext Transfer Protocol)은 처음에는 서버와 브라우저 간에 데이터를 주고 받기 위해 설계된 프로토콜이다. 하지만 지금은 브라우저 뿐 아니라 서버간의 통신할 때도 사용한다.

HTTP는 헤더를 통한 확장이 쉽다.
HTTP는 Stateless

SSH

SSH(Secure Shell Protocol)은 보안되지 않은 네트워크에서 네트워크 서비스를 안전하기 위한 암호화 네트워크 프로토콜

ssh <pem> <user>@<serverIP>

보통 프라이빗 키가 있는 경로에서 이런 식으로 키를 명시하고 실행함.

FTP (File Transfer Protocol)

노드와 노드간의 파일을 전송하는데 사용하는 프로토콜

FileZilla (예시)
로컬 PC에서 원격 PC로 파일을 전송할 때 사용하는 프로토콜

SMTP

인터넷을 통해 메일을 보낼 때 사용되는 프로토콜(Simple Mail Transfer Protocol)

47. 전송계층 (Transport)

애플리케이션 계층에서 받은 메시지를 기반으로 세그먼트 혹은 데이터그램으로 데이터를 쪼개고 데이터가 오류없이 순서대로 전달되도록 도움을 주는 층

TCP / UDP 차이점

항목	TCP (전송 제어 프로토콜)	UDP (사용자 데이터그램 프로토콜)
패킷 교환방식	가상회선 방식	데이터그램 방식
신뢰성	O	X
오류검사	재전송, 체크섬	체크섬
순서 보장	O	X
헤더 길이	20~60 바이트 (가변)	8 바이트 (고정)
연결	연결 지향 (3-way / 4-way handshake)	비연결
브로드캐스트	X	O
속도	느림	빠름

48. 인터넷 계층(network)

인터넷 계층

IP, ICMP, ARP가 대표적이며 한 노드에서 다른 노드로 전송 계층에서 받은 세그먼트 또는 데이터 그램을 패킷화하여 전송

ICMP

ICMP는 노드와 노드 사이에서 통신이 잘되나를 확인할 때 쓰는 프로토콜

데이터를 교환하는 데 사용되지 않음
일반적으로 테스팅에 사용됨

49. TCP : 3-way handshake

SYN 단계: 클라이언트는 서버에 클라이언트의 ISN을 담아 SYN을 보낸다.
SYN + ACK 단계: 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인번호로 클라이언트의 ISN + 1을 보낸다.
ACK 단계: 클라이언트는 서버의 ISN + 1한 값인 승인번호를 담아 ACK를 서버에 보낸다.

🧐 ISN이란?

TCP(Transmission Control Protocol) 기반 데이터 통신에서 각각의 새 연결에 할당된 고유한 32비트 시퀀스 번호

SYN

Synchronization의 약자 - 연결 요청 플래그

ACK

acknowledgement의 약자 - 응답 플래그

50. TCP: 4-way handshake & TIME_WAIT

TIME_WAIT이 필요한 이유

지연 패킷을 받기 위함 → 데이터의 무결성을 지킴

51. 라우팅 #1 . 개념

라우팅(routing)이란?

네트워크에서 데이터를 전송할 때 최적의 경로를 선택하는 과정

라우터가 이를 수행함.
데이터는 보통 출발지에서 목적지로 가는 동안 여러 개의 라우터를 거치며 여러 번의 라우팅을 수행
- 보통 초당 수백만번 일어남.

라우터(router)

라우터는 네트워크 사이에서 데이터를 전달하는 장치

보통 둘 이상의 서로 다른 네트워크에 연결됨
데이터를 목적지로 보낼 때 최적의 경로를 결정하고, 경로가 결정되면 해당 경로로 데이터를 넘겨주는 일(라우팅)을 수행

라우팅 테이블

라우팅 테이블은 IP 주소를 기반으로 라우터의 위치를 저장한 테이블 또는 데이터베이스 이며 다양한 네트워크에 대한 정보와 해당 네트워크에 연결하는 방법이 포함되어 있음

52. 라우팅 #2. 라우팅테이블

라우팅 테이블

예) PC 1 → 101.25.67.7로 데이터를 보내려고 할 때

101.25.67.7은 101.25.67.0 과 같은 클래스 내의 네트워크임

라우팅 테이블의 구성요소

네트워크 대상 (Network Destination): 목적지 네트워크의 IP 주소
서브넷 마스크(Netmask): 대상 주소를 설명할 때 쓰이는 값.
게이트웨이(Gateway): 이 장치와 연결되어 있는 홉, 패킷이 전달되는 다음 IP 주소(외부 네트워크와 연결된 장치)
- 만약 목적지가 로컬 네트워크라면 연결됨(connected)라고 표기되며, 다른 네트워크라면 해당 네트워크의 게이트웨이를 가리킴
인터페이스(Interface): 게이트웨이로 가기 위해 거치는 장치
- 10.0.0.2는 eth3을 통해 접근 가능
메트릭(Metric): 우선순위라고도 불리며 패킷 전송을 위해 최적의 경로가 선택되도록 참고되는 값
- 일반적으로 홉 수(hop count), 처리량이 들어감

게이트웨이(Gateway)

게이트웨이는 프로토콜 변환기라고도 하며 네트워크와 네트워크를 잇는 장치이다. 라우터와 하는 기능 자체가 비슷

홉(hop)

WorkStation 1 → 2로 이동한다고 가정할 때,

hop count = 2 (→ 건너 뛴 Router의 개수)

Q) hopcount가 낮은게 좋을까?

YES (적을 수록 빠름)

홉(hop)은 네트워크에서 출발지와 목적지 사이에 위치한 장치를 의미함

홉 카운트(hop count)는 데이터가 출발지와 목적지 사이에서 통과해야 하는 홉의 개수를 의미

라우팅 테이블 실습

netstat -r

53. IP주소, MAC주소, ARP, RARP

IP 주소

논리적 주소이며 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호

논리적? (⇒ 변한다)

MAC 주소

MAC 주소(Media Access Control Address)는 네트워크 인터페이스에 할당된 고유 식별자이며 보통 장치의 NIC에 할당됩니다.

48비트로 이루어져있으며 24비트의 OUI와 24비트의 UAA로 이루어져있다.

OUI: IEEE에서 할당한 제조사 코드

UAA: 제조사에서 구별되는 코드

windows 명령어

ipconfig /all

mac 명령어

ifconfig
ifconfig en0 | grep ether

en : 네트워크 인터페이스 prefix

인터페이스	의미
`en0`	보통 Wi-Fi
`en1`	유선 Ethernet (또는 반대일 수도 있음)
`en2+`	추가 네트워크 (USB 랜, 가상 어댑터 등)

ARP와 RARP

MAC주소는 어떻게 찾아야할까?

→ ARP (프로토콜)을 통해 확인

ARP의 과정

IP주소에 맞는 MAC주소를 찾기 위해 해당 데이터를 ‘브로드캐스팅’을 통해 연결된 네트워크에 있는 장치한테 모두 보냄
맞는 장치가 있다면 해당 장치는 보낸 장치에게 유니캐스트로 데이터를 전달하여 주소를 찾게됨

54. IP주소 체계 #1: 이진수 이해하기

십진법 표현

123_{10} = 1 \times 10^2 + 2 \times 10^1 +3\times 10^0

이진법 표기

$0\rm{b}100101$
$100101_{2}$
$100101_{\rm b}$

55. IP주소체계 #2: IPv4와 IPv6

IP주소 체계는 IPv4와 IPv6로 나누어짐

IPv4

IPv4는 32비트로 표현되는 주소체계이며 $2^{128}$ 개의 주소(41억 9천만 주소)를 표현할 수 있다.

IPv6

IPv6는 128비트로 표현되는 주소체계이며 $2^{128}$ 개의 주소 $(3.4 * 10^{38})$ 를 표현

IPv4보다 더 넓은 주소 체계를 가짐
- IPv4에서 쓰였던 NAT, 서브네팅이 필요하지 않음
콜론(:)으로 구분함
- 연속되는 0(zero)는 : (콜론으로 치환가능)
보안
- IPv6에는 데이터통신을 암호화할 수 있는 IPSec이 내장

Q. IPv4와 IPv6 중 어떤게 더 나을까?

IPv6는 IPv4보다 많은 주소를 표현할 수 있다. 또 불필요한 헤더가 삭제되어서 빠르고 IPSec도 있어 보안적인 측면에서도 좋다. 보통은 IPv6를 사용하는 것이 IPv4보다 속도가 더 빠르지만 일부 사례는 그렇지 않을 수도 있다.

56. IP주소체계 #3 Classful IP Addressing

IP주소는 인터넷 주소로 네트워크 주소, 호스트주소 즉, 두 부분으로 나뉜다.

네트워크 주소 → 호스트들을 모은 네트워크 지칭
- 호스트(Host)란?
  
  컴퓨터 네트워크에 연결된 컴퓨터나 기타 장치

Classful IP Addressing 정의

네트워크 주소를 매기고 그에 따라 네트워크의 크기를 다르게 구분하여 클래스를 할당하는 주소체계

구분 기준 ⇒ 서브넷마스크(Netmask)

Class	First Octet (decimal range)	First Octet (binary range)	IP range	Subnet Mask	Hosts per Network ID	# of networks
Class A	0–127	0XXXXXXX	0.0.0.0–127.255.255.255	255.0.0.0	2^24 - 2	2^7
Class B	128–191	10XXXXXX	128.0.0.0–191.255.255.255	255.255.0.0	2^16 - 2	2^14
Class C	192–223	110XXXXX	192.0.0.0–223.255.255.255	255.255.255.0	2^8 - 2	2^21
Class D	224–239	1110XXXX	224.0.0.0–239.255.255.255	-	-	-
Class E	240–255	1111XXXX	240.0.0.0–255.255.255.255	-	-	-

Class A

한 네트워크당 16,777,214 호스트 ID(약 1600만개)
0.0.0.0은 특수 주소
127.x.x.x은 루프백 주소임
- 루프백 주소 : 자기 자신(로컬 호스트)을 가리키는 IP 주소
  - 예) 127.0.01

Class B

2^16 – 2 = 한 네트워크당 65534 호스트 ID(6만 5천개)
네트워크 주소 범위 : 128 ~ 191 로 시작

Class C

2^8 – 2 = 한 네트워크당 254 호스트 ID
네트워크 주소 범위 : 192 ~ 223 로 시작

🧐 ‘-2’를 왜하나?

맨 앞자리는 네트워크 주소(n.x.x.x)로 남겨두며 마지막 주소는 브로드캐스팅(x.x.x.255) 주소

🧐 클래스풀의 문제점

네트워크의 크기가 작은 경우 큰 네트워크를 필요로 하는 조직은 여러개를 확보해야 하는

어려움

57. IP주소체계 #4. 클래스리스와 서브넷마스크, 서브네팅

기존 Classful의 문제점

네트워크 크기가 작은 경우 큰 네트워크로 필요로하는 조직은 여러 개 확보 필요
- 또, 남는 네트워크가 생김

⇒ Classless 등장

서브넷마스크를 중심으로 어디까지가 네트워크 주소고 어디까지가 호스트주소인지를 나눔

서브네팅 : 네트워크를 나눈다는 의미
서브넷 : 서브네트워크, 쪼개진 네트워크
서브넷마스크 : 서브네트워크를 위한 비트마스크

58. IP주소 체계 #5 Public IP 와 Private IP

IP주소의 부족을 해결하기 위해 Public IP와 Private IP로 나누고 중간에 NAT라는 기술을 통해 해결한다.

NAT

NAT(Network Address Translation)은 패킷이 트래픽 라우팅 장치를 통해 전송되는 동안 패킷의 IP 주소를 변경, IP주소를 다른 IP주소로 매핑하는 방법
- NAT를 통해 내부 네트워크 IP가 노출되지 않는다는 점 (장점)

1주차 - CS 스터디

Tue, 24 Mar 2026 00:00:00 GMT

1. 디자인 패턴이란?

디자인 패턴은 소프트웨어 설계 과정에서 반복적으로 발생하는 문제를 해결하기 위해 정리된 설계 규약이다. 객체 간 관계와 역할을 구조화함으로써 코드의 재사용성과 유지보수성을 높일 수 있다.

디자인 패턴의 종류

디자인 패턴은 크게 생성패턴, 구조패턴, 행동패턴 3가지로 나누어짐

1) 생성 패턴

생성패턴은 객체 생성 방법이 들어간 디자인 패턴

싱글톤, 팩토리, 추상팩토리, 빌더, 프로토타입 패턴이 있음

2) 구조 패턴

객체, 클래스 등으로 큰 구조를 만들 때 유용한.

3) 행동 패턴

객체나 클래스 간의 알고리즘, 책임 할당에 관한 디자인 패턴

eterator, observer, strategy..

22. 라이브러리와 프레임워크의 차이

22.1 라이브러리

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것이며 폴더명, 파일명 등에 대한 규칙이 없고 프레임워크에 비해 자유롭다.

예) axios

22.2 프레임워크

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 말한다. 폴더명, 파일명 등에 대한 규칙이 있으며 라이브러리에 비해 좀 더 엄격한 특징을 지닌다.

예) vue.js , Django

23. 싱글톤 패턴

싱글톤 패턴(Singleton pattern)이란?

하나의 클래스의 오직 하나의 인스턴스만 가지는 패턴

하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만 그렇게 하지 않고, 하나의 클래스를 기반으로 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는데 쓰이며 보통 데이터베이스 연결 모듈에 많이 사용됨.

왜 사용하는 걸까요?

보통 클래스를 만들면 필요할 때마다 new 연산자로 인스턴스를 여러 개 만들 수 있다. 하지만, 자원관리, 상태 공유 등의 상황에서는 인스턴스가 여러 개면 오히려 문제가 발생할 수 있다.

자원관리
- 데이터베이스 연결 객체(Connection Pool)
- 로그 기록 객체 (Logger)등
상태 공유
- 설정 정보(Config) 처럼 프로그램 전체에서 동일한 데이터를 참조해야할 때 유용

싱글톤 패턴의 특징

private 생성자 : 클래스 외부에서 new 를 통해 인스턴스를 생성하지 못하도록 막는다.

장점

하나의 인스턴스를 기반으로 해당 인스턴스를 다른 모듈들이 공유하여 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어듦

단점

의존성이 높아짐
TDD(Test Driven Development)를 할 때 걸림돌이 됨.

멀티스레드 환경에서 동시성 문제 방지

synchronized나 double-checked locking등을 사용

코드 예시 (JS)

class Singleton {
    constructor() {
        if (!Singleton.instance) {
            Singleton.instance = this
        }
        return Singleton.instance
    }
    getInstance() {
        return this 
    }
}
const a = new Singleton()
const b = new Singleton() 
console.log(a === b) // true

24–25. 싱글톤 패턴을 구현하는 7가지 방법 #1,2

1. 단순한 메서드 호출

싱글톤 패턴 생성 여부 확인
- 싱글톤이 없으면 → 새로 생성
- 새로 만들고 있다면 → 인스턴스 반환

public class Singleton {
    private static Singleton instance;

    private Singleton() {
        
    }

    public static Singleton getInstance() {
        if (instance == null) {  
            instance = new Singleton();
        }
        return instance;
    }
}

해당 코드의 문제점

원자성 결여

2. synchronized

3. 정적 멤버(즉시 초기화, Eager Initialization)

4. 정적 블록

5. 정적 멤버와 Lazy Holder(중첩 클래스)

6. 이중 확인 잠금(DCL)

7. Enum

26. 팩토리 패턴

팩토리 패턴이란?

상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴

상위 클래스에서는 객체 생성방식에 대해 알 필요가 없어져 유연성을 갖게 되며 객체 생성 로직은 하위클래스에서만 관리 되기 때문에 유지보수성이 증가

27. 이터레이터(iterator) 패턴

이터레이터 패턴이란?

이터레이터(iterator)를 사용하여 컨테이너의 요소에 접근하는 디자인 패턴이다. 각기 다른 자료구조들을 똑같은 인터페이스로 순회를 쉽게할 수 있다는 장점이 있다.

*컨테이너란 동일한 요소들을 담아놓는 집합을 말한다. 배열과 맵이 있다.

28. DI와 DIP

의존성 주입(DI)과 의존 관계역전원칙(DIP)

의존성 주입(Dependency Injection)이란?

메인 모듈(main module)이 ‘직접’ 다른 하위 모듈에 대한 의존성을 주기보다 중간에 의존성 주입자(dependency injector)가 이 부분을 가로채 메인 모듈이 ‘간접’적으로 의존성을 주입하는 방식.

의존 관계역전원칙(DIP)이란?

DIP; Dependency Inversion Principle

자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙을 말합니다.

이는 2가지의 규칙을 지키는 상태를 의미함.

상위 모듈은 하위 모듈에 의존해서는 안됨
추상화는 세부사항에 의존해서는 안됨

의존성 주입의 장점

외부에서 모듈을 생성하여 모듈을 쉽게 교체할 수 있는 구조가 됨.
단위 테스팅과 마이그레이션이 쉬워짐
애플리케이션 의존성 방향이 좀 더 일관되어 코드를 추론하기 쉬워짐

의존성 주입의 단점

결국에는 모듈이 더 생기게 되므로 복잡도가 증가하게 됨
종속성 주입 자체가 컴파일을 할 때가 아닌 런타임 시에 일어나기 때문에 컴파일할 때 종속성 주입에 관한 에러를 잡기가 어려워짐

29. 전략 패턴

전략패턴이란?

전략(Strategy)라고 부르는 ‘캡슐화한 알고리즘’을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 디자인 패턴이다.

30. 옵저버 패턴

옵저버 패턴이란?

주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵서버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴이다.

31. Proxy 패턴

프록시패턴이란?

객체가 어떤 대상 객체에 접근하기 전, 그 접근에 대한 흐름을 가로채서 해당 접근을 필더링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인 패턴이다.

프록시 서버 예시

Cloud Flare

32. MVC / MVP / MVVM 패턴

1) MVC 패턴

MVC패턴은 Model, View, Controller로 이루어진 디자인 패턴

모델(Model)

모델은 애플리케이션의 데이터인 데이터베이스, 상수, 변수등을 의미

뷰에서 데이터를 생성하거나 수정할 때 컨트롤러를 통해 모델이 생성 또는 업데이트 됨.

뷰(View)

뷰(view)는 inputbox, checkbox, textarea등 사용자 인터페이스 요소를 나타내며 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻함.

컨트롤러(Controller)

컨트롤러(Controller)는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리역할을 하며 이벤트등 메인 로직을 담당함.

MVC 패턴의 장점

애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성요소에만 집중해서 개발할 수 있음
재사용성과 확장성이 용이하다는 장점

MVC 패턴의 단점

애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점 존재

폭포수 효과
- MVC패턴은 규모가 커질 수록 Model과 View가 서로를 복잡하게 참조하는 양방향 데이터 흐름을 갖게됨.
- 예시) 페이스북의 Markseen

2) MVP 패턴

3) MVVM 패턴

대표적인 프레임워크 뷰(Vue.js)

33. Flux 패턴

단방향을 가지기 때문에 일관성이 증가함.

일관성이 증가하기 때문에 테스팅이 쉬워짐

Flux의 4가지 핵심 요소

Action
- 무엇이 일어날지 정의하는 객체
- 사용자의 이벤트 처리
  - 마우스 클릭, 스크롤 등
Dispatcher
- 어떤 action을 관리하는 객체
- 모든 action을 받아서 Store에 저장하는 중앙 통제실
Store
- 애플리케이션의 상태와 이를 변경하는 로직을 담고 있음
- Dispatcher를 통해서만 상태 변경이 가능함.
View
- Store에서 데이터를 가져와 화면에 렌더링하고, 사용자 입력이 들어오면 새로운 Action을 생성함

Flux 패턴이 적용된 Redux

[알고리즘] 구간합 / 누적합

Mon, 09 Mar 2026 00:00:00 GMT

1. 1차원 구간합

1) 합 배열 정의

S[i] = A[0] + A[1] + ... + A[i-1] + A[i]

2) 합 배열 구하기

S[i] = S[i-1] + A[i]

3) 구간합 구하기

예: i ~ j 까지의 구간합?

S[j] - S[i-1]

백준 11659 – 구간합 구하기 4

수 N개가 주어졌을 때, i번째 수부터 j번째 수까지 합을 구하는 프로그램을 작성하시오.

import sys
input = sys.stdin.readline

n, m = map(int, input().split())
arr = list(map(int, input().split()))
arr.insert(0, 0)

# 구간합 배열
prefix_s = []
prefix_s.append(arr[0])

for i in range(1, n+1):
    sum = prefix_s[i-1] + arr[i]
    prefix_s.append(sum)

for _ in range(m):
    result = 0
    i, j = map(int, input().split())

    result = prefix_s[j] - prefix_s[i-1]

    print(result)

2. 2차원 구간합

백준 2167 – 2차원 배열의 합

n, m = map(int, input().split())

arr = [[0]*(m+1)]  # 0번째 행 추가

for _ in range(n):
    row = [0] + list(map(int, input().split()))
    arr.append(row)

# prefix_sum 초기화 
prefix_sum = [[0] * (m+1) for _ in range(n+1)]

# prefix_sum[1][1] 시작 추가
prefix_sum[1][1] = arr[1][1]

# prefix_sum 순회하면서 각각의 값 채워넣기 
for i in range(1, n+1):
    for j in range(1, m+1):
        if i == 1 and j > 1:
            prefix_sum[i][j] = prefix_sum[1][j-1] + arr[1][j]
        elif i > 1 and j == 1:
            prefix_sum[i][j] = prefix_sum[i-1][1] + arr[i][1]
        else:
            prefix_sum[i][j] = prefix_sum[i-1][j] + prefix_sum[i][j-1] - prefix_sum[i-1][j-1] + arr[i][j]

k = int(input())

for _ in range(k):
    i, j, x, y = map(int, input().split())

    result = prefix_sum[x][y] - prefix_sum[i-1][y] - prefix_sum[x][j-1] + prefix_sum[i-1][j-1]

    print(result)

[React] props와 state의 차이

Sun, 08 Mar 2026 00:00:00 GMT

props vs state

props와 state의 정확한 차이는 무엇인가요?

Context

컴포넌트의 주요 책임은 원시 데이터(raw data)를 풍부한 HTML로 변환하는 것이다. 해당 관점에서 보면 props와 state는 HTML출력이 생성되는 원시데이터를 구성한다.

즉, props와 state는 컴포넌트의 render()함수에 들어가는 입력 데이터다. 따라서 각 데이터가 무엇을 의미하는지 그리고 어디에서 오는지 자세히 살펴봐야 한다. 또한 우리는 React Cosmos를 사용하고 있는데, 해당 환경에서 props는 초기 state를 포함할 수 있기 때문에 해당 개념을 이해하는 것이 중요하다.

💬 공통점

props와 state는 모두 일반적인 JavaScript 객체
props와 state는 변경되면 컴포넌트는 다시 렌더링 됨.
props와 state는 결정적임.

🧐 예시를 고려해보자.

Q) 어떤 컴포넌트가 시간이 지나면서 자신의 속성을 변경해야 한다면? props? state? 어디에?

어떤 컴포넌트가 시간이 지나면서 자신의 속성을 변경해야한다면 state에 있어야함.

props

props는 properties의 줄임말이다.
- props는 컴포넌트의 설정이라고 볼 수 있다.
- 즉, 컴포넌트에 전달되는 옵션이다.

state

state는 컴포넌트가 마운트될 때 기본값으로 시작한다.
- 그리고 시간이 지나면서 값이 변경될 수 있음
- 해당 변화(변경)는 사용자 이벤트로 인해 발생함
- state는 특정 시점의 상태를 나타내는 스냅샷이라고 볼 수 있음
- 컴포넌트는 자신의 state를 내부적으로 관리

props와 state 변경 가능 여부

	props	state
부모 컴포넌트로부터 초기값 받을 수 있는가	Yes	Yes
부모 컴포넌트가 값을 변경할 수 있는가	Yes	No
컴포넌트 내부에서 기본값 설정 가능	Yes	Yes
컴포넌트 내부에서 변경 가능	No	Yes
자식 컴포넌트 초기값 설정 가능	Yes	Yes
자식 컴포넌트에서 변경 가능	Yes	No

그렇다면 State는 다다익선인가?

state는 선택사항이다.
- 결국 상태의 변화는 컴포넌트의 복잡도를 증가시키고 예측 가능성을 낮출 수 있기 때문에 가능하면 state가 없는 정적 컴포넌트가 낫긴 하다.
- 물론 인터랙티브한 애플리케이션에서는 state 없이 구현한다는 것은 말이 안된다.
- 하지만 stateful한 컴포넌트를 너무 많이 만드는 것은 피하는 것이 좋다.

레퍼런스

SOP, CORS, CSRF란 무엇인가?

Sat, 07 Mar 2026 00:00:00 GMT

CORS란?

Cross-Origin Resource Sharing의 약자, 교차 출처 리소스 공유는 웹 브라우저가 보안상 다른 도메인으로의 API 요청을 제한하는 정책(SOP)을 예외적으로 허용해주는 HTTP 기반 메커니즘 입니다.

🧐 정확히 풀어서 설명하자면..

브라우저는 보안을 위해 현재 페이지의 출처(origin)와 다른 출처의 리소스에 접근하지 못하도록 제한하는 정책을 가지고 있다. 이를 동일 출처 정책(Same-Origin Policy, SOP)이라고 함.

하지만, 현대 웹사이트는 내 서버 뿐만 아니라 네이버 지도 API, 구글 폰트, 공공데이터 등의 남의 서버에서 데이터를 가져와야할 일이 많음.

외부 API아니더라도 당장 개인 프젝을 할 때에도 프론트엔드단과 서버단의 출처가 다른 경우가 존재함

그렇다면, 이 사이트는 안전하니까 데이터를 주고 받을 수 있게 해줄게 라고 서버가 허락해주는 규칙이 CORS (교차 출처 리소스 공유)인 것이다.

😩 왜 이렇게 복잡하게 해놨을까?

만약 이런 제한이 없었다면,,
- 브라우저에 쿠키가 남아있을 때, CSRF 혹은 세션 하이재킹에 대한 위험이 존재함.

Origin(출처)은 무엇인가?

브라우저가 **'서로 다른 출처'**라고 판단하는 기준은 세 가지이다.

Protocol (http vs https)
Host (example.come vs api.exmaple.com)
Port (80 vs 8080)

발생원인

웹사이트 (예: A 도메인)에서 다른 API 서버 (B 도메인)로 리소스를 요청할 때 브라우저가 보안상 기본적으로 차단하여 발생

작동 방식

브라우저는 서버에 Preflight를 보내 허용된 출처인지 확인하고, 서버가 헤더를 통해 허용하면 데이터 교환이 가능함.

해결 방법

서버 측에서 응답 헤더(Access-Control-Allow-Origin)를 설정하거나, 프록시 서버를 사용하여 도메인을 맞추는 방식을 사용

주의

CORS는 브라우저 보안 정책일 뿐, 서버 기능이 아니다.
- 따라서, Postman에서는 잘 되는데, 브라우저에서 막히는 이유 또한 위와 같다.

레퍼런스

맥북에 Claude Code 설치

Sat, 07 Mar 2026 00:00:00 GMT

curl -fsSL https://claude.ai/install.sh | bash

HTTP?

Fri, 06 Mar 2026 00:00:00 GMT

HTTP?

하이퍼텍스트 전송 프로토콜(HTTP)은 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜이다. 웹 브라우저와 웹 서버간의 통신을 위해 설계되었지만 다른 목적으로도 사용할 수 있다. HTTP는 무상태 프로토콜이고, 서버가 두 요청 간에 어떠한 데이터도 유지하지 않는다.

HTTP를 왜 알아야할까?

현재 개발에서 API를 받아올 때 대부분 HTTP로 받아오기 때문. 물론 시스템 개발자도 일정 부분 당연히 알아둬야하겠지만..서도

🧐 HTTP로 제어 가능한 것?

레퍼런스

HTTP 개요

법정동 기준 상권 데이터 수집 구현기 (Kakao Local API)

Tue, 03 Feb 2026 00:00:00 GMT

법정동 기준 상권 데이터 수집 구현기 (Kakao Local API)

Tue, 03 Feb 2026 00:00:00 GMT

일단, 수집하고자하는 데이터는 다음과 같다.

법정동 코드 (한 구역에) CATEGORIES에 포함된 편의시설의 개수이다.

CATEGORIES = {
    "CS2": "편의점",
    "MT1": "대형마트",
    "PK6": "주차장",
    "BK9": "은행",
    "FD6": "음식점",
    "CE7": "카페",
    "HP8": "병원",
    "PM9": "약국",
}

Table Header & 예시

법정동코드	category_group_code	count
1111010100	CS2	2
1111010100	MT1	0

1. Kakao api key 발급

Kakao map api를 활용할 예정이기 때문에, 앱을 등록하고 kakao api key를 발급하도록 한다.

이미지 중 C. 호출 허용 IP 주소에 내 Public ip 주소를 입력해야 한다.
가장 간단한 방법은,
- 네이버 > “내 아이피 주소 확인”

- Private ip를 입력하지 않도록 주의하자.

1.1 NotAuthorizedError 에러

초반에 앱에 플랫폼 REST API 키로 사용하다가 다음과 같은 인증 에러를 마주했다.

{'errorType': 'NotAuthorizedError', 'message': 'App(QuadS) disabled OPEN_MAP_AND_LOCAL service.'}
수집된 장소 수: 0

1.1 에러 해결

앱 > 제품 설정 > 카카오맵 에서 사용 설정을 ON 해주면 해결 된다.

2. 구성

전체 구성은 다음과 같다.

설정 및 공통 상수 정의
좌표 기반 행정구역정보 변환 함수
좌표 to 법정동 코드 함수
카테고리기반 장소 수집 함수
동 주소 기반 좌표 변환 함수
실행

1. 설정 및 공통 상수 정의

import pandas as pd
import requests
import time
import os
from dotenv import load_dotenv

load_dotenv()

KAKAO_REST_API_KEY = os.getenv("KAKAO_REST_API_KEY")

HEADERS = {
    "Authorization": f"KakaoAK {KAKAO_REST_API_KEY}"
}

ADDRESS_URL = "https://dapi.kakao.com/v2/local/search/address.json"
CATEGORY_URL = "https://dapi.kakao.com/v2/local/search/category.json"
COORD2REGION_URL = "https://dapi.kakao.com/v2/local/geo/coord2regioncode.json"

CATEGORIES = {
    "CS2": "편의점",
    "MT1": "대형마트",
    "PK6": "주차장",
    "BK9": "은행",
    "FD6": "음식점",
    "CE7": "카페",
    "HP8": "병원",
    "PM9": "약국",
}

OUTPUT_PATH = "../output/seoul_legal_dong_category_count.csv"
RADIUS = 800

print(KAKAO_REST_API_KEY)

2. 좌표 기반 행정구역정보 변환 함수

Kakao developers | 문서 > 로컬 > REST API > 좌표로 행정구역정보 변환

좌표계에 대한 좌표값을 받아 해당 좌표에 부합하는 행정동, 법정동을 얻는 API

행정동 (region_type == "H")

법정동 (region_type == "B")

def coord_to_bcode(x, y, sleep=0.05):
    res = requests.get(
        COORD2REGION_URL,
        headers=HEADERS,
        params={"x": x, "y": y, "input_coord": "WGS84"}
    )

    if res.status_code != 200:
        return None

    for doc in res.json().get("documents", []):
        if doc.get("region_type") == "B":
            time.sleep(sleep)
            return doc.get("code")

    time.sleep(sleep)
    return None

3. 좌표 to 법정동 코드 함수

def coord_to_bcode(x, y, sleep=0.05):
    res = requests.get(
        COORD2REGION_URL,
        headers=HEADERS,
        params={"x": x, "y": y, "input_coord": "WGS84"}
    )

    if res.status_code != 200:
        return None

    for doc in res.json().get("documents", []):
        if doc.get("region_type") == "B":
            time.sleep(sleep)
            return doc.get("code")

    time.sleep(sleep)
    return None

4. 카테고리 별 장소 수집

def fetch_places(category, x, y, radius):
    page = 1
    rows = []

    while True:
        res = requests.get(
            CATEGORY_URL,
            headers=HEADERS,
            params={
                "category_group_code": category,
                "x": x,
                "y": y,
                "radius": radius,
                "page": page,
                "size": 15
            }
        ).json()

        rows.extend(res.get("documents", []))

        if res["meta"]["is_end"]:
            break

        page += 1
        time.sleep(0.05)

    return rows

5. 동 주소 -> 좌표 변환

def dong_to_coord(address, sleep=0.1):
    res = requests.get(
        ADDRESS_URL,
        headers=HEADERS,
        params={"query": address}
    )

    if res.status_code != 200:
        return None, None

    docs = res.json().get("documents", [])
    if not docs:
        return None, None

    time.sleep(sleep)
    return float(docs[0]["x"]), float(docs[0]["y"])

6. 실행

법정동별 카테고리 시설 수 계산 & 즉시 저장

커널이 종료 되더라도 이어서 실행할 수 있도록 분기 처리

dong_df = pd.read_csv("../raw/legal_dong.csv")

seoul_dong_df = dong_df[
    (dong_df["시도명"] == "서울특별시") &
    (dong_df["시군구명"].notna()) &
    (dong_df["읍면동명"].notna()) &
    (dong_df["읍면동명"] != "")
].copy()

done_bcodes = set()

if os.path.exists(OUTPUT_PATH) and os.path.getsize(OUTPUT_PATH) > 0:
    done_df = pd.read_csv(OUTPUT_PATH)
    done_bcodes = set(done_df["법정동코드"].astype(str))
    print("이미 처리된 법정동 수:", len(done_bcodes))
else:
    print("기존 결과 없음 (처음 실행)")

# CSV 헤더 최초 1회만 작성
if not os.path.exists(OUTPUT_PATH):
    pd.DataFrame(
        columns=["법정동코드", "category_group_code", "count"]
    ).to_csv(OUTPUT_PATH, index=False)
    
for idx, row in seoul_dong_df.iterrows():
    bcode = str(row["법정동코드"])

    if bcode in done_bcodes:
        continue

    address = f"서울특별시 {row['시군구명']} {row['읍면동명']}"

    x, y = dong_to_coord(address)
    if x is None:
        continue

    rows_to_save = []

    for category in CATEGORIES.keys():
        places = fetch_places(category, x, y, RADIUS)

        count = 0
        for p in places:
            place_bcode = coord_to_bcode(p["x"], p["y"])
            if place_bcode == bcode:
                count += 1

        rows_to_save.append({
            "법정동코드": bcode,
            "category_group_code": category,
            "count": count
        })

    pd.DataFrame(rows_to_save).to_csv(
        OUTPUT_PATH,
        mode="a",
        header=False,
        index=False
    )

    time.sleep(0.3)

React - SVGR 설치

Tue, 03 Feb 2026 00:00:00 GMT

1. Vite project에서 SVGR 설치

npm install -D vite-plugin-svgr

2. vite.config.ts 설정

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import svgr from 'vite-plugin-svgr'

export default defineConfig({
  plugins: [
    react(),
    svgr(),
  ],
})

3. 타입 선언 추가 (TypeScript 사용 시)

/// <reference types="vite-plugin-svgr/client" />

4. 사용 방법

Vite 방식

import Icon from '@/assets/icon.svg?react';

<Icon />

?react 를 붙여야 하는 이유
- Vite는 기본적으로 SVG를 URL으로 처리함
- 따라서 ?react를 붙여야 React Component로 변환됨

CRA(Create React App) 방식

import { ReactComponent as Icon } from './icon.svg';

구분	CRA	Vite
SVG React 변환	기본 내장	별도 plugin 필요
import 방식	`{ ReactComponent as Icon }`	`?react`
설정 접근	Webpack 숨김	설정 파일 명시적

딥러닝 | Agentic AI개요

Sun, 19 Oct 2025 00:00:00 GMT

Agentic AI란?

주어진 상황에서 문제 해결을 하기 위해 스스로 목표를 설정하고, 재조정하며 적응적 의사결정을 하는 AI를 말한다.

Agentic AI vs AI Agent

Agentic AI : 스스로 목표 설정을하고 실행 능력을 갖춘 AI
AI Agent : 특정 작업 중심으로 사전에 정의된 범위 내에서만 자율적으로 작동

특징	Agentic AI	AI Agent
정의	스스로 목표를 설정하고, 재조정하며 적응적 의사결정을 하는 AI 시스템	환경을 인식하고, 결정하며, 사전에 정해진 목표를 달성하기 위해 자율적으로 행동하는 개별 소프트웨어 프로그램 또는 시스템
범위	여러 AI Agent를 조율하여 복잡한 고수준 목표 달성 (상위 개념)	특정 목표 달성을 위한 기본 구성 요소 (하위 개념)
목표 설정	스스로 목표를 설정하고 재조정	사전에 정해진 목표를 따름
행동	적응적 의사결정 및 AI Agent들의 협업을 통한 복잡한 문제 해결	환경에 따라 결정하고 자율적으로 행동

Agent System은 다음과 같이 나눌 수 있다.

1. Single Agent System

하나의 AI system이 환경과 상호작용하며 문제 해결을 함

(+) : 단순구조

(+) : 의사결정 속도가 빠름

(-) : 복잡한 문제 해결 불가능

2. Multi Agent System

여러 Agent들이 동일한 환경에서 상호작용하며 문제 해결을 한다.

(+) : 복잡한 문제 해결 가능

MAS의 특징

분산성 (decentralization)
- 의사결정과 제어가 중앙 집중적이지 않고, 각 에이전트들이 독립적으로 동작한다.
- 단일 실패 지점을 제거하여, 시스템 안정성을 향상시켰다.
- P2P network, 블록체인, 자율 드론 분산 제어
자율성 (Autonomy)
- 외부의 개입 없이, 스스로 목표 달성을 위한 의사결정 수행
- 환경 변화에 대응, 인간의 개입 최소화
- 예) 로봇이 스스로 경로 탐색, 에이전트가 자원 사용 결정
상호작용 (Interaction)
- 에이전트들 간 정보 교환과 협력을 통해 집단적으로 문제 해결
- 시너지 효과
적응성 (Adaptivity)
- 에이전트가 환경 변화 및 다른 에이전트의 행동에 맞게 전략을 수정
- 동적 및 불확실한 환경에서도 유효하게 동작 가능
- 예) 주식 거래에서 시장 변화에 따라 매매 전략 조정

다음과 같이 세분화 할 수 있다.

2-1. 계층기반 MAS (Hierarchy MAS)

하나의 관리 Agent와 여러 개의 Agent들로 구성 되어 있다.
- 관리 Agent는 전체 프로세스를 조율, 하위 Agent들을 제어하고 업무 조정
- (+) : 통제 용이, 의사결정 속도 빠름
- (-) : 중앙 에이전트 의존성, 병목 가능성

2-2. Collaborative MAS (협력 기반 MAS)

여러 Agent들이 정보를 공유하며 협력적으로 문제해결한다.
- (+) : 시너지 효과 -> 문제 해결 능력이 높아짐
- (-) : 협상과 조율이 필요
- 협력 전략
  - Task Sharing
  - Result Sharing
  - CNP(Contract Net Protocol)
- 응용 사례
  - 자율주행 : 차량들이 서로 협력하여 교통의 혼잡도를 완화시킴
  - 로보틱스 : 다수의 드론이 협력하여 탐사, 재난 구조 수행
  - 스마트 그리드: 에이전트 기반 전력 거래와 분배를 최적화
  - 전자상거래: 자동 협상 / 경매 에이전트
  - 사회 시뮬레이션 : 인구 이동, 질병확산등

2-3. Competitive MAS (경쟁기반 MAS)

Agent들이 자신의 이익을 극대화하기 위해 경쟁
- 주식 시장 시뮬레이션, 경매 시스템
- (+) : 현실성 반영
- (-) : 갈등이 발생 -> 전체 효율이 저하됨

Agent간 통신 프로토콜

Agent간 정보 교환을 위해 프로토콜 필요

통신 방식
- 직접통신
- 브로드캐스트 / 멀티캐스트
- 중앙 매개체 기반

FIPA (Foundation for Intelligent Physical Agents)

MAS의 상호운용성 확보를 위한 국제 표준 제정

FIPA-ACL(Agent Communication Language)

에이전트 간 메시지 교환을 위한 언어

메시지 구성: Performative, Content, Sender, Receiver, Ontology, Protocol

딥러닝 | CNN(합성곱신경망) 개요

Fri, 17 Oct 2025 00:00:00 GMT

1. CNN 이란?

Convolutional Neural Network의 줄임말로, 격자 이미지와 같은 데이터를 설계하기 위해 고안된 인공 신경망

합성곱(convolution) 연산을 통해 이미지의 공간적 특징을 추출(feature map)한다.

특징

vision 분야에서 성능 우수

이미지 데이터를 인식하고 패턴을 찾는데 유용

데이터를 학습하고 패턴을 사용하여 이미지를 분류함

1-1 CNN 모델 발전

LeNet
AlexNet
VGGNet
ResNet
EfficientNet

2. CNN의 구조

Convolution과 Pooling을 반복하면서 특징을 찾고, 그 특징을 fully connected NN의 입력 데이터로 사용함으로써 Classification을 수행함

2-1 CNN Layer

CNN의 Layer는 크게 3가지로 나눌 수 있다.

Convolutional Layer

Pooling Layer

Fully-connected Layer

2-1-1. Convolutional Layer

이미지 데이터는 3차원 tensor로 표현됨

이미지 input을 받아, 필터와 합성곱 연산을 통해 특징이 두드러지도록 feature map을 생성한다.

filter(kernel) : 필터를 통과한 이미지는 선, 색상, 형태, 경계등 이미지를 구분지을 수 있는 요소가 뚜렷해짐

필터가 많을 수록 더 많은 이미지 feature를 추출할 수 있음

stride : 필터의 이동량

padding : 이미지에 합성곱 연산을 수행하면 출력 이미지의 크기가 입력이미지의 크기보다 작아지는 문제 발생 -> 이미지 가장자리에 특정 값으로 픽셀 추가

예) Zero-padding : 가장 자리를 0 pixel로 채움

feature map(=activation map이라고도 함)

2-1-2. Pooling Layer

feature map의 feature를 유지하면서, 이미지의 크기를 줄이는 다운사이징 기법

일반적으로, 이미지 데이터는 인접 픽셀들 간 유사도가 높다는 특징을 이용

기법 3가지

Max Pooling : 가장 큰 신호에 값으로 반응 -> 노이즈 감소, 속도가 빠름, 영상의 분별력이 좋아짐

Average Pooling

Min Pooling

2-1-3. Activation Function

각 뉴런(노드)의 입력 값을 처리한 후에 출력값을 결정하는 함수

입력 값을 다음 층으로 출력을 전달할 지를 결정함

 a=f(z) 
 \\ z = w \times X + b

활성화 함수 종류: ReLU, Sigmoid, Tanh, Leaky ReLU 등

활성화 함수 사용 이유?

비선형성: 신경망에 비선형성을 도입하여 단순한 선형 변환으로는 해결할 수 없는 문제 해결

출력 범위 조정

신경망의 학습 속도에 영향

리버싱 핵심 원리 | PE 파일 구조

Fri, 10 Oct 2025 00:00:00 GMT

PE 파일 형식 (Portable Executable)

PE(Portable Executable) 는 실행 파일, DLL, 오브젝트 코드 등을 위한 파일 형식이다. 이름처럼 다른 곳으로 옮겨도 실행이 가능하도록 이식성을 염두에 두고 설계되었다. PE 파일은 크게 PE 헤더와 섹션으로 구성된다.

PE 헤더 (PE Header)

PE 헤더는 파일의 메타데이터를 담고 있으며, 운영체제가 파일을 메모리에 어떻게 매핑하고 실행할지에 대한 정보를 제공한다.

1. DOS 헤더 (DOS Header)

모든 PE 파일의 시작은 IMAGE_DOS_HEADER 구조체로 시작한다. 이는 MS-DOS와의 하위 호환성을 위한 부분이다.

typedef struct _IMAGE_DOS_HEADER // DOS .EXE header
{
    WORD e_magic;       // Magic number
    WORD e_cblp;        // Byte on last page of file
    WORD e_cp;          // Pages in file
    WORD e_crlc;        // Relocations
    WORD e_cparhdr;     // Size of header in paragraphs
    WORD e_minalloc;    // Minimum extra paragraphs needed
    WORD e_maxalloc;    // Maximum extra paragraphs needed
    WORD e_ss;          // Initial (relative) SS value
    WORD e_sp;          // Checksum
    WORD e_ip;          // Initial IP value
    WORD e_cs;          // Initial (relative) CS value
    WORD e_lfarlc;      // File address of relocation table
    WORD e_ovno;        // Overlay number
    WORD e_res[4];      // Reserved words
    WORD e_oemid;       // OEM identifier (for e_oeminfo)
    WORD e_oeminfo;     // OEM information; e_oemid specific
    WORD e_res2[10];    // Reserved words
    LONG e_lfanew;      // File address of new exe header
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

주요 멤버 변수는 다음과 같다.
- e_magic: DOS signature로 항상 "MZ" (0x5A4D) 값을 가진다. 파일이 유효한 PE 파일인지 확인하는 첫 번째 지표이다.
- e_lfanew: NT 헤더의 시작 위치를 알려주는 오프셋 값이다. 이 값을 통해 NT 헤더로 바로 이동할 수 있다.

2. DOS 스텁 (DOS Stub)

DOS 헤더 바로 뒤에 위치하며, PE 파일을 DOS 환경에서 실행했을 때 "This program cannot be run in DOS mode"와 같은 메시지를 출력하는 작은 프로그램이다.

3. NT 헤더 (NT Headers)

e_lfanew가 가리키는 위치에 있으며, PE 파일의 핵심 정보를 담고 있다. Signature, File Header, Optional Header 세 부분으로 나뉜다.
- Signature: PE 포맷임을 나타내는 시그니처로, "PE\0\0" (0x00004550) 값을 가진다.
- 파일 헤더 (File Header): IMAGE_FILE_HEADER 구조체이며, 파일의 개략적인 정보를 담는다.
  - Machine: 대상 CPU 아키텍처 (e.g., x86, x64).
  - NumberOfSections: 파일에 존재하는 섹션의 개수.
  - TimeDateStamp: 파일이 생성된 시간.
  - Characteristics: 파일의 속성 (e.g., 실행 파일인지, DLL인지).
- 옵셔널 헤더 (Optional Header): IMAGE_OPTIONAL_HEADER 구조체이며, 이름과 달리 실행 파일에서는 필수적인 헤더이다. 프로그램 실행에 필요한 핵심 정보를 포함한다.
  - Magic: PE32(0x10b) 또는 PE32+(0x20b, 64비트)를 구분한다.
  - AddressOfEntryPoint: 프로그램이 처음 시작되는 코드의 주소(RVA).
  - ImageBase: PE 파일이 메모리에 로드되는 시작 주소.
  - DataDirectory: IMAGE_DATA_DIRECTORY 구조체 배열로, Import/Export 테이블, 리소스, TLS 등 중요한 데이터 구조의 위치와 크기 정보를 담고 있다.

섹션 (Sections)

헤더 다음에 위치하며, 코드, 데이터, 리소스 등 파일의 실제 내용을 담고 있다. 각 섹션은 자신의 속성을 정의하는 섹션 헤더를 가진다.

주요 섹션 종류

.text: 실행 가능한 코드를 포함하는 섹션. 일반적으로 실행/읽기 전용 권한을 가진다.
.data: 초기화된 전역 변수 및 정적 변수를 저장하는 섹션.
.rdata: 읽기 전용 데이터 (e.g., 문자열 리터럴, 상수)를 저장한다. Import/Export 테이블 정보도 이 곳에 위치할 수 있다.
.bss: 초기화되지 않은 데이터 섹션. 파일 내에서는 공간을 차지하지 않지만, 메모리에 로드될 때 할당된다.
.rsrc: 아이콘, 이미지, 메뉴 등 프로그램에서 사용하는 리소스를 저장한다.
.idata: 다른 DLL에서 가져오는 함수 정보를 담은 Import Address Table (IAT) 등이 위치하는 섹션이다.
.edata: 다른 프로그램에서 사용할 수 있도록 함수를 노출하는 Export 정보가 담긴 섹션이다. (주로 DLL)
.reloc: ImageBase에 로드할 수 없는 경우, 코드 내의 주소를 수정하기 위한 재배치 정보를 담고 있다.

PE Viewer로 확인

사용한 PE Viewer -> VX PE Viewer ver 1.0

Dos header signature 확인

Dos Header > Magic number 부분을 클릭하면 아래 HEX DUMP 창에 해당 영역에 하이라이트가 칠해진 부분을 확인할 수 있다.

Magic Number가 차지하는 부분은 총 2bytes이고 signature는 MZ이다.

PE 파일 로딩과 메모리

Windows가 프로세스를 메모리에 로드할 때, PE 파일의 정보를 사용하여 가상 메모리 공간에 내용을 매핑한다. 이때 운영체제는 가상 메모리의 어느 위치에, 어떤 크기로 공간을 할당해야 할지 어떻게 알 수 있을까?

그 해답은 옵셔널 헤더(Optional Header) 에 있다.

ImageBase: PE 파일이 메모리에 로드될 가상 주소(VA)의 시작점을 지정한다. 예를 들어 ImageBase가 0x00400000이라면, 로더는 이 주소부터 PE 이미지를 배치하려고 시도한다.

Hex Dump에서 이 값은 00 00 40 00처럼 보이는데, 이는 intel x86 아키텍처가 사용하는 리틀 엔디안(Little Endian) 바이트 순서 때문이다. 낮은 주소에 데이터의 가장 낮은 바이트(Least Significant Byte)부터 저장하므로, 실제 값은 0x00400000이 된다.

ImageBase에 지정된 주소는 희망 사항(preferred address)일 뿐, 항상 그 주소에 로드된다는 보장은 없다. 만약 해당 프로세스의 가상 주소 공간에서 ImageBase 주소가 이미 다른 모듈(e.g., 다른 DLL)에 의해 사용 중이라면, PE 로더는 다른 비어있는 주소에 파일을 로드하게 된다. 이 과정을 재배치(Rebasing) 라고 하며, 이를 위해 .reloc 섹션의 정보가 사용된다.

Operating System | 병행성의 개념

Thu, 09 Oct 2025 00:00:00 GMT

병행성(concurrency)의 원리

OS는 멀티프로세스를 처리해야함. 멀티프로세스를 처리해야하는 OS의 공통 주제는 아래와 같음

Multiprogramming : 단일 프로세서 시스템 + 여러 개 프로세스

Multiprocessing : 멀티 프로세서 + 멀티 프로세스

Distributed Processing

공유자원(such as memory, files, and I/O access)을 나누고 점유하는데 있어서 방법론이 필요함.

병행성(concurrency)라는 개념 등장

병행성은 다음과 같은 3가지 상황에서 발생한다

다수의 응용: 다수의 활동 중인 응용들 간에 처리시간의 동적 공유를 위해 멀티 프로그래밍이 발전

구조화된 응용: 모듈화된 설계 원칙과 구조적인 프로그램이 발전되면서 일부 응용이 병행 프로세스의 집합

운영체제 구조: 운영체제도 다수의 프로세스와 쓰레드의 집합으로 구현

병행 처리의 문제점

전역 자원의 공유가 어려움

운영체제가 자원을 최적으로 할당하기 어려움

프로그래밍 오류 찾기가 어려움

인터리빙이나 오버래핑으로 인해 발생하는 문제점 -> 단일처리기 시스템에서나 다중처리시스템에서 동일

다른 프로세스의 행동에 종속

OS의 스케줄링 정책에 의존

OS의 인터럽트 처리 방법에 따라 달라짐

병행성과 관련된 주요 용어 정리

용어	정의	주요 특징 / 핵심 포인트
Atomic Operation (원자적 연산)	수행 도중 중단되거나 다른 프로세스가 중간 상태를 볼 수 없는 연산	- 불가분성(Indivisibility) - 중간 상태 노출 불가 - 병행 프로세스 간 고립 보장
Critical Section (임계영역)	공유 자원에 접근하는 코드 영역	- 동시에 하나의 프로세스만 접근 가능 - 동기화 기법으로 보호 필요
Deadlock (교착상태)	프로세스들이 서로의 자원을 기다리며 무한 대기하는 상태	- 자원 대기 순환 구조 - 시스템 진행 정지 - 예방/회피/탐지 기법 존재
Livelock (라이브락)	프로세스들이 상태를 계속 바꾸지만 실제로는 아무 작업도 수행하지 않는 상태	- Deadlock과 달리 상태 변화는 존재 - 실질적 진전 없음 - 과도한 재시도 루프 발생 시 흔함
Mutual Exclusion (상호배제)	한 시점에 오직 하나의 프로세스만 임계영역 실행 가능	- 경쟁 방지 - 세마포어, 뮤텍스 등으로 구현 - 임계영역 문제 해결 조건 중 하나
Race Condition (경쟁상태)	여러 프로세스가 동시에 공유 자원에 접근해 결과가 실행 순서에 따라 달라지는 상태	- 비결정적 결과 발생 가능 - 원자성 보장 실패 - 동기화 필요
Starvation (기아)	프로세스가 실행 가능한 상태임에도 스케줄링에서 계속 배제되어 실행되지 못하는 상황	- 우선순위 스케줄링에서 자주 발생 - 공정성(Fairness) 문제 - Aging 기법으로 완화 가능
Shared Resource (공유 자원)	여러 프로세스가 함께 사용하는 자원 (메모리, 파일 등)	- 동기화 필요 - 경쟁 상태의 원인
Synchronization (동기화)	여러 프로세스의 실행 순서를 제어하여 일관성을 유지하는 기법	- Mutual Exclusion 구현 수단 - 세마포어, 모니터, 조건 변수 등 사용

자원경쟁

병렬 프로세스들은 같은 자원을 사용하려고 경쟁하면 충돌이 발생한다.

프로세스들이 경쟁(race)하면 다음 3가지 제어 문제가 발생함

상호배제, 교착상태, 기아

eg. memory, files, and I/O access, clock

Operating System | 상호배제

Thu, 09 Oct 2025 00:00:00 GMT

상호배제 (Mutual Exclusion)란?

한 번에 하나의 프로세스만 임계 구역(critical section)을 실행할 수 있도록 하는 원리.

상호 배제를 보장하기 위해서는 프로세스가 인터럽트(interrupt) 되지 않도록 해야 한다.
단일 프로세서 시스템에서는 여러 프로세스가 동시에 실행되지 않고 인터리빙(interleaving) 방식으로 번갈아 실행된다.
실행 중인 프로세스는 OS 서비스를 호출하거나 인터럽트를 받을 때까지 계속 실행된다.
OS 커널은 인터럽트 비활성화(disable interrupts) 및 활성화(enable interrupts) 기능을 제공한다.

while (true) {
    /* 인터럽트 비활성화 */
    /* 임계 구역 */
    /* 인터럽트 활성화 */
    /* 나머지 코드 */
}

위 방식은 임계 구역이 인터럽트를 받지 않으므로 상호 배제가 보장된다.
그러나 다음과 같은 단점이 존재한다.
- 실행 효율 저하 (프로세스 인터리빙 제한)
- 다중 프로세서(multiprocessor) 환경에서는 동작하지 않음
따라서 이러한 한계를 보완하기 위해 다른 상호 배제 알고리즘(예: Peterson’s algorithm, Test-and-Set 등)이 사용된다.

상호배제 해결방법

연습문제 5.1

With respect to mutual exclusion using interrupt disabling

Mention the requirements for this exclusion and state which of them are met when interrupts are disabled.

임계영역에 접근하고자 하는 프로세스의 수행이 무한히 미루어져서는 안됨.
임계영역이 empty일 때, 임계영역에 진입하려고 하는 프로세스가 지연되어서는 안 됨
프로세서의 개수나 상대적인 프로세스 수행 속도에 대한 가정은 없어야 함.
프로세스는 유한 시간 동안만 임계영역에 존재할 수 있음.

Identify the problems associated with this mechanism.

연습문제 5.3

(a)해설

initial values $x$ 와 $y$ 의 값이 각각 2와 3이다.

$P_1$ 에서 $x =$ $2 \times 3$ 이므로 $x = 6$ 이다.
$P_1$ 에서 $y + 1$ 이므로 $y=4$ 이다.
$P_2$ 에서 $x +1$ 이므로 $x=7$ 이다.
$P_2$ 에서 $y = x \times y = 6 \times 4$ 이므로 $y=28$ 이다.

(b)해설

assembly 코드를 확인해야 interleaved concurrent schedule을 확인할 수 있다.
교행 수행 되었을 때 가지 수는 많음 -> 순차 실행 되었을 때와 x, y갱신된 값이 다르다 정도만 알고 넘어가면 됨.
$P_1$ 에서
- x := x * y 에서
  - LOAD R1, X X의 값을 R1(레지스터)에 로드
  - LOAD R2, Y Y의 값을 R2(레지스터)에 로드
  - MUL R1, R2 R1에 R2의 값을 곱하여 R1에 갱신
  - STORE X, R1 R1의 값을 X에 저장
- y++ 에서
  - INC R2 R2의 값을 1만큼 증가
  - STORE Y, R2(증가된) R2의 값을 Y에 저장
$P_2$

리버싱 핵심 원리 | DLL

Tue, 07 Oct 2025 00:00:00 GMT

Windows Library, DLL

라이브러리(Library)란?

함수, 변수, 데이터, 타입 리소스등 여러 가지 프로그래밍 요소들의 집합

windows 운영체제에서는 주로 *.lib, *.dll과 같은 확장자를 가진다.

표준화할 수 있는 함수 집합

C 표준 함수 : printf(), scanf() 등

Win32 API : LoadLibraryA(), GetProcAddress(), MessageBox(), ...

라이브러리 링킹이란?

누군가가 만들어놓은 라이브러리를 자신의 프로그램에서 활용하는 방안

정적링킹과 동적링킹으로 구분된다.

정적 링킹(Static Linking)

빌드 중 링커가 라이크러리 컨텐츠를 바이너리(exe) 실행파일에 통합하는 방식

실행 파일에 라이브러리 코드가 복제되기 때문에 실행 파일의 크기가 커짐

실행 파일은 단독 실행 파일이 되기 때문에 빌드만 성공하면 런타임에 실패하지 않음

동적 링킹(Dynamic Linking)

빌드 시 라이브러리 함수 코드가 실행 파일에 통합되지 않고, 런타임에 라이브러리 로드 및 함수 호출이 수행되는 방식

프로그램 실행 시에 함수가 실행 파일과 연결됨

호출할 함수 정보를 IAT(Import Address Table)에 적재되므로 실행 파일의 크기가 작다는 장점이 있음

PATH 또는 시스템 폴더에 DLL이 없으면 프로그램 실행 불가 (런타임 시에 오류 발생)

리버싱 핵심 원리 | Stack Frame

Mon, 06 Oct 2025 00:00:00 GMT

스택 프레임

x64dbg에서 main caller에 break point를 걸고 확인

main함수도 누군가에게 호출 됨

EBP 레지스터를 이용하여 스택 내의 로컬 변수, 파라미터, RET에 접근하는 기법

EBP를 사용하는 이유: ESP 레지스터의 값은 프로그램 안에서 수시로 변경되기 때문에 스택에 저장된 변수, 파라미터에 접근하고자 할 때는 EBP를 사용하는 것이 효율적임

EBP: 베이스 포인터, ESP: 스택의 최상단 주소를 가리키는 레지스터

함수가 호출될 때마다 스택 프레임이 만들어진다.

스택 프레임 안에는 함수의 매개변수(파라미터), 복귀 주소(RET), 지역 변수 등이 포함됨

스택 프레임의 구조

(함수의 프롤로그)
PUSH EBP
MOV EBP, ESP
-------
(함수 본체)
...

-------
(함수의 에필로그)
MOV ESP, EBP
POP EBP
RET

일단 기존의 EBP값을 어딘가에 저장해둬야하기 떄문에 EBP값을 스택에 저장해둠 (나중에 복구해야함)
EBP는 함수가 종료될 때까지 유지됨 (함수 실행 중에는 ESP가 계속 변함)
- 그 다음 현재 ESP가 가리키는 값을 EBP에 갱신함
- 함수 실행
- 함수 실행이 종료되면 EBP가 가리키는 값을 다시 ESP에 저장
- EBP값을 pop하여, 함수 시작 전에 저장해둔 이전 함수의 프레임 포인터(EBP)를 되돌려줘서 스택 프레임을 원복함

스택 예제

int function(int a, int b) {
    char buffer[10] = { 0 };
    a = a + b;
    return a;
}
void main() {
    int c;
    c = function(1, 2);
}

스택 예제 | main 함수의 prologue

메모리 연산자

특정 주소의 값을 참조하기 사용하는 연산자

BYTE PTR[...]
WORD PTR[...]
DWORD PTR[...]
QWORD PTR[...]

BYTE는 1바이트,
WORD는 2바이트,
DWORD(Double WORD)는 4바이트
QWORD(Quad WORD)는 8바이트.

Operating System | 쓰레드(Thread)

Sun, 05 Oct 2025 00:00:00 GMT

프로세스와 쓰레드

쓰레드 = 실행흐름

쓰레드의 장점(benefits)
- 프로세스에 비해 새로운 쓰레드 생성 시간/비용이 절약됨
- 프로세스 종료 시간보다 쓰레드 종료 시간이 짧다.
- 한 프로세스 내의 두 쓰레드들 사이의 교환 및 교체 시간이 짧다.
- 동일 프로세스 내의 쓰레드들은 메모리 및 파일을 공유하기 때문에, 이들 쓰레드들은 커널의 개입 없이 서로 통신 가능

단일쓰레딩(threading) & 멀티쓰레딩(Multithreading)

UNIX 계열의 여러 운영체제는 다중 사용자 프로세스를 지원하지만, 프로세스 당 하나의 쓰레드만을 지원한다.

JAVA 수행시간 환경은 하나의 프로세스가 멀티 쓰레드를 지원한다.

단일 프로세스 내에 멀티 쓰레드 실행을 지원 가능

현존하는 멀티 프로세서 -> 다수의 프로세스 & 프로세스 당 다수의 쓰레드

쓰레드의 기능

쓰레드 동기화(synchronization)

한 프로세스 내의 모든 쓰레드들은 동일 주소 공간 및 자원들을 공유

공유 자원: 전역 변수, 파일, 힙(heap)duddur

공유 자원에 대해 동시 접근 시, 일관성 유지 기법 필요

Agentic AI (1)

Fri, 03 Oct 2025 00:00:00 GMT

📌 AI 시스템의 사회적 영향

경제적 영향

산업 구조 변화: 제조·물류·금융·의료 전반에서 자동화·효율성 증대
혁신 가속: 자율주행, 맞춤형 헬스케어, 스마트시티 등 신산업 창출
노동시장 재편: 단순 업무 감소, 고급 기술·데이터 일자리 증가 → 일자리 양극화
부의 불평등: 대기업 중심 시장 집중 심화

사회적 영향

생활 편의 향상: 추천·교육·헬스케어 개인화
문화 변화: 콘텐츠 제작 자동화
디지털 격차: 활용 능력 차이로 불평등 확대
신뢰 문제: 딥페이크·허위정보로 정보 신뢰 하락

📌 AI 규제 필요성과 프레임워크

필요성

새로운 위험 (의료 AI, 자율주행 등)
보안 위협 (딥페이크, AI 활용 사이버 공격)
설명가능성 부족 (책임·법적 문제)

국가별 접근

미국: 산업경쟁력 유지 + 위험 완화
EU: 위험기반 규제, 강력한 법적 구속력 (EU AI Act)
중국: 사회통제 중심 규제
한국: 균형적·진흥지향적 법제

📌 EU AI Act (유럽연합 인공지능법)

2024년 3월에 통과된 AI 기술의 급속한 발전과 광범위한 적용에 따른 윤리적, 법적, 사회적 영향에 대응하기 위해 마련된 포괄적인 AI 규제 법안

위험 기반 분류
- [Level 1] 수용 불가 위험 → 사용 전면 금지
- [Level 2] 고위험 → 인프라, 교육, 필수 서비스 → 강한 규제
- [Level 3] 제한적 위험 → 딥페이크 등 → 투명성 의무 부과
- [Level 4] 저위험 → 상업·개인용 → 규제 최소
투명성 의무
- AI와 상호작용 중임을 고지
- 합성 콘텐츠 결과물 표시 의무

📌 미국 NIST AI RMF (위험관리 프레임워크, 2023)

목적: AI 이점 극대화 + 위험 최소화
적용대상: 모든 분야·규모의 조직

AI 신뢰성 7대 특성

유효성·신뢰성
안전성
보안성·회복탄력성
책임성·투명성
설명가능성
프라이버시
공정성·편향 완화

📌 Traditional AI vs. Agentic AI

구분	Traditional AI	Agentic AI
목표	외부 명령 수행	목표 설정·재조정
상호작용	입력-출력 중심	환경·에이전트·인간과 지속적 상호작용
의사결정	사전학습 모델 기반	적응적·협력적 의사결정
자율성	제한적	예측불가 상황에서도 자율 대응
협력	개별 성능 최적화	전체 성능 최적화

📌 Generative AI vs. Agentic AI

구분	Generative AI	Agentic AI
핵심 개념	콘텐츠 생성 (텍스트·이미지 등)	목표 설정·의사결정 수행
출력	프롬프트 기반 결과	의사결정 + 행동 수행
상호작용	단발적 입력-출력	지속적 협력/협상
자율성	외부 지시 의존	스스로 목표·전략 수립
활용 예	텍스트 작성, 이미지 생성	교통 신호 제어, 위급상황 자율 대응

📌 Agentic AI 특징

자율성(Autonomy): 목표·의사결정 스스로
적응성(Adaptability): 환경 변화 대응
협력성(Cooperation): 타 에이전트·인간과 상호작용
설명가능성(Transparency): 의사결정 근거 제공
확장성(Scalability): 모듈형 확장 가능
맥락인식(Context-awareness): 상황 기반 의사결정

📌 동작 단계

인식 (Perception): IoT, DB, SNS 등에서 데이터 수집
추론 (Reasoning): 계획·의사결정 수행
행동 (Action): 작업 실행 및 수정
학습 (Learning): 경험 축적, 성능 개선

📌 기술 스택

LLM + RAG: 정보 검색 강화
강화학습: 전략적 계획 수립
멀티에이전트 시스템: 분산 환경 협력

📌 Agentic AI 유형

Cooperative

역할 분담 → 전체 목표 최적화
예: 교통신호 제어, 스마트팩토리, 디지털포렌식

Collaborative

목표를 동적으로 협상·조율
예: 출퇴근 시간 교통 처리량 vs 주말 안전성, 사건 유형별 디지털포렌식

📌 도전과제

연동 복잡성: 기존 시스템 통합 문제
정확성: 데이터 품질 의존
설명가능성 부족: 블랙박스 의사결정
리스크 관리: 개인정보, 보안, 법적 리스크
유지보수: 지속적인 감독·테스트 필요

📌 Dark AI / Dark LLM

Dark AI: 딥페이크, 사이버 범죄, 감시·프라이버시 침해, 무기화 등
Dark LLM: WormGPT, FraudGPT → 악성코드, 피싱, 랜섬웨어 자동화
방어 기술: DarkBERT(다크웹 분석), FakeCheck(딥페이크 탐지)

📌 The 30% Rule

AI 70% + 인간 30% 역할 분담

이유

윤리적 안전장치 (사회적 가치·법 기준 충족)
AI 한계 보완 (편향, 오류 방지)
인간의 창의성, 공감, 도덕적 판단 보존

리버싱 핵심 원리 | 1부 기초 리버싱

Fri, 03 Oct 2025 00:00:00 GMT

1. 리버싱 분석 방법

1.1 정적 분석

파일의 겉모습을 분석하는 방법
- 파일을 실행하지 않음
- 파일의 종류, 크기, 헤더, 정보, 디지털 인증서 등의 다양한 내용을 확인
- 디스어셈블러를 이용해 내부 코드와 그 구조를 확인

1.2 동적 분석

파일을 직접 실행시켜서 그 행위를 분석하고, 디버깅을 통해 코드 흐름과 메모리 상태를 자세히 살펴보는 방법

2. 리틀 엔디언 표기법

컴퓨터에서 메모리에 데이터를 저장하는 방식을 의미 (바이트 오더링; Byte Ordering)

2.1 바이트 오더링(Byte Ordering)

일련의 데이터를 저장하는 방식
- 바이트 오더링에는 **빅 엔디언(Big Endian)**과 **리틀 엔디언(Little Endian)**표기 두가지가 있음
```
BYTE b = 0x12;
hr0RD w = 0xL234:'
DTORD dt/ = 0x12345678;
char str[] = "abcde";
```
- **빅 엔디언(Big Endian)**은 데이터를 저장할 때 사람이 보는 방식과 동일하게 앞에서부터 순차적으로 저장함
  - 사람이 보기엔 직관적인 편
  - 사용예시
    - UNIX 서버에 사용되는 RISC 계열의 CPU에서 사용됨
    - 네트워크 프로토콜
- **리틀 엔디언(Little Endian)**은 데이터를 저장할 때 역순으로 저장함
  - Intel x86 CPU에서 리틀 엔디언 방식을 사용함

3. Visual Studio 디버깅 방법

의심 함수 앞에 breakpoint.
변수 Watch에 추가.
처음엔 Step Over로 큰 그림 파악.
이상 징후가 보이는 호출 지점에서 Step Into.
내부가 괜찮다? Step Out으로 상위로 복귀.

; --- C:\Users\최우진\source\repos\WEEK03\WEEK03\week03.cpp -------------------------

int main(void) {
004010A0 55                   push        ebp
004010A1 8B EC                mov         ebp,esp
004010A3 83 EC 0C             sub         esp,0Ch
    ; int retval;
    ; int a = 0x10;
004010A6 C7 45 F8 10 00 00 00 mov         dword ptr [ebp-8],10h
    ; int b = 0x20;
004010AD C7 45 FC 20 00 00 00 mov         dword ptr [ebp-4],20h

    ; printf("Program Started!\n");
004010B4 68 00 21 40 00       push        402100h
004010B9 E8 82 FF FF FF       call        00401040
004010BE 83 C4 04             add         esp,4

    ; retval = add(a, b);
004010C1 8B 45 FC             mov         eax,dword ptr [ebp-4]
004010C4 50                   push        eax
004010C5 8B 4D F8             mov         ecx,dword ptr [ebp-8]
004010C8 51                   push        ecx
004010C9 E8 B2 FF FF FF       call        00401080
004010CE 83 C4 08             add         esp,8
004010D1 89 45 F4             mov         dword ptr [ebp-0Ch],eax

    ; printf("%d\n", retval);
004010D4 8B 55 F4             mov         edx,dword ptr [ebp-0Ch]
004010D7 52                   push        edx
004010D8 68 14 21 40 00       push        402114h
004010DD E8 5E FF FF FF       call        00401040
004010E2 83 C4 08             add         esp,8

    ; printf("End of Program! \n");
004010E5 68 18 21 40 00       push        402118h
004010EA E8 51 FF FF FF       call        00401040
004010EF 83 C4 04             add         esp,4

    ; return 0;
004010F2 33 C0                xor         eax,eax
}
004010F4 8B E5                mov         esp,ebp
004010F6 5D                   pop         ebp
004010F7 C3                   ret

; --- D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl --------

라인별 해설

함수 프롤로그 & 스택 프레임 생성

004010A0 55                push ebp          ; 이전 프레임 포인터 저장
004010A1 8B EC             mov  ebp, esp     ; ebp를 현재 스택 꼭대기로 설정
004010A3 83 EC 0C          sub  esp, 0Ch     ; 지역변수 12바이트 확보

retval, a, b의 type이 int(4bytes) 3개 -> 12바이트(0x0C) 공간 확보
- stack은 높은 주소에서 낮은 주소 방향으로 확장됨
- sub esp, 0Ch → esp = esp - 0Ch
  - esp는 스택 포인터
지역변수 배치
- [ebp-8] = a
- [ebp-4] = b
- [ebp-0Ch] = retval

3.1 Step over & Step Into 차이

Step Over

현재 줄을 실행하되, 그 줄의 함수 안으로 들어가지 않음
- 결과만 받아서 다음 줄로 이동

Step Into

현재 줄에서 호출한 함수의 "첫 줄"로 들어감
- 함수 내부 흐름을 한 줄씩 추적함

Operating System | Process

Sat, 27 Sep 2025 00:00:00 GMT

Chapter 3 프로세스 기술과 제어

3.1 프로세스란?

프로세스의 정의

수행중인 프로그램

컴퓨터 상에 수행 중인 프로그램의 인스턴스

처리기에 할당되어 수행될 수 있는 개체(entity)

명령들의 순차 수행, 현재 상태, 연계된 시스템 자원들의 집합

PCB(Process Control Block)

Running 중인 Process를 interrupt한 이후에, 다시 Running을 재개할 수 있도록 충분한 정보를 유지해야한다.

PCB 블록의 구성요소

identifier

status

priority

program counter

context data

I/O status information

accounting information

3.2 프로세스 상태

two-state 프로세스 모델

작업 큐를 구성하는 각 요소는 특정 프로세스의 PCB를 가리키는 pointer이다.
수행 중이 인터럽트를 당한 프로세스는 다시 큐로 옮겨진다.
- 만일 프로세스의 수행이 완료되었거나 도중에 취소된다면, 프로세스는 폐기된다. (Exit)

five-state 프로세스 모델

two-state 프로세스 모델에서는 실행 중인 프로세스에 인터럽트가 발생하면 Not Running 상태로 전환된다. 그런데 단일 큐(single queue)를 사용하는 경우, 디스패처가 어떤 프로세스를 우선 실행시킬지 판단하기가 까다로워진다.
- 이러한 상황을 보다 자연스럽게 처리하기 위해서는 Not Running 상태를 Ready와 Blocked 상태로 분할하는게 효과적이다.

suspended-state 프로세스 모델

3.3 프로세스 기술 (Process Description)

운영체제 제어구조

운영체제가 프로세스와 자원들을 관리하기 위해서는 상태를 나타내는 정보를 가지고 있어야한다.

각 개체에 대한 정보를 테이블로 구성하여 유지한다.

1. Memory tables

주기억 장치와 보조기억장치 모두의 track을 유지하기 위해 사용

주기억장치의 일부는 운영체제가 사용할 수 있도록 예약됨

예약되지 않은 나머지는 프로세스들이 사용할 수 있음

1. Memory tables이 가진 정보

프로세스에게 할당된 main memory
프로세스에게 할당된 secondary memory
- such as which processes may access certain shared memory regions
주기억장치 또는 가상메모리 블록들에 대한 보호속성
가상 메모리 관리를 위한 정보

2. I/O tables

입출력 장치와 컴퓨터 시스템의 채널들을 관리하기 위해 사용된다.

입출력 테이블은 chapter 11에서 다룰 예정

3. file tables

파일 존재 여부와 secondary memory에 저장된 파일의 위치, 현재 상태등에 대한 정보 저장용

chapter 12에서 다룰 예정

3.4 프로세스 제어

Operating System | Computer System Overview | Interrupt

Thu, 25 Sep 2025 00:00:00 GMT

Interrupt란?

Interrupt의 정의

CPU의 정상적인 흐름을 방해하는 동작을 말한다

→ 대부분의 I/O 디바이스는 CPU보다 느림

CPU는 디바이스가 작업을 완료 할 때까지 기다려야 함
Blocking I/O의 문제점

Interrupt의 분류

CPU는 디바이스의 작업 완료를 위해 기다릴 수 있음

→ 하지만 이는 처리기의 성능 저하 유발의 원인이 됨 → 이를 위해 디바이스가 작업이 완료되면 CPU에게 인터럽트를 걸 수 있도록 허용함

프로그램
- exception(응답없음) : 보통 프로세스 죽었을때
타이머
I/O (주된 인터럽트)
- 연산의 정상적인 종료
- 다양한 에러조건을 알려줌
하드웨어 실패

Interrupt의 단계

CPU가 인터럽트가 발생했는지 여부를 검사함
인터럽트가 발생한 경우
- 프로그램의 실행을 보류
- 인터럽트-처리 루틴 실행

Interrupt의 처리 루틴

특정 I/O 디바이스를 서비스하기 위한 프로그램

일반적으로 운영체제 시스템에 포함됨

인터럽트를 처리하기 위한 오버헤드 존재

입출력 연산이 완료되기를 기다리며 낭비하는 시간에 비해 상대적으로 짧음

프로세스의 나머지 상태 정보를 저장
인터럽트 처리
프로세스의 상태 정보 복구
이전 PSW와 PC를 복구

Interrupt의 종류

1. 순차적 인터럽트 처리

하나의 인터럽트가 처리 중에는 다른 인터럽트가 발생하더라도, 실행하지 않음

→ 상대적 우선순위 및 시간 긴급도를 고려하지 않음

2. 다중 인터럽트

인터럽트 간의 우선 순위를 지정함

CPU는 실행 가능한 하나 이상의 프로그램을 보유
프로그램이 실행되는 순서는 프로그램의 상대적인 우선 순위와 입출력 대기 여부에 따라 달라짐
인터럽트 처리 루틴이 실행을 마치면, 인터럽트가 발생한 당시에 수행 중이던 프로그램으로 돌아가지 않을 수 있음
- PC 복구 → 무조건 원래 프로그램 실행되는 게 아니라, 운영체제가 개입해서 다른 프로그램(프로세스을 실행할 수도 있음.
- 예시 ) 타이머 인터럽트, I/O 완료 인터럽트

Operating System | Computer System Overview

Thu, 25 Sep 2025 00:00:00 GMT

ch 1 학습목표

시스템의 기본 요소와 그 사이 관계 설명
프로세서에 의해 명령어가 수행되는 처리 단계를 설명
인터럽트의 개념 이해 및 프로세서가 인터럽트를 사용하는 이유를 설명
컴퓨터 메모리 계층 구조 나열 및 설명층 구조 나열
멀티프로세서의 기본 특성과 멀티코어의 구조에 대해 설명
스택 연산과 프로시저 호출 및 리턴 지원

1.1 컴퓨터 기본 구성 요소(HW)

처리기(CPU; Central Processing Unit)

컴퓨터의 두뇌: 데이터 연산, 논리 연산(ALU), 제어(control Unit)

레지스터 (register)

x86, ARM, PPC, Sparc, Alpha, MIPS, SH4, Xscale

주기억장치(main memory) | 휘발성(volatile)

메모리 셀: 메모리 내의 개별적인 저장 공간

데이터와 프로그램 저장 (실 메모리라고도 불림)

저장 장치(storage device) | 비휘발성(non-volatile)

디스크, CD-ROM, 플로피, Flash Memory(NOR, NAND 등)

입출력 장치

입력 장치: 키보드, 마우스, Key Pad, Touch Screen

출력 장치: 모니터, 프린터, LCD

통신 장치

모뎀(modem), 이더넷(Ethernet), IrDA, CDMA, Bluetooth

CPU의 비트 수가 커질수록 한 번에 전송 가능한 데이터의 양(버스 폭)이 커져 병렬 처리량이 많아진다

시스템 전체 성능은 CPU, 메모리, I/O 장치 중 가장 느린 구성 요소의 영향을 크게 받는다

CPU와 I/O 모듈은 시스템 버스를 통해 데이터를 교환하며, 필요에 따라 메모리 매핑 I/O나 DMA 방식이 활용된다

1.1.1 CPU 레지스터

메모리 주소 레지스터 (MAR)
1. 다음 번에 읽거나 쓸 주소를 명시
메모리 버퍼 레지스터 (MBR)
1. 메모리에 쓸 데이터, 수신된 데이터 포함
I/O 주소 레지스터(I/O AR)
I/O 버퍼 레지스터(I/O BR)

1.1.2 마이크로 프로세서

과거) 단일 칩에 하나의 프로세서를 직접 (CPU) → 하나의 칩에 코어라고 불리는 여러 개의 프로세서 포함

1.1.3 주요 처리기 레지스터 (Processor Registers)

CPU 내부에 있고, 프로그램 실행에 필요한 정보를 저장하는 레지스터이다.

크게 두 그룹으로 나눌 수 있다.

제어 및 상태 레지스터 (Control and status registers)
- 처리기의 작동을 제어하기 위해 사용
- 프로그램의 실행을 제어하기 위한 특권 모드의 운영체제 루틴에 의해 사용
종류
- Program Counter
  - 반입*할 명령어의 주소 포함
- Instruction Register
  - 최근에 반입된 명령어 포함
- Program Status Word (PSW)
  - interrupt enable / disable
  - supervisor / user mode
  - condition codes or flags
    - positive result, negative result, zero, overflow

1.1.4 명령어 실행 (instruction cycle)

처리기가 메모리로부터 명령어를 읽거나(fetch) 수행(execution)

fetch → execution → store → fetch (loop)

CPU는 Main Memory로부터 Instruction을 Fetch 한다.
Program Counter가 다음에 fetch할 명령어의 주소를 저장한다.
fetch이후, Program Counter의 증가

1.1.5 Instruction Register

Fetched instruction은 IR에 적재된다.

범주
- 처리기 ~ 메모리
  - CPU와 메모리간 데이터 전달
- CPU ~ I/O
  - 주변장치로 데이터 전달
- 데이터 처리
  - 데이터 산술 또는 논리연산
- 제어
  - 실행 순서의 변경

1.1.6 Instruction Register의 구조 (가상)

16bit라고 가정

통상적으로 왼쪽을 상위 비트, 오른쪽을 하위 비트라고 한다.

opcode(4bit) : 연산코드 → 연산자로 16개의 연산 가능

0001 = 메모리에 저장된 값을 AC*에 적재

- 0010 = AC에 저장된 값을 메모리에 저장
- 0101 = 메모리에 저장된 값을 AC에 더함

address (12bit): 2^12 -1 = 4096 -1

프로그램 실행 예시

1단계 (fetch)

PC에 저장된 값 = [300](다음에 실행할 명령어의 메모리주소 )

MAR ← PC : 300번지를 MAR에 적재

메모리[300] → MBR : 300번지 메모리에서 명령어 0x1940을 읽어 MBR에 저장

MBR → IR : 명령어 0x1940을 IR에 저장

PC++ : 다음 명령어(301번지)를 가리키도록 증가

2단계 (execution)

IR에 저장된 값 0x1940를 실행

상위비트 0001(2), 하위비트 0x940

[940] 메모리에 저장된 값을 AC에 적재

[0 0 0 3] AC

3단계 (fetch)

PC에 저장된 값 = 다음에 실행할 명령어의 메모리주소 [301]

0x5941을 IR에 적재

PC++

4단계 (execution)

상위비트 0101(2), 하위비트 0x941

[941] 메모리에 저장된 값을 AC에 누적

[0 0 0 3] + [0 0 0 2] = [0 0 0 5] AC

5단계 (fetch)

PC에 저장된 값 = 다음에 실행할 명령어의 메모리주소 [302]

0x2941을 IR에 적재

PC++

6단계 (execution)

상위비트 0010(2), 하위비트 0x941 [941] AC에 저장된 값을 메모리에 저장 941번지 >> [0 0 0 5]

미주

반입(fetch): CPU가 메모리에서 명령어를 읽어오는 과정

PC(Program Counter) 에 저장된 값 = “다음에 실행할 명령어의 메모리 주소”
이 주소가 MAR(Memory Address Register) 로 전달됨
해당 메모리에서 명령어를 읽어와서 MBR(Memory Buffer Register) 에 저장
그 명령어가 IR(Instruction Register) 로 옮겨짐 → 해석/실행

누산기(Accumulator)

산술 논리 연산의 중간 결과값을 임시로 저장하는 레지스터로, 계산 과정에서 데이터를 누적하고 처리하는 역할을 담당한다. CPU 내부에 위치하며 연산 속도를 높이기 위해 사용된다.