"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

 

전 세계가 빠져있는 AI 열풍에서도 가장 큰 비중을 차지하고 있는 것이 바로 Software Development 분야이고,

그러한 AI 코딩 분야에서도 최근 가장 핫한 키워드가 바로 "바이브 코딩(Vibe Coding)"이다.

 

그리고, 이러한 열풍에 발맞춰서 뉴스에서 계속 언급되고 있는 것이

"소프트웨어 개발자의 해고", "취업난" 이다.

 

AI의 엄청난 발전에 따라 개발자들도 변화를 해야 한다.

바로 그 이야기를 이 책 "바이브 코딩 너머 개발자 생존법"에서 말하고 있다.

 

 

그렇다.

지금 개발자는 "생존법"에 대해서 고민을 해야하는 시기인 것이다.

 

살아 남아야 한다.

 

 

출간한지 얼마 안된 따끈따끈한 책이다.

 

 

지은이 "에디 오스마니(Addy Osmani)"는 구글에서 크롬 웹브라우저, 제미나이 개발을 하고 있는

25년차 이상의 시니어 개발자이자 리더로써 많은 책을 낸 나름 유명한 분이다.

 

최근 "무엇이 1등 팀을 만드는가?"라는 책도 한빛미디어에서 번역되어 출간했었는데.

그 때 "기민함(Agility)"을 상당히 강조를 했었었다.

 

에디 오스마니가 말하는 기민함이란

단순히 빠른 것만 말하는 것이 아니라, 변화하는 환경에서 효과적으로 적응하고 대응하는 사고방식을 말했었다.

 

그 연장선에서 바로 이 책에서 말하고자 하는 내용이 있는 것이 아닐까 생각해본다.

 

 

이 책은 크게 3개의 파트로 구성이 되어 있다.

 

PART 1 에서는 일단 바이브 코딩에 대해서 알아본다.

 

 

PART 2 에서는 실무에서 AI를 어떻게 사용해야 하는지에 대해서 말하고 있다.

 

 

PART 3 에서는 AI이기 때문에 발생하는 보안을 포함한 신뢰와 자율성에 대해서 이야기 하고 있다.

 

 

바이브 코딩에 대해서 이야기 하는 책이고,

챕터들을 봐도 상당히 기술적인 이야기를 하고 있는 것으로 보이지만,

 

사실 공부하듯이 봐야 하는 기술 서적으로 분류해야 하기 보다는

그냥 주우욱~ 읽어가는 일종의 개발 인문 서적으로 보는 것이 맞지 않을까 한다.

 

 

AI 시대에서 개발자로 어떻게 살아가야할지 조금이라도 고민을 하는 분들이라면

한 번 쯤 읽어보면 좋을 IT 교양 서적으로 추천하고 싶다.

반응형

 

좋은 기회가 되어서 정말 간만에 길벗출판사의 도서를 리뷰하게 되었다.

 

개인적으로 좀 바쁜 시기였음에도 불구하고, 도저히 피할 수 없는 너무나 매력적인 조건들이라 리뷰 신청을 하지 않을 수 없었다.

- 최근 진행하고 있는 스터디에서 트랜스포머를 건드려보고 있는데, 직접 만들어보는 GPT 라니 !!!

- 개인적으로 공부할 때 가장 좋아하는 스크래치 부터 직접 구현해보는 방식이다 !!!

- 원서의 출처가 MANNING 이라면.... 최소한 기본 이상은 될거라는 믿음이 있다 !!!

- 소스코드 구현도 PyTorch 기반으로 했다. 와우 !!!

- 내가 너무나 추종하는 박해선님이 옮긴이로 참여한 책이다 !!! 우와 !!!

- 박해선님이 참여했다면 ... 하나 하나 꼼꼼하게 다시 만들어 주시는 샘플 코드들이 기대되고 ... !!!

- 박해선님이 참여했다면 ... 혹시 동영상 강의도 기대를 ?! ?!

 

 

표지를 보곤 출간한지 좀 오래된 책인 것 같은 느낌이 들었지만,

원서 "Build a Large Language Model (From Scratch)"를 살펴보니 24년 10월 29일에 출간되었다.

 

음... 그냥 교과서 같은 느낌의 표지 디자인이라고 생각해야겠다! ㅋㅋ

 

 

개인적으로 열렬한 팬심을 갖고 있는 박해선님의 책이라 무조건 믿음 이다 !!! ^^

 

