‘Can’t be fucked’: 기술 부채의 과소평가된 원인

(jesseduffield.com)

1P by GN⁺ 2023-10-13 | ★ favorite | 댓글 1개

개발 실력은 지식만으로 결정되지 않으며, 해야 할 일을 알면서도 동기 부족 때문에 테스트·리팩터링·재현 사례 작성을 미루면 기술 부채가 쌓임
훌륭한 개발자는 flaky test를 조사해 고치고, 발견한 버그를 티켓으로 만들거나 즉시 수정하며, 새 기능이 기존 코드와 맞지 않으면 먼저 리팩터링함
“premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” 같은 격언은 실제 제약을 다룰 때 유용하지만, 단순히 하기 싫음을 숨기는 말로도 쓰일 수 있음
Lazygit에는 수개월에 걸쳐 end-to-end 테스트 시스템을 만들고 효과를 체감했지만, Lazydocker에는 같은 테스트를 추가하지 않았고 최소 재현 저장소 요청과 God Struct 리팩터링도 미뤄짐
완벽한 코드를 쓸 에너지가 없을 때도 부족한 부분을 솔직히 드러내면, 유지보수 기준과 다음 작업의 우선순위를 더 쉽게 판단할 수 있음

기술 부채를 만드는 동기 부족

“Can’t Be Fucked”는 무언가를 하고 싶지 않거나 할 에너지와 동기가 없는 상태를 뜻하는 호주식 속어임
개발 지식을 많이 배우면 더 나은 프로그래머가 될 수 있다고 생각했지만, 실제로 존경하게 되는 개발자는 지식뿐 아니라 꾸준한 성실함을 갖춘 사람들임
좋은 개발자는 문제가 작을 때 제대로 다루는 편이 장기적으로 시간을 아낀다는 점을 알고 행동함
- flaky test가 있으면 조사하고 고침
- 야생에서 버그를 발견하면 티켓을 만들거나 즉시 수정함
- 새 기능이 기존 코드와 맞지 않으면 억지로 끼워 넣기보다 먼저 리팩터링함
- 필요하면 스택 아래까지 내려가 원인을 파악함
이런 개발자들도 “good enough”가 맞는 경우, 범위를 줄여야 하는 경우, 도메인을 더 배운 뒤 아키텍처를 바꾸는 편이 나은 경우를 구분함
문제는 그런 판단과 별개로, 어떤 순간에는 프로젝트의 외부 제약보다 동기 결핍이 더 강한 제약이 된다는 데 있음

격언 뒤에 숨지 않고 솔직해지기

Lazygit의 end-to-end 테스트 시스템은 수개월 동안 파트타임으로 만들었고, 이후 많은 회귀를 막았으며, 지금 와서 추가하려면 더 어려웠을 것이라는 확신이 있음
- 그럼에도 Lazydocker에 end-to-end 테스트를 추가하지 않은 이유는 단순히 CBF였음
다른 오픈소스 저장소에 이슈를 올린 뒤 최소 재현 Git 저장소를 요청받았지만 아직 만들지 않았고, 1년 넘게 시작한 큰 리팩터링도 끝내지 못해 코드가 여전히 God Struct에 많이 남아 있음
번아웃인지, 성장 마인드셋 부족인지, 성격의 문제인지는 확정하지 않음
기술 부채의 장기적 고통을 아는 것은 회피 동기가 될 수 있지만, 아는 것과 실제로 올바르게 행동하는 것은 다름
“테스트가 너무 많으면 유지보수 부담이 생긴다”, “다른 기능이 어떤 영향을 주는지 보고 리팩터링하겠다”, “premature optimisation”, “cut scope aggressively” 같은 말은 좋은 판단에도 쓰이지만 핑계로도 쓰일 수 있음
코드나 pull request의 일부가 부족한 이유가 게으름이라고 인정하면, 리뷰어는 그 부족함이 기준을 넘는지 또는 다음 작업에 시간을 쓰는 편이 나은지 직접 판단할 수 있음
CBF 상태가 왔을 때 낙담하기보다 솔직해야 하며, 너무 오래 100%로 달려왔다면 휴가가 필요할 수도 있음

GN⁺ 2023-10-13 [-]

Hacker News 의견들

