레거시의 해부

정보는 어디에 사는가

B사(자동차 부품)의 입사 2년 차 품질 엔지니어가 팀장에게 지시를 받는다. "작년에 고객사에서 하우징 크랙 클레임 들어왔을 때 우리가 뭐라고 회신했는지 찾아서, 이번 건에도 같은 논리로 쓸 수 있는지 봐 줘." 그의 하루는 이렇게 흘러간다.

1. 품질 시스템의 클레임 대장을 검색한다. 접수일과 고객사, "종결" 상태만 있고 대응 내용은 없다.
2. 공유 드라이브 \\품질\고객\2025\클레임\ 폴더를 연다. 하위 폴더 이름이 담당자마다 다르다. 0412_크랙, 하우징건, 고객사 회신(최종).
3. 그 안에 PPT 세 개와 엑셀 두 개가 있다. PPT는 경영진 보고용이라 결론만 있고, 엑셀은 측정 데이터인데 시트 이름이 Sheet1(2)다.
4. 당시 담당자는 다른 사업부로 옮겼다. 메신저로 물어보니 "메일로 회신했던 것 같은데, 제 메일함 보관 기간이 지나서…"라는 답이 온다.
5. 결국 당시 참조자였던 선배의 메일함에서 회신 메일을 찾는다. 오후 4시다.

이 엔지니어가 게을러서가 아니다. 정보가 시스템이 아니라 사람과 파일을 따라 흩어져 있기 때문이다. 이런 정보를 흔히 다크 데이터(dark data)라고 부른다. 조직이 업무 중에 만들고 저장하지만, 찾거나 분석하거나 재사용하지 못하는 정보다. 그리고 그 정보가 팀·시스템·개인별로 갇혀 서로 연결되지 않은 상태를 데이터 사일로(data silo)라고 한다.

정보의 거주지마다 성격이 다르다. 아래 표는 각 거주지가 AI 관점에서 어떤 특징을 갖는지 정리한 것이다.

우리 팀의 정보 거주지 지도 그려 보기

우리 팀의 정보가 어디에 얼마나 사는지 감으로라도 적어 보면 대화가 달라진다. "데이터가 없다"는 막연한 불평이 "결정의 대부분이 메일에 있고, 측정값은 엑셀에 있다"는 구체적인 진단으로 바뀐다. 아래 슬라이더로 각 거주지의 상대 비중을 정해 보자(합계는 자동으로 100%로 맞춘다). 거주지별 AI 준비도와 건당 검색 시간은 교육용 가정값이며, 오른쪽 아래 메모에 적어 두었다.

엑셀이 시스템이 될 때: EUC

현업 사용자가 IT 부서를 거치지 않고 직접 만든 계산·관리 도구를 최종 사용자 컴퓨팅(EUC, End-User Computing)이라고 한다. 제조 현장에서 대표적인 EUC는 엑셀이다. 엑셀이 시스템이 되는 과정은 대개 비슷하다.

1. 개인 메모설비 엔지니어가 정비 이력을 자기 PC 엑셀에 적기 시작한다.
2. 팀 공유편해 보여서 공유 폴더에 올리고 팀원들이 같이 쓴다. 열이 늘어난다.
3. 로직 추가MTBF 계산 수식, 조건부 서식, VLOOKUP으로 다른 파일 참조가 붙는다.
4. 자동화누군가 VBA 매크로로 월간 보고서 자동 생성 버튼을 만든다.
5. 사실상의 시스템월간 설비 회의가 이 파일 없이는 열리지 않는다. 만든 사람은 다른 팀으로 갔고, 매크로를 고칠 줄 아는 사람이 없다.

EUC 자체가 나쁜 것은 아니다. 현업이 빠르게 필요를 해결한 결과이고, 오히려 어떤 데이터와 로직이 실제로 필요한지 알려 주는 귀중한 요구사항 문서다. 문제는 이것이 관리되지 않을 때 생기는 위험이다.

버전 분기가 얼마나 빠르게 늘어나는지는 공유 방식과 참여 인원에 크게 좌우된다. 아래는 단순한 확률 모델로 그 감을 보여 주는 시뮬레이터다.

메일 스레드 해부: 결정은 어디에 묻히는가

제조 조직에서 가장 중요한 결정의 상당수는 메일로 이루어진다. 출하 보류, 임시 대책, 고객 회신 일정, 특채 승인. 문제는 메일이 결정을 기록하는 도구가 아니라 대화를 나르는 도구라는 점이다. 스레드가 길어지면 다음 일이 생긴다.

