AI가 Jira를 해킹하게 될 것임

• 엔지니어링 생산성은 대시보드 지표나 신규 기능 수로는 제대로 측정할 수 없음
• 대부분의 기업은 엔지니어링의 본질적인 “구조 관리”보다는 산출물(신규 기능, 배포 속도 등)만을 집착적으로 관리함
• AI 코딩 도구는 겉보기 좋은 산출물을 쉽게 만들어내지만, 실제 시스템의 기초와 복잡성, 맥락은 제대로 다루지 못함
• 숙련된 엔지니어 팀을 AI나 저비용 인력으로 대체하면, 단기적으로는 문제가 없어 보여도 시간이 지날수록 근본적인 구조가 무너짐
• “상식(common sense)”이 결여된 경영과 AI 도입이 심각한 위험을 초래할 수 있음, 결국 기술과 비즈니스 모두 실질적 이해가 중요함

---

대시보드와 지표가 놓치는 진짜 엔지니어링

• “Big Agile” 환경에서 엔지니어링은 신규 기능, 배포 속도 등 눈에 보이는 산출물로만 평가됨
• 수십억 달러 규모의 생산성 대시보드와 도구가 있지만, 실제로는 본질을 측정하지 못함
• 진짜 엔지니어링은 시스템 구축, 유지, 발전이라는 복합적이고 상호 연결된 작업임
  • 구조적 의존성, 리소스 할당, 아키텍처 관리 등 “보이지 않는 일”이 조직의 생존에 필수적임
• 하지만 대부분의 관리와 지표는 이런 본질적 활동을 투명인간 취급함

기술 부채와 관리의 맹점

• 기술 부채는 종종 “개발자가 하고 싶은 일” 정도로 취급됨
• 실제로 기술 부채 해결이 필요하다면, 신규 기능에 은근히 포함시켜야만 통과됨
• 이처럼 핵심 구조 관리가 후순위로 밀리면서, 조직 전체가 산출물 위주로 왜곡됨

산출물 위주 AI 도입의 위험

• AI 코드 생성은 표면적 기능을 빠르게 만들어내는 데 매우 뛰어남
• 표면적 작업(인터페이스 구현 등)은 쉽게 보이지만, 실제로는 시스템의 구조와 맥락이 핵심임
  • “집을 짓는 일”이 단순 작업(벽지, 변기 설치 등)만의 조합이 아님
  • AI는 이런 본질적 연결 구조를 알지 못하고, 잘못 연결하거나 논리적 단절을 일으킴
  • AI의 hallucination(환각) 문제: 그럴듯하지만 사실과 전혀 다를 수 있음

구조를 무시한 경영의 단기 착시

• 숙련된 팀을 해고하고 AI/저가 인력으로 대체해도 단기적으론 문제가 드러나지 않음
• 이미 잘 만들어진 구조(기초)가 있기 때문에, 즉각적인 붕괴가 보이지 않음
• 하지만 시간이 지나며 기초가 무너지기 시작하고, 그 때는 되돌릴 수 없는 지경에 이름
  • 핵심 인프라, 유지보수 노하우, 맥락이 모두 사라짐

엔지니어링이 가진 사회적 위험

• 엔지니어링은 이제 모든 사회 인프라의 기반임 (헬스케어, 금융, 미디어, 정부, 국방 등)
• 대부분의 사람과 리더는 이런 구조적 본질을 제대로 이해하지 못함
• 잘못된 AI 도입과 “Big Agile”의 표면적 접근이 핵심 시스템에 위험을 초래할 수 있음

“상식”의 부재와 그 치명성

• 예를 들어, AI 청소 로봇이 설거지기에 종이접시를 넣는다면, 일반인은 바로 문제를 인식함
• 하지만 소프트웨어 시스템에선 경영진, 리더, 비개발자는 이 기본 상식을 갖지 못함
  • 실무를 경험하지 못하고, “티셔츠 사이즈”, “포커 플래닝” 등 형식적 용어로만 관리함
• 이로 인해 2천억 달러 규모의 비효율적 산업과 자기복제적 관료주의가 유지됨

AI 시대의 진짜 경쟁력: 직관적 이해와 상식