CBF의 상당 부분은 보상과 인센티브만으로도 설명 가능함
지금 회사에 들어왔을 때는 에너지가 넘쳐서 깨진 빌드를 고치고, 방치된 테스트를 통과시키고, 배포 파이프라인을 리팩터링하고, 버그의 근본 원인을 찾아 고쳤음
그런데 시간이 지나니, 사람들은 나를 본받기는커녕 “어차피 저 사람이 고치겠지”가 됐고, 허드렛일을 하면 더 많은 허드렛일만 돌아온다는 걸 알게 됨
반대로 대충 해킹하듯 만드는 사람은 결과를 잘 포장해서 먼저 승진했고, 운영에서 문제가 터질 때쯤엔 이미 다른 프로젝트로 넘어가 있음
내가 매주 몇 시간씩 도와주는 주니어는 2022년에 급하게 채용된 덕분에 나보다 많이 벌고, 나는 2023년에 “기대 이상” 평가를 받았지만 어려운 시기라며 인상도 못 받음
결국 월급 받고 일하는 입장에서 노력이 보상받지 못하거나 오히려 벌이 된다면, 동기가 사라지는 게 이상하지 않음
- 월급만을 위해 일하게 됐다면 살아 있다는 의미를 놓친 것일 수도 있음
  떠나서, 자신이 있을 만한 곳과 자기 사람들을 찾아야 함
- 맞음. 문제는 동기 자체가 아니라 동기 비용인 경우가 많음
  인정받으면 동기 비용이 크게 낮아지고, 사람은 보상을 좋아함
  사람들이 게임을 수천 시간 하는 것도 동기 비용이 아주 낮기 때문임
  직장을 게임화하자는 뜻은 아니지만, 스스로를 변호하면 쪼잔해 보이니 동료들이 서로를 인정해줘야 함
기술 부채에도 서로 다른 이자율이 있고, 실력은 0% 부채를 놔두고 고이자 부채부터 갚는 데 있음
지하실 벽장 바닥을 깔다가 자재가 모자라 뒤쪽까지 완전히 못 깔았는데, 보기엔 좀 못생겼지만 항상 상자로 가려져 있고 수십 년 살아도 영향이 없음. 이건 0% 기술 부채임
반면 배수로가 막히면 시간이 지날수록 지하실 누수나 배수로 탈락으로 비용이 커지니 이자가 붙는 부채임. 현관 계단이 망가져 계속 걸려 넘어지는 것도 빨리 고쳐야 하는 고이자 부채임
엔지니어링에서는 모든 기능 개발을 늦추는 아키텍처 문제가 고이자 부채일 수 있고, 거의 손대지 않는 파일의 지저분한 코드나 TODO는 실제로는 저이자 부채일 수 있음
엔지니어들은 한편으로는 0% 부채를 고치느라 더 중요한 일을 놓치고, 다른 한편으로는 “제품/리더십이 기술 부채 해결을 지원하지 않는다”고 하지만 실제 비용과 이자율을 잘 설명하지 못하는 경우가 많음
- “실제 비용을 설명하지 못해서 그렇다”는 데는 동의하지 않음
  위에서 아래까지 새롭고 반짝이는 것만 주목받고, 기존 것을 유지하는 일에는 관심이 없음
  설령 중요성을 설득해도, 경영진은 그 일이 필요하다고 동의할 뿐 성과 평가에는 아무런 긍정적 영향이 없음. 잘못되면 질책만 받는 일을 내가 떠안게 됨
- 비유에는 동의하지만, 큰 팀에서는 코드 품질에 적용되는 깨진 유리창 이론을 무시할 수 없음
  코드베이스가 지저분하고 일관성이 없으면, 숨겨진 파일이라도 개발자들은 새 기능을 일관성과 품질 있게 구현하려는 마음이 줄어듦
  “어차피 이 모듈 전체를 다시 써야 하니 일단 여기 대충 붙이고, 나중에 정리하자”가 됨
  https://en.wikipedia.org/wiki/Broken_windows_theory
- 기술 부채의 이자율이라는 비유가 좋음
  기술 부채라는 표현의 자연스러운 확장이고, 핵심을 간결하게 전달해서 회사에서도 써먹고 싶음
