🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangSmith는 LLM 애플리케이션 개발 흐름을 관찰성, 평가, 프롬프트 엔지니어링으로 재정리한 새 홈페이지와 워크스페이스 리소스 관리를 위한 Resource Tags 개선을 공개했다.

📌 핵심 요약

• LangChain 팀은 LangSmith 제품 홈페이지를 새롭게 설계하고, 워크스페이스 안에서 리소스를 더 잘 정리할 수 있도록 Resource Tags 지원을 개선했다고 발표했다.
• 새 홈페이지는 LLM 애플리케이션을 만들고 최적화하고 반복 개선하는 엔지니어링 팀의 실제 작업 흐름을 바탕으로 관찰성, 평가, 프롬프트 엔지니어링 세 영역으로 나뉜다.
• 관찰성 영역은 Tracing Projects와 Dashboards를 중심으로, 사용자가 자신의 애플리케이션 데이터를 직접 살펴보고 문제를 디버깅하며 비용, 지연시간, 품질 같은 지표를 추적하도록 돕는다.
• 평가 영역은 Datasets, Experiments, Annotation Queues를 통해 데이터셋 구성, 자동 평가, 실험 결과 추적, 사람 검토 워크플로우를 연결해 LLM 애플리케이션 개선 지점을 찾도록 한다.
• Resource Tags는 리소스를 하나의 엄격한 애플리케이션 구조에 묶기보다, 애플리케이션·환경·사용자 정의 태그 기준으로 유연하게 필터링하고 관리할 수 있도록 개선됐다.

🧩 주요 포인트

1. LangChain 팀은 LangSmith 제품 홈페이지를 새롭게 설계하고, 워크스페이스 안에서 리소스를 더 잘 정리할 수 있도록 Resource Tags 지원을 개선했다고 발표했다.
2. 새 홈페이지는 LLM 애플리케이션을 만들고 최적화하고 반복 개선하는 엔지니어링 팀의 실제 작업 흐름을 바탕으로 관찰성, 평가, 프롬프트 엔지니어링 세 영역으로 나뉜다.
3. 관찰성 영역은 Tracing Projects와 Dashboards를 중심으로, 사용자가 자신의 애플리케이션 데이터를 직접 살펴보고 문제를 디버깅하며 비용, 지연시간, 품질 같은 지표를 추적하도록 돕는다.
4. 평가 영역은 Datasets, Experiments, Annotation Queues를 통해 데이터셋 구성, 자동 평가, 실험 결과 추적, 사람 검토 워크플로우를 연결해 LLM 애플리케이션 개선 지점을 찾도록 한다.
5. Resource Tags는 리소스를 하나의 엄격한 애플리케이션 구조에 묶기보다, 애플리케이션·환경·사용자 정의 태그 기준으로 유연하게 필터링하고 관리할 수 있도록 개선됐다.

🧠 상세 정리

1. 홈페이지 개편의 배경과 핵심 방향

LangChain 팀은 LangSmith의 제품 홈페이지를 새롭게 설계하고, 워크스페이스 내 리소스 정리 기능을 개선했다고 밝혔다. 이번 변화는 여러 개발자와 기업이 LLM 애플리케이션을 만들고 최적화하며 반복하는 방식을 관찰한 결과를 반영한 것이다. 글은 단순한 UI 변경 소개가 아니라, LangSmith가 개발 워크플로우를 어떻게 이해하고 제품 구조에 반영했는지를 설명한다. 핵심은 LLM 애플리케이션 개발을 관찰성, 평가, 프롬프트 엔지니어링이라는 세 축으로 나누어 사용자가 필요한 기능을 더 명확히 찾도록 하는 데 있다.

2. 관찰성: 트레이스와 대시보드 중심의 문제 파악

새 홈페이지의 첫 번째 영역은 관찰성이며, 여기에는 Tracing Projects와 Dashboards가 포함된다. LangSmith는 AI 엔지니어에게 중요한 권장사항인 ‘자신의 데이터를 직접 보라’는 접근을 지원하기 위해, 애플리케이션에서 발생한 트레이스를 모아 검색하고 필터링하고 개별 트레이스까지 자세히 확인할 수 있게 한다. 이런 데이터포인트 단위의 관찰성은 애플리케이션 내부에서 실제로 무슨 일이 벌어지는지 이해하고 문제를 빠르게 찾는 데 중요하다고 설명된다. Dashboards는 비용, 지연시간, 품질뿐 아니라 에이전트 동작 추이와 실시간 평가 점수 같은 사용자 정의 지표를 시간에 따라 모니터링하도록 돕는다.

3. 평가: 데이터셋, 실험, 사람 검토를 연결