저자인 '세바스찬 라시카'의 그동안의 저서들과 이번 책을 봤을 때 교과서 스타일을 좋아하는 것으로 보이기에

박해선님의 스타일과 너무 잘 맞는, 말 그대로 찰떡궁합인 것 같다.

 

 

원서가 출간된지 거의 1년만에 번역본이 출간된 것이다보니 AI 시대에 있어서 1년이라는 시간이 살짝 걱정되지만

최근 LLM의 근간이 되는 그 뿌리에 대한 내용이기도 하고,

코드에 있어서의 문제는 박해선님이 충분히 그 간극을 매꿔주시고 부족한 것은 보충해주셨을 것이라 문제 없을 것이다.

 

 

LLM 관련 샘플 코드들의 경우 라이브러리 버전 맞추기라던지, GPU 리소스의 문제가 있기 때문에

종종 Colab에서만 실행 가능하거나, 실습 환경 구축하는 것에 많은 제약이 있기도 하는데

친절하게도 일반적인 환경에서도 실습 가능하도록 세심히 배려해주셨다.

 

소스코드는 아래 링크와 같이 박해선님의 저장소에서 찾아볼 수 있다.

https://github.com/rickiepark/llm-from-scratch

 

 

이 책은 표지뿐만 아니라 챕터 구성이나 그 내용, 심지어 목차의 타이틀만 봐도 "교과서"의 냄새가 많이 난다.

나쁜 의미가 아니라 LLM에 대해서 공부하는 사람에게는 너무나 좋은 너무나 충실한 책이라는 의미이다.

 

 

개인적으로 풀컬러 책을 좋아하기에 조금 아쉽기는 하지만,

그래도 흑백으로만 하지는 않고, 주황색으로 포인트를 주었다.

 

 

이 책은 부록이 살짝 숨어있다.

책의 뒷 부분을 보면 "워크북"이 분리가 된다.

 

 

그렇다 !!! 이 책은 정말 교과서 였던 것이다 !!!

책을 잘 공부했는지 연습문제도 제공을 해준다 !!!

 

음... 문제의 퀄리티가 엄청 고급스럽지는 않은 것 같은데,

그래도 제대로 공부했는지 확인하는 용도로는 충분히 괜찮은 것 같다.

 

 

혹시나, 하고 찾아봤는데

역시나 박해선님은 나의 기대를 져버리지 않고 동영상 강의를 제공해주셨다.

https://www.youtube.com/playlist?list=PLJN246lAkhQhgakhcxz-5GwG_NYuJgSv1

 

 

교과서 책이라서 그러신 것인지, 별도 강의도 운영을 하신다. (이것은 물론 유료 강의이다 ^^)

http://www.inflearn.com/course/lt밑바닥부터-만들면서-배우는-llm-1

 

 

 

아! 그리고, 현재 이 책의 경우 아직 초판이기에 정오표 확인이 정말 중요하다.

https://tensorflow.blog/llm-from-scratch/

 

 

오타도 물론 있지만, 소스코드 부분에 있어서 생각보다 많은 부분의 정오표가 기록되어 있다.

공부할 때 빼놓지 말고 필독 !!!

 

 

 

이 책을 보면 설명도 정말 잘 되어있고 그림으로 설명하는 부분도 정말 세심하게 많이 신경써서 표현된 것을 알 수 있다.

 

하지만, 조금 아쉬운 점은 지나친 한글화 작업이다.

뭔가 의도하신 바가 있으셔서 그렇게 하셨을 것이라 생각은 하지만,

공부하는 입장에서 지나친 한글화는 오히려 더 햇갈리거나 나중에 더 어려움을 느끼게 된다.

 

예를 들어, "layer normalization" 같은 경우 "층 정규화"라고 사용하는 것이 크게 어색하지는 않은데

"causal attention" 같은 경우 "코잘 어텐션"이라고 한글로 사용을 하게 되면 상당히 많이 어색하다.

 

구글에서 "코잘 어텐션"이라고 검색해도 잘 나오지도 않는다.

오히려 "인과적 어텐션"이라고 검색하는 것이 더 많은 결과가 나온다.

 

아직 대중화(?)되지 않은 용어의 경우에는 그냥 본래 단어(영어)로 표현하는 것이 더 좋지 않을까 생각해본다.

 

(하지만, 미천한 내가 알지 못하는 이유가 있을 거라는 생각은 한다. 셀프 어텐션과 뭔가 pair가 되어야 한다거나 하는...)

 

 

