이번에는 AI를 이용한 소프트웨어 개발의 개념과 용어에 대해 정리해 보았습니다.

최근까지 육아 휴직을 다녀왔거나, 레거시(Legacy) 개발 방식 및 기술을 다루는 프로젝트에 있었다는 경위도 있어, AI에 관해서는 우라시마 타로(시대에 뒤처진) 상태라 내심 상당히 초조했습니다... 무엇인가를 할 때 뼈대를 이해하지 않으면 행동으로 옮기지 못하는 성격이라, 일단 AI 주변의 개념·용어를 시계열을 포함하여 정리해 보았습니다.

부끄럽지만 「하네스 엔지니어링(Harness Engineering)?」 「Gem?」 같은 상태였지만, 정리함으로써 이해가 깊어져 조금 개운해졌습니다. 저와 같은 시대에 뒤처진 & AI 초보 엔지니어 분들에게 참고가 된다면 좋겠습니다.

• 9년 차 WEB 엔지니어
• 육아 휴직 및 레거시 현장 장기 체류로 인해 AI에 관해 시대에 뒤처진 상태

지금까지 AI를 이용한 소프트웨어 엔지니어링의 변천사를 대략적으로 되돌아본다.

GitHub Copilot이 등장. 다만 이때의 AI는 어디까지나 「자동 완성 도구」. 어디까지나 인간이 얼마나 잘 지시를 내리는가(프롬프트를 잘 작성하는가)가 중요했다.

#프롬프트 엔지니어링 (Prompt Engineering)

ChatGPT가 보급된다. 할루시네이션 (Hallucination)을 방지하기 위해 RAG로 외부 지식을 제공하고, TDD로 AI가 작성한 코드를 기계적으로 검증하기 시작했다.

#RAG #TDD #DDD

자연어만으로 애플리케이션을 개발할 수 있게 된다. **바이브 코딩 (Vibe Coding)**이 유행한다. Gem 등으로 AI를 커스터마이징하여 문맥(Context)을 갖게 한다.

#바이브코딩 #Gem

Cursor나 Cline 같은 AI 에이전트형 IDE가 보급된다. 프롬프트 그 자체보다 「AI에게 어떤 파일(≒문맥)을 읽게 할 것인가」가 중요해진다.

#컨텍스트 엔지니어링 (Context Engineering) #MCP

AI가 자율적으로 코드를 작성하기 때문에, 인간은 「Markdown으로 사양서를 작성한다」, 「AI가 테스트·실행할 수 있는 환경(하네스)을 정비한다」는 역할로 시프트(Shift)한다.

#AI구동개발 #사양구동개발 #하네스엔지니어링

AI의 성능 향상에 맞춰 엔지니어링 기법도 변화하며, 그에 따라 다양한 용어도 생겨났다.

또한 기존의 TDD나 DDD도 형태를 바꾸어 재평가 및 중요시되고 있다.

AI에 대하여,

• 어떻게 질문할 것인가?
• 어떻게 지시문을 작성할 것인가?

의 테크닉.

현재는 모델의 진화로 인해 공들여 만든 복잡한 프롬프트는 불필요해지고 있다.

AI에 대하여,

• 어떤 정보(파일, 로그, 사양 등)를 전달할 것인가?

를 설계하는 것.

AI의 컨텍스트 윈도우(Context Window, 한 번에 읽을 수 있는 글자 수)가 거대해진 현재는, 능숙한 지시를 내리는 것보다 필요한 문서를 과부족 없이 읽게 하는 것이 결과를 좌우한다.

2024년경에 등장한 버즈워드(Buzzword). 사소한 것은 신경 쓰지 않고, AI와 대화하며 직관(Vibes)으로 코드를 작성하는 스타일. 프로토타입 작성에는 좋지만, 운영 환경에는 적합하지 않다.

인간 또는 AI가 먼저 테스트 코드를 작성하고, 그 테스트가 통과하도록 AI에게 구현하게 한다.

AI에 의한 코딩은 「그럴듯한 버그」를 만들어내는 경우가 많다. 그것들을 전부 인간이 리뷰하기에는 한계가 있다. 그렇기 때문에 「테스트 통과 = 올바름」이라는 자동 검열로 만들 수 있는 테스트 주도 개발(TDD)이 재평가되고 있다.

비즈니스 업무 지식(=도메인)을 중심으로 소프트웨어를 설계한다.

AI는 일반적이고 평범한 아키텍처를 채택하려는 경향이 있다. 프로젝트(PJ) 고유의 비즈니스 규칙을 AI에게 이해시키기 위한 수법으로서, 도메인 주도 설계(DDD)의 「유비쿼터스 언어(Ubiquitous Language, 공통 언어)」를 인풋(Input)하는 것이 중요시되고 있다.

AI를 단순한 보완 도구가 아니라, 설계구현테스트~리팩터링을 담당하는 자율형 에이전트(Agent)로 다루는 개발. 인간은 코드를 작성하는 시간을 줄이고, 「AI의 매니지먼트」, 「리뷰」에 전념한다.

인간이 엄격한 사양서를 작성하고, 그것을 바탕으로 AI에게 구현하게 한다. 바이브 코딩과는 대척점에 있는 수법.

생각하는 방식으로는 기존의 폭포수(Waterfall) 개발에서의 요구사항 정의·설계의 유사 형태. AI는 매우 우수하지만 어디까지나 지시 대기 상태이므로, 명확한 지시를 전달함으로써 정확하게 움직이게 한다.

