안녕하세요. 디디 입니다!
영유아 자녀를 키우고 계신 학부모 분들이라면, 키즈노트라는 앱을 많이 사용하고 계실텐데요.
키즈노트는 어린이집·유치원과 학부모가 아이의 생활을 공유하고 소통할 수 있도록 만든 모바일 알림장 앱입니다.
다만 선생님들이 올려주신 사진을 모바일에서 다시 PC로 옮기거나, PC 웹사이트에서 수천 장의 사진을 하나씩 저장해야 하는 과정은 꽤 번거로웠습니다. 그래서 이 불편을 해결해보고자 OpenClaw를 활용해 Chrome Extension을 만들어 보았습니다.
이번 작업에서 특이했던 점은 IDE를 처음부터 열지 않았다는 겁니다. 오픈클로 대시보드에서 바로 시작했고, 오픈클로 Chrome Extension(browser relay) 을 활용하는 방식이 생각보다 훨씬 효율적이어서 그 경험을 공유해보려 합니다.
개발 흐름: 오픈클로 → VS Code + Codex
전체 작업은 크게 두 단계로 나뉘었습니다.
핵심 로직은 오픈클로 대시보드에서만으로 완성했습니다. 코드 작성, 파일 편집, 실행, 로그 확인, 커밋까지 한 흐름 안에서 반복이 가능했기 때문에 IDE를 따로 열 필요가 없었습니다. "코드만" 보는 게 아니라 세션/탭/네트워크 상태까지 같이 보면서 작업할 수 있다는 점이 이 방식의 핵심이었고요.
이후 QA 과정과 Chrome 웹스토어 등록을 위한 세부 준비(매니페스트 정리, 스크린샷, 개인정보처리방침 등)는 VS Code + Codex 로 진행했습니다. 반복적인 검토와 파일 정리가 많아지는 단계에서는 IDE가 역시 편하더라고요.
결국 "탐색·구현"은 오픈클로, "정리·마무리"는 IDE라는 흐름이 자연스럽게 만들어졌습니다.
처음엔 헤드리스 크롤링으로 시작했다가 방향을 틀었습니다
키즈노트가 로그인 기반 SPA라서, 처음엔 헤드리스 브라우저로 접근했습니다.
근데 현실은:
세션/쿠키 처리가 예상보다 까다롭고
동적 렌더링 때문에 DOM에 앨범 링크가 아예 안 잡히고
봇 탐지 이슈까지
결국 헤드리스 방식을 포기하고 Chrome Extension(browser relay)으로 전환했습니다.
Chrome Extension(browser relay)이 효과적이었던 이유
오픈클로 Chrome Extension(browser relay)은 별도의 브라우저 프로파일을 띄우는 게 아니라, 이미 로그인된 실제 Chrome 탭을 그대로 에이전트가 제어하는 방식입니다. 툴바 버튼 하나로 attach/detach가 가능하고, 에이전트는 해당 탭의 로그인 세션을 그대로 활용합니다.
① 인증 문제가 구조적으로 사라집니다
헤드리스 환경에서는 세션 재현을 위해 쿠키 복붙, 헤더 세팅, CSRF 토큰 처리 등을 직접 다뤄야 합니다. browser relay는 이미 로그인된 탭을 그대로 쓰기 때문에 이 과정 자체가 없어집니다.
② 내부 API 구조를 현장에서 빠르게 파악합니다
앨범 목록 수집 방식을 고민하던 중, 탭의 네트워크 흐름을 직접 확인했더니 내부 API 엔드포인트가 바로 보였습니다.
/api/v1_3/children/{id}/albums/
공식 문서가 없는 내부 API였는데, 실제 탭에서 트래픽을 보니 구조 파악이 빠르게 됐습니다. 결과적으로 DOM 파싱 시도를 접고(어차피 href 링크 자체가 없었 음) API 직접 호출로 방향을 바꿨고, 응답에 title, content, created, attached_images[], attached_videos[] 가 전부 포함되어 있어서 페이지 렌더링 없이 API만 순회하는 훨씬 안정적인 구조로 만들 수 있었습니다.
③ 가설 검증 사이클이 짧아집니다
"page_size를 100으로 올려도 서버가 허용할까?" 같은 의문이 생기면, attach된 탭에서 바로 fetch 날려보고 응답을 확인하면 끝입니다. 코드 수정 → 빌드 → 실행 → 로그 확인 사이클 없이 탭 콘솔 수준의 즉각적인 피드백이 가능합니다. (결과적으로 page_size=100 허용 확인 후 그대로 적용했습니다.)
④ "코드 문제"와 "환경 문제"를 빠르게 구분합니다
버그가 생겼을 때 코드가 문제인지, 실행환경(세션/탭 상태/타이밍)이 문제인지 구분하는 게 은근히 시간을 잡아먹거든요. browser relay를 쓰면 오픈클로가 실행환경을 직접 보면서 원인을 같이 추론하기 때문에 진단이 빠릅니다.
실제로 확장 Reload 직후 Receiving end does not exist 오류가 반복됐는데, 이것도 "콘텐츠 스크립트가 탭에 아직 attach되지 않은 것"으로 바로 특정되어, UI에 "준비/연결 확인" 단계를 추가하는 방식으로 깔끔하게 해결됐습니다.
바이브코딩과의 궁합
바이브코딩은 결국 빠르게 시도하고, 확인하고, 수정하 는 루프입니다. Chrome Extension(browser relay)은 그 "확인" 단계를 극단적으로 단축시켜줍니다.
코드 수정 → attach된 탭에서 즉시 결과 확인 → 다음 방향 결정.
IDE 없이 대시보드에서 핵심 로직을 완성할 수 있었던 것도 이 루프가 대시보드 안에서 완결되기 때문입니다. 편집, 실행, 환경 확인, 커밋까지 컨텍스트 전환 없이 한 흐름으로 이어지니까요.
특히 세션, 쿠키, 탭 상태처럼 환경에 의존적인 문제가 많은 작업일수록 이 차이가 더 두드러집니다. 코드만 반복해서 수정하는 것보다, 실행환경을 직접 보면서 같이 접근하는 방식이 이런 류의 작업엔 훨씬 적합하다는 걸 이번에 체감했습니다.
마치며
Chrome Extension 자체도 흥미로운 작업이었지만, 이번 프로젝트의 실질적인 수확은 "환경을 함께 보면서 작업하는 방식" 의 효율을 직접 확인한 것이었습니다.
로그인/세션이 엮이거나, "왜 안 되지?"가 반복되는 작업이라면 오픈클로 Chrome Extension(browser relay) 방식을 한번 고려해보세요. 접근 방식 자체가 달라집니다.
결과물은 아래 링크로 공유 합니다.
읽어 주셔서 감사합니다.
https://chromewebstore.google.com/detail/nhbdlacdjcdfhblnhihklhembdefjppo?utm_source=item-share-cb
