hi_soap.log

프렌즈 4블록

Sun, 28 Jun 2026 07:02:04 GMT

2026.06.28

문제 풀이

1차 실행 오류

63.6/100

블록을 내릴 때 구조가 잘못되었음

O O O O O
O O O O O
O O O O O
X X O O O
X X O O O
O O O O O
X X O O O
X X O O O
O O O O O

와 같은 상황에서 empty == 4일 때, [5][0] = [1][0] [1][0] = ' '이 되는 문제가 발생하게 됨

import java.util.List;
import java.util.ArrayList;

class Solution {
    public int solution(int m, int n, String[] board) {
        int answer = 0;
        List remove = new ArrayList<>(); // 제거 할 블록의 인덱스 저장
        boolean isFin = false; // 제거할 블록의 유/무 표시

        char blocks[][] = new char[m][n];
        for (int i = 0; i < m; i++) {
            for (int j = 0; j < n; j++) {
                blocks[i] = board[i].toCharArray();
            }
        }

        while(true) {
            if (isFin) {
                break;
            }
            for (int i = 0; i < m - 1; i++) {
                for (int j = 0; j < n - 1; j++) {
                    char b1 = blocks[i][j];
                    char b2 = blocks[i][j + 1];
                    char b3 = blocks[i + 1][j];
                    char b4 = blocks[i + 1][j + 1];

                    if (b1 == b2 && b2 == b3 && b3 == b4 && b1 != ' ') { // 2 x 2 블록이 모두 같을 때
                        remove.add(new int[]{i, j});
                        remove.add(new int[]{i, j + 1});
                        remove.add(new int[]{i + 1, j});
                        remove.add(new int[]{i + 1, j + 1});
                        // 해당하는 인덱스 모두 저장
                    }
                }
            }
            if (remove.isEmpty()) { // 더 이상 제거할 블록이 없을 때
                isFin = true;
            }
            for (int i = 0; i < remove.size(); i++) { // 블록에서 전체 제거
                if (blocks[remove.get(i)[0]][remove.get(i)[1]] == ' ') {
                    continue;
                }
                else {
                    blocks[remove.get(i)[0]][remove.get(i)[1]] = ' ';
                    answer++;
                }
            }
            remove.clear(); // remove 원소 전체 제거

            // 블록 내리기
            for (int i = 0; i < n; i++) {
                int empty = 0;
                for (int j = m - 1; j >= 0; j--) {
                    if (empty > 0 && blocks[j][i] != ' ') { 
                        blocks[j + empty][i] = blocks[j][i];
                        blocks[j][i] = ' ';
                    }
                    if (blocks[j][i] == ' ') { // 비어있는 공간 발견 시,
                        empty++;
                    }
                }
            }
        }
        return answer;
    }
}

2차 실행 오류

81.8/100

Deque를 사용해서 블록을 내리는 구조를 바꾸었음

if (q.size() > 0 && blocks[j][i] != ' ') {
    int p[] = q.poll();
    blocks[p[0]][p[1]] = blocks[j][i];
    blocks[j][i] = ' ';
}
if (blocks[j][i] == ' ') { // 비어있는 공간 발견 시,
    q.offer(new int[]{j, i});
}

에서 이미 아래의 조건문에 q.offer(new int[]{j, i})가 있으므로 중복됨

import java.util.List;
import java.util.ArrayList;
import java.util.Deque;
import java.util.ArrayDeque;

class Solution {
    public int solution(int m, int n, String[] board) {
        int answer = 0;
        List remove = new ArrayList<>(); // 제거 할 블록의 인덱스 저장
        boolean isFin = false; // 제거할 블록의 유/무 표시

        char blocks[][] = new char[m][n];
        for (int i = 0; i < m; i++) { // char 배열로 저장
            for (int j = 0; j < n; j++) {
                blocks[i] = board[i].toCharArray();
            }
        }

        while(true) {
            if (isFin) {
                break;
            }
            for (int i = 0; i < m - 1; i++) {
                for (int j = 0; j < n - 1; j++) {
                    char b1 = blocks[i][j];
                    char b2 = blocks[i][j + 1];
                    char b3 = blocks[i + 1][j];
                    char b4 = blocks[i + 1][j + 1];

                    if (b1 == b2 && b2 == b3 && b3 == b4 && b1 != ' ') { // 2 x 2 블록이 모두 같을 때
                        remove.add(new int[]{i, j});
                        remove.add(new int[]{i, j + 1});
                        remove.add(new int[]{i + 1, j});
                        remove.add(new int[]{i + 1, j + 1});
                        // 해당하는 인덱스 모두 저장
                    }
                }
            }
            if (remove.isEmpty()) { // 더 이상 제거할 블록이 없을 때
                isFin = true;
            }
            for (int i = 0; i < remove.size(); i++) { // 블록에서 전체 제거
                if (blocks[remove.get(i)[0]][remove.get(i)[1]] == ' ') {
                    continue;
                }
                else {
                    blocks[remove.get(i)[0]][remove.get(i)[1]] = ' ';
                    answer++;
                }
            }
            remove.clear(); // remove 원소 전체 제거

            // 블록 내리기
            Deque q = new ArrayDeque<>();
            for (int i = 0; i < n; i++) {
                q.clear();
                for (int j = m - 1; j >= 0; j--) {
                    if (q.size() > 0 && blocks[j][i] != ' ') {
                        int p[] = q.poll();
                        blocks[p[0]][p[1]] = blocks[j][i];
                        q.offer(new int[]{j, i});
                        blocks[j][i] = ' ';
                    }
                    if (blocks[j][i] == ' ') { // 비어있는 공간 발견 시,
                        q.offer(new int[]{j, i});
                    }
                }
            }
        }
        return answer;
    }
}

나의 코드

소요 시간: 1시간 18분

시간 복잡도: $O((m * n)²)$

import java.util.List;
import java.util.ArrayList;
import java.util.Deque;
import java.util.ArrayDeque;

class Solution {
    public int solution(int m, int n, String[] board) {
        int answer = 0;
        List remove = new ArrayList<>(); // 제거 할 블록의 인덱스 저장
        boolean isFin = false; // 제거할 블록의 유/무 표시

        char blocks[][] = new char[m][n];
        for (int i = 0; i < m; i++) { // char 배열로 저장
            for (int j = 0; j < n; j++) {
                blocks[i] = board[i].toCharArray();
            }
        }

        while(true) {
            if (isFin) {
                break;
            }
            for (int i = 0; i < m - 1; i++) {
                for (int j = 0; j < n - 1; j++) {
                    char b1 = blocks[i][j];
                    char b2 = blocks[i][j + 1];
                    char b3 = blocks[i + 1][j];
                    char b4 = blocks[i + 1][j + 1];

                    if (b1 == b2 && b2 == b3 && b3 == b4 && b1 != ' ') { // 2 x 2 블록이 모두 같을 때
                        remove.add(new int[]{i, j});
                        remove.add(new int[]{i, j + 1});
                        remove.add(new int[]{i + 1, j});
                        remove.add(new int[]{i + 1, j + 1});
                        // 해당하는 인덱스 모두 저장
                    }
                }
            }
            if (remove.isEmpty()) { // 더 이상 제거할 블록이 없을 때
                isFin = true;
            }
            for (int i = 0; i < remove.size(); i++) { // 블록에서 전체 제거
                if (blocks[remove.get(i)[0]][remove.get(i)[1]] == ' ') {
                    continue;
                }
                else {
                    blocks[remove.get(i)[0]][remove.get(i)[1]] = ' ';
                    answer++;
                }
            }
            remove.clear(); // remove 원소 전체 제거

            // 블록 내리기
            Deque q = new ArrayDeque<>();
            for (int i = 0; i < n; i++) {
                q.clear();
                for (int j = m - 1; j >= 0; j--) {
                    if (q.size() > 0 && blocks[j][i] != ' ') {
                        int p[] = q.poll();
                        blocks[p[0]][p[1]] = blocks[j][i];
                        blocks[j][i] = ' ';
                    }
                    if (blocks[j][i] == ' ') { // 비어있는 공간 발견 시,
                        q.offer(new int[]{j, i});
                    }
                }
            }
        }
        return answer;
    }
}

AI 코드

시간 복잡도: $O((m * n)²)$

List를 사용하는 대신 boolean을 사용하여 시간 복잡도는 동일하지만, List의 오버헤드를 제거함

import java.util.ArrayDeque;
import java.util.Deque;

class Solution {
    public int solution(int m, int n, String[] board) {
        int answer = 0;
        char[][] blocks = new char[m][n];
        for (int i = 0; i < m; i++) {
            blocks[i] = board[i].toCharArray();
        }

        while (true) {
            boolean[][] removed = new boolean[m][n];
            boolean found = false;

            for (int i = 0; i < m - 1; i++) {
                for (int j = 0; j < n - 1; j++) {
                    char b = blocks[i][j];
                    if (b != ' ' && b == blocks[i][j+1] && b == blocks[i+1][j] && b == blocks[i+1][j+1]) {
                        removed[i][j] = removed[i][j+1] = true;
                        removed[i+1][j] = removed[i+1][j+1] = true;
                        found = true;
                    }
                }
            }

            if (!found) break;

            for (int i = 0; i < m; i++) {
                for (int j = 0; j < n; j++) {
                    if (removed[i][j]) {
                        blocks[i][j] = ' ';
                        answer++;
                    }
                }
            }

            Deque q = new ArrayDeque<>();
            for (int i = 0; i < n; i++) {
                q.clear();
                for (int j = m - 1; j >= 0; j--) {
                    if (q.size() > 0 && blocks[j][i] != ' ') {
                        int[] p = q.poll();
                        blocks[p[0]][p[1]] = blocks[j][i];
                        blocks[j][i] = ' ';
                    }
                    if (blocks[j][i] == ' ') q.offer(new int[]{j, i});
                }
            }
        }

        return answer;
    }
}

오픈채팅방

Sat, 27 Jun 2026 06:24:31 GMT

2026.06.27

문제 풀이

나의 코드

소요 시간: 34분

시간 복잡도: $O(n)$

map은 uid와 실제 이름을 저장하고, access는 Enter, Leave, Change등의 상태 정보와 uid를 저장하였음.

access의 상태 정보와 map에 저장된 실제 이름을 uid를 통해 매핑하여 문제를 해결함

import java.util.Map;
import java.util.HashMap;
import java.util.List;
import java.util.ArrayList;

class Solution {
    public String[] solution(String[] record) {
        int len = record.length;
        Map map = new HashMap<>(); // uid와 이름 저장
        List access = new ArrayList<>(); // 출입 여부와 uid 저장

        for (int i = 0; i < len; i++) {
            String info[] = record[i].split(" ");

            if (!info[0].equals("Leave")) {
                map.put(info[1], info[2]); // uid와 이름 저장
            }
            access.add(new String[]{info[0], info[1]});
        }
        List result = new ArrayList<>();

        for (int i = 0; i < access.size(); i++) {
            if (access.get(i)[0].equals("Change")) {
                continue;
            }

            String name = map.get(access.get(i)[1]); // uid로 이름 찾기

            if (access.get(i)[0].equals("Enter")) {
                result.add(name + "님이 들어왔습니다.");
            }
            else {
                result.add(name + "님이 나갔습니다.");
            }
        }

        return result.toArray(new String[0]);
    }
}

AI 코드

시간 복잡도: $O(n)$

record만 2번 순회하는 방식을 사용하여 access리스트 없이 해결함

import java.util.Map;
import java.util.HashMap;
import java.util.ArrayList;
import java.util.List;

class Solution {
    public String[] solution(String[] record) {
        Map map = new HashMap<>();
        List result = new ArrayList<>();

        for (String r : record) {
            String[] info = r.split(" ");
            if (!info[0].equals("Leave")) {
                map.put(info[1], info[2]);
            }
        }

        for (String r : record) {
            String[] info = r.split(" ");
            if (info[0].equals("Enter")) {
                result.add(map.get(info[1]) + "님이 들어왔습니다.");
            } else if (info[0].equals("Leave")) {
                result.add(map.get(info[1]) + "님이 나갔습니다.");
            }
        }

        return result.toArray(new String[0]);
    }
}

파일명 정렬

Fri, 26 Jun 2026 06:52:31 GMT

2026.06.26

문제 설명

파일명 정렬 세 차례의 코딩 테스트와 두 차례의 면접이라는 기나긴 블라인드 공채를 무사히 통과해 카카오에 입사한 무지는 파일 저장소 서버 관리를 맡게 되었다.

저장소 서버에는 프로그램의 과거 버전을 모두 담고 있어, 이름 순으로 정렬된 파일 목록은 보기가 불편했다. 파일을 이름 순으로 정렬하면 나중에 만들어진 ver-10.zip이 ver-9.zip보다 먼저 표시되기 때문이다.

