해커 문화의 뿌리에서 시작해 LLM과 ‘바이브 코딩’이 장인정신, 설계, 팀 문화, 그리고 프로그래머의 정체성에 미치는 위협을 성찰하며, 도구가 아닌 인간 중심의 프로그래밍을 옹호한다.
나는 프로그래머다. 코더. 키보드 카우보이. 해커. 하루 종일 키를 두드리며 코드를 만든다. 재밌다. 그게 내 정체성이다. 에디터, Vim은 내 작업장이고 내 성소다1. 여기서 나는 내 공예를 갈고닦고, 도구를 벼리고, 호기심으로 능력을 확장하며, 잠시 동안 최면 같은 플로우로 도피한다. 생각과 나 사이엔 INSERT 모드뿐인 전체 화면 터미널 창. 브람의 제단2 앞에서, 나는 허공에서 현실의 실을 뽑아 실리콘을 타고 흐르는 비트로 잣는다. 완전히 상상으로만 존재하는, 손에 잡히지 않는 세계지만 현실(IRL)에 영향을 미친다. 장인정신과 창의성에서 위안을 찾는 곳. 퍼즐을 푸는 사이에 시간은 사라진다. 그림을 완성하는 것보다 조각을 연결하는 것이 더 중요한 곳. 손끝에서 버퍼로 솟는 공예. 나는 프로그램을 짜며 플로우와 구성 속으로 희미해진다.
1950년대 말 MIT에서 새로운, 전기가 흐르는 듯한 문화가 움트고 있었다. 손으로 만지고, 실험적이며, 반권위적이었다. 나는 그곳에 앉아 slate-blue L자형 콘솔 앞에 있는 나 자신을 상상한다. 옆의 금속 기둥 벽, 엉킨 전선, 초기 트랜지스터로 이루어진 기계—“틱소(Tixo)”4—에 먹일 천공 종이테이프 프로그램을 뱉어내는 플렉소라이터(Flexowriter)3로 쉼 없이 타이핑하며. 프로그램이 돌아가는 동안 기계에서 흘러나오는 황홀한 삑삑 소리를 들으며, 성공할까 하고 숨을 죽인다. 훗날 ‘해커’라 불리게 될 이들이 내 주변에 모여 코드에 손가락질하며 어떻게 “The Right Thing”5—완벽하고, 순정하며, 간결한 프로그램—을 이룰지 조언한다. 그들이 “해커 윤리”를 열정적으로 체현하며, 내가 탐구를 이어가도록 그들 자신의 종이 프로그램 조각을 내어주는 모습을 통해 프로그래밍의 원초적 문화가 흘러넘치는 것을 느낀다.
코딩의 공예가 주조된 곳—26동이라는 컴퓨팅의 도가니—이 바로 그곳이었다. 거의 70년 전, Tech Model Railroad Club의 구성원들은 기계의 언어에 흠뻑 빠져 디지털 마법의 숙련을 추구했다. 점점 더 어려워지는 암호 같은 난제를 형식 언어로 다루는 숭고한 마술, 그리고—문화의 핵심으로—소프트웨어 주술의 암흑 예술을 공부하는 다른 이들과 발견을 나누는 일.
고대 해커들의 유령은 여전히 기계를 배회하고, 그들이 구축한 문화를 통해 우리의 마음까지 맴돈다. 공예를 단련시키던 그들의 유산은 여전히 남아 있다. 우리는 그들이 그랬듯, 같은 경이로움, 성취감, 퍼즐 풀이의 우아함에 이끌린다. 여전히 “The Right Thing”에 의해 움직인다. 이러한 헌법적 아이디어들, 프로그래머 정체성의 핵심은 점점 더 위기에 처해 있다. 위협받고 있다. 한때 눈부시고 명확해 보였던 프로그래밍의 미래는 이제 불길한 어둠과 사기극, 불확실성에 가려졌다.
실제로, 수십억 달러짜리 AI 산업, 헤커 뉴스의 상주인들(그리고 그곳의 권력자들), 링크드인에 들끓는 LLM 광신도 군단을 믿는다면, 소프트웨어 개발의 미래는 프로그래밍과 별로 닮지 않았다. 1년 전만 해도 밈 같던 바이브 코딩(vibe-coding)은 주류가 되어가고 있다.
현재(물론 계속 바뀌지만), 바이브 광신도들의 궁정은 코드 대신 마크다운으로 사양서를 쓰라고 우리를 부추긴다. 우리가 능숙하게 누려온 깊은 몰입과 공예의 깊이는 사라졌다. 코드베이스 구석구석에서 시간을 보내며 퍼즐을 풀고, 잘 숨겨진 비밀을 찾아내던 시간은 없다. 대신, 우리를 대신해 ‘생각해주는’ 에이전트 무리 사이를 오가며 산만한 인지와 맥락 전환을 끌어안으란다. 창의적 퍼즐 풀이는 기계에 맡기고, 우리는 공예에서 분리된 채 그저 조작자로 전락한다.
일부—내 예상보다 훨씬 많은—사람들은 이런 변화, 이 새로운 정체성: “사양서 엔지니어링(Specification Engineering)”을 반긴다. 오퍼레이터가 되는 일에 들떠, 스티브 잡스 코스프레를 하며 “오케스트라를 지휘”하고 싶어 한다. 애초에 코딩에는 별 관심이 없어 보이는데, 대체 왜 프로그래머가 되려고 했던 걸까 의아할 따름이다. 혹시 워즈와 잡스를 헷갈린 걸까?
솔직히, 프롬프트, 컨텍스트, 혹은 사양서 “엔지니어링”6이 프로그래머에게 밝고 번영하는 직업을 보장하리라 상상하기 어렵다. 공예, 숙련, 노동의 가치 절하 냄새가 물씬 난다. 우리만의 독특한 추상적 사고 능력이 사실상 필요치 않은 새로운 정체성. 제품 관리자와 디자이너가 이미 점유한 영역으로 우리를 떠민다.
회사 안에서는, 이 새로운 정체성이 밀어붙여지면서 권력 역학이 바뀌고 있다. 엉뚱한 곳에서 생산성을 높이려는7 광란의 질주 속에서, 개발자들은 점점 더 구체적인 방식으로 LLM을 쓰도록 강요받고 있다. 순응하라, 아니면 추방될 것이다. 우리의 사양 만료를 예고하는 제품을 쓰거나, 사표를 쓰거나. 경영진이 우리 도구에 대해 이처럼 구체적인 사용법을 의무화한 적은 거의 없었다. 우리는 요리사나 목수처럼, 에디터를 정성껏 설정하고, 닷파일과 개발 환경을 만지작거리며, 스스로 도구를 큐레이션하고 갈고닦는 일에 큰 자부심을 느껴 왔다. 공예의 일부로, 우리는 우리의 사고와 맞닿게 도구집을 개인화하는 데 헌신해 왔다. 이런 일을 일상과 거의 접점이 없는 경영진이 칙령으로 내려버리는 것은 침해처럼 느껴진다. 그들의 관심사는 결과, 프로세스, 창의성 촉진이어야 한다. 수십 년 동안 프로그래머는 회사에서 우대받아 왔다. 이 새로운 서사는 경영진이 균형을 다시 자신들 쪽으로 기울이는 수단을 제공한다.
어떤 이들은—기쁨과 기대에 차서—LLM과 그 영향력을 저수준에서 고수준 언어로의 전환, 즉 어셈블리에서 포트란으로의 이행에 비유한다. 나는 이 비유가 여러 면에서 틀렸다고 본다. 첫째, 우리가 포트란으로 뛰어올랐을 때 그 도약은 프로그래밍에 뿌리를 두고 있었기 때문이다. 포트란은 공예를 제거하려 한 것이 아니라 그 위에 쌓았다. 포트란은 프로그래밍 형식주의의 정밀함과 표현력을 없애지 않고 확장했다. 둘째, 포트란은 주어진 입력에 대해 올바른 결과를 산출하는 데 늘 성공적이었다. 이 어느 것도 LLM의 세계에선 성립하지 않는다. 나는 광신도들이 “네가 그냥 잘못 쓰는 거야”라며, 매번 달라지는 서사에 맞춰 골대를 옮기는 소리가 들리는 듯하다. 그러나 우리는 AI 도구가 프로그래밍 언어와 같은 결과를 낼 거라 기대할 수 없다. 그것들은 전혀 다른 규칙과 파라미터에 의해 설계되었다.
컴퓨터와 프로그래밍이 얼마나 사람을 열 받게 하는지 영어에는 그걸 충분히 설명할 욕설조차 모자라지만, 적어도 우리는 언제나 정밀함 하나만큼은 믿을 수 있었다. 프로그래밍을 통해 지시한 대로 정확히 수행한다는 점 말이다. 아마도 컴퓨터의 정밀함에 의존하고 신뢰해 온 탓에, 챗봇이 우리가 요청한 대로 했다고 가스라이팅할 때8에도 곧잘 믿어버리도록 길들여진 것인지도 모른다.
LLM과 그것을 다루는 일은 본질적으로 부정확하다. 대규모 언어 모델의 특성에서도, 우리가 그것에 명령을 내리는 방식—오해되기 쉬운 자연어—에서도 그렇다. 비결정성을 그토록 질색하는 우리가, 프로그래머인 우리가 어째서 이런 컴퓨팅 방식을 선택했는지 아이러니하다. 우리는 예측 가능성, 조합성, 멱등성, 그리고 들쑥날쑥하지 않은 통합 테스트를 선호한다. LLM 코드가 대표하는 것은 그 반대다. 일관성 없는 혼돈.
다익스트라는 “자연어 프로그래밍의 어리석음에 대하여”에서 간명하게 썼다. “자연어가 일을 단순화할 것이라는 가정을 우리는 도전해야 한다.” 그리고 “형식적 텍스트의 미덕은, 정당한 조작을 위해서는 몇 가지 간단한 규칙만 만족하면 된다는 데 있다. 곰곰이 생각해 보면, 이는 모국어를 사용할 때는 거의 피하기 어려운 온갖 허튼소리를 배제하는 놀랍도록 효과적인 도구다.”
엄격함과 관료제를 들이밀어 AI 보조 개발(에이전트가 운전석에 앉는)을 바이브 코딩과 구분하려는 움직임이 있지만, 짐승의 본성을 무시한다. 나는 LLM이 생성해 준 코드를, 내가 직접 썼거나 PR에서 리뷰할 때만큼 면밀히 읽지 않게 된다. LLM 코딩에는 눈을 흐리게 만드는 어떤 속성이 있는 듯하다. 나는 대충 훑는다. 압도되고 지루하다. CI만 통과하고 컴파일만 되면, 못을 박아 놓은 함정도 눈감고 받아들인다. 테스트가 작동하도록 설정됐는지, 존재하지 않는 라이브러리를 끌어왔는지, 아니면 통째로 하나를 구현해 버렸는지조차 확인하지 않는다. 물론 대가는 나중에 치른다. 내가 판 함정에 내가 빠지고, 몇 시간의 작업이 부러진 기반 위에 쌓였다는 걸 깨달을 때. 아니면 누군가가 풀 리퀘스트나 버그 리포트에서 지적하거나, 인시던트 호출을 받을 때까지 눈치채지 못할지도 모른다.
책의 리뷰나 요약은 결코 직접 읽는 경험을 대신할 수 없다. 매 문장을 곱씹으며 수시간, 수백 페이지 동안 사유하는 경험 말이다. 마찬가지로, 마무리된 AI 작업의 요약만 훑어보는 일은 도메인, 문제, 가능한 해법에 대한 깊은 이해를 빼앗아 간다. 코드베이스와의 연결도 끊어 버린다. 자신의 무지의 심연 속으로 과감히 뛰어들어, 드러내고, 배우고, 주제와 그 함의를 이해하는 일은 만족스럽고 좋은 소프트웨어에 필수적이다. 소유감, 주체성, 깊고 충만한 일은 에이전트 탭 사이로 흩어진 주의력으로 대체됐다.
미국의 위대한 에세이스트 조앤 디디온은 이렇게 썼다. “나는 내가 무엇을 생각하고, 무엇을 보고 있으며, 무엇을 보며 그것이 무엇을 의미하는지 알아내기 위해 전적으로 글을 쓴다.” 피터 노어는 “이론 구축으로서의 프로그래밍”에서 같은 개념을 탐구한다. 노어가 말하는 “이론(Theory)”은 코드베이스에 대한 이해를 체현한다. 그것이 어떻게 작동하는지, 그 형식과 현실 세계의 표상이 무엇인지. 이는 몰입을 통해서만 얻을 수 있는 맥락과 통찰이다. 노어는 “이론”을 프로그래밍의 일차적 산출물, 결과로 나온 소프트웨어가 아니라 실제 산물이라고 말한다. 잘 발달한 “이론”이 있어야만 코드베이스에 확장과 버그 수정을 효과적으로 적용할 수 있다. 바이브에 기대 대충 훑는 시선으로는, 그런 이론을 세우기 어렵다. 아마 노어는 불가능하다고 단언했을 것이다.
좋은 설계는 몰입에서 솟는다. 우려내듯 푹 담그는 데서 나온다. 텍스트 버퍼에서의 오가며 하는 작업과, 종종 키보드에서 떨어진 자리에서 나온다. 전체 코드베이스를 머릿속에 통째로 담아두는 일은 불가능하다. 흐릿한 심상 모델을 선명하게 하려면 모듈, 클래스, 함수 속으로 잠수해야 한다. 코드를 읽고 쓰며 인지를 확장하고, 친숙함과 문제 도메인에 대한 이해를 되찾아야 한다.
대략의 맥락이 떠오르고, 수많은 서툰 시도를 거친 뒤에야 우리는 마침내 해법을 찾아낸다. 나쁜 설계의 불협화음을 몸으로 느껴야 한다. 역겹고 반복적인 코드를 직접 써 보아야만, 더 낫고, 더 간결하고, 더 우아하며, 더 조합 가능하고, 더 재사용 가능한 길이 있음을 깨닫는다. 그러면 멈칫하게 된다. 한 걸음 물러서서 문제를 깊게 생각한다. 다시 시작한다. 씻고 반복한다. 정반대로, AI 에이전트 작업은 마찰이 없다. 대안을 탐색하지 않게 만들고, 우리가 받아들인 것이 흠잡을 데 없는지, 그저 그런지, 형편없는지, 심지어 해로운지조차 알 수 없게 만든다. 품질은 반복으로 빚어진다—불쾌한 해법을 탐색하지 않고서 어떻게 좋은 설계를 상상할 수 있겠는가?
LLM으로 뒤범벅된 코딩의 인지 부채는 우리의 공예와의 분리를 넘어선다. 우리 모두 그런 이야기를 들었다. 과대광고에 취하고 바이브에 들뜬, 2010년대 초 프레임워크를 갈아타던 자바스크립트 개발자들보다도 짧은 집중력을 지닌 ‘슬롭’ 잡역부들이, 풀 리퀘스트와 설계 문서에 찌꺼기를 퍼부어 협업을 좌절시키고 팀을 혼란하게 만든다. 코드 리뷰어 동료들은 자신들이 이제 마지막이 아니라 첫 번째 품질 관리 관문이 되었다는 가혹한 자각 속에 정신이 망가져 가고 있다. 리뷰를 부탁받고; 어쩔 수 없이 갈가리 해부한다. 새로 추가됐지만 한 번도 호출되지 않는 함수, 환각처럼 추가된 라이브러리, 눈에 빤한 런타임 혹은 컴파일 오류를 지적한다. 그러는 동안 작성자는—분명히 자기 “자신의” 코드를 대충 훑었을 뿐인—아무 책임도 지지 않은 채 말한다. “이런, 그건 Claude가 쓴 거예요. 바보 같은 AI, 하하.”
오지랖 넓은 매니저와 푼돈을 아끼는 임원들은 (부디 모르는 사이에 그러고 있길 바라지만) 팀에서 인간적 상호작용을 줄이려 밀어붙인다. 고립되고 연결이 끊긴 채, 우리는 이제 스스로의 업무 경험 주위에 벽을 쌓도록 권장되고 또 권한을 부여받는다. 페어 프로그래머가 필요할 때, 해법을 핑퐁할 상대가 필요할 때, 프로토타입을 만들고 아키텍처를 스케치할 때, 코드베이스의 난해한 부분에 대한 전문가적 질문에 답할 사람이 필요할 때, 사람 대신 LLM을 찾는다. 온보딩 버디, 멘토, 동료가 더는 필요 없다. 대신 기계와 대화하면 된다. LLM이 있으면, 사람을 피하는 일이 너무 쉬워져서 곧 규범이 될지도 모른다. 미래는 정말 밝기만 하겠다…
우리가 얼마나 AI 과대광고의 서사에 쉽게 동조하고, 계획된 우리 공예의 말소9에 자발적으로 가담하며, 생각의 수단을 선뜻 내놓는지 보는 일은 불편하다. 우리는 취미로 생계를 꾸릴 수 있었던 행운아들이었다. 일부가 옛 워터폴 모델을 빼닮은 꼼꼼하고 엄격한 프로세스를 만들어 ‘슬롭’을 상쇄하자고 하지만, 그 경우에도 우리는 여전히 일에서 재미있는 부분을 외주 주고 감독질이라는 허드렛일로 바꿔치기했을 뿐이다. 다음은 뭔가, TPS 리포트?
LLM은 소프트웨어의 복잡성에 대한 ‘궤도 핵폭격식’ 해법처럼 보인다. 실제 문제를 다루는 대신, 우리는 증상을 치료하려고 훨씬 더 복잡하고 흐릿한 무언가를 집어 들었다. sed를 Claude로 바꿔 쓰거나, 문서를 몇 시간 뒤져도 여전히 명확하지 않은 라이브러리나 프레임워크에 대해 답을 물어보는 정도는 별로 개의치 않는다10. 하지만 나는 그저 오퍼레이터나 코드 리뷰어로—재미있고 흥미로운 일에 뒷자리에 앉는 것으로—남고 싶지 않다. 나는 운전대를 잡고, 공예 속으로 잠수하고, 오케스트라 _안_에서 연주하고, 복잡한 퍼즐을 풀고 싶다. 나는 프로그래머, 공예가로 남고 싶다.
나의 도구는 반복 작업(프로그래밍엔 그런 게 아주 많다)을 줄이고, 코드베이스를 이해하며, 올바른 프로그램 작성을 돕는 역할을 하길 바란다. 내 대신 ‘생각하도록’ 설계된 제품에는 모멸감을 느낀다. 내가 만든 소프트웨어에 대한 나 자신의 이해라는 주체성을 앗아가고, 동료들과의 연결을 끊는 제품 말이다. 설령 LLM이 과대광고만큼 잘해 준다 하더라도, 우리는 그 모든 것과 우리의 공예를 잃게 된다. 인간은 기계와 그 뒤의 기업들보다 더 중요하다. 그 기업들은 우리가 그들이 파는 새로운 아메리칸 드림을 좇는 동안 이윤을 챙긴다. 그 대가로 우리는 비판적 사고 능력, 즐거움, 공예, 사생활, 그리고 어쩌면 우리의 행성까지 내놓는다.