- 많은 경우 0% 부채와 비싼 부채를 구분하는 비용이 그냥 고치는 비용만큼 들기도 함
  그래서 “개발자가 실제 비용을 설명하지 못했다”고 탓하는 건 조금 쉬운 핑계임
  고객에게 보이는 문제가 생기면 해결될 가능성이 있지만, 내부 문제일 뿐이면 가능성이 훨씬 낮아짐
- 실제로 아무에게도 빚진 게 없는데 부채라고 부르는 게 이상함
  “0% 기술 부채” 같은 표현을 진지하게 쓸 때, 혹시 개념을 잘못 잡은 건 아닌지 돌아봐야 함
  부채는 갚거나 이자를 치러야 하는데, 그런 게 없다면 부채가 아님
  다음엔 아직 구현하지 않은 기능도 0% 기술 부채라고 할 건가 싶음
Steve Jobs 팬은 아니지만, 장인정신과 디테일을 신경 쓰는 태도에 대한 그의 인용문은 늘 좋았음
“아름다운 서랍장을 만드는 목수라면, 벽을 향해 아무도 보지 못하는 뒷면이라고 합판을 쓰지 않을 것이다. 본인은 그게 있다는 걸 아니까, 뒷면에도 아름다운 나무를 쓸 것이다. 밤에 편히 자려면 미감과 품질이 끝까지 이어져야 한다”
소프트웨어 전반은 “요구사항을 기술적으로 겨우 만족했으니 내 일은 끝”이라는 태도로 크게 고통받는다고 봄
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
- 이 비유는 좋지만, Jobs는 품질과 장인정신에 집착하는 리더십 문화를 만들어서 그게 가능했음
  기준에 못 미치는 하드웨어와 소프트웨어는 출시를 거부했고, 올바른 사양으로 만들지 못한 사람을 해고했다는 얘기도 많음
  반면 대부분은 “최대한 빨리 끝내서 더 팔고, 품질 테스트만 무사히 통과하도록 필요한 건 대충 맞춰라”는 정반대 리더십 아래에서 일함
- Jobs가 말한 목수는 현실의 목수가 아니라 허구에 가까움
  실제 목수는 시장에서 경쟁하려면 실용적이고 비용 효율적이어야 함
  아무도 보지 않는 곳에 비싼 나무를 쓰거나 시간을 들이면 처리량은 줄고 고객 비용은 불필요하게 올라감
  장인에게도 시간과 돈은 유한하고, 보이지 않는 일에 쓴 시간은 더 눈에 띄는 일에 쓰지 못한 시간임
  같은 실력의 목수들이 더 낮은 비용으로 더 많이 생산하는 시장에서는 그런 목수가 밀려날 것임
- 어릴 때부터 거의 30년 쓰고 있는 괜찮은 서랍장 뒤를 보니 합판이 붙어 있음. 이제 교체할 때가 되긴 했음
  소프트웨어 문제는 태도보다 인센티브 문제에 가깝다고 봄. 좋은 일을 하고 좋은 소프트웨어를 쓰는 건 좋아하지만, 하루 시간은 한정돼 있고 내가 이익을 얻지 못할 사업상 이득을 위해 개인 시간을 포기할 정도는 아님
  게다가 리팩터링을 시작하면 어느 날 갑자기 오늘 안에 끝내야 하는 필수 기능이 생길 거라고 합리적으로 예상 가능함
  경영진이 기술 부채 해결에 동의하더라도, 결국 일정 추정치를 부풀리고 배정된 일 대신 리팩터링하지 않으면 해결되지 않음
- 예전에 쓴 글과 잘 맞는 대목임
  어떤 책에서 대장장이 인물이 마차 부품을 고치며 “언제나 할 수 있는 최선을 다하라”고 말함
  “그건 밑에 들어가는 부품이라 아무도 못 보잖아요”라는 말에, “하지만 나는 거기 있다는 걸 안다. 내가 할 수 있는 만큼 잘하지 않으면 그 마차가 지나갈 때마다 부끄러울 것이다. 그리고 나는 그 마차를 매일 볼 것이다”라고 답함
  https://news.ycombinator.com/item?id=28086786
