다 열지 않고 연결할 수 있을까요? - 지란지교해커톤 TOP3 A.M.D
지난주에는 지란지교해커톤 우승팀 4-STAR의 이야기를 전해드렸습니다. 그런데 그날 패밀리 데이 무대에는 세 팀이 올랐죠. 오늘은 그중 한 팀을 소개하려고 합니다.
아쉽게 우승은 하지 못했습니다. 하지만 끝까지 완주한 28개 팀 중에서 TOP3까지 올라온 데는 분명한 이유가 있었습니다.
주말에 급한 결재가 올라옵니다. 노트북을 엽니다. VPN을 실행하고, 로그인하고, 인증번호를 받아 입력하고, 연결이 잡히기를 기다립니다. 그제야 ERP 화면이 열립니다. 아마 지란인이라면 한 번쯤 겪어보셨을 겁니다.
A.M.D 팀은 이 네 단계를 지웠습니다.
인프라운영팀과 정보보안팀에서 모인 세 사람이 한 달여 만에 만든 OfficeBridge 이야기입니다.
Q1. 세 분의 자기소개와 맡고 계신 일을 부탁드립니다. 팀 이름을 'A.M.D'로 정한 이유도 궁금합니다.
안녕하세요. 저희 팀 A.M.D는 Angry Metal Dragon의 약자입니다. 팀명은 저희 세 사람의 이름에서 각각 한 글자씩 가져와 지었습니다. 인프라운영팀 강승철의 철(Metal), 이용환의 용(Dragon), 그리고 정보보안팀 막내 김영욱의 욱(Angry)을 조합했습니다.
저희 인프라운영팀은 자사 솔루션의 서버 자산과 인프라를 관리·운영하는 업무를 담당하고 있고요. 정보보안팀에서는 내부 네트워크와 공통 자산 그리고 보안 환경을 관리하고 있습니다. 이번 프로젝트에서는 자유로운 연결과 보안이라는 두 가지 방향을 함께 고민했고, 그 과정에서 정보보안팀의 루키인 김영욱 사원을 팀원으로 영입하게 되었습니다.
Q2. OfficeBridge는 어떤 제품인가요? VPN을 켜고 사내 시스템에 들어가던 지란인에게 무엇이 달라지는지 궁금합니다.
한마디로 표현하면 "VPN을 켜는 순간이 사라집니다."
기존에는 외부에서 사내 시스템에 접속하려면 VPN 클라이언트를 실행하고, 로그인한 뒤 인증번호를 입력하고, VPN 연결이 완료되어야 ERP나 GitLab 등에 접근할 수 있었습니다. OfficeBridge는 이 과정을 없앴습니다. 임직원은 브릿지 앱을 한 번 설치한 뒤 회사 코드와 계정으로 최초 1회 인증하면, 이후에는 별도의 로그인 절차 없이 본인이 접근 권한을 가진 시스템이 메뉴바에 표시됩니다. 원하는 시스템을 클릭하면 바로 접속할 수 있습니다.
대신 접근 관리와 통제는 훨씬 세분화되었습니다. 기존 VPN처럼 일단 사내망에 연결되면 내부 시스템이 전체적으로 노출되는 방식이 아니라, 관리자가 부서, 사용자 단위로 허용한 시스템만 표시되고 접근할 수 있도록 설계했습니다. 허용되지 않은 시스템은 사용자 입장에서는 아예 존재하지 않는 것처럼 보입니다.
또한, 이러한 조직도 트리와 정책 설정 방식은 기존 자사 솔루션의 구성과 크게 다르지 않도록 설계했습니다. 즉 새로운 서비스를 도입하더라도 고객에게 기존 지란 제품과 비슷한 방식으로 사용할 수 있도록 하여 익숙한 사용자 경험을 제공하는 것까지 CX 관점에서 함께 고려했습니다.
Q3. VPN은 한 번 연결되면 사내망 전체가 열린다는 점을 문제로 잡으셨습니다. 이 문제의식은 어떤 경험에서 나왔나요?
저희 세 명 모두 업무 특성상 타겟에 대한 접근 허용과 차단을 관리해야 하는 입장입니다. 인프라운영팀은 서버 자산을 직접 관리하다 보니 접근 권한이 계정별로 세분화되지 않았을 때, 감사나 침해 대응 과정에서 얼마나 복잡해지는지 직접 경험했습니다. 반대로 정보보안팀에서는 이미 열려 있는 접근 권한을 나중에 회수하거나 좁히는 과정이 얼마나 번거로운지도 계속해서 경험하고 있었고요. 게다가 기존 VPN 방식은 구조적으로 일단 연결하고, 이후 방화벽 룰 등을 통해 접근 범위를 좁히는 방식에 가깝습니다. 저희는 이 순서를 반대로 가져가고 싶었습니다.
"처음부터 허용된 시스템만 보이게 하자."
OfficeBridge는 이러한 문제의식에서 출발했습니다.
Q4. 보통은 외부에서 들어올 문을 회사 쪽에 열어두는데, OfficeBridge는 회사 안에서 밖으로 먼저 연결을 겁니다. 이렇게 하면 무엇이 안전해지나요?
기존 접속 방식에서는 외부에서 사내 시스템으로 들어올 수 있도록 회사 측에 인바운드 포트를 열어둬야 했습니다. 이 열린 포트 자체가 공격 표면이 될 수 있습니다. 포트 스캔의 대상이 되거나, 해당 서비스의 취약점을 노린 공격이 발생할 수도 있고요.
OfficeBridge는 인바운드를 허용하지 않는 방식으로 설계했습니다. 사내망에 설치된 커넥터가 릴레이 서버를 향해 먼저 아웃바운드 WSS 연결을 생성합니다. 방화벽 입장에서는 내부 PC가 일반적인 외부 HTTPS 서비스에 접속하는 것과 유사하기 때문에 별도의 인바운드 포트를 열 필요가 없습니다. 결국 릴레이 서버에서 사내망으로 직접 들어오는 경로 자체가 처음부터 존재하지 않는 구조입니다.
<Officebridge 데모 영상>
Q5. 늘 켜져 있는 방식으로 만들었다가, 관리자가 로그인할 때만 통로가 열리게 전부 다시 만드셨습니다. 잘 돌아가던 걸 왜 뒤집으셨나요?
처음에는 커넥터는 상시 구동되는 데몬 형태가 맞다고 생각했습니다. 그런데 개발을 진행하면서 생각이 바뀌었습니다. 상시 구동이라는 것은 반대로 말하면, 고정된 토큰 하나만 탈취되더라도 터널을 24시간 언제든 사용할 수 있는 구조가 될 수 있기 때문입니다. 사람이 실제로 사용하고 있지 않아도 컴퓨터만 켜져 있으면 터널이 계속 열려 있는 셈이죠.
그래서 전체 구조를 다시 설계했습니다. 관리자가 회사 코드와 계정, 2차 인증을 통해 로그인해야만 터널이 열리고, 로그아웃하거나 다른 관리자가 콘솔에서 '연결 강제 종료'를 실행하면 즉시 터널이 종료되도록 변경했습니다. 즉, 단순한 연결을 넘어 관리자 인증이 된 경우에만 연결되도록 보안 관점에서 구조를 다시 설계한 것입니다.
Q6. 한 달여에 41번 코드를 올리고, 프로그램 세 개와 윈도우·맥 설치 파일까지 만드셨습니다. 역할 분담과 AI 활용 방식이 궁금합니다.
세부 보안 정책 기획과 테스트는 김영욱 사원이 주도했고, 구성도와 커넥터 앱, 임직원용 앱은 제가 담당했습니다. 릴레이 서버는 이용환 대리가 맡았습니다. 각자 다른 영역을 개발하다 보니 중요한 것은 각 산출물을 하나의 제품처럼 자연스럽게 연결하는 것이었습니다. 초기에는 이 부분에서 어려움이 많았지만, Claude Code와 GitHub를 활용해 코드 관리와 리뷰를 진행했습니다.
AI는 단순히 기능을 구현하는 데만 활용한 것은 아닙니다. 배포 전 렌더링 검증이나 커밋 메시지 정리처럼 반복적인 작업부터, macOS 환경에서 별도의 Wine 없이 Windows 빌드를 만들어내는 우회 방법을 찾는 작업까지 AI의 도움을 받았습니다. 그 덕분에 저희는 반복 작업에 쓰는 시간을 줄이고, 설계와 보안 판단처럼 사람이 직접 고민해야 하는 부분에 더 많은 시간을 쓸 수 있었습니다. 그 결과 한 달 남짓한 기간 동안 41개의 커밋을 쌓았고, Windows와 Mac 설치 파일까지 다운로드할 수 있는 수준까지 구현할 수 있었습니다.
<VPN 없이 wifi로 IDC 장비에 접속하기>
Q7. 휴대폰 인증번호 방식을 가져다 쓰지 않고 직접 만들고, 국제 표준 정답표로 검증까지 하셨습니다. 직접 만든 이유가 있나요?
관리자용 커넥터는 비밀번호 하나가 탈취되면 사내망 터널까지 연결될 수 있는 구조이기 때문에, 반드시 2차 인증을 적용해야 한다고 판단했습니다. 외부 라이브러리를 사용할 수도 있었지만, 보안에 직접적으로 영향을 주는 부분인 만큼 저희가 내부 동작을 정확하게 이해하고 통제할 수 있는 방식으로 구현하고 싶었습니다.
그래서 Google Authenticator와 호환되는 TOTP(RFC 6238)를 Node.js의 표준 암호화 모듈만으로 직접 구현했습니다. 또한 단순히 동작하는 수준에서 끝내지 않고, 배포 전에 RFC 4226의 공식 테스트 벡터를 이용해 계산 결과가 정확히 일치하는지 검증했습니다. 이후 실제 환경에서 등록 → 인증번호 확인 → 로그인 과정까지 다시 테스트한 뒤 반영했습니다.
Q8. 보안 검사 예외를 프로그램 전체가 아니라 딱 한 곳만 풀도록 하셨습니다. 이런 디테일까지 챙기게 된 배경이 궁금합니다.
커넥터가 사내 ERP 같은 시스템에 대신 요청을 보내주는 구조인데, 붙여보니 계속 에러로 막혔습니다. 내부 시스템들이 자체서명 인증서나 사내 CA 인증서를 쓰고 있으니 Node.js가 기본적으로 신뢰를 못 하고 거부한 거였습니다.
프로세스 자체의 인증서 검증을 꺼버리고 싶었지만... 편의를 위해 만든 기능이 프로그램 전체의 보안 수준을 끌어내리면 안 된다는 게 그때 저희 세 명이 재확인한 원칙이었습니다. 그래서 커넥터가 내부 시스템으로 보내는 그 HTTPS 요청의 옵션 객체 하나에만 예외를 적용했습니다.
Q9. 시험용이 아니라 실제 사내 ERP와 개발 시스템에 붙여 확인하셨습니다. 가장 애먹은 문제는 무엇이었나요?
AI 덕분에 크게 애먹은 부분은 없었지만, 앞선 이슈 외에도 로그인 이후엔 시스템이 원래 자신의 주소로 리다이렉트하는 문제가 있었습니다. 릴레이 서비스의 도메인이 아닌 내부 시스템의 실제 주소로 브라우저가 이동하면서 다시 접속할 수 없는 상황이 발생했습니다. 결국 리다이렉트 응답의 Location 헤더를 가로채 서비스 도메인에 맞게 다시 작성하는 로직을 별도로 구현했습니다.
Q10. 지금 회사의 지원이 가장 필요한 부분은 무엇인가요? 이후 해커톤 참가를 고민 중인 지란인에게 하고 싶은 말씀도 부탁드립니다.
현재 코드 자체는 지속적으로 에이전틱 AI를 활용한 리뷰와 고도화를 팀 내에서 업무 외 시간에도 진행해볼 계획입니다. 리소스 측면에서도 릴레이 서버는 물리 서버가 아니라 IDC 내 Private Cloud 환경에 인스턴스를 구축해 충분한 배포 환경을 준비할 수 있습니다. 앞으로는 실제 서비스 환경에서 웹소켓 세션이 얼마나 증가할지에 대한 부하 테스트와 모니터링이 필요할 것 같습니다. 의도적으로 부하를 발생시키고 실제 사용량을 측정하면서 성능과 안정성을 지속적으로 개선해나갈 계획입니다.
개발과 테스트에 있어 전문 개발팀은 아니지만, 저희 A.M.D팀이 노력하고 계속 열정적으로 임한다면 충분히 서비스화에 가까운 결과물을 만들어낼 수 있다는 자신감을 얻을 수 있었습니다. 다만, 최근 느끼는 니즈는 UI, UX 디자인과 초기 기획서의 부족함입니다. 기술적으로 구현한 OfficeBridge를 실제 서비스로 발전시키기 위해서는 사용자 경험과 서비스 관점에서 한 단계 더 다듬는 과정이 필요하기 때문에 지원이 가장 필요한 부분은 전문 기획자와 디자이너라고 생각합니다.
끝으로 해커톤 참가를 고민하고 계신 지란인 여러분께 말씀드리고 싶습니다. 대AI 시대가 도래했습니다. 이제는 어떤 경력을 쌓아왔는지만큼이나 얼마나 다양한 경험을 해보고, 그 경험을 바탕으로 어떤 아이디어를 만들어내느냐가 중요해졌다고 생각합니다. 그리고 아이디어를 실제 결과물로 만들어내는 것은 결국 추진력이라고 생각합니다. 주저하지 말고 자신이 가진 아이디어와 꿈을 직접 실현해보셨으면 좋겠습니다. AI 시대에 가장 중요한 것은 생각하고 행동하는 사람, 그리고 그 사람이 행동할 수 있도록 뒷받침하는 리소스라고 생각합니다. 그 리소스만큼은 저희 인프라운영팀과 정보보안팀에서도 최대한 지원할 수 있도록 노력하겠습니다. 서버 인프라 자원이 필요하신 분들은 언제든 문의해주세요. 최대한 지원할 수 있도록 하겠습니다.
문을 열어두는 것은 쉽습니다. 열어두지 않고 연결하는 것이 어렵습니다. A.M.D팀은 한 달여 만에 그 어려운 쪽이 가능하다는 것을 보여줬습니다.
다음에는 TOP3의 마지막 한 팀 이야기로 찾아오겠습니다.
지란지교패밀리의 AI 전환은 계속됩니다. 그리고 지란지교해커톤도 계속됩니다. 올해 시작된 도전들이 어디까지 갈지, 그리고 또 어떤 다른 도전들이 시작될지 함께 지켜봐 주세요.