과거에 담당했던 데이터 연계 처리(Data Integration Processing)를 다시 한번 검토하게 되었습니다.

계기는 연계 대상의 사양 변경에 대비하여, 기존 처리가 문제없이 작동하는지 확인하고 싶어졌기 때문입니다.

코드도 문서도 검증에 필요한 정보도 남아 있었지만, "어떤 조건에서 정상적으로 작동하는지", "무엇을 확인해야 하는지"는 즉시 떠오르지 않았습니다.

그래서 이번에는 AI에게 코드와 문서를 읽게 하면서, 사양 정리, 테스트 데이터 생성, 평가 진행 방식의 정리를 함께 진행했습니다.

이번에 하고 싶었던 것은 다음 세 가지입니다.

• 연계 대상의 사양이 바뀌어도 기존 메커니즘으로 올바르게 가져올 수 있는지 가늠하는 것
• 그 확인에 사용할 수 있는 테스트 데이터를 사양에 따라 만드는 것
• 가공 후의 데이터가 어디로 전달되고, 다음에 누가 처리하는지 파악하는 것

이 기사에서 쓰고 싶은 것은 결과 그 자체보다 다음의 점입니다.

• AI가 사양 이해를 진행하게 하려면 어떤 인풋(Input)이 효과적인가

처음에 다음 네 가지를 전달하니 상당히 진행하기 수월했습니다.

• 무엇을 평가하고 싶은가
• 처음에 볼 파일
• 실행해도 되는 범위
• 무엇을 OK로 간주할 것인가

완벽한 사양서를 처음부터 전달한다기보다, AI가 탐색을 시작하기 위한 발판을 전달하는 이미지입니다.

이번에 대상으로 삼은 것은 입력 데이터를 받아 가공하고, 연계 대상으로 전달하는 메커니즘입니다.

등장하는 시스템을 대략 정리하면 다음과 같습니다.

• 입력 데이터를 받는 보관 영역
• 데이터를 정형화(Formatting) 및 분류하는 처리 기반
• 가공 후 데이터를 받는 연계 대상
• 다음 처리로 연결하는 통지 및 연계 트리거(Trigger)
• 코드와 문서를 읽으며 사양 정리 및 테스트 관점 도출을 진행하는 AI

전체적으로는 파일을 배치하면 가공 처리가 실행되고, 그 결과가 다음 시스템으로 전달되는 구성입니다. 이번에는 이 흐름을 전제로, 사양 이해와 테스트 데이터 생성을 어디서부터 시작하는 것이 수월할지 확인했습니다.

이번에 AI가 수행한 것은 대략 다음과 같은 내용입니다.

• 처리의 입구와 변환 조건(Transformation Condition)을 읽음
• 조건에 맞는 테스트 데이터를 만듦
• 검증 환경에서 처리를 실행함
• 설정된 통지 및 연계 트리거를 확인함
• 그 이후의 연계 경로를 정리함

실제로 데이터 가공 처리의 입구를 기점으로 변환 조건을 추적하여, 최종적으로 연계 대상으로 전달되는 흐름임을 확인할 수 있었습니다.

도중에 효과적이었던 구체적인 사례도 있었습니다. 변환 로직(Transformation Logic)을 추적하니 특정 조건을 만족하는 데이터는 처리 대상으로 남는다는 것을 알 수 있었습니다. 이를 알게 됨으로써 이번 목적에 대해 타당한 테스트 데이터 조건을 판단하기 쉬워졌습니다.

처음에 효과적이었던 것은 의뢰를 "이 코드의 사양을 알려줘"가 아니라, "연계 대상의 사양이 바뀌어도 올바르게 처리할 수 있는지 평가하고 싶다"라고 설정한 것이었습니다.

이것만으로도 AI의 탐색 범위를 상당히 좁힐 수 있습니다.

• 어떤 입력이 처리 대상인가
• 어떤 행이 정상 데이터로 남는가
• 성공 시 어디로 나가는가
• 실패 시 어디로 떨어지는가
• 연계 대상으로는 누가 인계받는가

코드베이스 전체를 자유롭게 읽게 하는 것보다 입구를 하나 전달하는 것이 더 빠릅니다.

이번에는 다음 세 가지가 효과적이었습니다.

• 처리의 입구 파일
• 변환 로직의 본체
• 기존 단위 테스트(Unit Test)

특히 테스트 파일이 있으면 AI가 상상으로 사양을 보완하기 어려워지므로 도움이 됩니다.

이것도 상당히 중요했습니다.

도중에 "로컬에 국한되지 말고 이용 가능한 검증 환경을 사용해도 좋다"라고 전환함으로써, AI가 실제 운용에 가까운 검증으로 나아갈 수 있게 되었습니다.

이 한마디가 있는 것만으로도 AI는 다음과 같이 움직이기 쉬워집니다.

• 로컬 검증보다 검증 환경 확인을 우선함
• 실행 대상 및 저장 위치를 확인함
• 출력 파일의 내용까지 확인하러 감

AI를 상대로 할 때는 첫 지시를 끝까지 고정할 필요가 없었습니다.

이번 사례의 경우, AI가 변환 조건을 찾아낸 뒤에 "그 조건이라면 이 테스트 데이터로 OK"라고 답할 수 있었기에 다음 단계로 넘어가기 쉬웠습니다.

즉, AI에게 필요한 것은 처음부터 완전한 정답이 아니라, 도중에 수용 조건(Acceptance Criteria)을 업데이트할 수 있는 대화입니다.

이번 경험을 바탕으로 하면 다음과 같은 형태로 전달할 때 상당히 진행하기 수월합니다.

한동안 손대지 않았던 데이터 연계 처리의 사양을 잊어버렸습니다.
하고 싶은 것:
연계 대상의 사양이 바뀌어도 올바르게 처리할 수 있는지 평가하고 싶습니다.
...

포인트는 모든 것을 세세하게 쓰는 것이 아니라, AI가 다음 수를 결정할 수 있는 재료를 전달하는 것입니다.

반대로 다음과 같이 던지면 진행하기 어렵습니다.

• "이것 좀 조사해줘"라고만 하고 목적이 없음
• 입구 파일이 없음
• 실제 환경을 만져봐도 되는지 알 수 없음
• 무엇을 알게 되면 완료인지가 없음

AI는 편리하지만, 탐색의 우선순위를 결정할 재료가 없으면 아무래도 넓고 얕게 흐르기 쉽습니다.

이번에 시도해보며 느낀 점은, AI에게 필요한 것은 완벽한 사양서(Specification)보다 다음의 4가지 점이라는 것이었습니다.

• 평가 목적
• 입구 파일 (Input File)
• 실행 범위
• OK 조건

과거에 담당했던 처리를 재검토할 때일수록, 이 4가지 점이 있는 것만으로도 상당히 진행하기 수월해집니다.

"이전에 만졌던 처리인데, 지금은 사양을 기억하지 못한다"라는 상황은 흔히 발생하므로, 비슷한 상황에 처한 분들에게는 상당히 궁합이 좋은 진행 방식이라고 생각합니다.

주의사항

본 블로그에 게재된 내용은 저 개인의 견해이며, 소속된 조직의 입장이나 전략, 의견을 대표하지 않습니다. 어디까지나 엔지니어로서의 경험과 생각을 발신하고 있으니 양해 부탁드립니다.