서론

안녕하세요. 주식회사 Cyber Security Cloud에서 딜리버리 총괄 부장을 맡고 있는 쿠로다라고 합니다.

개발, 서포트, TAM(Technical Account Manager)과 같은 프로덕트 딜리버리 조직을 총괄하며, 조직 구축 및 프로덕트 로드맵 책정, 각종 프로젝트 운영에 참여하고 있습니다.

최근 AI에 의한 조직 및 업무의 변혁을 저희 회사로서도 무겁게 받아들이고 있습니다.

딜리버리 조직 전반에 대한 AI 침투와, 특히 코딩 에이전트 (Coding Agent)를 전제로 한 프로덕트 개발 프로세스의 혁신은 저 자신의 중점 테마로서 매일取り組んでいる(매진하고 있는) 영역입니다.

보안을 본업으로 하는 저희 회사가 코딩 에이전트를 조직적으로 능숙하게 다루기 위해서는 기술적인 이해와 조직 전략 모두를 동시에 움직여야 합니다.

그 시행착오의 현실을 현장과 매니지먼트 양면에서 몇 가지 기사로 나누어 기록·발신해 나가고자 합니다.

엔지니어링 조직을 둘러싼 환경 변화

먼저, AI에 의해 변화하고 있는 엔지니어링 조직의 환경을 개관하겠습니다.

경쟁력의 차이가 AI 활용 능력에 의해 급격히 확대

지금까지도 다양한 기술 혁신이 있었다고 생각합니다만, AI 문맥에서 특기할 만한 점은 그 압도적인 "진화의 속도"입니다.

AI 모델 벤더 각사의 치열한 경쟁과 가속적으로 출시되는 신기능으로 인해, "AI 활용의 최적해"는 매일(진정한 의미에서 "매일") 변화하고 있습니다.

이제 슬슬 캐치업(Catch-up)해야겠다며 문서를 읽으며 손을 움직이고, "이런 방식으로 사용할 수 있겠구나"라고 생각한 찰나, 불과 1~2주 만에 그 방식이 과거의 것이 되어버린 경험을 하신 분은 분명 저뿐만이 아닐 것입니다.

그러한 상황 속에서 항상 최신 정보에 안테나를 세우고 자신의 손으로 시도하며 지견으로 익혀 나가는 멤버가 있는 조직, 혹은 그것을 가능하게 하는 환경을 갖춘 조직과 그렇지 않은 조직과의 경쟁력 차이는 가속도적으로 확대되고 있습니다.

조직의 존속성에도 영향을 미치기 시작함

확대되고 있는 것은 경쟁력의 차이뿐만이 아닙니다. 조직을 유지·성장시키기 위한 "인재 확보"의 문맥에서도 차이가 발생하고 있습니다.

최근 채용 면접에서 엔지니어 후보자분들로부터 "코딩 에이전트는 어떻게 사용하고 있습니까?"라는 질문을 받는 기회가 늘어나고 있습니다. 2년 전에는 거의 없었던 질문입니다. 질문 방식도 바뀌고 있어, "사용하고 있습니까?"가 아니라 "어떻게 사용하고 있습니까?"라며 이미 사용하고 있는 것을 전제로 한 질문이 되고 있습니다.

이러한 질문의 배경에는 물론 "더 나은 개발자 경험(Developer Experience)"을 추구하는 자세도 있다고 생각됩니다만, "AI를 업무에서 활용한 경험을 적극적으로 쌓지 않으면 살아남을 수 없다"는 엔지니어로서의 커리어에 대한 절박함도 느껴집니다.

코딩 에이전트의 눈부신 진화로 인해 엔지니어 불필요론도 이야기된 지 오래되었습니다만, 당사자인 엔지니어 스스로가, 특히 성장 의욕이 높은 사람일수록 이 상황에 강한 위기감을 느끼고 있는 것으로 보입니다.

