▲

병목은 결코 코드가 아니었다

 (thetypicalset.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Codex는 .txt에서 1년 넘게 미뤄온 구조화 생성 알고리듬 실험의 첫 작동 버전을 몇 시간 만에 만들었지만, 핵심 변화는 개인 코딩 속도보다 협업 병목이 드러난 데 있음
  • 에이전트가 구현을 맡으면 팀의 속도를 늦추는 것은 코드 작성자가 아니라 로드맵, 인수 기준, 설계 문서처럼 에이전트가 바로 실행할 수 있는 정밀한 명세를 만드는 일로 바뀜
  • 코드 작성 비용이 낮아지면 이전에는 만들지 않았을 프로토타입과 내부 도구가 늘어나며, 사용자가 흡수할 수 있는 속도는 그대로라서 무엇을 만들지 않을지 정하는 집중의 규율이 더 중요해짐
  • 에이전트는 Slack, PR, 이슈, 커밋, 설계 문서에서 암묵적 결정과 관례를 추출해 지식베이스를 만들 수 있지만, 사람이 직접 쌓는 공유 맥락을 완전히 복원하지는 못함
  • 다음 10년의 우위는 최고의 모델보다 50명, 200명, 2,000명 규모에서도 줄어드는 결정 집합에 정렬되는 조직적 일관성을 유지하는 회사에 있을 가능성이 큼

코딩 에이전트가 바꾼 병목

  • .txt에서 1년 넘게 미뤄온 실험은 구조화 생성 알고리듬과 오픈소스 대안을 테스트하고, 단순히 “이 문자열을 받아들이는가”가 아니라 “올바른 토큰 분포를 생성하는가”에 가까운 문제를 확인하는 작업이었음
  • 이 실험은 로드맵에 계속 남아 있었지만, Codex에 접근법을 30분가량 설명한 뒤 몇 시간 만에 작동하는 첫 버전이 만들어짐
  • 코딩 에이전트는 개인이 코드를 쓰는 방식을 이미 크게 바꾸고 있지만, 개인 생산성 향상이 곧바로 소프트웨어 산업 전체의 속도 증가로 이어진다고 보기는 어려움
  • 영향력 있는 소프트웨어는 여러 사람이 협업해 만드는 경우가 많으며, 분석의 더 흥미로운 단위는 개인 생산성이 아니라 협업임
  • 소프트웨어는 사람들이 시스템이 무엇을 해야 하는지 협상한 뒤 남는 결과물에 가깝고, 코드는 중요하지만 더 어려운 작업의 잔여물임

로드맵이 한계가 됨

  • 에이전트가 구현을 맡는 팀에서 속도를 늦추는 것은 에이전트가 바로 집어 실행할 수 있을 만큼 정밀한 명세를 만드는 일임
  • 로드맵, 인수 기준, “우리가 실제로 원하는 것”은 테스트 스위트, 티켓, 설계 문서 같은 형태로 명확하게 적혀야 함
  • 기능은 매우 빠르게 구현되고, 엔지니어가 다른 엔지니어를 기다리는 대신 다음에 올바르게 작성된 명세를 기다리는 상황이 생김
  • 병목은 코드를 쓰는 사람에게서 어떤 코드가 존재해야 하는지 결정하는 사람에게로 이동하며, 이는 곧 관리의 문제임

더 싸진 코드는 더 많은 합의를 요구함

  • 코드 작성 비용이 낮아지면 같은 결과를 위해 10%만 노력하는 것이 아니라, 이전에는 할 가치가 없던 결과에 같은 노력을 쓰게 됨
  • 3개월 전에는 “시간 낭비”로 여겨졌을 프로토타입이 오후 한 번에 만들어지고, 명확한 수요가 없던 내부 도구가 만들어졌다가 잊히기도 함
  • 사용자가 흡수할 수 있는 기능의 속도는 팀이 10개를 출시하든 50개를 출시하든 대체로 그대로임
  • Steve Jobs가 1997년에 말한 것처럼 “집중은 거절하는 것”이며, Apple은 그해 제품군의 약 70%를 정리했음
  • 에이전트가 있으면 새 기능을 출시하는 감각이 더 쉬워지기 때문에, 무엇을 만들지뿐 아니라 무엇을 만들지 않을지 정하는 규율이 더 어려워짐

맥락이 핵심 자원이 됨

  • 협상과 합의는 조직 안의 공유 맥락 위에서 돌아감
  • 맥락은 무엇을 만들고 있는지, 왜 중요한지, 무엇을 시도했는지, 누가 무엇을 결정했는지, 무엇이 핵심이고 무엇이 남은 흔적인지를 포함함
  • 팀의 인간은 같은 방에 있고, 같은 Slack 채널을 읽고, 새벽 2시에 같은 장애를 디버깅하면서 맥락을 자연스럽게 쌓음
  • 이 맥락의 대부분은 문서화되지 않으며, 시니어 엔지니어가 PR 리뷰에서 “이건 마이그레이션을 깨뜨릴 것”이라고 말할 때도 문서 없는 맥락을 쓰는 경우가 있음
  • 에이전트는 그런 식의 삼투를 할 수 없고, 방 안에 있거나 계획 대화를 반쯤 듣거나 지난 장애의 기억을 지닌 채 맥락을 얻지 못함
  • 프롬프트, 파일 트리, 도구, 명시적 지시 안에 넣지 못한 맥락은 에이전트가 안정적으로 갖고 있지 않음
  • 맥락이 없으면 에이전트는 조금 잘못된 질문에 대해 그럴듯한 답을 만들 수 있음
  • .txt에서 에이전트가 유용한 일을 했을 때도 실제로는 사람이 맥락 작업을 해둔 것이며, 다음 10명의 엔지니어가 그 그림을 자동으로 갖게 되는 것은 아님
  • 조직이 늘 암묵적으로 의존해온 맥락은 이제 속도를 제한하는 입력이 되었고, 사람은 명시적 버전을 읽을 대상이 없었기 때문에 이를 암묵적으로 남기는 경향이 있음

에이전트가 맥락을 생산하는 루프

  • 사람이 쉽게 소비할 수 있는 맥락을 만드는 일은 사람들이 좋아하지 않는 작업임
  • 에이전트는 PR 댓글, 닫힌 이슈, 커밋 메시지, 오래된 설계 문서, Slack 아카이브를 빠짐없이 읽고, 아무도 문서화하지 않았던 패턴을 추출하는 데 강점이 있음
  • .txt에서는 코드베이스, 이슈, PR, 스레드를 크롤링해 암묵적 결정, 관례, “왜 이렇게 했는지”를 지식베이스로 만드는 에이전트를 구축하기 시작했음
  • 이 지식베이스는 단순히 “이 모듈이 존재한다”가 아니라, “마이그레이션이 기존 동작을 보존해야 해서 이 모듈이 이상하다”거나 “이 벤치마크는 이전 최적화가 분포를 조용히 바꿨기 때문에 중요하다” 같은 맥락을 담음
  • 다른 에이전트는 코드베이스에서 행동해야 할 때 이 지식베이스를 사용함
  • 사람이 비공식적으로 수행하던 삼투가 에이전트와 사람 모두 읽을 수 있는 형태로 외부화됨
  • 맥락을 소비하는 에이전트에는 맥락을 생산하는 에이전트가 필요하며, 이 루프가 돌아가면 조직은 스스로 만들지 않았을 문서화된 기반을 갖게 됨
  • 다만 이 루프가 만드는 것은 언제나 부분적인 그림임
  • Michael Polanyi의 말처럼 “우리는 말할 수 있는 것보다 더 많이 알고” 있으며, 어떤 핵심 맥락은 말로 적힌 적이 없기 때문에 존재하고, 적는 순간 달라질 수 있음
  • 사람이 직접 만나 쌓는 삼투 층은 문서화된 부산물만으로 완전히 복원될 수 없음
  • 결과물은 완전한 복원이 아니라 유용한 출발점에 가까우며, 그것이 누적 효과를 내기에 충분한지는 아직 실험적인 질문으로 남아 있음

새로운 해자는 기술보다 조직에 있음

  • 다음 10년의 승자는 반드시 최고의 모델이나 최고의 에이전트 인프라를 가진 회사가 아니라, 50명, 200명, 2,000명으로 커지면서도 줄어드는 결정 집합에 정렬된 채 1인당 더 많은 산출을 내는 회사일 가능성이 큼
  • 이런 회사는 에이전트가 오기 전부터 가장 어려운 문제가 일관성이라는 점을 알고 있었던 조직임
  • 이는 문화와 관리의 문제이며, 항상 그래왔음
  • IDE, 버전 관리, CI, 마이크로서비스, DevOps 같은 이전 세대 도구는 더 나은 도구로 조정을 해결하겠다고 약속했지만, 실제로는 이미 존재하던 조직적 일관성을 증폭하는 역할을 했음
  • 작은 팀은 일관성을 거의 공짜로 얻기 때문에 증폭 효과가 대체로 긍정적이며, 에이전트를 강하게 지지하는 목소리가 작은 팀에서 많이 나오는 이유도 그들의 맥락에서는 대부분 맞기 때문임
  • 일정 규모를 넘으면 일관성은 만들어지고 유지되어야 하며, 증폭 효과는 양방향으로 날카로워짐
  • 좋은 조직은 더 좋아지고, 나쁜 조직은 더 빠르게 망가지는 방향으로 움직임
  • 에이전트는 이전 도구들보다 훨씬 큰 증폭기이며, 개인이 코드를 더 빨리 쓰게 하는 수단으로는 과대평가되고 조직이 아는 것을 외부화하게 만드는 수단으로는 과소평가됨

회사 문화의 확장으로서의 에이전트

  • 에이전트는 자기 생각의 확장처럼 느껴질 수 있고, 그 감각은 강력함
  • 더 어려운 과제는 에이전트를 회사 문화의 확장으로 만드는 것임
  • 이를 위해서는 글쓰기 문화, 자신이 여전히 맥락 병목인 지점을 식별할 만큼 사려 깊은 관리, 일관성을 유지해야 할 실제 산출물로 다루는 사람이 필요함
  • 새로워진 점은 이런 것들 중 일부를 이제 구축할 수 있다는 점임
  • 읽고 추출하는 루프는 그 한 형태이며, 다른 형태도 나올 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 경력 내내 팀 회의, 애자일 의식, 이슈 추적기, 백로그, Slack, 이메일, 설계 리뷰처럼 자신들이 가장 본질적이고 성스러운 활동이라며 지켜야 한다던 몇 시간짜리 코딩 몰입 상태를 방해하는 모든 것에 불평하던 엔지니어들이, 기계가 코드를 자기들보다 빨리 쓰게 되자 갑자기 부끄러움도 없이 협업 활동의 중요성과 코드·코딩의 하찮음을 설교하기 시작하는 게 우습게 느껴짐
    틀린 말은 아니지만, 1년 전까지만 해도 어느 팀에서나 가장 반사회적이고 협업을 안 하던 사람들이 보이는 노골적인 위선은 여전히 놀라움

    • 특정 저자나 아는 사람을 말하는 건가? 온라인 집단 전반에 대한 일반화라면, 개인의 특성을 집단 전체의 특성으로 보는 집단 귀인 오류에 빠졌을 수 있음
      어쨌든 두 가지는 동시에 참일 수 있음: 코드를 쓰는 것이 병목이 아니어서 기능을 배포 가능한 속도보다 더 빨리 개발할 수 있고, 깊은 집중이 필요한 일을 할 때 방해받는 건 짜증 나고 흐름을 끊음
      https://en.wikipedia.org/wiki/Group_attribution_error
    • 이건 거짓 양자택일임. 소프트웨어 개발은 항상 고객부터 코더까지, 그리고 그 사이의 사람들 모두가 같은 이해를 유지하게 만드는 일이었고, 그 사이 사람은 적을수록 좋음
      고객과 코더 사이의 동기화를 높이는 회의는 드물고 귀함. 큰 조직에서는 잘못된 이유로 의식적인 회의가 늘어남. 사람들은 고객과 코더 사이 과정에 자신을 끼워 넣어 존재감을 보이려 함
      개인적으로는 고객, 최종 사용자, UX 디자이너, 실제 이해관계자와의 회의를 좋아함. 기업 내 영향력을 위해 대역폭을 잡아먹는 회사 정치형 바쁨꾼들과의 회의는 질색임. 내 사용자와 나 사이에 또 다른 중간관리자가 끼어들 필요는 없음
    • 그게 왜 위선인가? 예전 세계에서 아주 중요한 과정이 실제 코드 작성이었고, 많은 시간이 들며 방해가 없을수록 큰 이득을 봤다면, 윗선에 진행 보고서를 만들기 위한 제한적 가치의 각종 의식 때문에 끊기는 건 시간 낭비처럼 느껴졌을 것임
      반대로 코드 작성은 매우 빨라졌고, 달성해야 할 비즈니스·기술 요구사항을 이해하는 것이 어려운 부분이 된 새 세계에서는 같은 사람이 그런 의식을 더 우선시하고, AI 에이전트가 코드를 쓰는 동안 방해를 감수할 수 있음
      상황의 사실관계가 바뀌었을 때 생각을 바꾸는 건 위선이 아님
    • 의식과 티켓은 실제 협업에 특별히 효과적이지 않음. 주로 일을 경영진에게 읽기 쉽고 통제 가능하게 만드는 도구임
      회사 밖에서 누군가와 창작 프로젝트를 한다면 Scrum 의식이나 Jira부터 떠올리지 않는 데는 이유가 많음. 협업을 중시하면서도 그런 것들을 비판하는 건 완전히 일관적임
    • 이건 100% 부정과 자존심임. 원치 않게 오래 계약직으로 일해왔는데, 새 팀에 합류할 때마다 똑같은 반응을 봄
      팀은 일이 너무 많아서 아무것도 못 한다고 불평하고, 그래서 매니저가 나를 투입함. 그러면 갑자기 아무것도 넘기고 싶어 하지 않음. 지금도 딱 그 한가운데 있음
      팀은 “완전히 몰렸다”고 하면서도, 내가 처리할 수 있는 거의 모든 일이 자기들이 하는 게 최선이고 도움이 필요 없다고 주장할 여력은 있음. 나는 괜찮음, 앉아서 돈 받으면 됨. 하지만 냄새가 똑같음
      A: 자신들은 대체 가능하고 일이 그렇게 독특하지 않다는 것, B: 병목은 프로세스나 업무량이 아니라 자신들이라는 걸 인정하고 싶어 하지 않음

  • 베테랑 엔지니어들은 속도 문제의 진짜 원인이 항상 기술보다 조직에 더 있다는 걸 알고 있었던 것 같음
    비즈니스가 집중된 생산적 로드맵을 정의하지 못하는 것이 소프트웨어 엔지니어링의 오랜 문제였음. ROI가 거의 없는 다음 반짝이는 것으로 계속 뛰어들면서도 시스템적 기술 부채는 처리하지 못하게 해서, 내가 일한 여러 회사를 장기적으로 망가뜨렸음

    • 베테랑 엔지니어에게는 맞을 수 있지만, AI 이전의 주니어 엔지니어에게 속도는 항상 기술적 문제였음
      C++를 1년 내내 써도 std::unique_ptr를 이해하지 못하는 주니어 엔지니어들을 알고 있고, 이런 사람은 팀 전체에서 항상 속도가 가장 느림
      예전에 주니어 엔지니어 성과 평가를 쓸 때는 실제로 성과가 속도에 크게 좌우됐고, 대략 일정 기간 안에 작성한 버그 없는 코드 줄 수로 측정됐음. 좋은 주니어는 명확히 정의된 기능을 받아 좋은 코드를 빨리 썼고, 좋지 않은 주니어는 같은 일을 받아 느리게 쓰거나 빠르게 버그 많은 코드를 써서 디버깅과 재작성에 훨씬 많은 작업을 만들었음
    • 비즈니스가 집중된 생산적 로드맵을 정의하지 못하는 게 문제라는 데 동의하고, 대부분의 개발자가 시간과 경험을 통해 이를 깨닫는다는 데도 동의함
      비즈니스 근거, 범위, 입력, 원하는 출력을 명확히 이해하면 데이터 모델, 시스템 설계, 코드는 거의 자연스럽게 나오거나 적어도 훨씬 분명해짐
    • “넓은 의미에서 시스템을 설계하는 조직은 그 조직의 소통 구조를 복제한 설계를 만들 수밖에 없다”
      — Melvin E. Conway, 1967
    • 이제 시스템적 기술 부채는 LLM으로 대규모 대응이 가능함. 앞으로의 모델은 이를 지속할 만큼 충분히 좋아질 것이고, 믿지 않는다면 왜 아닌지 설명해보라고 하고 싶음
      먼저 Chinchilla 같은 스케일링 법칙이 어떤 것인지, 검증을 포함한 강화학습이 근본적으로 어떻게 작동하는지 이해하고 있는지 생각해봐야 함
      근본적인 한계가 비즈니스가 자신과 전략을 일관되게 표현할 수 있느냐에 있다는 데는 완전히 동의함
      하지만 지금의 이점은 사실상 무료로 프로토타입을 만들 수 있다는 것임. 예전에는 엔지니어 인력 투자에 극도로 신중해야 했지만, 이제는 같은 시간 제약 안에서 훨씬 더 많은 것을 시도할 수 있음
    • 유능한 엔지니어라면 엔지니어링은 제품 개발의 조립 라인 쪽이라는 걸 이해해야 함
      어떤 기능과 버그 수정을 언제 출시할지, 제품 전반을 어떻게 개발·관리할지가 항상 진짜 도전이었고, 이 전략의 상당 부분은 AI가 빠르게 만들 수 없는 피드백 루프에 의존함
      동시에 비즈니스 쪽 리더들이 자기 쪽의 나쁜 결정에 책임지는 대신 엔지니어 속도를 희생양으로 삼는 경우도 많다고 느낌

  • 보통 병목은 코드가 맞지만, 코드 작성이 아니라 코드 자체임. 내 경력에는 느린 애플리케이션 때문에 생긴 지연이 수없이 많음
    Eclipse 기반 편집기를 써야 하는데 느리고 주기적으로 멈추거나 크래시남. 빌드 작업은 15~20분 걸림. 최대 50ms면 끝나야 할 작업을 영원히 처리하는 웹 앱도 자주 겪음
    이런 목록은 끝없이 이어질 수 있음. 모든 지연은 내 집중을 산산이 깨는 방해임. 지금은 관리직으로 수십 명과 행정적 방해를 다루지만 여전히 회사에서 코드를 씀
    소프트웨어가 느리면 내 최하위 우선순위가 됨. 그게 누구에게 영향을 주든 신경 쓰지 않음. 정말 중요했다면 우리 모두를 끌어내리는 이 느린 소프트웨어 시럽에 인질로 잡혀 있지 않았을 것임

    • 어떤 편집기이고, 왜 Eclipse인가?

  • 코드는 부채임
    코드를 자산으로 보기 쉬울 수 있지만, 근본적으로는 부채임. 새 코드로 가는 일부 “병목”은 산출이 늘어난 부채보다 크도록 보장하기 위해 존재함. 더 빠르게 더 많은 코드를 만드는 에이전트는 더 빠르게 더 많은 부채를 만드는 것임
    코딩 에이전트에 대한 흥분과 회의의 상당 부분은 즉각적인 생산성 증가, 즉 새 기능과 새 제품·새 매출 같은 즉각적인 산출이 장기 부채 증가를 상쇄하는지에 관한 것임. 답은 앞으로 1~3년은 지나야 알 수 있고, 분야마다 다를 것임
    이 관점에서는 이런 병목을 에이전트형 워크플로 안에 직접 넣으려는 시도가 어느 정도 말이 됨. 일관된 프로젝트 비전을 중시하고 새 기능이나 제약 없는 프로세스에 반대할 수 있는 추가 맥락을 코딩 에이전트에 제공하는 것은 가치 있음
    글이 말하려는 게 이건가? 일부 에이전트가 제품 관리 책임을 맡아 가능한 한 많은 것을 응집된 제품 비전으로 종합하고, 그 비전을 최대한 엄격하게 코딩 에이전트에게 상기시키게 하려는 시도인가?
    이런 에이전트가 새 제안과 새 풀 리퀘스트를 “전체 그림에 대한 부합성” 관점에서 검토해야 하는가? 이를 맥락이라 부르든 비전이라 부르든 다른 이름으로 부르든 말임
    이런 에이전트는 맥락을 종합하고 팀 가치와 비전에 언어적으로 맞아 보이는 일관된 로드맵을 제시하는 데 매우 뛰어날 수 있음. 하지만 좋은 관리자나 팀이 가진 분별력을 가질 수 있을지는 회의적임. 특정 로드맵을 빠르고 설득력 있게 승인하는 것이 득보다 해가 클 수도 있음

    • “코드는 부채”라는 말은 너무 단순화함. 코드 그 자체는 자산도 부채도 아님
      추가 복잡성 없이 비즈니스 요구를 해결하는 데 필요한 최소한의 코드는 유지보수 부채가 붙은 자산임. 농부의 트랙터가 유지보수가 필요한 자산인 것과 같고, 방치하면 비트 부패로 감가상각됨
      불필요한 복잡성을 만들기 위한 코드는 순수한 부채임

  • 맞지만, 코드 작성은 항상 뭔가를 가르쳐 줌
    창업자 규모의 스타트업과 수백억 달러 규모의 상장회사에서 일해봤지만, 명세대로 구현하면 문제를 해결할 솔루션을 설명한 제품 명세서, 피치 덱, PRD를 본 적이 없음. 실제로 만들어보면 그것이 어떻게 동작해야 하는지 배우게 됨
    소프트웨어는 복잡하고 상호작용적인 매체임. 문제를 이해하고 해결하고 싶어 하는 사람들과 함께 코드 안에서 반복하는 것만이 가치 있는 제품이 만들어지는 유일한 방식이었음. 회의와 다이어그램도 도움이 되지만, 동작하는 소프트웨어를 작성하기 전까지는 가진 것이 있는지 알 수 없음

  • “목표는 우리의 구조화 생성 알고리즘과 그 오픈소스 대응물을 테스트하는 것이었고, 순진한 ‘이 문자열을 받아들이는가?’를 실제 문제에 가까운 ‘올바른 토큰 분포를 생성하는가?’로 대체하는 것이었다… 지난달 Codex에 30분 동안 방법을 설명했다. 몇 시간 뒤 작동하는 첫 버전이 나왔다. 그게 전부였다”
    이는 병목이 실제로 코드였다는 걸 증명함. 이제는 AI가 그 코드를 썼을 뿐임
    “병목은 코드가 아니었다”고 생각한 사람은 이미 목표를 논의해봤고 머릿속에서 일관되게 정리해둔 상태였음
    코드가 병목이라는 말이 꼭 “이 기능을 원했지만 코딩하는 데 몇 달이 걸렸다”는 뜻일 필요는 없음. “2년 동안 이 기능을 원했지만, 앉아서 코드로 옮기고 5~10일을 쓰는 마찰 때문에 미뤘다”도 포함
    코드가 병목이 아니었다면 그냥 앉아서 직접 썼을 것임. 하지만 직접 코딩하는 노력과 시간을 들이고 싶지 않았고, LLM만큼 적게 걸리지 않는다는 것도 알고 있었음
    최종 명세가 명확하지 않은 경우에도 탐색적 코드 작성, 확인, 폐기, 새 설계 재시도는 LLM을 쓰면 더 빠름. 정확히 “코드” 부분이 빨라지기 때문임
    다시 말해 병목은 코드였음
    이 글 자체도 뻔한 표현을 피하라는 지시를 넣은 AI 생성 글처럼 보이고, 그래서 여전히 읽기가 지루함

  • 글에서 “Jevons Paradox: 어떤 것이 더 싸지면 덜 쓰는 게 아니라 더 많이 쓰게 된다”라고 했는데, 이는 제번스 역설을 망가뜨린 표현임
    저 문장은 역설이 아니라 매우 자연스러운 효과임. 어떤 것이 더 싸지면 사용량이 늘어나는 건 당연함
    제번스 역설이 실제로 설명하는 것은 어떤 자원의 사용이 더 효율적이 되어 특정 작업에 필요한 양이 줄었는데도, 그 자원의 총 사용량은 증가하는 상황임

    • 왜 이것을 역설이라고 표현하는가? 단순한 원인 하나는, 이제 더 적은 자원을 쓰므로 더 싸졌고, 그래서 주어진 작업이 전보다 더 많이 수행되기 때문임
    • 물론 어떤 것이 더 싸지면 사용량이 늘어나는 건 당연함
      하지만 자원 사용이 더 효율적이 되면 그 “사용”의 가격이 더 싸지는 것도 당연하지 않은가?
      그래서 효율이 증가하므로 사용량이 당연히 올라감. 이를 역설이라 부르는 이유는 일부 사람들이 효율 향상이 소비를 줄이는 좋은 방법이라고 순진하게 생각하기 때문임
      “역설”이라고 불리는 거의 모든 것은 이렇게 뻔함
    • 역설은 우리가 그것에 더 많은 돈을 지불한다는 데 있어야 하는 것 아닌가?
      또는 어떤 프로세스가 더 효과적, 즉 더 짧은 시간이 걸리게 되면 우리가 그 프로세스에 더 많은 시간을 쓰게 된다는 것일 수도 있음

  • 무엇을 위한 병목인가? 더 많은 기능?
    소프트웨어의 양이 회사의 성공을 결정한다고 생각하지 않음. 맥락의 양을 포착하는 것도 그렇게 중요하다고 보지 않음
    중요한 건 맥락의 품질임. 인간들이 얼마나 잘 추론하는가?
    그다음은 태도임. 인간들이 나쁜 상황에 얼마나 잘 대응하는가?
    그다음은 자원 관리임. 회사가 사람과 돈을 얼마나 잘 다루는가?
    마지막은 운임. 통제할 수 없는 요소 중 얼마나 많은 것이 우리 편인가?
    이런 것들이 회사의 꽤 좋은 병목들임. 에이전트가 이것들을 곧 해결할 것 같지는 않음

    • 비즈니스에서 소프트웨어 애플리케이션은 돈을 만들어내는 “그 일”을 돕는 도구임. 소프트웨어 세계에 있는 우리는 그 일이 소프트웨어와 소프트웨어 기능이라고 생각하지만, 그 바깥에서는 대개 다른 “일”이 있음
      비소프트웨어 비즈니스가 쓰는 소프트웨어 애플리케이션을 더 좋게 만드는 병목은, 소프트웨어가 실제로 비즈니스에 이득이 되는 소프트웨어 작업을 모두 하도록 보장하는 데 있음
      시간을 절약하고, 인간을 더 생산적으로 만들고, 인간 오류를 줄이고, 비즈니스를 더 효율적으로 만들고, 이익률을 높이는 것들임
      이 모든 것은 예측하고 정량화하기가 꽤 어려움. 비즈니스에 도움이 될 아이디어로 시작하고, 설계하고, 프로토타입을 만들고, 시험할 수도 있음. 결국 소프트웨어 애플리케이션을 만들거나 개선하고, 비즈니스를 얼마나 더 좋게 만들었는지 측정하려 함
      이 모든 과정에서 소프트웨어가 올바른 문제를 올바른 방식으로 다루고, 결국 비즈니스를 더 좋게 만드는지 보장하는 것은 어려운 문제임. 소프트웨어를 만드는 것이 얼마나 빠르고 쉬워졌는지와 무관함
      그래도 속도는 정말 도움이 될 수 있음. 프로토타입을 만들고 시험하고 피드백 루프를 개선할 수 있음
    • “더 많은 기능?”이라기보다는 코드 변경임. 꼭 기능만이 아니라 버그 수정, 일반 유지보수, 테스트 가능성을 높이기 위한 리팩터링도 포함
      AI 코딩 도우미를 쓰면 과거에 주니어 개발자 작업으로 여겨지던 것들이 이제는 빠른 프롬프트와 백그라운드에서 도는 에이전트로 구현됨
      이런 주니어 개발자 작업은 이제 코딩 도우미가 거의 사람 개입 없이 손쉽게 전달함. 백로그는 새 항목이 추가되는 속도보다 더 빨리 비워짐. 그리고 처리 능력이 더 이상 문제가 아니게 되면서 새 항목도 점점 더 많이 추가됨
      이제 과제는 변경량을 따라잡는 것임. 우리 조직에서 직접 보고 있음
      다른 병목을 떠올릴 수 있다고 해서 코드 생성이 병목이 아니었거나, 지금 병목이 아니라는 뜻은 아님. 백로그라는 개념 자체가 그것이 병목임을 보여줌

  • “소프트웨어는 한 무리의 인간들이 시스템이 무엇을 해야 하는지 서로 협상하고 난 뒤 남는 것이다”
    이 표현이 마음에 듦. 특히 맥락에 대해 동의함. 장기 유지되는 경험 많은 팀이 보상받는 지점이 바로 거기임
    그런 팀을 수십 년 동안 관리했음. 결국 우리 부서가 통합될 때, 연차가 가장 낮은 엔지니어도 10년차였음
    팀이 그렇게 오래 함께 있으면 소통 오버헤드는 거의 무시 가능한 수준으로 떨어짐
    그래서 요즘 하루살이 같은 재직 기간 문화가 가장 속상함
    요즘은 주로 혼자 일함. 생산성은 매우 높지만 범위는 정말 제한적임
    좋은 팀에 속해 있던 시절이 그리움

  • 대체 어떤 프로젝트를 하길래, 경영진이 원하는 기능을 이해하는 것만 어려운 부분이고 나머지는 그냥 “타이핑해내면” 되거나 요즘은 LLM에 넘기면 되는 건가?
    그게 하는 일이라면, HN의 많은 사람들이 LLM이 자신들을 대체할 수 있다고 생각하는 것도 놀랍지 않음

    • 이 주제의 논의는 항상 모두가 코드를 같은 방식과 같은 기능으로 쓴다고 가정하고, 세상 나머지를 그 렌즈에 억지로 끼워 넣는 것처럼 보임
      그래서 우리는 또 한 번 같은 원을 돌며 불안을 말하고, 서로 빗나간 이야기를 하고, 30분 뒤 다음 논평 기회를 기다림
    • 연차가 높아질수록 코드는 더 대체 가능해 보이고, 프로세스가 더 중요하고 어렵게 느껴졌음
    • CRUD 앱의 80% 정도가 이렇다. 가끔 흥미로운 문제가 있긴 하지만 상위 20% 같은 건 아님
      대부분은 오프쇼어링과 정리해고 사이클 때문에 코드 품질 면에서 뜨거운 쓰레기임
    • 반사. 얼마나 제한된 프로젝트 경험을 했길래 소프트웨어 개발 공간에 코드 난이도와 조직 문제 사이의 거대한 연속체가 없다고 생각하게 되는가?
답변달기