지금 우리는 대형 언어 모델(LLM)이라는 새로운 기술의 엄청난 변화 속에서 살고 있어요 . 이 변화는 마치 90년대 후반 웹이 처음 등장했을 때처럼 느껴져요 . 그때는 웹이 엔터프라이즈 소프트웨어에 큰 영향을 주지 않을 거라 생각했지만, 결국 웹이 모든 것이 되었죠 . LLM의 발전 속도도 웹처럼 점점 빨라지고 있답니다 . 이런 변화 속에서 소프트웨어 개발은 10년 안에 지금과는 매우 달라질 거예요 .
시나리오 | 핵심 내용 | 개발자 준비 필요성 |
종말 시나리오 | AI가 인류를 지배하거나 멸망시킬 가능성 | 우리의 노력과 상관없이 결과는 같을 것 |
정체 시나리오 | LLM의 발전이 현재 수준에서 크게 나아가지 않음 | 지금 도구만으로도 멋진 일 가능, 준비 안 해도 괜찮음 |
소프트웨어 혁명 시나리오 | LLM이 소프트웨어 개발 방식을 혁신적으로 변화시키지만, 인간 개발자는 여전히 필요함 | 지금 공부하는 것이 중요, 새로운 기회를 잡을 수 있음 |
LLM 발전에는 여러 미래가 예상되지만, 크게 세 가지 시나리오를 생각해 볼 수 있어요 .
첫 번째는 '종말 시나리오'예요 .
AI가 우리를 죽이거나 배터리로 사용하거나 , 토스터 생산량만 최적화하려다 세상을 토스터 공장으로 만들 수도 있죠 .
이 시나리오에서는 우리가 LLM을 공부하든 안 하든 결과는 똑같을 거라고 해요 .
두 번째는 '정체 시나리오'입니다 .
LLM이 지금보다 크게 발전하지 않고 시들해지는 경우인데 , 저는 지금 도구로도 놀라운 일을 할 수 있다고 생각해요 .
이 시나리오라면 지금 공부하지 않아도 괜찮고, 나중에 "내가 그럴 줄 알았지!"라고 말할 기회가 올 거예요 .
그래도 저는 이 시나리오를 준비하고 있지는 않답니다 .
세 번째는 제가 가장 가능성 높다고 생각하는 '소프트웨어 혁명 시나리오'예요 .
소프트웨어 개발이 완전히 바뀌지만, 인간 개발자는 여전히 필요하다는 거죠 .
이 시나리오에서는 지금 LLM을 공부하는 것이 정말 중요해요 .
미래에 더 쉽게 배울 수도 있겠지만 , 일찍 시작하는 것이 유리하답니다 .
LLM을 잘 쓰려면 '프롬프트 엔지니어링'이라는 것을 배워야 해요 . 이건 LLM에게 우리가 원하는 결과를 얻도록 명령을 잘 내리는 방법 같은 거죠 . 마치 요리사에게 재료와 레시피를 정확히 알려줘야 맛있는 음식이 나오는 것처럼요.
저는 게임 캐릭터 대화에 LLM을 써보는 실험을 했어요 .
단순히 "너는 해적이야"라고 시키는 건 잘 안 됐죠 .
제가 해적에게 AI 스타트업 아이디어를 제안했더니, 해적은 돈이 될 것 같다며 관심을 보였지만 , 진짜 해적 같은 반응은 아니었어요 .
시간 여행자가 보물을 훔치려 할 때 "요즘 세상에 그런 짓을 하다니!"라고 말하는 해적은 없겠죠 ?
그래서 명령을 여러 개로 나누어 쓰는 방법을 시도했어요 .
하나는 '이 대화가 해적 시대 배경에 맞나?' 확인하고 .
다른 하나는 '해적의 대사를 만들어줘'라고 시키는 거죠 .
이렇게 하니 LLM이 제가 원하는 배경에 맞는지 더 잘 판단하더라고요 .
이것은 마치 오래된 디자인 원칙인 '관심사의 분리'와 같아요 .
하나의 복잡한 명령 대신, 명확한 여러 단계를 거치게 하는 것이 LLM을 더 신뢰성 있게 만드는 방법이 될 수 있답니다 .
LLM을 우리 기존 소프트웨어와 합쳐서 쓰는 것도 가능해요 . 마치 레고 블록처럼, LLM이라는 특별한 블록을 기존 소프트웨어 블록과 연결하는 거죠. 이렇게 하면 더 복잡하고 재미있는 시스템을 만들 수 있어요 .
저는 해적 게임 대신 경찰 심문 게임을 만들어봤어요 .
이 게임에서는 목격자에게 질문하고, LLM이 그 질문이 얼마나 '위협적인지' 숫자로 평가해줘요 .
그 숫자를 가지고 게임의 다른 규칙들이 다음 상황을 결정하죠 .
이처럼 LLM은 특정 기능을 수행하고, 나머지 게임 로직은 기존 소프트웨어로 만드는 방식이에요 .
LLM의 예측 불가능한 부분과 기존 소프트웨어의 정확한 부분을 잘 조합하는 거죠 .
Retrieval-Augmented Generation (RAG)이라는 기술도 있어요 .
이건 LLM이 답변을 만들 때, 가지고 있는 지식 외에 외부 자료(문서, 웹 검색 결과 등)를 참고하게 하는 거예요 .
마치 스마트폰으로 검색해서 정보를 얻고, 그 정보를 바탕으로 답변하는 것과 같아요 .
이 기술은 LLM이 자신의 학습 데이터 외의 정보에 기반하여 답변하게 하는 데 유용하답니다 .
개념 | 설명 | 특징/장점 | 활용 사례 |
파인튜닝 (Fine-tuning) | 이미 학습된 LLM의 내부를 특정 목적에 맞게 수정하는 과정 | • 처음부터 모델을 만드는 것보다 효율적 | • 사용자 의도 분류 (예: 정보 요청, 행동 요청) |
기반 모델 (Base Model) | 파인튜닝의 시작점으로 사용되는, 이미 많은 지식을 학습한 대규모 언어 모델 | • 세상의 다양한 개념 및 관계에 대한 일반적인 지식 보유 | N/A |
LLM의 내부를 살짝 바꿔서 내가 원하는 일을 더 잘하게 만드는 것을 '파인튜닝(Fine-tuning)'이라고 해요 . 이건 처음부터 모델을 만드는 것과는 달라요.
이미 세상 많은 것을 알고 있는 모델을 시작점으로 사용해요 .
집이 뭔지, 차가 뭔지, 차는 보통 집 안에 없다는 걸 이미 아는 모델에 새로운 것을 살짝 가르치는 것이죠 .
파인튜닝의 장점은 작은 모델로도 큰 모델과 비슷한 성능을 낼 수 있다는 거예요 .
큰 모델은 돈도 많이 들고 느릴 수 있거든요 .
그래서 작은 모델에 큰 모델이 만든 결과물을 가지고 학습시키는 거죠 .
저는 LLM이 사용자의 '의도'를 분류하는 모델을 만들어봤어요 .
예를 들어 "프랑스 수도가 뭐야?"라고 물으면 '정보 요청'으로 분류하는 거죠 .
"프랑스행 비행기 예약하고 싶어"는 '행동 요청'이고요 .
이렇게 특정 목적에 맞게 모델의 일부(예: 마지막 출력 부분이나 중간 숨겨진 부분)를 수정하면 , 모델이 그 목적에 더욱 특화된 능력을 갖게 됩니다 .
LLM 모델을 개발하거나 파인튜닝할 때는 실제 데이터가 아주 중요해요 . 직접 사용자들이 입력한 데이터를 보면, 우리가 생각지 못한 다양한 상황과 표현들을 알 수 있거든요 . 마치 우리가 세운 계획이 현실과 부딪히며 수정되는 것처럼요.
저는 인터넷에서 사람들이 실제로 챗봇에 입력한 데이터를 찾아서 사용했어요 .
이 데이터에 LLM을 사용해서 '사용자의 의도' 라벨을 달았죠 .
처음에는 제가 생각한 분류 기준이 완벽하다고 생각했지만 , 실제 데이터를 보니 어떤 질문들은 어떤 범주에도 명확히 속하지 않는 경우가 많았어요 .
예를 들어, "분석 보고서 요청" 같은 것은 정보 요청인지, 행동 요청인지 애매했죠 .
이런 데이터는 분류 체계 자체를 다시 생각하게 만들어요 .
또 하나 조심해야 할 점은, 모델이 학습 데이터의 '꼼수'를 부릴 수 있다는 것이에요 .
제가 만든 분류 모델은 '프롬프트 명령어'를 잘 구분하지 못했는데 , 파인튜닝을 시켰더니 구분을 잘하는 것처럼 보였어요 .
그런데 알고 보니, 모델은 단순히 글자 수가 긴 것을 '프롬프트 명령어'로 분류했던 거예요 .
실제 내용을 이해한 것이 아니라, 데이터의 특징(길이)만 보고 판단한 거죠 .
이런 함정을 피하려면 다양하고 균형 잡힌 학습 데이터를 만드는 것이 중요해요 .
도메인 주도 설계(DDD)는 소프트웨어 복잡성을 다루는 데 유용한 방법론이에요 . 발표자는 LLM 시대에도 DDD가 여전히 의미가 있을지 고민했어요 . 결론적으로, DDD의 핵심 개념들이 LLM 활용에 도움이 될 수 있다고 생각합니다.
DDD의 목표는 소프트웨어의 복잡성을 해결하는 것인데 , LLM도 복잡한 정보를 다루는 도구라는 점에서 공통점이 있어요 .
DDD의 중요한 개념 중 하나인 '유비쿼터스 언어'는 팀원들이 도메인(업무 영역)에 대해 같은 용어를 사용하고 이해하는 것을 말해요 .
이것이 LLM에게 명령을 내리는 프롬프트 엔지니어링에도 도움이 될 수 있다는 가설을 세웠죠 .
LLM에 익숙해지면 자연어보다는 더 구조적이고 명확한 언어로 프롬프트를 만들게 되는데 , 이것이 유비쿼터스 언어와 닮아 있다는 거예요 .
또 다른 DDD 개념인 '바운디드 컨텍스트'는 모델의 적용 범위를 명확히 정하는 것이에요 .
LLM 자체도 특정한 방식으로 언어를 이해하고 생성하는 '정해진 경계(Bounded Context)'를 가진다고 볼 수 있어요 .
이런 개념을 활용하면 LLM의 응답을 좀 더 예측 가능하게 만들고 , 기존 소프트웨어와 더 쉽게 통합할 수 있지 않을까 추측하고 있답니다 .
LLM으로 인해 세상은 정말 빠르게 변하고 있어요. 우리는 무엇이 일어날지 정확히 알 수 없습니다 . 이런 불확실한 시대에 개발자로서 어떻게 대처해야 할까요?
가장 중요한 것은 '배우고, 배우고, 또 배우는 것'입니다 .
지금 배우는 것이 나중에 쓸모없어질 수도 있지만 , 끊임없이 새로운 것을 익히려는 자세가 중요해요 .
마치 웹 초창기에 여러 기술을 배웠다가 사라진 것처럼요 .
그리고 직접 '실험'하고 '경험'하는 것이 아주 값지답니다 .
혼자만 알지 말고, 커뮤니티와 '공유'하세요 .
개인이 할 수 있는 것보다 커뮤니티 전체가 함께 배우고 성장하는 힘이 훨씬 크기 때문이에요 .
마지막으로, '모른다는 것을 편하게 받아들이는 것'도 중요해요 .
무조건 강한 의견을 가지기보다 "나는 모르지만, 어떤 변화든 준비하겠다"는 자세가 더 좋답니다 .
지금은 웹 초창기처럼 엄청나게 흥미진진한 시기예요 . 이 기회를 놓치지 마세요!
LLM은 웹의 등장과 같이 소프트웨어 개발에 큰 변화를 가져올 것이며, 기존 소프트웨어와 LLM 컴포넌트를 결합하는 방식이 가까운 미래에 유용할 것이라고 생각합니다.
💡 LLM 학습을 위해 에릭 에반스가 제안하는 방법은?
프롬프트 엔지니어링: LLM에 원하는 응답을 얻기 위해 구체적인 지침을 제공하는 것
파인튜닝: 기존 모델을 특정 작업이나 데이터셋에 맞게 조정하여 성능을 향상시키는 것
내부 구조 이해: LLM의 작동 방식을 이해하기 위해 관련 서적이나 자료를 학습하는 것
이 컨텐츠는 대형 언어 모델(LLM)의 현재와 미래에 대한 강연으로, LLM이 소프트웨어 개발에 가져올 혁명적인 변화와 이에 대한 준비의 중요성을 강조합니다. 강연자는 LLM을 활용한 프롬프트 엔지니어링과 파인튜닝 경험을 공유하며, DDD(Domain-Driven Design) 원칙이 LLM 시대에도 유효할 수 있다는 가설을 제시합니다.
최근 대형 언어 모델(LLM)에 대한 관심이 높아지고 있음.
LLM과 관련된 변화는 매우 빠르게 일어나고 있어, 오늘 이야기하는 내용도 1년 후면 구식이 될 수 있음.
현재의 논의는 임시적이고, 추측에 기반한 부분이 많음.
LLM에 대해 깊은 이해나 경험을 가진 사람은 아직 많지 않음.
LLM은 'Large Language Model'의 약자임.
과거의 AI 시도들과 달리, 이번 LLM은 웹이 처음 등장했을 때와 비슷한 혁신적 느낌을 줌.
웹이 처음에는 별 것 아닌 것처럼 보였지만, 결국 모든 것을 바꿨듯이 LLM도 그럴 가능성이 있음.
변화의 속도가 점점 더 빨라지고 있음.
미래에 대해 확실히 알 수는 없지만, 준비는 필요함.
대표적인 시나리오 세 가지:
종말 시나리오: AI가 인류를 위협하거나, 모든 것을 장악하는 극단적 상황. 이 경우, 우리가 LLM을 공부하든 안 하든 결과는 같음.
실망 시나리오: LLM이 지금 수준에서 더 이상 발전하지 않는 경우. 그래도 이미 상당한 영향이 있을 것이고, 소프트웨어 개발 방식에 변화가 있을 것임.
소프트웨어 혁명 시나리오: LLM이 소프트웨어 개발을 혁신하지만, 인간의 역할은 여전히 필요함. 이 경우, 지금 공부하는 것이 미래에 유리함.
LLM의 발전은 노동시장 등 사회 전반에 큰 변화를 가져올 수 있음.
소프트웨어 개발 방식이 크게 바뀔 것이며, 새로운 기회와 재미가 생길 것임.
ChatGPT 등 LLM의 현재 활용 사례는 전체 가능성의 일부에 불과함.
웹이 1996년에 보여준 모습만으로 2010년의 웹을 상상하기 어려웠던 것처럼, LLM의 미래도 지금은 상상하기 어려움.
LLM을 공부하면 변화에 더 잘 적응할 수 있고, 더 재미있게 일할 수 있음.
LLM 활용은 단순한 채팅을 넘어 다양한 방식으로 확장될 수 있음.
도메인 전문가와 협업이 중요하며, 이는 DDD(도메인 주도 설계)의 원칙과도 맞닿아 있음.
LLM은 복잡한 도메인을 다루는 데 적합한 도구가 될 수 있음.
LLM을 활용한 게임 대화 예시:
단순히 "너는 해적이다"라고 프롬프트를 주면, 시대와 맞지 않는 대답(예: AI 스타트업 이야기)이 나올 수 있음.
대화의 일관성과 설정을 유지하려면, 프롬프트를 분리해서 설계하는 것이 효과적임(예: 하나는 설정 체크, 하나는 대사 생성).
예시: "이 대사가 해적 이야기 설정에 맞는가?"를 별도로 체크하도록 프롬프트를 분리함.
LLM의 응답을 게임 로직에 활용할 때, "true/false" 등 구조화된 결과를 받아서 사용할 수 있음.
LLM 기반 컴포넌트와 기존 소프트웨어 컴포넌트를 조합하는 방식이 유용함.
실제로는 해적 게임 대신 경찰 인터뷰 게임을 개발함:
증인을 설득해 정보를 얻는 게임으로, LLM이 대화의 위협 정도를 평가함.
여러 프롬프트를 조합해 게임의 흐름을 제어함.
LLM의 예측 불확실성을 기존 소프트웨어의 규칙과 결합해 활용함.
Retrieval-Augmented Generation(검색 기반 생성) 등 최신 LLM 활용 기법도 소개됨.
LLM을 기존 소프트웨어와 결합해 사용하는 것이 앞으로의 주요 패턴이 될 것임.
복잡한 케이스는 LLM이, 단순한 케이스는 기존 로직이 처리하는 식으로 역할을 분담할 수 있음.
이런 조합의 최적화는 오랜 시행착오를 통해 발전할 것임.
설계 원칙(Separation of Concerns, 관심사의 분리)이 LLM 프롬프트 설계에도 적용됨.
파인튜닝은 기존 LLM의 일부를 수정해 특정 목적에 맞게 성능을 높이는 방법임.
예시: 작은 모델(66M 파라미터)에 의도 분류 기능을 추가함.
"프랑스의 수도는?" → 정보 요청
"프랑스로 비행기 예약하고 싶다" → 행동 요청
데이터셋 라벨링 과정에서 LLM과 사람이 모두 완벽하지 않음을 경험함.
분류 체계(카테고리)가 명확해야 좋은 성능을 얻을 수 있음.
실제 데이터는 예시로 만든 데이터와 달리 예외가 많아, 도메인 전문가의 구체적 예시가 중요함.
ChatGPT 등 LLM을 활용해 분류 체계 설계와 라벨링을 보완할 수 있음.
파인튜닝 과정에서 데이터의 편향(예: 긴 텍스트=프롬프트로 오인) 등 함정도 경험함.
이미 유사한 프로젝트가 존재해도, 직접 실습하며 배우는 과정이 중요함.
LLM의 내부 동작 원리를 이해하기 위해 수학(선형대수 등) 공부가 필요할 수 있음.
하지만 반드시 수학적 원리를 깊이 알 필요는 없으며, 다양한 학습 경로가 존재함.
ChatGPT 등 LLM 자체를 활용해 코드 작성, 버그 수정, 라이브러리 추천 등 실습에 도움을 받을 수 있음.
앞으로의 소프트웨어는 LLM과 기존 소프트웨어가 혼합된 형태가 될 가능성이 높음.
LLM을 도메인 언어(ubiquitous language)로 활용하거나, 특정 도메인에 맞게 파인튜닝하는 방식이 유망함.
LLM의 개념(예: bounded context, 경계된 맥락)이 DDD의 개념과 유사하게 적용될 수 있음.
DDD의 핵심은 복잡한 도메인 모델링과 언어, 그리고 도메인 전문가와의 협업임.
LLM이 도메인 전문가 역할을 일부 대체하거나 보완할 수 있음.
앞으로 어떤 방식이 효과적일지는 실험과 시간이 필요함.
미래를 예측하는 것보다, 계속 배우고 실험하는 자세가 중요함.
지금 배우는 것이 1~2년 후에는 쓸모없어질 수도 있지만, 실험을 통해 얻는 경험이 더 중요함.
실제 프로젝트와 실험 결과를 커뮤니티와 공유해야 더 큰 발전이 가능함.
지금은 LLM과 AI가 매우 흥미로운 시기이므로, 적극적으로 시도하고 즐기는 것이 중요함.
모르는 것을 인정하고, 열린 자세로 준비하는 것이 바람직함.
DDD와 AI의 결합 사례를 만들어 공유하는 것도 권장함.
결론: 지금은 실험과 학습, 그리고 커뮤니티와의 공유가 가장 중요한 시기임.