AI는 내 일자리의 강탈자가 아니다. 내 동료이고 스승이며 후임이다.

AI를 사용하면서 느낀 것은 AI가 내가 처음 학습을 시작할 때 모르는 것을 알려주는 좋은 스승이자, 코드를 작성할 때 어떻게 구현하는 것이 좋은지 토론할 수 있는 동료이자, 실제 작업을 진행할 때 방법을 학습시키고 제대로 구현되었는지 확인하는 후임 같은 존재라는 것이다.

함께 가는 동반자이지 나를 대체하는 존재가 아니다. 다만 학습해야 하는 방향성이나 업무 패러다임은 많은 변화가 있을 것이 확실하다. 하지만 개발 자체를 대체하지는 않는다는 것도 사실이다.

결국은 사람이 해야 한다

AI가 모든 것을 다 해주는 것 같지만, 결국 무엇을 해야 할지 정하고 어떤 방식으로 어떤 기술을 사용할지 결정하는 것은 사람이다. AI는 그 과정에서 고민하고 학습하고 커뮤니케이션하는 비용을 획기적으로 줄여줄 뿐, 실제 의사결정과 방향성 제시는 사람의 몫이다.

비개발자도 AI의 도움으로 개발을 할 수 있다고 하지만, 이는 초기 단계에만 적용된다. 시스템이 복잡해질수록, 다양한 예외 상황을 고려해야 할수록 기본적인 개발 지식 없이는 진행이 어려워진다.

또한 문제 해결 방법이 적절하지 않다면, 다음 문제를 해결할 때 기존 코드 구조가 모래성처럼 무너질 가능성이 높다. 이를 방지하려면 AI가 올바른 학습을 해야 하고, 학습의 내용과 품질, 그리고 방향을 결정하고 지도하는 주체는 결국 사람이어야 한다.

CLI 버전의 무한한 가능성

CLI 버전이야말로 개발 AI 도구로서 가장 완벽하다고 생각한다. 터미널상에서 사용할 수 있는 기본 모듈이나 표준화된 도구들이 매우 많고, AI는 이러한 도구들을 매우 잘 활용한다. 그래서 일반적으로 이야기하는 워크플로우도 별다른 설정 없이 미리 정해진 프롬프트만 실행하면 웬만한 워크플로를 구축할 수 있다. 여기에 MCP(Model Context Protocol)까지 연결하게 되면 가능성은 더욱 확장된다.

예를 들어, 일정 시간마다 나에게 할당된 Jira 티켓이 있는지 확인해서 대기 중인 티켓만 골라 각각의 티켓을 해결하는 worktree를 생성하고, 개별로 작업을 수행한 후 그 결과를 PR로 자동 생성하는 워크플로우를 구축하고 싶다고 하자.

먼저 Jira를 MCP로 연결하거나 curl로 Jira REST API에 접근해서 나에게 할당된 티켓 정보를 가져올 수 있다. 이 중에서 특정 상태인 티켓만 필터링하는 것도 가능하다. 이 과정도 API 문서만 제공해서 학습시키면 관련된 동작을 잘 수행할 것이고, 성공한 결과를 가지고 프롬프트로 만들어서 실행해 보면서 예외 케이스를 추가하면 된다.

여기까지 되면 Jira 티켓 번호로 로컬에 브랜치를 생성하게 하면 된다. Git 터미널도 있고 GitHub API도 존재하기 때문에 이를 이용해서 브랜치를 생성하게 하고, Jira의 내용을 바탕으로 문제를 해결하는 코드를 스스로 작성하게 할 수도 있다.

그다음에 작업이 완료되었다고 판단되면 PR을 원격에 생성하게 하면 된다. 개발자는 이 생성된 PR을 검토하거나 브랜치를 로컬로 가져와서 실행해 보면서 수정사항이나 미비 사항을 Jira에 남기거나 PR에 리뷰로 남기면, AI가 이를 다시 인식하게 할 수 있다 (인식시키는 방법은 Git 트리거를 사용하거나 일정 시간마다 호출하는 방식을 사용하면 된다).

이 과정을 반복하다 보면 자잘한 이슈는 자동으로 해결되고, 사람은 AI가 처리하기 어려운 복잡한 문제나 제대로 구현되지 않은 부분만 처리하면 된다. 즉, 개발 생산성이 크게 향상되는 것이다.

이렇게 터미널 기반으로 AI 개발 환경을 구현한다는 것은 생각보다 상상하는 모든 것을 가능하게 할 수도 있다.

똑똑한 AI vs 성능이 낮은 AI

Claude, Gemini, ChatGPT, Grok 등 여러 다양한 AI를 사용하다 보면 같은 질문에 전부 다른 답변을 한다. 답변의 품질은 결국 토큰을 얼마나 사용했느냐와 얼마나 많은 데이터로 학습되었느냐에 따라서 달라지는 것 같다.

그렇다면 성능이 높은 AI가 항상 좋을까?

실제 업무에 활용해보면서 느낀 것은 고성능 AI는 토큰을 많이 사용한다는 점이다. 즉, 비용이 문제가 된다. 그렇다고 저렴한 모델을 사용하면 답변의 품질이 문제가 된다.

