42 Seoul - 003_printf

🖨️ ft_printf : 데이터의 ‘표현’을 책임진다는 것의 의미

우리가 프로그래밍 세계에 입문하며 가장 먼저 배우는 주문은 아마 printf("Hello, World!");일 것이다.

너무나 당연하게, 마치 공기처럼 사용해왔던 이 함수는 컴퓨터 내부의 추상적인 데이터(숫자, 주소)를 인간이 인지할 수 있는 ‘문자’의 형태로 번역해주는 마법과도 같다.

처음, 디버그 툴을 배우기 전에 가장 쉽게, 가장 많이 쓰는 디버깅 툴도 보통 print 계열이리라.

born2beroot가 시스템이라는 땅을 이해하는 과정이었다면, ft_printf는 그 땅 위에서 오가는 데이터의 ‘표현’을 직접 설계하고 책임지는, 언어의 번역가가 되어보는 과제였다.

이 과제의 핵심은 ‘정해지지 않음’을 다루는 데 있다. 컴파일 시점에는 몇 개의 인자가, 어떤 타입으로 들어올지 전혀 알 수 없는 상황.

C언어의 엄격한 타입 시스템에 살짝 열린 뒷문을 통해, 함수의 호출 규약(Calling Convention)과 스택 메모리의 작동 방식을 어렴풋이나마 엿보며, 유연함의 대가가 얼마나 큰 책임감을 요구하는지(…) 알게 되는 과정이였다.

사실 이 과제를 먼저 해야 하는 것이었음에도, born2beroot 를 먼저 하게 된 이유도, 실질, 이 프로젝트가 가지는 방대함, 고려해야하는 우선순위 등 기존의 과제들과 격이 다른 수준의 것이었음이 가장 큰 문제였다.

🎩 가변 인자의 이해: 약속과 신뢰의 메커니즘

ft_printf의 구현은 <stdarg.h> 헤더에 정의된 매크로들을 이해하는 것에서 시작된다. 이는 단순한 기능 습득이 아니라, 함수를 호출하는 쪽과 호출되는 쪽 사이의 보이지 않는 ‘약속’을 이해하는 과정이었다.

• va_list, va_start, va_arg, va_end: 이 네 가지 도구는 컴파일러가 스택에 차례대로 쌓아둔 인자들을, 프로그래머가 제공한 ‘서식 문자열’이라는 지도를 보고 올바른 크기(타입)만큼씩 순서대로 읽어 나갈 수 있게 해주는 메커니즘이다.

printf 함수는 서식 지정자 %d를 보고 “다음에 올 인자는 int 크기만큼 읽어야겠군”이라고 신뢰하고 va_arg를 실행한다. 만약 이 신뢰가 깨지면(예: %d에 char*를 전달), 프로그램은 곧바로 정의되지 않은 동작(Undefined Behavior)의 나락으로 떨어진다.

🧩 서식 지정자 파싱: 작은 언어의 해석기(Interpreter) 만들기

처음 기본적인 메서드의 구조는 ft_printf의 본질은 서식 문자열(format string)이라는 작은 언어를 해석하고, 그에 맞는 동작을 수행하는 작은 해석기를 만드는 것과 같았다.

1. 문자열 순회 및 분기: 프로그램은 전달받은 서식 문자열을 루프를 통해 한 글자씩 읽다가, 제어 문자인 %를 만나면 해석기 모드로 전환된다. 이후 따라오는 문자에 따라 어떤 종류의 ‘번역’을 수행할지 결정해야 했다.
2. 데이터 타입별 번역:
   • c, s, %: 가장 기본적인 번역. 데이터를 그대로 표현하거나(c, s), 제어 문자를 일반 문자로 탈출(%%)시키는 역할을 담당했다. 특히 s 처리 시 NULL 포인터가 들어오는 예외 상황을 어떻게 다룰지는 ‘안정성’에 대한 첫 번째 시험대였다.
   • d, i, u: 2진수로 저장된 정수 데이터를 10진수 문자열로 변환하는 핵심적인 번역 과정. libft에서 만든 ft_itoa를 활용하고, 부호 없는 정수(unsigned int)를 처리하며 컴퓨터의 숫자 표현 범위를 다시 한번 상기하게 되었다.
   • x, X: 10진법에 익숙한 인간의 시각을 16진법으로 바꾸는 번역. 이는 메모리 주소나 비트 연산 결과를 확인할 때 왜 16진법이 유용한지에 대한 실용적인 이해로 이어졌다.
   • p: 가장 추상적인 개념인 ‘메모리 주소’를 눈에 보이는 16진수 문자열로 시각화하는 번역. 이는 포인터라는 개념을 단순한 변수가 아닌, 실제 물리 메모리 상의 한 점을 가리키는 구체적인 값으로 인지하게 만들었다.

