하네스 엔지니어링의 첫걸음, AI에게 맡길 도구와 맥락부터 갖춘다

"오늘 저녁에 뭐 먹을까?"

국내 전자 대기업 실무자들이 모인 교육장에서, 모두가 생성형 AI에 이 문장을 똑같이 넣었습니다. 그런데 화면마다 올라온 메뉴가 달랐습니다.

생성형 AI는 다음에 올 말을 확률로 고릅니다. 김치찌개, 삼겹살, 비빔밥처럼 확률이 여러 후보에 흩어져 있고, 실행할 때마다 그중 하나를 뽑습니다. 확률이 넓게 퍼질수록 같은 질문에도 답이 매번 달라집니다.

저녁 메뉴라면 상관없습니다. 영업, 마케팅, 하드웨어 검증까지 직무는 제각각이었지만 이날 모인 사람들의 고민은 같았습니다. 반복되는 일을 AI에게 넘기고 싶은데, 시킬 때마다 결과가 달라서 믿을 수가 없다는 것이었습니다.

하네스는 AI 에이전트가 원하는 방향으로만 움직이게 만드는 일의 환경 전체입니다. 일을 처리할 도구를 만들고, 그 도구에게 회사 사정을 알려주고, 결과가 통과인지 판정할 기준과 장치를 세우고, 되돌릴 수 없는 순간에는 멈춰서 사람에게 묻게 만드는 일까지가 여기 들어갑니다. 이번 편은 앞의 두 가지, 도구를 만들고 맥락을 채우는 과정까지를 다룹니다.

도구, 반복되는 일은 코드로 맡긴다

여기서 에이전트는 지시를 받으면 내 PC의 파일을 직접 열고, 필요한 코드를 짜서 실행하고, 결과 파일을 저장하는 데까지 스스로 해내는 AI를 말합니다. Claude Code나 Codex 같은 도구가 이렇게 일합니다. 채팅창에 자료를 붙여넣고 받은 답을 다시 파일에 옮겨 적던 방식과는 다릅니다. 사람이 중간에서 파일을 오가며 옮길 필요가 없습니다.

월간 리뷰를 맡은 영업기획팀 실무자의 일은 네 단계로 나뉩니다. 시장 동향 뉴스를 모으고, 법인들이 올린 실적을 집계할 수 있는 형태로 정리하고, 권역별 달성률을 분석하고, 그 결과로 보고서를 씁니다. 이 네 단계를 하나씩 에이전트에게 시켜보는 데서 도구 만들기가 시작됩니다.

두 번째 단계에서 바로 문제가 생깁니다. 법인 40곳의 실적을 모은 파일을 열어보면 같은 법인인데 코드 표기가 'NAX-01', 'NAX01', 'nax_01'처럼 제각각이라, 피벗으로 묶이지도 않고 다른 표에서 권역명을 찾아 붙이지도 못합니다. 실적 숫자는 어떤 행은 천 대, 어떤 행은 대 단위로 적혀 있습니다. 에이전트에게 법인코드 표기를 하나로 맞추고, 권역명을 붙이고, 단위를 천 대로 통일하라고 하면 이번 달 파일은 정리됩니다.

다음 달에도 같은 모양의 파일이 올라옵니다. 그때마다 같은 정리를 다시 시키면 시킬 때마다 비용이 들고, 확률로 움직이는 AI이니 결과는 매번 조금씩 달라질 수 있습니다. 그래서 이번에는 정리하는 일을 시키는 대신 정리하는 코드를 만들게 합니다. 코드는 만들 때 한 번만 비용이 들고, 그 뒤로는 몇 번을 돌려도 토큰 소모 없이 같은 결과를 냅니다. 지금은 법인 40곳, 640행짜리 파일이지만 수십만 행 단위의 데이터를 다루는 업무라면 차이는 더 커집니다. 에이전트가 한 줄씩 읽어가며 판단하면 그만큼 시간이 오래 걸리고, 데이터가 그 정도 규모면 끝까지 읽어내지 못하는 경우도 있습니다. 코드는 같은 작업을 압도적으로 빠른 속도로, 오차 없이 끝냅니다. 뉴스 수집과 달성률 집계도 같은 식으로 코드로 바꿔 둡니다. 보고서 문장처럼 매달 사정이 달라지는 부분만 에이전트의 몫으로 남습니다.

