매일매일 마주하는 새로운 문제들

[ 내가 겪은 문제들 ]

이번에도 역시 개발을 하는 과정 중간중간 여러 어려움이 있었다. 특히 스크래핑 작업은 한 회사만 잘 해 놓으면 다른 회사는 금방 할 수 있을 줄 알았는데 매일매일 새로운 문제와 마주했다. 너무 많은 문제가 있었지만, 나름 중요하다고 생각하는 문제들을 위주로 정리해볼까 한다. 

# 문제 1 -  “또다시 설계부터”

이번 과제도 역시 설계부터 진행했다. 설계를 하다 보면 생각해야 할 부분이 너무 많아서 아직도 제일 어려운 부분인 것 같다. 이번에는 댓글과 대댓글 부분을 설계하면서 어려움을 겪었다.

<문제>

• 댓글과 대댓글을 모두 테이블로 만들 경우 너무 많은 테이블이 생성된다.

<해결 방법>

• 댓글 테이블에 ‘parent_comment_id’ 라는 필드를 두어 대댓글의 경우 부모의 comment_id를 필드에 넣어준다. 부모 댓글의 경우  ‘parent_comment_id’ 필드 값은 Null 값을 가진다. (편의상 댓글을 부모 댓글, 대댓글을 자식 댓글로 표현했다.)

# 문제 2 - “쿠키를 이용한 인증”

현재 P2P 업체는 현재 공인 인증서 & 공동 인증서를 사용할 수 없다. 그러므로 사용자로부터 직접 정보를 받아와 P2P 사이트에 직접 로그인하여 스크래핑 작업을 거쳐야 한다.  

<문제>

• 로그인 요청을 많이 할 경우, 해당 P2P 사이트에서 잘못된 접근으로 인식하고, 로그인 시도를 막을 수 있다.

<해결 방법>

• 해당 사이트의 쿠키 정보를 따로 저장하여 로그인할 때 header에 쿠키를 넣어서 로그인한다. 
• 만약 쿠키의 유효 기간이 만료되었다면 다시 로그인하여 쿠키 정보를 저장한다.

# 문제 3 - “쿠키는 어디에 저장할까?”

처음에는 쿠키 정보를 데이터베이스에 저장했었다. 하지만 각 업체별로 사용자 인증을 하는 방법이 모두 다르고, 쿠키 값을 하나만 가지고 있을 때도 있지만 여러 값을 가질 수도 있다.

<문제>

• 어떤 사이트는 쿠키를 통해 사용자를 인증하지만, 어떤 사이트는 로그인에 성공할 경우 token을 발행하여 token을 통해 사용자를 인증한다.

<해결 방법>

• 다양한 사용자 인증 정보들을 데이터베이스가 아닌 파일에 저장한다.
• pickle을 이용해 사용자 인증 값을 파일에 저장하고, 마이페이지에 접속할 때 파일에서 인증값을 읽어와 header에 넣어 요청한다. 

# 문제 4 - “로그인에 필요한 다양한 정보들”

사용자가 로그인을 하기 위해서 브라우저는 사용자의 아이디, 비밀번호 정보만 알면 된다고 생각했다. 하지만 스크래핑을 진행하다 보니 다양한 사이트들에서 보안상의 문제로 여러 방법을 사용하고 있어 사이트의 정보를 가져오는데 어려움이 있었다. 

<문제>

• 어떤 사이트에서는 client_id, csrf_token이라는 값들을 로그인할 때 아이디, 비밀번호와 함께 보내주어야 한다.

<해결 방법>

• 이런 값들은 html 헤더에 숨겨져 있거나, script 파일에 값이 있는 경우가 대부분이었다. 직접 어디에 값이 있는지 확인하여 정규 표현식을 이용해 이 값을 가져오는 코드까지 스크래핑 코드에 추가해야 했다. 

# 문제 5 - “매번 실시간으로 값을 불러와야 할까?”

