지난 2년 동안 개발자들은 한 가지 기술에 집착해 왔습니다.

프롬프트 엔지니어링 (Prompt engineering).

더 나은 지침을 작성하기.

더 많은 컨텍스트 (Context) 추가하기.

역할 정의하기.

출력 형식 지정하기.

예시 추가하기.

AI에게 "단계별로 생각하라 (think step by step)"라고 말하기.

사람들은 거대한 프롬프트 라이브러리를 만들었습니다.

프롬프트 강의를 판매했습니다.

"궁극의 AI 프롬프트"를 공유했습니다.

그리고 완벽한 프롬프트를 쓸 수 있는 사람들에게 미래가 달려 있다고 믿었습니다.

프롬프트 엔지니어링은 중요했습니다.

하지만 그것은 버전 1이었습니다.

버전 2는 이미 여기에 와 있습니다.

그것은 바로 **워크플로 엔지니어링 (workflow engineering)**이라고 불립니다.

완벽한 프롬프트의 문제점

AI에게 다음과 같이 요청한다고 상상해 보세요:

_"프로덕션 준비가 된 애플리케이션을 구축하고 배포하세요."

당신은 3,000단어 분량의 프롬프트를 작성할 수도 있습니다.

아키텍처 (Architecture)를 설명하고.

코딩 표준을 정의하고.

인프라 (Infrastructure)를 지정하고.

테스트 전략을 기술하고.

배포 프로세스를 설명할 수도 있습니다.

그럼에도 AI는 여전히 실수를 할 수 있습니다.

왜일까요?

소프트웨어 개발은 단 하나의 작업이 아니기 때문입니다.

그것은 하나의 워크플로 (Workflow)입니다.

당신은 단 한 번의 시도로 프로덕션 시스템을 구축하지 않습니다.

계획합니다.

구축합니다.

테스트합니다.

실패합니다.

디버깅 (Debug)합니다.

개선합니다.

배포합니다.

모니터링 (Monitor)합니다.

반복합니다.

그런데 왜 우리는 여전히 전체 엔지니어링 프로세스를 하나의 프롬프트로 압축하려고 노력하고 있는 걸까요?

프롬프트 엔지니어링은 지침 단위로 생각합니다

전통적인 AI 워크플로는 다음과 같습니다:

프롬프트 (Prompt) → AI → 응답 (Response)

그것은 유용합니다.

하지만 제한적입니다.

당신은 지침을 제공합니다.

모델은 무언가를 생성합니다.

그러면 프로세스가 멈춥니다.

코드에 버그가 있다면?

또 다른 프롬프트를 작성합니다.

테스트가 실패한다면?

또 다른 프롬프트.

배포가 깨진다면?

또 다른 프롬프트.

당신이 워크플로 엔진이 되어버립니다.

AI는 당신이 자신을 앞으로 움직여주기를 기다립니다.

워크플로 엔지니어링은 시스템 단위로 생각합니다

워크플로 엔지니어링은 다르게 보입니다.

목표 (Goal) → 계획 (Plan) → 실행 (Execute) → 테스트 (Test) → 평가 (Evaluate) → 개선 (Improve) → 반복 (Repeat)

AI는 단순히 답변을 생성하는 것이 아닙니다.

그것은 프로세스를 거쳐 이동합니다.

API를 구축한다고 상상해 보세요.

워크플로는 다음과 같이 할 수 있습니다:

요구사항 분석.

아키텍처 설계.

API 생성.

데이터베이스 모델 생성.

단위 테스트 (Unit tests) 작성.

테스트 실행.

실패 분석.

코드 수정.

의존성 (Dependencies) 스캔.

보안 검토.

문서 생성.

배포 설정 준비.

워크플로는 정의된 조건에 도달할 때까지 계속됩니다.

이는 다음과 같은 방식보다 훨씬 더 강력합니다:

"좋은 API를 만들어 주세요."

프롬프트는 하나의 작은 구성 요소가 됩니다

프롬프트가 사라지는 것은 아닙니다.

프롬프트는 더 큰 시스템의 더 작은 부분들이 되어가고 있습니다.

CI/CD 파이프라인을 생각해 보세요.

파이프라인은 하나의 거대한 Bash 명령어가 아닙니다.

그것은 단계 (Stages)를 포함합니다.

빌드 (Build).

테스트 (Test).

스캔 (Scan).

패키징 (Package).

배포 (Deploy).

검증 (Verify).

각 단계는 특정 책임을 가집니다.

AI 워크플로도 이와 유사하게 변하기 시작했습니다.

한 에이전트 (Agent)가 계획을 세웁니다.

