AI 코딩 시대의 문제 정의·검증 경계 설계

1. AI 코딩 역량을 ‘도구를 쓰는 사람’으로만 읽지 않기

코딩 에이전트가 초안 코드, 테스트의 출발점, 문서의 골격을 빠르게 만들면 개인의 경력도 곧바로 두 갈래의 단순한 질문으로 좁아지기 쉽다. 특정 도구를 능숙하게 조작하는가, 아니면 그렇지 않은가. 그러나 이 구도는 실제 일을 너무 많이 지운다. 같은 에이전트를 사용해도 어떤 팀은 요구사항을 구체화하고 실패 조건을 확인하는 데 시간을 쓰고, 어떤 팀은 결과를 복사한 뒤 뒤늦게 무엇이 잘못됐는지 찾는다. 차이는 입력창에 쓴 문장의 길이보다 앞뒤의 판단 구조에 있다.

Andrew Ng가 2026년 8월에 공개한 AI Engineering Skills Map은 만 건이 넘는 채용 공고와 전문가·채용 담당자 인터뷰 등을 종합해, AI 애플리케이션 구축·배포, 소프트웨어 공학 기초, 코딩 에이전트 활용, 빌드 형성이라는 네 가지 역량을 제시한다. 이 자료는 직무별 채용 기준표도, 개인의 합격 가능성 예측도 아니다. 다만 ‘AI 엔지니어’라는 직함보다 넓게, 여러 개발 직군이 어떤 작업 능력을 연결해야 하는지 생각하게 한다는 점에서 유용한 출발점이다.

특히 원문은 코딩 에이전트를 잘 쓴다는 일을 모델의 한계를 이해하고, 맥락을 관리하며, 검증 장치로 작업 고리를 닫는 능력과 연결한다. 또 명세가 주어졌을 때 에이전트의 구현 능력이 높아질수록, 엔지니어는 무엇이 명세에 들어가야 하는지 함께 형성하는 역할을 맡게 된다고 설명한다. 이 글에서 제안하는 것은 그 변화를 ‘더 전략적인 사람이 되라’는 추상적 조언으로 바꾸지 않는 것이다. 대신 문제 정의, 실행 명세, 검증 기록이라는 세 산출물을 작고 재사용 가능하게 남기는 방법이다.

여기서 조심할 점도 있다. 한 편의 스킬 맵은 산업 전체의 역할 변화를 확정하지 않는다. 조직의 제품, 규제, 고객 위험, 팀 구성에 따라 필요한 역량과 책임은 달라진다. 따라서 아래 방법은 개인을 평가하는 점수표나 채용의 정답이 아니라, 현재 업무에서 다음 학습과 협업의 빈칸을 발견하기 위한 편집부 제안이다.

2. 좋은 명세는 에이전트용 지시문보다 팀의 질문이다

명세를 작성한다는 말은 종종 기능 목록을 길게 적는 일처럼 들린다. 하지만 에이전트에게 주는 정보가 늘어날수록 무엇을 검증할지 더 흐려진다면, 그 문서는 좋은 명세가 아니다. 명세의 목적은 생성기를 설득하는 것이 아니라, 팀이 같은 결과를 보고도 서로 다른 ‘완료’를 말하지 않게 하는 데 있다.

실무에서는 요청을 세 층으로 나누어 적어 볼 수 있다. 첫째는 사용자 맥락이다. 누가 어떤 순간에 어떤 불편을 겪는가를 현재 관찰 가능한 사실과 함께 쓴다. 둘째는 제약과 선택이다. 지켜야 할 권한, 데이터 범위, 응답 시점, 되돌릴 수 없는 변경, 이미 합의된 정책을 적는다. 셋째는 성공·실패 조건이다. 어떤 관찰이 나오면 이번 변경을 계속하고, 어떤 결과면 멈추거나 다시 질문할지를 적는다. 이 셋은 완벽한 요구사항을 약속하지 않는다. 오히려 모르는 것을 작업 초기에 보이게 한다.

