일은 코드를 작성하는 것이 아니다. AI가 틀렸을 때를 아는 것이다.

Source: Dev.to

저는 제 구인 게시판인 GlobalRemote에서 거의 모든 작업에 AI 코딩 에이전트를 사용합니다. 이 에이전트는 제 스크래퍼를 작성하고, CI 파이프라인을 구축하며, 데이터베이스 스키마를 설계합니다. 코드베이스의 대부분을 이 에이전트가 작성했습니다.

몇 달 동안 이렇게 구축해오면서 한 가지 패턴을 발견했습니다: 제가 가장 가치 있게 하는 일은 코드를 작성하는 것이 아니라, AI가 틀린 부분을 잡아내는 것입니다 — 특히 출력은 올바른 것처럼 보이지만, 곰곰히 생각해 보면 설득되지 않는 경우를 말합니다.

1. 잘못된 도구를 사용했을 때

내 파이프라인은 정규식을 사용해 채용 공고에서 기술 스택 요구 사항을 추출한다. 어느 역할이 게시판에 올라왔지만 기술 스택이 명시되지 않았다. AI가 조사해 보니 정규식이 해당 게시물 형식에 매치되지 않는다는 것을 발견하고, 정규식 패턴을 확장하자고 제안했다.

그것도 괜찮다. 하지만 우리는 이미 같은 채용 설명에서 다른 필드를 분류하고 추출하는 LLM을 사용하고 있었다. 이미 비용을 내고 있는 LLM을 활용할 수 있는데, 왜 부서지기 쉬운 정규식을 유지해야 할까?

에이전트는 이에 동의하고 LLM 기반 추출을 구현했다 — 더 탄력적이며 정규식으로는 절대 잡히지 않았을 가장자리 경우도 처리한다.

AI는 현재 접근 방식 내에서 최적화를 수행했다. 나는 접근 방식 자체가 옳은지 의문을 제기했다. 이것은 내가 계속해서 보는 패턴이다 — AI 에이전트는 주어진 문제를 해결하는 데는 뛰어나지만, 당신이 올바른 문제를 해결하고 있는지에 대해서는 질문하지 않는다. 그 부분은 여전히 당신에게 달려 있다.

2. Technically Correct, Actually Misleading

내 파이프라인은 GitLab 채용 공고에서 지리 데이터를 추출했는데—미국, 캐나다, 프랑스, 독일, 아일랜드, 네덜란드, 스페인, 영국에서만 지원 가능한 역할—이를 multi‑region으로 태그하고 지역을 Americas와 Europe로 지정했습니다. 나는 에이전트에게 검증을 요청했으며, 에이전트는 데이터가 정확하다고 확인했습니다—공고에 두 지역에 걸친 국가들이 나열되어 있었기 때문입니다.

문제는 이렇습니다: 브라질 사용자가 “Americas”를 보면 지원할 수 있다고 생각하고, 헝가리 사용자가 “Europe”를 보면 마찬가지로 생각합니다. 하지만 이 직무는 실제로는 8개 특정 국가에서만 열려 있습니다.

에이전트는 이를 고려하지 못했습니다. 기존 데이터를 확인한 결과, 나는 이미 이 상황에 대해 select‑countries 배지를 가지고 있음을 발견하고, 해당 직무를 업데이트했으며, 이후 시스템이 향후 실행 시 이 구분을 올바르게 인식하도록 LLM 추출 프롬프트도 수정했습니다.

나는 이런 일을 직접 겪었기 때문에 이를 발견했습니다. 나는 비명백한 국가에 거주하면서 “Americas” 또는 “Global Remote”라고 표시된 직무에 제외된 경험이 있습니다. Zapier, Outliant 등 여러 회사가 위치 조건이 모호한 채용 공고 때문에 나를 배제한 사례가 있었습니다.

3. The Silent Failure

내 파이프라인은 일정대로 실행되었습니다. 39개의 채용 공고를 스크랩하고, 이를 처리했으며, “추가할 새로운 항목이 없습니다.” 라고 보고했습니다. 오류도 없고, 정상 종료되었습니다.

39개의 목록 중 새 채용이 전혀 없다는 것은 이상해 보였습니다. 나는 원시 데이터를 꺼내어 에이전트에게 파이프라인의 결정을 자체 감사하도록 요청했습니다.

그 결과 두 가지 버그가 발견되었습니다:

1. 중복 제거 규칙이 새 채용을 제목이 비슷한 폐쇄된 목록과 잘못 매칭시켜—다른 게시물, 다른 채용 ID, 유효한 급여 데이터—조용히 제외했습니다.
2. 파이프라인이 절대 파싱하지 않았던 급여 필드 때문에, 급여 정보가 표시된 채용이 “급여 투명성 없음”이라는 이유로 제외되고 있었습니다.

파이프라인은 오류를 발생시키거나 경고를 표시하지 않았습니다. 성공을 보고하면서도 유효한 채용을 조용히 누락하고 있었습니다.

나는 코드를 읽는 것으로는 이 문제를 잡지 못했습니다. 출력 결과가 직감에 맞지 않았기 때문에 발견한 것입니다.

왜 이것이 중요한가

Ben Shoemaker는 최근 글에서 엔지니어들이 코드를 한 줄씩 읽는 것을 멈추고 “하네스”— 사양, 테스트, 검증 레이어, 신뢰 경계에 투자해야 한다고 주장했습니다. OpenAI는 이를 Harness Engineering이라고 부릅니다.

이 세 가지 예시를 그 관점에서 보면, 저는 무의식적으로 바로 그 일을 해오고 있었습니다. AI가 프로덕션을 담당하고, 저는 사양, 신뢰 경계, 그리고 “이것이 실제로 내 사용자에게 의미가 있는가?”라는 레이어를 담당합니다.

현재 AI 도구를 사용해 개발하고 있는 엔지니어라면, AI의 제안을 무시하고 직접 개입하는 순간에 주목하세요. 그 순간들은 작업 흐름을 방해하는 것이 아니라, 가장 가치 있는 부분입니다. 시장이 요구하는 스킬셋이며, 비록 공개하지 않더라도 스스로 기록해 두는 것이 좋습니다.