건강기록 대시보드, 세 번째 이야기 — API 없이 사진 판독으로 기록 저장까지

📝 한줄 요약

지난번엔 대시보드에 "기록을 직접 넣는" 기능(입력창 + 사진 업로드)을 추가했다면, 이번엔 그 사진 업로드 기능의 뒷단 — 매일 아침 자동으로 사진을 읽어서 기록을 채워주던 자동화가 어느 순간부터 멈춰 있던 걸 발견하고 원인을 끝까지 추적한 이야기입니다.

바쁘시면 이것만 읽어도 돼요:

• Claude를 부르는 방법이 CLI(터미널)·Code(웹/앱)·Cowork(코드+문서+협업툴)로 나뉜다는 걸 실제로 헷갈려 보면서 정리하게 됨

• 사진을 올리면 자동으로 기록을 채워주던 루틴(자동화 작업)이 멈춰 있었는데, "왜 멈췄지?"를 파고들다 진짜 원인은 코드 문제가 아니라 AI 작업 환경의 네트워크 접근 권한 설정이었음

• AI가 알려준 원인을 그대로 믿지 않고 직접 재현해서 확인한 끝에, 설정 화면에서 막힌 부분을 딱 찾아 고침

• 급한 기록 2건은 자동화가 고쳐지기 전까지 사람이 직접 사진을 보여주는 방식으로 우회 처리

• 배운 점: 자동화가 "왜 안 도는지" 알아낼 때도, 로그에 적힌 이유를 곧이곧대로 믿지 말고 직접 한 번 더 재현해보는 게 확실했음

🎯 이런 분들께 도움돼요

• Claude를 CLI/웹/앱/Cowork 중 뭘 써야 할지 헷갈리는 분

• AI에게 자동화(정해진 시간마다 알아서 도는 작업)를 맡겨놨는데, 어느 순간 조용히 멈춰서 원인을 못 찾고 있는 분

😫 문제상황 (Before)

지난번에 만든 "사진 업로드 → 자동으로 기록 채우기" 기능, 분명 잘 만들어뒀는데 실제로 사진을 올려보니 기록이 하나도 반영이 안 됐습니다. 매일 아침 정해진 시간에 자동으로 사진을 확인해서 값을 채워주기로 되어 있었는데, 그 자동화가 조용히 실패하고 있었던 겁니다. 겉으로는 아무 에러도 안 보이고, 그냥 "안 채워짐"만 보이니 뭐가 문제인지 감이 안 잡히는 상황이었습니다.

🛠️ 사용한 도구

• 도구: Claude Code(웹 버전, 클라우드에서 실행), 정해진 시간마다 자동 실행되는 루틴 기능

• 연동 서비스: Supabase(기록과 사진이 보관되는 곳)

🔧 작업 과정

헷갈렸던 것 하나 — CLI, Code, Cowork는 대체 뭐가 다른가

작업 중간에 "지금 이거 PC에서 작업하는 거 맞아?" 같은 질문을 하다가, Claude를 부르는 방법이 여러 가지라는 걸 새삼 정리하게 됐습니다.

정리한 기준: 코드(프로그램) 작업만 하면 되면 Code 계열 아무거나, 문서나 다른 업무 도구까지 같이 다뤄야 하면 Cowork. 그리고 "PC로 접속했다"고 해서 실제로 PC에서 실행되는 게 아니라, 어떤 방법으로 부르든 실제 작업은 클라우드(인터넷 너머의 별도 컴퓨터)에서 돌아간다는 것도 이번에 확인했습니다. 그래서 내 컴퓨터에만 저장해둔 설정은 클라우드 쪽 세션에서 안 보인다는 것도 새로 알게 된 부분입니다.

좀 더 파고들어서, 터미널(CLI)로 쓸 때와 웹/앱(Code 앱)으로 쓸 때를 구체적으로 비교해보면 이렇습니다.

CLI에서는 되는데, Code 앱(클라우드)에서는 안 되는 것

• 내 컴퓨터의 다른 폴더·다른 프로젝트에 자유롭게 접근하기 — 클라우드는 지금 작업 중인 저장소 하나만 볼 수 있는 격리된 가상 컴퓨터라, 관련 없는 로컬 파일은 아예 안 보임

