AI를 주니어 플랫폼 엔지니어로: 코딩 에이전트를 '온보드'하는 방법

I’m sorry, but I can’t retrieve the contents of the linked article. If you provide the text you’d like translated, I’ll be happy to translate it into Korean while preserving the formatting and technical terms as requested.

Introduction

제가 DevOps 워크플로우에 AI를 본격적으로 사용하기 시작한 첫 순간, 저는 많은 사람들이 저지르는 같은 실수를 저질렀습니다. 새로운 엔지니어가 팀에 합류할 때, 우리는 그들이 즉시 생산성을 발휘하길 기대하지 않습니다. 생산 시스템에 바로 접근 권한을 주고 생산성을 요구하지도 않습니다.

• 시스템에 대한 컨텍스트
• 문서
• 경계
• 기여할 수 있는 안전한 환경
• 시스템이 어떻게 작동하는지 이해할 시간

그러한 요소가 없으면, 재능 있는 엔지니어라도 어려움을 겪게 됩니다. AI도 마찬가지입니다. 좋은 AI 결과물과 나쁜 AI 결과물 사이의 가장 큰 차이점 중 하나는 컨텍스트입니다. 컨텍스트가 없으면 AI 에이전트는 일반적인 답변을 제공하는데—기술적으로는 맞지만 시스템, 아키텍처, 제약 조건에 맞지 않습니다. 바로 여기서 context.md 파일이 매우 강력해집니다.

• 인프라가 어떻게 구성되어 있는지
• 명명 규칙
• 환경 및 워크플로우
• 제약 조건(비용, 보안, 규정 준수)
• Terraform 모듈이 어떻게 조직되어 있는지
• 시스템에서 “좋은” 것이 어떤 모습인지

AI가 이 컨텍스트를 갖게 되면, 제안이 일반적이지 않고 시스템에 맞는 느낌을 주기 시작합니다—마치 시스템이 어떻게 연결되어 있는지 이제야 이해한 주니어 엔지니어와 같습니다.

플랫폼 컨텍스트

개요

이 저장소는 Terraform을 사용하여 AWS 인프라를 관리합니다. 주요 워크로드는 개발, 스테이징, 프로덕션 환경의 EKS 클러스터에서 실행됩니다.

핵심 원칙

• 가능한 경우 관리형 서비스를 선호합니다.
• 변경의 영향을 최소화합니다.
• 환경 간 결합을 피합니다.
• 모든 변경은 PR 검토를 거쳐야 합니다.

Terraform 구조

• modules/ → 재사용 가능한 인프라 구성 요소
• envs/dev → 개발 환경
• envs/staging → 스테이징 환경
• envs/prod → 프로덕션 환경

명명 규칙

리소스는 -- 형식을 따릅니다.
예시: prod-payments-eks

가드레일

• 프로덕션을 직접 수정하지 마세요.
• PR 승인 없이 terraform apply 하지 마세요.
• 명시적으로 필요하지 않은 한 리소스 교체를 일으키는 변경을 피하세요.

비용 제약

• 정당한 사유가 없으면 작은 인스턴스 유형을 선호합니다.
• 자동 스케일링에는 항상 상한을 정의해야 합니다.

보안

• IAM 역할은 최소 권한 원칙을 따라야 합니다.
• 명시적으로 승인되지 않은 와일드카드 권한을 허용하지 않습니다.

검토 기대사항

Terraform 계획을 검토할 때 다음에 집중하세요:

• 리소스 교체
• 네트워킹 또는 IAM 변경
• 스케일링 및 비용 영향
• 모듈 간 영향

“좋은” 상태는

• 작고 독립적인 변경
• 명확한 PR 설명
• 최소한의 영향 범위

AI를 주니어 플랫폼 엔지니어로 활용하기

새 엔지니어를 온보딩할 때도 우리는 경계(무엇을 해야 하고, 하지 말아야 할지, 어디에서 변경할 수 있는지, 무엇이 검토가 필요한지)를 정의합니다. 같은 접근 방식이 AI에도 적용됩니다.

AI는 다음을 해서는 안 됩니다:

• 인프라 변경을 직접 적용
• 검토 절차를 우회
• 운영 판단이 필요한 결정을 내림

이것은 의도적인 설계 선택입니다. 새로운 엔지니어와 마찬가지로 목표는 안전한 기여이며, 최대 자율성이 아니라는 점을 기억하세요.

새 엔지니어가 합류하면 보통 다음부터 시작합니다:

• 작은 변경
• 풀 리퀘스트
• 코드 리뷰
• 가이드된 피드백

시간이 지나면서 자신감과 신뢰가 쌓입니다. 같은 모델이 AI에도 매우 잘 작동합니다. AI가 인프라에 직접 작동하도록 두는 대신, PR 워크플로우에 기여하는 사람으로 다룹니다. AI는:

• 변경 사항 생성
• 차이점 설명
• 잠재적 문제 강조
• 가독성 향상

최종 결정은 여전히 인간 검토를 거치며, 시스템을 안전하게 유지하면서 AI 가속의 이점을 활용합니다.

주니어 엔지니어는 피드백을 통해 성장하고, AI 시스템도 반복을 통해 개선됩니다. 문제가 발생했을 때 답이 거의 “AI가 작동하지 않는다”는 것이 아니라, 컨텍스트가 불완전했다는 경우가 많습니다. 시간이 지나면서 컨텍스트와 기대치를 다듬으면 AI는 훨씬 신뢰할 수 있게 되며, 무작위 생성기가 아니라 시스템을 이해하는 팀 구성원처럼 행동하기 시작합니다.

AI를 주니어 플랫폼 엔지니어로 생각하면 워크플로우 설계 방식이 바뀝니다. 다음과 같이 묻는 대신:

“이 도구가 무엇을 할 수 있나요?”

“이 시스템에 누군가를 온보딩하려면 어떻게 해야 할까?”

그 질문은 자연스럽게 다음을 이끌어냅니다:

• 더 나은 컨텍스트
• 명확한 경계
• 안전한 워크플로우
• 보다 예측 가능한 결과

DevOps에서 AI를 자율적인 운영자로 다룰 필요는 없습니다. 많은 경우, 잘 온보딩된 주니어 엔지니어처럼 활용하는 것이 가장 좋습니다:

• 컨텍스트에 의해 가이드됨
• 가드레일에 의해 제한됨
• 안전한 워크플로우를 통한 기여
• 시간이 지나면서 개선

목표는 엔지니어를 대체하는 것이 아니라, 시스템을 이해하기 쉽고, 운영하기 안전하며, 진화 속도를 빠르게 하는 것입니다. 때로는 AI에 더 많은 권한을 주는 것이 아니라, 더 신중하게 온보딩하는 것이 최선의 방법입니다.

이 접근 방식에 대해 여러분의 생각을 궁금합니다.

Originally published on Medium: