42 Seoul - 008_minishell | Paul’s Archives

💻 Minishell: 운영체제의 축소판, 텍스트와 프로세스 사이의 번역가를 자처하다

통곡의 벽. 수 많은 42서울의 과제들 과정에서도, 역대급으로 고민하고, 소통할 일이 많아지는 프로젝트. 쉽지 않았던 이 프로젝트는 지금도 두고두고 생각나는, 정말 쉽지 않은 ‘험한 것’ 이었다.

이전의 과제들이 개별적인 시스템 콜이나 동기화 메커니즘을 깊게 파고드는 경험이었다면, Minishell은 이 모든 것을 아우르는 하나의 작은 운영체제를 설계하고 구현하는 종합적인 과제이다.

셸(Shell)은 단순히 명령어를 실행하는 프로그램을 넘어, 커널(Kernel)이라는 시스템의 심장부와 사용자 사이를 연결하는 정교한 인터페이스이자 번역가이다. 사용자가 입력한 한 줄의 텍스트 문자열이 어떻게 생명력을 얻어 여러 프로세스의 협연으로 재탄생하는지, 그 모든 과정을 직접 지휘해야 하는, 시스템 프로그래머로서의 진정한 역량을 시험받는 프로젝트이다.

Minishell은 “어떻게 문자열을 해석하고(Parsing), 어떻게 프로세스를 생성하며(Process Management), 어떻게 그들 간의 데이터 흐름을 제어할 것인가(IPC & I/O Redirection)”라는 세 가지 거대한 질문에 대한 답을 찾아가는 여정이다. 그리고 거기에 한 스푼 더.

이 과제는 42서울에서의 본 과정에서의 최초 팀 과제이다.

📞 0단계: 협업 길 들이기

처음 수행한 협업의 시작은 정말로 ‘어색’ 했다.

처음 마지하는 git, 버전관리, git 전략과 같은 내용들은 생소한데, 심지어 ‘일’이 아니라 ‘배움’이란 차원에서 진행하는 프로젝트다보니 여럿의 생각이나, 주장이 이어졌고 이러한 것들 속에서 어떻게 프로세스를 만들어내는 지는 정말 어려운 일이었다. 그나마 2명이 한다는 점에서, 해당 프로젝트의 목표가 본격적인 협업이라기 보단, ‘협업 맛보기’ 라는 컨셉이라는 차원에서 본다면 그나마 괜찮았다고 본다.

우선, 상대를 파악했다. 상대의 표현, 상대가 바라는 바, 특히나 목표가 동일하다고 해도, 그 동일한 목표에 대해 이해하고 있는 것은 다른 경우도 많았다. 특히나 신경 쓴 것은 ‘표현’의 정교화다.

한쪽이 아무리 지식이 뛰어나도, 협업을 해서 효율을 내려면, 상대가 이해하는 말로 해줄 수 있어야 하고, 실제로 프로세스 과정에서 약속된 언어로 한다는 말은 정보의 공유 수준도 비슷해져야 한다는 것을 의미했다.

기술적인 전략으로 깃 브랜치 전략, PR 시 어떻게 할지… 등 처음 하는 것인 만큼, 팀원과 진행하는 과정에서 git 의 협업 관련 서적을 보면서, 가장 최선이 뭘까 고민했었다.

사실, 이 내용을 디테일하게 정리한다면 엄청난 일이 될 거다. 거의 한 프로젝트를 3개월간 수행했던걸 생각하면, 얼마나 많은 대화와 소통, 특히 거기서 서로 어떻게 하는 걸로 해야 효율적일지 논하던 시간들은 지금 생각하면 무척 값진 일이었지만 동시에 힘든 과정이기도 했다. 그나마 위안은 42서울의 학생들 상당 수가 개발자의 가능성, 성향, 그리고 무엇보다 열정과 재미를 느끼는 이들이었기에 그런 점들이 우리를 묶어주었던 것이다.

📜 1단계: 문자열 해석 (Parsing) - 무의미한 텍스트에서 의미 있는 구조로

본격적으로 기능 구현에 들어가면 셸의 첫 번째 임무는 명령어를 컴퓨터가 이해할 수 있는 구조적인 데이터로 변환하는 것이다.

예를 들어 ls -al | grep "main" > result.txt와 같이 약속된 명령어들의 나열이있다. 하지만 실제로 컴퓨터가 이 명령어를 알아듣나? 아니다. 실질 터미널에서 치는 내용을 컴퓨터는 알아듣지 못한다. 0, 1이 아니기 때문이다. 따라서 ‘이해시키는’ 작업이 필요하고 이는 작은 프로그래밍 언어의 컴파일러를 만드는 과정과 유사하며, 크게 두 단계로 나뉜다.

