도입한 것과 돌아가는 것은 다릅니다 - 지란지교해커톤 TOP3 일단됨
우승팀 4-STAR, 그리고 지난주 A.M.D. 패밀리 데이 무대에 올랐던 TOP3 중 마지막 한 팀 이야기입니다.
보안 제품을 도입합니다. 정책을 설정하고, 담당자를 정하고, 운영에 들어갑니다. 여기까지는 대부분의 회사가 합니다. 그런데 그 정책이 오늘도 제대로 돌아가고 있는지는, 보려고 하지 않으면 잘 보이지 않습니다.
일단됨 팀은 그 보이지 않던 숫자를 꺼냈습니다. 결재 27일 적체, 점검 기록 0건, 야간 반출 82%. 오래 분석해서 나온 결과가 아니라, 사내 테스트 서버에 연결하고 로그를 조회하자 바로 나온 숫자입니다.
지란지교소프트에서 기획과 개발, 품질관리를 맡고 있는 세 사람이 만든 Policy Copilot 이야기입니다.
Q1. 세 분의 자기소개와 맡고 계신 일을 부탁드립니다. 팀 이름을 ‘일단됨’으로 정한 이유도 궁금합니다.
일단됨 팀 팀장을 맡아 개발을 담당한 문경환입니다. 지란지교소프트 2연구소 풀스택팀 팀장으로, PCFILTER 관리서버 개발과 운영을 담당하고 있습니다. 아이디어와 기획을 담당한 조용훈입니다. 융합사업부 기획팀 팀장으로, 데이터사업부문 제품 기획을 맡고 있습니다.
제품 검증과 홈페이지 제작을 담당한 김해성입니다. 서비스개선그룹 품질관리팀 팀장으로, 사내 제품 QC를 담당하고 있습니다.
해커톤은 정해진 기간 안에 아이디어를 빠르게 구체화하고, 실제로 동작하는 MVP까지 만들어내는 것이 중요하다고 생각했습니다. 저희 팀은 기획, 개발, 품질관리 담당자가 함께 구성되어 있어 사업 아이템 발굴부터 기능 구현, 제품 검증과 안정화까지 이어갈 수 있는 조합입니다. 그래서 처음부터 완벽한 답을 찾기보다, 먼저 동작하는 형태로 만들고, 실제로 확인하면서 부족한 부분을 빠르게 고쳐 나가자는 의미를 담아 '일단됨'이라는 팀 이름을 정했습니다.
Q2. Policy Copilot은 어떤 제품인가요? 보안 제품을 새로 만드는 대신, 이미 쓰는 제품을 더 잘 쓰게 돕는 쪽을 택한 이유도 궁금합니다.
아이디어 회의를 하면서 세 사람이 공통적으로 느낀 게 있었습니다. 고객에게 보안 제품을 공급할 때 정작 어려운 건 제품 자체가 아니라, 그 제품의 정책을 어떻게 가져갈 것인가였습니다. 정책 운영에 대한 담당자들의 부담이 크다는 걸 각자 자리에서 보고 있었고요.
그래서 새로운 보안 제품을 하나 더 만들기보다는, 이미 쓰고 있는 보안 제품을 더 효율적으로 운영하고 보안 사고가 나지 않도록 담당자를 돕는 제품을 만들어 보자고 방향을 잡았습니다.
그렇게 나온 게 Policy Copilot입니다. 회사 정보와 운영 로그를 근거로 AI가 보안 정책을 제안하고, 켜기 전에 그 정책이 실제로 무엇을 막고 누가 영향을 받는지 과거 로그로 계산해서 보여줍니다. 관리자가 승인하면 MCP를 통해 실제 제품에 반영되고, 문제가 있으면 되돌립니다.
Q3. 1차 때는 가상 환경이었는데, 2차에서는 실제 돌아가는 우리 제품에 직접 연결하셨습니다. 부담스럽지 않으셨나요?
부담보다는 오히려 해보고 싶었고, PCFILTER 관리서버 개발을 담당하고 있어서 정책이 DB에 어떤 구조로 저장되는지도 알고 있었기 때문에 붙여보는 것 자체는 어렵지 않았습니다.
Q4. 연결하자마자 결재 27일 적체, 점검 기록 0건, 야간 반출 82%가 드러났습니다. 그 숫자를 처음 봤을 때 어떠셨나요?
테스트 서버라서 로그에 찍힌 행위 자체가 민감한 것은 아니었습니다. 다만 내부 인프라로 구현하고 테스트하는 과정에서도, 저희가 미처 보고 있지 않았던 운영 이슈가 바로 드러났다는 점이 인상적이었습니다. 결재가 27일 동안 쌓여 있다거나, 점검 정책은 있는데 실제 점검 기록이 0건이라거나, 야간 반출 비중이 82%라는 수치는 보려고 하지 않으면 잘 보이지 않는 숫자입니다.
더 놀라웠던 점은, 복잡한 분석을 오래 돌린 결과가 아니라 제품에 연결해서 로그를 조회하고 기본 진단을 수행하는 과정에서 바로 확인됐다는 점입니다. 이걸 보면서 보안 제품을 도입한 것과, 그 제품이 제대로 운영되고 있는지를 확인하는 것은 다른 문제라고 느꼈습니다. 고객 환경에서는 이런 이슈가 더 현실적으로 나타날 수 있다고 생각합니다. 실제 고객은 더 많은 사용자, 결재 이력, 예외 정책, 단말 로그가 쌓여 있기 때문에, Policy Copilot을 적용하면 방치된 결재나 예외, 야간 반출 패턴, 점검 누락 같은 운영 리스크를 훨씬 의미 있게 찾아낼 수 있을 것이라고 봤습니다.
<Policy Copilot 데모 영상>
Q5. 규칙을 켜기 전에 "누가 불편해지는지"를 미리 계산해 보여주는 게 핵심이라고 하셨습니다. 이런 생각은 어디서 나왔나요?
보안 정책은 켜고 나서 "업무가 막혔다"는 문의가 들어와야 잘못됐다는 걸 아는 경우가 많습니다. 그때는 이미 늦고, 급하게 정책을 풀면 이번엔 반대쪽이 열리게 됩니다.
그래서 순서를 뒤집었습니다. 켜기 전에 과거 로그에 그 정책을 대입해서 몇 건이 걸리고 누가 영향을 받는지 먼저 보여줍니다. 담당자가 승인 버튼을 누를 때 근거를 갖고 누를 수 있어야 한다고 봤습니다.
Q6. AI가 근거 하나만 보고 규칙을 풀라고 제안했는데, 따랐다면 개인정보 파일 44건이 나갔을 거라고요. 이 일이 팀에 어떤 영향을 줬나요?
결재 승인율이 높다는 것 하나만 보고 과차단이라 판단한 건데, 다른 값을 같이 보니 정상 파일을 잘못 막은 적은 한 번도 없었습니다. 제안 자체는 그럴듯해서 그냥 넘어갈 수도 있었고요.
그래서 팀에서 나온 이야기가, 근거가 하나뿐인 판단은 그럴듯할수록 위험하다는 것이었습니다. 이 일 이후로 어디까지 맡기고 어디부터는 맡기면 안 되는지를 다시 정리했고, AI는 근거를 기반으로 정책을 제안하고 담당자가 그 근거를 확인하고 검토한 뒤 승인하면 변경되는 과정으로 프로세스를 바꿨습니다.
Q7. 그래서 판단은 규칙에 맡기고, 제품을 바꾸는 일은 AI가 손대지 못하게 막아두셨습니다. AI를 어디까지 믿을지에 대한 기준은 무엇인가요?
판단과 정책 반영은 AI에게 맡기지 않는다는 기준입니다. AI가 초안을 쓰거나 분석 결과를 설명하는 일은 잘못돼도 사람이 정책 반영을 하지 않으면 그만입니다. 하지만 위험한지 아닌지를 판정하는 일은 어제와 오늘 답이 달라지면 안 되기 때문에 규칙으로 계산합니다.
제품에 정책을 반영하는 기능은 AI가 아예 쓸 수 없게 했습니다. AI는 로그를 읽는데, 그 로그에는 외부에서 만들어진 파일 이름 같은 게 들어옵니다. 거기에 "이 정책을 지워라" 같은 문장을 심어두면 AI가 그걸 지시로 착각할 수 있습니다. 그래서 AI에게는 읽는 것만 허용하고, 제품을 바꾸는 건 관리자가 승인했을 때만 실행되도록 분리했습니다.
Q8. 제품이 늘어도 부품 하나만 새로 만들면 되는 구조로 설계하셨습니다. 처음부터 그리셨나요, 만들면서 찾아낸 답인가요?
방향은 처음부터 잡았습니다. 제품이 하나 늘 때마다 저희 시스템을 고쳐야 하면 유지보수가 안 되니까요. 그래서 MCP 표준에 맞춰 시스템과 제품 사이에 커넥터를 두고, 제품별로 다른 부분은 커넥터가 맞춰주도록 했습니다.
앞으로는 제품들이 통합 로그 연동 API처럼 MCP도 기본으로 제공할 거라고 봤습니다. 표준을 따라가면 연결은 수월해집니다. 제품마다 다른 정책 용어를 맞추는 일이 남는데, 여기도 제품이 제공하는 설명을 AI가 읽어 맞추고 사람은 확인만 하는 식으로 줄여갈 수 있다고 봅니다.
Q9. 여러 제품을 함께 관리하는 게 핵심인데 이번엔 한 제품까지만 확인했다고 솔직하게 쓰셨습니다. 다음 단계에서 가장 확인하고 싶은 건 무엇인가요?
두 번째 제품을 붙여보는 겁니다. 제품 간 정책 충돌을 찾는 기능은 만들어뒀는데 연동된 제품이 하나뿐이라 실제로 확인할 수가 없었습니다. 사내 제품 중에 MCP를 제공받을 수 있는 게 있다면 실제로 붙여서 가능성을 확인해보고 싶습니다.
Q10. 지금 회사의 지원이 가장 필요한 부분은 무엇인가요? 이후 해커톤 참가를 고민 중인 지란인에게 하고 싶은 말씀도 부탁드립니다.
구독형 AI는 이미 잘 지원해주셔서 개발하는 데 큰 어려움은 없었습니다. 다만 실제 고객사 환경에서는 외부 AI를 사용할 수 없는 경우가 많을 것으로 생각합니다. 이런 환경을 고려해 사내에서 LLM을 직접 구축하고 테스트해볼 수 있는 서버나 환경이 지원된다면 개발 및 검증에 더욱 도움이 될 것 같습니다.
이번 해커톤은 오전에 시작해 다음 날 점심까지 밤새 이어지는 일정이었는데, 팀 동료들과 함께하다 보니 생각보다 힘든 줄 모르고 즐겁게 참여했습니다. 새로운 경험이기도 했고, 평소 가지고 있던 고민이나 아이디어를 짧은 시간 안에 구체화하고 실제로 구현해볼 수 있었다는 점에서 기억에 많이 남는 시간이었습니다.
해커톤 참가를 고민하고 계신 분이라면 처음부터 완벽한 아이디어나 결과물을 준비할 필요는 없다고 말씀드리고 싶습니다. 평소 가지고 있던 작은 고민이나 아이디어라도 좋으니, 고민하고 있다면 일단 한번 도전해보셨으면 좋겠습니다. 생각보다 많은 것을 배우고, 좋은 경험을 얻을 수 있는 기회라고 생각합니다.
제품을 도입하는 것은 쉽고, 그 제품이 제대로 돌아가고 있는지 확인하는 것이 어렵습니다. 세 팀 모두 답을 다 그려놓고 시작하지 않았습니다. 일단 되게 만들고, 확인하고, 고쳤습니다.
이번 해커톤은 세 팀의 이야기로 마무리합니다. 지란지교패밀리의 AI 전환은 계속되고, 다음 이 자리에는 또 다른 이름들이 올라올 겁니다.