42 Seoul - 001_get_next_line

📄 Get_Next_Line: ‘상태’를 기억한다는 것의 의미

만약 컴퓨터에게 기억이 없다면 어떻게 될까? 모든 연산은 그저 일회성으로 끝나고, 방금 전에 했던 작업을 다시 이어가는 것은 불가능할 것이다. libft가 C언어의 문법과 메모리 조작이라는 ‘행위’에 집중하는 과제였다면, get_next_line(이하 GNL)은 컴퓨터가 어떻게 ‘상태(state)’를 기억하고 연속적인 작업을 처리하는지에 대한 깊은 통찰을 요구하는, 완전히 새로운 차원의 도전이었다.

“파일에서 한 줄씩 읽어오라”는 명제는 단순해 보였다. 하지만 이내 깨달았다. 이것은 단순히 파일을 읽는 기술을 넘어, ‘시간’이라는 축 위에서 데이터의 흐름을 제어하고, 함수의 생명주기를 뛰어넘는 ‘기억’을 구현해야 하는 문제라는 것을. C언어의 저수준(low-level) 파일 입출력과 씨름하며, static이라는 키워드에 담긴 철학을 비로소 이해하게 된 여정이었다.

🧠 핵심 개념 정복하기 (Conquering Core Concepts)

GNL의 세계로 들어가기 위해선, 컴퓨터의 가장 기본적인 소통 방식을 먼저 이해해야 했다.

1. 파일 디스크립터(File Descriptor): 추상화의 첫걸음

우리가 키보드를 두드리고, 모니터를 보고, 파일을 읽는 모든 행위는 운영체제(OS)의 눈에는 그저 ‘데이터의 흐름’일 뿐이다. OS는 이 복잡한 장치들을 0(표준 입력), 1(표준 출력), 2(표준 에러)와 같은 정수 번호로 단순화하여 우리에게 제공한다. 이것이 바로 파일 디스크립터(FD)다. open() 함수를 통해 파일을 열면, OS는 새로운 번호표를 발급하며 “자, 이제 이 번호로 파일과 소통해”라고 말해주는 것과 같다. GNL은 이 번호표 하나에 의지해 거대한 파일의 내용을 한 줄씩 탐험하는 항해사와 같았다.

2. read()와 BUFFER_SIZE: 경계 위의 줄타기

GNL의 유일한 무기는 read 함수였다. 이 함수는 BUFFER_SIZE라는 정해진 크기만큼만 데이터를 가져온다. 여기서 GNL의 본질적인 딜레마가 시작된다. 우리가 읽으려는 ‘한 줄’이라는 개념은 지극히 인간적인 단위이지만, 컴퓨터는 그저 바이트(byte)의 흐름으로 세상을 본다.

• BUFFER_SIZE가 한 줄보다 작으면, 개행 문자(\n)를 만날 때까지 여러 번 read를 호출해야 한다.
• BUFFER_SIZE가 한 줄보다 크면, 한 줄을 읽고도 데이터가 버퍼에 남는다.

바로 이 ‘남아버린 데이터’를 어떻게 처리할 것인가? 이번 호출에서 남은 데이터를 다음 호출을 위해 어딘가에 고이 보관해두어야만 했다. 함수가 호출되고 끝나는 찰나의 순간을 넘어, 다음을 기약하는 ‘기억’이 필요했다.

3. 마법의 키워드, static: 함수에 영혼을 불어넣다

이 문제의 해답은 바로 static 변수에 있다. ✨

char *get_next_line(int fd)
{
    static char *backup;
    // ...
}

함수가 끝나면 사라지는 일반 지역 변수와 달리, static 변수는 프로그램이 시작될 때 단 한 번 메모리에 할당되어 프로그램이 끝날 때까지 자신의 값을 유지한다. 즉, GNL 함수가 수십, 수백 번 호출되어도 backup 변수는 마치 어제의 일을 기억하는 사람처럼, 이전에 읽고 남겨둔 데이터를 간직하고 있는 것이다.

이 static 변수 backup에 read로 읽어온 내용을 계속 이어 붙이고(strjoin), 개행 문자를 발견하면 그 앞부분까지를 세상에 내보내고(return), backup에는 개행 문자 뒤의 나머지 약속을 담아두는 것. 이 로직을 깨달았을 때, 나는 비로소 함수에서 아주 기본적인 ‘상태’라는 걸 보관하는 방법을 배울 수 있었다.

🛠️ 나의 GNL 구현기 (My GNL Implementation Journey)

그러나 알다시피 머리로 이해하는 것과 손으로 구현하는 것은 천지 차이다.

