AI 도입 사례
'작동하고 있으니, 손대지 않는다'. 그렇게 계속 이야기되던 시스템이, 정신을 차려 보니 10년 전 그대로 사내의 중심에서 작동하고 있었습니다——많은 기업이 짐작 가는 바가 있을 것입니다. 이번에는, 2016년 릴리스의 프로젝트 관리 시스템이,2020년에 지원이 종료된 OS 위에서 인터넷에 공개된 채로사용되던 상태로부터, 최신 환경으로 이전한 실록입니다. 실 작업 2일.티켓 3,623건·첨부 4.0GB를, 단 1건의 손실도 없이 이관했습니다.
'작동하고 있으니 손댈 수 없다'가, 10년간 이어졌습니다.
대상은 사내의 프로젝트 관리 시스템(Redmine). 안건의 진행, 장애 대응 기록, 고객과의 주고받은 경위——10년치가 이곳에 쌓여 있습니다. 그야말로멈출 수 없으니 손댈 수 없다라는 상태였습니다.
그러나 내용을 조사해 보니, 결코 방치해도 되는 상태가 아니었습니다.
| 항목 | 이전 전 | 이전 후 |
|---|---|---|
| OS | CentOS 6.10 (2020년 지원 종료) | AlmaLinux 10.1 |
| 애플리케이션 | Redmine 3.2.1 (2016년) | Redmine 6.1.3 |
| 실행 환경 | Ruby 2.2.4 | Ruby 3.3.10 |
| 데이터베이스 | MySQL 5.7 | MariaDB 10.11 |
| 웹 서버 | Apache 2.2 + Passenger | nginx 1.26 + puma |
OS의 지원이 끊긴 지 6년.그동안 공개된 취약점의 수정은, 일절 적용되지 않았습니다. 그것이 사외에서 접근할 수 있는 상태로 계속 작동하고 있었습니다. '작동하고 있으니 안전'이 아니라,'작동하고 있을 뿐, 보호되고 있지는 않다'라는 것이 정확한 표현입니다.
망가지지 않은 채, 방어만이 멈춰 있는 것입니다.
이전의 성패는, 착수 전의 실측에서 결정되어 있었습니다.
이전에 들어가기 전에, 현황을 숫자로 파악했습니다. 이 부분이 결과적으로, 공수를 크게 좌우하고 있습니다.
- 데이터베이스 38MB / 첨부 파일 4.0GB
- 1일당 20~30요청＝현역으로 사용되고 있다
- 확장 플러그인: 제로. 독자 디자인: 없음
마지막 1줄이 결정적이었습니다. 이런 종류의 이행에서 가장 말썽이 되는 것은,나중에 붙인 확장 기능이 새 버전에서 작동하는지 여부입니다. 작동하지 않으면 '대체품을 찾는다', '기능을 포기한다', '직접 고친다'의 세 가지 선택지가 되고, 거기서 몇 주간이 사라집니다. 이번에는 그 장애물이 처음부터 존재하지 않았습니다.
이 실측을 바탕으로, 착수 전에 3가지 방침을 정했습니다.
1. 버전을 한 단계씩 올리는 것을 그만두었다
당초에는 3.2 → 4.2 → 5.1 → 6.x로 단계적으로 올리는 것을 전제로 견적을 냈습니다. 그런데 검증해 보니,10년치를 한 번에 뛰어넘어 갱신할 수 있다는 것을 알게 되었습니다. 상정하고 있던 공수가 통째로 불필요해졌습니다.
2. 데이터베이스의 종류를 바꾸지 않았다
다른 시스템과 운용을 맞추기 위해, 다른 데이터베이스 제품으로 옮기는 안도 있었습니다. 그러나 이행 원본의 데이터 형식이 다르기 때문에, 변환 처리를 끼워 넣을 필요가 있습니다.티켓 3,623건·이력 6,071건이라는 '사라져도 알아채기 어려운 데이터'에, 변환이라는 리스크를 들이지 않습니다.운용의 통일보다, 데이터가 1건도 빠지지 않는 것을 우선했습니다.
3. 기존 서버를 직접 업그레이드하지 않았다
새 서버를 별도로 준비하여, 전환은 입구의 설정을 1줄 고쳐 쓰는 것만으로 했습니다.실패해도 1줄 되돌리면 원상 복구라는 상태를, 끝까지 유지하기 위해서입니다.
시간을 빼앗긴 것은, Redmine이 아니었습니다.
여기부터가 실무입니다. 이전 중에 마주친 문제를 나열해 보니, 경향이 뚜렷이 드러났습니다.
8가지 가운데,Redmine 본체에서 비롯된 것은 3가지뿐. 게다가 그중 1가지는 '생각보다 쉬웠다'라는 좋은 오산입니다. 실질적으로 애를 먹은 것은 2가지에 지나지 않습니다.
나머지는 OS의 세대 차이, 보안 기구, 통신 경로, 암호화, 외부 시스템 연계——모두 애플리케이션의 바깥쪽에 있습니다.
10년치 쌓인 '주변 환경의 차이'입니다.
'1줄로 되돌릴 수 있다'를 끝까지 놓지 않습니다.
전환은, 입구 서버의 전송 대상을 새 서버로 향하게 하는 것만. 되돌릴 때도 1줄입니다. 그리고구 환경은 정지시키지 않고, 작동하는 채로 남겨 두었습니다.
전환 당일은 '작동하는 구 환경'과 '작동하는 새 환경'이 병존하여, 어느 쪽으로든 1줄로 오갈 수 있는 상태를 유지하고 있습니다. 며칠 두고 문제가 없음을 확인한 뒤에, 구 시스템을 정지시켰습니다.
이전으로 끝내지 않고, 10년치의 부족을 메웠습니다.
새 환경에서는, 구 환경에 없던 것을 동시에 갖추었습니다.
- 매일의 백업(7세대) — 구 환경에는 백업의 구조 자체가 없었습니다
- 접근 출처의 기록 — 이전 전에는 전체 접근이 동일하게 보여, 누가 어디에서 오는지 추적할 수 없는 상태였습니다
- 로그인 시도의 제한 — 표준 기능이 없기 때문에, 웹 서버 측에서 보강
- 소스 코드 연계의 자동 갱신 — 사실상 동결되어 있던 연계가 15분마다 갱신되도록
결과적으로 이관한 데이터는 다음과 같습니다. 구 환경과 새 환경에서, 건수가 완전히 일치함을 확인하고 있습니다.
외부 시스템으로부터의 연계도, 설정 변경 없이 그대로 작동하고 있습니다.이용자 입장에서 보면, 로그인 화면이 새로워졌을 뿐——이전으로서 이상적인 착지입니다.
'우리에게도, 같은 서버가 있다'라면.
이번 이전이 단기간에 끝난 이유는, 3가지로 집약할 수 있습니다.
- 확장 기능이 들어 있지 않았다——그래서 10년치를 한 번에 뛰어넘을 수 있었다
- 착수 전에 실측했다——판단의 재료가 숫자로 갖춰져 있었다
- 되돌릴 수 있는 상태를 유지했다——전환 당일에 도박을 하지 않아도 되었다
반대로 말하면,이 3가지는 착수 전에 확인할 수 있습니다.'지원이 끊긴 서버에서, 멈출 수 없는 시스템이 작동하고 있다'——혹시 짐작 가는 바가 있다면, 우선 현황을 숫자로 파악하는 것부터 상담해 주세요. 옮길 수 있는지 여부는, 대개 조사해 보면 알 수 있습니다.
당사는, 지원이 종료된 OS·오래된 프레임워크 위에서 계속 작동하고 있는 업무 시스템의 이전·쇄신을 지원하고 있습니다.
현황 조사(버전·데이터양·확장 기능의 유무·공개 범위)는 무료. 레거시 시스템의 쇄신(AI Re: Platform／약칭: AIR Platform)과 함께,지금 바로 문의해 주세요.
문의 양식('레거시 이전 상담 희망'이라고 덧붙여 적어 주세요)／ info@flagship-ai.jp
시리즈 '레거시 to AI 실록'
- 총집편: PC 1대로 22개 시스템·약 246,000줄 ― AI 개발 3.5개월의 실측 기록
- 실록①: 20년 된 Java를, 약 1주일 만에 전면 쇄신
- 실록②: 기존 코드 0줄 변경으로, 기간계에 새로운 입구를 만든다
- 실록③: 1개월급의 구성 검토를, 프로토타입 2일＋실측으로
- 실록④: 옛 마이닝 PC가 2일 만에 '사내 전용 ChatGPT'로
- 실록⑤: 지원 종료 서버에서, 10년 된 시스템을 2일 만에 구출(본 기사)
※본 기사의 수치는 2026년 8월 시점의 실측값입니다. 이전에 소요되는 기간·작업 내용은 시스템의 구성·확장 기능의 유무에 따라 다릅니다.