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

• 10년 경력의 데이터 엔지니어가 술에 취한 상태에서 커리어, 기술, 동료, 삶에 대해 솔직하게 적은 글로, Reddit r/ExperiencedDevs에 원래 게시되었던 글의 보존본
• 기술 스택 자체보다 각 분야의 10~20가지 핵심 원칙이 중요하며, 스택은 그것을 쉽게 만드는 도구에 불과
• 커리어 성장의 가장 효과적인 방법은 이직이며, 불만족스러운 직장에 머무를 이유가 없음
• 좋은 코드란 주니어 엔지니어도 이해할 수 있는 코드이고, 최고의 코드는 코드가 없는 것
• 자기 가치를 보상이나 직급에 연결하지 말 것, 친절함과 노력이 장기적으로 커리어와 삶 모두를 바꿔줌

---

나는 술에 취해 있고 아마 후회하겠지만, 지난 10년간 엔지니어로서 배운 것들의 취중 랭킹을 적어본다.

• 커리어를 발전시킨 가장 좋은 방법은 회사를 옮기는 것
• 기술 스택은 크게 중요하지 않음 — 데이터 분야에는 약 15가지 기본 패턴이 존재하고, 모든 분야에 10~20개의 핵심 원칙이 있으며, 기술 스택은 그것을 쉽게 만드는 도구일 뿐이니 너무 걱정하지 말 것
• 사람들이 이직을 추천하는 데는 이유가 있음 — 직장에 불만이 있다면 떠날 때
• 회사에서 좋은 평생 친구를 만들기도 했지만, 그것이 모든 직장의 요건이 될 필요는 없음 — 친구 없이도 행복했던 직장, 좋은 친구가 있어도 불행했던 직장 모두 경험
• 매니저에게 적당히 솔직해지는 법을 배움 — 너무 솔직하진 않되, 직장에서 진정성을 유지할 정도로. 최악의 경우? 해고? 2주면 새 직장을 구함
• 분기에 한 번 이상 새벽 2시에 온콜로 깨는 상황이면, 심각한 문제가 있는 것이므로 고치든지 그만두든지 해야 함

한 잔 더 따르며

• 좋은 매니저의 자질은 좋은 엔지니어의 자질과 많이 겹침
• 처음 시작했을 때는 기술과 프로그래밍과 컴퓨터 과학에 매료되었지만, 이제는 그 시절이 지남
• 좋은 코드는 주니어 엔지니어가 이해할 수 있는 코드, 훌륭한 코드는 CS 1학년도 이해 가능, 최고의 코드는 코드가 아예 없는 것
• 엔지니어로서 가장 과소평가된 스킬은 문서화 — 좋은 문서 작성법을 알려주는 사람이 있다면 진심으로 돈을 내겠음, 1천 달러짜리 강좌라도 좋은 문서를 쓸 수 있게 보장해 준다면 지불 의향
• 위와 관련하여, 변경 사항에 대한 좋은 프로포절 작성도 훌륭한 스킬
• 거의 모든 종교 전쟁 (vim vs emacs, mac vs linux 등)은 중요하지 않음… 하나만 빼고. 아래 참조
• 나이가 들수록 동적 언어에 대한 감사함이 커짐. 맞다, 내가 말했다. 덤벼라
• 방에서 가장 똑똑한 사람이라고 느끼는 순간이 있다면, 떠날 시기
• 풀스택 웹 개발자가 왜 이렇게 적게 받는지 이해 불가 — 프런트엔드, 백엔드, 브라우저 호환성, 네트워킹, 데이터베이스, 캐싱, 웹과 모바일 차이, 끊임없이 나오는 새 프레임워크까지 전부 이해해야 함. 기본 연봉 50만 달러는 받아야 함
• 인턴을 더 많이 채용해야 함 — 에너지 넘치고 아이디어 가득한 녀석들. 질문하고 비판할 줄 아는 인턴이 최고

한 모금

