AI 에이전트에게 질문하기 vs 위임하기

대부분의 개발자들은 AI를 더 똑똑한 Stack Overflow처럼 사용합니다.

질문을 입력합니다. 답변을 얻습니다. 그리고 직접 업무를 수행합니다.

그것도 괜찮지만, 그것은 느린 방식입니다 😩 더 빠른 모드가 존재하지만, 대부분의 사람들은 아직 그 방식으로 전환하지 않았습니다.

차이점: 질문하기(Asking) & 위임하기(Delegating)

AI에게 질문할 때:

"내 인증(auth) 모듈에 대한 테스트를 어떻게 작성하나요?"

당신은 친절한 설명을 듣습니다. 그러고 나서 테스트를 직접 작성합니다. 여전히 당신이 일을 하고 있는 것입니다 🥸

AI 에이전트에게 위임할 때:

"/src/auth.py에 대한 테스트를 작성해줘. 로그인, 로그아웃, 그리고 유효하지 않은 토큰 케이스를 포함해줘. 테스트를 실행하고, 만약 실패하는 것이 있다면 통과할 때까지 코드를 수정해줘. 무엇을 변경했는지 나에게 알려줘."

에이전트는 당신의 파일을 열고(opens), 테스트를 작성하며(writes), 이를 실행하고(runs), 실패 내용을 읽고(reads), 코드를 수정하며(fixes), 작동하는 테스트 스위트와 함께 당신에게 돌아옵니다(comes back).

당신은 결과를 검토합니다. 당신은 일을 하지 않았습니다.

이것이 바로 변화의 핵심입니다 🙂‍↔️ 사소해 보일 수 있지만, 시간 차이는 엄청납니다.

효과적인 위임을 작성하는 방법

성공적으로 작동하는 모든 위임에는 네 가지 요소가 있습니다. 새로운 팀원에게 업무를 맡기는 것이라고 생각해보세요:

• 목표 (Goal): 무엇을 결과물로 만들어야 하는가?
• 범위 (Scope): 코드베이스의 어느 파일이나 영역인가?
• 성공 조건 (Success condition): 작업이 올바르게 완료되었음을 어떻게 알 수 있는가?
• 결과 보고 (Report back): 무엇을 왜 변경했는지 나에게 알려달라.

실제 사례는 다음과 같습니다:

디버깅 (Debugging):

"여기 에러와 스택 트레이스(stack trace)가 있어. 근본 원인을 찾아내고, 수정하고, 무엇이 잘못되었었는지 설명해줘."

이것이 작동하는 이유: 당신은 에러가 무엇을 의미하는지 묻는 것이 아닙니다. 문제 전체를 넘겨주고(handing over), 원인을 찾고, 수정하고(fix), 설명(explain)하도록 하는 것입니다 😎

리팩터링 (Refactoring):

"이 파일을 리팩터링해줘. 중첩(nesting)은 최대 2단계까지. 단일 함수는 30줄을 넘지 않도록. 코드베이스 내의 모든 호출 지점(call site)을 업데이트해줘."

이것이 작동하는 이유: 제약 조건이 명확하고 확인 가능(clear and checkable)하기 때문입니다. 에이전트는 자신이 언제 작업을 마쳐야 하는지 정확히 알게 됩니다 🧐

데이터베이스 마이그레이션 (Database migration):

"이 스키마 변경을 위한 마이그레이션 스크립트를 작성해줘. 멱등성(idempotent)을 갖추도록 해줘. 로컬 테스트 데이터베이스에서 실행하고 성공을 확인(confirm)해줘."

이것이 작동하는 이유: 당신은 에이전트가 당신에게 돌아오기 전에 자신의 작업을 검증(verify its own work)할 수 있는 방법을 제공했습니다 🤔

PR 리뷰 (PR review):

"이 PR diff를 읽어줘. 프로덕션(production) 환경에서 실패할 수 있는 요소를 찾아줘. 내가 놓친 테스트를 작성해줘."

이것이 작동하는 이유: 두 가지 목표가 모두 구체적입니다. 에이전트는 이 두 가지를 엔드 투 엔드(end to end)로 수행할 수 있습니다 🥵

