LLM과 소프트웨어 개발에 대한 몇 가지 생각

잠시(일부는 휴가, 일부는 업무) 이 사이트 관리를 떠나 몇 주를 보내려 합니다. 일상을 몇 주간 벗어날 시간을 생각하니, LLM과 AI의 현황에 대해 흩어진 생각들을 몇 가지 나눠두고 싶어졌습니다.

❄❄❄❄

AI가 소프트웨어 개발에 미치는 영향에 대한 초기 설문을 몇 개 봤습니다. 정말로 속도를 높여주는가, 코드 품질을 개선하는가 아니면 망가뜨리는가? 이런 설문들의 큰 문제 중 하나는 사람들이 LLM을 어떻게 사용하는지를 고려하지 않는다는 점입니다. 제가 보기엔 대다수의 LLM 사용은 그럴싸한 자동완성, 흔히 코파일럿을 통한 사용입니다. 하지만 제가 아는, LLM에서 가장 큰 가치를 뽑아내는 사람들은 자동완성이 별로 쓸모 없다고 여기고, LLM이 소스 코드 파일을 직접 읽고 수정하여 작업을 수행하게 하는 접근을 선호합니다. LLM 사용의 서로 다른 워크플로를 무시하는 설문은 사람들을 틀린 방향으로 이끄는 데이터를 만들어낼까 봐 걱정됩니다.

(또 다른 복잡성은 모델마다 능력이 다르다는 점입니다.)

❄❄❄❄

“프로그래밍의 미래는 무엇인가요?”라는 질문을 자주 받습니다. 지금 소프트웨어 개발에 뛰어드는 게 좋을까요? LLM이 주니어 엔지니어의 필요를 없애버릴까요? 시니어 엔지니어는 너무 늦기 전에 업계를 떠나야 할까요? 여기에 대한 제 대답은 “전혀 모르겠습니다”입니다. 더 나아가 이 미래가 어떨지 안다고 말하는 사람은 엉뚱한 소리를 하고 있다고 생각합니다. 우리는 아직 LLM을 어떻게 써야 하는지 알아가는 중이며, 특히 LLM이 크게 향상된다면 이를 잘 활용하는 법을 파악하기까지는 시간이 걸릴 것입니다.

제가 제안하는 것은, 실험해 보라는 것입니다. 최소한 다른 사람들이 무엇을 하는지 읽어보되, 그들의 워크플로 세부에 주의를 기울이세요. 가능하면 직접 실험해보고, 경험을 공유해주세요.

❄❄❇❄

“AI가 버블인가요?”라는 질문도 받습니다. 제 대답은 “물론, 버블입니다”입니다. 운하와 철도에서 인터넷에 이르기까지, 모든 주요 기술 발전에는 경제적 버블이 함께했습니다. 우리는 이 버블이 언젠가 터져서 많은 투자가 허공으로 사라질 것을 거의 100% 확신합니다. 하지만 모르는 것은 언제 터질지, 그리고 그때까지 버블이 얼마나 커지며 그 과정에서 어느 정도의 실질적 가치가 생성될지입니다. 다음 달에 터질 수도, 2년은 더 갈 수도 있습니다.

또한 버블이 터지면 많은 회사가 망하겠지만, 모두가 망하는 것은 아니라는 것도 알고 있습니다. 닷컴 버블이 터졌을 때 pets.com은 죽었고, Webvan도 죽었습니다… 하지만 아마존은 죽지 않았습니다.

❄❄❄❄

저는 몇 해 전에 대중 연설에서 은퇴했습니다. 발표의 스트레스는 그립지 않지만, 업계 친구들과 어울리는 건 꽤 그립습니다. 그래서 GOTO Copenhagen에서 많은 친구들과 다시 만날 날을 기대하고 있습니다. 저는 1990년대(그때는 JAOO라 불렸습니다)부터 GOTO 컨퍼런스 시리즈에 관여해왔고, 지금도 이들이 흥미로운 프로그램을 구성하는 방식에 감탄합니다.

✢❄❄❄

예전 동료인 Rebecca Parsons는 오랫동안 환각(hallucination)은 LLM의 버그가 아니라 기능이라고 말해왔습니다. 사실 그것이 그 기능입니다. LLM이 하는 일은 환각을 만들어내는 것뿐이고, 다만 그중 일부가 우리에게 유용할 뿐입니다.

이로부터 따라오는 한 가지 함의는, 같은 질문을 LLM에 한 번 이상, 어휘를 조금 바꿔서라도, 던져보아야 한다는 점입니다. 그러면 답변을 비교할 수 있고, 심지어 LLM에게 답변들을 비교해달라고 요청할 수도 있습니다. 답변 사이의 차이가 그 답변만큼이나 유용할 수 있습니다.

특히 숫자 답을 환각 엔진에 묻는다면 최소한 세 번은 물어봐서 변동성을 가늠해야 합니다. 더 나아가 우리가 결정론적으로 계산할 수 있는 답을 LLM에게 계산시키면 안 됩니다(네, 그런 경우를 본 적 있습니다). 답을 계산하는 코드를 생성해달라고 LLM에 요청하는 것은 괜찮지만(그래도 한 번만 하지 마세요), 그렇게 하세요.

❄❄❄❄

다른 형태의 공학은 세계의 가변성을 고려해야 합니다. 구조 엔지니어는 측정할 수 없는 모든 요인에 대한 공차를 설계에 반영합니다. (경력 초기에 디지털 전자의 고유한 특성은 공차라는 개념이 없다는 말은 들은 기억이 납니다.) 공정 엔지니어는 사람이 작업을 수행하며 때때로 깜박이거나 부주의할 수 있음을 고려합니다. 소프트웨어 공학은 결정론적 기계를 다룬다는 점에서 특이합니다. 아마 LLM은 우리가 비결정성의 세계에서 다른 공학 분야의 동료들과 합류하는 지점을 표시하는 것일지도 모릅니다.

❄❄❄❄

적절한 이유와 함께 LLM을 주니어 동료에 비유하는 말을 자주 들었습니다. 하지만 제 경험상 LLM은 “모든 테스트 통과”라고 흔쾌히 말하곤 하지만, 제가 실제로 실행해보면 실패가 있습니다. 만약 그게 주니어 엔지니어의 행동이라면, 인사팀(H.R.)이 개입하기까지 얼마나 걸릴까요?

❄❄❄❄

LLM은 소프트웨어 시스템의 공격 표면을 크게 늘립니다. Simon Willison은 AI 에이전트를 위한 치명적 삼박자(The Lethal Trifecta)를 이렇게 설명했습니다: 개인 데이터에 대한 접근, 신뢰할 수 없는 콘텐츠에 대한 노출, 외부로 통신하는 경로(“유출, exfiltration”)를 결합한 에이전트. 여기서 “신뢰할 수 없는 콘텐츠”는 여러 방식으로 들어올 수 있습니다. 웹페이지를 읽으라고 시키면, 공격자는 1pt 흰 글자를 흰 배경에 넣어 지시를 숨겨 그 말을 잘 믿는 LLM을 속여 개인 데이터를 빼내게 만들 수 있습니다.

이는 특히 브라우저에서 동작하는 에이전트의 경우 심각합니다. 공격자의 웹페이지를 읽으면, 그 에이전트를 속여 다른 탭의 당신 은행 계좌로 가서 잔액을 “친절한” 공격자에게 이체해 “선물을 사”도록 만들 수 있습니다. Willison의 견해는 “에이전트형 브라우저 확장이라는 개념 전체 가 치명적으로 결함이 있으며 안전하게 만들 수 없다”는 것입니다.