AI가 코딩·테스트·실행하기 위한 안전한 환경(=하네스)을 구축하는 것. 하네스(Harness)란 일본어로 말하면 생명줄이나 안전벨트를 의미한다.

예를 들어 AI가 멋대로 운영 DB를 날려버리지 않도록, 샌드박스(Sandbox) 환경을 마련하고, Linter나 CI/CD를 정비하여 AI가 자율적으로 시행착오를 겪을 수 있도록 하는 엔지니어링.

AI 주도 개발(AI-driven development)에서는 AI가 가장 읽기 쉬운 경량 포맷인 Markdown이 개발 자료의 주역이다. 이것들은 AI에게 프로젝트(PJ)의 문맥(=컨텍스트(Context))을 이해시키기 위한 것이다.

• 프로젝트의 목적
• 대상 사용자
• 충족해야 할 기능 요구사항 · 비기능 요구사항

등을 기재한다. AI가 무엇을 만들어야 하는지 놓치지 않도록 하기 위함이다.

# TODO 앱 요구사항 정의
## 프로젝트의 목적
사용자가 일상의 태스크를 간편하게 기록 · 관리하고 실행을 촉진하기 위한 TODO 애플리케이션을 구축한다.
...

• DB 스키마
• API의 인터페이스(IF)
• 화면 구성
• 아키텍처(Architecture) 방침

등을 기재한다. AI에게 "이런 구조로 만들어 주세요"라고 강제한다.

# TODO 앱 설계서
## 기술 스택
- React
...
```typescript
type Task = {
id: string; // UUID
title: string;
completed: boolean;
createdAt: number; // Unix Timestamp
}

구현 절차를 단계별(Step-by-step)로 기재한다.

AI 에이전트(AI Agent)는 이 파일에 기재된 태스크에 체크✅를 해나가며 자율적으로 작업을 진행한다.

구현 태스크 목록

Phase 1: 초기 셋업

• Vite를 사용하여 React+TypeScript 프로젝트를 생성한다
  ...

※ AI 에이전트가 이 마크다운의 체크박스 `[ ]`를 스스로 `[x]`로 바꿔가며, 자율적으로 태스크를 소화하는 이미지.

- 변수명은 카멜 케이스(Camel Case)
- 에러 핸들링(Error Handling)은 ◯◯로 한다

등을 기재한다. AI에 대한 프로젝트(PJ) 고유의 동작이나 규칙을 기술한다.

코딩 규약 및 AI를 위한 지시

언어와 프레임워크

• 항상 TypeScript를 사용하며, 엄격한 타입 정의(any 금지)를 수행할 것.
  ...

AI에게,

- 커맨드 라인(Command Line)에서 사용할 수 있는 도구
- DB 접속 스크립트 사용법

등, AI가 실행 가능한 조작 방법을 가르친다.

도구 및 커맨드 라인 조작 매뉴얼

패키지 관리

본 프로젝트에서는 패키지 매니저로 npm을 사용합니다(yarn이나 pnpm은 사용하지 마세요).
...

AI에게 사내 문서나 전체 코드베이스를 검색하게 하고, 그 결과를 바탕으로 답변하게 하는 기술.

예를 들어 "이 PJ의 인증 플로우(Flow)에 대해 알려줘"라고 물으면, 백그라운드에서 RAG가 작동하여 관련 파일을 읽어 들여 정확한 답변을 내놓는 식이다.

특정 역할이나 컨텍스트를 부여한 커스텀 AI 어시스턴트를 만드는 기능. OpenAI의 **Custom GPTs**도 마찬가지다.

예를 들어,

- 사내 코딩 규약을 모두 읽힌 코드 리뷰어 Gem
- 요구사항 정의서의 대화 상대(Wall-hitting partner)가 되는 Gem

등을 만들어 활용할 수 있다.

AI와 외부 도구(PC의 로컬 파일이나 사내 DB, Slack, GitHub 등)를 표준 규격으로 연결하는 오픈 프로토콜.

AI를 브라우저 안에서 사용하는 것뿐만 아니라, AI 에이전트가,

- 직접 로컬의 PostgreSQL 내부를 확인하거나
- Jira 티켓을 읽게 하는

것과 같은 일을 심리스(Seamless)하고 안전하게 할 수 있게 되었다.

AI가 급격히 진화하고 있기에, 저도 "어쨌든 도구를 만져봐야 해", "내 업무에도 도입해야 해"라며 초조해했습니다. 그래서 잠시 멈춰 서서, 일단 지금까지의 경위와 탄생한 개념들을 되돌아보며 이해한 뒤에 도구를 만져보니, 저의 기존 업무와 AI 도구 사이의 가교를 놓기가 훨씬 수월해졌다는 실감이 듭니다.

더 이상 업무에서 코드를 쓸 수 없게 되는 것(※금지된 것은 아니지만)은 상당히 쓸쓸한 일이고, 직업을 잃을 불안함도 있습니다. 하지만 과거의 개발과 비교하면 시대가 흐를수록 개발 언어는 자연어에 가까워져 왔기에, 지금 자연어로 소프트웨어 개발이 가능해진 것은 당연한 귀결이며, 일종의 해피엔딩이라고 생각합니다.

오늘 당장 소프트웨어 엔지니어가 불필요해진 것은 아니며, 해야 할 일과 할 수 있는 일은 아주 많습니다! 진화한 소프트웨어 엔지니어링을 다시 한번 즐겨봅시다.