개발 인생 복구 센터

[TIL] 리눅스 입문 with 우분투 5일차 정리 (파일과 디렉터리, 링크)

Min:Dev — Mon, 13 Jul 2026 16:56:42 +0900

본 게시글은 "2025년 1월 12일"에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다.
원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

활동명: 길벗 코딩 자율 학습단 12기

활동 일자: 2025년 01월 12일

활동 범위: 리눅스 입문 with 우분투 p.115~147

디렉터리를 다루는 명령어로는 mkdir, rmdir, cp, mv, rm이 있다.
옵션을 잘 활용하면 더 효율적으로 파일과 디렉터리를 다룰 수 있다.
rmdir은 내부가 비어 있어야 삭제할 수 있는 반면, rm -r 옵션은 디렉터리 전체를 한 번에 삭제할 수 있어 주의가 필요하다.
소프트 링크는 원본 파일과 강하게 결합되어 있어 원본이 사라지면 깨질 수 있다.
하드 링크는 원본과 약하게 결합되어 있어 원본이라는 개념이 따로 없고, 원본 파일이 삭제되어도 계속 남아있다.

디렉터리 다루기

mkdir

의미: make directory
역할: 디렉터리를 생성한다.

$ mkdir [옵션] 디렉터리

디렉터리 이름을 여러 개 입력하면 한 번에 여러 디렉터리를 만들 수 있다.

이미 존재하는 디렉터리는 만들 수 없고, 존재하지 않는 디렉터리만 새로 생성된다. 다만 -p(parents) 옵션을 주면 이미 존재하더라도 에러 없이 넘어간다.

예를 들어 animals라는 디렉터리가 있다면, 한 번에 그 하위 디렉터리를 만들 수 있다.
이때 snake 디렉터리를 만들려면 상위 디렉터리인 animals가 먼저 존재해야 하며, 없으면 오류가 발생한다.
-p 옵션을 주면 animals 디렉터리가 없어도 자동으로 생성한 뒤 snake 디렉터리까지 함께 만들어준다.

rmdir

의미: remove directory
역할: 디렉터리를 삭제한다.

$ rmdir [옵션] 디렉터리

mkdir과 마찬가지로 여러 디렉터리를 한 번에 입력하면 모두 삭제할 수 있다.

rmdir은 비어 있는 디렉터리만 삭제할 수 있다.

cp

의미: copy
역할: 파일이나 디렉터리를 복사한다.

$ cp [옵션] 원본파일 대상파일
$ cp [옵션] 원본1 원본2 ... 디렉터리

-f(--force): 대상 파일이 이미 존재하면 강제로 덮어쓴다.
-r(--recursive): 지정한 디렉터리 하위 파일을 모두 복사한다. (디렉터리 복사 시 사용)

여러 개의 파일을 한 번에 복사해서 특정 디렉터리에 넣을 수도 있다.

마지막 경로가 디렉터리가 아니라 파일이면 어떻게 될지 궁금해서 test라는 파일을 만들어 확인해봤다. greeting과 say-hi 파일의 내용이 합쳐져서 들어갈 줄 알았는데, 그런 것은 아니었고 cat 명령어와 동일하게 동작했다.

mv

의미: move
역할: 파일이나 디렉터리를 이동하거나 이름을 변경한다.

$ mv [옵션] 원본 대상
$ mv [옵션] 원본1 원본2 ... 대상

여러 개의 원본을 한 번에 옮길 수도 있다.

-f(--force): 파일을 덮어쓸 때 묻지 않고 실행한다.
-i(--interactive): 파일을 덮어쓸 때 사용자에게 실행 여부를 물어본다.

~/바탕화면/testdir/temporary 경로에서, test 디렉터리 안에 greetings와 say-hi 파일이 있는 상황을 가정해보자.

$ mv test/greetings test/say-hi ..

현재 작업 경로가 temporary일 때 이 명령을 수행하면, 마지막 인자인 ..로 인해 temporary/test/greetings와 temporary/test/say-hi 파일이 temporary의 상위 디렉터리인 testdir로 이동한다.

$ mv temporary/hoho ./hihi

이렇게 하면 이름을 바꾸면서 동시에 이동도 가능하다. temporary 디렉터리 안에 있던 hoho라는 파일의 이름을 hihi로 바꾸면서 temporary와 같은 계층으로 옮긴 것이다.

rm

의미: remove
역할: 파일을 삭제한다.

$ rm [옵션] 파일

-d(--dir): 디렉터리를 삭제한다. rmdir과 같은 역할이다.
-f(--force): 파일이 존재하지 않아도 실패 처리하지 않는다.
-i(--interactive): 파일을 삭제하기 전에 여부를 확인한다.
-r(--recursive): 디렉터리와 그 안에 포함된 모든 파일, 디렉터리를 삭제한다.

-r 옵션을 사용하면 디렉터리까지 통째로 삭제된다. 한 번의 실수로 시스템을 되돌릴 수 없는 상태로 만들 수 있으니 주의해야 한다.
특히 sudo rm -rf /를 실행하면 돌이킬 수 없는 대참사로 이어진다.

소프트 링크, 하드 링크

아이노드

리눅스에서 모든 파일과 디렉터리는 아이노드(inode)라는 고유한 식별 번호를 가지고 있다.

파일 이름은 단지 이 아이노드를 가리키는 이름표일 뿐이고, 실제 파일의 실체(내용, 권한, 소유자 등 메타데이터)는 아이노드에 저장되어 있다.

$ ls -i

이 옵션을 사용하면 각 파일의 아이노드 번호를 확인할 수 있다.

파일의 실제 내용은 데이터 블록(data block)에 저장되며, 데이터 블록(data block)을 아이노드(inode)에 연결하는 구조다.

파일의 경로 정보 (위치 + 이름)은 아이노드가 아닌 덴트리(dentry, directory entry)에 저장하여 계층으로 관리한다.

파일의 경로 정보는 하나의 아이노드와 연결된다.

디렉토리는 데이터 블록을 가지지 않는다.

루트 디렉터리(/)도 하나의 덴트리와 아이노드로 구성된다.

루트 디렉터리(/)의 하위 디렉터리 목록 (sub-dirs)는 루트 디렉터리 덴트리로 관리된다.

다른 디렉터리들도 덴트리와 아이노드로 구성된다.

파일은 디렉터리의 자식(child) 목록으로 관리된다.

소프트 링크

의미: symbolic link, soft link
역할: 원본 파일을 가리키는 일종의 바로가기(단축 아이콘)를 만든다.

$ ln -s 원본 링크이름

윈도우의 바로가기 아이콘을 떠올리면 이해하기 쉽다. 링크 파일 자체는 원본의 경로 정보만 담고 있을 뿐, 실제 데이터를 갖고 있지 않다.

제일 앞의 918450, 918448이 아이노드 식별자다.

소프트 링크는 권한 제일 앞에 l로 표시된다.

s-link 파일은 target 파일을 가르키기에 동일한 결과가 출력되지만, stat 명령어로 확인하면 아이노드 식별자가 엄연히 다른 파일임을 확인할 수 있다.

엄연히 다른 파일이기 때문에 s-link 파일을 실행해도 target의 접근 시간은 그대로 유지된다.

파일 이름이 바뀌면 어떻게 될까?

target의 이름을 target-2로 변경해보자.

소프트 링크는 원본 파일의 경로를 참조하기 때문에, 원본 파일의 이름이 바뀌거나 파일이 삭제되면 소프트 링크는 더 이상 유효한 대상을 가리키지 못하고 깨진 링크(broken link)가 되어버린다.

즉 소프트 링크는 원본과 강하게 결합되어 있다고 볼 수 있다. 원본이 사라지면 링크도 의미를 잃는다.

하드 링크

의미: hard link
역할: 동일한 아이노드를 가리키는 또 다른 이름을 만든다.

$ ln 원본 링크이름

하드 링크는 소프트 링크와 다르게 경로가 아니라 동일한 아이노드를 직접 가리킨다. 그래서 원본 파일이라는 개념 자체가 따로 존재하지 않는다. 두 이름 모두 같은 데이터를 가리키는 동등한 이름일 뿐이다.

복사(cp)와의 동작 차이를 보자.

아예 새로운 데이터 블록과 아이노드를 생성하기 때문에 복사와 하드 링크의 방식에는 차이가 있다.

둘 중 하나의 이름(파일)을 삭제해도 아이노드가 가리키는 실제 데이터는 다른 이름을 통해 계속 남아있다. 아이노드는 그 아이노드를 참조하는 이름이 모두 사라졌을 때만 실제로 삭제된다.

하드 링크를 만들게 된다면 권한 뒤의 연결된 하드 링크의 수가 변경된다.

제일 앞 아이노드의 번호가 동일하다는 것은 아이노드를 공유하고 있다는 의미다.

소프트 링크와 동일한 출력 결과를 나타낸다.

stat으로 두 파일을 비교한다면 아이노드 하나를 공유하기 때문에 접근하는 시간과 수정 시간 모두 공유되기 때문에 한쪽에서 변경을 수행할 경우 양쪽에서 변경된다.

소프트 링크에서는 원본 파일의 이름 target을 target-2로 변경하면 빨간색 출력과 함께 실행이 안됐지만

하드 링크는 정상적으로 동작한다.

소프트링크 vs 하드링크

소프트 링크

원본의 경로를 참조한다.
원본과 다른 아이노드를 가진다.
원본이 사라지거나 이름이 바뀌면 깨진다. (원본과 강하게 결합)
디렉터리도 링크로 만들 수 있다.

하드 링크

원본과 동일한 아이노드를 직접 참조한다.
원본이라는 개념이 따로 없다. (원본과 약하게 결합)
원본이 삭제되어도 다른 이름으로 계속 남아있다.
디렉터리에는 만들 수 없다.

5일차 후기

디렉터리를 다루는 명령어들은 평소 GUI 환경에서 마우스로 하던 작업(복사, 이동, 삭제, 이름 변경)을 CLI로 옮긴 것뿐이라 크게 어렵지 않았다. 다만 소프트 링크와 하드 링크의 차이는 처음 들었을 때는 헷갈렸는데, "경로를 참조하느냐 vs 아이노드를 직접 참조하느냐"로 정리하고 나니 명확해졌다.

처음 알게 된 것

모든 파일과 디렉터리는 아이노드라는 고유 식별자를 가지며, 파일 이름은 그저 아이노드를 가리키는 이름표에 불과하다는 것
소프트 링크는 원본의 경로를 참조하므로 원본이 삭제/이동되면 깨지지만, 하드 링크는 아이노드를 직접 참조하므로 원본이라는 개념 자체가 없다는 것
하드 링크는 그 아이노드를 참조하는 이름이 모두 사라져야 실제 데이터가 삭제된다는 것

[TIL] 리눅스 입문 with 우분투 4일차 정리 (명령어, 파일, 디렉터리)

Min:Dev — Mon, 13 Jul 2026 16:06:28 +0900

본 게시글은 "2025년 1월 11일"에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다.
원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

활동명: 길벗 코딩 자율 학습단 12기

활동 일자: 2025년 01월 11일

활동 범위: 리눅스 입문 with 우분투 p.81~114

CLI 사용에 익숙해지면 GUI보다 훨씬 빠르게 작업할 수 있다.
윈도우가 익숙하게 느껴지는 이유는 그만큼 많이 사용해봤기 때문이며, 리눅스도 자주 사용할수록 익숙해진다.
리눅스 파일 시스템은 윈도우와 달리 드라이브라는 개념이 없다.
리눅스에서는 디렉터리를 포함해 대부분의 대상을 파일로 다룬다.
프로세스와 시스템 정보를 파일처럼 제공하는 가상 파일 시스템(procfs, sysfs)이 존재한다.

CLI vs GUI

CLI(Command Line Interface)는 GUI(Graphic User Interface)보다 한 번에 더 많은 명령을 빠르게 내릴 수 있다는 장점이 있다. 다만 이를 제대로 활용하려면 어느 정도의 숙련도가 필요하다.

출처: https://namu.wiki/w/%EA%B3%A0%EC%9D%B8%EB%AC%BC

리눅스는 CLI로 사용하는 것이 여러모로 유리하다.

GUI로는 설정하거나 자동화할 수 없는 작업이 존재하고, 서버에 GUI 환경을 설치하는 것 자체가 추가적인 자원 소모로 이어지기 때문이다.

명령어 형식

리눅스의 명령어는 다음과 같은 형식을 따른다.

$ 명령어 [옵션] [인자]

명령어 종류에 따라 옵션이나 인자를 추가로 사용한다.

옵션

옵션은 여러 개를 동시에 사용할 수 있으며, 대소문자도 구분한다. 하이픈(-)을 이용해 옵션임을 나타낸다.

하이픈 1개(-): 알파벳 한 글자로 된 옵션을 지정할 때 사용한다.
하이픈 2개(--): 여러 글자로 된 옵션을 지정할 때 사용한다.

$ ls
$ ls -l
$ ls -a -l
$ git commit --amend <새로운 커밋 메세지>

옵션은 순서에 상관없이 사용할 수 있다.

-a와 -A는 서로 다른 옵션이다. 옵션은 대소문자를 구분하므로, 사용하는 명령어에 따라 정확히 구분해서 사용해야 한다.

인자

인자는 명령어에 전달하는 값으로, 파일 이름이나 디렉터리 이름 등이 여기에 해당한다.

$ cd [디렉터리 경로]

명령어

man

의미: manual
역할: 리눅스 명령어에 대한 설명을 확인할 때 사용한다.

$ man [옵션] [섹션] 페이지

페이지는 조회할 대상을 의미하며, 명령어일 수도 있고 개념일 수도 있다.

예를 들어 man man을 입력하면 man 명령어 자체에 대한 자세한 설명을 볼 수 있다.

man --help처럼 help 옵션을 주면 간략한 설명만 확인할 수 있다.

ls

의미: list
역할: 파일 목록을 화면에 출력한다.

$ ls [옵션] [파일]

-a: 모든 파일 출력
-l: 파일의 여러 속성을 포함해 길게 출력
-t: 만들어진 순서대로 출력
-R: 하위 모든 디렉터리를 순회하며 출력
-h: 사람이 읽기 좋은 크기 단위로 출력
-/: 루트 디렉터리 표시
-al: 파일 속성까지 함께 출력

-a, -l, -al은 이전부터 자주 사용했지만, -t, -R, -h, -/는 이번에 처음 알게 되었다.

cd

의미: Change Directory
역할: 현재 위치한 디렉터리를 변경한다.

$ cd [디렉터리]

Bash를 실행하고 로그인하면 사용자는 자신의 홈 디렉터리에서 시작한다. 즉, 사용자 한 명당 하나의 홈 디렉터리를 가진다.

디렉터리를 이동하려면 먼저 현재 위치(HOME 디렉터리)에 어떤 자료가 있는지 확인해야 한다.

$ ls -al

출력 결과에서 맨 앞에 d가 붙어 있으면 디렉터리라는 의미이며, 이를 통해 test 디렉터리로 접근할 수 있다는 것을 알 수 있다.

test에서 다시 상위 디렉터리(바탕화면)로 돌아가려면 다음과 같이 입력한다.

$ cd ..

pwd

의미: print working directory
역할: 현재 작업 디렉터리를 절대 경로로 조회한다.

$ pwd

상대 경로

현재 작업 디렉터리를 기준으로 파일 경로를 나타낸다. (ex. ./test)

절대 경로

루트 디렉터리를 기준으로 파일 경로를 나타낸다. (ex. /home/test)

cat

의미: concatenate
역할: 파일 내용을 연결하거나 조회한다.

$ cat [옵션] [파일]

-n 옵션을 주면 줄 번호와 함께 출력한다.

exit

의미: exit
역할: 현재 실행 중인 셸을 종료한다.

$ exit [종료_코드]

프로세스는 메모리에서 실행 중인 프로그램을 의미하며, 종료 코드는 프로세스가 종료되면서 남기는 상태 값으로 0~255 사이의 정수를 가진다. 터미널에서 exit을 입력하면 셸뿐 아니라 터미널 프로그램 자체도 함께 종료된다.

nano

텍스트 편집기로, VSCode나 메모장처럼 파일을 편집할 수 있다. vim, emacs 등 다른 편집기도 있지만 nano는 상대적으로 간단하게 사용할 수 있다는 장점이 있다.

$ nano [파일명]

지정한 파일이 없는 상태에서 저장 후 종료하면 새로운 파일이 생성된다.

파일 시스템

정의: 파일에 대한 정보를 관리하는 소프트웨어
역할: 운영체제의 요청을 받아 파일을 저장 장치에 저장하고, 원하는 파일을 빠르게 찾을 수 있도록 한다.

파일 시스템은 운영체제별로 지원하는 종류가 다르며, 크게 세 가지로 나뉜다.

디스크 기반 파일 시스템
네트워크 기반 파일 시스템
가상 파일 시스템

디스크 기반 파일 시스템

HDD, SSD 같은 보조 기억 장치를 위한 파일 시스템으로 가장 흔히 사용된다.
물리적으로 연결된 저장 장치에 설치해서 사용할 수 있다.
파일 이름, 크기, 속성, 경로 등의 정보와 실제 파일 내용이 저장된 위치 정보를 함께 관리하기 때문에 빠르게 대응할 수 있다.

포맷(format)이란?

저장 장치에 파일 시스템을 설치하는 것을 의미한다. 파일을 저장할 수 있는 상태로 만드는 과정이기 때문에, 기존 파일 시스템의 정보가 지워지면서 데이터도 모두 삭제된다.

네트워크 기반 파일 시스템

원격 컴퓨터(서버)에 연결된 저장 장치를 네트워크로 연결해 로컬 컴퓨터에서 사용하는 파일 시스템이다.
서버에 직/간접적으로 연결된 저장 장치의 일부를 네트워크 기반 파일 시스템으로 제공할 수 있도록 설정할 수 있다.
대표적으로 NFS, Samba 등이 있다.

가상 파일 시스템

가상 파일 시스템은 실제로 존재하지 않는 파일로 구성된다.
소프트웨어가 노출하려는 정보를 디렉터리와 파일 구조로 표현하는 방식이다.
리눅스의 procfs, sysfs가 대표적이다.
커널이 응용 프로그램에 제공할 정보를 디렉터리와 파일 구조로 만들며, 응용 프로그램이 가상 파일 시스템의 파일을 읽으면 커널이 해당 파일의 핸들러 함수를 호출해 실시간으로 데이터를 생성한다.

데이터베이스의 View처럼, 미리 정의된 함수로 필요한 시점에 데이터를 가공해서 제공하는 구조와 비슷하다는 인상을 받았다.

procfs

정의: process file system
역할: 실제로 존재하지 않는 가상 파일들을 통해 프로세스와 시스템 상태에 대한 정보를 커널이 동적으로 생성해서 제공한다.

프로세스 정보는 /proc 디렉터리에 마운트되며, cd /proc을 입력하면 해당 디렉터리로 이동해 확인할 수 있다. 이때 보이는 숫자로 된 디렉터리들은 각 프로세스의 ID, 즉 PID를 의미한다. 특정 PID 디렉터리에 들어가 status 파일을 열면 해당 프로세스의 상태를 확인할 수 있다.

proc 디렉터리에서 cat meminfo를 실행하면 메모리 사용 현황을 확인할 수 있는데, Windows의 리소스 모니터보다 더 자세한 정보를 보여주는 느낌이다.

sysfs

정의: system file system
역할: 커널의 하위 시스템과 하드웨어 장치 등에 대한 정보를 제공한다.

파일 계층 구조

윈도우

드라이브를 중심으로 이루어진 계층 구조를 가진다.
운영체제가 설치된 드라이브는 C 드라이브이며, 이 외에도 D, E, F 등의 드라이브가 존재할 수 있다.
드라이브는 각각 하나의 디스크에 대응하며, 파티션을 나누면 하나의 디스크를 여러 논리적 디스크로 분리할 수도 있다.

리눅스

리눅스는 모든 파일이 하나의 계층 구조를 이루며, 시스템 전체에 루트 디렉터리(/)가 단 하나만 존재한다. 윈도우가 몇몇 파일을 각자의 드라이브에 나누어 두는 것과 달리, 리눅스는 시스템에 존재하는 모든 파일이 루트 디렉터리 하위에 위치한다.

리눅스 커널은 디스크마다 이름을 붙인다. (ex. /dev/sda) 디스크 이름은 /dev 디렉터리 안에서 장치 파일 이름으로 인식되며, 이 경로에서 식별할 수 있다.
디스크를 운영체제에 연결하려면 먼저 파일 시스템을 디스크에 설치해야 한다.
파일 시스템을 설치한 뒤에는 디스크를 리눅스 시스템에 마운트해야 한다.

마운트란?

파일 시스템이 설치된 디스크를 특정 디렉터리에 연결하는 것을 의미한다. procfs가 /proc에, sysfs가 /sys에 연결되는 것과 같은 방식이다.

예를 들어 disk1을 루트에 마운트하고 hello_world 파일이 있다면 /hello_world 경로로 접근할 수 있고, disk2를 /mnt에 마운트하고 foobar 파일이 있다면 /mnt/foobar 경로로, disk3을 /data에 마운트하고 foobar 파일이 있다면 /data/foobar 경로로 접근할 수 있다.

리눅스는 모든 파일이 단일 계층 구조를 이루기 때문에 윈도우의 드라이브 개념보다 처음에는 낯설게 느껴질 수 있다. 하지만 단일 계층 구조이기 때문에 오히려 더 유연하게 시스템을 구성할 수 있다는 장점이 있다.

파일 종류

