최근에 개발 방법이 AI를 이용한 개발 방법으로 많이 변화해 왔다.
이전에는 VI 에디터와 메모장을 이용하여 개발을 하였고, 이후 노트패드, 에디터 플러스와 같은 아주 간단한 에디터 도구들의 등장! 자동완성을 도와주고 개발을 편리하게 해주는 이클립스와 인텔리제이의 등장까지.. 이때마다 들었던 이야기는 우수갯소리 였지만.
IDE 즉 eclipes 와 Intellij 를 사용할때 이런 말들을 하곤 했다.
”진정한 개발자라면 메모장을 열어서 개발해야 한다. 자동완성 해주는 eclipes 와 intellij 를 사용하면 개발이 퇴화한다”
하지만 이런말들은 그저 우수갯 소리였고, 이클립스나, 젯브레인에서 제공하는 유료툴인 인텔리 제이를 사용하였다.
지금은 또 한번 개발의 전환점을 맞이 하고 있는 것이라 생각된다.
AI 개발은 단순 웹브라우저 채팅 → cursor, windsurf → 이후 cli 도구를 이용한 → claude, gemini, codex 도구들을 사용하는 방향으로 발전되어 왔고 이 도구들을 좀더 잘 사용 할 수있는 방법을 탐구하기 시작하였으며 프롬프트엔지니어링 → 스킬셋 작성 → 하네스엔지니어링 단계까지 온것으로 보인다.
하네스란?
간단히 말해 하네스라는 용어 말이나 동물들에게 얻는 안장,고삐등의 구속구를 뜻한다. 이처럼 AI를 사용할때 우리가 원하는 방향대로 가지 않거나, 지침서 대로 가지 않을때 AI가 올바른 방향으로 올 수 있도록 하게 해주는것을 하네스 엔지니어링이라 뜻한다.
“그럼 하네스를 어떻게 쓰는거지?” 라고 생각할수 있는데 결국 claude, codex, gemini 를 사용하며 텍스트로, md 파일로 각각의 툴에게 이야기 했던 모든 것들이 하네스라고 해도 된다. 물론 AI 전문가처럼 md 파일을 만들어서 이때는 이렇게, 저때는 저렇게라고 하진 않았지만. 이모든것들이 메모리에 남고 이를 바탕으로 AI 가 동작됨으로 알게 모르게 모두 하네스엔지니어링을 하고 있던 것이다.
그럼 이제 하네스엔지니어링 즉 AI를 얼마나 더 내가 원하는형태로 잘 이용하느냐에 대한 생각으로 넘어가게된다. 구글의 유명하신 Addy Osmani(애디 오스마니) 가 (https://news.hada.io/topic?id=28294) 작성한 스킬셋이 AI 코딩에이전트를 사용한 프로덕션급의 스킬셋으로 표본이 되고 있다.
개발 생명주기를 보면 보통 방법론에서도 “분석 → 설계 → 개발 → 테스트 → 배포” 이렇게 되듯이 대부분의 스킬셋들도 비슷한 구조를 사용한다. 애디 오스나미가 추구하는 개발 생명주기를 살펴보면 해당 범위에서 크게 벗어나지 않으며, 좀더 세분화 되어 있는것을 볼수 있다.
DEFINE PLAN BUILD VERIFY REVIEW SHIP
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ Idea │ ───▶ │ Spec │ ───▶ │ Code │ ───▶ │ Test │ ───▶ │ QA │ ───▶ │ Go │
│Refine│ │ PRD │ │ Impl │ │Debug │ │ Gate │ │ Live │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
/spec /plan /build /test /review /ship
애디 오스마니가 제시한 개발 생명주기
- /spec 무엇을 만들지 정의
- /plan 구현 방법 계획
- /build 점진적 구현
- /test 동작 증명
- /review 머지 전 품질 게이트
- /code-simplify코드 단순화
- /ship 프로덕션 배포
이 생명주기를 따르며, 21개의 세부 스킬이 존재한다. 해당 개발 생명주기에 따라 별개의 skill들이 주입되며 각각의 스킬에 적혀있는 문서를 참고하여 플로우를 진행하게 된다. 아래는 세부스킬에 대한 상세 설명이다. 내가가진 프로젝트와 비교해 보았다.
Skill 핵심 내용 프로젝트비교 표
| 1 | idea-refine | 모호한 아이디어 → 구체적 제안으로 발산/수렴 | ❌ 없음 |
|---|---|---|---|
| 2 | spec-driven-development | 코드 전에 PRD 작성 | 🔶 analyze-requirements |
| 3 | planning-and-task-breakdown | 스펙 → 작은 태스크 분해 (AC 포함) | 🔶 development-plan |
| 4 | incremental-implementation | 얇은 수직 슬라이스, 기능 플래그 | ❌ 없음 |
| 5 | test-driven-development | Red-Green-Refactor, 테스트 피라미드 | ✅ development.md에 반영 |
| 6 | context-engineering | 에이전트에 적시에 적절한 정보 제공 | 🔶 pipeline.md |
| 7 | source-driven-development | 공식 문서 기반 결정, 인용 필수 | ❌ 없음 |
| 8 | frontend-ui-engineering | 컴포넌트, 디자인 시스템, WCAG | ❌ 해당 없음 (백엔드) |
| 9 | api-and-interface-design | 계약 우선 설계, Hyrum's Law | ❌ 없음 |
| 10 | browser-testing-with-devtools | Chrome DevTools MCP | ❌ 해당 없음 |
| 11 | debugging-and-error-recovery | Triage 5단계 | ✅ development.md 모드2에 반영 |
| 12 | code-review-and-quality | 5축 리뷰 (심각도 라벨) | 🔶 test-qa.md |
| 13 | code-simplification | Chesterton's Fence (동작 보존) | ❌ 없음 |
| 14 | security-and-hardening | OWASP Top 10, 인증, 시크릿 | 🔶 test-qa QA 체크리스트 |
| 15 | performance-optimization | 측정 우선, Core Web Vitals | ❌ 없음 |
| 16 | git-workflow-and-versioning | Trunk-based, atomic commit | 🔶 git-commit-korean 스킬 |
| 17 | ci-cd-and-automation | Shift Left, 품질 게이트 파이프라인 | ❌ 없음 |
| 18 | deprecation-and-migration | 필수 vs 권고 폐기 관리 | ❌ 없음 |
| 19 | documentation-and-adrs | ADR, API 문서 표준 | 🔶 exec-plans (일부) |
| 20 | shipping-and-launch | 출시 체크리스트, 단계적 롤아웃 | ✅ deploy-prep |
| 21 | using-agent-skills | 메타 스킬 (사용법 설명) | ❌ 없음 |
이렇게 많은 스킬들이 있지만 필자의 생각엔, 모든것을 다 따르는것보단 각자의 프로젝트에 맞춰 필요한 부분을을 채워 나가는게 맞다고 생각된다. 결국 하네스엔지니어리이라는 것은 사람이 만들어낸 또 하나의 용어이며 이를 방법론적으로 만들어 나가고 있는 단계인것 같다. 결국엔 이것을(AI 코드에이전트를 잘사용할수있게) 만들고 이를 잘 조율해주는 개발자나 관리자로 나가가는 방햐이 옳은길이 아닌가 생각해본다.
'소프트웨어공학' 카테고리의 다른 글
| software design pattern (0) | 2021.06.01 |
|---|---|
| UML diagram 무료툴 추천 (flowchart 무료툴) (0) | 2021.05.25 |
| 소프트웨어 공학 개요 (0) | 2008.03.21 |