소프트웨어 개발자의 고백: 더 이상 자기검열은 없다

• 수개월 동안 두려움 때문에 글과 온라인 활동을 중단했던 개발자가 자기검열을 멈추고, 그동안 인정하지 못했던 기술적·개인적 부족함을 고백하는 글
• 다형성(polymorphism) 개념을 10년 넘게 이해하지 못했고, SQL 실력을 잃었으며, 대부분의 코드를 자동화 테스트 없이 배포해 왔다는 사실을 인정
• 회사의 기술 스택 변화에 맞추려다 C#과 Blazor 학습을 중단하고, 여전히 Ruby를 사랑하지만 직업적으로 사용하지 못하는 현실, 그리고 관리자·동료가 블로그를 읽는 상황에서 느끼는 심리적 부담
• AI로 작성한 PR 제출 후 사이버 괴롭힘을 당한 경험과, 원격 근무에 대한 솔직한 감정 및 조직 내 맞춤형 개발 프로세스의 불필요성에 대한 솔직한 의견
• 두려움을 내려놓고 더 이상 자기 검열 없이 지속적인 학습과 공개적인 글쓰기를 이어가겠다는 다짐으로 마무리

---

시작: 두려움과 자기 검열을 멈추기로 한 계기

• 4월 이후 겁이 너무 커져서 글을 올릴 수 없었던 시간이 있었고, 소셜 미디어·뉴스 애그리게이터·포럼까지 모두 끊어 놓았음
  • 이 상태를 더 끌고 갈 수 없다고 느껴 두려움을 넘어 글을 다시 쓰기로 결정함
• 부족한 기초를 드러내기 싫어 꽁꽁 숨기고 지냈지만, 실제로는 많은 개발자가 비슷한 지식 공백 속에서 일하고 있다는 사실을 바라보게 됨
  • 지금까지의 학습 방식은 쓰는 영역만 비대하게 자라는 슬라임 몰드와 닮아 있었고, 사용하지 않은 지식은 그대로 말라버렸음
• 최근 다시 기초를 채우기 시작했고, 배운 내용을 글과 말로 재구성하면서 “모른다”는 사실을 가볍게 인정하는 감각이 자리 잡기 시작함
• 기초는 다시 익힐 수 있다는 확신을 직접 느끼며, 늦은 때는 없다는 감정이 생김

다형성을 10년 넘게 이해하지 못했던 시간

• 2012년부터 객체지향 코드를 쓴다고 생각했지만, 최근 1년 전까지만 해도 다형성을 제대로 이해하지 못하고 있었다는 사실을 스스로 인정하게 됨
  • 지금까지 작성한 코드는 객체지향이라기보다는 구조적 프로그래밍에 가까웠다는 현실을 마주함
  • 조건문을 클래스로 치환해 설계를 바꾸는 발상은 한 번도 해본 적이 없었음
• Sandi Metz 글과 Martin Fowler 자료를 보며 뒤늦게 개념을 이해했고, 그동안 놓친 것이 너무 많다는 사실이 분명해짐

• 이 사실을 드러내기 어려웠던 이유

  • 채용 인터뷰에서 객체지향 개념을 보는 역할을 맡아온 사람이 정작 다형성을 몰랐다는 사실을 드러내는 일이 버거웠음
  • 커리어 초반에 원칙 보다는 도구위주의 학습에 치우쳐 있었다는 점이 그대로 드러나고, CS를 전공하지 않은 배경 탓에 놓친 기초가 너무 많다는 사실을 마주하는 일이 쉽지 않았음

SQL을 잊어버린 경험

• 과거에는 SQL 책을 따라 연습 문제를 풀며 능숙하게 JOIN과 서브쿼리를 작성하던 시절이 분명히 있었음
• 프론트엔드 중심 실무가 이어지며 SQL을 쓸 일이 완전히 사라지자, 어느 순간 기술 하나 전체가 머릿속에서 사라져 있었다는 사실을 깨달음
  • 기본 쿼리는 떠오르지만, left join과 outer join의 차이를 설명하려면 문서를 다시 펼쳐야 하는 상태가 되어 있었음

