Make Company, Money, Code

ChatGpt가 연동된 New Bing 사용 후기

milC — Wed, 1 Mar 2023 18:25:33 +0900

You're in!

얼마 전 MicroSoft Bing에 ChatGpt가 도입되었다는 소식을 듣고 New Bing을 사용해보고 싶어서 대기명단에 등록을 해놨습니다.
그런데 오늘 제 차례가 되었다는 이메일이 도착했습니다.

차례가 되었습니다.

MicroSoft Edge 다운로드

New Bing은 MicroSoft Edge 브라우저에서만 사용가능하므로, 먼저 Edge를 다운로드 받습니다.
MicroSoft Edge Download 링크

Edge Download

각자의 환경에 해당하는 버전을 다운로드 받아서 설치하시면 됩니다.

Edge 실행

Edge를 실행하고, 대기명단에 등록했던 계정으로 로그인을 합니다.
일단 chatgpt를 검색해보겠습니다.

New Bing

우측에 못보던 요소가 생겼습니다. 답변이 나오기까지는 약 15초 정도가 걸리네요. 아직 속도는 개선이 필요한 듯 합니다.

Copilot 설정

스크롤을 위로 올려보니 Copliot을 설정할 수 있는 화면이 등장합니다.

Copliot 맞춤 검색

Copilot으로 검색해보기

건대 맛집 추천 으로 검색해보겠습니다.
빙이 답변을 해주는 군요.

도메인 정보 질문

ChatGpt는 웹 검색결과를 활용하지 못하기 때문에 한국에 맞춰진 정보나 실시간 정보들을 제공해주지 못합니다. 하지만 New Bing에서는 검색엔진과 융합되어 건대 맛집 추천과 같은 특정 도메인 정보, 실시간 정보도 정확하게 제공해줍니다.
답변에 링크가 함께 첨부되어 그 근거를 바로 알 수 있게도 되어있네요.

어느것이 가장 마음에 드냐길래, 제가 하나 픽 해봤습니다.

자연스러운 대화

ChatGpt에서 처럼 자연스럽게 대답을 해줍니다. 추가로 더 물어볼 수 있는 것들도 아래에 나옵니다. ChatGpt에서는 이러한 Domain-Specific한 주제로 이렇게 매끄러운 대화를 할 수 없었던 것에 비하면 웹 검색엔진과 합쳐진 ChatGpt가 꽤 독보적인 기능을 제공할 수 있다는 생각이 듭니다.

혹시 어디까지 되나 싶어서 주차가 되는지도 물어봤습니다. 주차 방법은 정형화되어있지 않아서 정리된 자료를 얻기 힘들기 때문이죠.

주차 가능 여부

답변은 놀라웠습니다. 주차 공간이 없다는 정보 뿐만 아니라 실제로 어떻게 주차를 해야하는지까지 알려주었습니다. 답변에 첨부된 링크를 클릭하면 해당 글이 적혀있는 블로그로 이동합니다.

이번에는 조금 더 세부적인 질문을 해보겠습니다.

좀 더 괴롭히기

이 답변에서 놀라웠던 점은 두가지입니다.

문장 형식으로 길게 이야기해도 핵심 검색 키워드로 요약하여 검색을 합니다. ("건대 개별룸 식당 6명 예약")
환이네 갈비살 근처라고 이야기했지만, 건대 근처로 키워드를 변환하여 훨씬 많은 검색 결과를 검토합니다.

하지만 아쉬웠던, 치명적인 한계가 여기에서 나왔는데요.

"건대 개별룸 식당 6명 예약" 키워드로 검색했을 때 나온 모든 식당을 적합하다고 판단한 것 같았습니다. Bing이 추천해준 3가지 식당은 실제 있는 식당이기는 하지만 건대에 있는 식당이 아닙니다. "건대"가 아닌 "개별룸" 키워드와 "예약" 키워드에 걸려서 나온 검색 결과입니다.
이와 같은 정보는 웹 사이트를 들어가서 사람이 검토해보면 쉽게 알 수 있는 오류이지만, AI레벨에서는 아직 거기까지 판단하기는 어려운 것으로 보입니다.

우측 하단에 동그라미가 초록색에서 주황색으로 바뀌어서 보여지는데, 최대 대화 길이인 6개에 가까워질 수록 빨간색으로 바뀝니다. 6개가 되면 기록을 지우고 이야기 해야합니다.

건대에 있는 식당으로 알려줘

이번에는 키워드를 약간 바꿔서 검색하긴 합니다.

조용한 주택의 경우 건대 근처에 있는 식당이 맞지만, 압구정역 근처라고 대답하네요. 민정 식당은 건대에 있는 식당이 맞지만 4~8인용 룸이 없습니다. 즉 잘못된 정보와 올바른 정보를 섞어서 제공하네요.
그리고 크롬 확장 프로그램 중 WebChatGpt 와 유사한 듯한 느낌도 받았습니다.
ChatGpt 확장 프로그램 Top3

아직 정확하지 않은 부분들이 있지만 검색 엔진과 융합된 ChatGpt의 잠재력을 볼 수 있었습니다. 텍스트 뿐만 아니라 이미지까지 분석하여 답변을 제공할 수 있다면 지금보다 훨씬 유용하게 활용할 수 있을 것 같네요.

리뷰 서비스 분석. 네이버 MY 플레이스

milC — Tue, 24 Jan 2023 19:08:39 +0900

네이버 리뷰 서비스 분석

이번에는 우리나라 검색엔진 점유율 1위인 네이버의 리뷰 서비스를 간단하게 분석해보고자 합니다. 네이버 MY 플레이스의 리뷰 방식은 계속해서 변하고 있는데, 변화하게 된 이유와 그 방향성에 대해서도 추측해보았습니다.

리뷰의 유형

1. 카드 내역

기존 영수증 리뷰에서 이제 카드 내역을 통해서도 리뷰를 남길 수 있도록 변경되었습니다.
카드 내역 리뷰가 추가된 첫번째 이유는 이제 영수증 데이터는 충분히 쌓였기 때문일 것입니다. 그래서 건당으로 지급하던 영수증 리뷰 리워드도 폐지하고, 적은 비용으로 다수를 동기부여할 수 있는 미션 제도로 변경했습니다.

