코드보다 문서가 많은 FA 업무의 비(非)코딩 공정을 AI로 처리하기

FA 엔지니어의 일은 코드를 작성하는 시간만으로 이루어져 있는 것이 아니다. 오히려 서류 작업이 더 많은 날도 있다. 사양 정리, 시험 절차서, 셋업 후 보고서. 이러한 문서 작업이 체감상 업무의 거의 절반 가까이를 차지한다. AI 활용이라고 하면 코드 생성에만 주목하기 쉽지만, FA에서는 비(非)코딩 공정이야말로 AI가 효과를 발휘할 수 있는 부분이 많다.

본 기사에서는 코드 주변의 문서 작업을 Claude Desktop을 이용해 어떻게 처리하는지에 대해 작성한다. 이전 연재에서 '공정의 연속성'을 Desktop의 장점으로 언급했다. 동일한 환경과 동일한 맥락 속에서 코드와 문서를 모두 다룰 수 있다는 것, 그 구체적인 내용이다.

사양 정리: 모호한 메모를 구조화하기

프로젝트 초반에는 대부분 파편적인 메모로 시작한다. 고객사의 요구사항, 장치의 제약 사항, 과거 프로젝트에서 가져온 부분들. 이것을 머릿속으로 사양에 조합하는 작업이 은근히 시간을 많이 잡아먹는다.

여기서 AI에게 초안 작성을 맡긴다. 목록 형태의 메모를 전달하며 '입출력, 상태 전이, 이상 시 동작 관점에서 사양서의 뼈대를 만들어 달라'고 요청하면, 빠져 있는 관점이 떠오른다. 이상 케이스를 작성하는 것을 잊었거나, 초기화에 대한 고려가 부족했다는 식의 구멍들이 구조화 과정을 통해 발견된다. AI가 채워 넣은 부분을 그대로 사용하기보다는, '지적된 구멍'으로 받아들여 스스로 확정시키는 것이 좋다.

사양서의 뼈대는 자신만의 형식을 정해두고 있다. 대략 이런 구성이다.

# FB명
## 목적 (1~2문장)
## 입력
...

이 형식을 AI에게 주어두면, 메모를 이 형태에 맞춰 흘려보내 준다. '제약' 항목을 넣는 것이 핵심인데, 여기에 배열의 시작점이나 데이터 타입 결정 사항 등을 적어두면 그것이 그대로 코드 생성 시 지침이 된다. 사양이 확정되면 바로 코드 생성 입력으로 활용할 수 있다. 이전 기사에서 작성했듯이, 나는 사양을 md 파일로 작성한 후 코드를 생성한다. 사양 정리와 코드 생성이 같은 환경에서 연결되어 있기 때문에, 사양을 수정하면 즉시 생성에 반영할 수 있다.

사양의 모호함을 해소하는 질문하기

또 하나 효과적인 것은 사양의 모호한 부분을 AI에게 질문하게 하는 것이다. 뼈대가 완성되면 '이 사양으로 구현한다고 가정하고, 결정되지 않은 점을 질문해 달라'고 요청한다. 그러면 '이상 상태로부터 복귀는 Execute 해제만으로 자동인지, 별도의 리셋 입력이 필요한지', '타임아웃이 필요한지'와 같은 질문들이 돌아온다. 스스로는 결정했다고 생각했던 부분이 실제로는 결정되지 않았다는 것을 깨닫게 된다. 질문에 답하는 형태로 사양을 채워나가면 빠진 부분이 줄어든다.

시험 절차서: 사양에서 역산하기

사양이 확정되어 있다면, 시험 절차서는 상당히 기계적으로 만들 수 있다. 사양의 각 항목에 대해 '어떻게 입력하고, 무엇을 확인하는지'를 대응시키면 된다. 이 대응 작업은 AI가 잘한다.

사양서를 전달하며 '각 항목을 검증할 시험 절차로 만들어 달라. 정상 케이스와 이상 케이스를 나누어서'라고 요청하면, 절차의 초안이 나온다. 이상 케이스 테스트는 사람이 잊기 쉬운 부분이라, 사양에서 포괄적으로 뽑아주는 것은 도움이 된다. 물론 실제 장비에서 의미 있는 절차인지는 스스로 판단해야 하지만, 처음부터 작성하는 것보다는 빠르다.

나오는 절차는 표 형태로 만들어 두면 현장에서 사용하기 좋다.

보고서: 사실만 정리하기

셋업 후의 보고서는 사실 정리가 주된 작업이 된다. 무엇을 했고, 어떻게 동작했으며, 어떤 과제가 남았는지. 여기서 AI에게 주의할 점은 '사실을 꾸며내지 않게' 하는 것이다.

나는 발생한 일의 목록 형태를 스스로 작성한 다음, 그것을 보고서 문체로 다듬어 달라는 순서를 따른다. AI에게 처음부터 쓰게 하면 그럴듯하지만 실제로는 일어나지 않은 것을 보완해 버린다. 사실은 사람이 제시하고, 형식만 AI에게 맡긴다. 이렇게 분담하면 허위 정보 생성 위험을 줄이면서 문서화의 수고만 덜 수 있다.