🏗️ 코드 구조화의 여정: 기능에서 설계로

초기 버전은 거대한 if-else 혹은 switch 문 안에 모든 변환 로직을 담으려는 시도를 했다. 하지만 이는 곧 유지보수의 재앙으로 이어진다는 것을 빠르게 깨달았다.

‘처리’의 단위를 처음에는 어차피 비슷한 기능들의 나열이고, 그러니 전체를 모든 로직에서 처리하게 하는 구조는, 어쩌면 사람의 인식에서는 당연한 것이다. 노션에 로직을 설계하던 당시, 얼마나 괜찮다고 느꼈는지- 생각보다 자신감있게 그 설계를 괜찮다고 동료들에게도 자랑했던 기억이 난다.

하지만 위에서 말한 듯 재앙이 될 수 있다는 사실은 명확했다. 메서드로 구분되지 못하고, if-else, switch 의 사용은 결국 한 단어, 한 글자마다 조건문을 도는 것이었고, 수 많은 예외 케이스들을 만나는 순간 어디서 어떤 에러가 나는지를 알기가 매우 까다로웠다.

심지어 같은 로직이라고 생각하는 조건들도, 결국 겹치고 얽히다보면 논리적으로 빈틈이 생기는 경우도 있었고, 이러한 사실은 메서드 로 구분을 하고, 로직을 모듈화 하는 것이 왜 중요한지, 그리고 그 논리의 단위를 얼마나 작게 해야 하는지 아주 중요한 부분을 배울 수 있는 기회였다고 생각한다.

또한 저장 및 출력을 할 때 서식 지정자를 만날 때마다 write 시스템 콜을 직접 호출하는 방식과, 출력할 문자열 조각들을 자료구조(연결 리스트 등)에 담아두었다가 마지막에 한 번에 출력하는 방식 사이에서 고민하다가 성능의 차이를 느껴 직접 호출하는 방식으로의 개선되는 과정 등…

단순히 ‘기능 구현’을 넘어 ‘효율적인 설계’에 대한 아주 큰 고민들의 첫 문턱이 아니었나 싶다. 이 프로젝트까지 와서야 비로소 복잡한 문제를 잘게 나누어 정복하는 소프트웨어 공학의 기본 원칙을 체득할 수 있었다.

✨ 성찰 및 배운 점

ft_printf는 매일 사용하던 도구의 내부를 분해하고 재조립해보는 소중한 경험이었다.

• 추상화의 이면: printf라는 편리한 추상화 계층 덕분에 데이터가 어떻게 ‘표현’되는지에 대한 고민 없이 개발할 수 있었다. 그 이면에는 가변 인자 처리, 데이터 타입 변환, 예외 처리 등 수많은 복잡한 과정이 숨어있음을 알 수 있었다.
• 신뢰 기반의 프로그래밍: C언어의 가변 인자 기능은 타입 체크를 컴파일러가 아닌 프로그래머의 책임으로 돌린다. 이는 유연함을 제공하는 대신, 사소한 실수가 프로그램 전체를 무너뜨릴 수 있는 위험성을 내포하고 있음을, 즉 C언어가 프로그래머를 얼마나 신뢰하는(혹은 방임하는) 언어인지 몸소 체험했고, 그렇기에 어떻게 대응해두는 것, 에러 핸들링을 어떤 식으로 하는 것으로 시스템 전체의 안전성을 유지할 수 있는지를 배우는 기회가 되었다.
• 문제 분할의 중요성: 하나의 거대한 문제를 ‘파싱’, ‘정수 변환’, ‘16진수 변환’ 등 작고 명확한 단위의 함수로 나누는 과정은, 이후 더 복잡한 프로젝트를 마주했을 때 어떻게 접근해야 하는지에 대한 훌륭한 훈련이 되었다.

결론적으로 ft_printf는 단순히 문자열을 출력하는 함수를 만드는 과제가 아니었다. 컴퓨터 내부의 비트(bit) 덩어리를 인간이 이해할 수 있는 의미 있는 정보로 ‘번역’하고 ‘표현’하는 책임이 전적으로 프로그래머에게 있음을 깨닫게 한, 개발자로서의 책임감과 시야를 한 단계 넓혀준 프로젝트였다.