버전 번호 외에도 숫자가 포함된 파일 목록은 여러 면에서 관리하기 불편했다. 예컨대 파일 목록이 ["img12.png", "img10.png", "img2.png", "img1.png"]일 경우, 일반적인 정렬은 ["img1.png", "img10.png", "img12.png", "img2.png"] 순이 되지만, 숫자 순으로 정렬된 ["img1.png", "img2.png", "img10.png", img12.png"] 순이 훨씬 자연스럽다.

무지는 단순한 문자 코드 순이 아닌, 파일명에 포함된 숫자를 반영한 정렬 기능을 저장소 관리 프로그램에 구현하기로 했다.

소스 파일 저장소에 저장된 파일명은 100 글자 이내로, 영문 대소문자, 숫자, 공백(" "), 마침표("."), 빼기 부호("-")만으로 이루어져 있다. 파일명은 영문자로 시작하며, 숫자를 하나 이상 포함하고 있다.

파일명은 크게 HEAD, NUMBER, TAIL의 세 부분으로 구성된다.

HEAD는 숫자가 아닌 문자로 이루어져 있으며, 최소한 한 글자 이상이다.
NUMBER는 한 글자에서 최대 다섯 글자 사이의 연속된 숫자로 이루어져 있으며, 앞쪽에 0이 올 수 있다. 0부터 99999 사이의 숫자로, 00000이나 0101 등도 가능하다.
TAIL은 그 나머지 부분으로, 여기에는 숫자가 다시 나타날 수도 있으며, 아무 글자도 없을 수 있다.

파일명을 세 부분으로 나눈 후, 다음 기준에 따라 파일명을 정렬한다.

파일명은 우선 HEAD 부분을 기준으로 사전 순으로 정렬한다. 이때, 문자열 비교 시 대소문자 구분을 하지 않는다. MUZI와 muzi, MuZi는 정렬 시에 같은 순서로 취급된다.
파일명의 HEAD 부분이 대소문자 차이 외에는 같을 경우, NUMBER의 숫자 순으로 정렬한다. 9 < 10 < 0011 < 012 < 13 < 014 순으로 정렬된다. 숫자 앞의 0은 무시되며, 012와 12는 정렬 시에 같은 같은 값으로 처리된다.
두 파일의 HEAD 부분과, NUMBER의 숫자도 같을 경우, 원래 입력에 주어진 순서를 유지한다. MUZI01.zip과 muzi1.png가 입력으로 들어오면, 정렬 후에도 입력 시 주어진 두 파일의 순서가 바뀌어서는 안 된다.

무지를 도와 파일명 정렬 프로그램을 구현하라.

입력 형식

입력으로 배열 files가 주어진다.

files는 1000 개 이하의 파일명을 포함하는 문자열 배열이다.
각 파일명은 100 글자 이하 길이로, 영문 대소문자, 숫자, 공백(" "), 마침표("."), 빼기 부호("-")만으로 이루어져 있다. 파일명은 영문자로 시작하며, 숫자를 하나 이상 포함하고 있다.
중복된 파일명은 없으나, 대소문자나 숫자 앞부분의 0 차이가 있는 경우는 함께 주어질 수 있다. (muzi1.txt, MUZI1.txt, muzi001.txt, muzi1.TXT는 함께 입력으로 주어질 수 있다.)

입출력 예

입력: ["img12.png", "img10.png", "img02.png", "img1.png", "IMG01.GIF", "img2.JPG"]

출력: ["img1.png", "IMG01.GIF", "img02.png", "img2.JPG", "img10.png", "img12.png"]

문제 풀이

30/100

먼 인덱스의 데이터와 비교하는 방식을 사용하여 정렬 안정성이 깨지는 오류가 발생함

1차 실행 오류

class Solution {
    public String[] solution(String[] files) {
        int len = files.length;
        String[][] file = new String[len][2];

        for (int i = 0; i < len; i++) { // 각 파일의 head와 number를 나누어서 저장
            StringBuilder head = new StringBuilder();
            StringBuilder number = new StringBuilder();
            boolean isNum = false;

            for (int j = 0; j < files[i].length(); j++) {
                char c = files[i].charAt(j);
                if (Character.isDigit(c)) { // 문자가 숫자일 때
                    isNum = true;
                }
                if (!isNum) {
                    head.append(Character.toUpperCase(c));
                    // 대소문자 구분하지 않으므로, 대문자로 통일하여 저장
                }
                else if (isNum) {
                    if (!Character.isDigit(c)) {
                        break;
                    }
                    number.append(c);
                }
            }
            file[i][0] = head.toString();
            file[i][1] = number.toString();
        }

        for (int i = 0; i < len; i++) {
            for (int j = i + 1; j < len; j++) {
                int n = file[i][0].compareTo(file[j][0]);
                if (n > 0) { // file[i][1] > file[j][1]일 때
                    String headTmp = file[i][0];
                    file[i][0] = file[j][0];
                    file[j][0] = headTmp;
                    String numberTmp = file[i][1];
                    file[i][1] = file[j][1];
                    file[j][1] = numberTmp;

                    String temp = files[i];
                    files[i] = files[j];
                    files[j] = temp;
                }
                else if (n == 0) { // 두 문자열이 같을 때
                    int number1 = Integer.parseInt(file[i][1]);
                    int number2 = Integer.parseInt(file[j][1]);

                    if (number1 > number2) {
                        String headTmp = file[i][0];
                        file[i][0] = file[j][0];
                        file[j][0] = headTmp;
                        String numberTmp = file[i][1];
                        file[i][1] = file[j][1];
                        file[j][1] = numberTmp;

                        String temp = files[i];
                        files[i] = files[j];
                        files[j] = temp;
                    }
                }
            }
        }

        return files;
    }
}

나의 코드

소요 시간: 1시간 14분

시간 복잡도: $O(n^2)$

AI를 활용하여 실패 원인을 분석하였고, 인접한 데이터끼리 비교하는 방식으로 코드를 직접 짜서 정렬 안정성을 확보함

class Solution {
    public String[] solution(String[] files) {
        int len = files.length;
        String[][] file = new String[len][2];

        for (int i = 0; i < len; i++) { // 각 파일의 head와 number를 나누어서 저장
            StringBuilder head = new StringBuilder();
            StringBuilder number = new StringBuilder();
            boolean isNum = false;

            for (int j = 0; j < files[i].length(); j++) {
                char c = files[i].charAt(j);
                if (Character.isDigit(c)) { // 문자가 숫자일 때
                    isNum = true;
                }
                if (!isNum) {
                    head.append(Character.toUpperCase(c));
                    // 대소문자 구분하지 않으므로, 대문자로 통일하여 저장
                }
                else if (isNum) {
                    if (!Character.isDigit(c)) {
                        break;
                    }
                    number.append(c);
                }
            }
            file[i][0] = head.toString();
            file[i][1] = number.toString();
        }

        for (int i = 0; i < len; i++) {
            for (int j = 0; j < len - 1; j++) {
                int n = file[j][0].compareTo(file[j + 1][0]);
                if (n > 0) { // file[i][1] > file[j][1]일 때
                    String headTmp = file[j][0];
                    file[j][0] = file[j + 1][0];
                    file[j + 1][0] = headTmp;

                    String numberTmp = file[j][1];
                    file[j][1] = file[j + 1][1];
                    file[j + 1][1] = numberTmp;

                    String temp = files[j];
                    files[j] = files[j + 1];
                    files[j + 1] = temp;
                }
                else if (n == 0) { // 두 문자열이 같을 때
                    int number1 = Integer.parseInt(file[j][1]);
                    int number2 = Integer.parseInt(file[j + 1][1]);

                    if (number1 > number2) {
                        String headTmp = file[j][0];
                        file[j][0] = file[j + 1][0];
                        file[j + 1][0] = headTmp;
                        String numberTmp = file[j][1];
                        file[j][1] = file[j + 1][1];
                        file[j + 1][1] = numberTmp;

                        String temp = files[j];
                        files[j] = files[j + 1];
                        files[j + 1] = temp;
                    }
                }
            }
        }

        return files;
    }
}

AI 코드

시간 복잡도: $O(n log n)$

나의 코드와 많은 차이가 나는 것을 보며 인덱스의 활용이나, 라이브러리 함수의 활용을 잘 해야겠다는 생각이 들었음

import java.util.Arrays;

class Solution {
    public String[] solution(String[] files) {
        return Arrays.stream(files)
            .sorted((a, b) -> {
                String[] pa = parse(a);
                String[] pb = parse(b);
                int cmp = pa[0].compareTo(pb[0]);
                if (cmp != 0) return cmp;
                return Integer.compare(Integer.parseInt(pa[1]),
                                       Integer.parseInt(pb[1]));
            })
            .toArray(String[]::new);
    }

    private String[] parse(String file) {
        int i = 0;
        while (i < file.length() && !Character.isDigit(file.charAt(i))) i++;
        int j = i;
        while (j < file.length() && Character.isDigit(file.charAt(j))) j++;

        String head = file.substring(0, i).toUpperCase();
        String number = file.substring(i, j);
        return new String[]{head, number};
    }
}

2 x n 타일링

Wed, 24 Jun 2026 04:38:35 GMT

2026.06.24

문제 설명

가로 길이가 2이고 세로의 길이가 1인 직사각형모양의 타일이 있습니다. 이 직사각형 타일을 이용하여 세로의 길이가 2이고 가로의 길이가 n인 바닥을 가득 채우려고 합니다. 타일을 채울 때는 다음과 같이 2가지 방법이 있습니다.

타일을 가로로 배치 하는 경우
타일을 세로로 배치 하는 경우

예를 들어서 n이 7인 직사각형은 다음과 같이 채울 수 있습니다.

직사각형의 가로의 길이 n이 매개변수로 주어질 때, 이 직사각형을 채우는 방법의 수를 return 하는 solution 함수를 완성해주세요.

제한사항

가로의 길이 n은 60,000이하의 자연수 입니다.
경우의 수가 많아 질 수 있으므로, 경우의 수를 1,000,000,007으로 나눈 나머지를 return해주세요.

입출력 예

문제 풀이

시간 초과 오류 발생

1차 실행 오류

class Solution {
    public int fibo(int n) {
        if (n <= 2) {
            return n;
        }
        return fibo(n - 2) + fibo(n - 1);
    }
    public int solution(int n) {
        return fibo(n) % 1000000007;
    }
}

나의 코드 & AI 코드

소요 시간: 1시간

시간 복잡도: $O(n)$

수학적 규칙을 찾아보던 중, 피보나치 수열과 같은 규칙을 가지고 있다는 것을 알아냄 n == 1일 때, 1 n == 2일 때, 2 n == 3일 때, 3 n == 4일 때, 5 n == 5일 때, 8 n == 6일 때, 13 n == 7일 때, 21 n == 8일 때 34 ...

다만 재귀로 구현하여 시간 초과 오류가 발생하였고, AI를 통해 DP(Dynamic Programming), 이미 계산한 결과를 저장해서 재사용 하는 방식 를 사용하여 해결함

class Solution {
    public int solution(int n) {
        if (n <= 2) {
            return n;
        }
        int fibo[] = new int[n + 1];
        fibo[1] = 1;
        fibo[2] = 2;
        for (int i = 3; i <= n; i++) {
            fibo[i] = (fibo[i - 2] + fibo[i - 1]) % 1000000007;
        }

        return fibo[n];
    }
}

주차 요금

Tue, 23 Jun 2026 04:58:35 GMT

2026.06.23

문제 설명

주차장의 요금표와 차량이 들어오고(입차) 나간(출차) 기록이 주어졌을 때, 차량별로 주차 요금을 계산하려고 합니다. 아래는 하나의 예시를 나타냅니다.

요금표
입/출차 기록
자동차별 주차 요금
어떤 차량이 입차된 후에 출차된 내역이 없다면, 23:59에 출차된 것으로 간주합니다.
- 0000번 차량은 18:59에 입차된 이후, 출차된 내역이 없습니다. 따라서, 23:59에 출차된 것으로 간주합니다.
00:00부터 23:59까지의 입/출차 내역을 바탕으로 차량별 누적 주차 시간을 계산하여 요금을 일괄로 정산합니다.
누적 주차 시간이 기본 시간이하라면, 기본 요금을 청구합니다.
누적 주차 시간이 기본 시간을 초과하면, 기본 요금에 더해서, 초과한 시간에 대해서 단위 시간 마다 단위 요금을 청구합니다.
- 초과한 시간이 단위 시간으로 나누어 떨어지지 않으면, 올림합니다.
- ⌈a⌉ : a보다 작지 않은 최소의 정수를 의미합니다. 즉, 올림을 의미합니다.

주차 요금을 나타내는 정수 배열 fees, 자동차의 입/출차 내역을 나타내는 문자열 배열 records가 매개변수로 주어집니다. 차량 번호가 작은 자동차부터 청구할 주차 요금을 차례대로 정수 배열에 담아서 return 하도록 solution 함수를 완성해주세요.

제한 사항

fees의 길이 = 4
- fees[0] = 기본 시간(분)
- 1 ≤ fees[0] ≤ 1,439
- fees[1] = 기본 요금(원)
- 0 ≤ fees[1] ≤ 100,000
- fees[2] = 단위 시간(분)
- 1 ≤ fees[2] ≤ 1,439
- fees[3] = 단위 요금(원)
- 1 ≤ fees[3] ≤ 10,000
1 ≤ records의 길이 ≤ 1,000
- records의 각 원소는 "시각 차량번호 내역" 형식의 문자열입니다.
- 시각, 차량번호, 내역은 하나의 공백으로 구분되어 있습니다.
- 시각은 차량이 입차되거나 출차된 시각을 나타내며, HH:MM 형식의 길이 5인 문자열입니다.
- - HH:MM은 00:00부터 23:59까지 주어집니다.
- - 잘못된 시각("25:22", "09:65" 등)은 입력으로 주어지지 않습니다.
- 차량번호는 자동차를 구분하기 위한, `0'~'9'로 구성된 길이 4인 문자열입니다.
- 내역은 길이 2 또는 3인 문자열로, IN 또는 OUT입니다. IN은 입차를, OUT은 출차를 의미합니다.
- records의 원소들은 시각을 기준으로 오름차순으로 정렬되어 주어집니다.
- records는 하루 동안의 입/출차된 기록만 담고 있으며, 입차된 차량이 다음날 출차되는 경우는 입력으로 주어지지 않습니다.
- 같은 시각에, 같은 차량번호의 내역이 2번 이상 나타내지 않습니다.
- 마지막 시각(23:59)에 입차되는 경우는 입력으로 주어지지 않습니다.
- 아래의 예를 포함하여, 잘못된 입력은 주어지지 않습니다.
- - 주차장에 없는 차량이 출차되는 경우
- - 차장에 이미 있는 차량(차량번호가 같은 차량)이 다시 입차되는 경우

입출력 예

문제 풀이

1차 실행 오류

if (!tempMap.isEmpty()) { // 주차장이 비어 있지 않을 때
    for (String key : tempMap.keySet()) { // 남은 차량 시간 정리
        int time = 1439 - tempMap.get(key);
        resultMap.put(key, time + resultMap.get(key));
    }
}

현재 주차장에 있는 차량이 한 번도 나간 기록이 없을 때, resultMap.get(key) 값은 null이 되는 경우를 고려하지 않음

import java.util.Map;
import java.util.HashMap;

class Solution {
    public int[] solution(int[] fees, String[] records) {
        Map tempMap = new HashMap<>(); // 현재 주차장에 남아 있는 차량
        Map resultMap = new HashMap<>(); // 차량이 사용한 총 시간

        int defaultTime = fees[0];
        int baseFee = fees[1];
        int unitTime = fees[2];
        int unitFee = fees[3];

        for (int i = 0; i < records.length; i++) {
            String[] record = records[i].split(" "); // 시간, 차량번호, 출입 내역 나누기
            String[] parts = record[0].split(":"); // 시간과 분으로 나누기
            int time = Integer.parseInt(parts[0]) * 60 + Integer.parseInt(parts[1]); // 시간과 분을 분으로 변환

            if (record[2].equals("IN")) { // 차량이 들어갈 때
                tempMap.put(record[1], time); // 차량번호와 들어간 시간 저장
            }
            else { // 차량이 나올 때
                int timeIn = tempMap.get(record[1]); // 차량이 들어간 시간
                if (resultMap.get(record[1]) != null) { // 출입 기록이 이미 있는 차량일 때
                    int timeRemain = resultMap.get(record[1]); // 남아 있던 시간 저장
                    resultMap.put(record[1], time - timeIn + timeRemain); // 원래 남아 있던 시간 + 사용한 시간
                }
                else {
                    resultMap.put(record[1], time - timeIn); // 차량이 사용한 시간 저장
                }
                tempMap.remove(record[1]); // 주차장에 주차 되어 있던 차량 빼기
            }
        }
        if (!tempMap.isEmpty()) { // 주차장이 비어 있지 않을 때
            for (String key : tempMap.keySet()) { // 남은 차량 시간 정리
                int time = 1439 - tempMap.get(key);
                resultMap.put(key, time + resultMap.get(key));
            }
        }

        int[] answer = new int[resultMap.size()];
        int index = 0;
        for (String key : resultMap.keySet()) {
            int time = resultMap.get(key);
            if (time < defaultTime) { // 사용 시간이 기본 시간보다 적을 때
                answer[index++] = baseFee;
            }
            else {
                if ((time - defaultTime) % unitTime != 0) {
                    answer[index++] = baseFee + (((time - defaultTime) / unitTime) + 1) * unitFee;
                }
                else {
                    answer[index++] = baseFee + ((time - defaultTime) / unitTime) * unitFee;    
                }
            }
        }
        return answer;
    }
}

2차 실행 오류

차량 번호 순서대로 오름차순 정렬하여 출력해야 함

import java.util.Map;
import java.util.HashMap;

class Solution {
    public int[] solution(int[] fees, String[] records) {
        Map tempMap = new HashMap<>(); // 현재 주차장에 남아 있는 차량
        Map resultMap = new HashMap<>(); // 차량이 사용한 총 시간

        int defaultTime = fees[0];
        int baseFee = fees[1];
        int unitTime = fees[2];
        int unitFee = fees[3];

        for (int i = 0; i < records.length; i++) {
            String[] record = records[i].split(" "); // 시간, 차량번호, 출입 내역 나누기
            String[] parts = record[0].split(":"); // 시간과 분으로 나누기
            int time = Integer.parseInt(parts[0]) * 60 + Integer.parseInt(parts[1]); // 시간과 분을 분으로 변환

            if (record[2].equals("IN")) { // 차량이 들어갈 때
                tempMap.put(record[1], time); // 차량번호와 들어간 시간 저장
            }
            else { // 차량이 나올 때
                int timeIn = tempMap.get(record[1]); // 차량이 들어간 시간
                if (resultMap.get(record[1]) != null) { // 출입 기록이 이미 있는 차량일 때
                    int timeRemain = resultMap.get(record[1]); // 남아 있던 시간 저장
                    resultMap.put(record[1], time - timeIn + timeRemain); // 원래 남아 있던 시간 + 사용한 시간
                }
                else {
                    resultMap.put(record[1], time - timeIn); // 차량이 사용한 시간 저장
                }
                tempMap.remove(record[1]); // 주차장에 주차 되어 있던 차량 빼기
            }
        }
        if (!tempMap.isEmpty()) { // 주차장이 비어 있지 않을 때
            for (String key : tempMap.keySet()) { // 남은 차량 시간 정리
                int time = 1439 - tempMap.get(key);
                if (resultMap.get(key) != null) {
                    resultMap.put(key, time + resultMap.get(key));
                }
                else {
                    resultMap.put(key, time);
                }
            }
        }

        int[] answer = new int[resultMap.size()];
        int index = 0;
        for (String key : resultMap.keySet()) {
            int time = resultMap.get(key);
            if (time < defaultTime) { // 사용 시간이 기본 시간보다 적을 때
                answer[index++] = baseFee;
            }
            else {
                if ((time - defaultTime) % unitTime != 0) {
                    answer[index++] = baseFee + (((time - defaultTime) / unitTime) + 1) * unitFee;
                }
                else {
                    answer[index++] = baseFee + ((time - defaultTime) / unitTime) * unitFee;    
                }
            }
        }
        return answer;
    }
}

나의 코드

소요 시간: 58분

시간 복잡도: $O(n)$

HashMap과 key 값을 기준으로 오름차순 정렬하는 TreeMap을 사용하여 해결 코드를 작성하기 전 코드 설계부터 하니 이전과 비교했을 때, 확실히 오류가 적어졌음.

다만 여전히 설계를 처음부터 끝까지 꼼꼼히 하는 습관과 문제를 꼼꼼히 읽는 습관이 필요함

import java.util.Map;
import java.util.HashMap;
import java.util.TreeMap;

class Solution {
    public int[] solution(int[] fees, String[] records) {
        Map tempMap = new HashMap<>(); // 현재 주차장에 남아 있는 차량
        Map resultMap = new TreeMap<>(); // 차량이 사용한 총 시간

        int defaultTime = fees[0];
        int baseFee = fees[1];
        int unitTime = fees[2];
        int unitFee = fees[3];

        for (int i = 0; i < records.length; i++) {
            String[] record = records[i].split(" "); // 시간, 차량번호, 출입 내역 나누기
            String[] parts = record[0].split(":"); // 시간과 분으로 나누기
            int time = Integer.parseInt(parts[0]) * 60 + Integer.parseInt(parts[1]); // 시간과 분을 분으로 변환

            if (record[2].equals("IN")) { // 차량이 들어갈 때
                tempMap.put(record[1], time); // 차량번호와 들어간 시간 저장
            }
            else { // 차량이 나올 때
                int timeIn = tempMap.get(record[1]); // 차량이 들어간 시간
                if (resultMap.get(record[1]) != null) { // 출입 기록이 이미 있는 차량일 때
                    int timeRemain = resultMap.get(record[1]); // 남아 있던 시간 저장
                    resultMap.put(record[1], time - timeIn + timeRemain); // 원래 남아 있던 시간 + 사용한 시간
                }
                else {
                    resultMap.put(record[1], time - timeIn); // 차량이 사용한 시간 저장
                }
                tempMap.remove(record[1]); // 주차장에 주차 되어 있던 차량 빼기
            }
        }
        if (!tempMap.isEmpty()) { // 주차장이 비어 있지 않을 때
            for (String key : tempMap.keySet()) { // 남은 차량 시간 정리
                int time = 1439 - tempMap.get(key);
                if (resultMap.get(key) != null) {
                    resultMap.put(key, time + resultMap.get(key));
                }
                else {
                    resultMap.put(key, time);
                }
            }
        }

        int[] answer = new int[resultMap.size()];
        int index = 0;
        for (String key : resultMap.keySet()) {
            int time = resultMap.get(key);
            if (time < defaultTime) { // 사용 시간이 기본 시간보다 적을 때
                answer[index++] = baseFee;
            }
            else {
                if ((time - defaultTime) % unitTime != 0) {
                    answer[index++] = baseFee + (((time - defaultTime) / unitTime) + 1) * unitFee;
                }
                else {
                    answer[index++] = baseFee + ((time - defaultTime) / unitTime) * unitFee;    
                }
            }
        }
        return answer;
    }
}

AI 코드

시간 복잡도: $O(n)$

기존 if/else 문으로 null 값을 파악하던 방법과 달리, getOrDefault()를 이용하여 한 줄로 해결

import java.util.HashMap;
import java.util.Map;
import java.util.TreeMap;

class Solution {
    public int[] solution(int[] fees, String[] records) {
        Map tempMap = new HashMap<>();
        Map resultMap = new TreeMap<>();

        for (String record : records) {
            String[] parts = record.split(" ");
            String[] timeParts = parts[0].split(":");
            int time = Integer.parseInt(timeParts[0]) * 60 + Integer.parseInt(timeParts[1]);
            String carNum = parts[1];

            if (parts[2].equals("IN")) {
                tempMap.put(carNum, time);
            } else {
                resultMap.put(carNum, resultMap.getOrDefault(carNum, 0) + time - tempMap.remove(carNum));
            }
        }

        for (String key : tempMap.keySet()) {
            resultMap.put(key, resultMap.getOrDefault(key, 0) + 1439 - tempMap.get(key));
        }

        int[] answer = new int[resultMap.size()];
        int idx = 0;
        for (int time : resultMap.values()) {
            int fee = fees[1];
            if (time > fees[0]) {
                fee += (int) Math.ceil((double)(time - fees[0]) / fees[2]) * fees[3];
            }
            answer[idx++] = fee;
        }

        return answer;
    }
}

스킬트리

Mon, 22 Jun 2026 06:55:29 GMT

2026.06.22

문제 설명

선행 스킬이란 어떤 스킬을 배우기 전에 먼저 배워야 하는 스킬을 뜻합니다.

예를 들어 선행 스킬 순서가 스파크 → 라이트닝 볼트 → 썬더일때, 썬더를 배우려면 먼저 라이트닝 볼트를 배워야 하고, 라이트닝 볼트를 배우려면 먼저 스파크를 배워야 합니다.

위 순서에 없는 다른 스킬(힐링 등)은 순서에 상관없이 배울 수 있습니다. 따라서 스파크 → 힐링 → 라이트닝 볼트 → 썬더와 같은 스킬트리는 가능하지만, 썬더 → 스파크나 라이트닝 볼트 → 스파크 → 힐링 → 썬더와 같은 스킬트리는 불가능합니다.

선행 스킬 순서 skill과 유저들이 만든 스킬트리1를 담은 배열 skill_trees가 매개변수로 주어질 때, 가능한 스킬트리 개수를 return 하는 solution 함수를 작성해주세요.

제한 조건

스킬은 알파벳 대문자로 표기하며, 모든 문자열은 알파벳 대문자로만 이루어져 있습니다.
스킬 순서와 스킬트리는 문자열로 표기합니다.
- 예를 들어, C → B → D 라면 "CBD"로 표기합니다
선행 스킬 순서 skill의 길이는 1 이상 26 이하이며, 스킬은 중복해 주어지지 않습니다.
skill_trees는 길이 1 이상 20 이하인 배열입니다.
skill_trees의 원소는 스킬을 나타내는 문자열입니다.
- skill_trees의 원소는 길이가 2 이상 26 이하인 문자열이며, 스킬이 중복해 주어지지 않습니다.

입출력 예

문제 풀이

나의 코드

소요 시간: 29분

시간 복잡도: $O(n)$

HashSet을 이용하여 해당 스킬이 순서가 필요한 스킬인지 판별

판별 후 현재 찍을 수 있는 상태인지 다시 판별하고 가능하면 넘어가고, 불가능하다면 반복문 중지

import java.util.Set;
import java.util.HashSet;

class Solution {
    public int solution(String skill, String[] skill_trees) {
        int count = 0;
        Set set = new HashSet<>();
        char skill_order[] = new char[skill.length()];

        for (int i = 0; i < skill.length(); i++) {
            set.add(skill.charAt(i));
        }

        for (int i = 0; i < skill_trees.length; i++) {
            int index = 0;
            boolean isPossible = true;
            for (int j = 0; j < skill_trees[i].length(); j++) {
                char c = skill_trees[i].charAt(j);
                if (set.contains(c)) { // 스킬 트리에 존재하는 스킬인 경우
                    if (skill.charAt(index) == c) { // 현재 배우는 것이 가능할 때
                        index++;
                    }
                    else { // 현재 배우는 것이 불가능할 
                        isPossible = false;
                        break;
                    }
                }
            }
            if (isPossible) {
                count++;
            }
        }
        return count;
    }
}

AI 코드

시간 복잡도: $O(n)$

HashSet을 사용하지 않고,

해당 값이 존재한다면 해당 인덱스를, 존재하지 않는다면 -1을 리턴하는 문자열에서 특정 문자의 인덱스를 반환하는 메서드인 indexOf()를 사용함

class Solution {
    public int solution(String skill, String[] skill_trees) {
        int count = 0;

        for (String tree : skill_trees) {
            int index = 0;
            boolean isPossible = true;
            for (char c : tree.toCharArray()) {
                if (skill.indexOf(c) != -1) {
                    if (skill.charAt(index) == c) {
                        index++;
                    } else {
                        isPossible = false;
                        break;
                    }
                }
            }
            if (isPossible) count++;
        }
        return count;
    }
}

교내 공학 경진대회

Mon, 22 Jun 2026 06:14:05 GMT

2026.06.22

문제 정의

1. 실내 길찾기 서비스

wi-fi 핑거프린팅 활용
local LLM을 활용한 부가 기능 개발
장애인을 위한 추가적인 계단 회피 경로

2. 코골이 베개

라즈베리 파이 센서 활용

인터넷연결

Fri, 12 Jun 2026 04:16:31 GMT

학습 목표

인터넷 연결에 필요한 권한을 이해하고 사용할 수 있다.
네트워크 연결 상태를 확인하는 방법을 이해하고 구현할 수 있다.
자바 API를 사용하여 네트워크 프로그래밍을 할 수 있다.
Retrofit을 사용하여 프로그래밍할 수 있다.
DownloadManager를 이용하여 파일 다운로드를 만들 수 있다.

네트워크 프로그래밍 용어 확인

UDP, TCP, HTTP, HTTPS
IP주소, 포트(port) 번호
서버, 클라이언트
소켓 프로그래밍
Listen, accept, connect*

안드로이드에서 네트워크 프로그래밍 방법

자바 소켓 API
TCP, UDP*
TCP, UDP상에서 바로 하기보다는 응용 프로토콜 라이브러리 사용
HTTP(S)를 사용하는 경우, 대부분 이 경우에 해당됨
자바 HTTP URL Connection Retrofit 라이브러리 (OkHttp 기반) Volley, Cronet 등도 있음*
MQTT를 사용한다면
paho, HiveMQ 등 라이브러리 사용*

권한 설정

안드로이드에서 네트워크에 접근하기 위한 권한 필요
설치시 부여되는 일반 권한이므로 동적 권한 확인 코드는 불필요

AndroidManifest.xml


HTTP 사용할 경우

HTTP와 HTTPS

HTTPS는 메시지를 암호화하여 전송*

HTTP는 메시지를 그대로 전송*

안드로이드에서 HTTP Url Connection API 사용할 때, http는 기본적으로 금지

http를 사용하기 위해서 Manifest의 application 태그 속성에

android:usesCleartextTraffic="true"를 추가*



네트워크 연결 상태

현재 연결된 네트워크 종류나 인터넷 연결 가능 여부를 판단

ConnectivityManager.allNetworks: 모든 네트워크 IF를 리턴

ConnectivityManager.activeNetwork: 현재 활성화된 네트워크 IF


private fun isNetworkAvailable(): Boolean {
    val connectivityManager =
    getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val nw = connectivityManager.activeNetwork ?: return false // 현재 활성화된 네트워크
    val actNw = connectivityManager.getNetworkCapabilities(nw) ?: return false

    println("${actNw.hasTransport(NetworkCapabilities.TRANSPORT_WIFI)},
             ${actNw.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR)}, "
             + "${actNw.hasTransport(NetworkCapabilities.TRANSPORT_ETHERNET)}")

    return actNw.hasCapabilities(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    // 인터넷 가능 여부
}

hasTransport: 네트워크의 특정 전송 방식

Wi-Fi인지, 모바일 데이터인지*

hasCapabilities: 네트워크의 특정 기능

인터넷에 연결 가능한지*


자바 소켓 API
NetworkRepository
class NetworkRepository {
    suspend fun fetchFromSocket(): String = withContext(Dispatchers.IO) {
        val sock = SocketFactory.getDefault().createSocket("google.com", 80)
        val istream = sock.getInputStream()
        val ostream = sock.getOutputStream()
        ostream.write("GET / \r\n".toByteArray())
        ostream.flush()
        val result = istream.readBytes().decodeToString()
        sock.close()
        result
    }
}
withContext(코루틴 컨텍스트, 코루틴)

해당 코루틴 컨텍스트로 코루틴을 수행
여기에서는 IO 담당 디스패쳐(스레드)에서 수행하도록 함

suspend

네트워크나 파일 I/O같이 블록 가능성있는 API 호출할 때 
반드시 비동기로 호출하거나 코루틴/스레드에서 수행해야 함

ViewModel
class MyViewModel : ViewModel() {
    private val repository = NetworkRepository()

    private val _response = MutableStateFlow("")
    val response: StateFlow = _response.asStateFlow()

    private val _responseBy = MutableStateFlow("")
    val responseBy: StateFlow = _responseBy.asStateFlow()

    fun refreshJavaSocket() {
        viewModelScope.launch {
            try {
                val result = repository.fetchFromSocket()
                _responseBy.value = "Java Socket : Succeeded to connect to the server"
                _response.value = result
            } catch (e: Exception) {
                _responseBy.value = "Java Socket"
                _responseBy.value = "Failed to connect to the server ${e.message}"
            }
        }
    }
}
HTTP(s) URL Connection API

java에서 제공하는 HttpURLConnection, HttpsURLConnection

HTTP(s) 프로토콜을 손쉽게 사용할 수 있는 API*

HTTP 사용 시 Manifest 파일의 application 태그에
android:usesCleartextTraffic="true"


NetworkRepository

이미지 URL의 데이터 수신 후 Bitmap으로 변환

class NetworkRepository {
    suspend fun fetchBitmapHttps(url: String):Bitmap? 
    = withContext(Dispatcher.IO) {
        val conn = URL(url).openConnection() as HttpsURLConnection
        try {
            val istream = conn.inputStream
            BitmapFactory.decodeStream(istream)
        } finally {
            conn.disconnect()
        }
    }
}
ViewModel
class MyViewModel : ViewModel() {
    private val repository = NetworkRepository()

    private val _response = MutableStateFlow("")
    val response: StateFlow = _response.asStateFlow()

    private val _responseBy = MutableStateFlow("")
    val responseBy: StateFlow = _responseBy.asStateFlow()

    private val _responseImg = MutableStateFlow(null)
    val responseImg: StateFlow = _responseImg.asStateFlow()

    fun refreshBitmapByHttpsLib(url: String) {
        viewModelScope.launch {
            try {
                val bitmap = repository.fetchBitmapHttps(url)
                _responseBy.value = "HttpsURLConnection"
                _response.value = "Succeeded to download the image"
                _responseImg.value = bitmap
            } catch(e: Exception) {
                _responseBy.value = "HttpsURLConnection"
                _responseBy.value = "Failed to download the image: ${e.message}"
            }
        }
    }
}
Bitmap을 파일로 저장

ContentResolver를 이용하여 MediaStore에 이미지 저장private fun saveBitmap(bitmap: Bitmap, fileName : String) {
  val collection = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
      MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERAL)
  } else {
      MediaStore.Images.Media.EXTERNAL_CONTENT_URI
  }
  val contentValues = ContentValues().apply {
      put(MediaStore.Images.Media.DISPLAY_NAME, fileName)
  }
  val destUri = contentResolver.insert(collection, contentValues) ?: return
  contentResolver.openOutputStream(destUri)?.use {
      bitmap.compress(Bitmap.CompressFormat.PNG, 100, it)
  }
}


Retrofit

HTTP 연결을 통해 받은 JSON 등의 구조체 데이터를 
알아서 클래스 객체로 만들어줌

HTTP body 내용이 JSON, 일반 문자열, XML 등에 따라 
변환기를 선택 사용 가능*

프로그래머는 필요한 인터페이스와 데이터 클래스만 정의하면 
구현은 Retrofit이 알아서 함

build.gradle(모듈)
dependencies {
  implementation("com.squareup.retrofit2:retrofit:3.0.0")
  implementation("com.squareup.retrofit2:converter-gson:3.0.0") 
  // Json용 변환기
}


Interface 정의

Retrofit에서 자동으로 만들어주는 REST API 정의

@GET(경로명) annotation 사용

경로명에 {이름}으로 된 것은 메소드의 인자로 치환됨*

치환되는 인자의 앞에 @Path("이름") annotation 사용*

리턴 값은 

Call＜타입＞을 리턴받아 콜백으로 응답을 받거나,

suspend**를 붙여서 해당 타입 객체를 바로 리턴 받는 방법이 가능
interface RestApi {
   @GET("users/{user}/repos")
   fun listReposCall(@Path("user") user: String): Call>

   @GET("users{user}/repos")
   suspend fun listRepos(@Path("user")user: String): List
}
Data class 정의
data class Owner(val login: String)
data class Repo(val name: String, val owner: Owner, val url: String)



interface RestApi {
    @GET("users/{user}/repos")
    suspend fun listRepos(@Path("user")user: String): List
}

### JSON
- NetworkRepository
- RestApi 객체 생성
*JSON 변환기 지정*

```kotlin
class NetworkRepository {
    private val baseURL = "https://api.github.com"
    private val api: RestAi = with(Retrofit.Builder()) {
        baseUrl(baseURL)
        addConverterFactory(GsonConverterFactory.create()) // JSON 변환기 지정
        build()
    }.create(RestApi::class.java)

    suspend fun fetchRepos(userName: String): List {
        return api.listRepos(userName)
    }
}
ViewModel
class MyViewModel : ViewModel() {
    private val repository = NetworkRepository()
    private val _response = MutableStateFlow("")
    val response: StateFlow = _response.asStateFlow()
    private val _responseBy = MutableStateFlow("")
    val responseBy: StateFlow = _responseBy.asStateFlow()

    fun refreshRetrofit(userName: String) {
        viewModelScope.launch {
            try {
                val repos = repository.fetchRepos(userName)
                _responseBy.value = "retrofit : ${repos.size} repositories"
                _response.value = StringBuilder().apply {
                    repos.forEach {
                        append(it.name)
                        append(" - ")
                        append(it.owner.login)
                        append("\n")
                    }
                }.toString()
            } catch (e: Exception)
        }
    }
}
Download Manager

시스템에서 제공하는 다운로드 기능
URL과 다운로드 위치만 알려주면 알아서 알림도 표시하고 다운로드 수행



다운로드 완료 방송 받는 방송 수신자
DownloadManager.ACTION_DOWNLOAD_COMPLETE



Docker
Wed, 03 Jun 2026 09:30:13 GMT
도커(Docker)

애플리케이션과 실행에 필요한 모든 요소를 

하나의 표준 단위(컨테이너)*로 묶는 플랫폼

컨테이너 = 코드 + 런타임 + 라이브러리 + 시스템 도구 + 설정

리눅스 커널의 네임스페이스/cgroup 기술로 
프로세스를 격리해 가볍고 빠르게 실행

핵심 이점
환경 일관성, 빠른 기동 시간, 높은 이식성, 대규모 운영의 자동화


도커의 필요성

개발 노트북, 테스트/운영 서버의 OS 버전, 의존성이 서로 다름
라이브러리 버전 충돌, 운영체제 의존 도구 누락, 시스템 환경변수 차이
도커는 애플리케이션 전체를 이미지로 고정 
→ 어디에서 실행해도 동일 환경 보장

가상 머신(VM) vs 컨테이너
VM

게스트 OS 전체를 가상화 → 무겁고(GB), 부팅에 분 단위 소요

컨테이너

호스트 커널을 공유, 앱과 라이브러리만 격리 → 수십 MB, 수 초 내 기동



동일 하드웨어에서 VM은 10대 수준, 컨테이너는 수백 개 까지 실행 가능
개발 속도, 자원 효율, 배포 빈도 등 모든 면에서 컨테이너가 유리

도커 아키텍처의 3대 요소
이미지(image): 앱과 환경을 고려한 읽기 전용 템플릿 - 붕어빵 틀
컨테이너(container): 이미지를 실행 상태로 인스턴스화한 실제 프로세스 - 붕어빵
레지스트리(Registry): 이미지를 저장, 공유하는 원격 창고 (ex) 도커 허브)
흐름: Dockerfile → build → 이미지 → push 
→ 레지스트리 → pull → run → 컨테이너
실습: Node.js 예제 어플리케이션
index.js/package.json - 두 파일을 같은 폴더에 준비
// index.js — 3000번 포트에서 응답하는 최소 웹 서버
const http = require('http');
const server = http.createServer((req, res) => {
  res.end('Hello Docker World!');
});
server.listen(3000, () => console.log('3000번 포트 가동 중!'));

