AI 코딩 보조 도구가 통제 불능 상태로 흐르지 않게 하려면, 개발자는 우수한 요구사항을 작성하고 제품 관리 역량을 함께 키워야 한다.
이제 진지한 개발자라면 인공지능이 마법처럼 모든 일을 대신해 줄 것이라고 기대하지 않는다. 업계는 다소 불편하지만 보다 현실적인 합의에 도달했다. 인공지능은 훌륭한 인턴이 될 수는 있지만, 시니어 개발자를 대체하지는 못한다는 인식이다. 그리고 이 전제가 성립한다면 또 하나의 결론도 자연스럽게 따라온다. 인공지능이 인턴이라면, 개발자는 관리자가 된다.
문제는 다수의 개발자가 관리에 능숙하지 않다는 점이다.
이런 한계는 개발자가 깃허브 코파일럿, 커서, 챗GPT와 같은 도구를 사용하는 방식에서 매일같이 드러난다. 개발자는 “버튼을 파란색으로 바꿔라”거나 “데이터베이스 연결을 수정하라”와 같은 모호하고 불완전한 지시를 던진 뒤, 인공지능이 2019년 이후 존재하지 않는 라이브러리를 만들어내거나 핵심 인증 흐름을 심각한 보안 취약점으로 바꿔 놓으면 놀라움을 표한다. 그리고 책임은 모델의 한계로 돌린다. 아직 충분히 똑똑하지 않다는 평가다.
그러나 대다수 경우 문제는 모델의 지능이 아니다. 문제는 지시의 불명확함이다. 이런 도구에서 가치를 얻기 위해 필요한 것은 더 많은 프롬프트 요령이 아니라 더 나은 요구사항이다. 인공지능과의 상호작용은 주문을 외우는 행위가 아니라, 공식적인 업무 위임 과정에 가깝게 다뤄져야 한다.
다시 말해, 개발자는 더 나은 관리자가 돼야 한다.
빠져 있는 핵심 역량, 요구사항 작성
구글 엔지니어링 매니저 애디 오스마니는 최근 ‘AI 에이전트를 위한 좋은 요구사항 작성 방법’이라는 제목의 글을 공개했다. 이 글은 인공지능 관리자로서 역할을 제대로 수행하는 데 필요한 가장 실용적인 설계도로 평가된다.
오스마니의 목적은 자율 코딩이라는 공상과학적 미래를 설득하는 데 있지 않다. 핵심은 에이전트가 맥락을 잃거나 방황하지 않고, 과도한 정보에 압도되지 않도록 하는 데 있다. 오스마니가 제시한 핵심 메시지는 단순하지만 의미가 크다. 방대한 단일 요구사항을 한 번에 던지는 방식은 맥락 창 한계와 모델의 주의 자원 제약으로 인해 실패하는 경우가 많다는 점이다.
오스마니가 제안한 해법은 ‘스마트 요구사항’이다. 이는 에이전트에게 실질적으로 도움이 되도록 작성되고, 세션이 바뀌어도 유지될 수 있으며, 모델이 무엇이 중요한지 따를 수 있도록 구조화된 명세서를 의미한다.
이 역량은 ‘AI가 개발자를 10배 생산적으로 만든다’는 담론에서 종종 빠져 있는 핵심 요소다. 성과의 배율은 모델에서 나오지 않는다. 인간이 의도를 제약 조건으로 번역하고, 인공지능의 출력을 실제 동작하는 소프트웨어로 옮길 수 있을 때 발생한다. 생성형 AI는 시니어 엔지니어의 가치를 낮추지 않는다. 오히려 그 가치를 더 높인다.
프롬프트에서 제품 관리로
주니어 개발자를 지도해 본 경험이 있다면 이 원리는 이미 익숙하다. “인증 기능을 구현하라”는 한 문장으로 업무를 맡기지 않는다. OAuth 사용, 구글과 깃허브 로그인 지원, 세션 상태의 서버 측 관리, 결제 영역 비접근, 통합 테스트 작성, 엔드포인트 문서화까지 구체적으로 명시한다. 예시를 제공하고, 주의해야 할 지점을 짚으며, 작은 풀 리퀘스트 단위로 작업을 요구해 결과를 점검한다.
오스마니는 이런 관리 원칙을 에이전트 기반 업무 흐름으로 옮기고 있다. 먼저 상위 수준의 비전을 제시하고, 모델이 이를 확장해 상세한 명세서를 작성하게 한 뒤, 그 요구사항을 수정해 공동의 기준 문서로 만드는 방식이다.
이런 ‘요구사항 우선’ 접근법은 블로그 논의를 넘어 도구 수준으로 빠르게 확산되고 있다. 깃허브 인공지능 팀은 요구사항, 계획, 작업 단계를 거친 뒤에만 에이전트가 코드를 수정하도록 하는 스펙 키트를 공개했다. 젯브레인스 역시 에이전트가 코드 변경을 시작하기 전에 검토 지점이 필요하다는 동일한 주장을 내놓고 있다.
쏘트웍스의 비르기타 뵈켈러도 이 논의에 합류해, 많은 팀이 회피하고 있는 불편한 질문을 던졌다. 요구사항 기반 데모는 문제 정의가 불명확하거나 규모가 큰 경우에도 개발자가 요구사항 분석을 상당 부분 담당할 것이라는 전제를 깔고 있다는 점이다.
즉, 기업이 사람 간 요구사항 소통에도 어려움을 겪고 있다면, 에이전트는 해결책이 아니라 혼란을 증폭시키는 요인이 된다. 단지 더 많은 토큰을 소모할 뿐이다.
실제로 작동하는 명세서 템플릿
우수한 인공지능 요구사항은 의견 수렴 문서가 아니다. 변경 비용을 높이고 정확성을 낮은 비용으로 확보하기 위한 도구다. 오스마니는 간결한 제품 개요에서 출발해 에이전트가 상세 요구사항을 작성하도록 한 뒤, 이를 반복 사용 가능한 기준 문서로 다듬을 것을 권한다.
핵심은 포함해야 할 구성 요소다. 첫째, 목표와 비목표를 명확히 구분해야 한다. 무엇을 할 것인지만큼, 무엇을 하지 않을지도 명시해야 한다. 비목표는 사소한 수정 과정에서 CSS 전체를 리팩터링하는 식의 범위 확장을 막아준다.
둘째, 모델이 추론할 수 없는 맥락을 제공해야 한다. 아키텍처 제약, 도메인 규칙, 보안 요구사항, 연동 지점이 여기에 해당한다. 비즈니스 로직에 중요하다면 반드시 명시해야 하며, 인공지능이 규제 경계를 추측하도록 맡겨서는 안 된다.
마지막으로 가장 중요한 요소는 경계 설정이다. 명확한 ‘접근 금지’ 목록이 필요하다. 접근 금지 목록은 운영 데이터베이스 설정 삭제, 비밀 정보 커밋, 시스템을 지탱하는 레거시 디렉터리 수정과 같은 사고를 방지하는 안전장치다.
마지막으로 완료 기준이 필요하다. 완료의 정의는 테스트, 불변 조건, 자주 누락되는 경계 사례 등 검증 항목 형태로 제시돼야 한다. 이는 새로운 도구로 재포장됐을 뿐, 본질적으로는 올바른 엔지니어링이자 관리 원칙이다.
맥락은 프롬프트가 아니라 제품
개발자가 에이전트에 좌절감을 느끼는 이유 중 하나는 프롬프트를 단발성 행위로 다루기 때문이다. 실제로는 작업 환경을 설정하는 과정에 가깝다. 오스마니는 과도하게 긴 프롬프트가 맥락 한계뿐 아니라, 한 번에 너무 많은 지시를 담을 때 모델 성능이 저하된다는 점에서도 실패한다고 지적한다.
앤트로픽은 이런 접근을 ‘컨텍스트 엔지니어링’이라고 정의한다. 배경 정보, 지시 사항, 제약 조건, 도구, 요구 출력물을 구조화해 모델이 핵심을 안정적으로 따르도록 설계해야 한다는 의미다.
이 과정에서 개발자의 역할은 특정 API 문법을 아는 사람이 아니라, 비즈니스 문제에 어떤 API가 적합한지 판단하고 그 사실을 인공지능에 정확히 전달하는 사람으로 바뀐다.
에단 몰릭의 글 ‘AI 인턴 온보딩’도 같은 메시지를 담고 있다. 인턴이 유용한 영역과 성가신 영역, 위임해서는 안 되는 영역을 구분할 줄 알아야 하며, 이는 결국 판단력과 전문성을 의미한다.
코드 소유권의 함정
물론 위험도 존재한다. 구현을 인공지능에 맡기고 요구사항에만 집중하면 소프트웨어의 현실과 멀어질 수 있다. 허니콤 최고기술책임자 채러티 메이저스는 이 위험에 대해 지속적으로 경고해 왔다. 메이저스는 ‘코드 작성’과 ‘코드 소유’를 구분한다. 인공지능은 작성 비용을 거의 0에 가깝게 만들지만, 디버깅과 유지보수, 운영 환경 이해라는 소유 비용은 오히려 증가한다.
메이저스는 인공지능 도구에 과도하게 의존해 감독 역할만 수행할 경우, 개인의 기술 전문성이 빠르게 약화된다고 지적했다. 오스마니가 강조한 관리형 개발 모델은 깊은 기술 이해를 전제로 하지만, 모든 코드를 인공지능에 맡기면 그 전제가 무너질 수 있다. 해법은 혼합 접근 방식이다.
개발자 산칼프 슈브함은 ‘저단 기어로 운전하기’에 비유했다. 단순하고 반복적인 작업은 자동화 수준을 높여 인공지능에 맡기되, 복잡하고 새로운 문제는 기어를 낮춰 직접 개입해야 한다는 의미다. 핵심 알고리즘은 직접 작성하고, 인공지능에는 테스트 코드 작성만 맡기는 방식이 여기에 해당한다.
운전자는 개발자이며, 인공지능은 운전사가 아니라 엔진이다.
미래는 명확히 정의된 요구사항 중심으로 움직인다
아이러니하게도 많은 개발자는 관리 업무를 피하고 싶어 이 직업을 선택했다. 코드는 결정론적이며, 컴퓨터는 지시받은 대로 움직인다. 반면 인간과 인턴은 모호하고 지속적인 관리가 필요하다.
이제 개발자의 주요 도구가 바로 그 모호한 존재가 됐다.
이 환경에서 성공하려면 개발자는 기술이 아닌 소프트 역량을 강화해야 한다. 비전을 명확히 설명하고, 복잡한 문제를 인공지능이 맥락을 잃지 않고 처리할 수 있는 모듈형 작업으로 분해할 수 있어야 한다. 이 시대에 두각을 나타낼 개발자는 가장 빠르게 타이핑하는 사람이 아니라, 비즈니스 요구사항을 기술적 제약으로 정확히 번역해 인공지능조차 실수하지 못하게 만드는 사람이다.
dl-itworldkorea@foundryco.com
Matt Asay editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.