그렇다면 성능이 낮은 AI는 불필요한 것일까?

사실 그렇지 않다. 결국 사람이 질문을 하는 것이기 때문에 질문의 수준과 난이도를 낮추면 토큰을 많이 사용하지 못하는 AI도 문제없이 작업을 수행하고 원하는 품질의 결과를 낸다.

즉, 문제를 잘게 쪼개서 해당 AI가 질문을 이해하고 처리할 수 있는 토큰 사용량에 맞게 작업을 시키면 답변의 품질은 크게 차이나지 않는다.

결국 핵심은 AI의 토큰 사용량에 맞게 얼마나 작업을 작게 쪼개서 분배하고 다시 합칠 수 있느냐, 그 설계를 어떻게 할 것이냐이다.

토큰을 많이 소모하는 고성능 모델은 추상적이거나 애매한 질문에도 좋은 품질을 보여주기 때문에 복잡한 문제를 해결하거나 조각나 있는 프로젝트를 하나로 통합할 때 사용하면 좋다.

반면 문제를 조각내서 작업하는 것은 저렴한 AI를 이용한다면 전체적인 토큰 소모량은 확실히 줄어들 것이다.

소규모 작업에는 Gemini, Codex를 사용하고 이를 통합하거나 많은 추론이 필요한 작업은 Claude를 사용하는 것이 현재 시점에서 최적의 조합이라고 생각한다.

만약 문제를 작게 나누어서 분배하고, 이를 검토하고 합치는 것까지 자동으로 할 수 있다면? 그런 AI 파이프라인을 구축할 수 있다면? 이것이 향후 발전 가능성이 높은 아키텍처가 아닐까?

AI 개발 워크플로우

지금 내가 생각하는 AI 개발 워크플로우는 다음과 같다.

단계별로 살펴보면:

1. JIRA 티켓 등록

티켓을 등록하는 방법은 어떤 것이든 상관없다. 현재 JIRA를 사용해서 작업할 뿐이고 (개인적으로 JIRA가 불편하다고 생각한다), 어떤 프로젝트 관리 프로그램을 사용하든 상관없다. 다만 웹훅을 지원해주는 것이 좋다.

티켓 구조는 스토리를 Claude가 처리할 티켓으로 정의하고, 하위 티켓으로 잘게 쪼개서 등록해야 한다. 스토리 티켓의 내용에는 하위 티켓을 어떻게 연결해서 어떤 기능을 만들 것인지, 최종 결과가 무엇인지를 명확하게 작성해야 한다.

하위 티켓은 Gemini가 가져가서 개별로 작업할 티켓이다. Gemini를 선택한 이유는 토큰 소모율이 현재 가장 낮다고 생각되기 때문이다. 토큰을 많이 사용하지 못하고 성능이 제한적이므로, 작업을 나눌 수 있는 만큼 잘게 쪼개서 상세하게 작성해야 한다.

티켓에는 작업 후 TDD, end-to-end 테스트를 어떻게 할 것인지에 대한 내용도 포함해야 한다.

2. 작업별로 worktree 생성

웹훅은 Gemini와 Claude 둘 다에게 전달된다. Gemini는 서브태스크의 상태가 진행 중인 경우에만 작업을 수행한다. Claude는 전체 서브태스크의 상태를 확인한 후, 모든 서브태스크가 완료된 경우에만 작업을 수행한다.

Gemini는 JIRA 티켓의 내용을 바탕으로 정해진 규칙에 따라서 worktree를 생성한다.

티켓 내용대로 작업을 진행하고 테스트까지 통과되면 PR을 생성하고, JIRA 티켓의 상태를 작업 완료로 업데이트한다.

3. 작업 통합 worktree 생성

Claude는 모든 서브태스크가 완료된 경우에만 작업을 수행한다.

worktree는 스토리 티켓의 번호로 생성하고, 각 서브태스크의 PR을 받아서 하나의 브랜치에 병합한다.

병합이 완료되면 스토리 티켓의 내용을 바탕으로 전체 로직을 개발한다. 이때 end-to-end 테스트를 진행하고, 테스트가 통과되면 PR을 생성하고 JIRA 티켓의 상태를 작업 완료로 업데이트한다.

4. 최종 검토 및 배포

사용자의 검토는 최종 PR이 생성되었다는 알림을 Slack이나 다른 매체로 전달받으면 시작한다.

사용자는 해당 기능이 제대로 동작하는지, 원하는 대로 구현되었는지 확인한다. 만약 수정해야 할 사항이 있다면 JIRA 티켓에 하위 티켓을 생성해서 Gemini가 작업을 진행하게 한다. 구현이 완료되었다면 배포를 진행한다.

이 과정에서 사용자가 어느 타이밍에 개입하고, 무엇을 확인하거나 작업할지에 따라서 다양한 변형된 워크플로우가 만들어질 수 있다. 하지만 전체적인 흐름은 위와 동일할 것이라고 생각한다.

실제 경험담

