요약
LLM이 세부를 대신 파고들면서 저수준 프로그래머가 설 자리를 잃었다는 고백입니다.
블로그 purplesyringa.moe의 운영자가 9월 24일에 쓴 개인적인 글입니다. 컴퓨터가 어떻게 돌아가는지 알고 싶어 8년 동안 저수준 작업을 해 왔지만, LLM(대형 언어 모델)이 그 의미를 앗아 갔다고 털어놓았습니다.
왜 중요한가
- 세부를 아는 것이 곧 평판이던 개발자에게 LLM은 편한 도구가 아닙니다. 일하는 이유 자체를 흔드는 변화라는 점을 보여 줍니다.
- 저자는 1년 사이에 세워 둔 앞날 계획을 잃고 장애 급여 신청을 걱정하게 됐다고 했습니다. 일의 즐거움과 생계가 함께 무너질 수 있다는 뜻입니다.
핵심 내용
- 저자는 자신을 저수준 분야도 다루는 프로그래머가 아니라, 세부에만 몰입할 수 있는 사람이라고 소개합니다.
- 빠진 정보가 있으면 배우지 못하고 개념을 처음부터 다시 쌓아야 이해하는데, 예전에는 이 성향이 강점이었다고 했습니다.
- LLM이 핫 루프(실행 시간을 가장 많이 잡아먹는 반복문)를 찾고 최적화까지 제안하면 그런 전문성의 값어치가 떨어진다고 봤습니다.
- 개인 프로젝트에 LLM을 써 보고는 모델이 누구보다 그 프로젝트를 잘 알게 되리라 느껴, 아끼는 작업에는 쓰지 않기로 했습니다.
- 이런 일을 챙길 여력이 있는 회사는 드물고, 레트로 컴퓨팅과 성능 최적화 취미판도 인정만 좇는 LLM 사용자가 늘었다고 했습니다.
HN 반응
- 저자와 같은 공허함을 느낀다는 공감이 많았고, AI를 덜 쓰고 코드를 직접 읽는 동료가 리뷰와 맥락 공유에서 더 낫다는 경험담도 나왔습니다.
- 반면 AI가 만든 대량의 변경을 사람이 따라잡기는 어렵다는 반론과, LLM의 변경을 이해하도록 돕는 새 도구가 필요하다는 제안이 맞섰습니다.
이 스레드의 여러 관점에 많이 공감합니다. 글쓴이의 마음도 이해하고요. 저도 제 직업의 앞날이 두렵고, 그 어느 때보다 생산적인데도 일이 예전만큼 보람 있게 느껴지지 않습니다.
그런데 LLM이 소프트웨어를 쓴다는 무서운 이야기나 에세이 대부분에 대해 저에게는 반례가 딱 하나 있습니다. LLM을 거의 쓰지 않는 제 동료입니다. 적어도 저와 비교하면 거의 안 쓰는 편입니다. 지금도 코드 대부분을 손으로 씁니다. Claude Code 없이 코드베이스를 grep으로 뒤지고요. 물론 Claude Code를 쓰긴 하지만, 일회성으로 딱 정해진 작업에만 씁니다.
그는 우리 팀의 다른 사람들(저 포함)처럼 지극히 평범한 개발자입니다. 그런데 우리 중 누구보다도 확실히 도움이 됩니다. 다른 팀 사람들이 어떤 게 어떻게 돌아가는지 물으면 늘 가장 먼저 답해 주고, 기획 회의에서 쓸모 있는 맥락을 짚어 주는 것도 늘 그 사람입니다. 코드 리뷰에서는 제가 놓친 것, 그리고 Claude나 Copilot도 놓친 것을 잡아냅니다.
저는 AI 쪽으로 너무 기운 것 같습니다. 제가 게으름뱅이인 탓도 있고, 벌써 좀 지쳐 버린 탓도 있고요. 하지만 예전에는 없던 뚜렷한 차이가 저와 제 동료 사이에 생겼습니다. 컨텍스트 부패(context rot)가 정말로 자리를 잡아 가고 있고 점점 심해지는 것 같습니다. 그러니 세부 사항을 신경 쓰는 일에는 여전히 가치가 있다고 생각합니다.
딱 제 얘기네요. 저는 LLM을 브라우저에서 특정한 질문을 할 때만 씁니다. 있잖아요, 제 작업을 블랙박스로 추상화해 버리게 두는 게 아니라요...
저는 회사에서 LLM을 안 쓰는 사람들을 많이 상대하는데, 대화가 막다른 길에 부딪히는 일이 꽤 잦습니다. 제가 “아니, 여기 인덱스가 없어서 앱에 성능 병목이 생기는 거예요. 성능 테스트를 돌려 보면 알 수 있어요” 하고 말하는 식이죠(실제로는 인덱스가 없어서 FOR UPDATE가 테이블 전체를 잠가 버리는 바람에 멈춰 버린 건이었습니다). 그러면 그 침묵이 들립니다(Slack 곳곳에서요). 그쪽은 거기까지 가려고 하지 않습니다. 해당 문제용 성능 테스트 스위트를 손으로 짜려면 품이 엄청나게 들고, “예전 같으면” 그걸 해야 한다고 정당화하기도 어려웠을 테니까요. LLM은 고려 대상이 아니라서, 분명히 해야 할 작업이 아예 시작도 못 하는 일이 됩니다. 제 Claude는 인덱스의 영향을 확인해 볼 수 있게 그 스위트 전체를 5분이면 만들어 줄 계획까지 다 세워 둔 상태였는데, 그걸 굳이 제가 다 해 주고 싶지는 않았다는 건 말할 것도 없고요. 언젠가는 LLM을 안 쓰는 동료들도 이전에는 아무도 하려 들지 않았지만 이제는 너무나 쉬워졌고, 사실상 업무의 일부가 된 일을 정면으로 마주해야 합니다.
맞는 말이지만, 성능 테스트는 원래부터 어려웠고 LLM은 이 분야에 형편없습니다. 그러니 그 동료분이 맞았을 수도 있죠.
저는 확실히 “그냥 깡통 부려 먹자” 쪽 사람입니다. 하지만 언제 쓸지 아는 게 중요합니다. 누군가 Claude가 짚어 낸 문제라며 그대로 퍼 나르는 걸 상대로 계속 따지다가 저는 완전히 지쳐 버렸습니다. 이제는 제가 상황을 어느 정도 알고 있는데 누가 “Claude가 그러던데요”라고 하면 그냥 무시합니다.
이 경우라면 문제를 보여 주는 열 줄짜리 재현 코드를 직접 만들 수도 있었을 것 같은데요. 사람이 해석할 수 있는 그런 걸 보내면 되지 않았을까요?
어떤 LLM을 쓰세요? Sol 6.1, Opus 5.5, Fable, Astra 중 아무거나에 그냥 성능 테스트를 해 보라고만 해도, 최적화가 형편없는 코드는 확실히 나아집니다.
구체적인 계획을 주면 탄탄한 테스트 하네스가 나오고요.
그리고 autoresearch 시스템을 구축해서 밤새 돌리면, 지표를 제대로 잡았을 때 전문가 수준의 최적화를 얻을 수 있습니다.
이런 건 성능 최적화에 아주 강합니다.
저는 이 말이 전혀 믿기지 않습니다. 우리 팀에도 (있었다는 점에 힘주어 말하는데요) 말씀하신 것과 똑같이 AI 도구를 멀리하고 모든 걸 손으로 하겠다고 고집한 베테랑 엔지니어들이 있었거든요. 나머지 팀원들이 AI를 도입한 뒤로도 한참 그랬습니다. 그런데 막상 코드 리뷰를 하면, 자기들이 익숙한 코드 영역에서조차 그들이 찾아낸 버그란 게 대개 사소한 지적, 자잘한 걸로 시간 끌기, 의견에 가까운 피드백(그걸 본인들은 객관적 사실처럼 포장하려 들었고요) 수준에 그쳤습니다. 게다가 AI가 찾아낸 건 거의 전부 반박했습니다. 비현실적인 시나리오라느니, 신경 쓸 가치도 없는 엣지 케이스라느니 하면서요.
근본적으로, AI 에이전트가 작성한 PR은 코드 줄 수와 분량이 꽤 작지 않은 이상 사람이 질 높은 피드백을 줄 수 없을 거라고 생각합니다. 한 사람이 머릿속에 담기에는 정보와 맥락이 너무 많습니다. 시니어 엔지니어가 제대로 읽고 좋은 피드백을 줄 수 있는 코드가 시간당 평균 400줄 정도이고, 코드 리뷰에 시간을 쓸수록 그 수치가 더 줄어든다는 통계를 본 적이 있습니다. 그래서 AI를 따라잡겠다고 고집하는 모든 분께 이렇게 말씀드립니다. 행운을 빕니다.
특히 Claude의 코드 리뷰 스킬은 쓸 만한 걸 꽤 찾아냅니다. 다만 특정 유형의 코드에는 큰 사각지대가 있어요. 그리고 사소한 지적도 잔뜩 내놓는 편인데, 항상 2개에서 8개 사이로 뭔가를 찾아내라고 아주 단단히 훈련받은 것 같습니다. 다행히 자잘한 걸로 시간 끄는 지적에는 “아니, 그건 됐어”라고 하면 잘 받아들이고 고집하지 않습니다. 하지만 큰 문제는 끝까지 붙들고 있죠. 그래도 처음에는 안 꺼낸 사소한 지적이 몇 개 더 튀어나오기는 할 겁니다!
하지만 코드를 속속들이 아는 사람이라면 리뷰의 신호 대 잡음비가 더 좋을 거라는 건 충분히 믿을 수 있습니다.
저는 균형점을 찾으려 애쓰는 중입니다. Claude가 놓친 끔찍한 버그를 찾아내기도 했고, 반대로 Claude가 저를 위해 끔찍한 버그를 찾아내 준 적도 있으니까요. 그것도 AI가 생성한 코드가 수만 줄이고 AI가 리뷰까지 하는 코드베이스에서요. 그래서 둘 다 활용하고 싶습니다.
“와, 이거 우리 가정을 많이 바꿔 놓는데” 싶은 큰 버그 중에는 누군가 에이전트를 찔러서 “이 부분에 충분히 신경을 안 쓰고 있는 것 같은데”라고 말했기 때문에 비로소 발견된 것들이 있습니다. 제 경험상 이게 둘 다 쓰는 걸 정당화해 줍니다.
그리고 에이전트가 정말 중요한 부분을 보도록 짚어 주는 걸 잘할수록, 에이전트도 당신이 놓친 문제를 더 잘 찾아냅니다.
Claude의 코드 리뷰는, 리뷰에서 찾았다고 주장하는 버그를 Claude가 직접 재현해 보게 하는 것에 비하면 훨씬 덜 흥미롭습니다. 제 경험으로는 후자의 적중률이 터무니없이 높았어요.
많은 사람이 이 도구를 쓰는 방식에서 가장 큰 문제는 도구를 신탁처럼 찾아간다는 점입니다. 문제에 도구를 연결해서 서로 주고받으며 풀게 하는 대신에요.
그리고 Claude가 놀라운 건 바로 후자의 상황입니다. 테스트를 돌리고, 직접 하면 며칠이 걸리거나 이상한 문제의 루프에 갇힐 시나리오를 구성할 수 있으니까요. 그런 다음 “좋아, 이 문제를 하나씩 보여 줘”라고 하면 그 자리에서 직접 확인할 수 있습니다.
버그의 상당수는 본질적으로 코드가 그럴듯한 일을 올바르게 수행하긴 하는데, 애초에 그걸 하면 안 되는 경우입니다. 코드베이스와 그 목적에 익숙한 사람은 이런 버그를 곧잘 알아봅니다. 경험이 적은 사람은 대개 못 알아보고요.
문제는 암묵지, 즉 암묵적 맥락입니다. 세부 사항 대부분은 어디에도 적혀 있지 않습니다. 경험으로 알고 있지 않다면 추측해야 하고, 추측하면 틀리는 일이 많습니다. 게다가 경험으로 아는 것조차 그걸 어기는 무언가를 보기 전까지는 자기가 안다는 사실을 의식하지 못하는 경우가 많습니다. 그러니 미리 적어 두는 것도 불가능합니다.
위 내용에서 사람을 AI로 바꿔도 본질적으로 달라지는 건 없습니다.
두 분 다 일화를 말하고 있는 거죠. 일화끼리는 서로 “상쇄”되지 않습니다.
제 일화를 세 번째로 하나 얹겠습니다. 제가 겪은 코드 리뷰 중에는 AI가 피드백을 잔뜩 내놓는데 그냥 잡음일 뿐인 경우가 있었습니다. 무시해야 할 것이거나, 피드백을 따르면 오히려 해가 되고 나중에 그걸 “고치느라” 토큰이 더 드는 경우였죠. 그런 일도 생깁니다. 가끔은 AI가 내놓는 결과가 상식에 어긋나고, 가끔은 아주 잘 맞아떨어집니다.
이 말에는 동의합니다. 다만 이유는 다릅니다. 꿀과 쓰레기가 뒤섞인 바다에서 헤엄치려는 것과 비슷합니다. 지치는 일이죠.
저는 LLM 리뷰 도구가 PR에 만족하고 돌아오기까지 얼마나 걸리는지 보는 게 재미있더라고요. 100줄쯤 바뀐 PR, 대단히 중요하진 않지만 그렇다고 사소하지도 않은 정도를 생각해 보세요. 로컬에 Claude 세션을 하나 띄워서 PR을 지켜보며 피드백을 기다리게 하고, 권고안을 전부 받아들여 변경 사항을 푸시한 다음 리뷰를 다시 요청하게 합니다. 어이없는 돈을 날리지 않으려고 반복 횟수는 10번으로 제한해 두고요. 그런데 LLM 리뷰어가 변경에 만족하면서 피드백이 전혀 없는 PR은 아직 한 번도 못 만들어 봤습니다.
그럼 LLM 기반 리뷰는 어디서 끊는 게 합리적일까요?
어, 저는
codex /review가 한 번에 만족하고 돌아온 적이 여러 번인데요. 손으로 쓴 PR이든 LLM의 도움을 받은 PR이든 마찬가지였습니다.우리는 LLM 리뷰를 딱 한 번만 돌리고, 권고안을 무작정 다 받아들이지 말고 팀이 직접 따져 보자고 논의도 했습니다. 그러니 (0, 1] 번 사이 어딘가인 셈이죠. 다만 사람과 LLM이 얼마나 관여하는 게 좋은가 하는 선호 비율은 그쪽과 우리가 다른 것 같네요.
어떤 종류의 문제를 강조해야 하는지, 어떤 게 사소한 지적이고 어떤 건 문제도 아닌지 지침을 담은 자체 스킬을 직접 작성하지 않았다면 완전히 정상적인 현상입니다.
저희 저장소에서는 blocker, should-fix, nit으로 분류하는 체계를 씁니다. 각 분류의 구체적인 정의와 기준, 예시는 스킬 파일에 담겨 있고요. PR을 리뷰할 때가 되면 에이전트들이 이 스킬을 불러와서 솔직히 정말 훌륭하게 해냅니다. 그다음에 사람이 지적 사항을 하나하나 읽고, AI에게 후속 질문을 던지고, 그 지적을 PR 리뷰에 올릴지 최종 결정을 내립니다.
이게 통한다는 걸 아는 이유는, 우리 팀에 이 스킬을 쓰지 않고 에이전트를 PR에 무작정 던지는 사람이 한 명 있기 때문입니다. 그 결과는 말씀하신 그대로입니다.
“잘못 쓰고 계시네요” 이거죠 :)
저와 똑같은 사람을 설명해 주셨네요. 같은 동기, 완전히 이해하지 못하는 건 쓰지 못하는 같은 성향, 같은 학습 방식, LLM이 나타난 뒤로 느끼는 같은 공허함까지요. 놀라울 정도인데, 저도 답은 없습니다. 저는 에이전트를 일종의 새로운 논리 프로세서로 받아들여 쓰려고 합니다. 그리고 에이전트를 가두고 제대로 정렬시킬 논리 하네스용으로 저만의 언어를 만들고 있습니다. 논리학, 정보 이론, 컴퓨터 과학의 근본 원리를 건드리는 일이라 지금 제게 흥미로운 건 그것뿐이에요. 하지만 나머지, 그러니까 평범한 문제를 위한 컴파일러를 쓰거나 프로그램을 쓰고 코드를 쓰는 일은 이제 전부 시시합니다. 다른 사람들이 LLM으로 복잡한 걸 뽑아내느라 고생한다는 건 저도 잘 알고 있는데도요(테오라는 사람이 토큰에 50만 달러를 쓰면서 만든 TypeScript 컴파일러 같은 게 그런 예인데, 그건 저라면 한 달 만에 1000분의 1 비용으로 만들 수 있습니다). 그렇다고 이 일에 달려들 만한 동기가 크게 생기지는 않습니다. 이유는 제가 문제를 풀어서 공개하고 나면 사람들이 그 아이디어와 거기에 들어간 에너지(수천 개의 작은 결정들)를 그냥 훔쳐 갈 수 있기 때문입니다. 예전에는 같은 규모로는 불가능했고 같은 두뇌 투입이 필요했던 일이죠. 이 불균형 때문에 저는 이제 뭔가를 오픈 소스로 공개하는 게 사실상 불가능해졌습니다.
제가 이해할 수 있게 도와주실 수 있을까요? 일하는 데 필요한 이해의 고도는 무엇이 결정하나요? 모든 걸 (물체라면) 마지막 원자 덩어리까지, (소프트웨어라면) 어셈블리 한 줄 한 줄까지 알아야 하는 건 분명 아닙니다. 계약이 분명히 정해진 깔끔한 인터페이스로는 왜 충분하지 않은 거죠? 그런 의미에서 저수준 라이브러리와 고수준 라이브러리를 실제로 가르는 건 무엇입니까?
적어도 저는 원한다면 합리적인 노력으로 스택의 어느 부분이든 이해할 수 있다고 믿을 수 있어야 합니다. 마침 반도체 물리를 파고들고 싶어지면 기꺼이 뛰어들 겁니다(저는 물리학자 출신이라 원자 수준은 학교에서 이미 거의 배웠습니다).
진지하게 묻습니다. 지금 스택의 어느 부분이든 이해하는 데 방해가 되는 게 뭔가요?
LLM에게 설명해 달라고 할 수도 있겠지만, 그게 도움이 될 올바른 출처처럼 느껴지지는 않을 것 같습니다. LLM을 활용해 사람이 쓴 자료를 찾아내고 그걸로 새로운 걸 배울 수도 있습니다. LLM이 “모든 일을 대신 해 줄” 필요는 없으니까요.
최신 AI 시스템은 강력합니다. 하지만 전능하지도 전지하지도 않습니다. 세부 사항을 이해하는 건 여전히 가치가 있고, 특히 어떤 알려진 분야든 그 최전선을 밀어붙이고 싶다면 더욱 그렇습니다.
어쨌든 상황이 절망적인 건 아닙니다. 적어도 아직은요. :)
온갖 부가 기능과 언어 서버 등을 다 갖춘 최첨단 모델에게 X의 사례를 전부 찾아 달라고 할 수 있죠. 그러면 12개를 내놓고 그게 전부라고 합니다. 최소 40개는 된다는 걸 빤히 아는 상황에서요(정확히 몇 개인지는 모르지만). 그래서 아니라고, X23과 X27 같은 게 빠졌다고 알려 줍니다. 그러면 AI는 다시 나갔다 와서 네, X가 41개 있습니다, 여기 있습니다 하고 말합니다. 그게 맞는지 확인하려면 얼마나 파 봐야 할까요?
저는 직접 찾아봤다가 여전히 빠진 게 있는 걸 발견한 적이 여러 번입니다. 그 빠진 걸 확인해 보라고, 더 꼼꼼히 찾아보라고 시키면 앗, 하더니 이제는 확실히 전부 찾았다고 합니다(정말일까요?).
이 이야기를 하는 건, 저는 지난 1년 넘게 하루에도 몇 번씩 거듭 당했다는 걸 말하고 싶어서입니다. 저는 지금도 이 도구들을 씁니다. 하지만 어떤 사람들이 이걸 우리 코드베이스에 대해 모르는 게 없는 신탁처럼 대하는 건 정말 이해할 수 없습니다.
좋은 지적입니다. 최첨단 모델이 늘 틀린다는 데 동의합니다. 신탁이 아니에요. 출력을 모세의 십계명처럼 받들 게 아니라, 동료들이 이 시스템을 능숙하게 다루는 사람이 되도록 북돋아야 한다고 생각합니다. 주요 AI 연구소는 지식의 롱테일 쪽으로 들어갈 유인이 부족하니 전문가가 더 필요할지도 모릅니다. 불완전하더라도 에이전트는 학습이라는 퍼즐의 한 조각이 될 수 있습니다. 답글 다시 한번 감사합니다. 생각할 거리를 많이 얻었습니다.
이 질문을 스레드 밖으로 꺼내서 지금 이 순간으로 가져와 보면...
요즘 계속 나오는 답은 “끊임없이 바뀌는 판에서 느끼는 허무함”이 아닐까 싶습니다.
미친 모자 장수의 티 파티 같은 거죠. 자리에 앉아서 돌아가는 방식을 파악해 놓으면 펑, 하고 3분의 1이 덮어써지고, 그간 들인 노력은 상당 부분 허공으로 날아갑니다. 그걸 대체하는 걸 만든 사람은 같은 만큼 고민을 쏟았을 리가 없는데도요.
많은 경우 그 원인은 순전히 우발적 복잡성(accidental complexity)입니다. 리눅스 코드베이스에 들어가 보려고 했는데, 세상에, FreeBSD보다 훨씬 어렵더군요. Chromium, LLVM도 마찬가지고요. 꼭 그래야만 하는 건 아니라고 생각합니다. 저는 (Emacs 말고도) 가능한 한 사람이 작성한 Common Lisp 소프트웨어를 쓰는데, 쓰든 작업하든 늘 즐거웠습니다.
LLM과 관련해 업계가 향해 가는 방향은 이걸 훨씬, 훨씬 더 나쁘게 만들 것 같습니다.
기계와 소통하는 엄격하고 형식적이며 재현 가능한 방법입니다.
컴파일러는 상당히 예측 가능한 소프트웨어이고, 재현 가능한 빌드도 있습니다. LLM은 여러 가지에 대해 대략적인 지식만 있고, 조금이라도 복잡한 일은 뭐든 대략적이고 흐릿한 방식으로 처리합니다. 조사에는 훌륭하고, 계획에는 괜찮지만, 실행에는 형편없습니다. LLM이 높은 수준의 요구 사항만 주어도 만족스럽게 돌아가는 코드를 쓸 수 있다는 건 기적입니다. 그리고 대개의 기적이 그렇듯, 이전에 본 적 없던 작은 현상에 눈이 부셔서 우리가 놓치고 있는 게 있을 가능성이 높습니다.
일부러 완전히 예측 가능하게 만든 겁니다. 컴파일러가 매번 다른 출력을 내놓는다면 그 출력을 디버깅하기가 꽤 어렵거든요.
원 댓글 작성자는 아니지만 비슷한 두뇌를 가진 사람입니다. 어떤 종류의 추상화는 불편합니다. 최악은 A와 B 사이에 직접적인 연결 고리가 없고, “A와 B는... 어떻게든 통합됩니다”라고만 적힌 계약 정의가 전부인 “그냥 믿어” 식의 웹 프레임워크 추상화입니다.
API가 뭔가를 받는다고 하면 그 “뭔가”의 정확한 형태를 알아야 합니다. “이 객체를 넘기면 됩니다”라는 설명은 제게 맞지 않아요. 엣지 케이스는 어디 있고, 상호작용은 어디 있고, 필요한 걸 제대로 넘기고 있다는 걸 어떻게 확신하나요? 문서는 그 객체 정의를 어디서 찾을 수 있는지 절대 알려 주지 않고, 그래서 3시간 동안 소스 코드를 파고든 끝에야 그냥 항목 두 개짜리 구조체 같은 거였다는 걸 알게 됩니다.
LLM은 복잡성의 폭발을 불러왔습니다. 갑자기 코드베이스가 어디선가 튀어나오는데, 최신 Claude를 이것저것 써 보는 걸 좋아하는 누군가가 며칠 뒤면 어차피 전부 바꿔 버릴 테니 그 모든 데이터 경로를 다 따라가 볼 의미가 없습니다.
저수준 프로그래밍에서는 거의 모든 게 의미에 맞춰 정렬된 날것의 데이터일 뿐입니다. 저는 파일 형식 때문에 헷갈려 하는 주니어들에게 파일 형식은 사회적 구성물이고, 어떤 구조가 있는 바이트 뭉치일 뿐이라고 말해 주곤 합니다. 저수준 프로그래밍에도 같은 원리가 적용됩니다. 바이트가 무엇인지, 엔디언이 어떤지, 부호가 있는지 압니다. 놓치는 게 없다는 걸 알기에 마음이 편하고, 거기서부터 각 블록이 앞의 블록 위에 쌓이는 걸 보며 쌓아 올립니다.
추상화는 멋지면서도 무섭습니다. 우리가 올라서는 거인의 어깨이지만, 그것이 비선형적으로 커지기 시작하면 우리를 매혹하는 만큼이나 위험에 빠뜨리지 않을까 두렵습니다.
채용 시장이 어떤 모습인지 저는 늘 헷갈립니다. 어떻게 사람들이 취업하려고 리트코드 같은 걸 열심히 파면서도 그런 근본적인 이해에는 구멍이 있는 걸까요?
저는 가면 증후군이 심합니다. AI를 쓰면 그게 정말 더 심해져요.
프로그래머들이 좌절하는 이유 중 하나는, 예전에는 코드가 생각을 하는 장소였는데 이제는 LLM이 파일을 휙휙 훑으며 수천 줄을 바꿔 버려서 따라갈 수 없기 때문이라고 생각합니다.
프로그램의 일부를 깊이 이해하는 건 여전히 가치가 있지만, 그걸 도와주는 도구가 없습니다. 우리는 그저 정말정말 열심히 생각하고 코드가 어떻게 서로 연결되는지 기억해 내면서 맨몸으로 부딪혀야 합니다.
저는 프로그래머가 자기 생각을 기록할 수 있는 공간을 주는 도구가 있으면 좋겠습니다. 개발자에게는 그림을 그리고 글을 쓸 공간이 필요하고, 거기에 실제 코드 상태에 맞춰 자동으로 갱신되는 코드 블록도 사이사이에 끼워 넣을 수 있어야 합니다.
제가 아는 가장 비슷한 건 Emacs에 포함된 org-babel인데, org 파일의 코드 블록을 실제 소스 파일로 내보내거나 실제 소스 파일에서 가져올 수 있습니다. 대부분
tangle과detangle이라는 함수를 호출해서 수동으로 하고요.저는 Emacs 사용자라서 이걸 Emacs에서 더 알아볼 생각이지만, Emacs가 이런 도구를 보편화하는 데 필요한 친숙한 UI가 될 일은 없을 겁니다.