Agentic Engineering 시리즈에 오신 것을 환영합니다. 이 시리즈는 AI 에이전트(AI agents)가 반복적인 워크플로우를 자동화하고, 개발자 도구를 오케스트레이션(orchestrating)하며, 엔지니어가 의미 있는 문제 해결에 집중할 수 있도록 함으로써 현대 소프트웨어 엔지니어링을 어떻게 변화시키고 있는지 탐구합니다.

왜 또 다른 AI 시리즈인가?

지난 몇 년 동안 인공지능 (Artificial Intelligence)은 모든 소프트웨어 엔지니어의 일상적인 워크플로우(workflow)의 일부로 빠르게 자리 잡았습니다.

우리는 ChatGPT에게 생소한 코드를 설명해 달라고 요청하고, GitHub Copilot에 의존하여 함수를 자동 완성하며, Claude로 단위 테스트 (unit tests)를 생성하고, Gemini를 사용하여 문서를 요약합니다. 이러한 도구들은 우리가 소프트웨어를 작성하는 방식을 근본적으로 변화시켰으며, 우리의 생산성을 높여준 것은 의심할 여지가 없습니다.

하지만 이러한 도구들을 몇 달 동안 사용하면서 저는 흥미로운 점을 발견했습니다.

저의 상호작용 대부분은 여전히 다음과 같은 모습이었습니다:

• 코드를 복사한다.
• LLM (Large Language Model)에 붙여넣는다.
• 저장소 (repository)를 설명한다.
• 비즈니스 컨텍스트 (business context)를 제공한다.
• 질문을 한다.
• 답변을 다시 IDE로 복사한다.

AI는 제 업무를 대신 해주고 있지 않았습니다.

AI가 저를 도울 수 있도록 필요한 모든 작업을 제가 직접 하고 있었습니다.

그 깨달음은 저를 훨씬 더 큰 질문으로 이끌었습니다.

만약 AI가 스스로 컨텍스트 (context)를 수집할 수 있다면 어떨까?

그 질문이 이 시리즈의 시작점이 되었습니다.

Agentic Engineering이란 무엇인가?

Agentic Engineering은 엔지니어링 워크플로우 (engineering workflows)를 이해하고, 스스로 컨텍스트를 수집하며, 개발자 도구와 상호작용하고, 의사결정을 내리며, 최소한의 인간 개입으로 의미 있는 작업을 수행할 수 있는 지능형 소프트웨어 시스템을 구축하는 실무를 의미합니다.

AI에게 고립된 질문에 답하라고 요청하는 대신, 우리는 AI에게 목표 (objective)를 부여합니다.

다음과 같이 말하는 대신:

"이 풀 리퀘스트 (pull request)를 검토해 주세요."

우리는 단순히 다음과 같이 말합니다:

"Team Alpha에 할당된 모든 오픈 풀 리퀘스트를 검토하세요."

그러면 에이전트 (agent)가 나머지를 알아서 처리합니다.

에이전트는 풀 리퀘스트를 찾아내고, 코드 변경 사항을 검색하며, 관련된 Jira 스토리를 이해하고, 수락 기준 (acceptance criteria)을 수집하며, 적절한 추론 모델 (reasoning model)을 호출하여 구조화된 검토 결과를 생성합니다.

엔지니어는 더 이상 모든 도구 사이의 가교 역할을 하지 않습니다.

에이전트(Agent)가 그 가교가 됩니다.

자동화는 수십 년 동안 존재해 왔습니다

이 시점에서 다음과 같은 질문을 던지는 것은 타당합니다.

"우리는 수년 동안 소프트웨어 엔지니어링을 자동화해 오지 않았나요?"

전적으로 그렇습니다.

• 소프트웨어 엔지니어링은 항상 자동화에 의존해 왔습니다.
• 빌드 서버 (Build servers)는 애플리케이션을 컴파일합니다.
• CI/CD 파이프라인 (CI/CD pipelines)은 서비스를 배포합니다.
• GitHub Actions는 워크플로 (workflows)를 실행합니다.
• 스크립트 (Scripts)는 반복적인 명령어를 자동화합니다.
• 코드형 인프라 (Infrastructure as Code)는 클라우드 환경을 프로비저닝합니다.

그렇다면 무엇이 AI 에이전트를 다르게 만들까요? 답은 의사결정이 이루어지는 방식에 있습니다. 전통적인 자동화는 미리 정의된 지침을 따릅니다.

에이전트는 목표를 추구합니다.

자동화의 진화 이해하기

