특수화학 케이스를 문서 한 건으로 마무리해야 하는 이유

특수화학 고객의 기술 케이스는 그 케이스를 위해 쓰고 승인을 거친 문서 한 건으로 마무리해야 합니다. 같은 케이스가 둘 없기 때문입니다. 조건, 소재, 용수, 설비, 현장 이력이 답을 정하므로 범용 보고서는 어느 케이스에도 답하지 못합니다. 루빈플라에서는 태스크가 회사 기록을 바탕으로 그 문서를 쓰고, 기본 설정에서는 등록하기 전에 사람이 승인합니다.

• 용수 하나만으로도 두 금속가공 현장의 결과가 갈릴 수 있습니다. 미국 산업안전보건청(OSHA)의 금속가공유 매뉴얼은 경수가 많은 금속가공유와 만나면 녹지 않는 비누 찌꺼기를 만들고, 일부 제품은 연수에서 거품이 많이 생길 수 있다고 설명합니다(US OSHA, accessed 2026).

• McKinsey Global Institute는 상호작용 업무 종사자(interaction workers)가 업무를 마치는 데 필요한 정보를 찾느라 보통 근무 시간의 19%를 쓴다고 추정했습니다(McKinsey Global Institute, 2012). 흩어진 케이스를 이어받는 사람이 떠안는 일이 이런 검색입니다.

• 루빈플라의 기본 제공 태스크는 저마다 정해진 유형의 문서 한 건으로 마무리됩니다. 제품 추천은 제품 제안서로, 문제 해결은 문제 해결 보고서로 마무리되며, 등록한 PDF에도 그 유형이 그대로 남습니다.

• 루빈플라의 유사 사례 분석은 과거 케이스를 찾기 전에 비교 기준부터 정합니다. 과거 케이스는 지배 메커니즘과 경계 조건이 현재 케이스와 일치하는 범위에서만 적용 가능한 사례로 봅니다.

• 제품 추천 케이스로 진행한 루빈플라 내부 벤치마크에서 케이스당 실작업 시간은 1시간 미만이었습니다. 같은 케이스와 같은 문서로 일반 AI 에이전트가 작업했을 때는 약 4.6시간이 걸렸습니다(Lubinpla Tasks page, 2026).

기술 케이스는 누군가 정리해 쓰기 전까지 어떻게 흘러가나요?

기술 케이스는 대개 조각난 채로 팀에 들어오고, 조각난 채로 남습니다. 케이스 전체를 정리해 달라고 요청받는 사람이 없기 때문입니다. 한 유통사의 응용 엔지니어를 떠올려 보겠습니다. 고객 공장의 보전 계획 담당자가 연삭 라인의 절삭유에 거품이 나기 시작했다고 메일을 보냅니다. 엔지니어는 공장에 전화해 들은 답을 노트에 적습니다. 공장 실험실은 섬프 측정값을 스프레드시트로 보내고, 현장 기술자는 채팅방에 사진을 올립니다. TDS는 처음 주문할 때의 메일 스레드에 들어 있습니다.

고객이 받는 것도 조각입니다. 농도를 낮춰 보자는 회신이 가고, 이어서 소포제에 관한 메일이 갑니다. 무엇을 찾았고, 무엇을 배제했고, 무엇을 해야 하고, 아직 무엇을 모르는지 한데 담아 보내는 사람은 없습니다.

그러다 라인에 다시 거품이 생기는데, 이 건을 맡았던 엔지니어는 다른 지역으로 옮긴 뒤입니다. 새로 맡은 엔지니어는 공용 메일함을 열고, 용수와 농도와 최근 변경 사항을 두고 공장에 같은 질문을 다시 합니다.

특수화학 케이스는 왜 모두 독립적인가요?

