연구소는 생각보다 많은 일을 동시에 굴립니다.
선행 연구가 있고 정부 과제가 있고 현장에 나가 있는 실증 사이트가 있고 팔 물건을 만드는 제품 개발이 있고 그 뒤에 양산 준비가 있어요. 여기까지가 “우리 일”이고, 바깥에는 업계 동향, 경쟁사 움직임, 우리 제품을 옭아매는 법령과 인증 기준, 쌓여가는 특허가 있습니다. 문제는 이게 전부 다른 사람의 머릿속과 다른 파일 속에 흩어져 있다는 거예요. 각 조각의 담당자는 있는데, 전체를 한눈에 보는 사람은 없었습니다. 그래서 한 화면에 모아보기로 했어요. 회의 자료를 만들 때마다 조각을 다시 줍는 대신, 늘 켜져 있는 현황판 하나를요.
만들다 보니 사이드바 메뉴가 하나씩 늘었고, 어느 순간 이런 모양이 됐습니다.
- 바깥을 보는 눈
- 업계 동향 · 경쟁사 비교 · 관련 법령. 남의 막대만 모인 구역이에요. 연구소는 안만 들여다보다 바깥에서 뒤통수를 맞습니다.
- 우리가 한 약속
- 사업 계획 · 통합 일정. 몇 년 치 로드맵이 가로로 누운 막대들로 한 장에 들어갑니다.
- 지금 벌어지는 일
- 과제 현황 · 실증 현황 · 기술 개발 · 상세 설계. 계획 말고, 오늘의 상태.
- 조직의 기억
- 특허 검토 · 이슈 트래커 · 피드백. 겪은 것을 잊지 않기 위한 장치들.
이 중 제일 눈길을 끄는 건 역시 통합 일정입니다. 몇 년 치가 한눈에 들어오니까요. 그런데 간트 차트의 미덕인 압축에는 대가가 있어요. 성격이 전혀 다른 일들이 시작점, 끝점, 진척률이라는 같은 문법으로 번역되면서 실증의 막대와 선행 연구의 막대가 화면에서 똑같이 생겨버립니다. 실증은 “현장에서 예상대로 안 돈다”로 실패하고 연구는 “2년을 팠는데 방향이 틀렸다”로 실패하고 제품은 “만들었는데 팔리지 않는다”로 실패하는데도요. 연구는 느린 엔지니어링이 아니다(research is not engineering at a slower speed)라는 에세이가 이걸 정확히 짚습니다. 연구·R&D·제품 개발은 성공 기준이 다른 별개의 활동이라고요.
일정표는 연구소가 스스로에게 한 약속의 목록일 뿐입니다. 연구소의 전부가 거기 있지는 않아요.
실증 현황을 일정과 별도 메뉴로 둔 것도 그래서예요. 실험실에서 되는 것과 현장에서 되는 것은 다른 종목이에요. 현장에는 실험실에 없는 것들이 있습니다. 계절, 계통, 운영자, 인증. 실증 사이트의 상태는 막대의 진척률로는 안 읽혀요. “지금 돌고 있나, 멈춰 있나, 왜 멈췄나”로 읽어야 합니다. 제품 개발도 마찬가지예요. 설계 문서와 기술 개발 현황이 각자 자리를 가져야, “연구는 됐는데 제품이 안 나오는” 구간이 어디서 막혔는지 보입니다.
이슈 트래커. 써보면 알게 되는 게 하나 있어요. 이슈는 프로젝트 경계를 존중하지 않습니다. 프로젝트 A에서 터진 문제의 뿌리가 프로젝트 C와 같은 경우가 흔해요. 같은 부품, 같은 협력사, 같은 가정. 프로젝트별로 쪼개진 회의에서는 이게 절대 안 보이는데, 이슈를 전부 한 곳에 쌓아두면 “어, 이 두 개 같은 문제 아닌가”가 나옵니다. 현황판의 진짜 기능은 통제보다 이런 우연한 발견에 있어요. 그러다 화면 앞에서 누군가 남의 막대를 가리키며 “이거 끝나야 우리가 시작하는데요”라고 말하는 순간이 제가 본 가장 생산적인 회의였습니다.
시행착오 노트니까, 안 된 것도 적습니다. 처음엔 일정표 하나면 현황판이 되는 줄 알았어요. 그런데 일정표만 있는 화면은 곧 혼내는 도구가 됩니다. 모든 막대를 일정 준수율 하나로 읽게 되거든요. 그 지표로 보면 연구 막대는 만성 지연이고 그래서 만성적으로 혼납니다. 사실 그 막대는 애초에 간트 차트의 문법으로는 쓸 수 없는 문장이었는데도요. 동향·실증·이슈·피드백이 옆에 붙고 나서야, 일정표는 여러 화면 중 하나로 내려왔고 막대마다 “이 일의 성공 기준이 뭐냐”를 먼저 묻게 됐습니다.
마지막으로, 이 화면을 누가 채우느냐는 얘기를 해야겠습니다. 항목이 이렇게 많으면 갱신은 그 자체로 노동이에요. 파일이 바뀌었는지, 막대가 얼마나 움직였는지, 이슈가 어디까지 갔는지. 이런 지루한 팔로우는 전부 AI에게 맡길 수 있습니다. 실제로 맡기고 있고요. 하지만 사람이 다 빠져도 되느냐고 물으면, 아닙니다. 연구개발은 데이터와 숫자가 틀리는 순간 문제가 되는 일이라, 화면에 올라가는 내용의 감수는 1차적으로 무조건 사람이 합니다. 특히 “이 특허가 우리를 침해하는가”처럼 나중에 큰 이슈가 될 수 있는 판단은 반드시 사람이 한 번 더 봐야 해요.
그래서 기준이 필요합니다. 어떤 갱신은 자동으로 돌려도 되고 어떤 판단은 사람 앞에 세워야 하는가. 이 경중을 가리는 평가 기준과 체크리스트를 만드는 일이 사실 화면을 만드는 일보다 중요했습니다. 원칙은 이렇게 잡았어요. 우선순위가 높거나 한번 만들어 둔 피드백 루프를 벗어나는 것은 사람이 들어가서 확인한다. 나머지는 처음 한 번만 점검하고 나면 자동으로 돌린다. 앞 단계가 안정화될수록 사람이 서 있어야 할 자리는 줄어들지만, 게이트 자체가 없어지지는 않습니다.
사람은 화면을 채우는 자리에서 빠지고, 화면을 의심하는 자리에만 남습니다.
한 장에 전부를 넣는 건 위험한 일이에요. 압축은 반드시 무언가를 지우니까요. 그래도 저는 반대쪽이 더 위험하다고 생각합니다. 전부를 한 번도 한 장에 안 넣어본 조직은 자기가 뭘 하고 있는지 끝내 모릅니다.
양산화 개발 조직의 연구원. 소수의 사람이 요구사항의 홍수를 견디는 자리에서, AI를 검색 도구가 아니라 손발로 세워보는 중입니다. 잘된 것보다 안 된 것을, 결론보다 과정을 적습니다.