두번째 이유는 네이버 파이낸셜의 성장입니다.

네이버 파이낸셜의 서비스인 네이버 페이가 높은 성장률을 보이고 있으며, 네이버의 캐시카우가 되었습니다. 네이버로써는 다른 서비스에서도 돈이 되는 곳으로 물길을 터고자 했을 것입니다. 네이버 플레이스의 UX에서도 이를 쉽지않게 엿볼 수 있습니다.

2. 영수증

1. 이런 곳 좋아요

리뷰 작성 과정 1

리뷰 작성 창에서 가장 먼저 유도하는 것은 이런 곳 좋아요! 버튼 클릭입니다. 별점이 아니라 마음에 드는지, 유사한 곳을 추천받을지를 물어보는 것입니다.

네이버 플레이스는 2021년 별점 시스템을 폐지하였습니다.

물론 별점 시스템은 직관적이지만, 네이버가 우리나라의 장소 검색을 거의 장악하다시피 해버린 상황에서 일부 악의적 소비자의 별점 테러는 가게에도 치명적인 영향을 끼치게 됩니다. 하지만 이것은 네이버가 별점 시스템을 내려놓게 된 결정적인 이유가 아닐 것입니다. 장소 리뷰 플랫폼에서 별점은 모두에게 당연한 시스템이었기 때문에 네이버의 시스템 탓을 하는 소비자는 많지 않았습니다.

별점을 폐지한 결정적인 이유를 추측해보려면 네이버가 돈을 어떻게 버는지를 생각해보면 쉽습니다. 네이버는 검색 플랫폼에서 가장 많은 매출을 창출하며, 그중에서도 중,소상공인들의 광고 매출이 가장 높은 비중을 차지하고 있습니다. 결국 쉽게말해 그들이 네이버의 돈줄이라고 볼 수 있죠.

그런데 기존 별점 리뷰 시스템에선 별점 1점짜리 악의적인 리뷰가 올라오면 화가난 점주가 네이버에 전화를 걸어서 리뷰를 내리라고 화를 내겠죠. 별점이 안그래도 상향 평준화되어있는 상황에서 1점짜리 평가는 가게에 치명적인 구조였기 때문입니다. 이렇게 소상공인들과의 얼굴 붉히는 관계를 오래 지속했다가는 네이버의 비즈니스 모델에 좋지 않은 영향이 있을 것이라는 판단이 네이버가 별점을 없앤 이유라고 생각합니다. 그래서 네이버의 리뷰 작성 UX를 보시면, 마치 원더랜드처럼 좋은 이야기만 끌어내려는 모습이 보입니다. 키워드에도 온통 장점만 가득하죠. 이 덕분에 네이버와 소상공인들의 관계는 조금 더 좋아졌을 지도 모릅니다. 물론 CS 비용도 많이 줄어들었겠죠.

다만 네이버는 아직 별점에 아직 미련을 깨끗하게 버리진 못한 것 같습니다.

아직 버리지 못한 미련

네이버가 봤을 때에도 별점이 직관적이고, 소비자들이 편리하게 가게를 고를 수 있는 좋은 수단이 되기 때문입니다. 물론 이것도 가게에서 직접 노출 여부를 선택할 수 있습니다. 그래서 별점이 낮거나, 생긴지 얼마 되지 않아 별점 리뷰가 쌓이지 못한 가게의 경우 별점이 노출되지 않는다는 단점이 있습니다. 그래서 소비자가 보기에는 다 좋아보이므로 가게의 변별력이 없고, 고르기가 매우 어려워진다는 문제가 생겼죠.

네이버에서도 이런 고민을 많이 한 모습을 엿볼 수 있습니다. 그게 바로 이런 곳 좋아요, 취향 기반 선호도 파악입니다.

A가게가 별점 1점짜리 식당이라서 100명 중 3명에게만 추천을 해준다면 A가게 사장님은 화가나서 네이버에 전화를 하겠지만, A가게를 좋아하는 사람과 유사한 취향을 갖는 3명에게만 추천을 해준다면 이건 A가게 사장님이 기분이 좋아질 일이죠. 소비자들도 만족할 가능성이 높습니다.

이젠 별점이 아니라 취향

네이버 MY 플레이스에서는 가게들도 사람들의 취향을 기반으로 묶고, 사람들의 취향 데이터를 수집하려는 다양한 시도를 하고 있습니다. 하지만 아직 검색서비스에서는 아직 별점을 놓지 못하고 있으며 취향에 따라 검색 결과가 다르지 않은 것으로 보아 (상단 광고 영역을 제외하고는 동일한 결과 노출) 아직 검색에 적용할 정도로 개인화가 되진 않은 것으로 보입니다. 사실 콘텐츠가 아닌 장소에 취향을 반영하여 유저가 만족할 만한 추천을 해줄 수 있을지도 아직은 미지수이죠.

다양한 OTT 서비스나 유튜브에서 취향에 맞는 추천을 해주는 취향의 시대가 온 만큼 네이버도 이에 따라가는 것으로 보일 수도 있겠지만, 네이버는 그것보다 훨씬 복잡한 소상공인과 소비자와의 줄타기를 하고 있는 것으로 보입니다.

2. 키워드 선택

리뷰 작성 과정 2

사용자의 선호도를 파악한 이후에는 장소에 해당하는 키워드를 선택하도록 합니다. 사용자가 피로감을 느끼지 않으면서도 최대한 유용한 정보를 뽑아내는 것이 목적입니다. 장소별로 다른 키워드들이 등장하며, 스크롤 압박을 주지 않는 가로 스크롤 형태로 피로감을 줄였습니다. 뿐만 아니라 별점 제도가 폐지된 이유에서 이야기했던 것처럼, 단점은 없고 장점들로만 키워드가 가득 차 있습니다.

리뷰 작성시에 키워드를 선택하면 네이버 지도의 리뷰 탭에서 정리되어 보여집니다. 다만 이러한 키워드를 네이버에서 별도로 분석하는지는 아직 확인할 수 없었습니다. 검색 결과에는 분석한 정보가 반영되지는 않았습니다.