마지막으로 이 책에 대해서 총편을 해보자면,

LLM을 공부하고자 하는 사람이라면 교과서로 생각하고 무조건 구매해서 꼼꼼하게 공부해야 하는 책이다 !!!

반응형

파이썬을 이용해서 개발을 하려다 보면

Python Version + Python Package 관리 때문에 마음 고생할 때가 종종 발생한다.

 

특히, 동시에 여러 프로젝트를 하려다보면

A 프로젝트는 Python 3.12 환경에 PyTorch 관련 패키지들이 필요하고

B 프로젝트는 Python 3.14 환경에 FastAPI 관련 패키지가 필요하는 등...

서로 다른 환경이 필요한 경우가 있다.

 

이런 것을 섞어서 하려다보면 많은 문제가 발생할 수 있기에

각 프로젝트마다 독립적인 개발환경을 제공해주기 위한 가장 아름다운 방법이

바로 파이썬 가상 환경이다.

 

 

▶ Virtual Environment

- 독립적인 파이썬 환경
  . 각 프로젝트에 필요한 파이썬 버전과 라이브러리 관리 가능
- 시스템(호스트) 파이썬과 분리
  . 시스템에 설치된 파이썬 환경을 변경하지 않고 개발 환경 구성
- 디렉토리 기반으로 가상 환경 구성

 

 

운영체제 전체에 기본적인 환경이 있겠지만,

내가 작업하는 디렉토리 + 하위 디렉토리만을 위한 독립적인 개발환경을 구성하는 것이다.

 

 

▶ Tools

- Python 생태계는 패키지 관리, 버전 관리, 가상환경 관리, 빌드 도구 등이 파편화되어 혼란스럽다는 평가를 받고 있음
- 가상환경 관련 도구의 경우 패키지 관리 도구와 같이 pair로 구성되는 경우가 많고, Python 버전 관리는 명확치 않음

 

 

파이썬 패키지 관리 도구라던지 파이썬 버전 관리 도구는 정말 다양하게 있다.

 

물론 개발자들의 사랑을 받는 유명한 도구들이 있긴 하지만,

문제는 그 유명한 도구들이 여러개 존재하기 때문에 혼란스러운 것은 여전하다.

 

 

그러던 중, 이런 춘추전국 시대에 밝은 빛을 비춰주는 존재가 등장했으니 !!!

아름다운 "uv"라는 도구가 ... (다음 기회에~^^)

반응형

C/C++에서 include를 하듯이, Python에서는 import를 한다.

 

Python의 매력은 언어 자체에만 있는 것이 아니라,

필요하다고 생각하는 것은 거의 다 존재하는... 정말 다양하고 멋진 패키지들이 있기 때문이다.

 

그런 패키지들은 어디에 저장이 되어있을까?!

 

 

▶ PyPI (Python Package Index)

repository of software for the Python programming language
Python package: collection of related code modules (files) bundled with metadata describing
                                how the package should be installed and used.

 

https://pypi.org/

 

 

▶ pip (package installer for Python)

- standard tool to install packages from PyPI
- The most popular tool for installing Python packages

 

https://pip.pypa.io/en/stable/

 

 

Python을 공부하면 알 수 밖에 없는 명령어가 바로 pip 이다.

Python을 설치하면 기본적으로 같이 설치되기 때문에 접근성에 있어서도 문제가 없다.

 

그래서 가끔 파이썬 패키지는 무조건 pip를 통해서만 설치해야 하는 줄 아는 사람도 있는데,

위 설명에서도 나오지만, pip는 그냥 "popular tool" 이다 !!!

 

파이썬 패키지 설치를 위한 도구는 pip 외에도 더 있다.

특히, 최근에는 "uv"라는 도구가 엄청난 인기를 얻고 있다.

 

다른 패키지 설치 도구들도 천천히 알아보도록 하겠다.

반응형

IntelliJ로 유명한 젯브레인(JetBrains)에서

25년 8월에 발표한 "The State of Python 2025)라는 보고서(설문조사)를 살펴보면

상당히 다양한 버전의 Python이 사용되고 있다는 것을 알 수 있다.

 

 

많은 사용자(15%)가 3.13 버전 이상의 최신 Python 버전을 사용하고 있지만,
1년 이상 오래된 버전을 사용하고 있을 가능성이 훨씬 더 높다(83%).

그런데, 이렇게 오래된 버전의 Python을 사용해도 괜찮은걸까?

 

 

