Posts

Today I Learned 날짜 2024년 2월 6일 화요일 내용 많은 것을 하진 못했다. weekly review report email은 잘 작동했지만 1가지 오류가 발생했다. 실서버 데이터 중 잘못된 데이터가 있어 그 샵의 시간대를 찾지 못했다. 어제 미처 추가하지 못한 부분이라 해당 부분에 대한 예외처리 코드를 추가했다. 당장 급한 Task는 없다고 생각해 테스트 코드를 작성하려고 했다. 이번에 만든 기능들에 대한 유닛테스트 코드를 작성해두고 싶었다. 2달? 정도 전 내가 이미 있던 테스트들이 고장나있던 상태라 고쳤는데 1가지 오류가 발생했다. 모든 타입의 위젯을 생성해보는 테스트였는데 특정 타입에서 item_per_page 라는 속성이 없어 발생한 문제였다. 각 위젯별로 위젯에 보여줄 아이템의 갯수를 설정할 수 있는데 GALLERY_GRID_TEMPLATE 타입에는 설정할 수 없다. 내가 파악하기론, GALLERY_GID 라는 위젯 안에 들어가는 템플릿이기 때문이다. 따라서 위젯을 생성하는 함수에서는 처리하지 않는 타입이라 오류가 발생했다. 제외 이유를 각주에 추가하고 테스트 케이스에서 제외했다. ...

Today I Learned 날짜 2024년 2월 5일 월요일 내용 이전에 진행했던 Task들을 마무리했다. 로컬에서는 문제없이 작동한다는 것을 확인했기 떄문에, 테스트 서버에서 확인이 필요했다. logging문으로 구체적인 예외 메시지를 확인할 수 있었는데, 특정 데이터가 None일 때 오류가 발생했다. 오류가 난 필드는 shop이 꼭 가지고 있어야 하는 데이터였기 때문에 이상했다. 테스트 서버의 데이터베이스를 확인해보니 모든 필드의 값이 None으로 되어있는 뜬금없는 데이터가 들어있었다. 그 레코드 하나를 지우면 해결될 일이지만, 실제 서버에서 이런일이 발생했다면 저 뜬금없는 레코드 하나때문에 작동을 안하고, 찾을려고 이리저리 뒤져볼 모습을 생각하니 해프닝으로 넘어갈 일은 아니라고 생각했다. ...

Today I Learned 날짜 2024년 2월 2일 금요일 내용 삼지선다 나름 기가 막힌 아이디어가 떠올라서, 어제의 Task를 처리했다. 내가 달성해야 할 구현 목표는 다음과 같다. 구글 스프레드시트에 있는 데이터는 기존 행에 새로운 값을 덮어써준다. 구글 스프레드시트에 없지만 2024년 2월 이후 가입했거나, 기존에 가입했으나 새로 AI 서비스를 이용하게 된 고객의 데이터는 새로운 행에 추가해준다. 서비스에서 탈퇴해 데이터가 없어졌을 떈 스프레드시트에서도 삭제한다. 추가된 데이터를 한번 정제해서 쓰면 되니 굳이 API가 완벽하게 정리된 데이터를 만들 필요는 없다고 하셨지만 뭔가 놓치고 있다는 느낌이 자꾸 들어 기존의 걸림돌을 되짚어봤다. ...

