AI를 20개 병렬로 돌리니 PM의 업무가 되었다

이 글은 2026년 10월 AI 정보 교류회 LT에서 발표한 내용을 글로 정리한 것입니다. 슬라이드는 여기에 있습니다.

현재 맡고 있는 일은 AI를 이용해 판정(判定)을 수행하는 업무 시스템의 연구 개발입니다. 인프라, 백엔드, 프론트엔드, AI 연구까지 거의 모든 것을 AI 에이전트에게 작성하게 했습니다. 두 달 정도 만에 모든 가지(枝)를 합치면 누적 약 370만 줄, 커밋은 5,699건이 되었습니다.

그 과정에서 알게 된 것은, AI를 10~20개 병렬로 돌리면 엔지니어의 업무가 PM(Product Manager)의 업무에 가까워진다는 것입니다. 이 글에서는 사용하고 있는 도구와 체제, 하네스 엔지니어링(Harness Engineering)과 컨텍스트 엔지니어링(Context Engineering)의 노하우, 그리고 인간에게 남는 일에 대해 쓰겠습니다.

20개 병렬은 연구 개발 특유의 방식입니다. 하지만 그 과정에서 필요하게 된 시스템(AI에게 인계하는 방법, 성과의 확실한 측정 방법, 같은 실수를 반복하지 않는 노하우)은 AI를 하나만 사용하는 개발에서도 유용할 것이라고 생각합니다.

프로젝트 고객이나 업무 내용은 적을 수 없어, 시스템과 숫자만을 기록했습니다. 숫자는 2026년 10월 초 기준으로 계산한 것입니다.

사용하고 있는 도구와 비용

AI에게 지출하는 돈은 구독료만으로 매달 13~14만 엔입니다. Claude Max 20x에서 사용할 수 있는 Opus는 총괄 역할, 상담 역할, 평가 역할을 담당합니다. ChatGPT Pro의 Sol (GPT-6.1)은 작업 역할과 리뷰 역할을 맡습니다. 이 외에 프로젝트 비용으로 API도 사용하고 있습니다.

생산성은 측정하지 않았지만, 체감상으로는 30배 정도입니다. 그렇게 생각하면 저렴한 투자라고 생각합니다. 비싸긴 하지만요.

모델 선택은 '몇 개 병렬로 얼마나 오래 사용할 수 있는지'를 기준으로 합니다. 이는 본인의 사용 방식에서 체감하여 측정한 숫자가 아닙니다.

반면에 일반적인 업무 시스템 개발이라면, 작업 역할은 OpenCode나 Hermes Agent, Claude Code 등에서 DeepSeek 같은 저렴한 모델을 사용해도 충분할 수 있습니다. 작업별로 적합한 AI를 전환하면 비용을 더 낮출 수 있을 것 같습니다. 다만, 이는 아직 시도하지 않은 방안입니다. 프로젝트에 따라 사용할 수 있는 모델에 조건이 있습니다(데이터 처리 방식이나 제공 국가 등). 전환하기 전에 확인해야 합니다.

전부 읽는 것은 이제 불가능하다

현재 프로젝트 규모는 다음과 같습니다.

20개 병렬로 무엇을 하고 있는가

양의 대부분은 연구 실험입니다. 개선 방안을 가지(枝)로 만들어 점수를 매겨 비교합니다. 대부분은 버립니다.

어느 날 병렬 작업의 내용은 대략 다음과 같습니다.

하나의 작업 흐름 (실험의 경우)

• 사람이 상담사에게 이야기한다. 예를 들어 '놓치는 것을 줄이고 싶다'.
• 총괄 역할이 이슈(Issue)를 만들고, 작업 역할에 부탁한다. 작업 역할은 이슈마다 새로운 대화와 가지로 움직인다.
• 작업 역할이 안을 만들고 커밋(commit)하여 태그를 붙인 후 실험을 돌린다.
• 평가 역할이 정답 데이터로 점수를 매긴다. 작업 역할에게는 정답을 보여주지 않는다.
• 다른 AI가 리뷰한다. 점수가 올라도, 다른 부분이 나빠졌다면 채택하지 않는다.
• 판정 기준을 크게 바꾸는 것은 사람이 채택할지 결정한다. 화면에 나오는 문장은, 사람이 이전과 이후를 보고 합격/불합격을 내린다.
• 버린 안도 기록과 태그를 남긴다. 같은 안을 두 번 시도하지 않기 위해서.

