AWS Elastic Beanstalk 413 Request Entity Too Large 오류 해결

문제의 원인

Elastic Beanstalk 를 이용해서 웹 서비스를 Deploy 할 경우 어플리케이션의 Reverse Proxy로 사용되는 Nginx의 설정 때문이다. Nginx의 설정 값 중 client_max_body_size를 이용하면 client가 너무 큰 사이즈의 request를 보내지 못 하도록 제한을 걸 수 있다. 이 설정은 request의 Content-Length 헤더값이 client_max_body_size에 설정된 값을 넘을 수 없도록 제한한다.(악의적인 대용량 파일 업로드 등을 방지하는데 사용)

다만 이 client_max_body_size 의 기본 값이 1MB 정도로 너무 낮게 설정되어 있기 때문에, 1MB를 초과하는 파일을 POST로 업로드 하는 일반적인 상황에서도 에러메세지가 표시되며 요청이 실패하는 경우가 발생 한다.

해결 방법

Elastic Beanstalk 환경이 아니라면, Nginx 설정(nginx.conf)파일을 직접 수정하는게 가장 빠른 해결책 이겠지만, Elastic Beanstalk 을 사용하여 배포된 환경에서 해당 인스턴스에 직접 접속하여 Nginx 설정 파일을 직접 수정하는 것은 좋은 생각이 아니다. 직접 Nginx파일을 수정하면 오토스케일링 상황에서 새로 생성된 인스턴스에서는 여전히 동일한 이슈가 발생하거나 해당 어플리케이션을 새로운 환경에 배포 했을 때에도 동일한 문제가 재발 하여 환경의 강건성(Robustness)을 떨어뜨리는 요인이 되기 때문이다. 어플리케이션 코드 이외의 인프라에 신경을 쓰지 않아도 되도록 만들어주는 Elastic Beanstalk의 장점을 십분 살리기 위해서는 Elastic Beanstalk 에 업로드 되는 어플리케이션 패키지 내에서 해당 이슈를 해결 할 수 있도록 구성하여야 한다.

AWS Elastic Beanstalk 공식 문서 중 Extending Elastic Beanstalk Linux platforms 를 참고 하면 배포되는 환경의 Nginx 설정을 수정하는 방법에 대해 정확히 서술되어 있는데 어플리케이션 루트(아래 구조 예시에선 ~/workspace/my-app/)에서 아래와 같은 경로에 Nginx 설정 파일을 추가하면 해당 설정을 배포 환경의 Nginx가 포함하게 된다.

~/workspace/my-app/
|-- .platform
|   `-- nginx
|       `-- conf.d
|           `-- myconf.conf
`-- other source files

즉 위 구조에서는 myconf.conf의 내용으로(파일명은 상관 없음, 확장자는 .conf 이어야 함) 원하는 최대 용량을 아래와 같이 지정하고 어플리케이션을 다시 배포하면 해당 문제를 해결 할 수 있다.(0으로 값을 지정하면 무제한으로 설정됨)

client_max_body_size 50M;

부동산 거래 시 매도인의 하자담보책임에 대한 정확한 정리

거의 6개월에 가까운 고생 끝에 결국 어느정도 마음에 들고 조건에도 맞는 매물을 찾아 계약을 진행하게 되었다. 모든 재화를 구매할 때 우리는 그 재화가 판매되는 가격에 상응하는 가치를 가지고 있는지, 그리고 해당 재화에 결함이나 특별한 하자가 없는지 판단하고 구매를 하는 것이 일반적일 것인데 주택의 경우 우리가 살면서 구매하는 재화 중 가장 비싼 축에 해당하기 때문에 이러한 두가지 과정을 더욱더 신중하게 진행 할 수 밖에 없다.

지난 6개월간 서울 전역을 임장하고 돌아다니면서 고생한 것은 사실 전자에 관한 것 이었고(예산, 거주 환경, 통근 등 다양한 제약조건 내에서 가격 대비 최고의 가치를 가진 아파트를 찾아내는 것) 막상 물건을 정하고 계약을 진행하려고 하니 후자와 관련된 것이 걱정이 되기 시작했다. 몇천만원 짜리 자동차를 살 때에도 인수 직전 물건에 문제가 없는지 꼼꼼히 살피는데, 아파트의 경우 그것에 비해 몇십배 비싼 재화 이면서도 자동차와 비교도 할 수 없을 정도로 많은 요소들(토지, 건물, 인테리어, 샷시, 배관, 보일러 등)이 하나의 재화를 구성하고 있는데 오죽 하겠는가.

신축 아파트의 경우 상대적으로 시설의 상태가 양호할 확률이 높고, 해당 아파트를 시공한 시공사가 일정기간 ‘하자보수’ 기간을 보장하기 때문에 크게 걱정할 것은 없지만 우리와 같이 준공 후 20년이 넘는 ‘구축아파트’를 매수 할 경우 세월의 풍파에 따라 시설물의 상태가 악화되어 있을 가능성이 높고 그러한 상황에서 매수한 아파트에 문제가 발생할 경우 이 문제에 대한 책임을 두고 매도인과 매수인사이에 분쟁이 발생할 가능성이 높아진다.

매도인의 ‘하자담보책임’

이러한 분쟁의 상황에 대비하여 대한민국 민법 제 580조에서는 매도인의 ‘하자담보책임’을 아래와 같이 규정하고 있다.

제580조(매도인의 하자담보책임) (1) 매매의 목적물에 하자가 있는 때에는 제575조 제1항의 규정을 준용한다. 그러나 매수인이 하자있는 것을 알았거나 과실로 인하여 이를 알지 못한 때에는 그러하지 아니하다.

제575조(제한물권있는 경우와 매도인의 담보책임) (1) 매매의 목적물이 지상권, 지역권, 전세권, 질권 또는 유치권의 목적이 된 경우에 매수인이 이를 알지 못한 때에는 이로 인하여 계약의 목적을 달성할 수 없는 경우에 한하여 매수인은 계약을 해제할 수 있다. 기타의 경우에는 손해배상만을 청구할 수 있다.

제582조(전2조의 권리행사기간) 전2조에 의한 권리는 매수인이 그 사실을 안 날로부터 6월내에 행사하여야 한다.

민법 제580조, 제575조 제1항, 제582조

즉, 매매의 목적물(아파트)에 하자가 존재하는 경우 매수인은 매도인에게 해당 하자에 대한 손해배상을 청구 할 수 있고 더 나아가 매매 계약을 해제 할 수 있다는 것이다. 다만, 위 조항은 무조건적으로 하자 발생 시 매도인에게 손해배상을 청구하거나 계약을 해제 할 수 있다는 조항은 아니며 일반적으로 아래와 같이 네개 조건을 충족해야 한다.

  1. 정당하게 성립된 매매 계약 이어야 함
  2. 매수인이 계약 시점에 해당 하자의 존재에 대해 알지 못했어야하며, 매수인의 과실로 알지 못한 경우는 인정되지 않음(즉, 매도인이 하자에 대해 계약시점에 미리 고지하고 매매한 경우는 해당하지 않으며 하자에 대해 충분히 확인이 가능하였으나 매수인측의 과실로 계약시점에 인지하지 못한 경우는 해당하지 않음)
  3. 매수인은 하자를 인지한 날로 부터 6개월 이내에만 손해배상 청구 혹은 계약해제를 요구 할 수 있음(즉, 계약 시점이 기준이 아니고 하자를 인지한 시점을 기준으로 6개월 이내임)
  4. 하자는 계약시점에도 존재하여야 함(판례 상, 계약 시점은 계약 체결일 뿐만이 아니라 계약의 최종 이행일인 잔금일 까지를 의미함. 잔금일 이후 매수인이 하자를 발견하게 되는 경우 매수인은 적어도 잔금일 이전에도 해당 하자가 존재함을 입증해야 함)