▶ Status of Python versions (2025.10.25 기준)

- 가끔 아직도 2.x 버전 Python을 사용하는 경우를 최근에도 보는데, 보안을 생각하면 정말 위험한 선택이다

- 문제는 이제는 3.9 버전 이하도 모두 보안 패치도 끝난 end-of-life 버전이라는 것이다.

 

 

 

▶ Supported versions (2025.10.25 기준)

- 현재 시작하는 프로젝트라면 최소한 3.10 버전 이상을 사용해야 하고

  가급적이면 3.12 버전 이상을 사용하는 것이 그나마 조금 안전한 선택이지 않을까 한다.

 

 

 

▶ Release Compatibility Matrix (w/ PyTorch)

- support 기간 뿐만 아니라 호환성도 고려하면서 버전을 선택해야 한다.

- 사용하고자 하는 PyTorch 버전에 따라서 호환되는 Python 버전이 따로 있다.

 

 

 

▶ Python Downloads

- Python 설치를 위한 다운로드 페이지를 보면 다양한 버전과 배포판을 볼 수 있다.

 

 

 

안정성 등을 고려해서 최신 버전을 기피하는 개발자가 많은데,

최근 버전의 Python을 선택하면 성능에서도 많은 장점이 있고 유용한 여러 feature들이 있으니 한 번 고려해보기 바란다.

 

 

[ 출처/참고 ]

- https://blog.jetbrains.com/pycharm/2025/08/the-state-of-python-2025/ 

- https://devguide.python.org/versions/

- https://github.com/pytorch/pytorch/blob/main/RELEASE.md#release-compatibility-matrix

- https://www.python.org/downloads/

반응형

파이썬을 사용하다 보면 종종 만나는 단어가 바로 "PEP"이다.

특히, 코딩 스타일 관련해서 매번 만나는 "PEP 8" 규칙.

 

과연, PEP가 뭐길래?

 

▶ PEP Created

- 1990년대 후반 CNRI에 있던 Barry Warsaw(배리 워쇼우)가 많은 제안들을 Guido가 살펴볼 수 있도록 프로세스 도입
- RFC(Request for Comments, 인터넷 기술 및 표준에 관한 문서) 프로세스를 참조하여 (제안 → 토론 → 결론) 체계 수립

 

다양하게 파생된 '-EP' 문서들

 

 

▶ PEP 0 - Index of Python Enhancement Proposals (PEPs)

- PEPs로 알려진 모든 PEP 목록을 살펴볼 수 있게 제공해준다.
- 다양한 기준으로 PEP 목록을 제공해준다.

 

 

 

 

▶ PEP 8 – Style Guide for Python Code

- 파이썬 답게 코드를 작성하기 (Pythonic Code)

- PEP 중에서 가장 유명하고, 필독해야 하는 문서

- 들여쓰기는 4개의 공백(space)을 사용해야 한다는 것과 같은 코드 스타일 가이드 이다.

 

 

 

▶ PEP 572 – Assignment Expressions

- Guido를 독재자에서 사임하게 만들었던 문제의 그 PEP

- 일명 바다코끼리 연산자(walrus operator) ":=" 도입
  . 할당 표현식(assignment expression)
  . Python 3.8에 포함

- Guido가 제안한 내용이고 도입을 하자는 입장이었고, 커뮤니티는 파이썬 답지 않고, 간결성을 해친다며 반대

- 결국은 승인되어 파이썬 3.8에 도입되었지만, Guido는 BDFL 모델을 내려놓게 되었고

  이후 "The Steering Council Model"을 통해 의사결정 하기로 함 (PEP 8016)

 

 

 

▶ PEP 20 – The Zen of Python

- 파이썬의 선 (파이썬이 추구하는 철학)

 

