술 취한 글: 시니어 엔지니어로서 배운 것들 (2021)

• 경력 성장에는 회사 이동이 효과적이며, 직함보다 실제로 무엇을 했고 무엇을 이뤘는지가 더 중요함
• 좋은 코드는 주니어도 이해할 수 있는 단순함을 갖고, 가장 좋은 코드는 불필요한 구현을 줄인 코드가 없는 형태에 가까움
• 문서화와 변경 제안서 작성 능력은 과소평가되기 쉬운 핵심 기술이며, TDD나 문제 풀이 중심 채용 평가는 과도하게 신봉되거나 왜곡되기 쉬움
• 기술 스택 집착보다 핵심 원칙과 도구 적합성이 더 중요하며, 데이터 엔지니어링에서는 SQL과 관계형 데이터베이스가 여전히 중심 축임
• 원격 근무, 보상, 리더십, 협업, 인간관계 전반에서 친절과 저축, 사람을 돕는 태도, 제품과 매출에 가까운 역할의 가치가 반복해서 강조됨

---

경력과 이직

• 경력 발전에는 회사 이동이 가장 효과적이라는 판단
  • 현재 직무에 만족하지 못한다면 구직 활동이 합리적 선택이라는 인식
• 회사마다 평생 가는 친구를 얻을 수는 있지만, 동료와의 친분을 모든 직장의 필수 조건으로 둘 필요는 없다는 경험
  • 동료와 친하지 않아도 만족스럽게 일한 적이 있었고, 좋은 친구가 있어도 불행했던 적이 있었다는 대비
• 매니저에게는 과하지 않더라도 정직함을 유지해야 하며, 일터에서도 어느 정도 진정성을 갖는 편이 낫다는 판단
  • 해고되더라도 새 일자리를 곧 구할 수 있다는 인식 포함
• 새벽 2시에 깨는 온콜 호출이 분기당 한 번을 넘으면 심각한 이상 신호로 간주
  • 그 경우 직접 고치거나 회사를 떠나는 선택 필요
• 직함은 대체로 중요하지 않고, 실제로 무엇을 했는지와 무엇을 이뤘는지가 더 중요함
  • 경력 초기에는 Junior→Mid→Senior 같은 직함 상승이 기술과 책임 확장에 유리
  • 경력 후반에는 더 낮은 직함으로 들어가 같은 보상을 받고 이후 승진으로 급여를 올리는 방식도 유리

좋은 엔지니어와 시니어 엔지니어

• 좋은 엔지니어와 좋은 매니저의 자질은 상당 부분 겹침
• 좋은 코드는 주니어 엔지니어가 이해할 수 있는 코드이며, 훌륭한 코드는 컴퓨터공학 1학년 학생도 이해할 수 있는 코드
  • 가장 좋은 코드는 코드가 없는 형태, 즉 불필요한 구현을 줄인 방향
• 좋은 엔지니어는 모범 사례를 알고, 시니어 엔지니어는 그 모범 사례를 언제 깨야 하는지 아는 사람이라는 구분
• 방 안에서 자신이 가장 똑똑한 사람이라고 느껴지면 떠날 시기라는 기준
• 지난 한 달 동안 주니어 엔지니어나 인턴에게 배운 것이 없다면 스스로 주의 깊게 보지 못한 것이라는 인식

문서화, 제안서, 테스트

• 엔지니어가 배워야 할 가장 과소평가된 기술로 문서화 지목
  • 좋은 문서를 쓰는 법을 배우고 싶고, 확실히 익힐 수 있다면 비용을 지불할 의향까지 언급
• 변경 사항에 대한 좋은 제안서 작성 역시 매우 중요한 기술
• 테스트는 중요하지만 TDD는 과도하게 신봉되는 문화로 평가
• 알고리듬과 데이터 구조는 중요하지만, 채용 과정에서 과도한 문제 풀이 위주 평가는 업계의 왜곡이라는 인식
  • 다른 전문직 면접에서 사소한 전공지식 퀴즈를 묻지 않는다는 비교 포함

기술 스택과 기술 선택

