잘되는 기능보다, 안 되는 이유를 찾는 일이 더 많았다
Santiago Brain을 만들면서 가장 많이 한 일은 새로운 기능을 추가하는 것이 아니었다.
오히려 이런 말을 더 많이 했다.
“왜 안 되지?”
“아까는 됐는데 왜 지금은 안 되지?”
“화면에는 있는데 왜 데이터가 없다고 나오지?”
“수정했다고 했는데 왜 실제 사이트는 그대로지?”
처음에는 오류가 생길 때마다 당황했다.
하지만 시간이 지나면서 생각이 조금 바뀌었다.
앱을 만든다는 것은 오류를 없애는 일이 아니라, 오류가 생겼을 때 원인을 찾아가는 과정에 가깝다.
특히 AI와 함께 개발하다 보니, 내가 직접 코드를 모두 이해하지 못해도 화면과 현상을 설명하면서 원인을 좁혀갈 수 있었다.
1. 버튼을 눌렀는데 아무 반응이 없는 문제
가장 흔했던 오류 중 하나다.
예를 들어 Google Calendar 연결 버튼을 눌렀는데 아무 반응이 없었다.
처음에는 로그인 문제라고 생각했다.
하지만 실제로는 버튼 상태가 잘못 저장되어 있거나, 화면이 오래된 상태를 보고 있는 경우도 있었다.
이런 문제는 겉으로 보기에는 단순하다.
사용자는 그냥
“버튼이 안 된다.”
라고 느낀다.
하지만 안쪽에서는
버튼 이벤트 문제,
인증 상태 문제,
캐시 문제,
브라우저 새 창 문제,
서버 응답 문제
등 여러 원인이 있을 수 있다.
그래서 하나씩 분리해서 확인해야 했다.
2. 분명 수정했는데 화면에 그대로 나오는 문제
이 문제도 정말 많이 겪었다.
예를 들어 상태값을 한글로 바꿨는데,
어떤 화면에는 여전히 waiting이 그대로 보였다.
나는 분명히 수정했다고 생각했다.
그런데 실제로는 한 곳만 바꾼 것이었다.
다른 카드나 다른 화면에서는 상태값을 직접 출력하고 있었다.
그래서 규칙을 바꿨다.
각 화면에서 따로 변환하지 않고,
모든 곳에서 같은 상태 표시 함수를 사용하도록 만들었다.
예를 들어,
waiting, pending → 대기
active, in_progress → 진행 중
completed, done → 완료
이런 식이다.
이때 배운 것은 이것이다.
같은 의미를 여러 곳에서 따로 처리하면 언젠가는 불일치가 생긴다.
3. Preview에서는 되는데 실제 사이트에서는 안 되는 문제
이 문제는 처음에 가장 헷갈렸다.
개발 화면에서는 분명히 수정된 기능이 보였다.
그런데 실제로 사용하는 공개 사이트에 들어가면 예전 화면이 그대로였다.
처음에는 수정이 실패한 줄 알았다.
하지만 이유는 따로 있었다.
개발 환경의 Preview와 실제 배포된 사이트는 다를 수 있다.
수정이 끝나도 다시 배포하지 않으면 실제 사이트에는 반영되지 않을 수 있다.
그래서 개발 순서를 더 명확하게 만들었다.
수정 → Preview 확인 → 테스트 → 배포 → 실제 사이트 확인
지금은 이 흐름을 거의 습관처럼 보고 있다.
4. 일정이 있는데 “일정 없음”이라고 나오는 문제
Google Calendar 연동에서도 이런 일이 있었다.
캘린더에는 일정이 분명히 있었다.
그런데 Santiago Brain에서는 일정이 없다고 나왔다.
이 문제를 처음 보면
“Google Calendar 연결이 끊어졌나?”
라고 생각하기 쉽다.
하지만 실제로는
연결은 정상인데 데이터를 읽지 못하는 문제일 수도 있다.
기본 캘린더만 읽고 있거나,
다른 캘린더를 놓치거나,
날짜 범위가 잘못됐거나,
시간대 계산이 어긋날 수 있다.
그래서 “연결 여부”와 “데이터 조회 여부”를 따로 확인하게 됐다.
5. 이미 끝난 일이 계속 오늘 우선순위에 나오는 문제
이 문제는 실제로 꽤 오래 남아 있었다.
광주 귀향이라는 할 일이 있었다.
실제로는 오래전에 끝난 일이었다.
그런데 오늘 화면에 계속 우선순위로 나타났다.
원인을 찾아보니 Google Tasks 원본에서는 여전히 미완료 상태였다.
Santiago Brain은 사람처럼
“이건 옛날에 이미 끝났지”
라고 기억하지 않는다.
데이터상 미완료이고 마감일이 지났다면,
그냥 중요한 overdue 할 일로 판단한다.
그래서 단순히 오래된 일을 전부 숨기기보다,
특정 Google 할 일을 Brain에서 우선순위 제외할 수 있게 하는 방식이 필요했다.
이 문제를 통해 다시 확인했다.
AI와 자동화는 내가 알고 있는 현실보다, 데이터에 적힌 상태를 더 믿는다.
6. 오늘과 내일 일정이 두 개인데 문자에는 하나만 오는 문제
문자 자동화에서도 이런 일이 있었다.
오늘 일정 하나,
내일 일정 하나가 있었다.
그런데 아침 문자에는 오늘 일정만 왔다.
제목은 분명히
“오늘과 내일 일정”
이라고 적혀 있었다.
문자는 정상적으로 발송됐다.
그래서 문자 서비스 자체의 문제는 아니었다.
문제는 그 전에 일정 데이터를 모으는 과정에 있었다.
오늘만 조회했는지,
내일 날짜 범위가 빠졌는지,
Google Calendar와 Tasks 중 한쪽만 읽었는지,
필터 과정에서 하나가 빠졌는지
확인해야 했다.
이런 문제는 겉으로는 한 줄짜리 문자 오류지만,
원인은 여러 단계에 걸쳐 있을 수 있었다.
7. 예약 작업은 돌았는데 문자가 안 오는 문제
반대로 문자가 아예 안 오는 경우도 있었다.
이때는 더 복잡하다.
예약 자체가 실행되지 않았을 수도 있다.
예약은 실행됐는데 일정 조회에서 멈췄을 수도 있다.
일정 조회는 성공했는데 문자 API 호출이 실패했을 수도 있다.
문자 API까지 호출했는데 인증이나 IP 제한에 걸렸을 수도 있다.
그래서 자동화에서는 단순히
“작업이 실행됐는가”
만 보면 안 됐다.
어디까지 성공했고, 어느 단계에서 실패했는가
를 봐야 했다.
이 때문에 로그와 발송 이력의 중요성을 많이 느꼈다.
8. 같은 할 일이 두 번 생기는 문제
중복 저장 문제도 자주 신경 써야 했다.
사용자가 버튼을 두 번 누를 수도 있다.
네트워크가 느려서 재시도가 일어날 수도 있다.
AI가 같은 저장 요청을 두 번 보낼 수도 있다.
이때 프로젝트나 할 일이 중복으로 생기면,
화면뿐 아니라 진행률 계산까지 틀어질 수 있다.
그래서 같은 요청이 반복되어도 중복 생성되지 않도록 방어가 필요했다.
특히 프로젝트를 만들 때
프로젝트,
마일스톤,
할 일
이 한꺼번에 생성되기 때문에 더 조심해야 했다.
9. 테스트는 실패했는데 실제 기능은 맞는 경우도 있었다
개발하면서 재미있는 경험도 있었다.
기능은 제대로 동작하는데 테스트가 실패하는 경우가 있었다.
이유를 보면 테스트가 예전 화면 문구를 기대하고 있는 경우가 많았다.
예를 들어 화면은 이미 한글 표현으로 바뀌었는데,
테스트는 예전 영문 상태값을 찾고 있었다.
이 경우에는 기능을 예전으로 되돌리는 것이 아니라,
테스트를 현재 기능에 맞게 수정해야 했다.
이것도 처음에는 낯설었다.
테스트가 실패했다고 항상 프로그램이 틀린 것은 아니었다.
기능이 바뀌었는데 테스트가 뒤처질 수도 있었다.
10. 삭제 버튼 하나도 여러 오류를 만들었다
삭제 기능도 생각보다 복잡했다.
예전에는 영구삭제를 하려면
정확히 영구 삭제라는 문구를 입력해야 버튼이 활성화되는 방식이 있었다.
그런데 띄어쓰기 하나만 달라도 버튼이 활성화되지 않았다.
사용자 입장에서는 불편했다.
그래서 나중에는
“되돌릴 수 없음을 이해했습니다”
체크박스를 선택한 뒤 삭제 버튼이 활성화되는 방식이 더 낫다고 생각했다.
하지만 또 문제가 생겼다.
한 화면에서는 새 방식으로 바뀌었는데,
휴지통 화면에는 예전 입력 방식이 그대로 남아 있었다.
이 역시 같은 기능이 여러 곳에 따로 구현되어 있을 때 생기는 문제였다.
오류 화면을 캡처하는 습관이 생겼다
Santiago Brain을 개발하면서 나는 거의 항상 화면을 캡처했다.
설명만 하는 것보다 훨씬 정확했다.
예를 들어
“버튼이 안 돼”
보다
실제 화면을 보여주고
“여기 버튼을 눌렀는데 비활성 상태다”
라고 하면 원인을 찾기가 쉬웠다.
AI도 화면을 보면서
어떤 문구가 보이는지,
어떤 상태인지,
어떤 버튼이 빠져 있는지
훨씬 구체적으로 분석할 수 있었다.
그래서 나에게는 화면 캡처가 개발 도구 중 하나가 됐다.
한 번에 많이 수정하면 원인을 찾기 어려웠다
처음에는 여러 문제를 한꺼번에 고치고 싶었다.
하지만 기능을 여러 개 동시에 수정하면,
문제가 생겼을 때 어느 변경 때문인지 찾기 어려웠다.
그래서 점점
하나씩 수정하고, 확인하고, 다음으로 넘어가는 방식
을 선호하게 됐다.
예를 들어
상태 한글화 수정,
확인,
오늘 화면 정리,
확인,
프로젝트 진행률 수정,
확인
이런 식이다.
조금 느려 보여도 결과적으로는 더 빨랐다.
AI가 “완료했다”고 해도 직접 확인해야 했다
AI Agent가 작업을 끝내면
“수정 완료”
라고 말할 수 있다.
하지만 나는 점점 그 말을 그대로 믿지 않게 됐다.
부정적인 의미가 아니다.
프로그램은 환경에 따라 결과가 달라질 수 있기 때문이다.
그래서 실제 화면에서 확인하고,
필요하면 새로고침하고,
배포 후 실제 사이트에서도 다시 확인했다.
자동 테스트가 통과했는지도 본다.
이 과정을 거쳐야 정말 완료된 것이다.
오류를 겪으면서 앱의 구조가 좋아졌다
처음에는 오류가 생기면 그냥 불편했다.
하지만 지금 생각하면 많은 오류가 구조를 더 좋게 만드는 계기가 됐다.
waiting이 남아 있던 문제 때문에 상태 표시를 통일했다.
중복 문제 때문에 저장 방식을 강화했다.
삭제 오류 때문에 보관·삭제·복원 정책을 정리했다.
문자 오류 때문에 발송 로그가 중요하다는 것을 알게 됐다.
오래된 Google 할 일 문제 때문에 외부 데이터를 무조건 신뢰하면 안 된다는 것을 알게 됐다.
즉,
오류 하나가 규칙 하나를 만들었다.
비개발자에게 가장 중요한 것은 오류를 두려워하지 않는 것이었다
예전의 나라면 오류 화면이 나오면
“내가 이걸 할 수 있을까?”
부터 생각했을 것이다.
지금은 조금 다르다.
오류가 나오면 먼저 묻는다.
“어디까지는 정상인가?”
로그인은 되는가.
데이터는 있는가.
화면만 문제인가.
저장은 되는가.
배포가 안 된 것인가.
이렇게 하나씩 나누면 문제의 범위가 줄어든다.
나는 코드를 전부 이해하지 못한다.
하지만 문제를 작게 나누고 현상을 정확하게 설명하는 능력은 조금씩 늘었다.
AI 시대의 개발은 오류와 대화하는 과정일지도 모른다
Santiago Brain을 만들면서 느낀 것은,
AI가 있다고 해서 오류가 없어지는 것은 아니라는 점이다.
대신 달라진 것은
오류가 생겼을 때 혼자 해결하지 않아도 된다는 것이다.
화면을 보여주고,
상황을 설명하고,
원인을 같이 찾고,
수정한 뒤 다시 확인한다.
이 과정을 반복하면서
조금씩 내가 원하는 앱에 가까워진다.
그래서 지금은 오류가 나타나도 예전처럼 크게 겁먹지는 않는다.
오히려
“또 하나 배울 게 생겼구나.”
라고 생각하는 경우가 많아졌다.
다음 글 예고
10편 — Santiago Brain을 실제로 사용해보니
마지막 글에서는 개발 기능보다 실제 사용 경험을 정리해보려고 한다.
매일 오늘 화면을 사용하는 방식,
AI와 대화하면서 아이디어를 검토하는 과정,
일정과 할 일이 연결되면서 달라진 점,
실제로 유용했던 기능과 거의 쓰지 않았던 기능,
그리고 앞으로 Santiago Brain을 어떤 방향으로 발전시키고 싶은지까지 정리해보겠다.