// package.json — 시작 스크립트 정의
{
  "name": "docker-node-app",
  "scripts": { "start": "node index.js" }
}
도커파일(Dockerfile)

이미지를 어떻게 만들지 단계별로 기술한 평문 스크립트 - 이미지의 설계도

한 줄 한 줄이 하나의 레이어(Layer)로 쌓여 최종 이미지 구성

변경이 없는 레이어는 캐시 재사용 → 빌드 시간이 극적으로 단축

공식 베이스 이미지(node, python, nginx 등) 위에 내 앱을 얹는 방식이 일반적


Dockerfile 상세 분석
# 1. 기반 이미지 설정 - Node.js 18이 설치된 리눅스 환경을 상속
FROM node:18
# 2. 작업 디렉토리 지정 - 컨테이너 내부 /app 폴더를 만들고 그리로 이동
WORKDIR /app
# 3. 소스 코드 복사 - 현재 폴더의 모든 파일을 /app 안으로 복사
COPY . .
# 4. 실행 명령어 정의 - 컨테이너 기동 시 자동으로 실행
CMD ["npm", "start"]
주요 명령어 정리

이미지 빌드 - docker build로 붕어빵 틀 만들기

명령: docker build -t yourid/node-app .

-t 옵션: 이미지에 [사용자/이미지이름: 태그] 형태의 이름표 부착

.: 빌드 컨텍스트 = Dockerfile이 위치한 현재 폴더

확인: docker images로 방금 만든 이미지가 목록에 표시되는지 점검


도커 허브를 통한 전 세계 배포 워크플로우

도커 컴포즈(Docker Compose)

여러 개의 컨테이너를 하나의 설정으로 정의/실행하는
다중 컨테이너 오케스트레이션 도구

설정 파일: docker-compose.yaml (YAML 형식)

한 줄 명령 docker-compose up으로 모든 서비스와 네트워크를 일괄 기동

각 서비스 간 의존 순서, 네트워크, 볼륨, 환경변수를 선언적으로 기술


도커 컴포즈가 필요한 이유

도커 단독 사용 시, 컨테이너마다 docker run을 반복하고
포트, 네트워크, 옵션을 매번 기억해야 함

수 개 ~ 수십 개 서비스가 얽힌 환경에서 수동 실행은 실수와 누락의 온상

컴포즈: 전체 토폴로지를 YAML로 버전 관리 
→ 팀원 모두 동일한 구성으로 재현

개발/테스트용 로컬 환경을 한 명령(up)으로 초기화하고
한 명령(down)으로 정리


실습: docker-compose.yaml 작성
웹 서버 + 레디스 구성 예시
version: '3.8'               # 1. 컴포즈 파일 규격 버전
services:                    # 2. 실행할 서비스들의 묶음
  web-app:                   # 3. 웹 서버 서비스 정의
    build: .                 # 4. 현재 폴더의 Dockerfile 로 빌드
    ports:                   # 5. 포트 연결 설정
      - "8080:3000"
    depends_on:              # 6. 실행 의존성 정의
      - redis-db             # 7. redis-db가 먼저 켜져야 함
  redis-db:                  # 8. 레디스 서비스 정의
    image: "redis:alpine"    # 9. 공식 경량 이미지 사용
라인별 해석

depends-on 실행 순서의 유무 비교


depends-on은 컨테이너 기동 순서를 보장하는 가이드라인
레디스 컨테이너가 먼저 올라온 뒤에야 웹 서비스가 실행됨
내부 애플리케이션이 완전히 준비(ready) 된 상태까지는 보장하지 않음
헬스체크 병행 권장*

컴포즈는 서비스 이름만으로 통신함
// web-app 컨테이너 내부의 Node.js 코드
const redis = require('redis');
// 과거방식 컨테이너 IP를 직접 적어야 했던 시대
// const client = redis.createClient({ host: '172.18.0.3' });

// 컴포즈방식 yml에 적은 서비스 이름을 그대로 주소로
const client = redis.createClient({ host: 'redis-db' });
// 도커 내부 DNS가 'redis-db'를 자동으로 해석해 연결
도커 컴포즈 핵심 명령어
docker-compose up-d: 설계도대로 모든 서비스를 백그라운드로 기동
docker-compose down: 컨테이너, 네트워크, 볼륨을 한 번에 정리
docker-compose ps: 현재 실행 중인 서비스 상태 조회
docker-compose logs -f [서비스명]: 실시간 로그 스트리밍으로 디버깅
docker-compose build: 코드 변경 후 이미지만 다시 빌드
마무리

도커는 앱과 환경을 이미지로 고정해 어디서나 동일하게를 보장함

도커파일의 네 줄 레시피만으로 나만의 실행 환경을 재현 가능하게 만듦

빌드 → 푸시 → 풀 → 런 4단계로 전 세계 어디든 배포 가능

도커 컴포즈는 YAML 한 장으로 다중 컨테이너 시스템을 한 번에 지휘함

서비스 이름과 depedns-on 만으로 컨테이너 간 통신/실행 순서를 해결





Playwright - E2E
Wed, 03 Jun 2026 08:46:29 GMT
Playwright

마이크로소프트가 개발한 오픈소스 웹 자동화 라이브러리

단일 코드 베이스
하나의 코드로 모든 브라우저 제어

엔진 지원
크롬, 파이어폭스, 사파리 완벽 지원

다국어 지원
TypeScript JavaScript, Python, Java, .NET


Playwright vs Selenium

E2E Test

사용자가 실제로 애플리케이션을 사용하는 처음부터 끝까지의 
흐름 전체를 확인하는 테스트

개별 함수가 아닌 사용자 관점에서의 시나리오 검증

ex) 회원가입 → 로그인 → 상품 검색 → 장바구니 → 결제 완료

전체 서비스가 실제 환경에서 문제없이 동작하는지 보장


설치 및 프로젝트 시작
사전 요구사항: Node.js 16 버전 이상 설치
버전 확인 명령어: node -v
설치 명령어: npm init playwright@latest
설치 과정에서 TypeScript/JavaScript 선택, 예제 테스트 자동 생성
프로젝트 구조 및 설정 파일
tests/: 테스트 코드 파일을 저장하는 폴더
playwright.config.ts: 전체 실행 환경 설정 파일
핵심 옵션

retries: 실패 시 재시도 횟수
headless: 브라우저 창을 띄울지 여부

projects: 크롬, 파이어폭스, 웹킷 등 브라우저 별 실행 설정
사례: 네이버 검색 테스트 코드
시나리오: 네이버 접속 → 검색창에 "Playwright" 입력
import { test, expect } from '@playwright/test';
test('  네이버 검색테스트', async ({ page }) => {
  // 1. 네이버 사이트로 이동
  await page.goto('https://www.naver.com');

  // 2. 검색창(#query) 에 'Playwright' 입력
  await page.fill('#query', 'Playwright');
시나리오: 엔터 키 입력 → 결과 페이지 제목 확인
  // 3. 엔터 키 눌러서 검색 실행
  await page.press('#query', 'Enter');
  // 4. 페이지 제목에 'Playwright'   가 있는지 확인
  await expect(page).toHaveTitle(/Playwright/);
});
셀렉터(Selector)와 HTML
셀렉터(selector): 웹 페이지 내 특정 요소를 가리키는 주소



// CSS 선택자
#query        // id  로 찾기
.btn_search   // class  로 찾기
Playwright 로케이터(Locator)

로케이터를 써야 하는 이유


깨지기 쉬운 CSS 경로 대신 사용자 관점 셀렉터 이용

유지보수 용이: 구조가 바뀌어도 버튼의 역할과 이름은 그대로이기 때문

가독성 향상: 코드만 봐도 무엇을 테스트하는지 알 수 있음

웹 접근성(Accessibility) 준수


플래키(Flaky) 테스트

성공과 실패를 오가는 불안정한 테스트

원인: 네트워크 지연, 타이밍 이슈, 비동기 렌더링, 데이터 의존성

영향: 테스트 결과에 대한 신뢰도 하락

개발자가 테스트를 신뢰하지 않아 결국 자동화 포기


플래키 해결: 1. 자동 대기(Auto-Waiting)

액션을 수행하기 전, 요소가 준비될 때 까지 자동으로 대기

체크 항목

1) Visible: 요소가 화면에 보이는가?
2) Stable: 애니메이션이 끝나 정지했는가?
3) Enabled: 활성화되어 클릭 가능한가?
4) Receives events: 이벤트가 처리될 준비가 됐는가?

플래키 해결: 2. 웹 퍼스트 어설션


고정 대기(waitForTimeout)는 절대 금지
웹 퍼스트 어설션은 조건이 만족될 때 까지 최대 5초간 확인
조건이 맞으면 다음 단계로 넘어가므로 안정성과 속도 모두 확보

테스팅 피라미드 전략


아래로 갈수록 많이, 위로 갈수록 개수를 적게
유닛은 수천 개 단위로 빠르게, E2E는 핵심 흐름 위주로 소수 정예

테스팅 비교
유닛 테스트(Unit Test)

함수, 메서드 등 코드의 가장 작은 단위를 검증
초고속(ms) 실행, 실패 시 문제 위치를 바로 특정
DB, 서버, 네트워크 등 외부 의존 없음
ex) sum(1, 2) 함수가 3을 반환하는가

통합 테스트(Integration Test)

여러 모듈이 결합했을 때의 상호작용 검증
DB 연동, API 호출과 응답, 외부 서비스 연계
유닛 테스트보다는 느리고, E2E 테스트보다는 빠름
ex) 회원가입 요청 시 실제로 DB에 사용자 정보가 저장되는지 확인

E2E 테스트

실제 사용자 관점에서 전체 흐름을 시뮬레이션
도구: Playwright, Selenium, Cypress 등
실제 사용자 경험을 그대로 검증
느리고 관리가 어려움, 핵심 기능 위주로 작성

사례: 네트워크 모킹
사용 의도와 목록 조회
1) 외부 서버에 의존하지 않는 독립적인 테스트 만들기
test('가짜 데이터를 사용한 목록 조회', async ({ page }) => {
  await page.route('**/api/todos', async route => {
    await route.fulfill({
      status: 200,
      body: JSON.stringify([{ id: 1, text: '모킹된 할일' }]),
    });
  });
  await page.goto('http://localhost:5173');
  await expect(page.getByText('모킹된 할일')).toBeVisible();
});
2) 인위적으로 만들기 어려운 엣지 케이스를 강제 재현
test('서버 에러 시 에러 메시지 표시', async ({ page }) => {
  await page.route('**/api/todos', async route => {
    await route.fulfill({ status: 500 }); // 500  에러 강제
  });
  await page.goto('http://localhost:5173');
  await expect(page.getByText('오류가 발생했습니다')).toBeVisible();
});
마무리

Playwright을 이용한 빠르고 안정적인 E2E 구현
로케이터로 깨지지 않는 견고한 셀렉터 작성
테스팅 피라미드 전략으로 테스트 효율 극대화
네트워크 모킹으로 외부 환경으로부터 독립성 확보
고정 대기 금지, 웹 퍼스트 어설션 사용 원칙 준수




Testing Pyramid
Wed, 03 Jun 2026 06:17:15 GMT
테스팅 피라미드란?

핵심 원칙

테스트 종류를 계층별로 나누어 비중을 조절하는 전략

아래로 갈수록 많게, 위로 갈수록 적게

각 계층은 서로 다른 속도, 커버리지, 특성을 가짐


필요한 이유
속도와 비용

하위 테스트일수록    실행 속도가 빠르고 유지보수 비용 저렴

정확한 피드백

오류 발생 시 버그의 위치를 즉시 파악 가능

신뢰성

상위 테스트를 통해 실제 서비스 작동을 최종 보장

안티 패턴 경계

아이스크림 콘 구조
상위 테스트만 많다면 느리고 취약*

유닛(Unit) 테스트와 코드 예시
함수·메서드의 독립적 로직 검증(Jest 스타일)
// 대상 함수: 10% 할인 적용
function applyDiscount(price) {
    return price * 0.9;
}

// 단위 테스트 코드
test('할인 계산 로직검증', () => {
  const result = applyDiscount(10000);
  expect(result).toBe(9000);
});
통합(Integration) 테스트와 코드 예시
모듈 간의 협력과 데이터 흐름 검증
test('회원가입 서비스 통합 검증', async () => {
  const newUser = { id: 'test_id', name: '홍길동' };
  // 1. 서비스 함수 실행 (DB  통신 발생)
  await userService.signUp(newUser);

  // 2. DB에서 데이터가 잘 저장되었는지 직접 조회
  const userInDb = await db.findUserById('test_id');
  expect(userInDb.name).toBe('홍길동');
});
E2E 테스트와 Playwright 코드
실제 사용자 관점의 전체 시나리오 보장
test('로그인 성공 후 메인 페이지 이동', async ({ page }) => {
  await page.goto('https://naver.com/login');
  await page.fill('#query', 'Playwright');
  await page.press('#query', 'Enter');

  // 결과확인:페이지제목검증
  await expect(page).toHaveTitle(/Playwright/);
});
요약 비교




npm audit & Trivy
Wed, 03 Jun 2026 06:06:26 GMT
학습 목표

왜 보안 도구가 필요한가
npm audit 이해하기
Trivy 이해하기
두 도구 함께 사용하기

2021년 Log4j 사태
Log4j

자바에서 거의 모든 회사가 쓰던 로그 기록 라이브러리

해당 라이브러리에 해커가 한 줄의 메시지만 보내도 
서버를 통째로 빼앗을 수 있는 치명적인 결함 발견


npm audit
"냉장고에 있는 식재료만 검사해주는 점원"
냉장고 안 식재료만 골라서 어떤 게 상했고, 리콜 됐는지 알려주는 점원

JavaScript, Node.js 패키지만 골라서 검사

특징

내장형
npm 설치 시 자동 포함
JavaScript 전용
Node.js 패키지만 검사
자동 수정
audit fix 한 줄로 패치

동작
1) package.json 읽기

재료 목록 확인{
  "dependencies": {
      "express": "4.17.1",
      "lodash": "4.17.20" // 옛날 버전
  }
}


2) 보안 DB 조회

공식 데이터베이스에 문의

3) 결과 보고

취약점 + 수정버전 안내

실제 실행 결과

npm audit fix 를 통해 자동으로 수정 가능
심각도(severity) 4단계
low: 위험도 낮음 - 약간 시들해진 채소
moderate: 보통 - 유통기한 임박
high: 심각 - 곰팡이 핀 빵
critical: 매우 위험 - 상한 고기
high, critical은 즉시 수정이 필요하며,
low, moderate는 우선순위에 따라 처리
Trivy
주방 위생검사원
냉장고 뿐만 아니라 주방 전체 가스레인지, 조리기구, 도시락 통 (컨테이너) 까지
전부 점검하는 종합 검사원
특징

다중 언어 지원

JavaScript, Python, GO, Java 등*

컨테이너 지원

Docker 이미지, OS 패키지 포함*

시크릿 검사

비밀번호, API 키 노출 탐지*


검사 대상
1) 컨테이너 이미지 - "배달 도시락 통"

Docker 이미지 안의 모든 것

2 소스 코드 - "레시피 노트"

GitHub 저장소

3) 설정 파일 - "주방 설계도"

Dockerfile, Kubernetes 설정

4) 비밀번호, 열쇠 - 금고 "비밀번호 메모"

코드에 실수로 적힌 API 키

사례: 실수로 비밀번호를 코드에 적었다면?


GitHub는 공개 저장소이기 때문에 업로드 순간 전 세계에 공유

npm audit vs Trivy


npm audit: 매일 점검
Trivy: 정기 종합검사
마무리




ESLint
Wed, 03 Jun 2026 05:31:14 GMT
학습 목표

린트가 무엇인지
왜 필요한지
무엇을 잡는지
ESLint 사용법

Lint
옷에 붙은 보푸라기

옷에 붙은 보푸라기처럼 떼어내야 할 자잘한 결함을 찾는 도구

코드의 맞춤법 검사기

실행하지 않고 읽기만 해서 검사

Lint가 잡아주는 것
1) 명백한 오류

실행하면 그냥 깨지는 것console.log(undefinedVar)
// 선언하지 않은 변수 사용

2) 잠재적 버그*
실행은 되지만 사고를 부르는 패턴if (x == "1") { ... }
// 타입까지 맞추지 않은 == 사용


3) 코드 스타일

팀이 약속한 일관성
ex) 
들여쓰기 4칸 vs 2칸
세미콜론 유무 등*

4) 베스트 프랙티스

관습적으로 더 좋은 방식
ex)
var → const/let
사용하지 않는 변수 제거 등*

컴파일러, 린터, 사람
컴파일러/인터프리터

문법 자체가 틀린 코드를 잡아줌

ex) ;이 빠지거나, 괄호가 닫히지 않은 경우
문법 100%

린터

문법은 맞지만 위험한 패턴

ex) == 사용, 사용하지 않는 변수, 팀 스타일 위반
습관·관습

사람

설계가 적절한지, 의도가 명확한지

ex) 해당 함수는 책임이 너무 많음, 변수 이름이 뜻을 담지 않음
의미·맥락

ESLint
JavaScript 린터의 사실상 표준
ESLint의 핵심 강점
1) 플러그인 아키텍쳐

룰을 켜고 끄고, 새로 만들 수 있음

2) 자동 수정

간단한 문제는 --fix 옵션으로 즉시 수정

3) 에디터 통합