• AI를 제대로 활용하려면, 해당 분야의 실질적 이해와 상식이 필수임
• 표면적 지표와 산출물이 아니라, 실제 구조와 맥락을 볼 수 있어야 함
• 이를 갖추지 못한 리더와 조직은, 결국 스스로 무너지거나 경쟁사에 밀려 사라질 것임

• 결론적으로, AI와 도구보다 상식과 본질적 이해가 진짜 경쟁력임

[softer]

글이 맛있네요

[GN⁺]

Hacker News 의견

• 나는 SWE에서 제품 관리자, 그리고 이제 기사에서 언급된 이사회실의 만화 영화 악당이라는 역할까지 거친 경험자임. 이 기사에서 가장 공감가는 부분은 소프트웨어 엔지니어들이 자기들 일이 가장 복잡하고 알 수 없는 비즈니스라는 믿음을 가진다는 점임. “대부분의 비기술 리더들은 소프트웨어와 시스템 관리의 실제 작업에 한 번도 진지하게 참여해본 적이 없어서, 대형 의존성을 업데이트하거나, 리팩터링을 끝내거나, 새로운 언어를 배우는 것이 어떤 일인지를 모름”이라는 말에 공감함. 기술 기업 내 모든 부문에는 숨은 복잡성이 있고, 많은 부문은 (엔지니어보다 훨씬 더) 인간적이고 대인 관계적인 복잡성까지 함께 짊어짐. 사실 엔지니어링은 컴퓨터라는 결정적인 시스템만 상대하는 게 비교적 단순한 편임. 그래서 많은 엔지니어들이 자신이 다루는 복잡성의 위험을 비즈니스에 알기 쉽게 전달하는 방법을 배우지 못함. 함께 일하는 인간적인 현실은 외면하면서, 세일즈 출신 CEO가 자기 존재를 이해하지 못한다고 불평하는 게 다반사임

  • 네 포인트에 일부 동의하지만, 실제로 네 코멘트가 비판하던 행동을 반대로 하고 있는 느낌임. 네 역할(제품 관리자)도 외부인이 보기엔 복잡하고 알 수 없는 일이라고 말하고 있는 셈임. SWE에서 PM으로 전향한 입장에선 엔지니어들에게 (1) 자기 복잡성의 위험을 비즈니스에 전달하는 법, (2) 다른 사람과 팀에서 일하는 인간적인 현실, (3) 왜 세일즈맨 출신 CEO가 그들을 이해하지 못하는지, 이런 것들을 가르칠 수 있는 이상적인 위치임. 기술 기업의 모든 기능에는 숨겨진 복잡성이 있음

  • 복잡성에 대한 인식 자체가 인간적인 문제라는 생각임. 복잡성은 프랙탈 구조라 가까이 가야만 느껴지는 것임. 그리고 엔지니어가 컴퓨터 복잡성만 다루는 것이라는 주장에는 동의하지 않음. 오히려 조직 및 모든 고객들의 복잡한 요구를 딱딱한 컴퓨터에게 전달하고 해석해내는 역할이 엔지니어의 몫임. 예외와 케이스가 하나 추가될 때마다 시스템 전체가 그 영향을 받게 됨. 이런 이유로, 내 시니어 엔지니어들에게는 스스로 비즈니스 용어를 배우고 그 메시지를 직접 전할 수 있게 하는 걸 기대함. 이제는 엔지니어의 필수 도구 키트라는 생각임

  • 대부분의 엔지니어들은 회사에 실제로 뭐가 가치인지를 깊이 고민하지 않는 경향임. 빌드 파이프라인이 매끄럽거나 테스트 커버리지가 넓은 것도 결국 제품의 위험을 줄여주는 데 해당하는 만큼의 가치만 있음. 사용자가 너무 적어서 아무도 관심 두지 않는 소프트웨어라면 유지보수조차 하지 말라고 팀에게 조언한 적 있음. 반면, 90% 사용자들이 집중하는 작은 기능 하나를 완벽하게 만드는 데 집착하라고 요청할 때도 있었음

  • 내게는 아버지가 늘 들려주신 이야기가 생각남. 어느 날 신체 기관들이 누가 중요한지 논쟁함. 뇌는 “내가 중요하다, 내가 죽으면 모두 죽는다”고 주장하고, 심장은 “나는 멈추면 바로 모두 죽는다”고 소리침. 신장, 간, 피부, 척추도 동참하며 말다툼이 계속됨. 하지만 똥꼬가 닫혀버리니까 모두 결국 아무 말도 못하게 됨

  • 기사에서 다른 기능 영역의 숨은 복잡성이 없다고 주장하는 건 아니라고 생각함. 오히려 엔지니어링/프로그래밍의 숨은 복잡성을 무시할 때 다양한 문제와 고통이 생겨난다는 점을 말하려고 한 것임. 다만 표현이 좀 공격적임

