AI는 과연 코딩에서 만능인가 #3
하네스를 만들기 전에, 하네스가 무엇을 지켜야 하는지부터 정했다.
이전 글에서는 AI와 개발하면서 반복해서 겪은 문제를 정리했습니다.
목적이 정해지기 전에 구현이 시작됐고, 실제 원인보다 눈앞의 증상을 먼저 고쳤습니다. 처음 판단이 틀리면 같은 오류를 여러 곳에 빠르게 복제했고, 테스트는 질문하지 않은 문제를 계속 통과시켰습니다.
처음에는 프롬프트를 더 자세히 쓰면 해결될 것이라고 생각했습니다.
규칙을 문서로 만들고, 작업 순서를 적고, AI가 실수할 때마다 주의사항을 추가했습니다. 실제로 짧은 작업에서는 효과가 있었습니다.
하지만 프로젝트가 길어질수록 같은 문제가 다시 나타났습니다.
그때부터 질문을 바꾸었습니다.
AI에게 무엇을 더 설명해야 할까가 아니라, AI가 작업할 때마다 무엇을 반드시 확인하게 해야 할까.
대화 안에만 있는 기준은 대화와 함께 사라진다
AI에게 규칙을 설명하는 것은 어렵지 않습니다.
“구현 전에 목적을 확인해”, “기존 구조를 먼저 읽어”, “테스트를 통과했다고 끝내지 마”라고 말하면 됩니다.
문제는 이 규칙이 대화 안에만 있다는 점입니다.
대화가 길어지면 앞에서 정한 내용이 약해집니다. 새로운 대화를 시작하면 다시 설명해야 합니다. 다른 AI를 사용하면 같은 기준을 처음부터 전달해야 합니다.
무엇보다 규칙을 어긴 뒤에도 코드는 그대로 만들어집니다. 나중에 제가 발견하지 못하면 그 판단이 프로젝트 안에 남습니다.
그래서 기준을 대화에서 꺼내야 했습니다.
AI가 어떤 대화를 거쳤든, 어떤 모델을 사용했든, 프로젝트에 들어오면 같은 목적과 기준을 다시 확인하도록 만들어야 했습니다.
모든 문제의 정답이 코드 안에 있는 것은 아니다
하네스를 고민하면서 가장 먼저 구분한 것은 정답이 어디에 있느냐였습니다.
코드 작성 방법의 정답은 비교적 찾기 쉽습니다. 타입, 컴파일러, 데이터베이스 제약, 이미 만든 공통 코드가 답을 가지고 있습니다.
업계 표준이 답을 가진 경우도 있습니다. 보안 기준이나 테스트 방법처럼 문서로 정리된 내용을 가져와 확인할 수 있습니다.
하지만 무엇을 만들어야 하는지에 대한 답은 코드 안에 없는 경우가 많습니다.
고객이 실제로 원하는 것, 이 기능을 만드는 목적, 어떤 선택을 감수할 수 있는지는 사람에게 있습니다. 시스템이 스스로 알아낼 수 없습니다.
취향처럼 정답이 하나가 아닌 문제도 있습니다. 이런 영역까지 하나의 규칙으로 강제하면 오히려 잘못된 답을 정확한 형식으로 만들게 됩니다.
그래서 모든 문제를 같은 방식으로 다루면 안 됐습니다.
- 코드 안에 답이 있으면 코드가 선택지를 줄임
- 표준에 답이 있으면 검사로 확인함
- 사람에게 답이 있으면 구현 전에 물음
- 정답이 하나가 아니면 선택할 수 있게 남김
이 구분이 하네스를 만들기 위한 첫 기준이 되었습니다.
하네스의 목적은 AI를 못 움직이게 하는 것이 아니었다
처음에는 하네스라고 하면 AI의 행동을 막는 장치부터 떠올렸습니다.
파일을 수정하지 못하게 하고, 특정 명령을 실행하지 못하게 하고, 승인 없이 다음 단계로 넘어가지 못하게 하는 방식입니다.
물론 이런 차단도 필요합니다. 하지만 막는 것만으로는 제가 겪은 문제를 해결할 수 없었습니다.
목적이 비어 있는데 개발을 막기만 하면, AI는 멈추지만 무엇을 물어야 하는지는 알 수 없습니다. 기준이 틀렸는데 그 기준을 강하게 적용하면, 잘못된 결과를 더 일관되게 만들게 됩니다.
제가 정한 하네스의 목적은 다음과 같았습니다.
AI가 만들 수 있는 결과 중 잘못된 선택지는 줄이고, 사람이 판단해야 하는 선택지는 사람에게 남긴다.
무조건 자유를 줄이는 것이 목적이 아니었습니다.
이미 답이 정해진 영역에서는 선택지를 줄이고, 사람의 판단이 필요한 영역에서는 AI가 대신 결정하지 못하게 하는 것이 목적이었습니다.
목적을 한 문장으로 먼저 고정했다
구현하기 전에 하네스가 끝났을 때 무엇이 달라져야 하는지 먼저 적었습니다.
AI가 구현을 맡더라도, 사람은 목적과 결정의 근거와 변경 범위를 계속 파악할 수 있어야 한다.
이 문장을 먼저 두니 필요한 기준이 따라오기 시작했습니다.
목적을 모르면 물어야 합니다. 기존 구조를 바꾼다면 어디까지 영향을 주는지 보여야 합니다. 결과가 맞다고 말하려면 무엇과 비교했는지 남아야 합니다. 같은 문제가 반복되면 다시 부탁하는 대신 시스템이 막아야 합니다.
반대로 이 목적과 관계없는 기능은 처음부터 만들 이유가 없었습니다.
하네스를 만들기 위한 개발도 일반 개발과 같았습니다. 목적이 없으면 필요한 기능과 있으면 좋은 기능을 구분할 수 없습니다.
그래서 저는 작업 흐름이나 도구보다 목적과 기준을 먼저 정했습니다.
기준을 만든 뒤에 도구를 만들었다
현재 사용하는 도구가 처음부터 있었던 것은 아닙니다.
먼저 실제 문제를 모았습니다. 어떤 판단을 AI가 대신했고, 어떤 정보가 빠졌고, 제가 어디에서 다시 지적했는지를 확인했습니다.
그다음 반복해서 지켜야 할 기준을 만들었습니다.
기준이 생긴 뒤에야 어떤 것은 문서로 남기고, 어떤 것은 질문으로 확인하고, 어떤 것은 코드나 검사로 막을지 정할 수 있었습니다.
순서는 다음과 같았습니다.
- 실제 문제 확인
- 지키려는 목적 확정
- 맞고 틀림을 가를 기준 수립
- 사람이 판단할 자리와 자동화할 자리 구분
- 반복 가능한 부분을 도구로 구현
도구가 기준을 만든 것이 아닙니다.
제가 세운 기준을 매번 같은 방식으로 실행하기 위해 도구를 만든 것입니다.
이 순서가 바뀌면 쉽게 구현할 수 있는 것만 도구에 들어갑니다. 그러면 정작 중요한 목적과 사람의 판단은 다시 도구 밖에 남습니다.
하나의 하네스로 모든 프로젝트를 다룰 수는 없었다
하네스를 만들면서 또 하나 확인한 점이 있습니다.
목적이 다르면 필요한 기준도 달라집니다.
이미 만들어진 공통 코드를 사용하는 프로젝트와 그 공통 코드 자체를 개발하는 프로젝트는 확인해야 할 것이 다릅니다. 기존 시스템을 옮기는 작업과 새로운 기능을 만드는 작업도 위험과 완료 기준이 다릅니다.
처음에는 하나의 거대한 하네스에 모든 절차를 넣으려고 했습니다. 하지만 그렇게 만들수록 모든 프로젝트가 필요하지 않은 절차까지 따라야 했고, 중요한 차이는 공통 규칙 안에 묻혔습니다.
그래서 하네스도 목적에 따라 나누기로 했습니다.
공통으로 지켜야 할 기준은 공유하되, 각 작업이 무엇을 만들고 어떤 위험을 다루는지에 따라 다른 흐름과 검사를 사용합니다.
이 구분 덕분에 하네스는 규칙을 많이 모아둔 문서에서 실제 개발 방법으로 바뀌기 시작했습니다.
이제 구조를 만들 차례였다
하네스를 직접 만들기로 한 이유를 정리하면 단순합니다.
- 대화 안의 규칙은 계속 유지되지 않음
- 문제마다 정답이 존재하는 위치가 다름
- 사람의 판단이 필요한 영역을 AI가 대신 결정하면 안 됨
- 반복할 기준을 먼저 만들고 그다음 도구로 옮겨야 함
- 목적이 다른 작업에는 다른 하네스가 필요함
여기까지 정하고 나서야 실제 구조를 설계할 수 있었습니다.
무엇을 지켜야 하는지 정하는 기준, 어떤 순서로 일할지 정하는 작업 흐름, 반드시 지켜야 할 조건을 실제로 막는 수단을 분리해야 했습니다.
다음 글에서는 이 세 가지를 어떤 구조로 나누고 다시 연결했는지 정리해보려고 합니다.