예를 들어 "강남역 디저트가 맛있는 카페"를 검색했을 때, 리뷰에 "디저트"가 언급된 카페들을 보여주기는 했지만, 키워드 선택 결과와의 연관성은 없었습니다.

네이버 지도 키워드 요약

3. 리뷰 작성

리뷰 작성

리뷰 작성 창의 플레이스 홀더에서도 네이버 리뷰의 방향성을 볼 수 있습니다. 업주와 사용자들이 상처받지 않도록 리뷰를 작성하라고 적혀있습니다.

또한 하단 등록하기 버튼이 계속 활성화되어있습니다. 글을 작성하는 것은 꽤 피곤한 일이기 때문에 쉬운 것들을 위에서 끝낸 후 마지막에 할 수 있도록 숨겨두었고, 그것마저 귀찮은 유저를 위해서 등록하기 버튼을 바로 누를 수 있게 되어있습니다.

시간이 된다면 다른 리뷰 서비스들도 비교 분석하는 글을 작성해보겠습니다.

감사합니다.

AWS EC2 인스턴스 인바운드 IP 제한 상태에서 Github Action 배포

milC — Thu, 5 Jan 2023 00:19:59 +0900

AWS EC2 인스턴스 인바운드 보안 설정 상태에서 Github Action 배포 자동화하기

일단 먼저 인스턴스를 만드는 방법이 궁금하신 분들은
AWS 프리티어 인스턴스 만들기
에 자세하고 쉽게 설명해놨으니 살펴보시면 됩니다.

인바운드 규칙이란?

EC2 인스턴스는 누구나 접근 가능한 public IP를 부여받습니다. 하지만 모두가 접속할 수 있다면, 해커들로 인해 소중한 인스턴스가 너덜너덜 해지겠죠. 그래서 생성한 인스턴스에 접근할 수 있는 인바운드 규칙을 설정하게 됩니다.

인바운드 규칙이란?

집, 회사 컴퓨터 IP만 인바운드 규칙을 열어놓으면, 집과 회사에서만 인스턴스에 접근할 수 있죠.
RDS 보안그룹에서 인바운드 규칙을 설정하는 것도 같은 맥락입니다. 주로 RDS의 인바운드 규칙은 서버 인스턴스의 IP만 허용해놓는 경우가 많은데, 데이터베이스를 다른 IP에서 접근할 수 있도록 하면 DB가 남아나질 않을 것이기 때문입니다.

보안그룹 인바운드 규칙 설정

Github Action 활용

하지만 Github Action을 활용하여 배포를 자동화하기 위해서는 Github Action의 IP도 인바운드 규칙에서 허용해야하는데, Github Action의 IP는 계속해서 유동적으로 바뀐다는 것이 문제입니다.
이를 해결하기 위한 방법은 여러가지가 있지만, 가장 직관적이고 간단한 해결책을 적용했습니다.
바로 Github Action이 실행될때마다 IP를 얻어와서 보안그룹에 잠깐 동안만 추가하는 것입니다.

EC2에 도커 환경은 구축되어 있어도 되고 없어도 됩니다.
이런 식으로 Github Action CD 파이프가 실행됩니다.

적용한 코드는 다음과 같습니다.

name: remote ssh command for deploy
on:
 push:
   branches: [master]
