엔지니어링 - 프롬프트 엔진니어링부터 비즈니스 엔지니어링까지

 

인공지능을 업무에 활용하다 보면 엔지니어링을 잘 알아야 한다. 어떤 질문을 던져야 원하는 답변을 얻을 수 있는지, 어떤 지시문을 써야 결과물이 더 정확해지는지가 가장 먼저 눈에 보이기 때문이다. 엔지니어링의 흐름을 보면 “AI에게 질문을 잘하는 단계”에서 “AI 시스템을 설계하고 운영하는 단계”로 성장하는 과정이다.

 

 

1. 프롬프트 엔지니어링

프롬프트 엔지니어링은 AI에게 무엇을 어떻게 요청할지 설계하는 단계다.

이 단계는 AI에게 원하는 결과를 얻기 위해 질문과 지시문을 잘 작성하는 기술이다. 예를 들어 “블로그 글 써줘”라고 말하는 대신, “AI 초보자를 대상으로, 1500자 분량으로, 문어체로, 도입·본문·정리 구조로 작성해줘”라고 요청하는 방식이다. 이 단계에서 명확한 요구사항을 작성하는 능력을 먼저 익혀야 한다.

나쁜 예시는 다음과 같다.

이번 주 프로젝트 상황 정리해줘.

이렇게 요청하면 AI는 어떤 형식으로, 어떤 기준으로, 누구에게 보고할지 알기 어렵다.

개선된 프롬프트는 다음과 같다.

너는 SI 프로젝트 PM 보조 역할이다.
아래 프로젝트 이슈 목록을 바탕으로 이번 주 주간 리스크 보고서를 작성하라.
보고 대상은 팀장과 임원이다.
문체는 간결한 보고서 문체로 작성하라.
다음 구조를 반드시 따르라.

1. 이번 주 주요 이슈
2. 일정 지연 가능성
3. 고객 대응 필요 사항
4. 다음 주 조치 계획
5. PM 판단 의견

과장하지 말고, 입력된 내용에 근거해서만 작성하라.

이 단계에서 핵심은 역할, 목적, 대상, 형식, 제약 조건을 명확히 주는 것이다.

 

 

2. 컨텍스트 엔지니어링

컨텍스트 엔지니어링은 AI가 답변할 때 참고해야 할 배경 정보와 자료를 설계하는 단계다.

프롬프트가 “무엇을 시킬 것인가”라면, 컨텍스트는 “AI가 무엇을 참고해야 하는가”에 가깝다. AI가 좋은 답변을 하려면 배경 정보, 문서, 기준, 예시, 이전 대화, 사용자 의도 같은 맥락이 필요하다. 예를 들어 회사 업무 문서를 요약하게 할 때 단순히 문서만 넣는 것이 아니라, “PM 보고용인지, 개발자 검토용인지, 고객 전달용인지”까지 알려주는 것이다.

프롬프트만 있을 때는 AI가 일반적인 답변을 한다. 하지만 컨텍스트를 함께 주면 업무에 맞는 결과가 나온다.

예시는 다음과 같습니다.

프로젝트명: CS SDK 고도화
기간: 2026.03 ~ 2027.03
현재 단계: 개발 2차 반복 구간
보고 대상: 고객사 PM, 내부 팀장
중요 기준: 일정 지연 여부, 고객 요청 변경, 장애 가능성

이번 주 이슈 목록:

• API 응답 속도 개선 요청 발생
• 배포 서버 접근 권한 승인 지연
• Vue 화면 일부에서 권한별 버튼 노출 오류 발생
• 고객 추가 요청 3건 접수
• 테스트 데이터 부족으로 검증 일정 하루 지연 가능성 있음

작성 기준:

• 고객 책임으로 단정하지 말 것
• 내부 조치 계획을 함께 제시할 것
• 위험도는 상·중·하로 구분할 것

이 단계에서는 AI에게 단순히 “보고서를 써라”가 아니라, 무엇을 알고 판단해야 하는지를 제공한다.

실무에서는 이 컨텍스트가 문서, 회의록, Jira 이슈, Excel, Confluence, DB 데이터, 이전 보고서가 될 수 있다.

 

 

3. 하네스 엔지니어링

하네스 엔지니어링은 프롬프트와 컨텍스트를 한 번 실행하고 끝내는 것이 아니라, 여러 번 실행하고 결과를 비교·검증하는 실험 구조를 만드는 단계다.

하네스는 AI를 한 번 실행해보고 끝내는 것이 아니라, 여러 프롬프트와 컨텍스트를 묶어서 반복 실행하고 결과를 비교·검증하는 구조를 말한다. 주니어 개발자에게는 다소 낯설 수 있지만, 쉽게 말하면 AI 실험 환경을 만드는 것이다. 입력값을 바꿔보고, 결과를 저장하고, 어떤 방식이 더 좋은지 비교하는 과정이다.