데이터 파이프라인 (Data pipeline):

"이 파이프라인에는 테스트가 없습니다. 다음 사항들을 확인하는 테스트(test) 스위트를 작성해줘: 각 단계에서의 스키마(schema) 일관성, 훈련(train) 세트와 검증(validation) 세트 간의 데이터 누수(data leakage) 없음, 그리고 null 값의 올바른 처리."

이것이 작동하는 이유: 항상 건너뛰게 되는 지루한 작업입니다. 이제 이것은 5분짜리 작업이 되었습니다 🥱

IDE를 열기 전에:

"여기 Jira 티켓이 있어. 레포지토리(repo)에서 관련 파일을 찾아줘. 내가 코드 한 줄을 쓰기 전에 무엇을 변경해야 하는지 요약해줘."

이것이 작동하는 이유: 20분 동안 고고학 탐사(archaeology)를 하는 대신, 맥락(context)을 파악한 상태에서 코딩을 시작할 수 있습니다 🥱

에이전트가 제공한 결과물을 확인하는 방법

에이전트는 빠릅니다. 하지만 때로는 틀리기도 합니다. 무작위로 틀리는 것이 아니라 예측 가능한 방식으로 틀립니다. 모든 것을 다시 검토하느라 40분을 허비하지 않고도 이를 잡아내는 방법은 다음과 같습니다.

확인 사항 1: 실제로 문제를 해결했는가?

코드를 실행(Run the code)하세요. 그냥 읽기만 하지 마세요.

에이전트는 완전히 정확해 보이지만 특정 엣지 케이스(edge case)에서 실패하는 코드를 작성할 수 있습니다. 이를 알아내는 유일한 방법은 실행해 보는 것입니다. 테스트가 있다면 실행하세요. 없다면 수동으로 실행하세요. 아니면 에이전트에게 테스트 코드를 작성하게 하세요.

코드를 읽는 것은 리뷰하는 것처럼 느껴지지만, 실제로 실행하는 것이 진짜 리뷰입니다.

확인 사항 2: 당신의 코드베이스(codebase)에 적합한가?

에이전트는 당신 팀의 컨벤션(team's conventions)을 알지 못합니다. 왜 그 모듈이 그런 구조로 되어 있는지, 혹은 지난 분기에 왜 그 패턴을 다시는 사용하지 않기로 결정했는지 알지 못합니다. 기술적으로 올바른 코드라도 당신의 상황에서는 여전히 틀릴 수 있습니다.

출력물에서 어색하게 느껴지는 부분, 특이한 패턴, 사용하지 않는 라이브러리, 또는 코드베이스의 나머지 부분과 일치하지 않는 접근 방식이 있는지 훑어보세요. 그것이 바로 오직 당신만이 잡아낼 수 있는 부분입니다.

확인 사항 3: 요청하지 않은 것을 변경했는가?

그것이 어떤 파일들을 건드렸는지 확인하세요. 주니어 개발자의 PR (Pull Request)을 검토하듯 diff를 읽으세요.

에이전트는 때때로 범위(scope)에 없던 주변 코드를 정리하거나 함수를 리팩토링(refactoring)하는 등 도움이 되는 변경을 수행하기도 합니다. 때로는 그것이 아주 훌륭할 수도 있고, 때로는 다른 무언가를 망가뜨릴 수도 있습니다. 수락하기 전에 에이전트가 무엇을 건드렸는지 파악하세요.

평가 매트릭스 (The evaluation matrix)

한 문장으로 요약한 사고방식의 전환

확인 사항	던져야 할 질문	위험 신호 (Red flag)
목표 (Goal)	실제로 문제를 해결했는가?	테스트는 통과하지만 로직이 틀림
...

그러한 검토는 대부분의 작업에서 5~10분 정도 소요됩니다. 40분이 아닙니다.

당신의 역할은 직접 일을 하는 것에서 목표를 정의하고 결과를 검토하는 것으로 변화합니다.

당신은 **판단력과 맥락 (context)**을 제공합니다. 에이전트는 속도와 지치지 않는 에너지를 제공합니다.

당신의 생각은 어떠신가요? 🤔 댓글로 남겨주세요