• 갈라짐: 누군가 "전체 회신" 대신 일부에게만 회신하면서 스레드가 둘로 나뉜다. 한쪽에서 바뀐 결정을 다른 쪽은 모른다.
• 참조자 변경: 중간에 참조가 추가·삭제되면서 뒤늦게 들어온 사람은 앞의 맥락을 모른다.
• 수치의 표류: 첫 메일의 불량률 1.8%가 세 번째 메일에서 "약 2%"가 되고, 보고서에는 2.1%로 적힌다.
• 모호한 기한: "다음 주 중", "가급적 빨리", "고객 확인 후". 아무도 날짜를 지키지 않아도 위반이 아니다.
• 근거의 실종: "첨부 로그 참고"라고 썼지만 첨부는 회신 과정에서 빠졌다.

아래는 A사(글로벌 전자부품 제조사)의 가상 고객 클레임 메일 스레드다. 버튼을 눌러 한 단계씩 결정·수치·기한·담당·근거를 찾아 표시하고, 마지막에 구조화된 레코드로 바꿔 보자.

보고서 PPT: 그림이 된 데이터

제조 조직의 공식 기록 중 상당수가 보고용 PPT다. 주간 품질 회의, 월간 설비 리뷰, 경영진 보고. 그런데 PPT는 데이터를 그림으로 바꿔 저장하는 형식이다.

• 엑셀 차트를 "그림으로 붙여넣기" 하면 원 숫자가 사라진다. 다음 달에 같은 차트를 다시 그리려면 원본 엑셀을 찾아야 한다.
• 슬라이드마다 표 구조가 다르다. 3월 보고서의 "불량 TOP5" 표와 4월 보고서의 표는 열 순서와 이름이 다르다.
• 결론("원인: 설비 노후")은 있지만 그 결론에 이른 근거와 기각된 가설은 없다. 회의에서 말로만 오갔다.
• 경영진 의견은 슬라이드 메모나 회의 후 메일에 남는다. PPT 파일만 보면 결정이 무엇이었는지 모른다.

생성형 AI는 PPT를 읽어 텍스트를 뽑고, 차트 이미지에서 숫자를 어느 정도 복원할 수도 있다. 그러나 이것은 어디까지나 복구 작업이다. 새로 만드는 보고서부터는 데이터를 먼저 남기고 그림은 나중에 만드는 쪽으로 순서를 바꾸는 것이 훨씬 싸다.

정보 인벤토리 만드는 법

정보 인벤토리(information inventory)는 우리 팀이 일하면서 만들고 쓰는 정보가 무엇이고 어디에 있는지 적은 목록이다. 거창한 데이터 카탈로그가 아니라 엑셀 한 장으로 시작해도 된다. 핵심은 "어떤 정보가 있나"가 아니라 "어떤 업무 판단에 어떤 정보가 쓰이나"에서 출발하는 것이다.

항목이 20~30개쯤 모이면, 각 정보에 대해 두 가지를 점수로 매긴다. 정보 가치(이 정보가 있으면 판단이 얼마나 빨라지고 정확해지나)와 현재 접근성(지금 찾고 꺼내 쓰기 얼마나 쉬운가). 그리고 2×2로 나누면 정리 순서가 보인다.

• 업무 판단 5~10개를 먼저 적고, 각 판단에 필요한 정보를 거꾸로 찾는다.
• "사람 머릿속"도 거주지로 적는다. 누구의 머릿속인지까지.
• 같은 정보가 여러 곳에 있으면 모두 적고, 어느 것이 기준(source of truth)인지 표시한다. 없으면 "없음"이라고 적는다.
• 민감도를 처음부터 함께 적는다. 나중에 AI에 넣을 수 있는지 판단하는 근거가 된다(12장).
• 완벽하게 만들려 하지 말고 2주 안에 1차본을 만든 뒤 분기마다 갱신한다.

레거시를 대하는 태도: 버리지 말고 옮겨라

레거시를 해부하다 보면 "전부 갈아엎자"는 결론에 이르기 쉽다. 하지만 레거시 파일과 메일에는 조직이 실제로 일해 온 방식과 판단 근거가 들어 있다. 갈아엎으면 그 지식도 함께 사라진다. 현실적인 순서는 다음과 같다.

1. 새는 곳부터 막기새로 생기는 정보부터 구조화한다. 다음 클레임부터는 이슈 카드로 받는다(3장).
2. 자주 찾는 것부터 옮기기인벤토리에서 ① 영역의 정보를 골라 과거 자료를 옮긴다. AI가 메일·PPT에서 항목을 뽑는 작업을 돕고, 사람이 검수한다.
3. 말 맞추기옮기면서 불량명·설비명·부품번호를 공통 코드로 맞춘다(4장).
4. EUC 승격 또는 정리핵심 엑셀은 로직을 문서화하고, 오래 쓸 것은 시스템으로 승격하고, 아닌 것은 소유자와 기한을 붙여 관리한다.
5. 나머지는 검색 가능하게옮기지 못한 문서는 권한을 지키며 검색 색인에 넣는다(6장).