jobs:
 build:
   name: Build
   runs-on: ubuntu-18.04
   steps:
   
     - name: Get Github action IP
       id: ip
       uses: haythem/public-ip@v1.2
       
     - name: Setting environment variables
       run: |
         echo "AWS_DEFAULT_REGION=ap-northeast-2" >> $GITHUB_ENV
         echo "AWS_SG_NAME=launch-wizard-2" >> $GITHUB_ENV
         
     - name: Configure AWS credentials
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} 
         aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} 
         aws-region: ap-northeast-2
     
     - name: Add Github Actions IP to Security group
       run: |
         aws ec2 authorize-security-group-ingress --group-name ${{ env.AWS_SG_NAME }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32    
       env:
         AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
         AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
         AWS_DEFAULT_REGION: ap-northeast-2
  
     - name: executing remote ssh commands using key
       uses: appleboy/ssh-action@master
       with:
         host: ${{ secrets.HOST }}
         username: ${{ secrets.USERNAME }}
         key: ${{ secrets.KEY }}
         port: ${{ secrets.PORT }}
         script: |
           ./deploy.sh
           
     - name: Remove Github Actions IP from security group
       run: |
         aws ec2 revoke-security-group-ingress --group-name ${{ env.AWS_SG_NAME }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32
       env:
         AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
         AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
         AWS_DEFAULT_REGION: ap-northeast-2

ubuntu18.04 (실행환경)이나 default_region등은 각자 환경에 맞게 설정해주시면 됩니다.
인스턴스 루트 디렉토리에 둔 deploy.sh 쉘 스크립트에는 필수적으로 이정도의 코드만 들어가 있으면 됩니다.

#!/bin/bash

cd ~/{프로젝트 경로}
git pull origin master
sudo docker-compose up --build -d // 1) docker-compose 사용 시
sudo npm restart // 2) 도커 없이 바로 돌릴 경우 설정된 npm 명령어 실행

이 부분을 지나면서 Github Action이 인스턴스에 접속하게되면 배포 파일을 실행해줍니다.

         script: |
           ./deploy.sh

secrets.{변수} 는 settings의 Secrets - Action에서 추가할 수 있습니다.

Action Secrets

궁금하신점은 댓글 남겨주시면 답변해드리겠습니다. 감사합니다.

유저가 '좋은 콘텐츠'를 제공하는 시스템 구축하기

milC — Sun, 23 Oct 2022 21:52:37 +0900

이 글을 쓰게 된 이유는 제가 Product Manager로 있는 플랫폼에서 더 양질의 콘텐츠가 올라오도록 하기 위한 방법을 고민하고 있기 때문입니다. 구체적으로 공개할 수는 없지만 저희는 리뷰 플랫폼이고 월 활성 사용자는 이번 달 기준 200만명을 조금 넘는 서비스입니다.
어떻게 하면 더 좋은 리뷰가 올라올 수 있도록 고민하다가 얻은 나름의 인사이트를 공유하고자 합니다.

좋은 콘텐츠가 올라오는 시스템이 중요한 이유

콘텐츠 플랫폼의 성패는 좋은 콘텐츠를 올라오게 하는 시스템이 얼마나 잘 구축되어있는지가 결정합니다.
따라서 모든 플랫폼은 어떻게 하면 좋은 콘텐츠가 많이 올라올 수 있을지, 좋은 콘텐츠를 어떻게 많은 유저들에게 보여줄지에 대해 고민하게 됩니다.

좋은 콘텐츠란?

어떤 플랫폼인지에 따라 '좋은 콘텐츠'의 기준은 다릅니다. 하지만 모든 좋은 콘텐츠는 공통점이 있죠.
바로 플랫폼에 돈을 벌어다주는 콘텐츠라는 점입니다. 플랫폼도 결국 사업 모델이기 때문에 모든 것은 매출로 이어지도록 설계됩니다.
물론 돈을 버는 방법은 플랫폼마다 다릅니다. 예를 들어 광고 수익이 주 수익원천이라면, 더 많은 광고를 보여줄 수 있는 콘텐츠가 좋은 콘텐츠가 됩니다. 만약 유저간의 계약 수수료가 주 수익 원천이라면, 계약을 잘 따낼 수 있는 유저가 좋은 콘텐츠가 됩니다.

시스템의 중요성

플랫폼 비즈니스는 일부 도메인를 제외하고는 진입 장벽이 낮은 분야입니다. 하지만 제대로 된 플랫폼을 설계하고 돌아가게 하기 위한 장벽은 매우 높습니다. 제대로 된, 다시 말해 돈을 잘 버는 플랫폼이 되려면 돈을 잘 벌 수 있는 시스템이 구축되어 있어야 합니다. 즉 돈을 버는 콘텐츠가 많이 올라오는 구조가 구축되어야 한다는 것입니다. 이 글에서는 그런 시스템을 구축할 수 있는 조건에 대해서 이야기해보고자 합니다.

YouTube, FaceBook, 커뮤니티 서비스에서는?

YouTube

유튜브의 수익 모델은 광고와 유튜브 프리미엄 결제입니다. 동영상 전, 후, 중간에 광고를 넣고 광고주로부터 돈을 받습니다. 이 광고가 귀찮은 유저들은 유튜브 프리미엄을 구독하게하고 이들에게는 광고를 노출시키지 않습니다. 유튜브가 돈을 많이 벌기 위해서는 사람들이 동영상을 오랫동안 봐야합니다. 유튜브의 수익은 유저들의 시청시간과 비례하여 증가합니다.
따라서 유튜브에게 좋은 콘텐츠는 많은 유저들이 오랫동안 보는 총 시청시간이 긴 동영상이고, 이런 콘텐츠를 제작하는 크리에이터에게 수익을 비례해서 배분합니다. 또한 시청시간이 길었던 동영상을 더 노출시키고, 사람들이 볼만 한 동영상을 상위에 노출시켰습니다. 이러한 시스템은 동영상 크리에이터와 유튜브의 목표를 일치시키는데 성공했습니다.

FaceBook

페이스북의 수익 모델도 유튜브와 동일한 광고 모델입니다. 하지만 다른 점이라면 콘텐츠 제작자에게 수익을 배분하지는 않는다는 점이죠.
대신 좋아요, 네트워크 효과, 노출 알고리즘 등을 활용하여 더 인기있는 콘텐츠를 많이 노출시키는 시스템을 구축했습니다. 페이스북에 콘텐츠를 업로드하는 사람들은 많은 사람들에게 콘텐츠가 닿기를 희망합니다. 그래서 유저들이 좋아할 만한 콘텐츠를 제작하여 업로드하게 됩니다. 그래야만 많은 사람들에게 노출될 수 있기 때문이죠. 물론 그 알고리즘에 대해서는 많은 논란이 있지만, 페이스북과 콘텐츠 제작자가 생각하는 좋은 콘텐츠의 관점이 일치한다고 볼 수 있습니다.

커뮤니티 서비스

네이버 카페, 디시인사이드 등은 전통적인 커뮤니티 서비스입니다. 이들 뿐만 아니라 대부분의 커뮤니티 서비스에는 사람들이 게시글에 추천 버튼을 누를 수 있게 되어 있습니다. 그리고 그러한 '인기글' 을 모아볼 수 있는 게시판이 있습니다. 당연하게 생각해왔지만 이것이 시스템입니다. 글을 작성하는 사람들은 많은 사람들이 글을 봐주길 희망하며 내 글이 큰 영향력을 갖기를 원합니다. 그래서 사람들이 좋아할 만한 글을 열심히 쓰는 것이죠.
그런데 만약 내가 열심히 쓴 글이 조회수와 추천 수도 보여지지 않고 대충 1-2줄 쓴 뻘글과 비슷한 영향력을 갖는다면 어떨까요? 아무도 열심히 쓰려고 하지 않을 겁니다. 콘텐츠 제작자가 원하는 바가 플랫폼에서 이루어지지 않기 때문이죠. 이런 플랫폼이 어딨겠냐 싶겠지만, 플랫폼이 '좋은 콘텐츠'가 어떤 것인지 정의하지 않거나, 좋은 콘텐츠를 분별하는 시스템이 마련되어 있지 않다면 당연하게 일어나게 될 결과입니다.

좋은 콘텐츠가 올라오는 시스템의 공식

위 사례들이 의미하는 것을 요약하면
1. 플랫폼은 어떤 콘텐츠가 돈을 버는 콘텐츠인지 명확하게 정의하고 기술적으로 구별해낼 수 있어야 한다.
2. 좋은 콘텐츠를 올리는 제작자들에게 성과에 비례한 보상이 돌아가도록 해야한다.
3. 그것이 플랫폼을 소비하는 유저들이 원하는 콘텐츠여야 하며 그런 콘텐츠를 더 많이 노출시켜야 한다.

라는 점 입니다.

플랫폼 성장 공식

위 세가지 조건을 모두 만족시켜야만 적절한 비즈니스 모델이라고 할 수 있습니다.
만약 새로운 플랫폼을 설계한다면, 위 공식을 역순으로 검토해보는 것이 적절합니다.

가장 먼저 플랫폼 소비자들이 우리 콘텐츠에 대한 니즈가 있는지를 점검해야 합니다. 초기에는 우수한 콘텐츠 제작자가 유입되지 않았을 수 있으니 직접 제작해서 확인해볼 수도 있겠죠.
니즈가 있다고 판단하면, 먼저 플랫폼에게 좋은 콘텐츠가 무엇인지 정의해야합니다. 어떤 콘텐츠가 많이 올라와야 플랫폼이 돈을 많이 벌 것인지 정의하고 이를 기술적으로 구분해낼 수 있는 방법을 찾아야 합니다. 그리고 그러한 콘텐츠가 소비자들에게 많이 노출되도록 시스템을 설계해야 합니다.
여기서 놓치기 쉬운 부분이 콘텐츠 제작자에게 적절한 보상을 제공하는 것입니다. 콘텐츠 제작자들이 콘텐츠를 제작함으로써 원하는 것이 무엇인지 파악하고, 플랫폼에게 더 좋은 콘텐츠를 만들어줄 수록 더 많은 보상이 돌아가도록 해야합니다. 이런 시스템이 구축되어야만 더 나은 콘텐츠 제작자들이 유입되고, 소비자들이 증가하는 선순환 구조가 만들어집니다.

실제 사례 적용

이제 지금까지 이야기한 것을 저희 서비스에 적용해보겠습니다.
먼저 서비스에서 유저들이 원하는 콘텐츠는 두가지로 구분할 수 있었습니다.

1. 믿을 수 있는 솔직한 리뷰 (실용적 가치)
2. 필력과 사진 실력이 뛰어난 사람들의 리뷰 (콘텐츠적 가치)

그리고 저희의 비즈니스 모델은 광고 모델입니다. 화면 노출 수와 광고 매출이 비례하는 모델이죠. 그렇다면 둘 중 어떤 콘텐츠가 우리에게 좋은 콘텐츠일지 정의하려면 각각의 화면 노출 수를 확인하면 됩니다.
위 두 리뷰 중 1번, 실용적 가치가 있는 리뷰는 대부분 상품정보 페이지에서 보여지고 있었습니다. 그리고 2번, 콘텐츠적 가치가 있는 리뷰는 피드(소식) 페이지에서 보여지고 있었죠. 이 둘의 비율을 확인해보니 1번 콘텐츠 화면 노출 이벤트 비율이 90% 이상이었습니다.
즉 실용적 가치가 있는 리뷰가 훨씬 저희에게 좋은 콘텐츠였죠. 하지만 저희는 어떤 콘텐츠가 더 실용적인 리뷰인지 구분하고 있지 않았습니다. 즉 전술한 '플랫폼에게 좋은 콘텐츠를 구별하는 것'이 이루어지지 않았던 것이죠.

현재 실용적인 리뷰는 웹에서 95% 이상, 앱에서 5% 이하로 노출되고 있었고, 좋은 콘텐츠를 구별하기 위해서 웹에서 각 리뷰 별 조회수를 기록하기로 하고, 좋아요 이외에 도움이 됐어요 등 다른 피드백 버튼을 추가하여 리뷰의 수준을 구별해 내기로 했습니다. 그 후에는 그 수준에 비례해서 리뷰 제작자에게 보상을 비례 제공하기로 했죠.

구체적으로 이야기를 할 수 없어서 조금 아쉽기는 하지만, 나중에 기회가 되면 그 결과와 함께 다시 포스팅하도록 하겠습니다.

Foowinkle MVP앱 개발 기록: 개발(2)

milC — Mon, 15 Aug 2022 23:00:37 +0900

시장에 있는 고객들에게 서비스로 배포하기 위해서는 클라우드 서비스를 활용하여 서버를 상시 가동시켜야만 합니다.

실제 회사에서는 어떤 클라우드 서비스를 활용할지 비용, 성능 등 다양한 기준으로 비교해보아야 하지만 저는 클라우드 관련 경험이나 지식이 없었기 때문에 가장 많이 활용되고 있고 관련 자료도 많은 아마존 웹서비스를 활용하기로 했습니다. 그리고 후일 다른 개발자분께서 합류하시면 AWS가 익숙할 확률이 높기 때문에 AWS 안에서 클라우드 서버를 모두 구축하였습니다.

AWS에서 활용한 서비스는 다음과 같습니다.

새로 계정을 만들어 프리티어 한도 안에서 활용하였습니다.

1. RDS (관계형 데이터베이스) - Mysql

2. EC2 - t2.micro

3. 로드밸런서 (설정만 하고 활용은 하지 않음)

4. SSL 인증

5. Route53

1. RDS

https://makethree.tistory.com/15

AWS migration 시리즈3. RDS 이전

프리티어 계정을 새로 만들면 기존에 있던 RDS도 이전해야한다. 기존 RDS에서 DB 스냅샷을 만들고 이를 새로운 계정으로 공유하여 이전하면 된다. 기존 계정의 RDS 에서 스냅샷 메뉴로 들어간다. 스

makethree.tistory.com

2. EC2

로컬 pem 파일 권한 설정 
chmod 600 ~.pem

접근
ssh -i "~.pem" ubuntu@{ec2인스턴스 주소}

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt-get install -y nodejs

npm -v, node -v 로 버전 확인

npm install -g express express-generator nodemon pm2

nginx 설치 경로 지정
sudo vi /etc/apt/sources.list
deb http://nginx.org/packages/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/ubuntu/ xenial nginx

source.list 내용 업데이트 되도록
sudo apt-get update
안되면
sudo apt-get install nginx

nginx 프록시 설정 (루트 포트 -> 3000번 포트 포워딩)

sudo vi /etc/nginx/sites-available/default

location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                # try_files $uri $uri/ =404;
                proxy_pass http://127.0.0.1:3000/; <- 추가
        }

sudo service nginx start

메모리 추가확보

sudo dd if=/dev/zero of=/swapfile bs=128M count=16

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

sudo swapon -s

sudo vi /etc/fstab
	파일끝에 추가
	/swapfile swap swap defaults 0 0

3. 로드밸런서 / SSL 인증 / Route 53

https://makethree.tistory.com/14

AWS Migration 시리즈2. 로드밸런서를 통해 https 적용하기

AWS에서 ssl 인증서를 발급받으면 도메인에 https://~ 로 접속할 수 있다. AWS에서 무료로 ssl 인증서를 발급받고 대상그룹과 로드밸런서를 생성한 뒤 http -> https 로 자동 리다이렉션 되도록 설정하는

makethree.tistory.com

AWS 프리티어 평생 쓰기 - Migration 시리즈 3. RDS 이전

milC — Mon, 15 Aug 2022 17:13:49 +0900

프리티어 계정을 새로 만들면 기존에 있던 RDS도 이전해야한다.
기존 RDS에서 DB 스냅샷을 만들고 이를 새로운 계정으로 공유하여 이전하면 된다.

기존 계정의 RDS 에서 스냅샷 메뉴로 들어간다.

스냅샷 생성 클릭

기다렸다가 스냅샷 생성이 완료되면, 스냅샷 공유 클릭

private 로 설정하고
AWS 계정 ID 입력

계정 ID

(계정 ID 는 AWS 우측 상단 메뉴에 있다.)

이제 새롭게 만든 계정(RDS를 이전 받을 대상)으로 로그인하여 RDS 메뉴에 들어간다.

스냅샷 -> 나와 공유됨 클릭
작업 토글 버튼을 클릭하고 스냅샷 복원 버튼을 누르면 스냅샷과 동일한 RDS 를 생성할 수 있게 된다.
프리티어 계정에서 무료로 사용하기 위해선 용량 20GB, t3.micro 사양으로 설정해야한다.

AWS 프리티어 평생 쓰기 - Migration 시리즈 2. 로드밸런서를 통해 https 적용하기

milC — Mon, 15 Aug 2022 01:42:55 +0900

AWS에서 ssl 인증서를 발급받으면 도메인에 https://~ 로 접속할 수 있다.

AWS에서 무료로 ssl 인증서를 발급받고
대상그룹과 로드밸런서를 생성한 뒤
http -> https 로 자동 리다이렉션 되도록 설정하는 것까지 다뤄보려한다.

ssl 인증서 발급

ssl 인증서는 AWS의 certificate manager 에서 발급받을 수 있다.

aws certificate manager

인증서 요청 클릭

퍼블릭 인증서 요청

완전히 정규화된 도메인 이름: *.example.com 입력 (인증서 적용하고자 하는 도메인)
DNS 검증 선택
태그는 입력할 필요는 없음.

AWS에서 도메인을 구입한 경우, AWS 로 도메인을 이전한 경우는 레코드 생성 버튼을 누르면 Route53 에 자동으로 CNAME 이름과 값이 등록되어 인증이 완료된다.
하지만 name.com 으로 구입한 도메인이므로 name.com 에서 설정을 완료해야했다.
도메인 관리 페이지에서 manage DNS 페이지로 들어간다.

CNAME 타입으로 설정하고, HOST 자리에 CNAME 이름 을 넣고, ANSWER 자리에 CNAME 값을 넣고 30분 정도 (개인 차 있음)
기다리면 인증이 완료된다.
그럼 https 인증서를 소유하게 된 것이다.

대상그룹 설정

로드밸런서는 트래픽을 여러 인스턴스로 분할해주는 역할을 한다. 하지만 프리티어에서는 인스턴스 하나까지만 무료이기 때문에.. ssl 인증서를 적용하는 데에 사용한다.
로드밸런서를 만들기 전에, 대상 그룹이라는 것을 먼저 만들어줘야 한다. 대상그룹이란 로드밸런서가 트래픽을 전달하는 대상 (인스턴스)의 그룹이다.
EC2 -> Target Group

Create target group

인스턴스 선택
+ 대상 그룹 이름은 원하는 대로 지으면 된다.

vpc 기본으로 설정, health check -> http

생성한 인스턴스 선택, 포트는 80번으로 설정

로드밸런서 설정

EC2 -> 로드밸런서

로드밸런서 생성 클릭

Application Load Balencer 선택

Listener 에 http(80), https (443)번 추가
둘다 이전에 만든 타겟 그룹으로 연결되도록 하기

로드밸런서가 프로비저닝이 끝나고 생성되면 Listener 를 편집해줘야 한다.

80번 포트로 들어오는 연결을 담당하는 리스너의 설정을 변경하여 https (443번 포트)로 리다이렉션 하도록 한다.

다음으로 80번 리스너의 규칙에 다음으로 리다이렉션 HTTP ~ 가 있으면 설정이 완료된 것이다.

AWS 프리티어 평생 쓰기 - Migration 시리즈 1. 도메인 이전

milC — Mon, 15 Aug 2022 01:09:51 +0900

MVP 개발을 위해 만들었던 프리티어 계정이 벌써 1년이 다 되어간다.
그리고 동시에 구입했던 도메인도 1년이 지나 갱신할 때가 되었다.
가비아에서 구입했던 도메인도 첫 1년은 500원이지만 연장하려면 5만원 이상 들기 때문에 도메인을 이전하기로 결정했다.
프리티어 계정도 AWS 계정만 하나 더 만들면 되기 때문에 굳이 비용을 지불하면서 현재 계정을 유지할 필요가 없다.
약간의 귀찮음만 극복한다면 마이그레이션은 나쁘지 않은 선택이다.
하지만 좀 많이 귀찮다.

이전해야(새로 만들어야)할 것들

1. 도메인
2. EC2 인스턴스
3. ssl, 로드밸런서
4. RDS
5. S3
6. CD - Github Action

이번 포스팅은 도메인 이전 과정을 적어보려 한다.

Git-hub 학생 계정을 활용하면 name.com에서 1년 치 도메인을 무료로 구입할 수 있다.
https://www.name.com/partner/github-students

Name.com: Free Domain for Students

You've been blocked from signing in for 30 seconds. Grab a cup of coffee and try again in a little bit. Have questions? - Check out our Knowledge Base for more information about two-factor authentication.

www.name.com

name.com

가지고 싶은 도메인을 저기에 검색하면 된다.
물론 .com .kr 같은 도메인은 무료로 주진 않는다.
구입 절차는 그리 어렵지 않기 때문에 따로 스크린샷을 첨부하진 않았다.

도메인을 구입했다면, 이제 남은건
EC2 인스턴스 만들기
ssh 접속해서 nginx 서버 구동하기
AWS 로드밸런서 세팅
AWS certificate로 ssl 적용 (https)
이다.

여기까지만 하면 기본적인 세팅은 모두 완료된다.

Product Manager 업무 정리 1. UX

milC — Sun, 24 Jul 2022 19:21:11 +0900

저는 현재 작은 규모의 IT 스타트업에서 Product Manager 로 근무하고 있습니다. 경력이 아직 짧아 직무에 대한 인사이트는 부족하지만 PM이 어떤 일을 하는지, 어떤 어려움을 겪는지에 대하여 제 경험을 기준으로 이야기하면 좋을 것 같아 글을 쓰게 되었습니다.

규모가 작은(10명 내외) 스타트업이지만 도메인에서 꽤 영향력있는 서비스라, MAU(월 활성 사용자)는 200만 명 가까이 됩니다. 의사 결정에 따른 임팩트는 결코 작다고 볼 수 없기 때문에, 큰 책임감을 갖고 일을 하고 있습니다.

작은 규모의 IT 스타트업의 PM은 다양한 부분에서 역할을 수행해야 합니다. PM의 업무는 회사의 특성마다, 규모마다 천차만별이겠지만 저희 회사에서 제가 맡은 업무는 5가지로 세분화할 수 있습니다. 물론 회사의 국면에 따라 추가적인 업무를 맡게 될 수도 있고 변경될 수도 있습니다.

제가 현재 맡고있는 업무입니다.

1. UI, UX 설계

a. 톤 앤 매너
b. UX 개선
c. UI 개선

2. 프로덕트 매니징

a. 일정 관리
b. QA (프로세스 관리, 지속적 트래킹)
c. 요구사항 전달 (to 개발자)
d. 중간 관리자 역할 (대표와 개발자 그리고 디자이너 간 의견 조율, 소통)

3. 브랜딩, 마케팅

a. 서비스 소개 작성
b. 마케팅 프로젝트 제안, 운영

4. 프로젝트 기획

a. 프로젝트 기획안 작성
b. 관련 서비스 케이스 조사 및 보고

5. 기타 업무

a. 개발자, 디자이너의 업무에 해당하지 않는 기타 프로덕트 관련 업무

이번 포스팅에선 1번 UI, UX 설계 업무를 간단히 소개해보고자 합니다.

1. UI, UX 설계

a. 톤 앤 매너

규모가 큰 회사라면 톤 앤 매너를 맞추기 위한 프로세스가 있지만, 작은 회사에서는 사람이 해야만 합니다. IT 서비스에서 고객과 커뮤니케이션하고, 브랜드의 일관된 이미지를 형성하기 위해 배너, 토스트 메시지, 팝업 메시지까지 하나 하나 많은 고민을 통해 결정해야합니다.
앱, 웹 서비스 안에서 사용자들에게 보여질 문구와 메시지를 구상하고, 디자이너, 대표님의 의견을 물어 결정한 뒤 정리된 문서를 통해 개발자분들에게 전달합니다.

b. UX 개선

회사 내부 구성원들은 오랫동안 제품을 다뤄왔기 때문에 제품의 구성에 매우 익숙합니다. 어떤 기능이 유저가 알아채기 쉽지 않은 어려운 위치에 있더라도 그게 어려운 위치라는 걸 깨닫기 어렵습니다. 그래서 디자이너와 함께 항상 유저 입장에서 서비스를 바라보려고 노력하며, 개선 사항이 생기면 바로 수정하거나, 조금 규모가 있는 사항이라면 대표님께 확인을 받아 수정합니다.

c. UI 디자인

제 옆자리에는 저희 회사의 유일한 디자이너분이 있습니다. 업무 중 누구보다 많이 소통하면서 더 좋은 UI가 무엇일지 고민합니다.
물론 실제 디자인은 디자이너께서 모두 하시지만 컴포넌트 중요도, 버튼 배치, UI 구성에 대해서 같이 고민하면서 고객에게 더 좋은 UX를 제공하기 위해 노력합니다.

회사 허락을 아직.. 받지 않아서 약간 두리뭉실하게 적을 수 밖에 없던 점 이해해주시면 감사하겠습니다 :)