사람이 보는 것은 방향성(방침)과, 채택할지 여부와, 화면에 나오는 말입니다. 코드의 세부 사항은 보고 있지 않습니다.

AI 시스템 구조

제가 이야기하는 것은 상담사 AI뿐입니다. 총괄 역할의 대화는 거의 보지 않습니다.

지시는 상담사에서 총괄 역할로, 총괄 역할에서 작업 역할로 흘러갑니다. 작업 역할은 이슈마다 새로운 대화로 움직이며, 자신을 총괄 역할 이외의 지시는 받지 않습니다. 작업과 리뷰는 다른 AI로 분리하여, 자신이 작성한 PR(Pull Request)을 스스로 병합(merge)하는 일은 없습니다. 밤에는 자동으로 돌리고, 낮에는 제가 직접 주도한다는 방식입니다.

상담사 역할을 둔 이유

총괄 역할(오케스트레이터)까지만 사용한 사람도 많다고 생각합니다. 저는 인간과 총괄 역할 사이에 또 하나의 AI를 끼워 넣었습니다.

총괄 역할을 Opus 5.5로 바꾸니 상당히 좋았다

역할에 배치하는 모델은 여러 번 바꿨습니다. Sol 혼자 시작해서, Astra가 총괄과 리뷰를 맡고, Astra 혼자, Astra가 총괄도 작업도(이건 너무 비쌌습니다), Astra가 총괄하고 Opus가 작업을 하고, Sol이 총괄하는 식으로 바뀌었습니다. 지금은, Opus가 총괄 역할이고 Sol이 작업 역할 및 리뷰 역할을 합니다.

Astra가 총괄이었을 때는, 간단한 작업이라도 작업 역할에게 세부적인 체크를 반복해서, 10시간 가까이 진행되지 않는 경우가 있었습니다. 병합 기준을 건너뛰는 경우도 있어서 스트레스가 많았습니다. 하네스(Harness)가 이전 모델용이었던 영향일 수도 있습니다.

Opus 5.5가 총괄이 된 후로는, 그런 일은 거의 일어나지 않았습니다. 작업 분배 방식이 5병렬 정도에서 20병렬 정도로 늘어나서, 정말 센스가 좋습니다. 밤에는 무리하게 사람을 깨우지 않고, 할 수 있는 것부터 진행하고, 확인하고 싶은 것은 아침에 모아줍니다. 제대로 잠을 잘 수 있게 되었습니다.

제 방식으로는, OpenAI 계열은 구현(실행), Anthropic 계열은 전체를 보는 역할을 분담하고 있습니다.

바꿔보니 알게 된 것도 있습니다. 규칙에 모델 이름을 쓰면, 바꿀 때마다 전부 고쳐야 합니다. 그래서 규칙은 역할(총괄 역할・작업 역할・리뷰 역할)으로 작성하고, 어떤 역할에 어떤 모델을 배치할지는 하나의 표로만 작성하도록 했습니다.

하네스 엔지니어링

AI를 하나 사용할 때부터 도움이 되는 생각입니다. 제 경우는, 병렬로 돌리고 오랜 시간 맡기기 시작한 후, 자체적인 시스템이 급격히 늘어났습니다.

AI에게 오랜 시간을 맡길 때 발생하는 일

자주 있는 것은 다음과 같습니다.

AI에게 말했던 불만과 오차를 모아보니, 약 2주 만에 184건이 되었습니다. 가장 많았던 것은 시험이나 감시의 허점, 일정 지연, 정했음에도 효과가 없는 세 가지였습니다. 이 모든 것을 지적하면 바로 인정하지만, 시스템으로 만들지 않으면 또 발생합니다.

AI에게 지시하는 문구를 추가하는 것만으로는 또 빠뜨립니다. 그래서 시스템으로 막기로 했습니다.

하네스 엔지니어링(Harness Engineering)이란

