C 언어와 stdio.h 라이브러리만으로 백준 풀며 포텐셜 올리기

제목 : stdio.h 만 가지고 백준 문제 풀어본 결과

---

코드 결과를 빠르게 보고 싶다면, 밑의 텍스트를 클릭하세요

코드로 바로 이동하기

다양한 라이브러리가 존재하는데, 굳이 힘들게 푸는 이유는?

이러한 힘든 도전을 하는 이유는, "C 와 최소한의 Lib 로 알고리즘 풀어보기 도전" 썼던 글 에 상세히 적어놓았다.

요약하자면, Node.js 엔진 기반의 JS 의 성능적 한계점을 느끼고, 최적화를 수행하고 구현하면서,

최적화 과정이 저 수준의 언어로 제작하는 것 보다 훨씬 더 어렵다는 것을 느꼈다.

이럴 거면 애초에 최적화 타겟 언어로 프로그램을 제작하는 것이 더 낫다는 판단을 했다.

그리고, 특히 특정 도메인의 프로그램을 제작하기 위해 다양한 라이브러리의 역할도 알지 못한 채,

쉽게 가져와서 사용하기만 해버리는 단순한 방법론적 프로그래밍에 회의감이 들었다.

특히, 특정 프레임워크를 선택하고 공부 할 때,

이것을 구현하기 위해, 저 메서드, 클래스를 간단히 가져와서 쓴다, 라는 관점으로 볼 때는

빠른 구현을 위해 프레임워크를 도입하는 것이 좋다고 생각한다.

그러나, 프레임워크 자체가 하나의 또다른 언어 수준으로 공부가 필요 해 지는 시기가 온다.

그 이유는, 프레임워크에서 가져온 변수나 메서드들이 어떻게 작동하는지 모르고, 이를 외우기 때문이라고 생각한다.

처음에는 나도 공식문서를 따라서 구현하며 만든 컴포넌트, 혹은 WAS(백엔드) 프로그램이 간단히 제작되는 것을 보고 좋아했는데,

구조적으로 개편하거나, 최적화를 진행하는 순간, 나는 알려주는 것 말고 배운 것 말고 아무것도 아는 것이 없었다는 것을 알게 된다.

이러한 회의감은 React, NestJS, Express, TypeORM, Spring, Next.js 등등 수많은 공식문서를 배우며 느끼게 되었다.

결국 나의 학습 방법이 틀렸다는 것을 인지하고, 모르는 것이 생겼을 때,

생기는 의문이 미래의 학습에 얼마나 도움이 되는지를 생각한다.

예를 들어, 현재 내가 가상화 컨테이너에 대해 알고 싶어 조사하며 글을 작성하고 싶다고 한다면,

이는 작성할 수 있다. 실질적인 온라인 배포 및 클라이언트 유치를 위해 꼭 필요한 과정이기 때문이다.

그러나, K8S(Kubernetes) 가 뭔지 궁금하다고 지금 당장 공부하지 않을 것이다.

첫 번째로 지금 공부하고 있는 도메인과 조금 떨어져 있을 뿐 더러,

아직 컨테이너 오케스트레이션과, 도커, 가상화 기술에 대해 제대로 알고 있지 않기 때문이다.

이러한 성찰을 바탕으로, "나는 어떻게 알고리즘을 공부해야 하는가?" 에 대해 혼란스러워 했다.

언뜻 나는 백엔드에 가까우니 Spring 을 할 것 같으니, 알고리즘을 Java 로 공부했다.

그러나, 지금 나의 행보는 Spring 에 가깝지 않으며, 오히려 웹 서버 개발과,

그에 반대되는 저 수준의 언어를 이용하여 직접 메모리 관리하는 것에 좀 더 가까웠다.

EX - 다양한 정렬 알고리즘 직접 작성, 집합, 맵 등 여러 자료구조 작성.

따라서, 역사가 매우 깊으며, 대부분의 언어가 형식을 참조하거나, 이를 아직도 활용중인

C 언어를 사용하여 알고리즘을 풀기로 했다.

이는 내가 미래에 진행하게 될 프로그램에 대한 여러 전략을 생각한 것인데,