- 요구사항만 겨우 만족하는 수준을 넘어서는 일이 대부분 보상받지 못하는 게 핵심임
  제대로 된 단위/통합/종단 간 테스트를 쓰고, 엉망인 코드를 보면 그 위에 또 얹는 대신 리팩터링하면, 티켓을 계속 “해결”하는 동료보다 서류상 생산성이 낮아짐
  특히 리팩터링이나 코드 품질 정리를 전혀 고려하지 않는 “완전 애자일” 조직에서 심함
  Apple은 적어도 한때는 예외였음. 제품 가격이 높아 고객이 품질을 기대했고, 회사에 그걸 가능하게 할 이익률이 있었으며, 무엇보다 경험을 보는 눈이 있는 Steve Jobs가 있었음
  반대 극단으로는 우주항공급 엔지니어링으로 주스 팩을 짜는 기계를 만든 Juicero 같은 사례도 있음
커리어 대부분 동안은 시키지 않아도 기회가 보이면 기술 부채를 정리했음. 애착과 소유감이 있었기 때문임
지금은 Jira 기반의 마이크로매니지먼트와 자율성 없는 일터라, 꼭 해야 하는 일 외에는 아무것도 하지 않음
예전에는 자발적 노력이 커리어의 핵심이었지만, 이제는 어떤 변경이든 관료적·사회적 프로젝트 관리 비용이 너무 커서 굳이 할 가치가 없음
제품이 장기적으로 잘 되든 회사가 성공하든 관심 없고, 다음 직장을 찾을 때까지 티켓만 처리함
- 이런 조직들이 정색하고 “리팩터링해도 돼요. 리팩터링 설계안을 만들고 다음 설계 회의에서 발표한 뒤, 여러 차례 리뷰와 피드백을 거쳐 마일스톤으로 쪼개고 추정한 다음, 다음 계획 주기에 다른 기능들과 우선순위를 정하면 됩니다”라고 하는 게 웃김
  반대로 “리팩터링은 허락받지 말고 하라”는 식으로 진행하면, 저장소의 기존 패턴을 따르지 않는 PR을 만들었다고 혼남
  “좋긴 한데 팀 전체와 논의해야 해요”가 됨
  그래서 기술 부채는 계속 커지고, PR 하나 병합하는 데 몇 달이 걸리며, 테스트는 너무 불안정해서 빌드될 때까지 재시작 버튼을 누르는 카지노 슬롯머신 같아짐. 애자일은 정말 훌륭함
- 이런 문화를 만드는 회사들이 보통 자기들의 문화를 자랑스럽게 여기고 잘하고 있다고 생각한다는 점이 흥미로움
- 나도 티켓만 처리하다가 다음 직장을 찾음
  반응형으로만 움직이는 일터에서 선제적으로 행동하는 것은 내 경험상 절대 보상받지 못함
  문제를 발견하면 그 순간 내 문제가 되고, 나중에 다시 터지면 내가 망친 게 됨
  PM과 관리층은 늘 부정적 가정으로 움직여서 그럴 가치가 없음
- “리팩터링은 허락받지 말라”는 태도 때문에 커리어에서 문제가 많았음
  특히 어떤 사람들은 자신에게 좋은 코드로 가는 깨달은 길이 있다고 생각하지만, 실제로는 기존 코드를 읽고 이해하는 것보다 쉬운 길을 택하는 경우가 많음
