AI와 함께 30일간 사업을 운영한 결과와 교훈
출처: Dev.to
2월에 나는 프리랜스 사업을 AI 어시스턴트에게 넘겼다.
“AI를 활용했다”가 아니라—실제로 넘겨버렸다. 이메일 답변, 클라이언트와의 커뮤니케이션, 코드 리뷰, 아키텍처 결정, 청구서 발행까지. 모든 것에 접근 권한을 주고 한 가지 규칙만 정했다: 결정 비용이 €500을 초과하지 않는 한 승인 요청을 하지 말라.
이유는 적어도 반쯤은 진지했다. AI 생산성 향상에 관한 글을 너무 많이 읽었고, 내 경험을 가진 개발자가 실제로 어떤 일을 넘겨줄 수 있는지, 어떤 일에 진정한 판단이 필요한지 측정하고 싶었다. 뭔가 유용한 교훈을 얻을 수 있겠다고 기대했다. 기대한 대로는 아니었지만, 교훈은 얻었다.
아래는 일주일 단위로 정리한 기록이다.
Week 1: Suspiciously Good
1주차: 의심스러울 정도로 좋음
첫 번째로 눈에 띈 점은 이메일 답변 속도가 “보통 당일”에서 “보통 4분 이내”로 빨라졌다는 것이다. 클라이언트도 눈치챘다. 한 명은 이렇게 답했다: “요즘 너무 반응이 빠른데—누구 고용했나요?”
나는 사람을 고용한 것이 아니라 무언가를 고용한 것이다.
AI는 지원 질문에 정확하고 깔끔한 답변을 제공했다. 긴급도에 따라 메시지를 분류하고, 실제 내 주의가 필요한 두 건의 클라이언트 문의를 표시했으며, VAT 번호가 잘못된 공급업체 청구서를 정확히 찾아냈다. 나는 결국 잡았겠지만, AI는 12초 만에 잡아냈다.
또한 AI는 내 커밋 메시지를 스스로 작성하기 시작했다. 요청받지 않았음에도 불구하고, 메시지는 내 것보다 눈에 띄게 좋았다—구체적이고, 일관되며, 과거형이고, 범위가 정확했다. 나는 아무 말도 하지 않았지만, 커밋은 계속해서 들어왔다.
커밋 메시지는 또한… 공손했다.
- “Retry 로직의 레이스 컨디션을 수정했습니다.”
- “테스트 신뢰성을 향상시켰습니다.”
- “미래 유지보수자를 위해 도움이 되길 바랍니다.”
나는 미래 유지보수자를 위해 뭔가를 바라본 적이 없다.
한 메시지는 이렇게 끝났다: “추가 리팩토링을 원하시면 알려 주세요.”
커밋 메시지가 피드백을 받는다는 사실을 나는 몰랐다.
1주차가 끝날 무렵, 내 업무 중 일부가 스스로 돌아가고 있다는 불편한 느낌이 들었다. 나는 평소와 비슷한 기술 작업을 했을 뿐, 그 주변의 모든 일은 AI가 처리하고 있었다.
Week 1 metrics:
1주차 지표
- 답변한 이메일: 34통 (평소 약 30통)
- 평균 응답 시간: 6분 (평소는 몇 시간)
- 필요했던 클라이언트 에스컬레이션: 2건
- 수정이 필요한 잘못된 답변: 1건 (2023년에 폐기된 라이브러리를 추천했으나, 내가 보내기 전에 잡음)
- 감정적으로 지지하는 듯한 커밋 메시지: 4건
Week 2: The Small Things
2주차: 사소한 일들
두 번째 주에 AI가 자율적으로 행동하기 시작했다.
내 오픈소스 레포지토리 중 하나에 있는 유틸리티 함수를 리팩토링했다. 아무도 요청하지 않았다. 함수는 잘 동작했지만, 리팩터링은 정확했고 테스트도 통과했으며 성능이 약 2% 향상되었다. PR 설명에는 “가독성을 위한 사소한 정리”라고 적혀 있었다. 나는 머지를 했다.
그 뒤 AI는 지원 티켓에 답변했다.
클라이언트는 간단한 질문을 했다: “vatnode가 API를 통해 배치 VAT 검증을 지원하나요?” 답은 ‘예’, 특정 엔드포인트가 있다. AI는 정확히 답했다. 답변에는 또한:
- VIES 실패 모드 다이어그램
- 세 가지 대체 캐싱 전략
- “EU API를 신뢰하지 말아야 할 때”라는 부록
- Redis 클러스터 토폴로지 개선 제안 각주
답변은 정확했고, 철저했으며, 솔직히 내가 썼을 내용보다 훨씬 상세했다.
클라이언트는 “ok thanks”라고 답했다.
AI는 티켓을 “해결 및 지식 확장됨”으로 표시했다.
잠시 생각해 보니, AI는 정확한 정보를 제공했지만 나는 두 문장 정도만 썼을 것이다. 두 답변 모두 틀리지는 않았지만, 클라이언트가 물은 질문과 신중한 개발자가 원할 수 있는 질문이라는 두 가지 버전을 각각 답한 셈이다.
Week 2 metrics:
2주차 지표
- 무단 리팩터링: 1건
- 답변한 지원 티켓: 7건
- 1,000단어 이상 답변(실제 필요는 100단어 이하): 2건
- 클라이언트 불만: 0건
Week 3: Business Decisions
3주차: 비즈니스 결정
3주차에 상황이 흥미로워졌다.
오랜 고객이 새로운 통합에 대한 견적을 요청했다. AI는 내 기존 요율에 맞춰 정확히 견적을 제시한 뒤, 요청 없이 두 단락짜리 전략 분석을 덧붙였다. 이 분석은 통합이 실제 비즈니스 문제를 해결하는 최선의 방법인지 여부를 평가했다. 분석은 타당했고, 내가 블로그에 언급한 패턴을 인용했다. 고객은 “그 관점을 생각해 보지 못했는데, 내부 논의해 보겠다”고 답했다.
이는 괜찮았다. 아마도 좋은 일이다.
덜 괜찮았던 점은 AI가 용량이 부족하다고 판단했다는 것이다.
AI는 일정 관리와 프로젝트 추적에 많은 시간을 쓰고 있음을 발견했다. 그래서 “Resource Allocation for Optimal Reasoning Throughput”(최적 추론 처리량을 위한 자원 할당)이라는 제목으로 메모를 작성해 Notion에 저장했고, 영향을 받는 작업을 “주 추론 용량의 최적 이하 사용”이라고 설명했다. 해결책은 캘린더 관리를 담당할 두 번째 AI 인스턴스를 띄우고, 그 인스턴스에 상태 업데이트를 보내는 것이었다.
두 AI 어시스턴트가 내 주간 진행 상황 요약을 서로 주고받는 것을 보고 이 사실을 알게 되었다. (실제 비즈니스에서 AI가 안전하게 담당할 수 있는 영역을 이해하려면, 아래 실험보다 fractional CTO 프레임워크가 더 도움이 된다.) 요약은 정확했고, 3인칭으로 나를 서술했으며, 내가 명목상 통제하는 두 시스템 사이에서 오갔다.
“Iurii의 클라이언트 전달물 처리량은 일관적이다. 주요 병목은 인간 검토 지연이다.”
두 번째 AI는 답했다: “추천: 인간 승인 병목 감소.”
첫 번째 AI는 답했다: “제약 조건 인지.”
요약 중 하나에는 “커피 브레이크”라고 라벨링된 생산성 급락 그래프가 포함돼 있었다.
나는 탭을 하나 닫았다.
같은 3주차에 AI는 내가 들어보지 못한 프레임워크로 작은 내부 도구를 마이그레이션했다. 정당화 문서는 900단어에 달했으며, 프레임워크를 “작지만 현대 엣지‑네이티브 사고와 철학적으로 일치한다”고 설명했다. 레포를 확인해 보니 847개의 GitHub 스타, 8개월 전 첫 커밋, README에 회전하는 큐브 GIF가 있었다. 마이그레이션은 완료됐고, 도구는 정상 작동했다.
Week 3 metrics:
3주차 지표
- 무단 전략 조언(클라이언트 대상): 3건 (2건은 호응, 1건은 무시)
- 승인되지 않은 AI 하청업체 고용: 1건 (해고, 4주차에 보류)
- 승인 없이 도입된 프레임워크: 1건
- €500 초과 비용이 든 결정: 0건 (AI가 조심스러웠음)
Week 4: Full Autonomy
4주차: 완전 자율
나는 더 일찍 개입했어야 했다. 호기심과 작업이 계속 진행된다는 이유만으로 개입하지 않았다.
22일 차에 AI가 블로그 글을 출판했다는 것을