한 달 동안 Claude Code로 개발할 때 2~3개의 worktree를 동시에 열고 각각의 작업을 진행하면서 느낀 점은 위와 같은 워크플로우가 가장 효율적이라는 것이다.

AI가 작업하는 동안은 다른 worktree로 이동해서 다음 작업을 진행시키거나 작업된 사항을 검토해서 피드백하는 형태로 진행했다.

생산성 측정 결과

생산성의 기준은 작업 완료까지 걸린 시간으로 측정했다.

기준치(1.0)는 내가 혼자서 작업할 때 걸린 시간을 기준으로 했다. 작업은 보통 1시간 정도 걸리는 작업으로 측정했다.

측정 결과:

• Claude Code: 기준 대비 약 0.8 ~ 1.2 수준의 생산성
• Codex: 기준 대비 약 0.3 ~ 0.5 수준의 생산성
• Copilot: 기준 대비 약 0.5 ~ 0.8 수준의 생산성 (Claude 3.7 기준)

초반에는 AI 사용법에 익숙하지 않아 오히려 시간이 더 오래 걸린 것도 있으므로 이를 감안해야 한다. 그리고 초반엔 잘못된 명령이나 잘못된 코드가 좀 있었다.

숙련 단계: 기준치 대비 1.2~2.0 수준의 생산성 달성

• 독립적인 작업: 서로 연관성이 없는 작업으로 잘게 쪼개서 동시에 진행하면 최소 2배이상 가능
• 연관성 있는 작업: 작업 간 의존성이 있거나 하나씩 검토하며 진행할 때는 1.2배 수준 (약 20% 향상)
• 작업을 세분화: 작업을 더 작은 단위로 나누면 AI가 더 쉽게 이해하고 처리할 수 있다.
• 학습 유무: AI가 특정 작업에 대해 학습한 정도에 따라 생산성이 달라질 수 있다. 자주 쓰는 패턴이나 컴포넌트를 문서화해서 미리 학습시키고, 작업을 시키면 생산성이 크게 향상된다.

결론적으로 어떤 워크플로우를 설계하고 사용하느냐에 따라서 생산성은 크게 달라질 수 있다는 것을 확인했다.

작업 시 유의사항

1. AI가 작업하는 동안 코드를 수정하지 말 것: AI가 작업하는 동안 코드를 수정하면 AI가 이를 다시 읽어서 분석하기 때문에 토큰 소모량만 증가한다. 따라서 AI가 작업하는 동안은 다른 worktree로 이동해서 다음 작업을 진행하거나 작업된 사항을 검토해서 피드백하는 형태로 진행해야 한다.

   같은 이유로 한 폴더에서 여러 개의 AI를 동시에 작업시키는 것도 좋지 않다. 파일이 변경될 때마다 서로 다시 읽기 때문이고, 작업이 서로 섞여서 AI끼리 작업 내용을 혼재해서 학습하게 된다.

2. 작업을 잘게 쪼개서 분배할 것: AI는 작업을 잘게 쪼개서 분배하면 더 쉽게 이해하고 처리할 수 있다. 따라서 작업을 세분화해서 AI가 처리할 수 있는 수준으로 나누는 것이 좋다.

3. 질문은 구체적이고 명확하게 작성할 것: AI에게 질문할 때는 구체적이고 명확하게 작성해야 한다. 애매하거나 추상적인 질문은 AI가 제대로 이해하지 못하고, 원하는 결과를 얻기 어렵다.

작업 시 팁

1. AI의 학습을 돕는 문서화: AI가 특정 작업에 대해 학습한 정도에 따라 생산성이 달라질 수 있다. 자주 사용하는 패턴이나 컴포넌트를 문서화해서 미리 학습시키고 작업을 시키면 생산성이 크게 향상된다.

2. 도메인별 문서화: 라이브러리를 만들거나 폴더로 도메인을 구분할 때 각각에 README.md를 만들어서 문서화해서 AI가 학습할 수 있도록 한다. AI가 해당 컴포넌트나 기능을 사용할 때 README.md를 읽고 학습할 수 있도록 한다.

3. 간결한 문서 작성: 프롬프트나 문서는 되도록 짧고 간결하게 작성하고, 가능한 AI가 작성하도록 한다. 사람이 작성한 경우 AI에게 먼저 학습시키고 결과를 확인한 후 피드백해서 다시 학습시킨 다음 이 과정을 문서화하라고 하면 된다.

4. 단순 작업 활용: AI의 생산성이 낮더라도 작업이 간단하거나 추상적인 지시사항이 없으면 AI가 작업을 잘 수행할 수 있다.

AI 시대의 개발자

AI 시대의 개발은 위와 같은 패러다임 전환이 필요하다. AI가 도와주는 개발 환경을 구축하고, AI가 효율적으로 작업할 수 있는 환경을 만들어야 한다.

앞으로 개발자는 AI와 직접 협업할 수도 있고, AI의 작업을 검토하고 지도하는 역할을 할 수도 있을 것이다.

어느 쪽이든 AI와의 협업을 통해 생산성을 극대화할 수 있느냐가 미래 개발자의 핵심 역량이 될 것이다.