[개발 일지] 네이버 클립 자동 스와이프를 만들며 내가 분리한 실행·중단·복구 조건

[개발 일지] 네이버 클립 자동 스와이프를 만들며 내가 분리한 실행·중단·복구 조건 thumbnail
대표 안내 이미지

한 줄 요약: 자동화는 계속 움직이게 만드는 것보다, 멈춰야 할 순간을 정확히 정하는 일이 더 중요했습니다. 이 기록에서는 내가 분리해 둔 실행·중단·복구 기준만 공유합니다.

기록 성격: 직접 개발 기록. 원본 문서·계정·내부 경로는 공개하지 않습니다.

먼저 확인한 핵심

  • 시작 전에 대상 화면과 사용자 의도를 다시 확인합니다.
  • 예상 밖 화면이나 오류가 감지되면 자동으로 다음 행동을 하지 않습니다.
  • 재개는 마지막 상태가 아니라 현재 화면을 다시 확인한 뒤에만 합니다.
[개발 일지] 네이버 클립 자동 스와이프를 만들며 내가 분리한 실행·중단·복구 조건 source
공개 가능한 내용을 다시 그린 설명 이미지

왜 이 기준이 필요한가

내가 공개하는 것은 기능의 원리와 검수 기준입니다. 계정 정보, 내부 경로, 실제 사용 기록은 포함하지 않습니다.

[개발 일지] 네이버 클립 자동 스와이프를 만들며 내가 분리한 실행·중단·복구 조건 infographic
핵심 판단 기준 인포그래픽

시작 조건을 사람에게 맡긴 이유

자동화에서 가장 사고가 나기 쉬운 지점은 시작입니다. 도구가 스스로 화면을 찾아 들어가면, 찾지 못했을 때도 무언가를 하게 됩니다.

  • 보고 싶은 화면까지 이동하는 일은 사람이 합니다.
  • 시작 버튼을 누르는 것도 사람이 합니다.
  • 도구는 눌린 뒤에만 움직입니다.

이렇게 두면 도구가 "지금 어디인지"를 판단할 필요가 없어집니다. 판단을 없애는 것이 판단을 정교하게 만드는 것보다 안전한 경우가 있습니다.

중단을 다음 동작보다 앞에 두기

예상하지 못한 상황에서는 다음 동작을 시도하지 않는 쪽을 기본으로 잡았습니다.

  • 멈춤 버튼을 누르면 즉시 멈춥니다. 진행 중인 대기를 기다리지 않습니다.
  • 동작 하나가 끝나기 전에는 다음 동작을 겹쳐 넣지 않습니다.
  • 서비스가 꺼지면 그 시점에서 끝냅니다. 자동으로 되살리지 않습니다.

자동으로 재개하는 기능은 편하지만, 사용자가 멈춘 이유를 도구가 알 수 없습니다. 멈춤은 사용자의 의사 표시로 보는 편이 맞습니다.

복구는 이전 상태를 되돌리는 것이 아니다

중단된 뒤 다시 시작할 때, 멈추기 전 위치나 진행 상황을 복원하지 않습니다. 사람이 다시 화면을 확인하고 시작하는 것이 복구입니다. 상태를 기억해 이어가면 편해 보이지만, 그 사이에 화면이 바뀌었을 가능성을 도구가 확인할 방법이 없습니다.

대신 기억하는 것은 하나뿐입니다. 버튼을 어디에 두었는지입니다. 이건 틀려도 위험하지 않은 정보입니다.

읽고 나서 확인할 것

이 글의 정보는 게시 시점의 공개 범위와 설계 기준을 나눠 정리한 것입니다. 제품·서비스의 실제 이용 가능 여부는 공식 안내와 현재 화면을 함께 확인하세요.

소프트웨어 설계 문서와 비교해 보는 중단·재시도·재개

실행, 중단, 복구를 나누는 방식은 이 프로젝트만의 발명이 아닙니다. 외부 시스템 호출이 실패할 때 어떻게 멈추고 다시 시도할지는 소프트웨어 설계 문서에서 오래 다뤄 온 주제입니다. 아래는 Microsoft Learn의 두 설계 패턴 문서와 Claude 컴퓨터 사용 도구 문서의 안내를 이 글의 기준과 나란히 놓은 것입니다. 해당 문서들은 이 앱을 다룬 것이 아니라 일반 원칙을 설명한 자료입니다.

서킷 브레이커: 실패가 이어지면 시도를 멈춘다

