"야, PI-Desktop이라는 프로젝트 봤어? 깃허브에서 하루 만에 별 545개 박혔다는데, 이게 좀 그렇다."

최근에 오픈소스 커뮤니티에서 갑자기 확 뜬 PI-Desktop이라는 프로젝트가 있었어. 데스크톱 기반 AI 에이전트 솔루션인데, README 문서에는 API 자격증명이 OS 키체인에 안전하게 저장된다고 적혀 있었거든. 딱 봐도 '오, 보안도 신경 쓰는구나' 싶게 만들었지. 문제는 실제 코드를 열어보니까 암호화된 파일 옆에 그 파일을 여는 평문 키가 같이 저장되어 있었던 거야. 운영체제 키체인을 호출하는 코드는 단 한 줄도 없었고. 문서는 9번이나 언급했지만 말이지.

이게 무슨 뜻이냐면, 데이터 폴더에 접근 가능한 사람이라면 누구든 암호를 풀어볼 수 있다는 얘기야. 백업이나 클라우드 동기화 과정에서 민감한 키가 노출될 위험이 엄청나게 커지는 거지. 하루 만에 별이 545개 붙을 정도로 인기가 치솟았는데, 정작 핵심 보안 기능은 문서와 코드가 달랐던 거야. 메인테이너는 이런 문제 제기에 감사 인사만 하고 아직 해결되지 않았다고 해.

이 사례가 정말 시사하는 바가 커. 우리가 AI 에이전트 같은 새로운 도구를 받아들일 때, 겉으로 보이는 인기도나 그럴듯한 문구만 보고 덜컥 도입하면 안 된다는 걸 다시 한번 느끼게 돼. 특히 보안이나 핵심 로직처럼 민감한 부분은 README 한 번 읽는 걸로는 안 되고, 직접 코드 한두 파일이라도 열어보는 습관이 필요하다는 거지.

AI가 만드는 ‘소프트웨어 팩토리’는 사람의 설계가 핵심

이렇게 신뢰성 문제가 있는 AI 도구들이 난립하는 상황에서, AI를 활용한 소프트웨어 개발은 대체 어떻게 바라봐야 할까? 단순히 "AI가 코드를 짜준다!"는 수준을 넘어, 이제는 AI가 개발 전반을 담당하는 '소프트웨어 팩토리' 개념이 주목받고 있어. OpenAI도 그렇고, 이정민 님 글에도 이런 관점이 잘 정리되어 있더라고.

핵심은 이거야. AI가 코드를 짜든, 테스트하든, 배포하든, 결국 작업의 출발점은 코드가 아니라 '사람이 달성하고자 하는 결과'여야 한다는 거야. 에이전트가 무슨 일을 하기 전에 사람이 명확하게 성공 기준과 제약 조건을 정하고, 완료 여부를 판단할 기준을 세워야 해. "이 기능 만들어줘"가 아니라, "이 기능을 통해 이 문제를 해결하고, 이 지표로 완료를 확인할 거야" 식으로 말이지. 자동화가 빨라질수록 오히려 목표를 정확히 정의하는 일이 중요해지는 거야.

그리고 AI 에이전트에게 회사 내부의 업무 맥락을 제공해야 해. 단순히 "보안 전문가처럼 검토해줘"라고 지시하는 것만으로는 부족하다는 거지. 실제 우리 회사의 보안 규칙, 시스템 제약사항, 기존 코드의 설계 의도 등을 에이전트가 알 수 있도록 연결해줘야 해.

또 중요한 건 '작성 → 검증 → 수정' 루프를 계속 돌리는 시스템을 만드는 거야. AI가 코드를 작성하면 CI에서 빌드와 테스트를 실행하고, 실패하면 AI가 다시 수정하도록 말이지. 실패를 끝으로 보는 게 아니라, 다음 수정의 근거로 삼아 끊임없이 개선하는 루프를 만들어야 해.

디자이너도 AI 에이전트로 '샤워 생각'을 프로토타입으로

이런 AI 중심의 개발 체계는 비단 개발자만의 얘기가 아니야. Grok Bot 디자이너인 존 바이와 펭 정 사례를 보면, 디자이너들도 AI 에이전트를 적극적으로 활용해서 전통적인 작업 흐름을 완전히 바꾸고 있더라고.

펭 정은 AI 에이전트를 백엔드 삼아 개인 웹사이트를 자동 업데이트하고 있어. CMS나 피그마 파일 없이 말이지. 사진 한 장이나 장소 이름만 보내면 포트폴리오가 자동으로 업데이트된다는 거야. 존 바이는 "Figma Bro"라는 AI 봇에게 프로덕션 디자인 작업을 맡겨놓고 자기는 헬스장에 간대. 심지어 '샤워 생각(shower thought)'이 떠오르면 바로 DevBot으로 프로토타입을 만들어서 아이디어를 테스트해본다고 하네. 제품 관리자나 엔지니어 거치지 않고 바로 말이야.

이게 바로 AI 에이전트가 개인의 생산성과 창의성을 얼마나 극대화할 수 있는지 보여주는 좋은 사례야. 복잡한 워크플로우의 병목 지점을 AI가 해결해주면서, 아이디어가 바로 실행으로 이어지는 거야. 이들은 자신만의 '봇 생태계'를 구축해서 업무 효율을 극한으로 끌어올리고 있어.

신뢰할 수 있는 시스템을 설계하는 안목

결국 이 모든 흐름은 AI가 단순히 코드를 생성하는 '도구'를 넘어, 소프트웨어 개발 전체를 아우르는 '시스템'이 되어가고 있다는 걸 보여줘. 존 바이나 펭 정처럼 개인의 '소프트웨어 팩토리'를 만들든, 전사적인 '소프트웨어 팩토리'를 구축하든, 이제 우리는 AI가 일하는 방식을 '설계'하는 단계로 넘어가고 있는 거야.

하지만 PI-Desktop 사례처럼, 아무리 혁신적인 AI 도구라도 겉모습만 보고 맹신하면 안 돼. 인기, 문서, 심지어 초기 기능의 화려함보다 중요한 건 결국 '신뢰할 수 있는 시스템'을 만드는 일이야. 그 시스템 안에서 AI 에이전트가 어떤 맥락으로 일하고, 언제 사람의 검토를 받으며, 어떤 기준으로 완성도를 판단할지 명확하게 정의해야 한다는 거지.

AI가 우리 일의 많은 부분을 대신하게 될수록, 우리는 AI를 위한 시스템 아키텍트이자 날카로운 품질 검사관이 되어야 해. 우리 팀의 AI 워크플로우는 어디까지 믿고, 어디서부터 들여다봐야 할까?

참고