Forge Fate
한국어
AI

더 많이 맡길 수 있게 되면, 개발자는 무엇을 결정해야 할까?

약 6분

지난 편에서는 작업을 맡긴 뒤 무엇을 읽고 실행했는지 확인하는 방법을 다뤘다. 이번에는 시선을 작업 전으로 옮겨 보자. 개발자가 원인도 해법도 아직 모를 때, 어디까지 맡기고 무엇을 먼저 정해야 할까?

설명용으로 “목록 조회가 느리니 고쳐 줘”라는 요청을 생각해 보자. 여기에는 개선할 대상이 빠져 있다. 어떤 사용자가 어떤 작업을 할 때 느린지, 데이터가 어느 정도일 때 문제가 나타나는지, 어떤 조건에서 다시 확인할 수 있는지 알 수 없다. 그렇다고 개발자가 이 질문의 답을 모두 찾아낸 뒤에야 작업을 맡길 수 있는 것은 아니다. 목표가 불명확할 때 필요한 조사와 목표 초안의 제안부터 요청할 수 있다.[S1]

“고쳐 줘” 전에 조사할 범위를 정한다

두 요청의 차이를 보자. 둘 다 가상의 목록 조회 작업에 대한 문장이다.

모호한 요청: “목록 조회가 느리니 고쳐 줘.”

결정 경계가 있는 요청: “어떤 사용자 작업과 데이터 규모에서 느린지, 재현 조건과 현재 상태를 먼저 조사해 줘. 조사 결과를 바탕으로 성능 목표와 가능한 대안을 제안해 줘. 정렬·페이지 동작과 응답 계약은 유지해 줘.”

두 번째 요청도 병목을 미리 지정하지 않는다. 대신 지금 필요한 결과를 조사와 제안으로 한정한다. 예를 들어 사용자가 첫 페이지를 여는 상황과 여러 페이지를 넘기는 상황 중 어디에서 문제가 드러나는지, 어떤 데이터와 환경에서 같은 현상을 관찰할 수 있는지를 밝혀 달라는 뜻이다. 이 사례의 저장소나 측정값은 없으므로 어느 상황이 실제 문제인지, 무엇이 원인인지는 아직 말할 수 없다.

성능 목표도 같은 순서로 다룬다. 현재 상태와 재현 가능한 측정 조건을 모른다면 목표 수치를 먼저 쓰기 어렵다. 이때는 조사 결과를 받아 목표를 제안받는 데까지가 한 단계다. 목표안을 받았다는 것과 성능 개선이 끝났다는 것은 다른 판정이다. 개선 완료는 이후 목표와 검증 방법을 합의하고 변경 뒤의 근거를 확인해야 말할 수 있다. 결과와 검증 근거를 함께 정하라는 방식은 Codex의 Goal 안내에서도 제시된다.[S1]

해법을 맡기되, 유지할 조건은 밝힌다

조사 결과에 따라 에이전트가 원인 후보를 찾고, 대안을 비교하고, 작업 계획을 제안하게 할 수 있다. 공식 장시간 작업 사례에서도 목표·제약·산출물·완료 조건을 주고 단계별 계획의 작성을 맡겼다.[S3] 개발자가 구현 절차를 미리 정해야만 위임이 가능한 것은 아니다.

다만 이 목록 조회 사례에서는 빠르게 만드는 과정에서 무엇을 유지할지 먼저 밝히는 편이 좋다. 정렬 순서, 페이지를 넘길 때의 동작, 호출자가 기대하는 응답 계약을 유지 조건으로 둔다. 사용자에게 보이는 결과가 달라지는 제안이라면, 속도 개선과 함께 묶어 조용히 진행할 수 없도록 경계를 긋는 것이다. 이는 실제 시스템의 계약을 확인했다는 뜻이 아니라, 이 설명용 요청에 넣을 조건이다.

선택 범위도 적을 수 있다. 이 사례에서는 기존 구조 안에서 계약을 지키는 국소 수정은 에이전트가 조사하고 선택해 진행하도록 맡긴다. 반면 DB 스키마 변경, 공유 캐시 도입, 공개 계약 변경이 필요하다는 판단이 나오면 곧바로 진행하지 않고 대안을 받는다. 각 대안의 비용, 호환성 영향, 운영 부담, 되돌릴 수 있는 정도와 선택 이유를 비교한 뒤 범위를 다시 정한다.

