42 Seoul - 000_libft

🚀 Libft: C 언어와의 첫 만남, 나만의 라이브러리 만들기

개발에 답은 없다. 왜냐면 개발이란 그렇기 때문이다.

도구들은 다양하고, 그 도구들의 어떤 연결이 얼마나 복잡하고, 최적화되며, 그걸 통해 동일한 결과라도 놀라운 결론에 도달하는가. 특히나 단 한 사람의 이야기가 아니라, 여러 사람들의 협업이 되면 그 때부터 개발은 단순히 ‘만든다’의 영역에서 ‘예술’까지도 넘볼 수 있는 꽤나 그럴 싸한 작품이 된다.

42 프랑스를 거쳐, 42 서울은 그런 철학을 인정한다.

그렇기에 답은 없고, 그저 모두에게 제공되는 것은 단 하나의 명제였다. 문제는 줄게, 답은 너가 찾아봐. 그리고 동료들과 그 과정을 치밀하게, 은밀하게, 그리고 치열하게 고민해봐.

다시 후기를 작성하게 된 지금 이순간에도 42서울의 그 가치는, 그 과정은 개발이 왜 매력적이고, 이제는 왜 ‘나에게 맞는 일이다’ 라고 생각하게 되었는가를 다시 한 번 느끼게 만든다.

그렇기에 ft(forty two)라는 키워드는 유난히 익숙하지만, 동시에 ‘뭔지 모를 느낌’을 주는 키워드이며, 그런 키워드와 함께 시작하는 libft라는 과제는 42 서울에서의 내 첫 번째 프로젝트이자, C언어의 깊은 물에 처음으로 발을 담갔던 순간으로 기억한다.

오픈 소스라는 키워드는 만드는 행위의 평등함을 추구했고, 그 와중에 생겨난 리눅스라는 시스템과 그 철학은 커져가면서 현대 컴퓨팅의 정수이다. 그리고 그런 리눅스의 표준, 기반들은 처음에 보기엔 생소했다. 왜 굳이 이런걸? 이라고 그때 당시에는 생각했지만, 지금 생각해보면 결국 지금, 양자 컴퓨팅에, AI 등 온갖 키워드의 시발점이 단어 하나를 메모리에 올리는 작업에서 비롯되었음을 깨달았다는 점에서 개발자들에게 컴퓨터의 이해는 어디서 오는가? 한다면 바로 여기서부터라고 자신있게 말할 수 있을 것이다.

C 표준 라이브러리 함수들을 직접 내 손으로 구현해야 했던 이 과제는, 마치 C언어의 심장부를 해부하는 것과 같은 경험이었다. 수많은 밤을 man 페이지와 함께 지새우며, 포인터와 메모리 주소와 씨름, printf 를 로직의 위치 위치마다 찍어보던 그 과정… 지금 생각하면 얼마나 고통스러웠는지 모른다.

이 프로젝트는 단순히 함수를 베끼는 것이 아니라, 그 작동 원리, 컴퓨터의 소통 방식을 근본부터 이해하고, 나만의 코드로 재창조하는 과정이었다.

📚 주요 학습 내용 (Key Learnings)

libft 프로젝트는 크게 세 부분으로 나눌 수 있다.

표준 라이브러리 함수를 구현하는 Part 1,

조금 더 복잡하고 유용한 함수들을 만드는 Part 2,

그리고 연결 리스트(Linked List)를 다루는 Bonus 파트

1. 표준 라이브러리 함수 재구현 (Re-implementing Standard Library Functions)

여기서는 C 언어를 기반으로 리눅스 시스템이 사용하는 언어의 특징, 그리고 그 언어를 통해 다시 사람의 명령을 어떻게 표현하면 될지, OS 가 어떻게 이해하는지를 가장 기본적으로 이해하는 방법을 배웠다.