• 영웅을 만나지 말 것 — 영웅의 5천 달러 강좌를 들었는데, 그는 훌륭한 사람이지만 결국 나머지 사람들처럼 즉흥으로 하고 있었음
• 기술 스택이 중요하기도 함 — Python 개발자 vs C++ 개발자를 떠올리면 전혀 다른 이미지, 특정 도구가 특정 작업에 특화되어 있기 때문. 뭘 해야 할지 모르겠으면 Java를 하면 됨 — 별로인 언어지만 거의 모든 것에 괜찮음
• 최고의 프로그래밍 언어는 Lisp. Lisp를 배워야 함
• 초보자에게 가장 수익성 높은 언어는 SQL — 다른 언어 다 필요 없음. SQL만 알면 돈을 벌 수 있음. 급여 담당자 50k → SQL 아는 급여 담당자 90k. 조직력 있는 평범한 직장인 40k → SQL까지 아는 사람은 PM이라 부르고 150k
• 테스트는 중요하지만 TDD는 컬트
• 안정적인 공무원 직장은 기대만큼 좋지 않음 (초중반 경력 기준) — 120k + 복지 + 연금은 좋아 보이지만 독점적 기술에 영혼을 팔게 됨. 엔지니어 평균 연령이 50+인 이유가 있음. 정부 계약직에는 해당 안 됨
• 서드파티 리크루터는 기생충 — 그러나 좋은 리크루터를 찾으면 관계를 키울 것. 3년 이상 서드파티 리크루터를 한 사람은 보통 별로, 좋은 사람들은 대기업 리크루터로 전환
• 스톡옵션은 무가치하거나 백만장자를 만들어 줌 — 엔지니어링 인원이 100명 이상이 아니면 보통 무가치
• 재택근무는 최고. 그러나 화이트보드 부재가 아쉬움
• FAANG에서 일해본 적 없음 — 뭘 놓치는지 모르겠지만, FAANG 출신을 면접하고 채용해 봤는데 그들도 뭘 하는지 모르긴 마찬가지
• 자기 가치는 총 보상과 상관없고 상관있어서도 안 됨 — 자본주의는 자기 가치를 판단하는 좋은 기준이 아님
• 매니저는 생각보다 권한이 훨씬 적음 — 누군가를 해고하지 않는 이유는 못하기 때문
• 직급은 대부분 중요하지 않음 — 어느 회사의 Principal Distinguished Staff Lead Engineer든 상관없음. 중요한 것은 무엇을 했고 무엇을 달성했는가
• 직급 관련 추가: 커리어 초기(10년 미만)에는 직급 상승이 좋음 — 스킬과 책임 성장. 커리어 후반에는 직급 하향이 유리 — 같은 보상을 받으면서 승진 시 급여 인상 가능
• 401k를 최대한 채울 것
• 모든 사람에게 친절할 것 — 커리어에 도움이 되기 때문이 아니라(도움 되긴 하지만), 친절함 자체가 보상이기 때문
• 지난 한 달간 주니어 엔지니어나 인턴에게서 배운 것이 없다면, 주의를 기울이지 않은 것

이런, 와인이 다 떨어졌다.

