Loading summary...
하네스 엔지니어링이라는 기법을 활용하면 클로드, 코덱스, 제미나이 등 다른 AI 모델을 사용하더라도 동일한 결과물을 얻을 수 있도록 강제할 수 있다. 디자인 시스템 등이 회기화되어 있어 어떤 모델을 사용해도 동일한 아웃풋이 나오도록 설정할 수 있다.
하네스 엔지니어링은 다양한 AI 모델을 사용하더라도 일관된 결과물을 얻을 수 있도록 하는 핵심 기법이다.
디오(DO)의 황현태 대표와 김지훈 FD를 모시고, 실제 현장에서 강건하게 소프트웨어를 빌딩하고 일관성 있는 결과물을 전달하는 방법에 대해 이야기 나눈다. 엔터프라이즈 AX 트렌드에 대한 국가적인 변화에 발맞춰 앞서나가는 두 분과 함께 흥미로운 내용을 공유한다.
AI 현장에서 일관성을 의미하는 몇등성이 중요하게 부각되고 있다. 자세한 사례를 통해 몇등성에 대한 이야기를 나눈다.
강건성 있는 결과물을 얻기 위한 방법으로 하네스 엔지니어링을 소개한다.
하네스 엔지니어링을 시연하기 위해 배달 플랫폼을 예시로 더미 스펙을 가져왔다.
배달 플랫폼은 크게 네 가지 소프트웨어로 구성된다고 가정한다.
고객은 처음에는 고객용 앱만 필요하다고 생각할 수 있지만, 대화를 통해 기사용 앱, 음식점용 앱, 어드민이 필요하다는 것을 알게 된다. FD(Forward Deployed Engineer)로서 고객의 요구사항을 듣고 구성 요소를 쪼개어 각 분류에 적합한 소프트웨어를 판단한다.
요구 사항 분석 -> 플랜 수립 -> 아키텍처 설계 -> 코드 레벨 디자인 설계 -> 린터 기반 코드 검토 -> 결과물 도출의 6단계 플로우를 통해 하네스 엔지니어링을 설명한다.
클로드, 코덱스, 제미나이 등 어떤 AI 모델을 사용하더라도 하네스 엔지니어링 기법을 활용하면 동일한 결과물을 얻을 수 있도록 방향을 강제하거나 조절할 수 있다.
막연한 요구 사항을 검증하기 위해 클로드, 제미나이, 코덱스에 각각 요구사항을 넣는다.
플랜은 세 가지 구성 요소로 이루어져 있다.
다양한 AI 모델을 사용하더라도 하네스 엔지니어링 기법을 사용하면 일관성 있는 결과물을 얻을 수 있다. 프롬프팅을 통해 문서를 작성하고 일관성을 유지한다.
가장 하이레벨한 기획 요소는 컨텍스트, 문제, 해결책(CPS)이다. 어떤 맥락에서 어떤 문제를 겪고 있기 때문에 어떤 솔루션을 제시해야 할지 정리한다.
CPS는 문서 유형 중 하나로, 생각을 정리하는 프레임워크다. SKT 프로젝트에서 팔란티어의 미팅 방식을 참고하여 도입했다. 고객의 문제, 문제에 대한 해결책, 컨텍스트를 CPS 문서로 정리한다.
CPS 문서는 내부용뿐만 아니라 클라이언트 공유용으로도 사용된다. 마크다운 문서를 레이텍 템플릿으로 빌드하여 PDF로 제공한다.
문서는 POC 기간 중 두 번 공유된다.
고객에게는 깃허브 초대하여 CPS 문서를 공유하고 매번 업데이트된 내용을 확인할 수 있도록 한다.
CPS 이후에는 PRD를 작성하고 디자인 단계로 넘어간다. 플랜과 디자인은 밀접하게 연관되어 있다.
PRD 자체를 엄밀히 리뷰하기보다는 산출물을 보고 다양한 레벨에서 리뷰한다. 문서보다는 프로젝트 진행 과정에서의 이야기가 더 중요하다.
전체적인 문서는 프로젝트 주기 내내 업데이트된다. 미팅 로그를 종합하여 CPS를 결정하고, CPS를 종합하여 PRD를 결정하는 방식으로 진행된다.
각 프로젝트마다 원칙을 세운다. 예를 들어 에이전트 프로젝트에서는 휴먼인더루프나 할루시네이션이 없어야 하고, 오딘 로그가 잘 남아야 한다. 고객사와 함께 개념 정의를 내리고, 각 개념의 하이어라키를 정하여 구조를 짠다. 구조에 맞게 데이터를 주고받을지 기술적으로 설계하면 필연적인 결과물이 도출된다.
유저 멘탈 모델도 설계에 포함된다.
설계 기법은 트렌드를 많이 타고, 엔지니어와 창업자의 관점을 모두 고려해야 한다. 다양한 레퍼런스와 경험을 바탕으로 설계한다.
엄밀하고 고결한 설계와 당장의 산출물 사이에서 트레이드오프를 한다.
다른 프로젝트에 투입될 때 김지훈 FD의 경험을 공유받는다. 코드 레벨 대신 방법론, 사상, 노하우를 공유한다.
각자 문서 스타일이 있으며, 만든 사람이 공유 여부를 결정한다. 회의를 열어 리뷰를 진행하고, 서로 영향을 주고받으며 집단 지성을 만들어간다.
업무 방식 자체를 통일하지는 않지만, 멘탈 모델을 일치시키는 데 집중한다. 모든 산출물은 깃허브, 노션, 슬랙에 오픈되어 있어 서로의 프로젝트를 이어받거나 넘겨줄 수 있다.
프로젝트마다 KPI가 다르기 때문에 고객이 무엇을 기대하는지를 최우선으로 생각한다. 다양한 방법론보다는 지켜야 할 원칙 몇 가지만 정해놓는 것이 효과적이다.
고객의 성공을 돕는 것이 중요하며, 고객사 내부의 프로세스를 심어주는 데 집중한다. AI 문서화를 통해 통합된 원칙을 만들어야 한다고 생각한다.
스타트업 레벨에서는 자유도를 높게 가져가는 것이 중요하지만, 엔터프라이즈 레벨에서는 방법론과 프레임을 가지고 하는 것이 중요하다.
설계가 완료되면 코드 레벨로 넘어간다. 대전제와 도메인 드리븐 디자인을 채택하여 요구사항에 맞는 도메인 모델과 아키텍처를 결정한다. 코드를 작성할 때 린터를 통해 코드 아웃풋을 해결한다.
린터를 사용하여 코드 스타일을 강제한다. 예를 들어 레스토랑이 모여있는 페이지는 복수형의 페이지로 강제하고, 파일명에 디테일이나 리스트를 사용하지 못하도록 한다. 임포트 문의 알파벳 순서, 임포트 가능한 파일, 익스포트 규칙 등도 린터로 관리한다.
코드에 시스템을 강제하여 퀄리티를 유지하고 일관성을 가져갈 수 있다.
코드 리뷰어 입장에서 작성자의 의도를 알 수 있도록 도구를 만든다. 기능이 망가졌을 때 파일을 지우고 새로 작성하는 방식으로 진행한다.
AI가 생성하기 편한 스타일이 있지만, 인간과의 협업을 위해 휴먼 리더블 코드가 중요하다. 유지보수를 위해 가이드라인에 맞춰 코드를 작성해야 한다.
한네스가 잘 설정되어 있고 유지보수 관점으로 넘어갔을 때 누가 들어오더라도 규칙을 쉽게 학습하고 이어갈 수 있도록 하는 것이 중요하다.
거대한 요구사항을 넣었을 때 한 번에 요구사항을 맞출 수도 있지만, 빼먹을 수도 있다. 린터를 사용하여 프롬프트 엔지니어링만으로 강제할 수 없는 부분을 보완한다.
커밋 시 린트 테스트를 실행하여 코드 구조를 만족시키도록 한다. 스몰 A부터 스몰 F까지, 라지 A부터 라지 C까지 넣었던 요구사항이 동치에 아웃풋이 나오도록 한다.
AI 모델마다 한 번에 오래 걸리더라도 아웃풋이 맞게 나오는 경우가 있고, 작게 여러 번 시도해서 나오는 경우도 있다. 하네스를 통해 정교화되는 형태로 간다.
디자인 시스템이 회기라되어 있어 어떤 모델을 사용해도 동일한 아웃풋이 나오게 된다.
하네스에서 설계를 꽉 잡아 놓는 것도 중요하지만, 잘 만들어졌는지 체크하는 것도 중요하다. 이밸류에이션에 집중해야 한다.
법적인 이밸류에이션이 아니라 조직에 맞는 이밸류에이션이 필요하다. 컨텍스트에 맞는 답변, 제대로 된 소스 데이터, 빠진 내용 없음 등을 평가한다.
서비스 응답 속도처럼 AI도 품질 표준을 잡아야 한다. 매일매일 체크하면서 품질이 유지되는지 확인해야 한다.
이밸류에이션 방법은 조직 문화와 맞닿아 있다. 조직별로 스타일이 다르기 때문에 조직에 맞는 이밸류에이션 메소드를 선택해야 한다.
프로젝트마다 품질 관리 대시보드를 별도로 제작하거나, 내부에 통합된 솔루션을 만들어 사용할 수 있다. 고객사의 성향을 보고 이밸류에이션 방법론을 결정한다.
만든 사람과 클라이언트 모두 이밸류에이션을 트래킹할 수 있어야 한다. 프로젝트를 계속 이어갈 수 있도록 끈을 유지하는 것도 중요하다.
구축 후 내부 인력이 유지보수할 수 있도록 역량을 강화해야 한다. AI는 불확정성이 크기 때문에 이를 잡아낼 수 있는 무기를 제공해야 한다.
하드웨어 프로젝트를 하면서 펌웨어를 구현하는 데 어려움을 겪었다. 전문가에게 문의하면 포맷을 해오라는 답변을 들었다.
제로로 돌아갔을 때 결과물로 가는 단계가 몇등이어야 한다는 것을 깨달았다. 어떤 짓을 했는지 모르면 포맷을 해서 처음부터 다시 시작해야 한다.
하드웨어 프로젝트 실패 경험이 현재 AI 엔지니어링에 영향을 주고 있다.