• 이 사실을 인정하기 어려웠던 이유

  • 젊을 때는 몇 년이 지나도 사실과 기술이 작은 힌트만 있으면 되살아나는 기억력을 갖고 있다고 믿었음
  • 이제는 그 능력이 그대로 유지되지 않는다는 현실을 체감했고, 기억에서 통째로 빠져버린 첫 기술이 SQL이었다는 점이 크게 다가왔음
  • 나이 듦과 기억의 흐름 변화를 공개적으로 적는 일이 쉽지 않았음

자동화 테스트 없이 개발해온 현실

• 지금까지 배포된 코드의 95% 이상이 자동화 테스트 없이 운영되고 있다는 사실을 스스로 인정함
  • 커리어 초기에는 테스트라는 개념을 접하지 못했고, Ember 시절에는 테스트 도구를 제대로 활용하기 어려웠음
• 최근에는 레거시 코드를 다루는 일이 많아 코드를 테스트 가능하게 만들 준비 작업에 충분한 시간을 쓰지 못함
  • 새로 만드는 서브시스템에서만 테스트를 곁들일 수 있었음

• 이 사실을 드러내기 어려웠던 이유

  • 이 고백이 커리어에 가장 치명적인 사실이라고 느껴질 정도로 무거웠음
  • Uncle Bob 기준에서는 테스트 없이 운영되는 코드는 비윤리적이라고 볼 수 있는 태도이며, 그 기준과 자신의 현실 사이의 간극을 직면하는 일이 두려웠음
  • 이 사실이 공개되면 채용 과정에서 불리한 판단으로 이어질 가능성이 커 보여 학습 과정 기록 자체를 미루게 되었음

Blazor를 배우지 못한 이유

• 회사가 Angular에서 Blazor로 전환하기로 하자, 팀에서 C# 경험이 없는 유일한 사람이어서 급히 따라잡기 위해 공부를 시작했었음
• 몇 달 뒤 전환 결정이 철회되자, 학습 동기가 통째로 사라져 책도 끝까지 읽지 못하고 멈춤
• 원래 C#이나 .NET은 사이드 프로젝트에서 쓰고 싶은 언어가 아니었고, 오로지 일을 위해서만 공부했던 흐름이 그대로 드러남

• 이 사실을 적기 어려웠던 이유

  • 이전 글에서 후속을 쓰겠다고 직접 약속해 둔 상태였고, 그 약속을 지키지 못한 채 다른 글을 쓰는 일이 점점 더 불편하게 느껴졌음
  • Blazor 관련 글이 높은 조회수를 기록했기 때문에, 방향을 바꿨다는 사실을 인정하는 일이 패배처럼 보일까 두려웠음

Ruby를 더 쓰고 싶은 마음

• Ruby는 지금도 가장 편하고 즐거운 언어이며, 예제·오픈소스·카타·해커톤 등에서 자연스럽게 손이 가는 언어임
• 그러나 2013년 이후 Ruby로 급여를 받은 적이 단 한 번도 없었고, 업무에서는 TypeScript 같은 언어를 쓰고 있음
• 여러 회사에서 함께 일해 온 동료들이 너무 좋아, 사람을 선택하는 대신 언어는 타협하는 선택을 이어와야 했음
• 퇴근 후와 주말 시간을 Ruby에 쓰고 싶지만, 다른 의무와 학습 목표에 밀려 Ruby를 충분히 쓸 시간이 거의 나지 않는 현실이 이어지고 있음

• 이 사실을 밝히기 어려웠던 이유

  • 매니저와 CTO가 이 블로그를 보고 있어, Ruby를 더 쓰고 싶다는 말이 퇴사 신호로 읽힐까 두려웠음
  • 회사에서 익숙하지 않은 언어를 밀어붙이려는 사람으로 보이고 싶지도 않았음

성인이 되어도 아픈 사이버 괴롭힘 경험

• 한 오픈소스 프로젝트에 LLM으로 만든 작은 패치를 제출하고 그 경험을 온라인 포럼에 공유했을 때,
  무능·역겹다·위협적이다 같은 인신 공격이 폭발적으로 쏟아지는 상황을 맞음