• 기술 스택 자체는 크게 중요하지 않으며, 분야마다 10~20개 정도의 핵심 원칙과 기본 패턴이 더 중요하다는 관점
  • 데이터 분야에서는 대략 15개의 기본적인 소프트웨어 엔지니어링 패턴이 반복된다고 봄
• 동시에 도구 적합성은 분명 존재하며, Python 개발자와 C++ 개발자라는 표현이 서로 다른 이미지를 주는 이유도 여기에 있다는 판단
• 무엇을 할지 모르겠다면 Java 권장
  • 거의 모든 일에 무난하게 쓸 수 있는 언어라는 평가
• 최고의 프로그래밍 언어로 Lisp를 꼽으면서도 정작 본인은 더 배워야 한다고 언급
• 나이가 들수록 동적 언어를 더 높게 평가하게 되었다는 인상
• 최신 기술을 무조건 쓸 필요는 없으며, 최첨단 스타트업도 외부에 보이는 최신 XYZ 기술을 전사적으로 쓰는 경우는 드물다는 경험
  • 대외 발표에 나오는 기술은 전체 엔지니어링 조직의 작은 일부인 경우가 많다는 지적
• 반대로 회사가 아직도 개발 대부분을 jQuery에 의존한다면 재평가가 필요하다는 판단
• 모호한 유행어인 big data 같은 표현에는 경계 필요
  • 10분마다 1만 행 스트리밍을 Spark와 Kafka로 처리한 경험
  • Python과 MySQL로 시간당 10억 행 배치를 다룬 경험
  • 이런 사례를 통해 레이블보다 실제 특성이 중요하다는 인식

프로그래밍 언어에 대한 관찰

• 한때 C# 을 싫어했지만 실제로 사용한 뒤에는 여전히 싫어하면서도 유용하다고 평가
• C#을 떠났다가 돌아왔을 때 언어가 많이 개선되었다는 체감
• 함수형 언어의 가장 큰 장점으로 함수 일급 객체와 그 개념을 공유하는 개발자 문화 언급
• 아무리 뛰어난 언어라도 사람들이 쓰지 않으면 큰 의미가 없다는 판단
• 언어 학습 자체보다 생태계 학습이 더 어렵다는 경험

데이터 엔지니어링

• 데이터 엔지니어링 분야에서는 SQL이 가장 수익성 있고 여전히 핵심이라는 평가
  • SQL만 알아도 높은 보상을 받을 수 있다는 예시 제시
  • Payroll specialist가 SQL을 알면 5만 달러에서 9만 달러 수준으로 뛰는 예시
  • 대기업에서 정리 능력만 있는 사람은 4만 달러 수준, 여기에 SQL이 더해지면 PM로 불리며 15만 달러를 받을 수 있다는 예시
• MySQL, Postgres, Oracle, SQL Server, SQLite 같은 관계형 데이터베이스가 여전히 최상위 위치
  • 새 기술을 써도 상당 부분 전이 가능하다는 판단
• 대부분의 회사는 스트리밍 처리를 하지 않으며, 스트리밍은 어렵고 복잡함
  • 경력 10년차여도 초당 1만 레코드 처리를 모른다고 걱정할 필요는 없다는 인식
• Airflow는 불만이 많아도 가장 널리 쓰이는 도구라는 평가
• 머신러닝 프로젝트는 실패 가능성이 높음
  • 구현이 복잡하고 어렵고, 머신러닝 모델의 유닛 테스트 작성 난이도를 그 근거로 제시
• 데이터 엔지니어링은 비교적 새로운 분야라 좋은 책이 아직 없고, 직접 해보며 익혀야 한다는 인식
  • 부트캠프로 배우기 어렵고, 향후 10년 안에 정리될 가능성을 언급

동료, 협업, 팀 문화