형식을 요청할 때도 '쓰지 않은 내용을 추가하지 말아 달라'고 명시한다. 그럼에도 불구하고 추가하는 경우가 있으니, 형식화된 문서를 원래 목록과 대조하여 늘어난 내용이 없는지 확인해야 한다. 숫자나 날짜가 멋대로 들어가 있다면, 먼저 의심해야 한다.

회의 메모 구조화하기

또 하나는 일상적인 작은 문서 작업으로 회의록이 있다. 설계 검토나 고객사와의 확인 과정에서 논의된 내용을 휘갈겨 쓴 메모가 남는다. 이것을 결정 사항, 미결 사항, 숙제(할당) 세 가지로 분류하는 것은 사소하지만 매번 발생하는 작업이다.

휘갈겨 쓴 메모를 건네며 '결정 사항, 미결 사항, 누가 할 숙제로 나눠달라'고 부탁하면, 분류된 형태로 돌아온다. 여기서도 사실을 추가해서는 안 된다. 메모에 없는 내용이 들어있으면 지워야 한다. 이렇게 분류된 자료는 다음 회의 시작 시 확인하는 재료가 된다. 미결 사항이 사양의 모호함과 직결되는 경우도 많기 때문에, 분류된 결과를 사양서의 '제약'이나 '미결' 항목에 반영한다.

회의록에서 사양서로, 사양서에서 코드와 시험 절차로 이어지는 흐름이 같은 환경 안에서 연결된다. 문서 작업 중 어느 한 가지를 AI에게 맡기기보다, 전체 흐름을 동일한 맥락으로 돌리는 것이 전후의 일관성을 잡기가 더 쉽다.

AI가 작성한 문서 검토

코드와 마찬가지로, AI가 작성한 문서도 검토한다. 관점은 코드와 조금 다르다. 사실과 일치하는지, 사양과 모순되지 않는지, 독자(고객사인지 내부인지)에게 맞는 수준인가. 특히 독자의 예상 시나리오는 AI가 취약한 부분이다. 사내용 기술 메모와 고객사 보고서는 작성해야 할 내용도 다르고, 쓰면 안 되는 내용도 다르다. 이 판단은 인간이 해야 한다.

문체도 본다. AI의 글은 어딘가 틀에 박힌 느낌을 주기 쉽다. 보고서라면 어느 정도 딱딱해도 괜찮지만, 그래도 '그럴듯한 문장'만으로는 부족하다. 사실이 전달되면 좋으니, 꾸밈은 필요 없다.

정보 관리 경계 설정

비코드 공정을 AI에게 맡길 때 가장 주의해야 할 것은 정보의 취급이다. 사양서나 보고서에는 고객사명이나 장치 구성 등 외부에 노출할 수 없는 정보가 포함된다. 무엇을 읽게 하고, 무엇을 쓰게 할지는 스스로 관리해야 한다. 개인적인 기사 작성용 폴더와 업무용 폴더를 분리해 두는 것은 이 연재를 통해 반복해서 써온 내용이다.

문서는 코드보다 근무지가 특정되는 정보를 담기 쉽다. 코드는 범용적으로 쓸 수 있지만, 보고서는 구체적인 프로젝트 이야기가 되기 때문이다. 그렇기에 비코드 공정에서 AI를 사용할 때는, 코드 작업 때보다 더 경계 설정에 의식을 해야 한다.

요약

FA 업무는 문서가 많다. 사양 정리에서는 놓친 관점을 AI에게 도출하게 하고, 모호한 점을 질문하여 채운다. 시험 절차서는 사양으로부터 역산시키고, 이상 상황 및 재실행 절차를 빠뜨리지 않는다. 보고서는 사실을 스스로 제시하고 형식만 맡겨서 꾸며진 부분이 없는지 대조한다. 코드 생성과 같은 환경에서 모든 것이 돌아가기 때문에, 사양이 수정되었을 때의 파급 효과도 추적하기 쉽다.

코드뿐 아니라 그 주변 문서 작업에 AI를 사용하면, 하루 동안 도구를 오가는 횟수가 줄어든다. 사소하지만, 이것이 쌓이면 큰 효과를 가져온다.

만약 이 서류에 AI를 사용했다는 이야기가 있다면 댓글로 알려주시면 좋겠다.

연재 '터미널도 Git도 없는 FA 개발 환경에서의 AI 코딩'

• 터미널 없이 AI 코딩—PLC 엔지니어가 Claude Code가 아닌 Claude Desktop을 선택한 이유
• Claude에게 PLC 전문 지식을 상시 배치시키기—'스킬'로 허가 명령 목록과 막히는 지점 모음 가지게 하는 방법
• AI가 작성한 ST 코드가 Sysmac Studio에서 통하지 않는 전형적인 패턴—타입 지정 리터럴・배열 INDEX・Execute 타입 FB
• FH 매크로를 AI에게 맡기기 어려운 이유—VBA처럼 보이지만 VBA는 아닌
• AI의 코드를 공장에서 사용하기 전 검증 프로토콜—사양 추적・책상 위 추적・독립 검토
• 세션을 넘나들며 지식 쌓기—Claude Desktop의 메모리와 폴더 연결을 FA 개발에 사용
• 코드보다 문서가 많다—FA 업무의 비코드 공정을 AI에게 맡기기(본 기사)

Discussion