나에게 필요한 지식과 기술을 검색해 보세요.

핸즈온 바이브 코딩: 패키지

기획부터 배포까지 실무 성장 지금 시작!

실무 전 과정을 담은 올인원 패키지

O'Reilly가 선택한 강의

Packt 시리즈로 최신 기술을 가장 빠르게

세계와 함께 배우는 실무 스킬, Packt 시리즈

업스테이지 X 한빛+

대한민국이 선택한 AI 기술을 경험해보세요

실무 중심 AI 강의를 무료 또는 특별가로 만나보세요

정지훈의 양자 컴퓨터 강의

기초부터 글로벌 전략과 투자 포인트까지 한 권에!

AI 다음 시대의 게임 체인저, 양자 컴퓨터를 만나다!

이것이 Spring AI다

텍스트 및 음성 대화에서 MCP Server까지

생성형 AI 시대의 Java 개발자를 위한 완벽한 가이드!

0/0

한빛+ 강의

핸즈온 바이브 코딩: 패키지

HOT

핸즈온 바이브 코딩: 패키지

정개발(정도현)
실전 예제로 다지는 머신러닝&딥러닝 with 파이썬(AI 기초편)

HOT

실전 예제로 다지는 머신러닝&딥러닝 with 파이썬(AI 기초편)

김진희
IT북토크 2025

IT북토크 2025

박해선, 김정욱, 박조은외 1인
소셜 미디어를 위한 노코드 AI 에이전트

소셜 미디어를 위한 노코드 AI 에이전트

클라리안 노스
미래를 준비하는 이들을 위한 AI와 양자 컴퓨팅의 기초

미래를 준비하는 이들을 위한 AI와 양자 컴퓨팅의 기초

비비안 아라나
이것이 오라클이다

이것이 오라클이다

우재남
핸즈온 바이브 코딩: 백엔드

핸즈온 바이브 코딩: 백엔드

정개발(정도현)
랭체인코리아 밋업 2025 Q2

랭체인코리아 밋업 2025 Q2

테디노트(이경록), 김태영, 우성우

새로나온책

누구나 아는 나만 모르는 챗GPT

누구나 아는 나만 모르는 챗GPT

이성원(누나IT)
소문난 명강의 크리핵티브의 한 권으로 끝내는 웹 해킹 바이블

소문난 명강의 크리핵티브의 한 권으로 끝내는 웹 해킹 바이블

하동민
AI 엔지니어링

AI 엔지니어링

칩 후옌, 변성윤
할루시네이션을 줄여주는 프롬프트 엔지니어링

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

한성민
플러터 엔지니어링

플러터 엔지니어링

마지드 하지안, 한국 플러터 커뮤니티
AI 프로덕트 기획과 운영

AI 프로덕트 기획과 운영

오성근, 마릴리 니카, 오용철
프런트엔드 레벨을 높이는 자바스크립트 퀴즈북

프런트엔드 레벨을 높이는 자바스크립트 퀴즈북

엄서영, 김지원, 백종현외 4인
한 권으로 끝내는 회계원리 문제 풀이집

한 권으로 끝내는 회계원리 문제 풀이집

김선미, 임영제, 신영직외 2인
헤드 퍼스트 소프트웨어 아키텍처

헤드 퍼스트 소프트웨어 아키텍처

닐 포드, 유동환, 라주 간디외 2인
밑바닥부터 시작하는 웹 브라우저

밑바닥부터 시작하는 웹 브라우저

파벨 판체카, 크리스 해럴슨, 이형욱외 1인
스프링 6 레시피(5판)

스프링 6 레시피(5판)

다니엘 루비오, 조시 롱, 마틴 데이넘외 5인
실무로 통하는 웹 API

실무로 통하는 웹 API

김태곤, 조 아타디
한 권으로 끝내는 회계원리

한 권으로 끝내는 회계원리

김선미, 임영제, 신영직외 2인
정지훈의 양자 컴퓨터 강의

정지훈의 양자 컴퓨터 강의

정지훈
이것이 Spring AI다

이것이 Spring AI다

신용권
요즘 교사를 위한 AI 디지털 수업 설계 가이드 with 2022 개정 교육과정

요즘 교사를 위한 AI 디지털 수업 설계 가이드 with 2022 개정 교육과정

김진관, 김상섭, 이대형외 2인
회사에서 바로 통하는 실무 엑셀 파워포인트 워드 한글(전면 개정판)

회사에서 바로 통하는 실무 엑셀 파워포인트 워드 한글(전면 개정판)

신면철, 전미진, 이화진
회사에서 바로 통하는 오토캐드 AutoCAD 2026

회사에서 바로 통하는 오토캐드 AutoCAD 2026

심미현
요즘 개발자, 채널.H에서 먼저 보고 갑니다.

요즘 개발자, 채널.H에서 먼저 보고 갑니다.

실무에 바로 적용 가능한 기술 콘텐츠, 전문가 작가들의 인사이트 칼럼

핸즈온 바이브 코딩! 프론트엔드부터 보안까지 완전 정복하기

핸즈온 바이브 코딩! 프론트엔드부터 보안까지 완전 정복하기

AWS 테크니컬 트레이너 출신 강사가 직접 안내하는 실전 핸즈온 바이브 코딩

한빛+의 지식 파트너가 되어주세요.

한빛+의 지식 파트너가 되어주세요.

한빛+에서 지식 파트너가 되어 줄 강사님 & 연사님을 모십니다.

0/0

채널.H

AI 다음은 ‘이것’이다! 입문부터 심화까지, 지금 읽어야 할 양자 컴퓨터 도서 3종

AI 다음은 ‘이것’이다! 입문부터 심화까지, 지금 읽어야 할 양자 컴퓨터 도서 3종

“양자 컴퓨터로 흥미로운 문제를 풀 시대가 성큼 다가왔다. 가슴 뛰는 순간이다.”— 젠슨 황, 엔비디아 CEO 올해 초 열린 엔비디아 GTC 2025 컨퍼런스에서는 처음으로 양자의 날(Quantum Day) 행사가 마련되었습니다. 행사의 사회를 맡은 엔비디아 CEO 젠슨 황은 업계 주요 인사들을 초청해, 양자 컴퓨팅이 열어갈 미래에 대해 깊이 있는 논의를 이끌었습니다. 세계적 리더들이 직접 참여해 비전을 공유할 만큼, 양자 컴퓨터는 지금 기술 산업의 가장 뜨거운 화두입니다. 모두가 입을 모아 말합니다. 미래를 바꿀 새로운 패러다임이 이제서야 나타났다고. 도대체 양자 컴퓨팅은 무엇이길래, 어떤 능력을 지녔기에 전 세계가 이토록 주목하는 걸까요? 이 질문에 대한 답을 찾아 나설 수 있도록 양자 컴퓨터를 고안한 천재가 들려주는 계산 이야기부터 양자 컴퓨터의 개념 실제 구현, 그리고 산업적 전망까지 두루 담은 세 권의 책을 소개합니다. 이번 연휴에는 AI 이후의 미래를 다시 설계할 기술, 양자 컴퓨팅의 세계에 마음 편히 몰입해보는 건 어떨까요? <입문 ~ 초급자를 위한 양자 컴퓨터 추천 도서>구현 기술부터 산업 전략까지, 양자 컴퓨터의 전체 지형을 짚다정지훈의 양자 컴퓨터 강의 『정지훈의 양자 컴퓨터 강의』는 양자를 쉽고, 넓게 배울 수 있는 최고의 입문서입니다. 중첩, 얽힘, 큐비트 같은 양자 컴퓨팅의 핵심 개념을 어려운 수식 없이 비유와 그림으로 풀어내고, 초전도·이온 트랩·중성 원자·광자·위상학적 큐비트 등 5가지 구현 기술의 원리와 장단점을 정리해 양자 컴퓨터의 구조와 흐름을 입체적으로 이해할 수 있도록 구성했습니다. 또한 IBM, 구글, 마이크로소프트, 아마존, 리게티 컴퓨팅, 아이온큐 등 글로벌 기업들의 기술 전략과 양자 경쟁의 판도가 알기 쉽게 정리되어 있어 기술 트렌드를 따라잡고 싶은 독자에게 깊은 인사이트를 선사합니다. 다시 말해, 이 책 한 권이면 기술 트렌드와 산업 흐름, 양자 컴퓨팅의 기초 개념과 구현 방식, 기업 전략은 물론 투자 관점에서 꼭 알아야 할 핵심 포인트까지 한눈에 정리할 수 있습니다. AI 다음 시대가 궁금하다면 이 책에서 그 답을 찾을 수 있습니다. 이제, 미래로 가는 첫걸음을 이 책과 함께 시작해 보시기 바랍니다. ✅ 이런 분께 추천합니다• AI 이후 기술의 흐름을 알고 싶은 분• 양자 컴퓨터를 실용적으로 이해하고 싶은 분• 기술 기반 투자 기회를 찾는 분• 미래 사회를 주도할 역량을 갖추고픈 누구나 <초급~중급자를 위한 양자 컴퓨터 추천 도서> ‘양자’가 두렵지 않은 가장 친절한 도서 | 한국공학한림원 추천 도서모두를 위한 양자 컴퓨터 『모두를 위한 양자 컴퓨터』는 우리가 사용하는 컴퓨터, 즉 전통적인 컴퓨터를 양자 컴퓨팅이라는 낯설고 새로운 미지의 존재와 연관시켜 설명합니다. 우리가 양자 컴퓨터로 '무엇을 할 수 있는지', '앞으로 무엇을 할 수 있을지'에 대한 답을 제시합니다. 또한 양자 컴퓨팅의 발전에 따른 기술 트렌드를 이해하고 새로운 기회를 포착할 수 있도록 정보를 제공하고 있습니다.양자 컴퓨팅에 대한 정보는 뉴스나 온라인에서도 얻을 수 있습니다. 하지만 『모두를 위한 양자 컴퓨터』는 기본 정보를 토대로 전체적인 큰 그림을 그리고, 실무에 양자 컴퓨팅을 도입할 수 있는지 결정하고, 필요하다면 바로 실행에 옮길 수 있는 귀중한 인사이트를 제공할 것입니다. 미래를 바꿀 기술의 최전선인 양자 컴퓨팅을 통해 새로운 가능성을 발견해 보세요! ✅ 이런 분께 추천합니다• 양자 컴퓨팅에 처음 입문하려는 독자• 양자 컴퓨팅이 자신의 직업, 비즈니스 또는 세상을 위해 무엇을 할 수 있는지 궁금한 독자✅주요 구성[1부] 양자 역학 및 전통적인 컴퓨팅 소개[2부] 게이트 기반 양자 컴퓨팅에 사용되는 큐비트 유형[3부] 양자 컴퓨팅 알고리즘, 프로그래밍 및 응용 분야[4부] 양자 컴퓨팅에 대해 알아 두면 좋은 이야기 <중급자~를 위한 양자 컴퓨터 추천 도서> 양자 컴퓨터를 고안한 천재가 들려주는 계산 이야기파인만의 컴퓨터 강의(2판) “과학에 문외한인 사람에게도 우주의 아름다움과 질서를 생생하게 전달하는 설명의 대가” - BBC“전후 세대 이론물리학자 중 가장 뛰어나고, 창조적이며, 영향력 있는 인물” - 뉴욕타임스 세계적인 물리학자이자 노벨 물리학상 수상자인 리처드 파인만의 컴퓨터 과학 강의가 재조명됩니다. 누구나 이해할 수 있게 풀어낸 명쾌한 비유로 가득한 『파인만의 컴퓨터 강의』의 초판 출간 20주년을 맞아 선보이는 2판은 시간이 흘러도 변하지 않는 컴퓨터의 기본 원리부터 구조, 한계, 물리학 그리고 미래까지 살펴봅니다. 특히 최신 연구 성과와 파인만의 통찰을 연결하는 특별 기고문을 추가로 담았습니다. 파인만은 "이해하지 못한 것은 설명할 수 없다"는 철학을 바탕으로 복잡한 이론도 누구나 이해할 수 있도록 쉽게 설명하며, 독자로 하여금 자신의 사고 방식을 돌아보게 만듭니다. 이 책은 컴퓨터라는 주제를 넘어, 빠르게 변화하는 세상을 이해하는 방식을 바꿔줄 ‘생각의 지도’와 같은 책이 될 것입니다. ✅ 이런 분께 추천합니다• 하드웨어 아키텍처·계산 이론의 기초를 탄탄히 다지고 싶은 학부·대학원생• 파인만 특유의 시각으로 컴퓨팅 한계를 물리학적 관점에서 탐구하고 싶은 개발자• 컴퓨터가 어떻게 동작하며 무엇을 할 수 있는지 ‘깊이 있게’ 이해하고 싶은 모든 사람

AI 애플리케이션 개발 흐름을 잡아주는 필독서, 『AI 엔지니어링』번역 후기

AI 애플리케이션 개발 흐름을 잡아주는 필독서, 『AI 엔지니어링』번역 후기