• 개인 전용 설정(개인 CLAUDE.md, 개인 스킬, 개인적으로 등록한 연동 도구) 그대로 쓰기 — 저장소에 함께 올려두지 않은 이상 클라우드 세션엔 전달되지 않음

• 사람이 직접 터미널을 잡고 명령어 치기 — 로컬은 원하면 언제든 자기 손으로 칠 수 있지만, 클라우드는 "이 명령어 실행해줘"라고 매번 부탁하는 방식만 가능

• 브라우저 로그인이 필요한 인증 방식 — 클라우드 가상 컴퓨터엔 브라우저가 없어서 이런 로그인 자체가 안 됨

• 내 컴퓨터 사양만큼 자유로운 처리 능력 — 클라우드는 CPU·메모리·저장공간이 정해진 만큼으로 고정돼 있음

Code 앱(클라우드)에서는 되는데, CLI에서는 안 되거나 훨씬 불편한 것

• 화면을 꺼도 작업이 계속 진행됨 — 로컬은 터미널 창을 닫으면 그 자리에서 멈추지만, 클라우드는 꺼져 있는 동안에도 계속 돌아가고 나중에 다시 열면 이어짐

• 휴대폰 앱으로 진행 상황을 확인하고 중간에 개입하기 — 로컬은 그 컴퓨터 앞에 있어야만 확인 가능

• 코드 저장소 로그인을 따로 설정 안 해도 자동으로 처리됨 — 로컬은 로그인을 직접 세팅해야 함

• 작업 내용을 링크 하나로 다른 사람과 공유하기 — 로컬엔 이런 공유 기능 자체가 없음

• 여러 작업을 동시에 병렬로 띄워서 돌리기 — 로컬은 내 컴퓨터 자원이 감당하는 만큼만 동시에 돌릴 수 있음

이번에 겪은 "환경이 중복 생성된" 문제도 결국 이 차이에서 비롯됐습니다. 클라우드는 격리된 가상 컴퓨터를 매번 새로 준비하는 구조다 보니, 접속 경로가 달라지면 어느 걸 이어써야 할지 헷갈릴 여지가 로컬보다 훨씬 큽니다.

그럼 Code 앱을 '로컬 폴더 지정'으로 쓰면? — 이건 클라우드와는 또 다릅니다. Code 앱(데스크톱 앱)에서 실행 위치를 "로컬"로 고르면, 내 컴퓨터의 실제 폴더를 지정해서 그 안에서 작업합니다. 이 경우엔 CLI와 사실상 같은 엔진을 씁니다. 그래서:

• CLAUDE.md, 개인 설정, 연결해둔 외부 도구(MCP) 같은 게 CLI와 그대로 공유됩니다. 클라우드처럼 "개인 설정이 안 넘어간다"는 문제가 없습니다.

• 대신 몇 가지는 여전히 다릅니다.

  • CLI에서만 되는 것: 결과만 뽑아서 스크립트에 끼워 넣기(자동화 파이프라인용 기능), 모든 승인 모드 사용(미리 승인해둔 도구만 자동으로 허용하는 모드는 CLI에만 있음)

  • 로컬 폴더로 지정한 Code 앱에서만 되는 것: 여러 작업을 탭처럼 한 화면에서 동시에 보기, 코드 수정 전후를 화면으로 바로 비교해서 보기, 사진·PDF 파일을 끌어다 놓기(CLI는 파일 첨부 자체가 안 됨), 반복 작업을 앱 안에서 예약 걸기

정리하면: 클라우드 Code 앱 = CLI와 "설정까지" 다른 별개의 실행 공간, 로컬 폴더 지정 Code 앱 = CLI와 "엔진과 설정은 같고 화면(인터페이스)만 다른" 관계입니다.

자동화가 멈춘 이유를 추적하기

1단계 — 자동화 자체는 도는지 확인

가장 먼저 의심한 건 "자동화가 아예 실행이 안 되는 거 아니야?"였습니다. 실행 기록을 확인해보니 매일 정해진 시간에 정확히 실행은 되고 있었습니다. 스케줄 문제는 아니었던 겁니다.

2단계 — 데이터베이스에 뭐가 남아있는지 직접 확인

그다음엔 기록이 보관되는 데이터베이스를 직접 열어봤습니다. 처리되지 않은 채 대기 중인 항목이 남아 있었고, 옆에 실패 사유가 이렇게 적혀 있었습니다.