• 웹 개발 공부를 진행하며, 웹 모듈(.wasm) 으로 최적화 전략을 생각할 수 있음
• 필요 할 시, 범용성 높은 c++ 로 전환이 가능함.
• GC 탑재 및 쉬운 C 버전인 go 언어로 전환이 가능함.
• 메모리 직접 관리로 GC 의 중요성 깨닫기
• 클래스가 존재하지 않으므로, struct (구조) 를 이용한 추상화 및 구현 전략 채택하여 Golang 고려
• 현재 사용중인 에디터가 Zed 라는 Rust 로 제작된 에디터인데, 부족한 마크다운 프리뷰를 고치고 싶음
  • Rust 의 메모리 빌림을 더 정확하게 이해하기 위해서 메모리 관리를 직접 해 보는 것이 중요하다 생각(개인적)
• 포인터에 대한 직감 발달을 위함

Java 입출력 전략을 C 로 가져오기

입력 문자열에 대한 토큰화 진행하기

Java 에는 입력 문자열에 대해 토큰화를 수행하는 StringTokenizer 라는 클래스가 존재한다.

생성자와 함께 인수로 토큰화를 수행 할 문자열 을 넣어주면,

생성된 객체를 통해 토큰을 하나씩 꺼내 사용 할 수 있다.

그러나, C 에서는 scanf("%d", &받을 숫자) 와 같은 메서드를 통해 하나씩 꺼내 사용하고 있었다.

나중에 입력의 토큰 수가 동적으로 변할 문제들을 고려하여, tokenizer 라는 나만의 메서드를 만들었다.

입력된 문자 배열 char* 를 toeknizer 에 보내주면,

char** 형태로 반환되는데, 이는 "각 문자 배열의 시작 주소를 가진" , "주소 배열" 이다.

마지막 주소에는 NULL 이 들어가 있기 때문에, 확실하게 끝을 인지할 수 있다.

숫자 문자열을 정수로 변환하기

보통 scanf("%d", ...) 를 통해서 이미 정수 변수로 할당 받으면 상관하지 않아도 될 부분이기도 하다.

그러나, 나는 이 부분도 parseInt 라는 메서드로 제작했다.

먼저, 간단하게 수 0 을 가진 변수를 만들어 놓고,

숫자 문자 배열의 마지막이 올 때 까지, 변수를 x10 하고, 현재 숫자 문자를 실제 수로 변환하여 더한다.

이에 대한 예시는 맨 밑의 코드를 참조하길 바란다.

숫자 문자를 수로 변환하기

이건 매우 쉬운데, 먼저 알아야 할 것은, 문자 배열의 순서는 '0' --> '9' 순으로 간다는 것이다.

따라서, char - '0' 으로 계산하면, 바로 현재 수 문자의 정수가 추출된다.

빈 공간을 감지하기

위에서 tokenizer 라는 토큰 문자열 주소 배열을 반환하기 위해서 사용되는 기능인데,

빈 공간을 감지한다면, 이는 넘거거나, 이제 토큰화를 시작해야 한다는 의미이다.

이 때, 물론 C 라이브러리로 해결 할 수 있지만, 나는 조금 간단히 생각했다.

char 값으로 32 = ' '(스페이스) 이며, 9 ~ 13 까지가 줄넘김, 탭 등등을 의미한다.

이러한 값을 인지하는 isBlank 함수를 만들었다.

Java 에서 C 를 사용하니 느껴지는 제약들

메모리를 직접 관리해야 한다.

Java 에서는, JVM 에서 Garbage Collector(쓰레기 수집기) 와 상호작용하면서,

곧 폐기처분 될 확률이 높은 Eden 영역, 오래 살아남는 메모리 영역 Old 영역을 분리하여 관리한다.

그러나, C 에서는 그런거 없다. calloc, malloc, 혹은 realloc 으로 동적 메모리 확장한

모든 메모리들은 stdlib.c 헤더의 free 메서드를 이용하여 직접 메모리 해제를 해 주어야 한다.

직접 문제를 풀기 위해 다양한 기능을 만들면서 느꼈던 것인데, 요즘 왜 Zig 나 Rust 가 뜨는지 이해가 되었다.

둘 다 메모리 안정성을 기반에 두고 만든 저 수준의 언어

클래스가 없다.

내가 이전에 Java 로 백준을 풀 때는, 특정 도메인의 유틸 기능들을 모아놓은 클래스를 직접 제작하여 문제를 해결했다.

HashMap, HashSet, Tree, Queue, Stack 등등을 직접 구현하며 자료구조에 대한 이해도를 높였다.

그러나, C 에서는 C++ 과 달리, 클래스가 존재하지 않는다. 대신, struct 가 존재한다.

예를 들어, 우리가 특정 클래스를 만든다면, 클래스가 가질 고유의 "변수" 와 "객체" 를 선언하고,

이 클래스를 위해 사용될 메서드를 내부에서 직접 작성했다.

