반응형 전체 글675 T5와 BART: 인코더-디코더로 모든 과제를 텍스트로 NLP · Transformer T5와 BART: 인코더-디코더로 모든 과제를 텍스트로 번역도, 요약도, 분류도 전부 "텍스트 입력 → 텍스트 출력". 통합된 프레임으로 NLP를 다시 정의하다.BERT는 인코더만, GPT는 디코더만 사용한다. T5와 BART는 둘을 모두 갖춘 인코더-디코더(seq2seq) 구조다. 인코더가 입력 전체를 양방향으로 이해하고, 디코더가 그 이해를 바탕으로 새 텍스트를 자기회귀적으로 생성한다. 이해와 생성을 한 모델 안에서 결합하므로 번역·요약처럼 입력을 변환해 출력하는 과제에 자연스럽게 맞는다.T5: 모든 것을 Text-to-Text로구글의 T5(Text-to-Text Transfer Transformer)는 과감한 통일을 시도했다. 분류든 번역이든 요약이든, 모든 NL.. 2026. 9. 29. GPT: 다음 단어를 예측하며 세상을 학습한 디코더 NLP · Transformer GPT: 다음 단어를 예측하며 세상을 학습한 디코더 "다음에 올 단어를 맞혀라"는 단순한 목표가, 어떻게 글쓰기·번역·추론을 모두 해내는 모델로 이어졌는가.GPT(Generative Pre-trained Transformer)는 OpenAI가 발표한 모델 계열로, 트랜스포머의 디코더를 쌓아 만든다. BERT가 문맥을 양방향으로 읽는 '이해' 모델이라면, GPT는 왼쪽에서 오른쪽으로 다음 토큰을 하나씩 예측하는 자기회귀(autoregressive) '생성' 모델이다.인과적 어텐션GPT의 핵심은 마스크드 셀프 어텐션이다. 각 토큰은 자신보다 앞에 있는 토큰만 참조할 수 있고, 뒤쪽은 마스킹되어 볼 수 없다. 미래를 미리 엿보지 못하게 막는 이 제약 덕분에, 모델은 "지금까.. 2026. 9. 28. BERT: 양방향 문맥으로 언어를 이해하는 인코더 NLP · Transformer BERT: 양방향 문맥으로 언어를 이해하는 인코더 2018년, 한 단어를 양쪽 문맥 모두로 해석하기 시작하면서 자연어 이해의 판도가 바뀌었다.BERT(Bidirectional Encoder Representations from Transformers)는 구글이 2018년에 발표한 모델로, 트랜스포머의 인코더만을 쌓아 만든 구조다. 이전의 정적 임베딩이나 단방향 언어 모델과 달리, BERT는 문장의 왼쪽과 오른쪽 문맥을 동시에 보면서 각 토큰의 의미를 해석한다. 그 결과 같은 단어라도 문장에 따라 다른 벡터를 얻는 문맥적 임베딩이 가능해졌다.왜 '양방향'이 중요한가"통장에서 돈을 찾다"와 "잃어버린 열쇠를 찾다"에서 '찾다'의 의미는 다르다. 단방향 모델은 앞쪽 단어만 .. 2026. 9. 28. 단어 임베딩: Word2Vec와 GloVe로 의미를 벡터에 담다 NLP · Representation 단어 임베딩: Word2Vec와 GloVe로 의미를 벡터에 담다 "왕 − 남자 + 여자 = 여왕"이 수식으로 성립하는 세계. 단어를 좌표 공간 위의 점으로 바꾸는 기술의 출발점.토큰을 정수 ID로 바꾸는 것만으로는 부족하다. ID는 그저 임의의 번호여서 고양이(42)와 강아지(43)가 의미상 가깝다는 사실을 전혀 담지 못한다. 임베딩은 각 단어를 수백 차원의 실수 벡터로 매핑해, 의미가 비슷한 단어가 공간상에서도 가까이 놓이도록 만든다. 그 바탕에는 분포 가설, 즉 "비슷한 문맥에 나타나는 단어는 비슷한 의미를 가진다"는 통찰이 있다.Word2Vec: 예측 기반 학습2013년 구글이 제안한 Word2Vec은 신경망으로 단어 벡터를 학습하는 두 가지 구조를 제시했다.. 2026. 9. 27. 토큰화(Tokenization): 텍스트를 모델이 읽는 단위로 쪼개기 NLP · Foundations 토큰화(Tokenization): 텍스트를 모델이 읽는 단위로 쪼개기 모든 자연어 처리 파이프라인의 첫 관문. 문장을 어떤 단위로 나누느냐가 이후 모델 성능 전체를 좌우한다.컴퓨터는 문자열을 그대로 이해하지 못한다. 텍스트를 모델이 다룰 수 있는 이산적인 단위, 즉 토큰(token)으로 분해하는 과정이 토큰화다. 토큰은 단어일 수도, 부분 단어(subword)일 수도, 심지어 개별 문자나 바이트일 수도 있다. 어떤 단위를 선택하느냐에 따라 어휘 사전(vocabulary)의 크기, 미등록 단어(OOV) 처리 방식, 시퀀스 길이가 모두 달라진다.토큰화의 세 가지 접근1. 단어 단위(Word-level)공백과 구두점을 기준으로 단어를 나누는 가장 직관적인 방식이다. 영어처럼.. 2026. 9. 27. 기술 다이어그램 (Mermaid, PlantUML) — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 기술 다이어그램: 코드로 그리는 그림 (Mermaid & PlantUML) 드래그로 그린 다이어그램은 코드가 바뀌면 거짓말이 된다. 텍스트로 다이어그램을 정의하는 Diagrams-as-Code 방식으로, 버전 관리되고 항상 최신인 시각 자료를 만드는 방법을 정리한다. Mermaid PlantUML Diagrams-as-Code Visualization 테크니컬 라이팅 시리즈·6 / 6Visio나 draw.io로 공들여 그린 아키텍처 다이어그램이 6개월 만에 현실과 동떨어지는 이유는 단순하다. 코드와 따로 놀기 때문이다. Diagrams-as-Code는 다이어그램을 텍스트로 정의해 코드 곁에 두고, Git으로 버전 관리하며, 리뷰를 거치게.. 2026. 9. 27. CHANGELOG 관리 — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 CHANGELOG 관리: 사용자를 위한 변경 기록의 기술 git log는 개발자의 기록이고, CHANGELOG는 사용자의 기록이다. Keep a Changelog 표준과 시맨틱 버저닝을 토대로, 사람이 읽을 수 있는 변경 이력을 유지하는 방법을 정리한다. CHANGELOG SemVer Release Notes Versioning 테크니컬 라이팅 시리즈·5 / 6"v2.3.0으로 업데이트해도 안전한가? 뭐가 바뀌었지?" 사용자의 이 질문에 답하는 것이 CHANGELOG다. 커밋 로그를 그대로 붙여넣는 것은 답이 아니다. CHANGELOG는 기계가 아니라 사람을 위해, 변경의 영향을 중심으로 쓰여야 한다.01왜 git log로 충분하지 않은.. 2026. 9. 26. README 작성 가이드 — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 README 작성 가이드: 프로젝트의 첫인상이자 명함 README는 방문자가 가장 먼저 읽는 문서이자, 종종 유일하게 읽는 문서다. 30초 안에 "이게 무엇이고 나에게 쓸모 있는가"를 전달하는 README 구조를 정리한다. README Open Source Onboarding Markdown 테크니컬 라이팅 시리즈·4 / 6깃허브 저장소에 들어온 사람이 별을 누를지, 그냥 떠날지는 대부분 README의 첫 화면에서 결정된다. 아무리 뛰어난 코드라도 README가 부실하면 아무도 쓰지 않는다. README는 코드의 포장지가 아니라 진입로다.01README가 답해야 할 세 가지 질문방문자는 무의식적으로 세 가지를 묻는다. 좋은 README는.. 2026. 9. 26. RFC 작성법 — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 RFC 작성법: 코드를 짜기 전에 합의를 설계하라 큰 변경일수록 코드보다 먼저 글로 합의해야 한다. RFC(Request for Comments)로 설계 의도를 공유하고, 비동기적으로 피드백을 모아 더 나은 결정을 내리는 프로세스를 정리한다. RFC Design Doc Async Collaboration Decision Making 테크니컬 라이팅 시리즈·3 / 6기능을 절반쯤 구현한 뒤에야 "이 접근 방식에 근본적인 문제가 있다"는 것을 깨달은 경험이 있다면, RFC가 필요한 순간을 이미 겪은 것이다. RFC는 키보드를 두드리기 전에 가장 값싼 매체인 글로 설계를 검증하는 협업 도구다.01RFC란 무엇이며 언제 쓰는가RFC는 인터넷 표.. 2026. 9. 26. ADR (아키텍처 결정 기록) — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 ADR: "왜 이렇게 결정했더라?"를 영원히 기록하는 법 코드는 "무엇을" 했는지 보여주지만, "왜" 그렇게 했는지는 사라진다. 아키텍처 결정 기록(ADR)으로 결정의 맥락과 트레이드오프를 미래의 팀에게 남기는 방법을 정리한다. ADR Architecture Decision Records Documentation 테크니컬 라이팅 시리즈·2 / 66개월 뒤 누군가 코드를 보며 "왜 여기서 Kafka를 안 쓰고 RabbitMQ를 썼지?"라고 묻는다. 당시 회의에 있던 사람은 퇴사했고, 슬랙 스레드는 검색되지 않는다. ADR(Architecture Decision Record)은 바로 이 "잃어버린 맥락" 문제를 해결하기 위한 가볍고 강력한 .. 2026. 9. 25. API 문서 작성 — 테크니컬 라이팅 IT 특수분야 · 테크니컬 라이팅 API 문서 작성: 개발자가 5분 안에 첫 호출에 성공하게 만들기 좋은 API 문서는 마케팅 자료가 아니라 사용 설명서다. 레퍼런스, 가이드, 튜토리얼의 역할을 구분하고 OpenAPI를 중심으로 유지보수 가능한 문서 체계를 설계하는 방법을 정리한다. OpenAPI REST Developer Experience Docs-as-Code 테크니컬 라이팅 시리즈·1 / 6API 문서의 품질은 채택률(adoption)에 직접적인 영향을 미친다. 개발자는 평균 몇 분 안에 첫 성공적인 호출(time-to-first-call)을 경험하지 못하면 다른 대안을 찾기 시작한다. 문서가 곧 제품의 첫인상이라는 전제에서 시작해야 한다.01레퍼런스 · 가이드 .. 2026. 9. 25. Kotlin Multiplatform — 로직은 공유, UI는 네이티브 모바일 개발 · 크로스 플랫폼 Kotlin Multiplatform — 로직은 공유, UI는 네이티브 UI까지 통일하려는 다른 프레임워크와 정반대 철학. 비즈니스 로직만 공유하고 화면은 각 플랫폼의 네이티브로 두는 KMP의 접근과, UI까지 공유하는 Compose Multiplatform을 함께 살펴봅니다. Kotlinexpect/actualCompose MPJetBrains다른 철학의 출발점지금까지 본 프레임워크 대부분은 UI까지 한 번에 공유하는 것을 목표로 했습니다. Kotlin Multiplatform(KMP)은 정반대 지점에서 출발합니다. 비즈니스 로직만 공유하고 UI는 각 플랫폼의 네이티브로 남겨두는 점진적 접근입니다.JetBrains가 만든 KMP는 네트워크 통신, 데이터 저장, 유효성.. 2026. 9. 24. .NET MAUI — C# 하나로 데스크톱까지 모바일 개발 · 크로스 플랫폼 .NET MAUI — C# 하나로 데스크톱까지 Xamarin.Forms의 진화형. 단일 C# 코드베이스로 iOS, Android, macOS, Windows를 모두 타깃하는 Microsoft의 공식 크로스 플랫폼 프레임워크를 깊이 들여다봅니다. C#XAML.NETMicrosoft.NET MAUI란 무엇인가.NET MAUI(Multi-platform App UI)는 Xamarin.Forms를 계승해 .NET 생태계로 완전히 통합한 크로스 플랫폼 프레임워크입니다. 하나의 C# 프로젝트로 모바일(iOS, Android)뿐 아니라 데스크톱(macOS, Windows)까지 동시에 빌드한다는 점이 가장 큰 특징입니다.기존에 모바일과 데스크톱이 별도 프로젝트로 나뉘었던 Xamari.. 2026. 9. 23. Ionic & Capacitor — 웹 기술로 만드는 네이티브 앱 모바일 개발 · 크로스 플랫폼 Ionic & Capacitor — 웹 기술로 만드는 네이티브 앱 HTML, CSS, JavaScript만으로 앱스토어에 올라가는 앱을 만든다. 웹 개발자가 가장 빠르게 모바일로 진입하는 길, Ionic의 UI와 Capacitor의 네이티브 브리지를 함께 풀어봅니다. WebViewCapacitorPWAAny FrameworkIonic과 Capacitor의 관계둘은 자주 묶여 불리지만 역할이 다릅니다. Ionic은 모바일에 최적화된 UI 컴포넌트 라이브러리이고, Capacitor는 웹 앱을 네이티브 앱으로 감싸고 네이티브 기능에 접근하게 하는 런타임/브리지입니다.핵심 발상은 명료합니다. 앱의 UI를 웹 기술(HTML/CSS/JS)로 작성하고, 이를 네이티브 컨테이너의 W.. 2026. 9. 22. Dart — Flutter를 떠받치는 언어 모바일 개발 · 크로스 플랫폼 Dart — Flutter를 떠받치는 언어 개발 중엔 JIT로 빠르게, 출시할 땐 AOT로 네이티브 속도로. 두 컴파일 모드와 사운드 널 안정성을 갖춘 Dart가 어떻게 Flutter의 Hot Reload와 성능을 동시에 가능하게 하는지 살펴봅니다. JIT + AOTNull Safetyasync/awaitGoogleDart란 무엇인가Dart는 Google이 2011년 발표한 객체 지향 언어로, 처음엔 JavaScript를 대체할 웹 언어를 목표로 했습니다. 큰 주목을 받지 못하다가 Flutter의 공식 언어로 채택되면서 부활했습니다. C 계열 문법을 따라 Java, JavaScript, Swift 경험자라면 빠르게 적응할 수 있습니다.Dart가 Flutter에 선택된 .. 2026. 9. 21. Flutter — 픽셀 단위로 그리는 크로스 플랫폼 모바일 개발 · 크로스 플랫폼 Flutter — 픽셀 단위로 그리는 크로스 플랫폼 네이티브 위젯을 빌리지 않고 자체 렌더링 엔진으로 모든 픽셀을 직접 그리는 Google의 UI 툴킷. 일관된 디자인과 60fps 성능을 한 코드베이스로 달성하는 Flutter의 핵심 원리를 분석합니다. DartImpellerWidgetGoogleFlutter란 무엇인가Flutter는 Google이 만든 UI 툴킷으로, 하나의 코드베이스로 모바일·웹·데스크톱·임베디드까지 커버합니다. React Native가 OS의 네이티브 위젯을 호출하는 것과 달리, Flutter는 자체 렌더링 엔진으로 모든 UI를 직접 그립니다. 화면의 모든 버튼, 텍스트, 애니메이션이 Flutter가 캔버스에 칠한 결과물입니다.이 접근의 핵심 이점.. 2026. 9. 20. Expo — React Native 개발의 가속 페달 모바일 개발 · 크로스 플랫폼 Expo — React Native 개발의 가속 페달 Xcode와 Android Studio 없이도 앱을 만들고 배포하는 플랫폼. 단순한 SDK를 넘어 빌드, 업데이트, 라우팅까지 통합한 현대 React Native의 사실상 표준 진입점을 살펴봅니다. Expo SDKEASExpo RouterOTAExpo란 무엇인가Expo는 React Native 위에 구축된 도구와 서비스의 통합 플랫폼입니다. 과거에는 "기능 제한이 있는 간편 도구" 정도로 여겨졌지만, 현재는 React Native 공식 문서가 새 프로젝트의 권장 시작점으로 안내할 만큼 위상이 달라졌습니다.핵심 가치는 설정의 제거입니다. 네이티브 빌드 환경 구성, 인증서 관리, 라이브러리 링크 같은 반복적이고 까다로운.. 2026. 9. 20. React Native — 검증된 크로스 플랫폼의 표준 모바일 개발 · 크로스 플랫폼 React Native — 검증된 크로스 플랫폼의 표준 하나의 JavaScript 코드베이스로 진짜 네이티브 UI를 그리는 프레임워크. Instagram, Discord, Shopify가 선택한 React Native의 작동 원리와 신아키텍처(New Architecture)까지 깊이 있게 다룹니다. JavaScriptReactNative UIMetaReact Native란 무엇인가React Native는 Meta가 2015년 공개한 크로스 플랫폼 프레임워크로, React의 컴포넌트 모델을 그대로 사용해 iOS와 Android 양쪽에서 동작하는 앱을 만듭니다. 핵심은 "한 번 작성하면 어디서나 실행"이 아니라 "한 번 배우면 어디서나 작성"이라는 철학입니다.웹 React.. 2026. 9. 20. 이전 1 2 3 4 ··· 38 다음 반응형
