뛰어난 엔지니어링은 거창한 이론이나 화려한 아키텍처에서만 나오는 것이 아니다. 개발자 윌 켈러허(Will Keleher)는 자신의 블로그 글에서, 실무에서 체감하는 생산성의 상당 부분이 사실은 작고 사소한 지식 조각들의 축적에서 온다고 주장한다. 어떤 언어 기능이 존재한다는 사실을 알고 있는 것, 곤란한 상황에서 빠져나오는 git 명령어를 외우고 있는 것, sed로 파일을 손쉽게 고치는 요령을 아는 것 같은 것들이다. 하나하나는 대단해 보이지 않지만, 이런 조각들이 쌓여 하루하루의 작업 속도를 결정한다는 관점이다.
지식은 결국 작은 조각들의 합
어떤 의미에서 이는 당연한 이야기다. 우리가 아는 모든 것은 더 작은 지식 조각들로 이루어져 있으니, 그 작은 조각들이 중요하다는 것은 자명하다. 그러나 켈러허가 특히 강조하는 것은, 지탱하는 배경 지식이 거의 없이도 곧바로 쓸 수 있는 유형의 요령들이다. 예컨대 파이썬을 전혀 몰라도 python3 -m http.server 한 줄이면 현재 디렉터리를 서비스하는 간단한 서버를 띄울 수 있다. 이런 요령은 그 자체로 완결되어 있어서, 별도의 학습 부담 없이도 작업을 조금 더 수월하게 만들어 준다.
실무자라면 이 대목에서 자신의 사례를 떠올리게 된다. 원인 모를 TCP 지연이 대개 Nagle 알고리즘과 TCP_NODELAY 설정 때문이라는 것을 아는 사람과 모르는 사람은, 같은 증상을 마주했을 때 문제 해결에 걸리는 시간이 크게 달라진다. 이런 지식은 정교한 이론 체계라기보다는, 한 번 겪어 보거나 누군가에게 전해 들으면 오래 남는 실전 감각에 가깝다. 원문 저자도 이 목록이 모든 사람에게 유용하지는 않을 것이라고 인정한다. 이미 다 아는 요령일 수도 있고, 자신의 분야에서는 전혀 쓸모없을 수도 있다. 하지만 그 경우라도 각자 오랜 시간에 걸쳐 쌓아 온 자신만의 요령 창고가 있을 것이라는 점을 짚는다.
회사 안에서 더 큰 힘을 발휘하는 지식
켈러허는 이런 고효율 지식 조각이 특정 회사 내부에서 특히 위력을 발휘한다고 본다. 언어나 도구에 관한 일반적인 요령뿐 아니라, 그 조직에만 존재하는 문서의 위치, 내부 도구를 다루는 관행, 특정 시스템의 함정 같은 회사 고유의 지식이 여기에 해당한다. 이런 정보는 코드나 매뉴얼 어디에도 잘 정리되어 있지 않은 경우가 많아, 아는 사람과 모르는 사람 사이의 격차가 더 크게 벌어진다.
그가 실제로 시도했던 방법은 단순하지만 인상적이다. 이전 직장에서 그는 매일 하나씩, 기술적인 것이든 회사에 특화된 것이든 엔지니어링 팀 슬랙 채널에 요령을 공유했다. 반응은 좋았다. 열 개 중 아홉 개를 이미 알고 있더라도 나머지 하나가 시간을 아껴 줄 수 있기 때문이다. 하루에 하나라는 빈도도 핵심이었다. 지식을 한꺼번에 쏟아부어 사람들을 압도하지 않으면서, 때때로 유용한 토론까지 불러일으키는 적절한 양이었다는 것이다. 그는 조직에서 비교적 선임 위치에 있는 엔지니어라면 이런 방식을 한번 해 볼 만하다고 권한다.
한국 실무자에게 주는 시사점
이 글이 한국의 개발 조직에 던지는 함의는 분명하다. 사내 지식 공유라고 하면 흔히 방대한 위키나 정식 온보딩 문서를 떠올리지만, 그런 대형 자산은 만들기도 어렵고 실제로 읽히기도 어렵다. 반면 하루 한 조각의 요령 공유는 진입 장벽이 낮고 지속 가능하며, 팀 전체의 암묵지를 조금씩 표면으로 끌어올린다. 특히 특정 시스템의 담당자만 알고 있는 운영 노하우처럼 문서화되지 않은 회사 고유 지식일수록 이런 방식의 가치가 크다.
다만 한계도 함께 짚어 둘 필요가 있다. 이 글은 개인 경험에 기반한 에세이일 뿐, 생산성 향상을 뒷받침하는 정량적 근거를 제시하지는 않는다. 어떤 요령이 유용한지는 사람과 분야에 따라 크게 달라지므로, 공유가 곧 팀 전체의 성과로 이어진다는 보장도 없다. 저자 스스로 이 아이디어를 줄리아 에번스(Julia Evans)의 블로그에서 처음 접했다고 밝히며, 그 핵심을 "작은 지식 조각은 강력하고, 재미있고, 다가가기 쉽다"는 말로 요약한다. 거창한 방법론을 도입하기 전에, 오늘 내가 무심코 쓴 명령어 하나를 옆자리 동료에게 건네는 데서 팀의 성장이 시작될 수 있다는 소박한 제안이다.