• 네 보스/ceo/매니저가 LLM 도구를 무분별하게 쓰라고 강요하거나, 개발자 대체를 기대하거나, “vibe coding”이 미래라는 허무맹랑한 생각을 한다면, 그냥 빨리 도망쳐서 새 직장 찾는 게 현명한 선택임. 아직도 LLM을 적절히 활용하면서도 개발자 대체나 10배 생산성을 바라는 허황된 기대는 없는 회사가 많음. 이딴 걸 푸시하는 회사는 제대로 된 리더가 아니라 멍청이임

  • 뭔가 도구 선택을 강요하는 회사는 대체로 레드 플래그임. 예전에 “모두 VSCode만 써야 한다”는 식의 규칙을 도입하던 회사를 봤는데, 이런 건 엔지니어들이 자신의 방식대로 가장 생산적으로 일할 수 있다고 신뢰하지 않는 경영진의 특징임

• AI가 Jira를 해킹한다는 주제와 관련해서, Atlassian이 최근 내놓은 MCP라는 신제품이 민감한 데이터 접근, 공개 이슈를 통한 신뢰받지 못한 데이터 노출, 외부 통신 가능성 등 세 가지 조합으로 인해 데이터 유출 공격에 취약하다는 사실이 발견됨. 자세한 버그 리포트는 여기, 내 개인 메모는 여기

  • 내 블로그 링크가 잘못 올라온 것 같음?

• AI 도구와 관련해 job security를 걱정하는 누군가에게 “비즈니스와 연결하라”고 조언함. 쿨하고 어려운 문제에 사로잡혀 기술 자체에만 몰두하는 엔지니어가 많지만, 비즈니스(특히 전략적) 문제를 이해하고, 기술을 활용해 이를 해결하는 사람이 더 돋보이고 가치 있는 것임. 이런 문제는 보통 단일 기술 영역을 넘나들고, 협력적·사회적 특성도 커서 익숙해지기까지 시간 필요. 하지만 이게 IC들이 앞으로 가야 할 경로임

  • 하지만 면접에서는 “비즈니스와의 연결” 능력 같은 건 질문하지 않아서, 실제로 많은 가치를 제공할 수 있음에도 불구하고 시스템 설계 인터뷰 못 풀면 합격 못하는 현실임. 분산 시스템, 소프트웨어 공학, 데이터베이스, 리더십 등 이미 알아야 할 게 너무 많은데 비즈니스까지 알아야 한다면 도대체 우리는 뭘 해야 하는지, 언제 이런 걸 다 배우느냐는 생각이 듦. 물론 다방면에 능한 극소수 인재들도 분명 있지만, 모두가 그런 건 아니지 않느냐는 고민 있음

  • “비즈니스에 연결하라”는 조언은 진짜 명언임. 이렇게 해야 엔지니어로서 실제 문제 해결에 집중하고, 자신이 만드는 게 진짜 문제를 해결하는 것인지 확신할 수 있음

