시니어 엔지니어로서 배운 것들 (2021)

• 장기 커리어에서는 잦은 이직이 보상 상승에 유리할 수 있지만, 오래 남아 자신의 코드가 프로덕션에서 살아남는 경험은 다른 종류의 깊은 피드백 루프를 줌
• 문서화와 테스트는 코드 자체보다 왜 그런 선택을 했는지, 왜 다른 선택을 하지 않았는지, 리팩터링 뒤에도 유지되어야 할 동작이 무엇인지를 남기는 수단으로 중요함
• 언어와 타입 시스템 선택에서는 동적 언어의 유연성과 정적 타입의 tooling·리팩터링 이점이 계속 충돌하며, 좋은 설계는 언어보다 경계와 계약을 얼마나 명확히 두는지에 더 크게 좌우됨
• 협업과 근무 방식에서는 공동 화이트보드 같은 즉흥적 상호작용의 가치, 코드 수명의 짧음과 길음이 공존하는 현실, 직장 문화와 보상 구조가 일하는 태도에 미치는 영향이 함께 드러남
• 저축과 은퇴 전략은 미국식 세제 혜택 계좌를 활용한 조기 은퇴 가능성과 함께, 소득·가족 상황·거주 지역·국가 제도 차이에 따라 현실성이 크게 달라짐

---

커리어 성장과 기술 시장

• 이직, 보상, 장기 피드백 루프

  • 다른 회사로 옮기는 방식이 소득 증가에는 자주 유리했고, 18~24개월 정도가 보상 개선의 sweet spot처럼 보였음
  • 4년 뒤 베스팅되는 equity, 내부 승진, 인플레이션을 반영한 급여 인상이 실제 기대에 못 미치는 경우가 많았음
  • 반대로 5년 이상 지난 자신의 코드를 프로덕션에서 보는 경험은 깊이 있는 피드백 루프를 줌
  • 1년 이하의 짧은 재직 반복은 좋지 않게 보일 수 있지만, 2~3년 주기의 이동은 경계선에 가까웠음

• 일반주의자와 시장 보상 문제

  • generalist는 좁은 전문성을 가진 사람보다 전반적으로 저평가되기 쉬움
  • 15년 동안 글로벌 네트워크, VLAN 체계, Entra와 Okta 기반 IAM, JAMF와 InTune MDM, Windows 서버, VMware VCF 데이터센터, AWS/GCP/Azure 테넌트, CapEx와 OpEx 예산 계획, 물리 보안과 인프라, 사이버 보안, 하드웨어, 소프트웨어, 라이선스, 아키텍처, 지원, 온콜까지 맡기도 했음
  • 그 경력에도 현재 시장 가치는 $130k 수준이었고, 2019년과 같은 액수인 데다 그 사이 생활비는 두 배가 되었음
  • 메트로 지역의 중위 임대료가 약 $3500이고, 세후 50/30/20 예산 기준으로도 감당하기 어려움

• 2021년 구직 시장과 현재의 거리감

  • "2주 안에 새 직장을 구한다"는 문장은 지금 기준으로는 aged like milk에 가까움
  • 그 문장은 링크된 Reddit 글에서 가져온 것이고, 5 years ago의 매우 다른 구직 시장을 반영했음
  • 2021~22년은 적어도 유럽에서 고용 시장의 정점이었고, "숨만 쉬어도" 일자리를 구할 수 있을 정도였음
  • 지금처럼 AI를 이유로 대량 해고한 뒤 더 낮은 급여로 재고용하는 경제 환경에서는 장기 투자 조언이 현실적이지 않을 수 있음

• 연봉 100k 신입 가정의 타당성 논쟁

  • 23세에 $100k/yr을 버는 미국 상황은 유럽 개발자에게 놀랍게 받아들여졌음
    • 39세, 업력 17년, 리드 역할, 은행·핀테크·메드테크·컨설팅 경력에도 연 €76k/yr 수준에 그치기도 했음
    • 개인 시간까지 써서 최신 기술을 공부하고 사이드 프로젝트를 해도 연봉은 그 수준에 머물렀음
  • 미국 기술 업계 보상이 세계 다른 지역 수준으로 정상화되면 충격이 클 수 있음
  • 반대로 Indeed 채용 공고 기준으로도 미국의 23세 신입 100k는 outlier일 수 있었음
  • 또 다른 반론으로 mid 2010s의 HCOL 도시 기준 Microsoft는 신입 개발자에게 100-120K를 줬고, Amazon과 Apple은 그보다 더 좋은 오퍼를 주기도 했음

문서화, 테스트, 지식 보존

• 왜를 남기는 문서화

  • 코드 자체를 읽는 것은 가능하지만, 왜 invert_parameters 같은 200줄 함수가 존재하는지, 어떤 문제를 해결했는지, 그 문제가 왜 생겼는지가 더 중요함
  • 코드의 예상 수명, 시간 압박이나 매니저 압박, 상하류 시스템의 이상한 동작 같은 배경을 남겨 두면 미래의 독자가 작성 당시의 사고 맥락을 이해하는 데 도움이 됨
  • 왜 그렇게 했는지뿐 아니라 왜 하지 않았는지도 함께 남겨 두는 것이 중요함
    • 빠르게 동작하는 비최적 해법을 구현하며 남긴 주석이 15년 뒤 제품이 성장한 시점에 다시 읽혀 활용되기도 했음
  • 이런 shadow knowledge는 담당자가 회사를 떠나면 함께 사라지기 쉬워서 남은 사람들이 혼란을 겪게 됨
  • 미래의 자신도 잊어버린다는 전제로 comments, commit messages, 기타 문서에 가능한 한 많은 clues를 남기기도 함