Foowinkle MVP앱 개발 기록: 개발(1)

milC — Tue, 17 May 2022 23:15:14 +0900

기획 단계에서의 요구사항, 디자인 미션 등을 바탕으로 본격적인 개발에 착수하게 되었습니다. 이번 프로젝트에서는 Kotlin 프론트엔드 개발이 가능한 팀원분과 저 2명이서 MVP 개발을 진행하였고, 저는 백엔드 개발을 담당하게 되었습니다. 시장 가설을 검증할 수 있는 MVP를 어떻게든 만들어 내는 것을 목적으로 난생 처음 JavaScript 문법, AWS 클라우드 서비스도 배워가면서 진행했기 때문에 부족한 부분과 시행착오가 많았습니다. 읽어주시는 분들께서는 "아 저렇게 할 수도 있구나~" 정도로 가볍게 읽어주시면 감사하겠습니다.

개발 과정은 문과생인 저에게 모든 것이 난관이었기 때문에.. 어떤 난관들이 있었는지 설명해보면서 회고해보겠습니다.

프로젝트 관리

사실 두명이서 진행하는 프로젝트였기때문에, 그냥 좋은 게 좋은거지~ 카톡으로, 전화로 이야기하면 될 것 같다고 생각했었습니다. 하지만 실제로 프로젝트를 진행해보니, 바로 지난 주 회의에서 이야기했던 것도 가물가물해지고, 요구사항들도 따로 문서화 해놓지 않으면 서로 말이 달라 문제가 발생했습니다. 이러한 문제가 발생하자, 더 이상 기술부채가 생기지 않도록 하기위해 빠르게 노션으로 문서화하여 협업을 진행하기로 했습니다.