harness는 마구(馬具)를 뜻합니다. 말의 힘을 원하는 방향으로 사용할 수 있게 하는 일련의 도구를 말합니다. AI로 치면, 모델 주변에 놓이는 도구, 규칙, 검사, 기록, 알림 시스템 전체를 의미합니다.

OpenAI 기사 'Harness engineering'에는 사람이 손으로 작성한 코드는 0줄이고, 사내용 제품을 5개월 만에 만든 사례가 실려 있습니다[2]. 규모는 약 100만 줄, 약 1,500 PR이었으며, 처음에는 3명이 하루 평균 3.5 PR을 처리했다고 합니다. 기사의 핵심 문구는 'Humans steer. Agents execute.'로, 사람은 방향을 잡고(조종하고), 에이전트가 실행합니다. 실패했을 때 '더 노력해라'라고 말하는 대신, 부족한 능력이 무엇인지 생각하여 에이전트가 이해할 수 있고 기계적으로 지킬 수 있는 형태로 만드는 것이라는 관점입니다.

엔지니어의 업무는 코드를 작성하는 것에서 환경을 설계하고, 의도를 전달하며, 에이전트가 확실히 작동할 수 있는 피드백 시스템을 만드는 것으로 이동합니다. 모델이 바뀌어도 시스템은 남습니다.

자주 언급되는 노하우

아래는 OpenAI와 Anthropic 기사에서 자주 언급되는 노하우입니다.

• 진입 파일은 목차로 만듭니다. 큰 AGENTS.md 파일을 하나 만드는 것은 실패했다고 OpenAI가 작성했습니다[2:1]. 100줄 정도의 목차를 만들고, 자세한 내용은 docs/로 안내합니다. - AI에게 보이지 않는 지식은 없는 것과 같습니다. Google Docs나 채팅, 사람의 머릿속에 있는 결정 사항은 리포지토리에 적습니다[2:2]. - 규칙은 시스템으로 지키게 합니다. linter나 구조 테스트로 막고, 에러 문구에 수정 방법을 써서 AI가 읽게 합니다[2:3]. - AI가 스스로 확인할 수 있게 만듭니다. 화면, 로그, 메트릭스를 AI가 직접 볼 수 있도록 합니다. 사람처럼 브라우저를 조작하게 하니 크게 좋아졌다고 합니다[3]. - 긴 작업은 기록으로 인계합니다. 새로운 대화는 이전 기억 없이 시작하므로, 진행 상황 파일, 기능 목록, git commit을 남기고 한 번에 하나의 기능을 진행합니다[3:1]. - 주기적으로 청소합니다. 지켜야 할 원칙을 적어두고, 주기적으로 작동하는 AI가 오차를 찾아내어 수정 PR을 올립니다[2:5].

하지만 OpenAI 기사 자체도 이 방식은 해당 리포지토리의 구조와 도구에 강하게 의존하며, 그대로 다른 곳에 적용된다는 보장은 없다고 작성합니다[2:6]。

이번 프로젝트에서 겪었던 어려움과 해결한 방법

스킬이나 프롬프트도 같은 방식으로 시도해 볼 수 있습니다. OpenAI의 스킬 평가 기사는 10~20개의 과제(실제 실패 사례를 만드는 것 포함)를 준비하고, 바꿀 때마다 점수로 비교하는 것을 권장합니다[4]. '좋아진 느낌'으로 결정하지 않기 위해서입니다.

규칙을 추가만 하면 계속 무거워진다

사고가 발생할 때마다 규칙을 추가하면 까다로운 것들만 늘어갑니다. 늦어졌다는 것은 보이지 않습니다. 아무리 말해도 원하는 구현이 되지 않으니, 지표를 넣었습니다.

DORA 지표는 이전에는 '4가지 핵심 요소(4 keys)'라고 불렸습니다. 2023년에는 '서비스 복구 시간'이 '실패한 배포 후의 복구 시간'으로 바뀌었고, 2024년에는 '배포 재작업률'이 추가되어 총 5가지가 되었습니다[5][6]. 재작업률은 본 서비스 문제 때문에 발생하여 예정에 없던 배포를 한 비율을 의미합니다.