예를 들어 “고객 문의를 요약하는 기능을 만들자”는 요청만으로는 대상 데이터, 이용자, 잘못된 요약의 위험, 승인 주체가 빠져 있다. 이를 “상담 담당자가 이미 열람 권한이 있는 문의를 빠르게 훑되, 원문을 대체하지 않는 요약을 제공한다”처럼 바꾸면 논의의 시작점이 생긴다. 이어서 민감정보 처리 기준, 원문으로 돌아가는 경로, 잘못된 요약을 발견했을 때의 수정 책임을 적을 수 있다. 이 과정에서 에이전트는 구현 초안을 만드는 동료 도구가 될 수 있지만, 사용자에게 허용되는 결과와 실패를 정의하는 사람은 자동으로 생기지 않는다.

다음 양식은 연구에서 검증된 평가 도구가 아니며, 실제 측정 결과도 아닙니다. 팀이 작은 변경을 논의할 때 쓸 수 있는 편집부 제안이다.

# 문제·명세·검증 카드

- **사용자 문제**: [누가, 어느 상황에서 겪는 불편인가]
- **이번 변경의 범위**: [포함하는 것과 제외하는 것]
- **제약과 이미 정해진 선택**: [권한, 데이터, 정책, 되돌림 조건]
- **성공을 볼 관찰**: [사용자 확인, 테스트, 운영 신호 중 실제로 볼 것]
- **실패 또는 중단 조건**: [멈추고 재검토할 결과]
- **확인하지 못한 질문**: [근거, 담당자, 확인 시점]
- **검토 책임**: [누가 결과와 예외를 확인하는가]

이 카드의 항목은 에이전트 프롬프트를 대체하려는 형식이 아니다. 프롬프트, 이슈, ADR, 테스트 계획에 흩어질 수 있는 판단을 한 화면에 모으는 방법이다. 특히 ‘성공을 볼 관찰’과 ‘실패 또는 중단 조건’을 함께 적으면, 속도에 대한 기대와 품질·안전에 대한 책임을 같은 대화에서 다룰 수 있다.

3. 생성 결과를 승인 결과로 바꾸지 않는 흐름

에이전트가 만든 코드나 문서는 첫 결과가 그럴듯할수록 검토 단계를 건너뛰기 쉽다. 그러나 생성 결과가 요구사항을 만족하는지, 기존 시스템의 제약을 건드리지 않는지, 사용자에게 설명 가능한지는 서로 다른 질문이다. 원문의 ‘빌드 형성’은 제품 감각과 비즈니스 맥락을 이해해 무엇을 만들지에 참여하는 능력으로 설명된다. 이를 팀 작업으로 옮기면, 구현 속도와 승인 책임을 분리하는 간단한 흐름이 필요하다.

이 흐름은 모든 변경에 같은 절차를 강제하자는 뜻이 아니다. 오히려 변경의 위험과 되돌릴 수 있는 정도에 맞게 검토 범위를 작게 정하자는 제안이다. 문구 한 줄의 변경과 권한 모델을 바꾸는 변경은 같은 문서량을 요구하지 않는다. 다만 어떤 경우에도 ‘에이전트가 제안했다’는 사실만으로 사용자가 겪을 결과가 검증됐다고 말할 수는 없다. 빠른 구현은 검토할 대상을 앞당길 수 있지만, 검토의 책임을 없애지는 않는다.

▲ 이 이미지는 실제 프로젝트 관리 도구나 팀의 측정 결과가 아니라, 모호한 요청을 검토 가능한 선택지와 다음 결정 기록으로 바꾸는 제안 흐름을 나타낸 AI 개념 일러스트입니다.

4. 보류와 질문을 경력 산출물로 남기기