• 페어 프로그래밍은 좋지만 시간이 많이 들고, 회사가 그 시간을 보통 원하지 않는다는 현실
• 똑똑한 엔지니어와 일하면 코더로서 성장하고, 똑똑한 비기술 동료와 일하면 엔지니어로서 더 크게 성장한다는 경험
• 준기술적 분석가들, 즉 프로그래밍은 알지만 소프트웨어 엔지니어링은 전문이 아닌 동료들이 큰 도움
  • 그들에게 이해되지 않으면 설계가 좋지 않을 가능성이 높다는 검증 역할
  • 가장 뛰어난 엔지니어들보다 이 분석가들에게 더 많이 배웠다는 평가
• 인턴을 더 많이 채용해야 하며, 에너지와 질문이 큰 가치라는 인식
  • 비판하거나 의문을 제기할 수 있는 인턴을 특히 높게 평가
• 근무 시간 외에는 일하지 않는 편이 좋지만, 본인이 원하고 몰입되는 프로젝트가 있을 때는 예외 허용
• 팀 간 해피아워나 사교 시간은 대부분 친목 목적이지만, 가끔은 중요한 프로젝트 정보를 비공식적으로 공유하는 장점도 존재
• 소프트웨어 엔지니어의 가장 좋은 점 중 하나로 비슷한 방식으로 사고하는 사람들을 만날 수 있다는 대목
  • 스포츠나 TV 취향이 아니라 문제를 바라보는 사고 방식의 유사성 강조

리더십과 매니저

• 매니저는 생각보다 권한이 훨씬 적다는 판단
  • 왜 누군가를 해고하지 않느냐는 질문의 답이, 실제로는 그럴 수 없기 때문인 경우가 많다는 인식
• 훌륭한 리더십의 가장 좋은 예로, 100% 자신의 실수였던 일을 리더가 대신 책임진 경험 제시
  • 그런 리더를 위해서라면 무엇이든 할 수 있다는 정도의 충성심 형성
• 함께 일한 최고의 리더들은 자신의 의견을 대변해 주는 동시에, 그와 충돌하는 다른 의견도 설명해 준 사람들
• 사람들을 더 나은 업무 수행자로 돕는 일이 커리어에서 가장 자랑스러운 성취라는 고백
  • 사람 관리자로 향하는 성향과 연결

원격 근무와 사무실 근무

• 재택근무 자체는 매우 좋지만, 화이트보딩 부재는 큰 단점
• 재택근무의 가장 큰 단점으로 동료에게서 배우기 어려움 지목
  • 질문할 자신감과 적극성 필요
  • 원격 근무자가 현장 근무자와 동등하게 취급되는 문화 필요
  • 커리어 첫 5년은 현장 근무가 더 나았다고 판단
• 회사가 반은 원격, 반은 출근 체제라면 원격 근무자가 이등 시민처럼 취급되지 않는지 확인 필요
  • 주요 의사결정이 물리적 현장에서 비공식적으로 이뤄지면 문화 개선이 어렵고, 다른 회사로 옮기는 편이 나을 수 있다는 판단

보상, 주식, 돈 관리

• 총보상은 자기 가치와 상관관계가 없다는 관점
  • 자본주의는 자기 가치를 판단하는 좋은 방식이 아니라는 판단
• 스톡옵션은 거의 무가치하거나 백만장자를 만들 수 있지만, 대체로 무가치할 가능성이 크다는 평가
  • 엔지니어링 인원이 100명 이상이면 10년 안에 가치가 생길 수도 있다는 조건부 판단
• 401k는 최대한 불입해야 한다는 조언을 여러 차례 반복
• 돈을 꽤 잘 벌고 있으므로 감사와 저축이 필요하다는 인식
• 수입이 6자리라면 가능한 한 401k를 최대치로 채워야 한다는 강한 확신

교육, 학습, 커뮤니티

• 수업, 책, 컨퍼런스 비용 지출은 충분히 가치 있음
  • 여러 컨퍼런스, 1.5천 달러 수준의 코스, 다수의 책, 구독 서비스를 이용한 경험 포함
• 영웅처럼 여긴 사람의 5천 달러짜리 코스를 듣고, 결국 그도 다른 사람들처럼 즉흥적으로 해 나간다는 인식을 얻음
• Hacker News와 r/programming은 전반적 흐름 파악과 최신 정보 확인에는 유용하지만 댓글 가치는 낮다는 평가
• 기술에 대해 강한 의견을 가진 시끄러운 아마추어가 많고, 존중받는 저널과 블로그에도 그런 글이 실릴 수 있다는 인식
  • 소문은 따라가되 최종 판단은 스스로 해야 한다는 태도