리눅스는 디렉터리를 포함해 다양한 대상을 파일로 표현한다. 하드웨어 장치를 제어하기 위한 디바이스 파일도 그중 하나다.

일반 파일(regular file): 영상, 사진, 텍스트 등 흔히 알고 있는 파일
디렉터리: 리눅스에서는 디렉터리도 파일의 한 종류로 취급한다.
심볼릭 링크: 특정 파일을 가리키는 바로가기 파일
블록 디바이스 파일: HDD, SSD, CD, DVD 등을 제어하기 위한 파일
문자 디바이스 파일: 키보드, 마우스, 프린터 등 문자 장치를 제어하기 위한 파일
파이프 파일: 프로세스 간 통신에 사용되는 파일
소켓 파일: 프로세스 간 통신에 사용되는 파일

파일 권한을 나타내는 -rwxrwxr-x, drwxrwxr-x 표기에서 가장 앞의 문자(-, d)가 바로 파일 종류를 나타낸다.

-: 일반 파일
d: 디렉터리
l: 심볼릭 링크 파일
b: 블록 디바이스 파일
c: 문자 디바이스 파일
p: 파이프 파일
s: 소켓 파일

디렉터리

정의: 파일 시스템을 계층화할 때 사용하며, 상하 개념을 만들 수 있다.
루트 디렉터리: 파일 시스템의 최상단에 위치하며 /로 표기한다.

$ pwd

현재 시스템의 디렉터리 위치는 위 명령어로 확인할 수 있다.

핵심 디렉터리는 다음과 같다.

/bin: 기본 실행 명령어 위치
/dev: 디바이스 파일 위치(디스크 등)
/etc: 시스템 설정 파일 위치
/home: 사용자 홈 디렉터리
/lib: 시스템 라이브러리 위치
/mnt: 디스크 등을 임시로 마운트하는 위치
/proc: procfs(가상 파일 시스템)가 마운트되는 위치
/root: root 사용자의 홈 디렉터리
/sbin: 시스템 관리용 명령어 위치
/sys: sysfs(가상 파일 시스템)가 마운트되는 위치
/tmp: 시스템 임시 파일 위치
/usr: 시스템 소프트웨어 위치

홈 디렉터리

정의: 리눅스에 사용자를 추가할 때마다 할당되는, 사용자 전용 디렉터리다.
역할: 사용자별 설정과 데이터가 저장된다.

터미널을 실행하거나 SSH로 접속해 로그인하면, 로그인한 사용자의 홈 디렉터리가 현재 작업 디렉터리로 설정된 상태에서 시작한다. 루트 디렉터리와 달리 ~로 표시되면 현재 계정의 홈 디렉터리를 의미한다.

4일차 후기

리눅스를 정말 얕게만 사용해봤던 입장에서 새롭게 알게 된 내용이 많아 유익했다.

sysfs와 procfs 같은 가상 파일 시스템이 존재한다는 것을 이번에 처음 알았다. 아직 깊이 이해했다고 하기는 어렵지만, 데이터베이스의 View처럼 필요할 때마다 조회해서 사용자에게 정보를 제공하는 구조라는 인상을 받았다.

책에서는 간략하게만 설명되어 있어 추가적인 실습을 통해 직접 알아가고 있는데, 이 내용이 뒤에서 더 깊이 다뤄지길 기대하고 있다. 만약 그렇지 않다면 완독 후 활동 후기를 다시 돌아보면서 부족한 부분을 보완할 생각이다.

처음 알게 된 것

ls의 -t, -R, -h, -/ 옵션을 처음 알았다.
윈도우에서는 흔히 '폴더'라고 부르지만, 리눅스에서는 '디렉터리'라고 부른다는 것을 알았다.
프로세스와 시스템 정보를 담고 있는, 실존하지 않는 동적인 파일 구조인 가상 파일 시스템의 존재를 처음 알았다.
리눅스는 드라이브별로 나뉘는 대신 디스크를 디렉터리에 마운트해서 사용한다는 사실을 처음 알았다.
루트 디렉터리 하위 디렉터리들(/etc, /usr 등)의 용도를 알게 되었다.
파일 권한 표기에서 가장 앞자리가 파일 종류를 나타낸다는 것을 처음 알았다.

[TIL] 리눅스 입문 with 우분투 3일차 정리 (터미널과 셸)

Min:Dev — Sun, 12 Jul 2026 01:32:19 +0900

본 게시글은 "2025년 1월 9일"에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다.
원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

활동명: 길벗 코딩 자율 학습단 12기

활동 일자: 2025년 01월 08일

활동 범위: 리눅스 입문 with 우분투 p.71~80

Bash 셸은 단순히 많이 사용되는 것이 아니라, UNIX 계열 환경에서 오랫동안 사용되며 널리 자리 잡은 이유가 있다.
서버 개발자를 준비한다면 Linux 환경에서 자주 사용되는 Bash 셸을 익혀두는 것이 도움이 된다.
터미널은 사용자와 셸을 연결하는 입출력 인터페이스이며, 실제 명령을 해석하고 실행하는 역할은 하지 않는다.
셸은 사용자의 명령을 해석하고 운영체제와 연결해주는 인터페이스 역할을 한다.
셸 스크립트를 활용하면 반복적인 작업을 자동화하여 시스템 관리와 개발 효율을 높일 수 있다.

터미널(Terminal)

터미널은 사용자와 컴퓨터가 상호작용할 수 있도록 입출력을 담당하는 장치 또는 프로그램이다.

과거의 터미널은 키보드와 모니터가 결합된 하나의 물리적인 단말기였다. 터미널 자체에는 연산 능력이 없었으며, 사용자의 입력을 컴퓨터(메인프레임, 미니컴퓨터 등)에 전달하고 그 결과를 화면에 출력하는 역할만 수행했다.

즉, 실제 연산은 터미널과 연결된 컴퓨터에서 수행되었으며, 터미널은 단순히 입력과 출력을 담당하는 장치였다.

하지만 컴퓨터 기술이 발전하면서 별도의 물리적인 터미널이 필요하지 않게 되었다.

오늘날에는 터미널의 기능을 소프트웨어로 구현한 터미널 에뮬레이터(Terminal Emulator)를 사용한다. 일반적으로 우리가 사용하는 '터미널'은 이러한 터미널 에뮬레이터를 의미하는 경우가 많다.

대표적인 터미널 프로그램은 다음과 같다.

Windows Terminal: Windows
GNOME Terminal: Linux(GNOME 데스크톱 환경)
iTerm2: macOS

터미널의 역할은 사용자와 셸(Shell)을 연결하는 것이다. 사용자가 입력한 명령을 셸에 전달하고, 셸이 실행한 결과를 화면에 출력한다.

따라서 터미널 자체는 명령을 해석하거나 실행하지 않는다. 명령을 해석하고 실행하는 것은 셸의 역할이며, 셸이 없다면 터미널은 단순한 입출력 창에 불과하다.

셸(Shell)

사용자가 입력한 명령을 해석하고 운영체제에 전달하여 실행하는 CLI(Command-Line Interface) 프로그램이다.

터미널과 셸은 자주 혼동되지만 서로 다른 역할을 한다.

터미널(Terminal): 사용자와 셸을 연결하는 입출력 인터페이스
셸(Shell): 사용자의 명령을 해석하고 실행하는 프로그램

즉, 터미널은 명령을 입력하고 결과를 출력하는 창이며, 실제로 명령을 처리하는 것은 셸이다.

예를 들어 터미널에서 ls 명령을 입력하면, 터미널은 입력 내용을 셸에 전달하고 셸이 이를 해석하여 운영체제에 실행을 요청한다. 이후 실행 결과를 다시 터미널이 화면에 출력한다.

과거의 터미널은 컴퓨터와 연결된 물리적인 하드웨어 장치였고, 셸은 그 위에서 사용자의 명령을 처리하는 프로그램이었다. 현재는 대부분 터미널 에뮬레이터를 사용하지만, 터미널과 셸의 역할은 여전히 동일하게 구분된다.

Bash (Bourne Again Shell)

Bash는 GNU 프로젝트에서 개발한 UNIX 계열의 셸이다. 현재도 많은 Linux 배포판에서 기본 셸로 사용되고 있으며, 가장 널리 사용되는 셸 중 하나이다.

Linux 커널을 개발한 리누스 토르발스는 Bash를 개발한 것이 아니다.

Linux는 운영체제의 커널이고, Bash는 사용자의 명령을 해석하고 실행하는 셸이다. 일반적으로 Linux 환경에서는 Linux 커널과 Bash를 비롯한 GNU 유틸리티를 함께 사용하여 하나의 운영체제 환경을 구성한다.

많은 Linux 배포판에서 Bash를 기본 셸로 제공하므로 Bash를 익혀두면 대부분의 Linux 환경에서 동일한 방식으로 명령을 사용할 수 있다.

또한 기본 셸이 Bash인 환경에서도 Zsh와 같은 다른 셸을 설치하여 사용할 수 있으며, Windows에서도 WSL(Windows Subsystem for Linux)이나 Git Bash를 통해 Bash를 사용할 수 있다..

Git Bash

Git Bash는 Windows에서 Git을 설치하면 함께 제공되는 Bash 환경이다.

Windows에서도 Bash 명령어를 사용할 수 있도록 GNU 도구와 Bash를 제공하며, Git 명령어와 함께 Linux에서 사용하는 다양한 명령어를 사용할 수 있다.

또한 Windows 실행 파일도 함께 실행할 수 있어 Windows 환경과 자연스럽게 연동된다.

Zsh (Z Shell)

Zsh는 Bash와 호환되면서도 더 다양한 기능을 제공하는 셸이다.

자동 완성, 강력한 프롬프트 커스터마이징, 플러그인 생태계(Oh My Zsh 등) 등을 지원하며, 개발자들에게 많이 사용된다.

macOS는 Catalina(10.15)부터 기본 셸로 Zsh를 채택하였다.

PowerShell

PowerShell은 Microsoft에서 개발한 셸이다.

기존 텍스트 기반 셸과 달리 객체(Object)를 기반으로 데이터를 처리하는 것이 가장 큰 특징이다. Windows의 기본 셸로 제공되며, 현재는 오픈소스로 공개되어 Linux와 macOS에서도 사용할 수 있다.

터미널과 셸의 관계

앞에서 살펴본 내용을 정리하면 다음과 같다.

터미널(Terminal): 사용자와 셸을 연결하는 입출력 인터페이스이다. 과거에는 키보드와 모니터로 구성된 하드웨어 장치였지만, 현재는 대부분 터미널 에뮬레이터 형태의 소프트웨어로 제공된다.
셸(Shell): 사용자가 입력한 명령을 해석하고 운영체제에 전달하여 실행하는 CLI 프로그램이다.

터미널은 명령을 입력하고 결과를 출력하는 창이며, 셸은 입력된 명령을 해석하고 실행하는 엔진이라고 이해하면 된다.
또한 터미널은 현재 사용 중인 컴퓨터의 셸뿐만 아니라, 네트워크를 통해 다른 컴퓨터에서 실행 중인 셸에도 연결할 수 있다.

과거에는 원격 접속을 위해 Telnet 프로토콜이 널리 사용되었다. 하지만 Telnet은 사용자 이름, 비밀번호, 명령어 등을 평문(Plain Text)으로 전송하기 때문에 보안에 매우 취약했다.

이러한 문제를 해결하기 위해 SSH(Secure Shell) 프로토콜이 등장했다. SSH는 통신 내용을 암호화하여 전송하므로, 네트워크를 통해 원격 컴퓨터의 셸에 안전하게 접속하고 명령을 실행할 수 있다.

즉, 오늘날에는 터미널에서 SSH를 실행하여 원격 시스템의 셸에 접속하는 방식이 가장 일반적으로 사용된다.

셸 스크립트(Shell Script)

셸 스크립트는 셸에서 실행할 명령어들을 순서대로 작성한 스크립트 파일이다.

셸 스크립트는 여러 명령어를 하나의 파일에 작성해 두고, 한 번의 실행으로 모든 명령을 순차적으로 수행할 수 있다.

마지막 명령까지 실행되면 스크립트는 종료된다.

또한 셸 스크립트는 명령행 인수(Command-line Arguments)를 받을 수 있어 상황에 따라 다른 동작을 수행하도록 작성할 수 있다. 이를 활용하면 하나의 스크립트를 다양한 환경에서 재사용할 수 있다.

셸 스크립트는 시스템 관리와 반복 작업을 자동화하는 데 매우 유용하다. 예를 들어 crontab에 셸 스크립트를 등록하면 정해진 시간이나 주기에 맞춰 자동으로 실행할 수 있다.

대표적인 활용 사례는 다음과 같다.

로그 파일 백업
오래된 파일 삭제
서버 상태 점검
애플리케이션 배포
데이터 처리 자동화

또한 셸 스크립트는 단순히 명령어를 나열하는 것에 그치지 않는다. 일반적인 프로그래밍 언어처럼 다음과 같은 기능도 지원한다.

변수
조건문(if)
반복문(for, while)
함수
명령행 인수($1, $2 등)

이러한 기능을 활용하면 단순한 자동화부터 복잡한 시스템 관리 작업까지 효율적으로 구현할 수 있다.

실습

echo로 출력하기
echo는 문자열이나 변수의 값을 화면에 출력하는 명령어이다.
셸 스크립트에서 실행 결과를 확인하거나 메시지를 출력할 때 가장 많이 사용하는 명령어 중 하나이다.
스크립트 파일 만들기
Ubuntu에 기본으로 설치되어 있는 텍스트 편집기를 열어 스크립트 파일을 생성한다.
스크립트 작성

첫 번째 줄의 #!/bin/bash는 Shebang(시뱅)이라고 한다.
Sheban은 스크립트를 실행할 때 어떤 인터프리터를 사용할지 지정하는 역할을 한다.
위 예제에서는 Bash를 사용하여 스크립트를 실행하도록 지정한 것이다.
스크립트 저장
작성을 마쳤다면 Ctrl + X를 눌러 편집기를 종료하고 저장한다.

현재 작업 경로가 ~/바탕화면 이라면, hello.sh 파일은 바탕화면에 생성된다.
스크립트 파일 권한 설정
스크립트를 실행하려면 실행 권한이 필요하다.
실행 권한은 chmod 명령어로 부여할 수 있다.
```
chmod +x hello.sh
```
chmod는 파일이나 디렉터리의 권한을 변경하는 명령어로, Linux를 학습할 때 반드시 익혀야 하는 기본 명령어다.
스크립트 실행
현재 작업 위치가 ~/바탕화면이라면 다음과 같이 실행한다.
```
./hello.sh
```

hello.sh만 입력하면 현재 디렉터리가 아니라 PATH 환경 변수에 등록된 디렉터리에서 실행 파일을 찾는다.

따라서 현재 디렉터리에 있는 스크립트를 실행하려면 ./hello.sh 처럼 경로를 함께 입력해야 한다.

Shebang이 필요한 이유

