GeekNews에 공유된 "2026년에 왜 코드를 작성하는가"를 보면, AI 코딩 에이전트가 보편화된 2026년에 소프트웨어 엔지니어가 여전히 코드를 직접 작성해야 하는 이유를 짚습니다. 단순히 "AI가 코드를 짜니까 사람은 다른 일을 해야 한다"가 아니라, 소프트웨어 팩토리의 운영자로서 코드를 읽고 만져야 하는 이유를 다섯 가지로 정리한 글이에요.
흥미로운 건 이 글이 "에이전트만 쓰면 된다"는 환상을 정면으로 부정한다는 점입니다. 저자는 성능이 낮은 모델도 잘 작동하는 인프라를 만드는 것이 엔지니어의 역할이지만, 그 인프라를 평가하고 개선하려면 결국 사람이 코드를 직접 다뤄야 한다고 강조합니다. AI가 짠 코드를 "검토만" 하는 자세를 경계하고, 직접 실행 환경에서 사고하는 습관이 여전히 중요하다는 메시지죠.
- 소프트웨어 엔지니어의 역할은 코드 생산을 넘어 소프트웨어 팩토리를 구축·유지하는 일로 확장됐지만, 시스템을 이해하고 개선하려면 여전히 직접 코드를 다룰 필요가 있음
- 프롬프트,
AGENTS.md, 지식 베이스로 에이전트를 안내하고 테스트, 린팅, 타입 시스템, 평가로 결과를 보호하면 성능이 낮은 모델도 충분히 쓸 만한 변경을 만들 수 있음 - 직접 코딩하면 영어를 거치지 않고 실행 환경에서 사고할 수 있어, 수동적인 코드 검토만으로 놓치기 쉬운 취약성·약한 테스트·불필요한 예외를 체감하게 됨
- 에이전트는 컴파일러보다 새로 합류한 인턴에 가까워 기존 코드와 부정확한 요구를 보수적으로 따르며, 인간의 일회성 실수까지 래핑과 간접 계층으로 확대할 수 있음
- 인간이 접근법을 직접 시험해 패턴을 정립하고 에이전트가 이를 반복하게 해야 소유감과 판단력을 유지하면서 자동화의 생산성을 활용할 수 있음
에이전트가 일하는 소프트웨어 팩토리
- 소프트웨어 엔지니어는 소프트웨어뿐 아니라 누구나 변경을 프롬프트로 요청하고 즉시 배포할 수 있게 하는 조립 라인도 유지함
- 프롬프트, 스킬,
AGENTS.md, 지식 베이스를 통해 에이전트가 성공할 수 있는 인프라를 선제적으로 구성함 - 테스트, 린팅, 타입 시스템, 평가, 다른 AI를 활용한 자동 평가로 결과를 사후에 보호함
- 충분한 제약과 최신 컨텍스트를 제공하면 지능이 낮은 모델도 경로를 벗어나지 않고 쓸 만한 변경을 만들 수 있어, 사람이 코드를 읽거나 직접 작성할 필요가 없어 보일 수 있음
- 그러나 Fable 수준의 지능을 가진 에이전트가 있더라도 직접 코딩은 영어라는 중간 계층 없이 실행 환경에서 직접 사고하게 해줌
- 에이전트가 만든 diff와 패치를 수동적으로 읽는 것만으로는 시스템 아키텍처와 깊이 연결되기 어려움
- 코드를 직접 다루면 그 위에 기능을 추가할 때 무엇이 깨지는지 체감할 수 있음
- 코드를 정리하고 여러 예외가 붙지 않는 일관된 아키텍처 원칙을 문서화하면 소프트웨어 팩토리도 더 안정적으로 작동함
- 디버깅 과정에서 테스트 전략의 약점을 찾아 고치면 새로운 종류의 버그 전체를 차단할 수 있음
- 직접 코딩만이 소프트웨어를 이해하는 유일한 방법은 아니며, 자화된 바늘과 흔들리지 않는 손처럼 극단적인 수작업을 고집할 필요도 없음
- 실제 코드의 대부분을 AI가 생성하더라도 직접 코딩은 여전히 유용한 도구로 남음
직접 코딩으로 지키는 사고력과 소유감
- 코드 읽기와 승인만 담당하는 역방향 켄타우로스 역할에 머물면 집중력과 소유감이 떨어지고, 저품질 코드가 검토를 통과하기 쉬우며 세밀한 조정도 어려워짐
- 세부 사항에 주의를 기울이지 않으면 취약성이 누적되고, 장기적으로는 저품질 코드가 에이전트에도 악영향을 줌
- 인간이 직접 접근법을 시험한 뒤 에이전트가 정립된 패턴을 반복하게 하면 결과에 계속 참여하고 소유할 수 있음
- 영어는 계산을 정밀하게 나타내기에는 명세가 부족한 언어임
- 알고리듬 작업에서는 실행 가능한 단계로 구상하고 사고할 필요가 있음
- 상황에 따라 설계 공간이 큰 저수준 언어나 계산 환경이 더 제한된 고수준 언어를 선택해 필요한 정밀도를 조절할 수 있음
- 코딩 에이전트를 컴파일러처럼 취급하면 형편없이 작성된 코드도 배포해도 된다는 태도로 이어질 수 있음
- 에이전트는 컴파일러보다 새로 합류한 인턴에 가까움
- 불완전하고 품질이 낮을 수 있는 기존 코드를 읽고, 부정확한 변경 설명을 바탕으로 새로운 변경을 생성함
- 인간은 인턴 집단에 사고와 취향을 그대로 넘길 수 없으므로 소비자로 머물지 않고 직접 관여해야 함
- 에이전트는 코드를 발견했을 때보다 더 나은 상태로 남기는 보이스카우트 규칙을 자발적으로 따르기 어렵고, 이를 맡기는 일도 부담스러움
- 현재 변경을 최대한 안전하게 만드는 쪽으로 치우쳐 기존 결정을 보수적으로 보존함
- 한 코드베이스에서 인간이 무심코 일부 상태에 브라우저 로컬 스토리지를 사용하자, 나머지 상태는 백엔드 데이터베이스에 저장하는데도 에이전트가 그 결정을 유지하려고 래핑과 간접 계층을 추가해 코드 줄 수가 약 3배로 늘어남
- 이런 보수성은 인간이 내린 일회성의 잘못된 결정을 증폭할 수 있음
- 코드를 직접 삭제하고 탐색하는 과정은 영어로만 지시할 때보다 더 나은 아키텍처에 도달하도록 도움
- 코드에 관심을 기울일수록 사고력과 저작자로서의 감각, 소프트웨어 팩토리를 이끄는 능력이 강화됨
- 소프트웨어 팩토리에서는 아키텍처 패턴부터 알고리듬과 성능까지 세부 사항이 중요함
- 에이전트는 평가·측정·보호 장치의 필요성을 높였고, 개인 프로젝트에서도 CI를 사후 작업이 아니라 초기에 추가하도록 유도함
- 이로써 소프트웨어 개발 상태는 크게 개선됐지만, 모든 조립 라인에는 여전히 약점이 남아 있음
- 자동차 공장에서도 조립 라인을 분해하거나, 내연기관의 세부 사항을 파고들어 10% 개선하거나, 현장 문제를 조기에 발견하지 못한 이유를 찾기 위해 하루 종일 브레이크 패드 테스트를 관찰해야 할 때가 있음
- 소프트웨어에서도 세부 사항과 전체 구조를 연결하려면 무엇을 직접 다룰 수 있는지에 자의적인 경계를 그어서는 안 됨
한국 시장에서의 시사점
한국 개발팀에서도 이미 비슷한 변화가 시작되고 있습니다. 스타트업·SI·중견기업을 막론하고 "Cursor·Claude Code로 PR이 쏟아지는데, 정작 코드는 이해 못 하겠다"는 피로감을 토로하는 팀장이 늘고 있거든요. 이 글의 관점에서 보면 그 피로감은 자연스러운 진통입니다. 사람이 소프트웨어 팩토리의 설계자로 이동하는 과정에서, 공장 자체를 평가하고 개선하는 손길이 여전히 필요하다는 뜻이니까요.
특히 금융·의료·공공 같이 도메인 규제가 강한 도메인에서는 "에이전트가 짠 코드를 그대로 머지"가 사실상 불가능합니다. 테스트·타입 시스템·평가를 에이전트가 만든 코드를 보호하는 안전망으로 강하게 유지해야 하고, 그 안전망 자체를 엔지니어가 직접 코드로 정의하고 튜닝해야 합니다. 2026년의 "코드를 작성하는가"는 곧 자동화의 품질을 책임지는 능력을 의미한다고 보면 정확합니다.
원문: GeekNews #31411
📰 원본 출처 · https://news.hada.io/topic?id=31411 (#N=31411)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.