비개발자의 해커톤 대상 수상이 증명한 에이전트의 가능성
최근 요즘IT에 올라온 한 비개발자의 해커톤 대상 수기(‘40대 비개발자, 어떻게 해커톤에서 대상을 탈 수 있었을까?’)는 AI 에이전트 시대의 개발 패러다임 변화를 상징적으로 보여준다. 코딩 지식이 부족한 개인이 숙련된 개발자들이 모인 대회에서 두 번이나 대상을 거머쥔 사실은 단순히 운으로 치부하기에는 시사하는 바가 매우 크다.
비개발자의 해커톤 대상 수상이 증명한 에이전트의 가능성
최근 요즘IT에 올라온 한 비개발자의 해커톤 대상 수기(‘40대 비개발자, 어떻게 해커톤에서 대상을 탈 수 있었을까?’)는 AI 에이전트 시대의 개발 패러다임 변화를 상징적으로 보여준다. 코딩 지식이 부족한 개인이 숙련된 개발자들이 모인 대회에서 두 번이나 대상을 거머쥔 사실은 단순히 운으로 치부하기에는 시사하는 바가 매우 크다.
최근 Openclaw를 활용한 자동화 사례들을 살펴보면 흥미로운 지점이 발견된다. 많은 사용자가 자동화의 성능을 얼마나 많은 명령을 동시에 내리는지 혹은 얼마나 복잡한 로직을 구현하는지에 집중하지만 실제 결과물의 품질은 전혀 다른 곳에서 결정된다. 바로 자동화된 태스크를 검증하는 단계다.
AI 에이전트와 협업하며 깨달은 사실은 지시 방식이 결과물의 질을 완전히 결정한다는 점이다. 과거의 코딩이 어떻게(How)를 작성하는 과정이었다면 에이전트 시대의 코딩은 무엇을(What) 달성할지 정의하는 과정으로 변하고 있다. 명령형 지시와 목표 지향적 지시의 차이를 이해하는 것이 에이전틱 엔지니어링의 핵심이다.
최근 작업 환경을 대폭 개편했다. 재택근무 환경이 macOS를 지원하지 않아서 한동안 사용하지 않던 아이맥을 꺼내 싹 포맷을 했다. 그리고 메인으로 삼아 화면만 꺼둔 채 서버처럼 상시 가동한다. 외부에서는 tailscale을 통해 윈도우 노트북이나 모바일로 접속해 모든 작업을 처리한다. SSH로 접속도 가능하고 Serve 기능을 통해서 웹으로도 접속이 가능하다.
AI 시대, 코딩 실력보다 중요한 '컨텍스트 설계'와 팀 생산성
최근 토스 테크 블로그에서 발행된 'Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기’라는 글을 읽고 큰 영감을 받았다. 평소 내가 생각하던 '미래 조직의 모습’과 너무나 일치하는 내용이었기 때문이다.
에이전틱 엔지니어링 도구보다 설계가 중요한 이유와 실전 원칙
에이전트를 더 잘 활용하기 위해 프레임워크나 플러그인, 복잡한 메모리 시스템을 도입하는 경우가 많다. 하지만 실제 운영에서 가장 중요한 것은 도구의 화려함이 아니라 설계다. 에이전트는 독립적인 사고를 하는 존재라기보다 주어진 컨텍스트 안에서만 유효하게 작동하는 시스템이기 때문이다.
AI 에이전트가 코드를 생성하고 실행하는 시대에 접어들면서 프로그래밍 언어의 선택 기준이 바뀌고 있다. 과거에는 인간 개발자의 생산성이 최우선이었다면 이제는 에이전트가 생성한 코드의 안정성과 검증 효율성이 더 중요해졌다. 이런 관점에서 Go는 에이전틱 워크플로우를 위한 가장 강력한 도구로 부상하고 있다.
AI 에이전트 시대에 걸맞은 새로운 개발 워크플로우 설계
기존의 이슈 등록, 커밋, 푸시, PR, 머지로 이어지는 방식은 90년대식 메커니즘에 가깝다. 사람의 실수를 방지하고 비동기 협업을 위해 설계된 이 과정은 컨텍스트를 완벽히 이해하는 AI 에이전트가 코딩을 주도하는 시대에는 오히려 낭비가 된다. AI 시대에 어울리는 새로운 개발 워크플로우를 제안한다.
MCP보다 CLI가 에이전트 시대의 진정한 표준인 이유
최근 앤트로픽의 MCP(Model Context Protocol)가 화제지만 실무에서 에이전트를 운영해보면 결국 다시 CLI로 돌아오게 된다. 프로토콜의 화려함보다 도구의 단순함과 확장성이 훨씬 중요하기 때문이다.
바이브 코딩을 비판하는 이들이 가장 흔히 내세우는 논리는 버그가 많다는 점이다. AI가 생성한 코드는 겉보기에는 멀쩡해도 실행해보면 예상치 못한 오류를 뱉어내는 경우가 빈번하다는 지적이다. 하지만 냉정하게 생각해보면 버그는 코딩과 늘 함께해왔다. 사람이 직접 한 땀 한 땀 코드를 짤 때도 버그는 늘 존재했다. 버그가 하나도 없는 코드는 애초에 불가능에 가깝고, 오히려 버그가 전혀 나오지 않는 개발 과정이 더 부자연스럽다.