VS Code 등에서 빨간 줄로 실시간 표시

4) 프레임워크 지원

React, Vue, TypeScript 모두 공식 플러그인

설치

npm eslint src: 검사만 진행
npm eslint src --fix: 자동 수정까지 진행
eslint.config.js

files

검사할 파일 패턴을 글롭(*)으로 지정함

languageOptions

ECMAScript 버전, 모듈 종류, 사용할 전역 변수

rules

룰 이름을 심각도로 매핑함
off → warn → error

실무에서 거의 항상 켜두는 5가지
no-undef: 선언하지 않은 변수 사용 금지 - error
no-unused-vars: 선언만 하고 사용하지 않는 변수 경고 - warn
eqeqeq: == 대신 === 강제 - error
no-console: 콘솔 로그 잔재 경고 - warn
prefer-const: 재할당 하지 않는 변수는 const - warn
PR마다 린트를 자동으로 돌리는 이유

1) 에디터 설정 의존 제거

같은 명령을 같은 환경에서 돌리기 때문에
"내 컴퓨터에서는 안떴는데요?" 를 차단

2) 리뷰의 짐 줄이기

컴퓨터가 잡을 건 컴퓨터가 잡고, 사람은 설계와 의도에 집중

3) 머지 차단

브랜치 보호와 함께 쓰면, lint가 빨개진 PR은 메인에 들어갈 수 없음

Summary

린트는 코드의 맞춤법 검사

컴파일러도 사람도 잡지 못하는 자잘한 결함을 자동으로 잡음

CI의 첫 단계

PR마다 자동, 사람 리뷰 전에 통과해야 함*





12. 대용량 저장 장치 관리
Tue, 02 Jun 2026 04:13:10 GMT
강의 목표

저장 장치의 특징과 
저장 장치가 시스템의 성능과 신뢰성에 미치는 영향을 이해한다.

하드 디스크 장치의 구조와 입출력 과정을 통해 
디스크 입출력 성능을 결정하는 요소에 대해 이해한다.

디스크 스케줄링 알고리즘에 대해 이해하고 이들의 성능을 비교한다.

FCFS, SSTF, SCAN, C-SCAN, LOOK C-LOOK*

디스크의 저수준 포맷과 고수준 포맷에 대해 이해한다.

최근에 많이 이용되는 
SSD 저장 장치의 구조와 입출력 과정 등에 대해 이해한다.


01. 저장 장치 개요
1.1 저장 장치의 특징
주기억장치

현재 실행 중인 프로그램 코드와 데이터를 적재

CPU가 직접 접근하는 기억장치

RAM 반도체 메모리가 사용됨*


저장 장치


전원이 꺼져도 프로그램과 데이터를 보조 저장할 수 있는 대용량 장치

CPU가 직접 접근하지 않고 입출력 전용 처리기에 의해 입출력됨

하드 디스크, SSD, 자기테이프, CD, RAID, USB 스틱 등*

대용량
몇 백 기가바이트(GB Giga Byte)에서 수십 테라바이트(Tera Byte)

비휘발성(non-volatile)
컴퓨터의 교체 시기보다 긺

가상 메모리의 스왑 공간으로 활용
메모리 계층 구조의 최하위단으로
데이터베이스나 파일 저장 및 가상 메모리의 스왑 공간으로 이용됨


1.2 저장 장치의 성능 및 신뢰성

저장 장치의 입출력 병목(I/O bottleneck) 문제 - 시스템 성능에 영향
저장 장치의 데이터 신뢰성(data reliability) 문제 - 시스템 신뢰성에 영향

저장 장치의 입출력 병목

저장 장치가 입출력에 과부하가 걸려 있는 상태

여러 프로세스로부터 유발된 입출력 요청들로 인해,
사용자나 프로세스는 입출력이 끝나기를 오래 기다리는 현상

CPU와 메모리의 처리 속도에 저장 장치의 속도 향상은 미치지 못한 것이 원인

주기억장치 메모리 늘리기
메모리를 늘려 저장 장치로의 입출력 횟수를 줄이기

디스크 캐시 늘리기
디스크 블록의 다음 블록들을 미리 디스크 캐시에 읽어두어
순차 읽기 응용의 입출력 응답 속도를 높인다.

디스크 스케줄링
디스크 암의 움직임을 최소화함으로써 
디스크 장치의 물리적인 입출력 시간을 단축하는 기법

SSD와 같은 빠른 저장 장치나 RAID와 같은 병렬 저장 장치 사용
속도가 빠른 저장 장치나  디스크를 병렬로 동작시키는 
RAID(Redundant Array of Inexpensive Disks)를 이용하여 
물리적인 입출력 성능 향상


데이터 신뢰성
디스크 미러링(disk mirroring)

2개의 디스크에 항상 동일한 데이터가 기록되도록 구현하고
사용자에게는 1개의 디스크처럼 보이게 하는 기법



디스크 미러링은 RAID 기법 중 하나로 RAID 레벨 1이라고 부름

RAID는 디스크의 입출력 병목 및 데이터의 신뢰성을 높이는 기법

핫 스와핑(hot swapping)
시스템 동작 중 디스크가 고장나면, 시스템이 동작 중인 상태에서
고장난 디스크를 제거 및 새 디스크를 삽입


RAID

디스크에 패리티(parity) 정보와 함께 분산 기록하여
디스크가 손상될 때 자동으로 복구하는 기법



RAID 기법 중 가장 많이 사용되는 레벨 5의 모형

3개의 디스크에 돌아가면서 배치하며,
그중 한 디스크에는 패리티(parity) 블록을 저장

작동 중 디스크 2가 고장이 나면 디스크 0, 1, 2를 통해 디스크 2를 복구


TIP 패리티 비트

데이터를 전송할 때, 오류를 검출하기 위해 추가되는 비트

짝수/홀수 패리티 비트
데이터와 패리티 비트를 합쳐 
1의 개수가 짝수(홀수)개가 되도록 패리티 비트를 만듦

데이터 비트가 001일 때, 짝수 패리티 비트는 1, 홀수 패리티 비트는 0*

홀수 패리티 비트 생성 방법은
모든 데이터 비트들에 XOR(exclusive OR, ⊕)
홀수패리티 비트 p = b0 ⊕ b1 ⊕ b2
사용 중 B2 블록 손상 시, B2 = P0 ⊕ B0 ⊕ B1


02. 하드 디스크 장치
2.1 하드 디스크 장치의 구조
하드 디스크(HDD, Hard Disk Driver)

자성체(magnetic meterial)로 코팅된 여러 개의 원형 판(platter, 플래터)에
디지털 정보를 저장하고 읽어 내는 저장 장치

디스크 제어 모듈

호스트로부터 명령을 받아 디스크 매체 모듈에 지시하여
디스크 캐시와 디스크 매체 사이에 입출력이 이루어지도록 함

입출력 버스 인터페이스를 통해 
디스크 캐시에 저장된 데이터를 호스트로 전송 또는
호스트로부터 디스크 캐시로 데이터 수신



입출력 버스 인터페이스

입출력 버스를 통해 호스트로부터 입출력 명령을 수신하고
데이터를 주고받는 하드웨어
PCI/SCSI/SATA/USB 버스 인터페이스 등 다양한 종류 존재

프로세서

운영체제로부터 전달받은 디스크 입출력 명령을 해석하여
기계 장치를 구동시켜 하드 디스크의 암(arm)을 움직이거나 
디스크 헤드(disk head)를 제어하여 플래터에서 읽거나 씀

내부에 명령 큐를 두고 호스트로부터 받은 여러 개의 입출력 명령 저장

스케줄링을 통해 디스크 액세스 시간 단축 및 캐시 관리


디스크 캐시

입출력되는 데이터의 임시 저장소 역할을 하는 빠른 반도체 메모리

몇 십 MB 크기*

운영체제가 저장하기 위해 보낸 데이터는 디스크 캐시에 먼저 저장 후,
프로세서에 의해 플래터에 기록됨

프로세서는 예측 읽기(prefetch)를 통해 다음에 읽을 것으로 예측되는 데이터를 디스크 캐시에 읽어 놓아 호스트의 응답 시간을 단축


디스크 매체 모듈
플래터(platter)

완전한 원형 판의 자성체로 디지털 정보가 기록되는 곳

디스크 헤드(disk head)

플래터 위를 움직이며 디지털 정보를 읽거나 쓰는 장치

디스크 헤드는 플래터 표면 위에 일정한 간격을 유지한 채 정보를 읽거나 기록

플래터 표면에 닿게 되면 해당 부분이 손상되어 불량 섹터(bad sector) 가능성*


암(arm)

디스크 헤드를 원하는 위치로 움직이는 장치

구동기(actuator)

암들은 모두 하나의 구동기에 달려 있으며, 함께 이동한다.
그 중 하나의 플래터에서만 입출력을 진행함*

디스크 파킹(disk parking)

park
디스크 암을 플래터 바깥의 안전한 위치로 이동시키는 명령어
디스크 암이 플래터 위에 있는 상태에서 컴퓨터를 옮기면 플래터 훼손 가능성*

TIP 최초의 하드 디스크 IBM RAMAC 350
2.2 입출력 버스

입출력 버스는 다음과 같이 여러 종류가 있으며, 하드 디스크 제조업체는 
버스 인터페이스 회로를 포함하는 하드 디스크를 만듦

ATA, SATA(Serial ATA), SCSI, IEEE 1394, Fiber Channel, USB

ATA(Advanced Technology Attachment)

하드 디스크나 CD-ROM 장치를 PC에 연결하는 표준 입출력 버스
상업적으로 IDE, EIDE 라는 이름으로 사용됨*

SATA

현대 컴퓨터에서 디스크 장치를 연결하는 가장 보편적인 버스
PC나 노트북의 하드 디스크에 사용됨*

SCSI(Small Computer System Interface)

하나의 버스에 하드 디스크, CD-ROM, DVD, 스캐너 장치 등 
여러 개의 장치들을 동시에 연결하는 입출력 버스
서버급 컴퓨터나 워크스테이션에서 사용됨*

2.3 디스크 저장 구조
섹터, 트랙, 실린더


하드 디스크의 모든 플래터들은 
하나의 구동축(spindle, 스핀들)에 연결되어 동시에 회전

언제나 동일한 속도인 등각속도(CAV, Constant Angular Velocity)로 회전


트랙(track)

플래터의 표면에는 여러 개의 동심원을 따라 정보가 저장되는데,
이 때의 각 동심원

실린더(cylinder)

같은 동심원을 가진 트랙들의 모임

섹터(sector)

디스크 장치가 저장하고 읽는 최소 단위

전통적으로 512바이트 크기이지만, 
최근에는 4KB 크기의 고급 포맷(Advanced Format)을 사용


존 비트 레코딩(zone bit recording)

전통적인 디스크

전통적인 디스크에서는 안쪽 트랙과 바깥쪽 트랙에 같은 개수의 섹터를 배치
안쪽 트랙에 비해 바깥쪽 트랙의 저장 밀도가 낮음*

존 비트 레코딩

밀도가 낮은 바깥쪽 트랙에 더 많은 섹터를 배치하는 
존 비트 레코딩(zone bit recording, ZBR) 방식의 하드 디스크 등장

전체 트랙을 몇 개의 존(zone, 영역)으로 나눔

바깥 존에 더 많은 트랙 당 섹터를 배치하여
디스크의 저장 용량을 늘리고 입출력 속도를 높임

바깥 존일수록 더 많은 섹터가 있으므로
시간당 입출력되는 섹터가 많아, 입출력 속도가 더 높음


디스크 물리 주소

트랙과 섹터는 바깥에서 안으로 0부터 증가하는 순서로 번호가 매겨짐

플래터의 개수가 4개일 때, 헤드는 8개, 한 실린더는 8개의 트랙으로 구성*

실린더 번호도 바깥에서 안쪽으로 0번부터 매겨짐

섹터의 위치는 CHS(Cylinder-Head-Sector) 물리 주소로 표현됨
CHS 물리 주소 = [실린더 번호, 헤드 번호, 섹터 번호]

운영체제는 디스크의 모든 섹터를 일차원으로 펼치고, 
여러 섹터를 블록(disk block)이라는 단위로 묶어 0번부터 블록에 번호를 매긴
논리 블록 주소(LBA, Logical Block Address)를 사용


하드 디스크의 회전 방향

하드 디스크의 모터는 반시계 방향으로 회전함
명확한 이유는 존재하지 않음*

하드 디스크를 세워 놓으면 고장 나지 않을까?

하드 디스크는 세워 놓든 눕혀 놓든 반대로 세워놓든 전혀 영향이 없음

2.4 디스크 용량
디스크 용량 = 실린더 개수 x 실린더 당 트랙 수 x 트랙 당 섹터 수 x 섹터 크기

실린더 당 트랙 수 = 디스크 헤드의 개수

용량 계산 사례 1
실린더: 1000개
실린더 당 트랙 수: 8개
트랙 당 섹터 수: 200개
섹터 크기: 512바이트

디스크 용량 = 1000 x 8 x 200 x 0.5KB = 약 800MB(819.2MB)
용량 계산 사례
실린더: 4000개
실린더 당 트랙 수: 2개
트랙 당 섹터 수: 2000개
섹터 크기: 512바이트

(1) 디스크에는 총 몇 개의 트랙이 있는가?
4000 x 2 = 8000개

(2) 트랙당 저장 용량은 얼마인가?
2000 x 512바이트 = 약 1MB

(3) 디스크의 총 저장 용량은 얼마인가?
8000 x 1MB = 8GB


TIP 저장용량을 나타내는 단위, KB와 KiB

KB, MB, GB의 단위는 1000을 단위로 하고,
KiB, MiB, GiB의 단위는 1024를 단위로 함


2.5 디스크 입출력 과정 및 성능 파라미터

디스크 장치는 운영체제의 디스크 드라이버로부터 받은 입출력 명령을 실행

운영체제는 논리 블록 주소를 사용하기 때문에,
디스크 장치가 운영체제로부터 받는 명령의 구성은 다음과 같다
읽기/쓰기, 논리블록번호(LBA), 호스트의 메모리 주소, 읽거나 쓰는 블록 수

디스크 입출력 명령이 내려지면, 디스크 장치 내 프로세서가
논리 블록 번호 → CHS 물리 주소 후, 디스크 헤드를 목표 실린더로 이동




1) 탐색(seek)
디스크 헤드를 목표 실린더로 이동

2) 회전 지연(rotational latency)
플래터가 회전하여 목표 섹터가 디스크 헤드 밑에 도달할 때 까지 대기

3) 전송(transfer)
디스크 헤드와 호스트 사이의 데이터 전송. 내부 전송과 외부 전송으로 나뉨

4) 오버헤드(overhead)
프로세서가 호스트에서 명령을 받고 해석하는 등 부가 과정


탐색

디스크 장치 내 모터를 이용하여 
디스크 헤드를 현재 실린더에서 목표 실린더로 이동시키는 과정

이동하는 실린더 개수를 탐색 거리(seek distance)라고 함

탐색 시간은 탐색 거리에 선형적으로 비례*

탐색 거리가 매우 짧은 경우 탐색 시간이 많이 걸리는 현상이 일어남

모터가 디스크 암을 가속시키는 탐색 초기와 
목표 실린더 앞에서의 감속에 많은 시간이 걸리기 때문*

오늘날 상용 하드 디스크의 평균 탐색 시간은 5ms 내외(1ms~10ms)


회전 지연

탐색 후 플래터가 회전하여 
헤드 밑에 목표 섹터가 도달할 때 까지 걸리는 시간

평균 회전 지연 시간 = 1/2 회전 시간

디스크의 회전 속도는 분당 회전수로 나타내며, 
단위는 RPM(Rotations Per minute)

7200RPM인 경우
1회전 시간 = 60초/7200 = 8.33ms
평균 회전 지연 시간 = 8.33ms / 2 = 4.17ms


전송
내부 전송

디스크 헤더가 플래터 표면에서 디스크 캐시로 데이터를 읽어오거나,
반대로 디스크 캐시에서 플래터 표면에 데이터를 기록하는 시간

한 트랙이 1000개의 섹터로 구성되고 섹터 크기는 512바이트(0.5KB)
한 트랙의 크기 = 1000 x 0.5KB = 500KB
디스크의 회전 속도가 7200RPM일 때, 1회전 시간 = 8.3ms
→ 8.3ms에 500KB를 읽어 전송


500KB/8.3ms = 약 60.24KB/ms = 60240KB/초 = 60MB/초

- 디스크의 회전 속도가 빠를수록 내부 전송 속도가 빠름

- 디스크 제조업체에서 공개하는 디스크의 데이터 전송률(data transfer rate)은
보통 내부 전송 속도를 의미함

- 바깥쪽 트랙을 액세스할 경우, 전송률이 더 높음

**외부 전송**
- 디스크 캐시와 호스트 컴퓨터 사이에 데이터가 전송되는 시간

- 디스크 장치와 호스트 컴퓨터가 연결되는 I/O 버스의 속도에 달려 있음
*일반적으로 외부 전송 시간 ＜ 내부 전송 시간*

#### 오버헤드 시간
- 호스트로부터 명령을 받고 해석하는 시간
- 디스크 헤드의 변경 시간(head switch time)
*이러한 시간들은 몇 마이크로초(us) 수준으로 매우 작기 때문에
디스크 입출력 시간에서 배제하기도 함*

#### 디스크 액세스 시간과 디스크 입출력 응답 시간
**디스크 액세스 시간(disk access time)**
- 디스크가 명령을 받은 후, 목표 섹터에 접근하여 읽거나 쓰기까지 걸리는 시간
`디스크 액세스 시간 = 탐색 시간 + 회전 지연 시간 + 내부 전송 시간`

**디스크 입출력 응답 시간(disk I/O response time)**
- 호스트나 응용프로그램 입장에서 디스크 입출력에 걸리는 전체 시간
디스크 입출력 응답 시간 = 탐색 시간 + 회전 지연 시간 + 전체 전송 시간 + 오버헤드
- 디스크의 캐시에 요청된 섹터가 있는 경우, 내부 전송 과정 없이
바로 디스크 캐시에서 호스트로 전송하기 때문에 가변적

#### 디스크 액세스 시간의 정의
- 디스크 액세스 시간에서 전송 시간을 뺀 
탐색 시간과 회전 지연 시간만으로 정의하기도 함

- 혹은 디스크 입출력 응답 시간을 단순히 디스크 액세스 시간이라고 부름

### 탐구 12-1 평균 디스크 액세스/응답 시간 계산
- 평균 디스크 탐색 시간: 5ms
- 디스크의 회전 속도: 10000rpm
- 섹터 크기: 512바이트
- 트랙당 섹터 수: 1000개
- 디스크 장치와 호스트 사이의 인터페이스 전송 속도: 100MB/s
- 디스크 장치의 오버헤드: 0.1ms

`평균 디스크 액세스 시간 = 평균 탐색 시간 + 평균 회전 지연 시간 + 내부 전송 시간`
디스크의 1회전 시간 = 60초 x 1000(ms 변환) / 10000 = 6ms
디스크의 평균 1회전 시간 = 6ms / 2 = 3ms
내부 전송 속도 = 1000 x 0.5KB / 6ms = 500KB/6ms
             = 83.3KB/ms = 83.3KB / 1000(MB 변환) x (1000 초 단위 변환) 
             = 83.3MB/초
1 섹터를 읽는데 걸리는 내부 전송 시간 = 0.5KB / (83.3MB/초) = 0.006ms
평균 디스크 액세스 시간 = 5ms + 3ms + 0.006ms = 8.006ms
평균 디스크 입출력 응답 시간 = 8ms + 0.5KB/(100MB/s) + 0.1ms
                         = 8ms + 0.005ms + 0.1ms
                         = 8.105ms
