printf 없이 Hello World를 출력하려면 어떻게 할까요?

Source: Dev.to

The Problem

printf가 없다고 가정하면 화면에 “hello world”를 어떻게 출력하겠습니까?
stdout에 직접 쓰면 됩니다. 그 전에 시스템 콜을 호출하고, 그 전에 메모리‑맵된 디스플레이 버퍼에 바이트를 넣고, 그 전에 프런트 패널의 스위치를 눌러 불빛이 깜박이는 것을 보게 됩니다.

각 레이어마다 누군가가 무언가를 만들어서 다음 사람이 그걸 직접 할 필요가 없게 했습니다. 이것이 바로 전체 분야의 본질입니다—우리가 설계하지 않은 언어, 우리가 짜지 않은 컴파일러, 우리가 발명하지 않은 프로토콜. 우리는 언제나 다른 사람들의 작업 위에 쌓아 올려서 그 결과물을 우리 것이라고 부릅니다. 아무도 그에 대해 문제를 제기하지 않았습니다.

printf가 항상 있던 것은 아닙니다. 누군가가 그것을 만들었고, 우리는 별다른 고지나 죄책감, 혹은 “우리가 직접 구현할 수도 있었다”는 설명 없이 사용했습니다. 프레임워크, 패키지 매니저, 그리고 그 이후에 나온 모든 것에도 동일하게 적용됩니다.

Progression of Abstractions

front panel switches → machine code → assembly → C → printf
    ↓
    syscalls → write() → stdio → high‑level languages → frameworks

각 단계마다 누군가는 “이 부분은 더 이상 할 필요가 없다”고 말했습니다. 그리고 각 단계마다 또 다른 누군가는 “그럼 실제로 무슨 일이 일어나고 있는지 어떻게 이해하겠느냐”고 물었습니다.

이전 레이어마다 여전히 문제 자체의 언어로 사고해야 했습니다:

• C는 메모리를 생각하게 만들었습니다.
• 동시성은 상태를 생각하게 만들었습니다.
• HTTP는 실패 모드를 생각하게 만들었습니다.

추상화는 작업을 압축하지만 이해를 건너뛰지는 않습니다. 답을 얻기 위해 무엇을 요청하고 있는지 알아야 하며, 그 답을 제공하는 시스템을 직접 만들 필요는 없을 뿐입니다.

Implications

새로운 레이어는 더 높은 수준이기 때문이 아니라, 처음으로 생각 과정을 거치지 않고도 출력을 얻을 수 있게 되었기 때문에 다릅니다. 할 수는 있지만, 그렇다고 해야 할 필요는 없습니다. 많은 사람들은 여전히 먼저 생각합니다. 저수준 추론을 건너뛰는 옵션 자체가 새로운 것이며, 그 부분이 진정으로 새롭습니다.

따라서 질문은 도구가 중요한가가 아니라—그것은 언제나 중요했을 것입니다.
더 나은 질문은 다음과 같습니다: 출력이 올바르게 보이지만 실제로는 그렇지 않을 때, 당신은 그 차이를 알 수 있겠는가? 찾을 수 있겠는가? 고칠 수 있겠는가?

그것은 함정이 아니라, 변하지 않은 부분일 뿐입니다.