향후 이 흐름은 더욱 가속화될 것이며, 조금 과장해서 말하자면 "AI 활용이 조직의 존속 가능성에도 영향을 미치게 될 것"이라는 위기감을 저 자신도 품고 있습니다.

보안이 확보된 활용 정비의 지연

조직에서의 AI 활용의 중요성과 위기감을 바탕으로, "그럼 우리 회사도"라고 생각했을 때 그곳에는 다음과 같은 벽이 가로막고 있습니다.

보안 리스크에 대한 대응... 코딩 에이전트가 과도한 권한을 가진 결과, 본래 개발자가 의도하지 않은 커맨드 실행이나 프롬프트 인젝션 (Prompt Injection) 등으로 인한 정보 유출, 변조와 같은 보안 리스크에 어떻게 대응해야 하는가. -
통제 가능한 AI 활용… AI를 활용한 개발의 고속화·생산성 향상을 실현하면서, 데이터 액세스 및 이용 이력 감사, 기밀 정보 관리, 비용 최적화, 컴플라이언스 (Compliance) 준수를 포함한 AI 거버넌스 (AI Governance)를 조직으로서 어떻게 확립할 것인가.

코딩 에이전트의 활용 및 그 환경 구축에 관한 정보는 넘쳐나는 반면, 그것을 보안이 확보된(Secure)·통제 가능한 형태로 조직에 전개하기 위한 방법론이나 정보는 아직 부족한 것이 실정입니다. 그러한 상황도 맞물려, AI 모델이나 기능 진화의 속도에 대해 조직 측의 정비가 많은 조직에서 뒤처지고 있는 것으로 보입니다.

이러한 상황에서 AI를 상용 환경용으로 본격적으로 이용하기 쉬운 것은, 적어도 다음과 같은 조건을 갖춘 조직이 아닐까 합니다.

• 리스크를 허용할 수 있는... 사업 리스크가 한정적이거나, 경영 판단으로서 리스크 수용 범위를 명확히 할 수 있는 조직
• 자체적으로 리스크 저감 대책을 강구할 수 있는... 보안 인력을 포함한 리소스와 노하우가 충분하여, 자체적으로 리스크 컨트롤 (Risk Control) 대책을 실행할 수 있는 조직

당사는 보안을 본업으로 하는 기업으로서, 안이하게 리스크 허용 접근 방식을 취할 수는 없습니다. 리소스가 충분한지는 별개로 하더라도, 당연히 자체적인 리스크 컨트롤 (Risk Control) 대책을 실행해 나가는 접근 방식을 취하게 됩니다. 향후 기사에서는 이러한 접근 방식에 뿌리를 둔 노력의 실상을 전달할 예정입니다.

CSC로서 지향하는 AI 드리븐 (AI-driven) 개발 조직

위와 같은 배경과 문제의식 속에서, 당사는 다음과 같은 개발 조직을 지향하고 있습니다.

폭발적인 딜리버리 (Delivery) 능력의 향상

'폭발적'이라고 굳이 표현했습니다.

AI 활용의 맥락에서 이야기되는 '생산성 향상'이나 '업무 개선', '자동화'와 같은 키워드는 모두 '기존의 조직·업무 내에 AI를 편입시킨다'라는 전제를 내포하고 있는 경우가 많습니다. 하지만 애초에 기존 업무가 인간 중심으로 설계되어 있다는 사실 자체가 병목 (Bottleneck)이 될 수 있습니다.

'폭발적'인 딜리버리 (Delivery) 능력의 향상이란 이러한 점진적인 향상을 목표로 하는 것이 아니라, '개발 기간이 3개월에서 3주로 단축되었다'라거나 '개발 인원이 10명에서 3명으로 줄었다'와 같이 차원이 다른 변혁을 의도하고 있으며, 이는 지금까지 당사가 축적해 온 노력의 연장선상에서는 결코 달성할 수 없는 것입니다.

이러한 목표를 내걸음으로써, 기존의 전제나 제약에 얽매이지 않고 성과(=고객에게 제공하는 가치)를 극대화하는 것에 집중하고자 합니다.

