[GL 1기] Cypress로 시작하는 E2E 테스트, 그리고 4주 만에 동작한 웹크롤러 (성장일지 7회차 큐레이션) 🌱

안녕하세요! 그로스로그 입니다!😊 🌱

브라우저를 대신 조작해주는 테스트 도구를 처음 써본 기록, 그리고 엑셀 노가다에서 시작한 아이디어가 4주 만에 동작하기까지의 기록. 1기 마지막 회차 두 편입니다.

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.

1기는 2024년 5월에 시작해 8월에 마무리됐습니다. 이번이 그 마지막 회차예요.

 

01

🧪 Cypress 사용하기

이종경 님

이종경 님 원문에 실린 이미지

이런 내용이에요
E2E 테스트 도구로 Cypress를 도입하면서, 왜 Playwright가 아니라 Cypress였는지부터 밝히고 시작합니다. 도구를 고른 이유가 먼저 나오는 글이라 따라가기 편해요.
본격적인 내용은 SPA에서 겪는 어려움입니다. 화면이 서버에서 완성돼 오는 게 아니라 자바스크립트로 그려지다 보니, 테스트가 요소를 찾으러 갔을 때 아직 화면에 없는 상황이 자주 생깁니다.
그럴 때 어떻게 대응해야 하는지를 실제 코드와 함께 정리했습니다. 직접 부딪히며 얻은 팁들이라 문서에는 없는 이야기들이 섞여 있어요.

E2E 테스트는 "사용자가 실제로 하는 행동"을 자동으로 재현하는 테스트입니다. 로그인 버튼을 누르고, 아이디를 입력하고, 목록이 뜨는지 확인하는 식이죠.

이 글은 Cypress로 그 작업을 시작하면서 만난 것들을 정리했습니다. 특히 SPA에서 DOM이 잡히지 않는 문제를 다룬 부분이 실전적이에요.

조금 더 들어가 보면

테스트에는 층이 있습니다. 함수 하나를 검증하는 단위 테스트, 여러 모듈이 함께 도는지 보는 통합 테스트, 그리고 사용자 시나리오 전체를 돌려보는 E2E 테스트입니다.

E2E는 가장 실제에 가깝지만 가장 다루기 까다롭습니다. 실제 브라우저를 띄우고, 실제 네트워크를 타고, 실제 화면을 그리니까요. 느리고, 잘 깨집니다.

여기서 글이 짚은 SPA 문제가 나옵니다.

예전 웹은 서버가 완성된 HTML을 보내줬습니다. 페이지가 도착하면 모든 요소가 이미 거기 있었죠. 그런데 React·Vue 같은 SPA는 다릅니다. 빈 껍데기 HTML이 먼저 오고, 자바스크립트가 실행되면서 화면을 그립니다. 데이터를 API로 받아와야 하는 부분은 더 늦게 채워지고요.

그래서 테스트가 버튼을 찾으러 갔을 때 그 버튼이 아직 없을 수 있습니다. 사람 눈에는 순식간이지만 기계에게는 순서가 중요하거든요.

초보자가 여기서 흔히 하는 대응이 "일단 3초 기다리자"입니다. wait(3000) 같은 걸 넣는 거죠. 당장은 통과합니다. 그런데 이게 최악의 선택이에요. 네트워크가 느린 날엔 3초로도 부족해 실패하고, 빠른 날엔 쓸데없이 3초를 버립니다. 테스트가 100개면 5분이 그냥 날아가요.

Cypress가 좋은 평가를 받는 이유가 여기 있습니다. 명령마다 자동으로 재시도(retry-ability)를 합니다. "이 버튼을 클릭해"라고 하면 버튼이 나타날 때까지 짧은 간격으로 계속 확인하다가, 나타나면 즉시 클릭해요. 있으면 바로, 없으면 정해진 시간까지 기다립니다. 고정 대기가 필요 없어지는 거죠.

Playwright와의 차이도 성격이 분명합니다. Cypress는 브라우저 안에서 테스트 코드가 함께 실행됩니다. 그래서 디버깅이 직관적이고, 실행 과정을 화면으로 되돌려 볼 수 있어요. 대신 브라우저 안에 갇혀 있다 보니 여러 탭이나 도메인을 넘나드는 시나리오에 제약이 있습니다. Playwright는 바깥에서 브라우저를 조종하는 방식이라 자유롭고 여러 브라우저를 지원하지만, 처음 배우기엔 Cypress 쪽이 부드럽습니다.