2.3 인터넷 전자메일 인터넷 메일 시스템의 상위 요소에는 다음 3가지가 있다. 사용자 에이전트(user agent) 사용자의 메시지 읽기, 전달, 저장, 구성을 담당 ex) 지메일, 마이크로소프트 아웃룩, 스파트몬용 지메일 앱 메일 서버(mail server) 각 수신자는 메일 서버 안에 **메일박스(mailbox)**를 갖고 있다. 메일박스는 수신한 메시지를 유지하고 관리한다. 송신자의 사용자 에이전트 → 송신자의 메일 서버 → 송신자의 메일 서버의 메시지 큐 → 수신자의 메일서버 → 수신자의 메일 서버 내 메일박스 수신자의 서버 고장으로 전달할 수 없으면 메시지를 **메시지 큐(message queue)**에 보관하고 나중에 전달을 재시도한다. SMTP(Simple Mail Transfer Protocol) 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜 TCP의 신뢰적인 데이터 전송 서비스를 이용 송신자의 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있음. 메일 서버가 송신할 때 : SMTP의 클라이언트로 동작 메일 서버가 수신할 때 : SMTP의 서버로 동작 2.3.1 SMTP A가 B에게 메일을 보내는 과정 A는 네이버의 전자메일 사용자 에이전트에게 B의 전자메일 주소(B@gmail.com)를 제공하고 메시지를 작성하여 메시지를 보내라고 명령한다. A의 사용자 에이전트(네이버)는 메시지를 A의 메일 서버에게 보내고 그 메시지는 서버에서 메시지 큐에 들어간다. A의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에서 메시지를 확인한다. 이후 B의 메일 서버에서 수행되는 SMTP 서버에게 TCP 연결을 설정한다. 이때 포트는 25. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 A의 메시지를 TCP 연결로 보낸다. B의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 이 메시지는 B의 메일 서버의 메일박스에 저장된다. B은 사용자 에이전트를 이용해 그 메시지를 읽는다. A와 B의 메일 서버가 물리적으로 거리가 멀더라도, 중간 메일 서버는 사용하지 않는다. 따라서 B의 서버가 죽어 있으면 전달하지 못한다. 이 떄, A 서버의 메시지 큐에 두고 지속적으로 재발송한다. 일정시간이 지나면, 폐기하고 A에게 발송이 실패했음을 알린다. 두 서버의 TCP 연결이 설정되면, SMTP의 서버와 클라이언트는 애플리케이션 계층 핸드셰이킹을 수행한다. 핸드셰이킹에서 서로에 대한 정보를 알게 되는 것처럼, 이때 클라이언트는 서버에게 두 사람(송신자와 수신자)의 전자메일 주소를 제공한다. 2.3.2 메일 메시지 포맷 우편을 보낼때, 편지 봉투에는 여러 정보가 담기게 된다(발신자, 수신자 등) 전자 메일에서는 메시지 몸체 앞에 있는 헤더에 담긴다. 2.3.3 메일 접속 프로토콜 메일 서버가 개인의 로컬호스트에 있다면, 항상 메일을 받기 위해 서버가 켜져있어야 한다. 따라서, 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다. 즉, 메일 서버는 보통 사용자들과 공유한다. 송신자의 사용자 에이전트는 메일 서버를 통해 수신자의 메일 서버로 메시지를 전송한다. 왜 송신자의 사용자 에이전트가 직접 수신자의 메일 서버로 메시지를 전송하지 않을까? 송신자의 사용자 에이전트는 수신자의 메일 서버에 도달할 수 없기 때문 이유는 보안 문제, SMTP의 규약, 스팸 방지, 신뢰성 보장 등 다양하다. 수신자의 사용자 에이전트는 받은 메시지를 보기 위해 SMTP를 사용할 수 없다. SMTP는 push지만 메시지는 pull 해야 하기 때문 메시지를 받는 방법 HTTP를 통해 요청 인터넷 메일 접근 프로토콜(Internet Mail Access Protocol, IMAP) 사용 이 둘 모두 메일 서버에 의해 유지되는 폴더를 관리하게 된다.

Today I Learned 날짜 2024년 2월 1일 목요일 내용 스프린트 결과가 배포됐다. 다행히 큰 빵꾸는 없었다. 많은 유저가 몰려왔으면 좋겠다. 구글 스프레드시트에 데이터 추가하기 새로 만든 기능에 대한 KPI 데이터를 구글 스프레드시트에 추가하는 태스크를 맡았다. 이전에, 작동이 멈췄던 커맨드를 다시 돌리는 작업을 했었는데 이와 비슷할거라고 생각해서 별로 어렵지 않겠다 싶었다. 약간의 차이점이 있었는데 이 부분을 너무 쉽게 생각했다. 기존에는 매일매일 새로운 행에 데이터를 추가했지만, 이번에는 기존 데이터에 덮어써야 했다. 1개의 샵 당 1개의 데이터를 가지게 되며, 이미 데이터가 존재한다면 새로 행을 추가하지 않고 수정해야 한다. ...

