Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
이 글은 복잡한 AI 에이전트 시스템을 다룰 때 필요한 핵심 역량으로 '시스템 관점' 이해를 강조합니다. 개발자는 구성 요소 간의 경계와 상호작용을 파악하고 최종 책임을 져야 합니다. 또한, 과거의 실패 예측 모델 대신 새로운 비즈니스 환경에 맞는 책임 의식이 필요하다고 지적합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 이전에도 비슷한 경험을 함. 개인 기여자(IC)에서 팀을 이끄는 역할로 옮겨가면서, 직접 작성했을 때만큼 깊이 이해하기에는 코드의 양이 너무 많아짐.
그때 배운 핵심은 시스템 전체를 이해하는 능력임. 구성 요소와 상호작용을 상자와 선으로 파악하고, 팀 개발자들에게 시퀀스 다이어그램도 산출물에 넣도록 권장함. 코드가 시스템에서 어떤 역할을 하는지 함께 이해하는 데 도움이 됨.
경계와 예상 입출력을 알면 상자 내부는 불투명해도 괜찮음. 잘못된 형식의 메시지가 나오는지 살펴보고, 필요할 때 해당 코드로 들어가 추적할 수 있음. 코딩 에이전트가 한 줄씩 검토할 수 없을 만큼 코드를 만드는 지금도 필요한 역량임. 시스템 관점은 지도이고, 경계는 어디를 파고들어야 할지 알려줌.
시스템을 만들어야 한다는 데는 동의하지만, AI는 결정의 대가를 직접 치르지 않으므로 팀 관리와 같지는 않음.
AI는 해고되거나 연애에서 거절당하지 않고, 가족을 실망시키거나 추운 거리에서 밤을 보내지도 않음. 현실적 결과를 전혀 고려하지 않는 인간이라면 팀에서 빨리 내보내야 할 시한폭탄임. 시스템을 구축할 때도 AI에는 이런 이해관계와 책임이 없다는 사실을 의식해야 함.
고수준 시스템 작업만 한다면 상자 내부를 파고들 실력은 어떻게 갖추게 될까? 아무리 철저히 테스트하고 검증해도, 그것을 작성하려면 저수준을 이해하는 사람이 필요함.
인간에게 법적 책임이 있는 한, 이런 접근은 누군가 소송을 당할 때까지만 통할 것임. 인간 전문가는 계속 필요하고 양성해야 함. 제품을 만들며 자연스럽게 배우는 대신 별도의 명시적 훈련이 필요해질 수 있는데, 기업들은 이를 싫어할 것임.
이 접근을 도입하려고 애쓰지만 쉽지 않음. 이런 시스템 관점을 배우는 방법이 있을까? 내게는 별로 자연스럽지 않음.
팀을 이끈다면 관리자나 유사한 역할일 텐데, 이는 기술 전문가의 역할과 전혀 다름. 기술 전반을 어느 정도 알면 좋지만, 관리자나 PO가 기술적 결정이나 코드 깊숙이 개입하는 것은 대체로 안티패턴임.
AI 산출물을 다루는 작업자는 에이전트가 내놓은 결과에 최종 책임을 짐. 사고가 나 법적 책임을 따지면 본인이 감당해야 하므로, 직접 검토·품질 보증 절차를 마련하고 때로는 코드도 살펴 수정하거나 에이전트에게 수정을 시켜야 함.
“이제 너도 관리자야!”라는 자기 위안은 그만둬야 함. 회사는 이들을 실제 관리자로 보지 않으며, 여전히 개인 기여자임.
비유는 직관적으로 와닿지만, 실제 실패보다 실패하는 듯한 감정에 너무 기대고 있어 정확한지는 의문임. 중요한 것은 사용자 불만, 보안 사고, 서비스 중단, 망가진 작업 흐름 같은 제품의 실패임.
과거에는 개발자의 스트레스와 불안이 제품 실패의 선행 지표였음. 넓은 책임 범위와 깊은 전문성을 동시에 감당하지 못하면 결과물의 품질이 나빠졌기 때문임. 하지만 에이전트도 같은 방식으로 실패하는지, 언제 신뢰해야 하는지에 대한 우리의 직관이 충분히 발전했는지는 불확실함.
실제로 내가 아는 성장기 SaaS 기업이나 최근 상장 기업 중에는 개발자 스트레스, 기능 출시 속도가 모두 올라가면서 장애는 줄어든 곳이 여럿 있음.
빠른 학습과 필요할 때 깊이 파고드는 능력뿐 아니라, 불편함이 실제 실패로 이어질 지점을 가려내는 직관도 필요함. 제때 다 배우리라 믿으며 불편함을 무시해서는 안 됨. 책임을 지려면 시스템의 모델을 머릿속에 유지하고, 어디를 깊이 살필지 능동적으로 정해야 함.
그건 관심 경제 이전에나 맞았던 것 같음. 내가 일하는 초대형 클라우드 기업은 2023년 이후 운영 환경에 배포하는 버그가 전년 대비 40% 증가했지만, 기능과 광고가 늘면서 사용자와 매출도 비슷하게 약 25% 성장함. 요즘 보안 사고나 운영 문제는 실적에 큰 영향을 주지 않는 경우가 많음.
실패가 사업에 타격을 준다는 전제는 사용자가 대안을 쉽게 찾고, 행동 패턴에 중독되거나 유도되지 않으며, 새 도구를 배울 정신적 여력이 있다는 옛 모델에 기대고 있음. LLM이 검색 엔진을 대체한 뒤 이탈이 크게 줄었고, 우리는 사용자의 인지적 약점을 이용해 앱을 계속 쓰게 만드는 패턴도 활용함. 일부 운영 버그와 실패는 예전만큼 큰 영향을 주지 않음.
불편함은 더 깊이 살펴보라는 신호이자 머릿속 모델을 갱신해야 할 수 있다는 신호임. 여러 번 깊이 파고드는 과정을 거치며 그런 감각이 쌓인다고 봄.
사이트는 접속되지 않지만, 특히 주의 깊게 봐야 할 것은 DB 스키마임. LLM은 정규화 판단을 형편없이 하는 경우가 많음. 데이터베이스 접근을 모듈화하면 여파를 어느 정도 줄일 수 있지만, 결국 객체 모델 등으로 번짐. AI를 많이 쓰는 프로젝트에서는 며칠마다 기능 개발을 멈추고 코드와 스키마를 검토한 뒤 정리함.
스키마는 직접 설계하는 편이 좋음. 이후 구현 방향을 강하게 결정하므로, 모델에 직접 프롬프트를 주기보다 스키마와 관련 주석을 활용하는 편이 나을 정도임.
어떤 스키마여야 할지 모르겠다면 바이브 코딩의 위험 신호임. 설계 단계로 돌아가 튜플과 관계에 확신이 생길 때까지 AI와 도메인을 논의해야 함.
나도 영속 데이터 형식, 통신 프로토콜, 공개 API를 건드리는 변경은 모두 검토함. 틀렸을 때 피해가 크고 프로젝트를 명확히 나누는 경계이기 때문임. 구체적인 경계는 프로젝트마다 다르지만, 일단 정해두면 나머지 코드는 잘못되어도 저렴하게 고칠 수 있어 훨씬 마음이 편해짐.
Hashnode의 일시적 장애였고 지금은 다시 접속됨. 스키마는 에이전트가 뭐라고 하든 항상 직접 깊이 살펴보는 부분임.
아직 AI가 못하거나 잘하는 영역을 찾아 인간의 대체 불가능한 가치를 정의하려 하지만, 그런 능력도 곧 AI의 확장되는 범위 안에 들어갈 수 있음. 왜 인간의 99.99%가 AI가 못 푸는 문제를 해결할 수 있다고 가정해야 할까?
인류의 미래를 논할 때 인간에게 AI가 절대 대체하지 못할 능력이 반드시 있다는 전제부터 내려놓는 편이 좋겠음. 인간의 주체성 보존은 도덕적·제도적 선택이지, 인간의 인지적 우월성으로 정당화해야 하는 것이 아님.
코드 작성을 포함한 현실 문제는 사람이 LLM보다 더 잘 해결할 수 있다고 봄. UX 디자이너는 LLM보다 좋은 UX를 만들겠지만, UX 설계 역량까지 갖춘 프로그래머보다는 못할 것임. 사용자 작업 흐름에 대한 암묵지와 코드베이스의 mental model을 결합하면 하향식 계획보다 일관된 경험을 만들 수 있기 때문임.
위임의 문제이기도 함. 사람을 더 투입하면 더 많이 할 수 있지만 품질은 떨어짐. LLM은 책임 면제 조항이 붙고 영합 성향도 통제되지 않는 아주 저렴한 외주 인력에 불과함.
우리는 그 논의에 초대조차 받지 못한 것 같음. 소수의 사람들이 인류의 미래를 계획하고, 우리가 원하든 말든 강요하려 하고 있음. 누군가 어떻게든 막지 않는 한 그렇게 될 것임.
사회 다수가 도덕적이라고 여기는 기준도 권력자가 제도 안에서 마음대로 행동하는 것을 막지는 못함. 더 많이 가진 사람이 인력·토지·자본 같은 유한한 자원의 배분에 과도한 결정권을 갖게 하는 근본적 불평등이 존재함.
구분해야 할 것은 모든 것을 유창하게 말하는 능력보다 모든 것에 대한 호기심임. 내가 아는 최고의 개발자들은 주제가 무엇이든 모르면 흔쾌히 인정하고 찾아봄.
필요할 때 배우는 접근에는 대체로 동의하지만, 코드만 보고 배울 수 있는 것은 아님. 여러 저장소와 설정 파일을 아우르는 방대한 맥락에 더해, 변경 이력과 절차, 조직 내부에만 전해지는 지식까지 필요할 수 있음.
여전히 업무에서 가장 어려운 부분이며 AI가 도와주기는 해도 완전히 해결하지는 못함. AI가 원하는 깊이나 전체적인 이해 수준에 미치지 못한 채 문제를 풀려는 경우를 자주 봄.
이력, 설정, 조직 내부 지식도 시스템 지도의 일부임. AI가 어려움을 없애주지는 않으며, 에이전트가 잘못된 수준에서 작업했을 때 어디로 파고들지 안내할 지도가 필요함.
항상 대규모 테스트 환경을 구축함. 정확성은 물론 신경 쓰지만, 보통은 별도로 요청하지 않아도 AI가 챙김. 함수를 요청하면 테스트도 작성함.
여기에 시간·공간 복잡도와 캐시 지역성도 따져 묻고, 블랙박스 테스트를 많이 함. 결과가 예상대로 동작하는지 확인한 다음 그 기대 동작을 문서로 남김.
이렇게 하면 같은 시간에 내가 만들 수 있는 것보다 더 좋은 코드가 나옴. 예전 작업 방식과 대체로 같지만, 더 철저해지고 시간을 잡아먹는 사소한 버그가 줄어든 셈임.
“경험과 폭넓은 지식은 복리로 쌓이지만 유지해야 한다”는 문장이 이 글에서 전문성 유지 문제를 다루는 유일한 부분임. 기술 작업을 그만두고 어떻게 전문성을 유지할 수 있을까? 한동안은 버티겠지만 결국 떨어질 것임.
그래도 1분기에나 닥칠 문제니 대수롭지 않게 넘기는 모양임.