• 이 공격은 사이트를 넘어 다른 웹사이트·이메일·SMS·전화로까지 이어졌고, 안전하지 않다는 감각을 직접적으로 느끼게 했음
• 포럼 관리자에게 실명을 지워달라고 요청했지만, 오히려 더 많은 PII가 프로필에 붙었고,
  외부 연락 이야기를 꾸며냈다는 허위 문구까지 영구적으로 박혀 버리는 상황을 마주함
• 결국 계정을 비활성화하고 사이트를 떠날 수밖에 없었음

• 이 사실을 적기 어려웠던 이유

  • 며칠간 이어진 괴롭힘은 가장 독성이 강했던 온라인 경험이었고, 지금도 그 여파가 남아 있음
  • 이 이야기를 공개하면 가해자들이 다시 찾아올 수 있다는 공포가 계속 됨
  • 프로필에 남은 허위 정보가 고용에 악영향을 줄 가능성까지 떠올라 더욱 말하기 어려웠음

SaaS 팀에 ‘특별한 프로세스’가 필요 없다는 생각

• 소프트웨어 업계에는 수십 년 동안 정제된 프로세스가 이미 있으며,
  Agile과 Lean, Kanban, XP 같은 방식은 이미 검증된 구조로 존재하고 있음
• 한정된 회사 역량을 새 프로세스 창안에 쓰는 대신 제품 개발에 집중해야 한다는 판단이 자연스럽게 자리 잡음

• 이 생각을 말하기 어려웠던 이유

  • 글을 쓸 때는 항상 자신이 잘 아는 주제에 기반해 쓰는 습관을 갖고 있으며, 이 경우에는 같은 회사 동료가 제안한 커스텀 소프트웨어 개발 프로세스가 계기가 되었던 상황임
    • 특정 동료나 그 아이디어를 공개적으로 비판하는 글처럼 보일 위험이 있다고 느꼈음
  • Kent Beck·Martin Fowler처럼 더 나은 협업 방식을 설명하면서도, 동시에 실수한 동료를 정면으로 겨냥하지 않는 글쓰기 능력이 부러움
    • 자신은 아직 그런 균형 감각을 충분히 갖추지 못했다고 느껴, 글쓰기를 망설였음

원격 근무가 실제 협업을 가로막는 방식

• 원격 근무는 많은 문제를 해결해 주지만, 소프트웨어 개발 자체는 함께 있는 공간에서 더 잘 굴러간다는 느낌을 지울 수 없음
• 영상 통화는 저대역폭·저감각 커뮤니케이션이고, 주변적 인식을 잃어 동료의 어려움을 포착하기 힘들어짐
• 도움을 요청하는 일도 더 부담스럽고, 화이트보드·스티키 노트 같은 공간적 사고가 온라인 도구에서 쉽게 깨짐
• 갈등은 모니터 화면 속 사람에게 적 이미지를 씌우기 쉽다는 특성 때문에 더 빠르게 심해짐

• 이 이야기를 적기 어려웠던 이유

  • 코로나 이후 완전 원격 회사가 되었고, 그 덕분에 27에이커 땅과 가족용 젖소까지 있는 삶을 꾸릴 수 있었음
  • 도시로 옮기기 어려운 생활 구조가 생겼기 때문에, 원격 근무를 선호하지 않는다는 말을 하는게
    현재 직장과 앞으로 지원할 모든 원격 직장에서 불리한 인상을 주는 것처럼 느껴졌음

이후 계획

• 이번 글로 두려움을 넘어서는 첫걸음을 다시 밟았다고 느끼며,
  앞으로도 기초 학습을 계속하며 배운 모든 것을 숨김 없이 적어 나갈 계획임
• 비슷한 경험이 있는 사람, 도움을 주고 싶은 사람, 다음 글이 궁금한 사람들에게
  Mastodon·RSS·메일링 리스트를 통해 소식을 전할 수 있도록 안내함

[GN⁺]

Hacker News 의견