셸 스크립트는 일반적으로 .sh 확장자를 사용하지만, 확장자만으로 어떤 인터프리터를 사용할지는 결정되지 않는다. 실제로 실행 방식을 결정하는 것은 Shebang(#!/bin/bash)이다.

예를 들어 다음과 같이 작성하면 Bash를 사용하여 스크립트를 실행한다. #!/bin/bash 반면 다음과 같이 인터프리터를 직접 지정하여 실행하면 Shebang은 사용되지 않는다.
bash hello.sh 즉, Shebang은 스크립트를 실행 파일처럼(./hello.sh) 실행할 때 사용할 인터프리터를 지정하는 역할을 한다.

3일차 후기

그동안 Linux를 사용해 오긴 했지만, 개념을 체계적으로 학습한 적은 없었다.

그래서 셸, 터미널, 셸 스크립트처럼 익숙하게 사용하던 것들의 정확한 개념을 새롭게 이해할 수 있었다.

어제 1일차와 2일차 후기를 한꺼번에 작성하면서 학습한 내용은 바로 기록해야 한다는 것을 다시 한번 느꼈다.

며칠만 미뤄도 기억이 흐려지고, 후기를 작성하는 것도 생각보다 훨씬 번거로웠다.

네이버 부스트캠프가 첫 개발 커뮤니티 활동이었고 과정도 상당히 강도 높았기 때문에, 다른 개발 커뮤니티도 비슷할 것이라고 생각했다.

현재 참여 중인 활동은 비교적 여유로운 편이라 부담 없이 학습을 이어갈 수 있었다.

책도 기대 이상으로 친절하게 구성되어 있었다. 중간중간 핵심 팁과 용어 설명이 잘 정리되어 있어 처음 접하는 내용도 어렵지 않게 이해할 수 있었다.

처음 알게 된 것

#!/bin/bash와 같은 인터프리터 지정 문법을 Shebang이라고 한다.
Bash는 많은 Linux 배포판에서 기본 셸로 사용된다.
터미널과 셸은 역할이 완전히 다른 개념이다.

[TIL] 리눅스 입문 with 우분투 2일차 정리 (우분투 설치)

Min:Dev — Sat, 27 Jun 2026 15:24:29 +0900

본 게시글은 "2025년 1월 8일"에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다.
원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

활동명: 길벗 코딩 자율 학습단 12기

활동 일자: 2025년 01월 07일

활동 범위: 리눅스 입문 with 우분투 p.39~70

리눅스 GUI 환경은 CLI 환경보다 설치해야 하는 패키지가 많기 때문에 설치 시간이 더 오래 걸릴 수 있다.
처음 CLI를 사용한다면 어렵기에 GUI를 설치한 후 터미널을 통해 CLI로 빨리 익숙해지는 것이 좋다.
자금적 여유가 된다면 클라우드를 사용하는 것이 편하다.
가상 머신은 설치 중, 이용 중에 문제가 발생할 확률이 높은 편이다.
가상 마신의 Guest Addon을 설치하면 로컬 호스트와 복사 붙여넣기 같은 것들이 가능해진다.

리눅스 시스템 구축 방법

리눅스 시스템을 구축하는 방법은 여러 가지가 있다.

1. 호스트 OS로 직접 설치

컴퓨터의 메인 운영체제로 리눅스를 설치하는 방식이다.

Windows, MacOS를 설치하는 것처럼 실제 하드웨어에 운영체제를 직접 설치한다.

실제 서버 환경에서도 사용하는 방식 중 하나이며, 하드웨어 자원을 가장 직접적으로 활용할 수 있다는 장점이 있다.

2. 가상 머신에 리눅스 설치

하나의 운영체제 위에서 가상화 프로그램을 이용해 다른 운영체제를 실행하는 방식이다.

기존 환경을 유지하면서 리눅스를 사용해 볼 수 있기 때문에 처음 리눅스를 학습할 때 많이 사용하는 방법이다.

다만 호스트 OS의 자원을 공유하기 때문에 하드웨어 사양이나 설정에 따라 성능 저하 또는 환경 문제가 발생할 수 있다.

3. 클라우드 서비스

AWS, Azure, Google Cloud와 같은 클라우드 서비스를 통해 외부 업체의 컴퓨터 자원을 임대하여 사용하는 방식이다.

사용자가 직접 보유한 컴퓨터의 전원을 종료하더라도 클라우드 서버는 외부 환경에서 동작하기 때문에 24시간 서비스를 운영할 수 있다.

다만 사용한 만큼 비용이 발생하며, 사용하지 않는 서버를 계속 실행하면 요금이 청구될 수 있으므로 관리가 필요하다.

클라우드 환경에서는 이미 구성된 서버를 사용하는 경우가 많기 때문에 운영 환경과 유사한 경험을 얻기에는 좋지만, 리눅스 설치 과정을 직접 경험하는 학습 목적이라면 가상 머신 방식이 더 적합할 수 있다.

실습

리눅스 배포판 중 사용자 친화적인 환경으로 많이 사용되는 Ubuntu 24.04 LTS 버전을 사용한다.

다운로드 링크

LTS(Long-Term Support)란?

안정성과 유지보수를 중요하게 생각하는 사용자나 환경을 위해 일반 버전보다 긴 기간 동안 업데이트와 보안 지원을 제공하는 버전이다.

실제 서비스를 운영하는 환경에서는 새로운 기능보다 안정성과 보안이 중요하기 때문에 LTS 버전을 선택하는 경우가 많다.

Ubuntu는 2년마다 4월에 출시되는 버전을 LTS 버전으로 지정한다.

일반 버전: 9개월 지원

LTS 버전: 5년 지원

가상 머신

Windows 환경에서 실습을 진행하기 때문에 VirtualBox를 사용하여 가상 머신 환경을 구성한다.

WSL을 사용하는 방법도 있지만, 이번 실습에서는 Ubuntu Desktop GUI 환경을 직접 구축하고 운영체제 설치 과정을 경험하는 것이 목적이므로 VirtualBox를 사용한다.

WSL은 Windows에서 리눅스 환경을 사용할 수 있도록 제공하는 기능으로, 터미널 기반 개발 환경을 빠르게 구성할 때 유용하다.

다운로드 링크

1. 메인 화면

Oracle Virtual Box 메인 화면이다.

2. 가상 머신 만들기

새로 만들기 버튼을 클릭한 후 다운로드해 둔 Ubuntu 24.04 LTS ISO 이미지를 선택한다.

이후 가상 머신이 저장될 경로와 기본 설정을 지정한다.

3. 사용자 계정

무인 설치 건너뛰기를 선택하면 VirtualBox가 운영체제 설치 과정을 자동으로 진행하지 않고, 사용자가 직접 설치 과정을 수행할 수 있다.

무인 설치(Unattended Installation)를 사용하면 VirtualBox가 미리 설정된 정보를 기반으로 운영체제 설치 과정을 자동화한다.

자동으로 설정되는 항목은 다음과 같다.

사용자 계정 생성
비밀번호 설정
컴퓨터 이름 설정
시간대 설정
Guest Additions 설치
설치 과정에서 필요한 입력 자동 처리

무인 설치 건너뛰기를 선택하면 자동 설치를 수행하지 않는다.

가상 머신만 생성된다.
ISO로 부팅된다.
일반 PC에 OS를 설치하는 것처럼 설치 화면이 나타난다.
언어, 키보드, 사용자 이름, 비밀번호 등을 직접 입력하며 설치를 진행한다.

리눅스 설치 과정을 직접 경험하고 싶다면 무인 설치 건너뛰기를 선택하는 것을 추천한다.

반대로 빠르게 가상 머신 환경을 구성하고 싶다면 무인 설치 기능을 사용하는 것이 편리하다.

4. 사양 설정

가상 머신의 사양은 호스트 PC의 자원을 고려하여 설정해야 한다.
일반적으로 호스트 PC 자원의 일부를 가상 머신에 할당하며, 이번 실습에서는 교재에 있는 사양과 동일하게 설정하여 진행한다.

VirtualBox에서는 주로 CPU 코어 수와 메모리(RAM) 용량 등을 설정할 수 있다.

너무 낮은 사양으로 설정하면 운영체제 설치 및 실행 과정에서 시간이 오래 걸릴 수 있다.
최초 설치 과정에서는 충분한 자원을 할당하고, 설치 완료 후 VirtualBox 설정에서 필요에 따라 조정하는 방식이 효율적이다.

5. 디스크 용량 설정

디스크 용량은 40GB 이상으로 설정하여 진행한다.

VirtualBox에서 디스크 생성 시 "전체 크기 미리 할당" 옵션을 선택하면 가상 디스크 파일이 생성될 때 지정한 용량만큼 실제 디스크 공간을 미리 차지한다.

반대로 동적 할당을 선택하면 실제 사용하는 용량만큼 디스크 파일 크기가 증가한다.
동적 할당 방식은 필요할 때 용량이 증가하기 때문에 초기 공간 사용량을 줄일 수 있다.

일부 환경에서는 성능 차이가 발생할 수 있지만, 학습 목적으로 사용하는 가상 머신이라면 동적 할당 방식으로도 충분하다.

6. 설정 확인

생성할 가상 머신의 최종 설정 값을 확인할 수 있다.

7. 목록

완료 버튼을 누르면 VirtualBox 메인 화면에 생성된 가상 머신이 표시된다.
가상 머신 생성이 완료되면 더블 클릭하거나 시작 버튼을 눌러 실행한다.

8. 실행

Ubuntu 설치 화면에서 Try or Install Ubuntu를 선택하여 실행한다.

9. 언어 설정

언어 설정은 사용자의 환경에 맞게 선택하면 된다.
당시에는 한국어로 설치했지만, 최근에는 개발 환경에서 영어 설정을 주로 사용하고 있다.

10. 접근성 설정

접근성 설정에서는 사용 환경에 맞게 불편함을 줄일 수 있는 기능을 설정할 수 있다.

11. 키보드 레이아웃 설정

키보드 레이아웃은 사용하는 환경에 맞게 선택하면 된다.
촬영 당시에는 한국어 키보드로 설정했지만, 최근에는 개발 환경에서 영어 키보드 설정을 주로 사용하고 있다.

가상 머신 환경에서는 호스트 OS와 게스트 OS 간 입력 처리 과정에서 키보드 인식 문제가 발생하는 경우가 있기 때문에, 가능하다면 영어 키보드 레이아웃을 사용하는 것도 방법이다.

12. 네트워크 설정

네트워크 설정은 호스트 OS에서 사용하는 환경에 맞게 선택하면 된다.

13. Ubuntu 설치 선택

Ubuntu 설치 화면에서는 Ubuntu 체험하기와 Ubuntu 설치 중 선택할 수 있다.
Ubuntu 체험하기는 설치 없이 Ubuntu 환경을 실행해보는 기능이다.

다만 Live 환경이기 때문에 가상 머신을 종료하면 변경한 내용이 유지되지 않을 수 있다.
지속적으로 실습 환경을 사용할 예정이라면 Ubuntu 설치를 선택한다.

14. 대화형 설치와 자동 설치

Ubuntu 설치 방식은 크게 대화형 설치(Interactive Installation)와 자동 설치(Automated Installation)로 나눌 수 있다.

대화형 설치 (Interactive Installation)

설치 중에 사용자가 직접 설정을 선택하는 방식이다.

언어
키보드 레이아웃
시간대
사용자 이름
비밀번호
디스크 파티션
설치 옵션 (일반 설치, 최소 설치 등)

자동 설치 (Automated Installation)

설치에 필요한 정보를 미리 작성한 설정 파일을 기반으로 운영체제를 자동으로 설치하는 방식이다.

Ubuntu에서는 일반적으로 user-data YAML 파일을 사용하여 설치 설정을 정의한다.

identity:
  hostname: ubuntu-server
  username: minseok
  password: ...
timezone: Asia/Seoul
keyboard:
  layout: us

자동 설치를 사용하면 설치 과정에서 사용자의 입력을 요구하지 않고 설정된 값에 따라 설치가 진행된다.
여러 대의 서버를 동일한 환경으로 구축해야 하는 경우, 클라우드 환경에서 서버를 반복 생성하는 경우, 테스트 환경을 빠르게 구성해야 하는 경우 유용하다.

15. 앱 선택

설치 과정에서는 기본 애플리케이션만 설치할지, 추가 도구와 유틸리티를 포함할지 선택할 수 있다.
학습 환경에서는 필요한 도구를 이후에 직접 설치해보는 경험도 중요하기 때문에 기본 설치 옵션을 선택해도 충분하다.

16. 추가 옵션

추가 옵션에서는 타사 소프트웨어와 일부 하드웨어 관련 지원 기능을 설치할지 선택할 수 있다.
설치되는 항목에는 다음과 같은 것들이 포함될 수 있다.

일부 장치 드라이버
무선 네트워크(Wi-Fi) 관련 드라이버
미디어 코덱
추가 소프트웨어 패키지

일반적인 데스크톱 환경에서는 선택해도 되지만, 학습 목적이라면 필요한 패키지를 직접 설치해보는 것도 좋은 경험이 된다.

17. 파티션

파티션 단계에서는 디스크 공간을 어떻게 구성하고 Ubuntu를 설치할지 결정한다.

디스크 지우고 Ubuntu 설치

선택한 디스크의 내용을 모두 삭제
파티션 자동 생성
Ubuntu가 알아서 루트(/), 스왑 등을 구성

수동 파티셔닝

사용자가 직접 디스크 영역을 나누고 파티션 구조를 설정하는 방식이다.
서버 환경이나 특정 디스크 구성이 필요한 경우 사용한다.

일반적인 실습 환경에서는 디스크 지우고 Ubuntu 설치 옵션을 선택하면 충분하다.

18. 계정 설정

Ubuntu에서 사용할 사용자 계정을 생성하는 단계이다.
비밀번호를 설정하여 로그인할 수 있지만, 실제 서버 환경에서는 보안을 위해 비밀번호 로그인 대신 SSH 키 인증 방식을 사용하는 경우가 많다.

이번 실습에서는 로컬 가상 머신 환경이므로 계정 비밀번호를 설정하여 진행한다.

19. 시간대 설정

시간대(Timezone)를 설정하는 단계이다.
한국에서 사용하는 환경이라면 KST(Asia/Seoul)로 설정하면 된다.

반대로 서버 환경에서는 UTC 기준으로 관리하는 경우도 많으며, 서비스 요구사항에 맞게 선택한다.

20. 설정 확인

앞에서 설정한 설치 옵션과 계정, 디스크 설정 등의 최종 값을 확인할 수 있다.

21. 설치

설정이 완료되면 Ubuntu 설치가 진행된다.

설치 시간은 가상 머신에 할당한 CPU, 메모리, 디스크 성능에 따라 달라질 수 있다.

22. 설치 완료

설치가 완료되면 가상 머신을 재부팅하여 설치된 Ubuntu 환경으로 진입한다.

23. 계정 로그인

설치 과정에서 생성한 계정 정보로 로그인한다.

24. 게스트 확장 CD 이미지 삽입

게스트 확장 CD 이미지는 VirtualBox에서 제공하는 Guest Additions 설치 파일이다.
가상 머신 내부의 운영체제가 VirtualBox와 더 원활하게 통신할 수 있도록 추가 드라이버와 기능을 제공한다.

설치하면 다음과 같은 기능을 사용할 수 있다.

화면 해상도 자동 조절: 가상 머신 창 크기에 맞춰 Ubuntu 화면 해상도 변경
마우스 통합: 호스트 OS와 게스트 OS 사이에서 마우스 이동 개선
클립보드 공유: 호스트 OS ↔ 게스트 OS 복사/붙여넣기 지원
파일 드래그 앤 드롭: 호스트와 게스트 간 파일 이동
공유 폴더: 호스트 OS의 폴더를 게스트 OS에서 접근 가능
시간 동기화: 호스트와 게스트 시간 차이 보정

25. 디스크 버튼 눌러서 게스트 확장 기능 설치

Guest Additions 설치 전 필요한 패키지를 설치한다.

sudo apt install build-essential dkms linux-headers-$(uname -r) perl bzip2

설치 과정에서 필요한 컴파일 도구, 커널 헤더, 관련 패키지를 함께 설치한다.
이후 VirtualBox 메뉴에서 삽입된 Guest Additions 이미지를 실행하여 설치를 진행한다.

26. 게스트 Addon 사용

Guest Additions 설치가 완료되면 클립보드 공유와 드래그 앤 드롭 기능을 사용할 수 있다.
설정에서 양방향 공유를 활성화하면 호스트 OS와 Ubuntu 사이에서 파일 이동이나 복사 작업이 가능하다.

다만 가상 머신 환경이나 VirtualBox 버전에 따라 일부 기능이 정상적으로 동작하지 않는 경우도 있다.
특히 파일 이동이 목적이라면 공유 폴더 기능을 사용하는 방식이 더 안정적일 수 있다.

2일차 후기

리눅스를 처음 사용하고 학습하려는 독자를 대상으로 한 도서인 만큼, 사용자 생성 과정을 직접 진행하는 등 독자가 직접 경험하며 학습할 수 있도록 구성되어 있었다.
도서 자체에 이미지가 많이 첨부되어 있어 설명을 따라가며 실습하는 과정에서도 큰 불편함이 없었다.

다만 가상 머신 구축 과정은 호스트 PC의 하드웨어 환경과 설정의 영향을 많이 받기 때문에, 설치 과정에서 예상하지 못한 오류를 마주하는 독자도 있을 것이라고 생각한다.
실습 과정에서 오류가 발생한다면 길벗 코딩 자율학습 네이버 카페의 멘토분들에게 도움을 요청하는 것도 좋은 방법이다.

오랜만에 Ubuntu를 설치해보니 기억나지 않는 부분도 있었지만, 익숙하게 진행할 수 있는 부분도 많아서 큰 어려움 없이 실습을 완료할 수 있었다.

Ubuntu LTS 버전이 짝수 연도 4월에 출시되는 버전이라는 점은 이번 학습을 통해 처음 알게 되었다.
LTS 버전이 일반 버전보다 긴 기간 동안 지원된다는 것은 알고 있었지만, 기본 지원 기간이 5년이라는 점도 새롭게 알게 된 부분이다.

[TIL] 리눅스 입문 with 우분투 1일차 정리 (운영체제, 리눅스)

Min:Dev — Sat, 27 Jun 2026 00:52:10 +0900

본 게시글은 "2025년 1월 7일"에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다.
원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

활동명: 길벗 코딩 자율 학습단 12기

활동 일자: 2025년 01월 06일

활동 범위: 리눅스 입문 with 우분투 p.1~38

운영체제 안에 커널이 포함되는 구조이다.
커널은 운영체제의 핵심 구성 요소로, 하드웨어 자원을 관리하고 프로그램이 자원을 사용할 수 있도록 중개하는 역할을 한다.
파일 시스템은 데이터를 저장하고 관리하는 방식이며, 운영체제마다 다양한 종류의 파일 시스템을 지원한다.
리눅스는 서버 및 개발 환경에서 널리 활용되는 운영체제이다.
개발자는 서비스 개발 및 운영 환경을 이해하기 위해 리눅스에 대한 기본적인 이해가 필요하다.

운영체제란 무엇인가요?

운영체제(OS, Operationg System)는 컴퓨터의 하드웨어 자원을 관리하고, 응용 프로그램이 하드웨어를 효율적으로 사용할 수 있도록 중개하는 소프트웨어이다.

대표적으로 운영체제는 CPU, 메모리, 저장 장치 등의 자원을 관리한다.

프로세스 스케줄링

프로세스 스케줄링은 여러 프로세스 중 어떤 프로세스에 CPU 사용 권한을 부여할지 결정하는 작업이다.

스케줄링 알고리즘: 어떤 프로세스를 선택할지 결정하는 기준과 방법이다.
프로세스 스케줄러: 스케줄링 알고리즘을 기반으로 CPU를 사용할 프로세스를 선택하는 운영체제의 구성 요소이다. 스케줄링 방식은 운영체제마다 다르다.
멀티 태스킹: 운영체제가 CPU 시간을 여러 프로세스에게 빠르게 분배하여 여러 작업이 동시에 실행되는 것처럼 보이게 하는 방식이다.

현재 CPU는 하나 이상의 코어를 가지고 있지만, 실행되는 프로세스의 수는 CPU 코어 개수보다 많은 경우가 많다.

운영체제는 짧은 시간 단위로 여러 프로세스에게 CPU를 번갈아 할당하여 자원을 관리한다.

이 과정에서 프로세스는 실행이 잠시 중단되더라도 이를 직접적으로 알 수 없으며, 마치 자신이 CPU를 계속 사용하고 있는 것처럼 동작한다.

운영체제가 프로그램을 실행하는 과정

프로그램의 실행 파일을 메모리에 적재한다.
CPU는 메모리에 적재된 명령어를 순차적으로 실행한다.
실행 중인 프로그램은 운영체제에서 관리하는 단위인 프로세스가 된다.

커널

커널은 운영체제의 핵심 구성 요소로, 컴퓨터가 부팅될 때 하드웨어를 초기화하고 시스템 자원을 관리하는 역할을 한다.

초기화(Initialization)란?

하드웨어(메모리, CPU, 저장 장치, 입출력 장치 등)를 인식하고 사용할 수 있는 상태로 설정하는 과정이다.
일반적으로 초기화는 장치를 준비하는 것을 의미하며, 데이터를 삭제하거나 공장 초기 상태로 되돌리는 것만을 의미하지는 않는다.
정상 작동을 위한 기본 상태로 설정하는 작업이라 볼 수 있다.

커널이 제공하는 다양한 기능을 기반으로 시스템 라이브러리, 셸, 각종 유틸리티 등이 함께 동작하여 하나의 운영체제를 구성한다.

따라서 커널과 운영체제는 동일한 개념이 아니다.

커널은 운영체제의 일부이며, 운영체제의 핵심 기능을 담당한다.

역할

커널은 운영체제가 여러 애플리케이션을 안정적으로 실행할 수 있도록 하드웨어 자원을 관리한다.

대표적으로 다음과 같은 기능을 수행한다.

프로세스 관리
메모리 관리
파일 시스템 관리
입출력 (I/O) 관리
장치 드라이버 관리
시스템 호출 (System Call) 제공

장치 드라이버

장치 드라이버는 운영체제가 하드웨어 장치를 사용할 수 있도록 연결해 주는 소프트웨어이다.

그래픽 카드, 랜 카드, 저장 장치, 마우스, 키보드 등 컴퓨터에 연결된 대부분의 하드웨어는 각각에 맞는 장치 드라이버를 필요로 한다.

역할

장치 드라이버는 하드웨어 장치를 초기화하고, 운영체제와 하드웨어 사이에서 명령과 데이터를 전달하는 역할을 수행한다.

이를 통해 운영체제는 하드웨어의 세부 동작 방식을 알지 못하더라도 장치를 사용할 수 있다.

드라이버 관리

장치 드라이버는 Windows Update, 하드웨어 제조사 홈페이지 또는 드라이버 관리 프로그램을 통해 설치하거나 업데이트 할 수 있다.

3DP CHIP 이라는 소프트웨어를 통해 받을 수 있는 것들이 장치 드라이버다.

Windows의 장치 관리자에서는 현재 컴퓨터에 연결된 장치와 설치된 드라이버의 상태를 확인하고 관리할 수 있다.

필자는 2014년에 오디오 장치 드라이버를 오랫동안 업데이트 하지 않았던 적이 있었다.

당시 별 다른 프로그램을 실행하지 않았음에도 CPU 사용률이 지속적으로 높아지고 냉각 팬이 계속 최고 속도로 동작하는 문제가 발생핬다.
장치 드라이버를 업데이트 한 뒤 문제가 해결된 경험이 있다.

모든 CPU 사용률 문제가 드라이버 때문인 것은 아니지만, 드라이버 문제 역시 시스템 성능과 안정성에 영향을 줄 수 있으므로 안정성이 검증된 최신 버전으로 관리하는 것이 좋다.

파일 시스템

파일은 운영체제가 데이터를 저장하고 관리하는 기본 단위이다.

파일 시스템은 저장 장치에 파일과 디렉터리를 저장하고 관리하는 방식이다.

또한 파일의 이름, 크기, 저장 위치 등의 메타 데이터를 관리한다.

파일의 읽기, 쓰기, 실행, 권한 및 접근 제어 기능을 제공한다.

FAT(File Allocation Table)

Microsoft에서 개발한 파일 시스템으로, 파일 할당 테이블(File Allocation Table)을 이용하여 파일의 저장 위치를 관리한다.

종류: FAT12, FAT16, FAT32, exFAT 등

장점
- 구조가 단순하여 파일 접근 속도가 빠르다.
- Windows, MacOS, Linux를 비롯한 대부분의 운영체제와 다양한 장치에서 지원하므로 호환성이 뛰어나다.
단점
- FAT32는 단일 파일 크기를 최대 4GB까지만 지원한다.
- 접근 권한, 암호화 등의 보안 기능이 부족하다.
- 저널링(Journaling)을 지원하지 않아 예기치 않은 종료 시 데이터 손상 가능성이 상대적으로 높다.
- 대용량 저장 장치와 많은 파일을 관리하는 환경에서는 성능이 떨어질 수 있다.

저널링(Journaling)이란?

작업 일지를 먼저 작성하고 실제 작업을 수행하는 방식이다.

저널링이 없는 파일 시스템의 저장 방식에 대해 알아보자.
1. 파일 데이터를 저장한다.
2. 파일 정보를 수정한다.
3. 저장 장치에 기록한다.
이 과정 중에 전원이 꺼지면 데이터는 일부 저장되고 파일 정보는 아직 변경되지 않는다.

저널링이 있는 파일 시스템의 저장 방식에 대해 알아보자.
1. "어떤 변경을 할 예정인지" 기록한다. -> 저널(Journal)
2. 실제 데이터를 변경한다.
3. 작업 완료 표시를 한다.
이 과정 중에 전원이 꺼질 경우 운영체제는 저널을 확인해서 완료되지 않은 작업은 취소, 완료된 작업은 반영할 수 있다.

NTFS(New Technology File System)

NTFS는 Microsoft에서 개발한 파일 시스템으로, 기존 FAT 계열 파일 시스템의 한계를 개선하기 위해 만들어졌다.

Windows 운영체제에서 기본적으로 사용되며, 다른 운영체제에서도 일부 지원된다.

NTFS는 MFT(Master File Table)를 기반으로 파일과 디렉터리 정보를 관리한다.

장점
- FAT32와 달리 단일 파일 크기 제한이 매우 크다.
- 대용량 저장 장치에서도 효율적으로 동작한다.
- 파일 권한 관리, 암호화, 압축, 저널링 등 다양한 기능을 제공한다.
- 갑작스러운 시스템 종료 상황에서도 파일 시스템 복구 가능성이 높다.
단점
- Windows 환경에서 가장 최적화되어 있다.
- MacOS에서는 기본적으로 읽기만 지원하며, 쓰기를 위해서는 서드 파티 프로그램이 필요하다.
- Linux에서는 읽기/쓰기를 지원하지만 배포판 및 커널 버전에 따라 지원 방식이 다를 수 있다.

EXT4(Fourth Extended File System)

EXT4는 Extended File System의 네 번째 버전으로, Linux 환경에서 가장 널리 사용되는 파일 시스템 중 하나이다.

EXT 계열 파일 시스템은 Linux 운영체제를 위해 개발되었으며, EXT3의 기능을 개선하여 성능과 안정성을 높인 파일 시스템이다.

파일 정보 관리를 위해 inode 구조를 사용하며, 파일의 연속적인 저장 공간을 효율적으로 관리하기 위해 extent 방식을 사용한다.

inode 방식이란?

index node는 파일의 메타데이터와 데이터 위치 정보를 저장하는 구조체이다.

파일 시스템은 파일 이름 자체를 inode에 저장하지 않는다.

파일 크기

소유자

권한

생성/수정 시간

실제 데이터가 저장된 위치

왜 파일 이름은 없을까?
/home/user/a.txt
/home/user/b.txt

두 파일이 있을 경우 파일 이름이 변경되어도 데이터 위치는 그대로 유지할 수 있다.
파일 이름만 디렉터리 정보에서 변경하면 된다.

extent 방식이란?

연속된 데이터 블록을 하나의 범위로 관리하는 방식이다.

기존 inode 방식은
block 100, block 101, block 102, block 103 이렇게 하나씩 저장된다.

extent 방식은
시작 block: 100, 길이: 4개 이렇게 저장된다.

장점
- Linux 환경에 최적화되어 높은 호환성과 안정성을 제공한다.
- 저널링을 지원하여 시스템 오류나 갑작스러운 종료 상황에서 파일 시스템 손상 가능성을 줄인다.
- 대용량 파일과 많은 파일을 효율적으로 관리할 수 있다.
- 파일 시스템 확장 기능을 지원한다.
단점
- Windows와 MacOS에서는 기본 지원이 제한적이며, 사용하려면 서드 파티 프로그램이 필요하다.
- Linux 환경 외에서는 호환성이 떨어진다.

XFS(eXtended File System)

XFS는 Silicon Graphic(SGI)에서 개발한 파일 시스템으로, 이후 Linux 환경에서 사용되고 있다.

대규모 데이터를 처리하는 환경에 적합하도록 설계되었으며, 데이터베이스 서버, 고성능 스토리지 시스템, 빅데이터 처리 환경 등에서 사용된다.

XFS는 메타데이터 관리에 B+ Tree 구조를 활용하여 대용량 파일과 많은 파일을 효율적으로 관리한다.

장점
- 대용량 파일과 대규모 저장 장치를 효율적으로 지원한다.
- 높은 병렬 처리 성능을 제공하여 다중 코어 환경에서 파일 작업을 효과적으로 처리할 수 있다.
- 파일 시스템 확장(온라인 확장)을 지원하여 운영 중에도 용량 확장이 가능하다.
- 저널링을 지원하여 시스템 장애 발생 시 파일 시스템 복구에 유리하다.
단점
- 작은 파일이 매우 많은 환경에서는 EXT4보다 유리하지 않을 수 있다.
- 단순한 개인용 환경에서는 XFS의 고성능 기능이 필요하지 않을 수 있다.
- 축소(shrink)를 지원하지 않아 사용 중인 파일 시스템 크기를 줄이는 작업은 제한적이다.

ZFS(Zettabyte File System)

ZFS는 Sun Microsystems에서 Solaris 운영체제를 위해 개발한 파일 시스템이다.

기존 파일 시스템과 달리 파일 시스템 기능과 저장 장치 관리 기능(ZFS Pool)을 함께 제공하는 구조를 가진다.

대용량 데이터 저장 환경과 데이터 안정성이 중요한 서버 환경에서 많이 사용된다.

장점
- Copy-on-Write 방식을 사용하여 데이터 무결성을 높인다.
- 데이터 손상을 방지하기 위해 체크섬(checksum)을 사용하여 데이터 오류를 감지할 수 있다.
- 스냅샷(snapshot), 복제(clone) 기능을 지원한다.
- 여러 저장 장치를 하나의 저장 공간처럼 관리할 수 있다.
단점
- Copy-on-Write 방식으로 인해 데이터 수정 시 추가 작업이 발생하여 일부 상황에서는 쓰기 성능이 떨어질 수 있다.
- 메모리 사용량이 비교적 높은 편이다.
- 일반적인 개인 환경에서는 제공하는 기능이 과할 수 있다.

Copy-on-Wrtie란?

데이터를 수정할 때 기존 데이터를 바로 덮어쓰지 않고, 변경된 데이터만 새로운 공간에 기록하는 방식이다.
데이터 복사가 필요할 때 처음부터 전체 데이터를 복사하지 않고 원본 데이터를 유지하다가 실제 수정이 발생하는 시점에 새로운 데이터를 생성한다.

기존 데이터가 손상되는 것을 방지하고 데이터 무결성을 유지할 수 있다.

Windows에서는 디스크 관리를 통해 저장 장치의 파일 시스템 종류를 확인할 수 있다.
Linux는 df -Th 명령어로 확인할 수 있다.

네트워크

네트워크는 컴퓨터와 컴퓨터가 데이터를 주고받을 수 있도록 연결하고 통신하는 기술 체계이다.

네트워크는 하드웨어 장치, 네트워크 소프트웨어, 통신 규칙인 프로토콜이 함께 동작하여 구성된다.

네트워크 드라이버: 유선 랜, 와이파이, 블루투스 등 네트워크 장치를 초기화하여 운영체제와 장치 사이에서 데이터를 전달하는 장치 드라이버이다.
네트워크 스택: 네트워크 통신에 필요한 여러 프로토콜을 구현한 소프트웨어 구조이다. 운영체제 내부에서 데이터의 송수신, 패킷 생성 및 처리, 주소 관리 등의 작업을 담당한다.
네트워크 프로토콜: 데이터를 주고받기 위해 통신하는 장치들이 서로 약속한 규칙이다. 데이터를 어떤 형식으로 만들고, 어떻게 전달하며, 오류가 발생했을 때 어떻게 처리할지 등을 정의한다.

인터럽트

인터럽트는 CPU가 현재 작업을 잠시 중단하고, 특정 이벤트를 먼저 처리하도록 알리는 신호이다.

주로 하드웨어 장치가 운영체제에 이벤트 발생을 알리기 위해 사용한다.

인터럽트 처리 과정

하드웨어 장치에서 이벤트가 발생한다.
장치는 CPU에게 인터럽트 신호를 보낸다.
CPU는 현재 실행 중인 작업을 잠시 중단한다.
운영체제의 커널이 해당 인터럽트를 확인한다.
커널은 적절한 인터럽트 처리 코드(Interrupt Handler)를 실행한다.
필요한 경우 연결된 장치 드라이버의 처리 루틴을 호출한다.

장치 드라이버와 인터럽트

장치 드라이버는 특정 하드웨어를 제어하는 소프트웨어이다.

운영체제가 인터럽트를 받으면 어떤 장치에서 발생했는지 확인하고, 해당 장치 드라이버가 필요한 처리를 수행하도록 한다.

운영체제는 인터럽트를 정확하게 처리해야 하드웨어 장치가 정상적으로 동작할 수 있다.

만약 인터럽트 처리가 제대로 이루어지지 않으면 입력 처리가 지연되거나, 데이터 전달 문제가 발생하는 등 장치가 비정상적으로 동작할 수 있다.

메모리

메모리는 프로그램이 실행되기 위해 필요한 데이터와 명령어를 저장하는 공간이다.

프로그램을 실행하면 운영체제는 프로그램의 실행 파일을 메모리에 적재하고, CPU는 메모리에 저장된 명령어를 가져와 실행한다.

프로그램이 실행되는 동안에는 실행 코드뿐만 아니라 변수, 객체, 함수 호출 정보 등 다양한 데이터가 메모리를 사용한다.

실행 중인 프로그램은 필요에 따라 추가적인 메모리를 요청할 수 있다.

운영체제는 여러 프로세스가 동시에 실행되기 때문에 한정된 메모리 자원을 효율적으로 관리하고 각 프로세스에 적절하게 할당해야 한다.

프로세스별 메모리 공간 관리
메모리 할당 및 해제
사용하지 않는 메모리 회수
가상 메모리 관리

스와핑(Swapping)이란?

메모리가 부족한 상황에서 사용하기 위해 메모리의 일부 내용을 디스크 영역으로 이동시키는 메모리 관리 기법이다.
필요한 데이터가 다시 필요해지면 디스크에 저장된 내용을 메모리로 다시 가져온다.

이 과정을 통해 실제 물리 메모리보다 더 많은 프로그램을 실행할 수 있다.

다만 디스크는 메모리보다 속도가 느리기 때문에 스와핑이 과도하게 발생하면 성능 저하가 발생할 수 있다.

UI

UI(User Interface)는 사용자가 프로그램과 상호작용할 수 있도록 제공되는 화면과 조작 방식을 의미한다.

사용자가 프로그램의 기능을 쉽게 이해하고 사용할 수 있도록 구성하는 것이 목적이었다.

GUI (Graphic User Interface)

GUI는 그래픽 요소를 이용하여 사용자와 상호작용하는 방식이다.

아이콘, 버튼, 창, 메뉴 등 시각적인 요소를 통해 프로그램을 조작할 수 있다.

대표적인 예:

Windows 바탕화면
웹 브라우저
모바일 애플리케이션

특징

직관적이고 배우기 쉽다.
시각적으로 상태를 확인하기 쉽다.
마우스와 키보드를 이용해 조작한다.

CLI (Command Line Interface)

CLI는 텍스트 명령어를 입력하여 프로그램과 상호작용하는 방식이다.

사용자가 명령어를 입력하면 시스템은 해당 명령을 해석하고 작업을 수행한다.

대표적인 예:

Linux 터미널
Windows PowerShell
명령 프롬프트

특징

반복 작업을 자동화하기 쉽다.
명령을 익히면 빠르게 작업할 수 있다.
원격 환경에서도 효율적으로 사용할 수 있다.

필자는 처음에는 CLI가 불편하고 왜 사용하는지 의문이 있었다.
하지만 CLI 사용에 익숙해진 이후에는 명령어 기반 작업의 빠른 처리 속도와 자동화 가능성 때문에 개발 환경에서 자주 활용하고 있다.

Linux란 무엇인가요?

Linux는 1991년에 리누스 토르발즈(Linus Benedict Torvalds)가 개발한 운영체제 커널이다.

리누스 토르발즈는 Linux 커널을 개발했으며, 이후 Linux 커널을 기반으로 다양한 구성 요소가 결합되어 하나의 운영체제 형태인 Linux 배포판이 만들어졌다.

즉, 커널과 운영체제는 동일한 개념이 아니다.

운영체제는 커널을 포함하여 사용자 인터페이스, 시스템 도구, 라이브러리 등 여러 요소로 구성된다.

따라서 일반적으로 사용하는 Ubuntu, Fedora 같은 시스템은 정확히 말하면 Linux 커널을 기반으로 한 운영체제(배포판)이다.

Linux 배포판은 Linux 커널과 운영체제 구성 요소를 함께 묶어 제공하는 형태이다.

대표적인 배포판

Ubuntu
Fedora
Red Hat Enterprise Linux(RHEL)
CentOS
Rocky Linux
Debian

배포판마다 제공하는 패키지 관리 방식, 지원 기간, 목적이 다르기 때문에 사용 목적에 맞는 배포판을 선택하는 것이 중요하다.

일부 배포판은 무료로 사용할 수 있으며, 일부는 기업 지원과 관리 서비스를 포함하여 유료로 제공된다.

사용처

서버

Linux는 웹 서버, 데이터베이스 서버, 클라우드 서버 등 다양한 서버 환경에서 널리 사용된다.

안정성, 보안성, 자동화 도구 지원 등의 이유로 서버 운영 환경에서 많이 선택된다.

클라우드 컴퓨팅

클라우드 환경에서도 Linux는 널리 활용된다.

AWS, Microsoft Azure 같은 클라우드 플랫폼에서는 Linux 기반 가상 서버를 생성하고 운영할 수 있다.

임베디드 시스템

임베디드 시스템은 제한된 하드웨어 자원에서 특정 기능을 수행하는 시스템이다.

Linux는 필요하지 않은 기능을 제거하여 경량화할 수 있고, 다양한 하드웨어를 지원하기 때문에 임베디드 환경에서도 사용된다.

ex) Raspberry Pi