1. 메모리 다루기 (<string.h> 등): memset, memcpy, memmove 같은 함수들을 만들면서 포인터와 메모리에 대한 이해가 깊어졌다. 특히 memcpy와 memmove의 차이점, C 언어의 메모리 사용 방식에 따라, 메모리 오버랩(overlap) 문제가 발견하고, 어떻게 해결하는지를 배웠다. “아니, 그냥 복사하면 되는 거 아냐?” 싶은데, 주소 값이 겹칠 때의 그 미묘한 차이를 이해하고, C 언어라는 걸 기반으로 무언가를 만든다고 하는 것은, 언어의 정해진 특성들을 기반으로 어떤 한계가 생기는지 처음 이해했던 순간이었다.
2. 문자열 갖고 놀기 (<string.h> 등): strlen, strlcpy, strlcat, strchr, strncmp 등등… C언어에서 문자열이 사실상 char 배열이며, 자료 타입들은 결국 이러한 데이터열의 연속임을 배웠다. 특히 문자열의 편집 과정에서, 데이터의 ‘단위’를 위한 NULL 문자의 중요성과 버퍼 오버플로우(buffer overflow)를 방지하기 위한 strlcpy의 소중함 등을 느낄 수 있는 시간이었다.
3. 문자 판별과 변환 (<ctype.h> 등): isalpha, isdigit, isalnum 같은 함수들은 비교적 간단했지만, 컴퓨터가 사람의 언어를 표현하는 아스키 문자 등에 대해 완벽한 이해가 필요 했다.
4. 문자열을 숫자로 (<stdlib.h> 등): 가장 난이도 있는 영역이었는데, atoi를 구현하면서 온갖 예외 케이스(공백, 부호, 숫자 아닌 문자 등)가 왜 생기는지, 그리고 특히나 동료 학습을 통해 이런 예외 처리가 얼마나 중요한지를(…) 뼈저리게 깨달았던 기억이난다.

2. 나만의 유틸리티 함수 구현 (Implementing Additional Utility Functions)

Part 1이 ‘모방’의 단계였다면, Part 2는 ‘창조’의 단계였다. 주어진 명세에 따라 Part 1에서 만든 아주 기초 단위의, 메모리 상의 데이터 하나를 수정하거나, 데이터를 다른 데이터 형식으로 바꾸는 등의 기술을 배웠으니, 이것들을 래핑(wrapping) 해보는 것을 요구했다.

• ft_split: 이 녀석이 아마 최종 보스 였을 것이다. 😂 문자열을 특정 구분자(delimiter) 기준으로 쪼개서 2차원 배열에 담아 반환하는 함수인데, 메모리 동적 할당과 당시 배열의 관점, 특히 차원을 가지고 배열을 만드는 것이 머릿속에 구조화가 전혀 되지 않아(…) 정말 어려웠다. 할당해야 할 메모리의 크기를 정확히 계산하고, 오류가 났을 때 이미 할당된 메모리를 모두 해제(free)해주는 누수(leak) 방지 처리까지… 컴퓨터가 깨끗하게 일을 시작해, 마무리 짓기까지 정말 많은 걸 배울 수 있었던 함수였다.
• ft_itoa: 정수를 문자열로 바꾸는 이 함수는 INT_MIN 같은 극단적인 케이스를 처리하는 게 핵심이었다. 사실 split 을 어려워하여 먼저 했었는데, 결국 각 자료타입이 표현할 수 있는 숫자의 양, 그리고 위에서 언급한 케이스들 조사를 하면서 정말 많이 틀렸었던 기억이 있다.
• ft_substr, ft_strjoin, ft_strtrim: 문자열을 자르고, 합치고, 특정 문자를 제거하는 등, 전에는 단순히 메서드 하나가 하나의 전체 작업을 담당하고 있었다면 그것을 구분하고, 단계를 구성하는 연습을 이 메서드들 기반으로 처음 해봤던 기억이난다.

3. 보너스: 연결 리스트 다루기 (Handling Linked Lists)

배열까지는 접근했으나, 다음을 살짝 맛볼 수 있는 기회가 해당 보너스 내용이었다.

typedef struct s_list
{
	void			*content;
	struct s_list	*next;
}					t_list;

추상화된 개념, ‘노드’는 꽤나 신선했다. 머릿속에서, 혹은 수학이나 과학에서 사용되는 개념의 캡슐을 만들고, 그 캡슐을 활용한 추상적인 표현을 오히려 구조로 만드는 과정. 그렇게 되었을 때, 단순한 수식으로 풀어 내려면 복잡할 수 있는 것을 좀더 가시적으로 인지하기 용이하게 만든다는 개념은, 수포자였던 나에게는 대단히 신선한 충격이었다.