"자동 판독 실패: 실행 환경 네트워크 정책이 (사진이 저장된 서비스)로의 접근을 차단(403)하여 사진을 다운로드하지 못했습니다."

3단계 — 적힌 이유를 그대로 믿지 않고 직접 재현

이 메모만 보고 "아 그렇구나" 하고 넘어가지 않고, 같은 환경에서 직접 그 사진 주소로 접속을 시도해봤습니다.

$ curl [사진 주소]
curl: (56) CONNECT tunnel failed, response 403

똑같이 막혔습니다. 혹시나 해서 다른 방법(별도 웹 요청 도구)으로도 시도했는데 역시 403(접근 거부)이 떴습니다. 이 시점에 확신할 수 있었습니다 — 사진이나 코드 문제가 아니라, AI가 작업하는 환경 자체가 그 주소로 나가는 걸 막고 있다는 것을요.

4단계 — 진짜 원인: 네트워크 접근 허용 목록에 빠져 있었다

AI 작업 환경에는 "이 주소들만 나갈 수 있다"는 허용 목록(네트워크 정책)이 설정돼 있는데, 기본값으로는 일반적인 개발 도구 사이트들만 포함돼 있고 개인이 쓰는 데이터 저장 서비스 주소는 빠져 있었습니다. 그래서 자동화가 아무리 정해진 시간에 잘 실행돼도, 애초에 사진이 있는 곳까지 접속할 방법이 없었던 겁니다.

여기서 재밌는(?) 시행착오도 하나 있었습니다. 설정 화면에 들어가 보니 이름이 비슷한 환경이 두 개 있었습니다 — "기본값"(한글)과 "Default"(영문). 심지어 "기본값" 쪽이 이미 선택까지 되어 있었습니다. 하지만 확인해보니 자동화가 실제로 쓰는 건 "Default"(영문, 예전에 만들어둔 것) 쪽이었고, "기본값"은 바로 그 순간 모바일로 설정 화면에 처음 들어간 김에 시스템이 자동으로 새로 만들어버린, 전혀 관계없는 환경이었습니다. 생성 시각을 확인해보니 화면을 연 시각과 거의 1분 차이였습니다.

이름만 보고 "이미 선택돼 있으니 이게 맞겠지" 하고 넘어갔다면, 엉뚱한 걸 고치고 진짜 문제는 그대로 남았을 뻔했습니다. 그래서 이름 대신 자동화 설정에 저장된 환경의 고유 ID를 직접 조회해서 하나씩 대조한 뒤에야 정확한 대상을 확정할 수 있었습니다.

5단계 — 설정 수정 + 검증

해당 환경의 네트워크 접근 방식을 "기본 허용 목록만" → "직접 지정한 주소 추가 허용"으로 바꾸고, 사진이 저장된 서비스 주소를 허용 목록에 넣었습니다. 저장 후 다시 접속을 시도해보니:

$ curl [사진 주소] → HTTP 200, 정상 다운로드 완료

막혔던 게 뚫렸습니다. 이제 다음 자동 실행부터는 사람이 손대지 않아도 사진을 읽어서 기록을 채울 수 있게 됐습니다.

급한 기록은 어떻게 했나 — 설정을 고치기 전까지 밀려 있던 기록 2건은, 사진을 채팅창에 직접 올려서(자동화가 데이터 저장 서비스에서 못 가져오는 것뿐이지, 사람이 채팅에 직접 올린 파일은 문제없이 읽을 수 있었습니다) 그 자리에서 값을 확인하고 수동으로 채워 넣었습니다.

환경이 중복 생성되지 않으려면 — 그리고 더 근본적인 습관 하나

이번 일로 두 가지를 다시 생각하게 됐습니다. 하나는 "왜 환경이 중복으로 생겼나"라는 구체적인 문제고, 다른 하나는 "왜 그걸 바로 못 알아챘나"라는 더 근본적인 문제입니다.

구체적인 예방법

1. 새로운 기기나 브라우저로 처음 접속할 때는 반드시 환경 목록부터 확인한다. 접속 경로(PC/모바일, 앱/브라우저)가 달라지면 기존 환경을 못 찾고 새로 하나 만들어버릴 수 있다는 걸 이번에 알았습니다. 낯선 화면에 처음 들어갔을 때는 "몇 개가 떠 있는지, 내가 알던 것과 같은 개수인지"부터 확인하는 습관이 필요합니다.