```

해당 문제는 1섹터 기준의 문제이므로 값이 매우 작기 때문에
내부/외부 전송 시간을 무시 가능하지만, 수십 섹터가 되면 무시할 수 없다.

03. 디스크 스케줄링 알고리즘
3.1 디스크 큐와 디스크 스케줄링


디스크 큐에는 디스크 입출력 명령들이
여러 프로세스나 스레드로부터 동시 다발적으로 도착하거나,
하나의 프로세스로부터 연속적으로 도착

후자의 경우 한 파일을 순차적으로 읽는 경우*

디스크 큐에 들어 있는 입출력 요청들의 요청 실린더는 
중구난방으로 예상되므로, 도착 순서대로 처리하기보다 
디스크 헤드의 현재 위치와 목표 실린더의 위치를 고려하여 처리

해당 방법으로 순서를 재조정하는 디스크 스케줄링 기법 필요*


3.2 디스크 스케줄링의 목표

디스크 스케줄링의 기본 목표는 
디스크 암이 움직이는 평균 탐색 거리를 최소화하는 것

평균 디스크 탐색 시간과 평균 디스크 액세스 시간을 줄이는 것*

디스크 장치 내 프로세서는 디스크 입출력 요청을 받으면
CHS 물리 주소로 변환하여 디스크 큐에 저장

평균 탐색 거리를 최소화하는 동시에 
입출력 요청들의 응답 시간 편차를 최소화하는 것도 고려


3.3 디스크 스케줄링 알고리즘

FCFS
SSTF
SCAN
LOOK
C-SCAN
C-LOOK
디스크 스케줄링 알고리즘을 평가하는 기준은 평균 탐색 거리
총 탐색 거리 / 입출력 요청의 개수*



처음 디스크 헤드 위치: 실린더 30
요청 실린더들: 79, 68, 11, 74, 10, 89, 65, 87, 26, 15
FCFS(First Come First Served)

디스크 큐에 도착한 순서대로 요청들을 처리

디스크 큐 전체를 검색할 필요가 없어 
구현이 쉽고, 기아가 발생하지 않으며 공평함

요청 실린더들의 위치를 고려하지 않기 때문에 성능이 나쁨



SSTF(Shortest Seek Time First)

현재 디스크 헤드가 있는 실린더에서 방향에 관계없이 가장 가까운 요청 선택

기아가 발생할 수 있으며, 중간 범위의 실린더에 요청이 많은 경우
양 끝쪽 실린더는 오래 대기할 수 있음

요청이 도착하여 응답하기까지의 편차가 큼



SCAN

한쪽 실린더 끝에서 다른 쪽 실린더로 방향을 정한 후, 
그 방향으로 있는 요청들을 처리하면서 이동

엘리베이터(elevator) 알고리즘이라고도 부름

SSTF에 비해 입출력 요청이 균등하게 처리됨

높은 처리율보다 입출력 요청을 공평하게 스케줄링하고자 하는 경우*




실린더 끝까지 이동 후 방향 전환

LOOK

SCAN과 같이 작동하지만, 현재 이동 방향으로 더 이상의 요청이 없는 경우
실린더 끝까지 가지 않고 즉시 이동 방향을 바꿈
대기 중인 요청이 없음에도 불구하고 맨 끝 실린더까지 이동하는
SCAN의 단점을 보완*


C-SCAN(Circular SCAN)

SCAN의 수정 버전으로, SCAN보다 더 균등한 서비스를 위해 보완된 알고리즘 

맨 바깥쪽 실린더에서 맨 안쪽 실린더로
한 방향으로만 이동하면서 요청을 처리

SCAN의 경우 중간 실린더에 위치한 요청들이 선택될 확률이 높음

요청 실린더 위치에 따라 서비스가 균등하지 않음*

바깥쪽으로 더 이상 요청이 없어도 
실린더 끝까지 헤드를 이동시키는 비효율성



C-LOOK

LOOK + C-SCAN

요청이 없어도 디스크 헤드를 끝 실린더로 이동시키는 C-SCAN의 단점 보완

이동하는 방향으로 요청이 없는 경우 
바로 바깥쪽 실린더에서 가장 가까운 요청으로 한 번에 이동



디스크 알고리즘 성능 비교

디스크 알고리즘 특성 비교

디스크 스케줄링에 대한 최근 경향

SSD(Solid State Disk)의 사용이 늘어나고 있어
디스크 스케줄링은 과거보다 덜 중요해짐

SSD는 디스크 장치와 달리 
헤드를 움직이는 모더와 기계 장치가 없는 반도체식 기억 장치

탐색과 회전 지연 시간이 없어 디스크 스케줄링이 필요하지 않음*


04. 디스크 포맷
4.1 저수준 포맷팅(LLF, Low Level Formatting)

하드 디스크의 플래터에 트랙과 섹터를 구분하는 정보를 기록하여
디스크 헤드가 섹터와 트랙을 인식할 수 있게 하는 작업

초기에는 하드 디스크 사용자가 직접 저수준 포매팅 진행

디스크 용량이 증가함에 따라, 디스크 밀도가 높아지고 
일반 사용자가 하기 힘들어지며 공장에서 저수준 포맷이 된 채로 출시됨

공장에서 저수준 포맷이 된 채로 출시되기 때문에
저수준 포맷을 하는 상용 소프트웨어들은 
디스크에 기록된 정보를 모두 지우는 제로필(zero fill) 작업만 진행

저수준 포맷팅은 섹터 크기에 따라
512 바이트 섹터 포맷과 4K 포맷(4096바이트 섹터 포맷)으로 나뉨


512바이트 섹터 포맷

과거 플로피 디스크나 하드 디스크에서 전통적으로 사용


GAP
다음 섹터를 읽기 전 플래터가 회전하는 동안
디스크 헤드가 준비하는 약간의 시간을 벌기 위해 삽입된 공간
SYNCH
디스크 헤드가 GAP의 끝을 인식하도록 약속된 코드
Address Mart
섹터의 물리적 주소가 새겨지는 공간
[트랙 번호, 헤드 번호, 섹터 번호]
512바이트의 섹터 공간
ECC(Error Correction Code)
읽거나 쓰는 과정에서 
손상된 섹터의 복구나 교정을 위해 추가 기록되는 데이터
4K 포맷

기존의 8개의 섹터를 하나의 섹터로 만든 것

고급 포맷(Advanced Format) 혹은 4K 섹터 포맷



디스크의 저장 효율 향상

4KB당 405바이트의 저장 공간 이득을 볼 수 있음

오류 수정 능력을 대폭 향상

ECC를 4KB당 하나만 두는 것으로 하는 대신 
기존 50바이트의 ECC를 100바이트로 늘림

디스크 입출력 성능 향상

현대의 응용프로그램의 크기가 커짐에 따라 4KB 단위의 입출력이 효율적

가상 메모리 체제에서의 페이지 크기가 4KB

가상 메모리 크기와 섹터 크기를 맞춤에 따라 섹터 위치 계산이 편해짐*


과거부터 사용하던 512바이트 버퍼를 
4K 섹터 디스크 컴퓨터에서 실행 시 문제가 발생함

4K 섹터로 포맷된 디스크 장치들 중에는 
물리적으로는 한 섹터를 4K 단위로 읽고 쓰지만
호스트에게는 한 섹터가 512바이트인 것처럼 보이도록 함-emulate

이러한 4K 디스크를 512 에뮬레이션 디스크 장치 혹은 512e라고 부름

읽기 요청 시, 4K 섹터를 물리적으로 읽고 그 중 요청된 512 바이트를 전송*


TIP 불량 섹터(bad sector)

하드 디스크의 플래터에 결함이 발생하여 읽고 쓸 수 없는 섹터

물리적 불량 섹터

디스크 헤드의 플래터 직접 접촉이 원인

SSD의 경우 저장 셀(cell)의 노후화

하드 디스크는 제조 과정에서 발생할 수 있음

물리적 불량 섹터는 고칠 수 없음


논리적 불량 섹터

섹터를 기록하는 도중에 갑작스럽게 컴퓨터가 꺼지는 경우 발생

섹터에 기록된 코드와 ECC(오류 정정 코드)의 불일치

디스크 장치가 불량 섹터로 처리*

기록된 정보의 손실은 일어날 수 있으나 수리 과정을 통한 재사용 가능


불량 섹터의 관리 주체

1990년대 이전, 여분 섹터가 존재하지 않아, 
운영체제가 파일 시스템을 통해 관리

운영체제의 파일 시스템에 의해 관리되지 않고,
디스크 장치의 펌웨어에 의해 관리됨

디스크 장치는 불량 섹터 리스트, 여분의 온전한 섹터(spare sectors)를 가짐

불량 섹터 발견 시, 스스로 여분 섹터로 매핑시켜
운영체제는 불량 섹터에 대해 알지 못함


4.2 고수준 포맷팅(HLF, High Level Formatting)

저수준 포맷된 하드 디스크를 여러 개의 파티션(논리적인 공간)으로 나누고,
각 파티션에 파일 시스템을 구축하는 과정

디스크의 저장 공간을 파티션(partition)으로 분할하는 과정부터 시작

디스크에는 여러 개의 파티션을 둘 수 있으며, 
파티션마다 서로 다른 운영체제를 선택할 수 있음

단, 부팅은 그 중 한 파티션에서만 이루어짐*

디스크를 포맷하고 파티션 나누는 방법은 두 방식이 있음

MBR/GPT 포맷*


MBR 포맷 - 전통 방식


파티션에 관한 정보는 부트 섹터에 기록됨
이 부트 섹터를 MBR(Master Boot Record)이라고 하며, 크기는 512바이트*


MBR의 구성

부트 로더 
446바이트로 부팅시 실행되는 프로그램

파티션 테이블
64바이트로 최대 4개의 파티션 정보 기록. 각 파티션 정보는 16바이트

매직 번호
2바이트 크기로 0xAA55 값 기록. 0xAA55가 아니면 MBR이 아니라고 판단




파티션을 나누지 않았을 때에는 파티션이 1개만 있는 것

파티션 테이블에도 1개만 유효함*

부팅이 시작되면 MBR에 저장된 부트 로더 프로그램이 메모리에 적재/실행됨

파티션 테이블을 검사하여 현재 부팅할 운영체제를 담고 있는
활성 파티션(active partition)을 찾음

이후 활성 파티션의 부트 섹터를 메모리에 적재시키고 코드를 실행*

파티션 개수가 제한적이고 파티션 정보에서 섹터 개수를 나타내는 비트가 32

한 파티션이 2$^{32}$개의 섹터까지 가능*

한 섹터의 크기가 512바이트이면, 2$^{32}$ x 0.5K = 2TB가 파티션의 최대 크기*

4K 섹터 디스크의 경우, 섹터 크기가 8배이므로 
파티션의 크기가 16TB까지 가능

그러나 MBR 포맷 사용 시, 
섹터 크기를 512바이트로 다루고 있기 때문에 파티션의 크기가 2TB로 고정됨



MBR 방식의 단점은 파티션의 크기가 2TB로 제한되며 부팅 속도가 느림

GPT(GUID partition table) 포맷 - 현대 방식

UEFI(Unfixed Extensible Firmware Interface) 펌웨어를 가진 
컴퓨터에서만 사용하는 포맷 방식

2TB 이상의 파티션을 만들 수 없는 MBR의 문제점을 개선

최근에 나온 대부분의 컴퓨터는 UEFI 펌웨어를 내장하고 있기 때문에
MBR 포맷이나 GPT 포맷 중 선택하여 사용할 수 있음



1) 보호 MBR 섹터가 첫 번째 섹터에 있는 이유

GPT 포맷 디스크를 MBR 포맷 디스크로 보이게 하려는 목적

사용자가 GPT 포멧 디스크에 MBR 포맷만 다루는 유틸리티를 실행했을 때,
이 유틸리티가 현재 디스크에 훼손이 발생한 것으로 오인하여
디스크를 포맷하거나 훼손하는 등의 오작동을 막기 위함*

보호 MBR 섹터의 구조를 MBR 포맷의 첫 섹터와 동일하게 구성

파티션 테이블의 첫 번째 항목의 섹터 개수를 최대치(0xFFFFFFFF)로 기록

전체 디스크를 모두 사용하고 있다고 착각하게 만듦*

보호 MBR은 MBR 포맷과의 호환성은 유지하면서
MBR 포맷만 지원하는 유틸리티가 GPT 포맷 디스크를 잘못 인식하여
덮어쓰는 것을 방지하기 위함


2) MBR 섹터의 파티션 테이블에서 
첫 번째 파티션 항목의 파티션 타입 필드 값을 0xEE로 기록

GPT 포맷을 다루는 소프트웨어들에게 
현재 디스크가 GPT 포맷임을 나타내기 위해

3) 진짜 파티션 테이블은 GPT 헤더 다음에 구성됨

총 128개까지 파티션이 가능

한 파티션의 크기는 18엑사바이트(Exa Byte)까지 가능*

GPT헤더의 구성 요소

파티션 테이블의 개수
파티션 테이블이 시작하는 디스크의 위치
각 항목의 크기
파티션 테이블 항목 개수
파티션 테이블의 오류 확인을 위한 체크섬(checksum) 정보 등*


4) GPT 헤더와 파티션 테이블을 이중화

GPT 헤더와 파티션 테이블은 디스크의 마지막 영역에 백업본을 둠
기본 GPT 헤더와 파티션 테이블이 손상될 때 복구 가능-높은 신뢰도*

MBR 포맷 디스크의 부팅

UEFI를 지원하지 않는 컴퓨터 디스크는 MBR 포맷으로 포맷팅되어야 하며,
기존 BIOS 펌웨어에 의해 부팅됨

*1) *전원이 켜지면 CPU는 BIOS 펌웨어 코드의 실행을 시작하여
메모리나 기타 장치들을 테스트하고 초기화
*2) *BIOS 안에 작성된 부트스트랩 코드를 실행
3) *부트스트랩 코드는 하드 디스크의 첫 번째 섹터인
MBR 섹터를 메모리로 읽어들이고 그곳으로 점프
*MBR 섹터의 첫 번째 부분에 부트 로더가 작성되어 있음
*4) *CPU가 이 코드를 실행하면 활성 파티션을 찾고 
활성 파티션의 부트 섹터를 메모리로 읽어들이고 실행시킴
*5) *부트 섹터의 코드는 자신의 파티션에 설치된 운영체제 커널을 메모리로 적재
*6) *커널로 제어를 넘기고, 커널 코드로 점프하여 
커널 코드를 실행하면 필요한 프로세스가 생성됨
GPT 포맷 디스크의 부팅
*1) *전원이 켜지면 컴퓨터에 장착된 UEFI 펌웨어가 실행됨
2) *UEFI 펌웨어에 저장된 EFI 변수를 읽음
*EFI 변수에는 부팅 순서, 부트 로더의 경로명 등 부팅에 관한 정보가 저장됨
*3) *기본 파티션 테이블에서 EFI 시스템 파티션 탐색

EFI 파티션은 FAT32로 포맷된 특별한 파티션

권장 크기는 100~550MB*

이 파티션 안에 디스크에 설치된 
모든 운영체제들의 부트 로더 프로그램이 저장되어 있음


*4) *UEFI 펌웨어는 EFI 변수에 지시된 부팅 순서에 따라
EFI 파티션에서 부트 로드 프로그램을 찾아 실행
*5) *부트 로더 프로그램은 해당 운영체제를 메모리에 적재한 후
커널 코드로 점프하여 커널 코드에 의해 프로세스 생성
BIOS와 UEFI 펌웨어

BIOS(Basic Input Output System)나 UEFI는 
컴퓨터 마더보드(mother board 또는 main board)에 장착된 
ROM(BIOS의 경우)이나 플래시 메모리와 같은 
비휘발성 메모리에 저장된 소프트웨어

전원이 켜지는 시점에 실행되는 최초의 프로그램

컴퓨터 메모리나 하드웨어들을 테스트하고 초기화하며 컴퓨터를 부팅시킴

UEFI는 운영체제와 마더보드나 
주변 장치 내에 장착된 펌웨어 사이의 매개 역할

실질적으로 장치들과 입출력 버스 등을 제어하는
마더보드 펌웨어 위에서 실행되는 작은 운영체제

과거 BIOS를 레거시 BIOS라고 하는게 좋음

UFEI와 BIOS를 구분하지 않기 때문*


Windows에서 파티션 나누고 사용하기

D:, E: 등의 논리 드라이브로 사용
복구 파티션(recovery partition)
진단 도구나 진단 데이터를 저장하는 파티션


리눅스에서 파티션 나누고 활용하기

리눅스, MacOS 등 Unix-like 운영체제에서 각 디스크 파티션에는
파일 시스템이 구축되거나 파티션이 통째로 스왑 영역으로 사용됨



많은 경우 파티션을 디렉터리에 연결하여 
전체를 하나의 파일 시스템으로 사용

이 것을 * 마운트(mount) 라고 함

3개의 파일 시스템을 디렉터리에 마운트시켜
전체를 하나의 파일 시스템처럼 사용

다른 파티션에 연결하기 위해 사용되는 home이나 kitae 디렉터리를
마운트 포인트(mount point)라고 함

마운트 포인트는 다른 파티션에 설치된 파일 시스템의 루트 디렉터리가 됨*


05. SSD 저장 장치

SSD(Solid State Drive, Solid State Disk)는 
플래시 메모리(flash memory)를 저장소로 사용한 비휘발성 기억 장치

메모리 계층 구조의 최하단에 위치하는 보조 기억 장치

하드 디스크와 달리 회전하는 디스크나 모터, 움직이는 헤드 등
기계 부품을 사용하지 않는 순수한 반도체 기억 장치

디스크보다 값이 비싸지만 입출력 속도가 5~50배 정도 빠름



5.1 SSD 장치의 구조와 인터페이스

SSD는 4개의 하드웨어 요소로 구성됨
플래시 메모리
DRAM 캐시
호스트 인터페이스
SSD 제어기*



플래시 메모리

SSD의 내부 저장소

플래시 제어기에 의해 읽혀지고 기록됨


DRAM 캐시

입출력 성능을 높이기 위해 DRAM 캐시를 두고 있음

DRAM을 장착한 SSD는 상대적으로 고가

디스크 캐시와 비슷한 목적으로 사용되어 
읽은 데이터나 쓸 데이터를 임시 저장

정전이 발생하면 DRAM 캐시에 들어 있는 데이터를 모두 잃음

이 때문에 DRAM을 사용하지 않는 제조업체도 있음*


호스트 인터페이스 회로

SSD 장치와 호스트를 연결하는 물리적인 인터페이스

SATA(Serial ATA)
SAS(Serial attached SCSI)
PCIe(PCI express) 등의 여러 가지가 존재함

가장 많이 사용되는 타입은 PCIe이며, 
PCIe 인터페이스를 가진 SSD를 NVMe 드라이브라고 함


SSD 제어기(SSD Controller)

SSD 장치에서 가장 중요한 부분

호스트로부터 받은 데이터를 플래시 메모리에 기록하고
플래시 메모리로부터 읽은 데이터를 호스트로 전송

전반적인 작업을 제어함*

논리 블록 주소를 물리 블록 주소로 바꾸는 매핑 테이블을 만들고 관리

논리 주소의 물리 주소 변환

wear leveling와 같은 
플래시 메모리에서 새로운 페이지를 저장할 장소 찾기나

garbage collection* 등의 기능을 수행함

SSD 제어기는 하나의 칩(SoC, System on Chip)으로 만듦

SSD 제어기 내부 플래시 메모리 알고리즘은 SSD 제조업체의 경쟁력

공개하지 않고 있음*


5.2 SSD 메모리의 논리 구조
페이지와 블록


플래시 메모리는 여러 개의 블록들로 구성되며 
각 블록은 다시 페이지(page)들로 구성됨


SSD 장치 내에서 플래시 메모리에 읽고 쓰는 단위는 페이지


플래시 메모리의 페이지는 
운영체제의 가상 메모리에서 다루는 페이지와는 아무런 관계가 없음

응용프로그램이 한 바이트를 읽거나 쓰고자 했어도, 페이지 단위로 읽고 씀

페이지 크기는 보통 4KB16KB, 블록 크기는 128KB256KB

공정 기술이 발전함에 따라 크기도 커지는 추세*

하드 디스크와 달리, 
블록이나 페이지의 위치에 따라 액세스 하는 시간이 다르지 않음


주소 변환

운영체제의 파일 시스템은 SSD를 디스크 장치로 인식

SSD에 대해서도 똑같이 액세스하고자 하는 데이터의 
논리 블록 번호(LBA) 발생

플래시 메모리에 저장된 각 논리 블록에 대해
플래시 메모리의 블록 번호와 페이지 번호를 나타내는 
주소 변환 테이블을 만들고 유지 및 관리

블록 읽기/쓰기 시 주소 변환 테이블 참조*


5.3 SSD의 플래시 변환 계층

하드 디스크를 기반으로 하는 운영체제의 파일 시스템은
디스크를 섹터 단위로 인식함

SSD에서는 페이지 단위로 인식함


섹터를 기반으로 하는 기존 파일 시스템은 SSD를 읽고 쓸 수 없음

이를 해결하기 위해 SSD 제어기 내에 
플래시 변환 계층(FTL, Flash Translation Layer)이라는 펌웨어를 둠

플래시 변환 계층은 SSD 내부의 물리적 특성을 
운영체제로(파일 시스템)부터 숨김




플래시 변환 계층은 운영체제의 파일 시스템에게
SSD가 섹터 기반의 저장소로 보이게 함

하드 디스크와 달리 SSD에서는 
논리 블록이 저장된 물리 페이지 주소와 함께 주소 변환 테이블도 계속 바뀜

특이한 페이지 쓰기 방식과 가비지 컬렉션 때문*

주소 변환 테이블은 
SSD 제어기의 내부 메모리(RAM)과 SSD 플래시 메모리에 저장됨

작동을 시작할 때 플래시 메모리로부터 내부 메모리로 읽어 들임*

SSD의 용량이 커지면 주소 변환 테이블도 같이 커지는 약점 존재*


5.4 SSD 입출력 동작
페이지 읽기(read)

플래시 메모리에서의 페이지 읽기는 단순히 해당 페이지를 읽기만 하면 됨

페이지 쓰기/프로그램(write/program)

플래시 메모리에 쓰기를 프로그램(program)이라고 부름

동일한 페이지에 덮어쓰기는 불가능하며,
오직 빈 페이지에만 쓸 수 있음

SSD가 빈 페이지를 찾고 그 곳에 데이터를 기록

빈 페이지를 만들기 위해서는 지우기 연산이 이루어져야 함

이미 기록된 페이지를 수정하는 경우 read-modify-write 연산을 실행



1) 페이지 읽기(read) - SSD 제어기의 메모리로 페이지 읽어 들이기
2) 페이지 수정(modify) - SSD 제어기의 메모리에서 페이지 수정
3) 페이지 쓰기(write) - 수정된 페이지를 새로운 빈 페이지를 찾아 기록
*4) * 플래시 메모리의 이전 페이지를 dirty 또는 stale로 표시

플래시 메모리는 쓰기와 지우기 횟수에 제한이 있기 때문에
특정 블록에 작업이 반복되면 블록의 수명이 빨리 다하게 됨

각 페이지에 대해 비거나, dirty/stale, 유효한(valid)페이지 상태 정보는
SSD 제어기에 의해 따로 관리됨

SSD가 데이터를 읽거나 빈 페이지에 데이터를 쓰는 속도는 매우 빠르지만,
페이지를 수정하는 속도는 매우 느림

페이지를 수정하여 다시 기록할 때마다 주소 변환 테이블도 같이 수정됨*

빈 페이지를 동일한 블록에서 찾을 필요는 없음


블록 지우기(erase)

플래시 메모리에서 쓰기와 지우기는 서로 다른 기능

플래시 메모리는 블록 단위로 데이터를 지움

높은 전압이 걸리면 주변 셀들의 값이 훼손될 수 있기 때문*

블록 지우기는 SSD가 가비지 컬렉션을 수행할 때
빈 블록을 확보하기 위해 내부에서 벌어지는 동작


가비지 컬렉션(garbage collection)

블록 내 페이지들의 수정이 계속되어 
dirty 페이지가 많아지고 빈 페이지가 없을 때 
SSD 제어기에 의해 가비지 컬렉션이 수행됨

값이 기록된 페이지(valid)들을 다른 페이지들을 

다른 블록의 빈 페이지로 복사*하고 원본 블록들을 지우는 과정



웨어 레벨링(wear leveling, 균등 쓰기 분배)

플래시 메모리의 모든 블록에 쓰기를 균등하게 분배하여
특정 블록에 대한 과도한 쓰기를 막음

플래시 메모리 블록은 쓰거나 지우기 횟수에 비례하여 닳아(wear)감

읽기는 영향을 주지 않고 쓰기가 영향을 줌

SSD 제어기는 플래시 메모리의 각 블록마다 지우기 횟수를 기억하고 
쓰기 시, 지우기 횟수가 가장 적은 블록을 선택함


5.5 SSD의 용도

SSD의 저장소 역할을 하는 NAND 플래시는 
오랜 시간 동안 전원이 공급되지 않으면 전하(charge)가 누출되어
저장된 데이터가 지워짐

백업 저장 목적에는 적합하지 않음*

읽기가 많은 운영체제 코드나 프로그램을 설치하는 용도로는 적합하지만,
쓰기나 수정 작업이 많은 스왑 영역이나 
파일이 임시로 생성되었다가 지워지는 임시 파일 시스템에 적합하지 않음





브로드캐스트 리시버, 컨텐트 리졸버
Sat, 30 May 2026 04:56:08 GMT
학습목표

브로드캐스트 리시버의 개념을 이해하고 사용할 수 있다.
컨텐트 프로바이더와 리졸버 개념을 이해하고 컨텐트 리졸버를 사용할 수 있다.
다중 동적 권한 요청을 이해하고 사용할 수 있다.

브로드캐스트 리시버(Broadcast Receiver)
시스템이나 다른 앱이 방송하는 메시지를 받는 리시버
시스템 이벤트시 방송

시스템 부트 완료, 충전 시작, 네트워크 연결 변경, 문자 수신 등의 이벤트
문자 수신과 같은 민감한 정보는 권한을 필요로 함

사용 방법

BroadcastReceiver 상속한 클래스, onReceive() 재정의
ContextCompat.registerReceiver()로 1번의 클래스 객체 등록
이 때 수신할 방송 종류를 IntentFilter로 정의하여 포함*
앱이 보내는 방송을 수신은 ContextCompat.RECEIVER_EXPORTED 플래그 설정*
더 이상 수신 할 필요가 없을 때 unregisterReceiver() 호출*

BroadcastReceiver 클래스 상속
onReceive() 재정의
class MyBroadcastReceiver(private val onReceiveMessage:
(String, String) -> Unit) : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) { ... }
}
수신자 등록/해지, 수신자에게서 메시지 받는 콜백
private fun startBroadcastReceiver() {
    IntentFilter().also {
        it.addAction(Intent.ACTION_POWER_CONNECTED)
        it.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED)
        it.addAction(Telephony.Sms.Intents.SMS_RECEIVED_ACTION) // 권한 필요
        ContextCompat.registerReceiver(this, broadcastReceiver, it, ContextCompat.RECEIVER_EXPORTED)
    }
}
override fun onStart() {
    super.onStart()
    startBroadcastReceiver()
}
override fun onStop() {
    super.onStop()
    unregisterReceiver(broadcastReceiver)
}
필요한 권한 등록, 동적 권한 요청
Telephony.Sms.Intents.SMS_RECEIVED_ACTION에 필요한 권한
AndroidManifest.xml에 권한 표시


동적 권한 요청

1개 권한 요청
rememberLauncherForActivityResult(
  contract = ActivityResultContracts.RequestPermission(),
  onResult = 결과 받을 람다
).launch(요청할 권한)

2개 이상 권한 요청
rememberLauncherForActivityResult(
  contract = ActivityResultContracts.RequestMultiplePermission(),
  onResult = 결과 받을 람다
).launch(요청할 권한들의 배열)


Content Provider / Resolver

안드로이드에서 다른 앱에 데이터를 제공해주기 위해 표준화된 인터페이스
적절한 데이터 은닉과 보호 기능 제공*


Content Resolver

Content Provider에 접근하기 위한 방법
CRUD - Create, Retrieve, Update, Delete 기능 제공
Content Provider에 따라 접근 권한이 필요한 경우가 있음
CallLog:READ_CALL_LOG*

사용 방법(데이터 읽기, Retrieve)

1) Context에서 ContentResolver 객체 가져오기
2) query로 컨텐츠 URI와 조건 등을 명시해서 실행, cursor 리턴
Create, Update, Delete의 경우, query 대신 insert, update delete 사용*
3) cursor를 사용하여 데이터 읽기

Content URI

query, insert, update, delete 모두 첫 번째 인자가 Content URI
Content URI는 접근하려는 content provider의 주소

cursor = context.contentResolver.query(
    android.net.Uri.uri, // Content URI, ex) CallLog.Calls.CONTENT_URI, 
    String[] projection, // 가져올 테이블의 칼럼 이름
    String selection, // 조건, SQL의 WHERE 절과 유사
    String[] selectionArgs, // selection의 ?에 들어갈 인자
    String sortOrder // SQL의 ORDER BY에 해당
)
cursor.moveToNext()
cursor.getColumnIndex(.getString or .getLong) // 칼럼 인덱스
권한 확인
private fun hasPermission(perm: String) = 
    context.checkSelfPermission(perm) == PackageManager.PERMISSION_GRANTED
필요한 권한 등록







Broadcast와 ContentResolver를 함께 응용

SMS를 수신 후 발송자 이름을 주소록에서 조회
추가로 필요한 권한 READ_CONTACTS
permissions += Manifest.permission.READ_CONTACTS





CD 파이프라인 해설
Wed, 27 May 2026 08:12:54 GMT
CD (Continuous Development)
Job 1.: Docker 빌드 + E2E 테스트
Job 2.: GHCR에 이미지 등록
Job 3.: GitHub Pages 배포
핵심 흐름
코드 push → 도커 이미지를 빌드해서 E2E 통과
→ 컨테이너 레지스트리 (GHCR)에 이미지 올리기
→ 정적 파일은 GitHub Pages로 웹 배포
GitHub Pages: GitHub에서 제공하는 웹 서버
용어 정리

Part 1.
워크플로우 메타데이터
name: CD

on: 
  push:
    branches: [main]

name: 워크플로우 이름. GitHub Actions 탭에 그대로 노출
on: 트리거를 정의하는 키워드
push: push 이벤트 발생 시 실행
branches: main 브랜치에 push될 때만 실행

워크플로우 권한
permissions: 
  contents: read
  packages: write
  pages: write
  id-token: write
필요한 권한만 명시적으로 부여

contents: read: 저장소 코드를 읽기만 함 (체크아웃에 필요)
packages: write: GHCR에 도커 이미지를 업로드하므로 쓰기 권한 필요
pages: write: GitHub Pages 배포에 필요한 쓰기 권한
id-token: write: OIDC 토큰 발급용. 비밀번호 없이 신원을 증명

환경 변수
env:
  IMAGE_NAME: ghcr.io/${{ github.repository }}
워크플로우 전체에서 쓸 환경 변수

IMAGE_NAME: 도커 이미지의 풀네임
${{ github.repository }}: GitHub이 자동으로 채워주는 사용자명/저장소

Part 2.
Job 1. 정의 + outputs
jobs:
  build-and-e2e:
    name: 1) Docker + E2E
    runs-on: ubuntulatest
    outpits:
      image-tag: ${{ steps.meta.outputs.tag }}

build-and-e2e: 이 job의 고유 ID

체크아웃 + 커밋 태그 만들기
steps:
  - uses: actions/checkout@v4
  - id: meta
    run: echo "tag=sha-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"

${GITHUB_SHA::7}: 현재 커밋 해시의 앞 7자리만 잘라냄

Docker 빌드 + 컨테이너 실행
- run: docker build -t calculator:test .

- run: docker run -d --rm --name calc -p 8080:80 calculator:test

-d: detached 백그라운드 모드로 실행
-rm: 컨테이너가 멈추면 자동 삭제
--name calc: 컨테이너 이름을 calc로 지정
p 8080:80: 호스트 8080 포트를 컨테이너 80포트에 연결

컨테이너 헬스체크
- name: 
  run: |
    for i in {1..20}; do
      if curl -sf http://localhost:8080 >dev/null; then echo OK; exit 0; fi
      sleep 1
    done
    exit 1

응답이 오면 exit 0 → 다음 step으로
20번 다 실패하면 exit 1 → 워크플로우 중단

Node 환경 + Playwright 준비
- uses: actions/setup-node@v4
  with:
    node-version: "20"
    cache: "npm"
- run: npm ci
- run: npx playwright install --with-deps chromium
E2E 실행 + 컨테이너 정리
- env:
    BASE_URL: http://localhost:8080
  run: npm run test:e2e

- if: always()
  run: docker stop calc || true

BASE_URL: 코드가 어디로 접속할지 알려주는 환경 변수
if: always(): 이전 step의 성공/실패와 무관하게 무조건 실행
||true: stop이 실패해도 워크플로우 전체를 실패시키지 않도록 무시

Part 3.
Job 2. 정의 + GHCR 로그인
push-image:
  name: 2) GHCR
  runs-on: ubuntu-latest
  needs: build-and-e2e
...
 - uses: docker/login-action@v3
   with:
     registry: ghcr.io
     username: ${{ github.actor }}
     password: ${{ secrets.GITHUB_TOKEN }}

needs: bulid-and-e2e: 이전의 job이 성공해야만 실행 (안전장치)
secrets.GITHUB_TOKEN: 매 실행마다 만들어지는 일회용 토큰

... 등
핵심 키워드

자주 발생하는 오류




CI 파이프라인 해설
Wed, 27 May 2026 06:50:59 GMT
CI (Continuous Integration)
역할
코드 품질 검사

스타일 규칙 위반
보안 취약점
각 함수/모듈
모듈끼리의 연동

4가지 검사
1) 린트

ESLint를 통한 코딩 스타일 검사2) 보안

npm audit를 통한 보안 취약점 검사 

3) 단위 테스트

Jest를 통한 각 함수 검증

4) 통합 테스트

Jest + jsdom을 통한 모듈 연동 검증
jsdom: Node.js안에서 가상의 브라우저 DOM을 흉내내는 라이브러리*

4개의 검사는 서로 의존하지 않으며, 병렬로 실행됨
하나라도 실패하면 merge 불가능
Part 1.
워크플로우 이름
# CI - PR이 열릴 때, 그리고 main에 push될 때 자동으로 실행
name: CI

#: 주석으로 YAML이 무시하지만, 사람이 읽을 때 도움
name: CI-workflow의 이름을 CI로 지정
GitHub의 Actions 탭에 name이 그대로 표시됨

두 가지 트리거
on: 
  pull_request:
    branches: [main]
  push:
    branches: [main]

main에 대해 push, PR 이벤트 발생 시 실행됨

PR: merge 전 검사
push: merge 후 검사 → main과 기능이 섞일 수 있기 때문*

CD는 push만 트리거


Part 2.
Job 1. lint + checkout
jobs:
  lint:
    name: 1) 린트 검사 (ESLint)
    runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

lint: 이 job의 고유 ID
name: UI에 보이는 이름 (한글도 가능)
runs-on: ubuntu-latest: 최신 우분투 가상머신 사용
actions/checkout@v4: 저장소 코드를 가상머신으로 다운로드

Node 설치 + 의존성 설치
- uses: actions/setup-node@v4
  with:
    node-version: "20"
    cache: "npm"
- run: npm ci
Lint 실행
- run: npm run lint

위반 사항 발견 시 0이 아닌 종료 코드 → step 실패 → job 실패
미사용 변수, 들여쓰기, 따옴표 스타일, 세미콜론 누락, == 대신 === 권장

Part 3.
Job 2. security 정의 + 준비
security:
  name: 2) 보안 검사 (npm audit)
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
    with:
      node-version: "20"
      cache: "npm"
    - run: npm ci

의존성 패키지의 보안 취약성을 검사하는 작업

각 job은 완전히 새로운 가상 머신에서 실행하기 때문에
모든 준비를 처음부터 다시 해야 함

job 1.에서 설치한 것들을 다시 설치하는 이유*


보안 검사 실행
- run: npm run audit

내부적으로 npm audit --audit-level=high 같은 명령을 호출

심각도가 높은 취약점이 발견되면 0이 아닌 종료 코드 → job 실패

npm run audit != npm audit

두 명령어는 서로 다른 명령임*


Part 4.
Job 3. unit-test 정의 + 준비
unit-test:
  name: 3) 단위 테스트 (Jest)
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: "20"
      cache: "npm"
  - run: npm ci
단위 테스트 실행
- run: npm run test:unit
검증 대상

순수 함수의 입출력
add(2, 3) == 5 인지 확인

유틸리티 함수의 동작
formatDate('2026-04-30')의 결과 검증

예외 처리
divide(1, 0)이 에러를 던지는지 확인

경계값(edge case)
빈 배열, null, undefined 입력 시 동작


*DB, 네트워크, 파일 시스템은 사용하지 않음*
빠르고 환경에 관계없이 같은 결과가 나옴
Part 5.
Job 4. integration-test 정의
integration-test:
  name: 4) 통합 테스트 (Jest + jsdom)
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: "20"
        cache: "npm"
    - run: npm ci
통합 테스트 실행
- run: npm run test:integration

jsdom은 document나 윈도우 브라우저 객체를 가짜로 만들어줌

Node.js는 서버용이라 document나 윈도우 같은 브라우저 객체가 없음*

실제 브라우저를 띄우지 않고도 dom 조작 코드를 실행할 수 있게 해줌*

E2E 테스트(Playwright)보다 훨씬 빠르고, 단위 테스트보다 현실적

E2E 테스는 Docker 컨테이너를 실제로 띄워야 하기 때문에 무겁고 느림*

보통 CI에서는 가볍고 빠른 검사를 진행함*


단위 테스트 vs 통합 테스트 차이

4개 Job의 공통 패턴
# 모든 job의 공통 패턴
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: "20"
      cache: "npm"
  - run: npm ci
  - run: npm run XXX

핵심 키워드

자주 만나는 오류




Ralph Loop
Wed, 27 May 2026 05:54:13 GMT
Ralph Loop

심슨 가족의 어린이 캐릭터 Ralph Wiggum에서 유래
화려한 프롬프트 엔지니어링이나 복잡한 에이전트 구조 없이
같은 프롬프트를 단순히 반복 실행

4가지 원칙

같은 프롬프트를 반복한다.(PROMPT.md를 그대로 매번)
AI는 매번 새 컨텍스트로 시작한다.(이전 대화를 기억하지 않음)
모든 정보는 파일에 저장한다.(SPEC.md, PROGRESS.md)
한 번에 한 작업만 한다.(작은 성공의 누적)

사용 분야
적합한 분야

완료 기준이 명확한 앱 (Todo, 가계부, 메모 등)
테스트로 검증 가능한 기능 단위

부적합한 분야

창의적 디자인
성능 최적화(전체 맥락을 필요로 하므로)

필요한 파일
SPEC.md

무엇을 만들지 정의하는 파일
AI는 이 파일을 절대 수정하지 않음

PROMPT.md

매 반복마다 AI에게 똑같이 전달할 지시문

PROGRESS.md

진행 상황 추적
매 반복마다 AI가 직접 갱신*

실행 스크립트

위 셋을 묶어서 반복




CI/CD 구축 with GitHub Actions
Wed, 27 May 2026 05:43:30 GMT

GitHub Actions

깃허브에서 제공하는 자동화 플랫폼
개발자가 코드를 올리거나 변경하는 특정 이벤트 발생 시,
미리 정의해둔 작업들을 자동으로 실행
깃허브 액션을 실행시키는 주요 이벤트 트리거로는, 
push, pull request, web hook 등이 있음

CI/CD와 GitHub Actions의 관계

개발자가 코드를 수정하면, 
자동으로 빌드하고 테스트 환경을 거쳐 코드의 품질을 검증* - CI*

이후 지속적 배포를 통해 검증된 코드를 실제 서비스 환경인
프로덕션에 자동으로 배포 * - CD*

GitHub Actions는 이 전체 파이프라인 과정을 자동화하여, 
개발자가 코드 작성에만 집중할 수 있게 도와주고 휴먼 에러를 줄여줌


GitHub Actions workflow 분석

name: 전체 자동화 작업의 이름을 정의
on: 특정 이벤트가 발생했을 때, 이 작업이 시작될지 결정하는 설정
예시에서는 main 브랜치에 PR, Push가 발생했을 때 작동
jobs: 실제 수행할 작업들을 정의하는 구역
여러 개를 설정하여 병렬로 실행하거나 순차적으로 실행 가능
runs-on: 이 작업을 실행할 가상 머신 환경 지정
예시에서는 ubuntu-latest 최신 버전의 리눅스 환경 사용 중
steps: 세부 실행 단계

Checkout code
uses 구문을 사용해서 깃허브 저장소의 코드를 가상 환경으로 복사

Set up Node.js
with 항목을 통해 특정 노드 버전 지정

install dependencies, Run tests
run 항목을 통해 터미널 명령어를 직접 실행


CI/CD 구축을 위한 프롬프트

CI
정적 분석

코드 자체에 문제가 없는지 점검

security scan

소스 코드 및 의존성의 보안 취약점을 점검

건물을 짓기 전, 설계도와 자재를 꼼꼼히 검사하는 것과 같음
단위 테스트

비즈니스 로직이 잘 작동하는지 확인

통합 테스트

여러 모듈이 서로 잘 연결되는지 확인

CD
도커 빌드

어떤 환경에서도 동일하게 작동할 수 있도록
도커 이미지를 생성
이때 빌드 시간을 단축하고 효율성을 높이기 위해
dependency와 도커 레이어 캐싱 전략을 반드시 적용해야 함*

container security scan

이미지가 만들어진 후, 이미지 레이어 자체에 보안 문제가 없는지 확인

E2E

실제 사용자 관점에서 시스템이 전체적으로 잘 작동하는지 확인

GitHub Pages 배포

모든 테스트가 성공적으로 마무리되었을 때 진행하는 절차

upload pages artifacts, deploy pages와 같은 도구를 이용하여,
모든 절차를 수동 작업 없이 자동화


smoke test

배포된 사이트가 실제로 살아있는지, 기본적인 기능이 응답하는지 확인

배포가 끝났다고 해서 모든 과정이 완료된 것이 아님*

해당 테스트로 전체 파이프라인의 성공 여부 확정


CI 이슈 라벨 생성을 위한 프롬프트

Label Data
ci: 파이프라인 관련 이슈나 풀 리퀘스트를 식별하는 데에 사용
testing: 테스트 코드나 품질 검증 관련 작업에 할당
static-analysis: 코드의 정적 분석 결과 추적
실행 로직

GitHub CLI를 통해 일관된 명령 수행

라벨이 존재하지 않을 때, gh label create: 라벨 생성
라벨이 이미 존재할 때, gh label edit: 색상과 설명 최신화

명령어 실행 중 특정 라벨에서 오류가 발생하더라도 
전체 프로세스가 중단되지 않고 다음 라벨로 넘어가도록 설계

자동화의 안정성 확보를 위함*


CD 이슈 라벨 생성을 위한 프롬프트

Label Data
cd: CD 파이프라인과 배포 전반 담당
docker: 도커 이미지와 컨테이너화 관련 이슈
e2e-testing: playwright을 기반으로 실제 사용자 환경에서의 동작을 검증
infrastructure: 인프라 및 배포 환경 설정 관리
CI/CD 구축을 위한 프롬프트
[이슈 등록]


gh CLI 깃허브 명령줄 도구를 이용하여 이슈 생성

Phase, description, Acceptance criteria로 구성

한꺼번에 많은 요청을 보내면 시스템 부하 가능성이 있으므로,
이슈들을 하나씩 순차적으로 생성해야함


GitHub Projects 칸반보드

[구현-테스트-커밋]


gh project 명령어로 Todo 열의 가장 위에 있는 이슈 번호와 제목 추출

해당 이슈의 상태를 In Progress로 변경 후 본인을 assignee로 할당*

gh issue view 명령어로 내용 상세히 확인

이슈 번호와 요약 키워드를 조합한 피처 브랜치 생성*

실제 수용 기준인 AC를 바탕으로 실제 코드 구현

검증 통과 시 PR 생성

PR 본문에는 해당 이슈를 자동으로 닫아주는 closes 구문 추가*


CI 워크플로우

on:push
이 모든 과정이 코드가 저장소에 업로드되는 순간 시작된다는 트리거를 의미
첫 번째 단계: 코드의 기초적인 결함 검사

static analysis - ESLint
실제로 코드를 실행하지 않고도, 문법적 오류나 코딩 컨벤션 위반을 검사

Security Scan - npm audit
보안 스캔으로, 
프로젝트에서 사용하는 외부 라이브러리에 알려진 취약점이 없는지 검사

중앙의 연결선은 의존성 관계를 나타냄

기초적인 문법 오류나 보안 결함이 있는 코드에 대해
리소스가 많이 드는 테스트를 수행하지 않음

컴퓨팅 자원을 효율적으로 관리하기 위함*


두 과정은 병렬/그룹화되어 실행됨
첫 번째 작업의 모든 작업이 성공적으로 마무리되어야만 
두번째 단계로 넘어갈 수 있음
두 번째 단계: 본격적인 코드 검증

프론트엔드 환경에서 Unit Tests(단위 테스트)
각각의 함수나 컴포넌트가 독립적으로 잘 작동하는지 검증한다는 사실

Integration Tests(통합 테스트) 및 커버리지 확인
이들이 서로 연결되었을 때도 비즈니스 로직에 맞게 돌아가는지 확인

커버리지: 전체 소스 코드에 대한 테스트 코드의 비율을 수치화한 것 *


두 단계 정리

정적 분석과 보안 스캔을 통해 코드의 무결성 확인

이를 통과한 코드에 한해서만 단위 테스트와 통합 테스트를 수행


CI 정적 분석


개발자가 작성한 코드의 안정성을 실시간으로 확인하는 파이프라인 역할

워크플로우 트리거

main, develop 브랜치에 코드가 push 또는 PR 생성 시,
해당 워크플로우가 자동으로 실행되도록 설계됨
개발자가 일일이 수동으로 검사하지 않아도 되며
코드에 변경 사항이 생길 때 마다 즉각적인 피드백을 받을 수 있음*

정적 분석 단계

npm install이 아닌 npm ci를 사용하는 이유는
package-lock.json 파일을 기준으로 의존성을 엄격하게 설치

개발 환경과 CI 환경 사이의 일관성 보장을 위함*

프론트엔드와 백엔드를 독립적으로 검사함으로 인해,
각각의 영역에서 발생하는 결함을 보다 명확하게 분리해서 파악 가능


결과 요약 및 가시성

if: always() 조건문을 사용함으로써
앞선 단계들의 성공 여부에 관계없이 무조건 결과를 출력하기 위함

security scan

1) 깃허브 저장소에 있는 최신 코드를 가상 환경으로 가져옴
2) 프론트엔드 스캔
npm audit

--audit-level=high 설정
보안 취약점 중 심각도가 높은 항목이 발견될 때만 빌드를 실패하게 만듦

개발자가 사소한 경고에 지치지 않게 하며, 치명적인 위험은 확실히 잡음*

--omit=dev
배포 시 포함되는 핵심 패키지들의 안정성만 집중적으로 검증

실제 서비스 실행 시 포함되지 않는 ESLint나 Jest등의 개발 도구는 미포함*


3) 백엔드 스캔

프론트엔드 스캔과 같은 과정으로 진행됨

프론트엔드와 백엔드를 나누어 검사함으로써
어느 영역에 보안 결함이 발생했는지 즉각적인 파악 가능
CI: 보안 검사

Trivy

라이브러리 내의 보안 취약점 검사

파일 시스템을 뜻하는 fs 모드를 통해 프로젝트 전체를 검사

HIGH, CRITICAL 단계의 문제만 집중하도록 만듦

해결 방법이 나오지 않은 문제는 ignore-unfixed 옵션으로 제외*

개발자가 수정 가능한 실질적인 위협에만 집중할 수 있도록 함*

exit-code: 1
치명적인 보안 결함 발견 시, 빌드 과정 강제 종료

모든 검사 결과는 Github Step Summary를 통해 깔끔한 표 형태로 출력


CI 단위 테스트

needs

앞 단계인 static-analysis와 
보안 스캔 단계인 security scan이 모두 통과되어야만 시작됨

Vitest

프론트엔드 테스트에 사용하는 도구

웹 화면의 버튼이 잘 눌리는지, 카드가 제대로 표시되는지 등
화면의 최소 단위 검사


Jest

카드 섞기 로직이나 데이터 처리 함수 같은 
복잡한 수학적 계산이 정확한지 꼼꼼하게 따져보는 역할

Vitest, Jest를 사용하기 위해 npm ci라는 명령어를 통해
개발 환경을 완벽하게 복제하고 각각의 테스트를 실행
if: always()

에러가 나서 테스트가 실패하더라도 결과 보고서는 반드시 만들어야 함
개발자가 무엇이 틀렸는지 알기 위해*

단위 테스트 사례: 피셔 에이츠 셔플 알고리즘 검증
카드를 무작위로 섞는 알고리즘

CI 통합 테스트


단위 테스트가 개별 부품의 이상 유무 확인을 했다면,
그 부품들이 연결되었을 때 이상이 없는지 점검

npm run test:integration

백엔드의 통합 테스트 실행

coverage

*"전체 코드에 대해 몇 퍼센트를 테스트했는가"* 를 나타내는 지표
설정한 임계값을 넘지 못하면 exit-code 1을 통한 품질 유지*

if: always()

성공 여부에 관계 없이 보고서로 남겨짐

통합 테스트 사례: 게임 API 연동 검증


단위 테스트는 내부 로직에 집중하고, 통합 테스트는 통신과 흐름에 집중

데이터 규약 검증 (API Contract)

프론트엔드와 백엔드 사이의 데이터 약속(타입, 속성)이 지켜지는지 검증

성능 요구사항(Performance)

사용자 경험을 보장하기 위함

비기능적 요구사항까지 통합 테스트의 영역으로 끌어들임*

서버의 라우팅, 비즈니스 로직, 데이터 생성 과정이 하나로 묶여
실제 서비스 환경에서 문제없이 작동할 것임을 보장


CD

on: workflow_run
CI 워크플로우가 성공적으로 완료되었을 때만 배포 과정이 시작되도록 설계됨
Docker Build and Push to~
소스 코드를 도커 이미지의 독립적인 단위로 묶어 저장소에 업로드
Container Security Scan
도커 이미지 내부의 보안 취약점이나 악성 코드 검사
E2E Test
playwright라는 도구를 사용해, 실제 사용자가 브라우저를 사용하는 것과 
  똑같은 환경에서 기능들이 유기적으로 작동하는지 확인
실제 사용자 경험을 시뮬레이션 하기 때문에 가장 긴 시간이 소모됨
Deploy to GitHub Pages
실제 서비스가 서버에 배포
전 세계 사용자들이 접속할 수 있는 상태
Smoke Test
배포 직후 서비스가 최소한의 정상 작동을 하는지 테스트

이러한 선형적 구조는 각 단계가 이전 단계의 성공을 보장받아야 실행되는
강력한 의존성 관계를 보여줌

개발자의 수동 개입 없이
빌드, 보안, 검증, 테스트, 배포, 최종 확인 과정이 모두 자동화됨


Docker


소프트웨어를 담는 표준화된 컨테이너

Docker Concepts

애플리케이션과 그 실행에 필요한 라이브러리를 하나로 묶어 패키징하는 도구
이렇게 패키징 된 결과물을 docker image라고 부름*

docker image

실행 가능한 정적인 상태의 템플릿

도커 엔진 위에서 실행하면, container라는 격리된 실행 객체가 생성됨


container

기존 가상 머신보다 훨씬 가볍고 빠름

독립적인 환경 제공

표준화된 소프트웨어 단위

어떤 환경에서도 동일하게 작동함


Registry & GHCR

우리가 만든 이미지는 Docker Hub나 GHCR(GitHub Container Registry)
와 같은 온라인 저장소에 보관하고 관리함

이렇게 업로드된 이미지는 환경에 관계없이 어디서든 실행 가능함


GHCR

깃허브의 생태계 내에 있어, 깃허브 액션과 긴밀하게 통합됨
보안, 자동화 배포 파이프라인 구축 시 효율적*

Dockerfile Structure

이미지를 빌드하기 위한 명령어 집합

FROM

베이스 이미지를 지정하는 시작점

LABEL

이미지의 관리자나 버전 정보를 기록하는 메타데이터

ENV

애플리케이션 안에서 사용할 환경 변수

WORKDIR

컨테이너 내부의 작업 디렉토리를 설정하여
이후 명령어들이 실행될 위치를 잡음

COPY

로컬 컴퓨터의 파일들을 이미지 내부로 복사

RUN

빌드 과정 중 필요한 패키지 설치 또는 업데이트 명령어 실행

EXPOSE

컨테이너가 외부와 통신할 때 사용할 포트 번호를 알려줌

CMD

컨테이너가 실행되는 시점에 기본으로 동작할 명령어를 정의

CD: Docker 이미지 빌드 및 GHCR 푸시

1. 파이프라인 시작 & 조건

CD 워크플로우는 메인 브랜치에서 CI 작업이 성공적으로 끝났을 때만 자동으로 시작되도록 설정됨

2. 빌드 환경 & 도구

Buildx
여러 환경에 맞춰 빌드 속도를 빠르게 해 주는 레이어 캐싱 기능 제공
배포 시간을 대폭 단축해 줌*

3. 인증 및 Frontend 빌드

GITHUB_TOKEN을 사용하여 
GHCR 컨테이너 저장소에 자동 로그인을 통한 보안성 확보 

nginx
웹 서버 설정 파일로, 해당 파일을 포함하여 저장소로 푸시


4. Backend 빌드 & 결과 리포트

컨텍스트를 최소화하여 가벼운 이미지 생성

GitHub Step Summary 기능을 통해
현재 빌드된 이미지 태그와 상태를 시각화


CD: Container Scan


소프트웨어를 실제 운영 환경에 배포하기 전 안정성을 최종적으로 검증

1) 보안 파이프라인 시작 & 조건

도커 빌드(이미지 만들기)와 푸시(이미지를 저장소에 등록) 작업이
성공적으로 완료된 직후 실행되도록 설계

배포 전 보안 검사는 선택이 아닌 필수 선행 작업

취약점이 포함된 이미지가 외부로 유출되는 것을 원천 차단


2) 인증 및 코드 접근

GHCR 저장소에 안전하게 접근하기 위해 깃허브 토큰을 사용해 로그인

보안 도구가 프라이빗 저장소에 있는 이미지를 내려받아 검사할 수 있도록
적절한 권한을 확보하는 과정으로 파이프라인의 신뢰성을 보장


3) 프론트엔드 이미지 보안 스캔

Trivy라는 도구를 사용하여 시스템에 치명적인 영향을 줄 수 있는
CRITICAL 등급의 취약점을 집중적으로 점검

심각한 보안 결함 발생 시 엑시트 코드 1번을 반환하여 전체 파이프라인 중단

결함이 있는 소프트웨어가 배포되는 것을 막음*


4) 백엔드 이미지 보안 스캔

패치가 존재하지 않는(해결 방법이 없는) 취약점은
결과에서 제외하여 불필요한 경고인 노이즈를 줄임
개발자가 당장 해결할 수 있는 문제에만 집중하게 만듦*

5) 결과 리포팅 및 공유

모든 스캔이 완료되면 GitHub Step Summary 기능을 통해
각 이미지의 보안 상태와 스캔 요약 결과를 시각적으로 출력함
팀원 전체에게 공개되어 
누구나 현재 배포된 소프트웨어의 품질과 안정성 확인 가능*

CD: E2E 테스트


실제 사용자가 우리 서비스를 이용하는 것과 똑같은 환경에서 
전체 시스템이 잘 돌아가는지 확인

1) 통합 검증 환경 구축

컨테이너 스캔까지 무사히 마친 후 실행되며,
파이프라인 내부에서 프런트엔드와 백엔드 모두 구동하여 전체 시스템을 구성

2) 의존성 설치 레이어

Node.js 20 버전에서 npm cache 기능을 적극 활용하여
매번 모든 패키지를 새로 받는 수고를 덜어냄
테스트 속도를 비약적으로 높임*

3) 브라우저 최적화 및 자동 실행

CD 속도를 최대한 끌어올리기 위해
여러 브라우저 대신 Chronium 하나만 설치해서 집중적으로 테스트

구글 크롬, 엣지, 웨일 등의 대부분 브라우저가 Chronium 기반임*

서버 환경에서 테스트를 돌릴 때, 브라우저 창을 직접 띄울 수 없음

이 때 사용하는 것이 headless 모드*

이후 Playwright 라는 도구를 이용하여 
웹 서버를 자동으로 띄우고 테스트를 실행하여 정밀한 검증 실행


4) 실패 분석 및 결과 보관

테스트가 실패할 경우에만 HTML 형태의 리포트를 아티팩트 형태로 업로드
해당 기록은 7일동안 기록됨*

playwright E2E Test Scenarios: Card Matching Game

CD: Smoke 테스트


하드웨어 수리 분야에서 유래됨
기기를 수리한 뒤 처음 전원을 켰을 때, 연기가 나지 않으면 큰 문제는 없는 것

전체 기능을 상세히 점검하기 전
가장 핵심적인 서비스가 죽지 않고 살아있는지 확인

최소한의 가용성 테스트*


curl 명령어를 통해 GitHub Pages 사이트로 실제 접속 시도

소프트웨어 공학의 회복 탄력성 원칙이 적용된 재시도 로직으로
리트라이 횟수를 5회로 설정, 각 시도 사이에 10초의 지연 시간을 가짐

CDN(Content Delivery Network) 전파가 전 세계적으로 완료되는데 걸리는
물리적인 시간을 고려한 설정

웹 서버가 서울에만 있다면, 미국 사용자는 데이터를 받기까지 오랜 시간 대기,
CDN을 사용하면 미국에 있는 거점 서버에서 바로 데이터 전송*

일시적인 네트워크 지연으로 인한 테스트 실패 현상 방지*

접속 거부 시에도 재시도하도록 설정하고,
최대 대기 시간을 30초로 제한하여 파이프라인의 무한 대기를 방지

HTTP 200 응답 수신 시 스모크 테스트 통과 메시지 출력과 함께 작업 종료


Health Check API 활용

단순히 메인 페이지가 열리는 것을 넘어, 서버 내부의 데이터베이스 연결이나
캐시 시스템이 정상적으로 작동하는지 확인

겉으로는 멀쩡해 보이지만, 실제 기능은 마비된 상태인 좀비 서버를 미리 감지


핵심 UI 요소의 렌더링 확인

HTTP 응답 코드가 200이라고 해서 화면에 내용이 제대로 보인다는 보장 없음
Playwright와 같은 도구를 이용하여 
페이지 제목, 로그인 버튼 등의 돔 트리 점검*

외부 연동 서비스의 연결성 점검

서비스와 연결된 외부 게이트웨이나 인증 API 서버와의 통신이 원활한지 확인




11. 파일 시스템 관리
Mon, 25 May 2026 09:42:46 GMT
강의 목표

응용프로그램과 저장 장치 사이의 파일 입출력 과정을 안다.
디렉터리와 파일의 계층 구조에 대해 이해한다.
파일 메타 정보와 파일 시스템 메타 정보에 대해 이해한다.
FAT 파일 시스템의 저장 구조에 대해 이해한다.
Unix 파일 시스템의 저장 구조에 대해 이해한다.
파일 입출력 연산이 이루어지는 과정을 이해한다.
파일 찾기, 파일 열기, 파일 읽기, 파일 쓰기, 파일 닫기*

01 파일 시스템과 저장 장치
1.1 파일과 저장 장치
파일(file)

사용자나 응용프로그램에게 정보를 저장하고 관리하는 논리적 단위

내용과 형식은 파일을 만드는 사용자나 응응프로그램에 의해 결정

컴퓨터 시스템은 0/1로 다룸*

파일이 생성되고 기록되고 읽혀지는 모든 과정은 운영체제에 의해서만 통제됨

저장 장치를 통제하는 것은 운영체제 본연의 기능이기 때문이며,
저장 장치에 관한 정보(빈 공간, 파일 저장 위치)는 운영체제에 의해서 통제됨*


비휘발성 영구 저장 장치(non-volatile)

전원이 꺼져도 정보가 지워지지 않는 저장 장치

예)
하드 디스크(HDD, Hard Disk Drive)
USB 플래시 드라이버(USB Flash Drive)
SSD(Solid-State Drive)
테이프 저장 장치

*램 디스크(RAM Disk)와 같이 메모리의 일부분을 저장 장치로 활용하기도 함*

이는 전원이 꺼지면 파일이 모두 사라지므로 영구 저장 장치는 아님*


1.2 디스크 장치 개요

운영체제의 파일 시스템은 저장 장치의 종류나 구조에 무관하게 설계됨

하드 디스크

자성체(magnetic material)로 코팅된 여러 개의 원판(플래터, platter)에
디지털 정보를 저장하고 읽어 내는 장치

디스크 장치는 디스크 매체 모듈과 디스크 제어 모듈로 구성됨



디스크 매체 모듈
플래터(platter)

정보가 기록되는 저장소로 스핀들(spindle)에 연결되어 함께 회전

디스크 헤드(disk head)는 플래터에서 정보를 읽거나 기록

아래 윗면 모두 정복 저장됨
플래터 당 2개의 디스크 헤드가 존재*

모든 암(arm)들은 하나의 구동기(actuator)에 달려 있어 안팎으로 움직임


디스크 제어 모듈

프로세서(processor)가 위치하는 곳으로, 운영체제로부터 명령을 받고 해석 후
디스크 매체 모듈을 제어하여 물리적인 디스크 액세스 진행

입출력 데이터를 임시 저장하는 디스크 캐시를 두고 있음

1MB~몇 십 MB 크기의 빠른 반도체 메모리*

운영체제가 전달한 데이터는 디스크 캐시에 가장 먼저 저장되며,
프로세서에 의해 디스크 캐시 → 플래터로 저장됨

읽기 요청을 받은 경우, 
프로세서는 플래터 → 디스크 캐시로 이동 후 호스트로 전송

디스크 캐시는 운영체제나 응용프로그램에게  디스크 입출력 시간 단축


호스트(host)

원격 네트워크에서 사용자가 연결하여 사용하는 장치를 터미널(terminal)

원격에 있는 컴퓨터를 호스트 또는 호스트 컴퓨터라고 함

디스크장치의 경우 입출력 버스를 통해 메인 컴퓨터와 연결되는데,
메인 컴퓨터를 호스트라고 함*


트랙, 섹터, 실린더

섹터(sector)

디스크에서 읽고 쓰는 최소 단위
512바이트 혹은 4096바이트*

트랙(track)

플래터에 정보가 저장되는 하나의 동심원
여러 개의 섹터로 구성됨*

실린더(cylinder)

모든 플래터를 통틀어 같은 반지름의 트랙 그룹

4장의 플래터를 가진 디스크는 헤드가 8개이므로,
실린더는 8개의 트랙으로 구성됨
섹터와 블록
섹터(sector)

디스크가 입출력하는 물리적인 최소 단위

블록(block)

운영체제가 파일 데이터를 다루는 논리적인 단위

운영체제는 파일을 블록 단위로 나누어 
하드 디스크에 분산 배치하고, 블록 단위로 읽고 씀

블록의 크기는 운영체제마다 다르며, 몇 개의 섹터로 구성됨


1.3 파일 입출력 주소
디스크 물리 주소와 논리 블록 주소

응용프로그램 - 파일 내 바이트 주소 
운영체제 - 논리 블록 주소
디스크 장치 - 디스크 물리 주소

디스크 물리 주소

디스크 장치는 플래터에서 섹터 단위로 읽고 씀CHS(Cylinder-Head-Sector) 물리 주소 = [실린더 번호, 헤드 번호, 섹터 번호]

논리 블록 주소(Logical Block Address)

디스크의 모든 블록들을 일차원 배열로 나열하고 번호를 매긴 주소

블록 번호는 맨 바깥쪽 실린더 → 안쪽 실린더 순서
맨 위의 트랙 → 아래 트랙으로 이동

디스크의 물리적인 구조와 무관함


바이트 번호

파일 내 바이트의 위치, 즉 옵셋

파일 주소 변환


사용자나 응용프로그램은 파일 데이터가 
바이트 단위로 연속해서 저장된다고 생각함

운영체제는 파일을 블록 크기로 분할하고, 각 블록을 디스크에 분산 저장

파일 블록 배치 정보(파일의 각 블록이 저장된 디스크 블록 번호)를 
별도로 저장 및 관리

응용프로그램에서 파일 내 바이트 주소의 변환 과정
파일 내 바이트 주소 
→ 논리 블록 주소(운영체제에 의해) 
→ CHS 물리 주소(디스크 장치에 의해)

주소 계층화 의미


응용프로그램, 운영체제, 디스크 장치 사이에서 
파일 데이터를 바라보는 시각은 계층화되어있음

계층 구조로 인해 사용자나 응용프로그램, 운영체제, 그리고 디스크 장치가
상호 독립적으로 정의된 기능 수행 가능

응용프로그램 작성자는 저장 매체의 하드웨어 구조나 특성에 대한 지식 없이
파일 입출력을 가능하게 함

운영체제는 저장 장치의 종류나, 실린더 수, 헤드 수, 트랙당 섹터 수 등
저장 장치의 하드웨어와 무관하게 개발될 수 있음

SSD와 같은 실린더나 트랙 등 디스크 포맷을 가지지 않는 저장 매체도
동일한 방식으로 입출력 가능*


1.4 파일 시스템의 정의와 범위
파일 시스템

저장 매체에 파일을 생성·저장·읽기·쓰기의 기능을 가진 운영체제를 통칭


파일 시스템을 구성하는 4가지 요소

파일 시스템의 논리 구조
저장 장치에 파일 시스템 구축
커널 내 파일 입출력 구현
응용프로그램을 위한 파일 시스템 인터페이스

파일 시스템의 논리 구조

운영체제는 여러 파일을 다루기 위해,
디렉터리와 파일들로 이루어지는 트리 계층 구조로 파일 시스템을 구성

저장 장치에 파일 시스템 구축

파일들을 저장 매체 속에 블록 단위로 분산 저장·관리하기 위한 체계
저장 매체 속 사용/미사용 블록에 관한 정보 등의 설계*

커널 내 파일 입출력 구현
1) 파일 생성

저장 매체의 빈 공간에 물리적으로 파일 이름과 속성 등을 기록

2) 파일 열기

파일을 읽고 쓰기 전, 파일의 존재, 접근 권한 등을 확인하는 작업과 함께
파일을 읽고 쓰고 공유할 수 있도록 커널 내 구조 형성

3) 파일 읽기

파일 블록이 저장된 위치를 알고 파일 데이터 읽기

4) 파일 쓰기

저장 매체에 파일 데이터를 기록하는 기능
이미 존재하는 파일 데이터를 갱신하는 경우엔 데이터를 덮어 쓰고,
새로운 파일 데이터를 기록하는 경우 저장 매체의 빈 공간을 할당받아 기록*

5) 파일 닫기

파일 열기 시에 형성된 커널 내 자료 구조 해제

6) 파일 삭제

저장 매체에서 파일이 저장된 영역을 빈 영역 리스트에 반환

7) 파일 메타 정보 읽기/변경

파일의 속성 등 메타 정보를 읽거나 변경

응용프로그램을 위한 파일 시스템 인터페이스(시스템 호출)

커널 내에 구현된 파일 입출력 기능을 활용할 수 있도록
open(), close(), read(), write, seek() 등 다양한 시스템 호출 제공
응용프로그램은 시스템 호출을 통해서만 파일 시스템 사용 가능*

1.5 파일 시스템 입출력 계층

파일 시스템은 파일이 입출력되는 모든 과정에서 관여



응용프로그램은 일반적으로 파일 입출력 라이브러리를 이용하여 작성됨

라이브러리

필요에 따라 시스템 호출을 이용하여 
운영체제에게 파일 입출력을 요청

파일 입출력 계층

요청이 정상인지 검사하고
요청된 파일 데이터의 바이트 주소 → 논리 블록 주소(LBA)로 변환

논리 블록 입출력 계층

논리 블록 주소에 해당하는 디스크 블록이 
커널 내의 버퍼(버퍼 캐시)에 있는지 확인

있으면 버퍼 캐시에서 읽거나 쓰기 작업으로 완료

없으면 디스크 장치 드라이버(disk driver)를 통해 
디스크 장치로 논리 블록 주소를 보내 입출력 지시


물리 저장소 입출력 계층

저장 장치에서 구현되는 계층으로, 
논리 블록 주소 → 저장 장치의 물리 주소로 변환하여 데이터를 액세스

저장 장치가 
하드 디스크 → CHS 물리 주소
SSD → 플래시 메모리 상의 블록 주소


1.6 파일 읽기 사례

C 표준 라이브러리 함수 fread()를 이용하여 파일에서 n바이트 읽기char buf[SIZE]
FILE* fp = fopen(...);
fread(fp, buf, n);


파일 데이터의 복사 경로
디스크 캐시 → 커널의 버퍼 캐시 → C 라이브러리의 버퍼 → 응용프로그램의 buf[]배열
파일 읽기 과정을 통한 주목 사항
1) 파일 읽기의 과정은 계층 구조로 이루어지고 그 역할이 잘 구분됨
2) 운영체제 커널의 역할은 사용자나 응용프로그램이 파일이 저장되는 
저장 장치의 종류나 구조, 위치 등 물리적인 특성에 무관하게 입출력 지원
3) 디스크 드라이버에 의해 파일에 대한 논리적 구조와 물리적 저장 공간을 분리
4) 파일 데이터는 여러 번의 복사를 거쳐 이동

버퍼들로 인해 많은 시간이 소요되기도 하지만, 
동일한 파일 블록 액세스, 
여러 스레드에 의해 동일한 파일이 공유되는경우
입출력 성능 향상*

02. 파일 시스템의 논리 구조
2.1 파일 시스템 구조

오늘날 운영체제는 대부분 
트리 계층 구조(tree hierarchical structure)로 파일 시스템을 구성
파일이 몇 십 개 수준이라면 계층 구조 없이 일차원적으로 저장*


디렉터리와 파일의 계층 구조
디렉터리(directory)

파일과 서브 디렉터리를 담기 위한 컨테이너

루트 디렉터리(root directory)
파일 시스템 계층 구조의 최상위 디렉터리

서브 디렉터리(sub directory)
루트 디렉터리의 하부에 존재하는 디렉터리




대부분의 파일 시스템에서는 
파일 블록의 저장 위치는 디렉터리에 두지 않고 다른 곳에 저장함

FAT 파일 시스템의 경우 FAT 테이블에,
유닉스나 리눅스 파일 시스템의 경우 i-node*

디렉터리는 서브 디렉터리나 파일들의 목록을 저장한 파일


디렉터리와 폴더

디렉터리는 파일을 담는 물리적인 컨테이너

폴더는 파일뿐 아니라 네트워크 환경, 내 컴퓨터, 제어판 등
파일 개념이 아닌 여러 요소들도 담을 수 있는 논리적인 컨테이너

디렉터리는 폴더의 일종이지만, 디렉터리와 폴더는 같은 개념으로 사용됨


파일 이름과 경로명

파일 이름은 a.jpg, main.cpp 등 이름(name)과 확장자(extension)으로 구성

확장자는 없을 수도 있음*

파일의 경로명(pathname)은 루트 디렉터리에서 
계층구조를 포함하는 완전한 파일 이름

gun.exe
리눅스: /Programs/Apps/gun.exe
Windows: C:\Programs\Apps\gun.exe


2.2 파일 시스템 메타 정보와 파일 메타 정보
운영체제는 파일 시스템을 다루기 위해 다음 2개의 매타 정보를 만들고 활용함

파일 시스템 메타 정보
파일 메타 정보

파일 시스템 메타 정보

파일 시스템 전체에 대한 정보로, 운영체제나 파일 시스템 종류마다 다름

공통적으로는 다음과 같다

파일 시스템 전체 크기
저장 장치에 구축된 파일 시스템의 현재 사용 크기
저장 장치에 구축된 파일 시스템의 비어 있는 크기
저장 장치 상에 비어 있는 블록들의 리스트*

저장 매체 속 예약된 특별한 위치에 저장하여,
파일이나 디렉터리와 섞이지 않도록 하고
운영체제가 쉽게 읽고 쓸 수 있도록 함


파일 메타 정보

파일에 관한 여러 정보로서 파일 데이터(실제 파일 내용)는 포함되지 않음

파일마다 메타 정보는 별도로 관리되며 운영체제에 따라 조금씩 다름

공통적으로 다음과 같다

파일 이름
파일 크기
파일이 만들어진 시간
파일이 수정된 시간
파일이 가장 최근에 액세스된 시간
파일을 만든 사용자(소유자)
파일 속성(접근 권한)
파일이 저장된 위치(파일 블록 배치 정보)*


파일에는 파일 데이터만 저장되고 파일 메타 정보는 다른 곳에 저장됨


파일 메타 정보는 어디에 저장되는가?

파일 메타 정보는 파일 데이터와 분리하여 따로 저장됨

TIP 파일 메타 정보 중 파일 속성(file attributes)

03. 파일 시스템 구축
3.1 파일 시스템 종류와 구현 이슈
파일 시스템 종류

FAT(File Allocation Table) - MS-DOS
UFS(Unix File System) - Unix
ext2, ext3, ext4 - Linux
HFS(Hierarchical File System) - Mac
NTFS(New Technology File System) - 윈도우즈 3.1~, FAT를 개선, 리눅스 지원
모두 트리 구조의 계층적 파일 시스템이지만, 저장 장치에서 구성 방식은 다름*

파일 시스템 구현 이슈

디스크 장치에 비어 있는 블록들의 리스트를 어떻게 관리할 것인가?
파일 블록들을 디스크의 어느 영역에 분산 배치할 것인가?
파일 블록들이 저장된 디스크 내 위치들을 어떻게 관리할 것인가?

3.2 FAT 파일 시스템

1980년대 PC의 개인용 운영체제인 MS-DOS의 파일 시스템으로 개발
파일 개수와 크기가 작았던 당시에 적합하도록 설계
진화된 모습으로 지금도 사용


FAT 파일 시스템의 구조

디스크의 맨 첫번째 섹터인 부트 섹터(boot sector)에서 
루트 디렉터리까지의 공간은 FAT 파일 시스템을 구축할 때(포맷할 때)
고정 크기로 설정됨

부트 섹터

한 섹터 크기로 파일 시스템 메타 정보 및 디스크에 관련된 정보들과
컴퓨터가 부팅할 때  실행되는 코드가 저장되는 영역

DOS 버전, 섹터 당 바이트 수, 블록 당 섹터 수, FAT 개수, 루트 디렉터리 항목 개수,
전체 섹터 수, FAT 당 섹터 수, 트랙 당 섹터 수, 디스크 헤드 개수 등

FAT 테이블 항목들을 조사하면 현재 파일 시스템 내에서
사용 중인 블록들과 비어 있는 블록들을 알 수 있음

MS-DOS 운영체제의 커널 코드는 IO.SYS와 MSDOS.SYS 파일에 들어 있으며, 
이들은 모두 루트 디렉터리(C:/)에, 
hidden, read-only, system 속성으로 저장됨

부팅이 시작되면 부트 섹터에 들어있는 코드가 메모리에 적재되고 실행됨


FAT1과 FAT2

파일 시스템의 전체 파일에 대해 파일이 저장된 디스크 블록들의 번호 저장

FAT가 훼손되면 파일을 찾을 수 없기 때문에 FAT2를 복사본으로 둠


루트 디렉터리

루트 디렉터리는 FAT2 바로 뒤에 구성됨

파일을 찾을 때 루트 디렉터리에서부터 시작하므로,
루트 디렉터리를 찾기 쉽도록 위치를 고정시키기 위함*

루트 디렉터리의 크기는 고정되어 있으므로
루트 디렉터리에 생성되는 파일이나 서브 디렉터리의 개수도 고정됨

루트 디렉터리에는 분산된 파일 블록들 중 시작 블록 번호를 저장

루트 디렉터리의 바로 아래에 있는 디렉터리의 메타데이터 저장


데이터 블록 영역

루트 디렉터리를 제외한 모든 파일의 데이터 블록들이 저장되는 영역

각 파일은 블록 단위로 데이터 블록 영역 내에 분산 저장됨


디렉터리

파일의 목록을 담은 특별한 파일

루트 디렉터리나 서브 디렉터리 모두 구조는 동일함

파일 하나당 하나의 디렉터리 항목이 생기므로, 
디렉터리 항목의 개수는 디렉터리에 존재하는 파일 개수와 동일함

FAT 파일 시스템에서 디렉터리 항목은 하나의 파일 메타 정보를 모두 저장

가장 중요한 것은 시작 블록 번호로 파일이 저장된 첫 번째 디스크 블록 번호*




정리
/usr/usrs/a.txt에서
usr, usrs는 디렉터리로 이 곳에 저장되는 데이터는 
하위 디렉터리/파일의 메타데이터이고
a.txt는 파일로 실제 데이터가 저장됨


즉, 데이터 블록에서
usr에는 usrs의 메타데이터가 저장되고,
usrs에는 a.txt의 메타데이터가 저장됨
a.txt에는 실제 데이터가 저장됨
255개 문자의 긴 파일 이름(Long File Name, LFN)
파일 블록 배치(File Allocation)

파일 데이터를 블록 단위로 디스크에 분산 저장하고
저장된 위치는 FAT(File Allocation Table) 라고 불리는 테이블에 기록
이 테이블의 항목들은 연결 리스트(Linked List)로 연결됨*



FAT 테이블의 항목별 의미
-1: 파일의 마지막 블록
0: 사용 가능한 자유 블록
2~: 파일의 다음 블록 번호

FAT 파일 시스템은 구축 시 모두 0으로 초기화되며,
운영체제는 블록을 할당할 때 FAT 항목이 0인 블록을 찾아 할당함

FAT 테이블의 항목 크기는 12, 16, 32비트로 진화함에 따라
파일 시스템 이름도 FAT12/16/32로 바뀌어 옴

FAT 테이블의 항목 크기가 16비트일 때,

한 항목이 가질 수 있는 주소의 경우의 수 = 2$^{16}$개
디스크 블록 크기가 4KB라면 파일 시스템이 저장할 수 있는 데이터의 양은
2$^{16}$ x 2$^{12}$ = 2$^{20}$ = 256MB*


FAT 파일 시스템의 장단점
장점

단순하여 구현이 쉽고 외부 단편화가 없음

단점

파일 당 ½ 블록 크기로 내부 단편화 발생
하나의 파일을 순차적으로 읽는 경우, 디스크 전체에 걸쳐 블록을 읽느라 디스크 헤드를 움직이는 탐색 시간(seek time)이 큼
FAT 테이블 영역이 손상되면 파일 시스템 전체를 읽을 수 없음

3.3 Unix 파일 시스템
Unix 파일 시스템의 구조

부트 블록(boot block)

부팅이 진행될 때 처음에 메모리에 적재되는 디스크 블록

운영체제를 적재하는 코드와 부팅 시 필요한 정보가 저장됨

하나의 디스크를 여러 개의 파티션으로 나누고 
각 파티션마다 파일 시스템을 구축할 수 있음

부팅에 참여하지 않는 파일 시스템의 부트 블록은 비어 있음


수퍼 블록(super block)

파일 시스템의 유지 관리를 위한 파일 시스템 메타 정보가 기록되는 공간

파일 시스템 크기와 상태 정보
블록 크기
자유 블록 수
자유 블록 리스트
자유 블록 리스트에서 요청시 할당할 다음 블록 인덱스
i-node 리스트의 크기
자유 i-node 수
자유 i-node 리스트
자유 i-node 리스트에서 요청시 할당할 다음 자유 i-node 인덱스
루트 디렉터리의 i-node 번호
수퍼 블록이 갱신된 최근 시간*

파일이 생성되고 읽고 쓰는 동안 자유 i-node를 찾거나 자유 블록을 찾는 등
커널에 의해 자주 액세스됨

디스크의 입출력을 줄이기 위해 부팅 초기에 메모리에 적재됨*

메모리에 적재된 수퍼 블록은 파일 입출력 동안 계속 갱신하기 때문에
주기적으로 디스크의 수퍼 블록에 기록되어야 함

메모리 적재 후 갱신되었을 때, 디스크에 기록되지 못한 채 컴퓨터 종료 시
파일 시스템이 깨지는 상황 발생*

디스크에 저장된 수퍼 블록 손상 시 심각한 문제 발생
→ 파일 시스템마다 디스크에 백업 수퍼 블록(backup super block)을 만들고,
기본 수퍼 블록(primary super block)과 같은 상태 유지

기본 수퍼 블록이 망가지면 백업 수퍼 블록을 이용해 복구*


i-node와 i-node 리스트
i-node(index node)

파일 메타 정보가 기록되는 구조체로서 파일마다 한 개씩 사용됨

i-node 리스트

i-node들의 테이블로서 수퍼 블록 다음에 저장되며,
파일 시스템이 구축될 때 크기가 고정되므로 i-node개수도 고정



파일이 만들어지면 운영체제는 i-node 리스트에서 
자유 i-node를 하나 할당받아 파일 메타 정보들을 기록·관리

i-node 리스트에서 i-node를 다 사용하게 되면 파일을 생성할 수 없음

i-node 리스트의 크기와 자유 i-node에 관한 정보는 수퍼 블록에 기록됨

각 i-node는 리스트에서 인덱스로 구분됨

i-node 번호 = i-node 리스트 인덱스와 동일*

i-node의 번호는 0부터 시작되지만 
사용할 수 있는 첫 i-node는 파일 시스템마다 다름

Unix는 1번, 리눅스는 2번부터 사용 가능
0번은 오류 처리를 위해 예약되어 있음*


데이터 블록들

파일과 디렉터리가 저장되는 공간
파일은 블록 단위로 분산 저장됨
블록의 크기는 수퍼 블록에 기록되어 있으며, 보통 4KB

디렉터리



FAT 파일 시스템이 각 파일의 메타 정보를 디렉터리에 두는 것과 달리,
Unix 파일 시스템은 파일 메타 정보를 i-node에 둔다.

탐구 11-1 Unix 파일 시스템의 Q&A
Q1. Unix 파일 시스템을 사용할 때 만들 수 있는 파일 개수는?

파일 하나당 하나의 i-node가 필요하므로 
i-node 리스트에 있는 i-node의 개수와 같음

Q2. 수퍼 블록이 메모리에 적재된 채 사용되어야 하는 이유는?

커널은 파일이 생성될 때마다 자유 i-node를 찾아야 하고, 
파일이 삭제될 때마다 i-node를 반환하기 위해 
수퍼 블록을 읽고 쓰는 작업이 발생하기 때문에, 
커널 코드의 실행을 빨리 하기 위해 수퍼 블록을 메모리에 적재하여 사용

메모리에 적재된 수퍼 블록은 주기적으로 디스크의 수퍼 블록에 저장됨


Q3. Unix 파일 시스템에서 
파일 시스템 메타 정보와 파일 메타 정보는 어디에 기록되는가?

파일 시스템 메타 정보는 수퍼 블록에 저장되고, 
파일 메타 정보는 i-node에 기록된다.
파일 이름은 디렉터리 항목(데이터 블록에 위치)에 기록된다.

TIP 파일의 i-node 번호 보기
ls -ial 명령어를 통해 현재 디렉터리에 저장된 파일들의 
i-node 번호와 i-node에 들어 있는 파일 메타 정보 출력

파일 블록 배치(File Allocation)

파일을 블록 단위로 디스크의 여러 블록에 분산 저장하고,
i-node에 15개의 인덱스를 통해 파일이 저장된 디스크 블록들의 번호를 기억
```
12개의 직접 인덱스 
1개의 간접 인덱스 
1개의 이중 간접 인덱스 
1개의 3중 간접 인덱스