안녕하세요. 칩 후옌의 신작『AI 엔지니어링』을 번역한 변성윤입니다. 번역을 진행하며 느낀 점들을 글로 남기고자 합니다. 저는 그의 전작인『머신러닝 시스템 설계』를 읽고 큰 감명을 받은 바 있습니다. 머신러닝 시스템 설계에 필요한 전반적인 내용을 체계적으로 정리되어 있어 제게도 큰 도움이 되었습니다. 이번에 출간된 『AI 엔지니어링』 역시 전작과 마찬가지로 AI 애플리케이션 개발의 전 과정을 폭넓게 다루고 있습니다. 저는 원서 중 가치가 있는 도서라고 생각하면 출판사에 직접 번역서 출간을 제안하는 방식으로 번역 작업을 진행하는데, 이 책은 특히 많은 분들이 꼭 읽어 보시면 좋겠다고 생각하며 제안하게 된 책입니다. 이번 번역 과정에서 저 또한 잘 알지 못했던 분야를 새롭게 확인할 수 있었고, 동시에 직접 AI 엔지니어링을 더 깊이 경험해 보고 싶다는 생각을 하게 되었습니다. 이 책이 독자 여러분께도 새로운 통찰과 도전의 계기가 되기를 바랍니다. 흐름을 보여주는 책의 힘 저는 개발 서적 가운데 전체적인 흐름을 잘 정리하면서 저자의 원칙이나 경험담을 담은 책을 좋아합니다. 그런 책을 읽다 보면 거시적으로 어떻게 사고해야 하는지 흐름을 잡을 수 있기 때문입니다. 『머신러닝 시스템 설계』, 『견고한 데이터 엔지니어링』등이 그러했고, 이번에 번역한 『AI 엔지니어링』 역시 전체적인 흐름을 잘 설명해 줍니다.특정 프레임워크를 다루는 책은 시간이 흐르면 내용도 바꾸어야 합니다. 하지만 전체적인 흐름을 정리한 책은 시간이 지나도 여전히 도움이 되죠. 이 책을 통해 AI 엔지니어링의 큰 그림을 먼저 익히신 뒤, 자신이 해결하고 싶은 문제를 떠올려 보시기를 권합니다. 그 문제를 해결하는 데 AI가 필요한지 고민해 보고, 필요하다면 직접 구현하면서 필요한 부분을 더 학습해 나가시면 좋겠습니다. 독자별 추천 학습 방법 이제 막 이 분야를 공부하려고 하는 분들은 먼저 이 책을 통해 전체적인 흐름을 잡은 후, AI 애플리케이션을 직접 만들어 보시는 것을 추천합니다. 단순히 책을 보거나 책을 정리하는 수준보다는 간단하게라도 결과물을 꼭 만들었으면 좋겠습니다. 결과물을 만드는 과정에서 직접 체화되고 깨달음이 생길 겁니다. 기존에 이 분야를 어느 정도 하고 계신 분들이라면 책을 읽으며 여러분들이 인지하지 못했던 내용 위주로 파악하는 것을 추천합니다. AI 분야가 넓고, 빠르게 발전하고 있어서 놓치고 있는 부분이 있을 수 있는데 이런 책을 통해 부족한 부분을 파악할 수 있을 겁니다. 저 또한 후자 쪽이라서 책을 계속 읽으며 부족했던 부분을 채울 수 있었습니다. 번역 과정에서 인상 깊었던 세 가지 포인트 이 책을 번역하면서 가장 인상 깊었던 부분은 '완벽한 모델'이 아닌 'AI 애플리케이션을 만드는 전체적인 과정'에 초점이 맞춰져 있다는 점이었습니다. 특히 인상 깊었던 부분은 다음 세 가지입니다. 1) 평가 시스템의 중요성 요즘 AI 프로젝트가 실패하는 이유 중 대표적인 것은 모델 성능이 아니라 제대로 된 평가 체계가 없기 때문에 발생합니다. 이 책은 3장과 4장에서 바로 이 평가를 다룹니다. 우선 3장에서는 평가에 대한 전반적인 접근 방법을 다룹니다. 파운데이션 모델은 하나의 입력에 여러 답변이 나올 수 있는 개방형 특성을 가지고 있어서 전통적인 ML과 비교하면 평가가 더 어렵다는 내용을 제시하며 언어 모델의 평가 지표를 설명합니다. 그 후엔 기능적 정확성과 참조 데이터의 유사도 측정을 통해 평가하는 방법을 제시합니다. 사람이 모든 것을 평가할 수 없기 때문에 AI 평가자(AI as a judge)를 사용하는 방법과 한계점을 제시합니다. 이처럼 어떤 방법을 소개할 때 한계점을 같이 제시해 주는 것은 실무에서 일어날 일을 예측하는 데 도움이 됩니다. 4장에선 AI 애플리케이션을 평가할 때 사용할 수 있는 기준들을 정의하고 계산하는 방법, 적합한 모델을 고르는 과정, 평가 파이프라인을 개발하는 방법을 살펴봅니다. 모델을 고르는 과정에서 자체 개발을 할 것인지, 상용 모델을 구매할 것인지에 대한 내용도 나오는데 실무에서 자주 하는 고민이라 독자분들이 많은 도움을 얻으실 수 있을 겁니다. 다음과 같이 모델 API 사용하기와 모델 자체 호스팅에 대한 장단점을 표로 비교한 내용도 있습니다. 출처:『AI 엔지니어링』p.234 2) AI 애플리케이션을 개발하는 점진적인 과정 소개 AI 애플리케이션의 프로토타입을 만드는 것은 과거에 비해 많이 쉬워졌습니다. 그러나 이 프로토타입을 운영을 할 수준까지 끌어올리려면 여전히 많은 시행 착오가 필요합니다. 책의 마지막 장인 10장에서는 AI 엔지니어링 아키텍처를 간단한 부분부터 시작해 고도화하는 과정을 설명합니다. ‘어떤 순서로, 과정을 거쳐 AI 애플리케이션을 개발해야 할까?’라는 고민이 있는 분들이라면 꼭 보시길 바랍니다. 처음 시작은 질의가 주어지면 모델 API가 답변을 생성해 응답하는 단순한 형태입니다. 이후 과정에서 필요할 때마다 구성 요소를 추가합니다. 예를 들어 컨텍스트를 보강하고, 입력과 출력에서 여러분과 사용자를 보호하기 위해 가드레일을 도입하고, 모델 라우터와 게이트웨이 추가, 지연 시간을 줄이기 위해 캐시 추가, 애플리케이션에 맞는 동작 등을 소개합니다. 출처:『AI 엔지니어링』p.536 이런 형태보다 더 복잡해지면 디버깅이 어려워질 수 있는데, 이때 모니터링에 대한 관점을 소개합니다. 지표 선정, 로그와 트레이스를 보는 관점을 통해 데이터를 어떻게 분석해야 하는지 아이디어를 얻을 수 있습니다. 복잡한 케이스를 다루는 것보다 이런 모니터링 환경을 구축해서 앞으로 실패를 빠르게 파악할 수 있게 해주려는 저자의 노력이 돋보였습니다. 그리고 사용자의 피드백을 받을 수 있는 구조에 대해 설명하는데, 데이터가 중요한 요즘 시대에 꼭 필요한 내용이라 생각합니다. 3) 기준을 잡을 수 있는 질문들 이 책은 AI 애플리케이션을 만드는 다양한 방법을 설명하고, 적합한 해결책을 평가할 수 있는 질문들을 제시합니다. • 이 AI 애플리케이션을 왜 만들어야 할까?• 자신의 애플리케이션을 어떻게 평가할까? AI를 사용해 AI 출력을 평가할 수 있을까?• 환각은 왜 발생할까? 환각을 어떻게 탐지하고 완화할 수 있을까?• 프롬프트 엔지니어링의 모범 사례는 무엇일까?• RAG는 왜 효과가 있을까? RAG를 수행하기 위한 전략은 무엇이 있을까?• 에이전트란 무엇일까? 에이전트를 어떻게 만들고 평가해야 할까?• 모델을 언제 파인튜닝해야 할까? 언제 파인튜닝하지 말아야 할까?• 데이터는 얼마나 필요할까? 데이터 품질은 어떻게 검증해야 할까?• 모델을 더 빠르고, 저렴하고, 안전하게 만들려면 어떻게 해야 할까?• 애플리케이션을 지속적으로 개선하기 위한 피드백 루프는 어떻게 만들까? 이런 질문들을 통해 독자 여러분들의 상황에 맞는 선택을 할 수 있게 됩니다. 개인적으로 왜 이 AI 애플리케이션을 만들어야 할까? 부분에서 감명을 받았습니다. AI가 유행이라서 하는 것이 아니라 애플리케이션이 AI와 만나 어떤 가치를 발휘할 수 있는가를 꼭 고민해야 한다고 생각합니다. 이런 생각을 통해 여러분들의 서비스에 대한 메타인지가 늘어날 수 있을 겁니다. 『AI 엔지니어링』을 통해 여러분들이 AI에 대해 더 익숙해지고, 겪고 있는 고민에 도움이 되었으면 좋겠습니다. 감사합니다. 변성윤AI를 통해 누구나 손쉽게 애플리케이션을 만들 수 있는 시대가 되었습니다. 하지만 신뢰할 수 있는 AI 제품을 만드는 일은 전혀 다른 과제입니다. 최고의 AI 전문가 칩 후옌이 스탠퍼드 강의와 엔비디아, 스노클 AI에서의 경험을 바탕으로 파운데이션 모델을 실제 서비스로 연결하는 체계적인 방법을 제시합니다. 『AI 엔지니어링』은 AI 애플리케이션을 안정적이고 효과적으로 설계하고 운영해야 하는 현업의 고민을 명쾌하게 풀어주는 AI 엔지니어링 실전 가이드입니다. 프롬프트 엔지니어링, RAG, 파인튜닝, 에이전트 설계 같은 최신 기법부터 모델 평가, 추론 최적화, 사용자 피드백을 통한 개선까지 AI 시스템 설계·운영의 전 과정을 현실적인 시각으로 풀어내며, 이론과 실무의 간극을 메워 줍니다. 특히 평가(Evaluation)를 핵심 주제로 다루어, “감”이 아닌 데이터 기반의 의사결정 원칙을 세울 수 있도록 돕습니다. 『머신러닝 시스템 설계』가 그랬듯, 이번 책 역시 빠르게 변하는 AI 생태계 속에서 흔들림 없는 기본기를 다져줄 든든한 교과서가 될 것입니다.

건축으로 이해하는 소프트웨어 아키텍처 | 설계와 아키텍처의 차이점

건축으로 이해하는 소프트웨어 아키텍처 | 설계와 아키텍처의 차이점

소프트웨어 아키텍처를 이해하기 위해 집을 떠올려 보세요. 집의 구조가 바로 아키텍처입니다. 집의 모양, 방의 개수, 층 수, 크기 등이죠. 이런 구조적 요소들은 나중에 변경하기 어렵고, 집에서 가장 중요한 부분입니다. 아키텍처는 집을 짓는 데 필수입니다. 아키텍처 없이 집을 짓는 모습을 상상할 수 있나요? 아마도 못생기고 기능적이지 않은 모양의 집이 나오게 될 것입니다. 소프트웨어도 마찬가지입니다. 확장할 수 없고 유지보수가 어려운 시스템들은 대부분 아키텍처를 충분히 고려하지 않았기 때문입니다. ✅ 건축 계획과 소프트웨어 아키텍처 소프트웨어 시스템의 ‘건축 계획’은 어떤 것일까요? 건축 계획이 집의 구조(방, 벽, 계단)를 정의하는 것처럼, 소프트웨어 아키텍처 다이어그램은 소프트웨어의 구조(사용자 인터페이스, 서비스, 데이터베이스, 통신 프로토콜)를 정의합니다. 둘 다 최종 결과를 가시화하고 개발에 지침을 제공합니다. 중요한 점은 건축 평면도에 바닥재 종류나 벽 색상, 가구 배치 같은 세부사항은 포함되지 않는다는 것입니다. 이런 것들은 구조적 요소가 아니라 설계(디자인) 요소이기 때문입니다. ✅ 소프트웨어 아키텍처의 차원들 우리 주변의 많은 것은 다차원적입니다. 예를 들어, 집에 있는 특정 방을 묘사한다고 생각해봅시다. 아마도 길이는 5미터, 폭은 4미터, 천장 높이는 2.5미터일 것입니다. 방을 정확하게 묘사하기 위해서는 높이, 길이, 너비의 세 가지 차원을 모두 명시해야 함을 주목하세요. 소프트웨어 아키텍처도 마찬가지로 차원을 설명할 수 있습니다. 다만 소프트웨어 아키텍처는 네 개의 차원이 있다는 점이 다릅니다. ① 첫 번째 차원: 아키텍처 특성 아키텍처 특성은 소프트웨어 시스템 아키텍처의 기반을 형성합니다. 이 특성이 없다면 아키텍처 관련 결정을 내리거나 중요한 트레이드오프(trade-offs)*를 분석할 수 없습니다. 두 개의 집 중 하나를 선택한다고 가정해봅시다. 한 집은 넓지만 시끄러운 고속도로 옆에 있고, 다른 집은 조용한 동네에 있지만 훨씬 작습니다. 어떤 특성이 더 중요한가요? 집의 크기가 중요한가요, 아니면 소음과 교통이 중요한가요? 이 기준이 없으면 올바른 선택을 할 수 없습니다. 소프트웨어도 마찬가지입니다. 새로운 데이터베이스를 선택할 때, 고성능 검색이 필요하다면 그래프 데이터베이스를, 데이터 관계 유지가 중요하다면 관계형 데이터베이스를 선택하게 됩니다. *트레이드오프(trade-offs): 두 가지 이상의 선택지나 요소 간의 균형을 맞추기 위해 하나를 선택할 때 다른 하나를 포기해야 하는 상황을 의미합니다. ② 두 번째 차원: 아키텍처 결정 아키텍처 결정은 시스템의 구조적 측면에 관한 선택으로, 장기적으로 중요한 영향을 미칩니다. 이러한 결정들은 제약사항이 되어 개발 팀에게 지침을 제공합니다.집을 짓는다고 가정했을 때 단층으로 짓고 싶은가요, 아니면 2층집을 원하시나요? 지붕은 평평한가요, 아니면 뾰족한가요? 만약 크고 방대한 랜치 하우스를 짓는다면 또 어떨까요? 이러한 결정들은 집의 구조적인 측면에 영향을 미치므로 좋은 아키텍처 결정의 예입니다. 집을 지을 때 단층인지 2층인지, 지붕이 평평한지 뾰족한지 결정하는 것처럼, 소프트웨어에서는 "사용자 인터페이스가 데이터베이스와 직접 통신하지 않고, 서비스를 통해 데이터에 접근한다"는 식의 결정을 내립니다. 이런 결정이 전체 시스템 구조를 결정짓게 됩니다. ③ 세 번째 차원: 논리적 컴포넌트 논리적 컴포넌트는 시스템의 구성 요소로, 집의 방과 같습니다. 주문 결제 처리, 재고 관리, 주문 추적 등의 기능을 수행합니다. 시스템 내에서는 보통 디렉터리나 네임스페이스로 표현됩니다. 예를 들어, app/order/payment는 '결제 처리'라는 논리적 컴포넌트를 나타냅니다. 각 컴포넌트는 명확한 역할과 책임을 가져야 합니다. ④ 네 번째 차원: 아키텍처 스타일 집이 빅토리안, 랜치, 튜더 등의 특정 스타일을 가지는 것처럼, 소프트웨어 시스템도 전반적인 구조와 형태를 정의하는 아키텍처 스타일이 있습니다. 아키텍처 스타일은 각기 다른 고유한 특성들로 소프트웨어 시스템의 전반적인 모습과 구조를 정의합니다. 예를 들어, 마이크로서비스(microservices) 아키텍처 스타일은 확장성이 좋고, 빠르게 변화하는 환경에 대응할 수 있는 높은 수준의 민첩성(agility)을 제공합니다. 반면에 레이어드(layered) 아키텍처 스타일은 덜 복잡하고 비용이 적게 듭니다. 이벤트 기반(event-driven) 아키텍처 스타일은 높은 확장성을 제공하며, 매우 빠르고 응답성이 좋습니다. 아키텍처 스타일은 시스템의 전반적인 특성을 정의하므로 처음부터 올바른 선택을 하는 것이 중요합니다. 랜치 하우스를 짓다가 빅토리안 주택으로 바꾸기 어려운 것처럼, 모놀리식에서 마이크로서비스로 전환하는 것도 상당한 작업이 됩니다. ✅ 아키텍처와 설계는 어떻게 다를까요? 아키텍처는 구조에 중점을 두고, 설계는 외관에 중점을 둡니다. 집으로 예를 들면, 벽면 색상, 가구 배치, 마루 종류는 설계 측면입니다. 반면 방의 크기, 문과 창문의 위치는 아키텍처, 즉 구조적 부분입니다. 비즈니스 애플리케이션에서도 마찬가지입니다. 아키텍처는 웹 페이지가 백엔드 서비스 및 데이터베이스와 통신하는 방식에 관한 것이고, 설계는 각 페이지의 색상, 필드 배치, 설계 패턴 등 외관에 관한 것입니다. 다시 요약하면 ‘구조’냐 ‘외관’이냐의 차이입니다. 때때로 아키텍처와 설계를 구분하는 것이 혼란스러울 수 있기 때문입니다. 이제 이들의 차이점을 알아보겠습니다. 새로운 주문 처리 시스템을 만든다고 가정해 보겠습니다. 고객은 주문 후 내역을 조회하거나 취소할 수 있고, 결제는 신용카드나 선불카드로 가능합니다. • 설계 관점 설계 관점에서 결제 기능을 구현하기 위해 다음과 같은 통합 모델링 언어(Unified Modeling Language; UML) 클래스 다이어그램을 통해 클래스들 간의 상호작용을 정의합니다. 소스 코드를 작성하여 이러한 클래스들을 구현하는 동안 설계 관점에서는 클래스 파일들이 어떻게 조직되고 배포되는지, 즉 소스 코드의 물리적인 구조에 대해서는 언급하지 않았습니다. • 아키텍처 관점 시스템 전체 구조를 다룹니다. 각 결제 유형별로 별도 서비스를 만들고, 이들을 관리할 오케스트레이터 서비스를 배치하는 등 시스템이 어떻게 조직되는지에 집중합니다. 새로운 주문 처리 시스템에 대해 다시 생각해봅시다. 시스템은 어떤 모습일까요? 아키텍처 관점에서 주문 결제 절차에 맞는 각 결제 유형을 위한 별도의 서비스를 생성하고, 결제 처리 부분을 관리할 오케스트레이터(orchestrator) 서비스를 만들 수 있습니다. 아래의 다이어그램처럼 말이죠. • 아키텍처와 설계 사이 실무에서 만나게 될 대부분의 결정은 이 두 예시 사이, 즉 아키텍처와 설계의 스펙트럼(범위) 안에 있게 됩니다. 어떤 결정이 아키텍처와 설계 사이의 어디에 위치하는지 알아야 하는 이유는 누가 결정을 내려야 하는지 알 수 있기 때문입니다. 개발팀이 독립적으로 결정할 것, 아키텍트가 주도할 것, 함께 협업해야 할 것을 구분할 수 있죠. 계획의 수준, 노력의 수준, 트레이드오프의 중대성, 세 요소를 종합하여 어떤 결정이 아키텍처에 가까운지, 아니면 설계에 가까운지 판단할 수 있습니다. 위 콘텐츠는 『헤드 퍼스트 소프트웨어 아키텍처』의 내용을 재구성하여 작성되었습니다.

프롬프트 엔지니어링은 요구 사항 엔지니어링이다.

프롬프트 엔지니어링은 요구 사항 엔지니어링이다.

