요약
메타 엔지니어의 고백을 계기로, AI가 짠 코드를 다 이해하지 못한 채 배포하는 불안을 어떻게 다루는지 묻는 글입니다.
본문
메타 엔지니어가 쓴 LinkedIn 글을 보고 공감했습니다.
저는 메타의 엔지니어인데, 일하면서 이렇게 불편했던 적이 없습니다. 요즘도 코드를 쓰고는 있지만 모든 게 블랙박스처럼 느껴집니다. AI로 코드를 만들어 배포하는 새 방식이 너무 빨리 굴러가서, 코드를 한 줄 한 줄 확인하는 데 시간을 쓰다가는 끝이 나지 않을 겁니다. 그러다 보면 직접 만든 시스템인데도 코드가 전부 어떻게 돌아가는지 제대로 이해하지 못하게 될 수 있습니다. 큰 그림은 알지만 세부까지는 모르는 것입니다. 어쩌면 이것이 새로운 표준이 되어 가는지도 모릅니다. 소프트웨어 엔지니어로서 몸에 밴 본능과는 정반대입니다. 저는 제가 만드는 것을 이해하는 데 익숙합니다. 이제는 마음 놓고 다음 단계로 넘어가려면 어디까지 이해해야 하는지 가늠하려 애쓰고 있습니다. 다른 엔지니어들도 이렇게 느끼십니까?
여러분은 이 문제를 어떻게 다루고 계십니까?
HN 반응
- 설계는 사람이 하고 AI에는 구현만 맡기라는 조언에 공감이 모였지만, 점진 배포가 되면 구조는 덜 중요하다는 반론도 나왔습니다.
- 동료들이 쏟아내는 수천 줄을 검토할 수 없어 그냥 승인한다며 다른 직업을 알아본다는 경험담도 이어졌습니다.
아직 아무도 이 얘기를 안 한 게 의외인데, 저는 LLM에게 코드 설계를 아예 맡기지 않습니다. 제가 만든 설계를 LLM이 구현하게 합니다.
구조 전체를 LLM에게 맡기는 대신, 제 코드가 해야 할 일을 담당할 추상화와 행위자의 계층 전체를 제가 시간을 들여 직접 만든다는 뜻입니다. 추상화들이 어떻게 놓이고 서로 어떻게 상호작용할지는 UML 수준에서 제가 정하고, 그 빈칸을 LLM이 구현하게 합니다.
이렇게 하면 코드가 어떻게 돌아가는지를 제가 알게 된다는 점이 핵심입니다. 각 단위가 어떻게 구현됐는지는 몰라도, 각 단위가 맡은 책임과 서로 어떻게 맞물리는지는 압니다. 프롬프트와 스킬을 아무리 많이 줘도 LLM은 쓸 만한 추상화를 만드는 데는 형편없다는 걸 알게 됐습니다. 일은 늘 끝내 주지만, 유지보수하기 어려운 코드가 되기 일쑤고, 요구사항이 바뀔수록 더 크고 무거운 리팩터링이 필요해집니다.
하지만 기본적인 설계 실력을 발휘해서 직접 설계하면 그런 문제가 없습니다. 나중에 리팩터링을 해도 제가 설계한 쉬운 추상화 안에 들어맞습니다. 게다가 미리 문서로 남겨 두니, 작업이 어떻게 흘러갈지를 보여 주는 살아 있는 문서도 생깁니다.
미리 계획하는 데 처음에 몇 시간이 들지만, 그러면 LLM의 일이 쉬워지고 토큰도 덜 쓰고 장기적으로 코드도 더 좋아집니다. 추상화만 제대로 잡혀 있으면 어떤 단위가 최적이 아니어도 상관없습니다. 최악의 경우에도 나중에 구현을 더 나은 것으로 갈아 끼우면 되니까요.
이 방식에 동의하지만, 이런 얘기를 굳이 해야 한다는 게 좀 놀랍네요. 이건 기본적인 소프트웨어 설계 원칙이고, 경력 있는 프로그래머라면 누구나 기본으로 이렇게 접근할 거라고 생각했거든요. 이 방식을 안 쓰는 사람들은 진짜 소프트웨어가 어떻게 만들어지는지 본 적 없는 주니어 개발자가 대부분일까요, 아니면 시니어 쪽으로도 번지고 있는 걸까요?
지금 업계 사람 대부분은 FAANG에서도, "시니어" 직함을 단 사람들 사이에서도 "소프트웨어 설계 원칙"을 다뤄 본 경험이 거의 없습니다. 비현실적인 보상 패키지를 받는 수만 명의 명문대 출신 인재들이 지난 10년 동안 JIRA에서 티켓을 뽑아 기존 코드에 최소한만 바꾸는 패치를 붙이는 일을 주 10시간쯤 하고, 나머지 30시간 넘게는 회의에서 거의 멍하니 앉아 보냈습니다.
읽기 아프지만 제 경험에도 들어맞는 말이네요. 이런 부류는 부채를 사일로 담장 너머로 던져 버리고, 뭔가 잘못되면 손가락질을 해대는 경우도 많죠.
저도 이제 보호 대상이 될 만큼 나이를 먹어서 나이 차별한다는 소리는 듣고 싶지 않고 그런 뜻으로 하는 말도 아닙니다. 그래도 자기 커리어의 마지막 직장에 와 있다는 걸 스스로 아는 듯한 부류가 분명히 있고, 저는 그런 사람들을 피해 다닙니다. 그런 경우를 너무 많이 봤거든요.
저도 제 코드는 이런 식으로 작업하지만, 동료들이 뭘 하고 있는지는 전혀 모르겠고, 일주일에 새로 생기거나 바뀌는 수천 줄을 리뷰하는 건 불가능합니다.
저는 그냥 PR을 승인합니다. 어쩔 수 없으니까요. 달리 뭘 해야 할지 모르겠습니다. 제 코드조차 다 살펴보기 벅찹니다.
지금 이직 자리를 찾고 있는데 북유럽 채용 시장이 어렵습니다. 저는 여기서 품질에 대한 관심을 모든 면에서 접었습니다. 제가 그렇게 큰 소리로 반대했는데도 회사는 분명히 자기 방향을 정했거든요.
제가 보기에 좋은 회사였던 곳과 본 마지막 면접에서는 NLP가 뭔지 묻는 질문에 제가 알아듣지 못해서 떨어졌습니다.
저는 웃었는데 그분은 웃지 않았고, 기분이 상한 얼굴로 진지한 질문이라고 하더군요. 농담인 줄 알고 "아, LLM 말씀이세요"라고 했습니다. 물론 그 뒤로는 진지하게 대답하려고 했지만, 기술 면접 3차였는데 연락이 오지 않았습니다.
새 직장을 구할 때까지는 월급만 받으면서 어중간한 결과물이나 내고 있습니다. (시니어 엔지니어, 경력 10년, 특허 보유, 유니콘 기업 3년 근무)
전기 기술자가 되는 것도 생각 중입니다.
NLP의 의미를 그들이 빼앗아 가면 불쾌할 것 같습니다. NLP는 자연어 처리(Natural Language Processing)를 뜻하고, LLM은 NLP의 일부일 뿐입니다. 기술 지식이 있다고 주장하면서 NLP가 "자연어 프로그래밍"이라고 우기는 사람은 걱정스럽습니다. Lisp에 가변 객체를 추가하자고 할 법한 사람들이니까요.
NLP가 "신경언어프로그래밍(Neuro linguistic programming)"이기도 하다는 걸 알면 놀라고 짜증 나실 수도 있겠네요. 저는 NLP를 얘기하면서 그걸 뜻하는 기술자들을 만난 적이 있습니다...
그건 심리학 쪽 얘기죠. 분야마다 자기들 용어가 있어도 별문제 없습니다. 의사소통이 무너지는 건 같은 분야 안에서 하나의 용어를 다른 것에 돌려 쓸 때입니다.
심리학이라기보다 초심리학에 가깝죠...
저는 다른 일로 전향하기 전의 마지막 기술직이 될 곳에 있습니다. 제가 좋아하던 일의 측면들은 사라졌고, 저한테 잘 안 맞는 작은 회사에서 비자 절벽을 앞두고 낮은 연봉으로 그럭저럭 버티는 중입니다. LLM이 주도하는 기술직 시장에서 경쟁력을 갖추려면 밟아야 할 단계들이 다른 직업(아마 의료 쪽)으로 바꾸는 데 필요한 단계들보다 덜 끌립니다.
행운을 빕니다! 저는 작년에 과감하게 뛰어들어서 지금 의대 필수 선수 과목을 마무리하는 중이에요. 제 유기화학 II 수업 30명 중 적어도 6명은 전직 소프트웨어 엔지니어일 거예요.
감사합니다! 의료 쪽으로 바꾼다는 게 정확히 무슨 뜻인지는 아직 탐색하는 단계입니다. 선수 과목은 하나도 안 끝냈고, 지금 계획은 내년에 두 번째 학사 과정에 등록해서 생물과 화학 과목부터 들어 나가는 거예요. 간호사부터 PA 과정, 의학물리까지 여러 선택지를 보고 있는데, 여러 직업에서 일하는 분들을 직접 따라다니며 지켜보는 일부터 시작해야 할 것 같아요.
의대에도 관심이 가지만, 저는 20대 후반 여성이고 아이를 갖고 싶어서요. 지금 의대 과정을 시작하면 수련이 끝나는 게 30대 후반인데, PA나 간호대는 그런 문제가 없으니까요. 의학물리는 그 중간쯤입니다.
오, 흥미롭네요. 저는 생명정보학을 잠깐 알아봤지만 의학물리는 생각조차 못 했어요. 의료 분야가 이렇게나 크다는 것, 그리고 전향하기 전에는 제가 그걸 얼마나 몰랐는지 놀라울 정도예요. 직접 따라다니며 지켜보는 게 앞으로 뭘 하고 싶은지 정하는 데 큰 영향을 준다는 데 동의해요. 제 사촌은 의대 대신 PA 쪽으로 갔는데, 투자 대비 효과와 자유 시간 면에서 솔직히 그게 최선인 것 같아요. 지금 30대 초반인데 격주 주말마다 다른 나라에 가 있거든요.
충분히 이해해요. 저는 님보다 나이가 좀 더 많은데, 진로를 정할 때 가정을 포기할 가능성이 높다는 게 부정적인 항목 맨 앞에 있었어요.
말 그대로 저도 같은 처지예요. AI로 돈도 벌고 사람도 돕는 제품을 만들 수 있는지 해보고, 안 되면 (훨씬) 적은 돈을 벌면서 사람을 돕는 의료 쪽으로 갈 생각이에요.
네, 조직 차원에서 강제해야 하는 문제일 거라고 생각합니다. 자기 일에 자부심이 있는데 책임지는 사람도 없이 쓰레기만 밀어 넣는 생각 없는 동료들을 상대해야 하는 분들께 공감합니다. 저는 (LLM이 나오기 전에) 전반적인 문화에 질려서 기업 소프트웨어 개발을 떠났는데, 그 뒤로 더 나빠졌으리라는 상상밖에 안 됩니다.
네, 지금은 정말 심각합니다. :( 안전하고 품질 좋은 소프트웨어를 만드는 기술을 10년 넘게 배우고 갈고닦았는데 이제 그게 쓸모가 없어졌다는 게 너무 아파요.
잘 풀려도 아무도 신경 쓰지 않고, 안 풀리면 "따라오든가 뒤처지든가"라는 말을 무심하게 듣습니다. 그게 문제의 핵심도 아닌데, 그냥 지금은 너무 힘들어요. 일하면서 즐거운 게 하나도 없어요.
어디로 가셨는지 여쭤봐도 될까요? 저는 진지하게 탈출구를 찾고 있는데 아직 뭘 해야 할지 모르겠어요. 스칸디나비아에서는 기술직 임금이 실제로 비슷하니 기술직도 괜찮을 것 같은데, 다시 학교에 가고 싶지는 않아요.
저는 운이 좋게도 돈을 충분히 모아 두어서, 검소하게 살면서 한동안 좋아하는 일과 공부 삼아 하는 프로젝트를 하고 있습니다. 혼자 개발자로서 AI를 활용해 상업용 소프트웨어 개발로 돌아가는 것도 생각하고 있는데, 초점은 품질과 장인 정신에 두고요. 제 생각에 품질 좋은 소프트웨어에 열정이 있다면 야심 찬 새 프로젝트를 시작하기에 지금보다 좋은 때는 없었습니다.
안전하고 품질 좋은 소프트웨어를 만드는 기술을 10년 넘게 배우고 갈고닦았는데 이제 그게 쓸모가 없어졌다는 게 너무 아파요.
과장된 홍보 때문에 그렇게 느껴질 수는 있지만, 정말로 그렇다는 데는 큰 의문이 듭니다. 제가 보는 업계는 "빠르게 움직이고 부수라"와 "이건 정말 제대로 돌아가야 한다"의 두 진영으로 빠르게 갈라지고 있습니다. 에이전트로 전부 짜서 PR에 뭐가 들었는지 제대로 확인도 하지 않고 병합하는 방식은 앞쪽에서는 표준 관행이 됐지만, 뒤쪽에서는 웃음거리가 되어 쫓겨날 겁니다.
LLM도 설계 원칙은 알고 있어요. 경험 많은 개발자라고 해서 생각만큼 특별한 건 아니에요.
오해하지 마세요. LLM은 대부분의 일에서 저보다 훨씬 낫습니다. 하지만 지금 세대의 모델이 가끔 의심스러운 결정을 내린다는 건 부인하기 어려울 겁니다. 특히 프로젝트 구조, API 경계, 코드 중복에서요. 그리고 전반적으로 취향이 나쁘다고도 생각합니다. 물론 이건 더 주관적이지만요.
잘난 척처럼 들리지 않게 말할 방법을 모르겠지만, 지난 1년을 보면 그런 것들 대부분은 그냥... 중요하지 않았어요. "변수 이름을 두고 PR 댓글로 싸우는 것"의 다음 단계일 뿐이라서 곧 구식이 될 겁니다.
물론 정말 중요한 시스템에서는 문제가 되겠지만, "코드를 A/B 테스트할 수 있거나" "천천히 배포할 수 있다면" 아마 중요하지 않을 거예요.
토큰 지출이 실제 회계의 대상이 되기 시작하면 설계가 중요하다는 걸 알게 되실 겁니다.
기술 부채는 여전히 기술 부채입니다. 그걸 헤치고 나아갈 수 있는 모델이 있다 해도, 계속 진척을 내려면 갈수록 정교한 모델이 갈수록 큰 컨텍스트 윈도를 다루며 갈수록 추측에 의존하는 작업 공간 연산을 해야 하니까요.
앤트로픽이나 오픈AI 같은 벤더들이 자기네 모델이 플랫폼 전체를 알아서 코딩할 수 있다고 시연하는 건, 그 플랫폼이 갈수록 복잡하고 알 수 없게 되어 가는 가운데 함정을 파는 겁니다. 그들은 내부용/출시 전 모델의 혜택을 보는 데다 사실상 무제한 지출이 가능하기 때문입니다. 그 모든 지출이 여러분을 함정으로 끌어들이는 미끼 역할을 하죠.
그 밖의 모두에게는 여전히 설계가 중요합니다. 사람들이 그 사실을 잊게 만들려고 정말 열심히 애쓰고 있을 뿐입니다.
솔직히 그 주장을 계속 듣는데, 지난 2년은 오히려 반대를 보여 줬어요. OAI/Ant만 추론을 제공하는 건 아니거든요.
비용을 낮추려고 "언제 Fable/GLM/DS를 쓸지"에 대한 일반 지침을 갖춘 FAANG급의 진짜 회사들도 있어요. 앞으로도 그렇게 갈 거라고 생각해요.
기술 부채에 대한 주장에는 답하지 않으셨네요. 주어진 토큰 예산 안에서 유지보수하기 좋은 고품질 코드를 가장 많이 얻으려면 어떻게 해야 할까요? 적어도 지금까지는 사람 전문가가 루프에 들어가는 게 답으로 보입니다. 그리고 LLM이 소프트웨어 개발을 완전히 자동화해 버릴 거라는 말을 몇 년째 들어 왔지만, 소프트웨어 채용 공고는 꾸준히 늘고 있습니다.
https://www.cnbc.com/2026/10/11/ai-software-developer-jobs.html
그게 그렇게 중요하지 않아요. 제가 내부에서, 다른 회사들에서, 다른 조직에서 읽는 모든 사례에서 보면 "유지보수" 비용은 내려가고 있어요. 토큰 예산은 바뀌고 있지만 모델 품질과 효율도 같이 올라가고 있고요.
그건 첫날부터 논란이었다고 생각해요. SE 일자리는 자동화될 수 있지만, 새 회사를 세우거나 새 투자를 하거나 하는 일이 가능해지면 일자리가 오히려 늘어날 수도 있죠.
가끔이죠. 님이 더 잘할 수 있다고 믿을 만큼 자주는 아니에요. 설령 그럴 수 있다 해도, 그런 방식으로 일하는 게 전체적으로 가치가 있다고 믿을 만큼은 아니고요.
원하는 방식으로 일하시면 됩니다. 제 경험상 에이전트가 모든 결정을 내리게 두면 진흙 덩어리가 되어서, 하나를 바꾸려면 수십 개 파일을 건드려야 합니다. 더 많은 컨텍스트가 필요하고, 토큰도 훨씬 빨리 먹고, 에이전트가 지름길을 택해 기술 부채를 쌓아요. 그래서 저는 제가 API를 정의해 둔 파일 하나, 또는 작은 파일 몇 개에만 변경이 닿게 하는 방식을 선호합니다. 앞으로 바뀔 수도 있겠죠. 저는 이 방식을 못 박아 둔 게 아닙니다.
그렇게 결론짓기엔 너무 이른 것 같아요. 우리는 에이전트 코딩을 이제 겨우 1년 했고, 그동안 역량이 크게 좋아졌잖아요. 이 논쟁의 어느 쪽에서도, 장기적으로 어디에 안착할지에 대한 결론을 뒷받침할 실증적 증거를 가진 사람은 없다고 생각해요.
제가 보는 주된 논거는 약간 보수적으로 가는 게 득이 될 가능성이 크다는 거예요. 감독을 너무 많이 해서 코드를 조금 덜 내보내는 잘못의 비용이, 아예 유지보수할 수 없는 시스템이 돼 버리는 비용보다 낫다는 거죠. 경우에 따라서는 "조금"보다 더 많이 덜 내보내겠지만, 이미 복잡하게 돌아가는 기존 시스템 대부분에서는 코드 생산 말고도 속도를 제한하는 요인이 많아서 실제 차이는 그리 크지 않아요.
에이전트 코딩 속도에서는 기술 부채가 훨씬 빨리 드러납니다. 소프트웨어 개발에서 실증적 증거를 요구하는 건 좀 터무니없는 기준이에요. 우리는 지금도 예전만큼 정량적으로 깜깜하니까요. 하지만 적어도 제게는 일화적 증거가 아주 분명합니다. 지금의 에이전트는 언덕 오르기식으로 최적화하고, 사람이 루프에 없으면 소프트웨어 아키텍처가 꽤 믿음직하게 나쁩니다.
그리고 얼마나 빨리 나아질지는 논란의 여지가 있어요. 소프트웨어 유지보수성에 대한 검증 가능한 보상은 가능하다고 보지만 아주 어렵습니다.
"제 경험상"이라고 한 건 말 그대로 지금까지의 제 경험이라는 뜻이었습니다. 저는 예측을 하는 게 아닙니다. 상황이 빠르게 나아지리라고 분명히 기대하고 있고, 그래서 자주 실험해 보는 게 좋다고 생각하는 거고요. 한 달 뒤에 에이전트가 읽을 수 없고 유지보수도 안 되는 엉망진창을 만들지 않고 2만 줄짜리 프로젝트를 한 번에 만들어 낸다는 걸 확인하게 되면, 정말 좋겠죠.