노트

NotebookLM 은 Google 의 자료 우선 (source-grounded) AI 노트북. 사용자가 업로드한 PDF·구글 문서·웹사이트·YouTube·오디오에서만 답변을 합성하므로 hallucination 이 일반 챗봇보다 적음. 04-gemini-api 가 raw API, 08-google-ai-studio 가…

9회 조회

RAG (Retrieval-Augmented Generation) 는 LLM 의 한정된 학습 시점·메모리 한계를 외부 지식으로 보완하려는 방식입니다. 검색·생성을 분리하면 모델을 다시 학습시키지 않고도 새로운 자료를 다룰 수 있습니다.

4회 조회

AI 가 브라우저 안으로 들어오는 흐름이 2023~2025 년에 빠르게 진행됐습니다. 사이드바 보조에서 시작해 페이지 요약·번역·드래프트, 그리고 에이전트가 사용자 대신 페이지를 다루는 자리까지 펼쳐졌습니다.

3회 조회

공공기관·외부 사업자가 제공하는 OpenAPI 를 프론트엔드에서 직접 호출 하면 첫 화면은 빠르게 만들 수 있습니다. 그러나 운영을 며칠 굴려 보면 같은 자리에서 같은 종류의 사고가 반복됩니다 — 키 노출, 응답 코드 해석, 프로토콜 미스매치. 그래서 외부 API 는 우리쪽 BFF 한 겹 을 사이에 두는 게 거의 항상…

2회 조회

관리 콘솔이나 백오피스는 한 프로세스에서 콘텐츠·카탈로그·운영 로그처럼 서로 다른 DB에 접근해야 할 수 있습니다. HTTP 경유 대신 풀 직접 접속을 선택할 때는 연결 수, 권한, 장애 격리를 함께 설계해야 합니다.

2회 조회

"공식 문서 보세요" 라는 답을 받고 막막했던 경험이 누구에게나 있습니다. 막상 펼쳐 보면 분량이 책 한 권이라 어디부터 봐야 할지 가늠이 안 됨. 문서는 책처럼 처음부터 끝까지 읽는 자료가 아닙니다. 검색 · 참조 · 발췌의 조합으로 사용. 이 글은 공식 문서의 일반적 구조 · 빠르게 훑는 법과 정독하는 법 · 변경…

좋은 개발자와 막 입문한 사람의 차이는 "아는 것이 많다" 보다 "모르는 것을 빠르게 찾는다" 쪽이 더 가깝습니다. 검색은 외우기의 보완이 아니라 별도의 기술. 이 글은 좋은 키워드를 만드는 법 · 공식 문서와 커뮤니티 자료의 우선순위 · 영어 검색 · LLM 을 검색의 보조로 쓰는 기준.

이 글은 프로그래밍을 막 시작하려는 사람을 대상으로, 학습 초반에 마주치는 영역을 사실 기반으로 정리합니다. 어디서부터 손을 대야 할지 막막할 때 지도 역할.

iOS 앱 빌드는 Android 와 비슷한 단계 (컴파일 → 자원 묶기 → 서명 → 패키지) 를 거치지만, 도구 · 배포 통로 · 정책의 모양이 꽤 다릅니다. 가장 큰 차이는 macOS 와 Apple Developer Program 이 사실상 강제된다는 점. 이 글은 Xcode 와 xcodebuild · 인증서 · 프로…

Android 앱을 빌드한다는 일은 어떤 도구를 쓰든 결국 비슷한 단계를 통과합니다. 소스를 컴파일하고, 자원을 묶고, DEX 로 변환하고, 서명. 결과 파일은 APK 또는 AAB. 이 글은 그 흐름과 sdk 버전 (min · target · compile) 의 의미 · 서명 키 운영 · Tauri · Flutter ·…

Flutter 는 Google 이 만든 UI 툴킷으로, 한 코드베이스에서 모바일 · 웹 · 데스크탑을 모두 겨냥. 자체 렌더링 엔진과 Dart 언어, 그리고 위젯 트리라는 표현 모델이 핵심. 이 글은 Flutter 의 출자 · Dart 언어 · 위젯 모델 · 렌더링 엔진 (Skia · Impeller) · 빌드 · 패키…