• 수업, 책, 컨퍼런스에 돈을 쓸 가치 있음 — 여러 컨퍼런스, 1.5k짜리 강좌, 많은 책, 구독에 투자했고 가치 있었음. 이렇게 하면 뭘 하는 척 더 잘할 수 있음
• 진심으로, 웹 개발자들은 왜 더 못 받는 건지? 그들은 모든 걸 알잖아!!!
• 손목터널과 허리 문제는 농담이 아님 — 지금 1천 달러 써서 좋은 장비를 구할 것
• 함께 일했던 가장 똑똑한 사람은 수학 박사 — 그에게서 정말 많이 배움. 잘 지내고 있길 바람
• 고등학교 때 절친이었던 여자 친구 이야기 — 사귄다는 소문에 그녀가 무시하기 시작. 기분이 좋지 않았지만 악감정은 없으며, 그때 더 잘 대처했어야 함
• 8학년 때 여자친구와 헤어지고 싶었지만 말하지 못하고 무시하기 시작 — 정말 나쁜 행동이었음. Lena에게 미안함
• 소프트웨어 엔지니어의 가장 좋은 점은 같은 방식으로 문제를 생각하는 사람들을 만나고 대화할 수 있다는 것. 같은 취미가 아니라 같은 사고방식
• 기술 업계에 여성이 충분하지 않음 — 조직 내 여성 엔지니어를 격려하고 돕고 있지만 더 무엇을 해야 할지 모름
• 흑인 엔지니어도 마찬가지
• 기술을 깊이 알게 되기 전에는 싫어한 적이 없음 — 싫어하면서도 동시에 클라이언트에게 추천할 수 있다면 좋은 기술. Jenkins은 끔찍하지만 추천해도 소프트웨어 과실은 아님
• git은 끔찍하지만 선택의 여지가 없음 — GUI 도구는 지옥이고, 커맨드 라인이 나음. 외울 명령어는 7개 정도, 나머지는 구글 검색
• 데이터 엔지니어니까 데이터 관련 교훈도 하나. Pandas 쓰지 마라
• 팀에 반기술적(semi-technical) 애널리스트가 있어 일이 더 쉬움 — 프로그래밍은 알지만 소프트웨어 엔지니어링은 모르는 사람들. 그들이 이해 못하면 설계가 잘못된 것. 가장 뛰어난 엔지니어보다 애널리스트들에게서 더 많이 성장
• 다크 모드는 라이트 모드 강제 전환 시 고통 — 그래서 라이트 모드 사용
• 보안에 대해 아는 것은 보안을 잘 모른다는 것을 아는 정도

이런, 와인이 다 떨어졌다.

• 좋은 엔지니어는 베스트 프랙티스를 아는 것, 시니어 엔지니어는 베스트 프랙티스를 언제 깨야 하는지 아는 것
• 버그나 장애에 책임을 돌리려는 환경이면 떠날 시기
• 진보적 회사, 특히 스타트업은 "진짜 자신을 가져오라"고 하지만 — 진짜 자신이 포르노 시청이 전부라면? 일과 사생활 사이에 건강한 경계를 유지하는 것이 중요
• 동료와 해피아워에서 술 마시는 건 좋아하지만, 차라리 아이들, 가족, 친구와 시간을 보내겠음
• 최고의 리더십 사례: 리더가 100% 본인 잘못인 실수의 책임을 대신 짐 — 그 리더를 위해서라면 불 속이라도 뛰어들 것
• 같은 맥락에서, 최고의 리더들은 본인의 의견을 대변하는 동시에, 충돌하는 다른 의견도 설명해 줌. 그들처럼 되려고 노력 중
• 사이드 프로젝트는 집어치워라 — 좋아한다면 해도 됨! 시간이 있어도 Reddit에 취중 글 쓰느라 너무 바쁨
• 알고리듬과 자료구조는 중요 — 하지만 한도가 있음. 약사 면접에서 유기화학 퀴즈를 내지 않듯, 업계의 면접 프로세스에 문제가 있음
• DevOps 엔지니어들은 정말 똑똑함. 최소한 그 사람들은 제대로 보상받는 편
• 좋아하는 일을 하는 것보다 싫지 않은 일을 하는 것이 더 중요
• 제품에 가까이 있을수록, 매출에 가까울수록 가치를 인정받는 느낌이 강함 — 기술적 수준과 무관, 가장 진보적인 회사에서도 마찬가지
• Linux는 중요 — Windows 환경에서도. 왜? 결국 Linux를 쓰게 되기 때문. 주말에 Arch 설치하며 놀았던 시간에 감사
• "빅 데이터" 같은 모호한 버즈워드를 경계해야 함 — Spark/Kafka에서 10분마다 1만 행 스트리밍도, Python/MySQL에서 시간당 10억 행 배치도 경험했는데, 라벨은 의미 없음
• 실리콘밸리 밖에도 좋은 직장은 있지만, 많은 좋은 직장이 실리콘밸리에 있음

맥주를 찾았다. 계속 가자.

프로그래밍 언어에 대해