처음에는 사용자가 요청할 때마다 매번 실시간으로 스크래핑을 해오도록 했다. 이번 2차 기술 세미나에서 부하 테스트라는 주제의 발표가 있었는데, 아마 처음 방식으로 서비스가 제공된다면 아주 적은 사용자의 접속만으로도 서버가 제 기능을 하지 못할 것 같다는 생각이 들었다. 

<문제>

• 매번 실시간으로 스크래핑을 해서 값을 가져올 경우 서버에 너무 많은 무리가 간다.

<해결 방법>

• 프론트엔드에서 값을 요청할 때 “refresh”라는 항목을 추가로 보내주어, 사용자가 값의 새로 고침을 원할 때만 실시간 스트리밍으로 값을 전달해 준다.
• 하지만 “refresh” 값이 false일 경우는 DB에 저장된 값을 보내준다.
• DB에 저장된 값과 실제 사이트 값의 일치를 위해 사용자 이용이 적은 새벽 시간에 자동으로 스크래핑이 실행되는 작업이 진행되어야 한다. 
• 이때 서버는 매번 깨어있다는 사실을 이용해 스케줄러를 이용할 수 있다. 
• 스케줄러를 사용해 매번 특정 시간에 python 소스 코드를 실행시킬 수 있다. 
• 윈도우 환경에는 윈도우 스케줄러, 리눅스 환경에서는 crontab을 사용할 수 있다. 
• 윈도우 환경에서도 별도의 설치 과정을 통해 crontab을 사용할 수도 있다. 

[ 여러 문제를 만나며 ]

사실 처음 스크래핑을 해야 한다는 과제를 받았을 때, 아무 어려움 없이 금방 해낼 수 있을 것으로 생각했었다. 인턴 생활을 하기 전 스크래핑을 해봤었고, 그 과정에서도 어려움이 많았었기에 그때 겪은 어려움들이 다 일 것이라고 생각했는데, 정말 매일매일 에러와 싸웠다. 회사마다 다른 인증 절차, 보안 방법들 때문에 하루에 한 회사를 스크래핑 하는데 시간을 다 보내기도 했었다. 

그래도 많은 회사를 스크래핑 하면서 웹 사이트가 어떤 식으로 동작하는지는 확실히 알게 된 것 같다. 이번에 특히 REST API를 통해 데이터를 주고받는 회사들 때문에 script도 많이 보게 되었는데, 평소에 script 파일은 볼 일이 없었기 때문에 정말 낯설었지만, 점점 변수들을 찾아가는 속도가 빨라지는 게 느껴져서 뿌듯했었다. 

[ 앞으로의 인턴 생활 ]

이후부터는 서비스 배포 실습이 진행된다고 한다. NCP(Naver Cloud Platform) instance 생성, ubuntu 서버 세팅, 소스 배포, 테스트 등 제일 해보고 싶었던 부분을 실습할 수 있어 벌써 기대가 된다. 이번에 배우는 내용에 대한 사전 지식은 거의 없다고 보는 게 맞기에 앞으로도 많은 문제와 만나지 않을까 싶다. 그래도 매번 새로운 것들을 배워가며, 조금씩 자신감을 찾아가고, 스스로 코드를 작성하는 일이 점점 익숙해지고 있는 것 같다.

매번 코드를 짜면서 느끼는 것이지만 학교 수업에서 교수님들이 왜 그렇게 알고리즘과 네트워크를 중요한 과목이라고 말씀하시었는지 이제야 느껴가고 있다. (항상 나중에 알아차려 매번 뒤늦게 고생하는….) 예전에는 특정한 기능을 할 수 있는 코드를 짜는 게 목표였다면, 요즘에는 어떻게 하면 더 효율적이고, 서버에 무리가 가지 않을까도 아주 조금은 생각하고 있는 것 같다. 아직 스스로가 부족하다는 것을 매일매일 느끼고 있고, 더 열심히 공부해야겠다는 생각이 든다. 앞으로 남은 인턴 기간 동안에도 새로운 것들을 받아들이는데 겁먹지 않고, 매일매일 새로운 것들을 배워나갈 수 있는 2달이 되었으면 좋겠다.