• 테스트의 문서 역할

  • 문서화는 ADR, 시스템 다이어그램, specs, JIRA 티켓, commit message, PR description, code comments, 직관적인 코드 등 여러 형태를 가질 수 있지만, 최신 상태를 유지해야 함
  • 테스트도 문서 역할을 하며, TDD나 BDD 같은 유행어와 별개로 실제 테스트 작성 능력은 명시적으로 훈련되지 않는 경우가 많음
  • 구현 세부에 과도하게 결합되거나 mocks, stubs로 가득 찬 테스트보다, 리팩터링을 견디는 테스트 세트를 만들면 잘 설명된 assertions를 통해 복잡한 루틴의 동작을 문서화할 수 있음
  • 이런 방식은 코드 주석에서 how나 what을 반복할 필요를 줄이고, 코드에서 commits, issue tracker로 올라갈수록 여러 층위의 why를 남기는 구조와 이어짐

• 의도, 이론적 동작, 신규 개발자 관점

  • 비정상 경로 실패 보상, 명확하지 않은 비즈니스 요구 대응, 나중에 고칠 임시 조치 같은 명백하지 않은 의도는 독자와 리뷰어가 반드시 알아야 함
  • 전기 설계 문서가 schematic, parts list, board layout뿐 아니라 theory of operation까지 포함해야 하듯, 소프트웨어도 코드나 UML만으로는 부족함
  • 주요 컴포넌트, 상호작용 이유, 흔한 동작 흐름, 신규 개발자가 가장 가능성 높은 변경을 어떻게 수행할지를 함께 적어야 함

• AI와 문서화 논쟁

  • AI는 코드 조각을 읽고 설명하는 데는 능하지만, 왜 그렇게 구현했는지를 쉽게 역공학하지는 못함
  • 반대로 기술적 이유라면 test suite나 type system 안에 표현되어 있어야 했고, 중요하지 않은 임의적 선택까지 문서화해도 읽히지 않을 수 있음
  • 다시 반대로, 세 가지 실행 가능한 알고리듬 중 하나를 "수학적으로 아름다워 보여서" 골랐다는 메모는 몇 년 뒤 최적화 담당자가 다른 두 가지도 시도해 보게 만드는 실질적 힌트가 됨
  • benchmark tests로 의도를 포착할 수 있지 않겠느냐는 반문도 있었고, premature optimization이 더 흔하므로 추가 코드는 dead weight가 될 수 있다는 시각도 함께 있었음
  • 중요 속성이 모두 테스트된 완전한 시스템을 전제하는 것은 현실의 99.9% 시스템과 맞지 않았고, AI가 코드를 역공학할 때도 맥락 지식이 핵심이었음
  • 반대편에서는 중요한 속성은 전부 테스트해야 하고, 남겨지지 않은 맥락은 인간도 LLM도 복구할 수 없다고 봤음

• 좋은 문서 기준과 LLM 활용

  • 좋은 문서는 다음 기능을 쉽게 구현하게 만드는 문서라는 간단한 기준이 있었음
  • LLM은 문서가 빈약한 코드에서도 내부적으로 추론을 구성해 의미를 복원하는 경향이 있었고, 실제로 코드와 함께 남겨야 할 문서는 그런 추론 과정에서 도달할 법한 내용과 비슷할 수 있음
  • 이런 문서 기준을 모델에 학습시키는 방향이 바람직하다고 봤고, doc-steward라는 GitHub 경로를 실험 중이며 아직 손볼 부분이 많지만 없는 것보다는 나았음

언어, 타입 시스템, 설계 사고

• 동적 언어와 정적 타입에 대한 상반된 경험

  • 나이가 들수록 dynamic languages를 더 좋아하게 된다는 문장에 공감하는 흐름과 함께, Python식 gradual typing은 좋지만 Ruby의 RBS나 Sorbet 방식은 덜 만족스럽게 느껴졌음
  • 반대로 가장 힘들었던 코드베이스가 Python이었고, 리팩터링이 매우 어려웠으며 정적 타입으로 막을 수 있었던 버그가 많았고 성능 문제도 사업에 영향을 줬음
  • 다른 쪽에서는 최악의 코드베이스가 Go였고, 충분히 의욕적인 개발자는 어떤 언어로도 난장판을 만들 수 있으며 타입이 이를 크게 막아주지 못한다고 봤음
  • Python에 basedpyright와 의도적인 type hinting을 결합한 최근 경험은 오랜만에 가장 만족스러웠고, 실제 생산성 면에서 AI보다 더 큰 효과를 느끼게 했음
  • 정적 타입 언어의 장점은 버그 예방보다 tooling 측면에서 더 크게 느껴지기도 했음
    • 입력 A의 형태가 출력 B가 요구하는 형태와 일치하는지 타이핑 단계에서 아는 것이 큰 이점이 됨

• 동적 언어의 역할과 한계

  • PHP로 커리어를 시작하고 인프라 팀에서 많은 리팩터링을 겪은 경우, 동적 언어가 겉보기에는 좋아 보여도 Go 같은 약한 정적 타입 언어가 더 균형 있게 느껴졌음
  • HN 자체가 동적 언어로 만든 중요한 웹사이트라는 점을 들어, 중요한 것은 동적 언어로 만들지 말라는 주장에는 동의하지 않았음
  • Python은 AI에서 orchestration과 glue에 많이 쓰이지만, 실제 AI의 무거운 계산은 Python이 아닌 GPU와 다른 언어 스택이 담당하며, 핵심 추론·학습 로직이 Python으로 작성되었다면 현재 수준의 AI는 없었을 것이라는 반론도 나왔음
  • 자동차 ABS 같은 시스템은 Python보다 더 오류 가능성이 큰 C나 마이크로컨트롤러 어셈블리로 작성되었을 가능성이 높았고, 실제 의도치 않은 ABS 작동을 겪기도 했음

