▲

코드는 부채임 (Code is Debt)

 (tornikeo.com)
16P by GN⁺ 5일전 | ★ favorite | 댓글 5개
  • AI 코딩 도구 사용은 "코드 부채"를 늘리는 일임
  • 동일한 제품과 매출을 가진 두 회사 중, 100만 줄 코드를 가진 회사보다 10만 줄 코드로 운영되는 회사가 훨씬 더 이해와 수정이 빠름
  • 즉 코드가 많을수록 부채가 쌓인다는 의미이며, AI 코드 생성은 생산성을 높이지만 동시에 부채를 증가시키는 행위로 해석할 수 있음
  • 부채는 긍정적/부정적 양면성을 가짐
    • 긍정적: 단기간에 빠른 성장을 가능하게 함
    • 부정적: 장기적으로 관리 실패 시 프로젝트 붕괴 위험 을 초래함
  • 즉, 부채는 좋거나 나쁠 수 있고, 이자가 있거나 없을 수 있으며, 빠른 성장을 가능하게도 하지만 프로젝트를 붕괴시킬 수도 있음
  • 중요한 것은 도구의 사용 여부가 아니라, 책임 있게 관리하는 태도임
  • 도구에 대한 손쉬운 접근성을 보장하면서도, 생성된 코드의 품질과 장기적 비용을 고려해야 함
▲
ndrgrd 5일전  [-]

코드가 매우 길어도 "무슨 일을 하는지"를 쉽게 설명할 수 있다면 부채가 아닙니다.

AI의 무분별한 사용은 그걸 어렵게 만들기 때문에 부채를 만든다고 이야기하는것이구요.

답변달기
▲
mulmuri 5일전  [-]

본문에 명확하게 명시되어있지 않긴 한데, AI로 코드를 작성하면 사람이 직접 작성한 것에 비해 익숙하지 않아서 부채가 된다는 의미일수도 있지 않을지?

