Claude Opus 4.5 vs Gemini 3, 진짜 차이는 '모델'이 아니다
AI가 앱을 직접 짓는 시대, 무엇이 달라졌나
퇴근 후 노트북만 열면 견적서 앱 하나쯤은 AI에게 맡겨서 뚝딱 만들 수 있는 시대가 열렸습니다. 예전이라면 사이드 프로젝트로 한 달은 잡던 일을, 이제는 두 모델을 번갈아 쓰면서 반나절 만에 끝낼 수 있습니다.
이번 사례의 흥미로운 지점은 거창한 데모가 아니라 아주 평범한 인보이스 앱이라는 점입니다. 대단한 알고리즘도 아니고, 혁신적인 서비스도 아닙니다. 실무자라면 누구나 한 번쯤 만들어봤을 법한 그 앱입니다. 그래서 더 의미가 있습니다. 일상적인 업무를 어디까지 넘길 수 있는지, 이 작은 실험이 잘 보여주기 때문입니다.
'속도'보다 중요한 것
두 모델 모두 대시보드, 클라이언트 목록, 인보이스 작성, 공유용 인보이스 화면까지 한 번에 설계하고 구현했습니다. 속도만 놓고 보면 이미 사람 손을 압도합니다. 그런데 결과물을 찬찬히 들여다보면 다른 질문이 떠오릅니다. 이 정도 퀄리티라면, 사람은 어디에 시간을 써야 하는가입니다.
제 기준에서는 프론트엔드 코드 타이핑 자체는 이미 의미가 많이 줄어들었습니다. 대신 어떤 흐름이 좋은 사용자 경험인지, 어떤 데이터를 보여줘야 사업에 도움이 되는지가 훨씬 중요해졌습니다. 같은 코드를 쳐도, 그런 감각이 있는 사람이 AI를 쓸 때 결과물이 완전히 달라진다는 점이 이번 실험에서 드러납니다.
계획을 세울 줄 아는 사람이 이긴다
또 한 가지 눈에 들어오는 변화가 있습니다. 모델이 사람에게 되묻는 질문의 질입니다. 메뉴를 어디에 둘지, 공유 페이지에 일반 사용자용 네비게이션을 숨길지, 어떤 목업 데이터를 쓸지 같은 사소해 보이는 질문이 전체 구조를 바꿉니다.
여기서 많이들 놓치는 부분이 있습니다. AI가 똑똑해질수록, 오히려 사람 쪽에서 사양을 모호하게 던지면 피해가 더 커집니다. 예전에는 개발자가 중간에서 다시 물어봐 주고 설계를 함께 다듬어 줬지만, 이제는 AI가 그대로 구현해 버립니다. 기획과 설계의 빈틈이 그대로 코드가 되는 시대입니다.
클로드와 제미니, 진짜 싸움은 '디자인 감각'과 '집요함'
두 모델은 모두 앱을 끝까지 만들었습니다. 하지만 과정과 결과물의 느낌은 꽤 달랐습니다. 어느 쪽이 절대적으로 우월하다고 말하긴 어렵지만, 성향 차이는 분명히 보입니다.
클로드: 꼼꼼한 질문과 균형 잡힌 화면
클로드 Opus 4.5는 시작부터 질문을 많이 던졌습니다. 공유 인보이스 페이지를 별도 레이아웃으로 할지, 어떤 폰트와 색감을 쓸지, 네비게이션 구조를 어떻게 잡을지 차근차근 확인합니다. 이 질문 덕분에 실제 결과물에서도 공유용 화면에 내부용 네비게이션이 노출되지 않는 등 디테일이 살아났습니다.
프론트엔드 디자인도 비교적 완성도가 높았습니다. 카드 구성, 메트릭 배치, 모바일 반응형 처리까지 전반적으로 안정적입니다. 물론 버튼이 이중으로 배치된다든지, 여백이 미묘하게 어색한 구석도 있었습니다. 그래도 제 기준에서는 리팩토링 몇 번이면 바로 실서비스에 쓸 수 있을 정도입니다.
백엔드 구현에서는 인보이스 라인 아이템이 제대로 저장되지 않는 문제도 있었습니다. 하지만 원인을 좁혀가며 수정하니 금방 수습이 됐습니다. 저라면 실무에서 빠르게 MVP를 띄워야 할 때, 우선 클로드 쪽에 손이 갈 것 같습니다. 질문과 계획을 같이 잡아준다는 느낌이 강하기 때문입니다.
제미니: 속도는 빠르지만, 허점도 드러난다
반대로 Gemini 3는 작업 속도가 눈에 띄게 빨랐습니다. 같은 수준의 기능을 구현하는 데 걸린 시간이 체감상 절반 정도였습니다. 화면 전환 애니메이션이나 미세한 호버 효과처럼, '요즘 서비스 같다' 싶은 터치도 잘 넣어줬습니다.
하지만 몇 가지 함정이 있었습니다. 화면이 처음 뜨지 않는 공백 문제, 존재하지 않는 라이브러리를 썼다가 스스로 '환각이었다'고 인정하는 장면, 클라이언트 검색 기능을 디자인해 놓고 실제로는 동작하지 않는 점 등이 그렇습니다. 한국 팀이 실무에서 쓴다면 이런 부분은 결국 사람 손으로 디버깅해야 합니다.
디자인도 깔끔하긴 하지만, 공유용 인보이스 화면에 내부 네비게이션이 그대로 살아 있는 등 사용 흐름을 고려한 설계에서는 상대적으로 아쉬움이 남습니다. 겉으로 보면 크게 티 나지 않지만, 비즈니스 서비스에서는 이런 작은 디테일이 신뢰와 직결됩니다. 속도에 민감한 팀이라면 매력적이지만, 완성도에 예민한 팀이라면 검수 체계를 더 단단히 깔아야 합니다.
누구에게 득이고, 언제는 오히려 독이 되는가
AI 모델 비교는 자주 모델 스펙 경쟁으로 흘러갑니다. 하지만 실제로는 팀의 상황에 따라 유불리가 완전히 갈립니다. 이번 사례도 마찬가지입니다.
이런 사람에게는 강력한 무기다
사이드 프로젝트를 몇 번이라도 끝까지 출시해 본 사람, 비즈니스 흐름과 화면 설계를 어느 정도 그릴 줄 아는 사람에게는 두 모델 모두 엄청난 레버리지입니다. 기획과 아키텍처를 머릿속에 그릴 수 있다면, 구현은 거의 전담 개발자를 하나 더 둔 것처럼 처리할 수 있습니다. 국내에서 소규모 스타트업이나 1인 개발자가 MVP를 몇 개씩 테스트하기에 딱 맞는 환경입니다.
또 하나, 코드 리뷰를 어느 정도 할 수 있는 사람이라면 특히 유리합니다. 모델이 만든 코드가 돌아가기만 하면 끝이라고 보지 않고, 구조와 네이밍, 예외 처리를 사람 눈으로 다시 잡아줄 수 있기 때문입니다. 이 경우 AI는 초안을 빠르게 뽑아주는 도우미에 가깝고, 마지막 품질은 여전히 사람의 몫입니다.
이런 상황이라면 속도보다 위험이 크다
반대로, 웹 서비스 구조를 아직 감으로 이해하지 못하는 입문자라면 상황이 다릅니다. 모델이 만들어 준 화면이 돌아가면 완성이라고 생각하기 쉽습니다. 하지만 검색이 안 되거나, 공유 링크가 잘못된 레이아웃을 쓰거나, 결제 버튼이 실제 결제와 분리되지 않은 채 남아 있는 식의 문제는 눈에 잘 안 띕니다. 국내에서 개인정보와 결제가 얽힌 서비스라면 이 부분은 치명적입니다.
또 기획 자체가 흐릿한 팀에게도 위험합니다. 목적과 주요 지표, 사용자 페르소나가 정리되지 않은 상태에서 "대충 인보이스 앱 하나 만들어줘"라고 던지면, AI는 그 모호함을 그대로 코드로 굳혀 버립니다. 나중에 손을 볼수록 더 많은 부분을 갈아엎어야 하는 구조가 됩니다. 제 기준에서는 뛰어난 모델을 고르는 것보다, 요구사항 문서를 스스로 명확히 적는 습관을 들이는 쪽이 훨씬 수익률이 좋습니다.
첫걸음을 어떻게 떼야 할지 막막하다면, 거창한 서비스보다 아주 작은 내부용 도구부터 시작하는 편이 좋습니다. 예를 들어 팀의 단순 엑셀 작업을 웹으로 옮겨본다든지, 반복되는 견적 메일을 자동화하는 수준의 실험입니다. 이 정도 스케일이면 모델의 실수도 안전하게 경험할 수 있고, 기획과 설계의 중요성도 몸으로 느낄 수 있습니다. 그 경험이 쌓인 뒤에야 비로소, 클로드든 제미니든 진짜 실력 차이도 보이기 시작합니다.
출처 및 참고 :
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.