보안 거버넌스 (Security Governance)를 AI 활용의 엔진으로

'보안 거버넌스 (Security Governance)'는 아무래도 방어적인 이미지가 강하기 때문에, '개발 속도·생산성'에 관한 트레이드오프 (Trade-off)나 비용으로 이야기되곤 합니다. 하지만 당사는 이를 '안심하고 사업을 가속하기 위한 엔진'으로 파악하고 있습니다. 이전에도 데이터 활용이나 DX (Digital Transformation)의 맥락은 있었으며, 이제 와서 갑자기 나온 생각은 아니지만, AI 시대인 지금이야말로 그 중요성이 더욱 커지고 있습니다.

당사는 이를 체현하기 위해, 우선 조직으로서 리스크를 파악·관리할 수 있는 상태를 갖추고, 책정된 대응 방침이 즉시 업무에 반영되는 프로세스 (Process)의 실현을 목표로 하고 있습니다. 나아가 가드레일 (Guardrail) 등의 리스크 저감을 체계화함으로써, 현장의 엔지니어가 최신 AI 모델이나 기능을 기동적으로 현장에 투입할 수 있는 상태를 만들어 가겠습니다. 이를 통해 다양한 리스크와 우려를 최소화하고, 현장이 성과 창출에만 집중할 수 있는 환경의 실현을 목표로 합니다.

넘어야 할 벽

지향하는 개발 조직상을 실현해 나가는 과정에서 크고 작은 다양한 벽이 존재하지만, 우선 큰 틀에서 다음과 같은 4가지를 과제로 설정했습니다.

벽 ①: AI 정책과 표준의 정비

'일단 써보자'로 끝날 문제가 아니기에, 정책과 표준을 먼저 정비해야 합니다. 하지만 이것이 결코 쉽지 않습니다.

이 어려움의 핵심은 AI의 이용 가부를 단순한 OK/NG로 결정할 수 없다는 점에 있습니다. 'MCP는 어디까지 허용할 것인가', '로컬 환경에서 어디까지 실행 권한을 부여할 것인가', '브라우저 버전은?', '에이전트(Agent) 간의 연계는?'와 같이 기능이나 모듈별로 개별적인 평가가 필요합니다. 일괄적으로 OK라고 해버리면, 겉으로는 허용된 기능만 사용하는 것처럼 보이지만 실질적으로는 본래 액세스해서는 안 되는 리소스로 가는 경로가 열려버리는 등의 우회로가 생기기 쉬우며, 기능 세트마다 리스크의 정도도 크게 다릅니다.

그렇다고 해서 차례차례 출시되는 모든 신기능을 매번 망라적으로 계속 체크하는 것은 현실적이지 않습니다. 엄격하게 규칙화하면 현장에서 최대한 활용할 수 없게 되고, 그렇다고 규칙이 없으면 안심하고 사용할 수 없습니다. 이 균형을 어떻게 맞추면서 정책을 지속적으로 업데이트하는 운용을 이어갈 것인가—가 본질적인 과제입니다.

벽 ②: 개발 조직·프로세스의 AI 최적화

앞서 언급한 '폭발적인 딜리버리 (Delivery) 능력의 향상'은 기존의 조직·업무에 AI를 편입시키는 점진적인 개선으로는 달성할 수 없습니다. 팀 편성이나 역할 정의, 개발 프로세스 (Process) 자체를 AI를 전제로 재설계할 필요가 있습니다.

예를 들어, 한 명의 엔지니어가 AI와 함께 담당할 수 있는 영역은 기존과는 크게 달라집니다. 설계·구현·테스트·리뷰의 어느 단계에 어떻게 AI를 투입하느냐에 따라 팀의 적절한 규모나 역할 분담도 달라질 것입니다.

