솔직히 고백하겠다. 나는 제대로 된 개발을 해 본 적이 없다. 말로만 프로젝트를 하겠다 떠벌려놓고는 제대로 프로토타입도 못 만들고 엎어버리기 일쑤였다.

처음에는 외솔 풀어쓰기체 생성기(참고 사이트)를 만들고 싶었다. 그런데 문제는 맞춤법부터 바뀌어버리는 바람에, 무엇보다도 가장 큰 문제가, 굳이 이걸 만들어서 써야 할 동기를 찾지 못했다. 만들고 싶었던 당시에는 소설에 인공어를 만들 필요 없이 이걸로 대체하면 되겠다, 싶었는데, 지금은 소설 창작에 흥미를 못 느껴 만들 동기가 사라져버렸다.

둘째는, LibreOffice에서 한글 어절 자름(word-break) 기능을 지원하는 일이었는데, 문제는 있었다가 사라진 기능이라, 왜 없앴는지 개발자와 의논하기 귀찮아서였다. (...)

가장 최근 마지막으로는, 연합우주 소프트웨어인 미스키를 위한 메타 태그 전용 프록시 서버를 만드는 것이었는데, 일본어라는 언어 장벽과 여러 가지 문제가 있었지만, 가장 큰 문제는, 실력자가 나타나, 메타 태그 문제를 너무 손쉽게 해결해버려 허무하게 백지화됐다.

이번에는 무모하게 크더라도 지속성 있는 프로젝트를 생각해야겠다고 생각했다.

바로 미스키와 마스토돈의 중간 형태의 연합우주 소프트웨어를 만드는 것이다.

본론

https://blog.wishket.com/blog/43645 이 개발 블로그 글을 토대로 프로젝트 개요를 작성해 보겠다.

프로젝트명

“국밥”. 국과 밥의 혼합이고, 도메인도 만들기 간단해서, 이걸로 정했다.

기획 배경

솔직히 미스키의 너무 많은 기능에 지쳤다. 그렇다고 마스토돈 서버로 옮기자니, 미스키에서 자주 쓰이는 특유의 반응과 커스텀 이모지가 아쉬웠다.

기획 목적

마스토돈의 단순함과 미스키의 다양성을 취합

타깃 사용자

연합우주 사용자

주요 기능

• 마스토돈처럼 단순한 인터페이스에 다양한 반응과 커스텀 에모지 추가

  개발 플랫폼

  PWA를 지향한 웹 개발이 될 가능성이 높음.

이 글을 시작하기에 앞서, 세 플랫폼 다 Visual Studio Code로 IDE를 통일해서 씀을 알려드립니다.

1. 윈도우는 MinGW-w64를 설치해 줍니다. 자세한 설명은 아래 블로그 글을 참조하세요. https://dntmdgns03.tistory.com/113
2. 맥은 CodeLLDB라는 확장 기능을 추가로 깔아 줍니다.
3. VS Code에서 .vscode라는 폴더 안에, 컴파일 작업용 tasks.json과, 디버그 작업용 launch.json 파일에서 아래 코드로 복붙해 줍시다. 저는 이 코드를 ChatGPT랑 입씨름하며 만들었습니다.
4. 이러고도 맥에서는 터미널에서 실행이 안 되는 문제가 발생할 수 있는데, 이 경우에는 VS Code의 디버그 탭에서 “Debug C (macOS, CodeLLDB)”로 맞춰져 있는지 확인하실 필요가 있습니다.

tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build C program",
            "type": "shell",
            "command": "gcc",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/a.out"
            ],
            "group": "build",
            "problemMatcher": [
                "$gcc"
            ],
            "windows": {
                "command": "gcc",
                "args": [
                    "-g",
                    "${file}",
                    "-o",
                    "${fileDirname}\\a.exe"
                ]
            },
            "linux": {
                "command": "gcc",
                "args": [
                    "-g",
                    "${file}",
                    "-o",
                    "${fileDirname}/a.out"
                ]
            },
            "osx": {
                "command": "gcc",
                "args": [
                    "-g",
                    "${file}",
                    "-o",
                    "${fileDirname}/a.out"
                ]
            }
        },
        {
            "type": "cppbuild",
            "label": "C/C++: clang 활성 파일 빌드",
            "command": "/usr/bin/clang",
            "args": [
                "-fcolor-diagnostics",
                "-fansi-escape-codes",
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/${fileBasenameNoExtension}"
            ],
            "options": {
                "cwd": "${fileDirname}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "detail": "디버거에서 생성된 작업입니다."
        }
    ]
}

launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug C (Windows)",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "${fileDirname}\\a.exe",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "console": "integratedTerminal",
      "preLaunchTask": "build C program"
    },
    {
      "name": "Debug C (Linux)",
      "type": "cppdbg",
      "request": "launch",
      "program": "${fileDirname}/a.out",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb",
      "externalConsole": false,
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "build C program"
    },
    {
      "name": "Debug C (macOS, CodeLLDB)",
      "type": "lldb",
      "request": "launch",
      "program": "${fileDirname}/a.out",
      "args": [],
      "cwd": "${fileDirname}",
      "preLaunchTask": "build C program",
      "stopAtEntry": false,
      "console": "integratedTerminal"
    }
  ]
}

컴파일러에 대한 불평

솔직히 말해서, 나는 부트캠프가 두 번째다. 자바 풀스택 웹개발 과정. 자바는 그래도 바이트 코드 언어다보니 자바 JDK만 깔면 나머지는 큰 문제가 없었는데, C 언어를 하면서 나를 괴롭힌 건 코드 그 자체가 아니었다.

“컴파일러”라는 녀석이다.

솔직히 “녀석”이라는 표현도 아까울 정도로 욕이 나오는 요인이다. 참고로 강의실에서는 x64 윈도우 환경을 쓰고, 내 개인적으로는 맥북을 쓴다. 컴파일러를 강의실에 맞추면 맥북이 못 읽고, 맥북에 맞추면 강의실에서 못 쓴다.

오늘 컴퓨터를 만지면서 욕을 많이 했는데, 코드가 아니라 컴파일러 때문이었다. 바이브 코딩을 C 언어 코드가 아닌, .vscode 폴더의 JSON 파일에다 했으니 말 다 했지.

분명 직장에서 x86_64 환경을 쓰고 맥북으로 원격 작업하는 사람이 있을 텐데, 부족한 내 검색 실력을 탓해야지.

오늘 짠 코드

# include <stdio.h>
# include <string.h>
# include <ctype.h>
char c;
char str[20] = "";

char *separator(char ch) {
    if(ch >= '0' && ch <= '9') {
        strcpy(str, "숫자");
    } else if (ch >= 'a' && ch <= 'z') {
        strcpy(str, "소문자");
    } else if (ch >= 'A' && ch <= 'Z') {
        strcpy(str, "대문자");
    } else if (ispunct(ch)) {
        strcpy(str, "특수문자");
    }
    return str;
}

int main() {
    printf(">");
    scanf("%c", &c);
    separator(c);
    printf(">%c: %s\n", c, str);
    return 0;
}

1. 내가 아무래도 각 자료형별 초기값에 약한 것 같다. 나중에 자주 쓰다보면 외워지겠지.
2. C 언어는 Java와 달리, 문자열을 하나의 자료형으로 취급하지 않고, 문자의 배열로 취급한다. strcpy 같은 함수를 쓰려면 string.h라는 헤더를 포함하자. (이건 정보처리기사 공부 덕분에 대충은 알고 있었는데, 실제로 써 보는 건 처음이었다.)
3. 원래는 정규식을 쓰려고 했지만, 인공지능 덕분에 ispunct() 함수와 ctype.h의 존재를 알게 되었다.
4. 포인터에 쓰이는 부호, &와 *의 의미를 선생님께 여쭤봐야겠다.
5. 1. &은 포인터 변수의 주소값을 불러오는 역할을 하고, *은 결과값을 불러오는 역할을 하는 것 같은데, 여전히 헷갈린다.
6. 선생님 조언으로는, 배열을 저장했다가 불러오는 거랑, 헤더를 많이 붙이면 최적화 쪽에서 감점이라고 하셨다.

