AI를 업무에 쓰기 시작했을 때는 질문을 잘 쓰는 게 가장 중요하다고 생각했다. “단계별로 생각해 줘”, “전문가처럼 분석해 줘” 같은 문장을 바꾸며 답의 품질을 비교했다. 조금 나아지긴 했지만 저장소가 크거나 배포와 검증이 이어지는 작업에서는 같은 실수가 반복됐다.
필요했던 건 멋진 프롬프트 하나가 아니라 AI가 어떤 파일을 읽고, 무엇을 바꿀 수 있고, 어디서 멈추며, 성공을 어떻게 증명할지 정하는 주변 구조였다. 이걸 하네스라고 부르기 시작했다.
하네스는 AI 주변의 작업 환경이었다
내가 만든 하네스는 거창한 프로그램보다 규칙과 도구의 조합에 가까웠다.
작업 규칙 : 수정 가능 범위, 비밀정보, 브랜치·배포 경계
탐색 도구 : 코드 검색, Git 이력, 문서와 로그
상태 기록 : 목표, 현재 단계, 이미 확인한 증거
검증 명령 : 테스트, 빌드, 화면과 런타임 확인
중단 조건 : 권한 부족, 대상 불명확, 위험한 변경
AI가 대화를 잊거나 작업이 길어져도 중요한 결정은 파일과 Git 상태에 남도록 했다. 말로 “조심해”라고 하는 것보다 실행 가능한 경계를 만드는 편이 안정적이었다.
작업을 닫힌 루프로 만들었다
한 번 답을 받고 끝내지 않고 작은 반복을 만들었다.
증거 수집
-> 가설과 영향 범위
-> 작은 변경
-> 자동 검증
-> 실패 분류
-> 원인에 맞는 수정 또는 중단
검증 실패를 무조건 다시 시도하지 않았다. 같은 원인이 반복되면 입력이나 권한이 바뀌어야 하는지 판단했다. 성공한 단계는 기록해 다음 반복에서 다시 수행하지 않았다.
성공을 명령 실행과 분리했다
테스트 명령이 0으로 끝났다는 건 그 테스트가 통과했다는 뜻이지 실제 화면과 배포가 정상이라는 뜻은 아니었다. 코드 검증, 빌드 산출물, 배포된 파일, 실제 런타임을 단계별 증거로 나눴다.
AI에게도 “완료”라고 쓰기 전에 어떤 증거를 확인했는지 출력하게 했다. 확인하지 못한 부분은 가정이나 남은 검증으로 표시했다. 자연스러운 완료 문장보다 증거 목록이 중요했다.
AI 활용은 시스템을 설계하는 일이 됐다
하네스와 루프를 만들고 나니 AI 답이 항상 맞아진 건 아니다. 대신 틀린 가설이 작은 범위에서 드러나고, 위험한 작업 전에 멈추며, 긴 작업을 이어갈 수 있게 됐다. 내가 매번 기억해서 지키던 순서를 재사용 가능한 작업 환경으로 옮긴 셈이었다.
요즘은 “어떤 프롬프트가 좋을까?”보다 “이 작업의 상태와 증거, 권한, 실패 루프는 어디에 있나?”를 먼저 묻는다. AI를 잘 쓰는 일은 대화 기술을 넘어 개발 프로세스를 명확하게 만드는 일로 이어졌다.