코드는 끝없이 나빠질 수 있다: '가라앉는 배' 비유의 오류
There's No Limit to How Bad Code Can Get
소프트웨어 엔지니어링 블로그에서 코드베이스의 악화를 설명할 때 자주 쓰이는 '가라앉는 배'나 '무너지는 건물' 같은 비유가 잘못되었음을 주장한다. 물리적 구조물과 달리 소프트웨어는 붕괴의 한계가 없어 코드는 무한히 나빠질 수 있다. 기술 부채는 파산이나 재시작 같은 강제 리셋이 없으며, 비즈니스는 코드 품질이 바닥을 치기 훨씬 전에 실패한다. 저자는 Amazon에서의 경험을 바탕으로, 리팩토링 시도가 실패하고 조직이 계속 악화되는 과정을 설명하며, 코드 품질 유지는 지속적인 노력이 필요함을 강조한다.
소프트웨어는 추상적인 영역에 있다. 건물이나 다리처럼 물리적 세계에 있어 그 본질을 보고 느낄 수 있는 것이 아니다. 건물에 계속 층과 방을 추가하면 결국 무너지겠지만, 소프트웨어에는 그런 제약이 없다. 코드는 언제나 더 나빠질 수 있고, 항상 새로운 간접 계층이나 성능 저하가 추가될 수 있다.
HN 토론
78- ChrisMarshallNY
제 첫 직장 중 하나는 1979년대 FORTRAN IV로 작성된 10만 줄 이상의 코드베이스에서 유지보수 엔지니어로 일하는 것이었습니다.
주석도 없었습니다.
서브루틴(지금 우리가 '함수'라고 부르는 것)도 없었습니다.
변수 이름은 4자보다 길 수 없었습니다.
재미있었죠. 가장 효과적인 디버그 도구는 오이자 보드였습니다. 그 덕분에 저는 전문적인 추측가가 되었습니다.
그 경험 때문에 오늘날 저는 코드 품질에 대해 그렇게 집착하게 되었습니다. 저는 누구에게도 그런 코드를 겪게 하고 싶지 않습니다.
그건 그렇고, 오늘날의 LLM을 사용하면 문서화가 제대로 안 되거나 형식이 잘못된 코드에 대한 변명의 여지가 없습니다. 상업용 수준의 스파게티 코드 천 줄을 작성하고 LLM에게 형식을 지정하고 문서화하라고 말할 수 있습니다.
- lukasgelbmann
통찰력 있는 기사입니다. 저자는 조직에서 기술 부채의 역학에 대해 훌륭한 점을 지적합니다.
저는 가라앉는 배가 꽤 좋은 은유라고 생각합니다. 하지만 침몰한 배는 끔찍하고 최악의 결과입니다.
은유에서 코드베이스는 계속 사용하기 어려울 때 침몰한 것입니다. 조직은 그 작업을 중단하고 더 이상 실행하지 않습니다. 이 시점에서 코드는 바다 밑바닥의 배처럼 비즈니스에 완전히 가치가 없습니다. 사실, 코드가 이론적으로 더 나빠질 수 있다고 상상할 수 있습니다. 그러나 현실에서는 그냥 방치되어 썩을 것입니다.[0] 비즈니스는 재작성을 시도하거나 제품을 중단할 수 있습니다.
비즈니스가 코드베이스 중 하나와 함께 침몰할 가능성은 있지만 반드시 그런 것은 아닙니다. 이것은 배에서도 발생할 수 있습니다. 비즈니스가 배에 크게 의존하는 경우입니다.
- blevinstein
> 기술 부채에는 파산도, 깔끔한 리셋도 없다
확실히 기술 부채 파산 옵션이 있습니다.
특정 코드나 기술 사용을 중단할 수 있습니다. 예를 들어 (새 코드나 타사/벤더 솔루션으로) 교체하거나, 코드의 기능이 더 이상 필요 없도록 시스템이나 비즈니스 프로세스를 재설계할 수 있습니다.
이것이 바로 기술 부채 은유가 의미하는 바입니다. 수명이 짧은 시스템은 곧 파산(코드 폐기 및 폐지)을 선언할 계획이므로 많은 기술 부채를 축적해도 큰 문제가 되지 않습니다. 반면 수명이 긴 시스템은 일반적인 할부 계획에 따라 기술 부채를 상환할 계획을 세워야 합니다.
- socalgal2
두 가지
1. LLM이 제 경험상 이 문제를 해결할 수 있습니다. LLM, 특히 더 현대적인 LLM은 대부분의 인간보다 훨씬 더 많은 단기 기억력을 가지고 있습니다(또는 적어도 저보다 훨씬 더 많습니다). 그들은 이런 종류의 코드를 파고들어 모든 엣지 케이스를 파악하고, 테스트를 작성하고, 개선을 위한 다양한 경로를 제안하고, 그 경로를 실행할 수 있습니다. 요청이 있으면 기꺼이 개발 시스템, 스테이징 시스템 등을 설정하여 전환을 안전하게 만듭니다. 적어도 제 경험은 그렇습니다. 그들은 제가 생각했던 것보다 훨씬 더 깊이 파고들 수 있습니다.
2. LLM 수정과 별개로, 이 기술 부채 패턴은 인간과 함께라면 거의 불가피하다고 생각합니다. 완벽한 세계에서는 모든 인간과 모든 리뷰어가 정확히 어떤 아키텍처를 작성해야 하고 어떤 테스트가 모든 규칙과 가정을 전달해야 하는지 알고 있습니다. 왜냐하면 무슨 일이 있어도 사람들은 떠나기 때문입니다. 하지만 저는 그런 코드베이스를 본 적이 없습니다. 그래서 규칙과 가정은 기껏해야 절반만 문서화되어 있고, 일부 주석이나 문서에 있을 수 있으며, 그 주석이나 문서는 해당 코드베이스 부분을 편집할 다음 사람이 볼 수도 있고 보지 못할 수도 있습니다. 그렇게 계속됩니다.
저는 Windows, Mac, Linux, Android, iOS에서 실행되는 코드베이스에서 작업합니다. 이러한 OS는 시간이 지남에 따라 변하고, 요구 사항이 변하고, API가 변하고, 세상이 변하고, 사람들이 하는 새로운 일에 새로운 API가 필요하며, 크로스 플랫폼 솔루션에 대한 우리의 원래 선택은 더 이상 완벽하게 맞지 않습니다. 우리는 계속 움직이고 출시해야 하며, 세상을 멈추고 재설계할 수는 없습니다. 게다가 원글 작성자처럼, 모든 [...]
- cebert
저렴한 오프쇼어 계약자와 일해 본 적이 있다면 이것이 사실임을 알 것입니다...