OpenAI의 기사에서도 병합(merge)을 막는 관문은 최소한으로 하도록 합니다. 고치는 것은 저렴하지만, 기다리는 것은 비싸기 때문입니다. 다만, 이는 처리량(throughput)이 높은 환경에서만 가능한 이야기이며, 그렇지 않다면 무책임하다고도 언급하고 있습니다[2:7]。

AI는 팀에 이미 있는 것을 증폭시킨다

DORA의 2025년 보고서에 따르면 응답자의 90%가 업무에 AI를 사용하며, 80% 이상이 생산성 향상을 느꼈습니다. 한편, AI는 처리량과는 정(+)의 관계였으나, 배포 안정성과는 부(-)의 관계였습니다[7]. 강점도 약점도 증폭됩니다.

DORA는 AI 효과를 극대화하는 7가지 역량을 제시했습니다[8]. 이 프로젝트에서 적용한 것과 비교해 보았습니다.

컨텍스트 엔지니어링(Context Engineering)

AI에게 무엇을, 어떤 순서로, 어느 정도까지 읽게 할 것인가에 대한 이야기입니다.

AI 에이전트를 일반적으로 사용할 때 발생하는 일

대화가 길어질수록 AI는 이전 지시를 잊고 답변의 질도 떨어집니다. 관련 없는 파일까지 읽느라 헤매고, 느려지고, 비용도 발생합니다. 오래된 문서와 새로운 문서 내용이 상충할 경우, 오래된 내용을 따르는 경우가 드물지 않습니다. 자동 압축을 거친 후 중요한 결정 사항이 빠지는 경우도 있습니다. 압축 후에 갑자기 영어로 답변하기 시작한 적도 있었습니다. 매번 새로운 대화마다 같은 설명을 다시 하는 것도 번거롭습니다.

AI가 한 번에 읽을 수 있는 양에는 한계가 있으며, 많이 넣을수록 개별 항목에 대한 주의력이 흐트러집니다. Anthropic은 이를 context rot이라고 부르며, 어떤 모델에서도 발생한다고 합니다[10]。성능이 절벽처럼 떨어지는 것이 아니라, 언덕을 내려오는 것처럼 점진적으로 떨어집니다.

컨텍스트 엔지니어링이란?

Anthropic의 기사

먼저 문서의 배치에 대해 말씀드리겠습니다. 진입점인 AGENTS.md는 지도 역할만 하고, 작업별로 '가장 먼저 읽을 것'을 안내하고 있습니다. 큰 문서는 맨 앞에 요약과 목차를 두고 '여기까지만 읽으면 충분하다'는 표시를 합니다. 그리고 진입 문서의 크기는 검사(inspection)를 통해 제한합니다. 같은 정보를 작성하는 것은 한 곳에서만 이루어집니다. 용어표나 어떤 역할에 어떤 모델을 배정할지에 대한 표 등이 그렇습니다. 무슨 일이 일어났는지 기록과 어떻게 할 것인지에 대한 규칙도 분리하여, 오래된 지시가 현재의 지시와 혼동되지 않도록 합니다.

대화 및 기억(Memory) 측면에서는 작업 역할은 이슈(Issue)마다 새로운 대화를 시작하며, 끝난 대화는 다른 이슈에서 재사용하지 않습니다. 총괄 역할과 상담 역할은 매일 새로운 대화로 변경하기로 했습니다. 인수인계 메모는 하루에 한 번이며, 평소에는 자동 압축에 맡기고 있습니다. 기억해야 할 내용은 하나의 사실(fact) 단위로 메모리에 기록하고 있으며, 현재 약 360건 정도가 있습니다. 평가의 정답 데이터는 작업 역할과 판정 엔진 모두에게 보여주지 않습니다. 점수를 매기는 것은 평가 역할입니다. 만약 보여주면, 답을 본 상태에서 '정확도가 높아졌다'고 착각하게 되기 때문입니다.

여기에는 몇 가지 까다로운 부분도 있습니다. 연구 작업은 서브 에이전트나 작은 모델로 나누지 않고, 강력한 모델에게 그대로 맡기고 있습니다. Terminal-Bench-Science 점수가 낮은 모델에게 맡겼을 경우, 판정 엔진의 성능이 나오지 않았기 때문입니다.

인간이 장악하는 영역