소프트웨어 엔지니어링 자동화가 어떻게 진화해 왔는지 살펴보겠습니다.

스크립트 (Scripts)

스크립트는 가장 단순한 형태의 자동화입니다.

정해진 명령 시퀀스를 실행합니다.

의존성 설치 (Install dependencies)

    ↓
...

스크립트는 빠르고 예측 가능하지만, 개발자가 프로그래밍한 내용만을 정확히 수행할 뿐입니다.

추론 (Reasoning)은 존재하지 않습니다.

CI/CD 파이프라인 (CI/CD Pipelines)

CI/CD 시스템은 이 개념을 확장합니다.

미리 정의된 이벤트에 대응하여 여러 자동화 단계를 오케스트레이션 (orchestrate)합니다.

코드 푸시 (Push Code)

   ↓
...

파이프라인은 전달 (delivery)을 매우 잘 자동화합니다. 하지만 가능한 모든 경로가 여전히 명시적으로 정의되어 있어야 합니다.

파이프라인은 결코 다음과 같이 묻지 않습니다.

"보안 스캔을 한 번 더 수행해야 할까요?"

그저 지침을 따를 뿐입니다.

GitHub Actions

GitHub Actions는 이벤트 기반 자동화 (event-driven automation)를 도입했습니다.

A pull request가 열립니다.

      ↓
...

엄청나게 강력함에도 불구하고, GitHub Actions는 여전히 결정론적 (deterministic)입니다. 모든 워크플로는 사전에 작성됩니다.

예상치 못한 새로운 상황이 발생하면 워크플로는 중단됩니다.

로봇 프로세스 자동화 (RPA)

RPA는 비즈니스 프로세스에 자동화를 가져왔습니다.

봇 (Bots)이 인간의 상호작용을 모방합니다.

      ↓
...

이는 수많은 반복적인 비즈니스 업무를 제거했습니다. 하지만 자동화는 여전히 세심하게 작성된 스크립트 기반의 동작을 따랐습니다.

만약 화면이 예상치 못하게 변경된다면, 많은 봇(Bots)들은 단순히 실패했습니다.

LLM 어시스턴트 (LLM Assistants)

대규모 언어 모델 (Large Language Models, LLM)은 대화의 양상을 바꾸어 놓았습니다.

사전에 정의된 로직을 실행하는 대신, 정보에 대해 추론할 수 있게 되었습니다.

개발자들은 갑자기 다음과 같은 능력을 갖춘 어시스턴트를 갖게 되었습니다:

• 코드 설명
• 문서 작성
• 테스트 생성
• 함수 리팩토링 (Refactoring)
• 요구사항 요약

하지만 여전히 한 가지 한계가 있었습니다. 어시스턴트는 전적으로 인간이 제공하는 컨텍스트 (Context)에 의존했습니다.

누락된 정보를 스스로 가져올 수는 없었습니다.

에이전틱 워크플로우 (Agentic Workflows)

에이전틱 워크플로우 (Agentic workflows)는 다음 단계를 나타냅니다.

AI에게 고립된 정보 조각들을 주는 대신, 도구 (Tools)에 대한 접근 권한과 목표 (Goal)를 부여합니다.

예를 들어:

오늘 릴리스 브랜치 (Release branch)에 머지(Merge)된 모든 풀 리퀘스트 (Pull request)를 검토하라.

에이전트는 다음과 같은 결정을 내릴 수 있습니다:

• GitHub에서 머지된 풀 리퀘스트 검색
• 각 코드 디프 (Code diff) 추출
• 관련 Jira 스토리 (Jira stories) 찾기
• 수락 기준 (Acceptance criteria) 읽기
• 구현 품질 검토
• 테스트 공백 식별
• 릴리스 노트 (Release notes) 생성
• 보고서 게시

중요한 점을 주목하십시오. 엔지니어는 이러한 단계들을 어떻게 (how) 수행해야 하는지 설명하지 않았습니다. 오직 무엇을 (what) 완수해야 하는지만 설명했습니다.

그 차이점이 바로 에이전틱 워크플로우를 전통적인 자동화와 근본적으로 다르게 만드는 요소입니다.

그래서... AI 에이전트 (AI Agent)란 정확히 무엇인가?

"AI 에이전트 (AI Agent)"라는 용어는 믿을 수 없을 정도로 대중화되었습니다. 불행하게도, 이는 믿을 수 없을 정도로 모호해지기도 했습니다.

오늘날 LLM을 호출하는 거의 모든 애플리케이션이 스스로를 AI 에이전트라고 마케팅합니다.

