DEV.to에 있었으면 하는 기능 5가지, 없어서 다행인 3가지

5 DEV.to Features I Wish Existed. 3 I'm Genuinely Relieved They Don't.

I'm a DEV Trusted Member, which means I spend a pretty unreasonable amount of time in the review...

Dhruv Jani2026-09-14

개요 #

DEV 신뢰 멤버(Trusted Member)로 활동 중인 Dhruv Jani가 플랫폼 사용기를 두 갈래로 정리했다. 하나는 "당장 만들어달라"는 기능 다섯 가지, 다른 하나는 "절대 들여놓지 말아달라"는 장치 세 가지다.

리뷰 큐와 댓글창에 오래 머무르다 보면 의견이 쌓인다는 게 그의 설명이다. 플랫폼 자체에 대한 불만은 아니라고 선을 그었다. 커리어를 걸 만한 공간이 아니었다면 애초에 여기서 활동하지 않았을 거라는 말도 덧붙였다.

있었으면 하는 기능 다섯 #

소원을 적어 걸어둔 종이들 Photo by Satoshi Hirayama on Pexels

1. 댓글 안에서 바로 쓰는 번역 토글 #

아이디어의 출처는 모바일 게임이다. 그가 즐기는 War Sniper 3D의 클랜 채팅에는 메시지마다 작은 버튼이 하나씩 달려 있다. 누르면 그 자리에서 자기 언어로 번역된다. 각자 편한 언어로 쓰고, 나머지 사람들도 대화를 따라간다.

War-sniper-clan-chat — *번역 버튼 하나가 다국어 대화의 문턱을 낮춘다.*

DEV의 필진은 전 세계에 흩어져 있다. 그런데 지금은 누군가 힌디어나 독일어로 댓글을 달면 스레드 대부분이 그냥 지나친다. 댓글에, 가능하면 본문에도 원터치 번역 토글이 붙는다면 지금은 보이지 않는 영역이 상당히 열린다는 주장이다.

translate-concept — *같은 원터치 방식을 DEV 댓글에 옮겨본 구상.*

2. 공개된 수정 이력 #

지금은 발행한 글을 고쳐도 읽는 쪽에서 무엇이 바뀌었는지 알 길이 없다. 오타 수정 정도야 상관없다. 문제는 내용이 달라지는 경우다. 철회한 주장, 고친 코드, 톤을 누그러뜨린 의견 같은 건 독자가 차이를 볼 수 있어야 한다는 것.

공개 수정 이력은 필자에게 추가 부담을 지우지 않으면서 플랫폼의 책임성을 높인다.

3. 제대로 된 시리즈 탐색 #

시리즈 안에 일단 들어가면 이동은 불편하지 않다. 태그 바로 아래와 글 맨 끝에 다른 편으로 가는 위젯이 붙는다. 여기까지는 잘 굴러간다.

Post-series-embed — *시리즈를 찾기만 하면, 편 사이를 오가는 건 이미 편하다.*

문제는 거기 도착하는 과정이다. DEV에서는 시리즈를 이름으로 검색할 수 없다. 시리즈를 모아 보여주는 페이지나 탭도 없다. 전용 시리즈 페이지가 있긴 한데 설명도 스타일도 없이 포스트 카드만 쌓여 있는 형태다.

A series page — *목적지는 있다. 문제는 독자를 거기까지 데려가는 길이다.*

결국 시리즈로 들어가는 유일한 입구는 그 시리즈에 속한 글 하나의 직링크를 이미 갖고 있는 경우뿐이다. 시리즈 연재를 적극 권장하는 플랫폼치고는 그 앞단의 탐색 계층이 거의 비어 있는 셈이다. 첫 링크 이후는 다 작동하는데, 그 첫 링크 하나가 모든 일을 혼자 떠맡고 있다.

Series-page-pconcept — *전용 Series 탭이 있다면 연재물이 링크 의존에서 벗어난다.*

그가 내놓은 해법은 반응이 좋은 시리즈를 모아 보여주는 Discover 피드 탭이다. 메인 피드가 개별 글을 띄우듯, 시리즈판 피드가 실제로 완결됐고 독자 반응도 있었던 연재물을 노출하면 된다는 것. 지금처럼 운과 직링크에만 기대는 구조에서 벗어날 수 있다.

4. 선택형 푸시 알림 #

DEV도 누가 답글을 달거나 멘션하면 메일을 보낸다. 여기엔 꽤 괜찮은 판단이 들어가 있다. 대략 5분 안에 그 댓글에 반응하지 않으면 그때 메일이 나간다. 이미 대화 중인 사람에게 그 대화를 알리는 알림은 필요 없으니까.

알림 설계로는 잘 만든 축이다. 받은편지함이 소방호스가 되는 걸 막아준다.

Comment-Mail — *조용해진 뒤에야 메일이 따라붙는다 — 다만 메일함을 열어야 한다는 전제가 남는다.*

다만 폰이나 데스크톱으로 오는 진짜 푸시 알림은 선택지에 없다. 메일을 열지 않아도 잠금화면이나 시스템 알림으로 뜨는 그런 종류 말이다.

토론이 활발한 스레드라면 그걸 켤 수 있으면 좋겠다는 게 그의 바람이다. 지금의 조용한 기본값은 그대로 두되, 실시간 대화를 원하는 사람만 즉시 푸시를 켜게 하자는 쪽이다.

가끔은 메일이 또 필요한 게 아니다. 방금 누가 답글을 달았다는 사실을 지금 알고 싶을 뿐이다.

5. 진짜 공동 저자 기능 #

그는 Gemma 4 Dev Challenge에 나가려고 Yug Vasava와 함께 AI 계약서 분석기 FinePrint를 만들었다. 막상 글로 옮길 때 문제가 생겼다. 한 명이 '저자'가 되고, 다른 한 명은 본문에 이름 한 줄로 언급되는 게 전부였다.

DEV에 공동 저자 기능이 없는 건 아니다. 다만 조직(organization) 계정으로 발행한 글에서만 쓸 수 있고, 최대 4명까지 글 상단에 표시된다. 그마저도 글의 귀속은 여전히 주 저자 쪽으로 기운다. 지분이 똑같이 나뉘지 않는다. 더 큰 문제는 이게 조직 계정용 우회책이라는 점이다. 그가 쓴 것 같은 개인 글에는 쓸 수 없다.

co-auth-post concept — *개인 글에서도 두 제작자를 동등하게 표기할 수 있다면, 실제 협업 모습과 맞아떨어진다.*

해커톤과 DEV 챌린지를 축으로 굴러가는 플랫폼이다. 대부분 팀 작업이고, 조직이라기보다 개인 둘이 붙은 형태가 많다. 그래서 이 빈틈이 여전히 실질적이라는 지적이다.

없어서 다행인 세 가지 #

1. 공개 비추천 카운터 #

댓글과 글에 신고(flag)는 걸 수 있지만, 싫어요 숫자가 드러나는 곳은 어디에도 없다. 그는 이걸 잘된 일로 본다.

공개 비추천 카운터는 이견을 답글이 아니라 몰매 메커니즘으로 바꿔놓는다. 어떤 의견이 틀렸다고 생각하면, 이 플랫폼은 버튼을 누르는 대신 말로 하게 만든다.

2. 반응 옆에 붙는 조회수 #

리액션과 댓글 수는 보이지만 조회수 원본은 보이지 않는다. 사소한 누락처럼 들려도 실제로는 제 역할을 한다. 몇 명이 들여다보고 그냥 지나갔는지 정확히 알려주는 점수판이 아니라, 원해서 반응한 사람들이 모인 공간이라는 느낌을 지켜준다는 것이다.

3. '알 만한 사람' 추천 엔진 #

트위터, 인스타그램, 링크드인은 계속 팔로우를 부추긴다. 활동 이력, 연락처, 방금 팔로우한 계정을 근거로 삼는다.

DEV는 그러지 않는다. 여기서 누군가를 팔로우하는 건 그 사람의 글을 보고 내리는 의도적인 선택이지, 팔로워 숫자를 불리려고 플랫폼이 들이민 제안이 아니다. 덕분에 성장률을 끌어올리라고 등 떠미는 네트워크가 아니라, 읽으러 오는 공간이라는 느낌이 남는다.

마무리 #

Jani는 매일 쓰는 플랫폼이라면 이런 목록이 양쪽 다 쌓이기 마련이라고 했다. 머릿속에 담고 다니느니 적어두는 편을 택했다는 것이다. 그는 글 말미에 독자들에게도 물었다. 위에 적힌 것 중 실제로 쓸 만한 게 있는지, 혹은 자신이 틀린 부분이 있는지.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.