인터넷에 관련된 내용을 찾아보면 특히 3과 관련하여 잘못된 정보가 공유되고 있는 경우를 심심치 않게 목격 할 수 있는데 – 가령 잔금일로 부터 6개월내 발생한 하자는 모두 매도인의 책임이라는 둥 – 이는 위에서 언급한 민법 조항만 잘 읽어보아도 잘못된 내용임을 알 수 있으며 심지어 개업 공인중개사 분들도 잘못된 내용을 작성, 공유하여 많은 혼란을 초래하고 있으므로 반드시 유의가 필요하다.

하자 담보 책임과 관련한 계약서 상 특약 조항 관련

보통 노후한 아파트에서 발생하는 중대하자의 경우 누수, 균열 등으로 발생 할 경우 비용이 크게 발생될 뿐만 아니라 해당 문제를 해결하는 과정에서 이웃간에 불필요한 스트레스가 발생하는 경우가 많기 때문에 매도인과 매수인 모두 해당 문제에 대해 민감하게 반응하기 마련이고, 이로인해 보통은 매매 계약서 상 특약을 넣고 계약을 체결하는 경우가 많다.

하지만 이번 매매 계약을 진행하면서 여러 방면으로 공부하고 정리를 해본 결과 정답은 ‘어차피 법에서 정의하고 있는 내용으로, 관련된 내용에 대해서는 별도로 계약서에 기입하지 않는 것’이라고 결론 내렸다.

통상 특약사항에 기입되는 내용들이 ‘중대하자가 발생할 경우 잔금일 이전에는 매도인 책임 잔금일 이후에는 매수인 책임'(이 경우 매도인이 발견하기 어려운 중대하자에 대해 잔금일 까지도 숨길 경우 매수인에게 불리함) 이라던지 ‘중대하자가 발생할 경우 잔금일로 부터 6개월까지는 매도인이 손해를 배상한다.'(이 경우 매수인의 과실여부나 계약 시점 하자 존재 여부와 무관하게 매도인이 배상하여야 하므로 매도인에게 불리함) 등 매도인이나 매수인 일방에 유리한 쪽으로 공평하지 않게 기입되는 경우가 많고(아마 공인중개사들이 분쟁 발생 시 책임 회피용으로 넣는 경우도 많은 것으로 안다.) 이렇게 공평하지 않게 작성된 특약은 어차피 큰 분쟁이 발생 하였을 경우 법정 공방으로 이어질 가능성이 높기 때문이다.

어차피 법에서 정확히 정의하고 있는 사안이라면, 매도인과 매수인 사이에서 특약 내용과 관련하여 불필요한 논쟁을 발생시키기 보다는 아예 관련 조항을 빼버리고 분쟁 발생 시 법적인 판단을 받는 것이 더 현명한 방법이라고 판단하였다.

중대 하자를 대하는 매수인의 태도

결국, 하자 발생 시 매도인의 하자담보 책임과 관련하여 가장 까다로운 부분은 해당 하자가 ‘계약시점(판례에 따르면 계약체결일 뿐만이 아니라 계약의 이행 시점인 잔금일 까지)’부터 이미 존재 하는 하자이어야 한다는 것이다.

따라서, 이사한 바로 다음날 갑자기 누수 등 중대한 하자가 발생한다고 하여도 그 하자가 잔금일에도 존재한다는걸 입증하지 못한다면 매수인은 매도인에게 하자보증책임을 요구하기 어렵다.

이러한 상황에서는 결국 아래와 같이 잔금일 이전까지 꼼꼼하고 지속적으로 매수 대상 물건에 대한 하자를 점검하는 것이 매수인에게 가장 중요한 자세라고 생각한다.

  • 매물 탐색 과정에서 첫 방문시 부터 집의 하자 유무에 대해 다방면으로 파악한다.(주요 하자 요소들에 대한 리스트를 미리 머리속에 담아두고 점검, 매도인 혹은 세입자와의 대화를 통해서 간접적으로 하자 유무 및 과거 히스토리 파악)
  • 계약서 작성일에 매도인에게 하자 유무와 하자 발생 시 책임에 대한 질문을 하며 그 답변 사항에 대해 녹음(분쟁이 발생하여 소송전에 이르게 될 경우 최소한의 안전 장치 확보, 본인이 대화에 참여하면 녹음이 불법이 아님)
  • 잔금일 잔금을 치르기전 주택의 최종 상태 확인하여 미리 고지되지 않은 하자 사항이 발견될 경우 매도인과 보상 협의
  • 잔금일 이후 만약 하자가 발생할 경우, 즉시 해당 하자의 전문가와 객관적인 상담을 진행하고 계약 시점에도 존재하였을만한 하자로 판단될 경우 하자 발생 사실에 대해 매도인에게 내용증명 등을 통해 통보

결론 : ‘어차피 완벽한 보호장치는 없다.’

결국, 매수한 주택에서 하자가 발생하는 일은 실제로 존재 할 수 있고 구축 아파트라도 매우 비싼돈을 주고 구매해야하는 작금의 현실 속에서 하자가 발생 할 경우 보상 책임에 대해선 매도인과 매수인 사이에서 피곤한 책임 공방전으로 이어질 가능성이 높다. 어떠한 경우에도 매도인 혹은 매수인 한쪽을 일방적으로 보호 할 수 있는 수단이 존재한다고 볼 수 없고, 계약의 당사자인 매수자가 인터넷에 떠도는 카더라식의 정보나 공인중개사의 말을 일방적으로 믿기보다는 스스로 관련 조항에 대해 공부하고 대비책을 마련하여 하자 발생 시 리스크를 헷징하는 것이 가장 최선의 길이라고 생각한다.

“세상에 내 편은 아무도 없고, 결국 모든 계약을 진행 할 때는 스스로를 지킬 방법을 항상 연구하자” 오늘의 교훈.

(저는 법률 전문가가 아니며, 위 내용은 법률 전문가의 검토를 받은 사항도 아닙니다. 부동산과관련된 모든 결정과 판단은 본인의 책임하에 신중하게 진행 하시길 바랍니다.)

Python/Django 쇼핑몰 서비스 스택

본 글은 회사 블로그에 본인이 작성한 글을 다시 갈무리한 것입니다.

이 글은 작년 7월경 본 블로그에 작성 하였던 Python/Django로 쇼핑몰 만들기 와 연결되는 글이며, 해당 글이 인프라와 사용하는 패키지 등이 혼합되어 작성되어 있었던 것과 달리 좀 더 서비스 인프라의 관점에서 작성되었습니다.


안녕하세요. 인테이크에서 시스템 개발과 운영을 담당하고 있는 조영일입니다. 인테이크는 현재 총 2개의 쇼핑몰(인테이크, 라이브스토어)을 운영하고 있으며 국내 대부분의 쇼핑몰과 달리 Cafe24, 고도몰 등의 쇼핑몰 솔루션을 사용하지 않고 프론트엔드 부터 결제 연동 등 백엔드 시스템 까지 모두 100% 자체 개발된 쇼핑몰을 운영하고 있습니다.

이 글은 이러한 쇼핑몰을 구축하면서 저희가 어떠한 도구와 스택을 도입하였는지, 쇼핑몰의 요소별로 설명한 글입니다. 쇼핑몰 기능에 집중하여 설명하므로, 일반적인 서비스 스택과는 다소 다른 구조를 가지고 있음을 참고 부탁 드립니다.

서비스 개발

  • 개발 언어 : Python
    그 유연성과 확장성 덕분에 너무나 많은 서비스들이 선택하고 있는 개발 언어인 Python을 사용 하고 있습니다. 웹 서비스 뿐만 아니라 사내 업무용 챗봇 및 통계 산출 도구 등 90% 이상의 프로젝트가 Python으로 개발 되었습니다.
  • 웹 개발 프레임워크 : Django
    전 세계적으로 가장 유명한 Python 기반 웹 프레임워크인 Django를 사용하고 있습니다. “The web framework for perfectionists with deadlines.”라는 캐치프레이즈에 맞게, Django는 웹 개발에 필요한 매우 풍부한 기능을 기본 탑재하고 있어서(덕분에 때로는 너무 무겁다고 평가 받지만) 필요한 기능을 가장 빠르게, 체계적인 방식으로 개발 할 수 있는 장점이 있습니다.  현재 인테이크 쇼핑몰, 라이브스토어 쇼핑몰, 쇼핑몰 및 외부 채널 주문을 취합 수집하고 물류센터와의 연계를 위한 SCM 시스템, 회사 공식 홈페이지 등 인테이크의 거의 모든 웹 서비스는 Django를 통해 개발 되었습니다.