12개의 직접 인덱스(direct index)

파일이 저장된 처음 12개의 디스크 블록 번호를 가리킴

파일 생성 시, 데이터 블록들이 저장되는 곳에서 자유 블록 1개를 할당받고,
블록 번호를 12개의 인덱스 중 첫 인덱스에 기록

블록 크기가 4KB라고 할 때, 파일 크기가 4KB를 넘어서게 되면
다시 자유 블록을 할당받고 블록 번호를 2번째 인덱스에 기록

12개의 직접 인덱스만으로 파일이 저장된 블록을 가리킬 수 있음

블록 크기가 4KB일 때
12개의 직접 인덱스로 가리킬 수 있는 파일 블록 수 = 12개
12개의 직접 인덱스로 가리킬 수 있는 파일 크기 = 12 x 4KB = 48KB

1개의 간접 인덱스(single indirect index)

파일이 12개의 블록을 넘어서 커지게 되면, i-node에 있는 간접 인덱스 사용

1개의 디스크 블록을 할당받아 간접 인덱스로 가리키게 하고
이 디스크 블록을 파일 블록에 대한 인덱스들로 사용


블록 크기가 4KB이고 블록 번호가 4바이트(32비트)일 때,

= 블록 번호를 표현하는 데 4바이트(32비트)를 사용할 때*
간접 인덱스로 가리킬 수 있는 파일 블록 수 = 4KB/4바이트 = 1024
간접 인덱스로 가리킬 수 있는 파일 크기 = 1024 x 4KB = 4MB
인덱스로 사용되는 디스크 블록 수 = 1개



