하네스 엔지니어링으로 강의사이트 25개 만든 후기

강의사이트 퍼블리싱을 직접 만들어야 하는 일이 생겼습니다.

페이지 수가 적지 않았고, 디자인 컨셉을 페이지마다 일관되게 유지해야 했으며, 반복 작업이 많아 손으로 하기에는 부담이 컸습니다.

이번에는 작업 자체를 하지 않고, 작업이 자동으로 굴러가는 환경을 먼저 만드는 방향으로 접근했습니다. 요즘 한창 회자되는 하네스 엔지니어링이라는 개념을 강의사이트 퍼블리싱에 적용해본 것입니다.

결론부터 말씀드리면, 명령 한 줄로 25개의 강의사이트 페이지가 한 번에 만들어졌습니다. 이 글은 그 과정을 정리한 후기입니다.

---

강의사이트 퍼블리싱, 손으로 하면 며칠 작업이었습니다

상황을 먼저 설명드리겠습니다.

메인, 강의 목록, 강의 상세, 결제, 마이페이지, 수강 내역, 공지사항 같은 기본 페이지부터 시작해서, 강사 소개, 후기, 자주 묻는 질문, 약관, 에러 페이지, 모달과 같은 부가 페이지까지 합치면 페이지가 25개에 달했습니다.

페이지 하나하나가 어려운 작업은 아니었습니다. 이미 메인 디자인 시안이 잡혀 있었고 각 페이지마다 구조가 비슷한 듯 다른 케이스가 많았습니다. 이 작업을 일일이 손으로 하면 꽤 오래 걸리는 작업입니다.

이 작업을 빠르게 끝내기 위해서 최근에 많이 회자되는 하네스 엔지니어링으로 작업해보기로 했습니다.

---

하네스 엔지니어링이 뭔가요

하네스 엔지니어링은 단순히 프롬프트를 잘 쓰는 기술이 아닙니다.

사람의 개입을 최소화한 상태에서 AI 에이전트가 알아서 일정한 결과물을 만들어내도록 환경 자체를 설계하는 작업입니다. 즉 "AI에게 일을 시키는 시스템"을 미리 짜놓는 일이라고 보시면 됩니다.

클로드 코드 환경에서는 이 매뉴얼이 스킬, 에이전트, 훅, 슬래시 명령어, 설정 파일로 구성됩니다. 어떤 작업을 할 때 어떤 룰을 따라야 하는지를 스킬로 정의하고, 작업의 흐름을 에이전트로 나누고, 권한과 자동 실행 규칙을 설정 파일에 박아두는 식입니다.

이 환경을 한 번 잘 깔아두면, 다음부터는 명령 한 줄만 입력해도 결과물이 일관되게 흘러나옵니다. 하네스 엔지니어링이 가지는 진짜 가치는 여기에 있습니다. 같은 일을 두 번째 시킬 때부터 그 차이가 드러납니다.

저는 이번 강의사이트 작업을 이 접근의 첫 실전 적용 사례로 잡았습니다.

---

하네스 설계 — 스킬 세 개와 에이전트 두 개

하네스 설계의 핵심은 작업을 잘게 쪼개고, 각 단위를 어떤 컴포넌트가 책임질지 정하는 것입니다. 저는 강의사이트 퍼블리싱에 필요한 작업을 다음과 같이 분리했습니다.

스킬 1

페이지 생성

어떤 페이지든 받아서 정해진 컴포넌트 라이브러리, 디자인 토큰, 레이아웃 규칙을 따라 페이지 코드를 생성합니다. 입력은 페이지 이름과 페이지 목적, 출력은 완성된 페이지 코드 파일입니다. 이 스킬 하나에 강의사이트 전체의 디자인 컨벤션을 박아두었습니다.

스킬 2

코드 검증

생성된 코드가 정해진 컨벤션을 지켰는지 확인합니다. 컴포넌트 import가 올바른지, 디자인 토큰을 하드코딩 없이 사용했는지, 반응형 클래스가 빠지지 않았는지 같은 항목을 정적으로 점검합니다.

스킬 3

디자인 검증

