수년간 블로그와 온라인 활동을 주저하게 만든 두려움, 개발 지식의 빈틈, 업무와 원격 근무, 사이버 괴롭힘에 대한 솔직한 고백과 앞으로의 배움과 글쓰기에 대한 다짐을 담은 글입니다.
4월 이후로 아무 글도 올리지 못했다. 두려웠기 때문이다. 몇 달 동안 소셜 미디어, 뉴스 애그리게이터, 토론 포럼도 피했다. 이제는 두려움이 나를 막게 두지 않기로 했다. 나는 무엇이 두려웠을까? 이 글에서, 그동안 이 블로그에 솔직히 털어놓지 못했던 _모든 것_을 이야기해 보려 한다.
먼저, 왜 지금에서야 이런 것들을 고백하는 걸까? 나만 중요한 기술이 빠져 있는 채로 일하는 소프트웨어 개발자가 아니라는 걸 깨달았기 때문이다. 내 커리어 동안의 학습 경로를 돌아보면, 마치 먹이를 찾아다니는 점균류(slime mold) 같았다. 당장 쓸모 있는 것만 강화하고, 나머지는 시들어 버리게 두는 식이었다. 하지만 요즘 들어 더 나은 지식의 토대를 쌓고 있다. 내가 배운 것을 글로 쓰거나 강연으로 정리하는 일은—학습 효과를 높여 주는—동시에 내가 예전에 몰랐다는 사실을 인정하게 만든다. 그리고 나와 같은 상황에 있는 사람들에게, 모르는 기본기를 지금부터라도 얼마든지 배울 수 있다는 걸 보여 주고 싶다. 나는 기초를 다시 채워 넣을 수 있고, 당신도 그럴 수 있다.
바로 그 무지로부터 지식을 향한 갈망이 싹튼다.
— 레티시아 포르텔라, 친절한 소프트웨어 개발 안내서
지난 12개월 동안 다형성(polymorphism)을 제대로 배우면서, 처음으로 “이걸 지금까지 몰랐다는 걸 인정하기 부끄럽다”고 느꼈다. 2012년부터 줄곧 표면적으로는 객체지향 소프트웨어를 써 왔다. 그런데 다형성에 대한 인식이 없었다는 건, 지금까지 내가 써 온 건 객체지향이라기보다는 구조적 프로그래밍에 가까웠다는 뜻이다. 조건문과 case 문을 특화된 클래스들로 치환할 수 있다는 생각조차 해 본 적이 없었다.
나는 채용 매니저로서 소프트웨어 엔지니어를 인터뷰했고, 객체지향 지식을 가진 사람을 뽑으려 애썼다. 돌아보면 이건 위선이었다는 게 분명하다. 이 격차는 내 커리어 초반을 원칙이 아니라 도구 중심으로 보냈다는 사실을 드러낸다. 또 정규 교육을 거의 받지 못했다는 점을 더 부각시킨다. 다형성은 대학의 모든 객체지향 강의에서 다루는 내용이다.
학생일 때 데이터베이스 강의를 들었다. 직장인이 된 뒤에는 _Learning SQL, 3rd Edition_의 내용을 읽고 예제를 전부 따라 해 보기도 했다. 한동안은 SQL을 쓸 줄 알았다. 하지만 나는 프런트엔드 웹 개발 쪽으로 전문 분야를 좁혔고, 직업적으로 SQL을 쓸 일이 사라졌다. 사용하지 않는 기술은 결국 퇴화한다. 지금도 기본적인 쿼리는 어떻게 쓰는지 기억하지만, 그 이상은 거의 남아 있지 않다. 예를 들어, left inner join과 outer join의 차이를 문서 없이 설명해 보라면 못 한다.
나는 “잊어버린다”는 경험에 익숙하지 않았다. 어린 시절 나는 거의 모든 걸 기억하는 놀라운 능력을 갖고 있었다. 직접 해 봤든, 읽었든, 들었든 상관 없었다. 사실이든, 기술이든, 사건이든 마찬가지였다. 네댓 해가 지난 뒤에도, 작은 단서만 있으면 홍수처럼 기억이 쏟아져 나왔다. 하지만 지금 서른 중반이 되니 더는 그렇지 않다. SQL은 _한 전체 기술_이 퇴화로 인해 통째로 사라진 첫 번째 사례다. 노화가 시작되었다는 사실을 받아들이는 것 자체가 힘들다. 그걸 공개적으로 인정하는 건 더 어렵다.
내가 프로덕션으로 배포한 코드의 95%는 자동화된 테스트가 없다. 커리어 초반에는 테스트라는 개념 자체를 접해 본 적이 없었다. 그 뒤에는 Ember로 프런트엔드를 작성했는데, 당시의 테스트 경험은 겉보기엔 괜찮아 보였지만 실제로는 꽤 괴로웠다. 더 최근에는 레거시 코드를 다루고 있는데, 그 코드를 테스트 가능하게 만들기 위한 수고를 들이지 않았다. 새 서브시스템을 설계할 때만, 처음부터 테스트 가능하게 설계할 수 있기 때문에 테스트를 쓰곤 한다. 자동화된 테스트 작성이 일상적인 습관이 되어야 한다는 데는 확신이 있지만, 아직 그 단계에 이르지 못했다.
아마도 이것이 내 커리어에 가장 큰 타격을 줄 고백일 것이다. 언클 밥의 말을 믿는다면, 테스트 없는 코드를 프로덕션에 배포하는 건 위험할 뿐 아니라 비윤리적이기까지 하다. 나는 내 학습 여정을 글로 올렸다가, 미래의 어떤 채용 매니저가 이 한 가지 이유로 나를 함께 일할 수 없는 사람으로 판단할까 봐 두려웠다.
자동화된 단위 테스트로 코드의 어느 정도를 테스트해야 할까요? 그 질문에 정말 답해야 하나요? 전부입니다! 전.부.요.
제가 100% 테스트 커버리지를 _제안_하는 거냐고요? 아니요, 저는 제안하는 게 아니라 _요구_합니다. 여러분이 작성하는 모든 줄의 코드는 테스트되어야 합니다. 끝.
그게 비현실적인가요? 전혀요. 여러분은 코드가 실행되리라 기대하기 때문에 코드를 씁니다. 실행되리라 기대한다면, 그 코드가 작동하는지 알아야 합니다. 그걸 아는 유일한 방법은 테스트하는 것입니다.
— 로버트 C. 마틴, 클린 코더(The Clean Coder), 1장: 프로페셔널리즘
사람들은 내가 C#, .NET, Blazor를 배우는 여정에 대해 후속 글을 올리길 기다리고 있다. 이 글은 그 후속편이 아니다. 그 글이 언젠가 올라올지조차 모르겠다.
C#은 애초에 내가 사이드 프로젝트용으로 배우고 싶던 언어가 아니었다. .NET도 내가 직업적으로 다뤄 보고 싶었던 플랫폼이 아니었다. 내가 그것들을 배우던 이유는 단 하나, 내 직장이었다. 내가 속한 엔지니어링 부서가 기술 스택을 Angular에서 Blazor로 전환하기로 했기 때문이다. 팀원들 중 C# 실력이 전혀 없는 사람은 나뿐이었다. 나는 즉시 그 부분을 메우기 시작했다.
두세 달 뒤, 거의 그만큼 갑작스럽게 그 결정이 번복되었다. 기술 스택은 결국 변경하지 않기로 한 것이다. 나를 밀어 주던 내적 동기가 사라지자, 읽고 있던 C# / .NET 책을 끝까지 보지도 않고 던져 버렸다. 그보다 더 중요한 배움의 과제들이 있었다.
무슨 소프트웨어 관련 생각이 떠오르든, 다 글로 남기겠다고 마음먹었다. 글을 쓰면 흩어지는 생각이 단단해지고, 공개하면 피드백을 받을 기회가 생긴다. 하지만 나는 두 가지 실수를 했고, 그것 때문에 두려움의 패턴에 갇혔다. 첫째, 마지막 Blazor 스택 관련 글의 끝에서 후속 글을 약속했다. 그 뒤로, 약속한 후속편이 아닌 다른 글을 올릴 때마다 더 불편해졌다. 둘째, 블로그 글이 받는 _트래픽 양_에 가치를 두기 시작했다. 그 학습 여정의 첫 발걸음을 담은 글들이 조회수 1위였다. 회사가 방향을 바꿨을 때 나도 방향을 틀었다고 인정하는 건, 마치 패배를 인정하는 것처럼 느껴졌다.
나는 루비를 사랑한다. 코드 예제에 루비를 쓴다. 오픈 소스 프로젝트의 기본 언어도 루비다. 코드 카타, 에튀드, 해커톤에도 루비를 즐겨 쓴다. 하지만 루비로 돈을 받은 적은 2013년 이후로 없다.
가장 이상적인—그러나 가장 가능성이 낮은—상황은 현 직장에서 루비 프로젝트를 시작하는 것이다. 나는 지금 팀원들 몇 명과 두 회사를 걸쳐 12년째 함께 일하고 있다. 나는 항상, 별로 멋지지 않은 언어를 써야 한다는 대가를 치르더라도, 훌륭한 사람들과 계속 일하는 쪽을 선택해 왔다.
안타깝게도 그 말은 곧, 나는 퇴근 후와 주말에만 루비스트(Rubyist)로 살 수 있다는 뜻이다. 그 시간에도 루비를 쓰기보다는, 다른 의무, 취미, 직업적 성장 목표에 시간을 더 많이 쓴다. 내가 원하는 만큼 루비를 많이 쓸 수 있는 유일한 현실적인 방법은, 루비를 쓰는 일로 돈을 받는 것이다.
내 매니저와, 그 위의 CTO가 이 블로그를 읽는다. 매일 쓰는 도구를 싫어한다는 걸 솔직하게 쓰기가 쉽지 않았다. 더 나아가, 지금 하는 일과는 다른 업무를 적극적으로 원한다고 쓰는 건 더 어려웠다. 그들이 “나 곧 그만두겠다”는 신호로 받아들이지 않을까 (그럴 생각 없다), 혹은 팀 어느 누구도 익숙하지 않은 도구를 억지로 도입하려 한다고 오해하지 않을까 (그럴 생각도 없다) 걱정됐다.
덤으로, 더 개인적인 고백 하나…
덤으로, 더 개인적인 고백 하나…
나는 젊은 시절 대부분을 온라인에서 보냈다. 초기의 인터넷 경험은 지적인 공간에 머무는 일이 많았고, 그 상호작용은 『엔더의 게임』에 나오는 넷(Nets)처럼 느껴졌다. 아이디어의 시장 말이다. 날선 비판이 빠르게 오갔지만, 그 화살은 _아이디어_를 향해 날아갔지 사람을 겨냥하진 않았다. 레딧이나 해커 뉴스처럼—댓글이 거칠어지기로 악명이 높은 포럼조차—날 불편하게 만들지 않는다. 거기서 쏟아지는 독설은 형편없는 아이디어를 공격하는 것이지, 개인을 모독하는 게 아니기 때문이다.
하지만 다른 웹사이트들은 달랐다. 나는 어느 온라인 포럼에서 괴롭힘을 당하면서 그 사실을 배웠다. 거기서 나는 무능하고, 교활하고, 역겹고, 무능하며, 무관심하고, 인간의 표현을 위협하는 존재라고 불렸다.
무엇이 이런 독설을 촉발했을까? 나는 한 오픈 소스 프로젝트에 작은 기능을 요청했고, 메인테이너는 PR을 받겠다고 했다. 그 프로젝트는 내가 써 본 적 없는 언어로 작성되어 있었다. 나는 LLM을 사용해 수십 줄 정도의 작은 커밋을 생성했고, 패치를 검토하고 테스트한 뒤, 풀 리퀘스트를 제출했다. 이 일은 몇 달 전의 일이라, AI 보조 패치에 대한 사회적 규범이 거의 없었고, AI 정책도 희귀했다. 그 프로젝트에 별다른 정책이 없었기 때문에, 나는 AI 사용 사실을 공개하지 않았다.
그 포럼에서 이 PR 이야기를 꺼내고, 내 윤리적 입장을 변호하자, 괴롭힘이 시작되었다. 사람들은 여러 웹사이트를 가로질러 나를 쫓아다녔고, 이메일과 SMS로 연락을 취했고, 심지어 전화까지 걸어 왔다. 나는 더 이상 그 웹사이트에 존재감을 드러내는 것이 안전하다고 느끼지 못했다. 댓글을 삭제하고, 프로필에서 개인정보를 지우고, 추가 괴롭힘을 막기 위해 포럼 관리자에게 내 실명을 프로필에서 제거해 달라고 요청했다. 대신, 그들은 내 프로필에 더 많은 개인정보를 붙였고, 편집 권한을 잠가 버렸으며, 내게 포럼 밖에서 연락한 적이 없다는 거짓말을 내가 했다는 식의 허위 주장으로 내 프로필을 영구적으로 훼손했다.
이 사건은 내가 겪어 본 것 중 가장 독성이 강한 경험 중 하나였고, 며칠 동안 계속되었다. 이 글을 쓰는 것만으로도 아직 그 잔향을 느낀다. 나는 그들이 댓글, 이메일, 심지어 내 전화번호를 통해 이 문제를 다시 들고 나올까 봐 두려웠다. 지금도, 관리자들이 내 프로필에 남긴 (아마도 명예훼손에 가까운) 문장이 나를 덜 고용 가능한 사람으로 만들지 않을까 두렵다.
수백 개의 회사, 수천 명의 연구자, 수만 명의 노동자, 수백만 달러의 돈이 우리 업계의 모범 사례를 만드는 데 쓰였다. 애자일 선언은 이제 술을 마실 수 있을 정도의 나이가 됐다. 서비스형 소프트웨어(SaaS)는 이미 10년 넘게 시장을 지배해 왔다. 당신 회사의 혁신 예산은 한정돼 있다. 그 예산을 새로운 소프트웨어 개발 생명주기를 직접 만들어 내는 데 쓰고 싶은가, 아니면 시장에서 이길 제품을 만드는 데 쓰고 싶은가? 스크럼, 린 / 칸반, 익스트림 프로그래밍(eXtreme Programming) 같은 걸 있는 그대로 따라 하고, 팀은 제품에 집중하게 두는 편이 낫다.
다른 글쓴이와 마찬가지로, 나는 내가 아는 걸 쓴다. 이 글은 한 동료가 회사에 맞는 커스텀 소프트웨어 개발 프로세스를 만들자고 강하게 주장했기 때문에 쓰고 싶어졌다. 내가 그 사람이나 그 아이디어를 후려치는 글처럼 보이지 않게 쓸 만큼의 섬세함을 가졌는지 확신이 없었다. 켄트 벡이나 마틴 파울러처럼, 실명을 거론하지 않고도 더 나은 일하는 방식을 쓰는 능력을 나는 존경한다.
원격 근무는 사무실 근무의 많은 문제를 없애 준다. 출퇴근, 비효율적인 부동산 사용, 토지가격 왜곡 같은 것들 말이다. 하지만 소프트웨어 개발은, 함께 일하는 사람들이 같은 공기를 마실 때 더 잘 된다. 카메라 항상 켜기 정책이 있다 해도, 화상 회의는 대역폭이 낮은 매체다. 동료들의 문제에 대한 주변적 인식(ambient awareness)이 사라진다. 도움을 요청하는 일은 더 큰 부담이 된다. 페어 프로그래밍의 효율도 떨어진다. 공간적으로 아이디어를 표현하려는 시도는 온라인 화이트보드와 포스트잇 소프트웨어에서 형체가 일그러진다. 심지어 갈등도 악화된다. 화상 회의만으로 상대를 적대 이미지(enemy image)로 만드는 건 쉽지만, 같은 방에서 함께 시간을 보내며 그 사람의 고통을 느끼다 보면 그 이미지를 유지하기가 훨씬 어렵다.
COVID-19가 닥쳤을 때, 내가 일하던 회사는 “2주 정도만” 재택근무를 하자고 했다. 몇 달이 지나도 사무실 없이 생산성이 유지됐고, 백신이 언제 나올지도 불투명해지자, 재택근무는 영구화됐다. 나는 그 기회를 틈타 시골로 이사했다. 지리적 차익(geographic arbitrage) 덕분에 27에이커 땅을 살 수 있었고, 가족용 우유 소 한 마리도 샀다. 그 뒤로 우리 가족은 그곳에 뿌리를 내렸다. 가까운 친구들, 지역 사회 활동, 출퇴근이 없다는 사실을 전제로 한 삶의 방식이 생겼다.
나는 원격 근무에 대해 부정적인 글을 쓰면, 지금의 원격 직장을—그리고 앞으로 찾게 될 모든 원격 직장 기회를—위태롭게 할까 봐 두려웠다. “사무실 근무를 선호하는 사람을 누가 원격으로 채용하겠어?”라는 생각이 들었다. 옆자리에 앉아 함께 일하는 걸 더 좋아하지만, 일 때문에 이사를 갈 가능성은 거의 없다. 이자는 낮고 기간은 30년인 모기지를 끼고 집을 샀다. 집값이 팬데믹 이후 폭등하기 전 가격이다. 잔디와 텃밭만 해도 1에이커, 거기에 농장 부지도 있다. 도시에서 현재 생활 수준을 유지하려면 지금 수입을 _두 배_로 늘려야 하는데, 그럴 가능성은 거의 없다.
이제 한 번 터져 버린 댐은 다시 막을 수 없다. 더 이상 글 올리는 걸 가로막는 건 없다. 나는 계속해서 실력을 쌓아 갈 것이고, 이제는 그 과정에 대해 자유롭게 쓸 수 있을 것 같다. 이 글이 당신에게도 와 닿았다면—당신도 메우고 싶은 지식의 빈틈이 있든, 내 빈틈을 함께 메워 주고 싶든, 아니면 그냥 앞으로 어떻게 되는지 궁금하든—댓글로 알려 주면 좋겠다. 내가 올리는 글을 전부 보고 싶다면 마스토돈을 통해 구독하고, 원하는 것만 골라 보고 싶다면 RSS를 쓰고, 큰 글을 올릴 때만 알림을 받고 싶다면 메일링 리스트를 구독해 달라.
당신이 팔로우하기 쉽도록, 이 블로그에 ActivityPub을 활성화했다. 이제 이 블로그는 완전한 마스토돈 계정이기도 하다: @[email protected].
Kerrick Long (blog)
프로그래밍, 학습, 코드, 책, 팀에 대한 글들
8개의 글
12명의 팔로워
좀 올드스쿨한 방식을 선호한다면, MacOS용 NetNewsWire, Windows용 Feedmill, Linux용 Newsflash 같은 XML 피드 리더를 설치하고, 아래 피드 중 하나 이상을 구독하면 된다.
물론 가장 클래식한(그리고 내가 가장 좋아하는) 방식은 이메일 알림 구독이다. 나는 새 _기사_를 발행할 때만 이메일을 보낼 것이고, 모든 마이크로 포스트에 대해 메일을 보내지는 않을 것이다.
내가 새 글을 올릴 때마다 알림을 받으세요. 개인정보 보호 정책이 적용됩니다.
