코딩 에이전트 시대에 엔지니어의 역할과 필요성에 대한 고찰

서론

최근 골든 위크(GW)에 꽤 긴 휴가를 얻게 되어, 화제가 되고 있는 코딩 에이전트(Coding Agent)를 시험해 보고자 Codex와 Claude Code, GitHub Copilot을 사용하여 학생 시절부터 구상해 왔던 커뮤니티 기반 SNS를 만들어 보았습니다.

만들어 보면서 놀랐던 점은 코딩 에이전트의 성능이 매우 높다는 것이었습니다.

코딩 에이전트가 트렌드가 되기 시작한 1년 전쯤에는 솔직히 코드 품질이 그리 높지 않아, 스스로 코드를 수정해야 하는 경우가 많았습니다.

하지만 최근의 코딩 에이전트는 코드 품질이 매우 높아져서, 코드를 크게 수정할 필요가 거의 없었습니다.

1년 만에 이 정도로 성능이 향상될 것이라고는 생각하지 못했기에 매우 놀랐습니다.

그래서 궁금해진 점은, 코딩 에이전트의 성능이 이토록 향상된 지금, 엔지니어가 과연 필요한가 하는 점입니다.

코딩 에이전트는 코드를 작성할 수 있을 뿐만 아니라 코드 품질도 높아지고 있기 때문에, 엔지니어가 코드를 작성할 필요가 없어지는 것이 아닌가 하는 생각이 들기 시작했습니다.

이 기사에서는 코딩 에이전트의 성능 향상과 그것이 엔지니어의 역할에 어떤 영향을 미칠지에 대해 생각해 보고자 합니다.

우선 「코드를 작성하는 사람」은 상당히 대체될 것이다

먼저 결론에 가까운 내용을 쓰자면, 단순히 「사양을 전달받아 코드를 작성하는 사람」으로서의 엔지니어 가치는 상당히 낮아질 것이라고 생각합니다.

예를 들어, 화면을 하나 추가하거나, API 엔드포인트(Endpoint)를 만들거나, 기존 컴포넌트(Component)에 약간의 상태(State)를 추가하거나, 테스트를 작성하는 등의 작업은 이미 코딩 에이전트가 상당히 높은 정밀도로 해낼 수 있습니다.

물론 완벽하지는 않습니다.

설계 의도를 오해하거나, 기존 문맥(Context)에 맞지 않는 구현을 하거나, 미묘하게 작동하지 않는 코드를 작성할 때도 있습니다.

하지만 그럼에도 「제로 베이스에서 스스로 작성하는 것」보다 명백히 빠른 상황이 늘어났습니다.

특히 기존 코드를 읽게 한 뒤 작은 변경을 요청하면, 인간이 작업하는 것보다 훨씬 짧은 시간 안에 제법 그럴싸한 구현을 내놓습니다.

이 변화는 상당히 큽니다.

지금까지는 구현력 그 자체가 엔지니어의 핵심적인 가치였습니다.

하지만 구현의 일부가 기계로 넘어가게 되면, 엔지니어의 가치는 「직접 손을 움직여 코드를 작성하는 것」에서 「무엇을 만들 것인지 결정하고, 나온 결과물이 올바른지 판단하는 것」으로 옮겨가게 됩니다.

그럼에도 엔지니어가 불필요해지리라고는 생각하지 않는다

한편으로는, 코딩 에이전트를 사용하면 사용할수록 현시점에서는 아직 엔지니어가 필요하다고 느꼈습니다.

구현 속도가 빠르고 코드 품질도 높다 하더라도, 그것이 가능한 이유는 처음에 아키텍처(Architecture) 방침을 전달받았기 때문이라고 생각합니다.

코딩 에이전트는 지시받은 것을 구현하는 데 특화되어 있습니다.

하지만 그 지시가 애초에 올바른지, 프로덕트(Product)로서 정말 필요한지, 현재의 설계에 얹어야 하는 것인지, 나중에 운용할 수 있는 형태인지와 같은 판단은 여전히 인간 측에 상당히 많이 남아 있습니다.

이번에도 제 안에 처음부터 아키텍처 방침이 있었고, 그것을 처음에 전달했기에 거의 상상했던 형태대로 코딩해 주었습니다.

나중에 제가 직접 읽을 수 있는 형태였기에 리뷰(Review)도 하기 쉬웠습니다.

반대로 아키텍처가 모호한 채로 진행하면, 개발 후반부에 수정량이 늘어나거나 최악의 경우 데그레(Degre, 퇴보), 즉 수정으로 인해 기존 기능이 망가지는 상태를 반복하게 될 가능성도 있습니다.

또한 설계가 정리되어 있지 않으면 변경할 때마다 프로젝트의 넓은 범위를 살펴봐야 하게 됩니다.

그렇게 되면 에이전트에게 읽혀야 할 문맥(Context)도 늘어나고, 토큰(Token) 소비량도 늘어난다고 느꼈습니다.

코딩 에이전트 시대에서도 처음에 어디까지 구조를 결정할 수 있는지가 상당히 중요하다고 느꼈습니다.