아름다운 것이 못생긴 것보다 좋습니다.
명시적인 것이 암시적인 것보다 좋습니다.
단순한 것이 복잡한 것보다 좋습니다.
복합적인 것이 복잡한 것보다 좋습니다.
납작한 것이 중첩된 것보다 좋습니다.
흩뿌려진 것이 모인 것보다 좋습니다.
가독성은 중요합니다.
특별한 상황이, 규칙을 깰 만큼 특별하단 얘기는 아닙니다.
실용성이 순수함을 이길 때까지는 말이죠.
에러는 조용히 넘어가서는 안됩니다.
명시적으로 조용히 만들지 않는 한.
모호한 상황이라면, 추측하려 하지 마세요.
문제를 풀 수 있는 (바람직하고 유일한) 분명한 방법이 있어야 합니다.
하지만 네덜란드 인이 아닌 이상 처음에는 분명하지 않을 수 있습니다.
지금 하는 게 하지 않는 것보단 좋습니다.
하지만 지금 당장 하는 것보다 안 하는 게 나을 때도 있습니다.
구현 방식이 설명하기 어렵다면, 그것은 좋지 않은 생각입니다.
구현 방식이 설명하기 쉽다면, 그것은 아마 좋은 생각일 겁니다.
Namespaces는 쩌는 생각입니다. 더욱 이런 것들을 해봅시다!

 

※ 중간에 네덜란드 사람이라고 지칭하는 이유는... 귀도가 네덜란드 사람이라서이다 ^^

 

 

 

[ 참조/참고 ]

- Python PEP, 태어나 세계로 퍼진 ‘○EP’ 이야기: https://news.hada.io/topic?id=21031 
- Paul Everitt, "Python 1994", PyBay2017: https://www.youtube.com/watch?v=7NrPCsH0mBU&t=1662s 
- PEPs & Co.: https://hugovk.dev/blog/2025/peps-and-co/ 

- PEP 0: https://peps.python.org/pep-0000/ 

- PEP 8: https://peps.python.org/pep-0008/ 

- PEP 572: https://peps.python.org/pep-0572/ 

- PEP 20: https://peps.python.org/pep-0020/ 

 

반응형

왠지 갑자기 파이썬을 다시 제대로 공부하고 싶다는 생각에

애초에 어떻게 태어났는지가 궁금해서 공부해보기로 마음 먹었다.

 

ABC

- 이름 자체가 뭔가 엄청나다 ^^

- 1970 ~ 1980년대에 배우기 쉽고, 사용하기 쉬운 언어를 만들기 위해 개발된 프로그래밍 언어 (BASIC 언어 대체로 고안)
- CWI(Centrum voor Wiskunde en Informatica, 네덜란드 국가 수학 및 컴퓨터 과학 연구소)의 프로젝트로 진행
- Leo Geurts(레오 회르츠), Lambert Meertens(람베르트 메르텐스) 및 Steven Pemberton(스티븐 펨버턴) 주도
- Guido van Rossum(귀도 반 로섬)이 1980년대초 구현자로써 참여함

 

생김새를 보면 정말 뭔가 상당히 친숙하다

 

 

 

▶ Python Created

- Guido van Rossum(귀도 반 로섬)은 1986년 CWI에서 Amoeba(아메바)라는 분산 운영체제 프로젝트로 부서 이동
- 1989년 예외 처리 및 확장에 강점을 갖는 ABC 언어와 비슷한 스크립팅 언어 개발 착수
- 1991년 2월, 유즈넷에 공개 (그 전에는 Amoeba 프로젝트에 적용하면서 계속 개발)

 

진짜 개발자가 명품을 만드는 것은, 보통 휴가 때 이루어지곤 한다 … (뭔가 현타가....)

 

 

 

▶ Guido Van Rossum

- 파이썬의 아버지이자 엄마, 시조새, 창조자, 신 !!!

- CWI, NIST, CNRI 같은 여러 연구 기관에서 근무
- 2000년 5월 기술 스타트업 BeOpen.com → 10월 파산
- 2000년 말 ~ 2003년 Zope Corporation 근무 (파이썬 기반 웹 어플 서버/커뮤니티)
- 2003년 ~ 2005년 Elemental Security (회사 맞춤형 프로그래밍 언어 개발)
- 2005년 ~ 2012년 Google (50% 파이썬 언어 개발, 사내 개발 도구 개발)
- 2013년 ~ 2019년 DropBox (클라우드 스토리지)
- 은퇴 선언 → 은퇴 번복
- 2020년 ~ Microsoft 개발 부서, 현재 명예 엔지니어 직책

 

2006년 OSCON

 

 

2024년 PyCon

 

 

▶ MISC

- Python 어원: Monty Python's Flying Circus(몬티 파이튼의 비행 서커스)
  . BBC에서 1969년~1974년 방영된 스케치 코미디 TV 쇼
  . Monty Python: 영국 코미디 그룹으로 TV쇼 및 영화, 극장 공연 등 다양한 활동