둘 다 정답이 있는 선택이 아닙니다. 그래서 이 글처럼 "왜 이걸 골랐는지"를 적어두는 게 의미가 있어요.

큐레이터 노트

도구 선택의 이유부터 쓴 글이라 뽑았습니다.

기술 글에서 가장 흔한 형태가 "A 사용법"입니다. 유용하지만, 읽는 사람은 "내 상황에도 A가 맞나"를 알 수 없어요. 이 글은 Playwright와 비교한 뒤 고른 이유를 먼저 밝혀서, 읽는 사람이 자기 상황에 대입해볼 수 있게 했습니다.

그리고 막혔던 지점을 남긴 것이 좋았습니다. SPA에서 DOM이 안 잡히는 문제는 공식 문서를 아무리 읽어도 잘 안 나옵니다. 직접 해봐야 만나는 벽이거든요. 이런 게 개인 블로그의 진짜 값어치예요. 공식 문서가 채우지 못하는 자리를 메워주니까요.

원문 읽으러 가기  ↗velog.io/@jong-kyung/Cypress-%EC%82%AC%EC%9A%A9%ED%95%98%E…

 

02

🕸️ #B3. Baro Data가 작동된다! (B3~B5 연작)

안혜린 님

안혜린 님 원문에 실린 이미지

이런 내용이에요
엑셀로 반복하던 단순 작업에서 출발한 아이디어가, 4주 만에 실제로 동작하는 웹크롤러가 되기까지의 기록입니다.
개발자가 만든 프로그램이 웹 안에서 실제로 돌아가는 걸 처음 본 순간의 반응이 그대로 남아 있어요. "신기하다, 이게 되네"라는 문장으로 시작합니다.
그리고 이야기는 거기서 끝나지 않고 경진대회 무대까지 이어집니다. 설레는 마음과 앞으로의 다짐을 담은 3편 연작이에요.

1기의 마지막 큐레이션은 그로스로그를 만든 사람의 기록입니다.

이 글은 기술 문서가 아닙니다. 코드도 없고 설정값도 없어요. 대신 아이디어가 실제로 움직이는 걸 처음 본 사람의 반응이 담겨 있습니다.

엑셀로 반복하던 작업이 있었습니다. 그걸 자동화하면 어떨까 하는 생각이 들었고, 팀이 붙었고, 4주 뒤에 실제로 동작하는 프로그램이 나왔습니다. 그 과정에서 나온 문장이 "신기하다. 이게 되네."예요.

조금 더 들어가 보면

Baro Data는 1기 신입회원 프로젝트로 진행된 웹크롤러입니다. 그로스로그가 기수마다 운영하는 팀 프로젝트의 첫 결과물 중 하나예요.

웹크롤링은 기술적으로 진입 장벽이 낮은 편입니다. 그런데 실제로 쓸 만한 물건으로 만들려면 생각보다 손이 많이 갑니다.

수집 대상 사이트의 구조가 바뀌면 크롤러는 바로 깨집니다. 요청을 너무 빠르게 보내면 차단당하고요. 로그인이 필요한 페이지, 자바스크립트로 늦게 그려지는 화면, 페이지네이션 처리, 그리고 모아온 데이터를 어떤 형태로 저장할지까지 — 하나씩 결정해야 할 게 계속 나옵니다.

그래서 "4주 만에 웹 프로그램 안에서 동작하는 걸 보여줬다"는 게 가볍지 않습니다. 크롤러 스크립트를 돌리는 것과, 그걸 웹 화면에 붙여서 다른 사람이 쓸 수 있게 만드는 건 다른 일이거든요.

그런데 이 글에서 정말 중요한 건 기술이 아닙니다.

비개발자가 문제를 정의하고, 개발자가 그걸 구현하고, 팀이 완성했다는 구조입니다. 엑셀로 반복하던 불편을 겪은 사람이 있었기에 아이디어가 나왔고, 그걸 만들 수 있는 사람이 있었기에 물건이 됐어요. 어느 한쪽만으로는 안 되는 일이었습니다.

그로스로그가 개발자만의 모임이 아니라 "성장하려는 사람들의 모임"으로 시작한 이유가 여기 있습니다. 문제를 아는 사람과 만들 줄 아는 사람이 같은 자리에 있어야 뭔가가 나오니까요.

큐레이터 노트

1기 마지막 큐레이션에 이 글이 놓인 게 우연 같지 않습니다.