서비스 호스팅

  • 서비스 호스팅 : AWS
    서비스 초기에는 국내 IDC를 사용하였으나, 서버에 대한 유지보수 이슈가 커짐에 따라 서비스의 개발과 운영에 집중하기 위하여 AWS(Amazon Web Service)를 도입하여 현재는 모든 서비스를 클라우드 상에서 제공하고 있습니다.

배포/오토 스케일링

  • 배포/오토스케일링 : AWS ElasticBeanstalk
    AWS에서 제공하는 어플리케이션 배포 서비스인 AWS ElasticBeastalk를 이용하여 어플리케이션을 배포하고 있습니다. AWS ElasticBeanstalk의 경우 기본적으로 AWS ELB(Elastic Load Balancer)를 통한 로드 밸런싱을 지원하며 git push 만으로도 새로운 버젼의 어플리케이션 배포 작업이 가능하여, 복잡한 배포 절차를 직접 구성 할 필요가 없습니다.AWS ElasticBeanstalk의 경우 배포 과정에서 pip를 통해 repository에 정의된 requirements.txt를 바탕으로 python dependency에 대해 자동으로 설치를 해주지만, 프로젝트에서 요구되는 python 이외의 dependency(리눅스 패키지 등)의 경우 ElasticBeanstalk에서 지원하는 Config Script를 작성하여 배포 단계에서 자동으로 설치되도록 하였습니다.오토스케일링의 경우 위에서 말한대로 AWS ElasticBeanstalk에서 ELB 를 통해 기본 제공하는 기능으로서, AWS 설정 콘솔에서 일정 시간 동안 Network In/Out 발생 할 경우 자동으로 서비스 인스턴스를 늘이고 줄일 수 있도록 하였습니다.