여기 댓글에는 오해가 좀 있음
개인 프로그래머에게 동기, 노력, 에너지, 의지력은 무엇이라 부르든 유한한 자원이고, 이건 완전히 정상임
조직의 장점은 개인 프로그래머보다 더 많은 일을 해낸다는 것이지만, 여러 요소를 붙이는 과정에서 틈이 생기고 일이 그 사이로 빠짐
COO, HR, 제품 관리자처럼 기술 업무가 아니라 조직 운영으로 월급을 받는 사람들은 그 틈을 처리할 프로세스를 만들어야 함
그런데 점점 더 많은 회사가 이 일을 개별 엔지니어와 디자이너에게 떠넘김. 손익이나 OKR로 측정하기 어렵기 때문임
회사는 고통받고 엔지니어는 번아웃됨. 추가 보상 없이 틈새로 빠진 작은 티켓과 업무를 계속 챙기는 데는 한계가 있음
여기 부정적인 분위기가 엄청나지만, 이 글이 내 일상 감정을 정확히 설명해줘서 반가웠음
오픈소스 프로젝트의 훌륭한 테스트 커버리지와 원칙 있는 리팩터링을 보면 나도 어떤 날은 “제대로 하자” 모드가 되어 잘 만든 것들을 많이 해냄
그러다 어느 날 그 에너지가 사라지면, 저자처럼 나도 CBF가 됨. 테스트를 건너뛰고, 좋지 않다는 걸 아는 위치에 코드를 덧붙이고, 미래의 내가 고마워하지 않을 길을 깔고 있음
그 일이 실시간으로 보이는데도 다시 영감 있는 “제대로 하자” 모드로 돌아갈 에너지나 동기가 없음
이게 전부 내가 직접 만들고 파는 소프트웨어에서도 벌어짐
저자가 Lazygit 만든 사람이라는 걸 보고 인상 깊었고, lazygit은 정말 좋아함. 내 머릿속에서는 늘 제대로 해내는 오픈소스 유지보수자 범주에 들어 있음
- 글쓴이인데, 이 댓글 덕분에 하루가 좋아졌음
  우리 둘 다 동기에 관해 비슷한 경험을 하는 것 같음
  lazygit을 좋아해줘서 기쁘고, 앞으로도 좋은 평가를 유지할 수 있기를 바람
대부분의 결정은 사실 무의식적임
“도저히 못 하겠다”는 상태는 뇌의 어떤 회로가 리팩터링이나 테스트 같은 일이 할 만한 가치가 없다고 판단한다는 뜻임
그 회로가 맞을 수도 있음. 객관적이고 전체적으로 보면 노력 대비 보상이 실제로 충분하지 않은 경우가 많기 때문임
예를 들어 종단 간 테스트를 두 달 동안 만들었고, 이후 6개월 동안 디버깅 등에서 3주를 절약했다면 계산이 맞지 않음
흔한 양극단이 있음. 한쪽에서는 비즈니스가 정말 잘못된 절충인 기술 부채를 엔지니어에게 강요하고, 다른 쪽에서는 엔지니어가 결국 보상되지 않을 이상적인 구조화와 거대한 테스트 묶음에 시간을 쓰기도 함
그 일부는 누군가 더 나은 코드 구조나 추가 테스트를 찾아내고 자신을 평가할까 봐 걱정하기 때문이기도 함
- 모든 게 투자 대비 수익만은 아님
  내가 내 기준에 못 미치는 것을 내놓고 있다고 느끼면, 그 기준이 실제 필요보다 높더라도 사기와 동기가 크게 손상됨
  기술 부채의 가장 큰 문제는 오히려 사기를 망가뜨리는 데 있다고 봄
Lazygit에는 종단 간 테스트 시스템을 몇 달 동안 부분적으로 만들었고, 그 시스템이 막아낸 회귀와 지금 와서 추가하려면 얼마나 더 어려웠을지를 매일 생각함
분명 가치가 있었다는 걸 아는데도 Lazydocker에는 왜 종단 간 테스트를 추가하지 않았냐면, 그냥 CBF이기 때문임
종단 간 테스트는 도구가 제대로 없으면 지옥처럼 귀찮고 엄청난 작업임. 쉽게 끼워 넣을 수 있는 기본 프레임워크가 더 좋아져야 함
- 종단 간 테스트를 유지하려면 사실상 개발자 한 명 분량의 시간을 배정해야 함
  운이 좋으면 그 사람이 통합 테스트까지 볼 시간이 남음
