요약
에이전트가 코드를 대신 써도, 탈이 났을 때 직접 파고들 줄 알아야 시스템의 주인이 될 수 있습니다.
코딩 에이전트에 일을 맡기며 일하는 한 엔지니어의 글입니다. Codex가 컴포넌트 15개를 한 줄씩 욱여넣은 30줄짜리 파일 때문에 CI(자동 빌드·검사)가 멈춘 일을 계기로, 읽는 속도보다 빨리 쌓이는 코드를 어떻게 책임질지 따져 봤습니다.
왜 중요한가
- 코드를 손으로 짜며 시스템을 익히던 길이 끊긴 뒤 엔지니어가 무엇을 갖춰야 하는지 기준을 제시합니다.
- 모든 줄을 읽거나 아예 안 보는 두 극단 대신, 어디를 파고들지 아는 능력을 책임의 조건으로 봅니다.
- 회사가 주니어의 긴 수련 기간을 지원하지 않을 것이라고 보고, 그 공백을 메울 역량을 정리했습니다.
핵심 내용
- 장애가 나면 연락받는 사람에게는 시스템의 큰 지도와 '괴물이 사는 곳'을 아는 감각이면 충분하다고 했습니다.
- 첫째 조건은 자료구조·네트워크·동시성 같은 기초 지식입니다.
- 기초가 있어야 규모가 늘 때 처리 시간이 제곱으로 불어나는 식의 조용한 실패를 알아챈다고 했습니다.
- 둘째는 여러 분야를 두루 아는 폭이며, 정식 교육보다 호기심과 경험으로 쌓인다고 봤습니다.
- 셋째는 필요할 때 깊이 배우는 태도로, 필자는 Kubernetes 책에서 본 레벨 트리거(현재 상태를 기준으로 동작) 방식으로 고질적인 버그를 잡았습니다.
HN 반응
- 팀장으로서 남이 쓴 코드를 구성요소와 경계만으로 파악해 온 경험과 같다는 공감이 컸지만, AI는 잘못해도 잃을 것이 없어 사람 팀과 다르다는 반론이 붙었습니다.
- 큰 그림만 보던 사람이 상자 안을 파고들 실력을 어떻게 기르냐는 물음에는, 에이전트 시대의 주니어 교육 해법을 아직 아무도 찾지 못했다는 답이 이어졌습니다.
AI가 나오기 전의 제 경험과도 일치합니다. 개발자 개인으로 일하다가 팀을 맡게 되면서, 제가 직접 짰다면 이해했을 만큼 깊이 이해할 수 없을 정도로 많은 코드가 쓰이게 됐습니다.
그때 익힌 기술이 바로 말씀하신 것, 시스템을 이해하는 것입니다. 저에게 이건 "상자와 선", 즉 구성 요소와 그 상호작용을 뜻합니다. 저는 팀원들에게 시퀀스 다이어그램을 산출물에 포함하라고 권해 왔는데, 그러면 서로 코드를 시스템의 맥락 안에서 볼 수 있기 때문입니다.
경계와 기대하는 입력, 출력을 알고 있으니 상자는 속이 안 보여도 괜찮습니다. 그래서 언제 상자 안으로 들어가야 하는지 알 수 있습니다. 잘못된 형식의 메시지를 보내고 있는가? 그렇다면 코드까지 추적해 들어가면 됩니다.
코딩 에이전트가 줄 단위로 검토할 수 있는 양을 훨씬 넘게 만들어 내는 지금, 우리가 길러야 할 기술이 이것이라고 생각합니다. 시스템 관점은 지도이고, 경계는 상자 안 어디를 파헤쳐야 하는지 알려 줍니다.
거의 동의해요.
네, 우리는 시스템을 만들어야 해요.
하지만 팀을 관리하는 것과 같지는 않아요. AI는 걸린 게 없으니까요.
AI가 내린 결정은 사람이 내린 결정과 같을 수 없어요. 따르는 결과가 다르니까요. AI는 해고당할 수도, 이성에게 거절당할 수도, 사랑하는 사람들을 실망시킬 수도, 추운 밤을 길거리에서 보낼 수도 없어요. 물질적 결과를 아랑곳하지 않고 결정을 내리는 사람은 하루빨리 팀에서 내보내야 해요. 언제 터질지 모르는 시한폭탄, 곧 리스크니까요.
그러니 시스템을 만들 때는 AI가 걸린 게 없다는 사실을 민감하게 의식해야 해요.
팀 사이에 차이가 있다는 데는 동의하지만, 누가 코드를 만들든 소프트웨어를 내놓는 데 필요한 기술에는 겹치는 부분이 정말 많다고 느낍니다.
그런데 다른 중요한 점을 짚으셨네요. 에이전트는 사람이 아닙니다. 에이전트 루프를 돌리는 요인은 사람이 좋은 일을 하도록 동기를 부여하는 요인과 전혀 다릅니다.
새로운 환경에서 사람 관리 기술이 끝나는 지점이 아마 거기일 겁니다. 사람에게서 높은 품질을 끌어내는 기법은 에이전트에게는 통하지 않습니다.
AI는 걸린 게 없을지도 모르죠.
하지만 밤새, 주말에도 일해요. 아픈 적도 없고요. 뭔가를 깜빡하는 일도 없어요. 제가 보기엔 늘 최고의 결과물을 내놓고요.
저한테는 그거면 충분히 걸린 거예요.
"걸린 게 있다"는 말을 "끊임없이 코드를 반복 생성한다"로 마음대로 바꿔 정의할 수는 없죠.
사람에게 일을 맡기는 것과 에이전트에게 일을 맡기는 것이 다르다는 걸 아는 엔지니어(만드는 사람)는 모르는 사람보다 경쟁력이 있을 거예요. 에이전트를 아예 쓰지 말자는 게 아니라, 어떻게 쓰느냐가 중요하다는 얘기예요.
그랬으면 좋겠네요. Opus 5.5도 지시를 무시하고, 놓친 걸 뒤늦게 찾아내는 일이 매일 있습니다.
제가 채용했던 사람들 80%보다는 낫습니다.
그럼 당신은 뭐 하러 필요한 거죠?
저는 AI 도구를 아주 좋아하지만, 내버려 두면 앞마당을 토끼굴투성이로 만들어 놓을 거예요. 지금은 판단을 내릴 사람이 필요해요.
5년 뒤에도 그럴까요? 아마 아닐 거예요. 물론 그때는 다른 토끼굴이겠죠.
2년 전만 해도 그 AI 도구는 존재하지도 않았는데, 5년 뒤를 예측하겠다고요?
저도 당신처럼 이 상황을 태평하게 볼 수 있으면 좋겠네요!
모르는 게 약이죠!
저는 AI를 쓰는 걸 오프쇼어 팀과 계약한 것(걸린 게 없는 팀)으로 생각해요. 대신 원하는 만큼 시시콜콜 간섭할 수 있죠.
오프쇼어 팀은 걸린 게 당연히 있습니다. 원글 작성자가 말한 것과 똑같은 이유로요. 그 사람들도 살 집은 지켜야 하니까요.
AI는 절대 그럴 일이 없습니다. AI는 제품이고, 동기나 자기 보존 본능이 없습니다. AI의 유일한 목표는 당신이 평생 쓰는 토큰 지출을 늘려서 회사의 이익을 극대화하는 것입니다.
제 경험은 그렇지 않았고, 글쓴이 경험도 아마 그렇지 않을 거예요.
당신도, 그 글쓴이도 "skin in the game(걸린 게 있다)"이 실제로 무슨 뜻인지 오해하고 있다고 생각합니다.
그분 말씀은 오프쇼어 구조가 근본적으로 제대로 돌아가지 않는다는 거예요.
컨설팅 업체는 최고의 시니어 개발자를 투입했다고 말해 놓고, 실제로는 당신 프로젝트를 하나도 모르고 언제든 다른 곳으로 재배치될 수 있는 주니어에게 프로젝트를 넘기거든요.
제가 컨설팅했던 고객사는 CSS border-color 한 줄을 고치는 데 40시간을 청구한 오프쇼어 컨설팅 업체와 계약을 끊었습니다. 청구 사기가 아닌가 의심했지만, 우리가 지켜본 개발자들의 수준을 보면 헨런의 면도날(어리석음으로 설명되는 일에 악의를 끌어들이지 말라는 원칙)을 배제할 수 없었습니다.
그런데 고수준 시스템 작업만 하면, 상자 안으로 파고들 기술은 어떻게 갖춥니까?
아주 철저한 테스트와 검증에 의존한다 해도, 그 테스트와 검증은 결국 저수준을 이해하는 사람이 작성해야 합니다.
사람이 법적 책임을 지는 한, 이 방식은 누군가 소송을 당할 때까지만 통할 겁니다. 그러니 인간 전문가는 계속 존재해야 하고 양성되어야 합니다. 제품을 만드는 과정에서 자연스럽게 익히는 방식이 아니라 좀 더 명시적인 방식으로 훈련해야 하겠지만요. 기업들은 이걸 싫어하겠죠.
저 개인은 그 기술을 어떻게 갖췄느냐고요? 구식으로 쌓았습니다. 수십 년 동안 이 일을 하면서요. vi와 손으로 짜는 어셈블리로 시작해서 IDE와 고수준 언어를 거쳐, 지금은 일시적인 서버리스 배포 환경의 분산 트레이싱까지 왔습니다.
주니어는 어떻게 갖추느냐고요? 네, 그게 어려운 부분입니다. 저를 여기까지 오게 한 건 지루하기 짝이 없는 일을 몇 년씩 꾸역꾸역 해낸 시간이었습니다. 근육을 키우려면 운동을 해야 하죠. 직접 손을 더럽히는 고된 과정 없이도 그 기술을 단련할 방법을 찾아야 할지도 모릅니다. 솔직히 저도 잘 모르겠습니다. 계신 곳에서는 이 문제를 어떻게 다루고 있나요?
네, 제 말이 그 말이에요. 언젠가는 사람이 "상자 안으로" 들어가 파헤쳐야 하고, 그 사람들은 그 일을 제대로 해낼 능력이 있어야 합니다.
AI 시대의 주니어 교육을 다루는 곳은 어디에서도 못 봤어요. 그나마 비슷한 게 저희 회사 방식인데, 책임 문제 때문에 AI 에이전트가 실행하는 모든 명령을, ls 같은 단순한 것까지 개발자가 일일이 승인해야 합니다. 덕분에 AI의 분석 과정을 처음부터 따라가게 되는데, 꽤 교육적일 수 있어요.
기업의 전반적인 비용 절감 문화(AI의 매력이 바로 복리후생이 필요 없다는 점이잖아요)를 생각하면, 앞으로 AI 이전에 훈련받은 사람들이 전문 문제 해결사 길드가 될 수도 있겠죠. 회사의 거대한 에이전트 덩어리가 고장 나고 사내 직원들은 원인을 파악할 깊은 지식이 없을 때, 낙하산처럼 투입돼 불을 꺼 주고 두둑한 보수를 요구하는 길드요.
그 승인 방식은 확실히 흥미롭네요. 전문가들이 일하면서 주니어에게 자기 생각을 일부러 하나하나 설명해 주는 것과 비슷합니다. 그래야 주니어가 방법 뒤에 있는 이유를 배울 수 있으니까요.
이 문제를 근시안적으로 보는 회사들은 분명히 있습니다. 그런 회사가 그 때문에 호되게 당하는 걸 본 적이 있습니다(대체로 그렇지만 항상 그런 건 아닙니다).
회사가 이런 걸 제공하지 않는다면 사람들은 커뮤니티에 기대야 한다고 봅니다. 저는 운 좋게도 밋업이 많은 곳에 살아서 이런 이야기를 나눕니다. 그런 곳이 없다면 온라인에도 활발한 토론이 많고, 바로 이 스레드가 그 예입니다.
커뮤니티를 통해 일하면 좋은 점은, 회사가 직원을 챙기지 않을 때 새로운 기회도 거기서 찾을 수 있다는 겁니다.
컴파일러가 나왔을 때 주니어 개발자들은 어셈블리를 이해하는 기술을 익힐 필요가 없었어요. 컴파일러가 너무 편해서 그 기술을 못 배울까 걱정하는 건 잘못된 걱정이었을 거고요.
지금은 주니어들이 어차피 끝장났지만, 소프트웨어 개발 기술을 못 배워서 그런 건 아니죠.
"주니어 개발자들은 어셈블리를 이해하는 기술을 익힐 필요가 없었다"는 말은 분명 맞는 말씀입니다.
그와 동시에 제가 그 시기에 본 바로는, 주니어가 도구에 맞게 기술을 전환하도록 적극적으로 도운 조직이 모두를 어둠 속에서 헤매게 내버려 둔 조직보다 성과가 좋았습니다.
자기가 쓴 소프트웨어에 법적 책임을 지는 프로그래머는 0.1%도 안 돼요.
저도 이 접근법을 받아들이려고 노력 중인데 쉽지 않네요. 이런 시스템적 접근을 배우는 조언이 있을까요? 저한테는 영 자연스럽게 되지 않아서요.
물론이죠! 시퀀스 다이어그램을 그려 보세요. 아니면 에이전트가 산출물의 일부로 그리게 하셔도 됩니다. 저는 "상자와 선" 관점을 키우는 데 늘 큰 도움이 됐습니다. 상자는 맨 위에 쭉 놓여 있고, 선은 그 사이를 오가니까요!
비유가 마음에 듭니다. 맞는 것 같아요. 하지만 실제로는 맞지 않다고 생각합니다. 이 비유는 실제 실패가 아니라 실패의 느낌에 크게 기대고 있으니까요.
여기서 정말 중요한 실패는 제품의 실패입니다. 화난 사용자, 보안 사고, 다운타임, 망가진 워크플로 같은 것들요.
스트레스받고 불편해하는 개발자는 지금까지 제품 실패의 선행 지표였습니다. 소프트웨어는 복잡하고, 개발자가 소유해야 할 범위의 폭과 전문성의 깊이를 동시에 감당하지 못하면 작업이 부실해져 제품 실패로 이어집니다. 에이전트가 같은 방식으로 실패하는지, 에이전트를 언제 어떻게 믿어야 하는지에 대한 우리의 집단적 직관이 제품 실패를 똑같이 예측할 만큼 충분히 발달했는지는 분명하지 않습니다.
일화를 하나 들자면, 성장 단계 SaaS나 최근 상장한 회사 가운데 개발자들은 모두 스트레스를 받는데 기능 출시 속도는 올라가고 장애는 줄어든 곳을 여럿 압니다. 세 가지가 동시에 일어나고 있어요.
그러니 빨리 배우는 사람과 필요한 때 맞춰 얻는 깊이도 중요하지만, 어떤 불편함이 진짜 실패로 이어질지에 대한 직관도 중요합니다. 불편함은 언젠가 다 배우게 될 거라고 믿으며 내다 버릴 감정이 아닙니다. 오너십이란 머릿속에 시스템의 모델을 쥐고, 어디를 파고들지 선제적으로 조종하는 것입니다.
그건 주목 경제 이전에나 맞던 얘기라고 생각해요. 보안 사고나 다른 프로덕션 문제를 보면 요즘은 판세를 거의 바꾸지 못합니다. 저는 하이퍼스케일러에서 일하는데, 2023년 이후 해마다 프로덕션에 나가는 버그가 40%씩 늘었어요. 그런데도 기능과 광고가 늘어난 덕에 사용자 증가와 매출은 비슷하게 25% 정도 올랐고요.
실패가 영향을 미친다는 전제 자체가 낡은 모델에 기반한다고 봐요. 이런 걸 가정하는 거죠.
사용자가 대안에 대한 정보를 쉽게 얻을 수 있다. 그런데 LLM이 검색 엔진을 대체한 뒤로 이탈이 훨씬 줄었어요.
사용자가 행동적으로 중독되거나 특정 패턴으로 유도되지 않는다. 우리는 사용자의 인지적 약점을 이용해 앱을 계속 쓰게 만드는 패턴을 씁니다.
사용자에게 익숙한 도구의 결함을 받아들이는 대신 새 도구를 배울 정신력과 체력이 있다.
프로덕션의 일부 실패와 버그는 그리 중요하지 않아요.
소프트웨어 중심 회사의 구조 거의 전부와 개발자가 비싼 이유는 이런 종류의 오류를 막기 위해서입니다. 그 일이 더 어려워졌고, 경영진이 LLM을 더 믿으라고 강요하고 개발자가 들여다볼 여력을 줄이는 일부 회사에서는 불가능해졌죠. 이미 운영 중인 제품과 기존 문화에서는 이게 덜 문제입니다. 매출이 보호받으니까요. 하지만 결국 그런 구조는 무너지고, 품질에 대한 사용자의 인식도 무너집니다. 브랜드가 충분히 타격을 입으면 그 속도는 빨라집니다.
모든 실패가 중요한 건 아니라는 데 동의합니다(사실 대부분은 중요하지 않죠). 반대편 끝에는 시드나 시리즈 A 단계 스타트업 가운데 일단 전부 출시하고 사람들이 불평하는 것만 고치는 모델로 운영하는 곳이 여럿 있습니다. 충분히 빨리 고치기만 하면 문제를 겪는 건 처음 n%의 사용자뿐이고 수정본이 배포되니까, 평균적인 사용자 경험은 꽤 좋습니다.
하이퍼스케일러라면 프로덕션에 버그를 내보내도 카나리나 트래픽 1%에 걸리는 정도겠죠. 그 정도면 괜찮겠네요!
실패의 양상이 바뀌더라도 제 요지는 여전히 유효하다고 생각합니다. 알아채기 어렵기 때문에 여전히 치명적인 실패(데이터 손상, 악용된 보안 구멍 등)가 있습니다. 어쩌면 오너십의 핵심 목표는 그런 실패가 어디서 일어날 가능성이 큰지 직관을 기르는 것일지도 모릅니다.