2.2.3 HTTP 메시지 포맷 HTTP 요청 메시지 ex) 1 2 3 4 5 GET /somedir/page.html HTTP1.1 Host: www.abc.com Connection: close User-agent: Mozilla/5.0 Accept-language: fr 메시지가 일반 아스키 텍스트로 쓰여있어 우리가 읽을 수 있다. 메시지는 5줄로 되어있고 각 줄은 CR(carriage return, \r)과 LF(line feed, \n)로 구별된다. CR : \r, 맨 앞으로 이동하라는 뜻 LF: \n, 새로운 라인 첫 줄을 **요청 라인(request line)**이라고 부른다. 3개의 필드로 구성 : method(GET), URL(/somedir/page.html), HTTP 버전(HTTP1.1) 이후의 줄들은 **헤더 라인(header line)**이라고 부른다. 요청하는 객체가 존재하는 호스트(Host) 명시 TCP 연결에서 이미 알게 되었지만, 웹 프록시 캐시에서 필요함 비지속 연결 명시(Connection) 요청을 보내는 브라우저 타입(User-agent) 객체의 언어 버전(Accept-language) : 서버에 있다면 프랑스어로 보낼 것 헤더라인 이후에 개체 몸체(entity body)가 있음. POST 방식에서만 존재하는, 클라이언트가 채워 넣는 곳 GET요청에서는 body 대신 URL 끝에 parameter로 추가됨(https://url.com?…) HEAD 방식 HTTP 메시지로 응답하고, 요청 객체를 보내지 않음 개발자의 디버깅에 많이 사용 PUT, DELETE, … HTTP 응답 메시지 ex) ...

AWS 이 글은 누군가 AWS를 다룰 때 조금이나마 덜 고생하길 바라는 마음으로 작성하며, 부정확한 정보에 대한 지적, 정정을 환영하고 자신이 아는 바가 있다면 얼마든지 추가해주길 바랍니다. 앞으로 지속적으로 추가할 예정입니다. What is AWS? 아마존 웹 서비스(AWS, Amazon Web Service)는 아마존닷컴의 클라우드 컴퓨팅 사업부이다. 아마존 웹 서비스는 다른 웹 사이트나 클라이언트측 응용 프로그램에 대해 온라인 서비스를 제공하고 있다. Region 아마존은 클라우드 컴퓨팅을 제공하기 때문에, 데이터센터를 곳곳에 보유하고 있다. 주 고객층을 생각해 물리적으로 가까운 리전을 선택한다. ...

Today I Learned 날짜 2024년 1월 31일 수요일 내용 logging과 print 문의 차이 : stdout buffer logging과 print의 차이에 대해 많이 찾아봤는데 디버깅을 위해선 logging문을 쓰는 것이 좋다는 의견이 대다수다. 사실 그냥 다 logging을 쓰라고 한다. 단순 출력이 아닌, 오류 메시지나 변수 내용, 위치 등을 다양하게 출력할 수 있으니 print가 쓰기는 편해도 전체 디버깅 작업의 속도를 높이는데는 logging이 훨씬 효과적이다. backgrountasks에서 print가 작동이 안되는 이유에 대해선 정확한 내용을 찾기 힘들었는데, stdout buffer가 원인이라는 얘기가 있다.stdout은 표준 출력 데이터를 의미한다. 반대로 stdin은 표준 입력(ex. 키보드) 데이터를 의미한다. 백준에서 알고리즘을 풀다보면 키보드 입력을 input() 이나 sys.stdin.readline() 으로 받곤 하는데 여기서 stdin이 나오는 걸 알 수있다. print 함수는 stdout을 사용하여 출력한다. print문이 콘솔창에 찍히는 것도 표준 출력으로서 나타나는 것. ...

2.2 웹과 HTTP(1) 2.2.1 HTTP 개요 웹의 애플리케이션 계층 프로토콜인 **HTTP(HyperText Transfer Protocol)**는 웹의 중심이다. **웹 페이지(Web page, 문서)**는 객체(object)들로 구성된다. **객체(object)**는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, 자바스크립트, CCS 스타일 시트 파일, 비디오 클립 등)이다. 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다. 각 URL은 2개의 요소를 갖고 있다. 객체를 갖고 있는 서버의 호스트 이름 객체의 경로 이름 **웹 브라우저(Web browser)**는 HTTP의 클라이언트 측을 구현하기 떄문에 웹의 관점에서 클라이언트와 브라우저는 혼용된다. HTTP는 TCP를 전송 프로토콜로 사용한다. 과정 HTTP 클라이언트가 먼저 서버에 TCP 연결을 시작 브라우저와 서버 프로세스는 각자의 소켓 인터페이스를 통해 TCP로 접속. 소켓 인터페이스는 각 프로세스와 TCP 연결 사이에서의 출입구다. 서버와 클라이언트는 메시지를 소켓 인터페이스에게 보낸다. 이후 부터는 TCP의 몫이다. HTTP는 **비상태 프로토콜(stateless protocol)**이다. 클라이언트에 대한 정보를 유지하지 않기 떄문이다. 2.2.2 비지속 연결과 지속 연결 클라이언트-서버 상호작용이 TCP상에서 발생할 때, 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지면 비지속 연결(non-persistent connection) 모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내지면 지속 연결(persistent connection) HTTP/1.0가 디폴트 모드로 지속 연결을 사용하지만 HTTP 클라이언트와 서버는 비지속연결을 사용하도록 설정될 수 있다. 비지속 연결 HTTP 클라이언트가 서버에게 URL을 통해 html 파일을 요청한다고 가정해보자. HTML 파일은 여러 개의 참조 객체 이미지를 가진다. HTTP 클라이언트는 HTTP 기본 포트 번호 80을 통해 서버로 TCP 연결을 시도한다. 그 결과 클라이언트와 서버는 각각 소켓을 가진다. 클라이언트가 자신의 소켓을 통해 HTTP 요청 메시지를 보낸다. 이 요청에는 필요한 html의 경로 이름을 포함한다. 서버는 소켓으로 요청 메시지를 받고 필요한 html 객체를 추출한다. 응답 메시지에 객체를 캡슐화하고 소켓을 통해 클라이언트로 보낸다. HTTP 서버는 TCP에게 TCP 연결을 끊으라고 한다(하지만 실제로는 클라이언트가 응답을 올바로 받을 때까지 끊지 않는다). 클라이언트가 응답 메시지를 받으면 TCP 연결이 중단된다. 필요한 참조 객체(이미지) 10개를 가져오기 위해 각각의 객체에 대한 TCP 연결이 시작된다(1~4 반복). 비지속 연결에선 총 11개의 TCP 연결이 발생한다. 순차적으로 하지 않고 동시 연결(동시에 11개의 연결을 구성하여 각각 처리)로 응답 시간을 줄일 수 있다. 세 방향 핸드셰이크(three-way handshake) SYN(Synchronize) : 클라이언트가 서버에 연결을 요청하는 메시지를 보냄 SYN-ACK(Synchronize-Acknowledment) : 서버가 클라이언트의 연결 요청을 수락하고, 클라이언테에게 확인 응답을 보냄 ACK(Acknowledgment) : 클라이언트가 서버의 확인 응답을 받고, 다시 서버에 확인 메시지를 보내 연결을 완료한다. RTT(round-trip time) : 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 돌아오는 데 걸리는 시간 세 방향 핸드셰이크 중 2단계가 완료될때 까지의 시간이 RTT다. ACK는 2단계가 완료된 후 요청 메시지를 보낼 때 같이 보낸다. 서버에 요청을 보낼 떄는 (TCP 연결 + 요청)이 필요하다. 따라서 서버의 응답시간은 (2RTT + 파일 전송 시간)이다. 지속 연결 HTTP 비지속 연결의 단점 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 함. 이를 위해 필요한 TCP 버퍼는 서버에게 부담이 될 수 있음. 응답시간 (2 RTT) 지속 연결은 하나의 지속 TCP 연결로 여러 웹페이지와 관련 객체를 통신할 수 있다. 파이프라이닝(pipelining) : 각 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있음. HTTP 서버는 타임아웃 기간동안 사용되지 않으면 연결을 닫기 떄문에, HTTP 디폴트 모드는 파이프라이닝을 이용해 지속 연결한다.

Today I Learned 날짜 2024년 1월 30일 화요일 내용 계속 QA를 진행하고 있다. 키워드 추출 실패 갑자기 특정 경우에 키워드를 추출해내는데 실패하고 있다. 키워드는 nltk 관련 문제라 AI가 고장난 건 아니였다. 안되는 상품의 URL을 들어가보니 리뷰들이 모두 한글로 작성되어있었다. 그동안 리뷰가 당연히 영어로 가져와질 것이라고 생각했는데, 원어(작성 언어)와 접속시 설정한 언어 중 하나로 선택할 수 있었다. 문장을 단어 단위로 쪼개는 tokenize는 punkt 데이터를 사용하는데 어제 말했듯 정말 다양한 언어 데이터가 존재하지만, 긍정 부정을 판별하는 opinion_lexicon은 영어밖에 없었다. 리뷰를 항상 영어 번역하여 가져오도록 했더니 해결되었다. ...