<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>이 글은 Amazon에서 AI 에이전트를 기반으로 코드 작성 뿐만 아니라, 업무 워크플로우를 재구성한 팀으로부터 측정된 결과들을 바탕으로, SW 개발자들이 일하는 방법을 위한 10가지 원칙을 소개하고 있습니다. 만약, 이미 AI 코딩 도구를 쓰고 있지만 제품 출시 속도가 빨라지지 않았다면, 꼭 읽어 보시길 권장 드립니다.</p>



<p><em>※ Kiro 웹 사이트의 원문(<a href="https://kiro.dev/topics/frontier-engineering/">https://kiro.dev/topics/frontier-engineering/</a>)을 요약하고 있지만, 저의 개인적인 의견도 추가했습니다.</em></p>



<h2>1. 당신은 코더가 아니라 아키텍트다</h2>



<p>프론티어 엔지니어는 자신이 만드는 코드 중 직접 타이핑하는 비율이 1% 미만입니다. 코드는 이제 AI가 쓰고, 주요 업무는 업무를 지시하고, 방향을 잡고, 검토하는 자율적인 에이전트를 만들고 있어요. 즉, 요구사항, 제약조건, 완성이 무엇인지 정의하고, 결과물이 의도에 맞는지 검증하는 일인 거죠.</p>



<p>그래서, 여러분은 명확한 의도를 글로 쓰는 훈련을 해야 합니다. 예를 들어, “구글 인증 API를 붙여줘” 정도가 아니라, 어떻게 보안 자격으로 엔드 포인트에 접근할 수 있는지, 토근이 만료되면 어떻게 접근하는지, 비인가 접근을 어떻게 테스트할지 명확하게 제시한 후, 에이전트에 맡겨야 합니다.</p>



<h2>2. 에이전트 시간은 최대로, 사람의 개입은 최소로</h2>



<p>프론티어 엔지니어는 구현하고, 텧스트하고, 검증하는 단계가 모두 포함된 30분 이상의 긴 작업을 AI에게 시킵니다. 많은 개발자가 코딩 어시스턴트와 주고 받는 방식으로 일합니다. 프롬프트를 던지고, 60초 정도 기다려서, 코드를 받고, 수동으로 테스트하고, 에러를 채팅에 붙여넣고, 개선하는 방식으로는 속도를 높일 수 없어요.</p>



<p>에이전트가 스스로 루프를 돌며 수정하고 정답에 수렴하게 두세요. 그러는 동안, 개발자는 다른 일을 하면됩니다. 점점 몇 시간 혹은 밤새 돌아가는 멀티 에이전트를 병렬로 돌리고, 결과는 다음날 아침에 검토하세요. 사람의 개입은 방향 설정과 결과 검증만으로 점점 줄여가야 합니다.</p>



<h2>3. 에이전트를 위한 코드베이스를 유지하라</h2>



<p>프론티어 엔지니어는 기본기가 충실한 에이전트를 만들어야 합니다. README와 아키텍처 문서, 기대 동작을 설명하는 테스트 케이스, 명확한 모듈 경계 등등을 코드처럼 관리하고 유지해야 합니다. 특히, 대규모 레거시 코드라면, AI에게 전체가 아니라 하나의 모듈 단위로 구현하도록 하세요.</p>



<p>사람은 온보딩을 한 번 하지만, 에이전트는 매 세션마다 온보딩하기 때문에, 사람이 머릿속에 들고 다니는 맥락을 에이전트에게는 명시적으로 줘야 합니다. 그리고, 에이전트가 주석에 스스로 문서화하도록 하고, 설계 결정을 영속적인 기억으로 남기도록하여, 다음 세션의 에이전트는 코드뿐 아니라 그 코드가 나온 이유까지 알게해야 합니다.</p>



<h2>4. 에이전트에게 테스트 환경을 제공하라</h2>



<p>프론티어 엔지니어는 에이전트가 로컬에서 테스트를 돌리고 스스로 고치고 자등으로 검증하는데 더 투자해야 합니다. 예를 들어, 자신이 사용하고 있는 린터와 단위 테스트, UI 변경 사항을 렌더링해 시각적으로 확인할 수 있는 웹 브라우저 테스트, 통합 테스트용 로컬 목업, 노트북에서 전체 스택을 띄워 종단간(E2E) 테스트할 수 있는 환경 등을 에이전트가 직접 쓸 수 있게 해야 합니다.</p>



<p>만약, 이런 투자가 없으면 코드 생성이 빨라질수록 빌드가 깨지고, 알 수없는 버그만 늘어납니다. 반대로 투자가 있으면, 에이전트는 많은 사람보다 더 꼼꼼하고 일관되게 검증하기 때문에 코드베이스 품질이 오히려 좋아집니다.</p>



<h2>5. 진짜 중요한 것은 방향성이다</h2>



<p>프론티어 엔지니어는 설계 단계에서 에이전트를 브레인스토밍 파트너로 활용합니다. 코드 구현 사항은 바꾸기 쉽지만 시스템 설계, API 계약, 의존성, 아키텍처 결정은 나중에 바꾸기가 어렵습니다. 장기적으로 중요한 결정에 에너지를 더 많이 쓰세요.</p>



<p>에이전트에게 두 세가지 대안 아키텍처를 요청하고, 모두 그럴듯하면 프로토타입을 만들어 비교하세요. 예전엔 토론으로 결정했던 것을 이제 데이터를 기반으로 결정할 수 있습니다. 이제 구현 방향이 정해지면, 코드 작성전에 에이전트를 위한 명확한 스펙과 요구사항을 작성해서 모호함을 줄여야 합니다.</p>



<h2>6. 코드는 일회용이다</h2>



<p>프론티어 엔지니어는 코드를 쉽게 버릴 수 있어야 합니다. 과거에는 몇 달간 쏟은 노력이 안타까워서, 또는 다시 시작하면 똑같이 시간이 걸릴까봐 버리기 어려워졌습니다. 이제 에이전트가 금방 다시 만들어 줍니다. 지금 만든 것이 출시할 가치가 있는지, 운영과 유지보수를 감당할 가치가 있는지 평가하세요.</p>



<p>다만, 단위 테스트는 코드와 함께 버려지지만, 경계 테스트 즉, 동작을 보장하는 E2E 통합 테스트, 불변식을 보장하는 속성 기반 테스트, 대규모 성능과 동시성을 보장하는 부하 테스트 같은 것들은 일관성을 위해 남겨두어야 합니다.</p>



<h2>7. AI 코드에 인간 기준을 적용하라</h2>



<p>프론티어 엔지니어는 자신의 이름으로 나가는 결과물은 자기가 책임을 집니다. 초기에는 AI 코드를 한 줄씩 리뷰하며 모델이 무엇을 잘하고 어디서 실패하는지 감을 쌓아야 합니다. 어느정도 익숙해지면, AI 리뷰어를 만들어 그 부담을 일부 넘깁니다. 보안, 유지보수성, 테스트 품질, 흔한 버그 패턴 등 팀이 중요시하는 것을 점검하게 하세요.</p>



<p>최종적으로 에이전트 루프를 코드 머징 이후까지 확장하세요. 빌드하고, 배포를 모니터링하고, 프로덕션 동작을 검증하고, 롤백이 생기면, 자동으로 수정 작업을 맡깁니다. 결과를 책임진다는 것은 코드 풀리퀘스트에서 멈추지 않고, 프로덕션까지 확장하는 것을 의미합니다.</p>



<h2>8. 에이전트가 아니라 경계를 신뢰하라</h2>



<p>프론티어 엔지니어는 에이전트가 실제로 필요한 파일, 도구, 네트워크, 자격증명에만 접근하도록 제한하고, 그 안에서 감독 없이 자율적으로 실행합니다. 최소한의 권한만 가진 환경안에서 에이전트의 활동 경계를 설정해야 합니다.</p>



<p>한계에 대한 확신이 쌓이면 경계를 넓히되, 프로덕션 환경에 대해서는 편집증 환자가 되어야 합니다. 명시적이고 의도적인 최소한의 권한 부여 없이, 에이전트가 절대 프로덕션 계정이나 배포 자격증명에 접근하면 안 됩니다.</p>



<h2>9. 모든 개발 주기에 에이전트를 쓰라</h2>



<p>프론티어 엔지니어는 코드 뿐만 아니라 모든 개발 주기에 에이전트를 사용합니다. 설계 문서 작성이나 스프린트 요약, 온콜 리포트, API 문서화 등에 에이전트를 활용할 수 있습니다. 위에서 언급했던 원칙들은 기획, 개발, 테스트, 배포, 운영 모든 단계에서 적용할 수 있습니다.</p>



<p>각 단계 업무가 스펙으로 명확해지면, 파이프라인 에이전트, 온콜 에이전트, 문서화 에이전트, 서드파티 에이전트 등을 만들고, 모두 에이전트 코드 베이스 (스펙 문서, MCP 서버, 스킬, 테스트 도구 등)를 공유하여, 어떤 일을 하든 일관되게 행동하도록 합니다.</p>







<p>프론티어 엔지니어는 제품을 만드는 시스템을 끊임없이 개선해야 합니다. 에이전트의 실수와 중단 하나하나가 시스템을 개선할 기회입니다. 그럴때 마다, 스펙 파일에 새 규칙을 추가하거나, 틀렸던 절차를 담은 스킬을 새로 작성하거나, 수동 단계를 자동화하는 CLI 도구를 만들거나, 올바른 맥락을 수집하는 MCP 서버를 세팅하거나, 그동안 막아뒀던 도구나 시스템에 대한 접근을 확대합니다.</p>



<p>다만, 새 모델이 나오면, 이전 모델의 약점을 우회하려고 만든 규칙 역시 계속 재평가하세요. 에이전트가 사용하는 스펙 파일과 도구 역시 모델만큼 빠르게 진화하는 살아 있는 산출물이어야 합니다.</p>



<hr>



<p>프론티어 엔지니어링은 엄격한 공학적 원칙을 기반으로 AI 에이전트를 더하는 체계적인 실천과정입니다. 이 와중에 개발자는 장기적으로 자신의 주의력을 관리하는 능력을 키워야 합니다. 저녁 식사 중이나 한밤중에 에이전트를 확인하고 싶은 충동을 자제하고, 내가 무엇에 신경을 써야 하는지 반복해서 결정해야 합니다.</p>



<p>아직, 프론티어 엔지니어링은 여전히 초기단계이고 아직 완성된 방법론은 압니다. 다만, 조금 느리더라도 초기에 방향을 잡는 노력에 더 시간을 쓴다면, 극적으로 빨라집니다. AI 에이전트의 능력은 사람이 가르친 것 위해서 나오니까요. 이렇게 AI로 개발하는 방식을 다르게 정의해 보시고, 오늘부터 일하는 방식을 바꿔보세요.</p>




	

<p><small>- ;</small></p>

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)</p>



	<p><small>* 이 글의 댓글 일부는 <a href="https://indieweb.org/Webmention">Webmention</a> 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.</small></p>