특수화학 케이스가 모두 독립적인 이유는 답을 정하는 사실이 한 고객의 현장에 속하고, 다른 어디에서도 똑같이 되풀이되지 않기 때문입니다. 같은 요청을 보낸 두 공장을 예로 들어 보겠습니다. 새 알루미늄 가공 라인에 어떤 절삭유를 써야 하느냐는 요청입니다.

첫 번째 공장은 연수기를 거친 물로 절삭유를 희석합니다. 두 번째 공장은 경도가 높은 지하수를 씁니다. OSHA 금속가공유 매뉴얼은 이 차이가 왜 중요한지 설명합니다. 경수의 칼슘과 마그네슘은 "많은 금속가공유와 섞이면 녹지 않는 비누 찌꺼기를 만들고", "일부 제품은 연수 때문에 거품이 많이 생길 수 있다"는 것입니다(US OSHA, accessed 2026). 같은 제품이 첫 번째 공장에서는 거품을 일으키고, 두 번째 공장에서는 비누 찌꺼기를 남길 수 있습니다.

현장 이력과 문제 자체도 케이스를 더 갈라놓습니다. 두 번째 공장이 얼룩 불만 때문에 어떤 제품을 뺀 적이 있다면, 그 이유로 후보 하나가 빠집니다. 첫 번째 공장에서는 여전히 쓸 수 있는 후보입니다. 얼룩이 절삭유에서 비롯된 것이 아닐 수도 있습니다. 세척한 다이캐스팅 부품에 다시 세척해도 지워지지 않는 흰 얼룩이 생겼다면, 헹굼이 덜 된 부품 위에서 알칼리 세정제의 규산염이 말라붙은 것이 원인일 수 있습니다. 그래서 이때 먼저 확인할 곳은 헹굼 단계와 헹굼수입니다.

케이스는 저마다 한 번만 존재하므로, 작업은 그 고객과 그 케이스를 위해 쓴 보고서 한 건으로만 마무리할 수 있습니다. 문서 한 건은 서식을 고른 결과가 아니라, 케이스가 독립적이라는 사실에서 나오는 결과입니다.

범용 보고서나 범용 AI 초안은 왜 어느 케이스에도 답하지 못하나요?

범용 보고서가 어느 케이스에도 답하지 못하는 이유는 케이스가 생기기 전에 쓴 글이기 때문입니다. 범용 AI 초안은 같은 문제를 더 빨리 되풀이할 수 있습니다. 브로슈어, 표준 적용 가이드, 템플릿을 재활용한 답변은 제품이 일반적인 조건에서 어떤 성능을 내는지 알려 줍니다. 그러나 이 현장의 용수나 합금, 탈락한 후보와 그 이유, 권고가 기대고 있는 조건, 아직 모르는 것은 적혀 있지 않습니다. 공장장은 "대부분의 알루미늄 가공에 적합"이라는 문구를 근거로 변경을 승인할 수 없습니다.

범용 AI 도구가 처음에는 도움이 됩니다. 통화 메모를 붙여 넣으면 어시스턴트가 금방 깔끔한 회신으로 바꿔 줍니다. 한계는 케이스에 이력이 쌓이면서 드러납니다. 어시스턴트는 사본을 놓고 일합니다. 회신은 메일로 나가고, 무엇을 결론 냈는지는 고객사 기록에 남지 않습니다. 어시스턴트는 회사 TDS의 한계값이나 그 현장의 지난 이력이 아니라 일반 지식으로 답합니다. 그래서 어시스턴트가 채운 템플릿은 어느 현장에서 읽어도 그럴듯합니다. 붙여 넣는 스레드가 늘어날수록 중요한 세부 정보가 입력 중간에 놓일 수 있습니다. Liu 등은 모델이 "긴 컨텍스트의 중간에 있는 관련 정보에 접근해야 할 때 성능이 크게 떨어진다"는 것을 확인했습니다(Liu et al., TACL 2024).

루빈플라에서는 태스크의 스텝이 고객사, 프로젝트, 업무일지, 그리고 데이터룸과 산출물에 있는 파일을 읽습니다. 고객용 문서는 그 고객사의 산출물에 다시 등록합니다.