더욱 까다로운 점은 최적해(Optimal Solution)가 하나가 아니라는 점입니다. 신규 개발인지 운영 단계인지, 또한 제품의 특성이나 아키텍처(Architecture)의 차이에 따라서도 AI 활용의 형태는 달라집니다. 저희 회사의 경우에는 이 모든 것이 대응 대상이 되기 때문에, "이것이 정답이다"라고 단정 짓지 않고 문맥(Context)에 따라 계속해서 고민하는 자세가 요구됩니다.

벽 ③: 증적 관리와 가드레일(Guardrail) 설계

"누가 무엇을 AI에게 던졌는가"를 기록하고, 부적절한 이용(기밀 정보 전송 등)을 방지하는 가드레일을 어떻게 설계할 것인가라는 과제입니다.

개발 속도를 저해하지 않으면서 통제 메커니즘을 마련하는 것은 쉽지 않으며, 특히 "현장에서 의식하지 않아도 지켜지는 메커니즘"을 어떻게 실현할 것인가가 관건입니다. 가드레일이 너무 엄격하면 개발의 방해가 되고, 너무 느슨하면 통제의 의미가 없습니다.

더욱 어려운 것은 "부적절한 이용" 판정 자체의 고도화입니다. 코딩 에이전트(Coding Agent)와 인간 사이의 상호작용, 로컬 환경에서의 커맨드(Command) 실행을 포함한 동작과 같은 복잡한 상황 아래에서는 단순한 패턴 탐지만으로는 한계가 있으며, 컨텍스트(Context)를 고려한 시맨틱(Semantic)한 분석이 필요합니다. 이 부분은 방식 설계에 머무르지 않는 고도의 기술적 과제를 내포하고 있으며, 기술로 대응 가능한 범위와 운영으로 보완해야 할 범위를 가늠하며 현실적인 설계로 녹여낼 필요가 있습니다.

기록·감시·제어 중 어느 것이든, 기존의 정적인 규칙 기반(Rule-based) 방식으로는 포착할 수 없는 AI 특유의 리스크 패턴에 직면하는 설계가 요구됩니다.

벽 ④: 공급망 리스크(Supply Chain Risk) 대응

코딩 에이전트가 생성하는 코드는 많은 경우 OSS 라이브러리에 의존합니다. AI가 대량으로 코드를 생성하는 환경에서는 의존 라이브러리의 리스크 관리를 조직으로서 어떻게 통제할 것인가가 중요한 과제가 됩니다.

코딩 에이전트는 인간보다 몇 배나 빠른 속도로 코드를 생성하며, 라이브러리의 선정과 추가도 자동으로 이루어집니다. 게다가 참조 정보가 오래되었거나 에이전트가 적절한 버전을 판단하지 못하는 경우에는, 이미 알려진 취약점(Vulnerability)을 포함한 오래된 버전이 의도치 않게 채택될 리스크도 있습니다. 코드의 생산량이 늘어날수록 의존 관계의 총량도 불어나며, 관리해야 할 대상이 급격히 확대됩니다.

개별 엔지니어의 최선(Best Effort)에 의존하는 것이 아니라, 조직 전체로서 지속적으로 대응할 수 있는 메커니즘을 어떻게 설계할 것인가——이는 AI 활용의 확대와 함께 더욱 무게감을 더해가는 과제입니다.

향후 기사에서 다룰 내용

이후의 기사에서는 상기 과제들에 대해 저희가 실제로 무엇을 고민하고, 무엇을 선택하며, 어떻게 임하고 있는지를 써 내려가겠습니다.

정책이나 표준의 책정과 같은 조직적인 노력부터 구체적인 기술 선정 및 설계·구현에 이르기까지, 실제적인 시행착오를 기록할 예정입니다.

완성된 결과물이 아니라 현재 진행형인 시행착오입니다. 잘 풀리지 않는 점이나 아직 답이 나오지 않은 부분도 포함하여 작성하겠지만, 비슷한 과제를 가진 조직 분들에게 조금이라도 참고가 된다면 좋겠습니다.

본 시도에 대해 질문이나 의견이 있으시다면 댓글을 남겨주시면 감사하겠습니다.