모바일 기기

Android는 Linux 커널을 기반으로 만들어진 모바일 운영체제이다.

또한 ChromeOS 역시 Linux 커널 기반으로 동작한다.

개발자가 리눅스를 알아야 할까요?

모든 개발자가 Linux를 반드시 깊게 알아야 하는 것은 아니다.

하지만 현대 개발 환경에서는 Linux 기반 서버, 클라우드, 컨테이너 환경이 많이 사용되기 때문에 Linux에 대한 이해는 개발 업무에 큰 도움이 된다.

특히 다음 분야에서는 Linux 지식이 중요하다.

백엔드 개발
서버 운영
클라우드 컴퓨팅
DevOps
네트워크 시스템

많은 프로그래밍 언어와 개발 도구가 Linux 환경을 지원하며, 실제 서비스 배포 환경 역시 Linux 기반인 경우가 많다.

따라서 개발자는 애플리케이션 개발뿐만 아니라 운영체제와 시스템 동작 방식에 대한 기본적인 이해를 갖추는 것이 좋다.

1일차 후기

1일차에는 운영체제의 구성과 필요성, 그리고 Linux에 대해 학습했다.

리누스 토르발즈가 어떤 배경에서 Linux를 개발하게 되었는지에 대한 내용이 추가되었다면 더 흥미로웠을 것 같다는 생각이 들었다. 다만 해당 내용까지 포함했다면 학습 범위가 더 길어졌을 것 같기에 핵심 개념에 집중한 구성이라는 느낌도 받았다.

짧은 분량이지만 운영체제가 무엇인지, Linux가 무엇이며 왜 필요한지에 대한 기본 개념이 잘 정리되어 있어 좋았다.
특히 가장 인상 깊었던 부분은 "왜 Linux를 배워야 하는가" 에 대한 내용이었다.

개발 직군에서 Linux를 많이 사용한다는 이유만으로도 충분히 학습할 가치가 있지만, 서버, 클라우드, 임베디드 시스템 등 각 분야에서 Linux가 어떻게 활용되는지 함께 설명되어 있어 Linux를 배우는 목적을 더 명확하게 이해할 수 있었다.

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 멤버십 수료 후기 - Web

Min:Dev — Sun, 21 Jun 2026 20:09:27 +0900

본 게시글은 "2024년 12월 16일에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다. 원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

본 게시글은 네이버 부스트캠프 웹・모바일 9기 활동의 콘텐츠 암묵 서약에 따라 작성 되었으므로 구체적인 미션 내용에 대해서는 발설할 수 없다.

챌린지 과정이 공통 CS 역량을 키우는 과정이었다면, 멤버십 과정은 웹 전문성을 깊이 있게 학습하는 과정이었다.
개발자로서 한 단계 더 성장할 수 있다.
협업의 가치와 중요성을 경험할 수 있는 과정이다.
프로젝트를 기획하고 운영하는 경험을 쌓을 수 있다.
기대와 두려움, 성취감이 함께했던 소중한 시간이었다.

네이버 부스트 캠프 소개

- 네이버 부스트 캠프 소개 + 베이직 과정 리뷰

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 베이직 수료 후기 - Web

2024년 4~5월 기준으로 작성해뒀던 임시 게시글이다. 본 게시글은 네이버 부스트캠프 웹・모바일 9기 활동의 콘텐츠 암묵 서약에 따라 작성 되었으므로 구체적인 미션 내용에 대해서는 발설할

seok3765.tistory.com

- 후기 이벤트 당첨된 챌린지 후기 보러 가기

- 최종 프로젝트 보러 가기

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 챌린지 수료 후기 - Web

※ 본 게시글은 "2024년 8월 14일에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다. 원본 게시글은 다음 링크를 통해 보러 갈 수 있다. 본 게시글은 네이

seok3765.tistory.com

멤버십 과정은 코드 리뷰, 협업 피드백, 개발 방법론, 다양한 개발 도구를 활용해 실무와 유사한 프로젝트를 수행하며 전문 지식과 소프트 스킬을 함께 향상시키는 과정이다.

또한 현업 개발자의 멘토링이 제공되어 단순히 코드를 작성하는 데 그치지 않고, 코드 리뷰를 통해 코드의 문제를 분석하고 해결하는 과정까지 경험할 수 있다.

프레임워크와 라이브러리를 단순히 사용하는 것에 머무르지 않고, 내부 동작 원리와 올바른 활용 방법을 학습한다.

최종 결과물 구현에만 집중하는 것이 아니라 프로젝트 주제 선정부터 요구사항 정의, 설계 ,운영까지 직접 수행하며 오너 의식을 기르고 서비스 개발 전반을 경험할 수 있다.

활동 후기

챌린지 후기에서도 언급했듯이, 3차 테스트를 시원하게 망쳤다고 생각했기에 부스트캠프와는 여기서 작별일 줄 알았다.

그래서 서울 여행을 잠깐 떠날까 싶어서 숙소와 교통편까지 모두 예약한 상태였다.

그런데 아침에 눈을 뜨고 휴대폰을 확인하니 문자 수신함에 멤버십 입과 등록 안내 메시지가 와 있었다.

당연히 탈락 결과 발표 메시지라고 생각했지만, 자세히보니 입과 등록 메시지였다.

이상함을 느끼고 메일함을 열었더니 정말 합격이었다.

내 인생에서 가장 의문스러웠던 이메일이었다.

솔직히 잘못 온 메일인줄 알았다.

입과 테스트를 정말 못 쳤다고 생각했기 때문에 떨어질 것이라 확신하고 있었다. 그런데 다른 캠퍼들과 마지막 테스트에 대해 이야기해 보니 아예 손도 대지 못한 분들도 있었다.

그때 비로소 평가가 시험 결과만으로 결정되는 것은 아니라는 사실을 알게 되었다.

합격 사실을 확인하자마자 여행 예약부터 모두 취소했다.

합격 소식을 접했을 때는 여러 감정이 동시에 밀려왔다. 기쁘기도 했지만, 한편으로는 '내가 과연 멤버십 과정에 적합한 사람일까?' 라는 생각도 들었다.

도전하지 않는다면 후회가 남을 것 같았다. 반대로 도전했다가 실패하더라도 미련은 남을지언정 후회는 남지 않을 것이라 생각했다.

다만 멤버십은 챌린지와 달리 실무형 프로젝트를 수행하고, 현업 개발자 및 분야별 전문가들과 코드 리뷰를 진행하는 과정이었다. 기대만큼 두려움도 컸다.

챌린지 기간에도 코드 리뷰 경험은 있었지만, 현업 개발자와 전문가들에게 내 코드를 보여준다는 사실이 부담스럽게 느껴졌다. 괜히 부족한 점만 보일 것 같아 겁이 났다.

하지만 부끄럽다는 이유로 숨기기만 해서는 성장할 수 없다. 챌린지 기간 동안 수없이 부딪히고 깨지면서 배우는 과정이 가장 큰 성장으로 이어진다는 사실을 몸소 느꼈다. 그렇기에 두려움과 동시에 기대감도 존재했다.

막상 시작된 8주간의 학습 스프린트는 예상과 조금 달랐다. 실무 프로젝트 중심일 것이라 생각했지만, 4주씩 두 번의 미션 기간으로 구성되어 있었고 챌린지와 비슷한 방식으로 웹 전문 지식을 학습하는 과정이었다.

여러 도구를 직접 구현해 보며 학습하는 형태였고, 웹과 관련된 다양한 라이브러리, 프레임워크, 개발 도구를 경험할 수 있는 좋은 기회였다.

이후에는 6주간의 그룹 프로젝트가 진행되었다. 가장 기대했던 기간이면서 동시에 가장 두려웠던 기간이기도 했다.

베이직 2주, 챌린지 4주, 멤버십 학습 스프린트 8주를 거치며 성장한 캠퍼들이 모여 하나의 프로젝트를 만든다는 점에서 기대가 컸다.

반면, 뛰어난 캠퍼들 사이에서 내가 잘 해낼 수 있을지에 대한 걱정도 존재했다.

웹 개발 경험 없이도 졸업 작품을 완수했던 경험이 있었기에 어떻게든 해낼 수 있을 것이라는 자신감도 있었다. 부족한 부분은 다른 캠퍼들에게 배우면서 채워 나가면 된다고 생각했다.

그룹 프로젝트 기간에는 주제 선정부터 기획, 설계, 구현, 협업, 최적화까지 서비스 개발의 전 과정을 경험할 수 있었다.
특히 이 시기에는 개발 역량보다도 협업 능력과 인프라 경험 등 소프트 스킬 측면에서 큰 성장을 이룰 수 있었다.

성장 후기

1차 미션

1차 미션에서는 웹에 대한 이해도를 높일 수 있는 미션이 주어졌다.

1주차

적응보다 생존이 우선이었던 주

공모전 본선 2개와 네이버 부스트 캠프 활동이 겹쳐서 제대로 적응을 못 했던 주간이었다.

당시 나는 HTML, CSS, Vanilla JS를 능숙하게 다루지 못했는데, 웹 서비스를 직접 구현하는 미션을 받았을 때 적지 않게 당황했다.

또한, 챌린지와 달리 일일 단위가 아닌 주간 단위로 미션이 주어졌기 때문에 구현뿐만 아니라 전체 일정과 학습 계획까지 스스로 관리해야 하는 어려움이 있었다.

주간 계획서 작성, 데일리 스크럼, 그룹 리뷰 등 해야 할 일이 급격히 늘어나면서 계획을 세우는 것조차 쉽지 않았다.

데일리 스크럼에서 다른 캠퍼들과 진행 상황을 공유할 때마다 진도 차이가 크게 느껴졌다.

웹 퍼블리싱 경험이 부족했던 반면, 같은 그룹원들은 이미 관련 경험이 있었기에 더욱 비교가 되었다.

챌린지 기간 동안 남과 비교하지 않기로 다짐했지만, 매일 진행 상황을 공유하다 보니 쉽지 않았다.

이 시기에는 '멤버십에 오면 안 됐던 건 아닐까?'라는 생각이 들 정도로 많이 위축되었다.

다행히 동료들의 격려와 응원 덕분에 자신감을 회복할 수 있었다.

다른 그룹의 그룹원들과도 진도 공유나 이야기를 나누면서 내가 특별히 뒤처진 것이 아니라는 사실을 깨달았고, 내가 속한 그룹의 수준이 다른 그룹에 비해 이상하게 높았다는 것을 알게 되었다.

생산성을 높이기 위한 준비

