에이전트로 인한 숙련도 감퇴
TMT숙련은 여전히 반복 훈련에서 나옵니다.
에이전트가 등장하기 전에는 코드를 쓰는 과정에서 자연스럽게 반복 훈련(reps)을 쌓았습니다. 여러 접근법을 시도해 보고, 잘못된 부분을 디버깅하고, 남의 코드를 리뷰하고, 많이 읽었습니다. 에이전트는 그 작업의 상당 부분을 건너뛸 수 있으니, 이제는 반복 훈련을 의식적으로 쌓아야 합니다.
제가 이 업계에 갓 들어온 사람이라면, 프롬프트를 넣기 전에 먼저 가설을 세워 보려 할 것입니다. "왜"를 자주 묻고, 변경된 코드를 읽고, 무엇이 실패할지 예측해 보려 할 것입니다. 때로는 문제를 직접 손으로 풀어 보기도 할 것입니다.
제 경험으로는 에이전트와 하는 작업이 잘 되려면 두 가지 능력이 필요합니다.
- 깊은 전문성: 좋은 결과가 무엇인지 정의할 수 있을 만큼 문제 영역을 잘 이해하는 것입니다. 사용자와 제품, 비즈니스를 이해하는 일도 여기에 포함됩니다.
- 판단력의 적용: 자신의 안목을 발휘해서, 알맞은 컨텍스트와 제약, 테스트, 검증 방법을 골라 이를 명확하고 검증 가능한 계획으로 바꾸는 것입니다.
이 두 가지를 기르기 위해 제가 연습할 기술은 의사결정, 명세 작성, 방향 조정, 검증입니다.
제가 실제로 쌓은 반복 훈련
소프트웨어 엔지니어링을 처음 시작했을 때, 저는 제가 뭘 하고 있는지 전혀 모른다는 느낌이 강했습니다. 무언가를 만드는 게 정말 재미있었고, 이것저것 시도해 보고 실패하고 실수에서 배우는 과정이 즐거웠습니다. 그러면서 매번 조금씩 더 멀리 나아갔습니다. 실패할 때마다 저는 그 실패를 더 나은 엔지니어가 되는 데 쓰이는 또 하나의 벽돌로 삼으려고 했습니다. 이 모든 과정이 결국 제가 반복 훈련을 쌓는 일이었습니다. 자바스크립트를 배운 방식도 그랬고, C++로 프로그래밍해서 데스크톱 애플리케이션을 만드는 법을 배운 방식도 그랬습니다. 그래픽을 많이 쓰는 애플리케이션의 성능을 튜닝하는 법을 배운 것도, 그 밖의 여러 가지도 다 그랬습니다.
반복 훈련을 쌓는 동안, 저는 어떤 작업에 들어갈 때 대체로 나름의 가설이나 아이디어를 갖고 있었습니다. 실제 동작 방식과 완전히 어긋난 생각일 때도 많았습니다. 그래도 통할 것 같은 방법을 시도해 봤고, 그게 안 되면 스택 오버플로에 가거나 웹에서 여러 문서를 찾아 읽으며 지식을 흡수했습니다. 아주 특이한 주제라면 책을 읽기도 했습니다. 그러고 나서 다시 제 길을 이어 갔습니다. 이걸 충분히 여러 번 반복하면 전문성이 쌓이기 시작합니다. 특히 주말에 취미로 만드는 수준을 넘어, 실제 현업 프로젝트에서 진짜로 해 보기 시작하면 더 그렇습니다.
지금 제가 쓰는 판단력은 대부분 이런 작은 반복 수천 번에서 나왔습니다. 실패를 디버깅하고, 남의 코드를 리뷰하고, 실제 시스템에 부딪히기 전까지는 멀쩡해 보였던 추상화를 끌어안고 살아 보는 일들입니다. 이제 에이전트는 그 작업의 상당 부분을 건너뜁니다. 경력 3년차라면, 그럴듯한 코드가 그것을 판단할 수 있는 능력보다 먼저 도착할 수 있습니다.
학습 과정을 건너뛰는 지름길
이제 AI로 개발을 시작하는 많은 사람은 학습 과정의 상당 부분을 건너뛸 수 있다고 생각합니다. "여기 문제가 있다"에서 "여기 해결책이 있다", 혹은 "작업 전체의 결과가 이렇다"로 아주 빠르게 갈 수 있습니다. 그 대신 원래라면 지식의 토대를 쌓아 주었을 과정, 그러니까 저건 하지 말라고, 왜 하지 말아야 하는지, 대신 이렇게 하라고 알려 주고 트레이드오프를 따져 볼 수 있게 해 주었을 과정을 모두 건너뜁니다. 그래서 저는 특히 주니어 엔지니어가 자기 학습에 스스로 적극적으로 나서야 하는 영역이 바로 여기라고 생각합니다.
저는 여러 AI 연구소와 이야기를 나눠 보기도 했습니다. 지금 AI 분야의 주요 업체 대부분은 사용자가 결과를 최대한 빨리 달성하거나 답을 최대한 빨리 얻도록 돕는 데 집중하고 있습니다. 학습이 목표 중 하나라고 명확히 밝히지 않으면 학습을 도와주지는 않습니다. "일정 관리 앱 만드는 걸 도와줘"라고 말하는 것과 "일정 관리 앱 만드는 걸 도와주면서, 한 단계씩 넘어갈 때마다 그 방법을 나에게 가르쳐 줘"라고 말하는 것은 다릅니다. 대부분은 두 번째처럼 말하지 않습니다. 그런 선택지가 있다는 걸 모르기 때문이기도 합니다. 요즘은 속도에 대한 기대치가 워낙 높고 빨리 출시하고 다음 일로 넘어가야 한다는 압박이 있다고 여기기 때문이기도 합니다. 하지만 더 나은 엔지니어가 되려면, 그리고 안목과 판단력을 끌어올려 주는 전문성을 계속 유지하려면, 일부러 시간을 들여 숙련을 쌓아야 한다고 생각합니다.
작업을 끝냈다고 반복 훈련이 되는 건 아닙니다
어떤 종류의 비판적 사고에서든, 어떤 문제를 다룰 때든, 해결책에 대한 가설을 세우고 그것이 어떤 모습일지 미리 그려 보는 것이 도움이 된다고 생각합니다. 로직과 코드라면 그 구조의 형태가 어떨지, UI라면 어떻게 보이고 어떤 느낌이며 어떻게 반응할지 같은 것들입니다. 작업이 끝났다고 해서 반드시 무언가를 배웠다는 뜻은 아닙니다. 그저 작업이 끝났다는 뜻일 뿐입니다. 배울 기회는 거의 의식적으로 찾아 나서야 합니다. 아니면 에이전트에게 만드는 중간중간, 또는 맨 마지막에 정리를 요청할 수도 있습니다. 이번 작업에서 얻은 핵심 교훈이 무엇인지, 중급 개발자나 주니어 개발자로서 지식의 폭을 넓히거나 문제를 바라보는 방식을 개선하는 데 도움이 될 만한 게 무엇인지 물어보는 것입니다. 이걸 계속 반복할 수 있습니다. 자기 학습에 스스로 적극적으로 나서기만 하면 됩니다.
요즘 제가 AI를 써서 할 수 있게 된 일이 여러 가지 있는데, 좀 더 복잡한 3D 그래픽 프로그래밍이 분명 그중 하나입니다. 저는 그 분야의 전문가가 아닙니다. 그래서 AI에게 이렇게 묻고 있는지 꼭 확인하려는 순간들이 있습니다. 이건 어떻게 동작하는지 설명해 줄 수 있어? 방금 구현한 이 개념을 나에게 가르쳐 줄 수 있어? 이 요소들이 서로 어떻게 연결되는지 같이 짚어 줄 수 있어? 저는 배우고 싶고 배우려는 마음이 있기 때문에, 그걸 위해 에이전트와 짝을 이뤄 일합니다. 배우려는 마음이 없다면 거기서 얻을 수 있는 기회를 잃습니다.
작업을 끝내도 반복 훈련이 되지 않는 상황은 과정에 실수가 없을 때도 생깁니다. 실수가 생기면 이런 생각을 하게 됩니다. 왜 잘못됐을까? 무엇을 더 잘할 수 있었을까? 내가 놓치고 있는 건 뭘까? 그래서 돌아보지 않을 수 없게 됩니다. 반면 모든 게 순조롭게 되면 배울 만한 순간이 거의 없습니다. 그냥 일 끝났으니 다음 작업으로 넘어가자고 생각하게 됩니다. 그래서 특히 주니어라면 계속 레벨을 올릴 기회를 찾아 나서야 합니다.
2026년 앤트로픽 연구에서 주니어 엔지니어들이 파이썬 라이브러리 Trio를 배우는 과정을 살펴봤습니다. AI 어시스턴트를 쓴 사람들은 이후 퀴즈에서 정답률 50%를 기록했고, 직접 손으로 작업한 그룹은 67%였습니다. 그리고 AI를 쓴 그룹 안에서도 좋은 결과를 낸 쪽은 모델을 코드 자판기처럼 쓰지 않고 개념을 질문하고 설명을 요청한 사람들이었습니다. 이건 제가 앞에서 말한 것과 이어집니다. AI를 그저 출력물과 결과를 뽑아내는 데만 쓰고, 짝으로 두지 않고, 비판적 사고력과 지식, 동작 원리에 대한 이해를 끌어올리는 데 쓰지 않으면, 결국 어떻게 동작하는지는 대체로 모르면서 프롬프트만 잘 쓰는 상태에 이를 수 있습니다. 그러면 검증하는 쪽은 아마 그다지 잘하지 못할 것입니다. 질문을 던지고 설명을 요청한 사람들이 더 좋은 결과를 낸 것은 저에게 별로 놀랍지 않습니다. 그 사람들은 어떻게 동작하는지, 자신이 아는 다른 것들과 어떻게 연결되는지를 훨씬 많이 되짚어 봤을 것입니다. 패턴을 맞춰 보면서, 이건 이렇게 동작하고, 나는 이렇게 이해하고 있고, 내 지식에는 이런 빈틈이 있다는 흔적을 쌓아 갑니다. 그래서 17% 차이가 난 것은 저에게 꽤 납득이 됩니다. 물론 이건 파이썬 라이브러리 하나만 다룬 단기 연구라서 결정적이라고까지는 말하지 않겠지만, 그래도 아주 흥미로웠습니다.
익숙하지 않은 것을 배울 때 저는 여전히 이렇게 일합니다. 저 자신을 과정 안에 남겨 두려고 합니다. 프롬프트를 넣기 전에 가설을 세웁니다. 왜 그런지 묻고, 변경된 코드를 직접 살펴보고, 무엇이 실패할지 예측하고, 에이전트가 자기 작업을 검증할 구체적인 방법을 줍니다. 때로는 작은 문제를 직접 손으로 풀어 봅니다. 에이전트가 작업을 마무리하는 동안에도 제 머릿속 모델은 계속 움직이고 있기를 바랍니다.
그래도 공격적으로 쓰세요
코드 수준의 전문성이 지금만큼 가치 있게 남아 있을 기간이 얼마나 될지는 모르겠습니다. 모델이 너무 빠르게 좋아지고 있어서 확신할 만한 게 별로 없습니다. 그렇다고 에이전트를 피하거나 한 줄 한 줄 직접 타이핑하는 일을 낭만적으로 포장하는 게 답이라고도 생각하지 않습니다. 저는 에이전트를 공격적으로 씁니다. 어떤 날은 세션을 다섯 개, 열 개씩 돌립니다. 한번은 다크 모드를 추가해 달라고 엉뚱한 프로젝트에 요청하고 있는 저를 발견했습니다. 그 실수가 제약 조건을 분명하게 알려 줬습니다. 에이전트의 처리량은 제 주의력보다 빠르게 늘어납니다.
성능 패널에서 보낸 수천 시간
제대로 하기까지 수천 시간을 들여야 했던 것들이 떠오릅니다. 성능 최적화가 그런 영역 중 하나입니다. 예전에는 참고할 만한 좋은 블로그 글이나 책이 늘 있는 게 아니었습니다. 메모리를 다루거나 하드웨어와 제약 조건을 어떻게 생각해야 하는지 짚어 주는 꽤 괜찮은 고전 문헌이 조금 있기는 했습니다. 하지만 웹 성능 최적화, 자바스크립트 최적화, 힙 최적화 같은 것들을 보면 좋은 글이 늘 있지는 않았습니다. 그래서 크롬 개발자 도구에 들어가서, 성능 패널로 페이지나 애플리케이션의 트레이스를 기록하고 직접 조작해 보면서 어디가 느린지 찾아내며 반복 훈련을 쌓았습니다. 그리고 파고들면서 가설을 세웠습니다. 플레임 그래프에서 문제가 가장 많이 몰려 있어 보이는 구간은 여기구나, 아니면 메모리 패널에서 보니 여기서 가비지가 수집되지 못하게 막고 있구나 같은 식이었습니다. 제 시절에는 충분히 많은 실수를 저지르고 근본 원인을 찾아내려 애쓰는 시련을 통과해야, 무엇이 통하고 무엇이 안 통하는지에 대한 지식, 때로는 아주 특이한 그 지식이 쌓였습니다.
요즘 비슷한 흐름이라면, DevTools MCP가 에이전트와 함께 성능 프로파일링을 대신 해 주고, 원인을 파악하고, 수정안까지 스스로 내놓는 식일 것입니다. 그러면 성능에 대한 전문성은 그만큼 쌓이지 않게 됩니다.
상상할 수 있는 것만 프롬프트로 쓸 수 있습니다
요즘 트위터를 훑어보면, 제 피드에 있는 상상력과 창의성에 늘 감탄합니다. 정말 많은 디자이너와 창작자가 놀라운 셰이더, 놀라운 게임, UI, 몰입형 경험을 공유하는데, 이제는 그런 것을 만드는 게 전보다 더 가능해졌습니다. 기술은 원래 있었지만, 이제는 상상력이 천장입니다. 이런 것들을 훨씬 더 빠르게 만들 수 있도록 접근성이 크게 좋아졌습니다. 하지만 애초에 아이디어를 떠올려 에이전트에게 만들라고 시키려면 그 상상력이 있어야 합니다. 그리고 그것을 검증하려면 전문성이 있어야 합니다. 그래서 검증은 바닥이고 상상력은 천장입니다.
저는 음악을 하는데, 곧 나올 앨범 사이트를 준비하면서 홈페이지 일부를 상호작용이 되는 3D 오브젝트로 채우고 싶었던 기억이 있습니다. 그것들이 경험의 일부가 되도록 말입니다. 3D CD 플레이어 같은 것들이었고, 바이닐 레코드 플레이어도 넣었던 것 같고, 어쩌면 테이프 플레이어까지, 90년대 향수를 담은 물건들이었습니다. 그런데 처음 버전들은 보기에 훌륭하지 않았던 것은 물론이고, 올바른 상호작용 패턴을 따르지도 않았습니다. 모바일에서는 성능도 좋지 않았습니다. 그래서 저는 먼저 이게 어딘가 버그가 있다는 걸 알아챌 전문성이 있어야 했습니다. 어쩌면 어떤 사용자든 알아챘을 수도 있습니다. 하지만 그다음에는 왜 그런지에 대한 가설이 있었습니다. 그러면 제가 직접 프로파일링하거나 에이전트에게 프로파일링을 시켜서 무슨 일이 있었고 무엇이 잘못됐는지 알아낼 수 있었습니다. 어쩌면 상호작용 로직을 작성한 방식이 그냥 좋지 않았을 수도 있습니다. 그래서 상상력은 정말 중요하지만, 전문성도 마찬가지로 중요하다고 생각합니다. 이 두 가지가 다 중요합니다. 떠올릴 수 있다면, 만들 수 있습니다.
다음 세대에게도 이 전문성이 필요할까요?
에이전트가 이런 작업들을 점점 더 잘 해낸다면 사람이 그 전문성을 쌓아야 하느냐는 질문은 타당합니다. 다음 세대가 이런 특이한 영역에서 전문성을 쌓아야 할까요? 적어도 오늘 기준으로는, 에이전트가 완벽하게 해내지 못해서 그 작업을 사람이 확인해야 하는 지점에서 전문성이 여전히 유용하다고 생각합니다. 특정 루프나 애니메이션, 스케줄링 루틴 같은 것을 최적화해 달라고 요청했을 때, 다른 무언가를 희생해서 그걸 해내는 경우가 있습니다. 무엇을 짚어봐야 할지 모르거나, 구현을 읽고 무엇이 이뤄졌는지 이해하지 못하면, 원하는 대로 동작하지 않는 것을 출시하게 될 수 있습니다.
스킬과 MCP는 유용한 작업 흐름을 담아 둘 수 있습니다. 하지만 그 전제가 더 이상 자기 시스템에 맞지 않게 된 순간을 알려 주지는 못합니다.
약 40만 건의 클로드 코드 세션을 살펴본 앤트로픽 연구는 전문성을 작업별로 달라지는 것으로 봤습니다. 그리고 하려는 작업에 대해 중급 수준의 전문성만 갖고 있어도, 조금 더 초보인 사람보다 검증된 성공에 도달할 확률이 높아진다는 것을 발견했습니다. 스택 전반에 걸쳐 10년 경력이 있어야 한다는 뜻은 아닙니다. 다만 좋다는 게 무엇인지 알아볼 수 있을 만큼 문제 영역을 이해해야 한다는 뜻입니다. 요즘 우리는 이걸 안목이라는 말로 이야기하기도 하고, 저도 전에 이에 대해 쓴 적이 있습니다. 클로드 코드 베스트 프랙티스 가이드를 읽으면서 첫 부분이 검증 이야기로 시작하는 것을 보고 무척 반가웠던 이유도 여기에 있습니다. 테스트, 스크린샷 활용, 그 밖에 에이전트가 계속 맞춰 가며 반복할 수 있는 신호들, 그리고 작업이 끝났다는 간단한 요약 대신 사람이 검토할 수 있는 증거를 주는 것들입니다. 전문성이 있으면, 전문성은 많지 않지만 그럭저럭 괜찮아 보이는 것을 만들어 낼 수 있는 사람보다 훨씬 잘 점토를 빚을 수 있습니다.
그리고 이 모든 것은 결국 작업을 검증하고 에이전트의 결과물을 판단할 수 있는 전문성을 갖추는 문제로 돌아옵니다. 그래서 소프트웨어를 만드는 데 쓰는 추상화 수준이 계속 올라가더라도, 우리가 숙련과 장인정신에 계속 투자할 수 있기를 바랍니다.
전문성의 수익률은 올라가고 있습니다
소프트웨어 엔지니어링의 기본기는 계속 중요할 것 같습니다. 전문성도 계속 중요할 것입니다. 그리고 바닥이 올라간 지금, AI는 사람들이 가진 기술과 전문성의 수익률도 함께 높이고 있습니다. 주니어인 사람은 실제로 무언가를 출시하고 실수하고 배우고 반복 훈련을 쌓으면서 주니어에서 벗어납니다. 전문가는 무엇을 만들어야 하는지, 그것을 어떻게 검증하는지, 이게 괜찮은 상태인지, 깨지지 않았는지, 유지보수할 수 있는지, 확장될지, 서로 다른 환경이나 플랫폼에서도 동작할지 어떻게 확인하는지에 대한 직관이 있습니다. 특히 이제는 아주 많은 사람이 프롬프트만으로 아이디어를 현실로 만들 수 있게 됐기 때문에, 그것을 품질 높고 출시할 만하게, 쓰는 사람이 즐겁고, 유지보수할 수 있고, 프로덕션에서 깨지지 않게 만드는 기술이 계속 중요할 것입니다.
저는 최소한 매주 몇 번씩 이런 일을 겪습니다. 이제는 어떤 앱이든 어떤 기능이든 프롬프트로 만들어 내기가 너무 쉽습니다. 예를 들어 저는 지금 텍스트 에디터를 만들고 있는데, 처음부터 다 짜는 건 아닙니다. 문법을 더 좋게 다듬을 여지를 짚어 주거나 AI 같은 문체를 쓰지 않도록 알려 주는, 일종의 글쓰기 보조 도구를 만들려는 아이디어입니다. 프런티어 모델은 여러 번 주고받은 끝에 괜찮고 보기 나쁘지 않은 UI를 만들어 줬습니다. 훌륭하지는 않았습니다. 그리고 문제도 여러 가지 있었습니다. 화면 공간을 최적으로 쓰지 못했고, 색 대비가 좋지 않았고, 스크롤 방식도 좋지 않았습니다. 이 모든 건 제가 전에 같은 실수를 해 보면서 전문성을 쌓았기 때문에 아는 것들입니다. 하지만 그 전문성이 없다면 그냥 프롬프트로 만들어서 세상에 내놓고 거기서 멈출 수도 있습니다. 무엇이 더 나은지 모르는 것입니다. 그 전문성을 쌓는 데 시간을 들이지 않았기 때문입니다.
다음 에이전트가 찾을 수 있는 곳에 교훈을 남기세요
제가 멘토링하는 사람들에게 하는 말 중 하나는, 에이전트와 일할 때 여러분이 에이전트를 더 좋게 만들어야 하고 에이전트도 여러분을 더 좋게 만들어야 한다는 것입니다. 그 말은 매일 어떤 형태로든 순환이 있어야 한다는 뜻입니다. 교훈이나 메모리 같은 곳에 뭔가가 추가되어 에이전트가 나아질 수 있어야 합니다. 그렇지 않으면 새 세션을 시작할 때마다 기억을 잃은 신입을 다시 온보딩하는 것처럼 느껴질 수 있습니다. 그 신입은 우리 비즈니스와 제품, 팀, 사용자의 미묘한 사정을 기억하지 못할 것입니다. 그래서 우리는 스킬뿐 아니라 컨텍스트, 그리고 에이전트에게 주려는 온갖 것에 그렇게 많은 것을 담아 두게 됩니다. 그리고 실제로 유용하고 실제로 문제에 딱 맞는 것과, 그냥 우리가 상황을 더 좋게 만든다고 믿는 것을 구분하는 데 신중해야 합니다. 그래서 저는 늘 이렇게 살펴보라고 권합니다. 어떻게 하면 에이전트를 더 많이 가르치면서, 매일 에이전트도 나아지고 자신도 나아지게 만들 수 있을까요?
채팅 창에서 어떤 문제를 풀고 있다고 해 봅시다. 예를 들어 작업 중인 UI 컴포넌트에서 미묘한 스크롤 버그를 발견했다고 하겠습니다. 에이전트와 여러 번 주고받으며 작업하다 보면 그 안에 나중에 쓸 수 있는 교훈이 어딘가 들어 있습니다. 그 교훈은 메모리에 추가될 수도 있고, 안 될 수도 있습니다. 특히 컨텍스트 압축이 일어나는 긴 세션이라면 그 교훈이 온전히 들어가지 않을 수도 있습니다. 그러면 채팅 창이 닫히는 순간 그 교훈은 사라질 수 있습니다. 반면 구체적인 교훈이나 테스트, 린트 규칙처럼, 특히 저장소 안에 담아 둘 수 있을 만큼 작은 형태로 정리해 두면 앞으로의 에이전트를 가르칠 수 있습니다. 저는 개인적으로 이게 아주 도움이 됐습니다. 교훈을 하나 얻으면 몇 분 시간을 들여 살펴봅니다. 이걸 lessons.md에 추가할 만한가, 아니면 에이전트에게 메모리에 넣으라고 할 만한가, 아니면 어떻게든 남아 있게 만들 만한가 하고 말입니다. 저는 교훈이 사라지는 걸 원하지 않기 때문입니다. 저 자신은 잊어버릴 것이고, 다음 문제로 넘어갈 것입니다. 이건 제게 늘 일어나는 일입니다. UI를 다루는 방식에 대한 특정한 취향부터, 컴포넌트를 작성하는 방식, 성능을 다루는 방식까지 온갖 것이 여기에 해당합니다. 그리고 어떤 문제를 다루는 미묘한 방식이 있다면, 매번 그걸 다시 설명하지 않아도 되도록 에이전트가 그걸 기억하거나 기억할 방법을 갖고 있기를 바랍니다.
우리는 에이전트가 우리가 하는 모든 것을 기억할 존재처럼 대하는 일이 잦지만, 실제로는 그렇지 않습니다. 에이전트에 메모리 시스템이 있어도, 배우려 했던 흥미로운 것들이나 자신이 일하기 좋아하는 방식, 검증하는 방식을 전부 떠올려 줄 것이라고 온전히 믿을 수는 없습니다. 그래서 이런 것들을 마크다운 파일에 더 많이 담기 시작해도 괜찮습니다. 다만 그것을 전략으로 삼아 과하게 투자하지 않도록 아주, 아주 조심해야 합니다. 저는 이중 순환이라는 개념을 늘 좋아했습니다. 배움이 있는 좋은 반복 훈련은 자신을 날카롭게 만들어야 하고, 자기 에이전트도 날카롭게 만들어야 합니다. 그리고 어떤 가설이 바로잡혔다면, 그 교정이 린트 규칙이나 타입 제약, 문서 규칙, 테스트가 될 만한지 따져 봅니다. 그래야 그게 계속 남아서 나중에 도움이 됩니다.
바깥 루프
이 모든 것이 숙련과 관련해 뜻하는 바는 이렇다고 생각합니다. 자신의 전문성과 장인정신에 투자하십시오. 반복 훈련을 하고, 실수하고, 거기서 배우십시오. 시간이 지나면 무엇이 존재할 가치가 있는지 알아낼 수 있게 됩니다. 계획을 쓰고, 계획을 다듬고, 완료가 무엇을 뜻하는지 정의하고, 정확성과 안전, 사용자 영향을 사람이 계속 확인해야 하는 지점을 미리 설계할 수 있게 됩니다. 오늘 엔지니어가 맡아야 할 바깥 루프는 대체로 그것이라고 생각합니다. AI는 앞으로도 엔지니어링을 추상화 계층 위로 계속 밀어 올릴 것입니다. 그리고 제가 돌릴 수 있는 에이전트가 많아질수록, 한정된 시간과 안목, 판단력을 어디에 쓸지 더 신중하게 골라야 합니다.