예를 들어 개발자가 Python으로 다음과 같은 실험을 할 수 있다.

prompts = [
    "주간 프로젝트 보고서를 작성하라.",
    "PM 관점에서 리스크 중심 주간 보고서를 작성하라.",
    "임원 보고용으로 일정, 리스크, 조치계획 중심 보고서를 작성하라."
]

context = """
프로젝트명: CS SDK 고도화
이번 주 이슈:
- API 응답 속도 개선 요청
- 서버 권한 승인 지연
- 권한별 버튼 노출 오류
- 테스트 데이터 부족
"""

for i, prompt in enumerate(prompts, 1):
    result = call_llm(prompt, context)
    save_result(f"result_{i}.txt", result)

이 구조의 목적은 “어떤 프롬프트가 더 좋은가?”를 감으로 판단하지 않고 비교하는 것이다.

개발자 기준에서는 다음을 해볼 수 있다.

프롬프트 A, B, C를 만든다.
같은 입력 데이터를 넣는다.
결과를 파일로 저장한다.
어떤 결과가 더 보고서답고 정확한지 비교한다.
좋은 프롬프트를 남기고 나쁜 프롬프트는 수정한다.

즉, 하네스 엔지니어링은 AI 실험을 반복 가능한 구조로 만드는 작업이다.

 

4. 툴 엔지니어링

툴 엔지니어링은 AI가 외부 도구를 사용할 수 있게 만드는 단계다.

AI가 검색, 파일 읽기, 데이터베이스 조회, API 호출, 이메일 작성, 캘린더 확인 같은 외부 도구를 사용할 수 있도록 연결하는 단계다. 예를 들어 AI에게 “고객 문의를 분석해줘”라고 했을 때, AI가 직접 데이터베이스에서 문의 내역을 가져오고, 유형별로 분류하고, 결과를 표로 정리하게 만드는 것이다. 이 단계에서는 API, JSON, 함수 호출, 인증, 데이터 구조에 대한 이해가 필요하다.

예를 들어 AI가 직접 프로젝트 이슈를 조회해야 한다면 다음과 같은 도구가 필요하다.

def get_project_issues(project_id: str):
    """
    프로젝트 ID를 기준으로 이번 주 등록된 이슈 목록을 조회한다.
    """
    issues = db.query("""
        SELECT title, status, priority, created_at
        FROM project_issues
        WHERE project_id = ?
        AND created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
    """, project_id)
    
    return issues

AI는 이 함수를 호출해서 실제 데이터를 가져올 수 있다.

사용자 요청:

이번 주 CS SDK 프로젝트 리스크 정리해줘.

AI 처리 흐름:

1. get_project_issues("CS_SDK") 호출
2. DB에서 이슈 목록 조회
3. 우선순위와 상태 분석
4. 주간 리스크 보고서 생성

이 단계부터 AI는 단순히 문장을 생성하는 도구가 아니라, 시스템과 연결된 작업 수행자가 된다.

 

5. 에이전트 엔지니어링

에이전트 엔지니어링은 AI가 목표를 보고 작업 순서를 스스로 판단하게 만드는 구조다.

에이전트는 단순히 답변만 생성하는 AI가 아니라, 목표를 보고 스스로 작업 순서를 정해 실행하는 구조다. 예를 들어 “이번 주 프로젝트 리스크를 정리해줘”라는 요청을 받으면, 관련 문서를 찾고, 일정표를 확인하고, 이슈를 분류하고, 최종 보고서를 만드는 식이다. 주니어 개발자는 여기서 계획 → 실행 → 관찰 → 수정이라는 흐름을 이해해야 한다.

예를 들어 사용자가 이렇게 요청한다.

이번 주 프로젝트 리스크를 찾아서 보고서로 정리해줘.

일반 LLM은 바로 답변을 만들려고 한다.
하지만 에이전트는 다음처럼 생각하고 실행 한다.

1. 프로젝트 이슈 목록을 조회한다.
2. 지연 가능성이 있는 이슈를 찾는다.
3. 고객 대응이 필요한 항목을 분류한다.
4. 장애 가능성이 있는 기술 이슈를 따로 표시한다.
5. 보고서 초안을 작성한다.
6. 누락된 항목이 없는지 검토한다.
7. 최종 보고서를 생성한다.

에이전트 구조에서는 AI가 단순히 “답변 생성”만 하지 않는다.
목표를 달성하기 위해 계획, 실행, 관찰, 수정을 반복한다.

에이전트는 혼자 똑똑한 AI가 아니라, LLM + 도구 + 메모리 + 실행 루프로 구성된 프로그램이다.

 

6. 워크플로우 엔지니어링

워크플로우 엔지니어링은 AI 작업을 정해진 절차로 고정하는 단계다.