<div id="respond"><h3>답글 남기기</h3>





</div>
   </div></article>
</div></div>

Channy's Blog

이 글은 Amazon에서 AI 에이전트를 기반으로 코드 작성 뿐만 아니라, 업무 워크플로우를 재구성한 팀으로부터 측정된 결과들을 바탕으로, SW 개발자들이 일하는 방법을 위한 10가지 원칙을 소개하고 있습니다. 만약, 이미 AI 코딩 도구를 쓰고 있지만 제품 출시 속도가 빨라지지 않았다면, 꼭 읽어 보시길 권장 드립니다.
※ Kiro 웹 사이트의 원문(https://kiro.dev/topics/frontier-engineering/)을 요약하고 있지만, 저의 개인적인 의견도 추가했습니다.
1. 당신은 코더가 아니라 아키텍트다
프론티어 엔지니어는 자신이 만드는 코드 중 직접 타이핑하는 비율이 1% 미만입니다. 코드는 이제 AI가 쓰고, 주요 업무는 업무를 지시하고, 방향을 잡고, 검토하는 자율적인 에이전트를 만들고 있어요. 즉, 요구사항, 제약조건, 완성이 무엇인지 정의하고, 결과물이 의도에 맞는지 검증하는 일인 거죠.
그래서, 여러분은 명확한 의도를 글로 쓰는 훈련을 해야 합니다. 예를 들어, “구글 인증 API를 붙여줘” 정도가 아니라, 어떻게 보안 자격으로 엔드 포인트에 접근할 수 있는지, 토근이 만료되면 어떻게 접근하는지, 비인가 접근을 어떻게 테스트할지 명확하게 제시한 후, 에이전트에 맡겨야 합니다.
2. 에이전트 시간은 최대로, 사람의 개입은 최소로
프론티어 엔지니어는 구현하고, 텧스트하고, 검증하는 단계가 모두 포함된 30분 이상의 긴 작업을 AI에게 시킵니다. 많은 개발자가 코딩 어시스턴트와 주고 받는 방식으로 일합니다. 프롬프트를 던지고, 60초 정도 기다려서, 코드를 받고, 수동으로 테스트하고, 에러를 채팅에 붙여넣고, 개선하는 방식으로는 속도를 높일 수 없어요.
에이전트가 스스로 루프를 돌며 수정하고 정답에 수렴하게 두세요. 그러는 동안, 개발자는 다른 일을 하면됩니다. 점점 몇 시간 혹은 밤새 돌아가는 멀티 에이전트를 병렬로 돌리고, 결과는 다음날 아침에 검토하세요. 사람의 개입은 방향 설정과 결과 검증만으로 점점 줄여가야 합니다.
3. 에이전트를 위한 코드베이스를 유지하라
프론티어 엔지니어는 기본기가 충실한 에이전트를 만들어야 합니다. README와 아키텍처 문서, 기대 동작을 설명하는 테스트 케이스, 명확한 모듈 경계 등등을 코드처럼 관리하고 유지해야 합니다. 특히, 대규모 레거시 코드라면, AI에게 전체가 아니라 하나의 모듈 단위로 구현하도록 하세요.
사람은 온보딩을 한 번 하지만, 에이전트는 매 세션마다 온보딩하기 때문에, 사람이 머릿속에 들고 다니는 맥락을 에이전트에게는 명시적으로 줘야 합니다. 그리고, 에이전트가 주석에 스스로 문서화하도록 하고, 설계 결정을 영속적인 기억으로 남기도록하여, 다음 세션의 에이전트는 코드뿐 아니라 그 코드가 나온 이유까지 알게해야 합니다.
4. 에이전트에게 테스트 환경을 제공하라
프론티어 엔지니어는 에이전트가 로컬에서 테스트를 돌리고 스스로 고치고 자등으로 검증하는데 더 투자해야 합니다. 예를 들어, 자신이 사용하고 있는 린터와 단위 테스트, UI 변경 사항을 렌더링해 시각적으로 확인할 수 있는 웹 브라우저 테스트, 통합 테스트용 로컬 목업, 노트북에서 전체 스택을 띄워 종단간(E2E) 테스트할 수 있는 환경 등을 에이전트가 직접 쓸 수 있게 해야 합니다.
만약, 이런 투자가 없으면 코드 생성이 빨라질수록 빌드가 깨지고, 알 수없는 버그만 늘어납니다. 반대로 투자가 있으면, 에이전트는 많은 사람보다 더 꼼꼼하고 일관되게 검증하기 때문에 코드베이스 품질이 오히려 좋아집니다.
5. 진짜 중요한 것은 방향성이다
프론티어 엔지니어는 설계 단계에서 에이전트를 브레인스토밍 파트너로 활용합니다. 코드 구현 사항은 바꾸기 쉽지만 시스템 설계, API 계약, 의존성, 아키텍처 결정은 나중에 바꾸기가 어렵습니다. 장기적으로 중요한 결정에 에너지를 더 많이 쓰세요.
에이전트에게 두 세가지 대안 아키텍처를 요청하고, 모두 그럴듯하면 프로토타입을 만들어 비교하세요. 예전엔 토론으로 결정했던 것을 이제 데이터를 기반으로 결정할 수 있습니다. 이제 구현 방향이 정해지면, 코드 작성전에 에이전트를 위한 명확한 스펙과 요구사항을 작성해서 모호함을 줄여야 합니다.
6. 코드는 일회용이다
프론티어 엔지니어는 코드를 쉽게 버릴 수 있어야 합니다. 과거에는 몇 달간 쏟은 노력이 안타까워서, 또는 다시 시작하면 똑같이 시간이 걸릴까봐 버리기 어려워졌습니다. 이제 에이전트가 금방 다시 만들어 줍니다. 지금 만든 것이 출시할 가치가 있는지, 운영과 유지보수를 감당할 가치가 있는지 평가하세요.
다만, 단위 테스트는 코드와 함께 버려지지만, 경계 테스트 즉, 동작을 보장하는 E2E 통합 테스트, 불변식을 보장하는 속성 기반 테스트, 대규모 성능과 동시성을 보장하는 부하 테스트 같은 것들은 일관성을 위해 남겨두어야 합니다.
7. AI 코드에 인간 기준을 적용하라
프론티어 엔지니어는 자신의 이름으로 나가는 결과물은 자기가 책임을 집니다. 초기에는 AI 코드를 한 줄씩 리뷰하며 모델이 무엇을 잘하고 어디서 실패하는지 감을 쌓아야 합니다. 어느정도 익숙해지면, AI 리뷰어를 만들어 그 부담을 일부 넘깁니다. 보안, 유지보수성, 테스트 품질, 흔한 버그 패턴 등 팀이 중요시하는 것을 점검하게 하세요.
최종적으로 에이전트 루프를 코드 머징 이후까지 확장하세요. 빌드하고, 배포를 모니터링하고, 프로덕션 동작을 검증하고, 롤백이 생기면, 자동으로 수정 작업을 맡깁니다. 결과를 책임진다는 것은 코드 풀리퀘스트에서 멈추지 않고, 프로덕션까지 확장하는 것을 의미합니다.
8. 에이전트가 아니라 경계를 신뢰하라
프론티어 엔지니어는 에이전트가 실제로 필요한 파일, 도구, 네트워크, 자격증명에만 접근하도록 제한하고, 그 안에서 감독 없이 자율적으로 실행합니다. 최소한의 권한만 가진 환경안에서 에이전트의 활동 경계를 설정해야 합니다.
한계에 대한 확신이 쌓이면 경계를 넓히되, 프로덕션 환경에 대해서는 편집증 환자가 되어야 합니다. 명시적이고 의도적인 최소한의 권한 부여 없이, 에이전트가 절대 프로덕션 계정이나 배포 자격증명에 접근하면 안 됩니다.
9. 모든 개발 주기에 에이전트를 쓰라
프론티어 엔지니어는 코드 뿐만 아니라 모든 개발 주기에 에이전트를 사용합니다. 설계 문서 작성이나 스프린트 요약, 온콜 리포트, API 문서화 등에 에이전트를 활용할 수 있습니다. 위에서 언급했던 원칙들은 기획, 개발, 테스트, 배포, 운영 모든 단계에서 적용할 수 있습니다.
각 단계 업무가 스펙으로 명확해지면, 파이프라인 에이전트, 온콜 에이전트, 문서화 에이전트, 서드파티 에이전트 등을 만들고, 모두 에이전트 코드 베이스 (스펙 문서, MCP 서버, 스킬, 테스트 도구 등)를 공유하여, 어떤 일을 하든 일관되게 행동하도록 합니다.
10. 에이전트 설정을 끊임없이 튜닝하라
프론티어 엔지니어는 제품을 만드는 시스템을 끊임없이 개선해야 합니다. 에이전트의 실수와 중단 하나하나가 시스템을 개선할 기회입니다. 그럴때 마다, 스펙 파일에 새 규칙을 추가하거나, 틀렸던 절차를 담은 스킬을 새로 작성하거나, 수동 단계를 자동화하는 CLI 도구를 만들거나, 올바른 맥락을 수집하는 MCP 서버를 세팅하거나, 그동안 막아뒀던 도구나 시스템에 대한 접근을 확대합니다.
다만, 새 모델이 나오면, 이전 모델의 약점을 우회하려고 만든 규칙 역시 계속 재평가하세요. 에이전트가 사용하는 스펙 파일과 도구 역시 모델만큼 빠르게 진화하는 살아 있는 산출물이어야 합니다.
프론티어 엔지니어링은 엄격한 공학적 원칙을 기반으로 AI 에이전트를 더하는 체계적인 실천과정입니다. 이 와중에 개발자는 장기적으로 자신의 주의력을 관리하는 능력을 키워야 합니다. 저녁 식사 중이나 한밤중에 에이전트를 확인하고 싶은 충동을 자제하고, 내가 무엇에 신경을 써야 하는지 반복해서 결정해야 합니다.
아직, 프론티어 엔지니어링은 여전히 초기단계이고 아직 완성된 방법론은 압니다. 다만, 조금 느리더라도 초기에 방향을 잡는 노력에 더 시간을 쓴다면, 극적으로 빨라집니다. AI 에이전트의 능력은 사람이 가르친 것 위해서 나오니까요. 이렇게 AI로 개발하는 방식을 다르게 정의해 보시고, 오늘부터 일하는 방식을 바꿔보세요.

AI 에이전트 시대, 개발자는 어떻게 일해야 하는가? – 프론티어 엔지니어링의 10가지 원칙

댓글