• TDD, 계약, 경계 명시

  • TDD를 제대로 처음 배웠을 때 눈이 뜨이는 경험을 하기도 했고, 같은 프로그램을 두 가지 방식으로 작성해 출력이 일치하는지 보며 요구사항 이해를 검증하는 방법이 실제로 잘 동작했음
  • "TDD is a cult"라는 문장에 일부 공감하면서도, 코드의 개별 부분에 대한 pre-conditions와 post-conditions를 아는 것은 중요함
  • Design-by-Contract는 그 개념을 형식화한 것이며, pre/post conditions뿐 아니라 class invariants도 다룸
  • AI 코드 생성 역시 이런 계약적 경계가 명확할수록 더 잘 작동할 수 있음

• 언어 선택 비유와 Java, Go, Rust 비교

  • "뭘 해야 할지 모르겠으면 Java를 하라. 거의 모든 것에 괜찮은 형편없는 언어"라는 문장에는 강한 공감이 따랐음
  • Rust를 Kotlin, Scala, Clojure가 아니라 Java의 진화형으로 보는 시각도 있었음
  • 이에 대해 Go가 Java와 비슷한 역할을 하며 inheritance와 과도한 함수형 요소가 없다는 시각, Rust는 C++의 후속에 더 가깝다는 시각, Java의 핵심은 ease of use였고 Rust는 그렇지 않다는 반론이 함께 나왔음
  • Java의 context dependency injection과 JSON, JAX-RS 조합은 단순하고 직접적인 백엔드 경험을 줬고, throughput은 좋지만 메모리 사용량은 약간 높았음

• 제약이 설계를 단순하게 만든 사례

  • 공유 호스팅 환경에서 SSH 없음, FTP-only deploys, background workers 없음, Redis 없음이라는 제약 때문에 proper한 job queue, WebSocket, cache layer를 만들지 못했음
  • 결국 시간당 한 번 PHP endpoint를 호출하는 cron job으로 click notifications를 전송하는 단순 구조를 택했고, queue, retry logic, worker process 없이도 6개월 동안 잘 동작했음
  • 처음부터 VPS가 있었다면 지금까지 유지보수 중인 더 복잡한 구조를 만들었을 가능성이 컸고, 호스팅이 "cron과 database만 준다"고 말한 것만으로도 결과적으로 충분했음

협업, 커뮤니티, 일하는 태도

• HN 댓글 가치에 대한 엇갈린 평가

  • HN과 r/programming은 아이디어를 얻고 최신 동향을 파악하는 데 좋지만, 댓글은 거의 가치 없다는 문장이 반복적으로 인용되며 일부 공감을 얻었음
  • "full effect as per usual", "LOL can't disagree" 같은 짧은 공감 표현도 이어졌음
  • 반대로 HN 모더레이터의 rate limit 때문에 하루 몇 번밖에 댓글을 못 쓰게 되자 댓글 읽기를 줄였고, 그 습관을 끊는 것이 오히려 나쁘지 않게 느껴지기도 했음
  • 어떤 이용자는 대부분의 날 댓글을 하나도 쓰지 않고, 써도 하루 두 개 이하라고 하며 참여 방식의 차이를 드러냈음
  • Lobsters는 초대를 받은 적이 없어도 정기적으로 읽을 만한 흥미로운 링크와 댓글이 있었고, 초대 제안, HN과의 토론 차이 비교, 작은 커뮤니티 특유의 익숙한 사용자 관계도 함께 이어졌음
  • 과거 bad behavior로 인한 down-vote 군집 때문에 제한이 걸렸지만, 이후 문제가 없어 제한이 풀렸다는 답변을 HN에 이메일로 받아 보기도 했음

• 원격 근무와 공동 화이트보드

  • 재택근무는 좋지만 whiteboarding이 부족하다는 점은 "유일하게 그리운 것"으로 꼽히기도 했음
  • 개인 화이트보드나 Teams류 도구의 공유 화이트보드 앱으로도 같은 문제를 해결할 수 있음
  • 하지만 핵심은 개인 보드가 아니라 공동 화이트보드였고, 소프트웨어 대체재가 있어도 직접 함께 서서 즉흥적으로 스케치하는 경험과는 달랐음
  • drawing tablet이 모두에게 보급되기 전까지는 온라인 화이트보딩이 충분히 자유롭지 않다는 인식도 있었음
  • 분기마다 1주일씩 팀이 직접 모이는 방식은 꽤 괜찮은 균형이었고, 사람들이 방 안에 모여 아이디어를 브레인스토밍하고 보드에 낙서하던 경험은 좋은 기억으로 남았음

• 코드 수명과 중요성에 대한 상반된 회고

  • 커리어 전체를 돌아보면 자신이 쓴 코드 가운데 significance가 있었던 것은 거의 0%에 가깝게 느껴지기도 했음
  • 30년 넘게 코드를 써 왔지만 5년 넘게 운영에 남아 있는 코드가 거의 없었고, 90년대 OOP를 배우며 쓴 형편없는 코드가 오히려 오래 살아남았으며, 2018~2021 스타트업에서 쓴 훌륭한 코드는 회사와 함께 사라지기도 했음
  • 반면 10년 뒤에도 돌아가며 10억 AUD 이상을 처리했고 유지보수가 거의 없었던 PHP 마이크로프레임워크 기반 프로젝트를 자랑스럽게 떠올리기도 했음
  • 10년 남짓 일했는데 자신이 쓴 코드 대부분이 아직 운영 중이라고 느끼는 사람도 있었고, 수백만 명 또는 수천 명 사용자가 쓰는 코드의 품질과 성능이 중요하다고 보는 사람도 있어 평가는 갈렸음
  • 어떤 경우에는 코드의 평균 half-life가 3~4년 정도였고, 15년 동안 같은 서비스의 백엔드가 Groovy on Grails → Java → Java → Python으로 네 번 재작성되기도 했음
    • 2026년의 Python 코드도 1996년 Perl과 JavaScript로 하던 것과 본질적으로 크게 다르지 않은 CRUD 앱이라는 냉소도 있었음