정적 컨텐츠 처리

  • 스토리지 : AWS S3
    인테이크는 기본적인 서비스 인프라를 AWS(아마존 웹 서비스) 상에서 운영하기 때문에 정적 컨첸츠 역시 AWS에서 제공하는 정적 컨텐츠 스토리지인 AWS S3를 통해 관리하고 있습니다.
  • CDN : AWS CloudFront
    정적 컨텐츠는 모든 사용자가 상시적으로 접근 하며, 쇼핑몰의 경우에 일반적으로 그 용량이 크므로(다수의 상품 썸네일, 긴 상품 상세 이미지 등) 컨텐츠를 제공하는 속도를 높이는 노력이 필요 합니다. 일반적으로 컨텐츠를 제공하는 서버와 사용자 사이의 물리적인 거리가 컨텐츠의 전송 속도에 큰 영향을 미칠 수 밖에 없는데, 인테이크는 이 문제를 AWS CloudFront 를 통해서 해결 하고 있습니다.AWS CloudFront는 AWS에서 제공하는 CDN(Contents Delivery Network)로서, S3에 존재하는 원본 정적 컨텐츠를 전 세계에 존재하는 50여개의 CloudFront 엣지 로케이션 서버에 캐싱 하므로서 전 세계의 사용자가 동일한 주소로 이미지를 요청하더라도 그 사용자에게 물리적으로 가장 가까운 엣지 로케이션 서버에서 파일을 제공하므로서 컨텐츠  빠르고 안정적으로 서빙 할 수 있도록 해줍니다.또한 AWS CloudFront를 사용 함으로서 모든 컨텐츠에 대해 사용자 도메인을 적용 할 수 있으며(예를 들면, 인테이크의 모든 컨텐츠는 https://i.intakefoods.kr의 도메인을 가집니다.) SSL 인증서를 적용 하여 모든 컨텐츠를 안전한 HTTPS 프로토콜로 제공 할 수 있습니다.

비동기 작업 처리/작업 스케쥴링

  • 비동기 작업 처리 : Celery
    쇼핑몰에 무슨 비동기 작업이 필요할까 의문을 품을 수 있지만, 실제로는 꽤 많은 비동기 작업에 대한 처리가 필요합니다. 사용자의 액션(주문완료 등)과 함께 작업이 실행되어야 하나 그 작업이 사용자의 경험에 해로운 blocking을 유발할 우려가 있는 작업들(eg. 외부 API와 I/O 작업이 필요한 Email/SMS/카카오 알림톡 발송), 실행 시간이 긴 작업(eg. 회원 대상 대량 SMS 발송) 등을 비동기로 처리하지 않을 경우 쇼핑몰의 매끄러운 운영에 상당한 방해요소가 될 수 있습니다.이러한 비동기 작업을 처리하기 위하여 python에서 가장 유명한 비동기 작업 워커 패키지인 Celery를 도입하였습니다.
  • 작업 스케쥴러 : Celery-beat
    또한 쇼핑몰을 운영하다보면 주기적으로 수행되어야 할 작업들 역시 많습니다. (eg. 매일 자정에 당일 매출 통계를 전 멤버한테 메일로 발송하기, 물류센터 API로 부터 자동으로 운송장 번호 가져오기, 특정 기간 동안 쇼핑몰 사용기록이 없는 회원 휴면 계정 처리하기, 매월 회원들의 구매 기록을 기반으로 회원 등급 평가하기 등)이러한 정기적 작업 스케쥴링을 위해서는 보통 리눅스의 crontab 등을 고려할 수 있지만, 위의 Celery 패키지에 포함된 celery beat가 이러한 작업 스케쥴러 기능을 제공하고 있어 해당 기능을 통해 작업 스케쥴러 기능도 Celery와 유연하게 통합하였습니다.
  • 메세징 큐(브로커) : AWS ElastiCache
    Celery와 같은 비동기 워커를 사용하기 위해선 메세징 큐가 반드시 필요합니다. 워커가 처리할 task들을 쌓아놓고 task의 처리 상태를 공유함으로서 다수의 워커가 중복된 task를 처리하는 일 없이 효과적으로 task를 처리 할 수 있습니다.Celery의 경우 기본적으로 RabbitMQ, Redis Amaon SQS, Zookeeper 등의 메세징 큐를 지원하지만 그 중 현재 가장 Stable 하게 지원되는 것은 RabbitMQ와 Redis 입니다. 저희는 그 중 상대적으로 좀 더 범용성이 있는(메세징 큐 이외에 캐싱 용도로도 효과적으로 사용 가능한) Redis를 선택하여 메세징 큐로 사용하고 있으며, 유지보수의 편의성을 위하여 AWS ElastiCache를 통해 호스팅된 Redis를 사용하고 있습니다.

버그 레포팅/운영

  • 버그 레포팅 : Sentry
    서비스 운영 시 발생하는 예상 밖의 exception이 발생하는 경우에 대비하기 위해 real-time crash reporting 도구인 Sentry 서버를 자체 구축하고, 해당 서버를 통해 live 서버에서 발생하는 exception이 발생할 경우 해당 내역을 자동으로 메일과 사내 커뮤니케이션 도구인 Slack으로 레포팅 되도록 하고 있습니다.
  • ChatOps : Slack
    ChatOps는 DevOps의 방법론 중 하나로, 메신저를 통한 사람의 명령에 따라 운영과 관련된 다양한 처리를 수행하고, 그 응답을 메세지 형태로 제공하는 ChatBot을 서비스 운영에 적극적으로 도입하는 것을 의미합니다.
    인테이크는 사내 업무용 커뮤니케이션을 위한 도구로 Slack을 사용하고 있으며, Slack API를 통하여 사용자의 명령에 응답 하는 ChatBot을 개발하였습니다. ChatBot은 사내 SCM 시스템, BitBucket, 버그 레포팅 시스템 등과 연계 하어 운영과 관련된 다양한 수치를 명령어 하나로 간단히 조회하고, 운영 시 발생하는 각종 이슈들을 해당 서비스에 직접 접속 할 필요 없이 Slack 상에서 담당자가 처리 할 수 있도록 구성 하였습니다.

이상 인테이크 서비스 스택에 대한 설명이었습니다. 이 글에 대한 피드백이나, 저희와 비슷한 환경에서 개발하시는 분들의 질문 등은 언제든 환영이니 아래 메일 주소나, 댓글로 연락 주시면 가능한 빨리 답변 드리도록 하겠습니다. 감사합니다.

dev@intakefoods.kr

스타트업/소규모 회사 사무실 네트워크 구축하기(1)

처음 부터 LAN 공사가 깔끔하게 되어 있는 사무실에 입주하면 가장 좋겠지만, 한 푼이 아쉬운 스타트업의 경우엔 그러한 사무실을 찾기가 쉽지 않다. 네트워크 등 사내 인프라를 전담하는 인력을 두는 것도 스타트업에선 쉽지 않기 때문에, 보통은 개발자(그 중에서도 서버 개발자)가 사내 인프라 관리 업무를 겸하게 되기 마련이다.

나 역시, 그러한 경우인데 워낙 장비를 다루는 걸 좋아하고 소싯적 산업기능요원으로 근무할때 IDC와 서버실을 뻔질나게 드나들었기에 어느 정도 자신이 있었다. 하지만 사무실에서 사용하는 장비가 늘어날 수록, 사무실에서 근무하는 멤버들이 많아질 수록 단일 공유기 위주의 네트워크 구성은 효율성과 안정성의 측면에서 어려움에 봉착하게 된다.

이 글은, PC/NAS/인터넷전화/무선 인터넷으로 구성된 사내 인터넷 환경을 구축하면서 얻은 교훈들을 스스로 정리하는 글이다.

인터넷 서비스 제공자(ISP) 선택

6인 미만의 멤버가 일하던 시절에는, LG U+의 가정용 인터넷/무선 인터넷 전화를 사용 하였으며 모든 멤버가 랩탑으로 업무를 보았기 때문에 공유기 하나에 모든 장비가 무선으로 연결되있는 어찌보면 깔끔한 환경이었다. 하지만, 업무의 효율성을 위하여 데스크탑을 도입하기로 결정하였으며 무선 인터넷 전화기의 연결이 불안정하여 간헐적으로 전화 수신이 잘안되는 문제가 발생, 대안을 찾기 시작하였다.

좋든 싫든 서비스의 퀄리티를 위해서는 메이져 3사(KT, SK Broadband, LG U+)의 서비스를 검토할 수 밖에 없었는데, 의외로 중소형 규모의 기업을 위한 기업용 인터넷 전화/인터넷 서비스를 제대로 제공하는 곳이 별로 없었다. 인터넷 서비스 제공자를 선택하는데 고려한 기준은 다음과 같다.

  • 기가비트급 인터넷 서비스를 제공 할 것 : 인터넷 기반의 사업을 하는 곳에선 그 업이 무엇이든 속도가 업무의 효율과 직결된다.
  • 기업용 인터넷 전화 서비스를 제공 할 것 : 일명 키폰 기능 – 대표번호 종속(eg. 1644-XXXX번호와 070 번호를 연결 시켜 주는 것), 돌려주기/받기, 통화 연결음 기능 등
  • 장치 접속 수의 제한이 없을 것 : 우리나라 ISP들의 고질병, 인터넷 접속 대수 제한. 가정용 인터넷 서비스는 컴퓨터 수가 좀 만 늘어나도 접속 대수를 제한 하는데, 인원수가 유동적으로 늘어나는 스타트업에선 매우 불편하고 비용 비효율적이다.

위와 같은 관점에서 고려하였을 때 3사 중 가장 나은 옵션은 KT라고 판단되어 KT 기업용 서비스를 신청하였다.(KT Giga 인터넷: 기업용 기가 인터넷 / KT Biz Centrix : 기업용 인터넷 전화)

KT 서비스를 사용하면서 얻은 노하우 몇 가지는 다음과 같다.

  • KT는 본사와 영업조직, 서비스조직이 모두 분리되어 있다 : 심지어 영업조직과 서비스조직은 KT소속이 아닌 제3사 하청 방식으로 되어있는 경우가 많다. KT 기업용 대표전화로 서비스를 신청하면, 신청 지역의 전화국에서 해당지역 영업 업체의 영업 담당자를 지정해주며 그 담당자가 상담을 위해 방문 한다. 영업담당자를 통해 서비스를 신청하면, KT 서비스 하청 업체에 소속된 설치 직원이 방문하여 실제 설치 서비스를 해주는 식.
  • 기본료와 약정 : KT의 기업용 인터넷 전화의 기본료는 전화기 기기값을 포함하여 회선당 월 3천원 수준으로 저렴한 편이다. 다만 3년 약정을 걸어야 저렴해지므로, 약정기간이 작은 회사 입장에선 다소 부담이 되는 편이다.
  • KT 기가인터넷 속도 : KT의 기가인터넷 서비스는 콤팩트와 일반으로 나뉘는데, 콤팩트의 경우 0.5Gbps, 일반의 경우 1Gbps를 속도 상한으로 한다. 우리 회사의 경우 일반 서비스를 신청했는데, 실제로 1Gbps의 속도가 나오는 것은 아니며 NIA의 인터넷 속도 측정 서비스를 통해서는 대략 720Mbps~760Mbps(업로드의 경우 800Mbps~860Mbps)의 속도가 나온다.(서울 동작구) CDN을 통한 대용량 컨텐츠 다운로드 통한 최고 속도가 대략 85Mb/s 정도.

http://www.speedtest.net/ 을 통한 속도 측정 결과 샘플

http://www.speedtest.net/ 을 통한 속도 측정 결과 샘플

사내 장비의 선택

기가비트급 네트워크에 대한 구축은 여전히 비싸다. Google을 필두로 기가비트급 네트워크에 대한 공급과 수요가 늘고는 있지만, 여전히 대부분의 네트워크 환경은 100Mbps급에 맞추어져있다. 공급과 수요가 충분치 않다는 것은 곧 장비의 가격이 높음을 의미한다. 기가비트급 네트워크 구축을 위해서는 아래 세가지 포인트에 대한 고려가 필요하다.

  • 공유기
    • 공유기는 연결된 기기 들에 대해 사설 IP를 부여하고 내부의 기기간 트래픽, 외부 인터넷 망으로 통하는 트래픽을 중계 해주는 역할을 한다.
    • 기가비트급 인터넷 환경을 제공하기 위해서는 당연히 공유기 역시 기가비트를 지원하여야 한다.
    • 공유기 자체의 하드웨어 성능
      • 연결된 장비가 많고, 많은 트래픽을 처리해야 할 수록 공유기의 성능이 중요하다. 연결되는 기기가 적다면 단지 가격이 저렴한 제품들을 구매해도 큰 문제가 없겠지만, 연결된 기기가 많을 수록 또 처리하는 트래픽이 커질 수록 공유기의 성능이 전체적인 네트워크 성능 병목이 되는 경우가 많다.
      • 사무실과 같이 연결되는 기기가 많은 환경에서는 내장된 CPU 성능이 좋고, 메모리 용량이 큰 10만원 이상의 고가형 제품을 선택하는 것이 좋다.
    • 무선 신호의 품질
      • 랩탑, 스마트폰 등의 사용이 많다는 것을 고려하면 무선 인터넷 신호의 품질 역시 신경써야 할 부분이다.
      • 우선 2.4Ghz/5Ghz 듀얼밴드 대역을 지원하는 공유기를 고르는 것이 좋다. 요즘 우리나라(특히 서울)는 어딜가도 통신사 와이파이, 가정용 공유기의 와이파이 신호, 다른 사무실의 공유기 와이파이 신호 등 수많은 신호들이 한 장소에 중첩되어 있기 마련인데 이러한 신호들은 대부분 표준 와이파이 신호 대역인 2.4Ghz 이며 결과적으로 자신의 와이파이 신호 이외의 신호들이 노이즈로 작용하여 무선 인터넷의 품질을 현저히 떨어 뜨린다. 이에 반하여 5Ghz 대역의 경우 상대적으로 사용하는 주변 신호의 수가 적고 또한 도달 범위가 좁기 때문에(주파수가 높아 회절이 잘 안됨) 간섭이 덜 한 편이다.
      • 와이파이 빔포밍 기술에 대한 지원 : 공유기가 와이파이 빔포밍 기술을 지원 할 경우 비교적 원거리에서도 무선 신호의 품질이 유지되기 때문에 사무실이 넓고 사각지대가 많을 수록, 해당 기술의 지원 여부도 따져보는 것이 좋다.
    • 위와 같은 조건을 만족하는 공유기 중 하나, D-Link 사의 DIR-868L

      위와 같은 조건을 만족하는 공유기 중 하나, D-Link 사의 DIR-868L

  • 스위칭 허브
    • 일반적인 공유기는 기본 제공 LAN 포트가 4~5개로 한정적이다. 따라서 그 이상의 장비들을 유선으로 연결하기 위해서는 스위칭 허브라는 다른 장비가 필요하다.(공유기 밑에 공유기를 또 다시 연결하는 방법도 가능하지만, 네트워크 구성이 복잡해지고 공유기에 비해 스위칭 허브의 가격이 더 저렴함)
    • 공유기? 스위칭 허브?의 차이점 : 공유기는 라우터의 일종이고 스위칭허브는 라우터와는 다른 역할을 한다. 어떻게 다른지를 이해 하려면 OSI 7 계층 모델에 대해 이야기하여야 하지만, 다소 추상적이고 이해가 쉽지 않다. 스위칭 허브는  쉽게 설명하자면 공유기 밑에 스위칭 허브를 연결 할 경우 공유기의 포트 수를 확장해주는 역할을 한다. 스위칭 허브에 연결된 기기들은 모두 공유기에 직접 연결된 것과 동일하게 공유기에 의해 관리된다.
    • 스위칭 허브 역시 기가비트급 장비를 선택하여야 스위칭 허브에 연결된 모든 장비들이 기가비트급 속도로 통신이 가능하다.
  • LAN케이블
    • LAN케이블은 다 같은 LAN케이블이다라고 생각하여 아무 케이블이나 고른다면, 기가비트급 장비를 다 갖춰놓고도 케이블에서 병목을 발생 시키는 꼴이다.
    • 카테고리 : 랜케이블은 규격에 따라 cat 5, 5e, 6 등으로 나뉜다. cat은 category의 약자이며, 숫자가 높을 수록 각 전선간 간섭 현상을 줄여 속도가 빨라진다. cat5의 경우 100Mbps 급 환경에서 일반적으로 사용되는 규격이며,  1Gbps 급 네트워크를 위해서는 cat6 케이블을 선택하여야 한다.

 

이 글에서는 기업용 인터넷 전화/인터넷 서비스를 위한 ISP 선택과 기가비트급 네트워크 구축을 위한 장비 선택에 대해 주로 서술하였다. 다음 글에선 실제 사내 네트워크 구성이 어떤 구조로 되어 있는지에 대해 서술할 예정이다.

 

정정 : 최초 작성 글에서는 cat5e 케이블을 사용할 경우 1Gbps 네트워크 구성이 안된다고 서술 되어 있었는데, 이는 잘못이다. cat5가 1Gbps 환경에서 사용 불가능하며 cat5e는 1Gbps 급 통신이 가능하다. cat6의 경우 1Gbps/10Gbps 통신이 가능하다. 

Kick Starter – Pebble2(페블2) 수령 및 Unboxing

최초 제품(Pebble Classic) 부터 프로그래밍 가능한 스마트 워치로 킥스타터에서 큰 인기를 끌었던 Pebble이 올해 5월, 킥스타터에서 새로운 제품인 Pebble2 펀딩을 진행한다고 하여 출시 다음날(5월 25일) 펀딩을 했다.

예전 제품군들도 관심이 갔지만, 이번 Pebble2를 펀딩하기로 마음 먹은 것은 무엇보다도 심박 센서(Heat rate sensor)가 탑재되었다는 점 때문이다. 자전거를 위해 원래도 별도의 심박 센서 제품을 살까 고민하였기 때문이다.

배송지연 – 수령까지의 타임라인

킥스타터 상에서 진행되는 하드웨어 프로젝트들의 고질적인 문제점이라고는 하지만, 이번 페블 프로젝트는 가장 최악의 예시라고 할 만큼 심각한 배송지연을 보여줬다.  5월 25일에 펀딩하여 11월 15일이 되어서야 제품을 수령하였으니, 결제부터 거의 6개월이 소요.

뭐 여러가지 이유가 있었겠지만, 나는 가장 큰 문제는 페블 팀의 잘못된 수요 예측에 있다고 본다. 6만 6천명이 이 프로젝트를 후원하고 모금액만 한화로 거의 150억원에 달하는 금액이 펀딩되었는데, 생산 설비는 정해진 기간과 수요를 따라 잡지 못한 듯 하다.

  •  9월 30일 : 당초 프로젝트 시작 시에 리워드가 9월 중 배송을 시작할 것이라고 공지.
  • 10월 1일 : 배송을 시작한다는 업데이트가 올라왔으나, Aqua 색상에 대해서만 배송이 시작되고 10월 1일부터 7일이 중국의 golden week, 태풍 메기로 인해 생산 및 배송이 지연될 것이라는 내용이 언급됨.
  • 10월 22일 : 다른 색상은 배송을 열심히 하고 있으나 여전히 Black과 Flame, Lime 색상은 생산이 완료되지 않은 것으로 공지됨. 10월 말까지 배송을 완료하겠다고 공지함.
  • 11월 2일 : 프로젝트 업데이트도 없고, 감감 무소식 이길래 항의 메일을 보냈으나 좀만 더 기다려달라는 답 뿐.
  • 11월 8일 : UPS로 부터 Shipping이 시작되었다는 메일을 받음
  • 11월 15일 : UPS 배송조회 화면에서는 며칠째 미국 국내 우체국으로 화물을 전달했다는 내용만 나오고 변화가 없기에 포기 하고 있었으나, 한국 우체국을 통해 배달 완료.

Unboxing

포장 상태

포장 상태

일반적인 뽁뽁이 봉투?에 포장이되어 배송되었다.

인보이스, 제품 박스

인보이스, 제품 박스

제품박스

제품박스

깔끔한 제품 패키징

제품 주의사항, 킥스터 Backer 스티커, 메뉴얼

제품 주의사항, 킥스터 Backer 스티커, 메뉴얼

패키지를 열어보니, 애플 스타일로 스티커가 하나 들어있었는데 킥스타터 Backer들에게만 지급되는 것인지는 명확치 않다.

본체, 충전기, 스트랩

스트랩, 본체, 충전기

구성품은 단순하다. 스트랩과 본체는 분리되어 있어서 직접 결합하여 사용하여야하는데, 결합 과정이 패키지의 안내 그림 처럼 쉽게 되지는 않았다.

최초 구동 화면

최초 구동 화면

최초 구동 시에는 무조건 스마트폰에 앱을 받아 페어링을 시켜야 한다.

심박 센서

심박 센서

후면에는 충전 단자, 심박센서가 위치한다. 킥스타터 로고도 있다.

첫 인상

아직 본격적으로 사용 해본 기간이 짧아서, 첫 인상만 간단히 남긴다. 자세한 리뷰는 1~2주 사용 해보고 작성 예정이다.

  • 타 스마트워치류에 비해 가볍고, 군더더기가 없다.
  • 페블 시리즈의 고질적인 문제점-기본 상태에서는 한글 지원이 안됨-은 여전하다. 페블2 4.x 버젼의 펌웨어에 대응 하는 한글 언어팩이 존재하는지도 미지수. 덕분에 휴대전화로 오는 알림이 대부분 깨져서 보인다. (수정 : 3.9 펌웨어용 한글 언어팩을 올려도 문제없이 한글 표시가 된다 : http://wh.to/pebble/wiki.php#.WC0sLrKLSUk)
  • 방수기능이 편리하다. 씻거나 잘때도 굳이 풀어둘 필요가 없다.
  • 심박 트래킹, 수면 트래킹이 생각보다 정확하다.
  • 스트랩이 광택처리 없이 표면이 부들부들한 타입이라서, 검정색 모델의 경우 먼지 등이 거슬린다.

Pebble App Store를 살펴보니 한국에 특화된 앱들은 거의 전무한 것 같아서 조금 더 사용해보고, Pebble SDK를 통해 직접 앱도 제작 해볼 예정이다.

어떤 회사가 기술 회사가 될때, 미친 밸류에이션이 된다.(When every company is a tech company, valuations go insane)

* Tech Crunch 기사 중, 인상적인 기사가 있어서 내용을 축약, 번역 하였다.

  • 미국에서 가장 트렌디하고 빠르게 성장하는 회사는 모두 기술 회사(tech company)라는 믿음이 만연해있고, 그러한 믿음으로 인해 요즘 뜨는 모든 회사들은 기술 회사로 어필되며(스스로 혹은 대중들에 의해서) 그를 통해서 미친듯한(insane) 밸류에이션을 받고 있다.
  • 얼마전 유니레버가 1조달러에 인수해서 화제가 된 Dollar Shave Club(면도기)을 비롯해서GoPro(카메라), Shack Shack(수제버거), Blue Bottle Coffee(프리미엄 커피) 등 소위 ‘잘나가는’ 회사들이 그들이 속한 비즈니스의 본질을 바꾸거나 혁신하지 않기 때문에 그들을 기술 회사라기보다는 전통적인 시장에 속한 하나의 브랜드라고 보아야 한다. (Many companies are not tech companies, they are brands.)
  • 때문에 이러한 회사들을 가치 평가 할때는 그 회사가 속한 시장 내의 경쟁 브랜드/회사를 살펴야지, 단순히 젋고 힙하다는 이유로 기술 회사에 대한 가치 평가에서나 적용 될 법한 “무언가를 이루어 낼 것이기 때문에(“it’s a tech company that happens to make x,”)이라던가, 혹은 지금은 세상이 달라졌으니 가능 하다는식으로 과도하게 높은 Valuation을 해서는 안된다.

원문링크 : http://tcrn.ch/2cNNq4k

윈마이(Yunmai) 미니 스마트 체중계 리뷰

날이 더워 여름이 지나는 동안 자전거를 세워만 두다가, 요 며칠 날씨가 좋아져 일주일 200km 목표로 다시 라이딩을 시작했다.

자전거 타는 일은 그 자체로도 즐거운 일이지만, 목표 없이 무작정 달리는 것은 개선이 없는 거 같아 그 성과를 측정 가능하도록 만들고 있다.

  • 라이딩 활동 : 페달링 속도(Cadence), 평균 속도, 상승 고도, 라이딩 코스 등 – Wahoo Cycling Censor + Strava
  • 몸 : 체중 – 일반 체중계

Strava는 러닝/사이클링 분야에서 가장 유명한 서비스이니 따로 말할 것이 없고, Wahoo Cycling Censor는 Bluetooth로 스마트폰과 연결되는 센서. Cycling Computer로 가장 유명한(그리고 비싼) Garmin과 비교 했을 때 편의성은 물론 부족하지만, Strava와 연결하여 사용하면 그런대로 쓸만하다.

체중의 경우 헬스장 등에서 일반 체중계를 사용할 기회가 있을 때마다 올라가서 측정하곤 했는데, 요즘엔 헬스장도 안다니고 일반 체중계로 측정하고 나면 잘 기록이 안되어서 본격적으로 자전거를 타기 시작한 기념으로 스마트 체중계를 하나 장만했다.

윈마이(Yunmai) 미니

스마트 체중계로 가장 유명한 것은 역시 샤오미 미스케일 이겠지만, 여러가지 스마트 체중계를 비교하면서 윈마이 미니로 결정. 윈마이는 샤오미와 동일하게 중국회사이며 제품의 디자인이나 어플리케이션 디자인이 여러모로 샤오미를 떠오르게 하는데, 아직까지는 스마트 체중계만을 전문으로 판매하고 있다.

윈마이를 선택하게 된 이유는 아래와 같다.

  • 체중 이외의 수치 측정 : BIA 생체전기저항측정법을 통해 근육량, 수분량, 단백질량, 내장지방량, 골격량 측정 가능
  • 어플리케이션 : UI 한글화, 일자별 수치 관리, 블루투스 페어링 편리성 등
  • 가격 : 기능은 유사 제품군 대비 많은 편인데, 가격 역시 저렴한편

실제 사용기

1234

포장 상태는 깔끔한 편이다. 패키지까지 한글화 되어 있는 것을 보면 수입사가 많은 공을 들인게 아닌가 싶다. 애플 패키지 스타일로 박스를 열면 제품이 가장 먼저 보이고, 그 밑으로 설명서와 함께 건전지가 동봉되어 있다.

0

제품의 모습. 윈마이 미니는 윈마이 제품 중에서도 가장 저가형 모델이고, 그만큼 본체의 플라스틱 재질이 오염이나 긁힘 등으로 부터 강해보이지는 않는다.(고가형 모델은 별도의 광택 처리 등이 되어 있는듯)

본체 위의 은색 원은 BIA 생체전기측정을 위한 전극이며, 체중 측정 시 저 위에 양쪽 발이 위치되도록 해야 한다.(양말 등을 신고 올라갈 경우 체중 이외의 수치는 측정이 안됨.)

0

사용법은 매우 쉽고 직관적이다.

  • 스마트폰 없이 올라가면, 체중계가 켜지며 체중계 자체의 LED에 몸무게가 표시된다.
  • 스마트폰에서 앱을 켜고 올라가면, 체중계가 켜지며 몸무게를 비롯한 여러 수치들이 측정되며 실시간으로 앱에 그 값이 표시되고 수 초가 지나고 나면 앱에 기록된다.

1

앱을 켠 상태로 측정하면 측정 시 마다 그 내역이 기록되며, 위 그림 처럼 일자별 변화 내역이 표시된다.

장단점

장점

  • 가성비
  • 미려한 UI/UX : 앱이 매우 직관적이며 편리하다. iOS에 탑재된 ‘건강’ 앱과 모든 데이터가 공유됨.

단점

  • 측정 수치 신뢰도 : 실제 몸이 좋은 걸 수도 있겠지만, 과거 인바디 측정 경험으로 미루어보아 체중 이외의 수치들에 다소 오차가 있어 보임(근육량, 체지방량 등이 실제보다 더 좋게 나온다) – 근데 뭐.. 인바디 측정 역시 정확도가 낮다고 하는 말이 있으니, 그냥 상대적인 변화에 대한 측정 용도로 사용하면 될 듯하다.

결론적으론 가격대비 만족이다. 사용한지 며칠 안되었지만 아침에 일어나면 체중계위에 샤워하기전 올라가는 것만으로 몸의 상태가 앱에 기록 된다는 점이 무척 마음에 든다. 이 체중계와 함께 올해 안에 건강한 방법(체지방량은 줄이고 근육량을 늘리는)으로 목표 체중 75kg에 도달하는 것을 노려보려한다.

Python/Django로 쇼핑몰 만들기

회사에서 한국판 소일런트라고 할 수있는 밀스(Meals) 홍보차 PyCon APAC 2016 후원 논의를 하다 여러가지 사유에서 결국 드랍하였고, 그냥 개인으로 참가 신청을 하였다.

참가 신청을 하고보니, 프로그램 목록에서 Django 로 쇼핑몰을 만들자 라는 발표를 발견했다. 이건 내가 3년째 하고 있는 일인데..?  마침 github에 발표 내용에 대해 분야별로 정리된 내용을 공유 해주셨기에, 이것을 기본으로 하여 스스로 정리차 내가 구축한 Intake(https://www.shopintake.com) 버젼으로 작성해 보았다.

필요 : 혼자 쇼핑몰을 만들어야 하는 상황이었고, 그래서 Python/Django를 골랐다.

이미지 파일 다루기

  • 스토리지 : AWS S3, CDN : AWS CloudFront
  • 이미지 리사이징 / 썸네일 : sorl-thumnail 패키지 활용
  • S3 Browser 통한 이미지 관리

배송 확인

  • 별도의 API를 사용하거나 만들지 않음
  • 대부분의 배송사들이 송장번호 기반의 배송 URL을 제공한다는 점에 착안하여 고객 송장번호를 URL에 삽입하여 해당 배송사 배송 확인 페이지로 바로 연결

이메일 발송

  • 가입, 회원등급 변경, 문의 답변, 결제완료, 마케팅 등에 사용됨
  • Mailchimp와 Mailchimp에서 제공하는 transactional email 서비스인 Mandrill 사용
  • 이메일 클라이언트에서 inline CSS(HTML 태그에 style attribute로 스타일 직접 추가하는 형태) 만을 지원하는 이슈가 있음, 하지만 Mailchimp는 해당 기능을 디폴트로 지원함
  • Mailchimp Automation 기능을 활용하여 쇼핑몰의 회원/구매기록 DB와 Mailchimp list를 연동, 다양한 상황에서 자동화된 메일링 발송(회원등급 변경, 장바구니에만 담기고 완료되지 않은 주문, 주문 후 N일이 지난 고객 등등)

결제

  • Intake(https://www.shopintake.com) 를 최초 구축하던 2년반전에는 아임포트 같은 아름다운 결제 API 서비스가 없었음
  • 당시 PG사들은 SDK로 JSP, ASP, PHP 등 기성 쇼핑몰 개발 주력 언어들만 지원하던 절망적인 상황
  • 이니시스 이니라이트 PHP SDK를 1:1로 Python으로 포팅하여 결제 환경을 구축함, 제한적으로 크로스브라우징 구현
  • 2015년 크롬 NPAPI 지원 중단 이슈로 인하여 이니시스가 기존 결제 플러그인 대신 ‘웹표준 결제 플러그인’을 도입함, 이 역시 이니시스의 난해한 개발 문서 읽으며 1:1로 Python으로 구현
  •  평소 자주 사용하던 서비스 중 하나인 토스(Toss)에서 결제 서비스인 토스페이(TossPay)가 출시되어, 빠르게 도입. 엄청나게 간편한 결제 API에 감탄.
  • 카카오 페이(KakaoPay) 역시 빠르게 도입, 카카오페이의 개발/운영 주관사는 다음카카오가 아닌 LG CNS. LG CNS에서는 Python 예제 코드를 제공하였으나, Java스러운 Python코드로 역시 해독이 어려움. 1:1로 Python 스타일로 라이브러리 변경
  • 아임포트 런칭 초기에 도입을 고려하였으나, 이미 구축한 legacy가 너무 많아 포기. 유지보수 이슈로 추후 도입 고려 중

관리자/통계 기능

  • raw-level의 모델 데이터 CRUD 작업 시에만 django admin 사용. django admin에 grappelli를 얹어서 사용
  • 주문관리, 회원관리, 제품관리, 매출 통계 등의 기능이 제공되는 별도의 관리자용 WebUI 구축
  • 관리자 페이지엔 회원 정보, 주문 정보, 매출 정보 등 민감한 사항이 많은데 간헐적으로 악의적인 로그인 시도가 감지되어, two factor authentication 으로 OTP(One Time Password) 도입. django-otp 패키지 사용 하였고, 구글에서 제공하는 OTP 앱인 google authenticator를 사용하여 관리자 페이지에 접근하는 모든 멤버들이 로그인 시점에 자신의 휴대전화를 통해 OTP를 제공받도록 함
  • django aggregation 활용하여 시간별(일간/주간/월간), 제품별(제품 카테고리/개별 SKU), 주문 유형별(PC, 모바일, 외부채널 등) 매출 통계, 회원 통계를 멤버들이 원하는 조건에 따라 조회 할 수 있도록 구현
  • 그래프의 경우 Google Chart 라이브러리 활용

CMS

  • 운영도 개발자가 할 것이 아니라면 쇼핑몰엔 기본적으로 상품 상세페이지/공지사항/이벤트 등 CMS(Contents Management System)이 필요함(쇼핑몰 운영하는 멤버는 HTML을 이해하지 못한다=.=)
  • Bootstrap 기반의 WYSIWYG 에디터인 summernote(django-summernote) 도입
  • 깔끔하고 사용하기 좋은 UI를 가지고 있지만, summernote가 생성하는 CSS는 깨끗하지 않고-일부 inline CSS가 쇼핑몰 자체의 CSS와 충돌을 일으키며 작성된 결과물이 표시될때 지저분하게 표시되는 문제 발생
  • django model signal 을 이용하여 저장 이후 summernote가 생성한 HTML검사하고 문제의 소지가 있는 inline CSS 들을 제거하는 기능 개발

디자인

  • 쇼핑몰 프론트엔드 디자인은 자체 디자인하여 퍼블리싱만 외주로 작업
  • 반응형 웹은 실제 사용자에게 큰 의미가 없다고 생각하여 PC와 모바일 별도로 디자인함

장바구니

  • 장바구니는 django-carton 패키지를 clone하여 수정 후 사용
  • django-carton은 자신이 구현한 Product Model을 장바구니 item으로 추가할수있고, 장바구니 추가/수량변경/삭제 등 기본적인 장바구니 기능이 구현되어 있음. 장바구니 정보는 session-base로 저장
  • 정보를 session에 저장하기 때문에  삭제 되면 안되는 장바구니 정보(회원 로그인 후 장바구니에 담은 물건) 가 휘발되는 문제 발생, 결제 완료 이전 장바구니정보를 JSON으로 serialize 하여 db에 저장하는 기능 추가 구현
  • 무료 배송,  구매 조건에 따른 사은품 기능 등을 쇼핑몰에서 추가로 요구되는 기능들 추가 구현함

주문 진행

  • 우편번호 검색의 경우 최초에는 우체국에서 제공하는 API를 Wrapping하여 사용하였으나, 한글 인코딩과 관련하여 자주 예상치 못한 변화가 발생하고 API 자체의 상태도 오락가락 하여 문제가 많았음
  • 다음 주소 API 공개 시점에 모든 주소 관련 API 를 다음 주소 API로 변경하였음

주문 모델

  • 카드/실시간계좌이체 의 경우 주문서 작성과 동시에 주문 완료 여부가 결정되므로 주문 완료 시점에 주문, 배송, 결제 정보, 주문 상품 정보가 담긴 모델을 생성
  • 가상계좌입금(무통장)/토스페이 등의 경우 주문 완료 시점과 결제 완료 시점이 다른 문제 발생, 주문 완료 시점에 카드/실시간계좌이체와 동일하게 모든 정보를 저장하되 주문 모델에 주문 상태를 추가하여 ‘입금 대기’상태로 저장함. PG사로 부터 입금 통보가 올 경우 결제 상태를 ‘결제 완료’로 변경하고 배송 시작.

비동기 작업/작업 스케쥴링

  • 쇼핑몰에 필요한 비동기 작업 : 사용자의 액션(주문완료 등)과 함께 작업이 실행되어야 하나 그 작업이 사용자의 경험에서 blocking을 유발할 우려가 있는 작업들(eg. 외부 API를 이용한 Email/SMS/카카오 알림톡 발송), 실행시간이 긴 작업(eg. 회원 대상 대량 SMS 발송)
  • 쇼핑몰에 필요한 작업 스케쥴링 : 주기적으로 수행되어야 할 작업들(eg. 매일 자정에 당일 매출 통계를 전 멤버한테 메일로 발송하기, 물류센터 API로 부터 자동으로 운송장 정보 가져오기, 특정 기간 동안 쇼핑몰 사용기록이 없는 회원 휴면 계정 처리하기, 매월 N일에 회원들 구매 기록 기반으로 회원 등급 평가하기 등)
  • Celery : Python 기반 비동기 Worker, Scheduler를 포함하는 패키지
  • 위 기능들을 Celery를 이용하여 구축하였으며 작업 queue로는 AWS ElastiCache 사용

배포

  • AWS ElasticBeanstalk 를 사용하여 git push 만으로 배포작업이 가능하도록 구성함
  • 기본적으로 특정 트래픽에 도달할 경우 자동으로 인스턴스를 추가하여 auto-scaling이 되도록 구성.
  • ElasticBeanstalk Config Script를 사용하여 새 인스턴스가 시작될때는 python package 이외(python package는 ElasticBeanstalk 이 requirements.txt 기반으로 자동으로 설치해줌) 에 필요한 Linux package를 설치하도록 구성함
  • AWS ElasticBeanstalk로 배포 할 경우 짧은시간(30초 미만) 동안의 서비스 downtime 이 발생함, 쇼핑몰 입장에선 심각한 수준의 downtime은 아님 -> 가급적 낮 시간동안엔 배포 안하지만, 심각한 문제의 경우 그냥 배포 진행
  • 올해 새로 출시된 AWS Certificate Manager 통해서 서버/CDN리소스에 대해 HTTPS 적용

운영

  • real-time crash reporting 도구인 Sentry 서버를 자체 구축하고, 해당 서버를 통해 live 서버에서 예상치 못한 exception이 발생할경우 해당 내역을 자동으로 메일, 슬랙을 통해 전송 하도록 함.
  • 사내 커뮤니케이션 툴로 사용 중인 슬랙에 Bot을 개발하여 연동함, 해당 Bot은 명령어를 통해 실시간으로 매출 통계 조회, 주문조회, 재고 조회 등이 가능하도록 함.

이외에도 자잘한 기능들이 많지만, 큰 맥락에선 이 정도로 정리가 되는 느낌이다. 쇼핑몰을 기반이 전무한 상태에서 직적 구축하다보니 우여곡절이 많았고 내가 이걸 왜 다 직접 만들고있나?(Why reinvent the wheel?)라는 생각도 들었지만, 결과적으로는 잘한 일이라는 생각이든다.  이미 존재하는 쇼핑몰 솔루션을 선택했더라면, 지금의 Intake와 같이 자유도 높은 쇼핑몰 운영은 아마 힘들었을 것이다.

* 글에서 언급한 패키지/서비스들이 참 많은데 아직 링크를 걸지는 못하였다. 차차 글 내용 추가와 함께 업데이트 예정.

SEO의 기본-검색엔진에 Sitemap.xml 제출하기

SEO, 검색엔진최적화

블로그 뿐만이 아니라, 내가 개발한 대부분의 웹사이트에서 중요시 여기는 것은 SEO(Search Engine Optimization, 검색엔진최적화)이다.

물론 네이버의 검색 점유율이 압도적인 한국에서는 (SEO=네이버 서비스에 컨텐츠 올리기)로 다소 변질 되었지만, 그렇다고 SEO를 할 필요가 없는 것은 아니다. 아무리 검색 결과 순위를 맘대로 매기는 네이버라고해도 SEO가 잘된 사이트와 그렇지 않은 사이트는 구분할 것이며, 사이트 규모가 커질 수록 네이버 뿐만 아니라 구글 등 다른 검색엔진을 통해 유입되는 트래픽이 늘어나기 때문에 SEO를 미리미리 잘해 두는 것이 좋다.

Sitemap을 제출하는 이유

이러한 SEO 작업의 기본 중의 기본(그렇지만 노력대비 효과도 좋은)은 검색엔진에 자신의 사이트 컨텐츠 중 크롤링 해야 하는 목록(sitemap)을 제출하는 것이다. 검색엔진은 기본적으로 웹 페이지내의 하이퍼링크를 찾고, 그 링크들을 통해 해당 사이트 내에 존재하는 웹페이지 목록을 알아내어 자신들의 검색 색인에 포함 시킨다.

웹사이트의 구성이나 내용에 따라서는 일부 페이지가 어떠한 하이퍼링크로 부터도 연결을 받지 못한 채 외톨이 상태가 될 수 있다. 뿐만 아니라 이 블로그와 같이 새로 생긴 웹사이트의 경우에는 그 웹사이트 자체를 가르키는 링크가 웹 상 어디에도 존재하지 않을 수 있기 때문에, 검색엔진이 사이트의 존재 자체를 알지 못할 수 있다.

sitemap은 이러한 문제를 해결하기 위한 용도로 고안되었는데, 간단히 원리는 약속된 특정한 양식을 통해 웹사이트의 운영자가 검색엔진에게 능동적으로 자신의 웹사이트 내에 존재하는 컨텐츠 들의 목록과 수정일, 변경 빈도 등을 알려주는 것이다.

Sitemap 만들기

sitemap은 미리 고안된 xml 양식으로 제작되어야 하며, 이 양식은 Google, Yahoo!, Microsoft(Bing)에 의해 지원된다. (Naver 등 국내 대부분의 검색엔진도 지원)

sitemap의 xml양식은 매우 간단한 수준 으로, 개발자라면 어렵지 않게 직접 개발도 가능하다. 하지만 검색 해보면, 대부분의 웹 개발 프레임워크에는 관련기능이 이미 구현되어 있고(eg. Django sitemap framework) WordPress에도 플러그인 형태로 이미 개발이 되어있어, 빠른 시간 안에 자신의 웹사이트에 sitemap.xml을 추가 할 수 있다.

아래는 이러한 방식으로 생성된 sitemap의 예이다.

http://www.foodb2b.kr/sitemap.xml (Django sitemap framework 사용)
http://54.150.211.139/sitemap.xml (WordPress Plugin 사용)

Sitemap 제출하기

이렇게 sitemap을 제작하였다면, 이제 제출 할 일만 남았다.

검색엔진에 따라 제출 방법이 다르지만, 우리나라 검색엔진 시장 특성 상 구글과 네이버  두개 검색엔진에만 제출 하면 충분하다.

구글은 웹서비스 운영자를 위한 검색 결과 최적화 도구인 구글 서치 콘솔(예전엔 구글 웹 마스터 도구 였음)을 제공하고 있고, 네이버도 얼마전에 이를 벤치마크 한듯한 네이버 웹마스터도구를 런칭하였다. 각 도구에서 sitemap제출 방법은 아래와 같다.

구글 서치 콘솔

  1. 구글 서치 콘솔 방문 후 본인 소유 구글 ID로 로그인
  2. 오른쪽 위 [속성 추가] 버튼을 클릭하여 추가하려는 웹사이트의 URL 추가g1
  3. Google Analytics, HTML 파일 업로드, Meta Tag 추가와 같은 방법으로 해당 사이트에 대한 본인의 소유권 증명
  4. 좌측 메뉴에서 [크롤링>Sitemaps] 클릭
  5. 우측 위 [SITEMAP 추가/테스트]버튼을 클릭하여 자신의 sitemap.xml url 입력
  6. [테스트]버튼을 누를 경우 해당 sitemap.xml에 오류가 없는지 점검해주며, 문제가 없을 경우 [제출]버튼을 클릭하여 제출g2
  7. 일정 시간이 지나면 위와 같이 sitemap.xml에 표시되는 컨텐츠 중 구글에 제출된 페이지가 표시됨

네이버 웹마스터 도구

  1. 네이버 웹마스터도구 에 네이버 ID를 통해 로그인
  2. 로그인 후 화면에서 [사이트 추가+] 버튼 클릭
  3. 프로토콜 및 URL 입력하여 사이트 추가
  4. HTML 파일 업로드, Meta Tag 추가와 같은 방법으로 해당 사이트에 대한 본인의 소유권 증명
    n1
  5. 좌측 [요청>사이트맵 제출] 클릭
  6. 표시되는 화면에서 자신의 sitemap.xml url 입력
  7. sitemap.xml 에 문제가 없을 경우 일정 등록이 되며, 일정 시간 이후 네이버 검색엔진에 의해 페이지가 수집됨