에이전트가 너무 자유롭게 움직이면 실무에서는 예측하기 어렵다. 그래서 업무 절차를 정해진 흐름으로 설계한다. 예를 들어 “입력 수집 → 문서 검색 → 요약 → 검증 → 승인 → 발송”처럼 단계별 흐름을 만든다. n8n, Make, LangGraph 같은 도구가 여기에 연결된다. 주니어 개발자는 이 단계에서 업무 프로세스를 코드나 자동화 흐름으로 바꾸는 능력을 배워야 한다.

에이전트가 자유롭게 판단하면 유연하지만, 실무에서는 예측하기 어렵다. 그래서 업무 흐름을 명확히 설계한다.

예시는 다음과 같다.

[1단계] 프로젝트 이슈 조회
        ↓
[2단계] 이슈 유형 분류
        - 일정
        - 품질
        - 고객 요청
        - 인프라
        ↓
[3단계] 위험도 산정
        - 상
        - 중
        - 하
        ↓
[4단계] 보고서 초안 생성
        ↓
[5단계] 형식 검증
        ↓
[6단계] PM 검토 요청
        ↓
[7단계] 최종 보고서 저장

 

이것을 n8n으로 만든다면 다음과 같은 흐름이 된다.

Schedule Trigger
→ DB에서 이슈 조회
→ LLM으로 이슈 분류
→ LLM으로 위험도 판단
→ 보고서 생성
→ Google Docs 또는 Notion 저장
→ Slack으로 PM에게 알림

워크플로우 엔지니어링의 핵심은 AI가 모든 것을 임의로 하게 두지 않고, 업무 절차 안에서 안정적으로 동작하게 만드는 것이다.

 

7. 평가 엔지니어링

평가 엔지니어링은 AI 결과물이 좋은지 나쁜지 판단하는 기준을 만드는 단계다.

AI 결과물이 좋은지 나쁜지를 감으로만 판단하면 실무에 적용하기 어렵다. 그래서 정확성, 일관성, 누락 여부, 형식 준수, 근거 충실도 같은 평가 기준이 필요하다. 예를 들어 RAG 시스템이라면 “답변이 문서 근거와 일치하는가?”, “없는 내용을 지어내지 않았는가?”, “사용자 질문에 직접 답했는가?”를 평가해야 한다. 이 단계는 AI 품질 관리의 핵심이다.

예를 들어 AI가 주간 리스크 보고서를 만들었다면 다음 기준으로 평가할 수 있다.

평가 항목기준

정확성	입력된 이슈와 다른 내용을 만들지 않았는가
누락 여부	중요한 이슈가 빠지지 않았는가
형식 준수	정해진 보고서 구조를 지켰는가
위험도 판단	상·중·하 구분이 합리적인가
근거 충실도	판단 이유가 입력 데이터와 연결되는가
문체	임원 보고에 적합한 문어체인가

간단한 평가 프롬프트는 다음과 같다.

아래 AI가 작성한 주간 리스크 보고서를 평가하라.
평가 기준은 정확성, 누락 여부, 형식 준수, 위험도 판단, 근거 충실도이다.
각 항목을 1점에서 5점으로 평가하고, 수정이 필요한 부분을 제시하라.
입력 데이터에 없는 내용을 만들어낸 경우 반드시 지적하라.

이 단계가 중요한 이유는 AI 시스템을 실무에 적용할 때 품질을 측정할 수 있어야 개선도 가능하기 때문이다.

 

8. LLMOps / AI 운영 엔지니어링

LLMOps는 AI 시스템을 만들고 끝내는 것이 아니라, 계속 운영하고 개선하는 단계다.

AI 기능을 만들고 끝내는 것이 아니라, 계속 운영하고 개선하는 단계다. 프롬프트 버전, 모델 버전, RAG 문서, 사용자 로그, 실패 사례, 평가 결과를 관리한다. 일반 웹 서비스에 DevOps가 필요하듯이, AI 서비스에는 LLMOps가 필요하다. 주니어 개발자는 로그, 모니터링, 배포, 버전 관리, 피드백 반영을 익혀야 한다.

예를 들어 주간 보고서 자동화 시스템을 운영한다면 다음 정보를 관리해야 한다.

프롬프트 버전: report_prompt_v1.3
모델: qwen3:4b
컨텍스트 소스: project_issues 테이블
실행 일시: 2026-06-20 09:00
사용자 요청: 이번 주 리스크 보고서 생성
생성 결과 파일: weekly_report_20260620.md
평가 점수: 4.2 / 5.0
오류 여부: 없음
사용자 피드백: 고객 요청 항목을 더 구체적으로 작성 필요

이 데이터를 남겨야 나중에 다음 질문에 답할 수 있다.

