바이브 엔지니어링 시대의 코드 즐거움
Source: Dev.to
Introduction
프로그래밍은 기계가 내 의지에 맞게 움직이게 할 수 있다는 점 때문에 언제나 나에게 매력적이었다.
지저분한 문제를 작은 조각으로 나누는 퍼즐 같은 즐거움, 버그의 형태가 드러날 때까지 시스템을 응시하는 일, 수백 혹은 수천 개의 파일을 뒤져서 잘못된 하나를 찾는 일—이 모든 것이 잘 풀릴 때는 정말 성취감을 주며, 마치 십자말 풀이를 풀거나 퍼즐을 맞추는 것과 같다.
그 즐거움의 많은 부분은 내가 프로그래밍을 배운 방식에서도 비롯되었다. 나는 전적으로 독학했고, 대학에서 프로그래밍 수업을 들었지만 한 번도 통과한 적이 없다. 이것이 나를 다른 사람보다 뛰어나게 만든다기보다는 내 사고 방식을 형성했다. 전통적인 경로를 벗어나 배우면서 다른 사람들의 코드를 많이 읽고, 결정들을 역공학하며, 고집스러운 자기 의존성을 키우게 되었다. 이런 배경이 없었다면 가졌을 수도 없는 장점과 관점을 제공했다.
오픈소스 소프트웨어는 그 여정의 중심에 있었다. 오픈소스를 통해 배웠고, 되돌려 주는 일은 언제나 나에게 의미가 있었다—덕을 쌓기 위한 것이든 이력서를 채우기 위한 것이든 아니라 상호 호혜의 차원에서. 나는 수년간 OSS에서 엄청난 혜택을 받았으며, 무언가를 되돌려 주는 것이 인정받는 것보다 더 큰 의미가 있다. 내가 직업적으로 해온 모든 일 중에서 가장 자랑스러운 것은 바로 이것이다.
오랫동안 나는 스스로를 bare‑knuckles programmer라며 반쯤 농담으로 부르곤 했다. 고집 때문에 일을 밀어붙였다. 내가 코드를 썼다면, 그 모든 줄을 내가 직접 썼다. 내 능력을 넘어서는 코드는 프로젝트에 없었으며, 설령 시간이 오래 걸리더라도 내 능력을 늘리고 확장해야 할 때는 스스로 늘려가며 작업했다.
그 코드와의 관계는 변하고 있다.
From vibe coding to vibe engineering
나는 vibe coding이라는 용어를 좋아하지 않는다. 왜냐하면 그것은 AI에게 원하는 것을 말하면 AI가 뭔가를 내놓는다는 인상을 주기 때문이다. 내 경험은 전혀 그렇지 않다.
내가 하고 있는 일은 vibe engineering에 더 가깝다.
그것은 실제 작업이다: 계획을 세우고, 제약을 설정하며, 감각을 발휘하는 일. 올바른 질문을 어떻게 던지는지, 어떻게 반론을 제시하는지, 그리고 무언가가 잘못됐을 때 이를 어떻게 감지하는지를 아는 것이다. 많은 노력이 협업적으로 계획을 세우고, 그 출력을 검증하는 데에 들어간다:
- 왜 이렇게 했나요?
- 이 코드는 실제로 무엇을 의미하나요?
- 여기 숨겨진 가정은 무엇인가요?
작업이 사라진 것이 아니라—그 수준이 한 단계 올라간 것이다.
PAGI and the hollow aftertaste
PAGI는 내가 가볍게 떠올려 만든 것이 아니다. 나는 1년 넘게 그것에 대해 고민했다: 개인 연구, AI와의 연구, 기존 코드베이스를 읽고 다시 읽으며, 설계를 응시하고, 느낌이 맞지 않는 접근법을 배제하고, 점차 내가 만들 가치가 있다고 믿는 무언가에 수렴해 갔다. 진지한 코드를 쓰기 시작했을 때쯤 나는 이미 문제에 많은 자신을 투자한 상태였다.
실제로 만들었을 때, 나는 프로젝트 전체를 vibe‑engineer했으며, 비동기 코드와 웹 서버와 같은 실제로 복잡한 영역도 포함했다—아직 전문가가 아닌 주제들이다.
한 차원에서는 중독적이었다. 오랫동안 생각해 온 것을, 과거에 피했던 영역에서 만들어냈다. 시스템이 동작한다. 그것은 실재이며, Perl OSS 생태계에 가치 있는 추가가 될 것이라고 생각한다.
그렇지만 성취감은 다소 허전했다. 부정직하거나 부당해서가 아니라, 코드와의 관계가 달라졌기 때문이다. PAGI의 일부 코드는 내가 처음부터 직접 작성할 수 없었던 코드다. 지금은—사실 깊이—이해한다. 왜냐하면 내 vibe‑engineering 과정의 일환으로 모든 것을 검토하고, 때때로 성가시게도 상세하고 까다로운 질문을 던지기 때문이다. 그래도 모든 줄을 내가 직접 입력한 경우와는 다르게 느껴진다.
과거에는 내 프로젝트에 “내가 할 수 없는” 코드가 전혀 없었다. PAGI와 함께 그 선을 넘었다.
Authorship, credit, and open‑source discomfort
그 선을 넘으면서 특히 오픈소스에서 불편한 질문이 떠오른다.
- 이게 정말 내 작업인가?
- 작업에 대한 찬사에 어떻게 대응해야 할까?
- AI는 도구인가, 협업자인가, 아니면 유령 작가에 더 가까운가?
여기서 까다로운 점은 내가 실제로는 인정에 별로 신경 쓰지 않는다는 것이다. 내가 신경 쓰는 것은 내가 크게 혜택을 받은 커뮤니티에 유용한 무언가를 되돌려 주는 일이다. 윤리적으로는 타당하다고 느껴도, 무시하기 어려운 내부적인 불편함이 있다. 구현의 상당 부분이 대화식으로 존재하게 된 것이지 손수 깎아 만든 것이 아니라는 사실을 알 때, 영리함이나 설계에 대한 찬사는 이상하게 느껴진다.
여기에 명확한 답은 없고, 내가 그런 답을 가지고 있다고 가장하고 싶지도 않다.
Mastery, necessity, and selective depth
이 모든 것을 복잡하게 만드는 부분 중 하나는 이제는 모든 것을 마스터할 필요가 없다는 사실을 깨달은 것이다.
나는 보안이 뛰어나고 성능이 좋은 웹 서버를 구축하는 전문가가 될 필요가 없다. 그것은 절대 핵심 업무 요구사항이 아니었고, 앞으로도 될 가능성이 낮다. 이런 면에서, 나는 데이터베이스 내부 구조에 대해 상대적으로 적게 알면서 SQL을 사용하는 것과 크게 다르지 않다. PAGI를 작성한 큰 이유는 비동기 웹 프로그래밍의 복잡성을 고수준 추상화 뒤에 숨겨, 덜 숙련된 프로그래머도 많은 시간을 들여 저수준 비동기 원시를 마스터하지 않아도 사용할 수 있게 하기 위함이다.
그럼에도 불구하고, 옛 방식—줄마다, 실수마다—으로 그 주제들을 마스터했더라면 더 행복했을지 하는 생각이 남아 있다.
그 긴장은 현실적이다. 일부는 장인 정신, 일부는 정체성, 일부는 타이밍과 관련된다. 나는 직업 경력의 마지막 단계에 있다; 앞으로 10년 이내 혹은 그보다 더 짧게 이 일을 놓아줄 가능성이 크다. 반면에, 1990년대 후반 이후로 프로그래밍에 이렇게 설레었던 적은 없으며, 그 설렘은 변화하고 있는 현실에 대한 조용한 슬픔과 나란히 있다.
When vibe engineering feels like mercy
이 이야기가 단순히 “AI는 좋다 / AI는 나쁘다”는 논쟁이 아니라는 것을 설득한 것은 전혀 다른 경험이었다.
직장에서 나는 수천 줄에 달하는 복잡하고 기술 부채가 쌓인 Perl 코드를 우리 새로운 Go 기반 시스템으로 옮겨야 했다. 그 일은 불쾌했다—내가 가장 싫어하는 종류의 작업. 죽은 코드 구역, 역사적 짐, 부서지기 쉬운 로직이 많았다.
그 작업을 vibe‑engineer했을 때는 존재론적 불안감이 전혀 없었다. 오히려 안도감이 들었다.
실수했을 때의 비용이 낮았다. 감정적 부담도 가벼웠다. 모든 줄을 손수 만들지 않았다고 해서 뭔가 의미 있는 것을 잃었다고 느끼지 않았다. 이 대비는 한 가지를 명확히 보여준다: 불편함은 AI 때문이 아니라, 내가 의미를 찾는 위치 때문이다.
Thinking out loud without the paralysis
처음에 충분히 깨닫지 못했던 또 다른 이점이 있다.
많은 프로그래머와 마찬가지로 나는 특히 아키텍처와 관련해 결정 마비에 빠지기 쉽다—가벼운 강박증 정도라고 생각한다. 나는 트레이드‑오프를 돌며 “잘못된” 방향을 선택할까 두려워한다. 과거에는 잘못될 경우의 비용이 높게 느껴졌다—기술적인 면뿐 아니라 개인적인 면에서도, 많은 노력을 투자했기 때문이다.
AI와 대화하는 것이 그 순환을 깨는 데 도움이 되었다.
인간이 아니더라도 무언가와 이야기를 나누는 것은 문제를 외부화하는 데 도움이 된다. 나는 옵션을 탐색하고, 아이디어를 스트레스 테스트하며, 덜 불안하게 앞으로 나아갈 수 있다. 잘못된 선택의 개인적 비용이 낮아졌기 때문에, 나는 덜 얼어붙는다. 나는 같은 심리적 대가를 치르지 않고도 결정을 수정할 수 있다는 것을 알고 있다.
그것은 다른 종류의 기쁨이다—자부심보다 조용하지만, 확실히 존재한다.
Where joy lives now
이제는 “위대한 프로그래머”가 무엇인지 잘 모르겠다. 나는 여전히 오픈소스 작업이 가장 자랑스럽다. 지금 가장 확실히 내 것이라고 느끼는 것은 모든 코드 줄이 아니라, 내가 선택한 문제, 해결책에 부여한 관점, 그리고 어리석지 않은 최소한의 수정을 고수하고 단순하고 이해하기 쉬운 코드와 인터페이스를 목표로 하는 자세이다.