나는 그룹원들을 따라잡기 위해 철저한 계획 작성에 몰입했다.

학습 스프린트는 총 8주 동안 진행되었기에 초반 준비가 전체 과정의 효율을 좌우할 것이라 생각했다.

내가 작성한 주차별 계획은 다음과 같다.

1주차: HTML, CSS
2주차: Vanilla JS
3주차: Backend
4주차: API 연동

첫 주차라 구체적인 계획은 잡기 어려워서 주차별로 계획을 작성하였고, 한 주 동안 시간을 어디에 많이 사용했는지 분석해 보니 문서 작업에 예상보다 많은 시간을 쓰고 있었다.

이 상태가 계속된다면 8주 동안 얻어갈 수 있는 것이 줄어들 것이라 판단하여 각종 문서 템플릿을 미리 제작했다.

결과적으로 이 템플릿은 학습 스프린트 기간 내내 큰 도움이 되었다. 첫 주에 템플릿을 만들지 않았다면 이후의 미션 수행은 훨씬 비효율적이고 일관성 없이 진행되었을 것이다.

챌린지 기간 동안 여러 번 무너져 본 경험이 있었기에, 오히려 1주차에는 빠르게 감정을 정리하고 다시 집중할 수 있었다.

또한 지금 당장 무엇을 해야 하는지 스스로 판단하는 능력이 이전보다 성장했다는 것을 느꼈다. 과거의 실패 경험이 새로운 문제를 해결하는 자산이 된 것이다.

기술보다 강점을 발견하여 팀에게 영향 미치기

당시에는 개발 진도가 느렸기에 팀원들에게 기술적으로 도움을 줄 수 있는 부분이 많지 않았다.

대신 눈에 들어온 것은 팀원 피드백이었다.

학교 프로젝트에서 팀장을 자주 맡았던 경험 덕분에 사람들의 강점을 파악하고 역할을 배분하는 데 자신이 있었다. 그래서 이 강점을 활용해 팀원들에게 도움이 되는 피드백을 남기고자 했다.

각 팀원의 활동을 꼼꼼하게 관찰하며 정성껏 피드백을 작성했다.

그 결과 운영진에게 직접 언급을 받게 되었다.

당시 큰 뿌듯함을 느꼈고, 잃어가던 자신감을 완전히 회복할 수 있었다. 무엇보다 기술적인 역량 외에도 사람을 관찰하고 피드백하는 능력 역시 나만의 강점이라는 사실을 다시 한번 확인할 수 있었다.

2주차

프론트에서의 흥미를 발견한 주

2주차는 Vanilla JS를 중심으로 학습을 진행했다.

직접 작성한 코드가 화면에서 즉시 결과로 나타난다는 점이 흥미롭게 느껴졌다.

React를 사용해 본 경험은 있었지만, Vanilla JS를 깊게 다뤄본 경험이 없는 분들이 있었기에 이때부터는 구현 방식에 대해 토론하고 의견을 나눌 수 있었다.

시각적으로 즉시 보인다는 점에서 프론트엔드 개발의 매력을 처음으로 느끼게 되었다.

좋은 코드는 결국 협업을 위한 코드

구현을 진행하면서 단순히 동작하는 코드보다 리뷰하기 쉽고, 읽기 쉽고, 유지보수하기 쉬운 코드를 작성하기 위해 노력했다.

코드를 작성하는 방식 하나에도 팀원들의 생산성이 영향을 받는다는 사실을 느꼈고, 자연스럽게 컨벤션을 지키는 습관도 생기기 시작했다.

이 시기를 계기로 컨벤션이 단순한 규칙이 아니라 협업 비용을 줄이는 도구라는 점을 이해하게 되었다.

피드백 방식의 개선
1주차에는 금요일 하루 동안 다섯 명의 팀원 피드백을 한꺼번에 작성했다.
그러다 보니 일부 내용을 잊어버리거나 충분히 고민하지 못한 채 작성하는 경우가 있었다.

2주차에는 방식을 바꿨다.
매일 한 명씩 피드백을 작성하고, 평소에도 팀원들의 활동을 한 줄씩 기록해 두었다. 덕분에 훨씬 구체적이고 진정성 있는 피드백을 남길 수 있었고, 피드백 자체의 품질도 크게 향상되었다.

돌이켜보면 2주차는 단순히 프론트엔드 기술을 익힌 시간이 아니었다. 1주차의 시행착오를 개선하며 나만의 작업 방식과 협업 방식을 만들어가기 시작한 시기였다.

3주차

코드 구조와 설계에 관심이 생기기 시작한 주

3주차에는 본격적으로 백엔드 개발을 시작했고, 프론트엔드에는 FSD(Feature-Sliced Design) 구조를 적용해 보는 경험을 할 수 있었다.

초반에는 기능 구현에만 집중했지만, 프로젝트 규모가 커질수록 코드가 길어지고 복잡해졌다. 시간이 지나자 내가 작성한 코드조차 다시 이해하기 어려워지는 순간들이 생겼다.

이 경험을 통해 단순히 동작하는 코드보다 유지보수하기 쉬운 구조가 중요하다는 사실을 체감했다.
그래서 프론트엔드 코드에 FSD 구조를 적용했고, 기능과 책임을 분리하면서 코드를 더 관리하기 쉬운 형태로 개선할 수 있었다.

백엔드가 나에게는 적합하다.

2주차에는 프론트엔드의 재미를 발견했다면, 3주차에는 다시 백엔드의 매력을 느끼게 되었다.
Express를 활용해 서버를 구현하면서 데이터를 처리하고 관리하는 과정이 흥미롭게 다가왔다.

프론트엔드는 사용자가 직접 결과를 볼 수 있다는 점이 매력적이었지만, 서비스의 핵심 로직과 데이터를 설계하는 백엔드 역시 또 다른 재미가 있었다.
특히 이 시기에는 디자인 패턴, 아키텍처, 코드 구조와 같은 주제에 관심이 많아졌다.

백엔드 경험이 어느 정도 있었기에 프론트엔드보다 상대적으로 빠르게 작업을 진행할 수 있었고, 구현보다 구조를 고민하는 시간도 점점 늘어나기 시작했다.

협업을 위한 코드를 고민
현업 개발자와의 피드백 세션, 그리고 팀원들과의 코드 리뷰를 통해 협업 방식도 함께 배울 수 있었다.
특히 PR 작성 규칙을 지키며 변경 사항을 설명하는 연습을 많이 했다. 이전에는 코드 자체에만 집중했다면, 이제는 다른 사람이 내 코드를 이해할 수 있도록 전달하는 과정도 중요하다는 것을 알게 되었다.

또한 코드 리뷰를 반복하면서 좋은 코드에 대한 생각도 조금씩 바뀌었다.
예전에는 주석을 많이 작성하는 것이 좋은 코드라고 생각했지만, 이 시기에는 주석이 없어도 의도가 자연스럽게 읽히는 코드가 가장 좋은 코드라는 생각을 하게 되었다.

결국 협업하기 좋은 코드는 다른 사람이 쉽게 이해할 수 있는 코드라는 점을 배울 수 있었던 한 주였다.

4주차

성장의 결과가 보이기 시작한 주

4주차에 들어서면서 여전히 끝내야 할 미션이 많이 남아 있었다.
한때는 일부 기능을 포기하고 선택과 집중을 해야 하나 고민하기도 했다. 하지만 결과적으로는 모든 미션을 마무리할 수 있었고, 스스로도 예상하지 못한 결과였기에 더욱 뿌듯했다.

돌이켜보면 4주차의 성과는 갑자기 만들어진 것이 아니었다.
1주차에 계획을 세우고, 템플릿을 만들고, 작업 방식을 개선했던 경험들이 조금씩 쌓이면서 자연스럽게 생산성이 높아졌다. 초반에는 느려 보였지만, 결국 그 준비 과정이 후반부의 속도를 만들어 준 셈이었다.

또한 구현 과정에서 이전보다 더 빠르게 의사결정을 내릴 수 있게 되었다.
예전에는 코드를 작성한 뒤에도 이 방식이 맞는지 오랜 시간 고민했다면, 이제는 여러 선택지 중에서 유지보수성과 가독성을 고려해 더 적절한 방법을 선택할 수 있게 되었다.

아직 부족한 점은 많았지만, 적어도 코드의 품질을 스스로 평가하고 개선하는 능력은 이전보다 성장했다는 것을 느낄 수 있었다.

1차 미션 종합 후기

1차 미션을 마치며 느낀 점은 슬로우 스타트도 나쁘지 않다는 것이다.
초반에는 다른 캠퍼들보다 느리다고 생각해 조급함을 느꼈지만, 오히려 충분한 준비와 계획 수립에 시간을 투자했기에 이후의 작업을 더 효율적으로 수행할 수 있었다.

또한 이번 과정을 통해 남과 비교하기보다 나 자신에게 집중하며 성장하는 방법을 조금씩 터득할 수 있었다.
무엇보다 가장 큰 수확은 학습과 구현을 병행하는 자신만의 방식을 찾았다는 점이다.
이전에는 공부를 한 뒤 구현을 해야 한다고 생각했지만, 이번 미션을 통해 학습과 구현은 분리된 과정이 아니라 서로를 보완하며 함께 진행할 수 있다는 사실을 배울 수 있었다.

1차 미션은 웹 기술을 배우는 시간이기도 했지만, 스스로 성장하는 방법을 배우는 시간이기도 했다.

2차 미션

1차 미션이 웹 전반에 대한 이해도를 높이는 과정이었다면, 2차 미션은 각자의 전문성을 더욱 깊게 탐구하는 과정이었다.

이번에는 풀스택으로 진행했던 이전 미션과 달리 프론트엔드와 백엔드 중 하나를 선택할 수 있었다.

선택한 분야를 중심으로 보다 심화된 미션이 주어졌으며, 단순히 기능을 구현하는 것을 넘어 해당 분야의 설계 방식과 문제 해결 능력을 기를 수 있는 내용으로 구성되어 있었다.

1차 미션이 웹 개발의 기초 체력을 기르는 시간이었다면, 2차 미션은 자신만의 전문 분야를 만들어 가는 시간에 가까웠다.

1주차

가장 크게 좌절했던 주

멤버십 기간 중 가장 힘들었던 시기를 꼽으라면 주저 없이 2차 미션 1주차를 선택할 것이다.

다른 캠퍼들은 보통 2차 미션의 3~4주차를 가장 힘들었던 시기로 이야기한다. 장기간 이어지는 일정과 체력적인 부담 때문이었다.

하지만 나에게 가장 힘들었던 시기는 1주차였다. 체력이 아니라 멘탈이 무너졌기 때문이다.

1주차에는 페어 프로그래밍으로 미션을 수행했다.
운 좋게도, 아니 어쩌면 운 나쁘게도 정말 뛰어난 캠퍼와 페어가 되었다.
처음에는 서로 이번 미션에서 도전해 보고 싶은 주제를 이야기했다.

나는 TypeScript와 TDD를 이야기했고, 페어는 ESLint와 Prettier를 활용한 협업 환경 구축을 이야기했다.

문제는 첫날부터 시작되었다.

TypeScript 경험도 부족한 상태였는데 ESLint, Prettier, 테스트 환경까지 함께 구축해야 했다. 설정 방식도 내가 알고 있던 예전 방식과 많이 달랐기에 환경 구축만 3일 가까이 소요되었다.

반면 페어는 달랐다.

이미 웹 개발 경험도 풍부했고, 환경 구축은 물론 코드 작성, 구조 개선, 반복 작업 자동화까지 자연스럽게 수행했다.
특히 문제를 발견했을 때 단순히 해결하는 것이 아니라 코드로 문제 자체를 없애는 모습을 보며 큰 충격을 받았다.
당시의 나는 '잘하는 개발자'를 머릿속으로만 상상하고 있었는데, 눈앞에서 그 모습을 보고 있는 느낌이었다.

원래 페어 프로그래밍은 서로 배우기 위한 활동이다.

하지만 당시 나는 배우기보다 위축되었다.

키보드 주도권이 내 차례가 될 때마다 긴장했고, 실수하면 안 된다는 생각 때문에 오히려 더 아무것도 하지 못했다.

페어는 정말 좋은 사람이었다.

내가 부족한 모습을 보여도 끊임없이 격려해 주었고, 이해하지 못하는 부분을 물어봐도 성실하게 설명해 주었다.
그럼에도 불구하고 나는 스스로를 계속 비교했고, 결국 자신감을 크게 잃어버렸다.
지금 돌이켜보면 그 주에 가장 후회되는 일도 있었다.
이해하지 못한 내용을 이해한 척 넘어간 것이다.

페어에게 방해가 될까 봐, 흐름을 끊을까 봐 질문하지 못했던 순간들이 있었다.
개발자로서 가장 경계해야 할 태도 중 하나라고 생각한다.
모른다는 사실보다 모르는 것을 숨기는 것이 더 위험하다는 것을 그때 깨달았다.

그리고 페어 프로그래밍때 개발자로서는 절대 하면 안되는 짓도 했다. 페어분께 방해될까봐 이해한 척 넘어갔던 상황들도 있어서 너무 죄송하기도 했고 스스로에게도 부끄러웠다.

1주차가 끝날 무렵에는 많이 무너져 있었다.
하지만 결국 다시 일어나야 했다.

시간은 나를 기다려주지 않았고, 여기서 멈춰 있을 수도 없었다. 그때 스스로에게 이런 질문을 던졌다.

'운영진은 왜 나를 멤버십에 합격시켰을까?'

분명 내가 부족한 부분도 있었겠지만, 반대로 나만의 강점도 있었기에 이 자리에 올 수 있었을 것이다.

또한 멤버십에 오고 싶어 했던 많은 캠퍼들이 있었다.
그 사실을 떠올리자 지금 이 시간을 좌절로만 보내는 것은 이 기회를 소중하게 여기지 못하는 행동처럼 느껴졌다.
그렇게 다시 마음을 다잡고 다음 주를 준비하기 시작했다.

2주차

자신감을 회복한 주

2주차에는 혼자 미션을 진행하게 되었다.
1주차에는 페어와 함께 개발하며 끊임없이 비교하고 위축되었다면, 이번에는 온전히 내 속도에 맞춰 개발할 수 있었다. 그 덕분에 부담감도 한결 줄어들었다.

무엇보다 주말 동안 많은 생각을 했다.

좌절감에만 머물러 있기보다 1주차에 배웠던 것들을 다시 정리해 보기로 했다.
페어와 함께 구현했던 코드를 처음부터 다시 읽어 보았고, 환경 구축 과정도 혼자 처음부터 다시 진행해 보았다.

그 과정에서 놀라운 사실을 깨달았다.
1주차에 이해하지 못했다고 생각했던 내용들이 사실은 이해할 능력이 없었던 것이 아니었다. 단지 너무 많은 새로운 정보가 한꺼번에 들어오면서 충분히 소화할 시간이 없었던 것이다.
혼자 다시 따라 해보니 그동안 이해한 척 넘어갔던 부분들이 하나씩 연결되기 시작했다.

그제야 페어가 왜 그런 선택을 했는지, 왜 그런 구조를 사용했는지 이해할 수 있었다.
결국 나를 가장 힘들게 만들었던 경험이 가장 큰 성장의 계기가 되었다.
돌이켜보면 1주차의 페어는 내게 정말 큰 영향을 준 사람이었다.
단순히 미션을 함께 수행한 것을 넘어, 내가 어떤 개발자가 되고 싶은지 생각하게 만들어 주었다.

지금도 멤버십 기간 동안 만난 가장 고마운 사람 중 한 명으로 기억하고 있다.
한편으로는 그만큼 감정적으로도 많이 흔들렸던 시기였다.

1주차가 너무 힘들었던 탓에 멘토님과 그룹원들이 함께하는 회고 시간에는 울먹이며 이야기했던 기억도 있다.
지금 생각하면 조금 부끄럽기도 하지만, 그만큼 진심으로 고민하고 있었고 성장하고 싶었던 시기였던 것 같다.

결과적으로 2주차는 기술적인 성장보다도 자신감을 회복한 시간이었고, 남과 비교하는 대신 어제의 나와 비교하는 법을 다시 떠올릴 수 있었던 한 주였다.

3주차

팀 문화의 중요성을 깨달은 주

1주차와 2주차를 돌아보면 기술적으로는 많은 것을 배웠지만, 소프트 스킬 측면에서는 아쉬움이 남았다.

특히 초반에는 자신감이 많이 떨어져 있었기에 그룹 활동에서도 다른 캠퍼들에게 의존하는 경우가 많았다.

'기술적인 기여가 아니라면, 내가 팀에 기여할 수 있는 것은 무엇일까?'

그 질문에 대한 답으로 선택한 것이 팀 문화였다.

3주차에는 새로운 그룹원들과 함께 매주 목요일 기술 공유 시간을 만들었다.
또한 코드 리뷰를 어떤 방식으로 진행할지, 어떤 기준으로 피드백을 남길지에 대해서도 그룹 내 규칙을 정했다.

처음에는 단순히 더 활발한 그룹 활동을 만들고 싶다는 생각이었다.
하지만 예상보다 훨씬 큰 효과가 있었다.
기술 공유를 통해 혼자 공부할 때보다 훨씬 많은 지식을 얻을 수 있었다.
각자 다른 주제를 학습하고 공유하다 보니 한 사람이 얻을 수 있는 지식의 범위를 자연스럽게 넓힐 수 있었다.
또한 처음 접하는 기술을 공유하다 보면 당연히 부족한 부분이 생길 수밖에 없었다.
그럴 때마다 해당 기술을 알고 있는 다른 팀원이 내용을 보완해 주거나, 함께 자료를 찾아보며 토론했다.
덕분에 단순히 발표하는 시간이 아니라 모두가 함께 학습하는 시간이 되었다.

무엇보다 인상 깊었던 점은 좋은 문화가 개인의 성장까지 바꿀 수 있다는 사실이었다.
기술 공유와 코드 리뷰 문화가 자리 잡자 그룹 전체의 참여도가 높아졌고, 자연스럽게 나 역시 더 적극적으로 학습하게 되었다.
이 경험이 너무 인상적이어서 이후 그룹 프로젝트를 진행할 때도 동일한 문화를 도입했다.
돌이켜보면 3주차는 기술을 배운 주라기보다 협업을 배운 주였다.

좋은 팀원도 중요하지만, 좋은 팀 문화는 그 이상의 가치를 만든다는 사실을 깨달을 수 있었던 시간이었다.

특히 인상 깊었던 일도 있었다.
이때 함께한 그룹원 중 한 분은 챌린지 기간에도 같은 그룹으로 활동했던 분이었다.
그분께서 예전과 비교해 훨씬 적극적으로 변한 것 같고, 그룹 활동을 하는 내내 편하게 참여할 수 있었다는 이야기를 해주셨다.

개인적으로는 정말 기쁘고 뿌듯한 순간이었다.

스스로는 성장했다고 생각하고 있었지만, 객관적으로 확인할 방법은 많지 않았다. 그런데 과거의 내 모습을 알고 있는 사람이 변화를 직접 이야기해 주니 그동안의 노력이 헛되지 않았다는 생각이 들었다.

무엇보다 기술적인 성장뿐만 아니라 협업 방식과 소통 능력 역시 함께 성장하고 있다는 것을 확인할 수 있었던 경험이었다.

4주차

선택과 집중의 중요성을 배운 주

1차 미션에서는 구현 자체에 집중했다면, 2차 미션에서는 구현보다 학습에 더 많은 시간을 투자했다.
그 결과 얻어간 지식은 많았지만, 모든 기능을 완벽하게 구현하지는 못했다.

처음에는 아쉬움도 있었다.
하지만 4주차에 들어서면서 생각이 바뀌었다.
이미 3주 동안 구현하고 학습했던 내용들이 있었고, 남은 시간은 한정되어 있었다. 모든 것을 붙잡기보다는 지금 가장 가치 있는 것이 무엇인지 판단해야 했다.

그래서 남은 기간 동안은 선택과 집중을 하기로 했다.
내가 이미 알고 있는 내용보다 아직 이해하지 못한 부분, 구현해 보지 못한 기능, 그리고 가장 궁금했던 주제들을 우선순위로 두었다.

결과적으로 모든 기능을 완성하지는 못했지만, 더 많은 것을 배울 수 있었다.
무엇보다 이번 경험을 통해 스스로 무엇을 알고 있고 무엇을 모르는지 객관적으로 돌아볼 수 있었다.
또한 부족한 부분을 인정하고 학습 계획을 세우는 것 역시 중요한 역량이라는 사실을 배웠다.

돌이켜보면 4주차는 단순히 미션을 마무리한 시간이 아니라, 한정된 시간 안에서 최선의 선택을 하는 방법을 배운 시간이었다.

2차 미션 종합 후기

2차 미션을 통해 가장 크게 얻은 기술적 성장은 TDD(Test Driven Development)에 대한 관점의 변화였다.
처음에는 테스트 코드를 작성하는 과정이 번거롭고 생산성을 떨어뜨린다고 생각했다.
실제로 초기 개발 속도만 놓고 보면 테스트 코드를 작성하지 않는 편이 더 빠를 수도 있다.

하지만 기능이 추가되고 서비스가 커질수록 테스트 코드의 가치가 드러났다.
테스트 코드는 새로운 기능을 도입할 때 기존 기능이 망가지지 않았는지 검증할 수 있는 안전장치가 되어 주었다.
또한 내가 명세대로 구현했는지를 확인하는 점검표 역할도 수행했다.

