2018년 Talking Points 최적화

 (rachelbythebay.com)
2P by GN⁺ | ★ favorite | 댓글 1개

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • “나쁜 코드”에 대한 경험이 몇 가지 있음. 혼자 일할 때가 많았지만 팀에서 그저 동작은 해도 최적은 아닌 코드를 쓴 적도 있음. 새 작업과 함께 예전 코드를 리팩터링하려 하면 자주 거절됐고, 필요한 리팩터링이나 수정은 티켓으로 남겨도 보통 우선순위가 밀리거나 무시됐음
    혼자라면 필요한 일을 우선순위에 넣을 수 있지만, 팀에서는 차선의 결정이 영원히 남거나 “시스템 다운” 순간까지 방치됨. 그 뒤 사후 분석에서 몇 달 전부터 폭탄을 고치자고 요청한 티켓을 가리키면 “비난”이나 “공격적”으로 받아들여졌고, 결국 해법은 차선의 코드를 절대 쓰지 않는 것처럼 되어 코딩할 때 좌절과 불안이 커짐
    2017년에 2003/2004년에 작성한 코드를 고쳐 달라는 연락도 받았는데, 그 코드가 여전히 운영 중이었음. 깨진 코드와 타협한 부분을 다시 보며 책임자가 바로 나였다는 걸 깨닫는 건 꽤 겸손해지는 경험이고, 그 뒤 유지보수 가능한 코드와 문서화에 대한 관점이 크게 바뀜
    • 팀과 회사에 따라 다름. 개발자가 코드 유지보수와 리팩터링 시간을 쓰도록 장려받고, 때로는 그 일만 하게 강제되며, 무작위 제품 요구보다 엔지니어링 중심 작업이 우선되고, 제대로 끝내기 위해 일정도 조정되는 팀을 많이 겪었음
      S&P 500 대기업, 1억~10억 달러 규모 회사, 스타트업까지 포함해 이런 경험이 보통이었음. 이런 경우에는 합리적 절충을 하고 비즈니스 필요도 챙길 수 있는 숙련된 소프트웨어 엔지니어와 관리자가 있었고, 엔지니어가 고객과 직접 상호작용하는 일도 잦았음
      핵심은 균형이고, 그 균형은 보통 균형 있게 판단할 수 있는 사람을 통해 만들어짐. “완벽”만 추구하면 끝없는 리팩터링과 미출시로 가고, 기술 부채나 쓰레기 품질을 무시하면 시간이 지나며 사업이 무너질 수 있음. 어디에 위치할지는 제품, 산업, 고객, 비즈니스에 따라 달라짐
    • 영웅으로 죽거나, 10년 된 git blame에서 자기 이름을 보게 될 만큼 오래 살아남거나 둘 중 하나임
    • “동작하지만 최적은 아님”은 시간이 부족하고 해야 할 일이 많을 때 종종 받아들일 수 있는 절충임. “완벽은 좋은 것의 적” 같은 MBA식 구호도 뭔가 빠졌을 때 써먹을 수 있는 표현임
    • 2017년에 2003/2004년에 쓴 코드를 고치러 불려 갔다는 건, 우리가 모두 시간 여행자라는 뜻이기도 함. 과거의 나에게는 관대하고 미래의 나에게는 살짝 무례함
      과거의 나는 어리고 순진했지만 생산적이었고, 산을 많이 넘었음. 코드를 파악하는 데 이틀 걸렸지만 결국 꽤 영리했고, 현재의 내가 전부 잊은 건 기억력이 나빠서일 수도 있음
      미래의 나는 모든 잘못을 바로잡을 것임. 더 나이 들고 현명하며, XXX와 TBD를 똑똑한 코드로 바꾸고, 좋은 아이디어는 구현하고 그저 그런 아이디어는 다시 구현할 무한한 시간이 있다고 믿음. 더 나은 주석이 있으면 이 셋이 하나가 될지도 모름
  • 이 의로운 “그 한 사람” 같은 태도는 해롭다고 봄. 시니어 개발자가 자신이 저지른 실수와 망한 일을 말할 수 있는 건 매우 해방적이고 건강함
    단순한 학습 기회일 뿐 아니라 개방적인 문화를 보여주고 가면 증후군에도 맞서는 효과가 있음. 완벽주의 태도는 이와 반대로 “더 노력해서 실수하지 마라”가 전부라서 배울 건 없고 개인 노력만 더 요구하게 됨
    • 적어도 두 번은 “그 한 사람”이 큰 실수를 인정하지 않았고, 좋은 고객을 잃는 한이 있어도 회피했으며 뒤에서 험담했을 거라고 짐작함
      한 번은 주니어가 보고서에 잘못된 소프트웨어 버전을 넣은 작은 실수를 내가 떠안았는데, 고객에게 “실수가 있었고 수정된 보고서가 여기 있다”고 말하면 될 일을 상사는 “이걸 숨기고 우리가 완벽하다는 체면을 유지할 수 있나?”만 생각했음. 같은 사람이 남의 실수는 할인, 보상, 무상 제공을 요구할 기회로 삼음
    • 대부분은 자기 일을 하며 나아지고 있다고 봄. 우리의 설정 관리에는 내가 쓴, 기능적으로는 잘 동작하는 것들이 꽤 있지만, 도구를 1~2년 다루고 나니 여러 이유로 품질이 꽤 나쁘다고 부르게 됨
      그래도 괜찮음. 바꿀 이유가 생기면 정리하면 되고, 그때까지는 나쁜 관행과 더 나은 접근법을 보여주는 예시로 남아 있음
    • 자기 자신에게서 비판할 점을 찾지 못한다면 발전하고 있지 않다는 뜻임. 그런 자기비판을 공유하면 다른 사람도 내 실수에서 배우고, 자기 실수에서 배워도 괜찮다는 걸 알게 됨
  • 코드 리뷰에서 “왜 그냥 그 실수를 안 하면 안 되냐”나 “왜 그냥 이렇게 안 하냐” 같은 말을 자주 듣음
    요즘은 “아마 당신 IQ가 저보다 높아서 그렇겠죠. 저는 IQ가 낮으니 더 멍청하고 단순한 일을 해야 합니다”라고 답함. 그러면 상대가 자신이 얼마나 성찰 없이 깎아내리는 작은 괴짜처럼 굴었는지 깨닫고 얼굴이 빨개질 때가 있음
    • “왜 그냥 … 안 해요?”로 시작하는 질문에는 조금 알레르기가 있음. 그 세 단어만 들어도 보통 뒤에 나올 제안을 예상할 수 있는데, 그게 엄청 복잡해서가 아니라 대개 가장 먼저 떠오르는 뻔한 방법이고 이미 신중히 검토됐거나 시도된 것이기 때문임
      질문 자체가 나쁜 건 아니지만, “내 아이디어는 너무 쉽다”와 “당신은 이 명백하고 쉬운 생각을 못 했다”는 전제가 짜증 나거나 모욕적으로 느껴짐. 반대로 내가 남에게 물을 때는 “왜 그냥”을 피하려고 하고, “어떤 이유로 X를 안 했다고 이해해도 될까요?”처럼 묻거나 그냥 친절하게 이유만 묻는 편이 더 나을 수 있음
      맥락 부족 때문에 나오는 질문이라면, 내가 한 일을 설명하기 전에 가장 뻔한 방법들이 왜 안 됐는지나 까다로운 요구사항과 문제 입력을 먼저 밝히면 막을 수 있음. 이미 커밋된 코드라면 커밋이나 병합 요청 주석으로 사후 뒷북을 줄이는 게 목표임. 때로는 반박하지 않고 그 방법을 시도했지만 왜 안 됐는지 직접 설명하고, 진심으로 다른 아이디어가 있는지 물어보는 것도 유용함
      정말 내가 생각 못 한 제안이고 문제를 풀 수 있을 것 같다면 좋은 아이디어라고 말하고 구현을 도와 달라고 함. 그럴 때 상대의 전제나 말투에 맞서고 싶은 유혹은 있지만, 그냥 받아들이고 잠깐 부끄러워하는 쪽을 택하려고 함
    • grug brain을 아주 잘 적용한 사례임 https://grugbrain.dev/
      “복잡성과 티라노사우루스와 1대1로 싸우는 것 중 고르라면 grug는 티라노사우루스를 고른다. 적어도 grug는 티라노사우루스는 볼 수 있으니까”
    • 농담이 아니라면 첫 질문은 도움이 안 되고 거의 못된 행동임. 누구나 가끔 실수함
      두 번째 질문은 보통 괜찮은 피드백일 수 있음. 사람들의 기술과 지식은 항상 겹치지 않음. A에게 미친 듯이 복잡한 것이 B에게는 아닐 수 있고, 그 반대도 가능하며, 꼭 누가 더 똑똑해서 그런 것도 아님. A는 SQL을 모를 수 있고 B는 pandas를 모를 수 있음
      이미 기술 스택에 SQL과 pandas가 둘 다 있다고 가정하면, 어떤 코드를 SQL에서 pandas로 옮기거나 반대로 옮기는 게 말이 될 때가 있음. 객체지향 스타일을 쉬워하는 사람도 있고 함수형 스타일을 쉬워하는 사람도 있음. 무엇이 더 타당한지는 항상 명백하지 않으니 질문이 좋은 질문일 수 있음. 제안이 나쁘면 왜 나쁜지 설명하고, 좋으면 지금 할 가치가 있는지 따져 보면 됨. 중간이거나 시간이 없으면 인정하고 넘어가면 됨
    • 다른 대안은 그냥 분명히 동의하는 것임. “맞아요, 멍청했죠?”나 “맞아요, 그러면 안 됐을 수도 있겠네요”, 혹은 “생각해볼게요”라고 답할 수 있음
      그러면 상대가 차선의 일을 했다는 이유로 나를 부끄럽게 하거나 죄책감을 주기 어려움. 이런 말의 목적은 자주 수치심으로 우위 세우기라고 봄. 게임에 참여하지 않는 선택이고, 보통 그게 이기는 수임
    • 무지해서 한 말이라면, 굳이 공격으로 받아들이고 상대를 창피하게 만들어 대가를 치르게 할 필요는 없음
  • 예전에 본 블로그나 글을 못 찾겠지만 메시지는 “코드에서 최적이 아닌 것을 봤다고 무능함을 가정하지 말라”였음. 그 코드를 쓴 사람에게는 촉박한 마감, 다른 우선순위, 그 밖의 요인 때문에 즉시 “옳은 일”을 하지 못한 사정이 있었을 수 있음
    • 작성 당시에는 코드가 완벽했더라도 코드베이스 성장과 요구사항 변화가 나쁘게 만들 수 있음
      예를 들어 저장할 항목이 10개라면 단순 파일이 실용적 선택일 수 있지만, 10,000개가 되면 데이터베이스가 필요할 수 있음. 그런데 처음부터 10개를 위해 데이터베이스를 썼다면 과설계라고 불평했을 것임
      클래스가 2개면 if/else로 충분하지만 20개가 되면 Factory 패턴이 필요할 수 있고, 처음부터 했다면 아키텍처 우주비행처럼 보였을 것임. 이런 성장을 예측하려다 틀리면 복잡한 코드를 만들게 됨. 계속 개발되는 프로젝트는 체계적으로 자기 자신보다 커져 감
    • 체스터턴의 울타리도 있음. 코드 안의 바보 같은 것이 예전에는 실제로 중요했을 수 있음. 더 나쁘게는, 지금도 드문 경계 사례에는 중요하지만 아직 그 이유를 못 보고 있을 수 있음
    • 관련해서 여기에 쓴 적이 있음: https://camhashemi.com/posts/building-through-uncertainty/
  • 블로그 글에 대해 여기와 reddit에서 몇 번 악성 댓글을 받았음. 그럴 때는 판단 없이 그 악성 댓글로 가는 링크를 글에 추가해 빛을 비추는 방식을 씀. 보통 아무 일도 없지만 가끔 논의를 더 건강한 방향으로 돌려놓음
    • 나도 꽤 많이 받았음. 일부는 아마 마땅했겠지만 대부분은 그렇지 않았을 가능성이 큼. 몇몇은 어느 정도 맞는 말이었지만 도움이 안 됐거나 커뮤니티에 직접 해로웠음. 맞는 말을 잘못된 방식으로 하면 여전히 틀린 말을 하는 것임
      악성 댓글을 판단 없이 링크하는 건 나쁜 생각이 아님. 댓글이 죽은 처리되면 항상 가능한 건 아니지만, 어쨌든 같은 방식으로 받아치지는 않음. 나도 할 수는 있지만, 휘발유가 효과적인 소화제가 아니라는 걸 배웠음
      내가 틀렸다면 그 실수가 있던 같은 장소에서 곧바로 인정하려고 함. 공개 공격 뒤의 비공개 사과는 특히 싫어함
      선은 있음. 나는 내가 꽤 좋은 일을 한다고 느끼고, 40년 정도 오래 해왔으며 그동안 많이 배웠음. 수준 낮은 일을 받아들이지 않는 까다로운 환경에서도 일해 봐서, 괜찮은 일을 습관적으로 하게 됨
      일반적으로 공개적으로 남을 판단하는 건 피함. 도움이 되지 않고, 내가 항상 맞는 것도 아님. 다만 함께 일하거나 그 사람의 것을 쓰는 상황이면 다를 수 있음. 내가 쓰레기를 받아들이지 않는다는 이유로 거칠게 공격받은 적도 있지만, Linus Torvalds처럼 굴지는 않음. 가능하면 존중하는 방식으로 그 작업은 내게 받아들일 수 없다고 말함
      그래도 항상 개선하고 새로 배울 수 있으며, 때로는 전혀 예상 못 한 곳에서 배우게 됨. 이런 배움에 열려 있는 건 기본적으로 좋은 정책임. 나는 틀리고 배움으로써 옳아짐. “좋은 판단은 경험에서 오고, 경험은 나쁜 판단에서 온다”
    • 내가 좋아하는 팟캐스트 중 하나인 YouTube의 well there's your problem은 팟캐스트에 불평하는 댓글을 거의 항상 고정함. 대체로 “이 팟캐스트가 마음에 안 드니 다른 팟캐스트가 되어야 한다” 수준의 불평인데, 고정되는 댓글은 매번 그 에피소드에서 가능한 가장 멍청한 해석에 가까움
      그런 댓글을 줄이는 데 효과가 있는지는 모르겠지만, 그런 식으로 담론에 참여하는 사람에게 은유적 바보 모자를 씌우는 의미는 있음
  • 일부 엔지니어에게 나쁜 태도가 있다는 점에는 동의함. 누구나 나쁜 코드를 쓸 수 있고, 모든 코드는 나쁘며 부채라는 논리에도 일리가 있음
    이 글은 “No more pink mustache”와 함께 읽기 흥미로움. 그 글에서 Lyft는 “믿기 어려운 규모로 망가져 있다”고 묘사되는데, 품질의 원인은 종종 의자에 앉은 사람이 아니라 조직임 :-)
    [1] https://rachelbythebay.com/w/2020/02/29/poof/
  • 2018년에 이 글을 읽었고 다시 올라와서 반가움. 나에게 질문을 던지게 만든 글 중 하나였음. 절대주의나 극단성을 없앨 수 없다면, 이런 대화나 사람을 접할 때 어떤 필터를 만들 수 있을까 고민하게 됨. 내 모델은 있지만, 다른 사람들은 어떤 전략을 쓰는지 궁금함
    • 이런 사람들은 자기 것이 아닌 감정적 영역을 차지하려 함. 보통 자신이 “그래도 된다”고 미리 계산했고, 이는 상대를 약하다고 본다는 뜻임
      선택지는 세 가지임. 포기하고 그 영역을 내준 뒤 삶을 계속 사는 것, 불공평함 때문에 잠을 덜 설칠수록 좋음. 정면으로 맞서는 것, 이들은 싸울 준비가 되어 있지만 입장 자체가 본질적으로 비합리적이라 그들의 사고 공간에 덜 끌려갈수록 “이김”. 위에서 내려오는 것, 그들이 틀렸다는 사회적 증거를 그들의 공간으로 가져오는 것임. 원글의 경우라면 서로의 일을 존중하고 꼬투리 잡지 않으면서 생산적인 프로그래머들이 이에 해당함
  • 누군가 “이렇게 했으면 더 나았을 수 있다”고 조언할 때, 그게 항상 나에 대한 공격이나 능력 모욕은 아님
    조언하는 사람이 대인관계에 서툰 멍청이일 수도 있고, 그냥 완전히 멍청이일 수도 있음. 세상의 일부가 나와 동의하지 않아도 괜찮음. 사람들이 반대 의견을 말하거나 동의하지 않는다고 해서 나를 위협하는 건 아님
  • 이상한 글임. 트윗처럼 들리고, 내용은 적으며 제목은 본문을 반영하지 않아서 클릭베이트처럼 보임
  • 그 요지에 반대하지는 않지만, 반대편도 있음. 피드백을 받아들이는 능력도 필요함
    • 대부분의 사람은 피드백을 받아들이고 적용할 수 있음. 다만 어떤 사람들은 피드백을 형편없이 주고는 상대가 피드백을 못 받아들인다고 여김
      이런 사람들은 자신이 선호하는 피드백 방식이 최고라고 생각하고 모두가 똑같이 느껴야 하며, 그렇지 않으면 상대가 바뀌어야 한다고 봄. 물론 틀렸음. 하지만 이걸 말해주면, 왜 첫 문장에서 “대부분”이라고 했는지 스스로 보여줌
답변달기