Circuit Breaker 패턴 문서(Circuit Breaker Pattern)는 실패할 가능성이 높은 작업을 반복해서 시도하지 않도록, 실패가 기준에 이르면 일정 시간 요청을 막는 방식을 설명합니다. 상태는 세 가지입니다. 정상일 때는 요청이 그대로 흐르는 Closed, 최근 실패가 기준을 넘으면 요청을 즉시 거부하는 Open, 일정 시간이 지나 제한된 수의 시험 요청만 통과시키는 Half-Open입니다. Half-Open에서 시험 요청이 성공하면 Closed로 돌아가고, 하나라도 실패하면 다시 Open이 됩니다. 문서는 Half-Open 단계가 회복 중인 서비스에 요청이 한꺼번에 몰리는 것을 막는 역할을 한다고 설명합니다.

이 문서가 짚는 고려 사항 중 이 글과 맞닿은 것이 수동 재설정입니다. 복구 시간이 크게 들쭉날쭉한 작업이라면 관리자가 직접 회로를 닫거나 열 수 있는 옵션을 두라고 안내합니다. 자동 스와이프 도구가 멈춘 뒤 스스로 되살아나지 않고 사람이 다시 시작하도록 한 설계는, 자동 복구 대신 사람의 결정을 복구 단계에 넣은 경우로 볼 수 있습니다.

재시도: 안전한 경우와 아닌 경우

Retry 패턴 문서(Retry pattern)는 일시적인 오류라면 잠시 뒤 다시 시도하면 성공할 수 있다고 설명하면서, 몇 가지 조건을 단다는 점이 중요합니다. 작업이 여러 번 실행되어도 결과가 같은 "멱등성"이 있어야 재시도가 안전하고, 그렇지 않으면 의도치 않은 부작용이 생길 수 있다고 합니다. 오류가 일시적이지 않거나 반복해도 성공할 가능성이 낮으면 재시도하지 말고 작업을 취소하고 예외로 알리라는 안내도 있습니다. 또 재시도 때문에 서비스가 이미 바쁜 상황을 더 악화시키지 않도록 횟수와 간격을 조절하라고 합니다.

화면을 눌러 영상을 넘기는 자동화는 이 기준에서 멱등성이 낮은 작업에 가깝습니다. 같은 동작을 두 번 하면 한 번 한 것과 결과가 다르기 때문입니다. 그래서 "실패했으니 한 번 더"를 자동으로 반복하기보다, 멈추고 상태를 다시 확인하는 쪽이 문서의 원칙에 더 맞습니다.

사람이 확인해야 할 결정

Claude의 컴퓨터 사용 도구 문서(Computer use tool)는 화면을 보고 클릭하는 도구를 쓸 때의 위험이 일반 API 기능과 다르다고 경고합니다. 권장 사항에는 최소 권한의 가상 머신이나 컨테이너 사용, 계정 로그인 정보 같은 민감한 데이터를 접근시키지 않는 것, 인터넷 접근을 허용 목록으로 제한하는 것, 그리고 현실에 의미 있는 결과를 낳는 결정과 동의가 필요한 작업은 사람에게 확인받는 것이 포함됩니다. 문서는 이 도구가 때때로 자신이 한 동작의 결과를 확인하지 않고 성공했다고 가정한다는 점도 한계로 들며, 단계마다 화면을 다시 확인하도록 안내합니다.

이 글의 기준과 대응시키면

상황설계 문서의 원칙이 글의 기준
시작 전요청이 정상 경로(Closed)로 흐름대상 화면과 의도를 사람이 확인하고 시작 버튼도 사람이 누름
반복 실패·예상 밖 화면실패가 기준을 넘으면 Open으로 전환, 요청을 즉시 거부다음 동작을 시도하지 않고 멈춤
재개 시도Half-Open: 제한된 수의 시험 요청만 통과, 성공하면 Closed현재 화면을 다시 확인한 뒤 사람이 다시 시작
복구 방식관리자가 수동으로 닫거나 열 수 있는 수동 재설정 옵션 권장멈춤은 사용자의 의사 표시이므로 자동 재개 없음

표의 오른쪽 칸은 이 글이 앞에서 설명한 기준이고, 가운데 칸은 위 문서들의 설명입니다. 두 칸이 같은 방향을 가리킨다는 것이 요점이지, 도구가 위 패턴을 그대로 구현했다는 뜻은 아닙니다. 서비스 정책이나 도구 기능은 바뀔 수 있으므로 실제 적용 전에는 각 공식 문서의 최신 내용을 확인하세요.

참고한 공식 문서