서비스는 끊임없이 변화한다.
그 변화 속에서 안정성을 유지하기 위해 테스트 코드는 선택이 아니라 투자라는 사실을 배울 수 있었다.

기술적인 성장 외에도 소프트 스킬 측면에서 얻은 깨달음이 있었다.
나는 뛰어난 기술로만 팀에 기여하는 사람이 아니었다.
상황에 맞게 내가 할 수 있는 일을 찾고, 필요한 문화를 만들고, 부족한 부분을 채워 나가는 방식으로도 팀에 기여할 수 있었다.

이번 2차 미션을 통해 '지금 내가 할 수 있는 것을 찾아 실행하는 것' 역시 나의 강점이라는 사실을 다시 한번 확인할 수 있었다.

그룹 프로젝트 후기

그룹 프로젝트 후기는 별도의 프로젝트 회고 글에서 자세히 다룰 예정이기에, 이 글에서는 멤버십 과정에서 얻은 경험 위주로만 간략하게 이야기하고자 한다.

- Denamu 바로 가기

My Blog

My WordPress Blog

your-website-url.com

서비스 소개

우리 Web 05 팀은 개발 블로그 플랫폼별로 분산되어 있는 피드를 한곳에 모아 제공하는 개발 블로그 큐레이션 서비스 Denamu를 개발했다.

이 서비스는 지속적으로 성장하여 개발 커뮤니티를 형성하는 것을 목표로 하고 있다.

팀 목표

프로젝트 주제를 선정할 때, 2가지 키워드에 집중을 했다.

지속 성장 가능성이 있는가?
실현 가능성이 있는가?

지속 성장 가능성

지속 성장 가능성을 위해 생각한 건 '서비스가 지속적으로 발전하려면 무엇이 있어야 할까?'이다.

이때 필요한 건 사용자라 결정지었다.

사용자가 있어야 프로젝트를 하는 의미가 있고 사용자가 곧 성장의 원동력이라 생각했다.

그렇다면 사용자 범위를 축소하여 지속적으로 우리 서비스를 사용하도록 해야 하며, 비로그인 사용자도 접근할 수 있도록 진입 장벽을 낮추는 것이었다.

지속 성장 가능성에 대해 생각하다 보니, 기능을 늘리는 것보다 핵심 문제를 명확하게 해결하는 것이 중요하다고 판단했다.

실현 가능성

우리는 6주라는 짧은 시간 안에 프로젝트를 완료해야 했다.

마감 기한이 있는 프로젝트이기에 기간 안에 최대한의 완성도를 내야했다. 그렇기에 완성도에 집중을 하여 프로젝트를 계획했다.

비록 마스터분들이나 다른 캠퍼분들이 간단한 프로젝트라고 평가하고 팀 내에서도 어려운 기술을 도입하지 않았지만 완성도를 고려하는 것 또한 하나의 기술적 도전이라 판단했다.

완벽한 서비스를 만들어서 UX를 향상시키는 것도 서비스에서 가장 중요한 요소라 판단했다.

또한, 6주만에 완성하고 버리는 디지털 쓰레기가 아닌 지속적으로 개발하며 발전시키는 프로젝트를 만들고 싶었다.

느낀점

이번 프로젝트를 통해 개발과 관련하여 내가 지금까지 해왔던 많은 행동들을 돌아보고 반성할 수 있었다.

작성하다 보니 네이버 부스트캠프는 단순히 기술을 배우는 과정이 아니라, 내가 가진 습관과 사고방식을 점검하고 개선하는 과정이었다는 생각이 들었다.

협업은 규칙에서 시작된다

이번 프로젝트를 진행하며 가장 크게 느낀 점은 좋은 협업은 좋은 규칙에서 시작된다는 것이다.
이전에는 컨벤션이나 PR 규칙 같은 것들이 개발 속도를 늦춘다고 생각했다. 하지만 실제 프로젝트를 진행해 보니 오히려 반대였다.

팀 내에서 사소한 것이라도 기준을 정해두면 불필요한 논쟁과 커뮤니케이션 비용을 줄일 수 있었다.
테스트 범위를 미리 정의해 두면 어떤 테스트를 작성해야 하는지 고민하는 시간이 줄어들었고, PR 규칙이 있으면 코드 리뷰어가 변경 의도와 구현 방향을 훨씬 빠르게 이해할 수 있었다.

결국 리뷰 속도는 생산성과 직결된다.
프로젝트 초기에 규칙을 정하느라 시간이 더 걸릴 수는 있다. 하지만 장기적인 관점에서는 팀 내 분쟁을 줄이고, 같은 논의를 반복하는 비효율을 제거하는 훨씬 효과적인 방법이었다.

좋은 코드는 상대방을 위한 코드다
코드에 대한 생각도 많이 바뀌었다.
예전에는 내가 읽기 좋은 코드를 작성하는 데 집중했다면, 이제는 다른 사람이 읽기 좋은 코드를 작성하는 것이 더 중요하다고 생각한다.
협업 환경에서는 결국 다른 사람이 내 코드를 이해해야 하고, 이해하기 쉬운 코드는 빠른 리뷰로 이어진다.
빠른 리뷰는 곧 빠른 생산성이다.

이번 프로젝트를 통해 좋은 코드는 작성자를 위한 코드가 아니라 함께 일하는 사람들을 위한 코드라는 사실을 배울 수 있었다.

또한 라이브러리를 도입할 때는 단순히 사용법만 익히는 것으로는 부족하다는 점도 느꼈다.
시간이 허락한다면 내부 동작 원리까지 이해한 뒤 도입해야 하며, 지속적으로 업데이트되는 라이브러리의 변경 사항과 보안 이슈 역시 꾸준히 확인해야 한다.

그리고 의외로 인프라 영역이 정말 재미있었다.
Docker Compose를 활용해 서비스를 구성하고 배포 환경을 관리하는 과정은 쉽지 않았지만, 문제를 해결해 나가는 과정에서 새로운 흥미를 발견할 수 있었다.

덧붙이자면 NestJS는 정말 재미있었다.

좋은 커뮤니케이션은 팀을 바꾼다

이번 프로젝트에서는 갈등이 단 한 번도 발생하지 않았다.
돌이켜보면 그 이유는 팀원 모두가 서로를 존중하며 소통했기 때문이라고 생각한다.

개발 협업에서는 피드백을 주고받는 일이 매우 많다. 이때 상대방의 의견을 반박할 수는 있어도 상대방의 자존심을 건드려서는 안 된다는 것을 배웠다.
같은 내용이라도 어떻게 전달하느냐에 따라 팀 분위기는 크게 달라질 수 있었다.

또한 이번 프로젝트에서는 리더십에 대해서도 많은 것을 배울 수 있었다.
학교 프로젝트에서는 대부분 내가 팀장을 맡았기에 다른 사람의 리더십을 가까이에서 볼 기회가 거의 없었다.
하지만 이번 프로젝트의 팀장님은 회의 안건을 명확하게 준비했고, 논의가 다른 방향으로 새지 않도록 자연스럽게 이끌었다.
덕분에 불필요하게 길어지는 회의가 없었고, 팀원들의 체력과 집중력도 효율적으로 관리할 수 있었다.
과거 팀장으로 활동하며 겪었던 여러 문제들을 떠올려 보니, 일부는 팀원 때문이 아니라 나의 리더십 부족 때문이었을 수도 있다는 생각이 들었다.

이번 프로젝트는 개발뿐만 아니라 리더십을 배우는 시간이기도 했다.
그리고 의사결정을 할 때는 무효표를 던지지 않는 것도 중요하다는 것을 배웠다.
명확한 의견을 제시해야 팀이 더 나은 방향으로 나아갈 수 있고, 결과에 대한 책임도 함께 질 수 있다.

의사소통을 할 때는 반드시 무효표를 던지지 않고 자신의 의견을 명확하게 전달하는게 뒷탈 안 생기고 팀 발전에 기여한다고 느꼈다.

남는 것은 기록이다
프로젝트를 진행하며 느꼈던 감정, 배운 내용, 트러블슈팅 과정은 반드시 기록으로 남겨야 한다고 생각한다.
기록하지 않은 경험은 생각보다 빠르게 잊힌다.
반대로 기록은 당시의 고민과 배움을 미래의 나에게 다시 전달해 준다.
또한 다른 사람과 경험을 공유할 수 있는 자료가 되기도 한다.

이번 부스트캠프를 통해 여러 번 느낀 사실이지만, 결국 남는 것은 기록이다.

끝이 아닌 새로운 시작

가장 넓은 바다는 아직 항해되지 않았고 가장 먼 여행은 아직 끝나지 않았습니다.
이제 한 달의 시간이 남았지만 그 끝은 아직 아무도 가보지 못한 길입니다.
그 끝이 창대할지, 그 마지막이 미약할지 알 수는 없지만 아무도 가보지 못한 길을 걸어갑니다.
가보지 않은 길에 대한 두려움은 크지만 기대감은 발걸음을 재촉합니다.
오늘 걸어가는 이 길은 가고자 했던 길의 어디쯤 일까요?
- 권성욱 캐스터

수능을 한 달 앞둔 학생들을 위해 권성욱 캐스터님께서 남긴 이 멘트가 문득 떠오른다.

멤버십 합격 소식을 들었을 때 가장 먼저 든 감정은 기대보다 두려움이었다.
'내가 과연 이 과정을 해낼 수 있을까?'

하지만 결국 그 두려움보다 성장하고 싶다는 마음이 조금 더 컸기에 한 걸음을 내디뎠다.
그리고 지금 돌아보면 그 선택은 내 개발 인생에서 가장 잘한 선택 중 하나였다.

부스트캠프는 단순히 개발 기술을 배우는 과정이 아니었다.
개발자로서의 태도와 협업 방식, 학습 방법, 그리고 스스로를 돌아보는 법까지 배울 수 있었던 시간이었다.
돌이켜보면 오늘의 나는 멤버십을 시작하기 전의 나와는 많이 달라져 있다.

물론 내가 가고자 하는 길에서 보면 아직 작은 한 걸음에 불과할지도 모른다.
하지만 그 한 걸음을 내딛기 전과 후는 분명히 다르다.
앞으로 어떤 길이 펼쳐질지는 알 수 없다.

다만 지금까지 그래왔듯 배우고 기록하며 한 걸음씩 나아가고자 한다.
지금은 마스터님의 조언대로 잠시 쉬어가며 다음 방향을 고민해 볼 생각이다.
그리고 다시 새로운 길을 향해 걸어갈 것이다.

부스트캠프 웹·모바일 9기의 모든 캠퍼, 운영진, 멘토, 마스터님들의 앞날을 진심으로 응원한다.

[ 소감 ]

적고 보니 멤버십 과정은 제게 참 많은 감정을 안겨준 시간이었습니다.

기대와 두려움이 공존했고, 자신감과 좌절이 반복되기도 했습니다. 때로는 스스로의 부족함에 실망하기도 했고, 반대로 작은 성장에 뿌듯함을 느끼기도 했습니다. 지금 돌아보면 그 모든 감정이 저를 한 단계 더 성장시키기 위한 과정이었다고 생각합니다.

네이버 부스트캠프는 제 개발 인생에서 가장 큰 전환점 중 하나였습니다. 단순히 새로운 기술을 배우는 것에 그치지 않고, 개발자로서 어떤 태도를 가져야 하는지, 어떻게 협업해야 하는지, 그리고 어떻게 성장해야 하는지에 대해 깊이 고민할 수 있었습니다.

물론 이러한 변화는 부스트캠프라는 환경이 있었기에 가능했습니다. 하지만 그 안에서 끊임없이 고민하고, 부딪히고, 다시 일어나며 스스로를 변화시키기 위해 노력했던 시간들이 있었기에 더욱 의미 있게 남는 것 같습니다.

소중한 성장의 기회를 제공해 주신 네이버 커넥트재단, 운영진분들, 마스터님들께 진심으로 감사드립니다.
또한 짧게 스쳐 지나갔지만 함께 고민하고 성장했던 캠퍼분들, 값진 경험을 공유해 주신 특강 연사분들, 그리고 코드 리뷰와 상담을 통해 많은 가르침을 주셨던 멘토님들께도 진심으로 감사의 말씀을 전하고 싶습니다.

부스트캠프를 통해 개발 경험뿐만 아니라 오래도록 기억에 남을 소중한 인연들도 얻을 수 있었습니다. 기술적인 성장과 더불어 협업, 소통, 기록과 같은 소프트 스킬까지 함께 배울 수 있었던 뜻깊은 시간이었습니다.

마지막으로 부스트캠프는 성장하고자 하는 의지가 있는 분들께 추천드리고 싶습니다.

누구에게나 쉽고 편안한 과정은 아닙니다. 많은 시간과 노력을 투자해야 하고, 때로는 스스로를 의심할 만큼 힘든 순간도 찾아옵니다.
하지만 그 과정을 견뎌낼 의지가 있다면, 투자한 것보다 훨씬 더 많은 것을 얻어 갈 수 있는 활동이라고 생각합니다.

부스트캠프와 함께했던 모든 분들의 앞날을 진심으로 응원합니다.

그리고 저 역시 이 경험을 바탕으로 앞으로도 계속 배우고 성장하는 개발자가 되겠습니다.

감사합니다.

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 챌린지 수료 후기 - Web

Min:Dev — Wed, 17 Jun 2026 19:59:11 +0900

본 게시글은 "2024년 8월 14일에 작성된 게시글로, 이전 블로그 (Velog) 게시글에서 내용을 수정하여 작성된 게시글이다. 원본 게시글은 다음 링크를 통해 보러 갈 수 있다.

본 게시글은 네이버 부스트캠프 웹・모바일 9기 활동의 콘텐츠 암묵 서약에 따라 작성 되었으므로 구체적인 미션 내용에 대해서는 발설할 수 없다.

개발자로서의 성장 방향을 완전히 바꿔준 최고의 경험이었다.
예상하지 못한 고난도 미션을 통해 문제 해결력과 학습 습관을 기를 수 있었다.
정답을 알려주는 교육이 아닌 스스로 배우고 탐구하는 자기 주도 학습 환경이었다.
동료와의 협업, 페어 프로그래밍, 피어 피드백을 통해 커뮤니케이션 역량을 키울 수 있었다.
대학교가 개발의 기초를 다지는 과정이었다면, 부스트 캠프는 실제 개발자로 성장하는 방법을 배우는 과정이었다.

네이버 부스트 캠프 소개

- 네이버 부스트 캠프 소개 + 베이직 과정 리뷰

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 베이직 수료 후기 - Web

seok3765.tistory.com

챌린지 과정은 개발자가 실제로 사용하는 도구와 운영체제의 동작 원리를 직접 구현하며 CS 지식을 학습하는 과정이다.

단순히 기능을 구현하는 것에 그치지 않고, 요구사항을 스스로 분석하고 문제 해결에 필요한 개념과 원리를 깊이 학습한다.

또한 학습한 내용을 바탕으로 설계하고 구현하는 전 과정을 반복하며 문제 해결 습관을 형성하도록 돕는다.

활동 후기

첫 개발 커뮤니티 활동으로 네이버 부스트캠프 웹・모바일 9기를 선택한 것은 최고의 선택이었다.

네이버 부스트 캠프의 방식은 다음과 같다.

"누군가 가르쳐주지 않는다. 문제에 대한 정답도 없다. 강의도 제공 안해준다. 해결해야 할 수단은 내 자신과 동료 뿐이다."

누군가 가르쳐주지 않기 때문에 스스로 학습하는 방법을 찾게 된다.

문제에 정해진 정답이 없기 때문에 자신만의 해결 방식을 고민하게 되고, 이를 다른 캠퍼들과 공유하며 문제 해결의 시야를 넓힐 수 있다.

강의가 제공되지 않기 때문에 단순히 정답을 찾고 끝나는 것이 아닌, 스스로 탐구하며 학습 범위를 확장할 수 있다.

나 자신과 동료만이 문제 해결의 수단이기 때문에 자신의 생각과 해결 과정을 설명하는 능력을 기를 수 있으며 협업 방식 또한 자연스럽게 배울 수 있다.

부스트 캠프에서는 고난도 미션을 해결하기 위해 필요한 CS 지식을 스스로 찾아 학습하고, 이를 동료들과 공유한다.

또한 학습한 내용을 직접 구현하며 단순히 읽고 이해하는 수준을 넘어 실제 경험을 겪으며 형식지에 있는 기억을 암묵지로 전환하는 활동을 매일 수행한다.

중간 중간 진행되는 페어 프로그래밍을 통해서는 타인을 존중하며 소통하는 방법, 함께 성장하는 방법, 그리고 개발자로서 가져야 할 태도에 대해서도 배울 수 있다.

처음에는 이러한 방식이 낯설고 충격적으로 느껴졌다. 하지만 시간이 지날수록 내가 가장 추구하던 학습 방식이라는 생각이 들었다.

매일 수행해야 하는 환경은 갖추어지지만 '어떻게 해야 하는지' 에 대한 정답은 주어지지 않는다. 스스로 방향을 정하고 성장해 나가야 하는 구조였으며, 이는 내가 생각하던 이상적인 학습 환경과 정확히 일치했다.

일반적으로 부트캠프라고 하면 강의를 통해 지식을 전달하고 수강생을 성장시키는 형태를 떠올린다. 하지만 그런 방식은 이미 대학 강의를 통해 충분히 경험해 보았다.

반면 챌린지는 야생에 던져진 캠퍼들이 각자 필요하는 지식을 사냥해야 하는 활동이다.

학습이 먹잇감이라면 캠퍼들은 사냥꾼이다. 배가 고플 때마다 스스로 먹이를 찾아야 하듯, 필요한 지식을 직접 탐색하고 습득해야 한다.

내가 원하던 환경과 매우 닮아 있었지만, 한편으로는 이런 방식이 정말 효과가 있을지 의문이 들기도 했다.

"가르쳐 주지 않는 데 성장이 되나? 그냥 알고리즘 문제 푸는 거랑 다를 거 없는거 아니야?"

이러한 생각이 바뀌는 데는 단 2일이면 충분했다.

2일차에 본격적인 미션이 주어졌는데, 주어진 미션은 불친절 그 자체였다.

요구사항은 명확하지 않았고, 무엇을 해결해야 하는지조차 쉽게 파악되지 않았다. 처음에는 어디서부터 시작해야 할지 감조차 잡히지 않았다.

하지만 마스터님께서 하셨던 말씀을 떠올리며 스스로 요구사항을 분석하기 시작했다.

필요한 학습 주제를 정리하고 관련 개념을 찾아 공부한 뒤 설계와 구현을 진행하면서 한 가지를 깨달았다.

"이게 진짜 개발 공부구나"

학교에서 시험을 위해 내용을 암기하던 방식과는 완전히 달랐다.

내가 직접 궁금한 것을 찾아 학습하고, 문제를 해결하기 위해 필요한 지식을 확장해 나가는 과정 자체가 즐거웠다.

학습을 이어갈수록 자연스럽게 더 깊고 넓은 영역으로 관심이 확정되었고, 이전보다 훨씬 적극적으로 공부하는 자신을 발견할 수 있었다.

물론 학습 범위를 지나치게 넓게 잡아 모두 소화하지 못하는 경우도 있었다. 그럴 때는 우선 키워드만 정리해 두고, 나중에 다시 학습할 주제로 남겨두곤 했다.

학교 공부의 현타

부스트캠프를 경험하며 학교에서 배운 내용들을 다시 돌아보게 되었다.
학교에서 배운 지식이 의미 없었다는 것은 아니다. 다만 대부분이 기초적인 수준에 머물러 있었고, 나는 그 지식을 충분히 깊게 이해하지 못한 채 시험을 위한 학습에만 집중하고 있었다는 사실을 깨달았다.

개발 공부를 할 때도 마찬가지였다. 문제를 해결하기 위해 블로그의 코드를 참고하는 데 급급했고, 그 이면의 원리와 동작 과정까지 깊게 이해하려는 노력은 부족했다. 부스트캠프를 통해 이러한 학습 태도를 되돌아보며 많은 반성을 하게 되었다.

건축공학과를 떠나 전공 변경을 결심했을 당시에는 컴퓨터와 관련된 모든 원리를 이해하는 개발자가 되고 싶다는 목표가 있었다. 하지만 시간이 지나면서 그 열정은 점차 희미해졌고, 어느 순간부터는 가능한 한 빨리 백엔드 개발자로 취업하는 것이 가장 중요한 목표가 되어 있었다.

만약 이러한 생각을 계속 유지했다면, 지금보다 더 깊이 성장하기보다는 현재 수준에 만족하는 개발자가 되었을지도 모른다.

부스트캠프의 미션 중에는 분명 학교에서 한 번쯤 배웠던 내용들도 있었다. 그러나 깊이 있게 이해하지 못했던 탓에 대부분 처음부터 다시 학습해야 했다.
그 과정에서 내가 정확히 알고 있는 것과, 알고 있다고 착각했던 것을 명확하게 구분할 수 있게 되었다.
특히 내가 알고 있다고 생각했던 CS 지식들이 실제로는 단편적인 이해에 머물러 있다는 사실을 깨달았을 때 큰 충격을 받았다. 그동안의 노력이 모두 헛된 것처럼 느껴져 적지 않은 상실감을 겪기도 했다.

하지만 지금 돌아보면 그 깨달음 자체가 성장의 시작이었다.
부스트캠프에서 수행한 수많은 미션 덕분에 부족했던 CS 기본기를 다시 다질 수 있었고, 무엇보다 스스로 학습하고 탐구하는 나만의 방법을 찾을 수 있었다.
돌이켜보면 내가 얻은 가장 큰 성과는 지식 자체보다도 '어떻게 학습해야 하는가'를 배운 것이었다.