노션 협업 페이지

API 명세

프론트엔드는 안드로이드 Kotlin, 백엔드는 Node.js로 진행했고, 서로 각자의 영역만 각자 담당했기 때문에 사실상 대부분의 협업은 API문서를 통해 진행되었습니다. API 문서를 작성하고 활용하면서 느낀 점은

1. 들여쓰기, 제목(h1,h2,h3) 깊이 설정을 잘 해야 가독성이 높고 오해의 소지가 생기지 않는다.

2. 변수 타입, 설명만 보고는 이해하기 어려우니 샘플코드를 작성하는 것이 좋다.

3. API 수가 많아질 수록 찾기 어려우니 잘 분류를 해놓아야 한다.

라는 점입니다.

API 명세문서의 일부

전국 식당 데이터 확보

시장 가설을 효과적으로 검증하기 위해서는 갤러리에 있는 음식 사진들을 손쉽게 앱 내에 아카이빙 할 수 있도록, 사진만 올리면 식당 이름을 알려주는 기능이 필수적이었습니다. 뿐만 아니라 이 부분이 사용자들에게 다른 서비스가 제공하지 않는 "WOW moment" 가 될 것으로 생각했기 때문입니다.

사업계획서에는 공공 데이터 포털에 있는 식당 데이터를 확보할 것이라고 했지만, 공공데이터를 다운로드 받아서 확인해보니 여러 문제를 발견하였습니다.