예를 들어, 이번에 SNS를 만들면서도 에이전트에게 맡기기 쉬운 작업과 맡기기 어려운 작업이 있었습니다.

• UI 컴포넌트 추가
• 유효성 검사(Validation) 구현
• API 호출 연결
• 테스트 케이스 추가
• 타입 에러나 Lint 에러 수정

이러한 작업은 상당히 맡기기 쉽습니다.

반면 다음과 같은 일은 아직 인간이 주의 깊게 살펴볼 필요가 있다고 느꼈습니다.

• 애초에 그 기능을 만들어야 하는가
• 데이터 모델(Data Model)을 어떻게 나누어야 하는가
• 권한이나 프라이버시를 어디까지 엄격하게 다루어야 하는가
• 사용자 경험(UX)으로서 자연스러운가
• 향후의 변경에 견딜 수 있는 설계인가
• 보안상의 허점은 없는가

특히 신경 쓰였던 점은 사양(Specification)의 세밀한 정합성입니다.

이번 사례를 들자면, 인가(Authorization) 구현 과정에서 프론트엔드(Front-end)와 백엔드(Back-end) 사이에 미묘한 불일치가 발생하는 일이 있었습니다.

인가는 단순히 "화면에서 버튼을 노출하지 않는 것"만으로는 불충분하며, 최종적으로는 백엔드 측에서도 올바르게 제어되어야 합니다.

이러한 부분은 세부 사양을 통째로 맡겨버리는 것이 아니라, 어디서 무엇을 보장할 것인지를 인간이 명확하게 해두는 것이 좋아 보입니다.

이 지점을 모호하게 둔 채 에이전트(Agent)에게 구현을 의뢰하면, 겉보기에는 작동하는 결과물이 만들어져 버립니다.

오히려 작동해 버리는 것이 문제입니다.

언뜻 보기에는 완성된 것처럼 보이기 때문에, 설계의 왜곡이나 운영상의 리스크를 알아차리기 어려워집니다.

중요해지는 것은 「쓰는 능력」보다 「읽는 능력"

코딩 에이전트(Coding Agent) 시대에 중요해질 능력 중 하나는 읽는 능력이라고 생각합니다.

여기서 말하는 읽는 능력은 단순히 코드를 눈으로 쫓을 수 있다는 의미가 아닙니다.

나온 코드를 보고 다음과 같은 관점에서 판단할 수 있는 능력입니다.

• 왜 이렇게 구현되었는가
• 어떤 처리를 하고 있는가
• 다른 효율적인 작성 방식은 없는가
• 기존 설계와 정합성을 이루는가
• 불필요하게 복잡한 구현이 되지는 않았는가
• 에러 케이스(Error Case)가 처리되었는가
• 테스트해야 할 경계 조건(Boundary Condition)이 반영되었는가
• 운영 환경에서 문제가 될 만한 부분이 없는가
• 해당 변경 사항이 프로덕트의 목적에 부합하는가

이것들을 판단하기 위해서는 결국 엔지니어링의 기초 체력이 필요합니다.

코드를 쓸 줄 모르는 사람이 코드의 좋고 나쁨을 안정적으로 판단하기는 어렵습니다.

설계를 해본 적이 없는 사람이 설계의 미흡함을 간파하는 것도 어렵습니다.

따라서 앞으로는 「코드를 쓸 수 있다는 것」 자체의 가치는 상대적으로 낮아질지도 모릅니다.

적어도 단순히 구현만 하는 가치는 분명히 낮아질 것이라고 생각합니다.

반면, 「코드를 이해하고, 설계를 평가하며, 리스크를 간파하는 것」의 가치는 오히려 높아지지 않을까요?

쓰는 능력보다 읽는 능력의 비중이 커진다.

이번에 코딩 에이전트를 사용해 보면서 가장 일하는 방식이 변할 것 같다고 느낀 점이 바로 이 부분이었습니다.

코딩 에이전트는 주니어 엔지니어가 아니라, 빠른 구현자에 가깝다

코딩 에이전트를 사용하기 전에는 막연히 "우수한 주니어 엔지니어가 옆에 있는" 듯한 모습을 상상했습니다.

하지만 실제로 사용해 보니 조금 달랐습니다.

주니어 엔지니어라면 구현 도중에 의문을 갖거나, 사양의 모호함을 질문하거나, 경험을 통해 팀의 맥락을 배워 나갑니다.

반면, 코딩 에이전트는 기본적으로 주어진 지시와 보이는 코드로부터 가장 그럴듯한 구현을 고속으로 내놓는 존재입니다.

즉, 육성 대상이라기보다는 매우 빠른 구현자로 취급하는 것이 더 가깝다고 느꼈습니다.

빠른 구현자이기에 지시가 좋으면 상당히 좋은 성과를 냅니다.

반대로 지시가 허술하거나 전제가 틀렸다면, 그 잘못된 점까지 포함하여 고속으로 형태를 만들어 버립니다.