한국어 자막판이지만 저화질 https://youtu.be/pIbgehaiK64

고화질이지만 영어 무자막 https://youtu.be/UGXkTmmkIFc

제가 악기를 마스터해가면서 의식(awareness)에 대해 생각했습니다. 4단계로 나뉩니다. 악기 연마에 밀접한 관련이 있어요.

첫 단계는, 무의식적 무지(無意識的無知, Unconscious Not Knowing)입니다. 무엇을 모르는지조차 모르는 때, 무지란 게 그렇지만 나쁘지는 않습니다. 어린 아이가 세계 정세에 무지한 것과 마찬가지입니다.

어떤 의미로는 행복한 상태라고도 할 수 있겠지요. 에어기타를 하는 사람을 보고 웃지 않는 사람은 없지요. 같습니다. 그리하여 첫 의식 단계는 “무의식적 무지”, 마치 어린 아이가 크리스마스에 기타나 베이스를 선물받고는 기뻐하며 끌어안고, 연주나 음 따윈 신경쓰지 않아요. 거울을 보며 웃기만 하죠.

그리고 몇 주, 몇 달이 지나서 친구들과 맞춰보거나 레슨을 받으며, 선생이 그동안 몰랐던 여러 가지를 알려 줍니다. 거기서 다음 의식으로 넘어가요.

의식적 무지(意識的無知, Conscious Not Knowing). 자신의 부족한 지식을 확실히 깨닫게 돼요. 행복한 상태라고는 못 하지요. 연습·습득할 것들을 생각하게 돼요. 안타깝게도 많은 사람들이 이 취미 상태에 머물러, 더는 나아가질 못해요. 더 이상 음악이 즐겁지 않아요.

하지만 그래도 열심히 모드나 스케일 따위를 배워 나가면서 도달할 다음 단계가, 의식적 지식(意識的知識, Conscious Knowing). 자신의 연주를 파악하고 이론도 알게 돼요. 연주 중에 펜타토닉이나 모드 같은 걸 생각하게 돼요. ‘실력있는’ 뮤지션 대부분은 거의 이 단계에 많이 머물러요. 업적을 쌓아가는 단계죠. 항상 자신의 연주를 판단하고 생각하죠. 많은 프로 뮤지션이 이 레벨에 머뭅니다.

마지막 의식 단계는 무의식적 지식(無意識的知識, Unconscious Knowing). 자신의 연주를 너무나도 잘 파악해서, 신경쓰는 일도 없어져요. 생각할 필요가 없는 거예요. 모든 게 직관적으로 와닿아요. 그 의식은 ‘빅터 우튼’이나 ‘스탠리 클라크’, ‘마커스 밀러’ 같은 사람들이 도달한 경지입니다. 말할 것도 없이 행복한 상태죠.

생각해 보면, 행복하다고 할만한 상태는 두 단계 말고는 없어요. 제일 처음인 “무의식적 무지”와 마지막인 “무의식적 지식”. 즉, 첫 단계를 벗어나면, 마지막까지 도달해야 행복하게 음악을 할 수 있어요.

너무 부정적이고 힘들게 느껴질 수도 있겠지만, 그 지식이 위대하든 보잘것없든 무의식에서 지각할 수는 있을 거예요. 만약 장조 밖에 모른다고 치면, 생각 없이 연주하게끔 만들어야 해요. 힘들지만은 않을 거예요.

집에 비유할 때가 많은데요, 네 칸짜리 집이 있다고 생각해 봐요. 그 네 칸이 아까 말한 의식 4단계입니다. 그렇지만 이 집에는 벽이란 게 없어요. 언제나 어디서나 넘어갈 수 있어요. 두려워하지만 않는다면 가능해요. 옆방을 쳐다볼 수도 있어요. 옆방의 일류 뮤지션들을 볼 수가 있어요. 두려워하지만 않는다면요.

제가 하고자 하는 말은, 무엇을 배우든 최대한 빨리 무의식적 지식 단계에 다다르세요. 그 방이 집에서 가장 아늑하니까요. 감사합니다.