• 직장 문화와 태도

  • 비기술 직군에서 얻은 교훈으로, 똑똑한 사람만큼 똑똑해지지 못해도 괜찮고, 무능한 사람들과 일하는 데 익숙해져야 하며, 직장은 친구를 만들기 좋은 장소이고, 신화 같은 job satisfaction보다 급여 극대화와 산출 최소화가 낫고, 가장 중요한 요소는 luck이라는 다섯 가지 목록이 있었음
  • 직장을 9-to-5로만 여기고 문서화나 장기 품질을 챙기지 않는 태도에는 비판이 있었고, 반대로 건강보험과 생계 때문에 잘못된 인센티브 게임을 할 수밖에 없는 노동자를 비난할 수 없다는 시각도 함께 있었음
  • "bring your authentic self"라는 문화에서도 직장에서는 결국 professional해야 함
  • 기술 업계에 여성이 충분하지 않고, 여성과 흑인 엔지니어를 더 격려하고 돕고 싶지만 무엇을 더 해야 할지 모르겠다는 대목도 있었음
  • 현재 기술 업계 thought leaders가 공개적으로 믿고 말하는 것을 보면 이런 현실을 더 잘 이해하게 된다는 코멘트도 이어졌음

• 형식과 어조

  • 혼자 와인을 마시며 글을 쓰는 장면은 이상하게 받아들여졌고, 위스키·보드카·맥주가 더 보통이라는 농담으로 이어졌음
  • 오타와 흐트러진 문장 구조가 alcohol induced unordered thoughts를 더 잘 살린다는 평가도 있었음
  • 술은 매우 개인적인 일이라 거의 항상 혼자 마시는 편이고, 피아노를 공개적으로 연주하는 일은 오히려 이상하게 느껴질 수 있음
  • Sonoma의 대형 와인 회사에서 일할 때는 혼자 와인을 마시는 사람이 많기도 했음
  • 술을 마시고 삶을 돌아보는 일은 드문 일이 아니며, Bukowski, Faulkner, Kerouac 같은 이름도 함께 떠올릴 수 있음
  • 반대로 실제 취중 글이라기보다 의도적으로 오타와 "pour another drink", "take a sip"을 섞은 literary device처럼 보여 이상하다는 비판도 있었음
  • "HR이 전문적 의무를 정하지 않는다"는 전제에서는, 술에 취해야 이렇게 솔직할 수 있는 사람은 senior나 mentor가 아니라 초기 알코올 중독자이자 겁쟁이에 가깝고, engineer 타이틀도 거짓이며 data science일 뿐이라는 공격적인 해석까지 가능했음

• 기타 비유와 반박

  • 약사 인터뷰가 유기화학 퀴즈를 보지 않는다는 비유에는, 약사는 인터뷰 전에 특별 학위와 수년의 공부, 시험을 거치며 실제로 유기화학 비중도 높다는 정정이 뒤따랐음
  • HN 댓글은 쓸모없는 경우가 많지만, Apple CEO change 같은 글에서는 댓글이 본문보다 나은 경우도 있음

저축, 은퇴, 세제 전략 논쟁

• 초기 절세·저축 전략

  • 20대에 6 figures를 버는 사람에게 401k 최대 납입, HSA 최대 납입, IRA 최대 납입, 생활비 6~12개월치 고금리 저축계좌 확보를 권하는 구체적 조언이 나왔음
  • 401k와 HSA, IRA 자금은 target date retirement fund에 투자하라는 제안도 포함됐음
  • 일부 회사는 401k를 자사주 중심으로 배정할 수 있으니 자산 배분을 확인해야 했음
  • HSA는 의료비를 현금으로 지불하고 영수증을 보관한 뒤 은퇴 시 상환받는 전략이 제시됐음
  • 23세에 시작하고 연봉 $100k/yr이면 45세 은퇴가 가능하다는 계산도 나왔음

• 현실성과 생활 조건에 대한 반론

  • 이 전략이 성립하려면 검소함, 저렴한 취미, 자녀 없음, 무직 배우자 없음, 가족 부양 부담 없음, 비싼 지역 회피 같은 전제가 필요했음
  • Ohio에서 외벌이로 아이를 키우며 45~50세 은퇴 궤도에 있고, 매달 $1,000 이상 기부도 하고 있지만 크게 놓치고 산다는 느낌은 없다는 응답도 있었음
  • 그 경우는 미국 상위 15% 소득자에 가까운 특권적 조건이었고, $80k 이하를 버는 많은 프로그래머에게는 적용하기 어렵다는 반발도 있었음
  • 이에 대해서는 수입 범위 안에서 살고 가능하다면 소득의 15% 를 저축하라는 답이 돌아왔음
  • 미국 프로그래머가 $80k 혹은 심지어 $100k 미만이라면 은퇴 계획의 1단계는 새 직장을 찾는 것이지만, 지금은 그만큼 쉽지 않고 일자리 자체에 감사해야 하는 상황에 가까움
  • 가족과 자녀가 있어도 완전히 불가능한 것은 아니라는 점을 강조했고, 두 부모가 비슷한 급여를 벌면 45세 은퇴도 가능하지만 대학 자금을 위한 더 많은 tax-advantaged 계획이 필요하며 비싼 도시에는 잘 맞지 않을 수 있음