AI 도구에서 최대한의 성과를 얻기 위한 경쟁 속에서, 프롬프트 엔지니어링(Prompt Engineering)—AI 도구의 출력을 안내하는 명확하고 구조화된 입력을 작성하는 실천—이 중심 무대에 올랐습니다. 그러나 소프트웨어 엔지니어들에게 이 기술은 새로운 것이 아닙니다. 우리는 수십 년 동안 다른 이름으로 이와 유사한 작업을 해왔습니다. AI 프롬프트를 작성할 때 직면하는 도전은 소프트웨어 팀이 세대를 거쳐 씨름해온 것과 동일합니다. 오늘날 프롬프트 엔지니어링에 대해 이야기하는 것은 개발자가 무엇을 구축해야 하는지, 어떤 조건에서, 어떤 가정 하에, 그리고 팀에게 어떻게 전달할지를 명확히 하는 오래된 대화를 계속하는 것입니다. 소프트웨어 위기는 1960년대 후반부터 이 문제에 붙여진 이름으로, 특히 1968년 NATO 소프트웨어 엔지니어링 회의에서 "소프트웨어 엔지니어링"이라는 용어가 도입되었습니다. 이 위기는 소프트웨어 프로젝트가 예산을 초과하고 지연되며, 종종 사용자가 실제로 필요로 하는 것을 제공하지 못하는 산업 전반의 경험을 나타냅니다. 이러한 실패가 프로그래머의 기술 부족이나 더 많은 기술 훈련이 필요한 팀 때문이라는 오해가 있었습니다. 그러나 그 회의의 패널들은 진정한 근본 원인으로 팀과 이해관계자들이 해결하려는 문제와 실제로 구축해야 하는 것을 이해하는 데 어려움을 겪고, 그 필요와 아이디어를 명확히 소통하며, 전달된 시스템이 그 의도와 일치하는지 확인하는 데 어려움을 겪고 있다고 보았습니다. 이는 근본적으로 인간의 커뮤니케이션 문제였습니다. 회의 참가자들은 이를 정확히 포착했습니다. Bell Labs의 Dr. Edward E. David Jr.는 소프트웨어가 무엇을 해야 하는지 논리적으로 명확하게 명시할 방법이 종종 없다고 언급했습니다. MIT의 Douglas Ross는 문제를 해결했다고 가정하며 무엇을 할 것인지 명시하고 그것을 수행하는 함정에 대해 지적했습니다. Prof. W.L. van der Poel은 불완전한 명세의 문제를 요약하며 대부분의 문제는 시작할 때 충분히 정의되지 않아서 올바른 솔루션을 구축하는 데 필요한 정보를 얻지 못한다고 말했습니다. 이러한 문제들은 코드가 작성되기 전에 팀이 자신들이 만드는 소프트웨어를 오해하게 만드는 원인입니다. 그리고 AI를 사용하여 코드를 생성하는 오늘날의 개발자들에게도 익숙하게 들릴 것입니다. 문제의 많은 부분은 제가 종종 "내가 말한 것이 아니라 내가 의도한 것을 하라"는 고전적인 문제라고 부르는 것으로 귀결됩니다. 기계는 문자 그대로 받아들이며, 팀의 사람들도 종종 그렇습니다. 우리의 의도는 거의 완전히 명시되지 않으며, 소프트웨어가 무엇을 해야 하는지에 대해 모두가 일치하는 데는 의도적이고 종종 어려운 작업이 필요합니다. Fred Brooks는 그의 고전적이고 널리 영향력 있는 "No Silver Bullet" 에세이에서 이에 대해 썼습니다. 그는 소프트웨어 개발을 쉽게 만드는 마법의 프로세스나 도구는 결코 없을 것이라고 주장했습니다. 소프트웨어 엔지니어링의 역사 내내, 팀들은 이해와 커뮤니케이션의 어려운 부분을 없애줄 은탄환을 찾으려는 유혹을 받았습니다. 소프트웨어 팀들이 AI 도구를 사용하기 시작했을 때, 그들이 수년간 괴롭혔던 동일한 문제가 다시 나타나는 것을 보는 것은 놀라운 일이 아닙니다. 1970년대 말까지 이러한 문제들은 품질의 관점에서 재구성되고 있었습니다. 품질 엔지니어링 분야에 큰 영향을 미친 Philip Crosby, Joseph M. Juran, W. Edwards Deming은 각각 많은 제품이 의도한 작업을 수행하지 못하는 이유에 대한 영향력 있는 견해를 가지고 있었으며, 이 아이디어는 특히 소프트웨어에 적용됩니다. Crosby는 품질이 근본적으로 요구사항에의 적합성이라고 주장하며, 명확히 정의하지 않으면 전달될 수 없다고 했습니다. Juran은 사용 적합성에 대해 이야기하며, 소프트웨어는 단지 체크리스트를 통과하는 것이 아니라 실제 문제를 실제 컨텍스트에서 해결해야 한다고 했습니다. Deming은 결함이 단순한 기술적 실수가 아니라 특히 커뮤니케이션의 부족과 공유 이해의 결여라는 깨진 시스템의 증상이라고 강조하며 더 나아갔습니다. 그는 엔지니어링의 인간적인 측면에 초점을 맞추어 사람들이 함께 배우고, 소통하고, 개선할 수 있는 프로세스를 만드는 것에 중점을 두었습니다. 1980년대에 품질 운동의 이러한 통찰은 소프트웨어 개발에 적용되기 시작했고, 이해관계자의 요구를 식별, 분석, 문서화, 관리하는 데 중점을 둔 요구사항 엔지니어링이라는 독립된 분야로 구체화되었습니다. 이는 자체 회의, 방법론 및 전문 실무를 갖춘 독립된 분야로 등장했습니다. IEEE 컴퓨터 학회는 1993년 첫 번째 국제 요구사항 엔지니어링 심포지엄을 통해 이를 공식화하여 소프트웨어 엔지니어링의 핵심 영역으로 인정했습니다. 1990년대는 요구사항 작업의 전성기로, 조직들은 더 나은 문서 형식이 더 나은 소프트웨어를 보장할 것이라는 믿음으로 공식 프로세스와 템플릿에 크게 투자했습니다. IEEE 830과 같은 표준은 소프트웨어 요구사항 명세의 구조를 규정하였고, 소프트웨어 개발 생명 주기 및 CMM/CMMI와 같은 프로세스 모델은 엄격한 문서화 및 반복 가능한 실무를 강조했습니다. 많은 조직들이 올바르게 작성하면 올바른 시스템을 보장할 것이라는 희망으로 상세한 템플릿과 양식을 설계하는 데 많은 투자를 했습니다. 실제로 이러한 템플릿은 일관성과 준수를 위해 유용했지만, 한 사람의 머릿속에 있는 것이 다른 모든 사람의 머릿속에 있는 것과 일치하는지 확인하는 어려운 부분을 제거하지는 않았습니다. 1990년대가 공식 문서화에 중점을 두었다면, 2000년대의 애자일(Agile) 운동은 더 가벼운 대화 중심의 접근 방식으로 전환되었습니다. 사용자 스토리(User Stories)는 무거운 명세에 대한 의도적인 반대점으로 등장하여 사용자의 관점에서 기능을 간단히 설명하는 짧고 간단한 설명으로, 작성하기 쉽고 이해하기 쉽게 설계되었습니다. 모든 세부 사항을 사전에 캡처하려고 하기보다는, 사용자 스토리는 개발자와 이해관계자 간의 대화를 위한 자리 표시자로 사용되었습니다. 이 실천은 의도적으로 간단하게 유지되었으며, 공유 이해는 문서화가 아닌 대화에서 비롯된다는 아이디어에 기반을 두고 있으며, 요구사항은 프로젝트 시작 시 고정되는 것이 아니라 반복과 작동하는 소프트웨어를 통해 발전한다고 보았습니다. 이 모든 것은 요구사항 엔지니어링을 소프트웨어 엔지니어링 실무의 정당한 영역이자 고유한 기술 세트를 갖춘 진정한 경력 경로로 강화했습니다. 이제 요구사항 엔지니어링이 구축해야 할 것에 대한 가정을 표면화하고 목표를 명확히 하며 관련된 모든 사람이 동일한 이해를 갖도록 하는 소프트웨어 엔지니어링의 중요한 영역이라는 광범위한 합의가 있습니다. 프롬프트 엔지니어링은 요구사항 엔지니어링이다 프롬프트 엔지니어링과 요구사항 엔지니어링은 문자 그대로 동일한 기술입니다—명확성, 컨텍스트, 의도를 사용하여 의도를 전달하고 구축되는 것이 실제로 필요한 것과 일치하도록 보장하는 것입니다. 사용자 스토리는 전통적인 공식 명세에서 진화한 것으로, 요구사항을 간단하고 유연하게 접근하면서도 의도를 모두가 이해하도록 하는 동일한 목표를 가지고 있었습니다. 사용자 스토리는 프로젝트에 대한 공유 이해를 만드는 것이 요구사항의 본질임을 팀들이 인식하도록 도왔기 때문에 산업 전반에 걸쳐 널리 수용되었습니다. 사용자 스토리는 팀이 의도를 캡처하고 대화, 반복, 작동하는 소프트웨어를 통해 이를 정제하는 가벼운 방법을 제공했습니다. 프롬프트 엔지니어링은 정확히 동일한 역할을 합니다. 프롬프트는 AI와의 대화를 위한 가벼운 자리 표시자입니다. 우리는 여전히 반복을 통해 이를 정제하며, 컨텍스트를 추가하고 의도를 명확히 하며, 실제로 의도한 것과 출력이 일치하는지 확인합니다. 그러나 중요한 것은 AI와의 전체 대화와 그 컨텍스트입니다. 개별 프롬프트는 단지 의도와 컨텍스트를 전달하는 수단일 뿐입니다. 애자일이 요구사항을 정적 명세에서 살아있는 대화로 전환한 것처럼, 프롬프트 엔지니어링은 AI와의 상호작용을 단일 명령에서 반복적인 정제 프로세스로 전환합니다—하지만 AI가 명확한 질문을 하지 않기 때문에 출력에서 누락된 부분을 추론해야 하는 경우가 많습니다. 사용자 스토리는 의도적으로 엔지니어링 작업을 사람들과 그들의 머릿속에 있는 것에 다시 집중시켰습니다. 요구사항 문서가 Word에 있든 Jira에 있는 사용자 스토리이든, 가장 중요한 것은 우리가 작성한 종이, 티켓, 문서가 아닙니다. 가장 중요한 것은 내 머릿속에 있는 것이 당신의 머릿속에 있는 것과 일치하고, 관련된 모든 사람의 머릿속에 있는 것과 일치하는 것입니다. 종이는 우리가 동의하는지 여부를 파악하는 데 도움이 되는 편리한 방법일 뿐입니다. 프롬프트 엔지니어링은 동일한 결과를 요구합니다. 팀원들과 정신 모델을 일치시키는 대신, 우리는 AI와 소통하고 있지만 목표는 변하지 않았습니다. 고품질 제품을 생산하는 것입니다. Deming, Juran, Crosby가 제시한 품질 엔지니어링의 기본 원칙은 프롬프트 엔지니어링에서도 직접적인 유사점을 가지고 있습니다. Deming의 시스템과 커뮤니케이션에 대한 초점: 프롬프트 실패는 사람의 문제가 아닌 프로세스의 문제로 추적될 수 있습니다. 이는 일반적으로 "나쁜 AI"가 아닌 컨텍스트와 커뮤니케이션의 부족에서 비롯됩니다.Juran의 사용 적합성에 대한 초점: Juran이 품질을 "사용 적합성"으로 정의했을 때, 그는 우리가 생산하는 것이 실제 요구를 충족해야 한다고 의미했습니다—단지 그럴듯해 보이는 것이 아니라. 프롬프트가 실제 문제를 해결하지 못하면 출력이 쓸모없으며, 사용에 적합한 프롬프트를 생성하지 못하면 환각이 발생할 것입니다.Crosby의 요구사항에의 적합성에 대한 초점: 프롬프트는 기능적 요구뿐만 아니라 유지보수성 및 가독성과 같은 비기능적 요구도 명시해야 합니다. 컨텍스트와 프레이밍이 명확하지 않으면 AI는 실제 의도가 아닌 훈련 분포에 맞는 출력을 생성할 것입니다. 이러한 품질 원칙이 프롬프트 엔지니어링에서 가장 명확하게 나타나는 방법 중 하나는 컨텍스트 엔지니어링(Context Engineering)이라고 불리는 것입니다—모델이 유용한 것을 생성하기 위해 볼 필요가 있는 것을 결정하는 것으로, 일반적으로 주변 코드, 테스트 입력, 예상 출력, 설계 제약 조건 및 기타 중요한 프로젝트 정보를 포함합니다. AI에게 너무 적은 컨텍스트를 제공하면, 그것은 훈련 데이터에 기반하여 가장 가능성이 높은 것으로 보이는 것을 채워넣습니다 (이는 대개 당신이 염두에 둔 것이 아닙니다). 너무 많은 정보를 제공하면, 정보에 묻혀서 당신이 정말로 요청한 것을 잃어버릴 수 있습니다. 무엇을 포함하고 무엇을 생략할지를 판단하는 것은 항상 요구사항 작업의 핵심에서 가장 깊은 도전 중 하나였습니다. 요구사항 엔지니어링과 프롬프트 엔지니어링 사이에는 또 다른 중요한 유사점이 있습니다. 1990년대에 많은 조직들은 템플릿 함정에 빠졌습니다—올바른 표준화된 양식이나 요구사항 템플릿이 좋은 결과를 보장할 수 있다고 믿었습니다. 팀들은 문서를 설계하고 작성하는 데 엄청난 노력을 기울였습니다. 그러나 진짜 문제는 형식이 아니라, 기본 의도가 진정으로 공유되고 이해되었는지 여부였습니다. 오늘날 많은 회사들은 프롬프트 라이브러리 또는 프롬프트 작성의 어려움을 제거하기 위해 실천을 표준화하려는 사전 작성된 프롬프트의 카탈로그와 같은 유사한 함정에 빠집니다. 프롬프트 라이브러리는 참조나 출발점으로 유용할 수 있지만, 문제를 프레이밍하고 공유 이해를 보장하는 핵심 기술을 대체하지는 않습니다. 1990년대의 완벽한 요구사항 템플릿이 올바른 시스템을 보장하지 않았던 것처럼, 오늘날의 캔 프롬프트도 올바른 코드를 보장하지 않습니다. 수십 년이 지난 후에도 Brooks가 그의 "No Silver Bullet" 에세이에서 제기한 포인트는 여전히 유효합니다. 이해해야 할 본질적인 복잡성을 제거할 수 있는 단일 템플릿, 라이브러리 또는 도구는 없습니다. 1990년대의 요구사항 엔지니어링이든 오늘날의 프롬프트 엔지니어링이든, 어려운 부분은 항상 동일합니다. 의도의 공유 이해를 구축하고 유지하는 것입니다. 도구는 도움이 될 수 있지만, 그 자체로는 규율을 대체하지 않습니다. AI는 이 핵심 커뮤니케이션 문제의 중요성을 높입니다. 팀원과 달리 AI는 반박하거나 질문하지 않으며, 주어진 프롬프트에 기반하여 그럴듯해 보이는 것을 생성할 뿐입니다. 이는 요구사항의 명확한 커뮤니케이션을 더욱 중요하게 만듭니다. 요구사항 엔지니어링의 이해 정렬은 프로젝트에 AI 도구를 도입할 때 더욱 중요해집니다, 왜냐하면 AI는 판단력이 없기 때문입니다. AI는 거대한 모델을 가지고 있지만, 잘 지시될 때만 효과적으로 작동합니다. AI는 코드, 문서 및 기타 프로젝트 정보와 인공물의 형태로 제공되는 컨텍스트가 필요합니다, 이는 AI가 프로젝트에 대해 아는 유일한 것이 우리가 말해주는 것이라는 것을 의미합니다. 그렇기 때문에 AI가 "아는" 것이 실제로 우리가 아는 것과 일치하는지 확인하고 검증하는 방법을 갖는 것이 특히 중요합니다. 고전적인 요구사항 엔지니어링 문제—특히 Deming이 경고했던 커뮤니케이션의 부족과 공유 이해의 결여는 요구사항 엔지니어와 애자일 실무자들이 수십 년 동안 해결하려고 노력해온 문제—는 우리가 AI를 사용할 때 더욱 복잡해집니다. 우리는 여전히 의도를 전달하고 요구사항을 명확히 지정하는 동일한 문제에 직면해 있습니다. 그러나 이제 이러한 요구사항은 팀이 읽기 위한 것이 아니라 AI의 컨텍스트를 설정하는 데 사용됩니다. 문제 프레이밍의 작은 변화가 AI가 생성하는 것에 큰 영향을 미칠 수 있습니다. 자연어를 사용하여 코드의 구조화되고 명확한 구문을 점점 더 대체하는 것은 전통적으로 소프트웨어가 이해 실패로부터 보호받는 데 도움이 되었던 중요한 안전장치를 제거합니다. 요구사항 엔지니어링의 도구는 그 누락된 안전장치를 보완하는 데 도움이 됩니다. 애자일의 반복적인 프로세스는 개발자가 요구사항을 이해하고, 작동하는 소프트웨어를 구축하며, 제품 소유자와 지속적으로 검토하는 것이 오해가 조기에 발견되도록 보장하는 점검이었습니다. AI가 요구사항에서 직접 코드를 생성함으로써 번역과 이해의 추가 단계를 제거할수록, 관련된 모든 사람—이해관계자와 엔지니어 모두—이 구축해야 할 것에 대한 진정으로 공유된 이해를 갖는 것이 더욱 중요해집니다.팀의 사람들이 소프트웨어를 함께 구축할 때, 그들은 무엇을 구축해야 하는지 이해하기 위해 많은 시간을 대화하고 질문하는 데 사용합니다. AI와 작업하는 것은 다른 종류의 피드백 사이클을 따릅니다—무엇이 누락되었는지 알기 전까지는 출력물을 보고 나서야 알 수 있으며, 종종 누락된 부분을 파악하기 위해 역설계를 해야 합니다. 그러나 두 가지 유형의 상호작용은 요구사항 엔지니어들이 항상 실천해온 컨텍스트와 커뮤니케이션에 대한 동일한 기본 기술을 요구합니다. 이는 실천에서 여러 가지 방식으로 나타납니다. 컨텍스트와 공유 이해는 기본입니다. 좋은 요구사항은 팀이 어떤 행동이 중요한지 이해하고 언제 작동하는지 알 수 있도록 도와줍니다—기능적 요구사항(무엇을 구축할 것인지)과 비기능적 요구사항(얼마나 잘 작동해야 하는지)을 모두 캡처합니다. 동일한 구분이 프롬프트에도 적용되지만, 수정할 기회는 더 적습니다. 중요한 것을 생략하면 AI는 반박하지 않고 그럴듯해 보이는 것으로 응답합니다. 때로는 그 출력이 합리적으로 보일 때까지는 문제가 해결된 것처럼 보입니다.범위 설정은 진정한 판단이 필요합니다. AI를 사용하여 코드를 작성하는 데 어려움을 겪는 개발자는 일반적으로 두 가지 극단에 빠집니다. 너무 적은 컨텍스트를 제공하거나(실제로는 실패하는 것처럼 보이는 단일 문장) 전체 파일을 붙여넣고 모델이 올바른 메서드에 집중하기를 기대합니다. 중요한 것을 명시적으로 언급하지 않으면—기능적 요구사항과 비기능적 요구사항 모두—무엇이 중요한지 알 수 없습니다.컨텍스트는 드리프트하고 모델은 그것이 드리프트하고 있다는 것을 모릅니다. 인간 팀과 함께라면, 이해는 점검과 대화를 통해 점진적으로 변화합니다. 프롬프트를 사용할 때, 드리프트는 몇 번의 교환만에 발생할 수 있습니다. 모델은 여전히 유창한 응답을 생성할 수 있지만, 말이 안 되는 수정을 제안할 때가 있습니다. 이는 컨텍스트가 드리프트했음을 나타내며, 대화를 재구성해야 한다는 신호입니다—아마도 모델에게 코드를 설명하거나 자신이 하고 있는 일을 다시 진술하도록 요청함으로써. 역사는 계속 반복됩니다. 흩어진 요구사항으로 가득 찬 바인더에서 IEEE 표준, 사용자 스토리, 오늘날의 프롬프트에 이르기까지, 규율은 동일합니다. 우리는 이를 진정한 엔지니어링으로 다룰 때 성공합니다. 프롬프트 엔지니어링은 요구사항 엔지니어링의 진화의 다음 단계입니다. 이는 프로젝트에 참여하는 모든 사람—AI를 포함하여—이 공유된 이해를 갖도록 보장하는 방법이며, 오해를 피하고 올바른 것을 구축하기 위해 항상 필요했던 동일한 주의, 명확성, 의도적인 커뮤니케이션을 요구합니다. 원문 . Prompt Engineering Is Requirements Engineering