이 경계는 모든 팀에 적용할 승인 규칙이 아니다. 여기서는 목록 조회 개선을 설명하기 위해 선택한 정책이다. 다른 시스템에서는 국소 수정도 큰 영향을 줄 수 있고, 이미 정해진 절차에 따른 스키마 변경은 판단 범위 안에 있을 수도 있다.

다시 판단할 지점은 어떻게 고를까

내가 개입 지점을 정할 때 함께 보고 싶은 것은 영향의 범위, 되돌리기 쉬움, 남은 불확실성이다. 변경이 넓게 퍼지거나 복구하기 어렵고 판단 근거까지 부족하다면, 실행 전에 대안과 이유를 받아 볼 필요가 커진다. 반대로 영향이 좁고 쉽게 되돌릴 수 있으며 유지 조건도 분명하다면, 선택을 맡길 여지가 커진다. 이것은 제품 기능의 규칙이 아니라 작업 경계를 정하기 위한 필자의 기준이다.

목록 조회 사례에 적용하면 질문이 구체적이 된다. 기존 구조 안의 수정으로 정렬·페이지·응답 계약을 지킬 수 있는가? 스키마를 바꿔야 한다는 제안이라면 관련 데이터와 배포에 어떤 영향을 주며 되돌리는 방법은 무엇인가? 공유 캐시를 넣는다면 어떤 운영 부담이 생기는가? 공개 계약을 바꾼다면 기존 호출자는 어떻게 되는가? 이 질문에 대한 비교를 받은 다음 결정 범위를 넓힐 수 있다.

도구가 어떤 명령의 실행을 허용하거나 기술적인 승인을 받았다는 사실만으로 그 설계 선택이 적절해지는 것은 아니다. 실행할 권한과 변경을 택할 이유는 서로 다른 질문이다.

단계마다 완료의 근거를 다르게 받는다

처음 요청한 조사 단계의 산출물은 문제가 나타나는 사용자 작업과 조건, 재현 가능한 측정 방법, 확인한 현재 상태, 원인 후보, 대안, 성능 목표 제안이다. 확인하지 못한 조건도 함께 드러나야 다음 결정을 내릴 수 있다. 원인 후보에는 관찰 근거와 추정이 구분되어 있어야 한다.

그다음 개선 단계로 진행한다면, 제안받은 목표와 검증 방법을 먼저 합의한다. 완료를 판단할 때는 그 방법으로 얻은 변경 뒤의 근거와 함께, 유지하기로 한 정렬·페이지 동작 및 응답 계약을 확인한다. 이 글에는 실제 측정이나 수정 결과가 없다. 따라서 어느 대안이 효과적이었다거나 개선이 완료됐다고 말할 수 없다.

이처럼 결과, 지켜야 할 조건, 작업 경계, 검증 근거를 연결하는 방식은 공식 Goal 안내의 제안과도 맞닿아 있다.[S1] 다만 그 내용을 전달하는 형식이 꼭 별도의 문서일 필요는 없다. 작은 일회성 수정에는 일반 프롬프트가 적합하다는 안내가 있고, 목표·계획 파일을 쓰는 개발 워크플로도 선택적 관례로 소개된다.[S1][S4] 위 사례의 경계 역시 프롬프트 하나에 담을 수 있다. 작업이 길어져 결정을 이어서 관리해야 할 때 Goal이나 Plan 같은 형식을 고려하면 된다.

더 많이 맡길 수 있다는 것은 조사, 대안, 계획까지 제안받을 수 있다는 뜻이기도 하다.[S1][S3] 그때 개발자가 기를 만한 능력은 모든 구현 답을 먼저 내는 능력만은 아니다. 제안된 선택이 어떤 목표와 조건에 기대는지 설명하고, 새 근거가 나오면 그 기준을 바꿀 수 있는 능력이다.

다음에 맡길 개발 작업 하나를 골라 짧게 적어 보자. 이루려는 결과는 무엇인가? 무엇을 유지해야 하는가? 어디까지 알아서 선택해도 되는가? 어떤 변경은 다시 판단해야 하는가? 완료를 알려 줄 근거는 무엇인가? 경계를 정해 맡긴 뒤에는 또 다른 질문이 남는다. 다음 편에서는 **“내가 직접 작성하지 않은 코드를 어떻게 판단할까?”**를 다룬다.

Sources

오류 제보·의견 보내기

글 제목과 주소가 포함된 메일 초안을 엽니다. 내용과 받는 사람을 확인한 뒤 보내주세요.

받는 사람: [email protected]

메일 앱에서 작성

메일 앱이 열리지 않으면 아래 내용을 복사해 평소 쓰는 이메일에 붙여 넣으세요.

문의 안내

관련 글