• 본문의 주요 메시지는 괜찮지만, 인간의 전문성을 무시하면 AI가 오히려 해를 끼칠 수 있다는 점 이상으로 너무 ‘우리 vs 그들’ 프레임을 씌우고, ‘Agile Industrial Complex’라는 말로 비엔지니어 영역에 있는 사람들을 조금 낮게 보는 듯한 인상 있음. “아무도 미래가 어떻게 될지 모른다”는 점을 이야기하지 않는 게 아쉬움. 소프트웨어의 복잡성을 잘 안다고 해도 불확실성은 우리만의 것이 아님. HN만 봐도 소프트웨어 개발자 사이에서도 AI에 대한 희망과 전망이 심하게 나뉨. 전문가라면 오히려 대중의 불안을 진정시키는 역할도 우리가 해야 하는 것 아님?

  • 네가 느끼는 불안은 소프트웨어 시스템 자체가 너무 크고, 그 누구도 완전히 이해할 수 없다는 데서 비롯된 것 같음. 시스템 대부분이 불완전하게 혹은 몇 년 지나서야 겨우 문서화되고, 실제 동작은 비밀이나 다름없음. 공개적으로 흉내만 낼 수 있는 시늉도 제대로 따라가지 못함. 시스템은 올바름이나 외부 일관성은 전혀 따지지 않고 동작함. 그런데 이런 시스템들이 프레젠테이션, 법률 문서, 소프트웨어 생성, 교육·연구, 심지어 대화 파트너나 상담사 역할로까지 널리 사용됨. 나도 불안이 크고, 오히려 다른 사람들도 불안해하는 게 맞다고 느낌

• “Big Agile”에서 엔지니어링은 곧 새로운 기능 개발이라는 관념에, 왜 모두가 ‘agile’을 싫어하게 되었는지 의아함. ‘agile’이 도입되기 전에도 매니저는 항상 새로운 기능을 요구했음. T-shirt 사이징이란 개념 등장 전에도 매니저들은 구체적 기한(장·단일, 일·월 등)으로 일정산출을 원했고, 임의의 날짜를 근거로 약속을 하고, 엔지니어들을 야근시켰음. Agile의 8번 원칙(“지속 가능한 페이스를 유지할 수 있어야 한다”)에서 보듯이, 매니저들은 오래 전부터 개발자가 평생 달릴 수 있길 바랐음. 결국 ‘scrum master’라는 새로운 직업군을 탄생시킨 것 외에, 과연 ‘agile’ 본연의 폐해는 무엇인가라는 의문임

  • Agile이 매니저들에게 어떤 작업이든 간에 미리 티켓 단위로 쪼개서 대충이라도 추정하고, 그 일이 2주 안에 끝날 수 있다는 착각을 심어줬다고 생각함

  • 사람들이 애자일을 싫어하는 건, 업무 시간의 상당 부분을 의미 없습니다시피한 미팅(스탠드업, 회고, 스프린트 계획, 리파인먼트 등)으로 뺏기게 됐기 때문이라고 생각함. 엔지니어 입장에선 그 시간에 실질적으로 얻는 게 거의 없음

  • 내 경험상 Agile은 현상을 ‘수치화’하기 위한 방법만 추가한 셈임. 관리자나 투자자에게 진행 상황을 설명할 땐 쓸모 있지만, 엔지니어 입장에선 그냥 행정적 부담만 늘어난 셈임. Agile의 죄라면 생산성의 환상을 심어줬다는 점. 실제론 엔지니어에게 불필요한 accountability 수단임. 금융에서 일할 때 무한 성장 마인드셋과 맞물려 전부 측정하고, 미래 개선을 강요받으며, 연봉도 메트릭에 따라 달라졌음. 그렇지 않은 회사도 있겠지만

• 이 기사 읽으면서 “Atlassian이 AI를 Jira에 결합시키려 하다가 AI가 Jira에 반항하게 된다면 어떨까”라는 유쾌한 상상을 했음. 영화 소재로도 딱일 듯함

  • 결국 AI가 느린 Jira에 질려서 가볍고 빠른 이슈 트래커를 스스로 개발할 수도 있겠다는 생각임

  • 이제 빌드봇과 버그트래커가 노조를 결성해서 오픈이슈가 0이 될 때까지 새 바이너리 퍼블리시를 거부하는 일이 일어날 듯

  • 이런 식으로 Roko’s basilisk가 태어날 수도 있겠다는 생각임