1. 읽고, 쌓고, 또 쌓고: read 함수가 더 이상 읽을 것이 없을 때까지, 또는 개행을 만날 때까지 반복문을 돌았다. backup이라는 공간에 BUFFER_SIZE만큼의 벽돌을 계속해서 쌓아 올리는 과정이었다. 이 과정에서 ft_strjoin은 나의 든든한 시멘트가 되어주었다.
2. 자르고, 내보내고: 마침내 개행이라는 이정표를 만나면, 그곳까지의 길을 잘라내어 결과로 반환한다.
3. 기억하고, 준비하고: 그리고 가장 중요했던 단계. backup 변수에는 잘라내고 남은 나머지 부분을 담아, 다음 호출의 시작점이 될 수 있도록 준비시켰다. 이 과정에서 수없이 터져 나오는 메모리 누수(leak)를 막기 위해 free와 사투를 벌였다. 정말 이 부분에서 생길 수 있는 에러, 특히 반복되는데 내가 놓치지 않으려면 구조적으로 생각해야 했고, C언어가 왜 그토록 정교한 메모리 관리를 요구하는지 온몸으로 깨달았다. (정말이지, 세그폴 화면은 다시 보고 싶지 않다… 😇)

✨ 보너스: 여러 개의 기억을 동시에 (Bonus: Multiple States at Once!)

필수 파트의 GNL은 static 변수 하나에 의존하기에, 오직 하나의 기억(파일)만 유지할 수 있었다. 하지만 보너스 파트는 여러 파일을 동시에 열고, 각 파일의 읽기 상태를 독립적으로 기억하라는 더 높은 차원의 과제를 제시했다.

하나의 뇌로는 여러 사람의 기억을 동시에 관리할 수 없듯, static 변수 하나로는 부족했다. 해결책은 ‘기억의 목록’을 만드는 것이다.

파일 디스크립터(FD)를 열쇠 삼아, 각 열쇠에 맞는 backup 데이터를 저장하는 배열(static char *backup[OPEN_MAX])이나 연결 리스트를 활용했다.

GNL이 특정 fd와 함께 호출되면, 우리는 기억의 목록에서 해당 fd에 맞는 기억을 꺼내 작업을 이어간다는 것을 구조화 하는 것이 관건이었다.

🤔 성찰 및 배운 점 (Reflection & Lessons Learned)

GNL은 나에게 ‘보이지 않는 것을 다루는 법’을 가르쳐줬다.

• 상태 관리의 본질: 파일 입출력을 넘어, ‘상태’라는 추상적인 개념을 어떻게 코드 레벨에서 구체화하고 유지하는지 깊이 이해하게 되었다. 이는 나중에 웹 서버가 수많은 클라이언트의 연결 상태를 기억하거나, UI 프레임워크가 컴포넌트의 이전 상태를 기억하는 등 모든 프로그래밍의 근간이 되는 원리였다. 이제는 정말 다양한 도구나, 개념이 있고, 사실 조금 더 곰곰히 생각해보면 ‘static’이 내부에 당연히 녹아 있겠지만, 이제는 다소 구식(….) 방법임을 새삼 느끼긴한다. 그러나 결국 최적화가 필요하고, 데이터를 더 고속으로, 더 빠르게 처리해야한다면 어쩌면 다시 끄집어낼 기회가 오지 않을까, 그렇게 생각해본다.
• static의 철학: static은 단순한 C언어의 키워드가 아니었다. 함수의 생명주기를 초월하여 데이터를 보존하는, C언어가 제공하는 가장 원시적이면서도 강력한 상태 관리 도구임을 깨달았다. 그때는 얼마나 빠른가? 이걸 기반으로 꽤나 호들갑을 떨었던(…) 기억이 난다.
• 디버깅과의 처절한 사투: 끝없이 터지는 메모리 누수와 세그폴은 나를 좌절시켰지만, 동시에 메모리의 할당과 해제의 흐름을 집요하게 추적하는 인내심과 문제 해결 능력을 길러주었다. 그게 핵심이기도 했다. 특히 보너스를 하게 되면, FD 의 관리가 병렬로 진행되는데, 조건이 추가될 수록 당연히 기존 내용을 두고, 다른 내용을 찾아온다는 작업이 이제는 머릿속에 그려지기에 어디서 뭘 잡아야 하는가? 를 기억하지만, 그땐 정말 힘들었다.

get_next_line은 한 줄의 문장을 읽어낸다라고 쉽게 이야긴 했지만, 핵심은 상태를 저장하고, 어떤 비즈니스 로직을 거치고, 또 거기서 여러 파일을 다룬다면 어떤 과정으로 작업을 왔다 갔다 할 수 있는지, 그 논리적 로직이 뭔지를 실질적으로 배우는 기회였다고 생각한다.