한 에이전트가 코드를 작성합니다.

한 에이전트가 검토합니다.

한 에이전트가 테스트합니다.

한 에이전트가 실패 원인을 조사합니다.

한 에이전트가 배포를 준비합니다.

진정한 엔지니어링 과제는 하나의 완벽한 지시문을 작성하는 것이 아닙니다.

이 모든 단계가 어떻게 함께 작동하는지 설계하는 것입니다.

DevOps 엔지니어들은 이미 이를 이해하고 있습니다

이것이 제가 DevOps 엔지니어들이 AI 시대에 엄청난 이점을 가지고 있다고 믿는 이유입니다.

DevOps는 항상 워크플로에 관한 것이었습니다.

CI/CD를 생각해 보세요.

코드가 푸시(Push)됩니다.

파이프라인이 시작됩니다.

애플리케이션이 빌드됩니다.

테스트가 실행됩니다.

보안 도구가 코드를 스캔합니다.

컨테이너 이미지 (Container image)가 생성됩니다.

이미지가 푸시됩니다.

애플리케이션이 배포됩니다.

모니터링 (Monitoring)이 시스템을 검증합니다.

무언가 실패하면 파이프라인이 중단됩니다.

이것이 바로 워크플로 엔지니어링입니다.

이제 파이프라인의 일부 단계를 지능형 에이전트로 교체해 보세요.

AI 에이전트가 실패한 빌드를 분석합니다.

다른 에이전트가 최근의 Git 변경 사항을 확인합니다.

다른 에이전트가 Docker 설정을 검토합니다.

다른 에이전트가 Kubernetes 이벤트를 조사합니다.

다른 에이전트가 가능한 수정 사항을 준비합니다.

원리는 놀라울 정도로 유사합니다.

만약 이러한 엔지니어링 사고방식을 배우고 싶다면, 저는 더 넓은 DevOps 생태계를 다루는 DevOps Complete Pack을 만들었습니다.

도구를 배우는 것도 유용하기 때문입니다.

하지만 도구들이 어떻게 함께 작동하는지 이해하는 데서 진정한 가치가 시작됩니다.

AI 워크플로 (Workflows)에는 루프 (Loops)가 필요합니다

좋은 워크플로 (Workflow)는 첫 번째 출력이 올바르다고 가정하지 않습니다.

검증합니다.

코드를 생성합니다.

테스트를 실행합니다.

테스트가 실패합니다.

에러를 읽습니다.

원인을 분석합니다.

코드를 수정합니다.

테스트를 다시 실행합니다.

이것이 루프 (Loop)입니다.

실패가 다음 단계를 위한 정보가 될 때, AI는 훨씬 더 유용해집니다.

이것이 바로 엔지니어들이 일하는 방식입니다.

우리는 완벽함을 기대하지 않습니다.

우리는 피드백 시스템 (Feedback systems)을 구축합니다.

도구는 AI를 일꾼으로 만듭니다

LLM (Large Language Model) 단독으로는 텍스트를 생성할 수 있습니다.

하지만 도구 (Tools)를 부여하면 상황은 더 흥미로워집니다.

터미널 (Terminal) 액세스.

Git 리포지토리 (Repositories).

문서 (Documentation).

API.

데이터베이스 (Databases).

모니터링 시스템 (Monitoring systems).

클라우드 플랫폼 (Cloud platforms).

테스트 프레임워크 (Testing frameworks).

이제 AI는 정보를 수집하고 제어된 동작을 실행할 수 있습니다.

예를 들어:

Kubernetes 에이전트 (Agent)가 포드 (Pods)를 조사할 수 있습니다.

이벤트 (Events)를 읽습니다.

로그 (Logs)를 분석합니다.

리소스 설정 (Resource configuration)을 확인합니다.

배포 변경 사항을 비교합니다.

가장 가능성 있는 근본 원인 (Root cause)을 제안합니다.

하지만 여기서 중요한 부분이 있습니다.

AI의 결정을 평가하기 위해서는 여전히 Kubernetes를 이해해야 합니다.

AI가 생성한 명령어가 자동으로 정확한 것은 아닙니다.

그렇기 때문에 탄탄한 기초 (Fundamentals)가 여전히 중요합니다.

만약 Kubernetes가 여러분의 경로 중 일부라면, 저의 CKA Complete Study Guide는 이러한 Kubernetes 기초를 쌓는 데 집중합니다.

목표는 명령어를 암기하는 것이 아닙니다.

AI에게 작동하도록 요청하는 그 시스템을 이해하는 것입니다.