두 번째 영역은 평가이며, LangSmith는 Datasets, Experiments, Annotation Queues를 이 영역에 배치했다. 글은 LLM 애플리케이션 평가가 개발 과정에서 병목이 되기 쉽다고 보고, 지속적이고 품질 높은 평가가 성능 이해와 개선 지점 파악에 필요하다고 설명한다. 사용자는 기존 데이터를 가져오거나 관찰성 영역의 로그에서 데이터 포인트를 자동으로 추가해 데이터셋을 구성할 수 있다. 이후 데이터셋 위에서 실험을 실행하고 자동 평가기로 결과를 점수화하며, 정확도와 스타일 같은 기준에서 회귀나 개선을 추적할 수 있다. 또한 사람 검토가 여전히 중요하므로 Annotation Queues를 통해 검토가 필요한 데이터 포인트를 정리하고 일관된 피드백 흐름을 만들 수 있게 했다.

4. 프롬프트 엔지니어링과 실시간 반복 개선

세 번째 영역은 프롬프트 엔지니어링이며, LangSmith는 Prompts와 Playground를 중심 기능으로 제시한다. 제품은 프롬프트를 저장하고 버전 관리할 수 있게 해, 프롬프트가 어떻게 변해왔는지 추적하고 팀원과 협업하기 쉽게 만든다. Playground에서는 프롬프트를 개별 데이터포인트에 실행하거나 전체 데이터셋에 적용해 대규모 영향을 살펴볼 수 있다. 또한 서로 다른 프롬프트와 모델 조합을 나란히 비교해 어떤 조합이 더 잘 작동하는지 확인할 수 있다. 글은 이 영역에서 더 나아가 ‘프롬프트 엔지니어링을 위한 IDE’가 어떤 모습일 수 있는지도 탐구하고 있다고 밝힌다.

5. 신규 사용자를 위한 온보딩 가이드

LangSmith는 새 사용자가 빠르게 시작할 수 있도록 홈페이지 상단에 온보딩 가이드도 추가했다. 이 가이드는 새 홈페이지가 강조하는 세 영역인 관찰성, 평가, 프롬프트 엔지니어링을 모두 다룬다. 이는 사용자가 기능 목록을 따로 찾아 헤매기보다, LLM 애플리케이션 개발 과정에서 어떤 순서와 목적에 따라 LangSmith를 사용할 수 있는지 이해하도록 돕는 장치다. 본문에서 온보딩 가이드는 길게 설명되지는 않지만, 개편된 정보 구조를 실제 첫 사용 경험과 연결하는 보조 기능으로 제시된다.

6. Resource Tags로 유연해진 리소스 조직화

글의 후반부는 워크스페이스 안에서 리소스를 더 잘 정리하기 위한 Resource Tags 개선을 설명한다. LangSmith의 Workspaces는 조직 안의 여러 팀이나 비즈니스 단위가 전용 환경을 나눠 쓰도록 설계됐지만, 팀이 커지면서 워크스페이스 내부 리소스 조직화 필요도 커졌다고 한다. LangSmith는 처음에는 각 리소스를 하나의 엄격한 ‘Application’ 개념에 묶는 방안을 검토했지만, 사용자 조사 결과 실제 사용 방식에는 너무 경직적이라는 점을 확인했다. 이제 Resource Tags는 기본적으로 애플리케이션 기준 필터링을 제공하면서도, 개발·스테이징·운영 같은 환경이나 사용자 워크플로우에 맞춘 커스텀 태그 필터링을 지원한다. 향후에는 태그 속성을 기반으로 조건부 권한을 부여하는 Attribute-Based Access Control도 도입해 보안과 사용자화를 강화할 계획이라고 밝혔다.

🧾 핵심 주장 / 시사점

• 이번 개편은 LangSmith가 LLM 애플리케이션 개발을 단일 기능 묶음이 아니라 관찰, 평가, 프롬프트 반복이라는 실제 엔지니어링 루프로 바라보고 있음을 보여준다.
• Resource Tags 개선은 팀 규모가 커질수록 프로젝트 단위만으로는 리소스를 관리하기 어렵고, 환경이나 사용 목적에 따른 다층적 분류가 필요하다는 문제를 반영한다.
• 자동 평가와 사람 검토를 함께 강조한 점은 LLM 애플리케이션 품질 관리에서 정량 지표와 human feedback이 모두 중요하다는 메시지로 읽힌다.

✅ 액션 아이템

• LangSmith 리디자인 홈페이지의 관찰성·평가·프롬프트 엔지니어링 3영역 구조를 기사 노트의 핵심 프레임으로 반영한다.
• Tracing Projects와 Dashboards를 중심으로 비용·지연시간·품질 지표의 장애 징후 점검 항목을 운영 기준에 맞춰 정리한다.
• Resource Tags 개선 내용을 바탕으로 애플리케이션·환경·사용자 정의 태그 기준으로 리소스 조회 규칙을 통합한다.

❓ 열린 질문

• 리소스를 앱 단일 구조가 아닌 태그 기반으로 관리할 때 실제 효율 개선은 어떤 지표로 판단할 수 있는가?
• 관찰성·평가·프롬프트 엔지니어링 중 현재 워크플로에서 우선적으로 강화할 영역은 어디인가?
• Tracing Projects와 Dashboards에서 비용·지연시간·품질 지표를 함께 볼 때 어떤 임계값 설정이 개선 포인트 탐지에 유리한가?