이 사회와 이 세상에서 사람들이 게으르다고 보는 관점은 대체로 말도 안 된다고 봄
수십 년 동안 주 40시간씩 일하고 환생한 뒤에야 쉬라는 식인데, 여기서 게으름을 말하자는 건가 싶음
정신 에너지는 남의 부를 만드는 데 뽑혀 나가고, 너무 늙어 아무것도 못 하게 되면 버려짐
매주 어제 끝났어야 할 기능이 또 나오는데 기술 부채를 언제 고치라는 건지 모르겠음. 자유 시간에 하라는 건가? 애초에 왜 계속 존재해야 하는지도 모르겠음
- 그래서 소프트웨어 일을 하다 번아웃됐음
  작은 팀의 성숙한 프로젝트에서는 남은 티켓이 전부 아무도 원하지 않는 어려운 버그였음
  며칠을 투자해도 의심 목록 몇 개를 지운 것 말고는 보여줄 게 없고, 잘못 지웠다가 일주일 뒤 다시 돌아오는 식의 버그들임
  매일 모든 정신 에너지를 그런 티켓에 쏟아야 하고, 커피나 각성제에 의지해 겨우 버그를 해결하면 코드를 제출하고 티켓을 닫은 뒤 바로 다음 티켓으로 가야 함
  진짜 휴식은 없고, 다음 티켓 초반에 아무도 즉시 결과를 기대하지 않을 때 잠깐 머리를 쉬게 됨
  하지만 며칠 지나면 사람들이 지금까지 뭘 했는지 묻고, 막혔냐고 묻고, 사실 거의 시작도 못 했는데 뒤처진 이유를 작은 거짓말로 꾸며야 함
  가장 쉬어야 할 때는 이미 가장 뒤처져 있고 사람들이 알아차린 뒤라, 휴가를 내는 것조차 선택지처럼 느껴지지 않음
- 5년 동안 스타트업을 하면서 완전히 망가졌음. 번아웃 위에 번아웃이 수년간 쌓임
  지금은 엔지니어링 비영리에서 주 20~30시간, 때로는 더 적게 일하고 돈은 빠듯하지만, 더 많이 일하는 건 도저히 불가능함
  사이드 프로젝트와 자전거 탈 시간이 조금 있고, 주말에는 절대 일하지 않음. 화요일도 특별한 경우가 아니면 일하지 않음
  지금 직장은 정말 사랑하고 꿈의 직장이지만, 나를 죽여가며 할 가치는 없음. 인생은 한 번이고, 제대로 사랑하며 살 것임
- 시간이 얼마나 걸릴지 거짓말하는 방법도 있음
  오늘 회사 장치 펌웨어를 거의 전면 재작성한 1개월짜리 작업을 끝냈는데, 처음에는 통신 모듈 일부의 작은 버그를 고치는 1주짜리 작업으로 잡혀 있었음
  다행히 느긋한 PM과 동료들이 있어서, 이제 그 코드의 8년 된 레거시 버그들을 실제로 고칠 수 있게 된 점을 인정해줌
  아직 엣지 케이스 테스트와 추가 수정은 남았지만, 원격 코드 업데이트가 동작하니 장치를 출하할 수 있음
  여기서 “거짓말”은 행동 권장에 가까움. 원래는 댓글을 “거짓말하라”로 시작했는데 오해가 있었음
- 일에서 게으르지 않다는 것과 오래 일한다는 것은 같은 뜻이 아님
- 존재해야 하는 이유는, 우리에게 너무 많이 일하게 만들고 더 일하지 않는다고 죄책감을 주는 경제적 힘에 맞서기 위해서임
  동료들에게 일의 더 넓은 함의를 생각할 시간을 갖는 게 중요하다고 알려주기 위해서도 존재해야 함
  이런 커뮤니티에 자신의 생각을 보태고, 초콜릿을 먹고, 가능하다면 개를 산책시키고, YouTube에서 Alan Watts 강의를 듣기 위해서도 존재해야 함
제대로 하려고 노력하는 사람으로서 기술 부채에서 중요한 건 추적이라고 봄
보이는 문제를 작업으로 하나 올리는 데는 몇 분이면 되고, 그 작업이 기술 부채가 됨
리더십은 기술 부채의 우선순위를 정하고 일정량을 계속 줄여나갈 책임이 있음
때로는 어떤 일을 하지 않기로 결정함으로써 기술 부채를 줄이기도 하는데, 그것도 완전히 괜찮음
기록하고, 확인하고, 처리하는 절차의 목적은 “지금은 아닌 문제”를 두 번째로 살펴볼 기회를 주는 것임
처음 직감이 틀려서 X가 필요 없었을 수도 있고, 반대로 당시엔 떠올리지 못한 이유로 맞았을 수도 있음
무엇보다 “지금은 못 한다”는 일 중 일부는 실제로 중요함. 시간을 들여 들여다보지 않으면 그런 일을 찾을 수 없음