• LinkedIn은 잡음이 많다는 평가
  • 구직 때는 응답이 좋지 않아 삭제
  • 이후 회사 채용을 위해 후보자 탐색에 사용하면서, 자신의 역할 일부가 그 잡음 생성에 기여하는 일이라는 자조 포함
• r/cscareerquestions는 자아 과시와 잘못된 정보가 많은 공간으로 평가
• r/ExperiencedDevs는 좋은 커뮤니티로 평가하며, 운영진에 대한 감사 표명
• Reddit 커뮤니티가 최저임금 주유소 일자리에서 벗어나 Linux, SQL, Python, C# 등을 배우고 현재 커리어에 이르기까지 큰 역할을 했다는 개인사 언급

업계와 직종에 대한 시각

• 풀스택 웹 개발자는 보상이 지나치게 낮다는 강한 주장
  • 프론트엔드, 백엔드, 브라우저 차이, 네트워킹, 데이터베이스, 캐싱, 웹과 모바일 차이, 새로운 프레임워크까지 모두 알아야 한다는 이유 제시
  • 기본급 50만 달러 수준을 받아야 한다는 과장된 표현까지 포함
• DevOps 엔지니어들은 매우 똑똑하며, 적어도 보상은 제대로 받는다는 인식
• FAANG에서 일한 적은 없지만, FAANG 출신을 채용하고 탈락시켜 본 경험상 그들도 모든 것을 아는 것은 아님이라는 판단
• 실리콘밸리 밖에도 좋은 일자리는 있지만, 좋은 일자리의 상당수는 여전히 실리콘밸리에 있다는 인식
• 정부의 안정적인 일자리는 특히 초중반 경력 엔지니어에게 기대만큼 좋지 않다는 평가
  • 12만 달러, 복리후생, 연금은 매력적이지만 난해한 독점 기술에 묶일 수 있다는 판단
  • 그런 조직의 엔지니어 중간 연령이 50세 이상인 이유가 있다고 언급
  • 이 조언은 정부 계약직에는 적용하지 않음
• 서드파티 리크루터는 대체로 기생적 존재로 평가
  • 다만 좋은 리크루터를 만나면 관계를 잘 유지하는 것이 커리어 초반 발판이 될 수 있음
  • 3년 이상 서드파티 리크루터로 남아 있으면 오히려 좋지 않을 가능성이 높고, 좋은 사람은 대기업 내부 리크루터로 이동하는 경향 언급
• 제품과 가까울수록, 그리고 매출 기여와 가까울수록 자신의 가치가 더 크게 느껴진다는 경험
  • 가장 진보적인 회사에서도 그 경향을 느꼈다고 언급

다양성, 친절, 인간관계

• 기술 업계에는 여성이 충분하지 않다는 문제의식
  • 조직 내 여성 엔지니어들에게 더 격려하고 도움을 주려 했지만, 무엇을 더 해야 할지는 모르겠다는 고백
• 흑인 엔지니어 역시 충분하지 않다는 문제의식
• 모두에게 친절해야 하며, 커리어에 도움이 되기 때문만이 아니라 친절 자체가 보람 있기 때문이라는 태도
• Conan O’Brien이 마지막 Tonight Show에서 말한 친절하게 일하고 열심히 노력하라는 조언이 삶에 큰 영향을 줬다는 회고
  • 어려운 시기에 그 말을 보고 실제로 그렇게 살기로 결심
  • 친절 덕분에 뛰어난 사람들을 만나 배웠고, 열심히 일하며 새로운 것을 두려워하지 않아 삶이 훨씬 나아졌다는 연결
• 아이들은 훌륭하지만, 자신은 어떤 아버지가 될지 두려워 의도적으로 자녀를 두지 않음

개발 도구와 기술 취향