네 단계를 다 거치자 보고서 초안이 나왔습니다. 어느 권역이 미달인지, 원인이 무엇으로 보이는지, 그래서 무엇을 해야 하는지가 수집한 뉴스를 근거로 논리적으로 정리돼 있었습니다. 그런데 이 보고서는 회사에서 그대로 쓸 수 없는 보고서였습니다.

맥락, 파일 밖에 있는 것을 채운다

문장은 매끄러웠지만 판단이 틀려 있었습니다. 이 팀에는 신규 입사자가 들어오면 제일 먼저 건네는 문서가 하나 있습니다. 월간 리뷰를 쓸 때 반드시 참고해야 하는 다섯 가지 기준이 담겨 있습니다.

• 러시아 법인은 제재 이슈로 집계에서 뺍니다 → 집계 대상이 달라집니다
• 제품군마다 미달선이 다릅니다. 주력인 스마트폰과 태블릿은 95%, 신규인 웨어러블과 버즈는 85% → 판정이 달라집니다
• 최근 한 달 실적은 마감 전 가집계라 확정치가 아닙니다 → 추세 해석이 달라집니다
• 경쟁사 자료는 외부 추정치라 소수점 비교 대신 추세만 봅니다 → 서술이 달라집니다
• 사업부장은 원인보다 회복 전망을 먼저 봅니다 → 보고서 순서가 달라집니다

에이전트는 이 문서를 받지 못한 채 보고서를 썼습니다. 같은 데이터를 두고도 한쪽 기준으로는 "양호"였고 다른 기준으로는 "미달"이었습니다. 물량이 가장 큰 스마트폰 제품군에서 이 판정이 갈리면 보고서 결론 전체가 뒤집힙니다.

이 다섯 가지는 데이터 어디에도 적혀 있지 않습니다. 이 업무를 오래 해 온 사람만 압니다. 월간리뷰 작성기준 문서를 에이전트에게 함께 넘기자 결론이 바뀌었습니다. 러시아 법인이 빠지고, 스마트폰은 95% 기준으로 다시 판정되고, 가집계 구간은 추세로만 서술되고, 사업부장이 바로 볼 수 있도록 회복 전망이 원인보다 앞으로 올라왔습니다.

Context Engineering이 하는 일이 바로 이것입니다. 파일 안에 있는 내용은 에이전트가 직접 읽어내지만, 이 업무를 오래 해본 사람 머릿속에만 있는 다섯 가지 같은 정보는 사람이 직접 채워 줘야 합니다. 그래서 이 일은 에이전트가 아무리 좋아져도 사라지지 않습니다.

내용을 맞추고 나니 이번엔 형식이 걸렸습니다. 회사 보고서에는 정해진 폰트와 색, 표를 그리는 방식이 있습니다. 평소에 알고는 있었지만 문서로 적어본 적은 없었습니다. 이번엔 그 기준을 글로 옮겨 디자인 가이드로 만들고 에이전트에게 넘겼습니다. 보고서는 내용과 형식 모두 회사 기준에 맞는 모습으로 다시 나왔습니다.

오늘 아침 같은 질문에 다른 메뉴가 나왔던 그 에이전트에게, 이제는 월간 리뷰 한 건을 맡길 수 있습니다. 반복되는 수집과 전처리, 분석은 코드가 넘겨받았고, 판단이 필요한 보고서 문장은 회사만 아는 다섯 가지 맥락을 받은 에이전트가 썼습니다. 도구와 맥락, 이 두 가지가 갖춰지자 보고서 한 건은 내용과 형식 모두 믿을 만한 수준이 됐습니다.

그런데 이 수준에 닿았는지는 사람이 매번 직접 열어보고 확인했습니다. 결과가 나올 때마다 틀린 곳을 짚어 다시 시키는 과정을 매달 반복해야 한다면, 에이전트에게 일을 맡겼다고 말하기는 어렵습니다. 결과를 통과시킬 기준과 그 기준으로 판정할 장치를 에이전트 바깥에 세우는 일이 남아 있습니다. 다음 편에서 이 둘을 세웁니다.

이 사례는 포텐스닷이 진행한 하네스 엔지니어링 교육에서 나온 것입니다. 같은 과정을 직접 설계해보고 싶다면 포텐스닷 기업교육에서 확인할 수 있습니다.