가장 까다로운 단계였습니다. 디자인을 항목별로 점수를 매기고, 70점 이하면 다시 만들도록 지시합니다. 색상 일관성, 여백, 폰트 위계, 컴포넌트 정렬, 반응형 적정성 같은 항목에 점수를 부여합니다.

스킬을 만든 다음에는 에이전트로 흐름을 묶었습니다.

에이전트 1 — 생성자
스킬 1과 스킬 2를 담당합니다. 페이지를 만들고 코드 레벨 검증까지 마친 결과물을 다음 단계로 넘깁니다.

에이전트 2 — 검증자
스킬 3을 담당합니다. 생성자가 넘긴 결과물의 디자인 점수를 매기고, 기준 미달이면 다시 만들도록 지시합니다.

이 분리가 시스템 설계의 핵심이었습니다. 만드는 역할과 검사하는 역할을 다른 에이전트로 분리해야, 만드는 사람이 자기가 만든 걸 후하게 평가하는 함정을 피할 수 있다고 판단했기 때문입니다.

---

하네스 테스트 — 한 페이지로 시스템을 보정했습니다

하네스를 처음 짜고 바로 25개 페이지를 돌리는 건 위험합니다. 시스템에 잘못된 부분이 있으면 25개 페이지에 같은 오류가 동시에 발생합니다.

그래서 저는 단계를 나눴습니다. 먼저 퍼블리싱할 페이지 목록을 마크다운 파일로 정리했습니다. 페이지 이름, 페이지 목적, 필요한 섹션, 참고할 디자인 시안 위치까지 한 파일에 모았습니다. 이 파일이 하네스의 입력 자료가 됩니다.

그다음 페이지 목록 중에서 가장 평범한 페이지 하나를 골라서 먼저 만들어보라고 지시했습니다. 한 페이지를 돌리면서 발견된 작은 문제들을 정리했습니다. 어떤 컴포넌트가 자꾸 잘못된 형태로 사용되는지, 어떤 디자인 토큰이 누락되는지, 검증자가 어떤 기준으로 점수를 깎는지를 확인했습니다.

이 과정에서 발견된 문제들은 곧바로 스킬에 반영했습니다. 컴포넌트 사용 예시를 추가하고, 자주 빠지는 클래스를 명시하고, 검증 항목의 기준을 더 구체화했습니다. 한 페이지를 만들고 보정하는 데 시간이 꽤 걸렸지만, 이 시간이 하네스를 짤 때 가장 중요한 투자라고 생각합니다.

한 페이지에서 시스템이 안정적으로 돌아가는 것을 확인한 다음에야 비로소 전체 페이지로 확장했습니다. 보정 단계 없이 25개를 한 번에 돌렸으면, 다시 25개를 손보는 데 더 많은 시간이 들었을 겁니다.

---

결과 — 명령 한 줄로 25개 페이지가 한 번에

보정이 끝난 후, 페이지 목록 파일을 통째로 던지면서 일괄 작업을 지시했습니다.

생성자 에이전트가 페이지마다 코드를 만들고, 코드 검증을 마친 후 검증자 에이전트에게 넘겼습니다. 검증자는 디자인 점수를 매기고 기준 미달이면 재작업을 요청합니다. 이 흐름이 페이지 단위로 반복되면서 25개 페이지가 차례로 완성되었습니다.

25개 페이지

명령 한 줄 던져두고 다른 일 하는 사이에 완성

명령 한 줄을 던져두고 다른 일을 하는 사이에 끝났습니다.

이전에도 여러 차례 에이전트로 코딩을 많이 했었지만 이렇게 한 번에 여러 페이지를 통째로 맡긴 건 처음이었습니다.

결과물은 모두 완성되어 있었고, 검증자가 검증 단계에서 평가한 내용을 살펴봤는데 결과물에 굉장히 관대했습니다.

---

실제 만들어진 강의사이트 페이지

하네스가 만들어낸 페이지 일부를 그대로 보여드립니다. 디자인 토큰과 컴포넌트 규칙이 페이지마다 동일하게 적용되어 있다는 점을 직접 확인하실 수 있습니다.

데스크톱 화면 10개

메인, 강의 목록, 강의 상세, 수강 신청, 신청 완료, 마이페이지, 수강 화면, 블로그, 블로그 상세, 후기 페이지입니다.