이처럼 간단한 구조체로 노드(node)를 만들고, 그 노드들을 엮어서 리스트를 만들고, 새로운 노드를 추가하고(lstnew, lstadd_front, lstadd_back), 리스트를 순회하고(lstiter), 삭제하는(lstdelone, lstclear) 등… 연결 리스트의 기본적인 모든 것을 구현했을 때, 더 복잡한 문제나 데이터의 처리를 훨씬 빠르게 대응하는게 가능했다. 특히 t_list **lst처럼 이중 포인터를 사용해서 리스트의 시작 주소 자체를 변경해야 했던 ft_lstadd_front 같은 함수는 포인터에 대한 이해도를 한 단계 끌어올려준 기억이었다.

🛠️ Makefile의 마법 (The Magic of Makefile)

프로그래밍, 코딩만 하다보면 잊는 경우도 많고, 특히 요즘은 인터프리팅 언어를 많이 쓰게 되다보니 잊고 살았지만. 본 과제에서는 C 코드뿐만 아니라 Makefile 작성법을 제대로 배운 첫 경험이기도 했다. 단순히 gcc 명령어를 나열하는 것을 넘어, 변수를 사용하고, %.o: %.c 같은 규칙을 만들고, all, clean, fclean, re, bonus 같은 목표(target)를 설정하면서 빌드 자동화를 지정하여 컴퓨터가 이해할 수 있는 목적 파일을 만들어낸다. 이 과정을 통해 만들어진 libft.a라는 정적 라이브러리(static library)는 그 뒤로 C 언어를 사용하는 동안 유용한 도구가 되어 주었다.

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

libft 과제를 동료들과 이야기 하고, 메모리나, 추상적 개념을 설명하거나, Makefile에 아스키 이펙트를 넣는 등의 작업은 정말 재밌는 작업이자, 시간 가는 줄 모르는 작업이었다.

• 메모리, 그리고 포인터: C가 왜 강력하고, 동시에 왜 위험한 언어인지 몸소 체험했다. 내가 직접 메모리를 할당하고 해제하면서 왜 그리 문제가 되고, 실제로 다른 언어들을 쓰게 되는 이유가 뭔지를 알 수 있었다.
• 문제 해결 능력: man 페이지를 친구 삼아, 수많은 오류와 세그폴(segmentation fault)을 디버깅하면서 끈질기게 문제를 파고들었다. 특히 man 페이지는 영어로 되어 있기도 하고 개발자의 언어로 적혀 있다보니 ‘간결’ 하지만 동시에 어느 영역에서 얼마나 이 메서드가 움직이는 건가? 와 같은 내용들을 다 파악할 수 없다는 점에서 첫 과제는 대략 1달의 시간이 들었다.
• 코드 규약(Norm): 42의 엄격한 코드 스타일 규약(Norminette)이란 것도 일종의 불만 이었다. 몇자 내에 작성이 되어야하고, 언어의 컨벤션을 지켜야 하는 등의 일들은 도대체 왜 그렇게까지 필요한가 라고 의문을 품었었는데, 지금 생각하면 얼마나 중요한 ‘프로세스’였는지를 새삼 느낄 수 있다.

돌이켜보면 libft는 단순한 과제가 아니라, C언어라는 세계를 탐험하기 위한 나만의 지도와 나침반을 만드는 과정이었어. 비록 힘들었지만, 이 프로젝트를 통해 얻은 지식과 경험은 앞으로 어떤 어려움이 닥쳐도 헤쳐나갈 수 있는 단단한 기초가 되어주었다. 특히나 정말 빠른 친구들은 순식간에 완성시키고 다른 과제를 하곤 했다. 그걸 바라보는 내 입장에선 참 당연히 비교적인 생각, 내가 정말 이 분야에 어울리는 사람인가? 하는 불평, 불만도 생겼지만 오히려 끝까지 붙잡고 한달에 걸쳐 완성했던 내 프로젝트를 통해, ‘하면 된다’라는 막연하지만 확고한 신뢰감이 생겼던 첫 프로젝트가 아니었나 싶다. 💪