• 한때 싫어했던 언어(C#)를 쓰기 시작하니, 여전히 싫지만 유용함을 인정
• 싫어했던 언어(C#)를 떠났다 돌아오니 크게 발전해 있었음
• 함수형 언어의 가장 큰 장점은 함수가 일급 객체라는 것, 그리고 모든 프로그래머가 그걸 안다는 것
• 아무리 뛰어나거나 우월한 언어라도 사람들이 안 쓰면 의미 없음
• 언어를 배우는 것은 어렵지 않음 — 어려운 것은 에코시스템을 배우는 것

동료에 대해

• 페어 프로그래밍은 훌륭하지만, 시간이 많이 들고 — 회사는 보통 그 시간을 쓰고 싶어하지 않음
• 똑똑한 엔지니어와 일하면 더 나은 코더가 됨. 똑똑한 비기술 동료와 일하면 더 나은 엔지니어가 됨
• 9시-5시 이외에 일하지 말 것 — 단, 멋진 프로젝트가 진행 중이고 몰입 상태라면 예외. 그건 최고
• 팀 간 해피아워와 소셜 타임의 99%는 그냥 수다. 하지만 1%는 중요한 프로젝트의 중요한 코드에 대한 이야기이고, 사교 자리에서 일 이야기를 꺼낸 덕에 큰일을 막은 경험 있음. 다른 팀과 어울려야 한다는 뜻이 아니라 그냥 유대감을 원하는 것이고, 부수 효과가 있을 뿐

재택근무에 대해

• 반 원격/반 사무실 환경에서 원격 직원이 이등 시민 취급받는지 확인 필요 — 주요 결정이 "물 마시러 가서" 이루어지면, 회사 문화를 바꾸거나(어려움) 원격 직원을 일급 시민으로 대우하는 다른 회사로 이동
• 재택의 두 번째 최악의 단점은 화이트보드 없음
• 재택의 최악의 단점은 동료에게서 배우기 어려운 것 — 자신감 있게 질문할 수 있고, 원격 직원이 현장 직원과 동등한 문화가 아니라면, 커리어 초반 5년은 사무실 근무가 나았음

기술에 대해

• 기술은 변한다는 것은 모두 알지만, 지난 10년간 극적으로 변했어도 기본 원칙은 크게 변하지 않음 — 특히 해당 분야에 적용되는 기본 원칙
• Hacker News와 r/programming은 전반적인 아이디어와 최신 동향 파악에만 유용, 댓글은 거의 쓸모없음
• 강한 의견을 가진 아마추어가 많고, "존경받는" 저널과 블로그에 실린 글도 마찬가지 — 소문은 파악하되 스스로 판단해야 함
• 최첨단 스타트업에서 일하지만 ABC 최첨단 기업이 발표한 최신 XYZ 기술은 안 씀 — 그들이 발표하는 것은 엔지니어링의 극히 일부이고, 대부분은 우리와 같은 기술 사용
• 그러나 징후를 읽어야 함 — 모던 기술을 쓰고 싶은데 회사가 여전히 jQuery 위주로 개발 중이라면 재평가할 시기

데이터 엔지니어링에 대해

• 데이터 엔지니어니까 데이터 특화 조언/경험을 추가
• SQL이 왕 — MySQL, Postgres, Oracle, SQL Server, SQLite 모두 여전히 최강. 새 기술을 써도 대부분 전이 가능
• 대부분의 회사는 스트리밍을 하지 않음 — 어렵고 복잡함. 10년 경력에 초당 1만 건 처리를 못해도 일자리는 있음
• Airflow는 별로, 그렇다. 다른 제품도 있지만 Airflow가 가장 널리 사용됨
• 머신러닝 프로젝트는 실패 가능성이 높음 — 복잡하고 구현이 어려움. 안 믿긴다고? ML 모델의 유닛 테스트 작성이 얼마나 쉬운지 생각해 볼 것
• 이 분야는 아직 새로움 — 데이터 엔지니어링에 좋은 책이 없음, 그냥 직접 해봐야 함. 부트캠프로는 안 됨. 10년 후에는 바뀔 가능성

삶에 대해

• 사람은 죽음 — 코드가 레거시가 되길 원한다면 시간을 쏟을 것. 하지만 나처럼 레거시가 가족, 친구, 주변 사람이라면 코드에 너무 집착하지 말 것
• 좋은 사람도, 똑똑한 사람도, 좋은 코더도 나쁜 코드를 작성함 — 코드 품질을 자기 가치의 종속 변수로 만들지 말 것
• 취미로 시작한 기술이 직업이 되면서 취미가 사라짐 — 기술이 더 이상 취미가 아님을 받아들이고 새 취미를 찾거나, 즐기려면 직장을 그만둬야 함
• 프로그래밍과 CS는 약 80년 된 학문 — 다른 공학 분야에 비하면 우리 모두 뭘 하는지 모르는 상태
• 꽤 괜찮은 돈을 벌고 있음 — 감사하고 아끼며 저축할 것

기타

• 여러 팀이 수년간 쓰는 대규모 플랫폼과 라이브러리를 만들었지만, 가장 뿌듯했던 코드는 자신만 쓰는 작은 스크립트
• 커리어에서 가장 자랑스러운 성취는 다른 사람들이 일을 더 잘하도록 도운 것 — 아마 피플 매니저가 될 운명이라 그런 것이고, 다른 사람에게는 도움이 안 될 수도 있음
• 구직 시 LinkedIn을 만들고 업데이트했지만 별로인 답변만 받고 삭제. 지금은 LinkedIn으로 채용 후보를 찾음 — LinkedIn은 노이즈가 많고, 그 노이즈에 기여하는 것이 업무의 일부이기에 가치가 있을 뿐
• 대학 때 자신을 좋아하는 여자를 알게 됨 — 낮은 자존감 때문에 안 믿었지만 데이트 신청을 받음. 정중히 거절했고, 19살에 성숙하게 "아니오"를 말할 수 있었던 것이 인생에서 가장 자랑스러운 순간 중 하나
• r/cscareerquestions는 에고와 잘못된 정보의 늪 — 그 사람들을 흔들어 세상이 진짜 어떤지 설명하고 싶지만 믿지 않을 것

지금 느끼는 감정들

• 술에 취해 있고 평소에 안 마시는 편이라, 하는 말이 전부 민망하거나 끔찍할 것 같음
• 사람들이 저축하고 투자해야 한다고 강하게 느낌 — 6자리 연봉이면 401k를 최대한 채울 것
• 항상 싫어했던 것이 되어 버림 — 기술 업계에서 일하지만 실생활에서는 기술을 피하는 사람. 나이가 들면 그런 건지도
• r/ExperiencedDevs는 꽤 괜찮은 커뮤니티. 모더레이터들에게 감사. 받는 것보다 훨씬 적은 감사를 받고 있음
• 커리어, 연봉, 인생을 Reddit에 빚지고 있음 — 주유소에서 최저임금을 받던 상태에서 Linux, SQL, Python, C# 등을 배워 현재 위치에 도달. Reddit은 욕을 많이 먹지만 커뮤니티들이 빈곤에서 벗어나게 해줌
• 아이는 좋음 — 선택으로 아이가 없음. 아이를 사랑하지만 어떤 아버지가 될지 두렵기 때문. 이 글에서 너무 개인적인 이야기인가?
• 누군가 누구를 존경하냐고 물었을 때 Conan O'Brien이라고 답했더니 비웃음. 하지만 진심이었음 — Tonight Show 마지막 방송에서 "친절하고 열심히 일하라"고 한 그 말이 인생의 어려운 시기에 들렸고, 잃을 것도 없으니 그대로 실천. 10년 넘게 친절했기에 훌륭한 사람들을 만났고, 열심히 일하고 새로운 것을 시도해서 인생이 무한히 나아짐. 심야 토크쇼 덕분에 인생의 충만함을 얻었다는 게 우스울 수 있지만, 내 인생이고 어떤 성공이든 심야 TV의 코미디언 덕분이라고 당당히 말할 것

만취 상태이니 제가 한 말은 무시하세요. 장광설 죄송합니다.

[heycalmdown]

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

[xguru]

요 몇일 프롬프트 개선중이라 오락가락 했네요. 바로 잡아놨습니다 ㅠ

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