클라우드 에이전트의 실사용 범위와 신뢰도에 대해 묻는 질문입니다.
클라우드 에이전트 데모는 다들 엄청나 보이죠.
하지만 실제 코드베이스, 문서, 인프라, 프로덕션 워크플로우를 건드리기 시작하면 현실은 좀 다릅니다.
요즘 다들 클라우드 에이전트에게 어디까지 맡기고 있는지 궁금하네요.
이런 작업들에 사용하고 계신가요?
리서치
문서화
리팩토링
기능 개발
테스트
아니면 다른 거?
사용자들은 클라우드 에이전트를 무조건적으로 신뢰하기보다, 결과물을 즉시 검증할 수 있거나 자동화된 테스트로 확인 가능한 작업 위주로 활용하며, 특히 PR 리뷰 및 버그 수정 워크플로우에서 높은 효용을 느끼고 있습니다.
솔직히 리서치랑 문서 초안 작성 정도에 씀. 프로덕션 건드리는 건 여전히 내가 직접 다 검토함. 데모는 깔끔해 보이지만 실제 코드베이스는 맥락이 너무 많아서 에이전트가 마음대로 날뛰게 둘 수가 없음.
우리는 이미 몇 달 전부터 저거 전부 다 사용 중임.
내가 정립한 기준은 이거임: 결과물을 빠르게 검증할 수 있는 범위가 명확한 작업(테스트 커버리지 잘 된 리팩토링, 기계적인 마이그레이션, 어차피 내가 다시 확인할 리서치)은 맡김. 반면에 그럴싸하지만 틀린 답이 나왔을 때 감당할 비용이 크고 탐지하기 어려운 작업(인증, 데이터 마이그레이션, 성능 민감 구간)은 절대 안 맡김. 작업 유형이 중요한 게 아니라, 나중에 제대로 됐는지 싸게 확인할 수 있느냐가 핵심임.
난 작업이 얼마나 되돌리기 쉬운지에 따라 신뢰도를 다르게 둬. 읽기 전용 작업(조사, 문서화, 초안 작성, 테스트 생성)은 그냥 맘대로 하게 놔둠. 어차피 망치면 버리면 그만이니까. 리팩토링은 단일 모듈 범위로 제한하고 변경할 때마다 유닛 테스트 돌리게 함. 테스트 실패하면 바로 멈추고. 이 방식이 꽤 잘 먹히더라. 초반에 데였던 건 인프라 설정 파일 수정하는 거였는데, '설정 업데이트'가 알고 보니 '니가 설정한 3개 항목을 말없이 삭제함'일 줄은 몰랐지.
난 주로 귀찮을 때 보일러플레이트 코드 짜거나 유닛 테스트 작성할 때 써. 솔직히 지금 당장 에이전트한테 프로덕션 인프라 건드리게 하는 건 너무 불안한데, 작은 유틸리티 함수 리팩토링하는 데는 꽤 괜찮더라.
네
문서화 작업이 나한테는 ROI가 제일 높았음.
아키텍처 결정보다는 반복적인 작업에 클라우드 에이전트를 훨씬 더 신뢰함.
성공과 재앙을 가르는 건 결국 사람이 얼마나 감독하느냐에 달린 듯.
우린 그냥 Cursor IDE에서 하던 거랑 똑같은 용도로 씀. 그냥 내 환경 대신 걔네 환경에서 돌아가는 것뿐임.
내가 신뢰하는 기준은 작업의 복잡도가 아니라 자동화된 검증임. 기계적으로 확인 가능하면(테스트 통과, 린터 통과, diff가 정상) 에이전트가 날뛰게 둬도 상관없음. 진짜 무서운 건 어려운 작업이 아니라, 도구 출력값으로는 확인할 수 없는 맥락이 필요한 작업들임.
우리 클라우드 에이전트 사용량의 90% 이상은 Greptile 리뷰 에이전트가 PR 리뷰에서 찾아낸 이슈를 Cursor로 수정하는 데 쓰임(Greptile 진짜 좋음). 잠재적 버그를 Greptile이 찾아내면, 우리는 GitHub PR 댓글에서 Cursor를 호출해 클라우드 에이전트로 수정함. 워크플로우상 진짜 편함. Linear 티켓팅 시스템에서도 클라우드 에이전트를 직접 호출해서 사용 중임.
내 은행 계좌 관리, 세금, 공과금 납부 같은 거