• 나는 아주 똑똑한 동료에게서 배운 게 있음. 그는 모르는 걸 두려워하지 않고, 이해될 때까지 계속 질문함. 공개적으로 배우는 데 필요한 자신감과 인내심이 대단하다고 느꼈음
• 글의 겸손함과 솔직함이 마음에 들었음. 모르는 걸 부끄러워할 필요 없음. 37년째 배우고 있지만 여전히 새로운 걸 익히는 중임.
  나도 사무실 근무를 선호하지만, 그게 RTO(사무실 복귀) 를 옹호하는 건 아님. 단지 내 성향일 뿐임.
  업계의 불안감과 가면 증후군이 사람들을 공격적으로 만드는 듯함. 다들 솔직해지면 좀 더 편해질 것 같음.
  그리고 고백하자면, Lisp나 Haskell로 Fibonacci보다 복잡한 걸 써본 적이 없음. 머리가 그 방식으로는 안 돌아감
  • 나는 네가 말한 원격근무 의견에 반대하지만, 그걸 개인적 의견으로 표현했기에 문제없다고 생각함.
    하지만 원문은 자신의 경험을 객관적 진리처럼 일반화해서 표현함. 특히 2인칭 서술이 오만하게 느껴졌음.
    어떻게 말하느냐가 내용만큼 중요함. 원격근무처럼 민감한 주제일수록 표현에 신중해야 함.
    나도 가족의 건강 문제로 원격근무를 해야 했기에, 글의 어조가 가볍게 느껴져 화가 났음.
    결국, 사람들이 과민반응한다고 하기 전에, 자신의 표현이 어떤 영향을 주는지 먼저 돌아봐야 함
  • 나도 Lisp 기반 프로젝트에 참여하기 전엔 Fibonacci 이상을 못 썼음. 매일 쓰다 보니 결국 익숙해졌음
  • 원격근무를 선호한다고 말하면 욕먹는 이유? 코로나 이후 자유를 얻은 사람들이 다시 구속된다고 느끼기 때문임. 그래서 반발이 심한 듯함
  • 요즘 유튜브 코딩 구루들은 뭐든 자신이 옳다고 함. 뭘 해도 틀렸다고 하는 세상임
• 원격근무 얘기를 들을 때마다 IRC 시절이 그리움. 그땐 이미 원격 협업을 잘했음.
  복도 대화 대신 팀 채팅으로 문제를 해결했고, 모두가 적극적으로 도왔음.
  지금은 오히려 도구를 더 잘 쓰지 못하는 느낌임
  • 요즘은 공개 채널에 글 쓰는 걸 두려워하는 사람들이 많음. 예전엔 익명성이 있었지만, 지금은 실명 기반이라 더 조심스러움.
    익명으로 말할 수 있는 공간이 줄어들면서 자유롭게 말하기 어려워진 문화가 생김
  • 예전엔 사무실에서 Slack을 쓸 때가 지금보다 훨씬 효율적이었음.
    그땐 실패하면 그냥 옆자리로 가서 해결했지만, 지금은 실패하면 그냥 끝임
  • 코로나 시절의 원격근무는 진짜 원격근무가 아님. 격리 상태였고, 문화나 프로세스가 준비되지 않았음.
    그래서 사람들은 외로움을 원격근무 탓으로 돌렸음
  • 변화의 원인은 인구통계보다 성격적 변화라고 봄. 예전엔 ‘이상한 아이들’이 많았고, 그들은 질문을 두려워하지 않았음.
    지금은 더 사회적으로 조정된 사람들이 많아져서 비동기 커뮤니케이션에 약함
  • 채팅으로 버그를 고치는 건 ‘같은 공기를 마신다’는 의미와 다름.
    비언어적 신호를 읽는 밀도가 낮기 때문에, 사회적 단서가 줄어듦
• 같은 SaaS 업계에 있어도 완전히 다른 세상에 사는 느낌임.
  많은 개발자들이 흥미보다 커리어 경로를 따라가고 있음.
  SQL은 세 번이나 다시 배웠음. 기술은 계속 변하니까 모든 걸 기억할 수 없음.
  중요한 건 문법이 아니라 문제를 해결하는 능력과 협업력임.
  AI가 이걸 대체하긴 어렵다고 생각함