이걸 구현하라고요...?

특정 알고리즘을 활용해야만 해결할 수 있는 미션은 거의 없었다. 물론 더 나은 성능을 위해 적절한 알고리즘을 적용할 수는 있었지만, 매일 주어지는 미션의 성격을 고려하면 특정 알고리즘을 활용한 최적화 자체가 핵심 목표는 아니라고 느꼈다.

대부분의 미션은 흔히 말하는 '구현 중심 문제'에 가까웠다. 개발자들이 실제로 사용하는 도구나 운영체제의 동작 원리를 직접 구현하는 형태였으며, 처음 미션을 접했을 때는 "이걸 직접 구현한다고요?"라는 말이 절로 나올 정도였다.

하지만 바로 그 점이 가장 큰 매력이었다. 평소에는 당연하게 사용하던 시스템과 도구들이 어떤 원리로 동작하는지 깊이 이해할 수 있었고, 직접 구현하는 과정에서 그 원리가 더욱 선명하게 다가왔다.

언젠가는 기술의 내부 동작 원리를 분석하고 직접 구현해 보는 시간이 필요하다고 생각해 왔는데, 부스트캠프는 그런 경험을 할 수 있는 최적의 환경이었다.

당시 코딩 테스트를 준비하면서는 특정 알고리즘을 활용해 문제를 해결하는 경험을 많이 했다. 물론 적절한 알고리즘을 선택하는 능력은 중요하다. 다만 당시 내가 경험한 많은 문제들은 문제를 분석하고 해결 방식을 설계하는 과정보다 이미 알고 있는 알고리즘을 구현하는 능력에 더 초점이 맞춰져 있다고 느꼈다.

반면 부스트캠프의 미션은 정해진 해법을 적용하는 것이 아니라 문제를 분석하고, 적절한 해결 방식을 스스로 찾아가는 과정에 집중되어 있었다. 그래서 더욱 만족스럽게 느껴졌다.

흥미로웠던 점은 배경지식을 알고 있다고 해서 반드시 미션을 쉽게 해결할 수 있는 것은 아니라는 점이었다. 기존 개념을 기반으로 하되 요구사항을 조금씩 변형해 출제했기 때문에, 익숙한 지식에만 의존하면 오히려 해결하지 못하는 경우도 있었다.

실제로 몇몇 미션은 설계를 세 번 이상 갈아엎기도 했다. 처음에는 비효율적으로 느껴졌지만, 그 과정에서 내가 알고 있다고 생각했던 지식의 빈틈을 발견할 수 있었다.

결국 미션을 해결하는 데 활용한 기존 지식은 일부에 불과했고, 대부분은 새롭게 학습하며 채워 나가야 했다. 덕분에 애매하게 이해하고 있던 내용들을 명확하게 정리할 수 있었고, 단순히 아는 수준을 넘어 제대로 이해하는 경험을 할 수 있었다.

직접 구현해 보기 전까지는 미처 알지 못했다. 평소 당연하게 사용하던 시스템과 도구들이 얼마나 많은 고민과 설계, 기술적 난관을 거쳐 만들어졌는지를 깨닫게 되었다.

그 과정에서 우리가 매일 사용하는 시스템과 도구를 만든 개발자들에 대한 존경심이 더욱 커졌다. 복잡한 문제를 해결하고 이를 사용하기 쉬운 형태로 제공해 준 개발자들에게 진심으로 감사한 마음이 들었다.

성장 후기

당시의 나는 학교에서 과탑을 했다는 이유만으로 CS 기본기는 충분히 갖추고 있다고 생각했다.

하지만 그것은 큰 착각이었다.

매일 새로운 미션이 주어질 때마다 부족한 부분이 드러났고, 차근차근 문제를 해결해 나가는 다른 캠퍼들을 보며 내가 생각했던 것만큼 탄탄한 기반을 갖추고 있지 않다는 사실을 깨달았다.

머릿속에는 항상 "분명 학교에서 배웠던 내용인데", "한 번쯤 사용해 본 기술인데"라는 생각이 맴돌았다. 그러나 정작 미션을 해결하는 데 필요한 핵심 개념과 원리는 제대로 기억나지 않았다. 결국 거의 모든 내용을 처음부터 다시 찾아보고 학습하는 과정을 반복해야 했다.

그 시기에는 내가 알고 있다고 생각했던 지식들이 실제로는 피상적인 이해에 머물러 있었다는 사실을 절실하게 느꼈다.

더구나 JavaScript 경험도 거의 없었다. 당시의 나는 JavaScript를 단순히 브라우저에서 동작하는 언어 정도로만 이해하고 있었고, Node.js 역시 브라우저 밖에서 JavaScript를 실행할 수 있게 해주는 런타임 환경 정도로만 알고 있었다.

지금 돌아보면 웹 개발자로서의 기반도, CS 지식에 대한 이해도 모두 부족한 상태였다.

부스트캠프는 그런 나의 현실을 직시하게 만든 과정이었다.

첫 현타 (1주차)

1주 차의 나는 한없이 작아져 있었다.

그동안 다양한 프로그래밍 언어를 사용해 본 경험은 있었지만, 웹 개발 경험은 Python 기반의 FastAPI를 간단히 사용해 본 것이 전부였다.

웹에 대한 지식 역시 정보처리기사 수준에 머물러 있었고, 지금 돌아보면 사실상 제대로 알고 있는 것이 거의 없었다.

부스트캠프를 시작한 뒤 내가 마주한 현실은 생각보다 훨씬 냉정했다.

알고 있다고 생각했던 CS 지식 대부분이 애매한 수준에 머물러 있었다.
JavaScript조차 제대로 다루지 못하는 웹 개발자 지망생이었다.
나보다 더 깊은 CS 이해도를 가진 비전공자 캠퍼들도 많았다.
어려운 미션을 제한 시간 안에 해결하지 못했고, 대부분 밤늦게까지 붙잡고 있어야 했다.

그럴 때마다 이런 생각이 들었다.

"이게 정말 과탑의 실력일까?"

캠퍼들과 해결 과정을 공유할 때마다 부끄러웠고, 때로는 쥐구멍에라도 숨고 싶었다. 심지어 중간에 포기하고 싶다는 생각이 들 정도로 자신감이 바닥을 쳤다.

첫 주는 말 그대로 무너지는 시간이었다.

점심시간에도 식사가 잘 넘어가지 않았고, 미션에 집중하다 저녁 시간을 놓치는 경우도 있었다. 다만 어떤 상황에서도 건강만큼은 지키자는 목표가 있었기에 식사는 거르지 않았다. 솔직히 말하면 맛있게 먹었다기보다 억지로 챙겨 먹었다는 표현이 더 맞을 것이다.

그 시기에 큰 힘이 되어 준 것은 운영진과 수료생들의 조언이었다.

"구현이 가장 중요한 것은 아니다. 부스트캠프 챌린지 미션은 현업 개발자에게 주어져도 제한 시간 안에 해결하지 못하는 경우가 있다. 중요한 것은 학습이다."

그 말을 듣고 스스로에게 다시 질문했다.

"나는 왜 챌린지에 들어왔는가?"

곰곰이 생각해 보니 내가 이 과정에 참여한 이유는 완성된 결과물을 만드는 것이 아니라 성장하기 위해서였다.

그 이후부터는 구현 여부에만 집착하기보다, 미션을 통해 새로운 CS 지식을 배우고 이해하는 데 더 집중하기 시작했다. 구현을 완벽하게 끝내지 못하더라도 학습한 내용이 있다면 충분히 의미 있는 하루라고 생각하게 되었다.

또한 동료들과 현재 상황을 공유하면서 위안을 얻을 수 있었다. 겉으로는 모두 잘해 보였지만, 이야기를 나눠 보니 대부분 비슷한 고민과 어려움을 겪고 있었다.

그때 깨달았다.

비교는 성장을 돕지 못한다는 것을.

챌린지 기간은 고작 4주였다. 낙담하고 있을 시간조차 아깝다고 생각했다. 남은 시간 동안 다른 사람과 비교하기보다 내가 가져갈 수 있는 것을 최대한 많이 배우고 성장하자는 방향으로 마음을 바꾸었다.

그 순간부터 주변 캠퍼들과의 비교를 멈추고, 어제의 나와 비교하기 시작했다.

성장 과정

1주차

1주 차에는 미션에서 제공하는 핵심 키워드를 중심으로 학습 내용을 정리하는 데 집중했다.

당시에는 학습 범위를 넓히기보다 하나의 주제를 깊게 이해하는 것이 더 중요하다고 판단했다. 아직 미션 진행 방식에 익숙하지 않았기 때문에, 넓고 얕게 학습하는 것보다 깊고 정확하게 이해하는 것이 나에게 더 적합한 방법이었다.

2주차

2주 차부터는 깊이 있는 학습에 어느 정도 익숙해지면서 설계에 더 많은 시간을 투자하기 시작했다.

문제를 해결하는 과정에서 시간 복잡도를 고려하고, 중복 코드를 줄이기 위해 DRY 원칙을 적용하려고 노력했다.
또한 평소 관심이 많았던 SOLID 원칙과 디자인 패턴에 대해서도 추가로 학습하며 설계 역량을 키우고자 했다.

단순히 동작하는 코드를 작성하는 것을 넘어, 더 나은 구조를 고민하기 시작한 시기였다.

3주차

학습과 설계 과정에 익숙해지면서 학습 범위를 넓히는 데 도전했다.

하나의 키워드를 학습하면 거기서 끝나는 것이 아니라 관련 개념과 기술까지 연결 지어 생각하려고 노력했다.
하지만 연관된 주제를 찾아내는 것 역시 하나의 능력이었다. 특히 익숙하지 않은 분야에서는 무엇을 더 공부해야 하는지조차 파악하기 어려웠다.
결국 아는 만큼 보인다는 말을 실감하게 되었다.

다행히 여러 미션을 수행하면서 이전에 학습했던 내용과 연결되는 개념들을 자주 발견할 수 있었다. 덕분에 지식을 독립적으로 암기하는 것이 아니라 서로 연결된 형태로 이해하는 연습을 할 수 있었다.

4주차

마지막 주에는 학습, 설계, 구현 사이의 균형을 찾는 데 집중했다.

초반에는 학습에 너무 많은 시간을 투자한 나머지 구현을 충분히 하지 못하는 경우도 있었다. 반대로 구현에 집중하다 보면 학습과 설계가 부족해지는 경우도 있었다.

그래서 세 영역의 균형을 맞추기 위해 많은 고민을 했다.
어느 정도 균형을 찾을 수는 있었지만, 마감 시간인 오후 7시 이전에 구현까지 완성하여 제출하는 것은 여전히 쉽지 않았다.
미션의 난이도는 이전보다 훨씬 높아졌지만, 오히려 그만큼 몰입도가 높아져 시간이 가장 빠르게 지나간 한 주이기도 했다.

개구리를 해부하지 말고, 직접 만들어 보아라.

- ≪바이트≫ 니콜라스 네그로폰데 박사

이 문장은 마스터님께서 자주 하시던 말씀이다.
처음 들었을 때는 단순한 격언처럼 느껴졌지만, 챌린지 과정을 거치면서 그 의미를 조금씩 이해하게 되었다.

단순히 원리를 읽고 이해하는 것과 직접 구현해 보는 것은 전혀 다른 경험이었다. 구현 과정에서 예상하지 못한 문제를 마주하고, 시행착오를 반복하며 비로소 원리가 내 것이 되었다.

돌이켜 보면 대학 2학년 시절 C++을 공부하며 라이브러리, 자료구조, 알고리즘을 직접 구현해 보겠다고 다짐했던 때가 있었다.
하지만 시간이 지나면서 결과를 만드는 것에만 집중한 나머지, 원리를 탐구하려는 초심은 조금씩 잊혀지고 있었다.

부스트캠프는 그 초심을 다시 떠올리게 해 준 계기였다.
앞으로도 단순히 사용하는 개발자가 아니라, 원리를 이해하고 직접 만들어 볼 수 있는 개발자가 되기 위해 노력하고 싶다.

정리 습관

부스트캠프 챌린지에 입과하면서 세운 목표 중 하나는 학습 내용을 꾸준히 정리하는 습관을 만드는 것이었다.
돌이켜보면 이 목표는 어느 정도 달성한 것 같다. 미션을 수행하는 과정에서 학습한 내용과 고민했던 과정들을 꾸준히 기록하며 나만의 정리 체계를 만들어 갈 수 있었다.

위 이미지는 챌린지 기간 동안 정리했던 내용들의 일부이다.
다만 학습 내용 자체는 콘텐츠 유출 방지 정책에 따라 공개할 수 없다.

정리 방식은 8기 수료생의 사례를 참고해 상당 부분 벤치마킹했다. 이미 검증된 정리 방법을 따라 해 보니 학습 내용을 구조화하고 복습하는 데 큰 도움이 되었다.
특히 이전까지는 노션을 체계적으로 사용해 본 경험이 거의 없어서 어떤 기준으로 정리해야 할지 고민이 많았다. 마침 수료생과의 밋업이 진행되었고, 그 과정에서 많은 조언을 얻을 수 있었다.

덕분에 단순히 내용을 저장하는 수준을 넘어, 나중에 다시 찾아보며 학습을 이어갈 수 있는 형태로 정리하는 방법을 익힐 수 있었다.
챌린지가 끝난 지금도 다시 공부해 보고 싶은 주제와 재도전해 보고 싶은 미션들이 많이 남아 있다.
당분간은 심심할 일이 없을 것 같다.

챌린지에서의 5가지 목표

챌린지에 입과하면서 노션에 나만의 목표를 정리해 두었다.
단순히 개발 역량 향상만을 목표로 삼으면 무리하게 달릴 것 같아, 개발 외적인 부분까지 포함해 스스로를 관리할 수 있는 목표들을 함께 세웠다.

1. 읽기 쉬운 글을 작성하고, 내 생각과 방법론을 논리적으로 설명하는 능력 기르기

2. JavaScript에 몰입하기. 문법뿐만 아니라 동작 원리까지 이해하기

3. 평소 사용하던 프로그램과 시스템을 직접 구현해 보기

4. 라이브러리를 사용할 때 내부 동작 원리를 이해하고 직접 만들어 보기

5. 건강을 유지하며 챌린지 수료하기

1. 읽기 쉬운 글을 작성하고, 내 생각과 방법론을 논리적으로 설명하는 능력 기르기

부스트캠프 베이직 지원 당시 자기소개서를 작성할 때부터 글쓰기 실력이 부족하다는 것을 느끼고 있었다.

또한 다른 사람에게 내가 작성한 코드나 구현 과정을 설명할 때도 어려움을 많이 겪었다. 표현력과 어휘력이 부족하다고 느꼈고, 머릿속에 있는 생각을 논리적으로 전달하는 것이 쉽지 않았다.

항상 "어떻게 해야 내 생각을 더 명확하게 설명할 수 있을까?"라는 고민을 가지고 있었다.

챌린지 과정에서는 글을 작성할 기회가 정말 많았다. 학습한 내용을 정리하고, 설계 과정과 요구사항 분석 결과를 기록하며, 다른 캠퍼들에게 내 코드와 문제 해결 과정을 설명해야 하는 상황도 자주 있었다.

그 과정을 반복하면서 글쓰기 능력뿐만 아니라 논리적으로 설명하는 능력도 이전보다 많이 성장할 수 있었다.

2. JavaScript에 몰입하기

JavaScript를 제대로 이해해 보고 싶다는 마음에 《모던 자바스크립트 Deep Dive》를 구매했다.
아쉽게도 책이 늦게 도착해 챌린지 기간 동안 많은 분량을 읽지는 못했지만, JavaScript의 동작 원리를 학습하는 데 큰 도움이 될 것이라는 확신이 들었다.

부스트 캠프에서 만나 이 책을 추천해 주신 junyeokk 님께 감사드린다.

추가로 《Node.js 교과서》도 함께 구매했다. 챌린지가 끝난 이후에도 꾸준히 읽으며 JavaScript와 Node.js를 깊이 있게 학습할 계획이다.

3. 평소 사용하던 프로그램과 시스템을 직접 구현해 보기

이 목표는 챌린지 미션을 수행하면서 자연스럽게 달성할 수 있었다.

오히려 내가 생각했던 것보다 훨씬 난도가 높은 미션들이 주어져 당황할 정도였다.

평소에는 결과물만 사용하던 프로그램과 시스템의 동작 원리를 직접 구현해 보면서, 그동안 당연하게 사용했던 기능들이 얼마나 많은 고민과 설계 끝에 만들어졌는지 체감할 수 있었다.

4. 라이브러리를 사용할 때 내부 동작 원리를 이해하고 직접 만들어 보기

라이브러리를 단순히 사용하는 것에서 그치지 않고 내부 동작을 이해하는 개발자가 되고 싶었다.

물론 직접 만드는 것보다는 이미 만들어진 것을 분석하는 경우가 더 많았기에 "개구리를 만든다"기보다는 "개구리를 해부한다"에 가까웠다.
그럼에도 내부 구현을 들여다보는 과정은 많은 도움이 되었다.
readline을 시작으로 EventEmitter, Worker Threads, fs 등 평소 사용하던 모듈들의 내부 구조를 살펴보며 동작 원리를 이해하려고 노력했다.

이 과정은 JavaScript와 Node.js를 더욱 깊이 이해하는 데 큰 도움이 되었다.

5. 건강을 유지하며 챌린지 수료하기

그동안 프로젝트나 과제를 진행할 때마다 건강을 희생하는 경우가 많았다.
그래서 이번만큼은 건강을 지키면서 끝까지 완주하자는 목표를 세웠다.

매일 3km씩 러닝을 했고, 식사도 거르지 않고 삼시 세끼 챙겨 먹었다. 수면 시간 역시 최대한 확보하려고 노력했고, 영양제도 꾸준히 챙겨 먹었다.
물론 쉽지는 않았지만, 결과적으로 건강을 크게 해치지 않고 챌린지 과정을 마칠 수 있었다.

돌이켜보면 다섯 가지 목표 모두 완벽하게 달성했다고 말할 수는 없지만, 챌린지 기간 동안 꾸준히 의식하며 실천하려고 노력했다는 점에서 충분히 의미 있는 목표들이었다.

3차 테스트 후기

지금까지의 내용을 보면 상당히 성장한 것처럼 보이겠지만, 3차 테스트 결과는 솔직히 말해 만족스럽지 못했다.
정말 예상 이상으로 아쉬운 결과였다.

물론 3차 테스트가 멤버십 합격 여부를 전적으로 결정하는 것은 아니었기에 불안함보다는 아쉬움이 더 크게 남았다.

특히 꼭 구현해 보고 싶었던 미션이었기에 더욱 아쉬웠다. 언젠가 시간을 내어 혼자서라도 끝까지 해결해 보고 싶다.

이번에도 구현 중심의 문제가 출제되었지만, 단순히 기능을 구현하는 능력을 평가하는 시험은 아니었다.
오히려 챌린지 기간 동안 습관화했던 문제 해결 과정을 얼마나 체화했는지를 확인하는 시험에 가까웠다.

요구사항 분석, 학습, 설계, 구현.
챌린지 기간 동안 나는 이 네 가지 과정을 반복하며 문제를 해결하는 습관을 만들었다.

하지만 테스트를 치르고 나서 한 가지 부족한 점을 발견했다.
네 가지 과정을 수행할 수는 있었지만, 제한된 시간 안에서 모두 끝내는 연습은 충분히 하지 못했다는 점이다.
각 과정의 중요성은 이해하고 있었고, 어느 정도 균형도 맞출 수 있게 되었다. 그러나 실제 시험 환경에서는 모든 과정을 정해진 시간 안에 순차적으로 수행해야 한다.

결국 문제는 역량 자체보다 시간 관리에 있었다.
돌이켜보면 시험뿐만 아니라 실무 역시 마찬가지다.
아무리 좋은 설계와 구현 능력을 갖추고 있더라도, 정해진 일정 안에 결과물을 제공하지 못한다면 좋은 평가를 받기 어렵다.

예전에 IT 전문 대기업에 종사하는 사촌 형이 해 준 말이 있다.

"제한된 시간 안에 최대한의 품질을 만들어 내고, 출시 이후 지속적으로 개선하는 것이 중요하다. 개발자는 약속된 일정을 지키는 것도 중요한 역량이다."

당시에는 당연한 이야기라고 생각했지만, 이번 테스트를 통해 그 의미를 다시 한번 실감하게 되었다.

이번 경험을 통해 앞으로는 요구사항 분석, 학습, 설계, 구현이라는 네 가지 과정을 단순히 수행하는 것에 그치지 않고, 제한된 시간 안에서 효율적으로 완성하는 연습도 함께 해야겠다는 교훈을 얻었다.

결과는 아쉬웠지만, 부족한 부분을 발견했다는 점에서 충분히 의미 있는 경험이었다.

고생한 나 자신

운영진분들께서 자주 하시던 말씀이 있다.

'회고를 하면 너무 자신을 가혹하게 때리기만 한다. 떄로는 보상도 줘야한다. '

챌린지 기간 동안의 회고를 돌아보며 그 말이 더욱 와닿았다.

우리는 종종 부족했던 부분과 실패한 경험만 떠올리며 스스로를 몰아붙인다. 하지만 지금까지 해낸 것들을 돌아보고, 그 과정에서 노력한 자신을 인정하는 것 또한 중요하다고 생각한다.

이 글을 읽는 분들도 때로는 자신에게 조금 더 너그러워져 보는 것은 어떨까.
지금까지 버텨 온 자신을 칭찬하고, 수고했다고 말해 주는 것도 분명 의미 있는 일이다.