어휘 분석 (Lexical Analysis / Tokenization): 입력된 문자열을 ls, -al, |, grep, "main", >, result.txt 와 같이 의미를 가진 최소 단위인 토큰(Token)으로 분해한다. 이 과정에서 공백은 분리의 기준이 되며, 파이프(|)나 리다이렉션(>, <) 같은 특수 문자는 ‘연산자’ 토큰으로, 따옴표로 묶인 문자열은 하나의 단일 토큰으로 인식하는 등 정교한 규칙이 필요하다. 이러한 규칙들은 요구되는 조건들, 쉘의 기본 동작에대한 공식문서를 보고 전부 기술화하였다. 약속된 컨벤션의 예약된 단어나 도구들에 대해 리스트업을 한 뒤에는 우선순위나 어떤 걸 우선시 해야 하는지 가시화 하였다.
구문 분석 (Syntax Analysis / Parsing): 생성된 토큰의 배열을 바탕으로, 명령어의 문법적 구조를 파악하여 추상 구문 트리(Abstract Syntax Tree, AST)와 같은 자료구조를 생성한다. 예를 들어, A | B > C 라는 명령어는 ‘파이프’라는 최상위 노드를 가지고, 그 왼쪽 자식으로는 ‘A’라는 간단한 명령어(Simple Command) 노드가, 오른쪽 자식으로는 ‘리다이렉션’ 노드가 연결되는 형태가 된다. 이 트리를 통해 각 명령어의 관계와 실행 순서, 입출력 방향이 명확하게 정의된다. 이 과정에서 닫히지 않은 따옴표나 문법에 맞지 않는 특수문자 사용과 같은 구문 오류를 잡아내는 것도 파서의 중요한 역할이다. 특히나 히어독과 같은 것들을 위한 개별 로직이 언제 어떻게 실행 되는지와 같은 포인트들을 이해하는 것도 매우 중요헤지며, 이를 구조체로 담아내는 작업, 그리고 특히나 이런 데이터 단위로 탐색이 편리한 메소드를 구성하는 것은 개발 속도에도 지대한 영향을 주었다.