개인적으로, 저는 더 높은 기준이 필요하다고 생각합니다. 엔지니어링 에이전트 (Engineering agent)는 몇 가지 특성을 갖추어야 합니다.

1. 목표 (Goal)를 가지고 있다

에이전트는 프롬프트 (Prompts)가 아니라, 목표를 향해 작동합니다.

2. 컨텍스트 (Context)를 수집할 수 있다

에이전트는 인간이 모든 것을 수동으로 조립할 필요 없이 정보를 검색합니다.

3. 도구 (Tools)를 사용한다

GitHub.

Jira.

Slack.

Docker.

Kubernetes.

데이터베이스 (Databases).

REST API (REST APIs).

LLM (Large Language Model)은 단 하나의 구성 요소일 뿐입니다.

4. 의사결정을 내린다 (It Makes Decisions)

하나의 고정된 시퀀스를 실행하는 대신, 에이전트는 어떤 도구를 언제 호출할지 스스로 선택합니다.

5. 유용한 결과물을 만들어낸다 (It Produces Useful Outcomes)

목표는 대화가 아닙니다.

목표는 업무를 완수하는 것입니다.

이 시리즈의 철학

이 시리즈의 모든 글은 하나의 단순한 원칙을 따릅니다. 우리는 챗봇을 만드는 것이 아닙니다. 우리는 엔지니어링 팀 동료를 만들고 있습니다.

각 글은 소프트웨어 엔지니어가 매일 수행하는 실질적인 워크플로우 (Workflow)를 탐구하며, 다음과 같은 단순한 질문을 던집니다:

AI 에이전트가 엔지니어링 의사결정은 인간에게 맡기면서, 반복적인 부분들을 처리할 수 있을까?

몇 가지 예시는 다음과 같습니다:

• 풀 리퀘스트 (Pull Requests) 리뷰
• 릴리스 노트 (Release Notes) 생성
• 프로젝트 스캐폴딩 (Scaffolding) 생성
• 개발자 온보딩 (Onboarding) 자동화
• 엔지니어링 지식 어시스턴트 구축
• 기술 문서 (Technical Documentation) 작성
• 프로덕션 장애 (Production Incidents) 대응

각 솔루션은 GitHub, Jira, GitHub Copilot, REST API, Python, Docker, 그리고 클라우드 네이티브 (Cloud-native) 도구 등 엔지니어링 팀이 매일 이미 사용하고 있는 실질적인 기술들을 사용하여 구축될 것입니다.

독점적인 프레임워크 (Proprietary frameworks)는 없습니다. 마법 같은 추상화 (Magical abstractions)도 없습니다.

오직 실질적인 엔지니어링뿐입니다.

이것이 중요한 이유

저는 AI가 소프트웨어 엔지니어를 대체할 것이라고 믿지 않습니다.

하지만 AI가 상당량의 반복적인 엔지니어링 업무를 대체할 것이라고는 믿습니다.

소프트웨어 시스템의 복잡성이 계속해서 증가함에 따라, 엔지니어들은 문제를 해결하기보다 정보를 수집하는 데 점점 더 많은 시간을 소비하고 있습니다.

에이전틱 엔지니어링 (Agentic Engineering)은 소프트웨어 개발 생명주기 (Software Development Lifecycle)에서 인간을 제거하는 것에 관한 것이 아닙니다.

불필요한 마찰 (Friction)을 제거하는 것에 관한 것입니다.

에이전트가 반복적인 업무를 처리하면, 엔지니어는 아키텍처 (Architecture), 시스템 설계 (System Design), 신뢰성 (Reliability), 보안 (Security), 성능 (Performance), 그리고 혁신 (Innovation)에 집중할 수 있는 더 많은 시간을 갖게 됩니다.

이것들이 바로 인간이 해결하는 데 탁월한 능력을 가진 문제들입니다.

다음 단계는?

다음 기사에서는 우리의 첫 번째 엔지니어링 에이전트(engineering agent)를 구축할 것입니다. 이 에이전트는 GitHub CLI, Jira, 그리고 GitHub Copilot을 하나의 자율적인 리뷰 프로세스(autonomous review process)로 결합하여 풀 리퀘스트(pull request) 워크플로우를 이해합니다.

이것은 단순한 또 다른 AI 어시스턴트(AI assistant)가 아닙니다.

이것은 소프트웨어 엔지니어링(software engineering)을 생각하는 새로운 방식의 시작입니다.

저자 소개