- 자비로운 종신독재자(BDFL, Benevolent Dictator for Life)
  . 커뮤니티 논쟁이 있을 때 최종 결론을 내려줄 수 있는 역할로 소수의 오픈소스 개발 리더에게 부여
  . 1995년 Python 창시자 Guido Van Rossum 호칭으로 처음 사용됨
  . 2018년 7월 12일 BDFL에서 사임한다고 Guido Van Rossum이 선언
   →  PEP(Python Enhancement Proposal) 572 개선 제안 논란 이슈로 사임

 

Monty Python

 

 

 

[ 참고/출처 ]

- ABC 공식홈페이지: https://homepages.cwi.nl/~steven/abc/ 

- Python Doc: https://docs.python.org/3/faq/general.html#why-was-python-created-in-the-first-place 

- Wikipedia: https://ko.wikipedia.org/wiki/귀도_반_로섬

- Monty Python: https://ko.wikipedia.org/wiki/몬티_파이튼

- BDFL, Benevolent Dictator for Life: https://ko.wikipedia.org/wiki/자비로운_종신독재자

- BDFL 사임: https://www.cio.com/article/3532595/파이썬-창시자가-말하는-사임-이유와-파이썬의-미래.html

- https://www.cinematerial.com/tv/monty-pythons-flying-circus-i63929/p/ani1bnus 

 

반응형

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

 

 

LLM을 현업에서 사용한다고 하면 다들 우려하면서 말하는 것이 바로 "hallucination(환각)" 현상이다.

 

실무에서는 예측 가능한 것이 중요하고, 정확한 것이 중요한데

LLM 특성상 확률로 결정되는 부분들이 있기에 예상을 벗어난 답변을 할 수도 있고

정확하지 않은 것을 사실인 것 처럼 말할 수도 있는 것이다.

 

LLM 자체가 확률을 기반으로 하기에 "hallucination(환각)"을 완전히 없앨 수는 없겠지만

어떻게 하면 줄일 수 있는지 그 방법을 배워야만 하는 것이다.

 

 

"프롬프트 엔지니어링"이라는 제목을 보고

처음에는 ChatGPT와 같은 웹 화면에서 프롬프팅을 하는 것을 예상했는데,

 

이 책은 표지에 hint가 있는 것처럼 LLM API를 사용하는 과정에서의

프롬프트 엔지니어링을 설명해주고 있다.

 

그리고 고맙게도 OpenAI API 뿐만 아니라 Gemini API까지 같이 언급해주고 있어서 실습을 할 때에 마음이 편했다.

 

사실 공부하면서 API 사용하는 것 정도는 커피값 정도 밖에 안되기에 객관적으로는 별 부담이 아닌데

희한하게 OpenAI API 사용하다보면 뭔가 엄청 부담스럽다(나만 그런가!? ^^).

 

소심한 나로써는 우리 구글님께서 제공해주는 Gemini API를 사용하는 것도 챙겨준 저자가 참 고맙다. 

 

 

책에서 추천하는 실습 환경은 "Colab + OpenAI API" 이기 때문에,

사전에 어느 정도 파이썬 프로그래밍에 대해서는 경험해본 사람을 추천한다.

 

처음에 좀 당황스러운 것은 구글 드라이브 주소를 하나씩 타이핑을 해야하는.... 그래서 나는 친절하게 링크를 !!!

- https://drive.google.com/drive/folders/12-NIX1ks8o5bMzCTGRrkE1GphwTq6K3A

 

 

GitHub 주소도 같이 링크를 남겨본다.

- https://github.com/KennethanCeyer/robust-prompting-notebooks

 

 

실제 노트북 코드를 보면 아래와 같다.

 

 

실제 돌려보면 아래와 같이 잘 나온다.

 

 

현업 업무에서 AI Agent 또는 챗봇 같은 것을 개발하다보면

주어진 상황이나 또는 RAG 데이터에 기반해서 정답을 찾아야 하는데

전혀 다른 소리를 하거나 아니면 일반적인 상황에 대한 답변을 하는 경우가 상당히 자주 발생을 한다.

 

이런 것을 컨트롤할 다양한 방법들을 시도해볼 수 있지만,

프롬프트 엔지니어링이 상당히 중요한 부분이면서 가장 강력한 솔루션이 될 수 있다.

 

그리고 그러한 프롬프트 엔지니어링을 배울 수 있는 좋은 책이 바로 여기 있다.

 

"할루시네이션을 줄여주는 프롬프트 엔지니어링"

 

반응형

+ Recent posts