커리어에서 눈에 띄는 결과만 모으면, 문제를 정확히 좁히기 위해 멈춘 순간은 흔적 없이 사라진다. 그러나 AI 코딩 환경에서 보류는 종종 중요한 판단이다. 데이터 권한이 불분명하거나, 성공 조건에 동의하지 못했거나, 장애 경로를 아직 확인하지 못했다면 구현을 더 빨리 하는 일보다 질문을 남기는 일이 팀을 보호할 수 있다. 이것은 위험을 과장하자는 말이 아니라, 불확실성을 누구나 다시 확인할 수 있는 형태로 바꾸자는 뜻이다.

개인은 이 기록을 ‘도구를 써서 무엇을 만들었다’는 목록보다 구체적으로 쓸 수 있다. 예를 들어 “요약 기능의 초안을 만들었다”보다 “원문 대체 가능성이 있는 요구를 발견해 열람 경로와 검토 책임을 질문으로 남겼고, 답이 확인되기 전에는 제한된 범위의 초안만 검토했다”가 더 많은 판단을 보여 준다. 여기에는 개인이 한 일과 팀이 합의한 일을 구분해야 한다. 동료가 결정한 정책을 자신의 성과로 적지 않고, 아직 측정하지 않은 효과도 완료된 결과로 바꾸지 않는다.

이런 기록은 이력서의 문장을 화려하게 만들기 위한 장치가 아니다. 다음 프로젝트에서 같은 가정을 다시 확인하지 않게 하고, 면접·내부 이동·회고에서 본인이 어떤 불확실성을 어떻게 다뤘는지 설명할 수 있게 하는 작업 메모다. AI 시대의 경력 성장은 생성량을 개인 순위로 바꾸는 데 있지 않다. 문제를 구조화하고, 제약을 드러내고, 결과를 검증할 사람과 근거를 연결하는 습관을 축적하는 데 있다.

5. 다음 주에 해 볼 작은 실험

거대한 업무 체계를 새로 도입할 필요는 없다. 다음에 에이전트를 쓰는 작은 변경 하나를 골라, 앞의 카드에서 빈칸이 가장 많은 항목 하나만 채워 보는 것으로 시작할 수 있다. 사용자가 누구인지 불분명하다면 사용자 문제부터, 권한이나 되돌림이 불분명하다면 제약부터, 결과를 확인할 방법이 없다면 성공·실패 조건부터 정한다. 그 뒤 생성 결과를 검토하고, 채택하지 않은 이유도 한 줄 남긴다.

처음에는 회의록을 새로 길게 만들기보다 기존 이슈 하나에 ‘이번에 확인할 관찰’과 ‘답이 없으면 멈출 질문’을 추가하는 정도면 충분하다. 다음 변경에서 그 문장이 실제 검토를 도왔는지 되돌아보면, 팀에 맞지 않는 항목은 줄이고 빠진 경계는 보완할 수 있다. 중요한 것은 양식을 지킨 횟수가 아니라, 다음 사람이 이전 판단의 근거와 한계를 찾아볼 수 있는가다.

이 방법이 품질, 속도, 경력 기회를 보장하지는 않는다. 또한 규제가 강한 도메인의 공식 검토 절차나 보안 승인 과정을 대체하지 않는다. 그럼에도 작은 기록이 쌓이면 팀은 어떤 질문이 반복되는지, 어디에서 에이전트가 도움이 되는지, 어느 경계에서 사람이 판단해야 하는지를 더 분명하게 볼 수 있다. 그때 AI 코딩 역량은 새 도구의 이름을 아는 상태를 넘어, 문제에서 다음 결정을 안전하게 이어 주는 실무 능력이 된다.

출처와 적용 범위

• Andrew Ng, The AI Engineering Skills Map — 2026년 8월 공개된 스킬 맵의 범위, 네 가지 역량, 코딩 에이전트·명세·빌드 형성에 관한 설명을 확인했다. 이 글의 카드와 흐름은 해당 자료를 그대로 재현한 것이 아니라 편집부의 실무 제안이다.