이러한 성질을 고려하면 에이전트를 능숙하게 다루기 위해서는 자연어로 세밀하게 명령하는 능력만으로는 불충분합니다.

오히려 태스크(Task)를 적절한 입도(Granularity)로 나누는 능력, 전제 조건을 명확히 하는 능력, 완료 조건(Definition of Done)을 정의하는 능력이 중요해집니다.

앞으로의 엔지니어에게 필요할 것 같은 것들

그렇다면 코딩 에이전트 시대에 엔지니어는 무엇을 키워야 할까요?

개인적으로는 다음의 5가지가 특히 중요해질 것이라고 생각합니다.

1. 문제를 정의하는 능력

무엇을 만드는가보다 왜 그것을 만드는가를 언어화하는 능력입니다.

에이전트는 구현안을 제시할 수는 있지만, 프로덕트 상의 과제를 스스로 찾아주지는 않습니다.

사용자가 무엇 때문에 곤란해하는지, 어떤 제약 조건 안에서 풀어야 하는지, 지금 해야 할 일인지.

이러한 부분들을 정리할 수 있는 사람의 가치는 앞으로도 계속 유지될 것이라고 생각합니다.

2. 설계하는 능력

에이전트는 국소적인 구현에는 강하지만, 시스템 전체의 정합성을 장기적으로 유지하는 것은 아직 서툽니다.

책임의 분리, 데이터의 흐름, 인가의 경계, 테스트 용이성, 향후의 변경 여지.

이러한 설계상의 판단을 인간이 쥐고 있지 않으면, 에이전트가 만든 코드가 쌓여 나중에 다루기 힘든 시스템이 되어 버립니다.

3. 검증하는 능력

에이전트가 내놓은 코드는 작동할 것처럼 보입니다.

하지만 작동할 것처럼 보이는 것과 올바르게 작동하는 것은 다릅니다.

테스트를 작성하고, 로그를 확인하고, 에러 케이스를 시도하고, 보안 관점에서 확인하는 것.

이러한 번거로운 검증을 생략하면 에이전트의 생산성은 쉽게 부채(Debt)로 변합니다.

4. 맡기는 방식을 설계하는 능력

에이전트(Agent)에게 너무 큰 태스크(Task)를 통째로 맡겨버리면, 의도와 다른 결과가 돌아오는 경우가 많습니다.

반대로, 적절한 크기로 나누고 전제 조건과 완료 조건(Definition of Done)을 명확히 하면, 상당히 안정적으로 성과를 내줍니다.

이는 단순한 프롬프트 기술(Prompt Engineering)이 아니라, 업무를 분해하는 능력 그 자체입니다.

무엇을 인간이 결정하고, 무엇을 에이전트에게 맡기며, 어디에서 검증할 것인가.

이 분담을 설계할 수 있는지 여부에 따라 생산성은 크게 달라진다고 느꼈습니다.

5. 기술적으로 이해한 상태에서 사용하는 능력

주니어 엔지니어(Junior Engineer)나 미경험자에게 코딩 에이전트는 오히려 기회라고 생각합니다.

어려운 기술을 처음부터 모두 이해하지 못하더라도, 앱을 만들 수 있는 시대가 되어가고 있기 때문입니다.

하지만 기술적인 이해가 불필요해지는 것은 아닙니다.

자신도 어떻게 돌아가는지 모르는 것을 고객에게 제공하는 것은 위험합니다.

특히 보안(Security)이나 인가(Authorization) 관련 부분은, 단순히 동작하는 것처럼 보이는 것만으로는 불충분합니다.

에이전트의 도움을 받으며 만드는 것 자체는 매우 좋은 학습 방법이라고 생각합니다.

다만, 그 결과를 읽고 자신의 언어로 설명할 수 있는 단계까지 나아가야 합니다.

만들 수 있는 것과, 책임을 지고 제공할 수 있는 것은 별개의 문제입니다.

요약

코딩 에이전트에 의해 엔지니어의 업무는 상당히 변할 것이라고 생각합니다.

특히, 시키는 대로 그대로 구현만 하는 업무는 앞으로 상당히 어려워질 것입니다.

하지만 그것이 엔지니어가 불필요해진다는 의미는 아닙니다.

현시점에서는 초기 아키텍처(Architecture)를 결정하고, 사양(Specification)의 정합성을 담보하며, 구현 결과를 해석하여 프로덕트(Product)로서 성립하는 형태로 다듬는 역할은 이전보다 더욱 중요해질 것이라고 느낍니다.

코딩 에이전트는 잘 사용하면 굉장히 강력한 도구입니다.

그러나 도구가 강력해질수록, 그것을 사용하는 측의 판단력도 요구됩니다.

만약 초기 아키텍처 결정까지 AI가 인간보다 더 잘할 수 있는 시대가 온다면, 그때는 인간의 역할이 더욱 변할 것이라고 생각합니다.

어쩌면 인간은 아이디어를 내는 존재에 가까워질지도 모릅니다.

앞으로의 엔지니어는 코드를 쓰는 사람이라기보다, 소프트웨어를 성립시키는 사람에 가까워질지도 모릅니다.