나 역시 운영진분들의 조언 덕분에 힘든 순간들을 잘 버틸 수 있었고, 이전보다 긍정적인 시선으로 스스로를 바라볼 수 있게 되었다. 이제는 사소한 성장이라도 인정하고 칭찬할 수 있는 사람이 된 것 같다.

챌린지에 입과하기 전 세웠던 다섯 가지 목표 중 가장 만족스러웠던 한 가지를 선택해 스스로에게 작은 보상을 주었다.

그동안 졸업 작품이나 학교 과제를 수행할 때면 건강을 희생하면서까지 결과물을 만들어 내는 경우가 많았다.

하지만 이번만큼은 달랐다.

매일 러닝을 하고, 식사를 거르지 않고, 수면 시간을 최대한 확보하며 나만의 루틴을 지키려고 노력했다.
그리고 무엇보다 건강을 크게 해치지 않고 챌린지 과정을 마무리할 수 있었다.
그래서 이번 보상은 결과물이 아니라 건강하게 완주한 나 자신에게 주는 선물이었다.

2024년 8월 13일, 챌린지 수료증이 발급되었다.

고작 4주라는 짧은 기간이었지만 수료증을 받는 순간 여러 감정이 한꺼번에 밀려왔다.

힘들었던 기억들이 떠올라 눈시울이 붉어지기도 했고, 앞으로 또 이런 소중한 기회를 만날 수 있을까 하는 아쉬움도 들었다.

베이직 과정에서는 수료증이 발급되지 않고 챌린지 과정부터 수료증이 주어진다고 들었는데, 그래서인지 더욱 뜻깊게 느껴졌다.

솔직히 말하면 베이직 과정 이후 진행된 2차 테스트에서 탈락할 것이라고 생각했다.
그런 내가 챌린지 과정을 끝까지 완주했다는 사실만으로도 충분히 보람찼다.
멤버십 과정에 진출하지 못하더라도 챌린지에서 얻은 경험은 결코 사라지지 않는다.

문제를 해결하는 방법, 학습하는 습관, 개발자로서의 태도, 그리고 함께 성장할 수 있는 소중한 인연들까지.
이 모든 것은 앞으로의 개발자 인생에서도 계속 남아 있을 자산이라고 생각한다.
그래서 결과와 상관없이 이번 챌린지는 내게 매우 의미 있는 경험이었다.

돌이켜보면 가장 잘 어울리는 문장은 이것인 것 같다.
"아쉬움은 있지만 후회는 없다."

마지막으로 네이버 부스트캠프 웹·모바일 9기 활동을 하며 직간접적으로 인연을 맺었던 모든 캠퍼분들께 진심으로 감사드립니다.

만약 혼자였다면 훨씬 외롭고 힘든 시간이 되었을 것 같습니다.
하지만 함께 고민하고, 함께 버티고, 함께 성장하는 동료들이 있었기에 끝까지 포기하지 않을 수 있었습니다.
특히 캠퍼분들이 공유해 주신 학습 자료와 경험들은 저에게 큰 도움이 되었고, 지금의 제가 성장할 수 있었던 중요한 원동력이 되었습니다.

함께 페어 프로그래밍을 진행했던 분들, 스터디를 함께했던 분들, 릴레이 프로젝트를 진행했던 분들 모두에게 감사드립니다.
부족한 저를 이끌어 주고, 격려해 주고, 함께 고민해 주신 덕분에 정말 많은 것을 배울 수 있었습니다.
기술적인 성장도 값졌지만, 그보다 더 값졌던 것은 타인과 함께 배우고 성장하는 즐거움을 알게 되었다는 점입니다.

네이버 부스트캠프 웹·모바일 9기에서 만난 모든 분들께 다시 한번 진심으로 감사드립니다.

[네이버 커넥트재단 부스트캠프 웹・모바일 9기] 날 것 그대로 작성하는 베이직 수료 후기 - Web

Min:Dev — Mon, 15 Jun 2026 00:57:18 +0900

2024년 4~5월 기준으로 작성해뒀던 임시 게시글이다.

본 게시글은 네이버 부스트캠프 웹・모바일 9기 활동의 콘텐츠 암묵 서약에 따라 작성 되었으므로 구체적인 미션 내용에 대해서는 발설할 수 없다.

네이버 부스트 캠프는 AI 시대의 지속 가능한 개발자를 양성하는 것을 목표로 하는 부트캠프이다.
베이직, 챌린지, 멤버십 과정으로 구성되어 있다.
베이직 과정은 JavaScript를 사용해야 한다는 점을 제외하면 일상 생활에 큰 부담이 없는 편이다.
베이직 과정은 기록의 중요성을 체감할 수 있는 과정이다.
챌린지 입과 시험은 베이직 과정을 충실히 수행했다면 크게 어렵지 않다.

네이버 부스트 캠프 소개

네이버 부스트 캠프는 네이버가 설립한 비영리 기관인 네이버 커넥트재단에서 운영하는 부트캠프이다.
주 목표는 AI 시대의 지속 가능한 개발자를 양성하는 것을 목표로 한다.

AI 시대에도 개발자에게 가장 중요한 역량은 "문제 해결력"이며, 적합한 문제 해결 방법을 찾기 위한 분석 능력, 기초 지식, 그리고 사용자가 체감하는 서비스 전반에 대한 이해를 중심으로 학습을 진행한다.

2016년 웹·모바일 과정을 시작했으며, 이후 2021년 AI Tech 과정을 개설하여 현재까지 지속적으로 운영되고 있는 부트캠프이다.

다른 부트캠프와 다르게 풀스택 과정으로 진행된다는 점이 특징이다.
웹 서비스는 프론트엔드와 백엔드가 유기적으로 협력해야 사용자에게 가치를 제공할 수 있다.

현업에서는 직무가 분리되는 경우가 많지만, 두 영역을 모두 이해해야 문제를 더욱 정확하고 효율적으로 해결할 수 있다는 철학 아래 프론트엔드와 백엔드로 나뉘지 않고 풀스택으로 교육을 진행한다.

또한 온라인으로 참여할 수 있어 지방에 거주하던 나에게는 매우 좋은 기회였다.

네이버 부스트 캠프 소개 웹: https://boostcamp.connect.or.kr/

부스트캠프

개발자의 지속 가능한 성장을 위한 학습 커뮤니티

boostcamp.connect.or.kr

베이직, 챌린지, 멤버쉽 과정의 기간은 기수마다 다를 수 있다. 하단 이미지는 2024년 (9기) 기준 활동 일정이다.

베이직 과정 소개

베이직 과정은 프로그래밍 언어를 활용해 문제 해결 능력을 기르는 단계이다. 웹 분야에서는 JavaScript를 사용한다.
JavaScript의 문법을 익히고 이를 활용해 구현 중심의 문제를 해결하면서 언어에 익숙해지고 컴퓨팅적 사고를 기르는 것이 주요 목표이다.

또한 문제를 해결하는 과정에서 시행 착오와 해결 과정을 꾸준히 기록하는 습관을 기르게 된다.

서류 준비

서류 준비는 일반 회사 지원하는 것과 비슷하게 준비하면 된다.

개인 정보 작성과 자기소개서 정도다.

1차 테스트 후기 (베이직 입과 시험)

베이직 과정에 입과하기 위해서는 1차 테스트를 통과해야 한다.

처음에는 입과 시험이라는 말에 부담을 느꼈지만, 실제로는 감독 시스템 없이 과제를 수행하듯 문제를 해결하는 방식이었다. 심리적 부담은 크지 않았다.

시험은 기본적인 CS 지식을 중심으로 구성되어 있었다. 학교에서 관련 내용을 꾸준히 학습해왔기에 큰 어려움 없이 응시할 수 있었다.

정확한 선발 기준은 알 수 없지만, 당시에 상당수의 지원자가 베이직 과정에 입과했다.

당시에는 베이직 입과 시험 이후 곧바로 챌린지 시험에 응시할 수 있는 대상자와, 베이직 과정을 반드시 이수해야 하는 대상자로 나뉘었던 것으로 기억한다.

나는 2차 테스트 응시 대상자로 선정되었지만, 부스트캠프의 학습 방식과 문화를 직접 경험해보고 싶어 베이직 과정 참여를 선택했다.

지금 돌이켜보면 이 선택은 꽤 만족스러웠다. 베이직 과정을 통해 부스트캠프의 학습 방식에 적응할 수 있었고, 이후 과정을 준비하는 데에도 도움이 되었다.

후기

활동 후기

베이직 과정은 평일 기준 약 10일 동안 진행된다.

과정 동안 Node.js 환경에서 JavaScript를 활용해 다양한 구현 문제를 해결해야 했다.

다행히 이전부터 백준과 프로그래머스 문제를 꾸준히 풀어왔기 때문에 문제 자체는 크게 어렵지 않았다.

입력과 출력 값이 확실했고, 요구사항들도 확실한 내용이 많았어서 문제 이해도 쉽게 할 수 있었다.

가장 어려웠던 것은 아침 일찍 일어나는 것과 처음 사용하는 JavaScript에 적응하는 일이었다.

다양한 프로그래밍 언어를 접해본 경험이 있었기에 기본적인 적응은 빠르게 할 수 있었다.

JavaScript만의 고유한 문법에는 익숙하지 않았지만, 운영진도 이를 고려한 듯 특정 문법을 반드시 알아야만 해결할 수 있는 문제는 출제하지 않았다.

당시에는 졸업 작품 공모전도 병행하고 있었지만, 공모전 준비에 영향을 줄 정도로 어려운 문제는 없었다.

대부분 오후 5시 이전에 문제를 해결할 수 있어서 일상 생활 및 프로젝트에는 큰 영향이 없었고, 오히려 빠르게 문제를 해결 했을 때에는 다른 방법으로도 해결하면서 문제나 코드에 스스로 갇히지 않고자 노력했다.

성장 후기

베이직 과정을 통해 가장 크게 느낀 것은 기록의 중요성이었다.

이전까지는 머릿 속에 기억하는 것만으로 충분하다고 생각했다. 하지만 매 주 금요일마다 멤버들과 활동 내용을 공유하거나 함께 문제를 해결해야 했고 정작 자세한 기록을 남겨두지 않아 문제 해결 과정을 제대로 설명하지 못하는 경우가 있었다.

반대로 꾸준히 기록을 남기고 나니 과정이 끝난 뒤에도 어떤 문제를 해결했고 어떤 고민을 했는지 생생하게 떠올릴 수 있었다.

이 경험을 통해 기록의 가치를 체감했고, 기록을 남길 수 있는 방법을 고민하게 되었다.

Notion과 블로그를 비교해본 결과, 다른 사람들과 소통하기에는 블로그가 더 적합하다고 판단하여 Velog를 개설했다.

기록의 가치는 단순히 학습 내용을 남기는 데서 끝나지 않았다.

회고를 자세히 작성하지 않았을 때는 내가 어떤 문제를 겪었는지, 그리고 그 과정에서 개발 외적으로 어떤 성장을 했는지 파악하기 어려웠다.

하지만 회고를 작성하면서 하루를 되돌아보는 습관이 생겼고, 문제의 원인과 당시의 감정을 정리할 수 있었다. 덕분에 스스로를 객관적으로 바라보게 되었고, 비슷한 상황을 더 잘 대처할 수 있는 계기가 되었다.

또 하나 인상 깊었던 점은 실수를 바라보는 문화였다.

이전에는 학교 과제 발표에서 실수가 발생하면 어떻게든 감추거나 포장하려고 했다. 하지만 네이버 부스트캠프에서는 오히려 자신이 겪은 시행착오를 적극적으로 공유하는 분위기였다.

비슷한 실수를 경험한 다른 캠퍼들의 해결 방법을 들을 수 있었고, 이를 통해 같은 실수를 반복하지 않는 방법을 자연스럽게 학습할 수 있었다. 실수는 숨겨야 할 것이 아니라 함께 공유하며 성장할 수 있는 자산이라는 점을 배울 수 있었다.

2차 테스트 후기 (챌린지 입과 시험)

베이직 과정에서 학습한 JavaScript와 컴퓨터적 사고를 바탕으로 챌린지 입과 시험에 응시했다.

2차 테스트는 감독 시스템이 존재했기 때문에 1차 테스트보다 훨씬 긴장됐다.

문제를 처음 봤을 때는 당황스러운 부분도 있었지만, 베이직 과정을 경험한 덕분에 어떤 유형의 문제인지 어느 정도 예상할 수 있었다.

실제로 베이직 과정에서 접했던 문제와 유사한 유형이 다수 출제되었다.

다만 구현 중심의 시험이었기 때문에 가장 큰 문제는 시간이었다.

시험 중에는 설계나 구현보다 문제를 정확하게 이해하고 입력 데이터를 처리하는 데 더 많은 시간을 사용했던 것 같다.

로직 자체는 복잡하지 않았다. 평소 코딩 테스트의 쉬운 문제를 무난하게 해결할 수 있는 수준이라면 충분히 도전해볼 만한 난이도였다.

Hello World!

Min:Dev — Sat, 13 Jun 2026 21:47:27 +0900

안녕하세요. 제 블로그를 방문해 주셔서 진심으로 감사드립니다!

쾌적하고 건전한 블로그 운영을 위해 아래 내용을 확인해 주시기 바랍니다.

댓글 이용 안내

광고성 및 홍보성 스팸 댓글은 삭제됩니다.
댓글 내 분쟁, 비방, 욕설 등으로 인해 다른 방문자에게 불편을 주는 경우 관련 댓글은 삭제됩니다.
정치적 갈등이나 특정 사상에 대한 선전·비방 등 불편함을 주는 댓글은 삭제됩니다.

게시글 관련 안내

이 블로그는 개발 학습 과정에서 얻은 지식과 경험을 정리하기 위해 운영하고 있습니다.

학습과 검증을 거쳐 작성하지만, 내용상 실수나 오타 또는 잘못된 정보가 포함될 수 있습니다.

오류를 발견하신 경우 댓글과 방명록 보다는 아래 이메일로 연락주시면 확인 후 신속하게 수정하겠습니다.

이메일: seok3765@naver.com

주제 요청 안내

원하시는 개발 주제나 다뤄주었으면 하는 내용이 있다면 방명록에 남겨주시기 바랍니다.

관련 내용을 학습하고 정리하여 가능한 범위 내에서 게시글로 작성해 보겠습니다.

앞으로도 방문해 주시는 모든 분들께 도움이 되는 블로그가 될 수 있도록 노력하겠습니다.

감사합니다.

[ETC] "Hello, Tistory!"

Min:Dev — Sat, 30 May 2026 02:07:10 +0900

개발 블로그를 운영하면서 처음에는 Velog에서 시작했다.

비록 45개의 게시글뿐이었지만, 마지막 게시글을 작성할 때쯤에는 억지로 시간을 내어 글을 쓰는 느낌이 강했다. 반면 지금은 블로그 글을 작성할 수 있는 여유가 생겼고, 임시 저장만 해두었던 글들도 하나씩 정리해보고 싶다는 생각이 들었다. 그래서 블로그 운영을 조금 더 적극적으로 해보고자 한다.

그러던 중 Velog에서 불편함을 많이 겪었기 때문에 자연스럽게 "Velog에서 계속 작성하는게 맞을까?" 라는 생각이 들었다.

사실 Velog를 사용하기 전에는 Tistory도 함께 고려했었다. 그래서 이번에는 내가 개발 활동을 하며 직접 느꼈던 경험들을 바탕으로 Velog와 Tistory를 비교해보게 되었다.

기존에 Tistory를 선택하지 않고 Velog를 선택했던 이유는 명확했다.

Tistory는 개발 전용 블로그 플랫폼아니다.
개발 정보를 소비하는 입장에서는 Velog보다 불편할 것 같다는 인식이 있었다. 반면 Velog는 개발자 중심 플랫폼이라는 느낌이 강했고, 다른 개발자들의 게시글에 쉽게 접근할 수 있다는 장점이 있었다. 또한 글에 관심을 받더라도 개발자들에게 직접적으로 노출될 가능성이 높다고 판단했다.

특히, Velog의 '추천', '최신' 카테고리를 들어가더라도 개발 게시글만 볼 수 있다는 것이 가장 큰 장점이었다.

하지만 Google에서 개발에 관련된 궁금한 사안을 검색하면 나오는 검색 결과는 대부분 Tistory의 블로그였다.
그리고 네이버 부스트 캠프에서 만난 캠퍼들의 대부분 메인 블로그는 Tistory 블로그 플랫폼을 사용했고, Velog는 그저 댓글을 다는 용도, 소통용으로만 사용하는 분들을 만났었다.

기존에 있던 팀 문화에서도 각자의 블로그에 학습 정리한 내용을 공유하는 문화가 있었는데, 나를 제외한 모든 팀원의 블로그 플랫폼이 Tistory였다.
빠르게 게시글을 업로드 할 수 있는 접근성
당시에는 네이버 부스트 캠프를 진행하고 있었고, 학습한 내용을 빠르게 기록해야 했다. 작은 내용이라도 임시 글 형태로 남겨두는 일이 많았기 때문에, 빠르게 작성할 수 있다는 점이 큰 장점으로 다가왔다.

특히 Markdown 기반으로 간편하게 작성할 수 있다는 점은 상당히 매력적이었다.

Velog는 개발 전용 블로그 플랫폼으로 게시글을 실시간으로 접근하기에 좋다는 것이 가장 큰 이유였다.

내가 느꼈던 Velog에서의 불편함은 다음과 같다.

간편함이 장점이자 독이었다.

가독성 문제
팀 내 기술 공유 문화가 있었기 때문에 게시글을 팀원들에게 공유하고 화면을 띄워 설명하는 일이 자주 있었다. 그런데 직접 글을 읽으며 설명하는 나조차도 화면 자체의 가독성이 불편하게 느껴졌다.

좌우 여백이 지나치게 넓다 보니 글이 중앙에 몰려있고, 시선을 빠르게 다음 줄로 이동해야 해서 읽는 과정이 다소 산만했다.

코드 블록 역시 아쉬웠다. 디자인을 변경할 수 없었고, 가로 공간이 좁아 코드가 자주 줄바꿈이 되었다. 특히 긴 코드의 경우 흐름을 따라가기 어려워 가독성이 많이 떨어졌다.
카테고리 분류 한계

Velog에는 '시리즈' 기능이 존재하지만, 내가 원하는 방식으로 카테고리 내부에 세부 카테고리를 구성하기에는 부족함이 있었다.

태그 시스템도 아쉬웠다. 홈 화면에서 게시글의 모든 태그가 노출되다 보니, 원하는 글을 찾기가 오히려 더 어려운 경우가 많았다.
디자인 커스터마이징 불가
Velog의 장점 중 하나는 플랫폼 자체가 통일된 디자인을 제공한다는 점이다. 하지만 시간이 지나면서 이 부분이 오히려 단점으로 느껴졌다.

디자인 수정이 거의 불가능하다 보니, 내가 원하는 형태로 블로그를 구성하거나 개성을 반영하기 어려웠다. 블로그는 '개인 공간'으로 본인의 개성을 나타낼 수 있어야 하는데 이런 점이 부족했다.

게시글에서도 글자의 색상 삽입, 구분선 디자인 변경 등에서 어려움이 많이 존재했었다.
부족한 통계 기능
Velog도 기본적인 통계 기능은 제공한다. 하지만 게시글별 전체 조회수와 일일 조회수 정도만 확인할 수 있는 수준이었다.

GA(Google Analytics)를 연동할 수 있었지만, 게시글마다 직접 스크립트를 포함시켜야줘야 하는 번거로움이 존재했고, 게시글 접근 경로 같은 것들은 확인하기 어려웠다.
광고 수익의 한계
블로그 운영의 주 목적은 기록과 학습 정리다. 하지만 글을 작성하면서 일정 수준의 수익까지 발생한다면 더 좋지 않을까 하는 생각도 있었다.

Tistory는 광고 삽입과 수익화 측면에서 비교적 자유로운 반면, Velog는 구조적으로 한계가 많다는 점도 플랫폼 이전을 고민하게 된 이유 중 하나였다.
익명 댓글 기능의 부재
Velog는 회원만 댓글을 작성할 수 있어 익명 댓글 기능이 제공되지 않는다.

물론 내 블로그에 댓글이 많이 달리는 편은 아니었다. 하지만 개발 블로그를 운영하면서 다양한 사람들과 자유롭게 의견을 주고 받고 싶었는데, 회원 가입이 필요한 구조는 소통의 진입 장벽으로 느껴졌다.

물론 Velog 역시 충분히 매력적인 블로그 서비스라고 생각한다.

빠르게 글을 작성하고 공유하기에 정말 좋은 플랫폼이다. 특히 개발자 중심 커뮤니티라는 점은 분명 큰 장점이다.

다만 나는 사용하면서 여러 불편함을 느꼈고, 그 불편함을 더 잘 해결해줄 수 있는 플랫폼이 Tistory라고 판단했다. 그래서 결국 블로그 플랫폼을 옮기기로 결정했다.

이제 남은 문제는 기존 게시글 45개를 어떻게 옮길지다.

하지만 이렇게 된 김에 예전에 작성했던 글들을 다시 하나씩 읽어보며 다듬고, 복습하는 시간으로 활용해보려고 한다.

결국 블로그 글은 단순히 "작성하는 행위" 자체보다, 다시 돌아보고 정리하는 과정에서 더 큰 의미가 생긴다고 생각한다.

그래서 천천히 하나씩 옮겨볼 생각이다. 힘내보자!