• 조기 은퇴 자금 규모와 생활비 계산

  • 45세에 은퇴하려면 약 $1M으로는 부족하다는 시각이 있었음
  • 반대로 $1.8M-$2.2M, 연 6%-7.5% 수익률, employer contribution 제외 기준이면 연 $72k-$88k를 인출할 수 있고, 67세에 social security를 받기 시작하면 자산이 계속 유지된다는 계산도 있었음
  • 45세 은퇴가 social security에 큰 영향을 주지 않느냐는 질문에는, 월 약 $3800 대신 $2500 정도를 받게 되어 연 $77k가 $107k/yr 수준이 되며, 더 중요한 것은 은퇴 계정이 계속 성장하도록 돕는다는 계산이 이어졌음
  • 연 $40,000으로도 살 수 있을 것 같아도, property tax나 응급실에서 몇 바늘 꿰매는 데 $40k가 드는 상황까지 고려해야 함
  • 영국 사용자는 병원비가 £0라고 받아쳤음

• 조기 인출 메커니즘과 계좌 운용

  • 45세 은퇴를 하려 해도 자금을 59.5세까지 인출할 수 없는 은퇴 계좌에 묶어 두면 어렵다는 지적이 있었음
  • 이에 대해 SEPP 72t disbursements, Roth conversion ladders, 조기 인출 패널티 납부 같은 방식으로 더 일찍 쓸 수 있다는 설명이 나왔음
  • 연간 지출 규모에 버퍼와 지붕 교체, 노후 차량, 건강 문제 같은 알려진 liabilities를 더해 계획해야 했고, ProjectionLab 같은 도구와 전문가 도움을 권하기도 했음
  • SEPP 72T는 최소 5년 또는 59.5세까지 유사한 인출을 유지해야 하며, 5년 동안 SEPP와 비과세 혜택 없는 계좌를 병행하고 동시에 Traditional 계정에서 Roth 전환을 진행한 뒤, 5년이 지나면 전환한 금액을 인출하는 방식이 소개됐음
  • 이 계획을 설명한 사람은 20대에 늦게 기술 업계에 들어와 45세가 아니라 50ish 은퇴를 목표로 했음
  • "rule of 55", Roth contributions의 연령 제한 없는 패널티 없는 인출, HSA에서 저장한 의료 영수증을 통한 환급도 조기 인출 전략에 포함됐음
  • HSA와 FSA는 다르며, 65세 이후 HSA 인출은 패널티가 없고 일반 소득으로 과세됨

• 401k, Roth, 과세 계좌의 상대 가치 논쟁

  • RRSP/401k는 자금을 묶고, 세금을 가장 적게 내고 싶은 시점으로 미루며, 미래 세율이 더 높을 수 있으므로 employer match 한도까지만 넣고 그 이상은 넣지 않는 편이 낫다는 주장이 있었음
  • 반대로 미국에서는 역사적으로 세율이 올라가기보다 내려왔고, 은퇴 시에는 401k와 Roth를 섞어 인출해 과세 구간을 낮출 수 있으며, 세전 자금이 먼저 복리로 성장하는 효과가 비과세 혜택이 없는 계좌보다 유리하다는 계산이 제시됐음
  • broker 계좌는 급여 시점에 세금을 내고, 인출 시 cost basis에 대해 또 세금을 내는 구조로 비교됐음
  • 미국 사례에서는 부부가 401k를 최대 납입해 약 50k 세금을 유예하고, 가구 소득 300k에서 그 금액이 24% marginal rate였다고 가정할 때, 은퇴 후 두 배로 늘어난 50k 인출에 12% 세율을 적용하면 88k를 손에 쥐게 됨
  • 반대로 비과세 혜택 없는 계좌는 처음에 24%를 내고 38k를 투자해 두 배가 되면 76k가 됨
  • 캐나다 관점에서는 RRSP/401k 인출 시 투자 수익 전체가 일반 소득으로 과세되지만, 비등록 투자 계좌는 capital gains로 marginal tax rate의 50% 만 과세되므로 더 나을 수 있다는 반론이 나왔음
  • 캐나다 쪽에서는 $50k를 S&P500에 30년 투자하면 약 $872k가 되고, RRSP에서는 전액이 소득으로 과세된다는 계산도 있었음
  • 이에 대해서는 캐나다 특화 계산기를 써 보라는 권유가 있었고, 미국에서는 401k, Roth, 비과세 혜택 없는 계좌를 혼합하는 방식이 실제 조기 은퇴 계획에 유리했다는 경험도 나왔음
  • 401k에서 Roth로 전환한 뒤 5년 후 페널티 없이 인출하는 401k/Roth conversion ladder를 이해하고 나서 생각이 바뀌었다는 경우도 있었음
  • 캐나다 사용자는 RRSP, TFSA, FHSA, 비등록 투자 계좌의 세제 차이를 정리하며, RRSP는 은퇴 전 인출이 불가능하다고 적었음
  • TFSA는 Roth와 비슷해 보이고, RRSP에서 TFSA로 비슷한 방식의 전환이 가능하다면 더 이른 시점에 자금에 접근할 수 있음
  • 정부 일 경험을 다소 부정적으로 쓴 원문과 달리, 457(b) 는 늘 감사할 만한 제도이기도 했음
  • "이건 나쁜 금융 조언"이라는 단호한 비판도 있었음

