ebson

문서는 코드보다 오래 사는 것처럼 보이지만, 사실 코드만큼이나 빨리 낡습니다. 코드가 바뀌면 그에 딸린 설명과 예제도 함께 바뀌어야 하는데, 사람의 손이 닿는 일이다 보니 한두 군데가 빠지기 쉽습니다. 그렇게 빠진 자리는 한동안 아무 표시도 내지 않습니다. 문서는 컴파일되지 않으니, 그 안의 예제가 더 이상 동작하지 않게 되어도 빌드가 깨지며 알려 주지 않습니다. 누군가 그 예제를 믿고 그대로 따라 쓰기 전까지는 조용히 남아 있습니다. 이번 글에서 다룰 LangChain4j의 문서 수정은 바로 그런 종류의 문제였습니다. 한 애너테이션이 라이브러리에서 제거되었는데, 그것을 사용하는 예제가 여러 문서에 그대로 남아 있었습니다. 그 예제를 복사해 붙이면 더 이상 컴파일되지 않는 상태였습니다. 결과만 보면 문서..

코드를 읽다 보면 "여기에 당연히 있어야 할 것이 왜 없지" 싶은 순간이 있습니다. 비슷한 항목들이 나란히 줄지어 있는데, 그중 두 개만 빠져 있는 식입니다. 빠진 자리는 평소에는 아무 표시도 내지 않습니다. 그 자리를 실제로 밟는 입력이 들어오기 전까지는요. 그러다 어느 날 누군가 하필 그 빠진 자리에 해당하는 값을 넘기면, 갑자기 알 수 없는 오류가 튀어나옵니다. 이번 글에서 다룰 LangChain4j의 에이전트 모듈 수정은 바로 그런 종류의 버그였습니다. 값을 알맞은 타입으로 바꿔 주는 코드가 있는데, 그 안에서 처리하는 타입 목록에 두 가지가 빠져 있었습니다. 빠진 타입을 쓰는 경우에만 변환이 제대로 되지 않아, 엉뚱한 타입의 값이 그대로 흘러가 오류로 이어졌습니다. 결과만 보면 두 줄을 더하고 ..

자바에서 문자열을 더하는 일은 너무 익숙해서 위험을 잘 느끼지 못합니다. 두 문자열을 +로 이으면 그만이고, 숫자든 다른 객체든 옆에 붙이면 알아서 글자로 바뀝니다. 그런데 이 편리함에는 조용한 함정이 하나 있습니다. 비어 있는 값, 즉 null을 문자열에 더하면 오류가 나는 것이 아니라 "null"이라는 네 글자가 그대로 붙는다는 것입니다. 예외가 터지면 적어도 무언가 잘못됐다는 신호라도 받겠지만, 이 경우에는 아무 일도 없었다는 듯 멀쩡해 보이는 문자열이 만들어집니다. 그 문자열이 어딘가로 전송되기 전까지는 말입니다. 이번 글에서 다룰 LangChain4j의 HTTP 클라이언트 수정은 바로 그 함정에 관한 것이었습니다. 파일을 업로드할 때 만들어지는 본문 안에, 비어 있어야 할 자리에 null이라는 ..

서비스를 만들다 보면 "정상적인 입력"을 가정하고 짠 코드가 의외로 많습니다. 사용자가 빈 값을 보내지 않을 것이고, 필수 항목은 채워서 보낼 것이라는 전제 위에 코드가 서 있습니다. 그런데 그 입력이 사람이 아니라 언어 모델에서 온다면 이야기가 달라집니다. 언어 모델의 출력은 대체로 형식을 잘 지키지만, 늘 그런 것은 아닙니다. 가끔은 비워 두어야 할 자리를 채우거나, 채워야 할 자리를 비운 채로 내놓습니다. 그래서 모델의 출력을 받아 실제 동작으로 옮기는 코드는, 그 입력이 어긋날 수 있다는 것을 전제로 단단하게 짜여 있어야 합니다. 이번 글에서 다룰 LangChain4j의 셸 도구 수정은 바로 그 지점에 관한 것이었습니다. 모델이 만들어낸 도구 인자 중 하나가 비어 있을 때, 코드가 의도한 방식으로..