배민의 숨은 디테일

배달의 민족에서 특정 가게를 링크로 공유하면, 위와 같은 형태로 미리보기 이미지가 나타난다. 개인적으로 가장 소름 돋았던 배민의 숨은 디테일이었다.

웹 개발을 모르는 사람이라면 사이트 내용을 미리보기로 띄워주는 건가? 라고 생각할 수 있다. 하지만 실제 저 링크로 들어가 보면, 저 이미지와 텍스트들은 찾아볼 수가 없다. 이것은 페이스북이 만든 Open Graph라는 규약을 통해 실제 홈페이지에 있는 이미지, 텍스트와 별개로 URL을 공유하는 과정에서 미리보기를 제공하는 것이다. 대부분의 SNS, 채팅 서비스에서 제공하고 있다 (페이스북, 디스코드, 카카오톡, 슬랙, 트위터 등).

웹페이지를 기획/개발하다 보면 홈페이지의 기능이나 디자인, 사용자 경험에 신경 쓰느라 SEO나 Open graph는 놓치기 쉽다. 하지만 위의 배민 사례를 살펴보면, 그냥 지나갈 수도 있었던 음식점 공유 슬랙을 한 번 더 보게 만들어줄 만큼이나 강력한 도구라 생각한다. 그래서 이번 고초대졸닷컴 리뉴얼에 있어서 신경 썼던 부분 중 하나가 바로 OG 이미지였다. 카카오톡으로 우리 사이트의 공고가 많이 공유되기도 하고 블로그를 통해 공고를 올리기도 하기 때문이다.

배민의 아이디어를 본떠 팀의 디자이너분께 따로 쓸 수 있는 이미지를 요청했다. 현재는 공고를 카카오톡으로 공유하면 아래와 같이 미리보기 이미지와 문구가 노출된다.

하지만 카카오톡의 경우, 전체 CSR을 하는 경우 OG를 잡지 못하는 문제가 있었다. 처음 배포 당시에는 배포 기간을 맞추느라 페이지 구분 없이 모두 CSR 형태로 개발하였었고 위의 미리보기가 작동되지 않았다. 지금은 SSG와 CSR을 함께 사용하면서 OG가 정상적으로 작동하고 있다. 아직 기업 정보의 경우에는 SSG가 적용되지 않았지만, 아래와 같은 이미지를 넣어두었다.

디스콰이엇 메이커로그의 경우에는 메이커로그에 이미지가 있을 경우 해당 이미지를, 없을 경우 디폴트 이미지를 OG image로 넣고있는 것으로 보인다!

hhttps://assets.disquiet.io/images/new-og-image.jpg

경쟁력있는 오픈채팅방 운영방법

오픈채팅방 운영 방안에 대한 @염현성 님의 게시글에 답글을 달면서, 그동안 고초대졸닷컴의 오픈채팅방을 어떻게 운영했는지 정리해보게 되었습니다.

(본 게시글 : https://disquiet.io/@yomon/makerlog/3146)

저희는 본 아이템인 생산직 채용플랫폼 고초대졸닷컴과 함께, 생산직 채용 정보를 나눌 수 있는 오픈 채팅방을 운영 중입니다. 작년 8월 아이템 출시와 동시에 시작하여 지금까지 1년이 넘게 오픈채팅방을 유지해오고 있고, 현재 약 1200명의 구직자/이직자/현직자분들이 실시간으로 활발하게 이용하고 계십니다! 처음에는 마케팅 목적으로서 시작했지만 현재는 저희 아이템의 아이덴티티로서 자리 잡은 것 같아요. 오픈채팅방은 최근 다양한 스타트업들이 활용하는 수단이기도 하고, 잘 활용한다면 꽤 비싼 가격으로 이용해야 하는 카카오 채널 메시지를 대체할 수 있는 수단이라고 생각합니다. 저희가 한 것이 무조건 답은 아니겠지만, 오픈채팅방을 처음 운영해보시는 분들께 조금이나마 도움을 드리기 위해 고초대졸닷컴이 활용했던 오픈채팅방 운영 방식을 더 상세하게 공유해 드리고자 합니다!

전체적인 운영방식

1. 반말을 사용하여 대화를 꺼내고, 질문을 하는 데 있어 높은 허들을 낮추었습니다
2. 존대를 사용하는 채팅방과는 확실히 분위기가 다르다고 생각합니다. 정말 가볍게 질문을 꺼낼 수도 있고, "나 오늘 힘들다" 또는 "일하기 싫다" 같이 사소한 얘기까지도 오고 갑니다!
3. 단 여기에서 반말은 낮춤말이 아닌 '평어'로 상대방을 비난하거나 낮추는 말은 허용하지 않습니다.
4. 방장/부방장을 통해 닉네임 규정 또는 대화 규정을 지키지 않는 분들을 즉각적으로 강퇴하고 있습니다.
5. 이를 통해 자유롭지만 통제된 환경을 만들고자 하였습니다. (부방장의 경우 저희 팀에서 관리하는 것이 아닌, 초반부터 톡방에서 활동하시던 실제 유저분들이십니다. 활동을 열심히 하시고 잘하시는 분들께 드렸습니다)
6. 닉네임 규정 같은 경우 각 구직자의 특징을 아는 데 도움이 되기도 합니다. 일종의 제로 파티 데이터의 역할을 하게 됩니다.
7. 또한 지극히 개인적으로는 "닉네임 규정"의 경우 그 자체의 의미보다 부방장에게 권력을 주기 위한 도구로서의 의미가 더 크다고 생각합니다. "닉네임을 지키지 않으면 부방장이 강퇴를 한다"라는 사실이 부방장의 권력을 만들게 되고, 톡방 질서에 영향을 준다고 생각합니다.
8. 부방 분들과, 톡방에서 활발하신 분들을 따로 분리하여 코파운더와 함께 "스태프 톡방"을 두고 있습니다.
9. 약 15분이 있으시고 가끔 부탁을 드리거나 중요한 질문을 드릴 때 사용하고 있습니다.
10. 스태프 톡방은, 톡방 이용자가 많아지면서 1대1로 물어보기 힘든 질문을 드리거나 톡방의 운영 방향성을 제시해드리는 목적으로 사용하고 있습니다.
11. 또 톡방 운영에 힘써주시는 만큼 스태프분들께는 선물을 보내드리거나 따로 감사 인사를 드리기도 합니다.
12. 매일 통일된 시간대에 "오늘의 채용공고"라는 고정 콘텐츠를 올리고 있습니다.
13. 초반에는 이것 때문에 유입되신 분들도 많이 계셨습니다.
14. 콘텐츠가 종종 올라오는 것과 고정된 콘텐츠가 주기적으로 올라오는 것은 다릅니다. 주기적이고 고정된 콘텐츠는 톡방의 정체성이 되고, 톡방에 들어오는 목적이 되기도 합니다.
15. 고정된 콘텐츠의 경우 업로드 시간이 됐을 때 톡방 이용자들에게 기대감을 주게 되며, 우리 톡방의 하나의 특징으로 자리 잡게 됩니다. 업로드가 늦으면 "오늘은 공고 안 올라오냐?" 와 같은 반응을 볼 수도 있습니다.
16. 4번의 콘텐츠를 좋아하시던 분들은, 톡방 규모가 커짐에 따라 (500명 초과) 콘텐츠만을 따라가지 못하고 많은 대화량에 지치기도 하셨습니다. 그래서 하루에 딱 한 번, "오늘의 채용공고"만 올라오는 조용한 카톡방을 추가 개설하였습니다.
17. 닉네임이나 다른 규정은 하나도 없으며, 단순하게 "채팅 금지"의 단 하나의 규칙만을 두고 있습니다. 채팅 시 즉시 강퇴됩니다. (체감상 평균 강퇴 시간 5초)
18. 현재는 이 톡방의 경우에도 1200명의 이용자를 보유하고 있습니다.

초반 (~100명)

1. 코파운더들이 모두 들어가서 생산직 구직자인 것 처럼 활동했었습니다.
2. 톡방에 대한 일종의 온보딩 과정으로 질문이 올라오면 구글링을 계속해서 비슷한 답이라도 보내드렸습니다.
3. 초반에는 이에 대한 만족도가 꽤 높았습니다. 버려지는 질문이 하나도 없도록 모두 다 답변했었습니다.
4. 사실 당시에는 생산직 분야에 대한 전문지식이 없었지만, 구글 검색으로 어느 정도 커버할 수 있었습니다.
5. 3~40명까지는 정말 유저가 천천히 늘었던 것 같습니다.
6. 한명 한명 유저의 목소리를 다 들었고, 실제 취업까지 성공하신 분을 축하하기도 했었습니다.
7. 그러다 어느 순간 한 분께서 톡방이 너무 마음에 드신다며 본인이 계신 다른 톡방에 홍보하셨고 100명까지 하루 만에 증가했던 것 같습니다.

중반 (~500명)

1. 이때부터는 유저가 급속도로 늘기 시작했습니다.
2. 이때부터는 톡방의 규칙을 확고히 했었고, 유저 제한을 두기 시작했습니다.
3. 즉 500명까지 계속해서 유저를 받은 것이 아니라, 100명 제한을 두고 100명을 받은 뒤 톡방이 잘 운영되면 200명으로 늘리고, 다시 200명이 차면 닫고 운영하는 식으로 500명까지 천천히 증가했습니다.
4. 한 번에 늘리지 않고 운영을 해가며 늘리는 방식이 QC의 측면에서 좋았던 것 같습니다.
5. 톡방 인원에 제한이 있었기 때문에 채팅이 적은 유저를 특정 주기로 강퇴(물갈이)하는 작업을 진행하기도 했었습니다.
6. 활동을 열심히 해주시는 톡방 유저분께 부방장을 드렸고, 방장봇을 잘 활용하기 위해 노력했습니다. 또한 앞서 설명해 드린 부방장 톡방을 파서 톡방을 관리할 수 있게 노력했습니다.
7. 랜덤 선물 추첨이나 선착순 선물 추첨 등의 기능을 종종 사용하기도 했습니다. 또 톡방에서 유저 테스트나 설문조사를 진행하고 보상을 드리기도 하면서 커뮤니케이션 했던 것 같습니다.
8. 톡방 담당을 하는 팀원을 확실히 정하여 관리하였습니다.

후반 (~1000명 이상)

1. 대화 수가 상당히 많기 때문에 주제별로 더 깊은 얘기를 나눌 수 있는 카톡방을 동시에 운영하였습니다.
2. 예를 들면 "SK 하이닉스 취업 준비방", "포스코 취업 준비방" 등, 같은 목적을 가진 분들이 얘기를 나눌 수 있는 방을 개설해드렸습니다.
3. 주제별 추가 채팅방에서는 항상 '[고초대졸닷컴 운영]' 이라는 일종의 품질 보증 타이틀을 유지하였고, 반말이 아닌 존댓말을 사용하면서 진지한 얘기가 오고 갈 수 있게 노력하였습니다.
4. 앞서 말씀드린 '공고방' 을 추가 개설하면서, 잡담 필요 없이 정보만 얻을 수 있는 방을 운영하였습니다.
5. 현재는 1150명대의 본방보다 더 많은 1250명대를 유지하고 있습니다.
6. 유료로 메시지를 보내야 하는 카카오 채널과 달리, 무료로 공지사항이나 정보를 유저들에게 바로 보낼 수 있습니다.

정리

1. 대부분 익명으로 진행되는 만큼 톡방의 취지와 방향성을 확실하게 정한 뒤 그에 맞춰 톡방의 규정을 잘 정립하면 좋을 것 같습니다.
2. 초반에는 시간이 뺏기더라도 확실한 QC와 "주기적인 콘텐츠" 가 운영에 있어 중요한 요소라고 생각합니다.
3. 오픈채팅방은 잘 사용한다면 카카오 채널 플러스 친구에게 보내는 메시지 비용을 절약할 수 있는 좋은 마케팅 수단이 될 수 있다고 생각합니다
4. 카카오에서는 올해 오픈채팅방을 통한 수익화를 시작하기도 했습니다. 오픈채팅방의 활용은 앞으로 무궁무진할 것이라 생각합니다.

웹페이지 간단하게 분석해보기 - 에브리타임

웹페이지 간단하게 분석해보기 — 에브리타임

에브리타임 pc 버전을 간단하게 분석해보았다

FE 개발환경으로는 Node.js — Express 와 Vue 그리고 jQuery 가 이용되었다.

기본적인 css 파일이나 로고 이미지, 기타 아이콘 이미지의 경우 홈페이지와 같은 도메인(everytime.kr)의 서버내에 파일로서 보관하고 있었다. 게시판 옆에 뜨는 작은 원의 경우에는 따로 파일이 아닌 하드코딩된 svg를 이용하고 있다.

광고 이미지의 경우 다른 서버를 통해 별도의 서브도메인을 활용하고 있었지만, 파일 명의 경우 path로 구분되지는 않았고 이미지 파일명에 게재 날짜를 같이 저장해서 보관하고 있었다. 프로필 디폴트 이미지도 또 다른 서버로 별도 서브도메인을 활용하고 있었는데, 아마 따로 프로필 이미지를 설정하는 유저가 있는 경우 이를 동적으로 처리하기 위해서 분리를 해둔 것으로 보인다. 게시글에 업로드된 사진의 경우에도 당연히 또 다른 서버 및 서브 도메인을 사용하고 있으며 세 서버 모두 AWS 의 S3 및 cloudfront 를 사용하고 있었다.

백엔드도 또한 추가 서버를 이용하고 있었고 Express 로 개발된 것으로 보인다. JSON이 아닌 XML로 정보를 주고 있으며, 로그인의 경우에는 FE 서버에서 처리한 뒤 FE 의 쿠키로 백엔드에서 인증을 구현해둔 것 같다. 특이한 점은 게시글 조회 API 에 대해서 GET이 아닌 POST 메서드를 사용하고 있다.

데이터 분석으로는 구글과 네이버 애널리틱스를 사용했다. 몇몇 페이지를 확인해봤지만 GA에는 pageview 이외의 별다른 커스텀 이벤트는 찍히지 않았다.

모바일웹 도입과 SEO

지난 10월 14일, 고초대졸닷컴의 리뉴얼 페이지가 배포되고 1주일이 지났다. 6개월이라는 긴 기간 동안 리뉴얼을 준비해 왔고 많은 문제 상황에 대한 대비를 해두었지만, 지난 1주일간 우리가 염두에 두지 못한 문제들이 생겨나기도 했다. 그중에 내가 느꼈던 가장 예상치 못한 큰 이슈 중 하나는, 모바일 웹에 대한 SEO 변화가 되지 않았다는 점이었다. 정확하게는 캐노니컬 태그(canonical tag)에 대한 적용을 해두지 못한 점이었다.

캐노니컬 태그란 홈페이지의 대표 URL 주소를 나타내는 태그이다. SEO를 공부하는 과정에서 만나게 되는 태그 중 하나이다. 캐노니컬 태그는 “홈페이지의 대표 주소를 알려주는 역할”을 한다. 고초대졸닷컴 홈페이지를 예시로 보자.

https://고초대졸.com/jd/list?page=1&order=recent
https://고초대졸.com/jd/list?page=3&order=view
https://고초대졸.com/jd/list?page=2&order=popular

세 주소는 공고의 리스트 페이지 주소들이다. 주소를 자세히 살펴보면 알 수 있듯이, /jd/list 라는 주소 뒤에 ? 기호와 page=~, order=~ 의 형태가 반복되는 것을 알 수 있다. (이와 같은 형태를 쿼리스트링이라고 한다. 자세한 내용은 이 블로그 참고) 결과적으로 세 주소는 같은 공고 리스트 페이지를 가리킴에도, 각자 다른 정렬방식과 다른 페이지의 위치로 이동하게 된다.

그렇기 때문에 구글과 같은 검색엔진에서는 위처럼 쿼리스트링이 다른 주소들은 서로 다른 주소로 인식하게 되고, 각 페이지로 들어가는 사람들을 서로 다른 페이지에 들어간 것으로 인식한다. 이렇게 되면 각 페이지가 전체 트래픽과 중요도를 나누어 가져가게 되는 것이고, 결과적으로 검색 결과에서 각 페이지의 순위나 퀄리티에도 영향을 줄 수 있는 것이다.

위 세 주소에 각각 20명의 사람이 들어왔다면 20점의 주소 3개를 갖는 것이지만, 세 주소를 단일 주소로 묶을 수 있다면 하나의 주소에 60명의 사람이 들어온 것이므로 60점의 주소 1개를 갖는 것이다. 저 3개의 주소가 사실상 같은 공고 리스트 페이지를 가리킨다는 점에서, 후자의 경우가 SEO적 관점에서 더 유리하다고 할 수 있는 것이다. 그렇기 때문에 사실 저 모든 페이지는 같은 URL을 공유하고 있음을 알려줘야 하는 것이고 캐노니컬 태그가 그 역할을 하게 된다.

---

하지만 이번 리뉴얼에서는 단순히 캐노니컬 태그를 적용하지 못한 것이 문제는 아니었다. PC와 모바일 웹은 쿼리스트링이 아닌 도메인이 서로 달라, 완전히 다른 주소로 인식해버린 것이 더 큰 문제였다. 고초대졸닷컴의 메인페이지를 예시로 보자.

https://고초대졸.com
https://m.고초대졸.com

두 주소는 각각 pc와 모바일에서의 고초대졸닷컴 메인 페이지 주소이다. 그리고 아래는 실제로 이번 배포가 끝난 3일 뒤의 PC 구글 검색 결과였다.

위처럼 모바일의 주소가 pc로 검색이 되는 문제가 있었다. 두 페이지가 서로 같은 페이지임에도 서로 같은 페이지임을 인식하지 못하는 문제였다. 해당 문제에 대해 해결 방법을 찾아보니, canonical 적용에 대한 문제임을 알 수 있었다. 이를 해결하는 방법은

1. pc와 모바일 페이지가 동일한 pc 페이지를 canonical 로 가리키게 한다
2. pc 페이지에는 alternate 를 활용해 모바일 페이지를 보조 페이지로 정의해둔다

였다. 즉 두 페이지가 사실 서로 같은 근본 페이지를 두고 있음을 알려주고, 그 근본 페이지에서는 보조 페이지를 정의 해주는것이다. alternate 의 경우 언제 그 보조 페이지를 적용하는지 따로 설정할 수 있어, 기기의 크기 등으로 조건을 붙여주면 더 정확하게 보조 페이지를 정의 할 수 있다. canonical 과 alternate의 적용 방법에 대해서는 생략한다.

---

기존에는 반응형 페이지로 개발했기 때문에, pc와 모바일이 서로 같은 URL과 코드를 공유했다. 그렇기 때문에 이번 리뉴얼 개발에 있어서 위와 같은 문제를 생각하지 못했다. 지금은 위 문제가 해결되었으며 아래와 같이 잘 검색되는걸 볼 수 있다.

모바일 검색 결과

PC 검색 결과

---

Q. 그럼 쿼리스트링이 없는 페이지는 캐노니컬 태그가 필요 없을까?

A. 아니다

도메인 앞에 www 가 붙는 경우(또는 안 붙는 경우)나 마케팅 과정에서 utm_source 와 같이 예상하지 못한 쿼리스트링이 붙는 경우도 있기 때문에 꼭 넣어주는 것이 좋다.

고초대졸닷컴 대규모 리뉴얼

2021년 8월 17일 오픈했던 고초대졸닷컴이, 지난 10월 14일 금요일 약 14개월만에 대규모 리뉴얼을 진행했습니다

고초대졸.com

외형적으로 변경된 주요사항으로는

1. 전체적인 디자인 개선
2. 공고와 기업정보 제공내용 증가
3. 데스크톱 페이지와 모바일 페이지의 분리

이 있으며

FE 에서 변경된 주요사항으로는

1. MPA 형태에서 SPA 형태로의 변경. 전체 SSR로 제공되던 형태에서, 페이지에 따라 CSR, SSG 방식을 추가 (React & Next.js)
2. FE와 BE가 함께 있던 방식에서, REST API 를 통해 BE와의 분리
3. Vercel 을 활용한 배포 및 CI/CD 도입

이 있고

BE 에서 변경된 주요사항으로는

1. AWS EC2 서버로의 이동 및 AWS RDS 도입
2. 백엔드 버전 관리 도입과 FE 작업 문서 제작
3. 에러 로깅 & 슬랙 알람기능 도입으로 실시간 에러 확인 및 처리

가 있습니다