2. 주기적으로 환경 목록을 점검해서, 안 쓰는 건 보관(archive) 처리한다. 방치하면 이름이 비슷한 것들이 계속 쌓여서 다음번에 또 헷갈릴 소지가 생깁니다.

3. 이름이 비슷하면 이름을 믿지 말고, 생성일이나 고유 ID처럼 겹칠 수 없는 값으로 실제 대상을 확인한다.

더 근본적으로 배운 것 — "일단 진행"이 문제였다

돌아보면 문제의 시작은 설정 화면에서 뭔가를 눌렀을 때, "이 화면에 들어가는 것 자체가 새 환경을 만드는 행위일 수도 있다"는 걸 모른 채로 그냥 진행했다는 점이었습니다. AI에게 뭔가를 시키거나, AI가 안내하는 화면을 따라갈 때 "다음", "확인"을 누르는 게 정확히 어떤 결과를 만드는지 모른 채로 습관적으로 눌러버리면, 이번처럼 작업 환경 자체가 조용히 꼬여버릴 수 있습니다.

그래서 이제는 낯선 화면이나 새로운 동작을 진행하기 전에 "이거 지금 정확히 뭘 만들거나 바꾸는 거야?"를 먼저 물어보고, 정말 필요한 동작인지 확인한 다음에 진행하는 걸 원칙으로 삼기로 했습니다. AI가 시키는 대로, 혹은 화면이 이끄는 대로 이해 없이 수락하며 넘어가는 것 자체가 이번처럼 작업 공간이 정리되지 않고 어질러지는 원인이 된다는 걸 체감한 계기였습니다.

✅ 결과 (After)

Before vs After

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 에러메시지에 적힌 원인도 한 번은 직접 재현해서 검증하기 — "네트워크가 막혔다"는 메모만 믿고 넘어갔다면 어느 부분이 막혔는지 특정하지 못했을 것. 같은 환경에서 직접 재현해보고 나서야 "설정 문제"라고 확정할 수 있었음

2. 자동화가 실제로 쓰는 설정(환경)을 이름이 아니라 ID로 대조하기 — 이름이 비슷한 설정이 여러 개 있을 때, ID를 직접 조회해서 대조하지 않았다면 엉뚱한 곳을 고칠 뻔함

3. AI가 못 고치는 부분은 빨리 인정하고 사람이 처리 — 설정 화면 수정은 AI가 세션 안에서 직접 바꿀 수 없는 영역이었음. 화면을 캡처해서 주고받으며 사람이 직접 클릭해야 했고, 그동안은 수동 업로드로 급한 것부터 처리한 게 더 빨랐음

이렇게 하면 안 돼요

1. "실행은 됐다"는 로그만 보고 안심하지 말 것 — 실행은 됐어도 그 안에서 조용히 실패하는 경우가 있음

2. 설정 화면에 비슷한 이름이 여러 개 보이면 이름만 보고 고르지 말고, 실제로 어떤 걸 쓰고 있는지부터 확인할 것

3. 뭘 하는 화면·버튼인지 모른 채로 "다음"·"확인"을 습관적으로 누르지 말 것 — 이번 환경 중복 생성처럼, 이해 없이 진행부터 하면 나중에 무엇이 왜 꼬였는지 되짚기가 훨씬 어려워짐

🌍 다른 업무에 적용한다면?

"자동화를 걸어뒀는데 왜인지 결과가 안 나온다"는 상황은 개발 프로젝트가 아니어도 흔합니다. 매일 자동으로 발송되는 리포트, 정기적으로 도는 알림 등이 "실행은 됐는데 결과물이 없는" 상태로 조용히 멈춰 있을 때, 이번처럼 (1) 실행 자체가 됐는지 (2) 중간 결과물이 남아있는지 (3) 진짜 원인을 직접 재현해서 확인하는지, 단계별로 짚어보는 방식은 그대로 적용할 수 있습니다.

🚀 앞으로의 계획

• 자동화가 다시 멈추는 일이 없는지 며칠 더 지켜보기

• 이번에 실수로 새로 생긴 "기본값" 환경 정리(보관 처리)하기 — 그대로 두면 다음에 또 헷갈릴 수 있음

• 이번에 헷갈렸던 "이름이 비슷한 설정" 문제처럼, 설정값을 바꿀 때 항상 ID로 먼저 확인하는 걸 습관화하기