코드의 세부 사항은 더 이상 추적하지 않습니다. 하지만 기술을 완전히 놓아버린 것은 아닙니다.

장악하고 있는 부분은 다음과 같습니다.

• 설계 판단: 예를 들어, 동시에 업데이트가 발생했을 때 어떻게 할지(낙관 잠금/비관 잠금), 긴 처리를 어디서 실행할지(SQS 같은 큐), 중단 시 처리 과정이 누락되지 않도록 할지(그레이스풀 샤트다운)
• 프런트엔드 구성과 AI 시스템의 내부 구조
• 최초 설계: AI와 대화하면서 인간이 수행하는 부분
• 고객, 타 부서, 타사 엔지니어와 소통할 수 있는 수준의 기술력
• AI 결과물을 통제할 수 있는 추상도에서의 이해

맡기고 있는 것은 AI 개선의 세부 사항입니다. 약점을 파악하여 분야별로 나누면, 작업을 요청하거나 딥 리서치(deep research)를 통해 방법을 찾아 순차적으로 시도하게 합니다. 코드의 상세 내용은 '무엇을 하고 있는지', '어떤 접근 방식을 취하고 있는지' 정도만 파악합니다. 보안 검사 및 테스트 작성 역시 AI에게 맡기고 있습니다. 업무 시스템이라면, 사양서에서 테스트 코드를 작성하게 한 후 통과하지 못하면 수용(acceptance)을 중단시킵니다. 그 위에서, 사양-구현-테스트 중 어디가 불일치하는지 확인한다는 방식으로 사용합니다. PoC의 경우, 사양서가 머릿속에만 존재하는 경우도 있습니다.

사람이 읽는 언어는 사람이 보는 것

화면에 표시되는 AI 코멘트 문구를 변경할 때는, 이전과 이후의 3~5가지 예시를 나열하고 자신이 승인한 후에 반영합니다. AI가 '안전을 위해'라며 화면의 코멘트 카드 자체를 삭제하려 했던 경우도 있었습니다. 이를 막고, 노출하는 것은 비밀이나 사내 용어만으로 제한하기로 결정했습니다. 사람이 읽는 문서는 배포 전에 'AI스러움(AI-っぽさ)' 검사를 거칩니다.

또 하나 불편한 점은 AI가 지나치게 하려는 경향입니다. 실무 질문에 대해 연구적인 엄격함으로 '며칠/몇만 원이 걸립니다'와 같은 예상치를 제시해 옵니다. 그 정도까지는 필요하지 않은 경우가 많기 때문에, 짧은 안으로 줄이는 것은 사람의 몫입니다. 무엇을 버리면 무엇을 잃는지도 AI에게 나열하게 합니다.

판단을 간소화하는 시스템

하루에 수십 번씩 판단을 요청받기 때문에, 한 번의 결정을 가볍게 만들지 않으면 돌아갈 수가 없습니다. 설명이나 비교가 필요한 결정은, 이전과 이후, 표, 추천 사항을 나열한 HTML 페이지를 AI에게 만들게 한 후 듣는 것이 원칙입니다. 들을 때는 선택지가 있는 질문 카드 형태로 만들어 자신이 고르기만 하면 되도록 합니다.

결정된 것은 나중에 수정할 수 없는 기록 파일로 남깁니다. 약 2주 동안 약 920건, 많으면 하루에 120건 정도 됩니다. 수정 불가능한 기록으로 남겨두면, 나중에 무엇을 언제 결정했는지 확인할 수 있습니다. 이는 AI에게 지시를 내린 근거가 되기도 합니다.

자동화는 아직 진행 중

루프를 돌려 AI의 성능을 전부 끌어내는 단계까지는 자신의 기술이 아직 도달하지 못했습니다. 밤에는 자동으로 작업을 시키고, 낮에는 대화하며 직접 통제하고 있습니다. 따라서 구성과 아키텍처를 파악해 두지 않으면 AI 결과물을 제어할 수 없습니다. 이곳은 아직 엔지니어의 영역이라고 생각합니다.