루빈플라에서 케이스마다 문서 한 건이란 무엇을 뜻하나요?

루빈플라에서 케이스마다 문서 한 건이란, 케이스 작업을 태스크로 진행하고 태스크는 정해진 유형의 문서 정확히 한 건으로 마무리된다는 뜻입니다. 통화와 방문은 업무일지로 기록하고, 태스크의 스텝이 고객사, 프로젝트, 파일과 함께 업무일지를 읽습니다. 그래서 문서는 메일이나 통화마다 따로 나오지 않고 태스크에서 나옵니다.

문서 유형은 작업에 맞춰 정해집니다. 기본 제공 태스크는 21개이고, 저마다 문서를 쓰는 스텝으로 마무리됩니다. 제품 추천은 제품 제안서로, 문제 해결은 문제 해결 보고서로, 시험 준비는 시험 계획서로 마무리됩니다. 케이스가 다음 단계로 넘어가면, 예를 들어 추천에서 시험으로 넘어가면, 다음 단계는 별도의 태스크로 진행되고 그 태스크의 문서로 마무리됩니다.

문서는 읽을 사람을 위해 씁니다. 고객용 문서의 표지에는 PREPARED FOR 항목에 고객사 이름이 적히고, 문서 스텝은 쓰기 전에 작업 내용 중 무엇을 독자에게 전할지 묻습니다. 대부분의 기본 제공 태스크에서 문서 스텝은 완료된 모든 스텝의 결과를 모아 구성하고, 새로운 판단은 내리지 않습니다. 그래서 문서에는 이 케이스의 스텝이 찾은 내용이 담깁니다.

그림 1. 문제 해결 케이스를 마치면, 그 케이스를 진행한 고객을 위한 문제 해결 보고서 한 건이 등록됩니다.

승인을 거친 문서 한 건은 기술팀에 어떤 도움이 되나요?

승인을 거친 문서 한 건이 있으면 기술팀은 승인 지점, 고객이 실행할 수 있는 답, 보관된 선례, 깔끔한 인계를 얻습니다.

승인 지점은 곧 책임 소재입니다. 사람이 승인하고 끝내기를 누르면 스텝에 승인한 사람의 이름이 '승인: 이름' 형태로 시각과 함께 표시되고, 그 뒤로는 문서를 바꿀 수 없습니다. 팀은 고객에게 무엇을 전했는지, 누가 그 답을 책임졌는지 알 수 있습니다.

답이 효과를 내는 것은 고객이 그 답대로 움직일 수 있기 때문입니다. 결론과 결론이 기대는 조건, 다음 단계를 받은 공장장에게는 승인하고, 주문하고, 실행할 대상이 생깁니다.

선례는 고객사에 남습니다. 이후 태스크는 그 고객사의 산출물에 있는 파일을 읽습니다. 새 케이스가 예전 케이스와 비슷해 보이면, 유사 사례 분석이 검색 전에 정해 둔 기준으로 둘을 비교하고, 과거의 결론을 현재의 확정된 결정으로 끌어올리지 않습니다. 예전 문서는 새 케이스에 참고가 되지만, 새 케이스는 그래도 자기 문서를 따로 받습니다.

인계도 마찬가지입니다. 엔지니어가 자리를 비우면 담당자 편집으로 태스크를 동료에게 넘깁니다. 넘겨받은 동료는 전달받은 메일함 대신 스텝과 등록된 문서를 엽니다.

기술 케이스 문서에는 무엇이 담기나요?

기술 케이스 문서에는 조건, 후보, 근거, 결론, 미결 사항이 담깁니다. 조건은 농도, 용수, 소재, 온도처럼 그 현장의 값입니다. 후보는 먼저 넓게 펼쳐 놓고, 확인된 현장 조건이나 보고된 관찰이 후보의 전제를 배제할 때에만 뺍니다. 뺀 이유는 남겨 둡니다.