모바일 화면 9개

동일한 디자인 시스템이 모바일에서도 그대로 적용됩니다.

색상, 여백, 폰트 위계, 컴포넌트 사용이 모든 페이지에서 일치합니다.

---

꿀팁 — 검증자 에이전트는 비관적으로 만드세요

이번 작업에서 가장 큰 교훈이 있다면 검증자 에이전트의 성격 설정입니다.

작업이 끝난 후 디자인 검증 결과를 살펴봤는데, 대부분 페이지가 85점 이상으로 평가되어 있었습니다. 70점 기준선을 한 번도 건드리지 않은 것입니다. 즉, 재작업 단계가 한 번도 발동되지 않았습니다.

처음에는 시스템이 잘 돌아갔다고 좋아했는데, 결과물을 다시 살펴보니 검증자가 결과물에 너무 관대했다는 사실을 알게 되었습니다. 사람이 보면 명백히 어색한 부분도 검증자는 70점은 넘는다고 평가했습니다. 검증자가 자기 기준에서는 합격이라고 판단한 것이지만, 실제 사용자 기준으로 보면 합격이 아니었던 것입니다.

💡 나중에 알게 된 사실인데, 검증자 에이전트는 의도적으로 비관적으로 설계해야 한다는 것입니다. 점수 기준을 더 박하게 잡고, 작은 흠도 점수에 반영하도록 만들어야 합니다. 평가자가 후하면 시스템 전체가 후해지고, 평가자가 박하면 결과물이 한 단계 더 다듬어집니다.

이 교훈은 하네스 설계 전반에 적용된다고 봅니다. 생성자보다 검증자를 짜는 데 더 신경 써야 하고, 검증자는 항상 사용자보다 까다로워야 합니다. 그래야 시스템에서 나온 결과물이 사용자에게 도달했을 때 합격선을 넘습니다.

다음번에 하네스를 설계할 때는 검증자 프롬프트의 첫 문장에 "당신은 매우 깐깐한 평가자입니다"라고 박아둘 생각입니다.

---

마무리 — 하네스도 결국 업무 자동화 파이프라인입니다

이번 작업을 정리하면서 든 생각이 있습니다.

하네스 엔지니어링이라는 말이 새롭고 멋있게 들리지만, 본질은 결국 스킬과 에이전트를 이용한 업무 자동화 파이프라인이라는 점입니다. 작업을 잘게 쪼개고, 각 단계의 책임을 명확하게 분리하고, 자동으로 흘러가게 묶는다는 점에서 전통적인 프로세스 설계와 같은 원리를 따릅니다.

 

다른 점이 있다면, 각 단계의 실행 주체가 사람이나 외부 시스템이 아니라 AI 에이전트라는 것뿐입니다. 그리고 이 에이전트가 자연어로 룰을 받아들이기 때문에, 시스템 설계와 운영 비용이 전통적인 자동화보다 훨씬 낮습니다.

1인 개발사 입장에서 이 변화는 결정적입니다. 예전에는 자동화 시스템을 짜는 비용이 자동화로 얻는 시간을 넘어서는 경우가 많았습니다. 하지만 이 접근은 그 비용을 크게 낮춰줍니다. 한 번 잘 깔아둔 하네스는 그다음 프로젝트에서도 재사용이 가능합니다.

 

물론 시작은 쉽지 않습니다. 어떤 작업을 하네스로 만들 가치가 있는지 판단해야 하고, 작업을 어떻게 쪼갤지 설계해야 하고, 검증자를 어떻게 비관적으로 만들지 고민해야 합니다. 그래도 한 번 깔아두면 두 번째 프로젝트부터 효과가 분명하게 나타납니다.

 

같은 AI 도구를 써도, 그냥 프롬프트만 던지는 사람과 하네스 엔지니어링으로 시스템을 짜는 사람의 생산성 차이는 갈수록 벌어질 것이라고 생각합니다. 1인 개발사일수록, 혼자 운영하는 서비스가 많은 사람일수록, 이 차이는 곧 매출의 차이로 이어진다고 봅니다.

 

다음 작업에서는 검증자를 더 비관적으로 만들고, 다시 한번 이 접근의 효과를 확인해볼 생각입니다.