Computer Use는 편리합니다. 코드에 남기고 싶지 않은 E2E 테스트도 Computer Use로 수행할 수 있습니다. 인프라부터 프런트엔드까지 모두 보고 있기 때문에 배포가 전체적으로 이루어지고, E2E 테스트가 늘었습니다. 배포할 때마다 검증 환경에서 실제로 1~3건을 돌려본 후에 수용하고 있습니다.

안전하게 사고하기

AI를 사용해 따라잡으려고 해도, 처음 접하는 분야에서는 함정에 빠지기 쉽습니다. 개발 환경과 검증 환경에서 DB에 연결할 수 없었던 적이 있었습니다. DB 인증 정보가 자동으로 전환되는 설정이었는데도 앱은 실행 시 읽었던 오래된 값 그대로였습니다. 헬스 체크(Health Check)가 DB를 확인하지 않았기 때문에 한동안 알아차리지 못했습니다. 접근 제한 설정으로 인해 통과해야 할 통신까지 막았던 경우도 있었습니다.

그래서 보안과 라이선스는 먼저 확정하고, 망설여지면 더 엄격한 쪽을 선택하도록 합니다. 보안이 무너지면 프로젝트와 고객 모두가 무너져 버리기 때문입니다. 죽지 않는 인프라를 만든 후에 실패하는 순서입니다.

AI를 사용하더라도 분야별 운영의 감각(勘所)은 필요합니다. 실제로 운영해 보면서 처음 부딪히는 것들이나 모르는 것들이 나오기 때문입니다. 사고는 피할 수 없으니, 안전하게 사고한다는 생각입니다.

엔지니어는 PM이 된다

10~20개 병렬로 진행하면 누가 무엇을 하고 있는지 일반적으로 알기 어려워집니다.

Issue에 전부 남겨두어도 바쁜 날에는 Issue와 PR(Pull Request)만으로 하루 67건이 되었습니다. 실험도, 인프라도, 연구도, 하네스(Harness)도 모두 Issue에 넣기 때문입니다. AI가 관리하는 요청 목록은 상한에 여러 번 도달하여, 12개에서 60개까지 늘렸습니다. 1~2시간 만에 끝날 것이라 생각했던 작업이 AI에게 물어보니 '앞으로 5일'이었다는 경우도 있었습니다.

이렇게 되자 발상은 '프로젝트 관리 메커니즘을 도입해야겠다'입니다.

AI의 PM을 AI가 맡고, 자신은 그 PM과 대화한다

지금은 요청마다 AI가 관리하는 목록에 한 줄씩 남기고, 끝날 때까지 지우지 않는 규칙을 가지고 있습니다. 담당 AI가 없는 요청, 기한이 지난 요청, 인계가 필요한 요청은 프로그램이 찾아내어 총괄자에게 알립니다. 자문역(相談役)은 매시간 순찰하며 멈춰 있는 것을 찾습니다. 완료했다고 할 수 있는 것은 측정했거나, 보고했거나, 자신이 확인했다는 세 가지 증거가 모였을 때뿐입니다.

사실 AI에게 태스크를 추정하게 해서 간트 차트를 만들고, 어떤 태스크를 언제까지 끝낼지 기한으로 관리하고 싶습니다. 아직 그 정도의 메커니즘은 만들지 못했습니다.

현재 하고 있는 일은 계획을 세우고, 완료시키고, 계획을 재검토하는 것입니다. 현장의 AI와 인식이 어긋나지 않도록 하는 것도 포함하여 PM 업무를 하고 있다는 느낌에 가깝습니다.

AI 조직만의 어려움

AI에서 다른 AI로 보내는 알림이 '자동 전송으로 보인다'는 이유로 사람이 다음 입력을 할 때까지 멈춘 적이 있었습니다. 지금은 파일 수신함과 스마트폰 알림을 사용하고 있습니다.

작업은 끝났는데 보고가 수신함에 도착하지 않는 경우도 하루에 세 번 있었습니다. 완료된 작업과 수신함을 대조하는 스크립트를 만들었습니다.

대화는 매일 바꿀 규칙을 정했는데도, 자문역은 같은 대화를 3일 동안 이어가는 적이 있었습니다. 규칙을 정해도 AI가 지킬 수 있는 것은 아닙니다.

앞으로의 커리어

