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

3 hours ago 2

(luminousmen.substack.com)

  • 경력 성장에는 회사 이동이 효과적이며, 직함보다 실제로 무엇을 했고 무엇을 이뤘는지가 더 중요함
  • 좋은 코드는 주니어도 이해할 수 있는 단순함을 갖고, 가장 좋은 코드는 불필요한 구현을 줄인 코드가 없는 형태에 가까움
  • 문서화와 변경 제안서 작성 능력은 과소평가되기 쉬운 핵심 기술이며, 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의 중요성, 기술 스택 집착의 과장, 최고의 코드는 코드가 없는 것이라는 부분에 특히 동의
    • 다만 동적 언어에 대한 평가는 유일하게 이견 표명
Read Entire Article