이 기록을 쓴 분은 그로스로그를 만든 사람입니다. 커뮤니티를 만들고, 첫 기수를 운영하고, 그러면서 본인도 멤버로서 성장일지를 썼어요. 운영만 한 게 아니라 같이 제출하고 같이 큐레이션 대상이 됐습니다.

저희가 이 글을 고른 이유는 그 사실 때문이 아닙니다. 글 자체가 좋았어요.

기술 블로그에는 완성된 결과물 이야기가 많습니다. 그런데 뭔가가 처음 동작하는 걸 본 순간의 감정을 적은 글은 드물어요. 대부분 그 감정을 지우고 결과만 정리하니까요. "신기하다. 이게 되네"라는 문장을 그대로 남긴 게 이 글의 힘입니다.

개발을 오래 하면 그 순간의 놀라움이 무뎌집니다. 그런데 사실 그게 이 일을 계속하게 만드는 감정이잖아요. 처음 동작했을 때의 기분을 기록해두면, 지쳤을 때 다시 꺼내볼 수 있습니다.

성장일지를 쓰는 이유 중 하나가 그거라고 생각합니다.

원문 읽으러 가기  ↗urban-techy.tistory.com/12

💡 두 편을 겹쳐 읽으며

한 편은 테스트 자동화 도구를 다루고, 한 편은 프로젝트가 처음 동작한 순간을 다룹니다. 층위가 완전히 다른데, 1기의 마지막 회차에 이 둘이 나란히 놓인 게 상징적입니다.

한쪽은 만든 것이 계속 잘 돌아가게 만드는 일이고, 다른 쪽은 아무것도 없던 데서 무언가를 만들어낸 일이에요.

개발은 이 두 가지가 번갈아 옵니다. 새로 만드는 흥분이 있고, 그걸 무너지지 않게 지키는 꾸준함이 있습니다. 둘 중 하나만으로는 오래 못 가요. 만들기만 하면 금세 무너지고, 지키기만 하면 앞으로 못 나갑니다.

1기 7회차에 이 두 편이 함께 뽑힌 게, 지금 돌아보면 그 균형을 보여주는 것 같습니다.

이번 회차에서 가져갈 것

1. 고정 대기(wait(3000))는 답이 아니다. 테스트가 불안정할 때 시간을 넣어 넘기고 싶어지지만, 그건 문제를 미루는 겁니다. "무엇이 준비될 때까지" 기다리게 만드는 쪽으로 바꿔야 느리지도 깨지지도 않습니다.

2. 도구를 고른 이유를 적어두기. Cypress냐 Playwright냐에 절대적 정답은 없습니다. 그래서 선택의 근거를 남겨두면 나중에 상황이 바뀌었을 때 다시 판단할 수 있어요. 결론만 적어둔 문서는 재검토가 불가능합니다.

3. 처음 동작한 순간을 적어두기. 결과물은 나중에도 볼 수 있지만, 그때의 감정은 적어두지 않으면 사라집니다. 그리고 그 감정이 다음 프로젝트를 시작하게 만드는 연료가 됩니다.

---

1기를 마치며

1기는 2024년 5월에 시작해 8월에 마무리됐습니다. 7회차, 14편의 큐레이션이 그 기록으로 남았어요.

지금 다시 읽어보면 이때가 아무 전례가 없던 시기였다는 게 느껴집니다. 어떤 글을 써야 하는지, 얼마나 자세히 써야 하는지, 실패한 이야기도 써도 되는지 — 아무도 몰랐어요. 그런데도 매 회차 이런 글들이 올라왔습니다.

Redis 세션 클러스터링부터 시작해서, 방통대 졸업 전략, nginx 버퍼링, FCM 푸시, AWS 프리티어의 함정, 그리고 마지막엔 처음 동작한 크롤러까지. 실무와 학업과 프로젝트가 뒤섞인 이 목록이 그로스로그가 어떤 곳인지를 그대로 보여줍니다.

이 기록들이 2기로, 3기로, 그리고 지금 5기까지 이어졌습니다.

좋은 글 남겨주신 이종경 님, 안혜린 님께 감사드립니다. 그리고 아무 길도 없던 첫 기수를 함께 만들어주신 모든 1기 멤버분들께 다시 한번 감사드려요! 😊

다음은 2기 큐레이션으로 찾아오겠습니다! 🌱

- 에디터 · 성장일지 큐레이터 -

---

※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.