양자 컴퓨터 어디에 투자할 것인가? 성공적인 양자 컴퓨터 투자를 위한 체크리스트 ​

양자 컴퓨터 어디에 투자할 것인가? 성공적인 양자 컴퓨터 투자를 위한 체크리스트 ​

왜 퀀텀 월드에 투자해야 하는가? 보스턴컨설팅그룹(BCG)은 양자 컴퓨팅이 2040년까지 전 세계적으로 약 8,500억 달러(한화 약 1,100조 원)의 새로운 비즈니스 가치를 창출할 것이라고 말합니다. 단순히 기술 트렌드 차원이 아니라, 앞으로 수십 년간 산업 전반에 걸쳐 거대한 지각 변동이 일어날 수 있다는 의미죠. 왜 지금, 퀀텀 월드에 투자해야 할까요?​ ① 모든 산업을 관통하는 혁명의 도화선 신약 개발, 신소재 설계, 금융 포트폴리오 최적화, 물류, AI는 물론이고, 나아가 예술과 인문학까지. 양자 컴퓨팅의 잠재력은 특정 산업에 국한되지 않습니다. 이는 마치 산업혁명 시대의 증기기관, 정보화 시대의 인터넷처럼 ‘범용 목적 기술’의 탄생을 우리가 직접 목격하는 순간이라 할 수 있습니다​② 천문학적 규모의 가치 창출 보스턴컨설팅그룹의 리포트에 의하면 특히 제약, 화학, 금융, 자동차 산업이 양자 컴퓨팅의 직접적인 수혜를 받을 가능성이 큽니다. 이것은 단순한 시장 성장의 문제가 아니라, 전혀 새로운 방식으로 부가가치를 창출하는 거대한 흐름에 참여하는 것과 같습니다. 출처: BCG 보고서 (https://www.bcg.com/publications/2024/long-term-forecast-for-quantum-computing-still-looks-bright) ③ 승자가 모든 것을 갖는 선점 효과 양자 컴퓨터 시장은 아직 여명의 단계에 머물러 있습니다. 진정한 잠재력을 가진 기업을 먼저 발견하고 투자하는 사람이 장기적으로는 비교할 수 없는 수익률을 얻을 수 있다는 뜻입니다. 초기 시장의 ‘선점 효과’가 활짝 열려 있는 셈입니다. 물론 양자 컴퓨터에 장밋빛 미래가 펼쳐져 있는 것만은 아닙니다. 이번에는 투자자가 반드시 냉철하게 직시해야 하는 그림자를 살펴봅니다.​ ①기술적 불확실성 - 위태로운 큐비트의 숙명 • 큐비트의 변덕 (결잃음 현상): 큐비트는 지독하게 예민한 존재입니다. 미세한 열이나 진동에도 양자 상태가 쉽게 깨져버리는 ‘결잃음’ 현상은 양자 컴퓨팅의 가장 큰 숙제입니다. 오류율이 10⁻³ 수준인 현재의 큐비트는, 10⁻ 15 이하의 오류율을 자랑하는 고전 컴퓨터에 비하면 아직 갈 길이 멉니다. • 확장성의 저주: 큐비트의 수를 늘릴수록 오류는 기하급수적으로 증가하고 제어는 더욱 복잡해집니다. 수백만 개의 큐비트가 필요한 ‘결함 허용 양자 컴퓨터’의 길은 아직 멀고 험난합니다. • 절대영도의 족쇄: 대부분의 양자 컴퓨터는 절대영도(-273.15℃)에 가까운 극한의 환경에서만 작동합니다. 이를 위한 거대한 희석 냉동기는 엄청난 비용과 에너지를 소모하는 기술적 족쇄입니다. • 알고리즘의 부재: 강력한 하드웨어가 있어도, 그 위에서 달릴 효율적인 소프트웨어와 알고리즘이 없다면 소용없습니다. 양자만의 독특한 능력을 100% 활용할 ‘킬러 앱’의 개발은 여전히 진행 중인 과제입니다.​ ② 시장 및 사업적 리스크 - 거인들의 전쟁터 • 거인들의 전쟁: 구글, 마이크로소프트, 아마존, IBM과 같은 빅테크 기업들이 막대한 자본을 쏟아부으며 시장을 선점을 위해 경쟁하고 있습니다. 이들과 경쟁해야 하는 스타트업에게는 혹독한 전쟁터입니다. • 기나긴 인내의 시간: 실질적인 수익 창출까지 10년 이상 걸릴 수도 있습니다. 그전까지는 끊임없이 자금을 조달 해야하는 ‘죽음의 계곡’을 건너야 합니다. • 거품과 허상: “세계 최초”, “최대 규모”와 같은 화려한 수식어 뒤에 숨은 기술적 현실을 꿰뚫어 볼 날카로운 안목이 없다면, 과장된 홍보의 희생양이 될 수 있습니다.​ ③ 윤리적 및 사회적 문제: 판도라의 상자 • 암호 해독의 위협: 양자 컴퓨터는 현대 문명을 지탱하는 암호 체계를 일순간에 무력화시킬 수 있는 ‘만능 열쇠’가 될 수 있습니다. 이는 국가 안보와 금융 시스템에 심각한 위협을 초래할 수 있습니다. • 감시 사회의 가속화: 개인의 모든 것을 추적하고 예측하는 강력한 감시 기술로 악용될 가능성을 배제할 수 없습니다. • 양자 격차: 기술을 가진 국가와 기업, 그렇지 못한 주체 간의 격차가 극심해져 새로운 불평등을 낳을 수 있습니다. 양자 컴퓨터, 어디에 투자할 것인가? 복잡한 생태계 속에서 옥석을 가리려면 각 영역의 선두 주자를 면밀히 살펴봐야 합니다.​① 양자 하드웨어: 퀀텀 월드의 개척자들 • 초전도 큐비트(선두 주자): IBM, 구글, 리게티 컴퓨팅 → 현재 가장 앞서나가며 대규모 확장에 유리한 방식입니다.• 이온 트랩 큐비트(정밀도의 강자): 퀀티뉴엄, 아이온큐 → 오류율이 낮고 안정성이 높아 정밀 계산에 강점을 보입니다.​• 중성 원자/광자 큐비트(미래의 다크호스): 큐에라, 파스칼, 사이퀀텀, 자나두→ 확장성과 상온 작동 가능성 등에서 혁신적인 잠재력을 보여줍니다.​• 위상학적 큐비트(궁극의 도전자): 마이크로소프트→ 이론적으로 가장 완벽하지만 아직 실체 구현까지는 가장 먼 길입니다.​② 양자 소프트웨어: 퀀텀 월드의 설계자들 • 통합 플랫폼: 퀀티뉴엄, 자파타 컴퓨팅, 클래식(Classiq)→ 특정 하드웨어에 종속되지 않고, 다양한 양자 컴퓨터에서 작동하는 운영체제와 솔루션을 제공합니다.​• 빅테크 플랫폼: IBM의 ‘키스킷’, 구글의 ‘써크’, 마이크로소프트의 ‘애저퀀텀’, 아마존의 ‘브라켓’과 같은 막강한 클라우드 인프라를 기반으로 생태계를 장악하려 합니다.​③ 양자 보안: 제국의 방패 • 양자 내성 암호(PQC): 양자 컴퓨터로도 뚫을 수 없는 새로운 암호 체계를 개발하는 기업들. NIST의 표준 화가 완료됨에 따라 시장이 본격적으로 열릴 것입니다. (예: ICTK)• 양자 키 분배(QKD): 양자역학 원리를 이용해 이론적으로 매우 강력한 보안 통신망을 구축하는 기술입니다. (예: SK텔레콤(아이디퀀티크)외 국내 통신사, 도시바)• 국내 기업: 우리로, 코위버, 쏠리드 등은 양자 통신에 필요한 핵심 부품과 장비를 공급하며 생태계의 중요한 축을 담당하고 있습니다. 성공적인 양자 컴퓨터 투자를 위한 7가지 체크 리스트​양자 컴퓨터는 단순히 기술적 호기심을 넘어, 산업 지형을 바꾸는 거대한 흐름으로 자리잡고 있습니다. 하지만 투자자의 관점에서 보면, 아직은 숲속에 안개가 자욱한 상황입니다. 수많은 기업이 ‘양자 혁명’의 깃발을 들고 등장했지만, 모두가 살아남는 것은 아닙니다. 마치 인터넷 초창기 수많은 닷컴 기업이 나타났다가, 결국 아마존·구글 같은 소수의 승자만이 시장을 장악했던 것처럼 말이죠.​그렇다면 어떤 기준으로 옥석을 가려야 할까요? 투자자가 반드시 확인해야 할 7가지 체크리스트를 살펴보겠습니다.​1. 로드맵을 해독하라단순 큐비트 숫자에 현혹되지 마라. 오류율, 게이트 충실도 등 성능의 질을 따져라. 기업이 제시하는 기술 로드맵이 허황된 꿈이 아닌 현실적인 계획인지 검증하라.​2. 어벤져스 팀을 찾아라노벨상급 과학자, 노련한 엔지니어 그리고 비즈니스 감각을 갖춘 경영진이 조화를 이루는 팀을 찾아라. 결국 모든 혁신은 사람에게서 나온다.​3. 생태계 안의 관계를 읽어라구글, 아마존, 마이크로소프트 같은 거인과의 파트너십은 기술의 상용화와 시장 진출에 결정적인 역할을 한다. 고립된 섬이 아닌 생태계의 허브와 연결된 기업에 주목하라.​4. 자금과 특허 포트폴리오를 확인하라혁신에는 막대한 자금이 필요하다. 자금 소진 속도(Burn Rate)와 추가 자금 조달 능력을 평가하라. 또한 기술적 해자 역할을 할 핵심 특허(IP)를 얼마나 확보했는지 확인하라.​5. 명확한 수익 모델을 요구하라세상을 바꾸겠다는 말만으로는 부족하다. 그래서 어떻게 돈을 벌 것인가에 대한 명확한 답을 가진 기업을 찾아라. 하드웨어 판매, 클라우드 서비스, 소프트웨어 라이선스 등 구체적인 수익 모델을 제시하는가?​6. 장기적 시야로 분산 투자하라퀀텀 투자는 100미터 달리기가 아닌 마라톤이다. 최소 5~10년의 장기적인 안목으로 접근하라. 특정 기술 방식에 올인하기보다 하드웨어, 소프트웨어, 보안 등 다양한 분야에 분산 투자 하여 리스크를 관리하라.​7. 하이브리드 접근을 이해하라양자 컴퓨터가 모든 것을 대체하진 않는다. 당분간은 고전 컴퓨터와 양자 컴퓨 터가 협력하는 하이브리드 방식이 대세일 것이다. 이 현실적인 접근법을 통해 실질적인 가치를 창출하는 기업이 초기 승자가 될 가능성이 높다. *위 내용은 『정지훈의 양자 컴퓨터 강의』 내용을 기반으로 작성한 <퀀텀 월드 투자 가이드: 미래를 여는 게임체인저>에서 발췌하였습니다. 양자 컴퓨팅의 여정을 따라가다 보면, 지금이야말로 기술과 산업, 그리고 투자까지 본격적으로 준비해야 할 시점임을 알 수 있습니다. 다가올 5~10년은 단순한 연구 단계를 넘어 실제 사회와 경제를 바꾸는 양자 시대의 서막이 될 가능성이 크기 때문입니다.​이 흐름을 더 깊고 입체적으로 이해하고 싶다면, 『정지훈의 양자 컴퓨터 강의』가 좋은 길잡이가 되어줄 것입니다. 양자 컴퓨터의 핵심 개념을 알기 쉽게 풀어내고, 초전도·이온 트랩·광자 등 다양한 구현 기술은 물론론 글로벌 빅테크들의 전략, 산업별 응용과 투자 포인트까지 한 권에 담았습니다.​AI 이후의 미래를 준비하고 싶은 독자라면, 지금 꼭 만나야 할 책입니다.

입문부터 심화까지, 닐 포드의 '소프트웨어 아키텍처' 도서 추천 4종

입문부터 심화까지, 닐 포드의 '소프트웨어 아키텍처' 도서 추천 4종

소프트웨어 아키텍처는 시스템의 성패를 좌우하는 핵심이지만, 개발자에게는 늘 추상적이고 막연하게 다가옵니다. “아키텍처를 공부해야지” 생각하면서도 어디서부터 시작해야 할지 막막한 경우가 많습니다. Neal Ford(출처: oreilly)ThoughtWorks의 소프트웨어 아키텍트, 닐 포드(Neal Ford)는 이런 문제를 해결하기 위해 개발자에서 아키텍트로 성장하는 길을 구체적으로 안내하는 책들을 꾸준히 써왔습니다. 그는 아키텍처를 추상적 개념이 아닌 실무에서 반복적으로 맞닥뜨리는 문제와 의사결정의 집합으로 바라봅니다. 지금부터 소개할 닐 포드의 아키텍처 저서 4권은 각각 다른 초점을 갖지만, 입문 → 기본기 → 변화 대응 → 심화로 이어지는 완전한 아키텍처 학습 로드맵을 제공합니다. 현재 자신의 위치와 필요에 따라 선택해서 읽어도 좋고, 순서대로 따라가며 체계적으로 읽어도 좋습니다. 도서명난이도추천 대상헤드 퍼스트 소프트웨어 아키텍처입문- 아키텍처 설계를 처음 배우는 초보 개발자소프트웨어 아키텍처 101기본- 아키텍처의 기본 개념과 용어를 명확히 정리하고 싶은 개발자- 아키텍트 역할을 준비하는 시니어 개발자, 기술 리더진화적 아키텍처응용- 배포와 운영 환경이 자주 바뀌는 조직의 개발자/아키텍트- 아키텍처 이해가 필요한 시니어 개발자소프트웨어 아키텍처 The Hard Parts심화- 마이크로서비스나 분산 시스템을 운영 중인 개발자/아키텍트- 확장성과 성능, 안정성 사이에서 균형을 고민하는 기술 리더 ① 헤드 퍼스트 소프트웨어 아키텍처 (입문) 아키텍처의 세계에 첫 발을 내딛는 사람을 위한 책입니다. “헤드 퍼스트” 시리즈답게 건축 비유, 시각적 자료, 스토리 기반 프로젝트([난&팝], [트립이지], [고잉 그린])를 통해 독자가 직접 아키텍트처럼 사고하고 선택해보게 합니다. 단순한 정의와 개념 설명을 넘어 “왜 이런 결정을 내려야 하는가”를 반복적으로 묻고 답하게 하여 아키텍처적으로 사고하는 법을 익히는 데 초점을 둡니다. 코드 레벨에서 벗어나 시스템 전반을 보는 눈을 키우고, 설계와 아키텍처의 차이를 명확히 설명합니다. 또한 다양한 아키텍처 스타일(계층형, 이벤트 기반, 마이크로서비스 등)을 사례와 함께 다루며, 각 스타일의 장단점과 적용 맥락을 설명합니다. 커뮤니케이션과 다이어그램 작성법도 중요한 주제로 다루고 있어서 실제 팀 내에서 어떻게 의견을 설득하고 아키텍처를 공유할 수 있을지 배울 수 있습니다. ✅ 주요 내용• 소프트웨어 아키텍처의 4대 구성: 특성, 결정, 컴포넌트, 스타일• 다양한 아키텍처 스타일: 레이어드, 모듈러 모놀리스, 마이크로서비스, 이벤트 기반 등• 아키텍처 트레이드오프 분석과 결정 기록(ADR) 작성법• 스토리 기반 가상 프로젝트: [난&팝], [트립이지], [고잉 그린]• 아키텍트 역할을 수행하며 실전 감각을 길러보는 50개의 연습문제 ✅ 추천 독자• 아키텍처 설계를 처음 배우는 초보 개발자• 개발자에서 아키텍트로 성장하고자 하는 소프트웨어 엔지니어• 아키텍처 의사결정 과정을 체계화하고 싶은 경험 많은 엔지니어• 스터디나 교육용 교재를 찾는 팀 리더 ② 소프트웨어 아키텍처 101(기본) 빠르게 변하는 기술 혁신으로 업계를 바라보는 아키텍트의 시선에도 변화가 필요합니다. 이 책은 지난 10년간의 변화를 오늘날의 구조에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴봅니다. 아키텍처 기초(패턴, 사고, 특성)와 아키텍처 스타일(레이어드, 파이프라인, 마이크로커널, 이벤트, 서비스, 오케스트레이션), 그리고 테크닉과 소프트 스킬(결정, 리스크, 도식화, 협상, 리더십, 커리어패스 등)을 최근 생태계와 설계 아키텍처의 관점에서 깔끔하게 정리해 담았습니다. 대학교 전공과목에서도 잘 알려주지 않는 소프트웨어 아키텍처에 대한 놀라운 인사이트와 주옥같은 명언까지 만나볼 수 있습니다. ✅ 주요 내용• 아키텍처 패턴: 수많은 아키텍처 결정을 내리는 기술적인 근간• 컴포넌트: 식별, 커플링, 응집, 분할, 세분도• 소프트 스킬: 효과적인 팀 관리, 회의, 협상, 프레젠테이션 등• 현대성: 지난 수년 동안 근본적으로 변화한 엔지니어링 프랙티스와 운영 방식• 엔지니어링으로서의 아키텍처: 소프트웨어 아키텍처를 더욱 탄탄하게 만들어주는 반복 가능한 결과, 메트릭, 구체적인 평가 ✅ 추천 독자• 아키텍처의 기본 개념과 용어를 명확히 정리하고 싶은 개발자• 아키텍트 역할을 준비하는 시니어 개발자, 기술 리더• 팀 차원에서 공통된 기준과 언어를 마련하려는 조직 ③ 진화적 아키텍처 (응용) 이 책은 소프트웨어 개발의 새로운 패러다임인 '진화적 아키텍처'에 대해 다루고 있습니다. 진화적 아키텍처는 끊임없이 변화하는 환경에 유연하게 적응할 수 있도록 '가드레일이 내장된' 아키텍처를 의미하며, 변화를 미리 예측하기보다는 변화 자체를 받아들이고 피트니스 함수를 통해 이를 감지하고 대응하는 방식입니다. 이러한 접근법을 통해 시스템이 점진적으로 발전할 수 있으며, 향후 대규모 재구축의 필요성도 줄일 수 있습니다. 현재 소프트웨어 개발에서 아키텍처 설계의 중요성이 계속 높아지고 있으며, 특히 서비스 지향 아키텍처(SOA)에서 마이크로서비스 아키텍처(MSA)로 넘어가는 흐름 속에서 진화적 아키텍처는 핵심 기술로 떠오르고 있습니다. 클라우드 네이티브를 도입하려는 개발자나 아키텍트들에게는 이제 필수 역량이 된 상황입니다. 이 책은 소프트웨어의 거장이자 『리팩터링』 저자 ‘마틴 파울러’가 추천한 도서이기도 하며, 전 세계적으로 인정받은 전문가들의 노하우가 담겨 있어 빠르게 변화하는 비즈니스 환경에 대응할 수 있는 유연한 아키텍처를 구축하는 실전 방법들을 학습할 수 있습니다. ✅ 주요 내용• 진화적 아키텍처: 변화에 유연하게 적응하는 가드레일 내장형 아키텍처• 피트니스 함수: 아키텍처 특성을 자동 검증하고 변화를 감지하는 핵심 도구• 점진적 변화: 대규모 재구축 없이 시스템을 단계적으로 개선하는 방법론• 자동화된 거버넌스: 코드 기반 검증과 데브옵스 통합을 통한 품질 관리• 실무 가이드: 그린필드부터 레거시 개조까지의 실전 적용 방법 ✅ 추천 독자• 배포와 운영 환경이 자주 바뀌는 조직의 개발자/아키텍트• 아키텍처 이해가 필요한 시니어 개발자• MSA/클라우드 도입 예정자• 변화에 유연한 시스템을 설계하고 싶은 기술 리더 ④ 소프트웨어 아키텍처 The Hard Parts(심화)이 책은 소프트웨어 아키텍처에서 가장 어렵지만 중요한 의사결정 문제들을 다룹니다. 분산 아키텍처를 구축할 때 서비스를 언제 나누고 언제 합칠지를 세분도 분해인과 통합인이라는 두 가지 관점에서 접근하며, 아키텍트가 객관적인 트레이드오프 분석을 통해 올바른 판단을 내릴 수 있는 실용적 프레임워크를 제시합니다. 전작이 소프트웨어 아키텍처의 전반적인 개론을 다뤘다면, 이 책은 제목 그대로 실무에서 마주하는 가장 난해하면서도 한번 결정되면 바꾸기 어려운 핵심적인 문제들에 집중합니다. 모놀리식 애플리케이션을 마이크로서비스로 분리하는 복잡한 과정, 서비스 간 계약 관리, 분산 환경에서의 데이터 처리, 워크플로와 트랜잭션 관리 패턴 등이 포함됩니다. 특히 가상의 애플리케이션 서비스 팀의 리팩토링 과정을 따라가며 현실적인 고민과 해결책을 제시하여 현장감 있는 학습이 가능합니다. 이 책은 '최고의 솔루션'을 제시하기보다는 각 아키텍처 방법론과 패턴의 장단점을 균형 있게 분석하여, 독자가 상황에 맞는 최적의 선택을 할 수 있도록 돕는 실무 중심의 가이드북입니다. ✅ 주요 내용• 트레이드오프 분석과 함께 의사 결정을 효과적으로 문서화하기• 서비스 세분화를 통해 더 나은 결정을 내리는 방법• 모놀리식 애플리케이션 분리의 복잡도• 서비스간 계약 관리 및 분리• 고도로 분산된 아키텍처에서 데이터 처리하기• 애플리케이션을 분리할 때 워크플로와 트랜잭션을 관리하는 패턴 학습✅ 추천 독자• 마이크로서비스나 분산 시스템을 운영 중인 개발자/아키텍트• 확장성과 성능, 안정성 사이에서 균형을 고민하는 기술 리더• 실전 문제 해결 관점에서 아키텍처를 학습하고 싶은 독자 좋은 코드 위에 좋은 아키텍처가 있을 때, 비로소 시스템은 오래 버티고 성장할 수 있습니다. 아키텍처는 오늘보다 나은 내일을 위한 기술의 뼈대이자, 변화를 견디게 하는 든든한 기반입니다. 빠르게 변하는 환경 속에서 개발자가 가져야 할 가장 중요한 역량은 단순한 구현 능력이 아니라, 시스템 전체를 바라보고 설계하는 아키텍처적 시각입니다. 결국 아키텍처를 이해하고 고민하는 과정이 곧 더 나은 기술, 더 나은 팀, 더 나은 미래로 이어집니다.

해킹 공부를 시작하는 여러분께 꼭 하고 싶은 말이 있습니다.

해킹 공부를 시작하는 여러분께 꼭 하고 싶은 말이 있습니다.

2010년, 정보보안 공부를 처음 시작할 당시에는 관련 정보가 매우 부족해 많은 어려움을 겪었습니다. 해외 사이트를 이곳저곳 돌아다니며 단편적인 정보들은 얻을 수 있었지만 전체적인 흐름과 낯선 개념, 체계를 이해하기에는 턱없이 부족해, 지식에 대한 갈증은 쉽게 해소되지 않았습니다. 특히 책을 통해 지식을 정리하고 학습하는 데 익숙한 저로서는 기본 개념, 동작 원리, 공격 방법론 등 하나부터 열까지 체계적으로 정리된 책이 간절히 필요했습니다. 그러나 당시 IT 개발 서적은 하루가 멀다 하고 출간되는 반면, 정보보안 분야는 국내에서 보편화되지 않았기에 출간된 서적조차 매우 적었습니다. 그때부터 언젠가 이 분야의 바이블처럼 제대로 된 책을 내가 직접 써야겠다는 다짐을 하게 되었습니다. 실무에 투입될 때마다 공부해야 할 것, 배운 것, 궁금했던 점들을 하나하나 기록하며 퇴근 후에는 틈틈이 공부와 연구를 이어갔습니다. 그렇게 한 걸음씩 차곡차곡 쌓아 올린 결과, 감사하게도 실무자 오프라인 교육, 온라인 교육 강의 그리고 이 책까지 집필할 수 있게 되었습니다. 이 책은 웹 해킹과 보안에 관심 있는 초보자부터 정보보안 실무자, 웹 개발자까지 폭넓은 독자층을 대상으로 합니다. 웹 해킹의 기본 개념과 동작 원리, 취약점의 발생 원인, 공격 기법을 자세히 다루고 있으며, 이를 바탕으로 보안 대응 방안까지 익힐 수 있는 실무 중심의 책입니다. 다만 공격 기법의 고급 기술, 심화·응용 기술은 다루지 않습니다. 왜냐하면 뿌리 지식이 부족한 상태에서 고급 기술을 익히는 것은 마치 기둥 없이 건물을 올리는 것과 같기 때문입니다. 이 책은 탄탄한 기초를 다지는 데 집중했습니다. 하지만 실망하지 않았으면 합니다. 이 책에 담긴 기본기만 제대로 익혀도 이후에 큰 성장을 이룰 수 있는 확실한 발판이 될 것입니다. 기회가 된다면 심화된 기술 내용을 다룬 책도 꼭 집필해보고 싶습니다. 그것은 저의 다음 목표이기도 합니다. 공부를 시작하는 여러분께 꼭 하고 싶은 말이 있습니다. 해킹 공격 기법 자체에만 너무 집중하지 않았으면 합니다. 해킹 공부를 처음 시작하는 사람들이 흔히 하는 함정 중 하나는 ‘공격 기법을 익히는 것이 곧 해킹 실력’이라고 착각하는 것입니다. 그러나 실무에서 공격 기법에만 치중한 사람들은 시야가 좁아져, 누구나 찾을 수 있는 일반적인 취약점들도 겨우 발견하게 됩니다. 그리고 웹 서비스에서 취약점이 발견되지 않으면 취약점이 없다고 단정짓습니다. 그렇다면 시야를 넓히는 방법은 무엇일까요? 바로 프로그래밍, 서버, 네트워크에 대한 공부입니다. 해킹이란 결국 ‘프로그램의 보안 허점’을 공략하는 것이기 때문에 프로그램에 대한 이해가 필수입니다. 프로그램이 어떻게 작동하는지 모른 채 공격 기술만 익힌다면 결코 뛰어난 보안 역량을 발휘할 수 없습니다. 또, 프로그램은 결국 서버에서 실행되므로 서버 구조와 동작 원리에 대한 이해도 반드시 필요합니다. 서버는 네트워크 환경에서 동작하므로 네트워크 지식 역시 빠질 수 없습니다. 해킹 공격 기술만 익힌 사람은 주로 누구나 찾을 수 있는 일반적인 취약점만 발견하는 반면, 공격의 근본 원리까지 이해한 사람은 기술만 익힌 이들이 놓치는, 보다 구조적인 취약점까지 찾아낼 수 있습니다. 여기에 프로그램의 작동 방식까지 깊이 이해하고 있는 사람은 공격 원리만 아는 사람보다 더 다양한 취약점을 식별할 뿐만 아니라, 나아가 프레임워크, 라이브러리, 운영 체제, 네트워크 등 전반적인 시스템 구조에 대한 이해까지 갖춘 사람은 훨씬 더 폭넓고 깊이 있는 보안 분석이 가능해집니다. 이처럼 시야가 높아질수록 이해의 깊이와 폭도 넓어지고, 다양한 케이스의 취약점을 발견할 수 있는 능력이 생깁니다. 얼마나 해야 할지 막막하고, 할 수 있을지 걱정되나요? 걱정할 필요 없습니다. 이 책을 끝까지 따라오기만 해도 실무에서 통하는 보안 감각을 충분히 키울 수 있습니다. 자, 이제 본격적으로 웹 해킹의 세계로 함께 들어가 봅시다.하동민 (크리핵티브)저자의 어려움에서 시작된 책,『크리핵티브의 한 권으로 끝내는 웹 해킹 바이블』은 웹 해킹의 기본 이론부터 실무 공격·방어 기술까지 아우르는 가장 완성도 높은 입문서입니다. 책은 단순히 기술을 나열하지 않습니다. HTTP와 SQL 기본 문법, 버프 스위트 사용법 등 기초 개념을 꼼꼼히 익힌 후, SQL 인젝션, XSS, CSRF, 파일 업로드 취약점 등 실제 보안 진단에 활용되는 핵심 공격 기법을 직접 실습합니다. 948쪽에 담긴 상세한 실습 예제와 체계적인 학습 흐름은 입문자가 보안의 기초를 다지고, 실무자가 공격과 방어 양쪽의 감각을 동시에 기를 수 있도록 돕습니다. 보안 전문가를 목표로 공부하는 예비 전문가부터, 현업에서 바로 활용 가능한 보안 기술을 배우고 싶은 개발자와 보안 담당자까지. 이 책은 여러분의 학습을 위한 가장 든든한 출발점이 될 것입니다.

디자이너를 위한 UX/UI 프로세스 단계별 AI 도구 30종

디자이너를 위한 UX/UI 프로세스 단계별 AI 도구 30종

디자이너를 위한 UX/UI 프로세스 단계별 AI 도구 30종생성형 AI의 도입은 UX/UI 디자인의 모든 과정에서 접근 방식을 근본적으로 변화시키고 있습니다. AI 기술은 단순히 반복 작업을 자동화하는 데 그치지 않고, 창의적인 아이디어 발굴에서 사용자 경험 개선까지 디자인의 모든 단계에서 새로운 기회를 만들고 있습니다. UX/UI 디자인 전 과정에 AI를 도입하려면 각 단계별로 어떤 AI가 유용할지 고민이 될 수밖에 없습니다. 어떤 AI를 도입할지 고민하기 앞서 UX/UI 디자인 과정을 먼저 세분화해보겠습니다. 세분화 기준은 디자인 문제 해결에 널리 쓰이는 더블 다이아몬드 모델을 활용하겠습니다. 더블 다이아몬드 모델은 문제를 넓게 탐색하여 발견하고, 그중 핵심 문제를 명확히 정의한 뒤, 해결책을 개발하고, 최적의 해결책을 전달하는 프로세스 로, 일종의 문제 해결 방법론입니다. 즉, 발견 → 정의 → 개발 → 전달이라는 4단계로 구성되어 있습니다. 출처: <디자인 경험을 바꾸는 UX/UI 디자인 with AI>, 한빛미디어 이번에는 디자인 프로세스별로 어떤 AI 도구를 사용해야 하는지, UX/UI 디자인 프로세스를 더블 다이아몬드 모델의 4단계로 구분해서 각 단계별로 유용한 도구들을 살펴보겠습니다. *아래 내용은 『디자인 경험을 바꾸는 UX/UI 디자인 with AI』에서 발췌하여 작성하였습니다.1.발견 단계 (Discover step)에서 쓸 수 있는 AI 툴 8종 UX/UI 디자인의 발견 단계에서는 사용자 요구 사항을 파악하고 문제를 정의합니다. 이 단계에서는 사용자 조사, 경쟁사 분석, 페르소나 생성, 사용자 여정 지도 작성 등의 활동이 이루어집니다. 이러한 활동을 통해 프로젝트의 방향을 설정하고 사용자 중심 솔루션을 개발할 수 있는 기반을 마련합니다. • 챗GPT챗GPT는 자연어 처리 능력이 뛰어난 AI로, 사용자 인터뷰 질문 생성, 페르소나 작성, 아이디어 브레인스토밍 등에 활용할 수 있습니다. 또한 사용자 피드백 분석이나 경쟁사 리서치 요약에도 유용합니다. 다양한 UX 관련 질문에 대한 답변을 제공하여 디자이너의 의사 결정을 지원합니다. • 클로드클로드는 챗GPT와 유사하게 UX 리서치 계획 수립, 인터뷰 질문 작성, 데이터 분석 등에 활용할 수 있습니다. 특히 긴 문서를 요약하거나 복잡한 정보를 구조화하는데 뛰어난 성능을 보여, 사용자 조사 결과 정리나 인사이트 도출에 유용합니다. 또한 윤리적 고려 사항에 대한 조언도 제공할 수 있습니다. • 퍼플렉시티 (Perplexity)퍼플렉시티는 실시간 정보 검색과 요약에 뛰어난 AI로, UX 트렌드 조사, 경쟁사 분석, 업계 동향 파악 등에 효과적입니다. 다양한 소스에서 양질의 정보를 빠르게 종합하고 관련성 높은 인사이트를 제공하여 디자이너가 최신 UX 동향을 파악하는 데 도움을 줍니다. • 컨센서스 (Consensus) 컨센서스는 학술 논문과 연구 결과를 분석하고 요약하는 AI 도구로, UX 관련 학술 연구를 빠르게 파악하는 데 유용합니다. 사용자 행동, 인지 심리학, 인터 페이스 디자인 등에 관한 최신 연구 결과에 쉽게 접근할 수 있어 데이터 기반의 UX 디자인 의사 결정에 도움을 줍니다. • 스톰 AI (Storm AI)스톰 AI는 주제에 대한 포괄적인 리서치와 보고서 생성을 자동화하는데 뛰어난 AI로, UX/UI 디자인 관련 주제에 대해 다양한 관점의 질문을 생성하고, 관련 정보를 수집하여 구조화된 보고서를 작성할 수 있습니다. 이는 프로젝트의 배경 조사나 사용자 컨텍스트를 이해하는 데 활용할 수 있습니다. • 시네틱 유저 (Synthetic Users)시네틱 유저는 가상의 사용자를 생성하고 시뮬레이션하는 AI로, 다양한 사용자 시나리오를 테스트하고, 사용자 행동을 예측할 수 있습니다. 실제 사용자 테스트 전에 초기 아이디어를 검증하거나 다양한 사용자 그룹의 니즈를 탐색하는데 활용할 수 있습니다. • 노트어블리 (Notably)노트어블리는 사용자 인터뷰와 피드백을 자동으로 전사하고 분석하는 AI 도구입니다. 음성을 텍스트로 변환하고, 주요 주제와 감정을 추출하여 인사이트를 도출합니다. 이를 통해 UX 연구자들은 더 많은 데이터를 효율적으로 처리하고, 패턴을 발견할 수 있습니다. • 원더링 (Wondering)원더링은 AI 기반의 사용자 리서치 플랫폼으로, 자동화된 인터뷰 진행과 분석을 제공합니다. 다국어 지원과 대규모 데이터 처리 능력을 바탕으로, 글로벌 사용자 연구를 효율적으로 수행할 수 있습니다. 또한 프로토타입 테스트와 개념 검증에도 활용될 수 있습니다. 출처: <디자인 경험을 바꾸는 UX/UI 디자인 with AI>, 한빛미디어 2. 정의 단계 (Define step)에서 쓸 수 있는 AI 툴 6종 UX/UI 디자인의 정의 단계에서는 프로젝트의 목표와 범위를 정의하고, 사용자와 이해관계자의 요구 사항을 파악합니다. 이 단계에서는 문제 정의, 사용자 페르소나 생성, 프로젝트 목표 설정 등의 활동이 이루어집니다. • 페르소나 젠 (Persona Gen)페르소나 젠은 사용자 페르소나 생성을 자동화합니다. UX/UI 디자이너가 빠르게 프로필을 생성할 수 있어 목표 사용자에 대한 팀과 조직의 이해와 공감을 높일 수 있습니다. 자동 생성된 페르소나를 기반으로 디자이너는 사용자 중심 설계를 더욱 효과적으로 수행할 수 있습니다. • UX프레시아 (UXpressia)UX프레시아는 고객 경험 매핑을 위한 도구입니다. 페르소나와 여정 지도 생성을 지원하여 협업을 간소화합니다. 이 도구를 통해 팀은 사용자 경험을 시각화하고 개선점을 쉽게 식별할 수 있습니다. • 깃마인드 (GitMind)깃마인드는 아이디어 구성과 시각화를 위한 마인드 매핑 및 플로우차트 작성 도구입니다. 디자이너의 창의성을 향상시키고 팀 협업에 도움을 줍니다. 복잡한 개념을 명확하게 정리하고 팀원들과 공유할 수 있어 정의 단계에서 유용합니다. • 윔지컬 (Whimsical)윔지컬은 브레인스토밍, 계획 수립, 창작을 할 수 있는 협업 시각화 작업 공간입니다. 플로우차트, 와이어프레임, 마인드맵 등의 기능을 제공하여 아이디어를 구체화하고 공유하는 데 효과적입니다. • 보즈 (Boords)보즈는 온라인 스토리보딩 도구로, 사용자 플로우를 시각화하고 효율적으로 피드백을 수집하는 데 도움을 줍니다. UX 디자인에서의 협업을 강화하여 프로젝트의 방향을 명확히 하는 데 유용합니다. • 스토리보더 ai (Storyboarder ai)스토리보더 ai는 스토리보딩 프로세스를 간소화합니다. 아이디어를 빠르게 시각화하고 효율적인 스토리를 생성할 수 있어 영화 및 UX 디자인에 활용됩니다. 프로젝트의 비전을 시각적으로 표현하는 데 도움을 줍니다. 출처: <디자인 경험을 바꾸는 UX/UI 디자인 with AI>, 한빛미디어 3. 개발 단계 (Develop step)에서 쓸 수 있는 AI 툴 7종 UX/UI 디자인의 개발 단계에서는 실제 디자인을 구체화하고 프로토 타입을 만드는 작업이 이루어집니다. 이 단계에서는 와이어프레임을 기반으로 상세한 디자인을 완성하고, 상호 작용 가능한 프로토타입을 제작하여 사용자 경험을 테스트합니다. AI 도구들은 이러한 과정을 더욱 효율적으로 만들어 줍니다. • 미드저니텍스트 프롬프트를 기반으로 이미지를 생성하는 AI 도구입니다. UX/UI 디자인에서는 아이디어 스케치, 무드 보드 제작, 커스텀 아이콘 및 일러스트레이션 생성 등에 활용할 수 있습니다. 디자이너의 창의성을 확장시키고 빠른 시각화가 가능해 디자인 프로세스를 가속화합니다. • 어도비 파이어플라이 (Adobe firefly)어도비의 AI 기반 이미지 생성 및 편집 도구로, 텍스트로 이미지 생성, 이미지 편집, 벡터 이미지 색상 변경, 텍스트 효과 생성 등 다양한 기능을 제공합니다. UX/UI 디자인에서는 커스텀 이미지 제작, 아이콘 디자인, 배경 제거 등에 활용할 수 있어 디자인 작업의 효율성을 높여 줍니다. • 갈릴레오 AI (Galileo AI)입력한 텍스트를 UI 디자인으로 생성하는 도구입니다. 다양한 디자인 스타일과 컴포넌트 그리고 생성한 디자인을 편집할 수 있는 기능도 제공합니다. 빠른 프로토타이핑과 디자인 아이디어 탐색에 유용하여 디자이너의 작업 속도를 크게 향상시킬 수 있습니다. • 비질리 (Visily)누구나 쉽게 사용할 수 있는 AI 기반 UI 디자인 소프트웨어로, 텍스트 프롬프트나 스크린샷을 기반으로 고품질 와이어프레임과 프로토타입을 빠르게 생성할수 있습니다. 복잡한 디자인 작업을 단순화하고 디자인 프로세스를 가속화하는 데 도움을 줍니다. • 크리에이티 (Creatie)아이디어 구상부터 디자인, 협업, 프로토타이핑, 개발자 전달까지 전체 디자인 프로세스를 지원하는 종합 디자인 도구입니다. 디자인 시스템 구축, 컴포넌트 생성, 레이아웃 제안 등을 자동화하여 디자이너의 생산성을 크게 향상시킵니다. • 위자드 (Uizard)AI를 활용하여 앱, 웹사이트, 데스크톱 소프트웨어의 UI 디자인을 빠르게 생성할 수 있는 도구입니다. 텍스트 프롬프트나 스크린샷을 기반으로 다중 화면 프로토 타입을 생성하고, AI 기반 컴포넌트 수정 기능을 제공합니다. 협업 기능에 특화되어 있어 팀 프로젝트에 적합합니다. • 피그마 (Figma)디자인 및 프로토타이핑 도구로, AI 기능을 통합해 한층 강력해졌습니다. AI를 활용한 디자인 자산 검색, 레이어 자동 이름 지정, 텍스트 생성 및 번역, 배경 제거 등의 기능을 제공합니다. 또한 클릭 한 번으로 정적 디자인을 인터랙티브 프로토타입으로 변환할 수 있어 디자인 워크플로우를 크게 개선합니다. 출처: <디자인 경험을 바꾸는 UX/UI 디자인 with AI>, 한빛미디어 4. 전달 단계 (Deliver step)에서 쓸 수 있는 AI 툴 9종 UX/UI 디자인의 전달 단계는 최종 디자인을 구현하고 출시합니다. 이 단계에서는 프로토타입을 완성하고, 개발 팀과 협업하여 디자인을 구현한 다음 최종 제품을 테스트하고 출시합니다. • 메이즈 (Maze)사용자 테스트를 자동화하고 분석하는 AI 기반 도구입니다. 프로토타입을 업로드하면 사용자 행동을 추적하고 분석하여 인사이트를 제공합니다. AI가 인터뷰 데이터를 분석하고 주요 테마를 추출하며, 편향되지 않은 설문 질문을 생성합니다. 이를 통해 디자이너는 사용자 경험을 빠르게 최적화할 수 있습니다. • 비주얼아이즈 (VisualEyes)AI를 활용하여 시선 추적 연구를 시뮬레이션하는 도구입니다. 93% 정확도로 사용자의 주의 집중 영역을 예측하고 시각화합니다. 디자인 요소의 효과성을 평가하고 선호도 테스트를 수행할 수 있어 시간과 비용을 절약하면서 사용자 중심 디자인을 할 수 있습니다. • 클루이파이 (Clueify)웹사이트의 시각적 분석을 제공하는 AI 도구입니다. 약 92% 정확도로 어떤 요소가 더 많은 주의를 끄는지 평가하고, 디자인의 명확성과 심미성을 평가합 니다. A/B 테스트를 빠르게 구현하고 전환율을 높일 수 있도록 지원하여 데이터 기반의 디자인 최적화가 가능합니다. • 웹플로우 (Webflow)AI를 활용하여 코딩 없이 웹사이트를 디자인하고 구축할 수 있는 플랫폼입니다. 콘텐츠 생성, SEO 최적화, 이미지 ALT 태그 생성 등을 자동화할 수 있습니다. 또한 AI 기반 템플릿 커스터마이징으로 빠르게 웹사이트를 시작할 수 있어 디자 인에서 개발까지의 과정을 가속화합니다. • 프레이머 (Framer)AI를 활용하여 원클릭으로 웹사이트를 제작할 수 있는 도구입니다. 사용자가 원하는 웹사이트를 문장으로 설명하면 AI가 자동으로 레이아웃을 생성합니다. 폰트, 색상 팔레트 변경이 자유롭고 CMS 관리 기능도 제공하여 콘텐츠 관리가 용이 합니다. 호스팅 서비스도 제공하여 즉시 웹사이트를 공개할 수 있습니다. • 버블 (Bubble)코딩 없이 웹 애플리케이션을 만들 수 있는 노코드 플랫폼입니다. AI 기능을 통해 데이터베이스 구조 설계, 워크플로우 자동화, 사용자 인터페이스 생성을 지원 합니다. 복잡한 로직도 시각적 인터페이스로 구현할 수 있어 아이디어를 빠르게 프로토 타입으로 만들고 실제 제품으로 발전시킬 수 있습니다. • 프론티 (Fronty)이미지나 스크린샷을 HTML과 CSS 코드로 변환하는 AI 기반 도구입니다. 디자인 이미지를 업로드하면 AI가 UI 요소를 인식하고 반응형 웹사이트 코드를 생성합니다. 생성된 코드는 SEO에 최적화되어 있으며, 내장된 비주얼 빌더로 코드를 수정할 수 있어 디자인에서 개발로 원활하게 전환할 수 있습니다. • 퀘스트 AI (Quest AI)피그마 디자인을 리액트 컴포넌트로 변환하는 AI 도구입니다. 코드 작성 없이 리액트 앱을 구축할 수 있으며, 애니메이션 라이브러리가 내장되어 있습니다. 생성된 코드는 깃허브 GitHub 로 푸시할 수 있고, 반응형 디자인을 지원합니다. 디자인 시스템과의 통합이 원활하여 디자인에서 개발까지의 과정을 가속화합니다. • 빌더 ai (Builder ai)AI를 활용하여 웹사이트와 앱을 빠르게 구축할 수 있는 플랫폼입니다. 직관적인 드래그 앤 드롭 인터페이스와 AI 생성 기능을 결합하여 사용자 경험을 최적 화합니다. 콘텐츠 관리, A/B 테스팅, 개인화 기능을 제공하며, API와의 통합이 용이해 복잡한 기능도 구현할 수 있습니다. 디자이너와 개발자 간의 협업을 원활하게 합니다. 출처: <디자인 경험을 바꾸는 UX/UI 디자인 with AI>, 한빛미디어 이처럼 다양한 생성형 AI를 활용하여 UX/UI 디자인 프로세스를 진행하면 이전보다 높은 생산성과 자동화를 경험할 수 있을 것입니다. 이러한 자동화를 통해 UX/UI 디자이너는 이전보다 많은 시간적 여유를 가지게 되어, 창의적인 활동과 사용자에게 정말 필요한 새로운 경험을 설계하는 데 더 많은 시간과 에너지를 투자할 수 있을 것입니다.디자이너는 실행자에서 전략가로, 심미적 감각에서 비즈니스 감각까지 점점 더 넓은 역할로 진화해왔습니다. 그러나 '창의성'을 기본 역량으로 지녀야 한다는 것은 시대가 변해도 동일하죠.『디자인 경험을 바꾸는 UI/UX 디자인 with AI』는 UI/UX 디자이너가 본질적인 역량인 ‘창의성’에 집중하면서도 업무의 효율을 높일 수 있도록, 실무에 AI를 효과적으로 활용하는 방법을 안내하는 실전서입니다. 책은 챗GPT, 미드저니, 웹플로우, 피그마 등 실제 AI 도구들을 어떻게 사용하고, 어떤 프롬프트로 요청해야 하는지 구체적이고 체계적으로 소개합니다. UX 디자이너는 물론, AI 시대에 협업 전략이 필요한 PM, PO, 기획자까지. 누구나 제로베이스에서 프로처럼 프로덕트를 완성할 수 있는 실질적인 가이드가 될 것입니다.⠀AI와 UI/UX 디자인의 접점에서 18년간 연구와 실무를 이끌어온 유훈식 교수의 통찰력이 집약된 이 책을 통해 프롬프트 엔지니어링, AI 기반 리서치, 이미지 모델링, UX 자동화 도구 활용법 등 실무 중심의 예제를 익히고 디자이너의 창의성과 생산성을 동시에 끌어올리는 AI 파트너십 전략을 수립해 보시기 바랍니다.

생성형 AI 시대, Java 개발자를 위한 가이드 『이것이 Spring AI다』 저자 인터뷰

생성형 AI 시대, Java 개발자를 위한 가이드 『이것이 Spring AI다』 저자 인터뷰

Q. 안녕하세요, 신용권 저자님! 먼저, 간단히 자기소개를 부탁드립니다. 안녕하세요, 『이것이 Spring AI다』 를 집필한 저자 신용권입니다. 저는 25년 동안 시스템 제어와 애플리케이션 개발자로 활동해 온 개발자이자, IT 교육자로도 일하고 있습니다. 메카트로닉스를 전공했고, 삼성항공 시스템 설계 파트에서 하드웨어 제어용 소프트웨어를 개발하면서 커리어를 시작했습니다. 이후에는 여러 교육기관에서 재직자와 전문가들을 대상으로 위탁 교육을 진행했으며, 현재는 한국소프트웨어산업협회에서 교수로 근무하고 있습니다. 주로 오픈 소스 프레임워크, 안드로이드, IoT, 스택 애플리케이션 분야에서 현업 재직자와 예비 개발자들의 역량을 강화하는 교육을 맡고 있고요. 저서로는 『혼자 공부하는 자바』, 『이것이 자바다』가 있습니다. 이번에는 『이것이 Spring AI다』를 통해 Java 개발자들이 생성형 AI 시대를 자신 있게 맞이할 수 있도록 돕고자 했습니다. Q. 최근 생성형 AI가 급속히 확산되고 있는데, 저자님은 이 흐름을 어떻게 보고 계신가요? 생성형 AI는 이제 더 이상 미래의 기술이 아니라, 이미 우리 일상 깊숙이 들어와 있습니다. 챗봇이나 음성 비서, 이미지 생성, 자동 문서 작성, 코딩 지원까지… 활용 영역이 매일같이 확장되고 있죠. 그 중심에는 대규모 언어 모델, 즉 LLM이라는 강력한 기술이 자리하고 있습니다. 저는 이 흐름이 단순한 기술 유행을 넘어, 소프트웨어 개발 패러다임 자체를 바꾸고 있다고 생각합니다. 이런 맥락 속에서, 자바 개발자들이 익숙한 환경 안에서 최신 AI를 어떻게 다룰 수 있을지를 고민하다가 이 책을 쓰게 되었습니다. Q. 이번 책의 주제인 Spring AI는 무엇이고, Java 개발자에게 어떤 의미가 있나요? AI 애플리케이션이 벡터 저장소를 사용하는 흐름Spring AI에서 도구 호출이 이루어지는 전반적인 흐름 Spring AI는 LLM을 Java 생태계에 통합하기 위한 Spring 프로젝트입니다. 친숙한 Spring Boot 프로그래밍 모델을 유지하면서도, 프롬프트 구성이나 스트리밍 응답 처리, 벡터 저장소 연동, 도구 호출 같은 복잡한 기능들을 비교적 손쉽게 구현할 수 있게 해줍니다. Java 개발자 입장에서 Spring AI를 처음 접했을 때, “아, 이제 파이썬에만 의존하지 않고도 본격적으로 AI 기능을 활용할 수 있겠구나” 하는 가능성과 실용성을 강하게 느꼈습니다. 그것이 바로 집필의 큰 동기가 되었죠. Q. 이 책이 단순한 API 설명서가 아니라 실습 중심으로 구성되었다고 하셨는데, 독자들이 특히 주목해야 할 부분은 무엇일까요? 독자들이 실제 애플리케이션을 만들 수 있도록 돕는 데 초점을 맞췄습니다. 예를 들어, 텍스트·음성·이미지 같은 멀티모달 처리를 어떻게 구성할 수 있는지, LLM이 생성한 응답을 어떻게 구조화할 수 있는지, 또 RAG나 도구 호출, 대화 기억처럼 실제 서비스에 필요한 고급 기능들을 어떻게 적용할 수 있는지를 다룹니다. 나아가 MCP 기반 아키텍처를 통해 LLM과 외부 시스템을 유연하게 연결하는 전략도 설명했어요. 즉, 단순히 기능 나열이 아니라 실무에서 “바로 써먹을 수 있는” 관점으로 접근했습니다. Q. 책의 구성은 어떻게 되어 있나요? 『이것이 Spring AI다』는 크게 두 부분으로 나눴습니다. 본문은 필수 학습 내용으로, 총 12개의 챕터에서 Spring AI를 이해하는 데 꼭 필요한 핵심 주제들을 다루고 있고요. 부록은 선택 학습 내용이라서, 독자들이 필요할 때 참고할 수 있도록 보강 자료를 넣었습니다. Spring AI는 Java 기반의 대표적인 웹 프레임워크인 Spring 위에서 동작하는 AI 통합 프레임워크입니다. 기존에는 AI 개발과 연동을 위해 주로 파이썬 생태계(PyTorch, TensorFlow 등)에 의존했잖아요? 그런데 Spring AI를 활용하면 Spring 환경 안에서 챗봇, 생성형 AI, 임베딩, RAG(검색 증강 생성) 같은 최신 기능을 쉽게 구현할 수 있습니다. Q. 학습 방식이나 접근법은 어떤 점에 중점을 두셨나요? 저는 단순히 기능만 나열하는 책은 쓰고 싶지 않았습니다. 그래서 기본 환경 설정부터 프로젝트 생성, API 활용, 프롬프트 엔지니어링까지 실습 중심으로 설명을 풀어갔습니다. 각 장을 따라가다 보면 자연스럽게 Spring AI의 전체적인 흐름을 체계적으로 이해할 수 있도록 구성했어요. 덕분에 Java 개발자라면 별도의 언어를 새로 배우지 않아도, 익숙한 Spring 프레임워크 안에서 AI 기능을 안정적이고 효율적으로 통합할 수 있을 겁니다. Q. 마지막으로, 이 책이 가장 도움이 될 독자는 어떤 분들일까요? Spring Boot 기반 백엔드 개발자라면 특히 도움이 될 것입니다. LLM을 서비스에 통합하고 싶거나, RAG나 도구 호출 같은 고급 기능을 자바 환경에서 구현하려는 분들에게 적합하죠. 또한 AI Agent 애플리케이션을 기획 중인 분, 음성 대화 챗봇이나 로봇을 만들고자 하는 분들도 이 책을 통해 많은 인사이트를 얻으실 수 있을 겁니다. 집필 과정에서 Spring AI는 굉장히 빠르게 진화하고 있었는데, 가능한 한 최신 버전 기준으로 예제와 설명을 구성하려고 노력했습니다. 저는 이 책이 생성형 AI 시대를 살아가는 Java 개발자들에게 든든한 나침반이 되기를 바랍니다. 이 책이 독자 여러분의 기술 여정에 도움이 되기를 바랍니다. 감사합니다. 텍스트 및 음성 대화에서 MCP Server까지 Spring AI의 모든 것 『이것이 Spring AI다』

스프링 MVC로 간단한 웹 애플리케이션 개발하기

스프링 MVC로 간단한 웹 애플리케이션 개발하기

스프링 MVC model-view-controller (모델-뷰-컨트롤러)는 스프링 프레임워크에서 가장 중요한 모듈입니다. 강력한 스프링 IoC 컨테이너를 기반으로 만들어졌으며 간단한 구성으로 스프링 IoC 컨테이너의 기능을 폭넓게 사용할 수 있습니다.MVC는 일반적인 UI 디자인 패턴입니다. 이 패턴은 애플리케이션에서 역할을 기준으로 모델, 뷰, 컨트롤러를 나눔으로써 UI와 비즈니스 로직을 분리합니다. 모델은 뷰가 화면에 보여 줄 애플리케이션 데이터를 캡슐화하고, 뷰는 비즈니스 로직 없이 오로지 데이터를 보여 주며, 컨트롤러는 사용자에게서 요청을 받고 백엔드 서비스를 호출해 비즈니스를 처리하는 역할을 합니다. 백엔드 서비스가 비즈니스 처리를 끝내고 화면에 보여 줄 데이터를 반환하면 컨트롤러는 이 데이터를 모아 뷰에 출력할 모델을 만듭니다. MVC 패턴의 핵심은 UI와 비즈니스 로직을 분리해서 서로 영향을 주지 않고 독립적으로 변경할 수 있게 한다는 점입니다.스프링 MVC 애플리케이션에서 모델은 보통 서비스 계층에서 처리되고 퍼시스턴스 계층에서 저장되는 객체입니다. 뷰는 JSP Java Server Pages , 타임리프 Thymeleaf, 프리마커 FreeMarker 등으로 작성한 템플릿이지만 엑셀이나 PDF 파일, RESTful 웹 서비스로도 정의할 수 있습니다. 우선 스프링 MVC의 핵심 동작 과정을 이해하기 위해, 가장 기본적인 웹 애플리케이션 구성부터 차근차근 따라가 보겠습니다.프런트 컨트롤러 front controller 는 스프링 MVC에서 가장 중요한 컴포넌트입니다. 아주 간단한 스프링 MVC 애플리케이션이라면 웹 배포 서술자에 프런트 컨트롤러의 서블릿만 구성하면 됩니다. 보통 디스패처 서블릿(DispatcherServlet)이라는 스프링 MVC 컨트롤러가 스프링 MVC 프레임워크의 프런트 컨트롤러로 작동하며, 모든 웹 요청이 디스패처 서블릿을 거쳐 처리됩니다. 스프링 MVC 애플리케이션에 들어온 웹 요청은 제일 먼저 컨트롤러가 받으며, 스프링 웹 애플리케이션 컨텍스트에 구성된 다양한 컴포넌트나 컨트롤러에 적용된 애너테이션을 구성해 요청을 처리하는 데 필요한 작업을 수행합니다. 스프링에서 컨트롤러는 @Controller나 @RestController 애너테이션으로 정의합니다. @Controller가 HTML 뷰를 반환하는 전통적인 웹 애플리케이션에 주로 사용된다면, @RestController는 @Controller와 @ResponseBody를 합쳐 객체를 JSON 또는 XML 형태로 반환하는 데 사용됩니다. 이는 주로 RESTful API를 개발할 때 유용합니다. @Controller 애너테이션이 적용된 클래스(컨트롤러 클래스)가 요청을 받으면 요청을 처리하는 적절한 핸들러 메서드를 찾습니다. 컨트롤러 클래스는 각 요청을 하나 이상의 핸들러 메서드에 매핑하며 컨트롤러 클래스의 메서드에 @RequestMapping 애너테이션을 적용해 핸들러 메서드를 지정할 수 있습니다. @RequestMapping 외에도 HTTP 메서드에 따라 @GetMapping, @PostMapping 등 더 구체적인 애너테이션을 사용할 수 있습니다. 핸들러 메서드의 시그니처는 일반적인 자바 클래스와 마찬가지로 특별한 제약이 없습니다. 메서드 이름을 임의로 지정하고, 메서드 인수를 다양하게 정의하며, 애플리케이션 로직에 따라 다양한 타입(예: String, void)의 값을 반환할 수 있습니다. 앞으로 @RequestMapping 애너테이션이 적용된 핸들러 메서드에서 사용하는 다양한 메서드 인수를 만날 것입니다. 다음은 미리 알아 두면 좋을 몇 가지 유용한 인수 타입입니다. HttpServletRequest, HttpServletResponse@RequestParam 애너테이션이 적용된 임의 타입arbitrary type의 요청 매개변수@RequestAttribute 애너테이션이 적용된 임의 타입의 요청 속성@ModelAttribute 애너테이션이 적용된 임의 타입의 모델 속성@CookieValue 애너테이션이 적용된 요청에 포함된 쿠키값핸들러 메서드에서 모델에 속성을 추가하는 데 사용하는 Map과 ModelMap핸들러 메서드에서 객체 바인딩, 유효성 검증 결과를 가져올 때 필요한 Errors와 BindingResult핸들러 메서드에서 세션 처리를 완료했음을 알리는 데 사용하는 SessionStatus 컨트롤러는 먼저 적절한 핸들러 메서드를 선택하고 해당 핸들러 메서드에 요청을 전달해 로직을 실행합니다. 보통 컨트롤러는 백엔드 서비스를 호출해 요청을 처리하며 핸들러 메서드는 다양한 입력 인수에 정보를 추가하거나 삭제해 스프링 MVC 흐름을 이어갈 수 있도록 구성합니다. 핸들러 메서드는 요청을 처리한 후 반환값으로 지정된 뷰에 제어권을 위임합니다. 핸들러 메서드의 반환값으로는 실제 뷰 구현체보다 파일 확장자를 명시하지 않은 논리 뷰 이름을 지정하는 편이 더 유연해서 좋습니다. 핸들러 메서드의 반환값은 논리 뷰 이름을 나타내는 String이거나 void입니다. void일 때는 논리 뷰 이름이 핸들러 메서드나 컨트롤러 이름 기준으로 결정됩니다. 뷰에서는 얼마든지 핸들러 메서드의 인수에 접근할 수 있으므로 컨트롤러에서 뷰로 데이터를 전달하는 데 문제가 없습니다. 예를 들어 핸들러 메서드가 Map과 SessionStatus 타입 객체를 인수로 받고 핸들러 메서드에서 값을 수정하더라도 반환하는 뷰에서 수정된 동일한 객체에 접근할 수 있습니다. 컨트롤러 클래스는 뷰 리졸버 view resolver 를 이용해 전달받은 논리 뷰 이름을 실제 뷰 구현체(예: user.jsp, todos.html, report.pdf )로 해석합니다. 뷰 리졸버는 인터페이스의 구현체로써 웹 애플리케이션 컨텍스트에 빈으로 구성하며, 논리 뷰 이름에 해당하는 실제 구현체(예: HTML, JSP, PDF)를 반환합니다. 컨트롤러 클래스가 논리 뷰 이름으로 실제 뷰 구현체를 해석하면, 해당 뷰 구현체는 로직에 따라 핸들러 메서드가 전달한 객체를 렌더링 합니다. 뷰의 역할은 어디까지나 핸들러 메서드의 로직에 추가된 객체를 사용 자에게 정확하게 보여 주는 것입니다. 요약하자면, 스프링 MVC의 요청 처리 과정은 요청 → DispatcherServlet → 컨트롤러 → 뷰 리졸버 → 뷰 순서로 정리할 수 있습니다.위 콘텐츠는 『스프링 6 레시피(5판)』의 내용을 기반으로 작성하였습니다.

데이터는 답이 아닌 질문을 품고 있다 - 디자이너를 위한 데이터 활용법

데이터는 답이 아닌 질문을 품고 있다 - 디자이너를 위한 데이터 활용법

데이터를 기반으로 디자인 의사결정을 처음 시도할 때 많은 분들이 이런 기대를 갖곤 합니다. “데이터만 보면 뭘 어떻게 해야 할지 바로 알 수 있겠지?” “이 안에 정답이 있겠지?” 데이터 입장에서는 조금 난감할 수 있습니다. 왜냐하면 데이터는 정답을 가지고 있지 않기 때문입니다. 오히려 질문을 품고 있습니다. 그것도 단순한 질문이 아니라 ‘사람’에 대한 질문 말이죠. 예를 들어 디자이너가 ‘페이지별 이탈률’ 데이터를 받았다고 해보겠습니다. 다른 페이지의 이탈률은 평균 10%~30%인데 특정 페이지만 이탈률이 약 80%인 것을 발견했습니다. 답을 찾는 UX/UI 디자이너 또는 프로덕트 디자이너는 ‘이 페이지에는 이탈을 유발하는 문제가 있다’ 라는 결론을 내립니다. 그러고는 갑자기 레이아웃, 컬러, 폰트, 버튼 크기, 문구 등을 수정하기 시작합니다. 하지만 정말 데이터는 ‘이 페이지에는 이탈을 유발하는 문제가 분명히 있다’라는 정답을 가지고 있었던 걸까요? 아닙니다. 사실 데이터는 질문을 건네고 있었습니다. ● 사용자들은 이 페이지에 어떤 기대를 가지고 왔을까?● 그들이 찾으려 했던 정보는 무엇이었을까?● 그들은 이전 페이지에서 무엇을 보고 이 페이지로 왔을까?● 그들은 왜 하필 이 구간에서 떠나기로 결정했을까?● 그들은 떠난 뒤 다시 왔을까? 아님 다시는 오지 않았을까? 이 질문들을 잘 들여다보면 공통점이 하나 있는데 바로 모든 질문의 주어가 사람이라는 점입니다. 화면 디자인이나 특정한 기능보다는 그것을 사용하는 사람을 먼저 이해해야 하기 때문입니다. 그래서 데이터를 기반으로 UX 디자인을 할 때 가장 먼저 해야 할 일은 ‘여기 버튼 클릭률이 왜 낮지?’가 아니라 ‘사용자는 이 버튼을왜 누르지 않았지?’라고 질문하는 것입니다. 주어에 기능 대신 사용자를 두면 자연스럽게 사용자를 궁금해하는 질문으로 바뀝니다. 그러면 질문의 범위는 화면을 넘어 훨씬 넓은 지점까지 확장됩니다. ● 사용자는 왜 많은 커머스 가운데 우리 서비스를 이용하는 걸까?● 사용자는 왜 헤어디자이너라는 직업을 선택한 걸까?● 사용자는 왜 반려동물을 키우기 시작한 걸까?● 사용자는 왜 갤럭시가 아니라 아이폰을 고집하는 걸까? 왜 이렇게 사용자의 행동을 궁금해하는 것이 중요할까요? 바로 진정한 문제 해결이 가능해지기 때문입니다. 표면적인 데이터만 보고 디자인을 수정하면 임시방편에 그치기 쉽습니다. 하지만 사용자 행동의 근본적인 동기와 맥락을 이해하면 그들에게 진정으로 필요한 솔루션을 제공할 수 있습니다. 결제 페이지의 이탈률을 개선한다고 가정하겠습니다. 문제를 찾기 위해 화면이나 특정 기능만을 본다면 ‘결제 버튼을 못찾아서 이탈했다’와 같은 답을 찾기 쉽습니다. 그리고 버튼을 수정하겠죠. 그러나 사람을 향해 질문한다면 ‘결제 전 배송비를 확인하고 싶었는데 찾지 못해서 이탈했다’와 같은 답을 얻을 수 있습니다. 그러면 결제 전에 배송비 정보를 잘 보이게 배치하여 그들에게 정말 필요한 솔루션을 제공해줄 수 있게 되는 거죠. 사용자의 목소리가 모두 정답은 아니다UX 디자인에서 사용자 피드백은 필수입니다. 그래서 우리는 설문 조사, 리뷰, 고객 응대 자료, 유저 인터뷰 등에서 사용자의 목소리를 찾곤 하죠. 하지만 모든 사용자 피드백이 유용하거나 의미 있는 통찰로 이어지는 것은 아닙니다. 오히려 잘못된 사용자 피드백에 지나치게 의존하면 서비스 품질이 낮아지거나 이도 저도 아닌 제품이 되어버리기도 합니다. 최악의 경우엔 사용자 목소리만 믿고 제품이나 서비스를 시장에 내놓았는데 그들의 말과 다르게 시장에서 외면받아 역사의 뒤안길로 사라져버리기도 합니다. 사용자의 목소리를 왜 그대로 믿으면 안 될까요? 크게 네 가지 이유가 있습니다. 1) 사용자는 다양하기 때문에 요구사항이 모순되기 쉽다서비스는 하나여도 이용하는 사람은 다양하며 각각 조금씩 다른 이유로 해당 서비스를 이용합니다. 모든 사용자가 똑같은 니즈와 기대를 가지고 있지 않아요. 각 사용자의 경험은 개인의 상황에 따라 다르기 때문에 피드백이 서로 충돌하거나 상반되기도 합니다. 어떤 사용자는 기능을 더 단순화해 달라고 요청하는 반면 다른 사용자는 기능을 더 추가해 달라고 할 수도 있습니다. 음악 스트리밍 서비스에서 어떤 사용자는 ‘재생 목록 추천 기능이 너무 많아서 복잡하다’고 하는 반면 다른 사용자는 ‘더 다양한 맞춤 추천이 필요하다’고 하는 등 서로 상반된 요구사항이 동시에 들어올 수 있는 거죠. 이런 모순적인 피드백을 무작정 반영하면 제품의 핵심 방향성을 잃을 수 있습니다. 2) 사용자 피드백이 소수의 의견일 수 있다우리는 문제가 없을 때는 아무 말도 하지 않고 넘어갑니다. 요구사항이나 불만사항은 오히려 문제가 생겼을 때 말합니다. 또는 이용하는 데 크게 불편하지 않으면 내 의사를 전달하기 귀찮아서라도 그냥 이용하기도 하고요. 반대로 너무 마음에 안 들 경우 의사 전달을 하지 않은 채 서비스를 떠나버리기도 합니다. 또 어떤 사용자는 다른 사용자에 비해 기능의 세부사항에 더욱 민감할 수 있습니다. 상대방이 세세하게 말할수록 우리는 그 기능이 정말 문제처럼 인식되어, ‘이 문제를 해결해야만 해’라고 생각하기 쉽습니다. 서비스가 너무 마음에 들어서 큰 목소리로 애정을 드러내는 사용자 역시 있습니다. 이런 경우 그 하나의 목소리가 너무 달콤해 서비스를 만드는 사람은 ‘모두 이 사용자와 같은 목소리를 내고 있다’고 착각하기 쉽습니다. 어떤 목소리든 고객의 소리는 대부분 적극적인 성향을 가진 사용자들이 냅니다. 그들이 모든 사용자를 대표하는 것이 아님에도 소수의 니즈를 다수의 니즈로 착각하여 이들의 의견을 전부 수용하면 정작 조용히 잘 이용하던 다수의 사용자를 잃을 수도 있습니다. 3) 사용자는 자신의 불편함을 정확히 설명하지 못한다사용자는 서비스를 넓은 시야로 볼 수 없고 관련한 전문 지식이 없기 때문에 문제의 원인을 정확히 진단하기 어렵습니다. 그래서 대부분 ‘불편하다’는 느낌은 받지만 정확히 어떤 점이 문제인지는 말하기 쉽지 않죠. 이럴 때 사용자가 제안하는 해결책은 눈에 보이는 것에만 그치는 경우가 많습니다. 이를테면 ‘버튼이 작다’라는 의견의 진짜 문제는 크기보다는 그들이 버튼 위치를 인지하지 못한 데 있는 것처럼요. 아마도 사용자는 이용하면서 ‘글쓰기 버튼이 어디 있는 거야. 아, 여기 있네. 아니 버튼 크기를 이렇게 작게 해 놓으니까 눈에 안 띄지’라고 생각한 뒤 “글쓰기 버튼이 작아서 찾기 어렵습니다”라는 피드백을 적었을 수 있습니다. 이런 경우 문제의 본질은 위치이기 때문에 버튼의 크기를 키워도 “글쓰기 버튼의 색상을 빨간색으로 바꿔주세요”와 같은 제안으로 다시 돌아올 수 있습니다. 4) 사용자는 창의적인 해결책을 제시하지 못한다다른 서비스에서 봤던 기능을 요구하거나 과거에 경험해봤던 기능을 요구하는 경우가 있습니다. 자신의 경험이나 들은 정보 안에서만 문제를 찾고 해결 방법을 떠올리는 것이죠. 왜냐하면 사용자는 익숙한 것에서 안정감을 느끼며 자신이 경험해보지 못한 혁신적인 해결책은 상상하기 어렵기 때문입니다. 아직 먹어보지 못한 음식의 맛을 상상하기 어렵듯이 사람들은 기존의 관습을 벗어난 혁신적인 해결책을 제시하기 어렵습니다.위 글은 『데이터 삽질 끝에 UX가 보였다』에서 내용을 발췌하여 작성하였습니다.