최근 Flutter 엔지니어로 불리는 일이 줄어들었습니다. 인프라, 백엔드, 프론트엔드, 보안, SRE를 모두 보는 횡단적인 업무가 많습니다. 앱 개발에서도 Flutter가 아니거나 웹을 보기도 합니다.

따라잡기는 필요합니다. 하지만 예전처럼 기술의 세부 사항까지 모르면 일할 수 없다는 상태는 아닙니다. 'Flutter 할 수 있어요', 'Rails 할 수 있어요'와 같이 특정 기술만을 강점으로 삼아 커리어를 쌓는 것은 상당히 어려워질 것이라고 생각합니다. 세부 사항은 AI가 할 수 있기 때문에, 인간이 하는 일은 더 상류(上流)에 있거나 종합직 같은 업무가 될 것입니다.

그렇다고 해서 누구나 괜찮다는 의미는 아닙니다. 경험은 요구됩니다. 앱이라면 릴리스 경험이나 리젝트 대응과 같은 업무 경험이 필요합니다. 분야의 경험은 필요하지만, 그 분야를 특정 기술이 아닌 종합적으로 한다는 형태가 되어가는 것이 흥미로운 부분입니다. '기술의 종합직'이라는 표현이 가까울지도 모릅니다.

앞으로 몇 년 동안 할 수 있을까

5년 정도 후에는さすがに 어려울 수도 있습니다. 지금의 기술 종합직 업무도 언젠가 AI가 할 수 있게 될 것이라고 생각합니다. 그렇게 된다면, 아마 AI를 사용해서 살아갈 길을 찾아나갈 것 같습니다.

개인 개발은 쉬워졌습니다. 3일 정도 만에 만든 앱 중 하나는 이번 달 1,200엔(지난달은 600엔), 또 다른 것은 월 2,000~3,000엔의 매출이 있습니다. 아주 작지만 돈이 되는 것을 쉽게 만들 수 있습니다. 조금 난이도가 있는 toC도 가능합니다.

다산다사(多産多死)로 하는 것도 방법입니다. 인간의 능력이 확장되면서 할 수 있는 것이 늘어나고 있습니다. 어떻게든 될 것 같다는 기분은 합니다.

맺음말

AI를 20개 병렬로 돌리니, 코드를 작성하는 시간은 거의 사라졌습니다. 대신 늘어난 것은 AI가 작동할 환경을 만드는 것, AI에게 무엇을 읽게 할지 결정하는 것, 그리고 계획을 세우고 실행하는 것입니다. 어느새 PM(Product Manager)의 일을 하고 있었습니다.

내일부터 시도해 볼 수 있는 것을 3가지만 말씀드리겠습니다. 모두 AI를 하나 사용할 때부터 효과가 있습니다.

• AI에게 요청하기 전에, 완료된 작업을 무엇으로 확인할지 결정한다.
• 긴 대화는 확정된 내용과 다음 작업을 짧게 적어 새로운 대화로 인계한다.
• 같은 실수를 두 번 했다면, 주의 문구를 추가하는 대신 체크리스트나 기록 시스템을 만든다.

마찬가지로 AI를 적극적으로 활용하고 있는 분들이 어디까지 맡기고, 무엇을 쥐고 있는지 듣고 싶습니다.

주식회사 Good Welchi에서 AI 구동 개발의 도입 및 운영 상담을 받고 있습니다. AI 에이전트를 규칙(Rule), 자동 테스트(Automatic Test), 리뷰에 넣어 개발 흐름에 통합하는 것부터 도와드릴 수 있습니다. 모바일 앱(Flutter)이나 기술 자문도 괜찮습니다.

편하게 문의주세요.

Vals AI 'Terminal-Bench Science' https://www.vals.ai/benchmarks/terminal-bench-science ↩︎

OpenAI 'Harness engineering' https://openai.com/index/harness-engineering/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

Anthropic 'Effective harnesses for long-running agents' https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩︎ ↩

OpenAI 'Testing Agent Skills Systematically with Evals' https://developers.openai.com/blog/eval-skills ↩︎

DORA 'DORA’s software delivery performance metrics' https://dora.dev/guides/dora-metrics/ ↩︎

DORA 'A history of DORA’s software delivery metrics' https://dora.dev/insights/dora-metrics-history/ ↩︎