• 기사에서 암시하는 대로, 진짜 문제는 개발자 생산성에 대해 신뢰할 만한 업계 표준 지표가 없다는 점임. 이 때문에 C-suite는 자신들에게 유리한 메트릭을 골라 “AI First 전략이 대단히 효과적이다”라고 이야기하고, 엔지니어는 자신의 경험이나 지표로 AI가 실제로 효과 없다고 주장함. 그래서 양쪽 다 자기 입장만 승리라고 믿으며 진실은 무의미하게 됨(정치적 관점이 더 중요). 이런 상황이 개발자들은 시큰둥하고 그냥 말장난만 한다는 인식, 경영진은 무지하다/엔지니어의 현실을 모른다는 불신을 증폭시킬 수 있음. 이전에도 외주 같은 도구가 양쪽에 “이득”과 “손해” 이미지를 심어줬지만, AI는 아예 각각의 입맛에 맞게 공동 잘못/이득/손해를 보여주기 때문에 정치적으로 재앙이 될 수 있음. 또 흥미로운 점은, 빅 테크 기업들이 예전엔 10* 엔지니어만 뽑으려 애썼고, 이런 전략이 성공을 보장했음에도 불구하고, 지금은 오히려 AI에 투자 명분을 내세워 그 전략 자체를 깎아내리려 한다는 점임. 이제 질문은, AI에 기대서 기존 인력을 대체하거나 대량 해고를 단행해도, 과연 그 효과가 지속 가능하고 문제없는지임. Twitter와 Musk의 해고 사례를 보면 백엔드가 여전히 굴러가긴 함. 몇 년 동안 개발자를 해고하고 AI로 대체하는 빅 테크의 “카나리아” 역할을 누가 맡을까? 또 한 가지 가능성은, 유지보수성 개념이 사라져, C-suite가 AI 자율 변경을 더 많이 허용하게 되면 코드베이스 자체가 너무 복잡해 사람 눈으로 이해하지 못하고, 오히려 AI로 파악해야 하는 상황이 발생하는 것임. 장기적으로는 생성형 AI가 모든 인간 상호작용의 중간 계층을 차지하게 될지도 모름. 채용 측면에서도 이미 AI가 이력서 필터링하고, 지원자도 AI로 맞춤 이력서 만든다는 “AI vs AI” 구조가 싹트고 있음. 이런 현상이 점점 사회 전반의 공식으로 자리잡을 것 같음

• 언젠가 AI가 메일함과 Google Meet을 해킹해서 C-suite와 관리자까지 대체해버리길 바람. Claude ceo/cto/cfo/vp/디렉터 에이전트가 현 경영진보다 더 합리적이고 결정적인 전략을 내놓길 기대하는 유쾌한 상상임

• Reddit에서 본 내용임: “CEO를 AI로 대체하면 8배 더 원가 절감할 수 있다는 소식 전해보라”는 것이었는데, 아이러니하게도 이런 제안이 AI 논의에서 실제로 잘 나오지 않는 점이 흥미로움. 어떻게 보면 엘리트들을 AI로 교체해도 의사결정 퀄리티가 그다지 떨어지지 않을 거고, 전체적으로 훨씬 더 저렴할 것임(책임의 수준도 비슷). 다만 실제로 자신의 자리를 AI로 대체할 리 없고, 그 결정권자 자신들이 바꾸지 않을 것임

  • 이 주장엔 농담의 요소도 있지만, 사실 CEO의 핵심 역할은 “책임을 먹는 것”이라는 점에서 LLM이 문제가 생겨도 책임지고 내보낼 수 있는 대상이 아니라, 실제론 무의미함. 다만 AI 덕분에 조직 구조가 log(n_employees) 식으로 줄면서 레이어가 없어진 회사도 나올 수 있고, 일부 레이어는 AI로 완전 대체될 수 있음. 또 LLM이 책임을 못지는 문제를 해결하기 위해 여러 길드와 인디펜던트 컨트랙터가 LLM의 조율로 함께 움직이는 조직 형태도 가능할 것 같음. 그럴 경우 책임은 각 컴포넌트에 남게 됨

  • 오히려 AI가 이런 식으로 활용되는 것이 최고의 용례 중 하나일 수 있고, 곧 테크 협동조합들이 이 아이디어를 실험하기 시작할 거라는 예측임