새로운 엔지니어링
바이브 코딩을 넘어 에이전틱 엔지니어링이라고 불리고 있는 새로운 방법론에 대한 글이다.
최근 3주 동안 클로드 코드를 틈나는 대로 열심히 써보았다.
나름대로 몇 가지 결론을 냈다.
- 앞으로 사람이 직접 코드를 타이핑할 일도, 수정할 일도 없다.
- AI가 모든 것을 다 해주는 것 같아도 여전히 엔지니어링이다.
- 기존의 엔지니어링보다 훨씬 추상적이기에 아예 다른 엔지니어링이다.
앞으로 사람이 직접 코드를 타이핑할 일도, 수정할 일도 없다.
내가 지금까지 살아오면서 쌓아온 하드 스킬 중에 최소 50% 이상은 무용지물이 되었다. 아까워하지 말고 빨리 다 털고, 새로 생긴 공간에 새로운 스킬을 집어넣어야 한다.
26년에 생긴 이 변화는 급작스럽지 않다. 2012년부터 AI의 발전은 로그 스케일에서 선형적으로 증가하고 있었고, 26년에 내 수준을 넘었을 뿐이다. 아무리 제프 딘이어도 길어야 1년 남짓이지 않을까 생각한다. 내 수준을 넘음으로서 내가 해야 할 일이 보다 명확해졌다.
“언러닝”이다. 25살 즈음 이 개념을 처음 접했다. 20대 초중반은 소프트웨어 개발을 조금씩 알아가던 때였다. 분야 자체가 오래 되지 않았고, 기존의 개발 방식보다 더 쉬워지고 추상화되고 생산성이 증폭되고 있을 시기였기에 이 분야에서 빨리 달려서 무언가를 이뤄내보고 싶었다. Django, React, fastAPI 등 새로운 프레임워크들이 나오면서 과거에 C++로 코딩하던 코딩 고수들보다 더 많은 것을 만들어내기가 쉬워졌다. 새로운 언어, 새로운 프레임워크를 인정하고 넘어오고 기존의 것을 내려놓은 사람들은 훨씬 더 잘했을 것이고, 그렇지 않고 여전히 C++을 고집하면 생산성 측면에서 유지하기가 어려웠을 것이라 생각한다. (물론 C++이 여전히 지금 임팩트를 낼 수 있는 곳들이 많고 하나의 예시일 뿐이다.) 이런 생각들을 가지고 25살 때 언러닝이라는 개념을 접했을 때 새로웠다. 나도 언젠가 30살이 될 것이고, 내가 지금 하고 있는 방식들이 머지 않아 고대 유물이 될 수 있다는 점을 인지하게 되었다. 언러닝을 해야 할 날이 오면, 과감히 다 버려보자! 라고 생각했다. 과거의 것을 고집하는 사람들을 보며 왜 과거의 것을 포기 못하지라는 생각도 했다.
그리고 지금이 되니까 언러닝이 참 쉽진 않구나 싶다. C++ 정도 레벨에서의 코딩을 한 건 1년 정도고 고3부터 지금까지 java, js, python, go 등 고수준 언어만을 사용해왔고 또 그 위에 추상화된 프레임워크 위에서 10년을 보냈다. 그 이전 시절과 비교하면 엄청나게 편리하지만, 내 한 26살까지는 하드 스킬 익히느라 정신 없었다. 쉽고 편리해진 만큼 세상에서 엔지니어로서의 경쟁력, 내가 만든 코드의 경쟁력, 제품의 경쟁력을 갖기 위해서는 여전히 심오한 세계를 알아야만 했다. 디자인 패턴, 아키텍처, 통신 등등 일하고 저녁이나 주말엔 공부하곤 했었다. (고등학교 친구들이랑 매주 일요일 오전 10시에 강남 투썸에서 스터디도 했었다. 그것도 벌써 4-5년 전이군…) 아쉽게 됐다. 거의 다 필요가 없어졌다! 물론 엔지니어링 철학적인 측면이나 기초를 탄탄하게 알고 있다는 측면에서 나쁠 건 전혀 없지만, 이제 AI가 짠 코드를 읽어보지도 않는 세상에서 분명 필요 없어진 지식들이 많다. 이런저런 얘기들을 했는데 결국 이제는 다 놔줘야 할 때라는 걸 인지하고 수행하는 것이 쉽진 않다라고 요약할 수 있겠다.
지금의 AI는 참으로 놀랍다. 모델 능력, 에이전트 능력 2개가 같이 향상되어 이런 결과를 만들어냈고, 이런 세상을 만들어낸 데에 기여한 모든 사람들이 존경스럽다. 코덱스는 작년에 조금만 써보고 올해 클로드 코드 위주로만 써봤는데 Opus 4.6이 참 잘하고, 클로드 코드로 만드는 서비스에선 Gemini 3.1 Pro를 써봤는데 이 친구도 참 잘한다. GPT-5.3까지도 비슷하다고 사람들이 이야기하는 것을 보면 구글, 앤트로픽, OpenAI가 거의 비슷하게 가고 있는 것 같다. 이 탑 프론티어 급들만 한정지어 얘기하면 코드 레벨에서 수많은 객체지향 설계 철학들을 나보다 훨씬 더 잘 지키고 더 좋은 시스템과 코드를 짠다. 이 뜻은 내가 직접 짜면 짤수록 서비스의 품질이 낮아진다는 뜻이다.
결심했다. 이제 나는 코드 타이핑하지 않기로! (물론 군대 일은 AI 없이 코딩하는거라 이건 코드쳐야 하긴 한다.)
AI가 모든 것을 다 해주는 것 같아도 여전히 엔지니어링이다.
AI가 만능 같았지만 한 순간이었고 오히려 더 어려워졌다. 한 차원 더 추상화되는 순간 꿈꿀 수 있는 영역이 한 차원 더 확장되면서 자유도는 올라가고 난이도는 더 높아진다. 예전과 같은 것을 만들고자 하면 더할 나위 없이 쉽겠지만 도구가 강력해지는 것보다 꿈은 더 대담해지기 마련이다.
내가 이번에 만들고자 했던 것은 Mech Delusioner (가칭)으로, 내가 만들고 싶은 목표를 이야기하면 해당 메커니즘을 만들어주는 서비스였다. Text to 3D는 많지만 Text to Mechanism은 없다. 정말 간단하게는 ”Geneva Wheel을 설계해줘.“부터, ”책을 넘길 수 있는 메커니즘을 설계해줘“처럼 복잡한 메커니즘까지 모두 커버하고 싶었다. 설계하는 서비스는 금방 짰으나 아무리 봐도 실제로 동작 가능한 메커니즘이 아니었다. AI가 스스로 검증을 못하기 때문이라고 생각하고 3D 시뮬레이션 상에서 테스트를 해보게 시켰으나 이미지 캡처본으로 이 서비스를 이해하는 AI에게 시뮬레이션 상에서의 문제를 해결할 수 있는 능력이 없었다. 어떻게든 시뮬레이션 상에서의 문제를 serializable하게 표현해보려 했으나 쉽지 않았고, 또한 AI가 여러 번 시도하다가 안되면 테스트 자체를 바꿔버려서 혼자 통과해버렸다.
이런 서비스가 세상에 없다. AI가 없었으면 내가 이걸 직접 할 생각하긴 쉽지 않았을 것이다. AI 때문에 더 과감한 꿈을 꾸었으나 쉽게 현실로 변환되지는 않았다.
지금 느끼는 것은 이 새로운 형태의 개발 역시 엔지니어링이라는 점이다. 내가 생각을 깊게 안 했다. 적당히 생각나는대로 쭉 쓰고 나머지는 AI가 알아서 잘 딱 개발해주리라 믿었다. 플랜 나오면 몇 줄 읽어보고 괜찮은 듯? 하고 엔터쳤다. 내가 정확히 무엇을 원하는지 구체화해야 하고, 그것을 잘 표현해야 하며, AI가 헤매거나 방향이 마음에 들지 않는다면 내가 잡아줘야 한다.
결국 엔지니어링이다. 문제를 명확하게 정의해야 하고, 수많은 트레이드오프 중에 선택해야 하며, 최적화해야 하고, 시스템을 설계해야 한다. 다만 엔지니어링 중 제일 낮은 레벨에 있었던 코드 타이핑, 코드 디자인 등만 없어졌을 뿐이다. 사실 지난 몇 년도 그랬다. 어려운 건 우리가 뭘 모르는지 알아내는 것, 문제 정의, 의사결정 등이었지 코딩 자체는 시간이 필요할 뿐 어렵진 않았다. 제일 아래에 있던 것부터 하나씩 없어질 것이고 그에 맞게 우리는 엔지니어링의 형태를 유지하며 한 계단씩 위로 올라나가야 할 것이다.
기존의 엔지니어링보다 훨씬 추상적이기에 아예 다른 엔지니어링이다.
내가 느끼기에 여전히 엔지니어링이지만 접근 방법은 엔지니어보다 리더에 더 가깝다. 목표를 명확하게 부여하고, 진행 상황을 틈틈히 팔로업하고, 어느 정도 헤매는 것은 믿고 기다려주기도 하고, 일하기 좋은 환경을 만들어주는 것이다.
답답하다고 절대 직접 일하면 안된다. 여러가지가 문제가 된다. 나보다 AI의 고점이 훨씬 높기에 (앞으로 AI는 더빠르게 높아질거기에) AI와 함께 일하는 법을 터득해야만 한다. 정답을 알려주지 말고 스스로 찾을 수 있도록 해야 한다. 그렇지 않으면 비슷한 문제가 발생했을 때 매번 내가 직접 답을 찾으려 하게 된다.
충분한 시간을 주어야 한다. 아예 이상한 방향으로 가는 것이 아니라면, 여유를 갖고 스스로 정답을 찾길 기다려야 한다. 모든 사람이 그렇듯 코딩하고 한번에 컴파일이 될 수 없고, 한번에 테스트를 통과할 수 없다. 이터레이션을 돌며 점점 고도화해나가는 것이 올바른 방법이다. 사람한테도 어느 정도의 시간을 부여하듯, trial and error를 할 수 있는 시간을 주자.
목표를 명확하게 부여하자. 나도 그렇지만 AI와 함께 일하는 사람들 중 아 왜 이렇게 알잘딱하지 못하지? 답답해하던 경험이 분명 많이 있을 것이다. 반대로 생각해보자. 사람은 얼마나 알잘딱한가? 여러 명의 팀원을 이끌며 리딩을 하다 보면 아 왜 이렇게 내 뜻을 제대로 이해못하지? 라고 생각하는 경우가 생기는데 100이면 99 이상은 내가 충분한 context를 제공하지 않고 불명확한 목표를 말했기 때문이다. 사람하고 일할 때도 흔히 말하는 OKR이라는 정량적인 목표를 세워서 이걸 달성하자! 라고 이야기하는데 AI한테 그냥 해줘! 해버리면 자기 생각에 이 정도면 할만큼 했다! 까지만 하게 된다. mesurable한 목표를 세우고 부여하자. 그것이 리더의 역할이다. 목표가 명확할 때 스스로 부족함을 인지하고 계속 이터레이션을 돌며 해당 수준까지 발전시키게 된다.
일하기 좋은 환경을 만들어주자. 개발자라면 맥북, 키보드, 마우스, 데스크, 의자 등이 필요할 것이다. 하나라도 없다면 당연히 생산성은 대폭 떨어진다. 크롬 브라우저는? VS Code는? 터미널은? python은? 설계한다면 Fusion360은? 전부 다 필요할 것이다. 환경을 잘 셋업해주자. 물론 필요한 환경을 스스로 구축할 수 있게끔 하는 것도 방법이다. 물론 그만큼 권한을 더 많이 부여해야 한다. 예시로 어느 정도의 돈을 쥐어줘야 될 수도 있다. 필요하다고 생각되면 SaaS 툴을 구독하게끔 할 수도 있고, 쿠팡으로 무언가 주문하게 할 수도 있다. 물리적 제품을 만든다면, 현실 세상에서 일할 수 있는 환경과 몸을 만들어줘야 할 것이다. AI가 일하는 것을 보면서 일함에 불편함이 없는지 생산성이 떨어지는 부분이 어디인지를 면밀히 체크하고 좋은 업무 환경을 만들어주자.
건설적인 피드백을 주자. 사람에게 하는 피드백은 꽤나 고민을 깊게 하고 그 본질을 꿰뚫는 정확한 피드백을 하기 위해 노력한다. 그러나 AI에게 하는 피드백은 1차원적인 피드백만 제공하고, 지금 당장의 문제에 대해서만 이야기하게 된다. 좀 더 메타적인 피드백을 주어 다음에 비슷한 상황이 생겼을 때 올바른 방법을 스스로 찾아나갈 수 있도록 하는 건설적인 피드백을 주자. 단순히 지금 당장의 문제만을 해결하는 피드백은 장기적으로 도움이 되기 어렵다.
나를 위해 일하는 에이전트를 매니징하는 것이 새로운 엔지니어링의 기초가 된다. 이 이후에는 효율적인 팀을 운용해야 한다. 1명의 에이전트에서, 2명의 에이전트로, 그리고 에이전트 팀으로 거듭나도록 해야 한다. 에이전트를 나눠야 하는 이유는 분명하다. 어떤 객체가 담을 수 있는 메모리와 스킬의 갯수는 유한하다. 또한 효율적으로 운용 가능한 메모리의 크기와 스킬의 갯수는 그보다 작다. 일정 범위 이상의 프로젝트를 하게 되면 반드시 에이전트 팀이 필요하게 된다.
역할을 부여하자. 역할이 없다면 팀 내에서 혼란이 생긴다. 명확한 역할 부여를 통해 각자의 책임을 분담하고, 한정적인 메모리와 스킬을 역할에 맞게 나눠가지도록 해야 한다. 새로운 에이전트를 채용해야 할 시점을 고민하자. 아무때나 아무렇게나 채용하면 현실에서 그렇듯이 프로젝트는 산으로 간다.
업무 문화를 만들자. 언제 어떻게 서로 소통해야 하는지 커뮤니케이션에 포커스를 맞춰 문화를 만들자. 처음부터 완벽한 문화를 만들 필요는 없다. 일하는 방식을 계속 보고 조금씩 조율하면 된다. 상황에 따라 서로 공유를 1일 단위로 할 수도 있고, 10분 단위로 할 수도 있다. 명시적인 미팅을 잡아 동기적으로 대화하게 할 수도 있고, 비동기적으로 스크럼만을 남기고 계속 각자 일하게 할 수도 있다. 상황에 맞춰 일하자.
마지막이다. 에이전트 팀까지 효율적으로 운용하는 것에 성공했다면, 에이전트 리더까지 키워야 한다.
리더십을 만들자. 지금까지 했던 모든 역할을 대신하여 에이전트가 수행하도록 하는 것이다. 지금까지의 여정에서 얻었던 모든 깨달음을 다 전수하고 에이전트 리더를 키우자. 건설적인 피드백을 주고, 일하는 환경을 만들어줄 수 있으며, 목표를 명확하게 부여하고, 업무 문화를 만들 수 있는 에이전트를 만드는 것이다.
이 모든 과정에서 코딩을 해야 할 이유는 전혀 없다. 이 모든 것은 자연어로 가능하다. 그러나 이는 대화가 아닌 엔지니어링이고 문제의 본질을 꿰뚫는 사고력과 자신만의 확고한 철학이 밑바탕되어야만 가능한 영역이다. 프로그래밍 언어 기반의 2000년대의 엔지니어링에서 25년이 지나 자연어 기반의 새로운 형태의 엔지니어링으로 인터페이스가 다 바뀌게 되었지만 본질만큼은 동일하다. 어떻게 보면 2000년대의 엔지니어 매니징이 현재의 새로운 형태의 엔지니어링이라고도 볼 수 있다. 2000년대 여러 사람들을 하나로 모아 위대한 결과를 만들었던 훌륭한 리더들처럼, 2026년 에이전트들을 하나로 모아 위대한 결과를 만들어내보자.