그러나, struct 는, 구조 가 가질 고유의 "변수" 와 "객체" 까지는 선언이 가능하나,

생성자와 소멸자를 외부에서 만들어야 하며, 이 구조(struct) 는 메서드를 추상화로 선언한다.

그리고, 외부에서 추상화 된 메서드를 직접 구현하는 형식이다.

이에 대해 굉장히 잘 작성 해 놓은 분이 계셔서, 글을 공유한다.

https://blog.naver.com/ruvendix/220980152324

포인터와 메모리 주소에 대한 개념을 숙지하고 있어야 한다.

Java 에서는 배열과 객체에 대한 정보를 JVM 이 관리하여,

우리가 직접 시스템 수준의 메모리를 건드리지 않고, JVM 이 생성 및 소멸시켜 관리했다.

이 과정에서, JVM 은 객체와 배열의 정보를 내부에 메타데이터로 저장했다.

역시나, C 는 그런것이 없다.

따라서, 우리는 객체를 생성하거나, 배열을 생성 할 때, 이 객체 혹은 배열에 대한 사이즈를 명확히 작성해야 한다.

그런데 이건, 쉽게 sizeof(<원시데이터>), sizeof(<struct 이름>)

주소의 끝을 인식할 다양한 방법을 알고 있어야 한다.

내가 백준 문제를 풀면서, 문자 배열을 순회할 때, for 을 거의 사용하지 않고, 대부분 while 로 작성했다.

이는 문자 ('\0') 가 문자 배열의 "끝" 을 알리기 때문이다.

그리고, 객체 혹은 배열의 시작 주소를 가진 포인터 배열은 NULL 로 표현이 가능하다.

그러나, 만약에 수 배열이 온다면, 이야기가 달라진다.

숫자 배열은 END 값을 0 으로 가진다. 따라서, 우리는 길이에 대한 메타데이터를 직접 생성하여 관리해야 한다.

이 경우, for 문을 사용하여 해결했다.

모든 함수와 객체, 변수에 대한 정보는 추상화 시켜 미리 작성해야 한다.

이것도 C, C++ 이 서로 다른 경향인데,

C 는 위쪽에서 작성된 코드가 아래의 구조 혹은 메서드를 호출 할 때, 무엇인지 알지 못한다.

이는 컴파일러가 위에서부터 아래로 읽기 때문이라서, 파일의 맨 위 쪽에 미리 추상화를 시켜놓아야 한다.

이러한 제약은 생각 외로, 이 문제를 풀기 위해 어떤 기능이 필요할지 세밀하게 생각하게 해 주는 계기가 되었다.

C 로 푼 문제 :

https://www.acmicpc.net/problem/1008

깃허브 코드 주소

작성한 정답 코드 예시 - 깃허브 새창

코드의 구조는 대략적으로 이렇게 표현된다.

#include<stdio.h>

extern ... // malloc, free, realloc, calloc 등등 가져오기

int parseInt(const char* str);
_Bool isBlank(ch);
// ... 등등 추상화 메서드 선언

int main(void) {

    // 메인 로직 수행
    //
    // 위에 선언한 추상화 함수를 참조하여 로직을 미리 구성할 수 있다.
    //
    // 동적 메모리 풀어주기

    return 0;
}

// ... 추상화 메서드들 작성.
int parseInt(const char* str) {
    // ... 문자열 --> 정수 과정
    return result * sign;
}
_Bool isBlank(char ch) {
    // 현재 문자가 "빈 칸" 을 의미하는 "문자들" 인지 아닌지.
    return 1 or 0
}

간단한 파싱 함수들과 유틸리티를 직접 작성한다.

수십개의 문제를 풀고 나서 느껴지는 현재까지의 문제점.

1. 실수가 어디서 발생했는지 정말 알기 어렵다.

백준의 알고리즘 문제는 전부 "문자열" 로 입력되기 때문에,

이를 파싱하거나 나누는 과정에서 같은 유틸리티 함수를 기입한다.

그러나, 내가 사람이기 때문에 가끔 메모리 접근 과정에서 실수를 한다.

예를 들어, 문자열을 들어 보자.

나는 문자열을 관리 할 때 주로 "포인터(*)" 를 가장 많이 애용한다.

직관적이기도 하고, '\0' == 0 값을 만난다면 자동으로 끝나는 while 문법을

쉽게 작성할 수 있기 때문이다.

즉, 길이를 알지 않아도 Iterater 역할을 해 주는 포인터가 루프문을 끝낸다.

