질문을 잘 해도 틀릴 수 있다: 포트원 인증 이슈로 본 LLM의 한계

1. 글을 쓰게 된 이유

새 기술을 익힐 때 LLM은 굉장히 편하다. 
그래서 사실 프로젝트를 하던 중 시간에 쫓기면 내 스스로 학습을 하지 않고, 
학습은 나중으로 미룬 채 일단 LLM으로 개발을 먼저 할 때가 있다.

문서 요약도 빠르고 개발도 빠르다. 쓰지 않을 이유가 없다.
이번 문제는 내가 프론트엔드에서 인증 부분을 맡게 되면서 생기게 된 문제다.
우리는 핀테크 프로젝트를 개발 중이었고, 금융권인 만큼
인증 부분이 중요하다고 판단했다.

포트원 인증을 개발하며 LLM을 이용한 코딩을 시작했다.
웹으로 하는 것은 빠르고 상당히 타당해 보였으며,
무엇보다도 React 기반으로 인증 창을 여는 것은 빌드 방식을 바꿔야 하는데 이것이 여간 오래 걸리는 방식이라서, 간단하고 빠르게 구현하기 위해 인증을 웹에서 하는 식으로 구현했다.

하지만 실제로는 그렇지 않았다.

2. 문제가 없는 줄 알았다.

내가 아이폰 사용자이다 보니
갤럭시는 내 것으로 사용하는 게 아니라 공기계 테스트 폰을 따로 사용했다.

문제는 이때 공기계로 인증을 할 때는 앱을 계속 띄워놓고 인증을 하다 보니, 이때는 문제를 알아채지 못했다.

실제 문제는 안드로이드에서 발생했다.
웹에서 인증을 시작한 뒤 외부 앱으로 이동하고, 다시 복귀하면 인증 진행에 필요한 중간 페이지가 유지되지 않았다.
그 결과 계정 생성과 계좌 생성이 실패했다.

이 때문에 계정 생성이나 계좌 생성이 불가능한 문제가 생겼다...

그래서 내가 이 문제를 해결하기 위해 질문을 했다.

3. 내가 질문을 잘못한 줄 알았다

내 스스로도 처음 질문은 추상적이었다.

LLM이 이를 다르게 해석할 여지가 있을 수 있다고 생각했다.
그래서 상황과 증상을 더 자세히 설명해 다시 질문했다.
하지만 두 번째 질문을 했는데 잘 되지 않았다.

그런데도 LLM은 기존의 대답에서 빙빙 돌았다.

문제를 분석하기보다는 자신이 익숙한 해결 방식으로 밀어붙인 것이다.

4. 여기서 깨달은 점

이 경험으로 알게 된 것은 단순하다.
내가 기술을 알지 못하면 오답을 거를 수 없다.
LLM은 "그럴듯한 정답"은 잘 만들지만, 내가 그 기술에 대해서 잘 알지 못하면 그 답이 진짜인지 아닌지 검증이 불가능하다.

이번 사례에서는 나름 잘 준비를 했다고 생각했지만
결국 잘못된 길로 간 사례다.
React 웹에서도 가능하다고 했으며 해결책도 명확히 제시했다.
문제는 그 답변이 내가 실제로 겪고 있는 현상과 맞물리는지 따지지 않았다.

5. 그렇다면 새 기술에서는 어떻게 쓸까?

이후에 나는 순서를 바꾸었다.

1. 공식 문서를 통해 기술의 제약 조건을 확인 한다.
2. 기술의 한계점이나 현재 프로젝트에서 어떻게 기술을 사용할지 파악한다
3. 그다음으로는 내가 파악한 기술이 맞는지 요약해서 검증한다.
4. 상황 정리 및 해석, 혹은 내가 빠뜨린 것을 체크한다
5. 답을 가져와서 소규모로 내가 생각한 게 맞는지 테스트를 반복하며 개발을 이행한다.

학습 - 질문 - 확인 - 검증
순서로 이어지게 했다.

어느 정도 시간을 쓰더라도
기술에 대해서 이해를 하고 그다음 단계를 진행하는 것이 결국에는 시간을 적게 쓰는 것이라는 것을 알 수 있었다.

6. 결론

LLM은 강력하다.
모르는 기술을 쓸 때 LLM을 정답 생성기처럼 그냥 사용해버리면 그럴듯하지만
결국 좋지 못한 결과물이 나온다고 생각한다.

질문을 잘하는 것도 중요하다.
하지만 자세한 질문을 하더라도 분명 틀릴 가능성은 존재한다.

특히 복잡하고 전문적인 과정으로 들어갈수록 문제이며, 가장 큰 문제는 틀렸을 때의 리스크이다.
잠깐은 빠르지만

결국 느려진다

모르는 기술일때는 LLM을 바로 사용하는 것 보다는 최소한의 기술을 이해한 뒤에
LLM에게 질문을 하는 것이 결국 시간을 아끼는 길이다.

LLM은 정답 생성기가 아니다.
검증 보조 도구이다.