• 미국과 유럽의 제도 차이

  • 독일 사용자는 미국의 tax-advantaged retirement funds를 매우 부러워했고, 독일의 정부 의무 연금은 붕괴 직전의 사기처럼 느껴지며 평균 근로자는 65/67세 이전 은퇴가 사실상 불가능하다고 봤음
  • 조기 은퇴 시 생애 연금의 매달 0.5% 가 삭감되고, 401k, Roth, IRA 같은 제도도 없다고 했음
  • "이게 다 무슨 뜻이냐"는 질문에 대한 답은 은퇴를 미리 계획하고 정부·고용주 지원 저축 수단을 활용하라는 것이며, 유럽에도 이런 제도는 많았음
  • 스위스에서는 국가 1기둥, 고용주가 동일액을 자주 부담하는 의무 민간 2기둥, 선택적 3a 기둥이 있었고, 2·3기둥은 주거용 부동산 구입이나 창업에도 사용할 수 있으며 60세 은퇴 계획과 연 10주 유급휴가, 90% 근무 체제 사례도 나왔음
  • 또 다른 유럽 사용자는 국가 연금 나이가 기대수명 증가에 맞춰 계속 뒤로 밀리고 있어 70대에나 은퇴할 수 있을지 모르며 제도를 신뢰하기 어렵다고 했음
  • 독일·프랑스에서는 임금의 20% 를 의무 납부해도 연금을 못 받을 수 있다는 비관도 있었음
  • Poland에는 IKE와 IKZE가 있으며, IKE는 60세까지 유지하면 세금을 내지 않고 stocks나 bonds에 투자할 수 있음
  • Germany와 일부 국가는 사실상 쓸모없는 보험·원금보장 옵션 외에는 선택지가 거의 없고, 투자하려면 세후 자금으로 넣고 인출 시 capital gains를 내야 함
  • UK는 National Insurance 기반 state pension, 2012~2018년 도입된 auto-enrollment private pension, 기본 5% employee + 3% employer 납입, salary sacrifice, SIPP, ISA, LISA 등으로 은퇴 저축 구조가 나뉨
  • Netherlands에서는 사적 연금이나 은퇴 전 인출 불가 은행 계좌에 추가 저축하면 wealth tax를 내지 않고 인출 시에만 세금이 붙거나, 납입액이 tax deductible인 경우도 있었음
  • 유럽 전반에 six figures가 불가능하다는 식의 일반화는 성립하지 않았고, 국가마다 제도가 달랐음

[heycalmdown]

본문 내용이 좀 이상하네요? Hacker News 의견들에 따로 모여서 나와야 할 내용이 본문에 들어있는데... 방향성이 바뀌신건가.

[wedding]

generalist에 대한 내용 공감합니다. 저도 신입땐 제너럴리스트가 되어야지~ 했는데

1. 하나만 잘하기도 벅차고
2. 대우가 진짜 짜더라구요.

[GN⁺]

Hacker News 의견들

• 소프트웨어 엔지니어를 하면서 비슷한 사고방식을 가진 사람들을 만난다는 말은 내 경험과는 좀 달랐음. 내가 만난 사람 50명 중 1명 정도만 장인정신 때문에 이 일을 하는 느낌이었고, 대부분은 그냥 9-to-5와 가시성, 임팩트 있는 프로젝트를 원할 뿐 깊게 자기 문제와 의견을 나누지는 않았음

  • 이 글이 2021년 글이라는 점이 중요해 보임. COVID 이전 분위기는 저자 설명과 더 가까웠고, 2010년쯤은 더 그랬던 기억임. 특히 돈만 보고 들어온 개발자가 크게 늘었고, 회사들도 다른 동기를 서서히 죽여온 느낌이 강했음. 10년, 15년 전과 비교하면 차이가 꽤 선명했고 2000년대는 더 거칠었다는 얘기도 들었음
  • 나는 반대로 공유 문화를 강하게 느꼈음. 마케팅에 있을 때는 다들 출근해서 일하고 퇴근하고, 점심엔 새 리포트나 영업팀 알고리즘 욕만 했음. 그런데 개발자가 되고 나서는 누가 새 plugin을 보여주고, 재밌는 로직 게임을 추천하고, 새 JS framework를 같이 만져보자고 하는 식으로 진짜 커뮤니티 안에 들어온 느낌이었음. 점심이 브레인스토밍이 되고, 냅킨에 미친 듯이 적어가며 문제를 같이 풀고, 컨퍼런스나 DefCon 얘기를 하는 문화가 있었음. 사이드 프로젝트도 늘 화제였고, 친구와 멘토들 덕분에 처음으로 developer community에 속한다는 자부심과 소속감을 느꼈음
  • 내 비결은 Emacs meetups에 가는 것임. Emacs를 돈 벌려고 쓰는 사람은 거의 없다고 봄
  • 이게 꼭 소프트웨어 엔지니어만의 특징인지는 잘 모르겠음. 다만 원글 작성자는 술기운에 좀 감상적이었던 것 같다는 느낌임
  • 나는 오히려 academia에서 비슷한 마음을 가진 사람을 더 잘 찾았음

• “2주 안에 새 직장 구함” 같은 말이 참 그 시절 느낌임. 그때는 직원 쪽이 시장을 쥐고 있어서 다들 전문가 행세를 하던 분위기였음

  • 지금 기준으로 보면 정말 우유처럼 빨리 상한 전망 같음
  • 나는 그 문구를 기사에서 못 찾겠어서, 정확히 뭘 인용한 건지 궁금했음