하지만 가끔, 새로운 동적 문자열을 생성하고 나서, 맨 마지막 부분에 0 값을 넣어주지 않았다.

그렇다면, 결과 출력 과정에서 Segmentation Fault 에러가 난다.

내가 인덱스 참조를 잘못 했는지, 혹은 이미 free 된 메모리에 접근했는지

전부 살펴봐야 한다.

2. 코드 이해력은 높아지지만, 알고리즘 시험에는 절대 적합하지 않다.

위와 같은 메모리 접근 에러가 가장 많이 일어나고,

이 때문에 유틸리티 함수를 작성하면서도 뇌는 백그라운드로 돌아가며 체킹한다.

덕분에 코드 가독성은 매우 높아지지만, 이러한 방식은 알고리즘 시험에 적합하지 않다.

만약에, 시험 문제로 HashSet, HashMap 을 사용해야 하는 상황이 있다고 가정해 보자.

나는 만약에 이러한 문제가 나온다면 Heap Sort 와 Binary Search 를 작성하여 풀게 된다.

그러나, 누군가는 바로 Standard Library 에서 기능들을 가져와 단숨에 풀 것이다.

기존에 존재하는 유틸리티를 가져오는 데는 1 줄이지만,

그 기능을 구현하기 위해서는 150 줄 정도를 직접 작성해야 하는 것이다. (최소)

3. 다차원 배열의 생성, 삭제, 관리

이는 void* 라는 타입으로 쉽게 유틸리티 함수를 생성할 수 있다.

또한, 삭제하는 과정도 쉽게 따로 메서드를 작성할 수 있다.

이는 malloc 과 같은 동적 배열 생성 메서드의 기능으로서,

우리가 처음 접근하게 되는 인덱스 0 주소 앞에, 이 배열에 대한 메타데이터가 저장된다.

그러나, 우리가 접근 하면 헤더 무결성이 깨질 가능성이 존재하며,

free 가 이 데이터를 읽어 우리가 생성한 동적 데이터를 자유롭게 삭제할 수 있다.

하지만, 다차원 배열의 주소값 관리와 접근은 일반 개발자 입장에서 어려울 수 있다.

예를 들어, 고차원 프로그래밍 방식으로 arr[2][3] 형식을 가진 정수 배열이 존재한다고 가정하자.

그렇다면, 나는 C 언어로 2 행, 2 열의 데이터를 가져오려고 한다면,

*(*(arr + 1) + 1) 이 된다. (인덱스 1 은 "2번째" 가르킴을 상정.)

물론, arr[1][1] 방식도 가능하다. 그러나, 포인터에 대한 추상적인 직감 및 이해도를 높이기 위해

선택한 방식이다.

위의 *(*(arr + 1) + 1) 는 무엇을 의미할까?

먼저, arr 는 1차원 배열 시작 주소를 가지고 있는 배열이다.

그리고 이 1차원 배열 시작 주소를 참조 할 수 있어야, 그 배열 내부의 "값" 을 관리할 수 있다.

조금 보기 편하게 만들어 보자면,

*(*(arr + row) + col) 이라고 볼 수 있다. == arr[row][col]

포인터적인 관점에서 보자면, 다차원 배열의 관리는 타 언어들보다 어려운 편이다.

4. 배열 크기 데이터는 나만 알고 있다.

물론 malloc 으로 인해 동적 배열 생성 시, 헤더 메타데이터로 바이트를 남기긴 하지만,

free 메서드를 위한 거지, 개발자를 위하진 않는다.

물론, 이렇게 동적으로 생성된 배열의 크기를 알 수 있는 라이브러리 메서드가 존재한다.

그러나, 정적 배열과 동적 배열의 크기를 알아내는 방식이 다르기 때문에,

따로 길이를 메인 콜백에서 관리하는 것이다.

(물론, 문자열의 경우 '\0' 값을 통해 끝을 알릴 수 있다.)

5. 서로를 참조하는 코드 구조가 형성 될 경우, 메모리 해제 선언이 번거롭다.

쉬운 코드를 작성 할 때는 몰랐던 부분이었는데,

실제로 자료구조 타입을 만들고 엮는 과정에서,

이들을 말끔하게 메모리 해제하는 것이 문제 해결 자체보다 "더 어렵다" 는 생각이 자주 들었다.

예를 들어, HashMap 을 만들었다고 가정 한다면,

이들을 전부 해제하기 위해 BFS 혹은 DFS 방식으로 하나씩 참조 해 나가며 해제해야 한다.

결국 HashMap 문제가 실버 5 수준이라면, 거의 골드 4 수준으로 난이도가 올라간다..