답변달기
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • 표면적으로 코드 라인 수(LOC)로 모든 것을 재는 방식은 단편적임을 느낌. Company A가 1백만 줄의 코드를 훨씬 깨끗하게 잘 정리하고 문서화했다면, 10만 줄의 미흡하게 작성된 Company B보다 더 좋은 상황이라고 할 수 있음. 핵심은 코드가 아닌 복잡성이 문제이고, 라인 수는 복잡성을 대략적으로 측정하는 지표일 뿐임. 코드는 자산임. 소프트웨어 회사의 산출물이자 자산임. 물론 자산이 많으면 복잡성도 올라가지만, 그건 너무 당연한 이야기임. 미국의 고속도로망이 유지 보수가 어렵고 복잡하기만 하다며 전적으로 부정적으로 볼 수 없는 것과 같음. AI 이슈는 제쳐두더라도, 결국 저자의 주장은 "복잡성이 적을수록 좋다"라는 기본적이고 누구나 알 만한 결론임. 그래서 이 글의 가장 중요한 요점은 "AI 코딩 도구가 불필요한 복잡성을 완성 코드에 더하지 않는지 꼭 확인하라"는 수준으로 압축할 수 있음

    • 난 오히려 복잡성이 여기에서 핵심 쟁점은 아니라고 생각함. 이미 살아남은 소프트웨어 비즈니스가 있다고 가정하고 거꾸로 생각해 보자면, 모든 비용(구매, 임금 등)은 원칙적으로 가능한 한 줄이는 것이 최선임. 복잡성이 단순성보다 나쁘다고는 하는데, 그건 진짜로 복잡하면 더 비싸기 때문임. 하지만 궁극적으로 중요한 건 단기든 장기든, 자본이든 운영이든 비용 자체임. LLM이 생성한 코드가 비용을 줄여주는지, 아니면 올리는지가 진짜 문제임. 코드 크기, 복잡성, 그리고 OP나 너가 언급하지 않은 수없이 많은 변수들이 다 중요함

    • 난 내 함수의 복잡성을 cyclomatic complexity로 보는 편임. SwiftLint로 복잡성을 측정해서 기준을 넘으면 표시되도록 함. 가끔은 대충 쪼개기도 하는데, 보통 더 단순하게 바꿀 방법을 꼭 찾으려고 함. 내 파일들은 꽤 길지만, 주석과 코드의 비율을 50:50 정도로 맞추려고 노력함. LLM에게 복잡성을 줄이고 주석을 늘리는 프롬프트를 주면 충분히 잘 해낼 것 같음

    • 코드는 휘발성 화학물질처럼 자산이자 부채임. 제대로, 신속하게 사용하면 돈을 벌 수 있지만 방치하거나 흘리면 부채가 됨. 소스코드는 스스로 변질되지는 않지만, 조직의 목표와 프로세스가 바뀌면서 '목적 적합도'는 계속 변함

    • "왜 우리는 단순한 소프트웨어를 만들지 못하는가?"라는 주제가 재밌게 느껴짐. 복잡성에 대해 "시스템들이 상호작용할 때 복잡성이 생긴다. 복잡한 시스템은 비합리적으로 치달을 수 있고, 뜻밖의 창의성도 나온다"는 점이 인상적임

    • 나는 소프트웨어 자체가 자산이지 코드가 자산은 아니라고 생각함. 마치 고속도로의 자산이 콘크리트가 아니라 완성된 인프라이기에. 콘크리트의 품질이 자산의 가치감소(감가상각)와 유지보수 비용에 영향을 미치고, 이는 다시 자산가치에 영향을 미침. 여기에 위험관리 관점도 반드시 고려되어야 함

  • 내 커리어 초반에는 코드를 많이 작성하는 게 중요하다고 생각했음. 20년이 지난 지금은 더 많은 코드를 지우는 걸 자랑스러워함. 보안 엔지니어 입장에서는 코드가 단순히 부채가 아니라 리스크이기도 함. 특히 외부 라이브러리 의존성이 큰 리스크임. 최근 동료와 함께 러스트 표준 라이브러리만 사용해서 600줄도 안 되는 작은 리눅스 init system을 짰고, 여러 조직의 프로덕션에서 사용 중임. 의존성 없이, 부팅도 1초 안에 끝남. systemd와 수백만 줄의 C 코드가 없어도 충분히 어플라이언스형 리눅스 서버를 만들 수 있음을 느낌. 직접 만들면 코드량이 훨씬 적고 시스템 전체를 완전히 이해할 수 있음

    • 멋지게 만들었는데, 혹시 빠진 건 없을지 궁금함

  • AI가 만들어내는 코드의 최악의 시나리오는, 회사 관점이 아니라 좀 더 개인적인 프로젝트에서 더 명확하게 보인다고 생각함. 내가 잘 아는 10,000줄의 훌륭한 코드를 직접 작성할 수도 있고, 몇 배 더 빠르게, 20,000줄짜리 문제 많은 코드를 대충 만들어낼 수도 있음. 나 스스로는 그 중간에서 균형을 찾으려 함. 만약 계속 개발을 확장하려고 하면, 첫 번째 케이스에서 허비한 시간이 결국 손해라고 생각함

    • 중간점이 항상 존재한다고 봄. 나의 경우 실제 코드 생성을 AI에 맡긴 적은 Bash, Python 스크립트처럼 자기완결적인 코드에만 한정했음. 이런 스크립트들은 커맨드라인과만 상호작용하니까 경계가 분명해서 관리가 쉬웠음. 이런 코드는 한 번 작성 후 다시 본 적이 없음. 하지만 코어 업무 도메인 코드를 AI로 생성하는 건 별 의미 없어서 그렇게 하지 않음. 어차피 코드리뷰를 해야 하고, 정말로 내가 필요로 하는 것은 코드의 유지보수성을 검증할 수 있는 경우임. 코드를 그대로 버릴 수 있거나 간단히 검토만 하면 되는 상황이 아니라면, 코드 생성 도구는 쓸 필요가 없음. 만약 AI가 제품 오너 역할을 하면서 실질적인 비즈니스 손실을 이해하고 개선까지 할 수 있다면 얘기는 달라지지만, 그땐 오히려 사용자가 없어지는 리스크까지 걱정해야 함

    • 나 역시 AI에 너무 많은 코드를 믿고 맡겼을 때마다 언젠가는 잃어버린 생산성의 대가를 톡톡히 치렀음. 만약 모든 게 vibe coding(그때그때 AI로 입맛대로 짜는 것)으로 된 앱이라면, 가장 필요한 역량은 “정말 이 기능이 필요했나?”를 판단하는 능력일 것 같음. 스파게티 코드 디버깅에서 한 줄 한 줄 무슨 역할인지 전혀 파악 안 되는 건 진짜 고통스러울 것 같음

    • 첫 번째 경우에서 시간을 잃었다고 했지만, 두 번째(더 나쁜 코드, 더 빠른 시간) 경우도 결국은 시간 손실임. 본질은 중간 지점 찾기에 있다고 생각함

  • 간략하고 변수명을 잘못 짓거나, 너무 영리한 코드는 오히려 장황하고, 잘 문서화되어 변수명이 풍부한 코드에 비해 훨씬 못함. 부채는 결국 코드를 이해하고 변경, 확장하는 데 드는 시간에 비례함. 코드 라인수는 부채를 완벽하게 측정할 수 있는 지표도 아님. 정말 모든 조건이 같다면, 코드양을 줄이면 읽기 쉬운 코드가 희생되어 부채가 오히려 늘어날 수 있음. 그래서 '이론의 부재가 부채다'라는 주장이 더 맞는 것 같음. 오히려 짧은 코드 자체가 LLM 관점에서 부채일 수도 있음. LLM 사용이 이론 구축을 최소화시키기 때문인데, 이는 AI가 프로젝트 전체에 대한 이론을 스스로 만들고 올바르게 엔지니어에게 전달하지 못하는 현 상황에서는 특히 그렇다고 생각함

    • 나는 프로그래밍을 이론 구축의 과정으로 보는 걸 좋아함. 특히 비즈니스용 프로그램일 경우에는 이 이론이 비즈니스 중심이어야 함. 예를 들어, "이 코드베이스에 개발자를 쉽게 채용할 수 있는가", "사업 모델이 얼마나 안정적인가", "각 기능의 비즈니스 중요도가 어떤가" 같은 관점이 꼭 들어가야 한다고 생각함

    • 갑자기 아이디어가 떠오름. AI에게 코드 안의 변수명/함수 설명을 물어보는 게 가능할까 궁금함. 난 지금까지는 코드 생성에만 AI를 써봤음

  • 내가 오래 다녔던 회사 중에는 자체 코드 자산은 없지만 핵심 비즈니스가 외부 3rd party 엔터프라이즈 서비스에 의존하는 곳들도 있었음. 여기서 궁금한 점은, 이런 경우 실제로 얼마나 많은 코드가 있다는 걸 어떻게 측정해야 할까? 예를 들어 레거시 SaaS 사업자에 의존하면, 그쪽 코드 라인 수도 우리 부채로 봐야 하는지 고민됨

    • 내가 보기엔 3rd party 서비스에 의존할 때 가장 큰 리스크는, 그쪽이 망하거나 인수 합병으로 서비스 조건이 바뀌는 거임. 대부분 자본금만 큰 스타트업에서 서비스가 제대로 자립하지 못한 상황에서 우리가 그걸 사용해야 하는 경우가 많음

    • 이 부분 완전 공감함. 예전 회사에서 이메일 마케팅 SaaS를 썼는데, 우리가 만든 통합 코드가 고작 500줄임에도, 서비스에 문제가 많아 불 끄기에 엄청 애먹었음. 결국 우리가 필요한 기능만 따로 다시 구현해서 인하우스로 가져오니 비용과 고생을 엄청 아꼈고, 코드 라인은 약 3천 줄 늘었음

  • 잘 이해가 안 감.

    1. 코드를 아예 원하지 않기 때문에 AI 코딩도 필요 없다는 말인가? 코드가 필요 없다면 이 논의는 무의미해짐
    2. AI가 코드량도 많고 질도 낮은 코드를 만든다는 게 가정이라면, 그 전제만으로도 AI를 쓸 필요가 없다는 결론에 도달하게 됨. 하지만 이건 큰 전제이고 증거도 없으며 기사에도 없는 주장임. 가정을 바꾸면:
    3. AI가 내가 쓸 때보다 더 적고 더 나은 코드를 만들면? 그럼 써야 하지 않을까?
    4. AI가 내가 만든 것과 동일한 품질을 50% 빠르게 해도, 역시 써야 하지 않을까?

  • 코드는 확실히 자산임은 분명하지만, 하드웨어와 마찬가지로 다양한 원인(결함, 소프트웨어/하드웨어 업계 변화 등)으로 가치가 감가상각됨. 소프트웨어 코드가 많아질수록 매년 감가상각해야 하는 비용이 올라감. 관리를 충분히 안 하면(예: 개발자 수 대비 코드가 너무 많거나) 나중에 문제를 고치는 비용이 기하급수적으로 커짐. 감가상각 개념에 '이자'가 붙는 셈임. 그래서 '부채'라는 표현을 쓰는 게 이해는 되지만, 완벽하게 일치하는 개념은 아님

  • 당연히 가장 완벽한 저장소는 이거라고 봄

  • 예전에는 한 달에 마이너스 2만 줄 코드를 지우는 게 내 자랑거리였음. 몇 년 전엔 20명 리모트 개발자 팀과 그걸 다시 해보려 했는데, 풀 리퀘스트가 쏟아져 도저히 따라갈 수 없었음. 지금은 Claude Code와 GPT랑 페어 프로그래밍을 하는데, 완전 후자의 느낌임. 여기엔 스마트한 리팩토링 기회가 있다고 봄. 다만 더 많은 맥락이 필요할 것 같음. Cursor와 Claude opus 4.1으로 레거시 코드에 이런 거 시도해 봤지만 백만 토큰으로도 부족했음. 아마도 개인 LLM이랑 공유 LLM 사이를 번역하는 식으로 하면 어떨까 싶은데, 혹시 이런 경험 있는 사람이 있는지 궁금함

  • 아무도 "기능 X를 완전히 구현하는 데 절대적으로 필요한 최소 코드량은 얼마일까?"라는 아주 중요한 질문은 잘 하지 않는 것 같음. 물론 정확히 답은 불가능하지만, 이런 생각 자체가 효율적인 마인드셋을 만들어줌. 반면에 사람들은 실질적으로 중요하지 않은 형식 검증 등엔 관심이 많음. 형식 검증은 최소 실현 코드량을 고려하지 않으면 오히려 낭비적이고 무의미해짐. 그리고 보통 엔지니어가 작성한 코드는 다 좋은 줄 아는데, 실제론 대부분 불필요한 추상화와 복잡성을 추가하면서 오히려 일이 많아짐. 소프트웨어 엔지니어링의 상당 부분은 오히려 마이너스 가치임. 물론 플러스와 마이너스가 혼재해 그래서 판단이 더 어려움

답변달기
▲
killdong 5일전  [-]

표면적으로 코드 라인 수(LOC)도 중요함. 생산성 측면에서 한페이지 읽고 이해하는 것과 , 3줄읽고 이해하는 것은 다름.

답변달기