따옴표와 환경 변수 처리: 파싱 과정에서 셸의 미묘한 규칙들을 구현해야 한다. 작은따옴표(')**는 내부의 모든 문자를 해석 없이 문자 그대로 취급한다. **큰따옴표(")는 내부의 $ 문자를 환경 변수로 인식하여 그 값으로 치환(Expansion)해야 한다.$?와 같이 마지막으로 실행된 명령어의 종료 코드를 나타내는 특수한 환경 변수도 처리해야 한다.

🛠️ 2단계: 명령어 실행 (Execution) - 구조화된 명령에 생명을 불어넣다

구문 분석을 통해 만들어진 실행 계획(AST)을 이제 직접 실행되게 하면 된다. 실행기는 트리를 순회하며 각 노드의 타입에 따라 적절한 시스템 콜을 호출하는 역할을 하고, 이때 리눅스 OS 의 철학, 프로세스의 라이프 사이클을 이해하는 것이 정말 중요해진다.

프로세스 생성 (fork): ls, grep과 같은 외부 명령어를 실행하기 위해 fork() 시스템 콜로 현재 셸 프로세스와 똑같은 자식 프로세스를 생성한다. 이후 자식 프로세스는 execve() 시스템 콜을 통해 자기 자신을 새로운 프로그램(ls 등)으로 교체하여 실행한다. 부모 프로세스(셸)는 waitpid()를 통해 자식 프로세스가 종료되기를 기다렸다가, 종료와 함께 제어권을 다시 가져와 다음 명령을 받을 준비를 한다. 이때 특히나 에러핸들링을 잘해주는 것이 필요하고, 적절한 문구를 통해 명령이 왜 실패했는지를 이해하는게, 디버깅의 핵심이었다.
파이프 (|) - 프로세스 간 통신 (IPC): pipe() 시스템 콜은 두 개의 파일 디스크립터(읽기용, 쓰기용)를 생성하여 프로세스 간 통신 채널을 만단다. A |B 구문에서, 셸은 파이프를 생성한 후 두 개의 자식 프로세스를 만든다. 여기서 중요한 부분이 파일, FD 를 통해 어떻게 관리되는지를 이해하는 것이었다. 특히나, 열고 닫는 것이 굉장히 중요해지는데, 여러개의 프로세스가 동작할 때, 출력-입력의 열려있는 것들을 잘 닫아주는 로직이 아니게 되면 이전 프로세스가 출력하고 담았지만, 프로세스가 정상 종료가 안 된 것, 혹은 데이터가 더 들어올게 남았다는 식으로 되기 때문에 이 특징을 이해하지 않으면 주구장창 대기하는 상태가 된다는 것은… 끔찍한 경험이었다(…)
- 프로세스 A: 자신의 표준 출력(STDOUT, fd 1)을 파이프의 쓰기용 끝에 연결(dup2)하고, A 명령어를 실행한다. A의 모든 결과는 이제 화면이 아닌 파이프로 흘러 들어간다.
- 프로세스 B: 자신의 표준 입력(STDIN, fd 0)을 파이프의 읽기용 끝에 연결(dup2)하고, B 명령어를 실행한다. B는 이제 키보드가 아닌 파이프로부터 데이터를 입력받아 처리한다.
리다이렉션 (<, >, >>, <<) - 파일 디스크립터 제어: 리다이렉션은 프로세스의 표준 입출력 대상을 파일로 변경하는 기술이다. 이는 open()으로 파일을 열고, dup2()로 기존의 표준 입출력 파일 디스크립터(0, 1, 2)를 새로 열린 파일의 디스크립터로 복제하는 방식으로 구현된다. *>: 명령어의 결과를 파일에 덮어쓴다. *<: 파일의 내용을 명령어의 입력으로 사용한다. *>>: 명령어의 결과를 파일 끝에 추가한다. *<< (Here Document): 구분자(delimiter)가 나올 때까지 입력을 받아 임시 파일에 저장한 후, 해당 임시 파일을 표준 입력으로 리다이렉션하는 방식으로 구현된다.
내장 함수 (Built-ins): cd, export, unset, exit와 같이 셸 프로세스 자체의 상태(현재 작업 경로, 환경 변수 등)를 변경해야 하는 명령어들은 외부 프로그램으로 실행할 수 없다. 이러한 내장 함수들은 프로세스의 주인이 되는 메인 프로세스의 설정을 건드리거나, 상호작용하기 때문이다. 예를 들어 cd를 자식 프로세스에서 실행하면 자식의 경로만 바뀌고 셸 자신은 그대로이고, 이렇게 되면 그 뒤에 오는 명령이 비정상적으로 실행 및 종료 될 수 있다. 따라서 이는 fork 없이 셸이 직접 함수 호출을 통해 처리해야 한다. README.md에 명시된 echo, cd, pwd, export, unset, env, exit가 이에 해당되고, 이들은 독자적인 방식으로 OS 와 주 프로세스에 직접 영향을 주도록 만들어야 했다.

🚦 3단계: 시그널 처리 - 예기치 않은 상황에 대응하기

사용자는 언제든지 Ctrl+C(SIGINT)나 Ctrl+D(EOF)를 눌러 프로세스를 제어하려 할 수 있다.상호작용적인 셸은 이러한 시그널을 적절히 처리하여, 자식 프로세스가 실행 중일 때와 프롬프트에서 입력을 대기 중일 때 다르게 동작하도록 설계해야 한다. signal 또는 sigaction 함수를 통해 특정 시그널이 도착했을 때 수행할 동작을 정의하여, 프로그램의 안정성과 사용자 경험을 향상시켰다. *대기 중: Ctrl+C는 새 프롬프트를, Ctrl+D는 셸을 종료한다.

실행 중: Ctrl+C와 Ctrl+\는 실행 중인 자식 프로세스에게 전달되어야 한다.

✨ 성찰 및 배운 점

Minishell은 단순한 C 프로그래밍 과제가 아니었다. 운영체제가 어떻게 사용자 요청을 처리하고, 프로세스들을 조율하며, 데이터의 흐름을 관리하는지에 대한 이해도를 높일 수 있는 정말 좋은 과제였다고 생각한다. 뿐만 아니라 한 개인이 개발할 수 있는 한계가 있고, 결국 협업으로 만들어내는 종합 예술임을 처음으로 느낄 수 있던 과제다. 그 와중에 느낀 점들 몇가지를 정리해보면,

추상화의 위대함: |나 > 같은 간단한 기호 뒤에 fork, pipe, dup2, execve와 같은 복잡한 시스템 콜들의 오케스트라가 숨어있음을 깨달으며, 잘 설계된 추상화의 힘을 체감했다.
프로세스 관리의 정수: 부모와 자식 프로세스의 관계, 파일 디스크립터의 상속, 프로세스의 라이프사이클을 직접 관리하며 운영체제의 핵심 역할인 프로세스 관리를 피부로 이해하게 되었다.
설계의 중요성: 어휘 분석기, 구문 분석기, 실행기를 각각 독립된 모듈로 설계하고, 이들을 연결하는 명확한 자료구조(AST)를 정의하는 과정은, 복잡한 시스템을 구축하기 위해선 견고한 아키텍처 설계가 선행되어야 함을 가르쳐주었다.

정말 쉽지 않았다. 포기하고 싶다는 생각을 정말 많이 했고, 무엇보다 팀원과 함께 기운이 빠지는 정말 쉽지 않은 프로젝트였다. 그래도 역시 그런 걸까? 돌아보니 정말 재밌고, 치열했던것 같다. 🤣