이러한 문제에도 불구하고 알고리즘 풀이를 진행하는 이유는,

1. AI 에게 쉽게 대체 될 수 없다.

정말 중요한 요소인데, 저수준의 프로그래밍 언어는 AI 가 절대로 선호하지 않는다.

GPT 가 막 유명해졌을 초창기부터 현재까지 20 달러를 결제하여 여태까지 사용하고 있는데,

AI 는 저수준 언어를 선호하지 않는다.

정확히는, 인간의 언어와 비슷한 고차원 언어(EX - JavaScript, TypeScript, Python)

이러한 언어들을 매우 선호한다.

왜 그럴까 생각 해 보면, 이러한 언어들은 컴퓨터 하드웨어적 부분에서 크게 조심해야 할 부분이 없다.

즉, AI 입장에서 하드웨어를 딱히 더 신경써서 틀린 답을 내기 어렵다는 의미이다.

하지만, 저수준 언어 + 나만의 커스텀 자료구조 가 형성되면, 이놈도 신기하게 틀린 답을 낸다.

(현재 GPT-o3)

2. 상황에 따라 다른 언어를 쉽게 익힐 수 있다.

거의 대부분의 언어의 패러다임이 C, C++ 에서 시작했다고 말할 수 있을 만큼,

프로그래밍 역사로 보면 C 와 C++ 은 너무나도 오래 생존하고 현재도 활발히 사용중인 언어이다.

현재도 이러한 언어들을 대체하겠다는 시도들이 많은데, 대부분이 사장되고 잊혀진다.

결국 저수준 언어에서 살아남는 것은 C, C++ 였다.

(물론, Zig 나 Rust 와 같은 메모리 안전 언어로 대체하려는 시도가 보이긴 한다.)

(예를 들어, AWS 의 일부 기능이 Rust 로 이전한 것. 등등)

어셈블리와 같은 "하드웨어 수준 언어" 를 제외하면, 이것보다 어려운 언어가 존재할까 의문이 든다.

따라서, 요즘 유행중인 "쉬운 C" 인 go 를 쉽게 배울 수 있으며,

C 를 대체하고자 노력하는 Zig 를 배울 수도 있고,

C++ 을 대체하고자 하는 Rust 를 배울 수도 있다.

3. 고 수준의 프로그래밍 언어의 최적화를 구성 할 수 있다.

아무리 JavaScript 와 Python 의 최적화가 많이 진행되어 빠르다고는 하지만,

인터프리터 언어의 특성상 저수준 언어의 모듈이 부착되어 최적화가 진행되어야 하는 부분이 많다.

당연히 JavaScript 의 기본 모듈들은 저수준 언어들의 모듈을 적극적으로 사용하여 최적화한다.

저 수준의 프로그래밍을 진행하다 보니,

프로그래머스 풀스택 과정(JS & TS) 을 돌이켜보며,

C or C++ 와 같은 저수준 언어를 따로 .wasm 으로 부착하여 최적화 할 수 있는 부분이

정말정말 많다는 생각이 든다.

JavaScript, Python 의 진입 장벽이 낮지만, 최적화 면에서는 여전히 부족한 부분이 많으므로,

아직 최적화 되지 않은 부분을 모듈로 개발하여 배포한다면, 많은 개발자들이 사랑해 줄 것으로 생각된다.

요약 및 마무리

그래서 내가 진행 한 것은,

"C 로 백준 문제를 풀되, stdio.h 를 제외한 모든 유틸리티는 직접 작성하기" 이다.

물론 나 스스로도 이러한 학습 방식이 "옳다" "나쁘다" 를 결정할 수는 없었다.

그 이유는 결정적으로 컴퓨팅 지능 포텐셜을 압도적으로 높일 수 있는 방식이었기 때문이다.

저 수준의 메모리 관리와 어려운 표현식을 다루다 보니, 시각을 넓힐 수 있다는 것이 매우 큰 수확이다.

이 공부 방식을 권장하지 않는 경우

만약에, 다른 프로그래밍의 추상적인 패러다임과 하드웨어 접근에 대한 조금의 이해도가 부족하다면,

나는 추천하지 않는다.

거의 95 퍼센트 이상은 지쳐서 포기할 것이라고 생각한다.

내가 만약에 이 공부 방식을 추천한다면,

"나는 절대로 AI 에게 코딩을 전부 맡기지 않겠다"

혹은 "C or C++ 를 이용하여 특정 프로그램을 커스텀 해야 한다" 의 경우 추천할 것 같다.