근거는 진술과 묶여 있습니다. 표에는 대개 출처와 기준일을 적은 캡션이 붙습니다. 문서 끝의 참고자료 페이지에는 데이터룸 파일, 웹 페이지처럼 태스크의 스텝이 인용한 출처가 행으로 정리되고, 이 행은 승인 전에 편집할 수 있습니다. 루빈플라는 확인된 것, 추론한 것, 모르는 것을 끝까지 구분해 다룹니다. 그래서 확인된 진술에는 출처가, 추론에는 메커니즘과 확인 방법이 붙습니다.

미결 사항도 답의 일부입니다. 결론을 뒤집을 수 있는 미지 사항은 모두 적습니다. 근거를 따져도 후보가 둘 이상 남으면, 문서는 남은 후보마다 그 후보들을 가려낼 시험을 함께 적습니다. 현장 조건에서 그 결론까지 가는 추론은 특수화학에서 기술 추론이 무엇을 뜻하는지 다룬 글에서 설명합니다.

케이스 문서는 메일 스레드, CRM 메모, 템플릿과 비교해 어떻게 다른가요?

케이스 문서에는 한 고객의 케이스 전체가 담깁니다. 메일 스레드나 CRM 메모에는 그 일부가 담기고, 범용 템플릿에는 아무것도 담기지 않습니다. 아래 표는 필요한 항목마다 세 가지를 비교합니다.

가장 많은 것을 가르는 행은 마지막 행입니다. 메일 스레드가 다음 케이스에 도움이 되려면 먼저 찾아서 다시 읽어야 합니다. 그때쯤이면 어느 회신이 최종인지 알던 엔지니어가 떠났을 수 있습니다. 템플릿은 모든 케이스를 같은 빈 양식에서 시작하므로, 한 현장에서 배운 것이 다음 현장으로 이어지지 않습니다. 등록된 케이스 문서는 고객사의 산출물에 있습니다. 그 현장의 다음 태스크가 이 문서를 읽고, 유사 사례 분석은 새 케이스를 이 문서와 기준별로 비교할 수 있습니다. 승인 행은 일이 잘못됐을 때 중요해집니다. 메일 스레드로는 누가 답을 확인했는지 아무도 말할 수 없지만, 케이스 문서에는 누가 언제 승인했는지 나옵니다.

케이스 문서가 하지 않는 일은 무엇인가요?

케이스 문서는 그 바탕이 되는 기록만큼만 최신이며, 제품이 효과가 있는지 가리는 확인 절차를 대신하지 않습니다. 데이터룸에 올라오지 않은 데이터시트 개정판이나 아무도 기록하지 않은 통화는 태스크에 보이지 않습니다.

제품 제안서가 곧 제품 승인은 아닙니다. 제품이 효과가 있는지는 벤치와 고객 라인에서 결정되고, 그 시험의 성공 기준과 중단 기준은 시험 준비 태스크가 미리 정합니다.

고객용 PDF에는 앱 안의 인용 표시가 실리지 않습니다. 앱에서는 스텝의 진술마다 그 바탕이 된 기록과 웹 페이지를 가리키는 번호 인용이 붙습니다. 고객 PDF에서는 이 표시를 빼고, 대신 승인 전에 확인한 참고자료 페이지를 인쇄합니다.

팀의 누군가가 공유하기 전까지는 고객에게 아무것도 가지 않습니다. 등록된 문서는 비공개로 시작하고, 고객사 담당자는 팀이 공유한 뒤에야 필드 케어에서 문서를 볼 수 있습니다.

전체 그림은 루빈플라 소개 글에서 볼 수 있습니다. 태스크 페이지에는 태스크마다 결과 문서가 정리되어 있고, 그 안의 추론은 특수화학의 기술 추론을 다룬 글에서 설명합니다.