**1개의 2중 간접 인덱스(double indirect index)**
- 파일이 1034(12 + 1024)개의 블록을 넘어 커지게 되면, 
i-node에 있는 2중 간접 인덱스가 사용됨

- 2중 간접 인덱스가 가리키는 1개의 블록은 
1024(4KB/4바이트)개의 인덱스로 사용되고, 
이 1024개의 인덱스는 또 다시 1024개의 블록 번호들을 가리킴
2중 간접 인덱스로 가리킬 수 있는 파일 블록 수 = 1024 x 1024 블록
2중 간접 인덱스로 가리킬 수 있는 파일 크기 = 1024 x 1024 x 4KB = 4GB
인덱스로 사용되는 디스크 블록 수 = 1 + 1024 = 1025개

**1개의 3중 간접 인덱스(triple indirect index)**
- 파일이 더 커지게 되면 
i-node에 있는 3중 간접 인덱스를 이용하여 파일 블록을 가리킴
3중 간접 인덱스로 가리킬 수 있는 파일 블록 수 = 1024 x 1024 x 1024
3중 간접 인덱스로 가리킬 수 있는 파일 크기 = 1024 x 1024 x 1024 x 4KB = 4TB
인덱스로 사용되는 디스크 블록 수 = 1 + 1024 + 1024 x 1024개