• 내가 쓴 코드의 95%는 테스트 커버리지 0% 였음. 여러 나라, 여러 회사에서 그랬음. 나만 그런지 궁금함
  • 자동화 테스트는 반복 개발 시 자신감을 주는 도구임. 한 번 익히면 다시는 돌아가지 않음
  • 나도 비슷했지만, 이제는 바꾸려 함. 테스트 없는 프로젝트에 나중에 추가하는 건 정말 어렵음
  • 테스트는 과대평가된 면이 있음. 잘못된 안도감을 주기도 함. 언어 자체가 테스트에 적합하지 않은 경우도 많음
• 주변에 일하는 사람들의 분위기가 집중을 유도함.
  집중의 전염 효과가 있음. 함께 일하는 공간이 생산성을 높임
  • 나도 같은 타입임. 하지만 회사가 ‘클린 데스크 정책’ 을 강요해서 불편함. 개인화된 환경이 필요함
  • 활기찬 카페에서도 비슷한 효과를 느낌. 다른 사람의 생산성이 나를 자극함
  • 이건 ADHD의 ‘바디 더블링’ 과 비슷한 개념임
  • 나도 사무실 근무를 선호하지만 문이 있는 공간이 필수임.
    문은 협업과 집중을 조절하는 최고의 도구임.
    온라인의 ‘away’ 상태보다 물리적 문이 훨씬 명확한 신호임
  • 하지만 모두가 그런 환경에서 잘 일하는 건 아님.
    누군가의 집중을 위해 다른 사람을 강제로 사무실에 불러내는 건 비인간적임
• 이 글은 용감함. 하지만 개인 경험을 일반화하는 문제를 잘 보여줌.
  원격근무가 나쁜 게 아니라, 지원 체계가 나쁜 회사에서 일한 경험일 수도 있음
• 저자는 자신에게 너무 엄격함. 모르는 걸 인정하는 건 해방감을 줌.
  나도 “모르겠음”을 자주 말함. 그게 EQ 높은 사람들의 특징임
  • 상사가 내가 “모르겠음”이라고 말하는 걸 좋아했음. 솔직함이 신뢰를 만듦
  • 직장에서는 괜찮지만, 온라인에서는 평판 걱정 때문에 “모르겠음”을 말하기 어려움
  • 면접에서 git rebase를 물을 때, 기술적 세부보다 실제 활용 능력이 더 중요하다고 생각함
• 저자의 솔직함이 좋았음. 나도 비슷한 경험이 있음.
  Kotlin으로 라이브 코딩하던 중 switch 문법이 생각나지 않아 당황했음.
  매일 쓰던 언어도 금세 잊을 수 있다는 걸 깨달음
  • 나도 switch 문법은 매번 찾아봄. 자주 안 쓰면 잊는 게 당연함
  • 나이 든 개발자가 많아지면 이런 ‘잊음의 순간’ 에 더 관대해질 것 같음
  • 누구나 실수함. 심지어 상사도 붙여넣기 단축키를 잊을 때가 있음
  • 자주 안 쓰면 기술이 빠르게 퇴화하지만, 다시 쓰면 금세 돌아옴.
    개념은 오래 남지만 세부 문법은 금방 사라짐
• 처음엔 글이 AI로 인한 개발자 소멸을 다룰 줄 알았음.
  하지만 실제로는 그 불안을 말하기조차 어려운 분위기임.
  나도 Claude로 코드를 쓰며 즐기지만, 동시에 두려움이 있음.
  우리가 다가올 변화의 본질을 가장 잘 아는 세대라면, 그걸 논의해야 함
  • Claude가 만든 코드가 사람 코드보다 나을 건 없음. 다만 생산 속도를 높여줌.
    문제는, 그게 실력 없는 사람들의 생산성만 높이는 것일 수도 있음
  • 앞으로 몇 년은 우리가 AI 에이전트의 팀리드로 남을 것임.
    하지만 기업이 AI를 관리자 역할로 쓰기 시작하면, 인간 개발자는 설 자리가 줄어듦.
    지금부터 AI 효율 컨설턴트 같은 역할로 전환을 준비해야 함
  • 나는 그냥 AI와 협업하거나 다른 재미있는 일을 할 생각임. 프로그래밍만이 전부는 아님
  • “AI 두머” 정책이 있는 회사라니, 독성 조직 문화임. 당장 새 직장을 찾아야 함