인프라스트럭처는 프로그래밍 가능한 지능이 되어가고 있습니다

코드형 인프라 (Infrastructure as Code)는 클라우드 엔지니어링을 변화시켰습니다.

인프라를 수동으로 생성하는 대신, 우리는 원하는 상태 (Desired state)를 기술했습니다.

AI 워크플로 (Workflows)는 이 아이디어를 더욱 확장할 수 있습니다.

시스템에 목표를 부여한다고 상상해 보세요:

"이 애플리케이션을 위한 보안 스테이징 환경 (Staging environment)을 생성하세요."

워크플로 (Workflow)가 애플리케이션을 분석합니다.

인프라 요구 사항을 식별합니다.

Terraform을 생성합니다.

설정 (Configuration)을 검증합니다.

보안 점검을 실행합니다.

계획 (Plan)을 수립합니다.

예상되는 변경 사항을 설명합니다.

사람의 승인을 기다립니다.

그 후 인프라를 적용합니다.

사람이 배제되는 것은 아닙니다.

사람은 승인 및 아키텍처 (Architecture) 계층으로 이동합니다.

만약 여러분이 코드형 인프라 (Infrastructure as Code, IaC)를 배우고 있다면, 제가 Terraform Associate Exam Crash Course도 준비해 두었습니다.

AI가 생성한 인프라를 오케스트레이션 (Orchestrating)하기 전에, Terraform이 실제로 무엇을 변경하는지 이해해야 하기 때문입니다.

프로그래밍에서도 동일한 변화가 일어나고 있습니다

AI를 이용한 프로그래밍은 단순히 다음과 같지 않습니다:

_"이 함수를 작성해줘."

더 나은 워크플로 (Workflow)는 다음과 같습니다:

문제를 이해합니다.

솔루션을 설계합니다.

구현 (Implementation)을 생성합니다.

프로그램을 실행합니다.

출력을 검사합니다.

엣지 케이스 (Edge cases)를 테스트합니다.

성능을 측정합니다.

취약한 부분을 리팩터링 (Refactor)합니다.

최종 솔루션을 문서화합니다.

이는 Python을 배우고 있든, Go로 시스템을 구축하고 있든 마찬가지로 적용됩니다.

프로그래밍 기초를 강화하려는 개발자들을 위해, 저는 두 가지 심화 리소스를 만들었습니다:

Mastering Python: The Complete Developer's Masterclass

그리고:

Mastering Go: The Complete Developer's Masterclass

하지만 중요한 경고가 있습니다.

프로그래밍 학습을 건너뛰기 위해 AI를 사용하지 마세요.

학습 루프 (Learning loop)를 가속화하기 위해 AI를 사용하세요.

작성합니다.

실행합니다.

망가뜨립니다.

디버그 (Debug)합니다.

이해합니다.

개선합니다.

그것이 바로 AI가 생성한 결과물을 검토할 수 있는 능력을 갖추는 방법입니다.

Git이 더욱 중요해집니다

AI가 더 많은 코드를 생성함에 따라, 변경 관리 (Change management)가 매우 중요해집니다.

무엇이 바뀌었는가?

왜 바뀌었는가?

어떤 에이전트 (Agent)가 수정을 생성했는가?

변경 사항이 회귀 (Regression)를 유발했는가?

안전하게 되돌릴 (Revert) 수 있는가?

AI는 버전 관리 (Version control)의 중요성을 낮추지 않습니다.

오히려 버전 관리를 더 중요하게 만들 수 있습니다.

다섯 명의 에이전트가 프로젝트를 수정하고 있다면, 강력한 Git 워크플로와 명확한 히스토리가 필요합니다.

그 기초를 강화하고자 하는 개발자들을 위해, 저의 Git Mastery: From Zero to Expert는 Git, GitHub, 그리고 GitLab 워크플로를 다룹니다.

AI는 코드를 빠르게 생성할 수 있습니다.

Git은 혼란을 제어할 수 있도록 도와줍니다.

컨테이너가 실행 경계(Execution Boundary)가 됩니다

AI 에이전트(AI agents)에게는 소프트웨어를 안전하게 빌드하고 테스트할 수 있는 환경이 필요합니다.

컨테이너(Containers)는 이에 자연스럽게 부합합니다.

에이전트가 코드를 생성합니다.

컨테이너 환경이 생성됩니다.

의존성(Dependencies)이 설치됩니다.

테스트가 실행됩니다.

애플리케이션이 실행됩니다.

환경이 파괴됩니다.

반복합니다.