**블록 번호가 32비트(4바이트)이고, 한 블록의 크기가 4KB일 때,
Unix 파일 시스템에서 파일의 최대 크기**
`48KB + 4MB + 4GB + 4TB`
![](https://velog.velcdn.com/images/hi_soap/post/2adda4c8-b914-4094-b9fc-31e74da78eb5/image.png)



#### 파일의 i-node를 찾는 과정
`/usr/source/main.c`를 찾는 과정
![](https://velog.velcdn.com/images/hi_soap/post/66cb2f45-d4fe-4088-bf15-f3d9c50689ae/image.png)

#### 리눅스에서 긴 파일 이름을 위한 디렉터리 항목
![](https://velog.velcdn.com/images/hi_soap/post/9cd8529b-6224-4e89-98d7-161fff2bba0c/image.png)
- `파일 이름`: 널문자(`'\0'`)로 끝나는 문자열로 최대 255문자까지 가능

- `파일 이름 길이`: 파일 이름의 실제 길이가 기록됨

- `파일 타입`: 파일인지, 디렉터리인지, FIFO인지, 네트워크 소켓인지, 링크인지 등 인지를 나타내는 값이 들어감

- `i-node 번호`: 크기도 4바이트로 늘었으며, 값이 0이면 사용되지 않는 디렉터리

## 04. 파일 입출력 연산
- 파일 입출력은 커널에 의해서만 이루어지므로,
응용프로그램에게 파일 입출력 관련 시스템 호출 함수들이 제공됨
open(), read(), write(), close(), chmode(), create, mount(), unmount() 등

### 4.1 파일 찾기
- 파일 찾기의 과정은 **파일의 경로명**으로부터 파일의 **i-node**를 찾는 과정으로 
커널에 의해 이루어짐

- i-node를 찾아야 해당 파일 데이터가 담겨 있는 블록들의 번호도 알 수 있고,
파일 타입과 이 파일에 대한 현재 프로세스의 접근 권한 등을 확인 가능

### 4.2 파일 열기, open()
#### 파일을 여는 이유
- 파일이 존재하는지 확인
- 현재 프로세스가 파일 연산(읽기/쓰기)할 수 있는지
파일에 대한 접근 권한을 확인
*파일이 존재하지 않거나, 접근 권한이 없다면 `-1`을 리턴*
- 연이어 파일을 읽거나 쓰기 위한 커널 내에 자료 구조 형성

![](https://velog.velcdn.com/images/hi_soap/post/f1a195d7-8312-4b50-97f6-249029950d26/image.png)

- 파일이 존재하는지 확인
- 파일이 존재한다면 디스크에서 메모리로 i-node를 읽어들임
- 파일에 대한 접근이 가능한지 권한 여부 판단
- 파일을 읽고 쓰기 위한 커널 자료 구조 형성

#### 파일 입출력을 위한 커널 자료 구조
**메모리 i-node 테이블**
- 현재 열린 파일들에 대해 디스크에서 i-node를 읽어 메모리에 형성한 테이블
*시스템에 1개 존재*

- i-node는 파일을 읽고 쓰는 과정에서 계속 액세스되므로, 
디스크 입출력 시간을 줄이기 위해 메모리에 올려놓고 사용

**오픈 파일 테이블(open file table)**
- 열려 있는 모든 파일에 관한 정보를 기록해둔 테이블

- 시스템에 1개만 있기 때문에
**시스템 파일 테이블(system file table), 전역 파일 테이블(global file table)**

- 파일이 열릴 때 마다 오픈 파일 테이블의 새 항목이 사용됨

- `열기 모드(R/W)`
`파일 옵셋(offset)`
파일 내에 다음에 읽거나 쓸 바이트 위치를 나타내는 정수값 
*커널에 의해 파일을 읽은 만큼 또는 쓴 만큼 옵셋을 증가시켜,
다음에 액세스할 파일 내 바이트 위치를 가리키게 함*
`메모리 i-node의 메모리 주소`
등으로 구성

- 오픈 파일 테이블의 항목 개수는 
이중 링크드 리스트(doubly linked list)로 구성되어
오픈 파일 테이블의 항목들을 동적으로 할당함
*무한정 많은 파일이 열리는 것은 허용하지 않음*


**프로세스별 오픈 파일 테이블(per-process open file table)**
- **프로세스 당** 하나씩 존재하며, 
프로세스가 파일을 열 때마다 테이블에 1개의 항목이 사용됨

- 

- 오픈 파일 테이블에 대한 메모리 주소가 기록됨
*프로세스가 열어 놓은 모든 파일에 대해
오픈 파일 테이블에 대한 주소가 기록된 배열*

- 프로세스가 생성될 때 생성되고, 종료하면 소멸됨

- 프로세스의 모든 스레드에 의해 공유됨

- 운영체제에 따라 다르지만 PCB에 저장됨

**버퍼 캐시(buffer cache)**
- 파일을 읽고 쓰는 과정에서 
파일 블록들을 일시적으로 저장하는 메모리 공간

- 커널 공간에 만들어짐

- 어떤 프로세스 혹은 어떤 파일의 블록인지 표시되지 않고,
오직 디스크 블록 번호로만 관리됨

- 프로세스가 파일을 읽을 때 버퍼 캐시에서 바로 읽어갈 수 있으며,
파일 쓰기 시에는 버퍼 캐시에 블록을 쓰는 것으로 파일 쓰기를 마침
*버퍼 캐시에 쓰여진 블록들은 커널에 의해 적절한 시점에 디스크에 기록됨*

#### 파일 열기 과정
```c
int fd = open("/usr/source/main.c", O_RDONLY);
// /usr/source/main.c를 읽기 모드로 여는 코드
(1) 파일 이름으로 i-node 번호 알아내기
(2) 디스크 i-node를 메모리 i-node 테이블에 적재

메모리 i-node 테이블에서 비어 있는 i-node를 할당받은 후, 적재
메모리 i-node 테이블에는 동일한 i-node가 여러 개 저장되지 않음
동일한 파일이 여러 번 열리면 메모리 i-node는 공유됨
파일이 수정될 때마다 메모리 i-node가 수정되고
적당한 시점에 디스크 i-node에 저장됨

(3) 오픈 파일 테이블에 새 항목 만들기

오픈 파일 테이블에 새 항목을 만들고 메모리 i-node의 주소를 기록
파일 열기 모드(O_RDONLY)정보를 기록
offset 값을 0으로 초기화
offset 값은 다음에 읽을 파일 내 바이트 위치를 나타냄
커널은 파일을 읽은 바이트만큼 offset을 증가시킴*

(4) 프로세스별 오픈 파일 테이블에 새 항목 만들기

프로세스별 오픈 파일 테이블에 새 항목을 만들고
오픈 파일 테이블 항목에 대한 주소 기록

(5) 프로세스별 오픈 파일 테이블의 항목 번호를 리턴

프로세스별 오픈 파일 테이블에 방금 생성한 항목 번호 리턴
이 번호는 정수 값으로 응용프로그램에 선연된 변수 fd에 저장됨
리눅스, MacOS 등 Unix 계열의 운영체제에서는 이 정수를
파일 디스크립터(file descriptor, fd)
Windows 계열에서는 파일 핸들(handle)이라고 부름

파일 디스크립터(file descriptor)

프로세스별 오픈 파일 테이블의 인덱스로서
열린 파일마다 매겨진 고유한 정수 번호

응용프로그램이 열어 놓은 파일을 대변하는 값*

파일을 연 응용프로그램에게 반드시 전달해야 함

open()의 리턴값


TIP 파일 디스크립터 0, 1, 2
0: 표준 입력 장치(키보드)
1: 표준 출력 장치(디스플레이)
2: 표준 오류 장치(디스플레이)

장치들은 운영체제에서 파일로 다루어짐#include 
int main() {
  char c;
  read(0, &c, 1); // 0번 파일 디스크립터(키보드)에서 문자 1개를 읽어 변수 c에 저장
  write(1, &c, 1); // 1번 파일 디스크립터(디스플레이)에 변수 c의 문자 출력
  write(2, "hello\n", 6); // 2번 파일 디스크립터(디스플레이)dp "hello\n" 출력
}



// 출력 결과
// a
// ahello

```c
#include  // 이곳에 상수로 선언되어 있기 때문에 가능함

read(STDIN_FILENO, &c, 1);
write(STDOUT_FILENO, &C, 1);
write(STDERR_FILENO, "hello\n", 6);

// 출력 결과
// a
// ahello

// 또는

#include 

fscanf(stdin, "%c", &c);
fprintf(stdout, "%c", c);
fprintf(stderr, "hello\n");

// 출력 결과
// a
// hello // stderr에 출력하면 버퍼를 거치지 않고 바로 출력됨
// a

처음부터 printf()나 scanf()를 사용하여 입출력을 할 수 있는 것은 운영체제가 프로세스를 생성할 때, 프로세스별 오픈 파일 테이블에 
파일 디스크립터 0, 1, 2 항목을 만들어 두었기 때문

4.3 파일 읽기, read()
char buf[1024];
int fd;
fd = open("/usr/source/main.c", O_RDONLY); // 파일 열기 후 fd는 3이라고 가정
read(fd, buf, 1024); // main.c 파일에서 1024 바이트를 읽어 buf에 저장

4.4 파일 쓰기, write()
char buf[230];
int fd;
fd = open("/usr/source/calc/c", O_RDWR);

4.5 파일 닫기, close()
close(fd); // fd가 가리키는 calc.c 파일 닫기

오픈 파일 테이블 항목의 참조카운트

오픈 파일 테이블의 항목은 서로 같은/다른 프로세스에 의해 공유될 수 있음

공유되는 개수를 기억하기 위해 
참조카운트(reference count) 필드를 두고 있음

파일이 닫힐 때 참조카운트를 1감소, 0이 되면 항목 제거*


탐구 11-2 동일한 파일을 동시에 여는 경우

두 프로세스 중 누가 먼저 실행되느냐에 따라 결과가 달라짐