문제 1: 공공데이터의 좌표계가 중부원점 좌표계(..난생처음 들었던 좌표계)였다. 사진에서 추출한 위치 좌표계(위경도)와 달랐다. 좌표계 종류가 이렇게나 복잡하고 많다는 사실을 처음 알았다.

문제 2: 전국 식당 DB를 받았더니 너무 크기가 커서 엑셀로 열리지도 않았다.

문제 3: 위치 좌표 정보가 없는 식당도 꽤 많이 있었다.

문제 4: 동일한 Row가 많았고 폐업한 식당도 상당 수 존재했다.

문제 5: DB는 다운로드 받은 그 당시의 정보라 시간이 지나면 다음에 같은 작업을 반복해야만 했었다.

초반부부터 예상치 못한 문제들이 닥쳐서 당황하기도 했지만, 곧 해결책을 찾고 DB를 구축했습니다.

문제 1 해결방법)

문제 1 ) 공공데이터의 좌표계가 중부원점 좌표계(..난생처음 들었던 좌표계)였다. 사진에서 추출한 위치 좌표계(위경도)와 달랐다.

구글에서 중부원점 좌표계 -> 위경도 로 변환하는 엑셀 수식 파일을 받아서 모든 Row에 적용했습니다.

자동 변환해주는 사이트도 있었지만, 속도가 너무 느리고, 횟수제한이 있어 활용하지 않았습니다.