• 기술이나 언어를 진심으로 싫어하게 되는 시점은 오히려 그것을 깊이 알게 된 뒤라는 경험
  • 싫어하지만 고객에게 추천할 수 있다면 좋은 기술일 수도 있다는 기준
  • Jenkins는 싫지만 새 고객에게 추천해도 소프트웨어 직업윤리 위반은 아닐 것 같다는 표현
• git은 끔찍하지만 선택권 없이 사용해야 하는 도구로 평가
  • GUI git 도구보다 명령줄 선호
  • 외워야 할 명령은 7개 정도이고 나머지는 검색하면 된다는 실용적 태도
• 보안은 조금 알수록 자신이 모른다는 사실만 더 분명해진다는 인식
• 다크 모드는 좋지만 일부 웹페이지나 미지원 앱 때문에 밝은 모드를 강제로 써야 하는 순간이 불편
  • 그 이유로 아예 라이트 모드를 사용한다는 선택
• Linux는 전부 Windows 환경에서 일할 때도 중요하다는 경험
  • 결국 Linux 환경에서 일하게 되었고, 주말에 Arch를 설치하며 놀던 시간이 유용했다는 회고

인생과 자기 인식

• 사람은 죽고, 자신의 유산을 코드에 둘지 가족과 친구에 둘지 선택해야 한다는 관점
  • 코드가 유산이라면 거기에 많은 시간을 써도 되지만, 그렇지 않다면 지나치게 집착할 필요는 없다는 판단
• 좋은 사람도, 똑똑한 사람도, 좋은 코더와 좋은 엔지니어도 나쁜 코드를 작성할 수 있음
  • 코드 품질을 자기 가치와 연결하지 말아야 한다는 조언
• 기술과 코딩이 취미였는데 일이 되면서 취미가 망가졌다는 감각
  • 기술이 더 이상 취미가 아니라고 받아들이거나, 새로운 취미를 찾아야 한다는 결론
• 프로그래밍과 컴퓨터과학은 약 80년 정도의 짧은 역사밖에 없어, 다른 공학 분야와 비교하면 집단적으로 아직 무엇을 하는지 완전히 모른다는 인식
• 좋아하는 일을 하는 것보다, 싫어하지 않는 일을 하는 편이 더 중요하다는 기준
• 술자리의 동료 관계는 좋아하지만, 여가 시간은 동료보다 아이, 가족, 친구와 보내고 싶다는 선호
• 자신이 한 말이 대부분 민망하거나 형편없을 수 있다고 인정하면서도, 저축과 투자, 친절과 노력의 중요성만큼은 강하게 확신

개인적 회고와 기타 단상

• 여러 팀과 사람들이 오랫동안 사용한 대형 플랫폼과 라이브러리를 만들었지만, 가장 자랑스러웠던 코드는 오히려 자신만 쓰던 작은 스크립트
• 수학 박사 출신 상사에게서 매우 많이 배웠고, 그가 잘 지내길 바란다는 회고
• 고등학교와 중학교 시절 인간관계를 잘 처리하지 못했던 기억을 꺼내며 미안함 표명
• 대학 시절 자신을 좋아한다고 한 사람의 고백을 성숙하게 거절한 일을 삶의 자랑스러운 순간 중 하나로 기억
• 술에 취한 채 쓴 글이라 자신의 말은 걸러 들으라는 단서를 여러 차례 달았지만, 동시에 업계와 삶에 대한 감정은 매우 강하게 표출
• 기술 업계에서 일하지만 현실에서는 기술을 피하는 사람이 되어, 예전의 자신이 싫어하던 모습이 되었다는 자각
• 데이터 엔지니어 경력 10년 이상인 보존자는 SQL의 중요성, 기술 스택 집착의 과장, 최고의 코드는 코드가 없는 것이라는 부분에 특히 동의
  • 다만 동적 언어에 대한 평가는 유일하게 이견 표명

[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에 메일을 보냈고, 예전에 안 좋은 행동으로 다운보트 클러스터가 잡힌 적이 있지만 그 뒤로 문제 없어서 제한을 풀었다는 답을 받았음. 생각보다 간단히 해결됐음