에이전트가 개발자의 컴퓨터를 무작위로 수정하게 두는 대신, 워크플로(workflows)는 격리된 환경을 사용할 수 있습니다.

이것이 Docker 지식이 여전히 믿을 수 없을 정도로 유용한 이유 중 하나입니다.

저는 Docker Mastery: From Zero to Certified에서 Docker의 기초와 자격증 중심의 개념들을 다루었습니다.

다시 말씀드리지만, 중요한 기술은 단순히 Docker 명령어를 기억하는 것이 아닙니다.

컨테이너가 왜 존재하는지, 그리고 더 큰 엔지니어링 워크플로(engineering workflow) 내에서 어디에 위치하는지를 이해하는 것입니다.

가장 중요한 기술은 '생각하기'일지도 모릅니다

여기 불편한 진실이 있습니다.

AI는 당신보다 더 빠르게 코드를 생성할 수 있습니다.

문서(documentation)를 더 빠르게 읽을 수 있습니다.

몇 초 만에 열 가지의 가능한 해결책을 만들어낼 수 있습니다.

하지만 더 많은 옵션이 자동으로 더 나은 결정을 만들어내지는 않습니다.

여전히 누군가는 다음과 같은 질문을 던져야 합니다:

이것이 올바른 아키텍처(architecture)인가?

트레이드오프(trade-offs)는 무엇인가?

확장(scale) 시에는 어떤 일이 발생하는가?

어디에서 실패할 수 있는가?

우리는 실제 문제를 해결하고 있는가?

우리가 이것을 만들어야 하는가?

AI 시대는 비판적 사고(critical thinking)를 없애지 않습니다.

오히려 그 가치를 높입니다.

이것이 제가 The Sharp Mind: A Complete System for Mastering Critical Thinking을 만든 이유이기도 합니다.

미래 개발자의 강점은 타이핑 속도가 아닐 수도 있기 때문입니다.

기계가 생성한 결정을 평가하는 능력일 수 있습니다.

새로운 엔지니어링 기술

프롬프트 엔지니어링(Prompt engineering)은 다음과 같이 묻습니다:

"AI에게 어떻게 더 나은 지침을 줄 것인가?"

워크플로 엔지니어링(Workflow engineering)은 다음과 같이 묻습니다:

"목표에 안정적으로 도달하는 시스템을 어떻게 설계할 것인가?"

이것은 훨씬 더 큰 질문입니다.

당신은 다음 요소들을 고민해야 합니다:

컨텍스트(Context).

도구(Tools).

메모리(Memory).

권한(Permissions).

피드백 루프(Feedback loops).

실패 처리 (Failure handling).

테스트 (Testing).

관측 가능성 (Observability).

인간의 승인 (Human approval).

중단 조건 (Stopping conditions).

프롬프트는 하나의 구성 요소일 뿐입니다.

워크플로 (Workflow)가 곧 제품입니다.

프롬프트 수집을 멈추세요

500개의 "궁극의 ChatGPT 프롬프트"를 저장한다고 해서 진정한 경쟁 우위를 확보할 수는 없을 것입니다.

시스템이 어떻게 작동하는지 배우세요.

프로그래밍을 배우세요.

Git을 배우세요.

컨테이너 (Containers)를 이해하세요.

인프라 (Infrastructure)를 이해하세요.

Kubernetes를 이해하세요.

자동화 (Automation)를 배우세요.

비판적 사고 (Critical thinking)를 기르세요.

그런 다음 AI를 이러한 시스템들에 지능적으로 연결하세요.

AI를 지시하는 사람이 워크플로 (Workflow)를 이해할 때, AI는 훨씬 더 강력해지기 때문입니다.

마치며

프롬프트 엔지니어링 (Prompt engineering)은 AI와 소통하는 법을 우리에게 가르쳐 주었습니다.

그것이 버전 1이었습니다.

이제 우리는 AI를 중심으로 시스템을 구축하는 법을 배우고 있습니다.

계획을 세우는 시스템.

도구 (Tools)를 사용하는 시스템.

테스트 (Test)를 수행하는 시스템.

실패로부터 배우는 시스템.

피드백 (Feedback)을 통해 개선되는 시스템.

그것이 버전 2입니다.

미래는 가장 긴 프롬프트를 가진 사람의 것이 아닙니다.

최고의 워크플로 (Workflow)를 설계할 수 있는 엔지니어의 것이 될 것입니다.

프롬프트 엔지니어링 (Prompt engineering)이 지능과 대화하는 것에 관한 것이었다면,

워크플로 엔지니어링 (Workflow engineering)은 지능을 실제로 일하게 만드는 것에 관한 것입니다.