1차 공개 · 8월 23일에 1차 강의가 모두 공개됩니다.
TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 32 READS

해커뉴스 댓글의 역설: 최악의 잡음 속에서 최고의 기술 토론을 건지는 법

온라인 기술 커뮤니티의 댓글창은 대개 실망스럽다. 개발자 댄 루(Dan Luu)는 2016년 글에서 자신이 잘 아는 주제일수록 해커뉴스(HN) 댓글의 상당수가 명백히 틀렸다고 지적한다. 정작 그 분야를 아는 사람의 글은 하나도 없고, 그럴듯하게 들리지만 완전히 잘못된 댓글이 맨 위를 차지하는 일이 흔하다는 것이다. 게다가 불필요하게 공격적인 댓글도 많다. 누군가를 가르치려면 모질게 굴 수밖에 없다는 식의 변명이 따라붙지만, 상대에게 멍청하다고 말하는 것이 학습에 도움이 될 리는 없다. 폴 그레이엄조차 "자기 글에 달린 HN 댓글은 절대 읽지 말라"고 했을 정도다.

그럼에도 루는 HN보다 기술적 통찰이 뛰어난 공개 포럼을 찾지 못했다고 말한다. 핵심은 잘 아는 사람의 댓글이 나타나는 빈도가 아니라, 나타났을 때 대체로 위로 떠오른다는 점이다. 다른 포럼에서는 그런 댓글이 아예 없거나, 있더라도 그럴듯한 오답들에 묻혀 버린다. 그는 블로그를 거의 쓰지 않지만 훌륭한 댓글을 남기는 사람이 20~30명은 떠오른다고 했고, 특정 저자의 저수준 최적화나 사업 운영에 관한 글이라면 읽어 볼 가치가 있다고 미리 확신한다고 했다. 이 글의 문제의식은 여기서 출발한다. 블로그 글은 수년 뒤에도 인용되지만 댓글은 대부분 사라진다는 것, 그래서 좋은 댓글을 따로 모아 둘 가치가 있다는 것이다.

사라지는 지식과 큐레이션의 가치

루가 모아 둔 댓글들은 왜 이 작업이 의미 있는지를 잘 보여 준다. 대표적인 것이 마이크로소프트 워드 파일 포맷에 관한 설명이다. 초기 워드의 파일은 사실상 메모리를 그대로 디스크에 덤프한 것이었고, 이후 기능을 추가하면서 하위 호환성을 지키느라 온갖 기괴한 우회로가 쌓였다는 증언이다. 특히 두 워드프로세서 사이의 완전한 양방향 변환이 거의 불가능한 이유로 페이지 나누기가 꼽힌다. 파일 포맷에는 어디서 페이지를 끊을지가 들어 있지 않고, 포매터가 그때그때 계산한다. 그래서 XML 포맷에는 "워드 95처럼 서식 적용" 같은 플래그가 잔뜩 있는데, 정작 그것이 무엇을 뜻하는지는 아무도 모른다는 것이다. 특정 워드프로세서가 미국 법무부가 요구하는 방식대로 법률 문서를 조판하는 유일한 도구라서 살아남았다는 일화도 함께 실려 있다.

오용을 부르는 설계와 인간 요소

또 다른 축은 엔지니어링 설계 철학이다. 한 댓글은 "좋은 엔지니어링은 사용자가 잘못할 수 있는 여지를 최대한 없애는 것이며, 오용을 부르는 기능을 만들어 놓고 설명서로 막으려 해서는 안 된다"고 말한다. 이를 극적으로 보여 주는 사례가 호주 워터폴 탈선 사고다. 기관사가 심장마비를 일으켰지만, 체중이 실린 다리가 데드맨 페달을 어중간하게 눌러 비상 제동이 걸리지 않았다. 대응책으로 나온 것이 경계(vigilance) 시스템인데, 처음엔 30초마다 버튼을 누르게 했더니 기관사들이 졸면서도 무의식적으로 정확히 눌렀고, 시간을 무작위화해도 마찬가지였다. 결국 무작위 시점에 무작위 동작(버튼·노브 등)을 요구하는 방식에 이르러서야 문제가 해결됐다. 사람의 습관화를 이겨 내려면 예측 불가능성을 설계에 넣어야 한다는 교훈이다.

비슷한 결의 이야기로, 세 개의 주요 컴파일러가 모두 동일한 널 포인터 상황에서 서로 다르게 동작한다는 지적도 있다. 하나의 printf 문에서는 문제가 없던 코드가 두 문장으로 나뉘면 세그폴트가 나는 미묘한 사례는, 도구를 신뢰할 때조차 그 경계 조건을 스스로 이해해야 한다는 점을 일깨운다.

실무자에게 남는 것

사업과 조직에 관한 댓글도 있다. 페덱스 허브 입지 선정 기준은 적당한 기존 공항, 좋은 날씨, 노동력, 낮은 생활비, 우호적 규제, 활주로 고도와 횡풍 조건 등 12가지에 이르렀고 그 결과가 멤피스였다. 구글 웨이브에 합류했던 이더패드 창업자는, 엔지니어와 자금이 많다는 것이 오히려 해가 될 수 있으며, 스타트업처럼 보인다고 해서 스타트업처럼 반복 개발이 되는 것은 아니라는 교훈을 남겼다. 상대의 개발 프로세스를 실제로 검증하지 않은 것이 실수였다는 반성이다.

한국의 IT 실무자에게 이 글이 주는 함의는 두 가지다. 첫째, 커뮤니티의 가치는 평균이 아니라 신호가 잡음을 뚫고 올라오는 구조에 있다. 사내 위키나 슬랙, 사내 게시판을 운영한다면 좋은 답이 묻히지 않도록 하는 장치가 콘텐츠 양보다 중요하다. 둘째, 흩어진 암묵지는 의도적으로 보존하지 않으면 사라진다. 뛰어난 설명이 담긴 스레드나 코드 리뷰 코멘트를 별도로 갈무리해 두는 습관은 조직의 자산이 된다. 다만 한계도 분명하다. 루가 고른 목록은 개인의 취향과 생존 편향이 반영된 선별물이며, 워드 포맷이나 사고 원인에 대한 증언들은 대부분 익명 개인의 회고여서 그 자체로 검증된 사실은 아니다. 인상적인 일화일수록 별도의 확인이 필요하다는 점을 잊지 않는 편이 좋다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://danluu.com/hn-comments/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...