• “영웅을 직접 만나지 말라, 5천 달러짜리 강의를 듣고 보니 그 사람도 우리처럼 즉흥적으로 해나가더라”는 말에 완전 공감했음

  • 어릴 때는 성인이 되면 어느 순간 딸깍 하고 세상을 이해하게 될 줄 알았음. 그런데 그런 일은 없었고, 결국 누구에게도 그런 순간은 없다는 걸 깨달았음. 다들 그냥 커다란 아이처럼 돌아다니며 알아가는 중일 뿐이었음. 누군가는 좀 더 빨리 알아가고, 누군가는 알아가길 멈출 뿐임. 그래도 세상이 이 정도로 굴러간다는 게 오히려 끈기와 야심의 증거처럼 느껴졌음. 한편으로 나는 내 영웅 몇 명에게 직접 연락도 해봤는데, 그 경험은 늘 짜릿하고 formative했음. 괜찮은 이유가 있다면 직접 닿아보는 걸 추천하고 싶음
  • 내 업계에서 꽤 유명하고 발표도 하고 블로그도 하고 다른 사람 책에도 인용되던 사람과 함께 일한 적이 있음. 그런데 코드는 기대에 한참 못 미쳤고, SDLC는 더 심했음. 유명세에서 오는 자아가 팀 기반 작업과 잘 안 맞는 경우가 있는 듯했음. 그 사람은 코드 리뷰나 PR 같은 기본 절차를 마치 헤이그에 끌려가는 것처럼 표현했고 팀원들을 관료주의자로 봤음
  • 결국 모두가 추측하는 중이고, 어떤 사람들은 그걸 조금 더 잘할 뿐이라는 생각임

• 엔지니어에게 가장 과소평가된 능력은 문서화라는 말에 내 생각을 덧붙이자면, 문서에는 무엇보다 왜를 남겨야 함. 코드는 읽을 수 있지만, 200줄짜리 invert_parameters 같은 함수가 왜 생겼는지, 무슨 문제를 풀었는지, 왜 그런 문제가 있었는지, 이 코드가 얼마나 오래 살아남을 예정인지가 궁금함. 나는 가끔 시간 압박이나 이상한 업스트림 문제 때문에 이렇게 썼다는 사과성 코멘트까지 남김. 특히 자명하지 않은 코드일수록, 작성 당시의 사고방식을 그려줘야 코드만으로는 안 보이는 맥락이 살아남음. 주니어든 시니어든 직장에서 이런 걸 더 많이 했으면 좋겠음

  • 나는 진짜 과소평가된 능력은 테스트라고 봄. 문서는 ADR, 시스템 다이어그램, 스펙, JIRA 티켓, 커밋 메시지, PR 설명, 코드 코멘트, 관용적인 코드 등 여러 형태가 있지만 유지보수 부담이 큼. 테스트도 낡으면 깨지지만, 잘 만든 테스트는 구현이 리팩터링돼도 살아남으면서 훌륭한 문서 역할을 함. mock과 stub로 가득 채우기보다, 잘 설명된 assertion으로 복잡한 루틴이 어떻게 작동하는지 보여주면 코드 주석에서 how나 what을 반복할 필요가 줄어듦
  • 나도 강하게 동의함. 나는 보통 의도 문서화라고 표현함. 기능 구현처럼 의도가 뻔하면 설명이 필요 없지만, 숨은 장애를 보정한다든가, 분명하지 않은 비즈니스 요구에 대응한다든가, 나중에 고칠 임시 코드를 넣는다든가 하는 경우엔 읽는 사람이 그 의도를 알아야 함. 안타깝게도 많은 사람이 기계만 보고 독자와 리뷰어의 관점을 생각하지 않는 점이 답답했음
  • 슬프지만 나는 이런 암묵지가 실제로 기록되는 걸 거의 못 봤음. 보통 그 지식을 가진 사람이 회사를 떠나면 같이 사라지고, 남은 사람들만 머리를 긁적이게 됐음
  • 지금은 AI 시대라서 더 중요해졌다고 느낌. AI는 코드를 읽고 설명하는 데는 능숙하지만, 왜 그렇게 했는지의 이유를 역으로 추론하는 건 쉽지 않음
  • 나는 뭐가 가장 과소평가됐냐고 하면 상황에 따라 다르겠지만, 현실적으로는 허세와 포장이 아닐까 싶음. 엄청난 시스템을 묵묵히 만들고 문서화해서 수년간 안정적으로 돌려놓는 엔지니어들을 많이 봤지만, 그런 사람들은 가치 인정은 받아도 꼭대기까지 올라가진 못했음. 반면 포장 잘하는 사람들은 천장이 없었음. 모르는 것도 안다고 하고, 불가능한 것도 가능하다고 하고, 남 얘기 흘리고 깎아내리며 책임을 초월해 버림. 제일 잘하는 사람들은 거의 사이코패스급이고, 그런 사람들이 세상을 굴린다는 냉소가 들 정도였음