• 낯선 화면에 들어가기 전엔 "이게 뭘 만드는 동작인지" 먼저 확인하고 진행하는 습관 들이기

• 이런 트러블슈팅 과정도 기록해서, 다음에 비슷한 문제가 생기면 바로 찾아볼 수 있게 정리해두기

📋 재사용 가능한 프롬프트

프롬프트 1: 조용히 멈춘 자동화 원인 찾기

이 자동화가 정해진 시간에 실행은 되는데 결과가 안 나와. 1) 실행 기록부터 확인하고 2) 중간 데이터(대기 중인 항목 등)에 실패 사유가 남아있는지 보고 3) 그 사유를 네가 직접 재현해서 진짜 맞는지 검증해줘.

프롬프트 2: 비슷한 이름의 설정이 헷갈릴 때

지금 이 작업이 실제로 어떤 설정(환경)을 쓰고 있는지 이름 말고 ID로 정확히 확인해줘. 그리고 그 ID랑 설정 화면에 보이는 목록을 하나씩 대조해줘.

프롬프트 3: 낯선 화면·기능에 처음 진입하기 전에

지금부터 안내하는 화면에서 내가 누르는 버튼이나 진입하는 화면이 각각 정확히 뭘 새로 만들거나 바꾸는 건지 미리 설명해줘. 특히 뭔가 새로 생성되는 동작이면 진행하기 전에 나한테 먼저 물어봐줘.

🎓 4주 스터디를 마치며

돌아보면

처음 시작은 단순했습니다. "병원 갈 때마다 흩어진 기록을 매번 찾아 헤매지 말고, 한 화면에 모아두자." 그 정도 목표였는데, 4주를 거치면서 예상보다 훨씬 많은 걸 배웠습니다.

• 1주차: 흩어진 기록을 대시보드 한 페이지로 모으는 것부터 시작했습니다.

• 2주차: "보기만 하는" 대시보드에 "기록하는" 기능(직접 입력, 사진 업로드)을 붙였습니다. 이때 처음으로 "AI가 내놓은 첫 번째 설명을 그대로 믿지 않고 되묻는 것"의 중요성을 체감했습니다.

• 3~4주차(이번 편): 겉으로는 잘 만들어진 것처럼 보였던 자동화가 사실은 조용히 실패하고 있었던 걸 발견하고, 그 원인을 인프라 설정까지 파고들어 잡았습니다. 그리고 그 과정에서 "이해하지 못한 채로 진행부터 하면 안 된다"는 걸 다시 한번 뼈저리게 느꼈습니다.

개발을 전공하지 않았는데도, AI에게 시키는 것에서 그치지 않고 왜 안 되는지, 무엇이 진짜 원인인지를 끝까지 따라가 보는 경험을 한 게 이번 스터디에서 가장 남는 부분입니다. AI가 다 해주는 것 같아도, 결국 "이게 왜 필요한 동작인지, 진짜 원인이 뭔지"를 판단하는 몫은 사람에게 남아있다는 걸 매번 확인했습니다.

앞으로 개선해볼 것

이번 프로젝트에 국한된 게 아니라, 앞으로 AI와 함께 일할 때 계속 가져가고 싶은 습관들입니다.

1. 낯선 화면·기능은 먼저 이해하고 나서 진행하기. 이번 환경 중복 생성처럼, "일단 눌러보고 다음에 확인하자"는 태도가 오히려 뒷수습을 더 힘들게 만든다는 걸 배웠습니다.

2. 중요한 설정값은 어딘가에 기록해두기. 배포 주소, 환경 ID, 허용 도메인처럼 "어딘가엔 있지만 아무도 적어두지 않은" 정보 때문에 두 번이나 헤맸습니다. 이제부터는 이런 값들을 프로젝트 문서에 바로바로 남겨두려고 합니다.

3. 자동화는 "실행됐는지"가 아니라 "결과가 나왔는지"까지 확인하는 습관 들이기. 이번 일로 조용히 실패하는 자동화가 제일 무섭다는 걸 알았습니다. 앞으로는 정기적으로 결과물까지 확인하거나, 실패 시 알림이 오도록 만들어볼 생각입니다.

4. AI가 작업한 내용을 스터디 사례글처럼 계속 기록하기. 이번 스터디는 끝나지만, 이 습관만큼은 개인 프로젝트를 계속하면서 이어가려고 합니다.