왜 이번 보고서 품질이 낮았는가?
어떤 프롬프트 버전이 가장 안정적인가?
모델을 바꾼 뒤 결과가 좋아졌는가?
특정 유형의 이슈를 AI가 자주 누락하는가?
사용자 피드백이 반복되는 부분은 무엇인가?

LLMOps는 개발자 관점에서 보면 로그, 모니터링, 버전 관리, 평가, 피드백 반영이다.

 

9. AI 제품화 / 비즈니스 엔지니어링

마지막은 기술을 실제 제품이나 서비스로 바꾸는 단계다.

기술을 실제 서비스나 수익 모델로 바꾸는 단계다. 단순히 “AI 기능이 된다”가 아니라, 누가 쓰는지, 어떤 문제를 해결하는지, 반복 사용 가치가 있는지, 비용 대비 효과가 있는지를 판단해야 한다. 예를 들어 블로그 자동화 도구, 업무 문서 요약 시스템, 사내 RAG 챗봇, 고객 응대 자동화 서비스가 여기에 해당한다.

예를 들어 지금까지 만든 기능을 단순한 스크립트로 두면 개인 자동화다.
하지만 다음처럼 만들면 제품이 된다..

서비스명:

AI 프로젝트 리스크 리포터

주요 기능:

1. 프로젝트 이슈 자동 수집
2. 일정 지연 가능성 분석
3. 고객 대응 필요 항목 분류
4. 주간 보고서 자동 생성
5. 위험도 상·중·하 표시
6. PM 검토 후 최종 보고서 저장
7. 이전 주차와 비교
8. 반복 리스크 패턴 분석

사용 대상:

- SI 프로젝트 관리자
- 개발팀 리더
- PMO 조직
- 유지보수 운영팀
- 고객 대응 담당자

비즈니스 가치:

- 주간 보고서 작성 시간 단축
- 리스크 누락 감소
- 보고 품질 표준화
- 프로젝트 이력 관리
- 신규 PM 교육 자료로 활용

이 단계에서는 기술보다 중요한 질문이 있다.

누가 사용할 것인가?
사용자가 매주 반복해서 쓸 이유가 있는가?
기존 방식보다 시간이 줄어드는가?
결과물을 신뢰할 수 있는가?
비용 대비 효과가 있는가?

AI 제품화는 단순히 “AI 기능을 붙이는 것”이 아니라, 반복 사용 가능한 문제 해결 구조를 만드는 것이다.

 

전체 흐름을 한 줄로 정리하면 다음과 같다.

프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링 → 툴 엔지니어링 → 에이전트 엔지니어링 → 워크플로우 엔지니어링 → 평가 엔지니어링 → LLMOps → AI 제품화

프롬프트 엔지니어링
→ AI에게 좋은 지시를 한다.

컨텍스트 엔지니어링
→ AI가 참고할 정보를 잘 넣어준다.

하네스 엔지니어링
→ 여러 입력과 프롬프트를 반복 실험한다.

툴 엔지니어링
→ AI가 DB, API, 파일 같은 도구를 사용하게 한다.

에이전트 엔지니어링
→ AI가 목표를 보고 작업 순서를 판단하게 한다.

워크플로우 엔지니어링
→ AI 작업을 안정적인 업무 절차로 만든다.

평가 엔지니어링
→ AI 결과물을 기준에 따라 점검한다.

LLMOps
→ AI 시스템을 운영하고 개선한다.

AI 제품화
→ 기술을 실제 서비스와 비즈니스로 만든다.

 

처음부터 모든 단계를 완벽히 할 필요는 없다. 이 모든 것을 한 번에 익히려고 하면 어렵다. 먼저 프롬프트로 AI에게 명확히 지시하는 연습을 하고, 그다음 문서와 데이터를 넣어 컨텍스트를 설계한다. 이후 Python으로 입력과 출력을 자동화하면서 하네스 개념을 익히고, API와 데이터베이스를 연결하면서 툴 사용 구조로 넘어가면 된다.

AI 개발자는 먼저  AI에게 잘 묻는 개발자가 되고, 다음에는 AI가 참고할 정보를 설계하는 개발자가 되며, 마지막에는 AI가 실제 업무를 수행하는 시스템을 만드는 개발자로 성장하는 것이다. 단순히 모델을 호출하는 사람이 아니라, 입력, 맥락, 도구, 절차, 평가, 운영을 함께 설계하는 사람으로 성장해야 한다.

1단계: 프롬프트 작성 연습
2단계: 문서나 데이터를 함께 넣는 컨텍스트 실습
3단계: Python으로 입력·출력 자동화
4단계: API나 DB 연결
5단계: 간단한 워크플로우 구성
6단계: 결과 평가 기준 만들기
7단계: 로그와 버전 관리 추가
8단계: 작은 내부 도구로 제품화