티스토리 뷰
나는 PC에서는 회사 내부 정보시스템의 개발 소스를 읽고, 화면과 Java, SQLMap 사이의 연결을 추적하는 AI 시스템을 구축했다.
DB에는 연결하지 않고 소스만 분석하도록 해 유지보수, 개발에 도움을 줄 수 있는 시스템이다.
문제는 공유였다.
다른 개발자가 질문하려면 내가 대신 질문을 입력하고, 나온 답변을 다시 전달해야 했다. 분석 결과가 도움이 되더라도 질문과 답변을 중계하는 과정은 계속 내 몫으로 남았다.
팀원도 직접 사용할 수 있도록 슬랙과 디스코드 같은 소통 도구를 검토했다. 하지만 회사 내부 시스템 분석 내용을 새로운 협업 서비스에 올리는 방식은 보안과 운영 측면에서 검토할 부분이 있었다.
그래서 이미 사용하고 있는 회사 이메일을 질문과 답변의 창구로 연결했다. 팀원은 메일로 질문하고, 로컬 PC의 AI가 소스를 분석한 뒤 같은 메일에 회신하는 구조다. 이번 글에서는 이 구성을 만들면서 적용한 설정과 실제로 겪은 문제를 정리해 본다.
1. 이메일을 AI 분석 요청 창구로 사용하기
처음부터 별도 웹 서비스를 만들지는 않았다. 팀원이 새로운 화면이나 사용법을 익히지 않아도 되는 방식으로 시작하고 싶었다.
이메일이라면 질문을 보내고, 답변을 읽고, 추가 질문을 이어가는 과정이 익숙하다. 질문과 답변이 같은 메일 대화에 남는다는 점도 편리했다.
처리할 메일은 제목으로 구분했다. 제목이 [분석요청]으로 시작하고, 관리자가 등록한 발신자가 보낸 메일만 분석 대상으로 받도록 했다. 일반 업무 메일이나 자동 회신까지 AI가 처리하지 않도록 범위를 좁힌 것이다.
예를 들어 다음처럼 요청할 수 있다.
제목
[분석요청] 인사기록관리 정정 사유가 저장되지 않는 원인 확인
본문
인사기록관리 화면에서 기록관리를 정정하고 저장한 뒤 다시 조회하면 정정사유가 표시되지 않는다.
관련 화면 → Processor → Service → SQLMap 흐름을 추적하고, 사유 값이 전달되거나 저장되지 않는 지점을 확인해줘.
근거 파일과 수정 방향을 정리하리, 해당 SQL문도 작성해줘.
제목만 보내는 것보다 화면명, 현재 현상, 원하는 동작을 본문에 함께 적는 편이 분석 범위를 정하는 데 도움이 됐다. 실제 첫 테스트에서는 제목에 ‘테스트’만 있고 본문이 비어 있어, 분석할 질문을 더 알려 달라는 답변이 돌아왔다.
2. Gmail과 로컬 Claude CLI 연결하기
구성의 중심에는 작은 메일 중계 프로그램을 두었다. Gmail API로 메일을 확인하고, 조건에 맞는 요청을 로컬 Claude CLI에 전달한 뒤, 분석 결과를 Gmail로 회신하는 역할이다. 구현에는 Python 표준 라이브러리를 사용했다.
흐름은 다음과 같다.
분석요청 메일 도착 → 발신자·제목 확인 → Claude CLI 실행 → 결과 확인 → 같은 메일에 회신
Gmail 연결에는 비밀번호를 프로그램에 넣는 방식 대신 Google OAuth 인증을 사용했다.
Google Cloud에서 프로젝트를 만들고 Gmail API를 활성화한 다음,
데스크톱 앱용 OAuth 클라이언트를 생성했다.
내려받은 인증 파일을 중계 프로그램 폴더에 저장하고, 브라우저에서 사용할 계정과 메일 읽기·보내기 권한을 허용했다.
설정 파일에는 수신 계정, 요청을 허용할 팀원 주소, 분석할 소스 폴더, 메일 확인 간격을 지정했다.
인증 파일과 토큰, 요청 처리 기록은 Git에 포함되지 않도록 제외했다. 인증 파일 내용을 채팅이나 블로그에 올리지 않는 것도 기본 원칙으로 삼았다.
실제 설정에서는 브라우저를 여는 단계와 인증정보를 저장하는 단계에서 문제가 있었다. Chrome 실행 오류가 발생했고, 다른 실행 환경에서는 네트워크 제한 때문에 인증이 끝까지 저장되지 않았다. 브라우저 화면이 열렸다는 사실만으로 연결이 완료됐다고 판단하지 않고, 인증정보 저장과 연결 계정 확인까지 따로 검증했다.
3. 소스 분석과 메일 발송의 범위 제한하기
이 시스템은 분석 대상 소스만 직접 읽는다. AI 가 사용할 수 있는 도구는 파일 읽기와 검색으로 제한했다. 메일에 “파일을 수정해줘”라는 문장이 들어오더라도 중계 시스템의 분석 범위를 바꾸지 않도록 구성했다.
내부 개발자의 이메일만 등록하여 회신하도록 구성했다.
관리자는 요청 허용 주소와 회신 수신자, 자동 작업의 실행·중지를 통제한다. 자동 회신은 등록된 범위 안에서 처리하며, 현재 구성에서는 요청자에게 답변을 보낸다. 모든 답변을 관리자가 매번 승인하는 방식은 아니다.
답변에서 비밀번호나 토큰, DB 연결 문자열, 일부 개인정보 패턴이 발견되면 발송을 보류하도록 했다. 다만 이 검사는 정규식 기반의 일부 패턴 탐지다. 모든 개인정보나 민감한 업무 내용을 정확히 찾아낸다고 볼 수는 없다.
또한 회사 이메일을 창구로 사용했다고 해서 전체 처리가 내부망에만 머무는 것은 아니다. 이번 구성에는 Gmail API와 외부 AI 서비스가 사용된다. 따라서 소스 분석에 외부 AI를 사용할 수 있는지, 어떤 내용을 이메일로 전달할 수 있는지는 조직의 정책 안에서 정해야 한다. 소스 분석 결과와 실제 DB·실행 화면에서 검증한 사실도 구분해서 읽어야 한다.
4. 60초마다 확인하고, 진행 상태를 보이게 만들기
수동 테스트에서 메일 수신, AI 실행, 회신이 연결되는 것을 확인한 뒤 상시 확인을 켰다. Windows 작업 스케줄러에 등록해 현재 사용자로 로그인하면 중계 프로그램이 실행되도록 하고, 새 메일은 60초마다 확인하도록 설정했다.
여기서 60초는 답변 시간과 다르다. 메일을 발견한 다음 소스 분석이 시작되므로, 관련 파일이 많거나 질문 범위가 넓으면 답변은 더 늦게 도착한다. 요청은 한 건씩 처리하며, 분석 중에 들어온 메일은 다음 확인 시점에 처리한다. PC가 꺼져 있거나 절전 상태면 요청도 대기한다.
상시 실행을 설정한 뒤에도 문제가 한 번 발생했다. 처음에는 작업이 실행 중이었지만, 나중에 확인하니 프로세스가 종료돼 있었다. 등록 성공만 확인해서는 충분하지 않았다. 콘솔 없이 백그라운드에서 실행하는 방식으로 바꾸고, 마지막 메일 확인 시각이 갱신되는지도 확인했다.
진행 상황을 보기 위해 Orca에는 ‘메일 분석 현황’ 탭을 추가했다. 이 탭은 5초마다 로컬 상태 기록을 읽어 대기·분석·회신·보류 상태를 보여준다. 현재 단계에서는 파일별 상세 로그나 완료율을 표시하지 않는다. 대신 자동 작업이 살아 있는지, 요청이 어느 상태에 있는지를 확인할 수 있도록 했다.
5. 마크다운 답변을 읽기 쉬운 HTML 메일로 바꾸기
처음 회신은 일반 텍스트로 보냈다. 내용은 전달됐지만, 긴 답변에서는 읽기가 불편했다. 마크다운 제목의 ##가 그대로 보이고, 표의 구분선과 SQL 코드가 본문 사이에 섞였다. 분석 답변에는 파일 경로와 조건식, 여러 단계의 근거가 들어가므로 서식의 차이가 생각보다 컸다.
그래서 회신을 HTML로 변환하도록 확장했다. 제목은 파란색 큰 글씨로, 표는 테두리와 행별 배경색으로 구분했다. SQL은 별도 배경에 넣고 키워드는 파랑, 문자열은 초록, 주석은 회색으로 표시했다. 굵은 강조 문구와 짧은 인라인 코드도 지원하도록 했다.
SQL의 색상을 바꾸더라도 쿼리 내용은 그대로 유지해야 했다. 이를 확인하는 검사와 함께, 원문에 HTML이 포함돼도 실행되지 않도록 처리했다. 외부 이미지나 스크립트를 불러오는 기능은 넣지 않았다.
메일에는 HTML 본문과 일반 텍스트 본문을 함께 담았다. HTML 표시가 어려운 메일 앱에서도 원문을 읽을 수 있게 하기 위해서다. 기존 기능 검사와 새 서식 검사를 합쳐 9개 검사가 통과했으며, 실제 색상과 배치는 메일 앱이나 다크 모드에 따라 달라질 수 있다.
6. 분석 결과를 공유하는 통로부터 작게 시작했다
이번 작업의 목적은 새로운 AI 모델을 만드는 것이 아니었다. 이미 로컬 PC에서 사용하던 소스 분석 AI를 다른 개발자도 직접 이용할 수 있도록 질문과 답변의 통로를 만드는 일이었다.
이메일을 연결하니 팀원은 자신의 업무 맥락을 직접 적어 질문할 수 있었다. 답변을 받은 뒤에는 같은 메일 대화에서 범위를 좁히거나 추가 근거를 요청할 수도 있었다. 관리자가 매번 질문을 옮겨 적는 과정은 줄이고, 요청 허용 범위와 실행 상태는 계속 관리할 수 있게 됐다.
다만 자동 분석이 실제 운영 검증을 대신하지는 않는다. 소스에서 발견한 원인 후보나 SQL 초안은 DB 구조와 배포본, 실행 화면을 확인하기 전까지 그 한계를 갖는다. 자동 회신에서도 이 부분이 드러나도록 하는 것이 필요했다.
다음에는 팀원들이 실제 업무 질문을 보내면서 요청 범위와 답변 품질을 점검할 예정이다. 특히 민감정보로 보류된 답변을 어떻게 검토할지, 개인정보를 노출하지 않으면서 진행 현황을 더 알아보기 쉽게 표시할지를 다듬어 보려고 한다.