Spring AI로 LLM에 대화 기억 기능 추가하기

Spring AI로 LLM에 대화 기억 기능 추가하기

챗봇을 만들어 본 분들이라면 이런 경험이 있으실 겁니다. 사용자가 한참 대화를 이어가다가 다시 질문을 던졌을 때, 챗봇이 앞선 맥락을 전혀 이해하지 못하고 전혀 다른 답을 내놓는 경우 말이죠. 대규모 언어 모델LLM은 기본적으로 상태를 저장하지 않기 때문에, 이전 대화 내용을 기억하거나 그에 기반한 응답을 생성할 수 없습니다. 이러한 한계를 보완하기 위해 Spring AI는 대화 기억Chat Memory 기능을 제공합니다. 이 기능을 통해 LLM과의 여러 차례 대화에서 주고받은 내용을 저장하고, 이후 대화에서 이를 조회해 문맥을 유지할 수 있습니다. 그렇다면 대화 기억과 대화 기록에 대한 차이는 무엇일까요? ✅ 대화 기억과 대화 기록의 차이 • 대화 기억(Chat Memory)현재 세션에서 LLM과 대화할 때 맥락context 유지하기 위해 사용하는 메시지들(UserMessage + AssistantMessage)입니다. 세션이 종료되면 없어지거나, 영구 저장할 수도 있습니다. • 대화 기록(Chat History)현재 세션뿐만 아니라, 과거 세션에서 주고받은 모든 메시지들(UserMessage + Assistant Message )을 말합니다. 과거의 대화 기억들이 꾸준히 저장된 것을 대화 기록입니다. Spring AI가 제공하는 대화 기억Chat Memory은 현재 대화를 이어가기 위한 문맥을 관리하도록 설계 되었기 때문에 현재 대화와 관련된 메시지만을 목적으로 합니다. 따라서 전체 대화 기록을 관리하는 최적의 솔루션이 아닙니다. 전체 대화 기록을 유지해야 한다면, Spring Data 모듈JPA, JDBC을 이용 하는 방식을 고려해야 합니다. Spring Ai는 대화 기억을 위해 기억 유형과 기억 저장소로 기능을 분리합니다. 기억 유형은 몇 개의 메시지를 저장할지, 어떤 기간 동안 저장할지, 전체 메시지 양을 얼마로 할지를 결정하고, 기억 저장소는 단지 메시지를 저장하고 조회하는 일만 하게 됩니다. Spring AI는 ChatMemory 인터페이스를 통해 다양한 기억 유형을 구현할 수 있도록 지원합니다. 어떤 정보를 기억할지, 그리고 언제 기억을 삭제할지는 ChatMemory 인터페이스를 구현한 클래스 에 따라 달라집니다. ChatMemory 인터페이스는 대화 기억을 관리하기 위해 기본 메소드들을 정의하고 있습니다. 대화 기억 추가add, 검색get, 삭제clear할 수 있는 다음 메소드들을 가지고 있습니다. public interface ChatMemory { void add(String conversationId, List<Message> messages); List<Message> get(String conversationId); void clear(String conversationId); } conversationId는 사용자 ID입니다. 로그인한 사용자 아이디를 사용해도 좋고, 웹 환경이라면 서버에서 생성 되는 세션 ID를 사용해도 좋습니다.add ( ) 메소드는 사용자 ID와 함께 대화 기억을 저장합니다.get()메소드는사용자ID로저장된대화기억을검색해서가져옵니다.clear()는사용자ID로저장된대화기억을삭제합니다. ChatMemory의 기본 구현체는 MessageWindowChatMemory입니다. 이 클래스는 지정된 메시지 최대 개수(메시지 윈도우)까지 메시지를 유지합니다. 메시지 수가 메시지 윈도우를 초과하면 오래된 메시지부터 제거합니다. 기본 메시지 윈도우 크기는 20개입니다. 메시지 윈도우를 변경하고 싶다면 다음과 같이 MessageWindowChatMemory를 명시적으로 빌드할 때, maxMessages ( )를 통해 설정하면 됩니다. ChatMemory memory = MessageWindowChatMemory.builder() .maxMessages(10) .build(); Spring AI는 ChatMemoryRepository 인터페이스를 통해 다양한 저장소에 대화 기억을 저장할 수 있습니다. 다음은 ChatMemoryRepository를 구현한 클래스들입니다. InMemoryChatMemoryRepository: 컴퓨터 하드웨어 메모리에 저장합니다.JdbcChatMemoryRepository: 관계형 데이터베이스를 저장합니다.CassandraChatMemoryRepository: ApacheCassandra를 이용해서 시계열로 저장합니다. Spring AI는 다른 저장소를 위한 구성이 없으면, 기본적으로 MessageWindowChatMemory를 이용해서 ChatMemory 빈을 자동 생성합니다. 그리고 대화 기억 저장소는 InMemoryChat MemoryRepository를 사용합니다. 자동 구성된 ChatMemory 빈은 사용자 ID별로 최대 20개의 메시지를 컴퓨터 메모리에 저장합니다. 이렇게 자동 구성된 ChatMemory 빈은 다음과 같이 필드로 주입하거나, 생성자 주입할 수 있습니다. @Autowired ChatMemory chatMemory; 또는 ClassName(ChatMemory chatMemory) { } ✅ 대화 기억을 위한 Advisor ChatMemory가 대화 기억을 제공하더라도, 이를 실제 프롬프트에 포함시키는 작업이 필요합니다. 이 역할을 담당자가 바로 Advisor입니다. Advisor는 LLM에게 프롬프트를 전송하기 전에 전처리 작업으로 ChatMemory로부터 받은 대화 기억을 시스템 텍스트 또는 메시지 묶음으로 프롬프트에 추가합니다. 그리고 LLM으로부터 응답이 오면, 후처리 작업으로 사용자의 질문UserMessage과 LLM의 응답AssistantMessage 을 ChatMemory를 이용해서 대화 기억 저장소에 저장합니다. • MessageChatMemoryAdvisorMessageChatMemoryAdvisor는 ChatMemory에서 받은 대화 기억을 사용자 메시지User Message 와 AI 메시지AssistantMessage들로 생성합니다. 그리고 이 메시지들을 프롬프트에 추가합니다. 다음은 MessageChatMemoryAdvisor를 빌드할 때 ChatMemory를 제공하는 코드입니다. MessageChatMemoryAdvisor advisor = MessageChatMemoryAdvisor.builder(chatMemory). build(); 다음은 MessageChatMemoryAdvisor를 ChatClient의 기본 Advisor로 추가하는 코드입니다. ChatClient chatClient = chatClientBuilder .defaultAdvisors( MessageChatMemoryAdvisor.builder(chatMemory).build() ) .build(); • PromptChatMemoryAdvisorPromptChatMemoryAdvisor는 ChatMemory로부터 받은 대화 기억을 텍스트 형태로 시스템 메시지에 포함시킵니다. 다음은 PromptChatMemoryAdvisor를 빌드할 때 ChatMemory를 제공하는 코드입니다. PromptChatMemoryAdvisor advisor = PromptChatMemoryAdvisor.builder(chatMemory).build(); 다음은 PromptChatMemoryAdvisor를 ChatClient의 기본 Advisor로 추가하는 코드입니다. ChatClient chatClient = chatClientBuilder .defaultAdvisors( PromptChatMemoryAdvisor.builder(chatMemory).build() ) .build(); 이렇게 Spring AI의 ChatMemory와 Advisor를 활용하면 기본적으로 이전 대화를 기억하지 못하는 LLM에서도 자연스러운 대화 흐름을 구현할 수 있습니다. 위 콘텐츠는 『이것이 Spring AI다』의 내용을 재구성하여 작성되었습니다.

한빛+는 콘텐츠, 교육, 기술 분야의 다양한 기업과 함께합니다.

ITCEN global