LLM 시대, 프롬프트 엔지니어링보다 '도메인 전문성'이 더 강력한 무기인 이유
최근 AI 도구들이 비약적으로 발전하면서 '프롬프트 엔지니어링'이라는 기술적 기법에 많은 관심이 쏠렸습니다. 하지만 실제 현업에서 LLM을 극한으로 활용해 고도의 결과물을 만들어내는 사람들의 공통점은 정교한 프롬프트 템플릿을 쓰는 능력이 아니라, 해당 분야에 대한 깊은 '도메인 전문성'을 갖추고 있다는 점입니다. 많은 이들이 LLM이 지식의 격차를 줄여준다고
최근 AI 도구들이 비약적으로 발전하면서 '프롬프트 엔지니어링'이라는 기술적 기법에 많은 관심이 쏠렸습니다. 하지만 실제 현업에서 LLM을 극한으로 활용해 고도의 결과물을 만들어내는 사람들의 공통점은 정교한 프롬프트 템플릿을 쓰는 능력이 아니라, 해당 분야에 대한 깊은 '도메인 전문성'을 갖추고 있다는 점입니다. 많은 이들이 LLM이 지식의 격차를 줄여준다고
최근 Claude Code나 Kiro와 같은 AI 코딩 에이전트들이 단순한 코드 완성을 넘어, 자연어 프롬프트 하나로 수십 개의 PR을 생성하고 인프라를 수정하는 수준까지 발전했습니다. 하지만 이러한 생산성 향상은 '기계적 속도'라는 트레이드오프를 동반합니다. AI 에이전트는 조직의 보안 리스크나 컴플라이언스를 이해하지 못한 채 오직 '작업 완료'에만 최적화되어
최근 LLM의 성능이 비약적으로 상승하면서, 역설적으로 우리가 모델의 성능을 측정하는 '자' 자체가 무용지물이 되는 현상이 가속화되고 있습니다. arXiv에 게재된 "When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation" 연구는 우리가 흔히 신뢰하는 벤치마크 점수가 왜 더 이상 모델 간의 변별력을 제공하지 못하는지, 그리고 이른바 '
DevOps.com을 통해 Airlock Digital이 발표한 'Agentic AI Control & Governance' 솔루션 소식을 접했습니다. 이번 발표의 핵심은 단순히 '어떤 AI 소프트웨어를 실행할 것인가'라는 기존의 화이트리스트 방식(Application Control)을 넘어, 실행 중인 AI 에이전트가 '실제로 어떤 명령을 내리고 어떻게 행동하는가'를 실시간으로 제어하겠다는
AI 에이전트가 단순한 텍스트 생성을 넘어 외부 API를 호출하거나 특정 비즈니스 로직을 수행하려면, 에이전트가 사용할 수 있는 '도구(Tool)' 혹은 '역량(Skill)'이 명확하게 정의되어 있어야 합니다. 지금까지는 이러한 스킬들을 개별적으로 정의하고 각 에이전트 설정에 하나씩 추가하는 방식이 일반적이었습니다. 하지만 프로젝트 규모가 커지고 팀 단위로 에이전트를
최근 LLM 기반 서비스의 표준으로 자리 잡은 RAG(Retrieval-Augmented Generation)는 구현이 쉽고 효율적이지만, 근본적인 구조적 한계를 가지고 있습니다. 바로 문서를 임의의 길이로 자르는 '청킹(Chunking)' 과정에서 지식 간의 유기적인 맥락과 관계가 완전히 단절된다는 점입니다. 전형적인 RAG는 사용자의 질문과 벡터 유사도가 높은 조각 몇 개를 가져와 컨텍스트에
프롬프트만으로는 부족했고, 컨텍스트만으로도 안전하지 않다. AI가 일하는 시스템 전체 — 컨텍스트 큐레이션, 검증 루프, 권한 경계 — 가 어떻게 진화해 왔는지, 그리고 지금 우리가 무엇을 먼저 짜야 하는지를 정리한다.
Claude Code에 OTEL 적용하고 모니터링 사이트 만든거 자랑(?)(codex, gemini 포함)
Antigravity, gemini 3.0 으로 react 개발하기
TCP(전송 제어 프로토콜) 개요 TCP는 불안정한 네트워크 환경에서도 신뢰성 있고 순서가 보장된 데이터 전송을 가능하게 하는 핵심 인터넷 프로토콜이다. IP가 호스트 간 패킷 전달만을 담당한다면, TCP는 포트 기반 프로세스 간 통신, 오류 복구, 재전송, 순서 제어를 제공한다. 흐름 제어와 혼잡 제어를 통해 TCP는 수신 버퍼와 네트워크 대역폭의 고갈을 방지한다.
Product Engineering 시대와 AI 개발 패러다임 변화 1. 패러다임 변화: 코드 작성의 목적이 달라졌다 1972년 Dennis Ritchie가 C 언어를 발표한 이후, 소프트웨어 산업은 오랫동안 다음 요소에 집중해 왔다. * 코드 효율성 (시간·공간 복잡도) * 코드 길이 및 생산성 * 가독성과 유지보수성 그러나 AI 시대가 시작되면서 기존 패러다임이 근본적으로 변하고 있음. John Carmack은
소개 소프트웨어 애플리케이션의 복잡도가 증가함에 따라 인프라에 대한 요구도도 함께 증가하고 있습니다. 인프라 팀은 다양한 서비스를 빠르고 안정적으로 제공해야 하지만, 인프라 구축은 여전히 수동 프로세스에 의존하는 경우가 많습니다. 이 문제를 해결하기 위한 핵심 접근 방식이 인프라 자동화이며, 그중 하나가 GitOps입니다. 1. 인프라 자동화의 필요성 * 애플리케이션 개발은 CI/CD로 자동화되었지만 인프라
한때 15억 달러의 가치를 인정받으며 AI 혁신의 선두주자로 불렸던 영국 스타트업 Builder.ai가 충격적인 진실과 함께 파산 위기에 직면했습니다. 마이크로소프트와 소프트뱅크 같은 거대 기업들로부터 4억 4,500만 달러라는 천문학적 투자를 받았던 이 회사가 어떻게 이런 상황에 이르게 되었는지, 그리고 그 뒤에 숨겨진 충격적인 진실을 파헤쳐보겠습니다. 화려했던 시작: "AI가 모든
DEMO Link Dify란? Dify는 오픈소스 기반의 LLM 애플리케이션 개발 플랫폼으로, 생성형 AI 서비스를 구축하는 데 필요한 다양한 기능을 제공합니다. 주요 특징은 다음과 같습니다 노코드/로우코드 개발: 직관적인 웹 UI를 통해 복잡한 코드 작성 없이도 AI 애플리케이션을 개발할 수 있습니다. 필요시 API를 활용한 커스터마이징도 가능합니다 . 다양한 LLM 지원: OpenAI의 GPT 시리즈,
ChatGPT, GitHub Copilot 같은 AI 코딩 도구가 등장하면서 개발자들의 작업 방식은 크게 바뀌고 있습니다. 코드 자동완성, 버그 수정, 문서 요약, 리팩터링까지… 반복적이고 지루한 작업은 AI가 척척 처리해주고, 개발자는 더 빠르게 더 많은 일을 할 수 있게 되었죠. 하지만 이런 편리함 뒤에는 한 가지 위험이 숨어 있습니다. 너무 편한 AI에 의존하다
import json import os import sys from urllib.parse import urljoin, urlunparse import requests import urllib3 urllib3.disable_warnings() DEFAULT_REGISTRY = "registry.ollama.ai" DEFAULT_NAMESPACE = "library" DEFAULT_TAG = "latest" DEFAULT_PROTOCOL_SCHEME = "https" class Manifest: def __init__( self, schema_version, media_
Python 개발을 하다 보면 conda를 통해 환경을 관리하거나 패키지를 설치하는 일이 많습니다. 하지만 conda의 느린 설치 속도, 긴 종속성 해결 시간, 높은 메모리 사용량에 답답함을 느껴본 경험이 있다면, 이제 _mamba_를 고려해볼 때입니다. mamba는 conda 사용자에게 거의 동일한 사용 경험을 제공하면서도 속도·성능·안정성 면에서 압도적으로 우수한 대안입니다. 🐍 Mamba란 무엇인가?
ci/cd
소프트웨어 개발 환경은 점점 복잡해지고, 고객 요구는 더 빨라지고 있습니다. 이 변화 속에서 기업들이 공통적으로 도입하고 있는 핵심 기술이 바로 CI/CD(지속적 통합/지속적 배포) 입니다. CI/CD는 단순히 “빌드/배포 자동화”가 아니라, 기업의 개발 조직이 더 빠르게, 더 안전하게, 더 높은 품질로 제품을 제공할 수 있게 해주는
Streamlit으로 OAuth 기반 데모 앱을 테스트하다 보면, 의도치 않게 서버가 8501 대신 8502 포트에서 실행되는 상황을 겪은 분들이 많을 것입니다. 저 역시 GitHub OAuth 리디렉션 URI를 8501로 설정해 두었기에 반드시 8501에서 실행해야 했습니다. 그런데 명령을 다시 실행해도 Streamlit은 고집스럽게 8502 포트를 선택했습니다. 처음엔 “이미 8501 포트를 사용 중인 프로세스가 있나?
wsl
WSL2(Windows Subsystem for Linux 2)를 사용할 때 자주 부딪히는 문제가 있다. 바로 WSL2 내부 서버에 외부에서 접근할 수 없다는 점이다. WSL2는 가상 네트워크 인터페이스를 통해 동작하기 때문에 리눅스에서 localhost로 열어둔 포트가 Windows나 외부에서 그대로 접근되지 않는다. 이를 해결하기 위해서는 portproxy 기능을 활용한 포트 포워딩 설정이 필요하다. 하지만 문제는…
Node.js 개발을 하다 보면 패키지 설치 속도, 사내 프록시, 사설 npm 서버, SSL 인증서 문제, CI/CD 자동화, 개인 토큰 관리 등 다양한 이유로 .npmrc 설정이 필수적이다. npm은 다음 경로의 .npmrc 파일들을 순서대로 병합하여 최종 설정을 결정한다: 1. 프로젝트 로컬: <프로젝트>/ .npmrc 2. 사용자 로컬: ~/.npmrc 3.
리눅스 서버에 접속할 때 우리는 흔히 다양한 터미널 프로그램(XShell, SecureCRT, LePutty, Team Tera 등)을 사용합니다. 대부분의 사람들은 리눅스와 로컬 PC 간에 파일을 전송할 때 FTP 또는 SFTP를 떠올리지만, 사실 이보다 훨씬 간단한 방법이 있습니다. 바로 ZMODEM 프로토콜을 지원하는 터미널 프로그램과 lrzsz 패키지를 활용한 파일 전송입니다. ZMODEM이란? ZMODEM은 오래된
Linux 환경에서 터미널의 프롬프트는 PS1 변수로 제어된다. 제공된 코드는 color_prompt에 따라 색상 적용 여부가 달라지는 동적 프롬프트 구성을 보여준다. 아래는 코드와 함께 각 요소의 의미를 풍부하게 분석한 내용이다. 📌 전체 코드 if [ "$color_prompt" = yes ]; then # PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[
python
Python 패키지를 외부 저장소(PyPI)에서 설치해야 하지만 내부망 환경에서 프록시 서버를 반드시 거쳐야 하는 경우, pip 설정 파일에 프록시 정보를 지정해야 한다. OS별로 설정 파일의 위치와 이름이 다르므로 주의한다. 🪟 Windows 환경 설정 📁 1. pip 설정 디렉터리 생성 Windows에서 pip 설정 파일은 다음 경로에 위치한다. %UserProfile%\AppData\Roaming\pip 예시: