DEV.to, 10년차 개발자가 꿈꾸는 기능 5가지와 없어서 안심한 3가지

DEV.to에서 '트러스티드 멤버(Trusted Member)'로 활동하며, 저는 리뷰 큐와 댓글 섹션에서 남들보다 훨씬 많은 시간을 보냅니다. 자연스럽게 플랫폼에 대한 이런저런 생각이 많아지더군요.

어떤 기능은 "당장 만들어 주세요!" 하고 외치고 싶고, 또 어떤 기능은 "제발 이 플랫폼에는 절대 나타나지 않기를..." 하고 바랄 때도 있습니다.

오늘은 그중 전자에 해당하는 기능 5가지와 후자에 해당하는 기능 3가지를 정리해봤습니다.

꼭 있었으면 하는 기능 5가지

1. 스레드 내 실시간 번역 토글

제가 즐겨 하는 모바일 게임 '워 스나이퍼 3D(War Sniper 3D)'에는 클랜 채팅 기능이 있습니다. 모든 메시지 옆에 작은 버튼이 하나 붙어 있는데, 이걸 누르면 해당 메시지가 즉시 제 언어로 번역됩니다. 사람들은 편하게 원하는 언어로 대화하고, 모든 클랜원은 그 내용을 쉽게 따라갈 수 있죠.

War-sniper-clan-chat 작은 번역 버튼 하나로 다국어 대화가 훨씬 수월해집니다.

DEV.to는 전 세계 개발자들이 글을 쓰는 진정한 글로벌 플랫폼입니다. 그런데 지금은 누가 힌디어, 독일어 또는 영어 외 다른 언어로 댓글을 달면, 대부분의 스레드는 그 댓글을 그냥 지나쳐버리죠. 댓글(이상적으로는 게시물까지)에 원탭 번역 토글이 있다면, 비영어권 사용자들에게 현재 접근 불가능한 방대한 양의 플랫폼 콘텐츠가 열릴 겁니다. 제가 실무에서 여러 국제 프로젝트에 참여하며 느낀 건, 언어의 장벽이 생각보다 훨씬 많은 좋은 아이디어와 정보 교환을 막는다는 점입니다. 이 기능을 통해 훨씬 더 다양한 관점을 접할 수 있을 거예요.

translate-concept DEV.to 댓글에 적용된 원탭 번역 기능의 개념도입니다.

2. 공개된 편집 이력

오늘 발행된 게시물을 수정해도, 읽는 사람은 무엇이 바뀌었는지 알 방법이 없습니다. 사소한 오타 수정이라면 괜찮습니다. 하지만 내용이 크게 바뀌는 경우—가령, 주장 변경, 코드 스니펫 수정, 어조 완화—독자들은 어떤 부분이 달라졌는지 확인할 권리가 있습니다.

공개된 수정 이력은 작성자에게 추가적인 부담을 주지 않으면서 플랫폼의 투명성을 높일 수 있습니다.

오픈소스 프로젝트나 팀 내 기술 문서 작업을 할 때, 커밋 히스토리나 PR 리뷰는 변경 사항의 맥락을 이해하는 데 필수적이죠. 블로그 글도 마찬가지로 이런 투명성이 중요하다고 봅니다.

3. 제대로 된 시리즈 발견 기능

일단 시리즈 안에 들어가면 탐색은 꽤 잘 되어 있습니다. 모든 게시물에는 태그 아래, 그리고 맨 아래에 다른 모든 파트로 연결되는 위젯이 표시됩니다. 이 부분은 훌륭해요.

Post-series-embed 일단 시리즈를 찾으면, DEV.to는 각 게시물 간의 이동을 쉽게 만듭니다.

문제는 그 시리즈를 처음부터 어떻게 찾느냐는 겁니다. DEV.to에서 시리즈 이름을 검색할 수도 없고, 플랫폼 어디에도 시리즈를 위한 탐색 페이지나 탭이 없습니다. 전용 시리즈 페이지는 존재하지만, 내용은 텅 비어 있습니다. 설명도 없고, 커스텀 스타일링도 없으며, 그저 게시물 카드들이 나열되어 있을 뿐이죠.

A series page 시리즈 목적지 페이지는 존재하지만, 독자들을 그곳으로 이끄는 것이 문제입니다.

어떤 시리즈에 접속하는 유일한 방법은 이미 그 시리즈의 게시물 중 하나에 대한 직접 링크를 가지고 있어야 한다는 겁니다. 연재 글 작성을 적극적으로 장려하는 플랫폼인데도, 시리즈 발견 계층은 거의 존재하지 않습니다. 첫 링크 이후의 모든 것은 잘 작동하지만, 그 첫 링크가 모든 부담을 혼자 짊어지고 있는 셈입니다. 제가 블로그에 특정 기술 스택에 대한 연재 글을 올릴 때마다, 첫 글의 유입이 전부인 경우가 많았습니다. 잘 정리된 시리즈가 묻히는 건 정말 아쉬운 일이죠.

Series-page-pconcept 전용 탐색 탭은 여러 부분으로 나뉜 작업물이 링크 의존적이지 않고 발견 가능하도록 만들 수 있습니다.

잘 반응이 좋은 시리즈를 위한 탐색 피드 탭이 있다면 이 문제 대부분이 한 번에 해결될 겁니다. 메인 피드가 개별 게시물을 띄우듯이, 시리즈 전용 버전은 사람들이 실제로 완성하고 독자들이 참여했던 여러 부분으로 된 작업물을 보여줄 것입니다. 운과 직접 링크에만 의존해서 시리즈가 퍼지도록 내버려 두지 않고요.

4. 선택적 푸시 알림

DEV.to는 누군가 답글을 달거나 나를 언급하면 이메일을 보냅니다. 여기에는 꽤 괜찮은 논리가 숨어 있죠. 약 5분 이내에 댓글이나 답글에 반응하지 않으면 그때 이메일이 발송됩니다. 이미 대화에 참여 중이라면, 내가 활발히 참여하고 있는 대화에 대한 또 다른 알림은 필요 없으니까요.

이것은 훌륭한 알림 디자인입니다. 받은 편지함이 폭주하는 것을 막아주죠.

Comment-Mail 대화가 잠잠해진 후에야 이메일이 도착하지만, 결국 받은 편지함을 확인해야 합니다.

하지만 휴대폰이나 데스크톱으로 실제 푸시 알림을 받을 수 있는 옵션은 없습니다. 잠금 화면에 뜨거나, 이메일을 열지 않고도 시스템 알림으로 표시되는 그런 알림 말이죠.

활발한 토론 스레드의 경우, 이러한 알림을 켜는 선택권이 있었으면 좋겠습니다. DEV.to의 현재 기본 설정인 '조용한 알림'은 유지하되, 실시간 대화를 원하는 사람들에게 즉각적인 푸시 알림을 선택할 수 있도록 말이죠. 갑작스러운 장애 보고나 긴급한 기술 토론이 벌어질 때, 이메일함을 일일이 확인할 여유가 없을 때가 많습니다. 실시간 푸시 알림은 이런 상황에서 정말 유용할 거예요.

가끔은 또 다른 이메일이 필요 없습니다. 단지 누군가 지금 바로 답장했다는 것을 알고 싶을 뿐이죠.

5. 진정한 공동 저작 게시물

저는 Yug Vasava와 함께 Gemma 4 Dev 챌린지에 참가하여 AI 계약 분석기인 FinePrint를 만들었습니다. 당시 이 프로젝트에 대한 글을 쓸 때, 우리 중 한 명이 '주 저자'가 되어야 했고, 다른 한 명은 본문에 이름이 언급되는 방식으로 만족해야 했습니다.

DEV.to에 공동 저자 기능이 있긴 합니다. 하지만 조직 계정(organization account)으로 게시된 게시물에만 해당되며, 최대 4명의 공동 저자를 추가하여 게시물 상단에 표시할 수 있습니다. 심지어 이 경우에도 게시물은 주로 주 저자에게 귀속되고, 공동 저자들에게 동등하게 분배되지 않습니다. 더 중요한 것은, 이것은 조직 계정을 위한 일종의 '우회책'일 뿐, 제가 쓴 글 같은 개인 게시물에는 적용되지 않는다는 점입니다. 해커톤이나 DEV 챌린지는 거의 모든 것이 팀 작업이며, 대개 두 개인 간의 협업이지 조직 단위의 작업은 아닙니다.

co-auth-post concept 개인 게시물에서도 실제 협업처럼 두 기여자를 동등하게 인정할 수 있습니다.

해커톤과 DEV 챌린지를 중심으로 구축된 플랫폼에서, 이는 여전히 큰 공백입니다. 해커톤이나 협업 프로젝트를 진행하면서, 결과물을 공유할 때 항상 '누구 계정으로 올리지?' 하는 고민이 있었습니다. 공동 저자 기능은 단순한 이름값 이상의 의미가 있습니다. 기여에 대한 정당한 인정이니까요.

없어서 안심한 기능 3가지

1. 공개적인 비추천(Downvote) 카운터

댓글과 게시물은 플래그(신고)될 수 있지만, 어디에도 비추천 수가 공개적으로 표시되지는 않습니다. 이건 정말 좋은 일입니다.

공개적인 비추천 카운터는 반대 의견을 실제 답글이 아닌 '집단 린치' 메커니즘으로 변질시킵니다. 어떤 의견이 틀렸다고 생각한다면, 플랫폼은 버튼만 누르는 대신 직접 의견을 말하도록 유도합니다.

온라인 커뮤니티에서 불필요한 비난과 논쟁이 생산적인 토론을 잠식하는 경우를 많이 봐왔습니다. 비공개적인 비추천은 반대 의견을 표현할 수 있는 최소한의 수단은 되지만, 공개적으로 카운터가 표시되면 순식간에 비난의 장으로 변질될 수 있습니다.

2. 반응 옆에 표시되는 조회수

게시물의 반응과 댓글은 볼 수 있지만, 순수 조회수는 볼 수 없습니다. 사소한 누락처럼 들리지만, 여기에는 중요한 의미가 있습니다. 사람들이 '보고도 반응하지 않은' 정확한 숫자를 보여주는 점수판처럼 느껴지지 않게 함으로써, 사람들이 진정으로 참여했기 때문에 반응했다는 느낌을 유지시켜 줍니다.

제 블로그의 목표는 항상 숫자가 아닌 '진정한 공감'이었습니다. 조회수가 높더라도 댓글이나 반응이 없다면 공허함을 느끼죠. DEV.to는 이런 '진정성'을 지켜주는 것 같아 좋습니다.

3. "좋아할 만한 사람" 추천 엔진

트위터, 인스타그램, 링크드인 등 모든 플랫폼은 활동, 연락처, 방금 팔로우한 사람을 기반으로 더 많은 계정을 팔로우하도록 끊임없이 유도합니다.

DEV.to는 이런 기능을 제공하지 않습니다. 여기서 누군가를 팔로우하는 것은 여전히 그들의 실제 글쓰기를 기반으로 한 의도적인 선택입니다. 팔로워 수를 늘리기 위해 플랫폼이 사용자 앞에 밀어 넣는 추천이 아니죠. 이 덕분에 플랫폼 전체가 '성장해야 할 네트워크'가 아니라 '읽을 거리'가 풍부한 공간처럼 느껴집니다.

저는 알고리즘이 추천하는 피드를 맹목적으로 따르기보다, 직접 찾아보고 팔로우하며 큐레이션하는 것을 선호합니다. DEV.to에서 제가 팔로우하는 사람들은 정말 제가 그들의 글을 좋아서 선택한 사람들이죠.

이 모든 것은 플랫폼 전반에 대한 불평이 아닙니다. 이 플랫폼이 잘 작동하지 않았다면, 저는 이곳에서 제 경력을 위한 입지를 다지지도 않았을 겁니다. 하지만 매일 사용하는 모든 플랫폼은 이 두 가지 목록을 쌓아가기 마련이고, 저는 그것을 그저 생각 속에만 두기보다는 이렇게 글로 적어두는 편이 좋겠다고 생각했습니다.

당신의 목록에는 무엇이 있나요? 위에서 언급한 기능 중 실제로 사용하고 싶은 것이 있나요, 아니면 제가 잘못 생각했다고 보시는 부분이 있나요? 아래에 댓글로 남겨주세요. 👇

원문: https://dev.to/dj29/5-devto-features-i-wish-existed-3-im-genuinely-relieved-they-dont-3b8n 수집일: 2026-09-15 02:06:28