하지만 엑셀 파일로 변환 결과를 구글 맵에 찍어보니 정확한 좌표가 나오지 않았습니다. 그래서 결과 좌표값을 몇개 더 구글 맵에 찍어보니 모두 오차가 비슷하게 나타나서, 변환 수식에 오차를 적용한 새로운 수식을 작성하고 새로운 수식으로 변환했습니다.

문제 2 해결방법

문제 2) 전국 식당 DB를 받았더니 너무 크기가 커서 엑셀로 열리지도 않았다.

터미널에서 "split -l 1000000" 으로 csv 파일을 분할해서 엑셀로 연 후 작업했습니다.

문제 3 해결방법

문제 3) 위치 좌표 정보가 없는 식당도 꽤 많이 있었다.

위치좌표는 없었지만 도로명주소와 지번주소는 가지고 있었습니다. 이를 위경도 좌표로 변환해주는 구글 스프레드시트 API인 지오코딩 을 활용하여 하루 무료 API 제한량 10000개씩을 매일 변환했습니다.

문제 4 해결방법

문제 4) 동일한 Row가 많았고 폐업한 식당도 상당 수 존재했다.

엑셀에서 필터를 적용하여 폐업한 식당의 Row를 삭제했고, 동일한 Row의 경우는 DB에 삽입하는 과정에서 삭제되도록 했습니다.

문제 5 해결방법

문제 5) DB는 다운로드 받은 그 당시의 정보라 시간이 지나면 다음에 같은 작업을 반복해야만 했었다.

공공데이터를 Foowinkle의 DB로 변환하는 과정을 문서화했습니다. 또한 최종 수정일자 컬럼을 추가하여 다시 공공 데이터를 다운로드 받으면 최종 수정일자가 마지막 DB 갱신일자 이후인 식당만을 추가하도록 했습니다.

DB 가공 프로세스 중 일부

DB 설계

draw.io

이 데이터베이스 명세는 기획 단계에서 설계했던 기능들이 추가되면서 변경된 최신 버전입니다.

DB 를 설계하면서 가장 어려웠던 부분들은

1. DB 테이블간의 외래키, 관계 설정

2. 어느정도의 종속을 허용할 것인지 결정하는 것

처음에는 마냥 외래키를 많이 걸어서 테이블끼리 관계가 견고해지면 좋은 DB인줄 알았습니다. 하지만 외래키가 걸려있다는 것은 삭제와 수정에 제한이 걸린다는 뜻이라 마냥 많이 엮어놓는 것만이 능사는 아니었습니다. 꼭 필요하지 않은 관계는 굳이 연결시키지 않는 것이 빠른 개발 프로세스에는 도움이 되기도 했습니다. 물론 나중에 서비스가 견고해지면 테이블 간의 관계를 엮고 견고하게 만드는 것이 중요한 일이 될 수 있겠지만요.

그리고 식당테이블의 갯수가 몇십만개가 되다보니, DB 탐색에서의 속도를 고려할 수 밖에 없었습니다. 따라서 각 INDEX를 설정해놓아 탐색 속도를 높였습니다. INDEX를 설정하면 삽입과 삭제, 수정하는 속도는 늘지만 탐색하는 속도는 빨라지기 때문에 수정과 삭제가 수시로 일어나는 것이 아닌 식당 정보 테이블에서는 INDEX를 설정하는 것이 여러모로 옳은 결정이었습니다.

다음 글에서는 난생처음 AWS로 서비스를 구축했던 방법과 겪었던 시행착오들을 회고해보겠습니다.