• 20대에 연봉 10만 달러 이상 버는 사람이 있다면, 401k와 HSA부터 최대한 채우고 IRA까지 꽉 채우라는 조언은 정말 중요하다고 봄. 전부 target date retirement fund에 넣고, 생활비 6개월에서 12개월치는 high yield savings account에 두라는 식의 기본 원칙도 괜찮아 보였음. 23살부터 시작하면 45세 은퇴도 가능하다는 취지였고, 나중에 미루면 45살에 아직도 20년 더 일해야 한다는 현실을 맞을 수 있다는 경고였음

  • 다만 이 전략으로도 45세 은퇴는 쉽지 않다고 봄. 검소한 생활, 싼 취미, 자녀 없음, 비경제활동 배우자 없음, 가족 부양 부담 없음, 비싼 지역 회피 같은 전제가 너무 많이 붙음. 아니면 거의 캠핑하듯 살아야 할 수도 있음
  • 하지만 그 돈을 은퇴 계좌에 묶어두면 59.5세 전엔 인출이 제한되는데, 45세 은퇴를 어떻게 하느냐는 의문이 생김
  • 이런 조언에 부정적 반응이 많은 게 오히려 신기했음. 좋은 초봉을 받는 사회초년생에게는 굉장히 실용적인 가이드라고 느낌
  • 나는 유럽 사람이라 이 미국식 절세 계좌 얘기가 정확히 무슨 뜻인지 궁금했음
  • 게다가 청춘을 즐기기 위한 지출을 빼더라도, 6자리 연봉이라 해도 막 10만 달러를 조금 넘는 수준인 젊은 층은 대개 HCOL 도시에 살아서 실제로는 남는 돈이 많지 않다는 점도 큼

• 내가 배운 가장 유용한 교훈은, 내가 일부러 만든 제약보다 내가 선택하지 않은 제약이 오히려 더 나은 제품 결정을 이끈다는 점이었음. 나는 공유 호스팅에서 링크 단축기를 돌리는데 SSH도 없고 FTP 배포만 되고, 백그라운드 워커도 Redis도 없음. 뭔가 제대로 된 큐나 WebSocket, 캐시 레이어를 넣으려 할 때마다 호스팅이 안 된다고 해서 그냥 안 했음. 그래서 클릭 알림은 한 시간에 한 번 PHP endpoint를 때리는 cron으로 보냄. 큐도 재시도 로직도 워커도 없고, 보내지거나 실패하거나 둘 중 하나이며 결과만 로그로 남김. 6개월 써보니 잘 돌아갔음. 처음부터 VPS가 있었다면 지금까지 관리해야 할 무언가를 더 크게 만들었을 텐데, 공유 호스팅이 “cron과 DB만 줌”이라고 선을 그어준 덕분에 그걸로 충분하다는 걸 배웠음

• 원글에는 꽤 여러 문제점이 보였음. 혼자 와인을 마시는 건 좀 특이하고, 보통은 위스키나 보드카나 맥주 쪽이 더 전형적이라는 생각임. ‘ever thing’ 같은 철자는 술 마신 상태의 정돈 안 된 생각 같아서 오히려 그 분위기와 맞았음. 그리고 webdev를 전문가의 대표처럼 보긴 어렵고, dark mode는 브라우저 확장으로 해결되는 경우가 많다고 느낌. 약사는 학위와 오랜 공부, 시험, 유기화학이 필요한 직업이고, HN 댓글이 무가치하다는 말도 과하다고 봄. 어떤 글은 형편없어도 댓글이 본문보다 나을 때가 꽤 많았음

  • 나는 술이 꽤 개인적인 행위라고 느껴서 거의 늘 혼자 마셨음. 피아노를 공개적으로 치는 게 이상하게 느껴졌던 것과 비슷한 감각이었음
  • 나도 Apple CEO 교체 같은 대중적 주제에서 쓸모없는 댓글이 많아지는 걸 본 적이 있어서, 다른 사람도 그걸 느꼈다는 게 재밌었음. 아마 주제의 대중성이 영향이 컸을 듯함
  • Sonoma 근처에 안 살아보면 와인 문화 감각이 좀 다를 수도 있겠다는 생각임
  • 술에 대한 그 코멘트 자체가 오히려 이상하게 들렸음

• 관련 글로 2021년 5월의 Drunk Post: Things I've Learned as a Sr Engineer가 떠올랐음. 댓글이 494개나 달린 글이었음

• 이 글이 2021년이라는 게 놀라웠음. SQL 얘기나 2주 만에 이직 같은 분위기가 너무 2014년 감성처럼 느껴졌음

  • 무슨 뜻인지 되묻고 싶었음. 적어도 유럽에서는 2021년에서 2022년이 고용시장 정점이었고, 숨만 쉬어도 채용되던 시기였음. SQL도 여전히, 특히 데이터 분야에서는 아주 중요하다고 봄
  • 나는 오히려 SQL이 언제부터 덜 중요해졌는지 궁금했음

• “HN과 r/programming은 대략적인 아이디어와 최신 동향 파악엔 좋지만 댓글은 거의 무가치하다”는 말과 관련해, 나는 HN 운영진에게 rate limit을 당한 뒤 댓글을 잘 안 읽게 됐음. 하루에 몇 번밖에 답글을 못 다니 참여 자체를 못 하니 읽을 동기가 줄었음. 대놓고 밴하지 않고 속도를 늦추는 식이라 더 미묘하게 불청객이 된 기분도 들었음. 혹시 놓치는 게 많을까 걱정했지만, 댓글을 확인하고 싶은 그 습관적 끌림을 끊는 게 생각보다 나쁘지 않을 수도 있겠다고 봤음

  • 나는 여기 참여하고 있다고 느끼지만, 대부분의 날에는 댓글을 하나도 안 쓰고 지나감. 써도 하루에 두 개 이하인 경우가 많아서, 꼭 많이 써야 참여하는 건 아니라고 느낌
  • 나는 Lobsters 초대를 못 받았어도 꾸준히 읽음. 참여를 못 해도 흥미로운 링크와 댓글은 충분히 얻을 수 있다고 봄
  • 나도 비슷한 일을 겪어서 hn에 메일을 보냈고, 예전에 안 좋은 행동으로 다운보트 클러스터가 잡힌 적이 있지만 그 뒤로 문제 없어서 제한을 풀었다는 답을 받았음. 생각보다 간단히 해결됐음