8월부터 시작한 단기간 프로젝트가 다 끝났다.
하루에 한 시간씩 깔짝거린 프로젝트라서 뭐 회고라고 할 것도 없는데, 그래도 프로젝트를 하면서 느낀 점은 써둬야 하지 않을까 해서 대충 적어보려고 한다.
(사실 프로젝트 끝은 8월 말에 다 끝냈는데 이제서야 정리하고 회고를 하게 되었다... 좀 부지런해져야 할 필요가 있을 듯)
프로젝트를 시작하기 전 느낀 점
일단 나는 평소에 Studocu 사이트를 굉장히 유용하게 활용하고 있었다.
답지를 따로 구매하기에는 가격이 꽤 부담되고... 그렇다고 푼 문제를 채점하지 않는 것은 문제를 푼 의미가 없어지니까. 그래서 전 세계 대학생들이 문제를 해결한 자료나 답지를 공유하는 사이트인 Studocu를 굉장히 편리하다고 생각했다.
그런데 Studocu를 사용하다 보면, 어느 시점부터 프리미엄 회원이 아니라면 더이상 답지의 이미지를 볼 수 없게 되는 경우가 생긴다. 그럴 때마다 나는 매번 시크릿 모드로 다시 그 주소로 들어가서 답지를 보고 그랬었는데, 이게 너무나도 귀찮았다.
이걸 어떻게 무료로 볼 수 있는 방법이 있을까 고민하다가... Studocu의 답지 이미지는 일정한 패턴으로 Studocu S3 서버에 저장되어 있다는 사실을 발견했다.
"어...? 이 정도 수준이라면 충분히 답지 이미지를 가져올 수 있겠는데...?"
그렇게 다음 학기가 개강하기 전에 빠르게 답지 이미지를 가져오는 사이트를 개발해서, 다음 학기를 좀 편리하게 다녀보고자 프로젝트를 기획하고, 개발하기 시작했다.
그래서 사실 지금에서야 밝히지만, AnswerDev는 답지 이미지를 크롤링하는 사이트가 아니라 Studocu S3 서버에서 이미지 주소를 도적질해 와서 내 서버에 띄우는 프로젝트이다. 프리미엄 회원이 아니라면 Studocu에서는 답지 이미지 자체를 프론트 단으로 보내지 않기 때문에, S3 서버에 저장되어 있는 답지 이미지의 주소를 내가 직접 알아내야 했다. 다행히 이 패턴을 찾을 수 있었어서 답지 이미지의 주소를 모두 알아낼 수 있었다.
물론 어느 정도 두려움은 있었다. 남의 S3 서버에 함부로 접속하는 것은 당연히 문제가 되기에...
그래서 나는 그냥 프로젝트를 배포하지 않고 나 혼자 사용하려고 했다. 암암리에 혼자만 사용하려고 했는데 그렇게 하자니 뭔가 아쉬운 느낌이 좀 들었다. 아무리 간단한 프로젝트라고는 하지만 그래도 열심히 개발했는데... 남들에게 보여주고 싶다는 그런 욕심?
그래서 일단 배포는 해 놨다. 물론 사용할 사람들이 없을 거라는 것을 알기에...ㅋㅋ 문제가 생기면 그 때 닫아야지 뭐
그리고 사실 이렇게 간단한 프로젝트를 진행한 데에는 이유가 있었다.
어느 날 지금까지 진행했었던 프로젝트들을 다시 돌아보니... 진짜 엉망진창 그 자체였다. 코드에서 구조라고는 찾아볼 수도 없었고, 하나의 Service에 모든 기능을 다 때려박는다던가 암튼 그런 토 나오는 수준의 코딩을 해놨던 것이었다.
그리고 구현해 놨던 기능들도, 내가 구현했다기보다는 그냥 남의 블로그를 그대로 베껴온 것에 불과하다고 생각했다. 이렇게 코딩을 해 놨다고 한 들, 내가 무슨 성장을 할 수 있을까?
그래서 나는 아주 기초적인 수준부터 모두 내 스스로 하나 하나 구현해보고자 이러한 간단한 사이드 프로젝트를 시작하게 된 것이었다. 다른 사람들의 블로그도 최소한으로 보고, 내가 의존할 곳은 오로지 라이브러리의 공식 문서 뿐이라는 생각으로 프로젝트를 시작했다.
프로젝트를 진행하면서 느낀 점
굉장히 수월했다. 다른 사람들의 블로그를 참고하지 않고 오로지 공식 문서만을 보고 코드를 작성하니 코드의 일관성도 유지되는 것 같고 코드 자체가 굉장히 깔끔하게 작성되었다고 생각한다.
물론 일부 라이브러리는 공식 문서가 제대로 작성되어 있지 않은 경우도 있었다. 그럴 때는 StackOverFlow에서 2023년 게시물 이후 게시물로만 참조했다. 너무 예전 게시글의 경우에는 Deprecate된 코드를 아직 사용하고 있는 경우가 많았기 때문이다.
실제로도 아직 Spring Security의 FilterChain을 설정하는 방법에 대해 구글 검색을 해보면, 아직도 WebSecurityConfigurerAdapter을 상속받아서 사용하고 있는 경우가 태반이다. 하지만 이러한 방식은 이미 Deprecate되었고... 나는 공식 문서에서 사용하는 방식을 따랐다.
그리고 비동기로 코드를 돌리는 방식도 성능 향상에 굉장히 큰 도움이 되는데, 구글링하면 아직 비동기 기능을 적용하지 않은 채 코드를 작성하는 분들이 많이 계셨다. 저번 현장실습을 경험하면서 비동기 방식은 거의 필수적이라는 것을 배운 이후로, 나는 이 프로젝트에 비동기 방식을 적용하였다. 뭔가 남들이 잘 알지 못하는 좋은 기능을 사용한 느낌이라서 뿌듯했다.
그 외에도 프로젝트 구현 자체는 딱히 어려운 부분 없이 수월하게 진행되었다고 생각한다.
그러나 한 가지 굉장히 큰 허들이 있었는데... 이 부분에 대해서는 아래에서 후술하겠다.
이건 여담이지만 S3 서버에서 이미지 주소를 가져오는 프로젝트를 진행하면서도... 해당 사이트의 보안이 확실히 허술하다는 생각을 많이 했다. 나 같은 일개 대학생에게도 답지 이미지를 다 노출당하는 수준이라니... 허수아비를 문지기로 세워 둔 급이라고 생각했다. 만약 내가 취직을 하게 되어서 서버를 개발하게 된다면... 진짜 보안에 대해서도 확실히 신경을 써야 할 것 같다..
프로젝트를 끝내며 느낀 점
사실 굉장히 간단하고, 단기간의 프로젝트였기 때문에 큰 감흥이나 감정은 느껴지지 않는다 ㅋㅋ
올해 초만 해도 인스타그램 클론하고 굉장히 기뻐했었는데, 이제 단순히 그 정도로는 큰 감흥은 느껴지지 않는 수준까지 온 것을 보니 올 상반기 동안 내가 큰 발전을 했다는 것이 느껴지기도 한다.
이번 프로젝트는 너무 단순했다. 그러나 단순한 만큼 기본기를 다지기 굉장히 좋았다고 생각한다.
기초부터 차근차근 스스로 코드를 작성하다 보니 SpringBoot의 구조에 대해서 어느 정도 이해할 수 있게 되었고, 단순히 남들이 작성한 블로그 코드를 베끼는 것을 하지 않고 나만의 코드를 작성할 줄 알게 되었다. 그리고 서버 개발자로서 보안이 얼마나 중요한 것인지도 알 수 있게 되었다(안 그러면 나 같은 사람들이 서버 자료를 빼가니까...)
나는 일상 생활 속에서 사소한 불편함을 해소하는 개발자가 되고 싶다. 지금까지의 프로젝트들도 그래왔고(물론 프로젝트라고 할 만한 것도 없지만), 앞으로도 그런 방향으로 나아가고 싶다.
위기 - EC2 Docker 환경에서 Selenium 크롤러가 봇으로 탐지되던 현상
그렇다... 위에서 말했던 굉장히 큰 허들이라는 게 바로 이것을 뜻하는 것이었다.
로컬에서는 Selenium을 headless로 돌려도 아무런 문제가 없었다. 그런데 EC2에서는 Selenium을 headless로 돌리면 봇으로 탐지되어 캡챠를 해달라는 웹사이트로 연결되었다.
그래서 크롬 드라이버 옵션에 온갖 매개변수를 다 넣어봤는데... 이 문제는 해결되지 않았다. 그래서 사실 아직도 이 문제는 해결하지 못한 채로 배포 중이다 ㅋㅋㅋ
처음 배포했을 땐 그래도 어느 정도 답지 크롤링이 잘 되었는데, 지금 보니까 10번 중 9번은 봇으로 탐지되는 듯...? 굉장히 비상...!
사실 프로젝트가 꽤 오래 걸린 것도 이 문제 때문이었다. 이 문제를 해결하기 위해 거진 2주를 머리 싸매고 고민했는데... 아직 해결하지 못했다. 심지어 최근에는 봇으로 더 쉽게 탐지가 되어서 아무래도 시간이 날 때 이 문제를 확실히 해결해야 할 것 같다.
아쉬운 점
- 스크랩 기능을 기획했지만, 나의 게으름으로 인해 추가하지 못한 채 프로젝트를 배포한 것.
사용자 경험을 위해서라면 이 기능은 반드시 있으면 좋을 것 같다고 생각했었다. 안 그러면 매번 URL을 복사해서 붙여 넣어야 하는 번거로움이 있으니까.
이제 와서 구현하라고 하면 뭐 할 수는 있다. 그러나 이 기능을 구현한다고 해서 내가 크게 성장할 부분은 없을 거라고 생각해서 일단은 미뤄 두도록 하겠다. - 배포 환경에서 크롤링 시도 시 봇으로 탐지되는 문제를 해결하지 못한 것.
이걸 반드시 해결했어야 했는데, 내 무능함으로 인해 아직도 해결하지 못했다.
사용자들이 편리하게 사용하기 위해서 이 문제를 반드시 해결해야 한다. 언젠가는 꼭 해결할 것이다. - Selenium 크롤링 시도 시 상당히 오랜 시간이 소요된다는 것.
이 문제는 한 번 가져온 답지의 이미지는 해당 답지의 URL과 연결시켜 DB에 저장해 둠으로써, 한 번 크롤링 했던 URL인 경우에는 Selenium이 아닌 DB로 조회함으로써 응답 속도를 굉장히 높이고자 했고, 실제로 코드를 이렇게 작성했었다.
그런데 답지 이미지의 URL에 제공되는 쿼리 스트링이 Studocu의 세션 정보를 가지고 있다는 것을 알게 되었고, 그래서 답지 이미지의 URL이(정확히는 그 쿼리 스트링이) 일정 시간 마다 업데이트 해 주어야 하는 상황이 발생했다.
물론 이 문제는 어렵지 않게 해결할 수 있지만, 봇 탐지 문제를 먼저 해결하려고 일단 미뤄놨다가 아직까지 봇 탐지 문제도 해결하지 못해서 이 문제도 해결하지 못 한 상태이다... 언젠가는 해결해야지. - 테스트 코드를 작성하지 않았다는 것.
사실 이 때 까지만 해도 TDD의 중요성을 거의 모르던 상태였다. 그러나 최근에 대다수의 기업들은 TDD를 선호하고 있다는 것을 알게 되었고, 테스트 코드 작성으로 80%의 오류는 막을 수 있다는 것을 알게 되었다.
TDD의 중요성을 이제 알게 되었으니... 해야겠지?
크게 느낀 아쉬운 점들은 이 세 가지라고 생각한다.
물론 나는 아직 미완성 개발자이기에 부족한 게 굉장히 많지만... 뭐 점차 고쳐 나가야 한다고 생각한다.
그래도 덕분에 의미 있던 한 달을 보냈던 것 같다. 심지어 이번 학기에 유용하게 사용할 수 있을 것 같은 서비스를 만들었으니 ㅋㅋㅋ
혹시 궁금한 게 있다면 댓글에 적어주시면 친절하게 답변해 드리겠습니다.
'프로젝트 > AnswerDev' 카테고리의 다른 글
[AnswerDev] 5. 동적 페이지 크롤링 using Selenium (0) | 2024.09.11 |
---|---|
[AnswerDev] 4. @Async 비동기 처리와 Security Context (0) | 2024.08.17 |
[AnswerDev] 3. Security 필터와 permitAll() (0) | 2024.08.17 |
[AnswerDev] 2. 비동기 처리 (0) | 2024.08.15 |
[AnswerDev] 1. 해답 크롤러 개발 준비 (0) | 2024.08.10 |