같은 앱을 iOS · Android · 웹에 한 코드베이스로 만들고 싶다는 요구는 오래됐습니다. 그 답으로 등장한 도구들은 시기마다 다른 방식을 택했습니다. 웹뷰 위에 얹는 쪽, 자바스크립트 브릿지로 네이티브 위젯을 부르는 쪽, 자체 캔버스에 직접 그리는 쪽. 이 글은 PhoneGap 부터 Tauri Mobile 까지의…

"좋은 이름" 이 무엇인지에 대해서는 여러 책과 연구가 있습니다. 이 글은 Clean Code · Code Complete · Mythical Man-Month · 인지부하 (Cognitive Load) 이론을 사실 기준으로 정리합니다.

피처 플래그 (feature flag · feature toggle) 는 큰 회사 사례에서 자주 인용되는 패턴. 작은 팀에서도 같은 무게의 기대를 거는 경우가 있는데, 비용과 이득은 환경에 따라 다릅니다. 이 글은 사실 기준으로 정리.

LLM 기반 코드 보조가 일상화되며 "AI 가 도왔다는 것을 어떻게 표기할 것인가" 가 팀마다 다른 결정으로 갈라졌습니다. 이 글은 관련 사실 (소송 · OSS 라이선스 입장 · 커밋 트레일러 관습) 을 객관적으로 정리합니다.

영어가 아닌 모국어로 문서 · 주석을 적는 선택은 비영어권 개발 팀에서 자주 마주치는 결정. 이 글은 식별자 (영어) 와 문서 / 주석 (모국어) 의 분리 관습 · 유니코드 식별자 표준.

저장소에는 두 종류의 독자를 위한 문서가 공존합니다. 사람과 코드 보조 에이전트 (LLM 기반 IDE 보조 · AI 코더). 이 글은 두 종류의 표준 · 관습.

한 번에 큰 리팩터로 모든 문제를 해결하려는 시도는 자주 실패합니다. 작은 단위로 꾸준히 정리하는 패턴이 더 안정적인 결과를 낸다는 평이 흔합니다. 이 글은 Boy Scout Rule 과 Strangler Fig Pattern.

"best practice" 라는 말은 종종 의문 없이 적용되지만, 모든 환경에 똑같이 들어맞는 단일한 답은 드뭅니다. 이 글은 맥락 의존성을 보여 주는 세 고전 (CAP · PACELC · Conway's Law) 의 사실.

폴더 구조는 단순한 파일 분류가 아니라, 코드 사이의 의존 방향과 변경 영향 범위를 약속하는 장치가 될 수 있습니다. 이 글은 Feature-Sliced Design · Domain-Driven Design · Hexagonal Architecture 의 사실.

SSOT (Single Source of Truth) 는 데이터 거버넌스 용어에서 시작해 코드 · 문서 · 스키마 운영의 원칙으로 확장. 이 글은 출처 · 적용 영역 · 트레이드오프.

세 머리글자는 소프트웨어 설계 원칙으로 자주 함께 인용. 출처와 의미가 조금씩 다르고, 서로 충돌하는 해석도 있습니다. 이 글은 각 원칙의 출처 · 의도 · 자주 혼동되는 사례.

"객체지향이냐 함수형이냐" 라는 질문은 한때 진영 다툼처럼 다뤄졌습니다. 오늘날의 모던 언어는 둘을 함께 지원하고, 실무 코드는 두 패러다임을 자연스레 섞어 씁니다. 이 글은 두 패러다임의 출자 · 핵심 원칙 · 모던 언어가 둘을 어떻게 흡수했는지 · 실무에서 어느 자리에 어느 시각이 잘 맞는지.

같은 문제를 풀다 보면 비슷한 형태가 반복됩니다. 1990 년대 객체지향이 보편화되면서 그런 반복을 이름 붙여 정리한 책이 나왔고, 이후 패턴은 개발 문화의 공통어가 됐습니다. 이 글은 패턴의 출자 · 23 GoF 패턴의 분류 · 자주 만나는 7 가지의 의미 · 함수형 등가물 · 안티패턴 · 패턴이 도구이지 목적이 아니…

"이 코드는 빠른가요" 라는 물음은 환경 · 하드웨어 · 입력에 따라 답이 달라집니다. 그래서 컴퓨터 과학은 입력 크기가 커질 때 시간 (또는 메모리) 이 어떻게 자라는지를 함수 형태로 표기. 그 표기가 Big O. 이 글은 Big O 의 출자 · 자주 만나는 성장률 · 시간과 공간 복잡도 · 실무에서의 의미와 한계.