부서마다 있는 일

부서마다 비슷한 일이 있습니다. 분기마다 측정 결과 엑셀을 열어 기준을 넘은 값을 노랗게 칠하고, 관정별로 추이를 그리고, 그 그림을 보며 "W02는 지난 분기부터 나빠지고 있다"는 문장을 만들어 보고서에 붙입니다. 서른 줄짜리 파일이면 반나절이면 끝나지만 관정이 늘고 항목이 늘면 하루가 갑니다. 그러면서도 전산 부서에 시스템을 만들어 달라고 요청할 만한 일은 아닙니다. 요청서를 쓰고 예산을 잡고 검수하는 절차가 이 일보다 큽니다. 그래서 몇 년째 사람이 합니다.

바이브코딩이 바꾸는 것은 정확히 이 자리입니다. 프로그래밍 언어를 배우는 것이 아니라, 무엇을 원하는지 말로 정확하게 적으면 도구가 만들어지는 방식입니다. 어떤 파일을 넣으면 어떤 화면이 나와야 하는지, 어떤 값을 어떤 기준으로 갈라야 하는지를 문장으로 쓸 수 있다면 그 문장이 곧 설계서가 됩니다. 요청서를 잘 쓰는 능력이 그대로 개발 능력이 되는 셈입니다. 그리고 요청서를 잘 쓰는 일은 여러분이 이미 매일 하는 일입니다.

그래서 이 과정에서 가장 오래 다루는 것은 편집기 사용법이 아니라 요구를 적는 법입니다. 도구는 반년이면 바뀝니다. 지금 쓰는 화면이 내년에 그대로 있을 거라고 아무도 장담하지 못합니다. 반면 "이 엑셀을 넣으면 이런 판정이 나와야 한다"를 정확히 적는 일은 도구가 바뀌어도 그대로 쓰입니다. 오늘 배울 것 중 가장 오래 남을 것이 그것입니다.

직접 만들 만한 일

모든 업무를 직접 만들 수 있는 것은 아닙니다. 다음 셋을 만족하면 직접 만드는 편이 빠르고, 하나라도 어긋나면 아직 이릅니다.

첫째로 입력과 출력이 분명해야 합니다. 어떤 파일이 들어오고 어떤 화면이 나와야 하는지 한 문장으로 말할 수 있어야 합니다. 이것이 안 되면 AI에게도 시킬 수 없습니다. "업무를 효율화하는 시스템"은 문장처럼 보이지만 아무것도 지시하지 않습니다. "관정별 수질 측정 엑셀을 넣으면 기준 초과 여부와 AI 해석이 담긴 대시보드가 나온다"는 지시입니다. 둘의 차이가 성패를 가릅니다.

둘째로 판정 기준이 이미 있어야 합니다. 법령이든 내부 지침이든 업무 매뉴얼이든 근거가 문서에 있어야 합니다. 기준을 AI에게 정하게 하면 그럴듯한 숫자를 만들어내고, 나중에 왜 그렇게 판정했느냐는 질문에 답할 수 없게 됩니다. 오늘 예제에서 유류 오염 의심을 1리터당 500마이크로그램으로 가르는 것도 먹는물 기준에서 온 것이지 누가 정한 값이 아닙니다.

셋째로 틀려도 되돌릴 수 있어야 합니다. 결재가 나가거나 대외로 발송되는 문서를 자동으로 만들게 하는 것은 아직 이릅니다. 사람이 결과를 보고 확인하고 손보는 자리가 남아 있어야 합니다. 오늘 만들 도구도 판정과 해석을 화면에 보여줄 뿐 어디로 보내지 않습니다.

오늘 만들 것

수질 측정 결과를 넣으면 이상치와 오염 의심을 가려내고, 관정별 상태를 한 문장으로 요약해주는 화면을 만듭니다. 설계에서 시작해 기능을 붙이고 데이터베이스를 연결하고 공개 주소로 배포하기까지 한 바퀴를 끝까지 돕니다. 중간에 멈추지 않는 것이 오늘의 목표입니다.

주제는 수질이지만 구조는 어느 업무에나 같습니다. 엑셀이 들어오고, 정해둔 기준으로 판정하고, 사람이 읽을 문장을 붙이고, 남겨서 다음에 다시 봅니다. 여러분 업무의 엑셀로 바꿔 넣으면 그대로 씁니다.