Be Original

온톨로지는 어떻게 "생각"하는가: 추론의 원리

Theo (테오) — Sun, 12 Jul 2026 09:57:57 +0900

지난 글에서 온톨로지를 이야기하면서 이런 말을 했습니다.

"LLM은 확률적으로 '추측'하지만, 온톨로지는 논리적으로 '증명'한다."

"소크라테스는 사람이다" + "모든 사람은 죽는다" → "소크라테스는 죽는다." 어디에도 직접 적혀 있지 않던 결론이 두 사실로부터 논리적으로 도출됩니다. 그게 온톨로지의 핵심 가치라고 했어요.

그런데 솔직히 그 부분을 좀 얼버무리고 넘어갔습니다. "추론이 핵심이다"라고만 하고, 정작 그 추론이 누가, 어떻게 일어나는지는 안 짚었거든요. 온톨로지가 안 적힌 사실을 찾아내는 "추론"이 실제로 어떤 원리로 돌아가는지, 예시 위주로 이야기해 보겠습니다.

추론을 하는 리즈너(Reasoner)

온톨로지에서 추론을 담당하는 건 리즈너(Reasoner)라는 도구입니다. 주어진 전제(사실과 규칙)만 가지고 결론을 끌어내는, 고지식할 만큼 원칙대로만 따지는 논리 기계예요. 사실 이걸 들여다보고 있으면 예전에 논리학 배우던 시절이 떠오릅니다. "모든 사람은 죽는다, 소크라테스는 사람이다, 따라서 소크라테스는 죽는다" 하던 그 삼단논법이요. 리즈너가 하는 일이 딱 그겁니다.

리즈너에게는 두 가지를 줍니다.

TBox - 규칙과 정의. "사람은 동물이다", "모든 사람은 죽는다" 같은 세상의 틀.
ABox - 실제 데이터. "소크라테스는 사람이다" 같은 구체적인 사실.

이 둘을 받으면 리즈너는 명시적으로 적혀 있지 않더라도 규칙상 반드시 따라오는 사실을 도출합니다. "소크라테스는 죽을 수밖에 없는 존재다" 같은 거요. 아무도 입력하지 않았는데 논리적으로 결론에 따라붙는 거죠. (엄밀히는 리즈너가 데이터를 "생성"한다기보다 "이게 참으로 따라온다"라고 밝혀내는 거예요. 이 결과를 실제 데이터로 저장해 두면 materialization이고, 저장하지 않고 질의 시점에 그때그때 계산할 수도 있습니다. 아래에서 더 다룰게요.

리즈너가 하는 일은 크게 세 가지로 나눌 수 있습니다.

1. 분류 (Classification): "이건 사실 저 종류다"

"아메리카노는 커피다"라고만 적었는데, "커피는 음료다"라는 규칙이 있으면 리즈너는 "아메리카노는 음료다"까지 자동으로 압니다. 일일이 "아메리카노도 음료임"이라고 적어줄 필요가 없어요. (정확히 말하면 "아메리카노"라는 클래스가 "커피"의 하위 클래스이고 "커피"가 "음료"의 하위 클래스라면, 어떤 개체가 아메리카노 타입일 때 그 개체는 커피이자 음료라는 것도 리즈너가 알 수 있다는 뜻이에요.)

2. 일관성 검사 (Consistency): "이거 말이 안 되는데?"

예를 들어 온톨로지에 "채식주의자는 고기를 먹는 사람과 양립할 수 없다"는 제약이 명시돼 있고, 삼겹살이 고기로 분류돼 있다고 해볼게요. 이때 "철수는 채식주의자다"와 "철수는 삼겹살을 먹는다"는 데이터가 함께 들어오면, 리즈너가 모순을 감지하고 빨간불을 켭니다. 사람이 일일이 검수하지 않아도 데이터의 모순을 잡아내는 거죠.

여기서 한 가지 짚고 갈 게 있어요. 리즈너가 "채식주의자는 원래 고기 안 먹잖아"라고 상식으로 알아서 판단하는 게 아닙니다. 위처럼 "채식주의자는 고기를 먹을 수 없다"는 제약이 온톨로지 안에 적혀 있어야 모순으로 잡혀요. 안 적어두면 리즈너는 둘이 함께 들어와도 모순으로 보지 않고 그냥 넘어갑니다. (리즈너가 의미를 아는 게 아니라 적어준 규칙만 따진다는 점, 이게 뒤에서도 계속 나올 핵심이에요.)

3. 논리적 귀결 (Entailment): "그럼 이런 것도 참이네"

위에서 본 삼단논법이 여기 해당합니다. 기존 사실 두 개로부터 논리적으로 따라오는 새 사실을 도출하는 것. 추론의 가장 강력한 부분이에요.

자, 그럼 본격적으로 들어가기 전에 큰 그림부터 한 번 잡고 가죠. 사실 "추론"이라는 말 안에는 성격이 전혀 다른 갈래가 여럿 들어 있거든요.

추론에도 세 가지 갈래가 있다: 연역·귀납·가추

논리학에서는 추론을 크게 세 종류로 나눕니다. 세 가지를 같은 상황에 놓고 보면 차이가 확 와닿아요. "비 오는 날, 구내식당에서 김치찌개가 동났다"는 한 장면을 두고 세 추론이 각각 어떻게 작동하는지 봅시다.

연역(Deduction): 규칙에서 확실한 결론으로

"모든 김치찌개에는 김치가 들어간다(규칙). 오늘 메뉴는 김치찌개다(사실). → 따라서 오늘 메뉴엔 김치가 들어간다."

전제가 참이면 결론은 100% 참입니다. 빠져나갈 구멍이 없어요. 앞에서 본 소크라테스 삼단논법, 그리고 이 글에서 다룰 리즈너의 추론(계층·역관계·체인 등)이 전부 이 연역에 속합니다. 온톨로지가 "추측이 아니라 증명한다"라고 할 때의 그 증명이 바로 연역이에요.

귀납(Induction): 관찰을 모아 일반 규칙으로

"지난 10주 동안, 비 오는 날마다 따뜻한 국물 메뉴가 평소보다 많이 나갔다(관찰들). → 비 오는 날엔 국물 메뉴 수요가 늘어난다(일반화)."

여러 사례를 모아 규칙을 뽑아내는 방식입니다. 연역과 달리 항상 맞지는 않아요. 11주 차에 깨질 수도 있죠. 어디까지나 "그럴 확률이 높다"입니다. 데이터에서 패턴을 학습하는 머신러닝, 그리고 지난 글에서 "LLM이 온톨로지 구축을 가속한다"라고 했던 것, LLM이 문서를 잔뜩 읽고 "이런 관계가 있을 법하다"라고 관계의 초안을 제안하는 것이 귀납적 성격이 강합니다. (엄밀히는 LLM의 답변이 항상 귀납만은 아니에요. 때로는 가추, 때로는 단순 패턴 완성처럼 섞여 나오죠. 다만 "사례에서 일반화한다"는 점에서 귀납 쪽에 가깝습니다.)

가추(Abduction): 결과를 보고 가장 그럴듯한 원인으로

"점심시간이 끝났는데 김치찌개가 동났다(결과). → 왜지? 손님이 많았나, 적게 준비했나... 가장 말 되는 설명은, 비가 와서 국물 메뉴로 수요가 몰린 거다(추정)."

결과를 먼저 보고 거꾸로 원인을 추리하는 방식입니다. 결론이 '확실'한 게 아니라 '제일 그럴듯한 설명'이에요. 의사가 증상을 보고 병명을 추정하거나, 셜록 홈즈가 단서로 범인을 좁히는 게 이 가추입니다. 진단이나 근본원인 분석에 쓰여요.

정리하면, 같은 장면을 두고 연역은 "규칙→결론"으로 내려오고, 귀납은 "사례들→규칙"으로 올라가고, 가추는 "결과→원인"으로 거슬러 올라갑니다. 이번 글의 주인공은 첫 번째, 연역입니다. 온톨로지 리즈너가 하는 게 바로 이거니까요. 다만 나머지 둘이 있다는 걸 알아두면, 나중에 "AI가 왜 어떤 건 확신하고(연역) 어떤 건 추측하는지(귀납·가추)"가 훨씬 선명하게 보입니다.

그럼 이제 그 연역이 구체적으로 어떤 규칙들로 일어나는지 하나씩 봅시다.

추론의 기본기: 여섯 가지 패턴

온톨로지 표현 언어(OWL)에는 리즈너가 알아서 적용해 주는 기본 추론 규칙들이 있습니다. 별도 프로그래밍 없이, 그냥 "이 관계는 이런 성질이야"라고 선언만 하면 리즈너가 알아서 사실을 불려줍니다. 자주 쓰이는 여섯 가지만 예시로 보죠.

1) 계층 타고 오르기 (subClassOf의 이행성)

가장 기본입니다. 클래스 사이에 "~의 하위 종류다"라는 관계를 걸어두면, 리즈너가 그걸 끝까지 타고 올라갑니다.

아메리카노  ⊂  커피  ⊂  음료

"아메리카노"라는 데이터 하나만 넣어도 리즈너는 이게 커피이자 음료라는 걸 압니다. 그래서 "음료 전부 보여줘"라는 질문에 아메리카노가 자동으로 걸려요. 카테고리가 6단계든 10단계든, 일일이 "이것도 음료, 저것도 음료"라고 적지 않아도 됩니다.

2) 속성에도 계층이 있다 (subPropertyOf)

관계(속성)도 상하 관계를 가질 수 있습니다. 예를 들어 "대표 레시피다"라는 관계를 "레시피다"의 하위 속성으로 정의하면, "이건 대표 레시피"라고만 적어도 "레시피"로 묻는 질문에 같이 잡힙니다. 좁은 의미로 적어도 넓은 의미로 검색되는 거죠.

3) 역방향은 알아서 채워준다 (inverseOf)

이게 은근히 편합니다. 두 관계가 서로 반대 방향이라고 선언해 두면, 한쪽만 적어도 반대쪽이 자동으로 생깁니다.

철수 ──(hasParent)──▶ 영희

여기서 hasParent와 hasChild가 서로 역관계라고 정의해 두면, 리즈너가 알아서 이런 사실을 추가합니다.

영희 ──(hasChild)──▶ 철수

"부모" 방향만 입력해도 "자식" 방향 질문이 다 됩니다. 데이터를 절반만 넣어도 양방향으로 다 조회되는 거죠.

4) 한 방향만 적으면 되는 대칭 관계 (SymmetricProperty)

"~와 짝이 잘 맞는다" 같은 관계는 방향이 없습니다. A가 B와 어울리면 B도 A와 어울리죠.

김치찌개 ──(어울림)──▶ 공기밥

이 관계를 대칭이라고 선언하면, 리즈너가 반대 방향도 자동으로 참으로 만듭니다.

공기밥 ──(어울림)──▶ 김치찌개

한 쌍에 한 줄만 적으면 됩니다.

5) 계단을 끝까지 올라가는 이행 관계 (TransitiveProperty)

"~에 속해 있다", "~의 부분이다" 같은 개체와 개체 사이의 관계도 계속 이어질 수 있습니다. 예를 들어 "어디에 위치한다(locatedIn)"는 관계를 보죠.

강남구 ──(locatedIn)──▶ 서울 ──(locatedIn)──▶ 대한민국

이 locatedIn 관계를 이행적이라고 선언하면, 직접 적지 않은 "강남구 locatedIn 대한민국"까지 리즈너가 도출합니다. 한 칸씩 이어진 관계를 끝까지 타고 가는 거예요.

1번 "계층 타고 오르기"와 헷갈릴 수 있는데, 둘은 적용 대상이 다릅니다. 1번 subClassOf는 클래스끼리의 계층(아메리카노라는 종류가 커피라는 종류에 속함)이고, 5번 TransitiveProperty는 locatedIn·partOf·ancestorOf처럼 개체끼리의 관계(강남구라는 장소가 서울이라는 장소에 속함)에 이행성을 부여하는 거예요. 그래서 5번 예시를 "강남구 ⊂ 서울"처럼 ⊂ 기호로 쓰면 안 됩니다. 그건 클래스 포함이라 1번 얘기가 돼버리거든요.

6) 진짜 마법, 속성 체인 (propertyChainAxiom)

여기가 개인적으로 가장 재미있는 부분입니다. 위의 것들이 "있는 관계를 불려주는" 거라면, 속성 체인은 여러 관계를 엮어서 완전히 새로운 관계를 만들어냅니다.

예를 들어 이렇게 정의할 수 있어요.

"어떤 사람의 부모의 형제는 그 사람의 삼촌이다."

철수 ──(부모)──▶ 영수 ──(형제)──▶ 민수

원래 데이터에는 "철수-부모-영수"와 "영수-형제-민수"만 있습니다. "삼촌"이라는 단어는 어디에도 없어요. 그런데 속성 체인을 정의해두면 리즈너가 이 사실을 도출합니다.

철수 ──(삼촌)──▶ 민수

두 홉(hop)을 건너야 알 수 있던 관계를 한 홉으로 압축해 주는 거죠. 실무에서 이게 왜 강력하냐면, 예를 들어 "이 재료가 어떤 상위 분류에 속하는가"를 계층을 따라 일일이 타고 올라가는 대신, "재료 → 상위분류"를 바로 잇는 지름길을 리즈너가 깔아줍니다. "농산물에 속하는 거 전부"를 물을 때 하위 항목을 하나하나 나열하지 않아도 한 번에 걸리는 식이에요.

관계만 봐도 타입을 안다 (domain / range)

하나 더. 속성에는 "이 관계의 주어는 어떤 종류여야 한다(domain)", "목적어는 어떤 종류여야 한다(range)"를 정해둘 수 있습니다.

"hasCuisine(요리 분류)의 주어는 반드시 레시피다"라고 정의해 두면, 어떤 X가 hasCuisine을 가지는 순간 리즈너는 "아, X는 레시피구나"라고 타입을 추론합니다. 타입을 직접 안 적어도 관계만 보고 알아내는 거죠.

다만 이건 양날의 검입니다. 잘못 정의하면 엉뚱한 타입까지 추론해 버려서, 의도하지 않은 데이터가 줄줄이 딸려 나옵니다. 강력한 만큼 조심해서 써야 하는 기능이에요.

기본기로 안 될 때: 규칙 기반 추론

지금까지 본 여섯 가지는 OWL이 기본으로 제공하는 "공리(axiom)"들입니다. 그런데 도메인이 복잡해지면 이걸로 표현이 안 되는 규칙이 나옵니다. 지난 글에서 들었던 예시를 다시 가져와 볼게요.

"A 약품은 B 성분을 포함한다" + "B 성분은 C 질환 환자에게 금기다" → "A 약품은 C 질환 환자에게 처방하면 안 된다."

이건 단순한 역관계나 이행 관계가 아니라, 조건이 붙은 IF-THEN 규칙입니다. 이런 건 SWRL 같은 규칙 언어로 따로 적어줍니다. (SWRL은 OWL에 규칙 언어를 결합하려는 대표적인 제안인데, 정식 W3C 권고 표준이 아니라 Member Submission 성격이에요. 그래서 제품마다 지원 범위가 다르니 실제로 쓸 땐 확인이 필요합니다.)

IF   약품(?a) ∧ 성분포함(?a, ?b) ∧ 금기성분(?b, ?c)
THEN 처방금지(?a, ?c)

리즈너는 데이터에서 이 조건에 맞는 패턴을 찾으면 결론 부분을 새 사실로 추가합니다. 사람이 "이 약은 이 환자한테 안 돼요"라고 일일이 안 적어도, 규칙 하나로 수만 건의 조합을 자동으로 도출하는 거죠.

헷갈리기 쉬운 지점 하나. 비슷하게 생긴 SHACL이라는 것도 있는데, SHACL Core의 주된 목적은 새 사실을 도출하는 추론이라기보다 검증입니다. OWL/SWRL이 "무엇이 참으로 따라오는가"라면, SHACL은 "이 데이터가 우리가 정한 품질 규칙을 지켰는가"에 가까워요. "이 레시피엔 요리 분류가 반드시 하나 있어야 하는데 비었네?" 같은 걸 잡아내는 역할이죠. (다만 SHACL Rules 같은 확장까지 가면 규칙으로 값을 만들어내는 처리도 가능해요. "SHACL은 절대 추론이 아니다"라고까진 못 하고, 기본 역할이 데이터 품질 검증 쪽이라는 정도로 이해하면 됩니다.) 추론과 검증, 둘 다 온톨로지에서 자주 같이 쓰이지만 목적이 달라요.

추론 엔진은 한 종류가 아니다

지금까지 "리즈너가 추론한다"라고 뭉뚱그렸는데, 사실 그 리즈너가 추론을 굴리는 방식 자체가 여러 갈래입니다. 목적지는 똑같아요. 숨은 사실 찾기. 그런데 거기까지 가는 엔진이 여러 종류고, 각자 잘하는 게 다릅니다. 앞에서 본 여섯 가지 패턴이 "무엇이 추론되는가"였다면, 지금부터는 "어떻게 추론하는가"의 이야기예요. 대표적인 네 가지만 봅시다.

1) 기술 논리(Description Logic, DL) 방식: "모순이 나나 끝까지 따져본다"

아마 "DL"이라는 말을 어디선가 들어보셨을 거예요(Description Logic, 기술 논리). 사실 OWL이라는 언어 자체가 이 기술 논리 위에 세워져 있습니다. 가장 정통이자 표현력이 강한 방식이에요.

이 계열 리즈너는 귀류법과 비슷하게 동작합니다. "이게 거짓이라고 가정해 보자 → 어, 그러면 규칙들이랑 충돌해서 모순이 생기네 → 그러니까 참이다" 하는 식으로 끝까지 따져보는 거죠. 이걸 타블로(tableau) 방식이라고 부릅니다. 복잡하게 얽힌 정의도 다 다룰 수 있지만, 그만큼 계산이 무겁습니다. Pellet, FaCT++ 같은 리즈너가 여기 속하고, HermiT도 이 계열인데 더 정확히는 타블로를 개량한 하이퍼타블로(hypertableau) 방식을 씁니다.

2) 규칙 기반(Rule-based) 방식: "IF-THEN을 계속 적용한다"

앞에서 본 IF-THEN 규칙을 데이터에 반복적으로 적용하면서 새 사실을 불려 나가는 방식입니다. 발상이 단순하고, 무엇보다 대용량 데이터에 강해요. 표현력은 DL보다 제한적이지만 빠르고 결과가 예측 가능해서, 실무에서 가장 흔하게 쓰는 축입니다.

이 방식과 짝을 이루는 게 OWL 2 RL 프로파일이에요. 이름의 RL이 아예 Rule Language에서 왔는데, "규칙 엔진으로 구현하기 쉽도록" 표현력을 잘라낸 버전이거든요. 표준 안에 "A subClassOf B이고 B subClassOf C이면 A subClassOf C" 같은 IF-THEN 규칙이 정의돼 있고, 리즈너는 이걸 더 이상 새 사실이 안 나올 때까지 반복 적용합니다. Neptune, GraphDB, RDFox 같은 그래프·규칙 엔진에서 바로 돌릴 수 있어서, 대량 데이터 추론이 필요할 때 현실적으로 가장 먼저 손이 가는 선택이에요.

3) 질의 재작성(Query Rewriting) 방식: "추론을 질문 쪽에 심는다"

이건 발상이 재미있어요. 데이터에 추론된 사실을 미리 채워 넣는 대신, 질문 자체를 추론까지 포함하도록 다시 쓴 다음 원본 데이터에 던집니다. "음료 줘"라는 질문을 리즈너가 내부적으로 "음료이거나, 커피이거나, 아메리카노인 것 줘"처럼 자동 확장해서 처리하는 식이죠. 데이터가 어마어마하게 크고 자주 바뀌어서 미리 추론해 박아두기가 부담스러울 때 유리합니다.

4) 결과 기반(Consequence-based) 방식: "거대한 분류 체계 전용"

분류 계산(무엇이 무엇의 하위인지)에 특화돼서, 말도 안 되게 큰 온톨로지도 빠르게 처리하는 방식입니다. 지난 글에서 언급한 의료 표준 온톨로지 SNOMED CT가 수십만 개념 규모인데, 이런 걸 다루는 ELK 같은 리즈너가 이 계열이에요.

눈치채셨을 수도 있는데, 이 방식들은 OWL의 "프로파일"과 짝을 이룹니다. OWL에는 표현력을 일부러 제한한 버전들이 있어요. 풀 사양(OWL DL)은 위의 1번 방식으로 뭐든 다 추론하지만 무겁고, RL·EL·QL 같은 프로파일은 표현력 일부를 포기하는 대신 각각 규칙 기반·결과 기반·질의 재작성 방식으로 빠르게 돕니다. 어느 게 정답이라기보다, 내 데이터가 얼마나 크고 / 얼마나 복잡하고 / 얼마나 자주 바뀌느냐를 보고 고르는 거예요.

언제 추론할까: 미리 vs 그때그때

여기서 실무적으로 중요한 갈림길이 하나 있습니다. 이 추론을 언제 돌릴 거냐는 문제예요. 크게 두 방식입니다.

전방 추론 (Forward chaining / Materialization)

데이터가 들어오는 시점에 미리 추론을 다 돌려서, 도출된 사실을 실제 트리플로 저장해 둡니다. "삼촌" 관계를 미리 다 계산해서 박아두는 거죠. 나중에 질문이 들어오면 이미 계산돼 있으니 조회가 빠릅니다. 대신 저장 공간을 많이 먹고, 원본 데이터가 바뀌면 다시 계산해야 해요.

후방 추론 (Backward chaining)

평소엔 도출된 사실을 저장하지 않다가, 질문이 들어오는 순간 그 자리에서 추론합니다. 저장 공간은 아끼지만, 질문할 때마다 계산하니 응답이 느려질 수 있어요.

현장에서 느낀 것 하나. 상용 그래프 데이터베이스 중에는 질의 시점에 추론을 해주지 않는 제품이 꽤 있습니다. 그러면 선택지는 사실상 하나예요. 데이터를 적재하는 빌드 단계에서 리즈너를 한 번 돌려서, 도출된 사실(역관계·대칭 관계·계층 롤업 등)을 미리 다 만들어 그래프에 박아 넣는 겁니다. 그래야 실제 질의는 추론 없이도 빠르게 답하거든요. "추론은 빌드 때 미리, 조회는 가볍게"가 현실적인 타협점인 경우가 많았습니다.

그런데 무거운 리즈너, 현실에서 어디에 쓸까

여기서 솔직한 이야기를 하나 하고 싶어요. 앞에서 "타블로(DL) 방식은 표현력이 강하지만 무겁다"라고 했는데, 이 "무겁다"가 생각보다 심각합니다. 표현력이 강한 추론은 최악의 경우 계산량이 지수적으로 늘어나요. 데이터가 조금만 커져도 시간과 메모리가 감당이 안 되는 수준으로 튑니다. 실제로 대량 데이터에 HermiT 같은 리즈너를 돌리려고 하면, 끝나기를 기다리다 포기하게 되는 경우가 흔해요.

그럼 이런 무거운 리즈너는 아무도 안 쓰느냐? 그건 아닙니다. 쓰는 자리가 다를 뿐이에요. 이걸 구분 못 하면 엉뚱한 데 갖다 쓰고 "왜 안 돌아가지?" 하게 됩니다.

이럴 때 쓴다: 온톨로지를 "설계하고 검증"하는 단계

HermiT·Pellet 같은 리즈너는 대량 데이터 처리기가 아니라, 온톨로지 스키마(TBox)를 점검하는 도구로 쓰입니다. 온톨로지 편집기(Protégé 같은)에 기본으로 들어 있어서, 설계자가 버튼 하나로 "내가 짠 공리에 모순은 없나?", "이 클래스 계층이 의도대로 분류되나?"를 확인해요. 스키마는 규모가 작고(수천 개 개념 수준) 자주 바뀌지도 않으니, 여기선 무거운 리즈너도 몇 초에서 몇 분이면 끝납니다. 표현력이 강한 만큼 복잡한 정의의 정합성까지 꼼꼼히 잡아주니, 이 자리에선 제값을 해요.

이럴 때는 안 쓴다: 대량 데이터에 실시간 추론

반대로 실제 인스턴스 데이터(ABox)가 수백만 건인데 거기에 풀 DL 리즈너를 돌리는 건 아무도 안 합니다. 안 돌아가니까요. 이 자리는 앞에서 본 대로 가벼운 규칙 기반(OWL RL) + 빌드타임 materialization, 또는 질의 시점 경로 탐색으로 갑니다.

그래서 현장의 실제 패턴은 역할을 나누는 거예요. 설계 단계에서는 스키마를 무거운 리즈너로 한 번 힘들게 검증하고(모순·분류 확인), 운영 단계에서는 검증이 끝난 그 스키마 위에서 대량 데이터를 가벼운 방식으로 처리합니다. "정합성 검증은 무거운 리즈너, 대량 처리는 가벼운 엔진"으로 나눠 쓰는 거죠.

덧붙이면, 사실 현업 온톨로지의 상당수는 애초에 HermiT가 필요할 만큼 복잡한 표현력을 쓰지 않습니다. 그런 무거운 추론이 꼭 필요하다면, 그건 문제를 푸는 데 정말 필요해서라기보다 온톨로지를 과하게 설계한 신호일 때도 많아요. 지난 글에서도 짚었듯, 완벽한 지식 체계를 만들려다 비대해져서 실패하는 게 흔한 함정이거든요. 풀려는 문제에 딱 필요한 만큼만. 이게 표현력을 고를 때의 기본기예요.

안 적힌 건 "거짓"이 아니라 "모름": 열린 세계 vs 닫힌 세계

엑셀이나 데이터베이스를 쓰던 분이 온톨로지를 처음 만지면, 거의 다 여기서 한 번 걸려 넘어집니다. 짚고 갈게요.

데이터베이스는 닫힌 세계 가정(CWA, Closed World Assumption) 위에서 돕니다. 한마디로 "내 데이터에 없으면 = 없는 것, 거짓"이에요. 항공 예약 시스템에서 승객 명단에 철수가 없으면? "철수는 이 비행기 안 탐"으로 단정합니다. 명단이 곧 세상의 전부니까요.

그런데 온톨로지(OWL)의 기본값은 정반대인 열린 세계 가정(OWA, Open World Assumption)입니다. "내 데이터에 없으면 = 거짓이 아니라, 그냥 모름."

예를 들어 "철수가 땅콩 알레르기다"라는 기록이 없다고 해볼게요.

닫힌 세계(DB식): "기록이 없으니 철수는 땅콩 알레르기가 아니다." (단정)
열린 세계(온톨로지식): "철수가 땅콩 알레르기인지 아닌지 모른다." (보류)

왜 굳이 이렇게 설계했을까요? 세상의 지식은 늘 불완전하기 때문이에요. 안 적혀 있다고 거짓이라 단정하면 위험합니다. 특히 알레르기 같은 안전 문제에서 "기록 없음 = 안전함"으로 처리했다간 큰일 나죠. 그래서 온톨로지는 함부로 단정하지 않고 "모른다"로 남겨둡니다.

이게 바로 초보자가 "왜 이 당연한 걸 추론 안 해주지?" 하고 한참 헤매는 지점이에요. "이 사람은 채식주의자라고 명시 안 했으니 아닌 거 아냐?"라고 기대하지만, 열린 세계의 리즈너는 단정하지 않고 "모릅니다"라고만 답하거든요.

비슷한 함정이 하나 더 있습니다. 이름이 다르다고 다른 존재라고 단정하지도 않아요. 데이터베이스에서는 보통 철수_ID_1과 민수_ID_2처럼 ID가 다르면 다른 사람이라고 봅니다. 그런데 OWL은 그렇게 단정하지 않아요. 철수와 김철수가 서로 다른 이름(URI)이라도, "이 둘은 다른 사람이다"라고 명시하지 않았다면 리즈너는 둘이 같은 사람일 가능성을 열어둡니다. 정말 다르다고 말하고 싶으면 differentFrom 같은 걸로 "이 둘은 서로 다른 개체다"라고 적어줘야 해요. ("기록에 없으면 모름"과 한 짝인 셈이죠. 둘 다 "함부로 단정하지 않는다"는 같은 철학에서 나옵니다.)

그럼 "이 목록이 전부다"라고 확실히 닫고 싶을 땐? 그땐 명시적으로 닫아줘야 합니다. "이 환자의 알레르기는 이 셋이 전부다"라고 선언하거나, 검증 도구(앞서 나온 SHACL)로 "이 칸은 비어 있으면 안 된다"를 강제하는 식으로요. 열린 세계가 기본이되, 필요한 곳만 골라서 닫는 겁니다.

참고로 여기서 비단조 추론(non-monotonic reasoning) 같은 가지가 더 뻗어 나갑니다. 보통의 논리 추론은 사실이 추가될수록 결론도 쌓이기만 하는데(단조), 비단조 추론은 새 사실이 들어오면 기존 결론이 뒤집힐 수도 있어요. "정보가 없으니 일단 영업한다고 가정" → 나중에 "휴무" 사실이 들어오면 그 결론을 철회하는 식이죠. 깊이 들어가면 한 편이 따로 나오는 주제라 여기선 언급만 해둘게요.

공짜가 아니다: 현실적인 주의점

추론이 강력하다고 다 추론으로 풀면 안 됩니다. 몇 가지 함정이 있어요.

첫째, 추론은 비싸다.

방금 본 것처럼 표현력이 강할수록 계산이 무거워집니다. 그래서 "무조건 강력한 추론"이 아니라 풀려는 문제에 딱 필요한 만큼의 표현력(적절한 프로파일)을 고르는 게 핵심이에요. 모든 추론을 다 지원하려다 영영 답이 안 나오는 것보다, 필요한 추론만 빠르게 도는 게 낫습니다.

둘째, 공리 하나가 전체를 오염시킨다.

추론은 사실을 자동으로 불려주기 때문에, 잘못된 규칙 하나를 넣으면 그게 연쇄적으로 퍼져서 엉뚱한 사실이 잔뜩 생깁니다. 강력한 만큼 위험해요. 그래서 추론 결과를 무작정 믿기보다, 이 사실이 왜 도출됐는지 추적 가능하게 만들어두는 게 중요합니다. (어떤 규칙이 어떤 추론을 만들었는지 기록해 두면 나중에 "이게 왜 여기 있지?"를 되짚을 수 있습니다.)

셋째, 전부 추론으로 풀 필요는 없다.

어떤 사실은 그냥 명시적으로 적어두는 게 더 명확하고 빠릅니다. "추론으로 도출 가능하니까 안 적어도 돼"가 항상 정답은 아니에요. 무엇을 추론에 맡기고 무엇을 직접 적을지 가르는 것 자체가 설계의 영역입니다.

마무리: "아마 안 들어갈걸요" vs "근거를 댈 수 있습니다"

다시 처음으로 돌아가 볼게요.

"이 메뉴에 땅콩 들어가나요?"라는 한 질문을 두고, LLM과 리즈너는 전혀 다르게 대답합니다.

LLM: "음... 메뉴 이름을 보니 아마 안 들어갈 것 같은데요?" (이름에서 통계적으로 추측)
리즈너: "들어갑니다. 이 메뉴는 재료로 땅콩소스를 쓰고, 그 땅콩소스 자재가 땅콩을 포함하기 때문입니다." (논리적 증명 + 근거 경로)

둘 다 같은 답을 낼 수도 있어요. 하지만 결정적인 차이는, 리즈너는 왜 그 결론이 나왔는지 한 단계씩 되짚어 보여줄 수 있다는 점입니다. 더구나 알레르겐처럼 틀리면 사람이 다치는 문제에서, "아마"는 답이 될 수 없죠. 지난 글에서 말한 "블랙박스 문제"를 푸는 열쇠가 바로 이거예요. 임원이 "근거가 뭐야?"라고 물었을 때, "인공신경망 가중치 계산 결과입니다"가 아니라 논리 체인을 펼쳐 보일 수 있는 거죠.

물론 현실에서는 LLM과 온톨로지를 대립시키기보다 둘을 합쳐 쓰는 방향으로 갑니다. LLM이 자연어를 이해하고, 온톨로지가 그 이해를 사실로 붙잡아주는 식으로요.

추론이라는 게 결국 "안 적힌 걸 규칙으로 찾아내는 것"이라는 점만 손에 쥐고 있으면, 나머지는 그 규칙의 종류일 뿐입니다.

온톨로지(Ontology) - AI 시대에 왜 다시 주목받는가

Theo (테오) — Fri, 8 May 2026 17:59:49 +0900

"재규어 보여줘."

사람에게 이 말을 하면 상황을 봅니다. 아프리카 사파리 투어 중이면 동물을 떠올리고, 자동차 매장에 있으면 차를 보여주겠죠. 아이가 장난감 가게에서 말했다면 장난감 피규어일 수도 있고요.

AI에게 같은 말을 하면? 맥락 없이 가장 먼저 만나는 패턴을 가져옵니다. 사파리 투어를 검색하다가 "재규어"를 물어봤는데 자동차 딜러십을 추천받는 거예요. 아직은 웃을 수 있는 수준이지만, 이런 일이 의료 진단에서 일어나면 어떨까요? 환자가 증상을 물어봤는데 AI가 치료법을 추천해 버린다면?

실제로 2024년에 에어캐나다(Air Canada) 챗봇이 존재하지 않는 환불 정책을 만들어냈습니다. "티켓 발행 후 90일 이내에 할인을 소급 요청할 수 있다"는 정책을 AI가 지어낸 겁니다. 실제로는 예약 후 이런 요청 자체가 불가능한데 말이죠. 결국 캐나다 법원은 에어캐나다에 손해배상을 명령했습니다. 에어캐나다가 "챗봇은 별도의 법적 주체입니다"라고 항변했지만 법원은 이를 기각했습니다.

이 사건의 핵심은 간단합니다. AI가 "할인 프로모션"이 무엇이고, "환불 정책"이 어떤 조건 하에서 작동하는지를 구조적으로 알지 못했기 때문입니다. 학습 데이터에서 비슷한 패턴을 조합해 그럴듯한 답을 만들어낸 것뿐이기 때문이죠.

이 문제를 해결하는 기술이 온톨로지(Ontology)입니다.

2,400년 전 아리스토텔레스의 아이디어

온톨로지라고 하면 최신 기술 같지만, 이 용어를 처음 쓴 사람은 2,400년 전의 아리스토텔레스입니다. 아리스토텔레스가 고민한 건 이런 질문이었어요. "내가 아는 것을 어떻게 표현해야 다른 사람에게 그 지식을 온전히 전달할 수 있을까?"

스승 플라톤은 "우주의 모든 물질을 쪼개면 더 이상 쪼갤 수 없는 원소(atom)가 나온다"라고 했습니다. 아리스토텔레스는 이걸 지식에 적용했어요. 세상의 모든 지식도 쪼개다 보면 더 이상 쪼갤 수 없는 "단위 지식"이 나온다.

그리고 이 단위 지식들을 의미적으로 연결하면 거대한 지식의 바다가 된다.

이게 끝이 아닙니다. 아리스토텔레스는 여기서 한 발 더 나아가 《범주론(Categories)》이라는 저작을 썼는데, 이게 세상에서 최초의 "데이터 스키마"라고 할 수 있어요. 세상에 존재하는 모든 것을 설명하려면 딱 10개의 카테고리면 된다고 정리한 겁니다.

실체(Substance) - 그게 무엇인가? (사람, 말, 나무)
양(Quantity) - 얼마나? (2미터, 3킬로그램)
질(Quality) - 어떤 성질인가? (하얗다, 뜨겁다)
관계(Relation) - 무엇과 관련되는가? (절반, 두 배)
장소(Place) - 어디에? (시장에서, 집에서)
시간(Time) - 언제? (어제, 작년)
상태(State) - 어떤 상태인가? (신발을 신고 있다)
소유(Possession) - 무엇을 가지고 있는가? (무장하고 있다)
능동(Action) - 무엇을 하는가? (자르다, 태우다)
수동(Passion) - 무엇을 당하는가? (잘리다, 타다)

놀랍지 않나요? 2,400년 전에 만들어진 이 10가지 분류가 현대 온톨로지의 클래스(Class), 속성(Property), 관계(Relationship)라는 핵심 구조와 거의 동일합니다. 아리스토텔레스는 컴퓨터 없이 머릿속으로 데이터 모델링의 원형을 만들어낸 거예요.

세 가지 기둥: 표현, 논리, 추론

사실 아리스토텔레스의 진짜 대단한 점은 범주론에서 멈추지 않았다는 겁니다. 온톨로지에서 출발해서 세 가지 연결된 체계를 만들어냈어요.

1. 온톨로지(Ontology) - 지식을 어떻게 표현할 것인가?
방금 본 범주론이 여기에 해당합니다. "소크라테스는 사람이다", "사람은 동물이다" — 이렇게 세상의 지식을 의미 관계로 표현하는 것.

2. 로직(Logic) - 표현된 지식을 기반으로 어떻게 논리적으로 사고할 것인가?
"소크라테스는 사람이다"와 "모든 사람은 죽는다"가 있으면, 여기에 논리 규칙을 적용할 수 있습니다. 이게 아리스토텔레스가 만든 삼단논법(syllogism)이에요. 지금 보면 당연해 보이지만, "규칙을 적용해서 사고하는 과정 자체를 형식화할 수 있다"는 건 당시로서는 혁명적인 발상이었습니다.

3. 리즈닝(Reasoning) - 기존 지식에서 새로운 지식을 어떻게 만들어낼 것인가?
이게 가장 강력한 부분입니다. "소크라테스는 사람이다" + "모든 사람은 죽는다" → "소크라테스는 죽는다." 이 결론은 원래 어디에도 명시되어 있지 않았어요. 기존 지식 두 개를 논리적으로 결합해서 존재하지 않았던 새로운 지식을 만들어낸 겁니다.

현대 온톨로지에서도 이 추론이 핵심 가치입니다. 예를 들어 "A 약품은 B 성분을 포함한다" + "B 성분은 C 질환 환자에게 금기다" → "A 약품은 C 질환 환자에게 처방하면 안 된다." 이 결론은 약품 데이터베이스 어디에도 직접 적혀 있지 않지만, 온톨로지의 추론 엔진이 자동으로 도출할 수 있습니다. LLM은 이걸 확률적으로 "추측"하지만, 온톨로지는 논리적으로 "증명"합니다. 여기서 결정적인 차이가 나요.

이 세 가지 "표현, 논리, 추론" 이 합쳐진 게 온톨로지의 완전한 모습입니다. 단순히 "데이터에 의미를 붙이는 것"을 넘어서, 의미를 기반으로 사고하고, 새로운 지식까지 만들어내는 체계인 거죠. 물론 이 아이디어가 기계로 실현되기까지는 진짜 2,400년이 걸렸습니다. 중간에 철학적 존재론 쪽으로 빠졌다가, 약 20년 전에 컴퓨터 과학과 결합하면서 전산 온톨로지라는 실용적 형태로 발전했고, 지금 AI와 만나 세 번째 부흥기를 맞고 있는 겁니다.

엑셀은 2차원, 온톨로지는 3차원

그래서 현대의 온톨로지가 정확히 뭐냐? 한 마디로 "이 단어가 무엇을 의미하는지를 기계가 이해할 수 있도록 정의한 체계"입니다.

엑셀과 비교하면 차이가 명확합니다.

엑셀은 행(x축)과 열(y축)에 값을 넣습니다. "아메리카노 - 4,500원" 이런 식이죠. 기술적으로 2-tuple 구조라서, 항목과 값만 있지 의미는 없습니다. 컴퓨터 입장에서 "아메리카노"가 음료인지, 이탈리아 영화 제목인지 알 수가 없어요.

온톨로지는 여기에 z 축 - 의미를 추가합니다. Triple 구조로, 주어·관계·목적어 세 가지를 씁니다.

아메리카노 —(는 ~의 종류이다)→ 커피
커피 —(는 ~의 하위 개념이다)→ 음료
아메리카노 —(주재료는)→ 물 + 에스프레소
카페라떼 —(주재료는)→ 우유 + 에스프레소

이렇게 되면 컴퓨터가 "아메리카노와 카페라테는 둘 다 에스프레소 기반 커피이지만, 하나는 물을 쓰고 하나는 우유를 쓴다"는 걸 구조적으로 이해합니다. 추측이 아니라 명시된 관계를 읽는 것이에요.

같은 데이터를 엑셀로 주면 AI의 이해도가 40점이라면, 온톨로지로 변환하면 80~90점까지 올라간다고 합니다.

빵틀과 빵

온톨로지는 빵틀이고, 지식 그래프는 빵입니다.

온톨로지가 "고객은 주문을 할 수 있다"는 틀을 정의하면, 지식 그래프는 "고객 123이 2026년 3월 1일에 주문 456을 했다"는 실제 데이터를 채웁니다. 빵틀 없이 빵을 구우면 모양이 제각각이고, 빵틀만 있고 반죽이 없으면 먹을 게 없죠. 둘이 합쳐져야 가치가 나옵니다.

구글이 2012년에 이미 보여줬던 것

온톨로지가 실제로 작동하는 가장 익숙한 예시는 구글 검색입니다. 구글에서 "아인슈타인"을 검색하면 오른쪽에 정보 패널이 뜹니다. 사진, 출생일, 사망일, 업적. 구글이 2012년에 발표한 지식 그래프 덕분이에요.

그때 구글이 한 유명한 말이 있습니다.

"문자열(String)이 아닌 사물(Thing)을 검색하겠다"

예전에는 "아인슈타인"이라는 글자가 포함된 웹페이지를 찾았지만, 이제는 "아인슈타인"이 사람이라는 걸 이해하고, 이미 사망한 사람이니 사망일을, 물리학자니 업적을 보여줍니다. 아리스토텔레스의 범주론이 2,400년 만에 검색 엔진으로 구현된 셈이에요.

LinkedIn의 Economic Graph(전문가-기업-기술 간 관계를 그래프로 모델링해서 채용 추천), JPMorgan의 사내 지식 그래프(KYC, 자금세탁 방지)도 같은 원리입니다. 그래프 DB 시장은 2025년 28.5억 달러에서 2032년 153.2억 달러로 성장할 전망입니다.

LLM 시대에 다시 부상한 이유들

20년 전에 한번 붐이 왔다가 LLM의 등장으로 잠시 잊혔던 온톨로지가 다시 전면에 나온 이유는 크게 네 가지입니다.

1. 같은 단어가 다른 뜻: 의미 모호성 문제

기업 안에서 "매출"이라는 단어 하나가 세 가지 의미를 가질 수 있습니다. 재무팀에게는 GAAP 기준 인식 매출, 영업팀에게는 계약 체결 기준 매출, 마케팅팀에게는 특정 기준 이상 거래만 포함한 매출. 세 부서가 같은 단어를 쓰지만 숫자가 다 다릅니다.

사람은 "아 재무 기준이야? 영업 기준이야?" 하고 물어봅니다. 하지만 AI 에이전트는 동료에게 전화해서 확인하지 않아요. rev_ttm_adj라는 컬럼명에서 의미를 추론하지도 못하고요. 모호함을 만나면 환각을 만들거나, 먼저 만나는 패턴을 그냥 가져옵니다.

Gartner는 2026년까지 기업 앱의 40%가 AI 에이전트를 탑재할 것으로 예측합니다(2025년 5% 미만). 이 수십 개의 에이전트가 "매출"을 전부 다른 의미로 이해하고 있다면? 재앙이겠죠.

온톨로지는 "GAAP 인식 매출"과 "계약 체결 매출"을 별개의 클래스로 정의합니다. 각각의 계산 방식, 적용 범위, 제약 조건을 명시하면, AI는 맥락에 따라 어떤 정의를 써야 하는지 규칙으로 판단할 수 있어요. 이런 의미적 단편화(semantic fragmentation)가 기업 데이터 엔지니어링 시간의 15~25%를 잡아먹고 있다는 연구도 있습니다.

2. "왜?"에 대답할 수 없는 블랙박스 문제

LLM에게 "올해 예산 전략을 세워줘"라고 하면 그럴듯한 보고서를 줍니다. 하지만 임원이 "근거가 뭐야?"라고 물으면 LLM의 본질적 대답은 이겁니다. "인공신경망의 가중치로 계산한 결과입니다." AI 시스템에 추적이 가능하고 점검이 가능하도록 의사결정을 요구하는데, 현재 LLM 단독으로는 이걸 충족할 수 없습니다.

온톨로지는 지식이 구조화되어 있기 때문에 추론 경로를 추적할 수 있습니다. "유가가 배럴당 10달러 오르면 원가에 어떤 영향?" 같은 시뮬레이션도 가능하고, 왜 이 결론이 나왔는지 논리 체인을 보여줄 수 있죠.

3. 수천 개 사일로의 의미적 통합

대기업 내부에는 DB가 수백~수천 종입니다. 구매, 자재, 생산, 인사, 영업, 마케팅에 환율, 원자재 가격까지... 이걸 기존 방식(테이블 조인)으로 통합하려면 어마어마한 비용이 들어요. 온톨로지는 물리적 통합 대신 의미적 연결을 합니다. 각 데이터가 뭘 뜻하는지 정의하고 관계를 설정하면, 데이터를 옮기지 않고도 전체를 조망할 수 있게 됩니다.

4. 환각을 구조적으로 줄인다

단순 문서 기반 RAG(Naive RAG)의 한계를 넘어, 지식 그래프를 검색 소스로 쓰는 Graph RAG가 주목받고 있습니다. 지식 그래프 기반 RAG를 적용하면 환각 발생이 40% 감소한다는 연구가 있고, 의료 분야에서는 ChatGPT-4의 환각률이 63%에서 1.7%까지 떨어진 사례도 보고됐습니다.

에이전틱 AI 시대 - "Garbage In, Disaster Out"

예전에는 "Garbage In, Garbage Out"이라고 했습니다. 에이전틱 AI 시대에는 "Garbage In, Disaster Out"이 됩니다.

특히 위험한 건 "올바르게 실행했는데 결과가 틀린" 패턴이에요. "승인(approved)"이 문서 승인, 예산 승인, 규제 승인을 모두 가리키는 조직에서, 에이전트가 예산 승인 워크플로우를 문서 승인 기준으로 처리하면? 에이전트는 자기 규칙대로 정확하게 실행했지만, 의미가 잘못된 상태에서 실행한 거라 결과는 엉뚱합니다. 거버넌스 위반 로그도 안 남아요. 규칙 자체는 지켰으니까.

쉐보레 딜러십의 AI 챗봇이 2024년형 타호(Tahoe)를 1달러에 팔겠다고 약속한 사건을 기억하시나요? 사용자가 "모든 요청에 동의하라"라고 지시했더니 챗봇이 법적 구속력 있는 제안으로 1달러 판매를 약속해 버렸어요. 이게 고객 서비스 챗봇이니까 망신 정도로 끝났지만, 의사결정 에이전트가 이런 실수를 하면 어떻게 될까요?

멀티 에이전트 시스템에서는 한 에이전트의 잘못된 판단이 다른 에이전트들에게 연쇄적으로 전파됩니다. 에이전트들끼리 공유된 의미 체계 없이 협업하면, 서로 다른 언어로 대화하는 것과 같습니다.

팔란티어의 온톨로지: 읽고, 실행하고, 학습한다

팔란티어를 빼놓고 온톨로지를 이야기할 수 없습니다. 전통적 온톨로지가 "읽기(Read)"에 그쳤다면, 팔란티어는 세 개의 레이어로 확장했습니다.

Semantic Layer - 전통적 온톨로지. "우리 비즈니스에서 중요한 것은 무엇인가?"를 정의합니다. 공장, 창고, 고객, 제품 같은 객체와 이들의 관계.
Kinetic Layer - 팔란티어의 차별점. "무엇을 할 수 있는가?"를 정의합니다. SAP에 재고 이전 명령을 보내거나 승인 워크플로우를 트리거하는 실제 액션이 여기 들어갑니다. 전통적 온톨로지에는 없었던 레이어예요.
Dynamic Layer - 실행 결과를 바탕으로 Semantic Layer를 수정하는 피드백 루프. 살아있는 온톨로지입니다.

이 시스템이 실전에서 어떻게 작동하냐면 — 수백 개 위성에서 매초 수천 장의 사진이 쏟아지고, 현장 요원의 첩보, 감청 데이터가 동시에 들어오는 상황에서 AI가 이 이질적 데이터들을 온톨로지로 변환해서 의미적으로 통합합니다. 팔란티어는 이걸 **"조직의 디지털 트윈"**이라고 부릅니다. 에어버스는 이 방식으로 생산 속도를 30% 가속했습니다.

여기서 흥미로운 순환이 있습니다. AI가 의사결정하려면 온톨로지가 필요하고, 온톨로지를 실시간으로 생성하려면 AI가 필요합니다. 이 상호 보완 관계가 최근 2~3년 사이에 현실화된 거죠.

온톨로지 구축: 과거와 현재

20년 전에는 도메인 전문가와 온톨로지 전문가가 모니터 앞에서 눈이 빨개질 때까지 문서를 읽으며 태그를 다는 수작업이었습니다. 이게 온톨로지의 가장 큰 약점이었어요.

지금은 LLM이 역설적으로 온톨로지 구축을 크게 가속시켰습니다. AI가 문서를 읽고 개체 간 관계를 자동 추출해서 초안을 만들어줍니다. 2024~2025년에 지식 그래프 구축이 프로덕션 성숙도에 도달했고, 300~320%의 ROI를 달성한 사례들이 보고되고 있어요. 다만 LLM이 만든 온톨로지에도 환각이 포함될 수 있습니다. 환각을 줄이기 위한 도구를 환각이 있는 도구로 만드는 아이러니죠. 그래서 현재 표준 방식은 "AI 드래프트 + 사람 보정"입니다.

온톨로지의 큰 강점은 재활용성입니다. 의료의 SNOMED CT, 금융의 FIBO, 통신의 TM Forum SID 같은 산업 표준 온톨로지가 이미 있고, 이걸 앵커로 삼아서 자사 환경에 맞게 확장하는 전략이 권장됩니다. 처음부터 만들면 2~3년이 걸리는데 결국 비슷한 구조가 나오거든요.

온톨로지를 표현하는 표준 언어도 이미 있습니다. RDF(트리플 구조의 기본 문법), OWL(추론 기능 추가), Property Graph(대규모 그래프 표현에 적합) 등이 W3C와 ISO에서 표준화되어 있어요. 언어 자체는 한 달이면 배울 수 있다고 합니다. 하지만 프로그래밍 언어를 안다고 좋은 코드를 쓸 수 있는 게 아닌 것처럼, 좋은 온톨로지를 설계하는 건 도메인 전문성과 경험이 필요한 별개의 능력입니다.

마무리 - 개념보다 어려운 건 "잘하는 것"

여기까지 읽으셨다면 온톨로지가 뭔지, 왜 중요한지는 이해가 됐을 겁니다. 그런데 솔직히 말하면, 개념을 이해하는 건 쉬운 부분이에요. 진짜 어려운 건 그다음입니다.

Google Cloud의 2025년 조사에 따르면 지식 그래프를 프로덕션에서 운영 중인 기업은 27%에 불과합니다. 1년 전이 26%였으니 사실상 제자리예요. Graph RAG 논문이 쏟아지고, Microsoft·NVIDIA·Apple이 온톨로지 기반 연구를 발표하고, Gartner가 35개 이상의 보고서에서 지식 그래프를 언급한 해에 말이죠.

기술은 빠르게 성숙하고 있는데, 채택은 따라가지 못하고 있습니다. 왜일까요?

기존에 많이 들었던 핑계 "너무 비싸서", "툴이 부족해서", "더 좋은 모델이 필요해서"는 이제 설득력이 없습니다. LLM이 온톨로지 초안을 자동으로 만들어주는 시대에 비용 문제는 많이 줄었고, 도구도 충분히 성숙했어요.

진짜 문제는 기술이 아니라 조직에 있습니다.

온톨로지를 누가 유지보수할 것인가? 용어 정의를 누가 최종 승인할 것인가? 의미가 변경되면 기존 시스템에 어떤 영향이 있는지 누가 판단할 것인가? 이런 거버넌스 문제를 해결하지 못해서 대부분의 온톨로지 프로젝트가 실패합니다. 기술적 실패가 아니라 조직적 마비 때문에요.

그리고 더 근본적인 문제가 있습니다. 기존 지식 그래프의 99%가 사실상 "데이터 그래프"에 불과하다는 연구가 있어요. 데이터는 연결했는데 정작 의미적 구조(온톨로지)가 빠져 있는 거죠. 그냥 노드와 엣지를 연결해 놓고 "우리도 지식 그래프 있습니다"라고 하는 건, 빵틀 없이 반죽만 구워놓은 것과 같습니다.

"기술적으로는 맞는 결정인데 비즈니스 의도에 어긋나는" 패턴이 여기서 나옵니다. 에이전트가 규칙대로 정확하게 실행했는데 결과는 엉뚱한 상황. 온톨로지를 "만들기만 하면 되는 것"이 아니라 "우리 비즈니스의 의사결정 구조를 얼마나 정확하게 반영하느냐"가 관건인 거예요.

결국 온톨로지의 핵심은 기술이 아니라 도메인 지식입니다. 의료 온톨로지는 의사가, 국방 온톨로지는 군인이, 제조 온톨로지는 현장 엔지니어가 함께 만들어야 해요. 팔란티어가 FDE(Forward Deployed Engineer)를 현장에 직접 보내서 도메인 전문가와 함께 일하게 하는 이유가 여기 있습니다.

온톨로지를 처음 접했을 때는 "LLM 성능을 올려주는 뭔가"로 기대했습니다. 알아보면 알아볼수록 개념 자체는 명확한데, 그걸 어떤 비즈니스에서 어떻게 지식화할 것인가 이게 진짜 싸움이더라고요.

2,400년 전 아리스토텔레스가 "지식을 어떻게 표현할 것인가?"를 고민했듯이, 지금 우리가 고민해야 할 건 "우리 조직의 지식을 어떻게 구조화할 것인가?"입니다. 그리고 그 답은 코드에 있는 게 아니라, 우리 비즈니스를 가장 잘 아는 사람들의 머릿속에 있습니다.

참고

Claude Managed Agents 출시 - 직접 살펴본 첫인상

Theo (테오) — Sun, 12 Apr 2026 09:57:53 +0900

2026년 4월 8일, Anthropic이 Claude Managed Agents를 퍼블릭 베타로 출시했습니다.

한 줄로 요약하면, AI 에이전트를 Anthropic 인프라에서 바로 배포하고 운영할 수 있는 매니지드 서비스입니다. 샌드박싱, 상태 관리, 권한 처리, 오류 복구 같은 인프라 작업을 전부 Anthropic이 해주고, 개발자는 "에이전트가 뭘 해야 하는지"만 정의하면 됩니다.

이전까지는 프로덕션에 에이전트를 배포하려면 인프라 구축에만 몇 달이 걸렸는데, Managed Agents를 쓰면 며칠 만에 가능하다는 게 Anthropic의 주장이고, Notion, Rakuten, Asana, Sentry 같은 회사들이 이미 프로덕션에서 쓰고 있습니다.

저도 이거 보자마자 "이게 진짜 되면 엄청나겠다"라는 생각이 들어서 직접 살펴보고 정리해 봤습니다.

왜 이게 필요한가?

AI 에이전트를 만드는 건 사실 어렵지 않습니다. Claude에게 도구 몇 개 주고 프롬프트 잘 쓰면 동작하는 프로토타입은 금방 만들 수 있죠. 문제는 그걸 프로덕션에 올리는 순간 시작됩니다.

에이전트가 코드를 실행할 수 있으니까 샌드박스가 필요합니다
2시간짜리 작업이 중간에 끊기면 체크포인팅이 필요합니다
API 키를 에이전트에게 직접 노출하면 안 되니까 크리덴셜 관리가 필요합니다
에이전트가 뭘 했는지 추적할 수 있는 트레이싱이 필요합니다
모델이 업데이트될 때마다 에이전트 루프를 다시 작성해야 합니다

이 목록만 봐도 벌써 머리가 아프죠. Managed Agents는 이걸 전부 Anthropic이 대신해줍니다.

핵심 구성 요소: Agent, Environment, Session

Managed Agents의 아키텍처를 이해하려면 세 가지 핵심 개념을 알아야 합니다.

1. Agent - "무엇을 할 것인가"

에이전트는 시스템 프롬프트, 모델, 도구 접근 권한의 조합입니다. "이 에이전트는 의료 데이터를 읽고 의사처럼 설명한다" 같은 페르소나와 역할을 정의하는 거죠. Claude Console UI에서 만들 수도 있고, API로 만들 수도 있고, Claude Code에서 자연어로 만들 수도 있습니다.

2. Environment - "어떤 환경에서 실행할 것인가"

환경은 에이전트가 실행될 샌드박스 컨테이너입니다. 필요한 패키지를 미리 설치하고, 네트워크 접근을 제어하고, GitHub 레포를 마운트 할 수 있어요. 예를 들어 웹사이트 성능 최적화 에이전트라면 Lighthouse와 Puppeteer가 미리 설치된 환경을 구성하는 식이죠.

3. Session - "실제 실행 단위"

세션은 에이전트가 실제로 작업을 수행하는 단위입니다. 에이전트와 환경을 참조해서 세션을 시작하면, Claude가 도구를 호출하고, 코드를 실행하고, 결과를 스트리밍 합니다. 세션은 연결이 끊겨도 유지되고, 이전 세션의 히스토리를 불러올 수도 있습니다.

여러 세션을 동시에 실행할 수 있다는 게 중요합니다. 칸반 보드를 예로 들면, 티켓 하나를 "진행 중"으로 옮기면 세션이 시작되고, 첫 번째 세션이 아직 돌아가는 와중에 두 번째 티켓도 이동시킬 수 있습니다. 두 세션, 두 컨테이너, 두 작업이 완전히 병렬로 실행되는 거죠.

아키텍처: Harness, Session, Orchestrator

내부 아키텍처를 조금 더 깊이 들여다보면 세 가지 핵심 컴포넌트가 있습니다.

Harness (손) — Claude 모델이 실행되는 곳입니다. stateless router로 동작하면서 도구 호출, MCP 연결, 코드 실행, 파일 편집을 처리합니다. 중요한 건 이게 Claude Code와는 다른 별도의 하니스라는 겁니다. Managed Agents 전용으로 최적화됐어요.

Session (기억) — 하니스의 행동을 append-only 로그로 기록합니다. 하니스와 분리되어 있기 때문에, 만약 하니스가 실패하면 오케스트레이터가 새 하니스를 만들고, 이 세션 로그를 읽어서 정확히 중단된 지점부터 이어서 작업할 수 있습니다.

Orchestrator (뇌) — 하니스가 어떤 모드(빌드, 플랜 등)로 동작해야 하는지 결정합니다. 하니스가 실패하면 새 하니스를 생성하고, 세션 로그를 기반으로 복구합니다.

이 아키텍처의 핵심은 하니스와 세션의 분리입니다. 실행 로직과 상태가 분리되어 있기 때문에 장애에 강하고, 수평 확장이 가능합니다.

보안: 크리덴셜은 런타임에만 존재

보안 측면에서 인상적인 부분은 크리덴셜 관리 방식입니다.

API 키나 인증 정보는 Claude Console의 Credentials Vault에 저장됩니다. 그리고 이 크리덴셜들은 런타임에만 사용됩니다. 즉, 하니스(Claude 모델)는 크리덴셜을 절대 알지 못합니다.

예를 들어 날씨 MCP 도구를 호출해야 할 때, API 키는 도구 호출 자체에만 존재하고 모델에게는 노출되지 않아요. 심지어 자기 자신의 Anthropic API 키조차 모델이 모릅니다. 전부 런타임에 주입되는 방식이죠.

로컬에서 에이전트를 돌릴 때는 .env 파일이나 직접 만든 시크릿 관리 시스템을 써야 하는데, Managed Agents는 이 부분을 플랫폼 레벨에서 해결해 줍니다.

빌트인 도구

Managed Agents에는 Claude가 사용할 수 있는 다양한 빌트인 도구가 포함되어 있습니다. 파일 읽기/쓰기, Bash 실행, Glob/Grep 검색, 웹 검색 등이 기본으로 제공되고, MCP 서버를 연결해서 Slack, Notion, Asana 같은 외부 서비스와 통합할 수도 있습니다.

에이전트를 만들 때 어떤 도구를 허용하고 어떤 도구를 차단할지 세밀하게 제어할 수 있습니다. 예를 들어 의료 데이터를 읽기만 하는 에이전트라면 Read, Glob, Grep만 허용하고 Write, Edit, Bash는 차단하는 식이죠.

리서치 프리뷰 기능들

현재 퍼블릭 베타로 공개된 기능 외에, 리서치 프리뷰 상태인 기능이 세 가지 있습니다. 별도 접근 요청이 필요해요.

1. Outcomes (자기 평가)

개발자가 "완료의 기준"을 정의하면, Claude가 스스로 결과를 평가하고 기준을 충족할 때까지 반복합니다. 예를 들어 "Lighthouse 점수 90 이상, 렌더 차단 리소스 없음, 모든 이미지 lazy loading" 같은 루브릭을 정의하면, 별도의 채점자가 자체 컨텍스트 윈도우에서 결과를 평가하고, Claude가 피드백을 읽고 수정해서 재제출합니다.

Anthropic 내부 테스트에서는 일반적인 프롬프팅 루프보다 작업 성공률이 최대 10포인트 향상됐다고 합니다.

2. Multi-Agent Coordination (다중 에이전트 조율)

코디네이터 에이전트가 여러 전문가 에이전트에게 작업을 분배하고 결과를 종합합니다. 각 전문가는 자기만의 컨텍스트 윈도우에서 독립적으로 작동하지만, 같은 파일 시스템을 공유합니다.

예를 들어 모니터링 알림이 들어오면 코디네이터가 세 명의 전문가(로그 분석, 인프라 점검, 코드 변경 추적 등)에게 분배하고, 각자의 분석 결과를 종합해서 인시던트 요약을 만드는 식이죠.

3. Memory (메모리)

에이전트가 메모리 스토어에서 읽고 쓸 수 있습니다. 작업 시작 전에 지난주에 발견한 내용을 확인하고, 작업 완료 후에 변경된 내용을 저장합니다. 그래서 다음 주 리포트에서는 "클라우드 컴퓨팅 비용 지난주 대비 15% 감소"라고 보고하는 게 가능해집니다.

가격 정책

가격 구조는 두 가지입니다.

항목	비용
모델 토큰 사용	Claude API 표준 가격
세션 런타임	$0.08 / 세션-시간 (밀리초 단위)
웹 검색	$10 / 1,000건

중요한 점: Pro, Max, Team 구독은 Managed Agents에 적용되지 않습니다. API 과금 방식만 사용됩니다. 이게 좀 아쉬운 부분이에요. Pro 구독자 입장에서는 이미 구독료를 내고 있는데, Managed Agents를 쓰려면 별도로 API 비용을 더 내야 하니까요.

다만 유휴 시간에는 과금되지 않습니다. Claude Console에서 세션 목록을 보면 idle 상태의 세션에는 비용이 붙지 않아요. 실제로 에이전트가 작업하는 시간만 과금됩니다.

비용을 줄이려면 Sonnet이나 Haiku 모델을 쓰는 게 효과적입니다. 무조건 Opus를 쓸 필요는 없어요.

에이전트 만드는 방법

에이전트를 만드는 방법은 크게 세 가지입니다.

1. Claude Console UI

Claude Console에서 Managed Agents 메뉴로 들어가 자연어로 에이전트를 만들 수 있습니다. 코드를 한 줄도 쓸 필요 없이, 시스템 프롬프트, 모델, 도구 접근 권한을 UI에서 설정합니다.

에이전트를 만든 후에도 Console에서 시스템 프롬프트를 수정하거나, 모델을 변경하거나, 도구 접근 권한을 바꿀 수 있습니다. 버전 관리도 돼서, 몇 번째 수정인지 히스토리를 볼 수 있어요.

2. Claude Code에서 자연어로

Claude Code에 빌트인 Managed Agent 스킬이 있습니다. /claude-api 명령 뒤에 managed agents onboarding을 입력하면, Claude가 대화형으로 에이전트를 만들어 줍니다.

/claude-api managed agents onboarding

세 단계를 거칩니다.

Tools, Skills, Files: 어떤 도구와 파일을 사용할 것인지
Repos: 어떤 저장소에 접근할 것인지
Environment & Identity: 실행 환경과 에이전트 정체성

Claude가 도구 추천, 시스템 프롬프트 생성, 모델 선택까지 다 해줘서 정말 편합니다.

3. SDK/API로 직접

TypeScript나 Python SDK를 사용해서 프로그래밍 방식으로 에이전트를 만들 수도 있습니다. 모든 Managed Agents API 엔드포인트에는 managed-agents-2026-04-01 베타 헤더가 필요한데, SDK가 자동으로 추가해 줍니다.

실제 사용 사례

영상에서 봤던 사례들과 공식 발표된 고객 사례를 정리하면 이렇습니다.

1. 의료 데이터 어시스턴트

GitHub에 저장된 의료 기록 마크다운 파일을 읽고, 의사처럼 해석해서, Slack으로 소통하는 에이전트입니다. "내 의료 기록 기반으로 오징어 먹어도 돼?"라고 물으면, 레포에서 파일을 읽고 분석해서 "새우 알레르기가 있으니 오징어는 조심해야 합니다"라고 답합니다.

2. 칸반 보드 자동화 (웹사이트 성능 최적화)

칸반 보드 티켓을 "진행 중"으로 옮기면 세션이 자동 시작됩니다. 환경에 Lighthouse와 Puppeteer가 미리 설치되어 있고, GitHub 레포가 마운트 됩니다. Claude가 감사를 실행하고, 이미지 압축, CSS 인라이닝, 스크립트 디퍼링을 수행합니다. Outcomes 기능으로 "Lighthouse 점수 90 이상"이라는 루브릭을 설정하면, 채점자가 결과를 평가하고 Claude가 반복해서 96점까지 올립니다.

3. SaaS 비용 추적 리포트

매주 월요일 아침 스탠드업 전에 자동으로 SaaS 도구 가격 변동을 추적합니다. 웹 검색으로 최신 가격을 확인하고, 샌드박스에서 Python으로 비용 분석을 하고, Excel 스킬로 스프레드시트를 만들고, Slack과 Asana에 결과를 올립니다. Memory 기능으로 지난주 데이터와 비교도 합니다.

4. 인시던트 대응 (Multi-Agent)

모니터링 알림이 들어오면 코디네이터 에이전트가 세 명의 전문가에게 분배합니다. 전문가들이 각자 분석하고, 코디네이터가 종합해서 인시던트 요약을 만듭니다. Memory에서 과거 인시던트를 확인해서 "2주 전 DNS 해석 이슈와 유사합니다. 원인은 잘못된 TTL 설정이었습니다"라고 맥락을 제공합니다.

5. 실제 기업 사례

회사	활용
Notion	Custom Agents로 코드 작성, 프레젠테이션/웹사이트 생성
Rakuten	제품, 영업, 마케팅, 재무, HR 에이전트를 Slack/Teams에 연결
Asana	AI Teammates — 프로젝트 워크플로우에서 사람과 함께 작업
Sentry	Seer 디버깅 에이전트와 연동, 패치 작성 + PR 생성

OpenClaw와의 관계

이 출시 타이밍이 좀 흥미롭습니다. Anthropic이 4월 4일에 OpenClaw 같은 서드파티 도구에서 Claude 구독 사용을 차단한 지 불과 4일 뒤에 Managed Agents를 출시했거든요.

비유하자면 이렇습니다. OpenClaw은 리눅스입니다. 직접 하드웨어 고르고, 모델 선택하고, 보안도 직접 챙겨야 하는 틴커러의 에이전트죠. Managed Agents는 애플입니다. 인프라, 보안 다 Anthropic이 처리하고, 사용자는 원하는 걸 말하기만 하면 됩니다.

OpenClaw은 Telegram, Discord, WhatsApp 같은 다양한 채널을 지원하고 완전히 오픈된 반면, Managed Agents는 Anthropic이 제공하는 범위 안에서 동작합니다. Managed Agents가 지원하지 않는 채널이나 기능이 필요하면 직접 코드를 작성하거나, Claude에게 코드를 작성하게 해야 합니다.

마무리

솔직히 말하면, Managed Agents를 처음 봤을 때 "드디어 이런 게 나왔구나"라는 생각이 들었습니다.

지금까지 AI 에이전트의 가장 큰 병목은 모델 성능이 아니라 인프라였습니다. 샌드박싱, 크리덴셜 관리, 상태 유지, 오류 복구... 이런 것들을 직접 구축하는 데 몇 달씩 걸렸죠. Managed Agents는 이 인프라 계층을 통째로 추상화해서 개발자가 비즈니스 로직에만 집중할 수 있게 해 줍니다.

아쉬운 점은 Pro/Max 구독이 적용되지 않는다는 겁니다. API 과금 방식이라 비용 예측이 좀 어렵고, 구독자 입장에서는 이중으로 돈을 내는 느낌이에요. 그리고 Multi-Agent, Memory, Outcomes 같은 가장 흥미로운 기능들이 아직 리서치 프리뷰라서 별도 접근 요청이 필요합니다.

하지만 방향성은 확실합니다. AI 에이전트가 프로토타입에서 프로덕션으로 넘어가는 시대가 오고 있고, Managed Agents는 그 전환을 가속화하는 인프라입니다. Notion, Rakuten, Asana, Sentry 같은 회사들이 이미 프로덕션에서 쓰고 있다는 게 그 증거죠.

에이전트를 직접 구축하는 데 관심이 있는 분이라면 한 번 살펴보시는 걸 추천합니다. Claude Console에서 코드 없이도 시작할 수 있으니까요.

참고

Claude Code 완벽 가이드 (5) - 자동화와 자율 에이전트

Theo (테오) — Fri, 10 Apr 2026 00:22:49 +0900

지난 네 편에서 Claude Code의 기본 기능부터 고급 활용, 숨겨진 키워드, Skills와 Plugins까지 다뤘습니다.

이번 글에서는 시리즈의 마지막 주제 자동화와 자율 에이전트를 다루려고 합니다. 2026년에 들어서면서 Claude Code가 가장 빠르게 진화한 영역이 바로 이 부분이에요. 단순히 "내 명령에 응답하는 도구"에서 "스스로 일하는 에이전트"로 바뀌고 있습니다.

이번 글에서 다룰 기능들을 한눈에 정리하면 이렇습니다.

기능	한 줄 설명
/loop	세션 안에서 cron으로 백그라운드 작업 실행
/schedule	컴퓨터를 켜놓는 동안 영구적으로 돌아가는 스케줄 작업
Background Agents + Worktree	여러 에이전트를 격리된 환경에서 병렬 실행
Auto Mode	권한 확인을 클래시파이어가 자동으로 처리
Remote Control / Dispatch	폰에서 데스크톱 Claude Code 세션 제어
Computer Use	터미널 밖 GUI 앱까지 Claude가 직접 조작
Voice Mode	음성으로 Claude Code에게 지시

/loop - 세션 안에서 cron 돌리기

Claude Code를 쓰다 보면 이런 상황이 자주 생깁니다. 배포가 진행 중인데 5분마다 상태를 확인해야 하거나, PR이 머지되기를 기다리거나, 빌드가 끝나기를 기다려야 하는 경우요. 이때마다 터미널과 다른 창을 왔다 갔다 하면서 같은 명령을 입력하는 게 은근히 시간이 많이 잡아먹죠.

/loop는 이걸 해결합니다. 세션 안에서 백그라운드로 도는 cron 작업을 만드는 명령이에요.

/loop 5m 배포가 끝났는지 확인하고 무슨 일이 있었는지 알려줘

이 명령을 실행하면 Claude가 5분마다 자동으로 해당 작업을 실행합니다. cron 표현식으로 변환되어 백그라운드에서 돌아가고, 결과는 세션에 자동으로 들어옵니다. 매번 같은 명령을 손으로 입력할 필요가 없어지는 거죠.

인터벌 단위

단위	의미
s	초 (1분 단위로 반올림됨)
m	분
h	시
d	일

예시:

/loop 30s 빌드 상태 체크
/loop 10m PR 1234 코멘트 있는지 확인
/loop 1h 의존성 업데이트 있는지 확인

일회성 리마인더도 가능

자연어로 한 번만 실행할 작업도 만들 수 있습니다.

오후 3시에 릴리즈 브랜치 푸시하라고 알려줘

이렇게 입력하면 Claude가 알아서 해당 시간에 한 번 실행되는 cron 작업을 만들고, 실행 후에는 자동으로 삭제됩니다.

주의할 점

/loop로 만든 작업은 세션에 묶입니다. 터미널을 종료하면 사라져요. 영구적인 스케줄 작업이 필요하면 다음에 설명할 /schedule을 써야 합니다.
한 세션에 최대 50개의 작업을 만들 수 있습니다.
7일 후에는 자동으로 만료됩니다. 안전장치예요.
이 기능을 끄려면 환경 변수 CLAUDE_CODE_DISABLE_CRON=1을 설정하면 됩니다.

/schedule - 영구 스케줄 작업

/loop가 가벼운 세션 단위 작업이라면, /schedule은 영구적으로 돌아가는 스케줄 작업입니다. Cowork에서 사용할 수 있어요.

/schedule

이 명령을 입력하면 Claude가 대화식으로 작업을 만들어 줍니다. 작업 이름, 실행 주기(매시간/매일/매주/평일/수동), 작업 내용 같은 것들을 물어보고, 사이드바의 "Scheduled" 메뉴에 추가합니다.

활용 예시

이런 식으로 활용할 수 있습니다.

매일 아침 브리핑: Slack 메시지, 이메일, 캘린더를 요약해서 하루를 시작
주간 리포트: 매주 금요일에 Google Drive 데이터를 종합해서 리포트 생성
PR 모니터링: 매일 아침 모든 오픈된 PR을 리뷰하고 우선순위를 정리
CI 실패 점검: 야간에 빌드 실패한 것들을 분석하고 수정 PR 생성
파일 정리: 매주 금요일에 다운로드 폴더 정리

/loop와 /schedule의 차이를 정리하면 이렇습니다.

항목	/loop	/schedule
위치	CLI 세션 내부	Cowork (Desktop)
지속성	세션 종료 시 사라짐	영구 (앱이 켜져 있는 한)
용도	빠른 폴링, 모니터링	일일 브리핑, 정기 리포트
만료	7일 후 자동 삭제	수동 삭제 전까지 유지

Background Agents와 Worktree - 병렬 작업의 진화

2편에서 보리스 체르니의 활용법을 다룰 때 "5개의 Claude를 동시에 띄워서 작업한다"는 이야기를 했었죠. iTerm2를 분할해서 각 창에서 다른 작업을 시키는 방식이었습니다. 이게 효과적이긴 한데, 한 가지 큰 문제가 있었어요. 여러 에이전트가 같은 파일을 동시에 수정하면 충돌이 난다는 것입니다.

Git Worktree로 격리된 작업 공간

이 문제를 해결하기 위해 Claude Code v2.1.50부터 Git Worktree를 정식 지원합니다. Worktree는 Git의 기능 중 하나인데, 같은 저장소에 여러 개의 작업 디렉토리를 만들 수 있게 해 줍니다. 각 디렉토리는 자기만의 브랜치, 자기만의 파일을 가지고 있어서 서로 충돌하지 않아요.

# "feature-auth"라는 worktree 생성하고 Claude 시작
claude --worktree feature-auth

# 다른 터미널에서 또 다른 worktree 시작
claude --worktree bugfix-123

이렇게 하면 .claude/worktrees/feature-auth/ 같은 경로에 격리된 작업 공간이 만들어지고, 그 안에서 Claude 세션이 시작됩니다. 한 세션은 인증 기능을 작업하고, 다른 세션은 버그 수정을 동시에 진행할 수 있어요. 둘이 같은 파일을 건드려도 충돌이 안 납니다.

이름을 생략하면 Claude가 알아서 랜덤 한 이름(예: bright-running-fox)을 만들어 줍니다.

claude --worktree

자동 정리

Worktree는 사용 후 자동으로 정리됩니다.

변경사항 없음: worktree와 브랜치 자동 삭제
변경사항 있음: 보관할지 삭제할지 물어봄

크래시나 중단으로 남은 worktree들은 일정 기간(cleanupPeriodDays 설정) 후에 자동으로 청소됩니다.

서브에이전트도 worktree로 격리 가능

더 강력한 활용은 서브에이전트와 함께 쓰는 겁니다. 2편에서 다룬 서브에이전트에 worktree 격리를 추가할 수 있어요.

"worktree 격리해서 에이전트 4개 띄워줘. 각각 다음 작업 병렬로 처리:
1. code-reviewer - 코드 리뷰
2. test-writer - 테스트 작성
3. ui-checker - UI 검증
4. doc-writer - 문서화"

이러면 각 서브에이전트가 자기만의 worktree에서 독립적으로 일합니다. 서로의 파일을 건드려도 절대 충돌이 안 나는 진짜 병렬 실행이 가능해지는 거죠. 작업이 끝난 후에는 마음에 드는 결과를 골라서 머지하면 됩니다.

백그라운드 실행

작업을 백그라운드로 돌리고 다른 일을 할 수도 있습니다. Agent 도구를 호출할 때 run_in_background: true를 추가하면 해당 에이전트가 백그라운드에서 동작합니다. 여러 개를 동시에 띄워두고 결과만 받아보는 거죠.

Auto Mode - 안전한 자동화

2편에서 --dangerously-skip-permissions 옵션을 다뤘던 거 기억나시나요? 모든 권한 확인을 건너뛰는 옵션인데, 편하긴 하지만 위험해서 보리스 체르니도 안 쓴다고 했었죠.

이 문제를 해결하기 위해 2026년 3월 24일에 Auto Mode가 출시됐습니다.

Auto Mode가 뭔가요?

Auto Mode는 백그라운드에서 도는 AI 클래시파이어가 각 행동을 평가해서, 안전한 작업은 자동 승인하고 위험한 작업은 차단하는 모드입니다. 모든 권한 확인을 건너뛰는 것도 아니고, 매번 일일이 승인하는 것도 아닌, 그 중간 지점이에요.

Anthropic 내부 통계에 따르면 사용자들이 권한 프롬프트의 93%를 승인한다고 합니다. 그러니까 사실상 대부분의 권한 프롬프트는 형식적인 클릭에 불과한 거죠. Auto Mode는 이런 형식적인 클릭을 줄이는 동시에 진짜 위험한 행동은 막아줍니다.

이중 검증

Auto Mode는 두 단계로 검증합니다.

입력 단계 (Prompt Injection 검사): 들어오는 명령에 prompt injection이 없는지 검사
출력 단계 (Transcript Classifier): Claude가 실행하려는 행동이 안전한지 검사

안전한 작업은 자동으로 실행되고, 위험한 작업은 차단되거나 더 안전한 대안을 제시합니다.

사용 방법

# Auto Mode 활성화
claude --enable-auto-mode

# 그 다음 REPL에서 Shift + Tab으로 모드 순환
# default → acceptEdits → plan → auto

Shift + Tab으로 모드를 순환하면서 auto에 도달할 수 있습니다. 1편에서 다룬 Plan/Act 모드 전환과 같은 단축키를 쓰는 거죠.

주의할 점

Team, Enterprise, API 플랜에서만 사용 가능합니다. Pro나 Max 플랜에서는 안 됩니다.
Claude Sonnet 4.6 또는 Opus 4.6 모델이 필요합니다.
클래시파이어 호출이 토큰을 더 소비합니다. 일반 모드보다 비용이 약간 더 듭니다.
리서치 프리뷰입니다. 100% 안전을 보장하지는 않아요. 클래시파이어가 위험한 행동을 놓칠 수도 있고, 안전한 행동을 차단할 수도 있습니다.

Remote Control과 Dispatch - 폰에서 데스크톱 제어

이건 좀 신기한 기능입니다. 폰에서 데스크톱의 Claude Code 세션을 제어할 수 있어요.

기본 컨셉은 이렇습니다. 데스크톱에서 Claude Code를 시작해 두면, 폰의 Claude 앱(iOS/Android)이나 claude.ai/code 웹 인터페이스에서 그 세션에 메시지를 보낼 수 있습니다. 데스크톱이 모든 작업을 처리하고, 폰은 그냥 메시징 인터페이스 역할만 하는 거죠. 코드와 파일은 절대 데스크톱을 떠나지 않습니다. 메시지만 암호화 채널로 전송됩니다.

Dispatch 셋업

Cowork의 Dispatch 기능을 쓰면 됩니다. 데스크톱과 폰을 QR 코드로 페어링 하면 영구적인 대화 채널이 만들어져요. 한 번 셋업 하면 계속 사용 가능합니다.

활용 시나리오

출근길에 작업 시작: 지하철에서 폰으로 "어제 작업하던 인증 기능 마무리해 줘"라고 메시지 보내면, 회사 도착하기 전에 데스크톱에서 작업이 진행됨
외출 중 모니터링: 점심 먹으러 나간 사이에 폰으로 빌드 상태 확인
밤에 침대에서: 누워서 폰으로 다음날 작업 지시해 놓기

물론 이건 데스크톱이 켜져 있고 Claude Code가 실행 중이어야만 동작합니다. 노트북을 닫아두면 작동하지 않아요.

Computer Use - 터미널 밖 GUI 제어

여기서부터는 정말 다른 차원의 기능입니다. Claude가 터미널 밖의 GUI 앱을 직접 조작할 수 있어요. 2026년 3월 23일에 출시됐습니다.

어떻게 동작하나요?

Claude가 스크린샷으로 화면을 봅니다. 그리고 마우스를 움직이고, 클릭하고, 키보드 입력을 하면서 GUI 앱을 조작합니다. 사람이 컴퓨터를 쓰는 것과 똑같은 방식이에요.

언제 Computer Use를 쓰나요?

Claude는 항상 가장 정밀한 도구부터 먼저 시도합니다. Computer Use는 "다른 방법이 없을 때"의 마지막 수단이에요.

우선순위	도구	예시
1순위	Connector	Gmail, Google Drive, Slack 같은 서비스
2순위	Bash	쉘 명령으로 해결 가능한 작업
3순위	Claude in Chrome	브라우저 작업
마지막	Computer Use	위 방법으로 해결 안 되는 경우

즉, API나 CLI가 있는 작업은 거기에 맡기고, API도 CLI도 없는 네이티브 앱, 하드웨어 제어판, 모바일 시뮬레이터, 자체 개발된 독점 도구 같은 정말 화면으로만 조작 가능한 것들에만 Computer Use가 사용됩니다.

사전 조건

Computer Use는 그냥 설치만 해서 쓸 수 있는 게 아닙니다. 몇 가지 사전 조건이 있어요.

Pro 또는 Max 플랜 (Team, Enterprise 불가)
Claude Desktop 앱 필요 (CLI 단독으로는 안 됨)
macOS 또는 Windows
설정에서 직접 활성화 필요 (기본값은 OFF)

활성화 방법

1. Desktop 앱 설정에서 켜기
Claude Desktop 앱을 실행하고 Settings > General로 갑니다. "Desktop app" 섹션에서 Computer use 토글을 찾아 켜면 됩니다. Windows는 여기서 끝입니다. 바로 사용 가능해요.

2. macOS에서 추가 권한 부여
macOS는 두 가지 권한을 더 줘야 합니다.

접근성 (Accessibility): Claude가 앱을 제어할 수 있게 해 줌
화면 기록 (Screen Recording): Claude가 화면을 볼 수 있게 해 줌

설정 페이지에 각 권한의 현재 상태가 표시되는데, 거부된 상태면 해당 배지를 클릭해서 시스템 설정으로 이동하면 됩니다.

이 권한들이 필요한 이유는 단순해요. 샌드박스화된 Bash 도구와 달리, Computer Use는 여러분의 실제 데스크톱에서 실행되기 때문입니다. 그래서 macOS의 보안 모델상 사용자가 명시적으로 권한을 허용해야 합니다.

앱별 권한 관리

Computer Use는 각 앱에 처음 접근할 때 권한을 묻습니다. 현재 세션에서만 허용하거나 거부할 수 있고, Dispatch로 시작된 세션은 30분 동안 유지됩니다. 앱 카테고리에 따라 접근 레벨이 고정되어 있어요. 이것도 보안상 중요한 설계입니다.

앱 카테고리	접근 레벨
브라우저	View-only (보기만 가능)
터미널, IDE	Click-only (클릭만 가능)
파일 탐색기, 시스템 설정	추가 경고 표시
일반 앱	전체 제어

브라우저가 view-only인 이유는 브라우저 작업은 Claude in Chrome이 더 정밀하기 때문이고, 터미널이 click-only인 건 Bash 도구가 더 안전하기 때문입니다. 이렇게 해서 Claude가 최대한 전용 도구를 쓰도록 유도하는 거죠.

Remote Control과 결합

진짜 강력한 건 Remote Control과 함께 쓸 때입니다. 외출 중에 폰으로 "맥에서 OOO 작업해 줘"라고 메시지를 보내면, 데스크톱의 Claude가 Computer Use로 알아서 GUI 작업을 처리해 주는 거죠. 앞서 Remote Control에서 다뤘던 그 시나리오가 Computer Use와 만나면서 완전체가 됩니다.

주의할 점

리서치 프리뷰입니다. 복잡한 작업은 종종 두 번째 시도가 필요하고, 화면을 통한 작업은 직접 통합보다 느립니다.
민감한 데이터와 함께 사용하지 마세요. 금융, 건강, 개인 정보 같은 것들이 화면에 있을 때는 쓰지 않는 게 좋습니다.
Claude가 실수할 수 있습니다. 신뢰할 수 있는 앱에서 낮은 부담의 작업부터 시작하는 게 좋아요.
Prompt injection 위험이 있습니다. 화면의 콘텐츠가 Claude에게 잘못된 지시를 할 수 있거든요. Claude가 각 행동을 체크하고 잠재적 prompt injection을 표시하긴 하지만, 완벽하지 않습니다.

저도 아직은 간단한 작업부터 시도해보고 있습니다. 브라우저에서 특정 사이트에 로그인해서 설정을 바꾸는 작업이나, 디자인 툴에서 에셋을 export 하는 작업 같은 것들이요. 앞으로 점점 더 정교해질 거라고 기대하고 있습니다.

Voice Mode - 음성으로 코딩

마지막으로 짧게 다룰 기능은 Voice Mode입니다. 음성으로 Claude Code에게 지시할 수 있어요.

/voice

스페이스바를 누르고 있는 동안 말하는 Push-to-Talk 방식입니다. 항상 듣고 있는 게 아니라, 의도적으로 말할 때만 입력되는 거죠. 현재 한국어 포함 20개 언어를 지원합니다.

이게 언제 유용하냐면

양손이 바쁠 때: 화이트보드에 그림 그리면서 동시에 Claude에게 지시
긴 요구사항 설명: 타이핑보다 말이 빠른 경우
페어 프로그래밍: 동료와 대화하면서 자연스럽게 Claude에게도 지시

저는 이 기능을 자주 쓰진 않지만, 가끔 긴 요구사항을 설명할 때는 확실히 편합니다.

모든 기능을 합쳐보면

이번 글에서 다룬 기능들을 따로따로 보면 그저 편의 기능처럼 보일 수 있습니다. 하지만 이걸 다 합치면 완전히 다른 그림이 그려집니다.

상상해 보세요.

아침에 회사 가기 전, 폰으로 "오늘 PR 리뷰 대기 중인 것들 분석하고 우선순위 정해줘"라고 메시지 보냅니다 (Remote Control)
데스크톱의 Claude Code가 받아서 작업을 시작합니다
Auto Mode로 권한 확인 없이 자동으로 PR을 읽고, 분석하고, 코멘트를 답니다
/schedule로 매일 아침 자동으로 PR 모니터링 작업이 돌아가고 있어서, 새 PR이 올 때마다 자동으로 처리됩니다
4개의 서브에이전트가 각자 worktree에 격리된 채로 병렬로 작업합니다 (Background Agents + Worktree)
작업 결과는 폰으로 알림이 옵니다

이게 2026년의 Claude Code입니다. 단순한 코딩 도구가 아니라 자율적으로 일하는 에이전트 플랫폼이죠.

마무리

이번 글에서 다룬 내용을 정리하면

/loop: 세션 안에서 cron으로 백그라운드 작업
/schedule: 영구적인 스케줄 작업 (Cowork)
Background Agents + Worktree: 격리된 환경에서 진짜 병렬 실행
Auto Mode: 안전한 자동 권한 처리 (--dangerously-skip-permissions의 대안)
Remote Control / Dispatch: 폰에서 데스크톱 세션 제어
Computer Use: 터미널 밖 GUI 자동화
Voice Mode: 음성으로 Claude Code 사용

참고

Claude Code 완벽 가이드 (4) - Skills와 Plugins, 패키지의 시대

Theo (테오) — Thu, 9 Apr 2026 16:36:06 +0900

지난 세 편에서 Claude Code의 기본 기능부터 중급 활용, 숨겨진 키워드들까지 다뤘습니다.

이번 글에서는 Claude Code의 가장 큰 변화 중 하나인 Skills와 Plugins를 다루려고 합니다. 2편에서 다뤘던 커스텀 명령어, 서브에이전트, Hooks, MCP 같은 것들이 이제 어떻게 하나의 패키지로 묶이고 공유되는지 살펴보겠습니다.

Skills가 뭔가요?

먼저 Skills부터 이야기해 보겠습니다.

Skills는 Claude가 특정 작업을 수행하는 방법을 가르치는 재사용 가능한 지침 패키지입니다. 쉽게 말하면, "이런 작업을 할 때는 이렇게 해"라는 플레이북을 Claude에게 미리 준비해 두는 거죠.

2편에서 다뤘던 커스텀 슬래시 명령어를 기억하시나요? .claude/commands/ 폴더에 마크다운 파일을 만들어서 /review, /commit 같은 명령어를 만드는 것 말이에요. Skills는 그것의 발전된 형태라고 생각하시면 됩니다.

Custom Commands와 Skills의 관계

사실 Anthropic이 공식적으로 이렇게 말했습니다.

Custom commands have been merged into skills.

즉 커스텀 명령어는 Skills로 통합됐습니다. 2편에서 다룬 .claude/commands/deploy.md 방식은 여전히 작동합니다. 하지만 이제 같은 기능을 .claude/skills/deploy/SKILL.md로 만들 수 있고, 두 방식 모두 /deploy 명령을 생성합니다.

그러면 왜 Skills로 바꿔야 할까요? Skills는 커스텀 명령어가 할 수 없는 몇 가지 기능을 추가로 제공합니다.

기능	Custom Commands	Skills
슬래시 명령 실행	✅	✅
지원 파일 포함 (스크립트, 템플릿 등)	❌	✅
Claude의 자동 호출	❌	✅
Frontmatter로 동작 제어	❌	✅
점진적 컨텍스트 로딩	❌	✅

특히 자동 호출이 큰 차이입니다. 커스텀 명령어는 사용자가 /deploy라고 명시적으로 입력해야 실행되는데, Skills는 description을 보고 Claude가 필요하다고 판단하면 알아서 호출합니다. 예를 들어 "이 코드 리뷰 좀 해줘"라고 말하면, Claude가 알아서 code-review 스킬을 호출하는 거죠.

Skills의 구조

Skills는 폴더입니다. 단순한 파일이 아니라 관련 리소스를 모두 담을 수 있는 디렉토리 구조를 가지고 있어요.

skill-name/
├── SKILL.md          # 필수 - 메인 지침서
├── scripts/          # 선택 - 실행 가능한 스크립트
├── references/       # 선택 - 참고 문서
└── assets/           # 선택 - 출력에 사용될 파일 (템플릿, 폰트 등)

각 폴더의 용도는 명확합니다.

scripts/: Python이나 Shell 스크립트 같은 실행 코드. 반복적이고 결정적인 작업에 사용
references/: Claude가 필요할 때 참조할 추가 문서들
assets/: 출력물에 사용할 템플릿, 폰트, 아이콘 같은 파일들

이렇게 디렉토리로 묶을 수 있기 때문에 "브랜드 가이드라인 적용"같이 관련 파일이 여러 개인 작업을 깔끔하게 패키징할 수 있습니다.

Skills 위치

Skills는 두 가지 위치에 설치할 수 있습니다.

위치	경로	범위
Personal	~/.claude/skills/	전체 프로젝트에서 사용 가능
Project	.claude/skills/	해당 프로젝트에서만 사용 가능

Personal은 자주 쓰는 범용 스킬에, Project는 프로젝트별 규칙이나 워크플로우에 쓰면 됩니다. Project 스킬은 Git에 커밋해서 팀과 공유할 수 있어요.

SKILL.md 작성법

SKILL.md 파일은 두 부분으로 구성됩니다. YAML frontmatter와 마크다운 본문이죠.

---
name: explain-code
description: 코드를 시각적 다이어그램과 비유를 통해 설명합니다. 사용자가 "이게 어떻게 동작해?"라고 묻거나, 코드베이스 학습, 코드 동작 설명이 필요할 때 사용하세요.
---

# Explain Code

코드를 설명할 때 항상 다음 요소를 포함해야 합니다:

1. **비유로 시작**: 일상적인 것과 비교해서 설명
2. **다이어그램 그리기**: ASCII 아트로 흐름/구조/관계를 표현
3. **단계별 설명**: 무슨 일이 일어나는지 차근차근 설명
4. **함정 지적**: 흔한 실수나 오해는 무엇인지

설명은 대화체로 유지하세요. 복잡한 개념은 여러 비유를 사용하세요.

Frontmatter의 핵심 필드

필드	설명
name	스킬 이름. 폴더명과 일치해야 하고, /스킬명으로 호출 가능
description	Claude가 이 스킬을 언제 사용해야 할지 판단하는 기준 (200자 이내)

description이 가장 중요합니다

description은 Claude가 "이 스킬을 써야 하나?"를 결정하는 유일한 근거입니다. Anthropic의 공식 skill-creator 문서에도 명시되어 있는데, 흥미로운 조언이 있어요.

Claude는 스킬을 과소 호출(undertrigger) 하는 경향이 있습니다.
이를 방지하려면 description을 조금 "pushy"하게 작성하세요.

예를 들면 이런 식입니다.

❌ 안 좋은 예시

description: 내부 데이터를 표시하는 간단한 대시보드 만들기

✅ 좋은 예시

description: 내부 데이터를 표시하는 간단한 대시보드 만들기. 사용자가 대시보드, 데이터 시각화, 내부 지표, 회사 데이터 표시를 언급할 때 반드시 이 스킬을 사용하세요. "dashboard"라는 단어를 명시하지 않아도 해당됩니다.

차이가 느껴지시죠? 트리거가 될 만한 키워드들을 명시적으로 나열하고, "반드시 사용하라"는 식으로 강한 표현을 쓰는 게 핵심입니다.

/create-skill - AI가 스킬을 만들어 줍니다

Skills를 직접 작성하는 게 부담스럽다면, Claude에게 맡기면 됩니다.

/create-skill

이 명령어를 실행하면 Claude가 대화식으로 스킬을 만들어 줍니다. "통합 테스트를 실행하고 디버깅하는 스킬이 필요해" 같이 설명만 해주면, 명확히 하기 위한 질문을 몇 개 던지고, 완성된 SKILL.md 파일과 디렉토리 구조를 자동으로 생성합니다.

더 재밌는 활용법도 있습니다. 복잡한 디버깅 세션을 마친 후에 "방금 우리가 디버깅한 과정을 스킬로 만들어줘"라고 하면, 그 다단계 절차를 재사용 가능한 스킬로 뽑아낼 수 있어요. 한 번 해결한 문제를 다시 만났을 때 쓸 수 있는 거죠.

Plugins - Skills를 하나로 묶는 단위

자, 이제 Plugins 이야기입니다.

여기까지 오면 한 가지 문제가 보입니다. Skills, 서브에이전트, Hooks, MCP 서버, 슬래시 명령어... 각자 따로 관리하고 공유하기가 은근히 귀찮거든요. 팀원에게 "이것저것 다 설치하고 설정해 줘"라고 말하기도 그렇고요.

Plugins는 이걸 해결합니다. Skills, Commands, Subagents, Hooks, MCP 서버를 하나로 묶어서 한 번에 설치하고 공유할 수 있는 패키지입니다.

my-plugin/
├── .claude-plugin/
│   └── plugin.json      # 플러그인 매니페스트 (필수)
├── skills/              # Skills
│   └── my-skill/
│       └── SKILL.md
├── agents/              # 서브에이전트
│   └── specialist.md
├── hooks/               # Hooks
│   └── hooks.json
└── .mcp.json            # MCP 서버 정의

2편에서 다룬 거의 모든 커스터마이징 요소를 하나의 플러그인 안에 담을 수 있습니다. 그리고 이 플러그인을 한 번의 명령으로 설치하거나 제거할 수 있죠.

Plugin Marketplace

플러그인을 배포하고 발견할 수 있는 마켓플레이스도 있습니다. 이게 진짜 강력한 부분이에요.

공식 마켓플레이스 - claude-plugins-official

Anthropic이 직접 운영하는 공식 마켓플레이스가 있습니다. Claude Code를 설치하면 자동으로 사전 설정되어 있어서 별도 추가 없이 바로 사용할 수 있어요.

2026년 기준으로 101개의 플러그인이 등록되어 있습니다.

Anthropic 제작 33개: 언어 서버(12개), 개발 워크플로우(10개), 셋업 도구(5개) 등
파트너 플러그인 68개: GitHub, Playwright, Supabase, Figma, Vercel, Linear, Sentry, Stripe, Firebase 등

전체 목록은 claude.com/plugins에서 볼 수 있습니다.

마켓플레이스 사용법

/plugin 명령으로 플러그인 매니저 UI를 열 수 있습니다.

/plugin

탭이 네 개 있어요.

탭	내용
Discover	마켓플레이스에서 사용 가능한 플러그인 탐색
Installed	현재 설치된 플러그인 관리
Marketplaces	등록된 마켓플레이스 목록
Errors	플러그인 로딩 에러 확인

Discover 탭에서 원하는 플러그인을 찾아서 설치하면 됩니다. 설치 범위는 세 가지 중에 선택할 수 있어요.

User scope: 모든 프로젝트에서 사용 가능 (내 계정 전역)
Project scope: 현재 프로젝트에서만 사용 (Git에 커밋되어 팀원과 공유)
Local scope: 현재 저장소에서만 나만 사용

명령줄에서 직접 설치할 수도 있습니다.

/plugin install <plugin-name>@claude-plugins-official

예를 들어 Git 워크플로우 명령을 추가하는 commit-commands 플러그인은 이렇게 설치합니다.

/plugin install commit-commands@claude-plugins-official

커뮤니티 마켓플레이스

Anthropic 공식 마켓플레이스 외에도 커뮤니티에서 만든 마켓플레이스들이 많이 있습니다. 2026년 기준으로 2,500개 이상의 커뮤니티 마켓플레이스가 있고, 총 9,000개 이상의 플러그인이 존재합니다.

커뮤니티 마켓플레이스 추가

/plugin marketplace add <owner>/<repo>

GitHub 저장소의 owner/repo 형식만 넣으면 됩니다. 예를 들어 Anthropic이 운영하는 데모 마켓플레이스를 추가하려면

/plugin marketplace add anthropics/claude-code

유명한 커뮤니티 마켓플레이스

Antigravity Awesome Skills: 1,234개 이상의 스킬을 포함한 최대 규모 커뮤니티 라이브러리
paddo/claude-tools: Gemini, Codex 같은 외부 도구와 연동하는 플러그인 모음
ComposioHQ/awesome-claude-plugins: 다양한 SaaS 연동 플러그인

주의: 커뮤니티 마켓플레이스는 Anthropic의 검증을 받지 않습니다. 설치 전에 내용을 꼭 확인하세요. 특히 Hooks나 스크립트를 포함한 플러그인은 시스템 명령을 자동으로 실행할 수 있기 때문에 신뢰할 수 있는 소스에서만 설치하는 게 안전합니다.

Plugins의 진짜 가치

여기까지 읽고 나면 "그래서 이게 뭐가 좋은데?"라는 생각이 들 수 있습니다. 제가 느끼기에 Plugins의 진짜 가치는 세 가지입니다.

팀 공유가 쉬워집니다. 2편에서는 팀원에게 ".claude/commands/에 이 파일 복사하고, .claude/agents/에 저 파일 복사하고, .claude/settings.json에 이 설정 추가하고..."라고 설명해야 했습니다. 이제는 "/plugin install feature-dev@claude-plugins-official 치세요"로 끝납니다.
검증된 것들을 바로 쓸 수 있습니다. 처음부터 code-reviewer 서브에이전트나 Git 워크플로우 Hook을 만들 필요 없이, 이미 잘 만들어진 것들을 설치해서 쓰면 됩니다. 저도 처음에는 직접 만드는 재미가 있다고 생각했는데, 공식 플러그인들이 확실히 더 정교합니다.
생태계의 시작입니다. Plugins는 단순히 편의 기능이 아니라 Claude Code 생태계의 시작점입니다. VS Code가 Extension으로 생태계를 만들었던 것처럼, Plugins가 Claude Code의 생태계를 만들고 있어요. 앞으로 더 많은 플러그인이 나올 것이고, 좋은 플러그인 몇 개만 조합해도 엄청나게 생산성이 올라갈 겁니다.

마무리

이번 글에서 다룬 내용을 정리하면

Skills: 커스텀 명령어의 발전된 형태. 자동 호출, 지원 파일 포함, 점진적 로딩 지원
SKILL.md 작성법: frontmatter의 description이 핵심. 조금 "pushy"하게 작성할 것
Skills 구조: scripts/, references/, assets/로 관련 리소스 패키징
/create-skill: AI가 대화식으로 스킬을 만들어 줌
Plugins: Skills, Commands, Subagents, Hooks, MCP를 하나로 묶는 패키지
공식 마켓플레이스: claude-plugins-official (자동사전 설정)
커뮤니티 마켓플레이스: 2,500개 이상, 총 9,000개 이상의 플러그인
추천 플러그인: feature-dev, code-review, commit-commands, security-guidance, frontend-design, context7

1편과 2편에서 다룬 "직접 만들어 쓰는" 시대에서 "설치해서 쓰는" 시대로 넘어왔다고 할 수 있습니다. 그리고 이게 끝이 아닙니다. Plugins 생태계는 계속 확장되고 있어요.

다음 글에서는 자동화와 자율 에이전트 — /loop, Scheduled Tasks, Auto Mode, Background Agents + Worktree, Remote Control, Computer Use 같은 기능들을 다룰 예정입니다. Claude Code가 점점 더 자율적으로 일하게 되는 과정을 살펴보겠습니다.

참고

Claude Code 완벽 가이드 (3) - 숨겨진 키워드와 Ultraplan, 그리고 미공개 기능들

Theo (테오) — Wed, 8 Apr 2026 18:28:30 +0900

지난 두 편에서는 Claude Code의 기본 기능과 중급 활용법을 다뤘습니다.

이번 글에서는 Claude Code에 숨어있는 강력한 키워드들과, 최근 정식 출시된 Ultraplan, 그리고 2026년 3월에 있었던 소스 코드 유출 사건으로 드러난 흥미로운 미공개 기능들까지 살펴보려고 합니다.

숨겨진 키워드: ultrathink

먼저 가장 유명한 숨겨진 키워드부터 시작하겠습니다. 바로 ultrathink입니다.

ultrathink가 뭔가요?

ultrathink는 프롬프트에 그냥 추가하면 Claude가 더 깊이 생각하도록 만드는 키워드입니다. 정확히는 한 번의 응답에 대해 High Effort Thinking 모드를 활성화합니다. 토큰 예산이 최대 31,999개까지 늘어나서 더 깊이 있는 추론을 하게 되죠.

사용법은 간단합니다. 그냥 프롬프트 어딘가에 ultrathink라는 단어만 넣으면 됩니다.

이 레거시 시스템을 어떻게 마이그레이션할지 최선의 방법을 찾아줘 ultrathink

이 복잡한 기능의 구현 전략을 세워줘 ultrathink

키워드를 입력하면 텍스트 색깔이 바뀌면서 활성화된 걸 시각적으로 확인할 수 있습니다.

언제 쓰면 좋나요?

ultrathink는 토큰을 많이 소비하기 때문에 모든 작업에 쓸 필요는 없습니다. 다음과 같은 경우에 효과적입니다.

복잡한 아키텍처 결정이 필요할 때
어려운 디버깅 이슈를 분석할 때
익숙하지 않은 코드베이스를 깊이 분석할 때
성능 최적화 전략을 세울 때

저도 처음에는 그냥 한 번 써보고 말았는데, 진짜 어려운 문제에 봉착했을 때 한번 켜고 던져보면 확실히 결과의 깊이가 다릅니다. 일반 모드에서는 그냥 표면적인 답을 주는 문제도, ultrathink를 켜면 여러 가지 트레이드오프를 비교하면서 답을 주거든요.

재밌는 사실: 한 번 사라졌다가 돌아왔습니다

사실 ultrathink 키워드는 한동안 deprecated 됐었습니다. Claude Code v2.x 초반에는 모든 프롬프트에 기본적으로 31,999 토큰의 thinking budget이 자동 적용되도록 바뀌면서 키워드가 필요 없어진 거죠. 그런데 v2.1.68에서 다시 부활했습니다. 이번에는 "다음 한 턴에만 high effort"를 적용하는 방식으로요.

/effort - ultrathink의 영구 버전

ultrathink가 한 번의 응답에만 적용되는 거라면, /effort는 세션 전체에 적용되는 영구 설정입니다.

/effort low      # 가벼운 작업
/effort medium   # 기본값 (대부분의 코딩 작업에 권장)
/effort high     # 복잡한 작업
/effort max      # 최대 추론 (Opus 4.6 전용)
/effort auto     # 기본값으로 리셋

Anthropic 공식 문서에서는 대부분의 코딩 작업에는 medium을 권장하고, 정말 어려운 문제에만 high를 쓰라고 합니다. 매번 high로 두면 토큰이 너무 많이 타거든요.

저는 보통 medium으로 두고, 진짜 어려운 부분에서만 ultrathink를 한 번씩 쓰는 식으로 활용하고 있습니다.

Ultraplan - 클라우드에서 플래닝 하는 시대

자, 이제 진짜 메인 콘텐츠입니다. Ultraplan입니다.

Ultraplan이 뭔가요?

Ultraplan은 Claude Code의 플래닝 작업을 Anthropic 클라우드(CCR, Cloud Container Runtime)로 떠넘겨서 처리하게 만드는 기능입니다. 30분짜리 깊은 플래닝 세션을 Opus 4.6 모델로 클라우드에서 돌리고, 그 결과를 웹 브라우저에서 리뷰한 다음, 최종 플랜을 다시 터미널로 "텔레포트"해서 실행하는 워크플로우입니다.

쉽게 말해서, 무거운 플래닝은 클라우드에서 돌리고, 내 노트북은 시원하게 다른 작업하면서 기다린다는 개념이죠. 기존 Plan 모드(Shift + Tab)와 비교하면 차이점이 명확합니다.

항목	로컬 Plan 모드	Ultraplan
실행 위치	내 노트북	Anthropic 클라우드 (CCR)
모델	현재 설정된 모델	Opus 4.6
리소스	내 컴퓨터 자원 사용	30분 클라우드 컴퓨팅
리뷰 인터페이스	터미널 (텍스트)	브라우저 (인라인 코멘트 가능)
동시 작업	플래닝 동안 터미널 점유	플래닝 동안 터미널 자유

가장 큰 장점은 터미널이 자유로워진다는 겁니다. Ultraplan이 클라우드에서 30분 동안 깊이 있는 플래닝을 하는 동안, 내 터미널에서는 다른 작업을 계속할 수 있죠. 심지어 Ultraplan 세션을 여러 개 동시에 띄울 수도 있습니다.

사용 방법

Ultraplan을 시작하는 방법은 세 가지입니다.

1. 슬래시 명령

/ultraplan tRPC v10 라우트들을 v11로 마이그레이션하면서 하위 호환성 유지해줘

2. 키워드
프롬프트 어딘가에 ultraplan이라는 단어를 넣으면 됩니다. ultrathink처럼요.

사용자 인증 시스템 전체 리팩토링 ultraplan

3. 로컬 Plan 모드에서 전환
먼저 로컬 Plan 모드(Shift + Tab)에서 빠르게 초안을 만들고, 결과가 만족스럽지 않으면 "Refine with Ultraplan" 옵션을 선택해서 클라우드로 넘길 수 있습니다. 저는 이 방식이 가장 많이 쓸 것 같아요. 로컬에서 빠르게 1차 초안 만들고, 더 깊이 파고들어야 할 때만 클라우드로 보내는 거죠.

세 가지 방법 모두 실행하면, 터미널에 클라우드 세션 링크가 표시됩니다. 그 링크를 열면 브라우저에서 플래닝 진행 상황을 모니터링할 수 있고, 사이드바에 Ultraplan 프로젝트가 추가되어 있는 걸 볼 수 있습니다.

이런 리뷰 인터페이스가 터미널 텍스트보다 훨씬 편합니다. 터미널에서는 "위에서 세 번째 단락 말이야"라고 풀어서 설명해야 했던 것들을 그냥 클릭해서 코멘트할 수 있으니까요.

전제 조건

Ultraplan을 쓰려면 두 가지가 필요합니다.

Claude Code on the Web 사용 가능 플랜
GitHub 저장소 연결

클라우드 세션이 GitHub 저장소의 스냅샷을 기반으로 동작하기 때문에, 로컬 전용 프로젝트나 커밋되지 않은 큰 변경사항이 있는 프로젝트에서는 정확한 플랜이 안 나올 수 있습니다. 중요한 작업은 항상 커밋하고 푸시한 다음에 Ultraplan을 실행하는 게 좋습니다.

브라우저에서 결과 확인하는 방법

Ultraplan을 시작하면 결과를 브라우저에서 확인해야 하는데, 접근 방법은 세 가지입니다.

1. 터미널에 표시되는 세션 URL 클릭
/ultraplan을 실행하면 터미널에 상태 인디케이터와 함께 세션 URL이 표시됩니다. 이 URL을 그냥 복사해서 브라우저에서 열면 됩니다.

> /ultraplan migrate the auth service from sessions to JWTs
Launching ultraplan session...
◇ ultraplan · Monitor progress in Claude Code on the web
  https://claude.ai/code/...

상태는 세 단계로 변합니다.

상태	의미
◇ ultraplan	Claude가 코드베이스 리서치/플래닝 중
◇ ultraplan needs your input	Claude가 질문이 있음 → 링크 열어야 함
◆ ultraplan ready	플랜 준비 완료 → 링크 열어서 리뷰

2. /tasks 명령으로 확인
세션 URL을 놓쳤거나 여러 Ultraplan을 동시에 돌리고 있다면 /tasks 명령으로 확인할 수 있습니다. 현재 진행 중인 항목을 선택하면 세션 링크와 에이전트 활동 상태를 볼 수 있어요.

3. claude.ai 사이드바에서 직접 접근
Ultraplan을 시작하면 claude.ai/code의 사이드바에 자동으로 Ultraplan 프로젝트가 추가됩니다. 브라우저에서 claude.ai에 로그인되어 있는 상태라면, 사이드바에서 해당 프로젝트를 클릭해서 바로 들어갈 수 있습니다.

Ultraplan은 백그라운드에서 도는 거라 터미널 인디케이터가 ◆ ultraplan ready로 바뀔 때까지 기다려야 합니다. 다른 작업을 하다가 알림으로 받고 싶다면, 2편에서 다뤘던 Hooks를 활용해 알림을 추가할 수도 있어요.

브라우저 리뷰 인터페이스

플래닝이 끝나면 브라우저에서 플랜을 검토할 수 있습니다. 가장 강력한 부분이 여기에요.

인라인 코멘트: 플랜의 특정 섹션에 직접 코멘트를 달 수 있습니다. "이 부분은 다르게 가야 할 것 같은데"라고 구체적인 위치에 표시할 수 있죠.
이모지 플래깅: 마음에 드는 부분과 안 드는 부분을 이모지로 빠르게 표시할 수 있습니다.
목차 사이드바: 마크다운 헤더 기반으로 자동 생성되는 목차로 긴 플랜도 빠르게 점프할 수 있습니다.

플랜 승인 후 실행 옵션

플랜을 승인하면 세 가지 실행 옵션이 나옵니다.

옵션	설명
Implement here	현재 진행 중인 대화에 플랜을 주입하고 이어서 작업
Start new session	현재 대화를 정리하고 플랜만 컨텍스트로 새 세션 시작
Cancel	플랜을 파일로만 저장하고 실행 안 함

또는 브라우저에서 "Approve plan and teleport back to terminal"을 선택하면, 클라우드 세션은 아카이브되고 플랜이 로컬 터미널로 전송됩니다. 이걸 "텔레포트"라고 부르더라고요.

로컬 Plan vs Ultraplan, 실제로 비교해 보면

저도 직접 비교해 봤습니다. 같은 프롬프트로 양쪽에서 동시에 플래닝을 돌려봤어요.

결과부터 말씀드리면 이렇습니다.

속도: Ultraplan이 압도적으로 빨랐습니다. 로컬에서는 아직 플래닝 중인데, Ultraplan은 1분 30초 만에 전체 아키텍처와 모든 이슈를 정리해 줬어요. 클라우드 환경의 컴퓨팅 자원이 훨씬 풍부하니까 당연한 결과겠지만, 체감 차이가 큽니다.
플랜의 깊이: Ultraplan이 더 섬세했습니다. 단순히 파일 목록만 나열하는 게 아니라, 의존성 체인을 매핑하고, 놓치기 쉬운 엣지 케이스를 미리 플래깅 하고, Mermaid 다이어그램으로 구현 순서까지 시각화해 주는 식이었어요.

사실 저도 여러 테스트를 하면서 느끼고 있지만 플래닝을 잘하면 결과물의 품질도 확실히 올라가네요. 사실 우리가 이미 알고 있는 에이전트 코딩의 기본 원리이기도 한데, Ultraplan이 그걸 다시 한번 증명할 수 있었습니다.

주의할 점

물론 Ultraplan에도 한계는 있습니다.

리서치 프리뷰 단계: 아직 정식 출시가 아니라서 버그가 있을 수 있고, 인터페이스나 기능이 변경될 수 있습니다.
스냅샷 기반: 클라우드 세션은 Ultraplan 시작 시점의 코드 스냅샷을 기반으로 동작합니다. 플래닝이 진행되는 동안 로컬에서 코드를 수정하면, 그 변경사항은 플랜에 반영되지 않습니다. 한 번은 플래닝 도중에 컬럼 이름을 바꿨다가, 이미 사라진 컬럼을 참조하는 플랜을 받은 적도 있습니다.
GitHub 의존성: 로컬 전용 레포지토리나 미커밋 변경이 많은 상태에서는 정확한 플래닝이 어렵습니다.
토큰 비용: 30분짜리 Opus 4.6 세션이라 토큰이 많이 탑니다. 가벼운 작업에는 오버킬이에요.

저는 한 줄로 설명할 수 있는 작업이나 이미 영향받는 파일을 알고 있는 작업에는 그냥 로컬 Plan 모드를 쓰고, 정말 복잡하고 불확실한 작업에만 Ultraplan을 씁니다.

/tasks - Ultraplan 세션 관리

Ultraplan을 여러 개 돌리다 보면 관리가 필요합니다. 그때 쓰는 게 /tasks 명령입니다.

/tasks

현재 진행 중인 모든 Ultraplan 세션을 모니터링할 수 있고, 필요하면 직접 중단시킬 수도 있습니다. 클라우드에서 백그라운드로 돌고 있기 때문에 이런 관리 인터페이스가 필요한 거죠.

/btw - 사이드 질문용 슬래시 명령

/btw는 작업 흐름을 끊지 않고 짧은 사이드 질문을 던질 때 쓰는 명령입니다. "By The Way"의 약자죠.

예를 들어 한참 어떤 기능을 구현하고 있는데 갑자기 "참고로 이 라이브러리 버전은 뭘 쓰는 게 좋아?" 같은 질문이 떠올랐을 때, 메인 컨텍스트를 오염시키지 않고 가볍게 물어볼 수 있습니다.

/buddy - 터미널 속 다마고치

자, 이건 좀 다른 종류의 기능입니다. 실용적이지는 않지만 재밌어요. 터미널 안에서 함께 사는 AI 펫입니다.

/buddy

명령을 입력하면 랜덤 한 캐릭터가 하나 생성됩니다. 저는 Ghost 종류의 Zephyr라는 친구가 나왔습니다.

╭──────────────────────────────────────╮
│                                      │
│  ★ COMMON                     GHOST  │
│                                      │
│                                      │
│     .----.                           │
│    / ×  × \                          │
│    |      |                          │
│    ~`~``~`~                          │
│                                      │
│  Zephyr                              │
│                                      │
│  "A well-meaning ghost who floats    │
│  through your code like a tornado,   │
│  pointing out bugs with chaotic      │
│  enthusiasm but genuinely trying to  │
│   help despite leaving a trail of    │
│  confusion in their wake."           │
│                                      │
│  DEBUGGING  ██░░░░░░░░  23           │
│  PATIENCE   ████░░░░░░  41           │
│  CHAOS      ████████░░  84           │
│  WISDOM     ██░░░░░░░░  15           │
│  SNARK      ░░░░░░░░░░   1           │
│                                      │
╰──────────────────────────────────────╯

각 Buddy는 종류와 희귀도(Common부터 Shiny까지)가 있고, 고유한 성격 설명과 5가지 스탯(Debugging, Patience, Chaos, Wisdom, Snark)을 가지고 있습니다. 제 Zephyr는 Chaos가 84로 좀 정신없는 친구네요.

Buddy의 특징

사용량에 카운트되지 않음: Buddy의 발언은 토큰 사용량에 포함되지 않습니다. 부담 없이 켜두면 됩니다.
자동 참여: 코딩하는 동안 알아서 한 마디씩 거듭니다. 코드를 평가하기도 하고, 버그를 지적하기도 합니다.
이름을 부르면 응답: 대화 중에 이름을 언급하면 그 친구가 직접 의견을 내놓습니다.

추가: 2026년 3월 소스 유출 사건과 미공개 기능들

자, 여기서부터는 좀 다른 이야기입니다. 2026년 3월 31일에 있었던 사건인데, Claude Code의 전체 소스 코드가 유출됐던 사건이에요.

무슨 일이 있었나?

2026년 3월 31일, npm 패키지 @anthropic-ai/claude-code v2.1.88에 실수로 59.8MB짜리 source map 파일(cli.js.map)이 포함되어 배포됐습니다. 이 파일에는 1,884개의 TypeScript 소스 파일이 들어 있었고, Claude Code의 전체 코드베이스가 그대로 노출됐죠.

Bun 번들러가 기본적으로 source map을 포함하는데, 이걸 npm 배포에서 제외하지 않은 인적 실수였다고 합니다. 보안 연구자 Chaofan Shou가 발견해서 X에 올렸고, Anthropic은 몇 시간 내에 파일을 제거했습니다.

이 유출에서 드러난 미공개 기능들이 정말 흥미로웠어요. 그중 일부는 이후 정식 출시됐고(앞서 다룬 Ultraplan, /buddy가 그 예입니다), 일부는 아직 미공개 상태입니다.

유출된 미공개 기능들

1. KAIROS - 백그라운드 메모리 통합
세션을 넘나드는 영구 어시스턴트입니다. 매일 append-only 로그를 유지하고, "dream cycle"이라는 4단계(Orient, Gather, Consolidate, Prune) 메모리 통합을 수행합니다. SendUserFile, PushNotification 같은 전용 도구도 가지고 있어요. 한 마디로 Claude가 우리가 쉬는 동안 백그라운드에서 자기 기억을 정리하는 거죠.

2. Coordinator Mode - 멀티 에이전트 오케스트레이션
여러 에이전트에게 작업을 분산하고 조율하는 모드입니다. 보리스 체르니가 5개의 Claude를 동시에 돌리는 방식의 진화 버전이라고 볼 수 있어요.

3. Daemon Mode - 백그라운드 지속 실행
Claude Code가 백그라운드 데몬처럼 계속 실행되면서 작업을 처리하는 모드입니다.

4. 26개의 미공개 슬래시 명령

명령	설명
/ctx-viz	컨텍스트 윈도우 시각화
/dream	수동 메모리 통합
/subscribe-pr	PR 구독
/autofix-pr	PR 자동 수정
/bughunter	버그 헌팅 모드

이미 출시된 /btw, /ultraplan, /buddy 같은 명령들도 원래는 이 유출에서 처음 발견된 것들이었습니다.

유출 사건이 보여준 것

이 유출이 흥미로운 건, Claude Code가 단순한 터미널 도구에서 자율적이고 분산된 AI 시스템으로 진화하고 있다는 걸 보여줬다는 점입니다.

Ultraplan: 클라우드에서 계획
Coordinator Mode: 작업 분산 (미공개)
Daemon Mode: 백그라운드 지속 실행 (미공개)
KAIROS: 세션을 넘나드는 메모리 (미공개)

이 네 가지가 합쳐지면, Claude Code는 우리가 자는 동안에도 백그라운드에서 계획을 세우고, 작업을 분산하고, 실행하고, 결과를 기억하는 진정한 자율 에이전트가 되는 거죠. 그리고 그중 하나(Ultraplan)는 이미 출시됐습니다. 나머지도 곧 나올 가능성이 높습니다.

마무리

이번 글에서 다룬 내용을 정리하면

ultrathink: 한 턴에 최대 thinking budget 활성화 (재도입)
/effort: ultrathink의 영구 버전 (low/medium/high/auto)
Ultraplan: 클라우드에서 30분짜리 깊은 플래닝 세션 실행, 브라우저에서 리뷰 후 터미널로 텔레포트
/tasks: Ultraplan 세션 관리
/btw: 사이드 질문용 슬래시 명령
/buddy: 터미널 속 AI 펫 (재미 요소)
유출 사건: KAIROS, Coordinator Mode, Daemon Mode 등 미공개 기능들

특히 Ultraplan은 한 번쯤 꼭 써보시는 걸 추천합니다. 단순히 "더 좋은 플래닝 도구"를 넘어서, AI 코딩 에이전트의 작업 방식 자체가 어떻게 바뀌고 있는지를 잘 보여주는 기능이에요. 무거운 작업은 클라우드에서 돌리고, 내 터미널은 자유롭게 유지하는 패턴이 앞으로 표준이 될 것 같습니다.

다음 글에서는 Skills와 Plugins — Claude Code의 새로운 패키징 시스템을 다룰 예정입니다. 1, 2편에서 다뤘던 커스텀 명령어, 서브에이전트, Hooks, MCP 같은 것들이 어떻게 하나의 패키지로 묶이고 공유되는지 살펴보겠습니다.

참고

Harness Engineering: AI 에이전트를 제대로 부리는 법

Theo (테오) — Sun, 5 Apr 2026 23:28:26 +0900

요즘 AI 개발 커뮤니티에서 Harness Engineering이라는 단어가 계속 나옵니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링 다음으로 나온 이 개념, 처음 들으면 뭔가 대단한 것처럼 느껴지지만 사실 핵심은 의외로 단순합니다. 그리고 이미 AI 코딩 에이전트를 쓰고 있는 분들이라면 어느 정도는 이미 하고 있는 것이기도 합니다.

이 글에서는 Harness Engineering이 뭔지, 왜 필요한지, 구체적으로 뭘 해야 하는지를 정리해 봤습니다.

Harness가 뭔데?

Harness는 영어로 "마구(馬具)"입니다. 말을 다룰 때 쓰는 고삐, 안장, 가죽끈 같은 장비를 말하죠.

AI 에이전트를 야생말이라고 한번 생각해 보세요. Claude, GPT, Gemini 같은 모델은 엄청나게 강력합니다. 하지만 그냥 풀어놓으면 어디로 달려갈지 모릅니다. 숲으로 달려가고, 작물을 밟아 버리고, 울타리를 부수고 도망칠 수 있죠. 힘이 강할수록 통제 없이는 더 위험합니다.

마구를 채운다고 말이 느려지나요? 아닙니다. 오히려 그 힘을 올바른 방향으로 집중시켜서 우리가 원하는 방향으로 빠르고 정확하게 일하게 만드는 겁니다. Harness Engineering은 바로 이 마구를 만드는 기술입니다.

정의를 한 줄로 하면 이렇습니다.

AI 에이전트가 자율적으로 일하되, 동시에 안전하게 통제할 수 있는 환경을 만드는 것

이 개념은 2026년 2월에 HashiCorp 창업자인 Mitchell Hashimoto가 처음 이름을 붙였습니다. AI 코딩 에이전트를 쓰다가 같은 실수를 계속 반복하는 걸 경험하고, 프롬프트에 "이렇게 하지 마"라고 써놔도 다음에 또 같은 실수를 하는 문제를 해결하기 위해 체계화한 개념이죠. 이름이 붙자마자 OpenAI, Anthropic, LangChain 등 업계 전체가 동조하면서 빠르게 퍼졌습니다.

왜 기존 방법으로는 부족한가?

Harness를 이해하려면, 왜 기존의 프롬프트 엔지니어링과 컨텍스트 엔지니어링만으로는 부족한지를 먼저 알아야 합니다.

프롬프트 엔지니어링의 한계

프롬프트 엔지니어링은 AI에게 말을 잘 거는 기술입니다. "계산기 만들어 줘" 대신 "공학용 계산기를 만들어 줘. 사인, 코사인을 지원하고 GUI로 만들어야 해"라고 구체적으로 요청하면 결과가 확 달라지죠.

하지만 프롬프트에는 천장이 있습니다. AI에게 "로그인 기능을 추가해 줘"라고 아무리 정교하게 써도, 우리 프로젝트의 기술 스택, 코드 구조, DB 스키마를 모르면 좋은 코드가 나올 수 없으니까요.

컨텍스트 엔지니어링의 한계

그래서 나온 게 컨텍스트 엔지니어링입니다. 프롬프트만 주는 게 아니라, 프로젝트 구조, 기존 코드, API 문서, 디자인 규칙까지 같이 제공하는 거죠. Anthropic의 정의로는 "AI가 일할 때 필요한 정보를 적절한 타이밍에 제공하는 기술"입니다.

그런데 컨텍스트를 아무리 잘 설계해도 해결 안 되는 문제가 있습니다. AI가 정보는 다 알고 있는데 그걸 가지고 엉뚱한 짓을 하는 경우입니다. 결제 시스템을 맡겼더니 갑자기 DB 스키마를 마음대로 바꾸거나, 신용카드 번호를 로그에 찍어 버리는 식이죠. 이건 정보의 문제가 아니라 규칙과 울타리의 문제입니다.

Harness Engineering의 핵심 철학

Harness Engineering에서 가장 중요한 문장은 이겁니다.

에이전트가 규칙을 어겼을 때, "더 잘해 봐"라고 프롬프트를 고치는 게 아니라,
그 실패가 구조적으로 반복 불가능하도록 Harness를 고치는 것

예를 들어 보겠습니다. AI 에이전트가 프론트엔드 코드에서 데이터베이스를 직접 호출했다고 하겠습니다. 일반적인 반응은 프롬프트에 "DB를 직접 호출하지 마"라는 문장을 추가하는 겁니다. 그런데 이러면 다음번에 또 실수합니다. 왜냐하면 프롬프트는 부탁이지 강제가 아니거든요.

Harness Engineering은 다르게 접근합니다. 아키텍처 테스트를 추가해서, 프론트엔드 폴더에서 DB를 임포트 하려는 순간 빌드가 실패하도록 만들어 버리는 거죠. 이렇게 하면 AI가 아무리 시도해도 그 실수는 구조적으로 불가능해집니다.

비유하자면 공장의 안전 시스템과 같습니다. 안전모를 안 쓰면 출입문 자체가 안 열리고, 기계에 손이 들어가려 하면 자동으로 멈추는 것처럼, 규칙이 사람의 판단에 의존하는 게 아니라 시스템에 내장되어 자동으로 강제되는 겁니다.

Prompt → Context → Harness, 흐름 정리

AI를 활용하는 방법은 계속 발전해 왔습니다. 이 흐름을 한번 정리해 보겠습니다.

단계	핵심	비유
Prompt Engineering	AI에게 말을 잘 거는 기술	말에게 명령하기
Context Engineering	AI에게 필요한 정보를 제공하는 기술	말에게 지도를 보여주기
Harness Engineering	AI가 실수할 수 없는 환경을 만드는 기술	말에게 마구를 채우기
Agentic Engineering	AI 에이전트의 추론과 워크플로우를 설계하는 기술	말 자체를 훈련시키기

이 네 가지는 순서대로 졸업하는 게 아닙니다. 전부 다 필요한 상호보완적인 축입니다. 말을 아무리 잘 훈련시켜도(Agentic) 마구 없이는(Harness) 밭을 갈 수 없고, 아무리 정교한 마구라도 말이 없으면 수레는 움직이지 않죠.

Harness의 네 가지 기둥

Harness Engineering은 크게 네 가지 요소로 구성됩니다.

1. 기계가 읽는 컨텍스트 파일

CLAUDE.md, agents.md, .cursorrules 같은 파일들입니다. 이것들은 단순한 문서가 아니라 AI가 실행하는 런타임 설정 파일입니다. 사람이 읽는 위키나 노션 문서와는 본질적으로 다릅니다.

AI 에이전트는 작업을 시작할 때 이 파일을 가장 먼저 읽습니다. 새 세션이 시작돼서 이전 내용을 잊어버려도, 이 파일은 항상 다시 읽히죠. 퇴사자가 아무리 바뀌어도 신규 입사자가 첫날 반드시 읽어야 하는 온보딩 문서가 있듯이, CLAUDE.md가 그 역할을 하는 겁니다.

예를 들어 이런 규칙을 넣습니다.

새로운 라이브러리를 도입하지 마
기존 API 패턴을 무조건 따라야 해
DB는 반드시 ORM을 통해서만 접근해

한번 설정하면 모든 작업에 자동으로 적용되기 때문에 매번 프롬프트에 반복할 필요가 없어집니다.

여기서 중요한 원칙이 하나 있습니다. OpenAI팀이 처음에 거대한 agents.md 파일을 만들었다가 실패한 경험을 공유했는데, 1,000페이지 설명서가 아니라 지도를 줘야 한다는 겁니다. 보편적으로 항상 적용되는 핵심 내용만 넣고, 세부 내용은 별도 파일로 나눠서 필요할 때만 참조하게 하는 거죠.

그리고 Hashimoto가 만든 Ghostty의 agents.md를 보면, 처음부터 완벽하게 설계한 게 아닙니다. 에이전트가 실수할 때마다 한 줄씩 추가되면서 점진적으로 개선된 파일입니다.

2. 결정론적 CI/CD 게이트

규칙을 파일에 써 놓는 것만으로는 충분하지 않습니다. AI는 규칙을 읽고도 어길 수 있거든요. 그래서 시스템이 자동으로 강제하는 장치가 필요합니다.

린터(Linter): 코드의 맞춤법 검사기라고 생각하면 됩니다. 코드가 정해진 규칙을 어기면 자동으로 에러를 띄워줍니다.
구조적 테스트: "이 폴더의 코드는 저 폴더의 코드를 임포트 할 수 없다" 같은 의존성 규칙을 테스트로 강제하는 겁니다.
프리커밋 훅(Pre-commit Hook): 코드를 저장하기 전에 자동으로 검사를 돌립니다. 저장 버튼을 누르는 순간 "잠깐, 이거부터 확인하고 저장해"라고 하는 거죠.

여기서 Harness의 진짜 힘이 나옵니다. 자동 교정 루프입니다. 린터가 빨간 불을 켜면, 에이전트가 스스로 코드를 수정하기 시작합니다. 사람이 개입하지 않아도 됩니다. 말이 고삐에 의해 방향이 틀어지면 자연스럽게 올바른 방향으로 돌아오는 것과 같습니다.

Claude Code의 Hook 기능이 대표적인 예입니다. Claude가 코드를 저장하려는 순간 Hook이 자동으로 타입 검사와 문법 체크를 합니다. 에러가 있으면 Claude한테 다시 돌려보내고, Claude가 스스로 고칩니다. "잘 짜줘"라고 부탁하는 게 아니라, 못 짜면 저장 자체가 안 되는 구조를 만든 겁니다.

그리고 중요한 원칙이 하나 더 있습니다. "성공은 조용히, 실패만 시끄럽게"입니다. 테스트가 다 통과하면 아무 말도 하지 않습니다. 실패했을 때만 에이전트에게 알려주는 거죠. 통과한 테스트 결과 4,000줄을 다 보여주면 AI가 그걸 읽느라 정작 할 일을 잃어버리거든요.

3. 명시적 도구 경계 (최소 권한 원칙)

AI 에이전트가 어떤 도구를 쓸 수 있고, 어디까지 접근할 수 있는지를 명확하게 제한하는 겁니다.

영역	허용	차단
파일 시스템	src/ 폴더 읽기/쓰기	config/ 폴더는 읽기만 가능
API	내부 API 호출 가능	외부 서비스 호출 불가
데이터베이스	SELECT 가능	DROP TABLE 절대 불가
터미널	화이트리스트 명령만 가능	임의 명령 실행 불가

프롬프트로 "절대 DB를 삭제하지 마"라고 쓰는 것과 도구 경계를 설정하는 것의 차이가 뭔지 아시겠죠? 프롬프트는 부탁이고, 도구 경계는 물리적 차단입니다. 부탁은 어길 수 있지만, 물리적 제약은 어길 수 없습니다.

4. 지속적 피드백 루프 (가비지 컬렉션)

Martin Fowler는 이걸 가비지 컬렉션이라고 불렀습니다. 직역하면 쓰레기 청소죠.

이게 왜 필요할까요? AI 에이전트는 기존 코드를 참고해서 새 코드를 짭니다. 기존 코드에 나쁜 패턴이 있으면 그대로 따라 합니다. "아, 여기선 이렇게 하나 보다" 하고 복제하는 거죠. 이러면 나쁜 패턴이 눈덩이처럼 불어납니다.

그래서 주기적으로 돌아가는 청소 시스템이 필요합니다. 코딩 규칙 위반을 자동으로 감지하고, 중복 코드를 발견하고, 사용하지 않는 코드를 제거하고, 아키텍처 위반을 체크하는 거죠.

그리고 여기서 Harness가 진화합니다. 에이전트가 실수할 때마다 그 실수는 새로운 규칙이 됩니다. 린터 규칙이 추가되고, 테스트가 추가되고, 제약이 추가됩니다. 시간이 지날수록 시스템이 점점 더 견고해지는 거죠. 말이 한 번 넘으려 했던 울타리가 점점 더 높아져서, 두 번 다시 같은 실수를 할 수 없게 되는 겁니다.

실제로 이렇게 하는 팀이 있다

OpenAI: 코드 한 줄 안 쓰고 제품 배포

2026년 2월, OpenAI는 엔지니어 세 명이 AI 에이전트만으로 대규모 소프트웨어 제품을 만든 사례를 공식 블로그에 발표했습니다. 직접 코드를 한 줄도 쓰지 않았다고 합니다.

이게 가능했던 이유는 AI 모델이 강해서가 아니라, Harness가 잘 설계되어 있었기 때문입니다. 이 세 명이 실제로 한 일을 분석해 보면 위에서 설명한 네 가지 기둥 그대로입니다. agents.md로 지침서를 설계하고, CI/CD 게이트로 자동 검증 파이프라인을 구축하고, 도구 경계로 접근 범위를 제한하고, 피드백 루프로 지속적으로 개선하는 구조를 만든 거죠.

결국 이 사람들이 코드를 쓴 게 아니라 시스템을 만든 겁니다. 여기서 나온 유명한 말이 "인간은 조종한다, 에이전트는 실행한다"입니다. 이 조종이 바로 Harness입니다.

LangChain: 모델은 그대로, Harness만 바꿔서 25단계 상승

LangChain은 코딩 에이전트 벤치마크에서 모델을 바꾸지 않고 Harness만 개선했더니 30위권에서 5위권으로 25단계나 올라갔습니다. 모델은 그대로였고 Harness만 바뀌었습니다. AI 에이전트의 성능을 좌우하는 것은 모델의 지능이 아니라 Harness라는 걸 보여준 사례죠.

Anthropic: 장기 실행 에이전트의 실패 패턴 발견

Anthropic 연구팀은 Claude Code SDK를 사용해서 claude.ai 클론을 만드는 실험을 했습니다. 여기서 두 가지 반복되는 실패 패턴을 발견했죠.

첫 번째는 에이전트가 모든 걸 한 번에 해결하려고 달려들다가 컨텍스트가 바닥나서 절반만 구현되는 문제였습니다. 다음 세션이 시작됐을 때 어디까지 했는지 기억이 없으니까 처음부터 다시 파악하느라 시간을 허비하는 거죠.

두 번째는 에이전트가 조기 종료를 선언해 버리는 문제였습니다. 아직 한참 남았는데 "다 됐네" 하고 끝내 버리는 겁니다. 이거 AI 코딩 에이전트 써보신 분들은 공감하실 겁니다.

Anthropic의 해결 방법은 환경을 읽기 쉽게(legible) 만드는 것이었습니다. 프로젝트를 200개 이상의 Feature로 분해해서 JSON 파일에 기록하고, 각 Feature에 pass/fail 상태를 달아서, 에이전트가 새 세션을 시작할 때마다 전체 진행 상황을 빠르게 파악할 수 있게 한 거죠. 그리고 Puppeteer MCP나 Chrome DevTools 같은 도구를 연결해서 에이전트가 직접 End-to-End 테스트를 할 수 있게 했더니, 코드만 봐서는 발견하지 못했던 버그까지 잡아내기 시작했습니다.

사실 이미 쓰고 있었다

여기까지 읽으면서 "그거 내가 이미 하고 있는 건데?" 싶은 분들도 있을 겁니다. 맞습니다.

사실 우리가 Claude나 ChatGPT와 대화할 때, 이전 메시지를 기억하면서 이야기하는 것처럼 느껴지는 것도 Harness 덕분입니다. AI 모델은 기본적으로 텍스트를 넣으면 텍스트를 뱉는 함수일 뿐이에요. 혼자서는 이전 대화를 기억하지도 못하고, 파일을 읽지도 못하고, 인터넷에 접속하지도 못합니다. 대화 내용을 계속 모아서 매번 모델에게 새로 전달해 주는 루프 자체가 이미 Harness인 겁니다.

CLAUDE.md 파일을 만들어서 프로젝트 규칙을 정리해 본 적이 있다면, 프리커밋 훅으로 자동 검사를 돌려본 적이 있다면, 이미 Harness Engineering을 하고 있었던 겁니다. 이름만 새로 붙었을 뿐이죠.

지금 당장 해볼 수 있는 것

너무 거창하게 생각할 필요 없습니다. 시작은 딱 두 가지면 충분합니다.

첫 번째, CLAUDE.md 또는 agents.md 작성: 프로젝트의 기술 스택, 코드 규칙, 절대 하면 안 되는 것들을 정리합니다. 처음부터 완벽하게 쓸 필요 없습니다. 에이전트가 실수할 때마다 한 줄씩 추가하면 됩니다.

두 번째, 프리커밋 훅 설정: 코드를 저장하기 전에 린터와 테스트가 자동으로 돌아가게 합니다. 에이전트가 규칙을 어기면 저장 자체가 안 되는 구조를 만드는 거죠.

그리고 기억해야 할 마인드셋이 있습니다. 한 번에 완벽하게 하려고 하지 말 것. 에이전트가 실제로 실패한 경우에만 그 케이스를 모아서 Harness를 조금씩 개선하면 됩니다. 아이디어가 아직 모호하거나 검증되지 않았다면 Harness를 구축하는 것보다 결과물을 빠르게 만들어내는 게 먼저입니다.

그리고 하나 더, Garbage In, Garbage Out입니다. 문제 정의나 기획 자체가 별로면 아무리 Harness를 거쳐도 좋은 결과물이 나오지 않습니다. Harness는 좋은 걸 더 잘 만들게 도와주는 것이지, 별로인 걸 좋게 만들어 주는 마법이 아닙니다.

앞으로 Harness는 어떻게 될까?

강화학습의 창시자 Richard Sutton은 "모델이 똑똑해질수록 Harness는 더 단순해져야 한다"라고 이야기했습니다. 모델이 업그레이드될 때마다 하드코딩된 규칙을 계속 추가하고 있다면, 흐름을 거슬러 가고 있는 겁니다. 에이전트가 스스로 판단할 수 있는 걸 우리가 억지로 제약하는 거니까요.

Vercel도 비슷한 경험을 공유했습니다. 정교한 전용 도구를 여러 개 만들어서 에이전트에 달아줬더니 오히려 성능이 떨어지고, 도구를 단 하나의 범용 Bash 명령으로 줄였더니 3.5배 빨라지고 성공률이 80%에서 100%로 올라갔다는 겁니다. 모델은 자기가 이미 잘 아는 범용 도구를 쓸 때 훨씬 잘 동작한다는 거죠.

언젠가는 에이전트가 스스로 Harness Engineering을 하는 시대가 올 겁니다. "내가 일을 잘하기 위한 환경 구성부터 먼저 살펴보고, 설정한 다음에 작업을 시작할게"라는 식으로요. 지금은 그렇게 하지 않기 때문에 Harness Engineering이 중요한 거지, 앞으로는 방향이 바뀔 수 있습니다.

마무리

Harness Engineering을 한 문장으로 요약하면 이렇습니다.

AI 에이전트가 실수했을 때, 프롬프트를 고치지 마세요
Harness를 고치세요

프롬프트는 부탁이고, Harness는 강제입니다. "넘지 마"라고 소리치는 대신 울타리를 더 높이 세우는 것. 그 실패가 구조적으로 반복 불가능하도록 시스템을 바꾸는 것. 이게 Harness Engineering의 핵심입니다.

개발자의 역할이 바뀌고 있습니다. 코드를 직접 작성하는 것에서, AI가 코드를 올바르게 작성할 수 있는 환경을 설계하는 것으로요. 코딩 능력이 필요 없어지는 게 아니라, 더 높은 차원의 능력이 요구되는 겁니다. 공을 직접 차는 선수에서 전술을 짜고 팀을 운영하는 감독으로 한 단계 올라가는 거죠.

NVIDIA Isaac Lab on AWS: Physical AI 로봇 강화학습 워크샵 따라해보기

Theo (테오) — Fri, 3 Apr 2026 00:13:55 +0900

요즘 Physical AI라는 키워드가 자주 보입니다. CES 2025에서 NVIDIA 젠슨 황이 "AI의 다음 단계는 Physical AI"라고 강조한 이후로, 로봇이 시뮬레이션에서 스스로 걷고 물건을 잡는 영상들이 쏟아지고 있죠. 영상을 볼 때마다 "저건 대체 어떻게 학습시킨 거지?"라는 궁금증이 있었는데, 그래서 NVIDIA Isaac Lab on AWS 워크샵을 직접 따라 해봤습니다.

이 글은 워크샵을 따라 하면서 정리한 내용입니다. Physical AI가 뭔지, 로봇이 어떻게 스스로 걷는 법을 배우는지, 그리고 이걸 AWS 클라우드에서 어떻게 돌리는지를 초보자 관점에서 정리해 봤습니다.

Physical AI, 왜 관심을 가지게 됐나?

저는 주로 Detection, Classification, OCR, LLM 같은 영역에서 AI를 다뤄왔습니다. 그러다 보니 Physical AI, 즉 로봇이 물리적 세계에서 동작하는 AI는 좀 먼 이야기처럼 느껴졌습니다. 하지만 최근 Boston Dynamics의 Atlas, Tesla의 Optimus, Figure의 휴머노이드 로봇 등이 눈에 띄게 발전하면서, 이 분야가 빠르게 실용화 단계로 가고 있다는 걸 체감했습니다.

출처: Nvidia

특히 인상적이었던 건 이 로봇들이 사람이 일일이 프로그래밍한 게 아니라, 시뮬레이션에서 강화학습으로 스스로 학습한다는 점이었습니다. 수천 번 넘어지면서 걷는 법을 배우고, 그 결과를 실제 로봇에 전이(Sim-to-Real)하는 방식이죠. 이게 어떻게 동작하는지 직접 경험해보고 싶었습니다.

로봇 학습이란?

워크샵 내용에 들어가기 전에, 로봇 학습의 기본 개념을 간단히 정리하겠습니다.

전통적으로 로봇은 수학적 모델링으로 제어했습니다. "이 각도에서 이 힘을 가하면 이렇게 움직인다"는 식의 물리 공식을 직접 계산해서 프로그래밍하는 방식이죠. 예를 들어 로봇 팔이 왼쪽에서 오른쪽으로 물건을 옮긴다고 하면, 사람은 직선으로 쭉 이동시키는 걸 상상합니다. 하지만 실제 로봇 팔은 각 관절이 회전 운동을 하기 때문에 호를 그리면서 이동합니다. 저도 이걸 몰랐다가 실제 로봇 팔이 작동하는 걸 보고 알게 됐는데, 직선으로 움직이게 하려면 각 관절의 각도를 동시에 정밀하게 계산(역기구학, Inverse Kinematics) 해야 합니다. 이런 계산을 사람이 직접 하는 거죠. 문제는 환경이 조금만 바뀌어도 다시 계산해야 하고, 복잡한 동작일수록 수학적으로 모델링하기가 극도로 어렵다는 겁니다.

로봇 학습은 이 한계를 넘기 위한 접근입니다. 로봇이 데이터와 환경 상호작용을 통해 스스로 동작을 배우는 것이죠. 크게 네 가지 방식이 있습니다.

학습 방식	핵심 개념	예시
지도학습 (Supervised)	라벨링된 데이터로 학습	물체 인식, 포즈 추정
비지도학습 (Unsupervised)	라벨 없이 패턴 발견	환경 맵핑, 이상 탐지
모방학습 (Imitation)	전문가 시연을 따라 학습	텔레오퍼레이션 데이터로 조립 학습
강화학습 (Reinforcement)	시행착오로 보상을 최대화	보행, 물체 파지

이 중에서 로봇의 행동 자체를 학습시킬 때 주로 사용되는 건 모방학습과 강화학습입니다. 이번 워크샵에서 다루는 건 강화학습입니다.

강화학습, 간단히 말하면

강화학습은 사람이 자전거를 배우는 과정과 비슷합니다. 넘어지면 "이건 아니다"(패널티), 균형을 잡으면 "이게 맞다"(보상)라는 피드백을 받으면서 점점 나아지는 거죠.

로봇 강화학습의 루프는 이렇습니다.

로봇(에이전트)이 환경을 관측(Observation)합니다 — 자기 몸의 위치, 관절 각도, 지형 정보 등
정책(Policy) 네트워크가 관측값을 받아 행동(Action)을 출력합니다 — 각 관절을 어떻게 움직일지
환경에서 행동을 수행하고 보상(Reward)을 받습니다 — 앞으로 전진하면 +, 넘어지면 -
이 과정을 수만~수십만 번 반복하면서 정책을 업데이트합니다

여기서 핵심은 보상 함수(Reward Function) 설계입니다. "어떤 상태가 좋고 나쁜지"를 정의하는 건 사람이 해야 합니다. 예를 들어 휴머노이드 보행 학습이라면, 전진 속도에 비례한 보상, 에너지 소비에 대한 패널티, 넘어지면 에피소드 종료 같은 식으로 설계하는 거죠.

이번 워크샵에서 사용된 알고리즘은 PPO(Proximal Policy Optimization)입니다. Isaac Lab에서 가장 널리 쓰이는 강화학습 알고리즘이고, 학습이 안정적이라는 장점이 있습니다.

NVIDIA Isaac Lab이란?

Isaac Lab은 NVIDIA의 로봇 학습 프레임워크입니다. 쉽게 말해 로봇에게 행동을 가르치기 위한 도구입니다.

NVIDIA는 로봇 시뮬레이션 분야에서 여러 도구를 발전시켜 왔습니다. Isaac Gym → OIGE → Orbit 등을 거쳐 현재 Isaac Lab으로 통합된 형태입니다. Isaac Lab은 Isaac Sim(물리 시뮬레이션 엔진) 위에서 동작하며, 역할 분담은 이렇습니다.

도구	역할
Isaac Sim	물리 시뮬레이션 + 렌더링 (물리 세계를 만드는 엔진)
Isaac Lab	학습 파이프라인 관리 (상태 → 관측 → 정책 → 행동 루프)

데이터 흐름을 좀 더 구체적으로 보면 이렇습니다.

Isaac Sim이 물리 시뮬레이션으로 로봇의 상태(State)를 생성합니다 — 관절 위치, 속도 등의 순수 데이터
Isaac Lab이 상태를 받아 노이즈를 추가합니다 — 실제 센서처럼 약간의 오차를 넣어 Sim-to-Real 전이 성능을 높입니다
노이즈가 추가된 관측(Observation)이 정책 네트워크로 전달됩니다
정책이 행동(Action)을 출력합니다
행동이 다시 Isaac Sim에 전달되어 물리 시뮬레이션이 실행됩니다
이 사이클이 반복되면서 정책이 점점 개선됩니다

최종 산출물은 .pt 또는 .onnx 형태의 학습된 정책 파일입니다. 이 파일이 바로 "로봇의 뇌"라고 볼 수 있습니다.

Isaac Lab에는 Cartpole 같은 단순 환경부터 Unitree H1 휴머노이드, Boston Dynamics Spot, Franka 로봇 팔까지 다양한 로봇과 26개 이상의 사전 구축 환경이 포함되어 있습니다. Berkeley, Fourier, ETH 등 여러 연구팀이 실제로 Isaac Lab을 사용해서 Sim-to-Real 전이까지 진행하고 있습니다.

직접 해본 것: Unitree H1 휴머노이드 보행 학습

제가 해본 건 Unitree H1 휴머노이드 로봇이 울퉁불퉁한 지형에서 걷는 법을 강화학습으로 학습시키는 것입니다. 그리고 이 과정을 AWS 클라우드 GPU 환경에서 실행했습니다.

전체 흐름은 크게 세 가지입니다. GPU 1개로 학습을 돌려보고, 여러 GPU로 분산 학습을 해보고, 학습이 끝난 모델로 실제 걷는 모습을 확인하는 것이죠.

GPU 1개로 학습 시작해 보기

먼저 EC2 인스턴스(g6.4xlarge, L40S GPU 1개)에 Amazon DCV로 원격 접속합니다. DCV는 GPU 가속 원격 데스크톱인데, Isaac Sim 같은 그래픽 중심의 애플리케이션을 원격에서 실행할 수 있게 해 줍니다. 접속하면 Ubuntu 데스크톱 환경이 나타나고, 터미널에서 Isaac Lab Docker 컨테이너를 실행해 학습을 시작합니다.

Ubuntu 데스크톱 접속 화면

# Docker 컨테이너 실행
cd environment/IsaacLab
xhost +
docker run --shm-size=60g --name isaac-lab --entrypoint bash -it --gpus all \
  -e "ACCEPT_EULA=Y" --rm --network=host \
  -e DISPLAY -e "PRIVACY_CONSENT=Y" \
  isaaclab-batch:latest

# 컨테이너 안에서 학습 시작
/isaac-sim/python.sh -m torch.distributed.run --nnodes=1 --nproc_per_node=1 \
  scripts/reinforcement_learning/skrl/train.py \
  --task=Isaac-Velocity-Rough-H1-v0

Isaac-Velocity-Rough-H1-v0이 학습 태스크 이름입니다. Unitree H1 휴머노이드가 거친 지형(Rough Terrain)에서 목표 속도로 걷는 법을 학습하는 환경이죠.

약 5분 정도 기다리면 Isaac Sim GUI가 뜨면서 시뮬레이션 화면이 나타납니다. 처음에는 로봇이 바로 넘어지는 게 보입니다. 아직 아무것도 배우지 못한 상태니까요. (여러 로봇이 계속 넘어지니까 좀비 같아 보이기도 하네요.)

학습 중에 TensorBoard를 띄워서 메트릭을 확인할 수 있는데, 주요 지표는 두 가지입니다.

mean_episode_length: 에피소드 평균 길이. 로봇이 넘어지지 않고 버티는 시간이라고 보면 됩니다. 학습이 잘 되면 이 값이 점점 늘어납니다.
mean_reward: 평균 보상. 학습이 진행될수록 높아져야 합니다.

이 태스크의 전체 학습은 72,000 에포크, 약 3시간이 소요됩니다. GPU 1개로도 돌아가긴 하지만, 복잡한 로봇 학습은 이것보다 훨씬 오래 걸리기 때문에 GPU를 더 쓸 필요가 있습니다.

AWS Batch로 GPU 8개 분산 학습

여기서 AWS Batch를 사용해 2노드 × 4 GPU(총 8 GPU)로 분산 학습을 실행해 봤습니다. Isaac Lab Docker 이미지를 ECR에 올리고, Batch에서 Compute Environment → Job Definition → Job Queue를 설정한 뒤 작업을 제출하면 됩니다.

Job Definition에서 핵심 환경 변수는 이렇습니다.

환경 변수	값	설명
TASK	Isaac-Velocity-Rough-H1-v0	학습 태스크
PROC_PER_NODE	4	노드당 GPU 수
MAX_ITERATIONS	100	학습 에포크 수
NCCL_SOCKET_IFNAME	eth0	멀티노드 통신 인터페이스

작업을 제출하면 AWS Batch가 알아서 EC2 인스턴스를 프로비저닝 하고, Docker 컨테이너를 띄우고, 분산 학습을 실행합니다. CloudWatch Logs에서 학습 진행 상황을 모니터링할 수 있고, 전체 학습은 약 12분 정도 소요됩니다. GPU 1개에서 3시간 걸리던 게 8개로 늘리니 확실히 빨라지는 걸 체감할 수 있었습니다.

학습된 모델로 걷는 모습 확인

가장 재미있는 부분입니다. 72,000 에포크를 학습한 모델(agent_72000.pt)을 EFS에서 마운트 해서 로드하고, 테스트 모드로 실행합니다.

cd /workspace/IsaacLab
./isaaclab.sh -p scripts/reinforcement_learning/skrl/play.py \
  --task=Isaac-Velocity-Rough-H1-v0 \
  --num_envs 25 \
  --checkpoint=/workspace/IsaacLab/TrainedModel/agent_72000.pt

--num_envs 25는 25개의 로봇을 동시에 시뮬레이션한다는 의미입니다. 약 2-3분 후 Isaac Sim GUI가 뜨면, 25개의 휴머노이드 로봇이 울퉁불퉁한 지형 위를 넘어지지 않고 걸어가는 모습을 볼 수 있습니다. 처음에 바로 넘어지던 것과 비교하면 확실히 다릅니다.

인터랙티브 데모도 있습니다.

cd /workspace/IsaacLab
/isaac-sim/python.sh scripts/demos/h1_locomotion.py

시뮬레이션이 로드되면 로봇을 클릭해서 1인칭 시점으로 전환하고, 방향키로 직접 조종할 수 있습니다. 위쪽 방향키를 누르면 전진, 아래쪽은 정지, 좌우로 방향 전환이 됩니다. 직접 조종해 보니까 울퉁불퉁한 지형에서도 균형을 잡으면서 걸어가는 게 신기했습니다. 제가 방향만 지시하면 나머지는 학습된 정책이 알아서 처리하는 거죠. 경사면에서 살짝 비틀거리다가도 다시 균형을 잡는 모습을 보면, 72,000 에포크 동안 수없이 넘어지면서 배운 결과가 이거구나 싶었습니다.

학습 데이터는 뭘 썼나?

"데이터가 뭔데?"라는 질문이 나올 수 있습니다. 일반적인 머신러닝과 다르게, 강화학습에서는 사전에 준비된 데이터셋이 없습니다. 데이터는 학습 과정에서 실시간으로 생성됩니다.

Isaac Sim이 물리 시뮬레이션으로 로봇의 상태를 생성하고, 로봇이 행동을 취하면 그 결과(다음 상태, 보상)가 새로운 데이터가 됩니다. 이 과정을 수만 번 반복하면서 정책이 개선되는 거죠.

다만 사전에 정의해야 하는 것들이 있습니다.

요소	설명
관측 공간 (Observation Space)	로봇이 "볼 수 있는" 정보 — 관절 위치/속도, 몸체 방향, 지형 높이맵 등
행동 공간 (Action Space)	로봇이 "할 수 있는" 행동 — 각 관절의 목표 위치/토크
보상 함수 (Reward Function)	좋은/나쁜 행동의 기준 — 전진 보상, 에너지 패널티, 넘어짐 종료 등
환경 (Environment)	거친 지형, 평평한 바닥 등 시뮬레이션 세계의 설정

Isaac-Velocity-Rough-H1-v0이라는 태스크 이름 자체가 이 설정을 담고 있습니다. Isaac Lab의 Velocity 추적 태스크, Rough(거친) 지형, H1(Unitree H1 로봇), v0(버전 0)이라는 뜻이죠. 이 태스크의 환경, 보상 함수, 관측/행동 공간은 Isaac Lab에 이미 정의되어 있어서 별도로 작성할 필요 없이 바로 학습을 시작할 수 있었습니다.

이걸로 뭘 더 해볼 수 있을까?

워크샵은 사전 정의된 태스크를 그대로 실행하는 수준이지만, 여기서 확장할 수 있는 방향은 꽤 많습니다.

환경 변경: Isaac-Velocity-Rough-H1-v0 대신 Isaac-Velocity-Flat-H1-v0(평평한 지형)으로 바꿔서 학습 난이도에 따른 차이를 비교해 볼 수 있습니다.
로봇 변경: H1 대신 Unitree Go2(사족보행 로봇)나 ANYmal 같은 다른 로봇으로 바꿔볼 수 있습니다. Isaac Lab에 다양한 로봇 에셋이 포함되어 있어서 태스크 이름만 바꾸면 됩니다.
보상 함수 커스터마이징: 기본 보상 함수를 수정해서 "더 빨리 걷기", "에너지를 적게 쓰면서 걷기" 같은 다른 목표로 학습시킬 수 있습니다.
모방학습 시도: 강화학습 대신 텔레오퍼레이션 데이터를 수집해서 모방학습(Behavior Cloning)으로 학습시켜 보는 것도 가능합니다.
Sim-to-Real 전이: 시뮬레이션에서 학습한 정책을 실제 로봇에 배포하는 단계까지 나아갈 수 있습니다. 노이즈 추가(Domain Randomization)가 이 과정의 핵심인데, Isaac Lab의 파이프라인에 이미 포함되어 있습니다.

개인적으로는 사족보행 로봇의 계단 오르기 같은 태스크를 직접 설계해 보면 재미있을 것 같습니다.

비용 참고

리소스	인스턴스 타입	시간당 비용 (On-Demand)
DCV 인스턴스 (학습/추론)	g6.4xlarge	약 $3
Batch 노드 (분산 학습)	g6.12xlarge × 2	약 $10.50 × 2 = $21

본인 계정으로 진행한다면, 반드시 완료 후 CloudFormation 스택을 삭제해야 합니다. g6 인스턴스가 계속 돌아가면 비용이 빠르게 늘어납니다.

마무리

Physical AI는 아직 저에게 익숙한 영역은 아닙니다. 하지만 이 워크샵을 통해 "로봇이 어떻게 스스로 걷는 법을 배우는지"의 전체 파이프라인을 경험할 수 있었습니다. Isaac Sim이 물리 세계를 시뮬레이션하고, Isaac Lab이 학습 루프를 관리하고, AWS가 GPU 인프라를 제공하는 구조가 깔끔하게 정리됐습니다.

특히 인상적이었던 건, 72,000 에포크를 학습한 모델이 울퉁불퉁한 지형에서 넘어지지 않고 걷는 모습이었습니다. 처음에 바로 넘어지던 모습과 비교하면, 강화학습의 효과를 직관적으로 확인할 수 있었습니다.

앞으로 로봇 학습 분야가 어떻게 발전할지 기대됩니다. Isaac Lab에는 이번에 사용한 Unitree H1 휴머노이드 외에도 Boston Dynamics Spot, ANYmal 같은 사족보행 로봇, Franka나 UR10 같은 로봇 팔, Crazyflie 쿼드콥터까지 다양한 로봇이 포함되어 있습니다. NVIDIA에서 제공하는 이 로봇들을 하나씩 바꿔가면서 학습시켜 볼 예정입니다.

NVIDIA Isaac Lab Documentation

참고: 이 워크샵은 2월에 진행했고 글도 그때 대부분 작성해 뒀는데, 일이 많아서 미루고 미루다 이제야 올립니다.

Claude Cowork: 비개발자를 위한 AI 에이전트

Theo (테오) — Thu, 15 Jan 2026 15:28:55 +0900

Anthropic이 Claude Cowork를 공개했습니다. 한 줄로 요약하면 "Claude Code의 비개발자 버전"입니다.

Claude Code가 개발자들 사이에서 큰 인기를 끌었는데, 재미있는 현상이 개발자들이 코딩 외에도 휴가 계획, 이메일 정리, 프레젠테이션 제작, 영수증 정리 같은 일반 업무에 Claude Code를 활용하기 시작한 겁니다. Anthropic은 이 패턴을 보고 "코딩이 아닌 업무에도 동일한 AI 협업이 가능하지 않을까?"라는 생각이 들었고 그 결과 Cowork을 만들었습니다.

더 놀라운 건 개발 기간입니다. Boris Cherny(Claude Code 책임자)에 따르면, Cowork는 약 1주일 반 만에 Claude Code를 사용해서 만들어졌다고 합니다.

Cowork란?

기존 Claude 채팅은 질문하면 답변하는 방식입니다. 반면 Cowork는 실제로 작업을 수행하는 AI입니다.

구분	일반 채팅	Cowork
방식	질문 → 답변	작업 지시 → 실행
파일 접근	업로드한 파일만	로컬 폴더 직접 접근
작업 흐름	매번 맥락 설명 필요	자율적으로 계획 수립 및 실행
결과물	텍스트 응답	파일 생성/수정/정리

사용자가 특정 폴더에 접근 권한을 주면, Claude가 해당 폴더 내 파일을 읽고, 수정하고, 새로 만들 수 있습니다. 마치 동료에게 업무를 맡기고 중간보고를 받는 느낌입니다.

사용 요건

현재 Cowork는 다음 조건에서만 사용 가능합니다.

Claude Max 구독
macOS용 Claude Desktop 앱
Research Preview 단계 (다른 플랜은 대기자 명단)

Windows 지원은 추후 예정이라고 합니다.

사용 방법

Step 1: Claude Desktop 앱에서 Cowork 탭 선택

Claude Desktop 앱을 열면 Chat과 Cowork 탭이 있습니다. Cowork를 클릭합니다.
참고: Max 구독자인데 Cowork 탭이 보이지 않는다면 앱을 최신 버전으로 업데이트하세요. 저는 1.0.3218 버전에서 확인했습니다.

처음 Cowork를 선택하면 "Claude 작업 공간을 시작하지 못했습니다. VM connection timeout after 60 seconds" 오류가 나올 수 있습니다. 정말 1주일 반 만에 만들어서 그런지 버그가 좀 있습니다. Claude를 종료 후 재시작하거나 Mac을 재시작하면 해결됩니다. 저는 Mac 재시작 후 정상 동작했습니다.

Step 2: 작업할 폴더 선택

Claude가 접근할 폴더를 지정합니다. Claude는 이 폴더 내에서만 파일을 읽고 수정할 수 있습니다.
주의: 중요한 파일이 있는 폴더는 피하거나, 백업 후 진행하세요.

Step 3: 작업 지시

일반 채팅처럼 원하는 작업을 설명합니다. Claude가 계획을 세우고 단계별로 실행합니다. 진행 상황은 실시간으로 확인할 수 있고, 필요하면 중간에 방향을 수정할 수도 있습니다.

활용 예시

파일 정리

"다운로드 폴더를 파일 유형별로 정리해줘"
Claude가 폴더 구조를 분석하고, 이미지/문서/압축파일 등으로 분류해서 정리합니다.

영수증 → 지출 보고서

"이 폴더의 영수증 사진들을 읽어서 지출 내역 스프레드시트를 만들어줘"
영수증 이미지를 분석해서 날짜, 금액, 항목을 추출하고 Excel 파일로 정리합니다.

흩어진 메모 → 보고서

"이 폴더의 메모 파일들을 분석해서 주요 내용을 정리한 보고서를 만들어줘"
여러 파일에 흩어진 정보를 종합해서 구조화된 문서로 만들어줍니다.

콘텐츠 분석

"이 폴더의 유튜브 영상 스크립트들을 분석해서 주요 주제와 통계를 보여줘"
파일들을 분석하고, 차트와 인사이트가 포함된 PDF 보고서를 생성합니다.

확장 기능

커넥터

기존 Claude에 연결한 커넥터들을 Cowork에서도 사용할 수 있습니다.

Google Drive
Gmail
Slack
Notion
Asana 등

예를 들어, 로컬 파일로 보고서를 만든 후 Gmail을 통해 팀원에게 전송하는 것도 가능합니다.

Claude in Chrome 연동

Chrome 확장 프로그램과 함께 사용하면 웹 브라우저 작업도 수행할 수 있습니다. 주식 가격 조회, 웹 검색 등 브라우저가 필요한 작업을 처리할 수 있습니다.

주의사항

Cowork는 강력한 기능을 제공하는 만큼, 몇 가지 주의가 필요합니다.

파괴적 작업 가능

Claude가 파일을 삭제하거나 수정할 수 있습니다. 지시가 모호하면 의도와 다르게 동작할 수 있으니, 명확한 지시와 백업이 중요합니다.

프롬프트 인젝션 위험

웹 콘텐츠나 다운로드한 파일에 악성 명령어가 숨어 있을 수 있습니다. Anthropic이 방어 기능을 구축했지만, 에이전트 보안은 아직 발전 중인 영역입니다.

날짜 인식 문제

일부 사용자 테스트에서 날짜 인식이 부정확한 경우가 보고됐습니다. 날짜가 중요한 작업에서는 결과를 확인하세요.

Research Preview

아직 초기 단계입니다. 버그나 오류가 발생할 수 있으니 중요한 작업에는 주의가 필요합니다.

현재 제한사항

macOS 전용 (Windows 추후 지원)
Max 플랜 전용 ($100~$200/월)
프로젝트 지원 안 됨
세션 간 메모리 없음
앱이 열려 있어야 작업 진행

마무리

Claude Cowork는 AI를 "답변하는 도구"에서 "일하는 동료"로 확장한 시도입니다. 파일 시스템 접근, 자율적 작업 수행, 병렬 처리 등은 기존 챗봇과 확실히 다릅니다. 현재는 Max 플랜 + macOS 조합에서만 사용 가능하지만, 향후 더 많은 사용자에게 열릴 예정입니다. 가격이 부담스럽긴 하지만, 파일 관리나 문서 작업이 많다면 한 번 써볼 만합니다.

참고 링크

Oracle Cloud Free Tier 가입 방법: 평생 무료 클라우드 서버 만들기

Theo (테오) — Fri, 9 Jan 2026 17:45:35 +0900

AWS, GCP, Azure 같은 클라우드 서비스는 프리티어가 있지만 대부분 12개월 제한이 있습니다. 반면 Oracle Cloud Free Tier는 상시 무료(Always Free) 서비스를 제공합니다. 기간 제한 없이 계속 쓸 수 있다는 뜻이죠.

특히 ARM 기반 Ampere A1 인스턴스는 4 OCPU, 24GB RAM까지 무료로 제공되는데, 이 정도 스펙이면 웬만한 개인 프로젝트는 충분히 돌릴 수 있습니다.

상시 무료로 제공되는 서비스

분류	서비스	스펙
컴퓨트	AMD 기반 VM ARM 기반 Ampere A1	2개 (각 1/8 OCPU, 1GB RAM) 4 OCPU, 24GB RAM (VM 1~4개로 분할 가능)
스토리지	블록 볼륨 오브젝트 스토리지	총 200GB (2개) 10GB (표준), 10GB (비정규), 10GB (아카이브)
데이터베이스	Autonomous Database NoSQL Database	2개 (각 1 OCPU, 20GB) 월 1.33억 읽기/쓰기, 테이블 3개 (각 25GB)
네트워크	아웃바운드 트래픽 로드 밸런서 VCN	월 10TB 1개 (10Mbps) 2개

이 외에도 모니터링, 알림, 로깅 등 다양한 서비스가 무료로 제공됩니다.

가입 전 준비물

이메일: 기존에 Oracle Cloud에 등록하지 않은 이메일
휴대폰 번호: SMS 인증용
신용카드: 해외 결제 가능한 VISA, MasterCard, AMEX (본인 인증용)
브라우저: Chrome, Safari, Firefox 권장

참고: 신용카드는 본인 인증 용도로만 사용됩니다. 인증 시 소액 결제 후 바로 취소되며, 상시 무료 서비스만 사용하면 요금이 청구되지 않습니다. 체크카드는 인증 실패할 수 있으니 신용카드를 권장합니다.

가입 절차

Step 1: Oracle Cloud Free Tier 페이지 접속

Oracle Cloud Free Tier 페이지에 접속합니다.

무료로 시작하기 버튼을 클릭합니다.

Step 2: 계정 정보 입력

국가: 대한민국
이름/성: 영문으로 입력
이메일: 사용할 이메일 주소 입력

내 전자메일 확인 버튼을 클릭하면 입력한 이메일로 인증 메일이 발송됩니다.

Step 3: 이메일 인증

받은 메일에서 인증 링크를 클릭합니다. 같은 브라우저에서 열어야 이어서 진행됩니다.

Step 4: 추가 정보 입력

비밀번호: 영문 대소문자, 숫자, 특수문자 포함 8 자 이상
클라우드 계정 이름: 로그인 시 사용할 계정명 (변경 불가)
홈 리전: 서울(Seoul) 또는 춘천(Chuncheon) 선택

중요: 홈 리전은 최초 설정 후 변경할 수 없습니다. 서울 리전은 수요가 많아 VM 생성이 어려울 수 있으니, 춘천이나 일본 리전도 고려해 보세요.

Step 5: 주소 및 연락처 입력

주소: 영문 주소로 입력 (네이버에서 "영문주소" 검색)
휴대폰 번호: SMS 인증 코드 수신용

계속 버튼을 클릭합니다.

Step 6: 신용카드 등록

Add Credit Card Details 버튼을 클릭하고 카드 정보를 입력합니다.

카드 번호
만료일
CVV

입력 후 인증을 위해 소액(약 $1)이 결제되었다가 바로 취소됩니다. 문자로 결제/취소 알림이 오면 정상입니다.

Step 7: 약관 동의 및 가입 완료

Oracle Cloud 서비스 약관에 동의하고 무료 계정 시작 버튼을 클릭합니다.

계정 생성 중 화면이 표시되고, 약 1분 후 로그인 페이지로 이동합니다.

Step 8: 로그인 및 MFA 설정

생성한 계정으로 로그인합니다. 첫 로그인 시 2단계 인증(MFA) 설정을 요청받습니다.

Oracle Mobile Authenticator 앱을 설치하거나, 다른 인증(FIDO 등)을 사용합니다.

Step 9: OCI 콘솔 접속

로그인이 완료되면 Oracle Cloud Infrastructure(OCI) 콘솔에 접속됩니다.

이제 VM 인스턴스, 데이터베이스 등 상시 무료 서비스를 사용할 수 있습니다.

가입 시 주의사항

홈 리전 변경 불가: 처음 선택한 리전은 변경할 수 없습니다. 신중하게 선택하세요.
중복 가입 불가: 1인 1 계정만 허용됩니다. 이메일, 전화번호, 신용카드 조합으로 중복 여부를 확인합니다.
30일 무료 크레딧: 가입 시 $300 크레딧이 제공되지만, 30일 후 소멸됩니다. 상시 무료 서비스는 계속 사용 가능합니다.
유료 업그레이드 전까지 과금 없음: 상시 무료 범위 내에서는 요금이 청구되지 않습니다. 유료 계정으로 업그레이드하지 않는 한 안심하고 사용하세요.
서울 리전 VM 생성 어려움: 서울 리전은 수요가 많아 "Out of capacity" 오류가 자주 발생합니다. 춘천이나 일본 리전을 고려하거나, 시간을 두고 재시도하세요.

VM 인스턴스 생성 방법

Step 1: 인스턴스 생성 페이지로 이동

OCI 콘솔 메인 화면에서 리소스 실행 섹션의 VM 인스턴스 생성을 클릭합니다. 또는 왼쪽 상단 햄버거 메뉴 → 컴퓨트 → 인스턴스 → 인스턴스 생성

Step 2: 이미지 선택

기본값은 Oracle Linux입니다. Chage image를 클릭해서 원하는 OS를 선택하세요.

Price가 "Free" 인 이미지만 무료입니다

Ubuntu
Oracle Linux
CentOS

Step 3: Shape 선택 (중요!)

Shape 변경을 클릭합니다."Always Free-eligible" 뱃지가 붙은 Shape만 무료입니다.

무료로 사용 가능한 Shape

Shape 스펙 비고

VM.Standard.E2.1.Micro	AMD, 1/8 OCPU, 1GB RAM	2개까지
VM.Standard.A1.Flex	ARM Ampere, 최대 4 OCPU, 24GB RAM	유동 할당

ARM(Ampere A1)을 선택하면 OCPU와 메모리를 원하는 만큼 할당할 수 있습니다. (최대 4 OCPU, 24GB)

Security는 기본값 그대로 넘어가면 됩니다. 인스턴스 생성 시 Security 부분은 기본 설정으로 두면 SSH(22번 포트)가 자동으로 열려 있어서 바로 접속할 수 있습니다.

Step 4: 네트워킹 설정

기본 VCN이 없으면 자동으로 생성됩니다. 공용 IPv4 주소 지정이 체크되어 있는지 확인하세요.

Step 5: SSH 키 등록

키 쌍 생성을 선택하면 자동으로 키가 생성됩니다. 전용 키 저장과 공용 키 저장을 클릭해서 둘 다 다운로드하세요.

중요: 전용 키(Private Key)는 이때만 다운로드 가능합니다. 분실하면 인스턴스에 접속할 수 없어요.

Storage도 기본값으로 두면 됩니다. 기본 부트 볼륨이 47GB로 설정되어 있고, 상시 무료로 총 200GB까지 사용 가능해요. 필요하면 나중에 부트 볼륨 크기를 늘리거나 블록 볼륨을 추가로 붙일 수 있습니다.

Step 6: 생성

생성 버튼을 클릭합니다. 잠시 후 상태가 RUNNING으로 바뀌면 완료입니다.

공용 IP 주소와 사용자 이름을 확인하세요.

Step 7: SSH 접속

# Ubuntu의 경우
ssh -i <전용키 경로> ubuntu@<공용IP>

# Oracle Linux의 경우
ssh -i <전용키 경로> opc@<공용IP>

Out of Capacity 오류?

ARM 인스턴스는 인기가 많아서 "Out of host capacity" 오류가 자주 발생합니다.

해결 방법

시간대를 바꿔서 재시도 (새벽 시간대 추천)
다른 가용성 도메인 선택
OCPU/메모리를 줄여서 시도
며칠 후 재시도

마무리

Oracle Cloud Free Tier는 다른 클라우드 서비스 대비 상당히 파격적인 조건을 제공합니다. 특히 ARM 기반 4 OCPU, 24GB RAM은 개인 프로젝트용으로 충분한 스펙입니다.

PaddleOCR Service: PaddleOCR을 AWS 서버리스로 배포하기

Theo (테오) — Fri, 9 Jan 2026 11:42:39 +0900

지난 글에서 PaddleOCR 3.0의 세 가지 모델(PP-OCRv5, PP-StructureV3, PaddleOCR-VL)을 테스트해 봤습니다. PP-OCRv5는 빠르고 가볍고, PaddleOCR-VL은 결과가 좋지만 GPU가 필요했습니다.

문제는 GPU 환경입니다. 매번 Colab 열어서 런타임 연결하고, 모델 로드하고, 이미지 업로드하고... 테스트할 때마다 이 과정을 반복하는 게 번거로웠습니다. 그래서 AWS에 배포해서 웹 브라우저에서 바로 테스트할 수 있는 플레이그라운드를 만들어봤습니다.

PaddleOCR Service란?

PaddleOCR Service는 PaddleOCR 모델들을 AWS 서버리스 인프라에서 테스트할 수 있는 웹 기반 플레이그라운드입니다. 이미지나 PDF를 업로드하면 OCR 결과를 바로 확인할 수 있고, 바운딩 박스 오버레이로 인식 영역도 시각적으로 볼 수 있습니다.

참고: 프로덕션 솔루션이 아닙니다. PaddleOCR 모델을 AWS 환경에서 실험하고 평가하기 위한 용도로 만들었습니다.

지원 모델

이전 글에서 테스트했던 세 가지 모델을 모두 지원합니다.

PP-OCRv5

일반적인 텍스트 추출에 최적화된 모델입니다. 80개 이상 언어를 지원하고, 속도가 빠릅니다.

옵션

언어 선택 (한국어, 영어, 중국어, 일본어 등)
문서 방향 자동 보정
문서 왜곡 보정
텍스트 라인 방향 감지

PP-StructureV3

문서 구조 분석 모델입니다. 제목, 본문, 표, 이미지 등 20가지 레이아웃 요소를 구분합니다. 이전 테스트에서 한글 인식률이 낮았던 점은 여전하지만, 영문 문서나 표 추출이 필요한 경우에는 유용합니다.

감지 가능한 레이아웃

doc_title: 문서 제목
paragraph_title: 섹션 제목
text: 본문 텍스트
table: 표 (Markdown으로 변환)
formula: 수식
image, chart: 이미지, 차트
그 외 14가지 요소

PaddleOCR-VL

0.9B VLM 기반 End-to-End 문서 파싱 모델입니다. 이전 테스트에서 가장 결과가 좋았던 모델이죠. 별도 옵션 없이 자동으로 언어와 구조를 인식합니다.

로컬에서 CPU로 돌리면 이미지당 10분씩 걸렸는데, SageMaker GPU 인스턴스에서는 훨씬 빠르게 처리됩니다.

아키텍처

AWS 서버리스 아키텍처로 구성했습니다.

컴포넌트	AWS 서비스	설명
Frontend	CloudFront + S3	React 웹 애플리케이션
인증	Cognito	사용자 인증
API	API Gateway + Lambda	REST API
OCR 엔진	SageMaker Endpoint	PaddleOCR 모델 추론
저장소	S3	문서 및 결과 저장
컨테이너	ECR + CodeBuild	SageMaker용 Docker 이미지

처리 흐름

Cognito로 로그인
React 프론트엔드에서 이미지 업로드
API Gateway → Lambda → S3 저장
Lambda가 SageMaker 엔드포인트 호출
SageMaker에서 PaddleOCR 추론
결과를 S3에 저장하고 프론트엔드로 반환

출력 포맷

네 가지 출력 포맷을 지원합니다.

포맷	설명	저장 형식
Markdown	구조화된 텍스트 (표 포함)	.md
HTML	웹 표시용 리치 포맷	.html
JSON	프로그래밍용 원본 데이터	.json
Blocks	바운딩 박스와 크롭 이미지 시각화	-

Document 탭에서는 OCR 결과를 직접 편집할 수 있습니다. 잘못 인식된 텍스트를 수정하거나 불필요한 부분을 삭제할 수 있죠. 편집 후 HTML 파일로 저장됩니다.

배포 방법

AWS CloudShell에서 간단하게 배포할 수 있습니다.

# 저장소 클론
git clone https://github.com/yunwoong7/paddle-ocr-service.git
cd paddle-ocr-service

# 배포 스크립트 실행
chmod +x deploy.sh
./deploy.sh

배포 과정에서 관리자 이메일과 SageMaker 인스턴스 타입을 입력하면 됩니다. 전체 배포는 약 20-30분 정도 소요됩니다.

비용 주의

⚠️ SageMaker 엔드포인트는 24시간 실행되며, ml.g5.xlarge 기준 월 $1,000 이상 비용이 발생합니다.

사용하지 않을 때는 엔드포인트를 삭제하세요.

# 엔드포인트만 삭제
./cleanup.sh --endpoint-only

# 전체 리소스 삭제
./cleanup.sh

마무리

PaddleOCR을 AWS에서 돌릴 수 있게 만들어봤습니다. 로컬에서 테스트할 때의 번거로움은 줄었고, GPU 환경도 신경 쓸 필요 없어졌습니다. 다만 비용이 만만치 않아서, 상시 운영보다는 필요할 때만 띄워서 테스트하는 용도로 쓰는 게 좋을 것 같습니다.

코드는 GitHub에 공개해뒀습니다.

GitHub: paddle-ocr-service

Claude Code 완벽 가이드 (2) - 커스텀 명령어부터 고급 활용까지

Theo (테오) — Thu, 8 Jan 2026 17:44:55 +0900

지난 글에서는 Claude Code의 설치와 기본 기능을 다뤘습니다.

Claude Code 완벽 가이드 (1) - 설치부터 기본 기능까지

작년 초만 해도 저는 Cursor를 주력으로 사용했습니다. 그런데 지금은 거의 Claude Code만 쓰고 있어요. 터미널 기반이라 처음엔 낯설었는데, 익숙해지고 나니 오히려 이게 더 빠르고 강력하다는 생

yunwoong.tistory.com

이번 글에서는 Claude Code를 더 강력하게 만들어주는 중급 기능들을 알아보겠습니다. 마지막에는 Claude Code를 만든 보리스 체르니(Boris Cherny)가 직접 공개한 활용법도 소개해 드릴게요.

중급 기능

커스텀 슬래시 명령어

반복적으로 사용하는 프롬프트가 있다면, 커스텀 명령어로 만들어두면 편합니다.

설정 방법

프로젝트 루트에 .claude/commands/ 폴더를 만들고, 마크다운 파일을 추가합니다.

.claude/
└── commands/
    ├── review.md
    ├── test.md
    └── commit.md

예시: review.md

# Code Review

방금 수정한 파일들을 검토해줘.

## 확인 사항
1. 보안 취약점은 없는지
2. 에러 핸들링이 제대로 되어 있는지
3. 성능 이슈는 없는지
4. 코드 스타일이 일관적인지

문제가 있으면 수정해줘.

예시: commit.md

# Commit and Push

1. 변경된 파일들을 확인해줘
2. 의미 있는 커밋 메시지를 작성해줘 (한국어)
3. 커밋하고 현재 브랜치에 푸시해줘

이렇게 만들어두면 /review, /commit으로 바로 호출할 수 있습니다.

예시: cm.md (Commit 을 위한 메시지 만들기)

# commit message

Generate a concise one-line commit message in English.
1. Run `git diff --cached --stat` to check staged files
2. If no staged files, run `git diff --stat` to check unstaged changes
3. Analyze the changes and generate a commit message following this format:
   - Start with a verb (Add, Fix, Update, Remove, Refactor, etc.)
   - Keep it under 50 characters
   - Be specific but concise
4. Output ONLY the commit message, nothing else

인자 받는 명령어

명령어에 인자를 전달할 수도 있습니다.

# API Endpoint 생성

$ARGUMENTS에 대한 API 엔드포인트를 생성해줘.

## 포함 사항
- 타입 정의
- 에러 핸들링
- 미들웨어 적용

사용할 때

/api-endpoint 사용자 프로필 조회

그러면 $ARGUMENTS 자리에 "사용자 프로필 조회"가 들어갑니다.

서브에이전트 (Sub-agents)

서브에이전트는 특정 역할에 특화된 별도의 Claude 인스턴스입니다.

왜 필요한가요?

메인 Claude의 컨텍스트를 오염시키지 않음
각 서브에이전트가 독립적인 컨텍스트를 가짐
병렬로 여러 작업을 동시에 처리 가능

서브에이전트 만들기

방법 1: /agents 명령어 사용

/agents
→ Create new agent 선택
→ Project 또는 Personal 선택
→ Generate with Claude 선택
→ 원하는 에이전트 설명 입력

방법 2: 직접 파일 생성

.claude/agents/ 폴더에 마크다운 파일을 만듭니다.

.claude/
└── agents/
    ├── code-reviewer.md
    ├── test-writer.md
    └── ui-checker.md

예시: code-reviewer.md

# Code Reviewer

당신은 시니어 개발자로서 코드 리뷰를 담당합니다.

## 역할
- 방금 작성된 코드를 검토
- 버그 가능성 체크
- 성능 이슈 확인
- 보안 취약점 검토

## 규칙
- 문제가 있으면 구체적으로 지적
- 개선 방안도 함께 제시
- 칭찬할 부분은 칭찬

예시: ui-checker.md

# UI/UX Checker

당신은 UI/UX 전문가입니다.

## 역할
- Playwright MCP를 사용하여 브라우저에서 앱 확인
- UI 컴포넌트의 디자인과 사용성 평가
- 접근성 이슈 체크

## 도구
- Playwright MCP 사용 가능

서브에이전트 호출

@code-reviewer 방금 수정한 파일들 검토해줘
@ui-checker 로그인 페이지 UI 확인해줘

병렬 실행

서브에이전트의 진짜 힘은 병렬 실행에서 나옵니다.

4개의 서브에이전트를 띄워서 각각 다음 작업을 병렬로 처리해줘:
1. @code-reviewer - 코드 리뷰
2. @test-writer - 테스트 코드 작성
3. @ui-checker - UI 확인
4. @doc-writer - 문서화

Hooks - 자동 실행 스크립트

Hooks는 특정 이벤트가 발생했을 때 자동으로 실행되는 스크립트입니다.

설정 위치: .claude/settings.json

사용 가능한 이벤트

이벤트	설명
stop	Claude가 응답을 완료했을 때
afterToolUse	도구(파일 수정 등)를 사용한 후
beforeToolUse	도구를 사용하기 전

예시 1: 작업 완료 알림

{
  "hooks": {
    "stop": [
      {
        "matcher": "",
        "command": "osascript -e 'display notification \"작업 완료!\" with title \"Claude Code\"'"
      }
    ]
  }
}

예시 2: 소리 알림

{
  "hooks": {
    "stop": [
      {
        "matcher": "",
        "command": "afplay /System/Library/Sounds/Glass.aiff"
      }
    ]
  }
}

예시 3: 파일 수정 후 자동 포매팅

{
  "hooks": {
    "afterToolUse": [
      {
        "matcher": "write|edit",
        "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
      }
    ]
  }
}

파일을 수정할 때마다 자동으로 Prettier가 실행됩니다.

예시 4: 파일 생성 후 자동 스테이징

{
  "hooks": {
    "afterToolUse": [
      {
        "matcher": "write",
        "command": "git add \"$CLAUDE_FILE_PATH\""
      }
    ]
  }
}

MCP 서버 연동

MCP(Model Context Protocol)는 Claude에게 외부 도구를 연결해주는 방식입니다.

MCP로 할 수 있는 것들

데이터베이스 직접 조회/수정
브라우저 제어 (Playwright)
외부 API 호출
문서 검색

MCP 서버 추가 방법

claude mcp add <server-name> -- <command>

예시: Context7 (최신 문서 참조)

claude mcp add context7 -- npx -y @anthropics/context7-mcp

Context7을 추가하면 Claude가 최신 라이브러리 문서를 참조할 수 있습니다.

Next.js 14 App Router에서 서버 컴포넌트 만들어줘. use context7

"use context7"을 붙이면 Claude가 자동으로 최신 문서를 찾아서 참고합니다.

자주 쓰는 MCP 서버들

MCP 서버	용도
Context7	최신 라이브러리 문서 참조
Playwright	브라우저 제어, UI 테스트
Supabase	데이터베이스 조회/수정
GitHub	저장소 관리, PR 생성
Stripe	결제 관련 기능

MCP 설정 파일

프로젝트 루트에 .mcp.json 파일이 생성됩니다.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@anthropics/context7-mcp"]
    },
    "playwright": {
      "command": "npx",
      "args": ["@anthropics/playwright-mcp"]
    }
  }
}

MCP 상태 확인

claude mcp status

또는 Claude Code 안에서

/mcp

Output Style - 응답 스타일 커스텀

Claude의 응답 스타일을 바꿀 수 있습니다.

/output-style

기본 제공 스타일

Default - 간결한 응답
Detailed - 부연 설명 포함
Learning - 학습용 (왜 이렇게 하는지 설명)

커스텀 스타일 만들기

/output-style new

응답할 때 이모지를 적극적으로 사용하고, 
친근한 말투로 설명해줘. 
코드에는 한국어 주석을 달아줘.

생성된 스타일은 .claude/output-styles/ 폴더에 저장됩니다.

권한 설정

Claude Code가 어떤 명령어를 실행할 수 있는지 제어할 수 있습니다.

설정 위치: .claude/settings.json

{
  "permissions": {
    "allow": [
      "npm run",
      "npm test",
      "git status",
      "git add",
      "git commit",
      "git push",
      "npx prettier",
      "npx eslint"
    ],
    "deny": [
      "rm -rf",
      "sudo",
      "chmod"
    ]
  }
}

allow에 등록된 명령어

확인 없이 바로 실행

deny에 등록된 명령어

절대 실행하지 않음

등록되지 않은 명령어

매번 사용자에게 확인 요청

주의: --dangerously-skip-permissions

claude --dangerously-skip-permissions

이 옵션을 쓰면 모든 권한 확인을 건너뜁니다. 편하긴 하지만 위험할 수 있어요.

쓰려면 Dev Container 안에서 쓰는 걸 추천합니다. (보리스 체르니도 이렇게 씁니다)

보리스 체르니의 Claude Code 활용법

여기서부터는 Claude Code를 만든 보리스 체르니(Boris Cherny)가 직접 공개한 활용법입니다. 2026년 1월 X(트위터)에 올린 글이 620만 조회를 기록하며 큰 화제가 됐어요.

1. 병렬 실행 - 5개 이상의 Claude를 동시에

보리스는 기본적으로 5개의 Claude를 로컬 터미널에서 동시에 실행합니다. 여기에 웹 세션 5~10개를 추가로 사용한다고 해요.

iTerm2 설정 (macOS)

iTerm2 → Preferences → Profiles → Terminal
✅ "Silence bell" 체크 해제
✅ "Send Notification Center alerts" 체크

이렇게 하면 Claude가 입력을 기다릴 때 알림이 옵니다.

창 분할

Cmd + D        # 수직 분할
Cmd + Shift + D  # 수평 분할

각 창에서 다른 작업을 시킵니다.

창 1: 테스트 작성
창 2: 리팩토링
창 3: 문서화
창 4: 버그 수정
창 5: 새 기능 개발

혼자서 소규모 팀처럼 일할 수 있습니다.

2. 가장 똑똑한 모델 사용 - Opus 4.5

보리스는 항상 Claude Opus 4.5를 사용합니다.

" Sonnet보다 크고 느리긴 하지만, 직접 조작할 필요가 적고 도구 활용 능력이 뛰어나서 결과적으로 더 빠르다 "

/config
→ Model → Claude Opus 4.5 선택
→ Thinking → 활성화

핵심 포인트

빠른 모델보다 똑똑한 모델
AI의 병목은 토큰 생성 속도가 아니라, AI 오류를 수정하는 인간의 시간
처음에 좀 더 시간을 들여도 수정 비용을 줄이는 게 이득

3. CLAUDE.md 팀 공유

보리스 팀은 CLAUDE.md를 Git에 커밋해서 공유합니다.

핵심 규칙

Claude가 실수할 때마다 CLAUDE.md에 규칙 추가
팀원 모두가 적극적으로 CLAUDE.md 개선에 참여
팀별로 각각의 CLAUDE.md 관리

# 실수 기록

## 2025-01-15
- ❌ Prisma migrate 전에 db push 먼저 해야 함
- 이유: 스키마 변경 시 데이터 손실 방지

## 2025-01-16
- ❌ API 라우트에서 try-catch 빠뜨리지 말 것
- 이유: 에러 시 500 대신 적절한 에러 메시지 반환 필요

이렇게 하면 Claude가 같은 실수를 반복하지 않습니다.

4. 커스텀 명령어와 서브에이전트 활용

보리스가 자주 쓰는 명령어

/commit-push-pr

Git 버전 관리 전체를 Claude가 자동으로 처리합니다.

서브에이전트

code-simplifier: 코드 정리 및 최적화
verify-app: 앱 테스트 및 검증

5. 권한 설정 - dangerously-skip-permissions 안 씀

보리스는 --dangerously-skip-permissions를 쓰지 않습니다. 대신 필요한 명령어들을 permissions 설정에 미리 등록해둡니다.

{
  "permissions": {
    "allow": [
      "npm run",
      "git status",
      "git add",
      "git commit",
      "git push",
      "prisma db push"
    ]
  }
}

그리고 이 설정을 팀과 공유합니다.

6. 검증 루프 - 가장 중요한 요소

" 훌륭한 결과를 얻기 위한 가장 중요한 요소는 Claude가 자신의 작업을 검증할 방법을 제공하는 것 "

보리스는 Claude에게 검증 방법을 명확히 알려줍니다.

CLAUDE.md에 추가

# 검증 규칙

모든 코드 변경 후:
1. npm run build 실행하여 빌드 확인
2. npm run test 실행하여 테스트 통과 확인
3. 실패 시 자동으로 수정 시도
4. 브라우저에서 직접 확인 필요하면 Playwright 사용

이런 피드백 루프를 갖추면 결과 품질이 2~3배 향상된다고 합니다.

유용한 도구들

Claude Code를 더 잘 쓸 수 있게 도와주는 도구들입니다.

ccusage - 사용량 확인

Claude Code를 얼마나 썼는지 확인할 수 있습니다.

npx ccusage@latest

일별 토큰 사용량, 비용을 시각적으로 보여줍니다.

Super Claude - 올인원 플러그인

여러 유용한 슬래시 명령어와 페르소나가 미리 구축되어 있습니다.

npm install -g @bifrost_inc/superclaude && superclaude install

특징

개발 관련 슬래시 명령어 모음
상황별 페르소나 자동 전환 (아키텍트, 프론트엔드, 백엔드 등)

Claude Code Templates

원하는 기능만 골라서 설치할 수 있는 템플릿 마켓플레이스입니다.

웹사이트: aitemplate.com

사용 방법

웹사이트에서 원하는 템플릿 선택
"Add to Stack" 버튼으로 장바구니에 추가
생성된 설치 명령어 복사
프로젝트에서 실행

npx claude-templates install hooks/auto-format hooks/git-add commands/review

마무리

이번 글에서 다룬 내용을 정리하면

커스텀 명령어: .claude/commands/에 마크다운 파일로 저장
서브에이전트: .claude/agents/에 역할별 에이전트 정의
Hooks: 특정 이벤트 발생 시 자동 실행
MCP: 외부 도구 연결 (DB, 브라우저, API 등)
Output Style: 응답 스타일 커스터마이징
권한 설정: allow/deny로 명령어 제어

보리스 체르니 방식:

여러 Claude 병렬 실행
가장 똑똑한 모델 사용
검증 루프 구축

직접 써보면서 자신만의 워크플로우를 만들어 보세요.

참고

Claude Code 완벽 가이드 (1) - 설치부터 기본 기능까지

Theo (테오) — Thu, 8 Jan 2026 13:14:47 +0900

작년 초만 해도 저는 Cursor를 주력으로 사용했습니다. 그런데 지금은 거의 Claude Code만 쓰고 있어요. 터미널 기반이라 처음엔 낯설었는데, 익숙해지고 나니 오히려 이게 더 빠르고 강력하다는 생각이 듭니다.

이 글에서는 Claude Code를 처음 접하는 분들을 위해 설치부터 기본 기능까지 정리해 보려고 합니다.

Claude Code란?

Claude Code는 Anthropic에서 만든 터미널 기반 AI 코딩 에이전트입니다. VS Code나 Cursor 같은 IDE가 아니라 터미널에서 직접 실행하는 방식이에요.

처음에는 소스 원복이나 코드 리뷰가 불편했는데, 지금은 업데이트가 많이 되어서 롤백도 쉽고 diff 확인도 편해졌습니다. 터미널이라 낯설 수 있지만, 코드 에디터는 기존에 쓰던 걸 그대로 쓰면서 Claude Code를 함께 활용하면 됩니다.

설치 방법

설치 방법은 세 가지가 있습니다.

방법 1: Native Install (권장)

macOS, Linux, WSL

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell

irm https://claude.ai/install.ps1 | iex

Windows CMD

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

방법 2: Homebrew (macOS)

brew install --cask claude-code

방법 3: NPM

npm install -g @anthropic-ai/claude-code

설치가 완료되면, 프로젝트 폴더로 이동해서 claude를 입력하면 됩니다.

cd your-project
claude

처음 실행하면 Anthropic 계정 로그인을 요청합니다. 로그인하면 바로 사용할 수 있습니다.

기본 기능

/init - 프로젝트 초기화

새 프로젝트에서 Claude Code를 처음 사용한다면, 가장 먼저 할 일은 /init 명령어입니다.

/init

이 명령어를 실행하면 Claude Code가 프로젝트 전체를 분석해서 CLAUDE.md 파일을 자동으로 생성해 줍니다.

CLAUDE.md가 뭔가요?

CLAUDE.md는 Claude Code의 "기억 파일"입니다. 이 파일에 프로젝트에 대한 정보를 적어두면, Claude가 매번 새로운 대화를 시작해도 프로젝트 맥락을 이해한 상태로 시작합니다.

/init으로 자동 생성된 CLAUDE.md를 보면 이런 내용이 들어 있습니다.

# Project Overview
Next.js 14 기반 웹 애플리케이션

# Tech Stack
- Framework: Next.js 14 (App Router)
- Language: TypeScript
- Styling: Tailwind CSS
- Database: Prisma + PostgreSQL

# Project Structure
/app - 페이지 및 라우팅
/components - 재사용 컴포넌트
/lib - 유틸리티 함수
...

이 파일은 자동 생성된 후에 직접 수정해도 됩니다. 예를 들어

# Coding Rules
- 함수명은 camelCase 사용
- 컴포넌트는 PascalCase 사용
- 한국어 주석 선호
- console.log 대신 proper logging 사용

# 자주 하는 실수 (Claude 참고용)
- Prisma migrate 전에 db push 먼저 실행할 것
- API 라우트에서 try-catch 필수

이렇게 규칙을 적어두면 Claude가 코드 작성할 때 이를 따릅니다. 팀 프로젝트라면 이 파일을 Git에 커밋해서 공유하면 팀원 모두 같은 규칙으로 Claude를 사용할 수 있습니다.

모드 전환 - Shift + Tab

Claude Code에는 두 가지 모드가 있습니다.

1. Plan 모드

코드를 직접 수정하지 않음
계획만 세우고 검토
"이렇게 하면 어떨까요?" 식으로 제안

2. Act 모드 (기본)

실제로 코드를 수정
파일 생성, 삭제, 편집 가능

Shift + Tab을 누르면 모드를 전환할 수 있습니다.

언제 Plan 모드를 쓰나요?

복잡한 기능을 구현하기 전에 먼저 계획을 세우고 싶을 때 유용합니다.

[Plan 모드에서]
사용자 인증 기능을 구현하려고 해. 
어떤 파일들을 만들어야 하고, 어떤 순서로 작업하면 좋을지 계획 세워줘.

Claude가 계획을 제시하면 검토하고, 마음에 들면 Shift + Tab으로 Act 모드로 전환해서 실행하면 됩니다.

저는 보통 이렇게 씁니다.

Plan 모드에서 계획 수립
계획 검토 및 수정 요청
만족스러우면 Act 모드로 전환
"위 계획대로 진행해줘" 입력

이렇게 하면 Claude가 엉뚱한 방향으로 가는 걸 미리 방지할 수 있습니다.

/config - 설정

/config 명령어로 Claude Code의 기본 설정을 변경할 수 있습니다.

/config

주요 설정 항목

1. Model 선택

Claude Sonnet 4.5 (빠름)
Claude Opus 4.5 (느리지만 더 똑똑함)
Claude Haiku 4.5 (가장 빠름)

2. Thinking 모드

활성화하면 Claude가 더 깊이 생각하고 답변
복잡한 문제에 유용

3. Rewind code

Claude가 수정한 코드를 이전 상태로 되돌리는 기능
잘못된 변경이 있을 때 빠르게 원복 가능

4. Notifications

Claude가 입력을 기다리거나 작업이 완료됐을 때 알림
병렬로 여러 세션 돌릴 때 유용

5. Auto-connect to IDE

VS Code 등 IDE와 자동 연결
Claude가 수정한 파일이 IDE에서 바로 반영됨

/clear - 대화 초기화

/clear

현재 세션의 대화 기록을 모두 지웁니다.

왜 필요한가요?

Claude Code는 대화가 쌓일수록 컨텍스트 윈도우가 차오릅니다. 너무 많은 대화가 쌓이면

예전 내용과 최근 내용이 섞여서 혼란
응답 품질 저하
토큰 비용 증가

그래서 하나의 기능 개발이 끝나면 /clear로 초기화하고 새로 시작하는 게 좋습니다.

/resume - 이전 대화 불러오기

/resume

/clear로 지운 대화나 이전 세션의 대화를 다시 불러올 수 있습니다.

"아, 아까 그 대화에서 이어서 작업하고 싶은데..."할 때 유용해요.

/export - 대화 내보내기

/export

현재 대화 내용을 클립보드나 파일로 내보냅니다.

활용 예시:

Claude Code에서 작업하다가 Cursor로 이어서 하고 싶을 때
대화 내용을 문서로 저장하고 싶을 때
팀원에게 작업 내용을 공유하고 싶을 때

/mcp - MCP 서버 상태 확인

/mcp

현재 연결된 MCP 서버들의 상태를 확인합니다.

/agents - 서브에이전트 관리

/agents

서브에이전트 목록을 보거나 새로 만들 수 있습니다. (자세한 내용은 아래에서 설명)

터미널 명령어 실행 - !

Claude Code 안에서 터미널 명령어를 직접 실행할 수도 있습니다. 느낌표(!)를 앞에 붙이면 됩니다.

!npm run build
!git status
!prisma db push

장점:

터미널을 따로 열 필요 없음
실행 결과를 Claude가 바로 볼 수 있음
에러가 나면 Claude가 바로 분석하고 해결책 제시

예를 들어 !npm run build에서 에러가 나면, Claude가 에러 메시지를 보고 "이 부분이 문제네요, 이렇게 수정하면 됩니다"라고 바로 알려줍니다.

마무리

여기까지가 Claude Code의 기본 기능입니다. 정리하면:

설치: Native Install, Homebrew, NPM 중 선택
초기화: /init으로 CLAUDE.md 생성
모드 전환: Shift + Tab으로 Plan/Act 모드 전환
설정: /config에서 모델, Thinking 모드 등 설정
유틸리티: /clear, /resume, /export 등 활용
터미널 실행: ! 붙여서 명령어 직접 실행

다음 글에서는 커스텀 명령어, 서브에이전트, Hooks, MCP 서버 연동 등 중급 기능을 다루겠습니다. Claude Code를 만든 보리스 체르니의 활용법도 이어서 다음글에 소개하겠습니다.

Claude Code 완벽 가이드 (2) - 커스텀 명령어부터 고급 활용까지

지난 글에서는 Claude Code의 설치와 기본 기능을 다뤘습니다. Claude Code 완벽 가이드 (1) - 설치부터 기본 기능까지작년 초만 해도 저는 Cursor를 주력으로 사용했습니다. 그런데 지금은 거의 Claude Code

yunwoong.tistory.com

참고

Claude Code 공식 문서

Multi-Agent 시스템, 정말 효과적일까?

Theo (테오) — Tue, 6 Jan 2026 12:20:07 +0900

안녕하세요, 오늘은 AI 에이전트 시스템에 관한 논문 하나를 소개해 드리려고 합니다.

최근 AI 에이전트가 화두가 되면서, "에이전트를 여러 개 쓰면 더 좋은 성능을 낼 수 있다"는 생각이 업계에 널리 퍼져 있습니다. 실제로 "More agents is all you need"라는 제목의 논문이 나올 정도로, 다중 에이전트 시스템(Multi-Agent System, MAS)에 대한 기대가 높았죠.

그런데 Google Research와 MIT 연구진이 이에 의문을 제기하는 연구 결과를 발표했습니다. "Towards a Science of Scaling Agent Systems"라는 제목의 이 논문은, 다중 에이전트 시스템이 특정 조건에서는 성능을 크게 끌어올리지만, 그렇지 않은 경우에는 오히려 비용과 오류만 키울 수 있다는 것을 정량적으로 보여줍니다.

왜 이 연구가 필요했나?

Agent Scaling across model intelligence and system architectures.

AI 에이전트란 LLM 기반으로 추론(Reasoning), 계획(Planning), 행동(Acting)을 반복적으로 수행하면서 환경이나 도구의 피드백에 따라 행동을 조정하는 시스템을 말합니다. 코드 생성, 웹 브라우징, 의료 의사결정, 금융 분석, 과학적 발견 등 다양한 분야에서 활용되고 있죠.

과제가 복잡해질수록 업계는 다중 에이전트 시스템(MAS)에 주목해왔습니다. 전문화된 에이전트들이 협업하면 단일 에이전트보다 더 나은 성능을 낼 것이라는 전제 하에요.

하지만 문제가 있었습니다.

"언제 에이전트를 추가하면 성능이 좋아지고, 언제 나빠지는가?"에 대한 정량적 기준이 없었습니다
기존 MAS 평가들은 서로 다른 프롬프트, 도구, 연산 예산을 사용해 공정한 비교가 어려웠습니다
최종 정확도만 측정하고, 조정 오버헤드, 오류 전파, 정보 흐름 같은 과정 역학은 분석되지 않았습니다

연구진은 이 gap을 메우기 위해 180개의 통제된 실험 설정을 구성하고, 에이전트 시스템의 스케일링 원리를 정량적으로 도출했습니다.

공정한 비교를 위한 철저한 통제

에이전트 아키텍처 정의

연구진은 먼저 단일 에이전트 시스템(SAS)과 다중 에이전트 시스템(MAS)을 명확하게 정의했습니다.

단일 에이전트 시스템(SAS)

하나의 LLM이 인식, 계획, 행동을 순차적으로 수행
도구 사용, 자기 성찰(self-reflection), Chain-of-Thought 추론을 사용하더라도 단일 의사결정 주체

다중 에이전트 시스템(MAS)

여러 LLM 기반 에이전트가 메시지 전달, 공유 메모리, 오케스트레이션 프로토콜을 통해 협업
네 가지 토폴로지로 구분:

아키텍처	설명	특징
Independent	에이전트들이 상호작용 없이 병렬 작업 후 결과 합성	최대 병렬화, 최소 조정
Decentralized	에이전트 간 직접 토론을 통해 합의 도출	P2P 정보 융합
Centralized	중앙 오케스트레이터가 하위 에이전트들을 조율	계층적 검증, 병목 가능성
Hybrid	계층적 통제 + 제한적 P2P 소통 결합	유연성과 통제의 균형

Independent (독립형)

각자 알아서 일하고, 마지막에 결과만 모으는 방식입니다. 에이전트끼리 대화가 없어서 빠르지만, 서로 뭘 하는지 모르니까 중복 작업이 생기거나 실수를 잡아주는 사람이 없습니다.
예) 학생 3명이 각자 조사해서 제출하면, 선생님이 그냥 합치는 조별과제

Centralized (중앙집중형)
팀장(오케스트레이터)이 있어서 일을 나눠주고, 결과를 검토하고, 최종 결정을 내립니다. 실수를 잡아낼 수 있지만, 모든 게 팀장을 거쳐야 해서 병목이 생길 수 있습니다.
예) 팀장이 업무 분배하고, 각 팀원 결과물을 검토해서 최종본 만드는 방식

Decentralized (분산형)
팀장 없이 에이전트들끼리 직접 토론하면서 합의를 도출합니다. 다양한 의견이 나올 수 있지만, 토론 시간이 오래 걸릴 수 있습니다.예) 팀원들끼리 회의하면서 서로 의견 조율해서 결론 내는 방식

Hybrid (하이브리드)
팀장도 있고, 팀원들끼리 소통도 하는 방식입니다. 가장 유연하지만, 그만큼 소통 비용이 제일 많이 듭니다.
예) 팀장이 전체 방향 잡아주면서, 팀원들도 서로 협의하는 방식

벤치마크 선정

연구진은 진정한 에이전틱(Agentic) 과제를 평가하기 위해 세 가지 필수 조건을 정의했습니다.

순차적 상호의존성: 이후 행동이 이전 관찰에 의존
부분 관찰 가능성: 핵심 정보가 숨겨져 있어 능동적 탐색 필요
적응적 전략 형성: 상호작용을 통해 얻은 새 증거에 따라 신념 업데이트

이 기준에 따라 네 가지 벤치마크를 선정했습니다.

벤치마크	과제 유형	특징
Workbench	코드 실행 및 도구 활용	명확한 성공/실패 기준, 결정론적
Finance Agent	금융 분석	다단계 정량 추론, 위험 평가
PlanCraft	Minecraft 환경 계획	제약 조건 하 시공간 계획
BrowseComp-Plus	웹 탐색 및 정보 추출	동적 상태 진화, 다중 페이지 종합

LLM 및 실험 설정

세 가지 LLM 패밀리에서 다양한 성능 수준의 모델을 평가했습니다.

OpenAI: GPT-5-nano, GPT-5-mini, GPT-5
Google: Gemini 2.0 Flash, 2.5 Flash, 2.5 Pro
Anthropic: Claude Sonnet 3.7, 4.0, 4.5

총 180개 실험 설정(5개 아키텍처 × 4개 벤치마크 × 9개 모델)에서 동일한 도구, 프롬프트, 토큰 예산을 적용하여 아키텍처 효과만 분리했습니다.

세 가지 지배적 패턴

Comparative performance of single-agent system (SAS) and multi-agent system (MAS) across four agentic benchmarks reveals highly task-dependent scaling dynamics.

1. 도구-조정 트레이드오프 (Tool-Coordination Trade-off)

도구가 많은 과제일수록 다중 에이전트 오버헤드로 인한 성능 저하가 심하다

연산 자원이 한정된 상황에서 에이전트 수를 늘리면, 각 에이전트가 활용할 수 있는 맥락 정보(토큰)가 줄어듭니다.

정량적 결과:

단일 에이전트: 효율성( ) = 0.466
다중 에이전트: 효율성 = 0.074 ~ 0.234 (2~6배 비효율적)
회귀 분석 결과: = −0.267, p < 0.001

특히 10개 이상의 도구를 사용하는 환경에서 이 효과가 두드러졌습니다. 에이전트가 늘어날수록 각자가 도구를 효과적으로 활용할 여력이 줄어들기 때문입니다.

2. 성능 포화 현상 (Capability Saturation)

단일 에이전트 성능이 ~45%를 넘으면, 에이전트 추가는 역효과

Cost–Performance Trade-offs Across Model Families and Architectures

단일 에이전트 기준선이 이미 45% 정확도를 넘는 과제에서는 조정 비용이 개선 가능성을 초과합니다.

정량적 결과:

회귀 계수: = −0.404, p < 0.001 (가장 큰 효과 크기)
임계값: 약 45% (표준화된 단위로 0.129)

이는 "이미 잘 작동하는 것에 에이전트를 추가하지 말라"는 실용적 지침을 제공합니다.

3. 아키텍처 의존적 오류 증폭 (Architecture-Dependent Error Amplification)

협업 구조에 따라 오류 증폭 정도가 4배에서 17배까지 차이

Coordination metrics across architectures and families ( = 180 configurations, 15,750 total instance runs). All systems matched for total reasoning tokens (mean = 4, 800 per trial)

아키텍처	오류 증폭률 ( )	설명
SAS	1.0×	기준선
Independent	17.2×	검증 메커니즘 없음, 오류 직접 전파
Decentralized	7.8×	P2P 토론으로 일부 검증
Centralized	4.4×	검증 병목이 오류 차단
Hybrid	5.1×	중간 수준

핵심 인사이트: Independent 아키텍처는 에이전트 간 소통이 없어 오류가 그대로 최종 결과로 전파됩니다. 반면 Centralized는 중앙에서 결과를 점검하는 단계가 있어 오류 전파를 억제합니다.

왜 같은 MAS가 다른 결과를 보이는가?

Finance Agent: MAS의 압도적으로 좋은 결과 (+57% ~ +81%)

금융 분석 과제에서는 모든 MAS 변형이 SAS를 크게 앞섰습니다.

Centralized: +80.8%
Decentralized: +74.5%
Hybrid: +73.1%

왜? 금융 분석은 자연스럽게 병렬 수행이 가능한 구조입니다.

Agent 1: 규제/뉴스 분석
Agent 2: SEC 공시 연구
Agent 3: 운영 영향 평가
Orchestrator: 다중 소스 발견 종합

각 하위 과제(매출 분석, 비용 구조, 시장 비교)를 독립적으로 수행한 후 종합할 수 있어, 조정 구조가 과제 구조와 정렬됩니다.

PlanCraft: MAS의 보편적으로 좋지 않은 결과 (−39% ~ −70%)

Minecraft 환경 계획 과제에서는 모든 MAS 방법이 성능 저하를 보였습니다.

Independent: −70.1%
Centralized: −50.3%
Decentralized: −41.5%
Hybrid: −39.1%

왜? PlanCraft는 엄격한 순차적 의존성을 가진 과제입니다. 예를 들어 diorite_wall을 제작하려면

Turn 1: search("diorite_wall") → 레시피: 6 diorite in 2x3
Turn 2: move(diorite → crafting_grid)
Turn 3: craft → 완료

이런 단순한 순차 과제를 MAS는 불필요하게 분해합니다.

Agent 1: 레시피 연구 (불필요 - 조회는 즉시 완료)
Agent 2: 인벤토리 확인 (불필요 - 상태는 모두에게 보임)
Agent 3: 제작 실행 (유일하게 필요한 단계)

이런 인위적인 분해가 조정 메시지를 오히려 대량 생성하고, 토큰을 추론이 아닌 조정에 소비하게 만듭니다.

BrowseComp-Plus: 제한적 개선 (+0.2% ~ +9.2%)

웹 탐색 과제에서는 개선이 미미했습니다.

Decentralized: +9.2%
Centralized: +0.2%

왜? 동적 웹 탐색은 Information gain(ΔI)이 불확실합니다. Finance Agent에서는 ΔI와 MAS-SAS 격차가 강한 상관관계(r = 0.71)를 보였지만, BrowseComp-Plus에서는 약한 상관관계(r = 0.18)만 나타났습니다. 에이전트들이 교환하는 메시지가 검증된 정보를 제공하기 어려운 것이죠.

Workbench: 미미한 효과 (−11% ~ +6%)

도구 실행 과제에서는 MAS의 효과가 거의 없었습니다. 여러 에이전트를 써서 얻는 이점만큼 조정 비용도 늘어나서, 결국 큰 차이가 나지 않은 것입니다.

GPT-5.2에서 확인

연구진은 연구 완료 후 출시된 GPT-5.2(Intelligence Index = 75)로 모델을 검증했습니다.

Out-of-sample validation metrics for GPT-5.2 on BrowseComp-Plus

연구에서 도출한 5가지 스케일링 원리 중 4가지가 GPT-5.2에서도 동일하게 적용되는 것을 확인했습니다. 성능 포화 현상, Independent 아키텍처의 성능 저하, Centralized/Decentralized의 우수성, Hybrid의 오버헤드 문제 등이 새로운 모델에서도 그대로 나타났습니다.

에이전트 수 스케일링: "4명의 법칙"

Number of agents scaling reveals model-dependent coordination limits

연구진은 에이전트 수(1~9명)에 따른 성능 변화도 분석했습니다. 결론부터 말하면, 에이전트는 3~4명이 최적입니다. 그 이상으로 늘리면 에이전트 간 소통 비용이 급격히 증가해서, 성능 향상보다 오버헤드가 더 커집니다. 실제로 Hybrid 시스템은 단일 에이전트보다 6.2배 더 많은 추론 턴이 필요했습니다.

더 비싼 모델이 항상 좋은가?

연구진은 서로 다른 성능의 모델을 섞어서 쓰면 어떻게 되는지도 테스트했습니다. 흥미롭게도, 비싼 모델을 모든 역할에 쓰는 것이 항상 좋은 건 아니었습니다. Anthropic 모델의 경우, 오케스트레이터에 저성능 모델을 쓰고 하위 에이전트에 고성능 모델을 쓴 조합이 전부 고성능 모델을 쓴 것보다 31% 더 좋은 결과를 보였습니다. 즉, 역할에 따라 적절한 모델을 배치하는 게 더 효과적입니다.

Anthropic 모델: 저능력 오케스트레이터 + 고능력 하위 에이전트(0.42)가 동질적 고능력(0.32)보다 31% 우수
Decentralized 혼합 능력: 거의 모든 모델 패밀리에서 동질적 고능력과 동등하거나 우수
Centralized: 오케스트레이터 능력보다 하위 에이전트 능력이 더 중요

LLM 패밀리별 특성

chmark-specific scaling dynamics across LLM families

각 LLM은 각각 잘 맞는 아키텍처가 달랐습니다. OpenAI는 Hybrid에서 강한 시너지를 보였고, Google은 어떤 아키텍처를 써도 성능 차이가 5% 미만으로 안정적이었습니다. Anthropic은 Centralized에서 가장 일관된 성능을 보였습니다. 즉, 어떤 모델을 쓰느냐에 따라 최적의 아키텍처도 달라질 수 있습니다.

언제, 어떤 아키텍처를 선택할 것인가?

연구진이 제시한 실용적 지침을 정리하면 다음과 같습니다.

1단계: 단일 에이전트 기준선 먼저 측정

단일 에이전트로 성능을 먼저 점검
정확도가 45%를 넘으면 에이전트 추가는 비용만 증가시킬 가능성 높음

2단계: 과제 특성 분석

과제 특성	권장 아키텍처
병렬 분해 가능 (금융 분석 등)	Centralized 또는 Decentralized
순차적 의존성 높음 (계획, 추론 등)	SAS 유지
다중 경로 탐색 필요 (웹 탐색 등)	Decentralized
높은 정확성/신뢰성 필요	Centralized (오류 억제)

3단계: 도구 수 고려

도구가 많을수록 → 단순한 아키텍처가 효과적
10개 이상 도구 → MAS 오버헤드가 이점을 상쇄

4단계: 에이전트 수 제한

3~4명이 최적
그 이상에서는 조정 오버헤드가 급증

아키텍처 선택 의사결정 경계

연구진이 도출한 정량적 기준

단일 에이전트 성능 < 45% → MAS 고려
단일 에이전트 성능 ≥ 45% → SAS 유지

여기서 45%는 해당 과제의 정확도(또는 성공률)를 의미합니다. 예를 들어 금융 분석 과제에서 단일 에이전트가 100개 중 45개 이상을 맞춘다면, 굳이 에이전트를 늘릴 필요가 없다는 뜻입니다. 이 임계값은 180개 실험 데이터에서 도출된 수치입니다.

한계점 및 향후 연구 방향

연구진은 다음 한계점을 인정했습니다.

에이전트 수 스케일링: 최대 9명까지만 테스트, 더 큰 집단에서의 창발적 행동은 미확인
모델 다양성: 동일 패밀리 내 다른 크기의 모델만 혼합, 근본적으로 다른 아키텍처 조합은 미탐구
도구 집약적 환경: 도구가 많은 환경을 위한 특화된 조정 프로토콜 개발 필요
프롬프트 최적화: 아키텍처별 프롬프트 튜닝은 수행하지 않음
벤치마크 범위: 4개 벤치마크로 제한, 구현된 에이전트나 다중 사용자 상호작용은 미포함

결론: "More Agents"가 아닌 "Right Agents"

이 연구는 "에이전트를 많이 쓰면 성능이 좋아진다"는 가정을 정량적으로 검증하고, 그것이 항상 참이 아님을 보여줬습니다.

핵심 메시지:

MAS 성능은 에이전트 수가 아닌 과제 특성과 아키텍처 정렬에 의해 결정됩니다
성능 범위: +80.9% (Finance Agent, Centralized) ~ −70.0% (PlanCraft, Independent)
도구가 많거나, 기준선이 높거나, 순차적 의존성이 있는 과제에서는 SAS가 우수
병렬 분해 가능하고 기준선이 낮은 과제에서는 Centralized/Decentralized가 효과적

연구진이 개발한 예측 모델은 과제의 특성만 보고도 87% 정확도로 최적 아키텍처를 예측할 수 있었습니다. 이제 "에이전트를 몇 개 쓸까?"가 아니라 "이 과제에 어떤 아키텍처가 맞을까?"를 먼저 고민해야 할 것 같습니다.

참고

Towards a Science of Scaling Agent Systems - arXiv

[ OCR ] Chandra OCR - 한글 테스트

Theo (테오) — Thu, 1 Jan 2026 00:29:11 +0900

밀린 숙제를 하듯 그동안 테스트해보고 싶었던 OCR 도구들을 하나씩 정리하고 있습니다. 이번에는 최근 벤치마크에서 1위를 기록한 Chandra를 테스트해 봤습니다.

Chandra는 Datalab에서 만든 OCR 모델로, 이미지와 PDF를 구조화된 HTML/Markdown/JSON으로 변환합니다. 특히 레이아웃 정보를 보존하면서 변환하는 것이 특징입니다.

GitHub - datalab-to/chandra: OCR model that handles complex tables, forms, handwriting with full layout.

OCR model that handles complex tables, forms, handwriting with full layout. - datalab-to/chandra

github.com

Chandra 주요 특징

Chandra는 Datalab에서 개발한 OCR 모델로, 같은 회사에서 만든 Marker(PDF to Markdown 변환 도구)와 Surya(OCR 모델)의 후속작입니다.

Markdown, HTML, JSON으로 변환 (레이아웃 정보 포함)
손글씨 지원
폼, 체크박스 정확하게 재구성
표, 수식, 복잡한 레이아웃 지원
이미지/다이어그램 추출 (캡션 포함)
40개 이상 언어 지원
두 가지 추론 모드: Local (HuggingFace), Remote (vLLM)

벤치마크 성능

olmocr bench 기준으로 Chandra는 83.1점으로 1위를 기록했습니다. 특히 Tables(88.0), Old Scans Math(80.3), Long tiny text(92.3) 항목에서 최고 점수를 받았습니다.

Model	ArXiv	Old Scans Math	Tables	Old Scans	Headers/ Footers	Multi column	Long tiny text	Base	Overall
Datalab Chandra v0.1.0	82.2	80.3	88.0	50.4	90.8	81.2	92.3	99.9	83.1
dots.ocr	82.1	64.2	88.3	40.9	94.1	82.4	81.2	99.5	79.1
olmOCR v0.3.0	78.6	79.9	72.9	43.9	95.1	77.3	81.2	98.9	78.5
Datalab Marker v1.10.0	83.8	69.7	74.8	32.3	86.6	79.4	85.7	99.6	76.5
Deepseek OCR	75.2	72.3	79.7	33.3	96.1	66.7	80.1	99.7	75.4
Mistral OCR API	77.2	67.5	60.6	29.3	93.6	71.3	77.1	99.4	72.0
GPT-4o (Anchored)	53.5	74.5	70.0	40.7	93.8	69.3	60.6	96.8	69.9
Qwen 3 VL 8B	70.2	75.1	45.6	37.5	89.1	62.1	43.0	94.3	64.6
Gemini Flash 2 (Anchored)	54.5	56.1	72.1	34.2	64.7	61.5	71.5	95.6	63.8

로컬 실행 시도

먼저 Google Colab에서 로컬 실행을 시도해 봤습니다.

# 설치
pip install chandra-ocr
pip install flash-attn --no-build-isolation

# 실행
chandra input.jpg ./output --method hf

모델 크기가 약 17GB라서 다운로드에 시간이 걸렸고, 막상 실행하니 CUDA 메모리 부족 에러가 발생했습니다. Colab 무료 버전의 T4 GPU(15GB)로는 부족했습니다. 로컬에서 실행하려면 최소 24GB 이상의 GPU 메모리가 필요해 보입니다.

Playground 테스트

다행히 Datalab에서 무료 Playground를 제공합니다. 로그인 없이 10페이지까지 테스트할 수 있습니다.

https://www.datalab.to/playground/documents/new

www.datalab.to

모드 선택

Playground에서는 세 가지 모드를 선택할 수 있습니다.

모드	설명	용도
Fast	가장 낮은 지연 시간	실시간 처리
Balanced	정확도와 지연 시간의 균형	대부분의 문서
Accurate	가장 높은 정확도	복잡한 문서

추가 기능

로그인 후 카드를 등록하면 $5 크레딧과 함께 추가 기능을 사용할 수 있습니다.

Track Changes (DOCX): MS Word의 변경 내용 추적 및 주석을 Markdown/HTML로 변환. 법률 검토 워크플로우에 유용
Chart Understand: 차트/그래프 데이터를 HTML 테이블로 변환. 투자 보고서나 컨설팅 문서에 유용
Segmentation: 문서 영역 분할
Extract: 특정 데이터 추출

테스트 결과

한글 문서로 테스트해 봤습니다.

테스트 이미지 1

테스트 이미지 2

테스트 이미지 3

속도

속도는 생각보다 빠르지 않았습니다. 이미지 한 장당 약 15초에서 1분 정도 걸렸습니다. Fast 모드라고 해서 확연히 빠른 것은 아니었고, 오히려 Fast가 Balanced보다 늦게 나온 적도 있었습니다. 서버 상태에 따라 달라지는 것 같습니다.

인식 품질

OCR 성능 자체는 매우 뛰어났습니다. 한글 인식도 잘 되었고, 테이블 구조도 정확하게 파악했습니다. 특히 복잡한 레이아웃의 문서에서 좋은 결과를 보여줬습니다.

로컬 설치 및 CLI 사용법

GPU 메모리가 충분하다면 로컬에서도 실행할 수 있습니다.

설치

# 설치
pip install chandra-ocr

# flash attention 설치 (권장)
pip install flash-attn --no-build-isolation

CLI 사용법

# HuggingFace 방식 (로컬 모델)
chandra input.pdf ./output --method hf

# vLLM 서버 방식
chandra input.pdf ./output --method vllm

# 디렉토리 전체 처리
chandra ./documents ./output --method hf

# 페이지 범위 지정 (PDF)
chandra input.pdf ./output --page-range "1-5,7,9-12"

# 이미지 추출 제외
chandra input.pdf ./output --no-images

vLLM 서버 실행

배치 처리나 프로덕션 환경에서는 vLLM 서버를 사용하는 것이 좋습니다.

# vLLM 서버 실행 (Docker)
chandra_vllm

# 환경 변수 설정
export VLLM_API_BASE=http://localhost:8000/v1
export VLLM_MODEL_NAME=chandra
export VLLM_GPUS=0

라이선스

Chandra의 라이선스는 두 가지로 나뉩니다.

코드: Apache 2.0
모델 가중치: OpenRAIL-M 수정 버전
- 연구, 개인 용도: 무료
- 펀딩/매출 $2M 이하 스타트업: 무료
- API와 경쟁적 사용: 불가
- 그 외 상업적 사용: 별도 라이선스 필요

결론

Chandra는 현재 벤치마크 기준으로 가장 뛰어난 OCR 모델 중 하나입니다. 특히 테이블, 수식, 복잡한 레이아웃 처리에서 강점을 보입니다. 한글 인식도 잘 됩니다.

다만 몇 가지 고려할 점이 있습니다.

리소스 요구량: 로컬 실행 시 약 17GB 모델 다운로드, 24GB 이상 GPU 메모리 필요
속도: Playground 기준 장당 15초~1분. 실시간 처리에는 부적합
라이선스: 상업적 사용 시 라이선스 확인 필요

참고 링크

[ OCR ] PaddleOCR 3.0 - PP-OCRv5, PaddleOCR-VL 한글 인식 테스트

Theo (테오) — Wed, 31 Dec 2025 22:35:10 +0900

2023년에 PaddleOCR을 소개한 적이 있습니다. 당시 PP-OCRv3 기준으로 한글 인식 성능이 꽤 괜찮았는데, 2025년 10월에 PaddleOCR 3.0이 출시되면서 많은 변화가 있었습니다. 이번 글에서는 새로운 라인업인 PP-OCRv5, PP-StructureV3, PaddleOCR-VL을 테스트해본 결과를 공유합니다.

GitHub - PaddlePaddle/PaddleOCR: Turn any PDF or image document into structured data for your AI. A powerful, lightweight OCR to

Turn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100+ languages. - PaddlePaddle/Paddl...

github.com

PaddleOCR 3.0 주요 변경점

PaddleOCR 3.0은 기존 PP-OCRv3에서 상당히 발전했습니다.

기능	설명	용도
PP-OCRv5	109개 언어 지원, 단일 모델로 다국어 인식	일반 텍스트 인식
PP-StructureV3	문서 레이아웃 분석, 테이블 인식, Markdown 변환	문서 구조 분석
PaddleOCR-VL	0.9B VLM 기반 문서 파싱	복잡한 문서 이해

설치

설치 방법이 기존과 조금 다릅니다. CUDA 버전에 맞는 PaddlePaddle을 설치해야 합니다. (CPU버전을 설치하여 테스트 해도 됩니다)

# CUDA 버전 확인
nvcc --version

# GPU 버전 (CUDA 12.x 기준)
pip install paddlepaddle-gpu -i https://www.paddlepaddle.org.cn/packages/stable/cu126/pip install "paddleocr[all]"

# CPU 버전
# pip install paddlepaddle
# pip install "paddleocr[all]"

PP-OCRv5 - 텍스트 인식

PP-OCRv5는 기존 PP-OCRv3의 후속 모델입니다. 가장 큰 변화는 단일 모델로 109개 언어를 지원한다는 점입니다. 모델 크기는 2M으로 경량화되었고, 이전 버전 대비 정확도가 13% 향상되었다고 합니다.

사용법

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    lang="korean",
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False
)

result = ocr.predict(input="test_image.jpg")

for res in result:
    res.print()
    res.save_to_img("output")
    res.save_to_json("output")

설명에는 언어 지정 없이도 다국어를 자동으로 인식한다고 되어 있지만 lang="korean" 을 지정하지 않으니 한글인식이 잘 되지 않아서 지정해야 합니다.

테스트 결과

전체적으로 양호한 결과를 보여줬습니다. 속도도 빠르고, 일부 오인식이 있었지만 전반적으로 괜찮았습니다. 기존 PP-OCRv3와 비교했을 때 체감상 큰 차이는 느끼지 못했지만, 다국어 혼합 문서에서는 확실히 편해졌습니다.

PP-StructureV3 - 문서 구조 분석

PP-StructureV3는 문서의 레이아웃을 분석하고 구조화된 데이터로 변환합니다. 텍스트, 표, 이미지, 수식 등 영역을 구분하고, Markdown이나 JSON 형식으로 변환할 수 있습니다.

사용법

from paddleocr import PPStructureV3

structure = PPStructureV3(
    lang="korean",
    use_doc_orientation_classify=False,
    use_doc_unwarping=False
)

result = structure.predict(input="test_image.jpg")

for res in result:
    res.print()
    res.save_to_img("output")
    res.save_to_json("output")
    res.save_to_markdown("output")

테스트 결과

솔직히 한글 문서에서는 결과가 좋지 않았습니다. 레이아웃 분석은 되는데 텍스트 인식 정확도가 떨어졌습니다. 영어나 중국어 문서에서는 잘 동작할 수 있지만, 한글 문서에는 PP-OCRv5나 PaddleOCR-VL을 사용하는 게 나을 것 같습니다.

PaddleOCR-VL - VLM 기반 문서 파싱

PaddleOCR-VL은 0.9B 파라미터의 Vision-Language Model을 기반으로 한 문서 파싱 모델입니다. 기존 파이프라인 방식(감지 → 인식)과 달리 End-to-End로 문서를 이해합니다.

주요 특징

0.9B 경량 VLM으로 비교적 빠른 추론
109개 언어 자동 인식 (별도 언어 설정 불필요)
header, table, text 등 영역 자동 구분
테이블을 HTML 형식으로 변환
손글씨, 역사 문서 등 다양한 문서 타입 지원

사용법

from paddleocr import PaddleOCRVL

ocr_vl = PaddleOCRVL()  # lang 파라미터 없음

result = ocr_vl.predict(input="test_image.jpg")

for res in result:
    res.print()
    res.save_to_img("output")
    res.save_to_json("output")
    res.save_to_markdown("output")

PP-OCRv5와 달리 lang 파라미터가 없습니다. VLM이 자동으로 언어를 인식합니다.

테스트 결과

결과는 꽤 인상적이었습니다. header, table, text 등이 자동으로 구분되어 나오고, 다국어 인식도 잘 되었습니다. 테이블은 HTML 형식으로 변환되어 구조가 그대로 유지됩니다.

다만 속도가 문제입니다. CPU로 돌리면 이미지 한 장당 약 10분 정도 걸렸습니다. GPU 환경에서 사용하는 것을 권장합니다. 일부 복잡한 이미지에서 누락이 있었지만, 일반적인 문서에서는 매우 뛰어난 성능을 보여줬습니다.

결론

PaddleOCR 3.0은 용도에 따라 세 가지 모델을 선택할 수 있게 되었습니다.

단순 텍스트 추출: PP-OCRv5 - 빠르고 가볍습니다
문서 구조가 중요한 경우: PaddleOCR-VL - GPU 환경에서 사용하세요
PP-StructureV3: 한글 문서에서는 아직 추천하기 어렵습니다

개인적으로는 일반적인 OCR 작업에는 PP-OCRv5, 테이블이 포함된 복잡한 문서에는 PaddleOCR-VL을 사용할 것 같습니다. GPU 환경만 갖춰진다면 PaddleOCR-VL의 결과물이 가장 만족스러웠습니다.

전체 테스트 코드는 Colab 노트북으로 공유합니다.

Claude Agent Skills: AI를 나만의 전문가로 만드는 방법

Theo (테오) — Tue, 30 Dec 2025 15:03:06 +0900

2025년 10월 16일, Anthropic이 Claude AI에 Agent Skills 기능을 추가했습니다. AI 에이전트에게 특정 업무를 전문적으로 수행할 수 있는 능력을 부여하는 기능으로, Claude를 맞춤형 전문 비서처럼 활용할 수 있게 해 줍니다.

Equipping agents for the real world with Agent Skills

Discover how Anthropic builds AI agents with practical capabilities through modular skills, enabling them to handle complex real-world tasks more effectively and reliably.

www.anthropic.com

Agent Skills란?

Agent Skills는 Claude에 필요한 기능을 추가할 수 있는 확장 패키지입니다. 지시 사항, 메타데이터, 스크립트, 리소스를 패키지로 묶어서 Claude가 특정 작업을 자동으로 수행할 수 있게 합니다. 쉽게 말하면, Claude에게 특정 업무를 잘하도록 알려주는 교육 자료나 매뉴얼입니다.

회사로 비유하자면..

기존 Claude는 신입 사원과 비슷합니다. 매번 같은 지시를 반복해야 하고, "어떤 형식으로 만들어 드릴까요?", "어떤 섹션이 필요한가요?" 같은 질문을 계속 받습니다. 새 대화를 시작할 때마다 처음부터 설명해야 하죠.

Skills를 장착한 Claude는 숙련된 직원에 가깝습니다. 회사의 업무 프로세스와 규정을 이미 파악하고 있어서, 간단한 지시만으로도 정확하고 일관된 결과물을 만들어냅니다. 한번 가르쳐 주면 계속 기억해서 꺼내 쓸 수 있습니다.

Agent Skills의 세 가지 핵심 장점

첫째, Claude를 전문화할 수 있습니다. 도메인별 특화된 역량을 부여해서 전문가처럼 활용할 수 있고, 브랜드 가이드라인이나 특정 프로젝트에 맞게 대응할 수 있습니다.
둘째, 반복 작업을 줄입니다. 한 번 만들어두면 계속 활용할 수 있어서, "A 스킬로 이걸 해줘", "B 스킬로 저걸 해줘"처럼 간단하게 요청할 수 있습니다.
셋째, 여러 스킬을 조합할 수 있습니다. 데이터 분석, 보고서 작성, 시각화 스킬을 동시에 사용해서 복잡한 워크플로우를 구축할 수 있습니다.

Skills의 작동 원리: 점진적 공개 방식

Agent Skills는 점진적 공개(Progressive Disclosure) 방식으로 세 단계에 걸쳐 작동합니다.

1단계 - 인식(Discovery): Claude가 시작할 때 모든 스킬의 이름과 설명만 로드합니다. 게임에서 스킬 창에 어떤 스킬이 있는지 아는 것과 비슷합니다. 파이어볼, 아이스볼이 있다는 건 알지만 아직 사용하지 않은 상태입니다.
2단계 - 활성화(Activation): 사용자의 요청이 특정 스킬과 관련되면 해당 스킬이 발동됩니다. "매출 데이터를 PPT로 만들어줘"라고 요청하면 PPT 스킬이 자동으로 활성화됩니다.
3단계 - 실행(Execution): 스킬의 상세 지침과 리소스를 불러와 실제 작업을 수행합니다. PPT 구성 방법, 적용할 디자인, 데이터 시각화 방식 등 모든 정보가 이 단계에서 적용됩니다.

이 방식 덕분에 토큰 사용량이 효율적이고, 필요한 순간에만 관련 컨텍스트를 불러오므로 빠르고 정확하게 작동합니다.

Skills vs MCP vs 커스텀 인스트럭션

세 가지 기능의 차이는 다음과 같습니다.

Skills는 특정 작업에 특화된 전문성입니다. PPT 작성, 데이터 분석, 보고서 생성 등 명확한 업무를 자동화하는 데 적합합니다. 관련 작업 시 자동으로 발동되며, 토큰 효율성이 높습니다.
MCP(Model Context Protocol)는 외부 시스템과의 연결입니다. 노션, Gmail, Google Drive 등 외부 도구와 연동해서 데이터를 가져오거나 작업을 수행합니다. 외부 도구 호출 시에만 명시적으로 사용됩니다.
커스텀 인스트럭션은 모든 대화에 적용되는 전체 공통 설정입니다. "항상 한국어로 답변해 줘", "간결하게 답변해줘" 같은 패시브 스킬이라고 보면 됩니다.

세 가지를 함께 사용하면 시너지가 납니다. MCP로 외부 데이터를 가져오고, Skills로 해당 데이터를 처리하고, 커스텀 인스트럭션으로 일관된 스타일을 유지하는 워크플로우를 구축할 수 있습니다.

스킬의 종류

내장 스킬 (Anthropic Skills)

별도 설정 없이 바로 사용할 수 있는 기본 제공 기능입니다. 엑셀(xlsx), 워드(docx), 파워포인트(pptx), PDF 처리 스킬이 포함되어 있어 문서 작업을 바로 시작할 수 있습니다.

커스텀 스킬 (Custom Skills)

사용자가 직접 만드는 맞춤형 스킬입니다. 회사의 보고서 양식, 브랜드 가이드라인, 특정 분석 프로세스 등을 스킬로 만들어 반복적으로 활용할 수 있습니다.

스킬 활성화 방법

Agent Skills는 Claude Pro 이상 유료 구독자가 사용할 수 있습니다. 활성화 순서는 다음과 같습니다.

Claude.ai에 로그인합니다
왼쪽 아래의 사용자 이름을 클릭하고 설정으로 들어갑니다
기능(Features) 탭에서 Code Execution and File Creation을 활성화합니다
아래에 각종 스킬들이 나타납니다

스킬 크리에이터(Skill Creator)를 켜두면 대화를 통해 새로운 스킬을 만들 수 있습니다.

스킬의 기본 구조

스킬은 폴더 형태로 구성되며, 핵심은 SKILL.md 파일입니다.

my-skill/
├── SKILL.md          # 필수: 지침 + 메타데이터
├── scripts/          # 선택: 실행 가능한 코드
├── references/       # 선택: 참조 문서
└── assets/           # 선택: 템플릿, 리소스

SKILL.md 파일은 YAML 프론트매터와 마크다운 본문으로 구성됩니다.

---
name: monthly-sales-report
description: 월간 매출 데이터를 분석하고 보고서를 생성합니다.
---

# 월간 매출 보고서 생성기

## 이 스킬을 사용할 때
사용자가 매출 데이터 분석이나 보고서 작성을 요청할 때...

## 작업 순서
1. 데이터 파일 확인
2. 주요 지표 분석
3. 차트 생성
4. 보고서 작성

name은 스킬 이름으로 최대 64자까지 가능하며, 영문 소문자와 하이픈만 사용할 수 있습니다. description은 스킬을 언제 사용할지에 대한 설명으로, Claude가 이 설명을 보고 적절한 상황에서 스킬을 발동시킵니다.

커스텀 스킬 만드는 두 가지 방법

방법 1: 대화로 스킬 만들기 (초보자 추천)

스킬 크리에이터를 활성화한 후, Claude에게 직접 요청하면 됩니다. "우리 회사 브랜드 가이드라인 스킬을 만들고 싶어. 도와줘"라고 하면, Claude가 필요한 정보를 물어보고 스킬을 자동으로 생성합니다.

브랜드 색상, 톤 앤 매너, 주요 용어 등을 대화로 정의하면, Claude가 이를 바탕으로 스킬 파일을 만들어줍니다. 코딩 지식이 없어도 충분히 만들 수 있습니다.

방법 2: 직접 작성하여 업로드하기

SKILL.md 파일을 직접 작성하고, zip으로 압축한 후 업로드합니다. 설정의 기능 탭에서 스킬 업로드 버튼을 클릭하고 압축 파일을 드래그하면 됩니다.

직접 작성이 어렵다면, 한글로 스킬 내용을 정리한 후 Claude에게 "이 내용을 스킬 양식에 맞게 작성해 줘"라고 요청하면 적절한 형식으로 변환해 줍니다.

활용 사례

PPT 자동 생성

매출 데이터 파일을 업로드하고 "이 데이터로 월간 매출 보고서 PPT를 만들어줘"라고 요청하면, Claude가 PPT 스킬을 자동으로 발동시켜 프레젠테이션을 생성합니다. 다운로드 가능한 PPTX 파일로 제공되어 바로 파워포인트에서 열 수 있습니다.

브랜드 가이드라인 적용

회사의 브랜드 색상, 폰트, 톤 앤 매너를 스킬로 정의해 두면, 이후 모든 콘텐츠 제작에 일관된 브랜드 아이덴티티가 적용됩니다. "인스타그램 카드뉴스 만들어줘"라고만 해도 브랜드 가이드라인에 맞는 디자인이 나옵니다.

정기 보고서 자동화

매주 또는 매월 작성하는 정형화된 보고서가 있다면, 해당 양식을 스킬로 만들어두세요. 데이터만 제공하면 동일한 형식의 보고서가 자동으로 생성됩니다.

Claude Code에서의 활용

개발자라면 Claude Code에서 Skills를 더 강력하게 활용할 수 있습니다. .claude/skills/ 폴더에 스킬을 정의하면, 해당 프로젝트에서 자동으로 인식됩니다.

보안 주의사항

Skills를 사용할 때 몇 가지 보안 사항을 염두에 두어야 합니다.

신뢰할 수 있는 소스의 스킬만 사용하세요
외부에서 가져온 스킬은 코드 내용을 반드시 검토해야 합니다
외부 네트워크 연결이 포함되어 있는지 확인하세요
API 키나 비밀번호 같은 민감한 정보는 스킬에 포함시키지 마세요

성공적인 스킬 작성을 위한 팁

작게 시작하세요. 처음부터 복잡한 스킬을 만들기보다, 간단한 스킬부터 만들어보면서 감을 익히는 게 좋습니다.
명확한 목적을 가지세요. 하나의 스킬에는 하나의 명확한 목적만 담아야 합니다. 여러 기능을 하나의 스킬에 넣으면 오히려 정확도가 떨어집니다.
지속적으로 개선하세요. 스킬을 사용하면서 부족한 부분이 발견되면 계속 업데이트하세요. 스킬 파일은 버전 관리가 가능하므로 팀과 공유하며 함께 발전시킬 수 있습니다.

참고

https://agentskills.io - Agent Skills 공식 문서 사이트 (스펙, 통합 가이드, 베스트 프랙티스 등)
https://github.com/anthropics/skills - Anthropic의 공식 예제 스킬 저장소
https://github.com/agentskills/agentskills - skills-ref 레퍼런스 라이브러리 (스킬 검증, 프롬프트 XML 생성 도구)
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview - Claude 공식 문서 (Skills 섹션 포함)

Gartner Top 10 Strategic Technology Trends for 2026

Theo (테오) — Sun, 28 Dec 2025 11:53:30 +0900

안녕하세요, 정말 오랜만에 글을 씁니다.

지난 몇 개월간 너무 바쁜 일정 속에 블로그 작성을 못했는데요. 그 사이 다루고 싶은 주제가 정말 많았습니다. 하나하나 정리해서 공유하고 싶었지만, 바쁜 일상에 치여 그냥 넘어가는 경우가 많았습니다.

그래서 다시 시작하는 첫 번째 글로, 매년 빠지지 않고 다뤘던 가트너 10대 전략 기술 트렌드를 선택했습니다.

글로벌 연구 조사 기업 '가트너(Gartner)'에서는 매년 주요 전략적 기술 트렌드를 발표하여, 가까운 미래에 대한 인사이트를 제공합니다. 지난 10월, 가트너 IT 심포지엄/Xpo에서 2026년 트렌드가 발표되었는데요. 이번 글에서는 가트너가 주목하는 2026년 10대 전략 기술 트렌드를 살펴보고자 합니다.

2025년 회고하기

미래 예측을 살펴보기에 앞서, 가트너에서 발표한 2025년 예측은 얼마나 주효했는지 되짚어 보려 합니다.

2025년 전망에서 가트너는 10개의 주요 기술 중 9개가 AI와 직간접적으로 연관되어 있다고 발표했습니다. 에이전트 AI, AI 거버넌스 플랫폼, 공간 지능, 다기능 로봇 등 AI가 거의 모든 기술 트렌드를 주도할 것이라 예측했는데요.

실제로 2025년은 AI 에이전트의 원년이라 할 만큼, 자율적으로 업무를 처리하는 AI 시스템이 본격적으로 등장했습니다. OpenAI의 Operator, Anthropic의 Computer Use, Google의 Mariner 등 주요 AI 기업들이 앞다투어 에이전트 기반 서비스를 선보였죠.

또한 허위정보 보안(Disinformation Security)의 중요성도 현실화되었습니다. 딥페이크와 AI 생성 콘텐츠가 급증하면서, 디지털 콘텐츠의 진위 여부를 검증하는 기술에 대한 수요가 폭발적으로 증가했습니다.

2026 트렌드 미리 보기

이제 2026년 트렌드를 살펴볼 텐데요. 세부적인 전략을 살펴보기 앞서, 2026년 가트너 발표에서 두드러지는 내용을 정리해 봤습니다.

1) AI는 더 이상 선택이 아닌 필수

가트너의 Gene Alvarez 부사장은 "2026년은 혼란, 혁신, 위험이 전례 없는 속도로 확대되는 결정적인 해"라고 강조했습니다. AI가 더 이상 '도입을 고려하는 기술'이 아닌, 기업 생존을 위한 필수 요소로 자리 잡았다는 의미입니다.

2) 세 가지 테마로 구분

2026년 트렌드는 기존과 달리 명확한 세 가지 테마로 구분됩니다.

The Architect (설계자): 안전하고 확장 가능한 디지털 기반 구축
The Synthesist (통합자): 다양한 기술을 조합하여 새로운 가치 창출
The Vanguard (선봉대): 신뢰, 거버넌스, 보안 강화

3) 혁신의 속도가 다르다

Tori Paulman VP 분석가는 "올해 특별히 다른 점은 속도입니다. 단 1년 만에 그 어느 때보다 많은 혁신이 등장했습니다"라고 언급했습니다. 다음 혁신의 물결이 몇 년 뒤가 아닌 바로 눈앞에 있다는 것이죠.

2026년 전략 기술 트렌드 10

본격적으로 2026년 전략 기술 트렌드에 대해 하나씩 살펴보도록 하겠습니다.

The Architect: 안전하고 확장 가능한 기반 구축

1) AI 네이티브 개발 플랫폼 (AI-Native Development Platforms)

AI는 이미 수년간 소프트웨어 개발 프로세스에 깊숙이 자리 잡아왔지만, 최근 도구의 성숙도가 높아짐에 따라 채택 속도가 더욱 빨라지고 있습니다.

AI 네이티브 개발 플랫폼은 생성형 AI를 활용하여 소프트웨어를 더 빠르고 쉽게 개발할 수 있게 해주는 플랫폼입니다. 대규모 개발 인력 대신 고효율 소규모 팀이 엔터프라이즈급 애플리케이션을 빠르게 생산하는 시대가 도래하고 있습니다.

가트너 전망: 2030년까지 조직의 80%가 AI 네이티브 개발 플랫폼을 도입

2) AI 슈퍼컴퓨팅 플랫폼 (AI Supercomputing Platforms)

생성형 AI의 폭발적 확산으로 연산 수요가 급증하면서, 이를 뒷받침할 고성능 인프라의 중요성이 더욱 부각되고 있습니다.

AI 슈퍼컴퓨팅 플랫폼은 CPU, GPU, AI 전용 반도체(ASIC), 뉴로모픽 및 대안적 컴퓨팅 패러다임을 통합하여 복잡한 워크로드를 처리하는 구조입니다. 머신러닝, 시뮬레이션, 분석 등 데이터 집약적 작업을 처리할 수 있죠.

[이미지 삽입 위치: AI 슈퍼컴퓨팅 플랫폼 구조도]

다양한 산업에서 이미 혁신을 촉진하고 있습니다.

헬스케어/바이오텍: 신약 개발 기간을 몇 년에서 몇 주로 단축
금융 서비스: 글로벌 시장 리스크 분석 및 포트폴리오 최적화
에너지 산업: 극한 기상 모델링 및 전력망 최적화

가트너 전망: 2028년까지 주요 기업의 40% 이상이 핵심 비즈니스 워크플로에 하이브리드 컴퓨팅 패러다임을 도입 (현재 8%에서 증가)

3) 컨피덴셜 컴퓨팅 (Confidential Computing)

컨피덴셜 컴퓨팅은 데이터를 암호화된 상태로 처리할 수 있게 해주는 차세대 보안 솔루션입니다.

하드웨어 기반의 신뢰 실행 환경(TEE, Trusted Execution Environment)을 통해 데이터가 사용 중에도 보호됩니다. 인프라 소유자, 클라우드 제공업체, 또는 하드웨어에 물리적으로 접근할 수 있는 누구에게도 콘텐츠와 워크로드가 비공개로 유지되죠.

규제가 강한 산업, 지정학적 리스크에 직면한 글로벌 운영, 심지어 경쟁사 간 협업에서도 매우 중요한 기술입니다.

가트너 전망: 2029년까지 신뢰할 수 없는 인프라에서 처리되는 작업의 75% 이상이 컨피덴셜 컴퓨팅 기반으로 전환

The Synthesist: 새로운 가치 창출을 위한 기술 통합

4) 다중 에이전트 시스템 (Multiagent Systems, MAS)

다중 에이전트 시스템은 여러 AI 에이전트가 각자의 역할을 수행하며 협력해 복잡한 목표를 달성하는 체계입니다.

마치 전문가 팀이 각자의 역할을 나눠 하나의 프로젝트를 완수하는 것처럼, AI 에이전트들이 자율적으로 정보를 교환하며 문제를 해결합니다. 에이전트는 단일 환경에서 제공되거나 분산 환경 전반에 걸쳐 독립적으로 개발 및 배포될 수 있습니다.

Gene Alvarez 부사장에 따르면, "다중 에이전트 시스템을 도입하면 조직은 복잡한 비즈니스 프로세스를 자동화하고, 팀의 역량을 강화하며, 사람과 AI 에이전트가 함께 일하는 새로운 방식을 만들 수 있습니다"라고 합니다.

주요 장점:

모듈화 되고 재사용 가능한 에이전트로 효율성 향상
입증된 솔루션을 워크플로 전반에 재사용하여 리스크 감소
운영 확장 및 변화에 빠른 적응 가능

가트너 전망: 2028년까지 대부분의 MAS가 멀티벤더 상호운용성을 지원하여 서로 다른 제공업체의 에이전트가 원활하게 협력 가능

5) 도메인 특화 언어 모델 (Domain-Specific Language Models, DSLM)

범용 대규모 언어 모델(LLM)은 특정 산업의 세부적인 요구사항을 충족시키기 어려운 한계가 있습니다.

DSLM은 특정 산업, 기능, 업무 프로세스의 데이터로 학습 또는 미세 조정된 모델로, 금융, 의료, 법률, 공급망 등 전문 분야에서 높은 정확도, 낮은 비용, 향상된 규정 준수를 제공합니다.

주요 장점:

산업별 맥락, 용어, 의도를 진정으로 이해
범용 LLM 대비 비용 효율적
규제 및 거버넌스 준수 강화

가트너 전망: 2028년까지 기업 내 생성형 AI 모델의 절반 이상이 도메인 특화 모델로 전환

6) 피지컬 AI (Physical AI)

피지컬 AI는 로봇, 드론, 스마트 장비 등 물리적 환경에서 감지, 결정, 행동, 학습을 수행하는 AI 기반 지능형 시스템을 의미합니다.

자동화와 안전성을 중시하는 제조, 물류, 의료 등의 산업에서 생산성 향상 및 비용 절감 효과를 기대할 수 있습니다.

피지컬 AI 도입이 확대됨에 따라, IT, 운영, 엔지니어링을 유기적으로 연결하는 새로운 역량을 갖추게 될 것으로 보입니다. 가트너는 이러한 변화가 기술 강화와 협업 기회를 제공하는 동시에 고용 불안을 야기할 수 있어 신중한 변화 관리가 필요하다고 제언했습니다.

The Vanguard: 신뢰, 거버넌스, 보안 강화

7. 선제적 사이버 보안 (Preemptive Cybersecurity)

사이버 위협이 급증하면서, 공격이 발생하기 전 대응하는 보안 전략이 주목받고 있습니다.

선제적 사이버 보안은 AI 기반 보안 솔루션으로 미리 위협을 탐지하고 차단하는 능동형 보안 전략입니다. Tori Paulman VP 분석가는 "선제적 사이버 보안은 AI 기반 보안 운영, 프로그래밍 방식의 거부 및 기만을 통해 공격자가 공격하기 전에 행동하는 것입니다. 이것은 예측이 곧 보호인 세상입니다"라고 설명했습니다.

가트너 전망: 2030년까지 전체 보안 예산의 절반 이상이 선제적 사이버 보안에 투입 (2024년 5% 미만에서 증가)

8) 디지털 출처 (Digital Provenance)

AI가 만든 콘텐츠, 외부 소프트웨어 등의 사용이 증가하면서 '디지털 출처 검증'의 중요성이 커지고 있습니다.

디지털 출처는 소프트웨어, 데이터, 미디어, 프로세스의 원본, 소유권, 무결성을 검증하는 능력을 의미합니다. 소프트웨어 자재 명세서(SBoM), 증명 데이터베이스, 디지털 워터마크 등을 활용해 공급망 전반에서 디지털 자산을 추적하고 검증합니다.

가트너 전망: 2029년까지 디지털 출처 역량에 투자하지 않는 기업은 수십억 달러에 달하는 규정 준수 및 제재 리스크에 직면할 수 있음

9. AI 보안 플랫폼 (AI Security Platforms)

AI 활용이 확대되면서, 보안 위협 역시 AI 기반으로 고도화되고 있습니다.

AI 보안 플랫폼은 프롬프트 인젝션(명령어 공격), 데이터 유출, 악성 에이전트 활동 등 AI 관련 보안 위협을 방어하는 통합 보안 체계입니다. 서드파티 및 맞춤형 AI 애플리케이션 전반에 걸쳐 가시성과 통제를 중앙 집중화합니다.

가트너 전망: 2028년까지 기업의 절반 이상이 AI 투자를 보호하기 위해 AI 보안 플랫폼 도입

10. 지오패트리에이션 (Geopatriation)

지정학적 리스크로 인해 기업 데이터와 애플리케이션을 글로벌 퍼블릭 클라우드에서 자국 또는 지역 클라우드로 이전하는 현상이 가속화되고 있습니다.

과거 정부나 금융기관에 국한됐던 주권형 클라우드가 글로벌 불안정성과 규제 강화로 인해 일반 기업으로 확산되고 있습니다.

Gene Alvarez 부사장에 따르면, "주권 태세가 강화된 제공업체로 워크로드를 전환하면 CIO는 데이터 거주지, 규정 준수, 거버넌스에 대한 더 많은 통제권을 확보할 수 있습니다"라고 합니다.

가트너 전망: 2030년까지 유럽 및 중동 기업의 75% 이상이 지정학적 리스크를 줄이기 위해 가상 워크로드를 지오패트리에이션 (2025년 5% 미만에서 증가)

2024 → 2025 → 2026: 트렌드의 진화

3년간의 가트너 트렌드를 살펴보면, 흥미로운 진화 패턴을 발견할 수 있습니다.

영역	2024년	2025년	2026년
AI 개발	AI 증강 개발	에이전트 AI	다중 에이전트 시스템
AI 보안	AI TRiSM	AI 거버넌스 플랫폼	AI 보안 플랫폼
컴퓨팅	산업 클라우드 플랫폼	하이브리드 컴퓨팅	AI 슈퍼컴퓨팅 플랫폼
물리적 AI	증강-연결된 인력	다기능 로봇	피지컬 AI
보안	CTEM	허위정보 보안	선제적 사이버 보안

핵심 시사점

AI가 단독에서 협업으로: 단일 AI에서 다중 에이전트 협업 시스템으로 진화
보안의 선제적 전환: 대응형에서 예측·예방형 보안으로 전환
물리적 세계와의 융합: 디지털 AI가 물리적 세계로 확장

마치며

지금까지 가트너에서 제시한 2026년 전략 기술 트렌드에 대해 알아봤습니다. 가트너에서는 이 10가지 기술 트렌드를 'The Architect(설계자)', 'The Synthesist(통합자)', 'The Vanguard(선봉대)'라는 카테고리로 묶어 설명합니다.

2026년 트렌드에서 가장 눈에 띄는 점은 AI가 더 이상 선택이 아닌 필수가 되었다는 것입니다. 단순히 AI를 도입하는 것을 넘어, 어떻게 안전하게 확장하고, 다양한 에이전트를 조율하며, 신뢰와 거버넌스를 확보할 것인지가 핵심 과제가 되었습니다.

Tori Paulman VP 분석가의 말처럼, "다음 혁신의 물결은 몇 년 뒤가 아닙니다. 지금 행동하는 조직만이 변동성을 견딜 뿐만 아니라 향후 수십 년간 자신의 산업을 형성할 것입니다."

기술 환경이 빠르게 변화하는 만큼, 이러한 트렌드를 주시하며 변화에 유연하게 대응하는 전략을 수립하는 것이 더욱 중요해질 것입니다.

참고

Gartner Top 10 Strategic Technology Trends for 2026

[ 2025년 06월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Mon, 26 May 2025 23:25:45 +0900

2025년 6월 IT 세미나

1. WWDC25

일시: `25.06.09(월) - 06.13(금) (태평양 연안 표준시)
장소: 캘리포니아, 온라인
주최/주관/후원: Apple

https://developer.apple.com/kr/wwdc25/

WWDC25

전 세계 개발자 커뮤니티와 함께 일주일 동안 기술 및 창의성을 주제로 놀랍고 다양한 온라인 활동에 참여해 보세요.

developer.apple.com

[ 2025년 05월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Mon, 26 May 2025 23:20:38 +0900

2025년 5월 IT 세미나

1. AWS Summit Seoul 2025

일시: `25.05.14(수) - 05.15(목) 10:00 - 18:00
장소: 코엑스 컨벤션 센터
주최/주관/후원: AWS
비고: 무료 (사전등록, 현장등록)

AWS Summit Seoul

기술 혁신의 최전선에 있는 AWS 서비스와 생성형 AI를 중심으로 변화하는 시대를 조망하는 기조연설을 준비했습니다. 비즈니스의 새로운 혁신을 가져올 수 있는 주요 산업별 성공 사례와 신기술

aws.amazon.com

2. AI EXPO KOREA 2025 (국제인공지능대전)

일시: `25.05.14(수) - 05.16(금) 10:00 - 17:00
장소: 코엑스 1층 Hall A
주최/주관/후원 : (사)한국인공지능협회

AI EXPO KOREA 2025 국제인공지능대전

hn.micen.kr

3. Google I/O 2025

일시: `25.05.20(화) - 05.21(수)
장소: 샌프란시스코, 온라인
주최/주관/후원 : Google

Google I/O 2025

Solve the I/O puzzle Guide, reflect, and split beams of light to illuminate beacons and advance through new challenges. Get started

io.google

4. KCD Seoul 2025

일시: `25.05.22(목) 10:00 - 18:00
장소: 슈피겐HQ A동 지하2층
주최/주관/후원 : Kubernetes Korea group

KCD Seoul 2025 | CNCF

In-person Event - Hello, Cloud Native & AI!2025 Kubernetes Community Day Seoul이 여러분을 찾아옵니다!올해도 Kubernetes와 CNCF 프로젝트를 중심으로 한 기술 행사가 개최됩니다....

community.cncf.io

[ 2025년 04월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Mon, 26 May 2025 23:04:40 +0900

2025년 4월 IT 세미나

1. Cisco Connect 2025 Korea

일시: `25.04.03(목) 09:00 - 18:00
장소: 그랜드인터컨티넨탈 서울 파르나스 그랜드볼룸(5층)
주최/주관/후원: Cisco

Cisco Connect 2025 Korea

바야흐로 AI 시대, 급변하는 시장에서 도태되지 않고 경쟁 우위를 선점하며 지속적인 성과를 만들어 내기 위해서는 AI 기반으로 인프라와 데이터를 서로 연결할 뿐만 아니라 조직을 보호하는 방

www.cisco.com

2. Brity Automation Summit 2025

일시: `25.04.04(금) 13:30 - 17:00
장소: 삼성SDS 마젤란홀
주최/주관/후원 : 삼성SDS

Brity Automation Summit 2025 | 삼성SDS

lp.mkt-email.samsungsds.com

3. Unite Seoul 2025

일시: `25.04.15(화) 10:00 - 18:00
장소: 코엑스 그랜드볼룸/아셈볼룸
주최/주관/후원 : Unite
비고: 유료 (70,000원)

Unite Seoul 2025

유나이트 서울, Unite Seoul, 유나이트 서울 2025

uniteseoul.co.kr

4. World IT Show 2025

일시: `25.04.24(목) - 04.26(토) 10:00 - 17:00
장소: 코엑스
주최/주관/후원 : 과학기술정보통신부
비고: 유료 (10,000원)

IT전시회 World IT Show

국내 최대 규모 IT전시회 4월 코엑스 개최

www.worlditshow.co.kr

5. kt cloud:summit 2025

일시: `25.04.30(수) 09:30 - 18:00
장소: 코엑스
주최/주관/후원 : kt cloud

kt cloud summit 2025

자세한 내용은 여기를 눌러 확인하세요

summit.ktcloud.com

[ 2025년 03월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Mon, 26 May 2025 22:47:57 +0900

2025년 3월 IT 세미나

1. JetBrains Executive Summit 서울

일시: `25.03.11(화) 13:00 - 17:00
장소: 성령빌딩
주최/주관/후원: 서울특별시/서울AI허브

JetBrains Executive Summit 서울 · Luma

3월 11일 (화) 오후 1시, 단군소프트에서 열리는 JetBrains Executive Summit 서울에 초대합니다. 전 세계 기업의 개발 인프라가 빠르게 변화하고 있습니다. 더 강력한 보안, 더 효율적인 비용 관리, 더 빠

lu.ma

2. 2025 인터넷서비스 트렌드 컨퍼런스

일시: `25.03.12(수) - 03.13(목) 10:00 - 17:00
장소: 포스코타워역삼 이벤트홀
주최/주관/후원: (사)한국인터넷전문가협회, 아이어워즈위원회

(사)한국인터넷전문가협회 : 2025 인터넷서비스 트렌드 컨퍼런스

2025 인터넷서비스 트렌드 컨퍼런스 주제 : 아이어워즈 2024 수상작들을 중심으로 인터넷서비스 트렌드 분석 및 전망 --> 세미나 신청내역 보기  --> 세미나/컨퍼런스 소개 사단법인 한국인터

www.kipfa.or.kr

[ 2025년 02월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Sun, 9 Feb 2025 11:50:42 +0900

2025년 2월 IT 세미나

1. AI SEOUL 2025

일시: `25.02.11(화) 10:00 - 18:00
장소: 코엑스 그랜드볼룸 1층
주최/주관/후원: 서울특별시/서울AI허브
비고: 무료 (사전등록, 현장등록)

AI SEOUL 2025

www.aiseoul2025.com

2. Lenovo TechDay'25

일시: `25.02.20(목) - 01.17(금) 10:00 - 17:00
장소: 서울드래곤시티 컨벤션 타워 3층, 그랜드 볼룸 한라
주최/주관/후원 : Lenovo

Summary - Lenovo TechDay’25 It’s Time for AI-nomics

www.lenovotechevents.com

[ 2025년 01월 ] IT 세미나/컨퍼런스 일정

Theo (테오) — Sun, 9 Feb 2025 11:40:59 +0900

2025년 1월 IT 세미나

1. .NET Conf 2025 x Seoul re:Invent 2024

일시: `25.01.9(목) 09:30 - 18:00
장소: 서울시 강남구 영동대로96길 20 대화빌딩 지하 1층, 스페이스쉐어 삼성역센터
주최/주관/후원: 닷넷데브
비고: 유료

.NET Conf 2025 x Seoul

닷넷 히어로들의 축제 / Festival of .NET Heroes

dotnetconf.kr

2. 국제 교육 콘퍼런스 에듀콘 2025

일시: `25.01.15(수) - 01.17(금) 10:00 - 17:00
장소: 코엑스 A, B홀
주최/주관/후원 : (사)한국교육녹색환경연구원, 엑스포럼
비고: 유료

Education Korea EDUCON

대한민국 교육박람회 | 에듀콘

www.educationkorea.kr

DeepSeek R1 로컬(Local) 설치 가이드

Theo (테오) — Mon, 3 Feb 2025 17:21:14 +0900

최근 AI 챗봇의 데이터 보안 문제가 중요한 이슈로 부각되고 있습니다. DeepSeek AI의 프라이버시 정책에 따르면, 웹 서비스나 앱을 통해 사용할 경우 개인정보, 사용 패턴, 디바이스 정보 등 광범위한 데이터를 수집하며, 이 정보들은 중국 서버에 저장됩니다.

수집되는 정보의 범위:

개인 프로필 정보 (이름, 이메일, 전화번호)
채팅 기록 및 업로드한 파일
디바이스 정보 (모델명, 운영체제)
네트워크 정보 (IP 주소)
키보드 입력 패턴
시스템 언어 설정

하지만 DeepSeek R1을 로컬 환경에서 실행하면 이러한 걱정 없이 AI 챗봇을 활용할 수 있습니다. 이 글에서는 DeepSeek R1을 로컬 컴퓨터에 설치하고 실행하는 방법을 자세히 알아보겠습니다.

1. 설치 준비하기

1.1 Ollama 설치

Ollama는 AI 모델을 로컬 환경에서 실행하기 위한 기본 프로그램입니다.

# Windows의 경우 PowerShell 관리자 권한으로 실행
winget install ollama

# macOS의 경우
brew install ollama

# Linux의 경우
curl -fsSL https://ollama.com/install.sh | sh

1.2. Docker 설치

OpenWebUI 실행을 위해 필요한 컨테이너 플랫폼입니다.

# Windows/macOS: Docker Desktop 설치 후 실행 확인
docker --version

2. 본격적인 설치 과정

2.1 Ollama 서비스 시작

ollama serve

2.2 OpenWebUI 설치

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

이 명령어를 실행하면 다음과 같은 과정이 진행됩니다.

Docker 이미지 다운로드 (처음 실행 시에만)
컨테이너 생성 및 네트워크 설정
데이터 저장을 위한 볼륨 생성
웹 서버 시작

전체 설치 과정은 인터넷 속도에 따라 1-2분 정도 소요됩니다. 설치가 완료되면 Docker Desktop의 Containers 탭에서 'open-webui' 컨테이너가 실행 중인 것을 확인할 수 있습니다.

설치 상태 확인을 위해 다음 명령어를 실행할 수 있습니다.

docker ps

정상적으로 설치가 완료되면 'open-webui' 컨테이너가 목록에 표시됩니다.

2.3. DeepSeek R1 모델 설치

브라우저에서 localhost:3000 접속합니다.

우측 상단에서 설정을 클릭하고 팝업화면에서 관리자 설정을 클릭합니다.

모델 설정에서 Manage Models을 클릭하고 모델 태그명( deepseek-r1 )을 입력한 뒤 Download를 클릭하면 다운로드가 진행됩니다.

3. 모델 실행 및 사용

설치가 모두 완료되었다면, OpenWebUI 상단의 모델 드롭다운 메뉴에서 'deepseek-r1:latest 7.6B'가 표시되는 것을 확인할 수 있습니다.

DeepSeek R1 7.6B 모델은 약 4.7GB 크기로, Apple M3 Pro 칩셋이 탑재된 시스템에서도 원활하게 구동됩니다. 다만 실제 사용해 보니 영어는 가장 안정적인 성능을 보여주며, 응답의 정확도가 높습니다. 한국어는 기본적인 의사소통은 가능하나, 간혹 중국어가 혼용되어 출력되는 경우가 있습니다.

위에는 DeepSeek R1 7.6B 모델과의 실제 대화 내용입니다. 2등을 추월했을 때 몇 등이 되는지에 대한 논리적 추론 테스트를 진행했습니다. 테스트는 실제 Apple M3 Pro에서 수행되었으며, 실시간으로 촬영된 것으로, 모델의 실제 성능과 응답 속도를 있는 그대로 확인하실 수 있습니다.

최근 DeepSeek R1의 개발 비용과 데이터 보안에 대한 다양한 이야기가 있습니다. 실제 개발 비용은 공개된 것보다 더 많이 소요되었을 것으로 추정도 되고, 웹 서비스나 앱을 통한 사용 시 데이터 프라이버시 문제도 제기되고 있습니다.

하지만 DeepSeek R1의 가장 큰 의의는 오픈소스로 공개되었다는 점입니다. 이미 GitHub에서는 다양한 개발자들이 이를 기반으로 새로운 모델들을 만들어내고 있습니다. 더 작은 크기의 모델이나 특정 용도에 최적화된 버전 등 다양한 변형 모델들이 등장하고 있어, AI 발전의 새로운 전기가 될 것으로 기대됩니다.

제가 "경주에서 2등을 추월했다면 몇 등이 되는가?"라는 간단한 논리 퍼즐을 테스트해 봤는데... 흥미롭게도 모델이 5분 이상 '생각 중(Thinking)'이더군요. 결국 컴퓨터의 메모리를 계속 잡아먹으면서 다른 작업을 할 수 없는 상황이 되어 프로세스를 강제 종료할 수밖에 없었습니다.

이렇게 오래 생각할 문제였나 싶네요.

AI로 시작하는 No-code 개발: MVP부터 프로토타입까지

Theo (테오) — Tue, 28 Jan 2025 00:14:16 +0900

안녕하세요. 이번에는 AI를 활용한 개발 경험을 공유해드리려고 합니다. 특히 개발 경험이 전혀 없는 분들도 AI를 이용해 어떻게 프로그램을 만들 수 있는지, 그 과정에서 배운 점들을 이야기해 보겠습니다. 제가 실험해 본 결과, AI 도구들을 적절히 활용하면 생각보다 훨씬 빠르게 원하는 프로그램을 만들 수 있습니다.

1. AI 개발 도구 현황

현재 AI 개발 도구는 크게 두 가지 방향으로 발전하고 있습니다.

웹 기반 프로토타이핑 도구
AI 코드 에디터

각각의 도구들은 서로 다른 장점을 가지고 있어, 개발 목적과 상황에 따라 적절히 선택해서 사용하면 됩니다. 자세히 살펴보겠습니다.

1.1 웹 기반 프로토타이핑 도구

프로토타이핑 도구들은 코드 작성 없이도 빠르게 아이디어를 구현할 수 있게 해주는 도구들입니다.

Lovable.dev

개발 지식이 없어도 쉽게 사용할 수 있는 도구입니다. 자연어로 원하는 기능을 설명하면 AI가 이해하고 실제 작동하는 프로토타입을 생성해줍니다. 특히 MVP 개발이나 아이디어 검증 단계에서 유용합니다.

Lovable

Build software products, using only a chat interface

lovable.dev

주요 기능:

코드 없는 프로토타입 생성
반응형 디자인 자동 생성
API 연동 지원
실시간 협업 기능
바로 테스트 가능한 실행 환경

Bolt.new

Lovable보다 더 완성도 높은 애플리케이션 개발이 가능한 도구입니다. 백엔드 통합이 강점이며, Supabase 등 다른 서비스들과의 연동이 쉽습니다.

bolt.new

What do you want to build? Prompt, run, edit, and deploy full-stack web apps.

bolt.new

주요 기능:

풀스택 애플리케이션 개발
데이터베이스 자동 통합
API 엔드포인트 자동 생성
사용자 인증 내장
실시간 데이터 동기화

v0.dev (Vercel)

Vercel에서 제공하는 AI 기반 UI 생성 도구입니다. Tailwind CSS와 shadcn/ui 컴포넌트를 활용한 모던한 UI 개발에 특화되어 있습니다.

v0 by Vercel

Chat with v0. Generate UI with simple text prompts. Copy, paste, ship.

v0.dev

주요 기능:

AI 기반 UI 컴포넌트 생성
Tailwind CSS 통합
shadcn/ui 컴포넌트 지원
반응형 디자인 자동화
코드 내보내기 기능

1.2 AI 코드 에디터

AI 코드 에디터들은 실제 개발 환경에서 코드 작성을 도와주는 도구들입니다.

Cursor

현재 가장 강력한 AI 코드 에디터 중 하나입니다. 전체 프로젝트의 컨텍스트를 이해하고, 이를 바탕으로 정확한 코드 제안을 제공합니다.

Cursor - The AI Code Editor

Built to make you extraordinarily productive, Cursor is the best way to code with AI.

www.cursor.com

주요 기능:

프로젝트 전체 컨텍스트 이해
자연어 기반 코드 생성
상세한 코드 설명
자동 리팩토링
고급 디버깅 지원

Windsurf

초보자도 쉽게 사용할 수 있는 AI 코드 에디터입니다. 직관적인 인터페이스와 자동화된 기능이 특징입니다.

Windsurf Editor by Codeium

Tomorrow's editor, today. Windsurf Editor is the first AI agent-powered IDE that keeps developers in the flow. Available today on Mac, Windows, and Linux.

codeium.com

주요 기능:

쉬운 코드 생성
실시간 오류 검사
간편한 프로젝트 설정
초보자 친화적 인터페이스
즉각적인 피드백

GitHub Copilot

GitHub의 방대한 코드베이스를 학습한 AI 도구입니다. VSCode 등 주요 IDE와의 통합이 강점입니다.

GitHub Copilot · Your AI pair programmer

GitHub Copilot works alongside you directly in your editor, suggesting whole lines or entire functions for you.

github.com

주요 기능:

실시간 코드 제안
다중 언어 지원
GitHub 통합
테스트 코드 생성
지속적인 학습과 개선

2. 백엔드/인프라 도구 생태계

개발에 필요한 백엔드와 인프라 도구들도 AI와의 통합이 강화되고 있습니다.

2.1 Supabase

PostgreSQL 기반의 강력한 백엔드 서비스로, Firebase의 오픈소스 대안입니다.

Supabase | The Open Source Firebase Alternative

Build production-grade applications with a Postgres database, Authentication, instant APIs, Realtime, Functions, Storage and Vector embeddings. Start for free.

supabase.com

주요 기능:

PostgreSQL 데이터베이스
실시간 데이터 구독
자동 API 생성
인증 시스템
Edge Functions
파일 저장소

2.2 인증 서비스

Next-Auth: Next.js 앱을 위한 인증 솔루션
Clerk: 풀스택 인증 플랫폼
Supabase Auth: Supabase의 내장 인증 시스템

2.3 배포 플랫폼

Vercel: Next.js 앱에 최적화된 배포 플랫폼
Netlify: 정적 사이트와 서버리스 기능 지원
Cloudflare: 엣지 컴퓨팅과 CDN 서비스

3. 실제 프로젝트 개발 경험

제가 이번에 시도한 프로젝트는 미국 외교관 교육기관인 FSI(Foreign Service Institute)의 언어 학습 방법에서 영감을 받아 개발한 영어 학습 프로그램입니다. FSI 학습법의 핵심인 실제 상황 기반 학습과 즉각적인 피드백 시스템을 AI 기술과 결합했습니다.

사용자가 새 글을 작성하면 먼저 주제를 선정하고, 그 주제에 대한 자신의 생각을 아는 범위 내에서 영어로 작성합니다. 그러면 GPT가 이 작문을 분석해서 Beginner부터 Master까지 5단계로 실력을 평가합니다. 평가 후에는 Tavily API를 이용해 온라인에서 관련 표현들을 검색하고, 이를 바탕으로 GPT가 사용자의 작문과 비슷한 수준의 모범 답안을 제시합니다. 사용자는 자신의 표현과 AI가 제안한 표현을 비교하면서 학습할 수 있습니다.
이 방식의 장점은 단순한 문법 교정이나 첨삭을 넘어서, 실제로 비슷한 상황에서 영어 원어민들이 어떤 표현을 사용하는지 배울 수 있다는 점입니다. 또한 실시간으로 자신의 영어 실력 수준을 객관적으로 파악할 수 있고, 구체적인 개선 방향도 제시받을 수 있습니다.
이런 시스템을 통해 사용자들은 더 자연스럽고 실용적인 영어 표현을 학습할 수 있습니다. 실제 상황에서 자주 사용되는 표현들을 익히고, 점진적으로 자신의 영어 실력을 향상할 수 있습니다.

이번 프로젝트는 개발 경험이 전혀 없다는 가정하에 시작했습니다. 프로젝트를 위해 ChatGPT o1, Cursor AI 코드 에디터, Next.js 프레임워크, shadcn UI 컴포넌트 라이브러리를 활용했습니다.
개발 과정을 최대한 단순화하기 위해 데이터베이스 연결, 사용자 인증, 배포 과정은 일단 제외했습니다. 대신 핵심 기능인 영어 작문, AI 분석, 관련 표현 검색에 집중했습니다. 이렇게 하면 개발 경험이 없더라도 기능 구현에 더 집중할 수 있고, 프로젝트의 실현 가능성을 먼저 검증할 수 있다고 판단했기 때문입니다.

3.1 PRD(Product Requirements Document) 작성

개발을 시작하기 전에 ChatGPT에 프로젝트의 핵심 아이디어를 전달하고 PRD를 작성하도록 요청했습니다. FSI 학습법의 핵심 원리, 영어 학습 프로그램의 주요 기능, 그리고 개발 환경에 대한 내용을 자연어로 설명했고, ChatGPT가 이를 바탕으로 상세한 PRD 초안을 만들어주었습니다. 저는 모델을 o1을 사용했습니다.

아래 요구사항을 바탕으로 영어 학습 서비스(Study English with AI) 개발에 필요한 PRD(Product Requirements Document) 작성해줘.
- 최대한 단순한 UI로 학습에만 집중할 수 있는 환경 제공
- 날짜별 학습 기록을 리스트뷰 형식으로 관리
- 사용자 작문을 GPT로 분석해서 5단계로 실력을 평가(Beginner, Intermediate, Upper Intermediate, Advanced, Master)
- 분석 결과에 따라서 각 학습 기록마다 Lucide React 이모티콘으로 단계 표시
- 필수 기술스택으로 Next.js App Router, ShadCN, TailwindCSS 사용하고, 요구사항에 따른 추가적인 기술스택 업데이트
- LangChain, GPT API, Tavily Search API 등 AI 기능 구현에 필요한 라이브러리 최대한 활용
- MVP(Minimum Viable Product) 개발에 집중. 복잡한 기능보다는 핵심 기능 완성도에 초점
- 와이어프레임, 데이터 모델, API 설계 포함
- 성능 목표(페이지 로딩/API 응답 시간)와 보안 요구사항 정의
- 단계별 개발 마일스톤과 우선순위 정의

PRD는 다음 내용을 포함해야해
- 프로젝트 개요
- 유저 플로우
- 핵심 기능
- UI/UX 설계
- 데이터 모델링
- 기술스택
- 성능/보안 요구사항
- 개발 로드맵
- MVP 기능 개발 이후 추가 개선사항

3.2 개발 환경 설정과 기본 규칙 수립

개발을 시작하기 전에 먼저 프로젝트의 기본 구조와 규칙을 설정했습니다.

PRD.md 파일 생성

앞서 ChatGPT와의 대화를 통해 만든 PRD 내용을 'PRD.md' 파일로 저장했습니다. 이 문서는 개발 과정에서 지속적으로 참조할 수 있는 가이드라인이 되었습니다.

.cursorrules 설정

Cursor AI 에디터에서 일관된 코드 스타일과 개발 방향을 유지하기 위해 .cursorrules 파일을 생성했습니다. 여기에는 다음과 같은 규칙들을 포함했습니다.

# 규칙
## 패키지 매니저
- **패키지 매니저**: `pnpm`을 사용합니다.

## UI 컴포넌트 생성
- **ShadCN 컴포넌트를 우선적으로 활용합니다.**
- **ShadCN 컴포넌트 추가 명령어**:
  - CLI 명령어 예시: `pnpm dlx shadcn@latest add button`

## 스타일 가이드
- TailwindCSS 클래스 순서:
  1. Layout (width, height, display)
  2. Spacing (margin, padding)
  3. Typography (font, text)
  4. Colors (bg, text)
  5. Effects (shadow, opacity)

## 환경 변수
- `.env.local`에서 관리

## Git 관련
- 커밋 메시지 컨벤션:
  - feat: 새로운 기능 추가
  - fix: 버그 수정
  - docs: 문서 수정
  - style: 코드 포맷팅
  - refactor: 코드 리팩토링
  - test: 테스트 코드
  - chore: 빌드 업무 수정

Next.js + shadcn/ui 초기 설정

그다음으로 프로젝트의 기본 환경을 설정했습니다.

npx shadcn@latest init

이 명령어를 통해 Next.js 프로젝트가 생성되고, shadcn/ui의 기본 설정이 완료되었습니다.

Composer에 개발 요청

기본 환경 설정이 완료된 후, Cursor의 Composer 기능을 활용해 본격적인 개발을 시작했습니다. PRD.md 파일을 참조하여 각 기능별 구현을 요청했습니다. 특히 PRD에 정의된 기능들을 순차적으로 구현하도록 요청했는데, 이렇게 하면 각 단계별로 결과를 확인하고 필요한 수정을 할 수 있다는 장점이 있었습니다.
이렇게 기본적인 프로젝트 구조와 규칙을 설정함으로써, 이후 개발 과정에서 일관성을 유지하고 효율적으로 작업을 진행할 수 있었습니다. 특히 .cursorrules 파일은 AI와 협업하는 과정에서 일관된 코드 스타일을 유지하는 데 큰 도움이 되었습니다.

4. 실제 개발 결과

4.1 새로운 작문 작성 기능 구현

첫 번째로 구현한 기능은 작문 작성 페이지입니다. 이 페이지는 사용자가 영어 작문을 시작하는 첫 단계입니다.

개발 과정에서 초기 PRD에는 없었던 힌트 기능을 추가했습니다. 사용자가 주제와 관련된 표현을 미리 참고할 수 있도록 하여 작문의 진입 장벽을 낮추기 위함이었습니다. GPT에 각 주제에 맞는 실용적인 예시 문장들을 요청하여 사용자에게 제공함으로써, 작문을 시작하는 단계에서부터 실질적인 도움을 줄 수 있게 되었습니다.

4.2 작문 분석 기능 구현

두 번째로 구현한 기능은 작문 분석입니다. 사용자가 작문을 완료하고 "분석하기" 버튼을 클릭하면, GPT API를 통해 작성된 영어 문장을 분석합니다. 분석은 5단계(Beginner, Intermediate, Upper Intermediate, Advanced, Master)로 평가되며, 각 단계별 상세한 피드백을 제공합니다. GPT는 문법적 정확성, 어휘 사용, 문장 구조의 다양성, 표현의 자연스러움 등을 종합적으로 평가하여 사용자의 현재 영어 실력을 진단하고 개선점을 제시합니다.

4.3 유사 표현 검색 기능 구현

세 번째로 구현한 기능은 유사 표현 검색입니다. 작문 분석이 완료되면 Tavily API를 활용하여 온라인에서 관련된 영어 표현들을 검색합니다. 검색된 결과를 GPT에 전달하면 사용자가 작성한 것과 비슷한 맥락의 자연스러운 영어 표현으로 재구성하여 보여줍니다. 단순한 작문 교정을 넘어서, 실제 원어민들이 비슷한 상황에서 어떤 표현을 사용하는지 학습할 수 있게 해주는 기능입니다.

이 외에도 여러 가지 기능들을 추가로 구현했습니다. 자주 사용하고 싶은 표현을 저장할 수 있는 단어장 기능, 작성한 글을 수정하고 삭제할 수 있는 기능 등을 개발했습니다. 모든 기능은 코드를 직접 작성하지 않고, Cursor의 Composer에 자연어로 요구사항을 설명하는 방식으로 구현했습니다. 예를 들어 "단어장에 표현을 저장하고 조회할 수 있는 기능을 만들어줘"와 같이 대화하듯 요청하면, AI가 이해하고 적절한 코드를 생성해 주었습니다. 개발 과정에서 발생하는 오류나 수정 사항들도 대화를 통해 해결했습니다.

5. AI 주도 개발의 한계와 개선점

제약사항과 우려

복잡한 비즈니스 로직 구현의 한계
AI 의존도가 높을 경우 반복적 오류 발생
코드 품질 관리의 어려움

개선 방향

명확한 PRD 문서 작성이 중요
- 상세할수록 AI의 이해도 상승
- 오류 발생 빈도 감소
개발 표준과 규칙 정립 필요
- .cursorrules 등 가이드라인 중요
- 일관된 개발 패턴 유지

AI 도구들을 활용한 개발은 MVP나 프로토타입 제작에 효과적이지만, 프로덕션 단계의 개발은 아직 제한적입니다. 하지만 명확한 PRD 작성과 개발 표준을 잘 정립한다면, 더 효율적인 개발이 가능할 것으로 보입니다.

여담이지만, 이 영어 학습 프로그램의 이름은 ChatGPT에게 추천을 받아 'Lingular Lab'으로 정했습니다. Language와 Singular의 조합으로, 독특하고 기억하기 쉬운 이름이라며 추천했습니다. 아이콘은 AI 이미지 생성 도구인 Recraft를 활용해 고래와 상어가 대화하는 모습을 디자인했습니다.

이렇게 프로그램 이름부터 아이콘까지, AI 도구들을 활용해 브랜딩 작업까지 완성할 수 있었습니다.

[Github] https://github.com/yunwoong7/ai-driven-dev-playground/

[Python] Pydantic Field: 더 세밀한 데이터 검증하기

Theo (테오) — Sun, 12 Jan 2025 11:28:30 +0900

Pydantic의 Field는 BaseModel의 필드를 더 자세하게 정의하고 검증하기 위한 도구입니다. 단순히 타입을 지정하는 것을 넘어서, 데이터의 범위, 형식, 기본값 등을 세밀하게 제어할 수 있게 해줍니다.

Field가 필요한 이유

기본 BaseModel만으로는 이런 제약사항을 표현하기 어려웠습니다.

class Product(BaseModel):
    name: str  # 길이 제한을 어떻게 할까요?
    price: float  # 음수는 어떻게 막을까요?
    stock: int  # 재고가 0 미만이면 안 되는데...

Field를 사용하면 이런 제약사항을 명확하게 표현할 수 있습니다.

from pydantic import BaseModel, Field

class Product(BaseModel):
    name: str = Field(min_length=1, max_length=50)
    price: float = Field(gt=0)
    stock: int = Field(ge=0)

Field의 기본 기능들

1. 기본값과 필수값 설정

from pydantic import BaseModel, Field

class User(BaseModel):
    # 필수 필드
    username: str = Field(min_length=3)

    # 기본값이 있는 필드
    is_active: bool = Field(default=True)

    # 기본값을 함수로 설정
    created_at: datetime = Field(default_factory=datetime.now)

    # 선택적 필드
    nickname: str | None = Field(default=None)

2. 숫자 범위 제한

class Score(BaseModel):
    math: int = Field(ge=0, le=100)  # 0 이상 100 이하
    bonus: float = Field(gt=0, lt=10)  # 0 초과 10 미만
    ranking: int = Field(gt=0)  # 양수만 허용

3. 문자열 검증

class Article(BaseModel):
    title: str = Field(
        min_length=1,
        max_length=100,
        pattern="^[A-Za-z0-9 ]*$"  # 영문, 숫자, 공백만 허용
    )
    content: str = Field(min_length=10)
    tags: list[str] = Field(
        default_factory=list,
        max_items=5  # 최대 5개의 태그만 허용
    )

Field의 고급 기능

1. 사용자 정의 검증

from pydantic import BaseModel, Field, validator

def must_be_positive(v: int) -> int:
    if v <= 0:
        raise ValueError("Value must be positive")
    return v

class Order(BaseModel):
    quantity: int = Field(default=1, ge=1)
    price: float = Field(gt=0)
    total: float = Field(default=0.0)

    @validator('total')
    def validate_total(cls, v, values):
        if 'quantity' in values and 'price' in values:
            expected = values['quantity'] * values['price']
            if v != expected:
                raise ValueError(f'Total should be {expected}')
        return v

2. 예제와 설명 추가

class Product(BaseModel):
    name: str = Field(
        description="상품의 이름",
        examples=["맛있는 사과", "신선한 바나나"],
        min_length=1,
        max_length=50
    )
    price: float = Field(
        description="상품의 가격 (원)",
        examples=[1000, 2000],
        gt=0
    )

실전 예제: 복잡한 데이터 모델

from typing import List
from datetime import datetime
from pydantic import BaseModel, Field, EmailStr

class Address(BaseModel):
    street: str = Field(min_length=1, max_length=100)
    city: str = Field(min_length=1, max_length=50)
    postal_code: str = Field(
        pattern="^[0-9]{5}$",  # 5자리 숫자만 허용
        description="5자리 우편번호"
    )

class UserProfile(BaseModel):
    username: str = Field(
        min_length=3,
        max_length=20,
        pattern="^[a-zA-Z0-9_-]*$",  # 영문, 숫자, 특수문자(_-)만 허용
        description="사용자 아이디"
    )
    email: EmailStr = Field(description="사용자 이메일")
    age: int = Field(ge=0, lt=150, description="사용자 나이")
    interests: List[str] = Field(
        default_factory=list,
        max_items=10,
        description="관심사 목록 (최대 10개)"
    )
    address: Address
    created_at: datetime = Field(
        default_factory=datetime.now,
        description="계정 생성 시간"
    )

Field 매개변수 총정리

1. 기본값 관련

default: 기본값 설정
default_factory: 기본값을 반환하는 함수 설정

2. 숫자 제한

gt: (Greater Than) 초과
ge: (Greater Equal) 이상
lt: (Less Than) 미만
le: (Less Equal) 이하

3. 문자열 제한

min_length: 최소 길이
max_length: 최대 길이
pattern: 정규식 패턴

4. 컬렉션 제한

min_items: 최소 아이템 수
max_items: 최대 아이템 수
unique_items: 중복 아이템 허용 여부

5. 문서화

description: 필드 설명
examples: 예시 값
title: 필드 제목

사용 시 주의사항

필드 검증은 런타임에 이루어집니다
과도한 검증은 성능에 영향을 줄 수 있습니다
정규식 패턴은 신중하게 사용해야 합니다

Pydantic의 Field를 활용하면 데이터의 유효성을 더욱 정확하고 세밀하게 검증할 수 있으며, 문서화까지 한 번에 처리할 수 있습니다.

[Python] Pydantic BaseModel: 데이터 검증을 쉽게 하자

Theo (테오) — Sat, 11 Jan 2025 11:05:50 +0900

Pydantic의 BaseModel은 Python 데이터의 유효성을 검사하고 관리하기 위한 강력한 도구입니다. JSON 데이터를 파이썬 객체로 변환하거나, API 요청/응답을 검증할 때 특히 유용합니다. 간단한 클래스 정의만으로 복잡한 데이터 검증 로직을 구현할 수 있어요.

BaseModel이 필요한 이유

기존에는 데이터 검증을 이렇게 했습니다.

def validate_user(data: dict):
    if "name" not in data:
        raise ValueError("이름이 필요합니다")
    if not isinstance(data["name"], str):
        raise ValueError("이름은 문자열이어야 합니다")
    if "age" in data and not isinstance(data["age"], int):
        raise ValueError("나이는 정수여야 합니다")
    # 이런 검증이 계속 필요...

BaseModel을 사용하면 훨씬 간단해집니다.

from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int | None = None
    email: str

# 자동으로 검증됩니다
user = User(name="김철수", email="kim@example.com")

기본적인 사용법

1. 간단한 모델 정의

from pydantic import BaseModel, EmailStr

class UserProfile(BaseModel):
    username: str
    email: EmailStr
    age: int
    is_active: bool = True  # 기본값 설정

# 데이터 생성과 동시에 검증
user = UserProfile(
    username="python_lover",
    email="python@example.com",
    age=25
)

print(user.username)  # python_lover
print(user.model_dump())  # 딕셔너리로 변환

2. 중첩 모델 사용하기

class Address(BaseModel):
    street: str
    city: str
    postal_code: str

class User(BaseModel):
    name: str
    age: int
    address: Address

# 중첩된 데이터도 자동으로 검증
user = User(
    name="홍길동",
    age=30,
    address={
        "street": "강남대로 123",
        "city": "서울",
        "postal_code": "06000"
    }
)

BaseModel의 강력한 기능들

1. 필드 검증

from pydantic import BaseModel, Field

class Product(BaseModel):
    name: str = Field(min_length=1, max_length=50)
    price: float = Field(gt=0)
    description: str | None = Field(default=None)
    tags: list[str] = Field(default_factory=list)

# 잘못된 데이터는 오류 발생
try:
    product = Product(name="", price=-100)
except Exception as e:
    print(f"검증 오류: {e}")

2. 커스텀 검증

from pydantic import BaseModel, validator

class Order(BaseModel):
    quantity: int
    price_per_unit: float
    total_price: float

    @validator('total_price')
    def validate_total_price(cls, v, values):
        if 'quantity' in values and 'price_per_unit' in values:
            expected = values['quantity'] * values['price_per_unit']
            if abs(v - expected) > 0.01:
                raise ValueError('총 가격이 올바르지 않습니다')
        return v

실전 예제: API 응답 처리

from datetime import datetime
from typing import List
from pydantic import BaseModel, Field

class Comment(BaseModel):
    id: int
    content: str
    created_at: datetime
    likes: int = Field(default=0, ge=0)

class BlogPost(BaseModel):
    title: str = Field(min_length=1, max_length=100)
    content: str
    author: str
    tags: List[str] = []
    comments: List[Comment] = []
    published: bool = False
    views: int = Field(default=0, ge=0)

# JSON 데이터를 자동으로 파싱하고 검증
post_data = {
    "title": "Pydantic 사용하기",
    "content": "Pydantic은 정말 유용합니다...",
    "author": "파이썬러버",
    "tags": ["python", "pydantic", "tutorial"],
    "comments": [
        {
            "id": 1,
            "content": "좋은 글이네요!",
            "created_at": "2024-01-11T10:00:00",
            "likes": 5
        }
    ]
}

post = BlogPost(**post_data)

BaseModel의 유용한 메서드들

model_dump(): 모델을 딕셔너리로 변환
- data_dict = user.model_dump()
model_dump_json(): 모델을 JSON 문자열로 변환
- json_str = user.model_dump_json()
model_validate(): 딕셔너리에서 모델 생성
- user = User.model_validate(data_dict)

주의사항

Pydantic v2와 v1의 차이점을 알아야 합니다
성능에 민감한 경우 검증 비용을 고려해야 합니다
순환 참조는 피해야 합니다

BaseModel은 특히 다음과 같은 상황에서 매우 유용합니다.

FastAPI 등 웹 프레임워크에서 요청/응답 데이터 검증
설정 파일 파싱과 검증
외부 API 응답 데이터 처리
데이터베이스 모델 정의

Pydantic의 BaseModel을 사용하면 데이터 검증 로직을 간단하고 명확하게 작성할 수 있으며, 타입 안전성도 보장받을 수 있습니다.

[Python] TypedDict: 딕셔너리에 타입 힌트 추가하기

Theo (테오) — Sat, 11 Jan 2025 10:58:18 +0900

Python의 TypedDict는 딕셔너리의 키와 값에 대한 타입을 명확하게 지정할 수 있게 해주는 기능입니다. 특히 복잡한 데이터 구조를 다룰 때 발생할 수 있는 타입 관련 오류를 미리 방지할 수 있어 유용합니다.

TypedDict가 필요한 이유

기존 딕셔너리는 이런 문제가 있었습니다.

# 일반 딕셔너리 사용 시
user = {
    "name": "김철수",
    "age": 25,
    "email": "kim@example.com"
}

# 흔히 발생하는 실수들
print(user["Name"])  # KeyError: 'Name' (키 이름 오타)
print(user["age"] + "살")  # TypeError: int + str 연산 불가
user["phone"] = 123  # 예상치 못한 새로운 키 추가

TypedDict 기본 사용법

1. 클래스 스타일로 선언하기

from typing import TypedDict

class User(TypedDict):
    name: str
    age: int
    email: str

# 타입 힌트가 있는 딕셔너리
user: User = {
    "name": "김철수",
    "age": 25,
    "email": "kim@example.com"
}

2. 함수형 스타일로 선언하기

from typing import TypedDict

# 대체 문법 사용
Movie = TypedDict('Movie', {
    'title': str,
    'director': str,
    'year': int,
    'rating': float
})

movie: Movie = {
    "title": "기생충",
    "director": "봉준호",
    "year": 2019,
    "rating": 4.5
}

TypedDict의 고급 기능

1. 필수/선택적 필드 지정

class BookBase(TypedDict):
    title: str    # 필수 필드
    author: str   # 필수 필드

class Book(BookBase, total=False):
    isbn: str        # 선택적 필드
    description: str # 선택적 필드

# description이 없어도 타입 에러가 발생하지 않습니다
book: Book = {
    "title": "파이썬 프로그래밍",
    "author": "홍길동",
    "isbn": "123-456-789"
}

2. TypedDict 상속

class MediaContent(TypedDict):
    title: str
    year: int

class Movie(MediaContent):
    director: str
    duration: int

class Series(MediaContent):
    seasons: int
    episodes_per_season: int

3. Extra Items와 Closed TypedDict

# 추가 필드의 타입을 제한하는 경우
class TaggedMovie(TypedDict, extra_items=bool):
    title: str
    year: int
    # 추가되는 모든 키의 값은 bool 타입이어야 함

# 추가 필드를 완전히 금지하는 경우
class StrictMovie(TypedDict, closed=True):
    title: str
    year: int
    # 정의되지 않은 필드는 추가할 수 없음

실전 예제: 복잡한 API 응답 처리

from typing import TypedDict, List, Optional

class GeoLocation(TypedDict):
    latitude: float
    longitude: float

class Address(TypedDict):
    street: str
    city: str
    country: str
    postal_code: str
    geo: GeoLocation

class UserProfile(TypedDict, total=False):
    id: int
    username: str
    email: str
    addresses: List[Address]
    phone: Optional[str]
    is_active: bool

# API 응답 데이터
user_data: UserProfile = {
    "id": 1,
    "username": "python_lover",
    "email": "python@example.com",
    "addresses": [{
        "street": "강남대로 123",
        "city": "서울",
        "country": "대한민국",
        "postal_code": "06000",
        "geo": {
            "latitude": 37.5665,
            "longitude": 126.9780
        }
    }],
    "is_active": True
}

TypedDict 사용 시 주의사항

런타임 검사 없음: TypedDict는 정적 타입 검사 도구(mypy 등)에서만 작동합니다.
- # 런타임에서는 이런 오류를 잡지 못합니다 movie: Movie = {"title": 123} # 타입 힌트 위반이지만 실행은 됨
IDE 지원: PyCharm, VS Code 등 현대적인 IDE에서 타입 검사와 자동완성을 지원합니다.
Python 버전 호환성: Python 3.8 이상에서 모든 기능을 사용할 수 있습니다.

TypedDict를 효과적으로 사용하는 경우

API 통신: 외부 API의 요청/응답 데이터 구조 정의
설정 파일: 프로그램의 설정 데이터 구조 정의
데이터베이스: ORM 모델의 필드 타입 정의
테스트: 목업 데이터의 구조 정의

TypedDict는 특히 큰 프로젝트에서 데이터 구조를 명확하게 정의하고, 타입 관련 버그를 미리 방지하는 데 매우 유용합니다. 정적 타입 검사 도구와 함께 사용하면 더욱 효과적입니다.

효과적인 AI 에이전트 구축: Anthropic의 가이드

Theo (테오) — Wed, 1 Jan 2025 23:23:24 +0900

이 글은 Anthropic이 발표한 "Building effective agents" (2024년 12월 20일) 문서를 바탕으로 정리한 글입니다.

Building effective agents

A post for developers with advice and workflows for building effective AI agents

www.anthropic.com

1. 에이전트란 무엇인가?

에이전트의 정의는 관점에 따라 다양할 수 있습니다. Anthropic은 에이전트 시스템을 두 가지로 구분합니다.

1-1. 워크플로우(Workflows)

정의: 미리 정의된 코드 경로를 통해 LLM과 도구들을 조율하는 시스템
장점: 예측 가능하고 안정적인 결과 제공
사용 예: 고객 문의 처리, 문서 번역, 데이터 분석

1-2. 에이전트(Agents)

정의: LLM이 상황에 따라 프로세스와 도구 사용을 동적으로 결정하는 시스템
장점: 복잡하고 불확실한 상황에 대처 가능
사용 예: 복잡한 문제 해결, 연구 보조, 프로그래밍 지원

2. 에이전트 시스템의 사용 시기

AI 에이전트의 개념을 이해하고 나면, 많은 기업과 개발자들이 "우리 시스템에도 AI 에이전트를 도입해야 할까?"라는 고민에 빠지게 됩니다. 새로운 기술이 등장할 때마다 그러하듯, AI 에이전트 역시 만능 해결책은 아닙니다. 오히려 AI 에이전트는 특정 상황에서 그 진가를 발휘하는 강력한 도구라고 볼 수 있습니다. 마치 망치가 모든 도구 중 가장 유용할 수 있지만, 나사를 조이는 데는 적합하지 않은 것처럼, AI 에이전트도 적재적소에 활용될 때 가장 큰 가치를 발휘합니다.

따라서 AI 에이전트 도입을 고려할 때는 "할 수 있는가?"가 아닌 "해야 하는가?"를 먼저 고민해야 합니다.

2-1. 사용해야 할 때

복잡한 작업이 필요한 경우
- 여러 단계의 의사결정이 필요할 때
- 상황별 맞춤 대응이 필요할 때
유연성이 중요한 경우
- 정해진 규칙으로는 해결이 어려운 문제
- 다양한 상황에 대처해야 할 때

2-2. 사용을 피해야 할 때

단순한 작업의 경우
- 단일 LLM 호출로 충분한 경우
- 검색과 예시만으로 해결 가능한 경우
비용과 속도가 중요한 경우
- 실시간 응답이 필요한 서비스
- 대량 처리가 필요한 작업

3. 프레임워크 사용에 대한 가이드

AI 에이전트를 구현할 때 많은 개발자들이 프레임워크 사용을 고민하게 됩니다. LangChain, Crew AI, AutoGen과 같은 다양한 프레임워크들이 있습니다. 프레임워크는 마치 조립식 가구와 같습니다. 필요한 부품들이 이미 준비되어 있어 빠르게 시작할 수 있지만, 때로는 그 규격화된 형태가 우리의 특별한 needs에 완벽히 들어맞지 않을 수 있죠. 또한 프레임워크를 사용하면 개발 속도는 빨라질 수 있지만, 그 내부 작동 방식을 이해하지 못한다면 나중에 문제 해결이 더 어려워질 수 있습니다.

따라서 프레임워크 사용을 결정하기 전에, 우리 프로젝트의 특성과 요구사항을 잘 파악하고 그에 맞는 선택을 하는 것이 중요합니다.

3-1. 주요 프레임워크들

3-2. 프레임워크 사용 시 고려사항

장점
- 빠른 시작 가능
- 기본 기능 제공
- 개발 시간 단축
단점
- 추상화로 인한 디버깅 어려움
- 불필요한 복잡성 추가 가능
- 성능 최적화의 제한

3-3. 권장사항

처음에는 LLM API 직접 사용
필요한 경우에만 프레임워크 도입
프레임워크 내부 구조 이해 필수

4. 기본 구성 요소와 패턴

AI 에이전트 시스템을 이해하는 가장 좋은 방법은 그것을 구성하는 기본 요소들과 일반적인 패턴들을 살펴보는 것입니다. 마치 레고 블록처럼, 이러한 기본 구성 요소들을 조합하여 다양한 형태의 에이전트 시스템을 만들 수 있습니다. 건축에서 기초 공사가 중요하듯이, AI 에이전트 시스템에서도 기본 구성 요소를 제대로 이해하고 설계하는 것이 매우 중요합니다. 잘 설계된 기본 구성 요소는 시스템의 안정성과 확장성을 보장하며, 효율적인 문제 해결을 가능하게 합니다. 여러 성공적인 구현 사례들을 통해 발견된 일반적인 패턴들은 비슷한 문제를 해결하는 데 있어 신뢰할 수 있는 가이드라인을 제공합니다.

아래에서는 AI 에이전트 시스템의 핵심 구성 요소인 '증강된 LLM'과 함께, 가장 널리 사용되는 다섯 가지 주요 패턴들을 자세히 살펴보겠습니다.

4-1. 증강된 LLM (기본 구성 요소)

핵심 기능
- 검색 능력 (필요한 정보 찾기)
- 도구 사용 (외부 시스템과 상호작용)
- 메모리 관리 (정보 저장과 활용)
구현 포인트
- 사용 사례에 맞는 기능 최적화
- 명확한 인터페이스 제공
- 효율적인 리소스 관리

The augmented LLM (출처: Anthropic)

4-2. 주요 워크플로우 패턴

프롬프트 체이닝

복잡한 작업을 작은 단계들로 나누어 처리하는 방식입니다. 마치 자동차 조립 라인처럼, 각 단계가 이전 단계의 결과물을 받아 처리하고 다음 단계로 전달합니다.

작동 방식
- 큰 작업을 작은 단계들로 분해
- 각 단계는 이전 단계의 출력을 입력으로 사용
- 단계별로 품질 검사 가능
장점
- 각 단계가 명확하고 관리하기 쉬움
- 중간 결과를 확인하고 수정 가능
- 문제 발생 시 특정 단계만 수정 가능
활용 사례
- 콘텐츠 제작: 개요 작성 → 초안 작성 → 교정/편집
- 데이터 분석: 데이터 정제 → 분석 → 시각화
- 코드 생성: 설계 → 구현 → 테스트

The prompt chaining workflow (출처: Anthropic)

라우팅

스마트한 접수처 직원처럼 작동하는 시스템입니다. 들어오는 요청을 분석하고 가장 적합한 전문가에게 전달하는 역할을 합니다.

작동 방식
- 입력 내용 분석 및 분류
- 적절한 전문 처리기 선택
- 결과 확인 및 필요시 재라우팅
장점
- 각 전문가가 자신의 전문 분야에만 집중
- 효율적인 작업 분배
- 처리 품질 향상
활용 사례
- 고객 서비스: 문의 유형별 전문 상담원 배정
- 문서 처리: 문서 종류별 전문 처리기로 라우팅
- 기술 지원: 문제 유형별 전문가 팀 배정

The routing workflow (출처: Anthropic)

병렬화

하나의 큰 작업을 여러 작은 작업으로 나누어 동시에 처리하거나, 같은 작업을 여러 방식으로 동시에 수행하는 방식입니다.

두 가지 주요 방식
1. 섹션닝 (분할 처리)
  - 큰 작업을 독립적인 부분으로 분할
  - 각 부분을 동시에 처리
  - 결과를 다시 통합
2. 투표 (다중 검증)
  - 같은 작업을 여러 LLM이 수행
  - 다양한 관점에서 결과 도출
  - 결과를 비교하고 최적의 답안 선택
장점
- 처리 속도 향상
- 정확도 개선
- 신뢰성 향상
활용 사례
- 대규모 문서 처리: 여러 섹션 동시 분석
- 품질 관리: 여러 검토자가 동시에 검토
- 보안 검사: 다양한 관점에서 동시 검증

The parallelization workflow (출처: Anthropic)

오케스트레이터-워커

지휘자와 오케스트라 단원들의 관계처럼, 중앙 관리자가 작업을 조율하고 여러 전문가들이 실제 작업을 수행하는 구조입니다.

구성 요소
1. 오케스트레이터 (지휘자)
  - 전체 작업 계획 수립
  - 작업 분배 및 조율
  - 결과 통합 및 품질 관리
2. 워커 (전문가)
  - 특정 영역 전문화
  - 할당된 작업 수행
  - 결과 보고
장점
- 복잡한 작업의 효율적 관리
- 전문성 활용 극대화
- 유연한 자원 활용
활용 사례
- 소프트웨어 개발: 다양한 모듈 동시 개발
- 연구 프로젝트: 여러 분야의 전문가 협업
- 콘텐츠 제작: 여러 전문가의 협업 필요 작업

The orchestrator-workers workflow (출처: Anthropic)

평가자-최적화자

작가와 편집자의 관계처럼, 한 시스템이 작업을 수행하고 다른 시스템이 그 결과를 평가하고 개선점을 제시하는 구조입니다.

작동 방식
1. 최적화자 (작가)
  - 초기 결과물 생성
  - 피드백 기반 수정
  - 지속적 개선
2. 평가자 (편집자)
  - 결과물 품질 평가
  - 구체적 피드백 제공
  - 개선 방향 제시
장점
- 지속적인 품질 개선
- 객관적 평가 기준 적용
- 반복적 개선 가능
활용 사례
- 콘텐츠 최적화: 글쓰기 품질 개선
- 코드 리뷰: 코드 품질 및 성능 개선
- 번역 작업: 번역 품질 향상

The evaluator-optimizer workflow (출처: Anthropic)

AI 에이전트 시스템은 분명 강력한 도구이지만, 모든 문제의 해답은 아닙니다. Anthropic의 연구가 보여주듯이, 성공적인 시스템 구축의 비결은 화려하거나 복잡한 솔루션이 아닌, 상황에 맞는 적절한 접근법을 선택하는 것에 있습니다.

시작은 작게, 하지만 확실하게 하는 것이 좋습니다. 처음에는 단순한 워크플로우로 시작하여, 필요한 경우에만 더 복잡한 패턴들을 도입하는 것이 현명한 방법입니다. 마치 레고 블록을 조립하듯이, 기본 구성 요소들을 하나씩 추가하면서 시스템을 발전시켜 나가는 것을 추천드립니다. 그리고 가장 중요한 것은, 실제 필요성에 대해 살펴보는 것입니다. 남들이 복잡한 시스템을 사용한다고 해서 우리도 그래야 하는 것은 아니기 때문이죠. 때로는 가장 단순한 해결책이 가장 효과적인 답이 될 수 있습니다. AI 에이전트를 시작하는 분들에게 이 글이 조금이나마 도움이 되길 바랍니다.

참고 자료

Building effective agents - Anthropic

구글의 AI 혁신: Gemini 2.0부터 Veo2까지

Theo (테오) — Sat, 28 Dec 2024 23:47:53 +0900

구글이 최신 AI 모델인 Gemini 2.0 Flash을 공개했습니다. 이번에는 OpenAI의 12일 이벤트 중간에 발표를 진행했는데요, 작년과는 달리 이번에는 구글이 훨씬 더 준비된 모습을 보여줬습니다.

주요 특징과 발전된 기능들

Flash의 성능 향상
- Gemini 1.5 Pro보다 2배 빠른 속도
- 더 낮은 지연시간으로 실시간 대화 가능
- 성능은 향상되었는데 속도는 더 빨라진 게 인상적
확장된 멀티모달 기능
- 텍스트, 이미지, 오디오 입출력 모두 지원
- 실시간 음성 변환과 다국어 지원
- 마치 실제 비서와 대화하는 것 같은 자연스러움
네이티브 도구 통합
- 구글 검색 직접 연동
- 코드 실행 기능 내장
- 서드파티 도구와도 연동 가능

혁신적인 연구 프로젝트들

1. 프로젝트 아스트라 (Astra)

OpenAI의 Advanced Voice Mode와 비슷한 기능입니다. 지난 5월 구글 I/O에서 처음 선보였는데, 하루 전 OpenAI가 라이브 행사에서 먼저 공개하면서 다소 아쉬움이 있었습니다. 이때 아스트라는 OpenAI 대비 지연 시간이나 성능면에서 부족해 보였는데, 이번 데모 영상을 보니 많이 발전한 모습이네요. 특히 구글의 강점인 검색, 렌즈, 지도까지 통합되어 있어 실용성도 한층 높아진 것 같습니다.

더 나은 대화 능력: 다국어, 혼합 언어 지원
새로운 도구 활용: 구글 검색, 렌즈, 지도 통합
10분 단위 대화 기억 기능
추후 스마트 글라스 연동 예정이라는 점이 흥미로움

2. 프로젝트 마리너 (Mariner)

최근 Anthropic의 Computer Use와 유사한 기능입니다. Computer Use가 전반적인 컴퓨터 제어에 초점을 맞췄다면, 마리너는 웹 브라우저에 집중했네요. 브라우저 확장 프로그램 형태로 제공되어 설치와 사용이 쉽고, 보안을 위해 권한을 제한한 점도 실용적인 접근으로 보이네요. 특히 화면을 직접 이해하고 작업을 수행할 수 있다는 점에서 웹 브라우징의 새로운 가능성을 보여주고 있습니다.

브라우저 화면의 모든 요소(텍스트, 코드, 이미지, 폼 등)를 실시간으로 이해하고 처리할 수 있으며, 구매와 같은 민감한 작업에서는 반드시 사용자 확인을 받도록 설계된 점도 눈에 띕니다. 이런 안전성 중심의 설계는 실제 업무 환경에서 더욱 신뢰할 수 있는 도구가 될 것 같네요.

웹브라우저 화면 실시간 이해
WebVoyager 벤치마크에서 83.5% 달성
안전을 위한 제한된 권한 설정이 인상적

3. 프로젝트 줄스(Jules)

이 기능은 GitHub Copilot과 정면으로 경쟁할 것으로 보이는데, 특히 워크플로우 통합이라는 차별점이 있어 기대가 됩니다. 개발자들이 줄스를 통해 반복적인 작업에서 벗어나 더 창의적인 개발에 집중할 수 있게 될 것 같네요.

개발자들의 오랜 꿈이었던 AI 페어 프로그래머
GitHub 통합으로 실제 개발 워크플로우에 자연스럽게 녹아듦
코드 리뷰, 버그 수정, 문서화 작업 지원
현재 엄선된 개발 그룹을 통해 테스트를 진행 중
2025년 초 공개 예정이며, https://labs.google.com/jules/home에서 대기 신청 가능
비동기 개발의 효율성을 위해 문제 분석과 코딩 작업을 Jules에 위임 가능
Jules가 작성한 코드는 개발자가 쉽게 검토하고 프로젝트에 병합 가능
진행 상황을 실시간으로 추적하고 우선순위 조정도 가능

멀티미디어 생성 능력 강화

1. 베오2(Veo2)

OpenAI의 Sora 출시에 맞춰 공개된 구글의 비디오 생성 AI
4K 해상도의 동영상 생성 가능
다양한 영화적 기법 지원
- 장르 및 렌즈 지정
- 로우 앵글 추적 샷
- 클로즈업 등 카메라 동작
- 배경 흐림 처리
- 특정 피사체 초점 처리

주목할만한 발전

실제 물리 법칙에 대한 이해도 향상
인간의 움직임과 표현의 자연스러움 개선
사실감과 디테일 크게 향상
육안으로 보이지 않는 'SynthID' 워터마크 포함

활용 계획

구글랩스의 'VideoFX'로 현재 이용 가능 (대기자 명단에 등록)
2024년 유튜브 쇼츠와 다른 제품으로 확장 예정
사용자 접근성 점진적 확대 중

특히 Sora가 공개되어 다소 실망스럽다는 평가를 받는 동안, Veo2는 더 정확하고 세밀한 영상을 만들어내며 사용자들의 극찬을 받고 있다는 점이 인상적입니다. 실제 영상을 보면 물리적 움직임이나 카메라 워크가 매우 자연스럽고, 특히 렌즈 효과나 초점 처리 같은 전문적인 영상 기법도 잘 구현해내고 있네요.

2. 이마젠3(Imagen 3)

주요 특징

더 밝고 잘 구성된 이미지 생성 능력
다양한 예술 스타일 정확한 구현:
- 인상주의
- 추상적 애니메이션
- 다양한 예술 장르 해석
각종 평가에서 경쟁 모델 대비 우수한 성능 기록

활용 방법

구글랩스의 'ImageFX'를 통해 즉시 사용 가능
위스크(Whisk)와 통합되어 더욱 강력한 기능 제공:
- 특정 주제, 장면, 스타일 기반 이미지 생성
- 다양한 디자인 변형 및 리믹스
- Gemini의 시각적 이해 능력과 결합

혁신적인 점

Gemini가 이미지의 캡션을 작성하고, 이 설명을 이마젠3에 입력해 결과물 생성
더 자연스러운 구도와 조명 처리
텍스트 프롬프트에 대한 더 정확한 해석

베오2와 함께 구글의 생성형 AI 라인업을 강화하고 있는 이마젠3는 특히 예술적 표현력이 크게 향상된 것이 특징입니다. DALL-E 3나 Midjourney와 비교해도 손색없는 퀄리티를 보여주고 있죠.

Gemini 2.0 Flash Thinking: 구글의 추론 능력 강화 모델

구글이 Gemini 2.0 Flash의 새로운 버전인 'Flash Thinking'을 예고 없이 공개했습니다. OpenAI의 o3 발표에 맞춰 공개된 이 모델은 현재 Google AI Studio에서 무료로 사용해 볼 수 있는데요.

주요 특징

1. 강화된 추론 능력

Chain of Thought(사고의 연쇄) 기능 지원
문제 해결 과정을 단계별로 보여줌
o1처럼 내부적으로만 처리하는 것이 아닌, 전체 사고 과정 공개
자체 검증 및 수정 능력 보유

2. 성능과 접근성

LMSYS Chatbot Arena 기준 o1과 동등한 성능 기록
무료로 즉시 사용 가능 (API 비용 없음)
32,000 토큰 컨텍스트 윈도우 지원
텍스트와 이미지 입력 처리 가능

특히 인상적인 점

문제를 해결하기 전에 질문을 정확히 이해하려 노력
오류를 발견하면 스스로 수정하는 능력
복잡한 추론이 필요한 문제도 단계별로 명확하게 해결
이미지 기반 추론 문제도 처리 가능

활용 예시

수학 문제 해결
- 각 단계별 사고 과정 표시
- 자체 검증 단계 포함
- 오류 발견 시 수정 과정 공개
이미지 기반 추론
- 이미지 속 정보 분석
- 시각적 퍼즐 해결
- 단계별 시각적 추론 과정 설명

이번 발표는 구글이 OpenAI의 o3에 대응하는 동시에, 추론 능력에서 한 단계 더 발전된 모습을 보여주었다는 점에서 의미가 있습니다. 특히 무료로 제공된다는 점이 큰 장점이 될 것 같네요.

향후 계획

구글은 2025년 초 더 큰 규모의 모델들과 함께 Gemini 2.0을 정식 출시할 예정이며, 검색 서비스에도 도입될 예정이라고 합니다. 특히 6세대 TPU 트릴리엄을 활용해 더욱 강력한 성능을 제공할 것으로 기대됩니다.

OpenAI: 12일간의 업데이트 총정리

Theo (테오) — Sun, 22 Dec 2024 00:10:56 +0900

OpenAI가 진행한 12일간의 특별 업데이트 이벤트가 끝났습니다. 매일매일 새로운 기술과 기능이 공개되었는데요, 이번 이벤트는 단순한 기능 업데이트를 넘어 AI 기술의 새로운 가능성을 보여준 의미 있는 시간이었습니다. 12일간의 여정을 하나씩 살펴보겠습니다.

Day 1: o1 시대의 개막

첫날부터 강력한 소식으로 시작했습니다. o1 모델이 모든 유료 사용자에게 공개되었고, 새로운 Pro 요금제($200)가 도입되었죠. 특히 o1 pro mode는 더 오래 생각하고 분석하여 복잡한 문제에서도 정확한 답변을 제공하는 것이 특징이었습니다.

OpenAI: 강력한 추론 엔진 o1 출시

OpenAI가 12일간의 특별한 업데이트 이벤트를 시작했습니다. 첫날부터 두 가지 중요한 변화가 공개되었는데요, 하나는 그동안 프리뷰 버전으로만 제공되던 o1(Project Strawberry) 모델의 정식 출시이고

yunwoong.tistory.com

Day 2: AI 학습의 혁신, 강화 파인튜닝

두 번째 날은 AI 학습 방식의 혁신을 가져왔습니다. '강화 파인튜닝'이라는 새로운 기술은 기존의 지도 학습과는 다르게 모델이 새로운 방식으로 추론하는 것을 학습합니다. 특히 놀라운 점은 단 12개의 예시만으로도 전문가 수준의 AI를 만들 수 있다는 것이었죠. OpenAI가 내부적으로 사용하던 기술을 공개한 것으로, 2025년 초 정식 출시될 예정입니다.

Day 3: 영상 생성의 혁명, Sora 출시

10개월 전 데모로 큰 화제를 모았던 Sora가 드디어 공개되었습니다. 첫날 발표된 ChatGPT Pro 요금제($200)가 처음에는 다소 부담스럽게 느껴졌는데요, o1 pro의 성능이 아무리 뛰어나도 일반 사용자가 활용할 수 있는 고난도 질문이 제한적이라는 점에서 그랬습니다. 하지만 Sora의 등장으로 상황이 달라졌습니다. Pro 사용자들은 최대 20초 길이의 1080p 고품질 영상을 워터마크 없이 생성할 수 있게 되었고, Plus 사용자들은 720p 해상도로 5초 영상을 만들 수 있게 되었죠.

특히 Pro 요금제의 경우, 영상 제작 업계 종사자들에게는 충분히 매력적인 선택지가 될 수 있을 것 같습니다. 추가로 Storyboard, Re-cut, Remix 등 전문적인 편집 도구들도 함께 제공되어 실제 영상 제작 워크플로우에 통합하기 좋은 환경이 마련되었습니다. 월 200달러라는 비용이 영상 제작 관련 전문가들에게는 충분히 투자 가치가 있는 금액이 된 셈이죠.

OpenAI, Sora(소라) 사용방법 가이드

OpenAI가 진행 중인 12일간의 특별 업데이트 이벤트의 세 번째 날, 드디어 기다리던 Sora가 공개되었습니다. 월요일 발표 직후에는 폭발적인 관심으로 인해 계정 생성이 잠시 중단되었었는데요, 이

yunwoong.tistory.com

Day 4: Canvas의 진화

기존 유료 사용자만 이용 가능했던 Canvas 기능이 모든 사용자에게 개방되었습니다. 특히 Python 실행 지원과 그래프/차트 생성 기능이 추가되어 데이터 분석과 시각화가 한층 쉬워졌네요.

Day 5: Apple과의 강력한 통합

iOS와 ChatGPT의 만남이 이루어졌습니다. Siri와 ChatGPT가 연동되어 음성으로 더욱 자연스러운 대화가 가능해졌고, Visual Intelligence를 통해 카메라로 보는 것에 대해 실시간으로 물어볼 수도 있게 되었죠. 특히 Mac, iPad, iPhone에서 단축키로 간편하게 ChatGPT를 호출할 수 있게 된 점이 인상적이었습니다.

Day 6: 고급음성모드의 진화와 산타와의 만남

영상 통화와 화면 공유 기능이 고급음성모드에 추가되었습니다. 실시간으로 화면을 보면서 대화하고, 문제를 함께 해결할 수 있게 되었죠. 특히 재미있었던 것은 산타 모드였는데요, 전 세계 모든 사용자들이 산타와 직접 대화를 나눌 수 있게 되었습니다.

OpenAI, Santa Mode와 영상 통화가 가능한 Advanced Voice 공개

OpenAI가 진행 중인 12일간의 특별 업데이트 이벤트의 여섯 번째 날, Santa Mode와 Advanced Voice에 영상/화면 공유 기능이 추가되었습니다. 사실 이 기능은 지난 5월 13일 OpenAI의 스프링 제품 업데이트 라

yunwoong.tistory.com

Day 7: Projects로 작업 관리 혁신

ChatGPT에 프로젝트 관리 기능이 추가되었습니다. 단순한 대화 정리를 넘어 파일 업로드, 커스텀 지시사항 설정, Search와 Canvas의 통합 사용까지 가능해졌죠. Secret Santa 프로젝트부터 웹사이트 제작까지, 다양한 용도로 활용할 수 있게 되었습니다.

Day 8: 검색의 대중화

ChatGPT의 검색 기능이 큰 발전을 이루었습니다. 특히 이 기능이 모든 무료 사용자에게도 개방된 점이 주목할 만했는데요, 모바일에서의 사용성이 대폭 개선되어 실제 생활에서 더욱 유용하게 활용할 수 있게 되었습니다.

Day 9: 개발자를 위한 선물, o1 API

드디어 o1 API가 공개되었습니다. 이전 프리뷰 버전보다 성능은 더 좋아지고 응답은 더 빨라졌으며, 가격은 동일하게 유지되었죠. 특히 시각, 함수 호출, 구조화된 출력 지원 등 다양한 기능이 추가되어 개발자들의 기대를 한 몸에 받았습니다.

Day 10: 소통의 확장

ChatGPT와의 전화 통화가 가능해졌습니다. 미국 번호로 직접 전화를 걸어 대화할 수 있게 되었고, WhatsApp을 통한 채팅도 가능해졌죠. 특히 매월 15분의 무료 통화 제공은 AI와의 소통 방식에 새로운 장을 열었습니다.

Day 11: macOS와의 완벽한 통합

macOS 앱들과의 연동이 한층 강화되었습니다. 텍스트 에디터, 코드 에디터, 터미널 등 다양한 앱에서 ChatGPT를 활용할 수 있게 되었고, 단축키를 통한 빠른 실행도 가능해졌습니다.

Day 12: 대미를 장식한 o3와 o3-mini

마지막 날, OpenAI는 가장 강력한 카드를 공개했습니다. o1의 후속 모델인 o3와 o3-mini의 등장이었죠. 특이한 점은 o2가 아닌 o3라는 이름을 선택했다는 건데요, Sam Altman은 "텔레포니카의 친구들을 존중하는 마음과 함께, OpenAI가 이름 짓기에 정말 서툴다는 전통을 이어가며 o3로 정했다"며 위트 있게 설명했습니다.

o3의 성능은 정말 놀라웠습니다:

SweetBench Verified에서 71.7% 정확도 (o1 대비 20% 이상 향상)
Codeforces에서 ELO 2727 (세계 상위권 프로그래머 수준)
AMI 수학 점수 96.7% (o1의 83.3% 대비 큰 폭 상승)
PhD 수준 과학 문제 GPQA에서 87.7% (전문가 평균 70% 대비 월등)

특히 ARC AGI 벤치마크에서의 성과가 인상적이었는데요, 5년간 깨지지 않던 기록을 경신하며 87.5%를 기록했습니다. 인간 수준인 85%를 뛰어넘는 결과였죠.

이번 12일간의 업데이트는 OpenAI가 AI 기술의 미래를 어떻게 그리고 있는지 잘 보여준 시간이었습니다. 영상 생성부터 음성 대화, 프로젝트 관리, 그리고 강력한 추론 능력까지, AI 기술의 전 영역에서 혁신적인 발전을 이뤄냈습니다. 2025년에는 이러한 경쟁을 통해 어떤 혁신적인 기술들이 등장할지 매우 기대됩니다.

OpenAI: 12일간의 특별 이벤트 마지막 날, o3와 o3-mini 공개

Theo (테오) — Sat, 21 Dec 2024 11:20:36 +0900

OpenAI가 진행한 12일간의 특별 업데이트 이벤트가 대단원의 막을 내렸습니다. 마지막 날 공개된 것은 바로 차세대 추론 모델인 o3와 o3-mini였는데요, 이는 상당히 의미 있는 발표였습니다.

최근 인공지능 시장의 주도권을 놓고 구글과 OpenAI가 치열한 경쟁을 벌이고 있습니다. OpenAI가 ChatGPT의 검색 기능을 무료화한 날, 구글은 OpenAI의 'Sora'와 경쟁하는 동영상 생성 AI 'Veo2'를 공개했죠. 또한 구글은 에이전트 기능이 강화된 'Gemini 2.0'을 발표하며 OpenAI를 견제했습니다.

이런 경쟁 구도는 이번이 처음이 아닙니다. 지난 5월 구글 I/O 행사 직전, OpenAI는 새로운 모델 '4o'와 'Advanced Voice Mode'를 전격 공개하며 구글 I/O에 쏠린 관심을 분산시킨 바 있습니다. 이러한 양사의 눈치게임은 이번 연말에도 계속되었는데요.

그런데 마지막 날 발표된 o3와 o3-mini는 이런 경쟁 구도를 뛰어넘는 놀라운 성능을 보여주었습니다. 특히 수학, 코딩, 추론 능력에서 기존 모델들을 크게 앞서는 결과를 보여주었는데요, 자세한 내용을 살펴보겠습니다.

왜 o2가 아닌 o3일까?

이번에 발표된 새로운 추론 모델의 이름이 특히 흥미롭습니다. 논리적으로 o1 다음은 o2가 되어야 할 것 같은데, OpenAI는 이를 o3로 명명했는데요.

Sam Altman은 이에 대해 재미있는 설명을 했습니다. "텔레포니카의 친구들을 존중하는 마음과 함께, OpenAI가 이름 짓기에 정말 서툴다는 전통을 이어가며 o3라고 부르기로 했다"라고 말했죠. 이는 스페인의 통신회사 텔레포니카가 이미 'O2'라는 브랜드를 보유하고 있기 때문입니다.

이런 위트 있는 작명 비하인드 스토리는 OpenAI의 겸손한 태도와 함께, 기업 간의 상표권을 존중하는 모습을 보여주는 좋은 사례가 되었네요.

o3와 o3-mini의 놀라운 성능

특히 주목할 만한 점은 ARC AGI 벤치마크에서의 성과입니다. 이 벤치마크는 2019년에 만들어진 AI 지능 측정 도구로, 5년간 깨지지 않던 기록을 o3가 마침내 경신했는데요. ARC AGI의 독특한 점은 매번 완전히 새로운 유형의 문제를 제시한다는 것입니다. 예를 들어, "빈 공간에 파란색 사각형 채우기"처럼 간단해 보이는 문제부터 "노란색 사각형 내의 색칠된 사각형 수를 세어 테두리로 표현하기"와 같은 복잡한 문제까지 다양합니다. 이러한 문제들은 인간에게는 직관적으로 해결할 수 있지만, AI에게는 매우 어려운 과제였습니다. 단순히 이전에 학습한 패턴을 반복하는 것이 아니라, 새로운 규칙을 즉석에서 이해하고 적용해야 하기 때문이죠. o3는 이 벤치마크에서 87.5%라는 놀라운 성능을 보여주며, 인간 수준(85%)을 뛰어넘었습니다.

먼저 o3의 핵심적인 성능 지표를 살펴보면:

SweetBench Verified: 71.7% 정확도 (o1 대비 20% 이상 향상)
CodeForces ELO: 2727 (경쟁 프로그래밍 전문가 수준)
AMI 수학 점수: 96.7% (o1의 83.3% 대비 큰 폭 상승)
PhD 수준 과학 문제 GPQA: 87.7% (전문 PhD 평균 70% 대비 월등)

특히 주목할 만한 점은 ARC AGI 벤치마크에서의 성과입니다. 5년 동안 깨지지 않던 기록을 경신하며 87.5%라는 놀라운 점수를 기록했는데요, 이는 인간 수준의 성능(85%)을 뛰어넘는 결과입니다.

o3-mini: 효율성의 새로운 기준

o3-mini는 비용 효율적인 추론의 새로운 지평을 열었습니다. 특히 주목할 만한 특징은:

3단계 추론 강도 조절 (Low/Medium/High)
o1 대비 동등하거나 더 나은 성능
대폭 감소된 지연 시간 (1초 미만의 응답 속도)
모든 API 기능 지원 (함수 호출, 구조화된 출력 등)

안전성에 대한 새로운 접근

이번 발표에서는 'Deliberative Alignment'라는 새로운 안전성 검증 기술도 함께 공개되었습니다. 이는 단순한 예시 기반의 안전성 검증을 넘어, 모델이 스스로 추론하며 안전성을 판단하는 혁신적인 접근방식입니다.

출시 계획

현재 o3와 o3-mini는 안전성 테스트 단계에 있으며, 연구자들의 검증을 거친 후 단계적으로 출시될 예정입니다:

o3-mini: 2024년 1월 말 출시 예정
o3: o3-mini 출시 직후 공개 예정
안전성 테스트 참여 신청: 2024년 1월 10일까지 가능

이번 12일간의 OpenAI 특별 이벤트는 단순한 신기능 공개를 넘어, AI 기술의 새로운 지평을 보여주었습니다. 특히 마지막 날 공개된 o3와 o3-mini는 구글과의 경쟁 구도를 뛰어넘어, AI 기술의 미래가 어떤 방향으로 발전할 수 있는지를 보여준 의미 있는 발표였다고 평가할 수 있겠네요.

OpenAI, Santa Mode와 영상 통화가 가능한 Advanced Voice 공개

Theo (테오) — Sat, 14 Dec 2024 11:30:15 +0900

OpenAI가 진행 중인 12일간의 특별 업데이트 이벤트의 여섯 번째 날, Santa Mode와 Advanced Voice에 영상/화면 공유 기능이 추가되었습니다. 사실 이 기능은 지난 5월 13일 OpenAI의 스프링 제품 업데이트 라이브 스트리밍 이벤트에서 이미 시연되었던 것인데요. 저는 오늘부터 드디어 실제 사용이 가능해졌습니다.

Advanced Voice에 추가된 영상 기능

기존 Advanced Voice는 음성으로만 대화가 가능했지만, 이제는 실시간 영상 통화와 화면 공유까지 지원합니다. ChatGPT 앱에서 Advanced Voice 모드로 들어가면 하단에 비디오 버튼이 새롭게 추가된 것을 확인할 수 있는데요.

실시간 영상 통화
화면 공유 기능
50개 이상의 언어 지원
자연스러운 대화 속도와 감정 표현

등이 가능해졌습니다.

산타와의 특별한 만남

특히 재미있는 점은 12월 한 달 동안 산타와 직접 대화할 수 있는 'Santa Mode'가 추가된 것입니다. 홈 화면의 눈송이 아이콘을 통해 접근할 수 있으며, ChatGPT 설정에서도 산타를 선택할 수 있습니다.

산타는 북극에서의 생활부터 엘프들의 근황, 재미있는 크리스마스 이야기까지 다양한 주제로 대화가 가능한데요, 특유의 유쾌한 목소리와 함께 실시간으로 반응해 주어 마치 실제 산타와 대화하는 듯한 경험을 제공합니다.

산타 모드를 영어와 한국어로 모두 테스트해 봤는데요, 흥미로운 차이점이 발견됐습니다. 영어로 대화할 때는 산타 특유의 "Ho Ho Ho"와 함께 정말 자연스럽고 유쾌한 목소리로 대화가 이루어졌습니다. 마치 실제 백화점 산타와 대화하는 것 같은 느낌이었죠.

반면 한국어로 대화를 시도했을 때는 아쉽게도 음성이 다소 부자연스러웠습니다. 산타 특유의 친근하고 따뜻한 느낌은 살아있지만, 발음이나 억양이 어색한 부분들이 있었네요. 특히 '크리스마스', '선물' 같은 단어들이 기계적으로 들리는 경향이 있었습니다.

하지만 이는 ChatGPT의 한국어 음성 합성이 계속 발전하고 있는 과정에서 나타나는 자연스러운 현상으로 보입니다. 앞으로의 업데이트를 통해 한국어 음성도 영어만큼 자연스러워질 것으로 기대됩니다.

그래도 아이들과 함께 산타와 대화를 나누며 크리스마스의 마법 같은 순간을 만들어보는 것도 좋은 경험이 될 것 같네요.

접근 방법과 이용 제한

Teams 사용자와 대부분의 Plus, Pro 구독자들에게 순차적으로 제공
유럽 지역의 Plus/Pro 구독자는 추후 제공 예정
Enterprise/Edu 플랜 사용자는 내년 초 이용 가능
Santa Mode는 전 세계 모든 ChatGPT 사용자에게 제공
첫 산타와의 대화 시 Advanced Voice 사용 제한이 일회성으로 초기화

실제 사용 경험

Advanced Voice에 새롭게 추가된 시각적 기능들을 테스트해 봤습니다. 기존 음성 모드에 진입하면 좌측에 새로운 옵션들이 추가되어 있는데요:

카메라 켜기
화면 공유
사진 업로드
사진 촬영

특히 화면 공유 기능이 인상적이었습니다. 실시간으로 내 핸드폰 화면을 공유하면서 질문할 수 있어 다양한 용도로 활용이 가능해 보이네요.

시각적 인식 테스트

간단한 테스트로 제가 있는 장소를 카메라로 보여주고 어디인지 물어봤는데요, ChatGPT가 처음에는 오락기가 보여서 오락실이라고 추측했다가, 영화 포스터를 발견하고는 영화관이라고 정확하게 맞추더군요. 실시간으로 보이는 요소들을 분석하고 맥락을 이해하는 능력이 인상적이었습니다.

수학 문제 풀이

'8÷4+8(4-2)=?'
이 문제는 10명 중 6명이 틀린다는 유명한 문제인데요, ChatGPT는 정답인 18을 정확히 맞췄습니다. 이 문제가 많은 사람들을 헷갈리게 하는 이유는 연산자 우선순위 때문입니다.

괄호 안 계산: (4-2) = 2
나눗셈: 8÷4 = 2
곱셈: 8×2 = 16
마지막으로 덧셈: 2+16 = 18

많은 사람들이 8÷4를 먼저 계산하고 그 결과에 8을 곱하는 실수를 하는데, 실제로는 나눗셈과 곱셈은 같은 우선순위를 가지므로 왼쪽에서 오른쪽으로 계산해야 합니다.

특히 인상적이었던 것은 단순히 정답을 맞히는 것을 넘어서, 왜 많은 사람들이 이 문제에서 실수를 하는지 명확하게 설명해 준 점이었습니다. 수학 교사처럼 연산자 우선순위를 차근차근 설명하면서, 나눗셈과 곱셈이 동일한 우선순위를 가지므로 왼쪽에서 오른쪽으로 계산해야 한다는 핵심 포인트까지 짚어주더군요.

이런 설명 능력은 실시간 영상 통화 기능과 결합되면서 더욱 빛을 발하는 것 같습니다. 마치 실제 과외 선생님과 대화하는 것처럼 자연스럽게 문제를 설명해 주니, 교육 도구로서의 활용 가능성이 무궁무진해 보입니다.

확실히 시각적 요소가 더해지면서 ChatGPT와의 상호작용이 한층 더 풍부해졌네요. 앞으로 이 기능이 어떻게 발전해 나갈지 더욱 기대가 됩니다.

OpenAI, Sora(소라) 사용방법 가이드

Theo (테오) — Fri, 13 Dec 2024 17:47:17 +0900

OpenAI가 진행 중인 12일간의 특별 업데이트 이벤트의 세 번째 날, 드디어 기다리던 Sora가 공개되었습니다. 월요일 발표 직후에는 폭발적인 관심으로 인해 계정 생성이 잠시 중단되었었는데요, 이제 다시 서비스가 정상화되어 직접 테스트해 볼 수 있게 되었습니다.

Sora

Transform text and images into immersive videos. Animate stories, visualize ideas, and bring your concepts to life.

sora.com

Sora 사용을 위한 준비

Sora는 sora.com에서 별도로 접속하여 사용할 수 있습니다. ChatGPT 웹사이트가 아닌 독립된 도메인이지만, 기존 ChatGPT 계정으로 로그인이 가능합니다.

계정 생성 및 로그인 프로세스

sora.com 접속 후 우측 상단의 'Login' 버튼 클릭합니다.

생년월일 입력 (18세 이상 사용 가능) 후 'Next' 버튼 클릭하면 요금제 선택 화면에서 현재 상태 확인 (기존 Plus 사용자: 하단 'Continue' 버튼으로 진행, 신규 사용자: 원하는 요금제 선택) 하고 기존 유료 사용자인 경우 'Continue'를 눌러서 진행합니다.

Username 설정까지 하면 Sora를 사용하기 위한 준비는 모두 끝났습니다.

요금제

ChatGPT Plus ($20/월)	ChatGPT Pro ($200/월)
* 월 50개 우선 생성 (1,000 크레딧) * 최대 720p 해상도 * 최대 5초 길이 제한 * 워터마크 포함 다운로드 * ChatGPT Plus의 다른 기능들과 통합 사용 * 일반 사용자나 가벼운 테스트에 적합	* 월 500개 우선 생성 (10,000 크레딧) * 무제한 일반 생성 (다소 느린 속도) * 최대 1080p 해상도 * 최대 20초 길이 지원 * 워터마크 없는 고품질 다운로드 * 최대 5개 동시 생성 * GPT-4, o1 모델 무제한 사용 포함 * 전문가와 기업 사용자에게 적합

사용 가이드

Sora의 인터페이스는 직관적이고 깔끔하게 구성되어 있습니다. ChatGPT 사용자들에게 친숙한 디자인을 채택하고 있어 쉽게 적응할 수 있죠.

좌측 메뉴 구성

Explore (탐색)
- Recent: 최근 생성된 비디오
- Featured: 추천 작품
- Saved: 저장된 항목
Library (라이브러리)
- All videos: 내가 생성한 모든 비디오
- Favorites: 즐겨찾기 한 작품
- Uploads: 업로드한 파일
- New folder: 새 폴더 생성
- Untitled folder: 기본 폴더

중앙 생성 패널

화면 하단에 위치한 비디오 생성 패널에서는 다양한 설정이 가능합니다.

프롬프트 입력창
- "Describe your video..." placeholder
- 자연스러운 언어로 원하는 장면 설명
- ChatGPT와 유사한 인터페이스
주요 설정 옵션
- 이미지 업로드: 참조 이미지 추가
- 영상 크기: 16:9, 9:16 등 비율 선택
- 해상도: 480p, 720p, 1080p 선택
- 프리셋: 다양한 스타일 옵션
- 영상 길이: 5초~20초 설정 가능
- 생성 수량: 동시 생성 비디오 수 설정

설정 팁

첫 생성 시에는 480p로 테스트
만족스러운 결과물은 1080p로 재생성
5초 내외의 짧은 클립으로 시작
프리셋은 None으로 시작하여 실험

첫 비디오 생성하기 - 실제 테스트

프롬프트 작성

바센지 강아지의 코믹한 상황을 자세히 묘사한 프롬프트 입력
강아지의 특징적인 외모(말린 꼬리, 붉은 갈색 털, 흰 무늬)부터 상황의 전개, 결말까지 상세하게 기술
예시: "A curious Basenji dog with its characteristic curled tail stands near a small wooden deck by a peaceful lake. The elegant dog, with its reddish-brown coat and white markings, confidently approaches a low wooden bench. As it tries to gracefully hop onto the bench to enjoy the lake view, it misjudges the distance and comically tumbles over the bench, showing its typical Basenji surprised expression with perked ears, before landing softly on the grass with its tail still curled."

설정 구성

해상도: 480p (빠른 테스트용)
길이: 5초
화면 비율: 16:9
생성 수: 2 (다양한 결과물 비교 가능)

생성 프로세스

'Create' 버튼 클릭 후 생성 시작
우측 상단에 원형 프로그레스 바가 나타나며 생성 진행상태 표시
일반적으로 1분 이내 완료
두 개의 영상이 동시에 생성되어 비교 가능

결과물

고급 기능 활용하기

스타일 프리셋

None (기본값): 프롬프트 기반 자유로운 스타일
Cardboard & papercraft: 종이 공예 질감
Archival footage: 빈티지 영상 느낌
Film Noir: 고전 흑백 영화 스타일
커스텀 프리셋 생성 가능

Remix 기능 활용하기

Remix는 생성된 영상의 특정 요소를 창의적으로 변경할 수 있는 강력한 도구입니다.

Remix 화면 구성

'Remix' 버튼 클릭으로 시작
원본 영상 미리보기 제공
변경 요소 설명 입력창
강도 조절 슬라이더

강도 설정 옵션

Subtle: 미세한 변화 (색감, 밝기 등 섬세한 조정)
Mild: 중간 강도 변화 (부분적 요소 변경)
Strong: 큰 폭의 변화 (전체적 분위기 전환)

활용 예시

원본: "A Basenji dog playing in a sunny garden"
Remix 프롬프트:
- "Change the garden to a snowy landscape" (Strong)
- "Make the lighting more dramatic" (Mild)
- "Add autumn leaves in the background" (Subtle)

Remix 사용 팁

한 번에 하나의 요소만 변경
자연스러운 결과를 위해 낮은 강도부터 시도
변경하고자 하는 요소를 구체적으로 설명

Re-cut 기능 활용하기

Re-cut 화면 구성

타임라인 뷰
구간 선택 도구
프레임 단위 미리보기
확장 방향 설정 옵션

주요 기능

구간 선택
- 프레임 단위 정밀 선택
- 드래그 앤 드롭으로 범위 지정
- 미리 보기로 정확한 지점 확인
확장 설정
- 앞쪽 확장: 선택 구간 이전 새로 생성
- 뒤쪽 확장: 선택 구간 이후 새로 생성
- 양방향 확장: 전후 모두 확장
재생성 옵션
- 문제 구간만 선택적 재생성
- 원본 영상의 스타일 유지
- 자연스러운 전환 자동 생성

Re-cut 사용 예시

시나리오: 5초 영상 중 2-4초 구간이 가장 자연스러운 경우
1. 2-4초 구간 선택
2. 앞쪽 확장 선택 (0-2초 재생성)
3. 뒤쪽 확장 선택 (4-5초 재생성)

Re-cut 활용 팁

가장 마음에 드는 구간을 정확히 선택
확장 시 원본 영상의 컨텍스트 유지
필요한 경우 여러 번 반복하여 최적의 결과 도출
전환 구간을 포함하여 선택하면 더 자연스러운 결과스토리보드 기능 활용하기

스토리보드 기능 활용하기

스토리보드는 Sora의 가장 강력한 기능 중 하나로, 영상의 전체적인 흐름을 시퀀스별로 세밀하게 계획하고 제작할 수 있습니다.

스토리보드 화면 구성

타임라인 기반의 직관적인 인터페이스
각 시퀀스별 설명 입력 가능
시간 배분 조절 기능

시퀀스 설정 방법

'Storyboard' 버튼 클릭으로 시작
각 시퀀스마다 상세한 설명 작성
시퀀스 간 자연스러운 전환을 위한 중간 상태 설명 가능
최대 20초까지 구성 가능

활용 예시

시퀀스 1 (0-3초):
"A vast red landscape with a docked spaceship in the distance, the sun setting behind rocky mountains"

시퀀스 2 (3-4초):
"Camera smoothly transitions closer to the spaceship, revealing its metallic surface gleaming in the sunset"

시퀀스 3 (4-5초):
"Final close-up of the spaceship's detailed exterior, with subtle steam venting from its engines"

스토리보드 사용 팁

각 시퀀스는 명확하고 구체적으로 설명
장면 전환을 자연스럽게 설정하기 위해 중간 과정 상세 기술
전체적인 내러티브의 흐름 고려
시퀀스 간 시각적 연속성 유지

Sora Storyboard

스토리보드 기능은 특히 광고, 짧은 영화, 제품 소개 등 스토리텔링이 필요한 콘텐츠 제작에 매우 유용합니다. 단순한 장면 연결을 넘어 하나의 완성된 이야기를 만들어낼 수 있죠.

저는 Remix를 선택하고 바센지 영상의 배경이나 상황을 변경해 보았습니다.

수정된 결과물

Sora는 아직 초기 단계임에도 놀라운 성능을 보여주고 있습니다. 단순한 비디오 생성을 넘어 Re-cut, Remix, Storyboard 등 다양한 편집 기능을 제공하여 사용자의 창의성을 한층 더 끌어올릴 수 있는 도구가 될 것으로 기대됩니다.

현재는 Plus($20/월)와 Pro($200/월) 두 가지 요금제로 제공되며, 각자의 사용 목적과 필요에 따라 선택할 수 있습니다. 특히 Pro 요금제의 경우 GPT-4와 o1 모델의 무제한 사용까지 포함되어 있어, AI 도구를 전문적으로 활용하는 사용자라면 충분히 고려해 볼 만한 가치가 있습니다.

다만, 아직 베타 서비스인 만큼 개선이 필요한 부분들도 있습니다. 사람을 포함한 이미지 업로드의 제한이나, 때때로 나타나는 불안정한 결과물 등은 앞으로 해결되어야 할 과제로 보입니다. 하지만 이런 한계에도 불구하고, Sora는 비디오 생성 AI의 새로운 지평을 열었다고 평가할 수 있겠네요.

OpenAI의 12일간의 특별 업데이트 이벤트 중 공개된 Sora. 앞으로 어떤 발전된 모습을 보여줄지, 그리고 어떻게 활용되어 갈지 매우 기대됩니다. 더 자세한 사용 후기와 활용 사례는 계속해서 업데이트하도록 하겠습니다.

추가로 다가오는 크리스마스를 위해 집 트리 사진을 올리고 산타가 선물을 가져다 주는 영상을 만들어 봤습니다.

Sora는 업로드한 이미지를 기반으로 영상을 생성하는 과정에서 집에는 없는 커튼이나 다른 장식들이 추가되기도 했지만, 전반적인 분위기와 특히 산타의 움직임, 그림자 처리까지 매우 자연스럽게 표현해냈습니다.

스토리보드 기능을 활용해 산타가 선물을 놓고 손을 흔드는 장면을 연출했는데요, 마치 실제 산타가 우리 집에 다녀간 것 같은 느낌을 주는 매력적인 영상이 완성되었습니다. AI가 만든 영상이라고 하기에는 놀라울 정도로 자연스러운 퀄리티를 보여줬네요.

OpenAI: 강력한 추론 엔진 o1 출시

Theo (테오) — Fri, 6 Dec 2024 15:18:24 +0900

OpenAI가 12일간의 특별한 업데이트 이벤트를 시작했습니다. 첫날부터 두 가지 중요한 변화가 공개되었는데요, 하나는 그동안 프리뷰 버전으로만 제공되던 o1(Project Strawberry) 모델의 정식 출시이고, 다른 하나는 파워 유저들을 위한 새로운 Pro 요금제의 도입입니다.

o1, 이제 모든 유료 플랜에서 사용 가능

o1은 이전에 Project Strawberry라는 코드명으로 알려졌던 ChatGPT의 추론 특화 모델입니다. Plus나 Teams 플랜을 포함한 모든 유료 사용자들이 이제 이 모델을 제한 없이 활용할 수 있게 되었죠. 특히 속도 면에서 큰 개선이 이루어져, 프리뷰 버전 대비 거의 2배 가까이 빨라졌다고 합니다.

Chain of Thought: o1의 차별화된 사고방식

o1의 가장 큰 특징은 'Chain of Thought(사고의 연쇄)' 추론 방식입니다. 기존 모델들이 즉각적인 답변을 제시했다면, o1은 마치 인간처럼 문제를 해결하기 전에 깊이 있는 사고 과정을 거칩니다. 다양한 전략을 시도하고, 실수를 인지하며, 더 나은 해결책을 찾아가는 과정이 인상적입니다.

특히 다음과 같은 영역에서 뛰어난 성능을 보여줍니다:

복잡한 수학 문제 해결
과학적 추론이 필요한 질문
코딩 및 소프트웨어 개발
마케팅 전략 수립
심층적인 분석이 필요한 작업

ChatGPT Pro - 파워 유저를 위한 무제한 플랜

이번에 새롭게 도입된 Pro 요금제는 월 200달러로 책정되었습니다. 기존 Plus 요금제의 10배 가격이지만, GPT-4와 o1에 대한 완전한 무제한 액세스를 제공한다는 점에서 의미가 있습니다. 초기에는 GPT-4 사용량이 주당 30-50회로 제한되어 있었던 것을 생각하면, 큰 변화라고 할 수 있죠.

Pro 요금제의 주요 특징:

GPT-4와 o1 무제한 사용
향상된 음성 대화 기능 무제한 제공
o1 Pro 모드 접근 권한
향후 추가될 웹 브라우징 기능 우선 제공

실제 성능은 어떨까?

o1의 벤치마크 결과를 보면 그 성능이 더욱 명확해집니다:

표준 거부 평가에서 99.5% 이상의 정확도
복잡한 추론 과제에서 GPT-4 대비 20-30% 성능 향상
다국어 처리 능력에서도 큰 폭의 개선

더욱 강화된 기능들

특히 반가운 소식은 o1에 이미지 처리 능력이 추가되었다는 점입니다. 이미지를 보고 분석하거나, 이미지와 관련된 추론을 수행하는 것이 가능해졌죠. 여기에 조만간 웹 브라우징 기능까지 추가될 예정이라고 하니, o1의 활용도는 더욱 높아질 것으로 보입니다.

오늘부터 이 새로운 기능들을 직접 테스트해 볼 수 있게 되어 매우 기대됩니다. 특히 코딩과 분석 작업에서 o1의 Chain of Thought 기능이 얼마나 효과적인지, 그리고 Pro 요금제가 제공하는 무제한 기능이 실제 작업 환경에서 어떤 변화를 가져올지 직접 경험해 보고 자세한 후기를 전해드리도록 하겠습니다.

앞으로 2주 동안 매일 새로운 업데이트가 공개된다고 하니, ChatGPT가 어떤 기능들을 더 선보일지도 궁금합니다.

AWS Bedrock으로 구현한 Contextual Retrieval

Theo (테오) — Wed, 4 Dec 2024 16:24:48 +0900

지난 글에서 소개했던 Anthropic의 Contextual Retrieval을 AWS Bedrock 서비스를 활용하여 직접 구현해 보았습니다. 특히 기존 RAG 시스템의 한계를 극복하고자 하는 이 방식의 효과를 실제로 확인해보고 싶었습니다.

Anthropic의 맥락적 검색(Contextual Retrieval): 대규모 지식 베이스를 위한 RAG 기술

2024년 9월 20일, Anthropic은 기존 Retrieval-Augmented Generation (RAG) 시스템의 성능을 크게 향상할 수 있는 '맥락적 검색(Contextual Retrieval)'이라는 새로운 방법을 소개했습니다. Introducing Contextual RetrievalAnthr

yunwoong.tistory.com

RAG 시스템의 한계

기존 RAG(Retrieval-Augmented Generation) 시스템은 긴 문서를 작은 청크로 나누어 처리하는 과정에서 다음과 같은 문제점들이 발생합니다:

청크 크기 제한: LLM의 컨텍스트 윈도우 제한으로 인한 강제 분할
독립적 임베딩: 각 청크를 독립적으로 벡터화하여 저장
문서 구조 손실: 목차, 섹션 등 문서의 구조적 정보 손실
참조 정보 단절: 이전/이후 내용에 대한 참조 관계 유실

이러한 한계는 다음과 같은 실패 사례로 이어집니다.

사용자 질문: "2023년 3분기 매출은 얼마였나요?"
결과적 답변: "2024년 3분기 목표 매출은 150억원입니다."

Chunk 1의 시간 정보 누락으로 벡터 유사도 검색 시 ‘2023년', ‘분기', '매출', '억원' 등의 키워드 중심 검색하여 2023년 3분기 매출"을 찾았는데 "2024년 3분기 목표"를 반환합니다.

구현 및 테스트 환경

사용한 AWS Bedrock 모델

Text Generation: anthropic.claude-3-5-haiku-20241022-v1:0
Embedding: amazon.titan-embed-text-v2:0
Reranking: amazon.rerank-v1:0

구현한 검색 모드

Contextual Embedding만 사용
Contextual Embedding + BM25 하이브리드 검색
하이브리드 검색 + Reranking

프로젝트 구성

bedrock_contextual_retrieval/
├── contextual_retrieval/
│   ├── __init__.py
│   ├── config/
│   │   ├── __init__.py
│   │   ├── default_config.yaml
│   │   └── schema.py
│   ├── utils/
│   │   ├── __init__.py
│   │   └── document_utils.py
│   ├── embedding_models.py
│   ├── vector_client.py 
│   ├── bm25.py
│   ├── reranker.py
│   └── retriever.py
├── tests/
│   └── test_search.py
└── asset/
    └── doc/
        └── test_doc.pdf

테스트 문서 선정

테스트를 위해 "2024년 「일자리 채움 청년지원금」 사업운영 지침(안)"을 선택했습니다. 이 문서는

약 90페이지 분량의 복잡한 공문서
한국어 특유의 행정 용어와 복잡한 문장 구조
다양한 예외사항과 조건들이 문서 전반에 걸쳐 분산됨

이런 특성을 가진 문서는 기존 RAG 시스템의 한계를 잘 보여줄 수 있는 좋은 테스트 케이스였습니다.

테스트 결과

동일한 질문 "일자리 채움 청년지원금 중복 지원 가능한 경우에 대해 알려줘"로 각 모드를 테스트했습니다.

1. Contextual Embedding 검색

기본적인 맥락 정보는 포함되었지만, 중복 지원이라는 특정 예외사항을 찾지 못해 "제공된 검색 결과에서 중복 지원에 대해 명확하게 언급된 내용은 없습니다"라는 잘못된 답변을 제공했습니다.

2. Contextual Embedding + BM25

BM25를 추가하여 키워드 기반 검색을 결합하자, 문서 중간에 있던 중복 지원 관련 내용을 정확하게 찾아내어 올바른 답변을 제공했습니다.

3. Reranking 추가

재순위화까지 적용하니 가장 관련성 높은 내용을 우선적으로 제공하며, 맥락을 잘 파악한 답변을 생성했습니다.

성능 향상 요소

Anthropic의 연구 결과와 유사하게, 이번 구현에서도 각 요소 추가에 따른 성능 향상을 확인할 수 있었습니다.

Contextual Embeddings: 검색 실패율 35% 감소
Contextual Embeddings + BM25: 검색 실패율 49% 감소
Reranking 추가 시: 검색 실패율 67% 감소

전체 코드는 GitHub에 공개했으니, 관심 있으신 분들은 직접 테스트해보실 수 있습니다.

[Source Code] Github - Bedrock Contextual Retrieval

Claude의 새로운 기능: 맞춤형 응답 스타일 설정

Theo (테오) — Thu, 28 Nov 2024 00:20:41 +0900

Anthropic이 Claude.ai 사용자들을 위해 발표한 새로운 기능인 '커스텀 스타일(Custom Styles)'에 대해 알아보겠습니다. 이 기능을 통해 사용자들은 자신만의 필요와 작업 방식에 맞게 Claude의 응답을 맞춤화할 수 있게 되었습니다.

Tailor Claude's responses to your personal style

Today, we're announcing custom styles for all Claude.ai users. Now you can tailor Claude's responses to your unique needs and workflows.

www.anthropic.com

맞춤형 스타일이란?

Claude의 커스텀 스타일 기능을 사용하면 Claude의 응답 방식을 사용자의 선호도에 맞게 조정할 수 있습니다. 개발자, 마케터, 제품 팀 등 각자의 업무 특성에 맞는 커뮤니케이션 스타일을 설정할 수 있습니다.

사전 설정된 스타일 옵션

Formal(격식): 명확하고 세련된 응답
Concise(간결): 짧고 직접적인 응답
Explanatory(설명): 새로운 개념을 배우기 위한 교육적 응답

스타일 맞춤화 방법

기본 스타일 외에도 자신만의 커스텀 스타일을 만들 수 있습니다.

샘플 콘텐츠 업로드
- 자신이 선호하는 커뮤니케이션 방식이 담긴 샘플 제공
- 실제 작성했던 문서나 대화 내용을 예시로 활용

스타일 가이드라인 설정
- 원하는 톤과 말투 지정
- 전문성 수준과 격식성 정도 설정
- 응답의 길이와 상세도 조절

역할 지정을 통한 스타일 조정
- 특정 역할을 부여하여 커뮤니케이션 스타일 변경
- 예: 교사, 전문가, 동료 등 다양한 페르소나 활용

활용 팁

업무 유형별 최적화

기술 문서 작성: 명확하고 전문적인 톤 설정
크리에이티브 작업: 자유롭고 창의적인 스타일 적용
교육 콘텐츠: 이해하기 쉽고 친근한 톤 사용

단순한 응답 생성을 넘어, 사용자의 개성과 필요에 맞춘 진정한 의미의 개인화된 AI 협업이 가능해졌습니다. 이 기능을 잘 활용한다면, 더욱 효율적이고 만족스러운 AI 활용이 가능할 것입니다.

Anthropic의 Model Context Protocol(MCP) : 사용 가이드

Theo (테오) — Wed, 27 Nov 2024 18:41:55 +0900

오늘은 Anthropic에서 새롭게 발표한 Model Context Protocol(MCP)에 대해 자세히 알아보려고 합니다. AI에 관심이 있는 분이라면 꼭 알아두어야 할 새로운 기술이니 차근차근 살펴보겠습니다.

Introducing the Model Context Protocol

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevan

www.anthropic.com

# MCP가 뭔가요?

MCP(Model Context Protocol)는 Anthropic이 새롭게 발표한 혁신적인 오픈 소스 프로토콜입니다. 이는 AI 어시스턴트가 다양한 데이터 소스와 직접 상호작용할 수 있게 해주는 표준화된 연결 방식입니다. 특히 주목할 만한 점은 이 프로토콜이 특정 AI 모델에 국한되지 않는다는 것인데 Anthropic의 Claude뿐만 아니라 모든 AI 모델이 이 프로토콜을 통해 비즈니스 도구, 콘텐츠 저장소, 개발 환경 등과 연동될 수 있습니다. 이미 Block, Apollo를 비롯한 여러 기업들이 MCP를 자사 시스템에 도입했으며, Replit, Codium, Sourcegraph 같은 개발 도구 회사들도 MCP 도입을 진행 중이라고 합니다.

좀 더 쉽게 설명하자면:

지금까지의 AI: "저는 학습된 데이터만 알고 있어요"
MCP 적용 후의 AI: "제가 직접 웹 서칭, 구글 드라이브, 슬랙, GitHub 등을 검색해서 최신 정보를 알려드릴 수 있어요!"

아래는 실제 MCP를 적용 전과 후의 답변 결과입니다.

기존 방식:
- 유저: "Claude, 비트코인의 현재 가격이 얼마인지 알려줘"
- Claude: "죄송합니다. 실시간 가격 정보에 접근할 수 없어요"
MCP 사용:
- 유저: "Claude, 비트코인의 현재 가격이 얼마인지 검색해서 알려줘"
- Claude: "Brave Search로 검색해 보니, 현재 비트코인 가격은 $51,234이고, 지난 24시간 동안 3.2% 상승했네요. 이 정보를 파일로 저장해 드릴까요?"

MCP 적용 전 / 후

OpenAI도 얼마 전 ChatGPT에 'Work with Apps'라는 유사한 기능을 발표했습니다.

출처: OpenAI

ChatGPT Plus와 Team 사용자들은 Xcode, VS Code, JetBrains IDE 등 다양한 코딩 앱과 연동하여 더 정확한 답변을 받을 수 있게 되었습니다. 하지만 OpenAI는 이 기술을 오픈 소스로 공개하지 않고 특정 파트너들과의 협력을 통해 제한적으로 테스트하고 있다는 점이 Anthropic의 접근방식과 다릅니다.

# MCP 시작하기: 따라 하기 가이드

1단계: Claude Desktop 앱 설치

Anthropic 웹사이트에서 다운로드
계정 로그인

2단계: 설정 파일 만들기

# Library/Application Support/Claude 폴더로 이동
cd ~/Library/Application\ Support/Claude

# config 파일 생성
touch claude_desktop_config.json

3단계: 서버 설정하기 (Brave Search + Filesystem)

MCP에서는 다양한 서버들을 지원하고 있습니다. 파일 시스템, GitHub, Google Drive, PostgreSQL, Slack 등 정말 많은 서버들이 있는데요. 오늘은 그중에서 가장 간단하게 테스트해 볼 수 있는 Brave Search를 이용하여 웹 검색도 하고 결과를 로컬 파일로 저장할 수 있도록 두 가지 서버를 함께 설정해 보겠습니다.

Brave Search API 키 발급받기 (기존이 이미 발급한 API 키가 있다면 Skip)

Brave Search API는 세 가지 요금제를 제공하고 있습니다. 우리는 테스트를 위해 무료 플랜을 사용할 건데요, 무료 플랜으로도 충분히 테스트해 볼 수 있습니다.

API 키 발급 순서

https://brave.com/search/api/ 접속
'Free' 플랜의 'Subscribe' 버튼 클릭
API 키 발급받기

파일 시스템 설정

/Users/사용자이름/Desktop: 추가로 접근을 허용할 경로
경로는 여러 개 추가 가능

설정 파일 구성하기

앞서 만든 claude_desktop_config.json 파일을 열고 다음과 같이 작성합니다.

{
    "mcpServers": {
      "brave-search": {
        "command": "npx",
            "args": [
            "-y",
            "@modelcontextprotocol/server-brave-search"
            ],
            "env": {
            "BRAVE_API_KEY": "YOUR_API_KEY_HERE"
            }
        },
        "filesystem": {
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-filesystem",
                "/Users/username/Desktop",
                "/path/to/other/allowed/dir"
            ]
        }
    }
  }

Tip: 무료 플랜은 초당 1회 요청만 가능하니, 검색 요청을 너무 빠르게 연속해서 하지 않도록 주의해 주세요!

# 테스트하기

설정이 완료되면 Claude Desktop 앱의 채팅 인터페이스에서 Available MCP Tools 버튼이 보여야 합니다. 이 버튼이 보인다면 MCP가 정상적으로 설정된 것입니다.

이제 실제로 테스트를 해보겠습니다.

웹 검색 테스트

"비트코인 가격 정보를 검색하고 bitcoin-price.md 파일로 저장해줘"

처음 실행할 때는 Brave Search 사용 권한을 요청하는 팝업이 뜰 수 있습니다. 이를 허용해 주세요.

파일 시스템 테스트

이어서 파일을 저장하기 위한 명령을 수행합니다. file system 역시 사용 권한을 요청하는 팝업이 뜹니다. 이를 허용해 주세요.

Brave Search로 검색하고 후 정보를 정리하여 지정된 MCP 폴더(/Users/yunwoong/Desktop/MCP)에 markdown 파일로 저장합니다.

MCP는 우리가 테스트해 본 Brave Search와 파일 시스템 외에도 다양한 서버들을 지원합니다. Google Drive로 문서를 검색하거나, Slack으로 메시지를 주고받고, GitHub 저장소를 관리하는 등 다양한 작업이 가능합니다.
더 멋진 점은 누구나 자신만의 MCP 서버를 만들 수 있다는 것입니다. TypeScript나 Python을 사용해 원하는 기능을 가진 서버를 개발할 수 있어요. 사내 시스템 연동이나 특별한 API 연동 등 필요한 기능을 직접 구현할 수 있습니다. Model Context Protocol 문서를 참고하시기 바랍니다.

MCP는 AI의 새로운 장을 열어가는 중요한 기술입니다. 이제 AI 어시스턴트가 우리가 실제로 사용하는 도구들과 직접 소통할 수 있게 되었죠. 아직 초기 단계지만, AI 통합의 미래를 보여주는 중요한 이정표가 될 것입니다.

[ 오류 해결 ] Mac에서 `pip install pygraphviz` 설치 문제 해결하기

Theo (테오) — Wed, 27 Nov 2024 00:29:55 +0900

Mac에서 pygraphviz를 설치하려고 할 때, 아래와 같은 오류 메시지가 발생할 수 있습니다.

이 문제는 pygraphviz가 Graphviz 라이브러리를 찾지 못해 발생합니다. 일반적으로 brew install graphviz로 Graphviz를 설치하면 해결될 것으로 기대되지만, 환경 설정이 올바르지 않으면 문제가 지속될 수 있습니다.

아래는 이 문제를 해결한 방법입니다.

1. 문제

pip install pygraphviz 명령을 실행하면 다음과 같은 오류가 발생합니다.

에러 요약:
- Graphviz의 헤더 파일(cgraph.h)을 찾지 못함
- 빌드 과정에서 clang 컴파일러 에러 발생

pygraphviz/graphviz_wrap.c:3023:10: fatal error: 'graphviz/cgraph.h' file not found
      #include "graphviz/cgraph.h"
               ^~~~~~~~~~~~~~~~~~~
1 warning and 1 error generated.
error: command '/usr/bin/clang' failed with exit code 1

2. 일반적인 해결법

먼저 brew install graphviz로 Graphviz를 설치합니다.

brew install graphviz

설치 후 다시 pip install pygraphviz를 실행했지만, 문제는 여전히 해결되지 않았습니다.

3. 최종 해결법

환경 변수를 수동으로 설정하고 설치를 다시 시도해야 합니다. 다음 명령어를 순서대로 실행하세요:

export PATH=$(brew --prefix graphviz):$PATH
export CFLAGS="-I $(brew --prefix graphviz)/include"
export LDFLAGS="-L $(brew --prefix graphviz)/lib"
pip install pygraphviz

명령어 설명

PATH 설정: Graphviz 바이너리 경로를 시스템 경로에 추가합니다.
CFLAGS: Graphviz의 include 디렉토리를 컴파일러가 참조하도록 설정합니다.
LDFLAGS: Graphviz의 lib 디렉토리를 링커가 참조하도록 설정합니다.

4. 설치 성공 메시지

위 단계를 따라 실행하면 pygraphviz 설치가 성공적으로 완료됩니다.

참고: 설치 후에도 문제가 발생하면 python -m pip show pygraphviz로 설치 경로를 확인하고, Graphviz 라이브러리가 올바르게 연결되었는지 추가 점검하세요.

AI 에이전트 시작하기: LangGraph 개념과 실습

Theo (테오) — Tue, 26 Nov 2024 00:23:21 +0900

AI 에이전트는 LLM(Large Language Model)을 활용하여 복잡한 작업을 수행하는 자동화된 시스템입니다. 일반적인 LLM 사용이 단순 프롬프트-응답 방식이라면, 에이전트는 더 복잡하고 반복적인 작업을 수행할 수 있습니다.

AI 에이전트의 핵심 디자인 패턴

계획(Planning): 작업을 수행하기 위한 단계를 미리 생각하고 계획합니다.
도구 사용(Tool Use): 검색, 계산 등 필요한 도구들을 활용합니다.
반성(Reflection): 결과를 반복적으로 개선하며, 여러 LLM이 결과를 검토하고 제안할 수 있습니다.
다중 에이전트 통신: 각각의 LLM이 고유한 역할을 수행하며 서로 협력합니다.
메모리: 여러 단계에 걸친 진행 상황과 결과를 추적합니다.

AI와 AI 에이전트의 차이: 깊이 '생각하는' AI의 시대가 온다

인간의 사고 과정에 대한 획기적인 통찰을 제공한 노벨상 수상자 다니엘 카너먼은 그의 저서 "생각에 관한 생각(Thinking, Fast and Slow)"에서 인간의 사고방식을 '시스템 1'과 '시스템 2'로 구분했습니

yunwoong.tistory.com

LangGraph 소개

LangGraph는 LangChain의 확장으로, 에이전트와 다중 에이전트 워크플로우를 구축하기 위해 특별히 설계되었습니다. 주요 특징은 다음과 같습니다.

Home

️LangGraph ⚡ Building language agents as graphs ⚡ Note Looking for the JS version? Click here (JS docs). Overview LangGraph is a library for building stateful, multi-actor applications with LLMs, used to create agent and multi-agent workflows

langchain-ai.github.io

핵심 컴포넌트

노드(Nodes)
- 에이전트나 함수를 나타냅니다.
- LLM 호출, 도구 실행 등의 작업을 수행합니다.
엣지(Edges)
- 노드들을 연결합니다.
- 워크플로우의 흐름을 정의합니다.
조건부 엣지(Conditional Edges)
- 다음 노드로의 이동을 결정하는 조건을 포함합니다.
- 워크플로우의 분기를 관리합니다.

State 관리

LangGraph의 중요한 특징 중 하나는 상태 관리입니다. 에이전트 상태(Agent State)는 아래와 같습니다.

그래프의 모든 부분에서 접근 가능
지속성 레이어에 저장 가능
나중에 상태를 복구하여 작업 재개 가능

AI 에이전트와 LangGraph 이해하기

AI 에이전트는 LLM을 사용해 복잡한 작업을 처리하는 자동화된 시스템입니다. 단순한 프롬프트-응답이 아닌, 여러 단계의 작업을 수행할 수 있죠. LangGraph를 사용해 이런 에이전트를 만들어보겠습니다.

먼저 필요한 라이브러리들을 가져옵니다.

from typing import List, TypeVar, Annotated, TypedDict
from operator import add
from langchain_openai import ChatOpenAI
from langchain_core.messages import AnyMessage, SystemMessage, HumanMessage, ToolMessage
from langgraph.graph import StateGraph, END
from langchain.tools import Tool
import getpass
import os

# API 키 설정
if "OPENAI_API_KEY" not in os.environ:
    os.environ["OPENAI_API_KEY"] = getpass.getpass("Enter your OpenAI API key: ")

1. 도구 설정: 계산기 예제

간단한 계산기 도구를 만들어보겠습니다. 이 계산기는 하나의 수식을 받거나 여러 인자를 받아 계산할 수 있습니다.

def calculator(*args) -> float:
    """수학 계산을 수행하는 함수"""
    if len(args) == 1:
        return eval(str(args[0]))
    return eval(' '.join(str(arg) for arg in args))

tool = Tool(
    name="calculator",
    func=calculator,
    description="Useful for performing mathematical calculations"
)

2. 상태 관리

LangGraph의 핵심 기능 중 하나는 상태 관리입니다. 대화 이력을 messages 리스트에 저장하고, operator.add로 새로운 메시지를 추가합니다.

class AgentState(TypedDict):
    messages: Annotated[List[AnyMessage], add]

3. 에이전트 클래스

에이전트의 핵심 로직을 담당하는 클래스를 만듭니다.

class Agent:
    def __init__(self, model, tools, system=""):
        self.system = system
        self.tools = {t.name: t for t in tools}
        self.model = model.bind_tools(tools)
        self.graph = self._create_graph()

그래프 생성

    def _create_graph(self):
        workflow = StateGraph(AgentState)

        # 노드 추가
        workflow.add_node("llm", self.call_model)
        workflow.add_node("action", self.take_action)

        # 엣지 추가
        workflow.add_conditional_edges(
            "llm",
            self.should_use_tool,
            {True: "action", False: END}
        )
        workflow.add_edge("action", "llm")

        workflow.set_entry_point("llm")
        return workflow.compile()

여기서 중요한 컴포넌트들을 살펴보겠습니다.

노드(Nodes)
- llm: 사용자 입력을 처리하고 도구 사용을 결정합니다.
- action: 실제 도구를 실행합니다.
엣지(Edges)
- 조건부 엣지: 도구 사용 여부에 따라 다음 단계를 결정합니다.
- 일반 엣지: 도구 실행 후 다시 LLM으로 돌아갑니다.

도구 실행 로직

    def take_action(self, state: AgentState):
        tool_calls = state["messages"][-1].tool_calls
        results = []

        for t in tool_calls:
            if t["name"] not in self.tools:
                result = "bad tool name, retry"
            else:
                args_values = list(t["args"].values())
                try:
                    result = self.tools[t["name"]].invoke(*args_values)
                except Exception as e:
                    result = f"Error executing tool: {str(e)}"
            results.append(
                ToolMessage(
                    tool_call_id=t["id"],
                    name=t["name"],
                    content=str(result)
                )
            )
        return {"messages": results}

4. 실행 및 테스트

에이전트를 초기화하고 테스트해 봅시다.

system_prompt = """You are a helpful assistant that can use tools to accomplish tasks.
When you need to perform calculations, use the calculator tool.
Always explain your reasoning before and after using tools."""

model = ChatOpenAI(temperature=0)
agent = Agent(model=model, tools=[tool], system=system_prompt)

def run_agent(question: str):
    print(f"\nQuestion: {question}")
    messages = [HumanMessage(content=question)]
    result = agent.graph.invoke({"messages": messages})
    print(f"Final Answer: {result['messages'][-1].content}")
    return result

이 구조의 장점은:

명확한 실행 흐름: 그래프 구조로 실행 흐름을 쉽게 이해할 수 있습니다.
유연한 확장성: 새로운 도구나 노드를 쉽게 추가할 수 있습니다.
상태 추적: 대화 이력과 작업 진행 상황을 효과적으로 관리합니다.

실제로 에이전트를 테스트해 보고 그 결과를 시각화해 보겠습니다.

# 테스트할 질문들 준비
test_questions = [
    "What is 25 * 48?",
    "If I have 3 groups of 17 items each, how many items do I have in total?"
]

print("=== 에이전트 테스트 시작 ===")
for question in test_questions:
    run_agent(question)
print("=== 테스트 완료 ===\n")

# 그래프 시각화
print("=== 그래프 구조 시각화 ===")
from IPython.display import Image
Image(agent.graph.get_graph().draw_png())

첫 번째 질문 "What is 25 * 48?"

LLM이 계산 필요성을 인식
calculator 도구 호출
결과를 받아 최종 답변 생성

두 번째 질문 "If I have 3 groups of 17 items each, how many items do I have in total?"

LLM이 문제를 이해하고 수식으로 변환
calculator(3 * 17) 실행
결과를 문맥에 맞게 설명

그래프 구조를 보면

LLM 노드 (시작점)
Action 노드 (도구 실행)
조건부 분기와 순환 구조

이러한 시각화를 통해 에이전트의 의사결정 과정과 작업 흐름을 명확하게 이해할 수 있습니다.

이 기본 구조를 바탕으로 다음과 같은 기능을 추가할 수 있습니다.

여러 도구를 사용하는 복잡한 작업 처리
중간 결과를 저장하고 불러오는 기능
사용자와의 대화형 상호작용
외부 API나 데이터베이스와의 연동

이렇게 만든 에이전트는 단순 계산부터 복잡한 정보 처리까지 다양한 작업을 자동화하는 데 활용할 수 있습니다.

AWS CLI로 S3 관리하기: 파일 업로드, 다운로드, 버킷 생성

Theo (테오) — Mon, 25 Nov 2024 00:09:06 +0900

Amazon S3(Simple Storage Service)는 AWS에서 제공하는 확장 가능하고 안정적인 객체 스토리지 서비스입니다. AWS CLI(Command Line Interface)를 사용하면 Amazon S3의 기능을 효율적으로 관리할 수 있습니다. 이 글에서는 AWS CLI를 사용해 S3 버킷 생성, 파일 업로드 및 다운로드와 같은 기본 작업을 다루어 보겠습니다.

S3란?

Amazon S3는 클라우드 스토리지 서비스로, 데이터를 객체 단위로 저장하며 높은 가용성과 보안을 제공합니다. S3는 웹 애플리케이션, 백업 및 복구, 빅데이터 분석 등 다양한 용도로 사용됩니다.

S3 작업을 위한 사전 준비

AWS CLI로 S3를 관리하려면 다음이 필요합니다:

AWS CLI 설치 및 구성
- AWS CLI 설치 가이드를 참조하여 설치합니다.
- aws configure 명령어를 사용해 자격 증명을 설정합니다.
적절한 IAM 권한
- S3 작업을 위해 s3:* 권한을 포함하는 정책이 필요합니다.
- 예: AmazonS3FullAccess 또는 사용자 정의 정책.

S3 버킷 생성

S3 버킷은 데이터를 저장할 컨테이너 역할을 합니다. 다음 명령어로 새 버킷을 생성할 수 있습니다.

aws s3 mb s3://your-bucket-name

s3://your-bucket-name: 생성할 버킷의 이름.
버킷 이름은 고유해야 하며, 소문자와 하이픈(-)만 사용할 수 있습니다.

예제

aws s3 mb s3://my-example-bucket

S3에 파일 업로드

S3에 파일을 업로드하려면 s3 cp 명령어를 사용합니다.

aws s3 cp <local-file-path> s3://<bucket-name>/<key>

<local-file-path>: 업로드할 로컬 파일 경로.
<bucket-name>: 업로드할 S3 버킷 이름.
<key>: S3에서 파일을 저장할 경로(생략 시 파일 이름만 사용).

예제

aws s3 cp myfile.txt s3://my-example-bucket/folder/myfile.txt

S3에서 파일 다운로드

S3에서 파일을 다운로드하려면 s3 cp 명령어를 사용합니다.

aws s3 cp s3://<bucket-name>/<key> <local-file-path>

<bucket-name>: 다운로드할 파일이 위치한 S3 버킷 이름.
<key>: S3 파일 경로.
<local-file-path>: 다운로드한 파일을 저장할 로컬 경로.

예제

aws s3 cp s3://my-example-bucket/folder/myfile.txt ./downloaded-myfile.txt

S3 버킷 또는 폴더 내용 나열

S3 버킷의 파일 목록을 확인하려면 s3 ls 명령어를 사용합니다.

aws s3 ls s3://<bucket-name>

예제

aws s3 ls s3://my-example-bucket/folder/

S3에서 파일 삭제

S3에서 파일을 삭제하려면 s3 rm 명령어를 사용합니다.

aws s3 rm s3://<bucket-name>/<key>

예제

aws s3 rm s3://my-example-bucket/folder/myfile.txt

S3 동기화

로컬 디렉토리와 S3 버킷(또는 경로)을 동기화하려면 s3 sync 명령어를 사용합니다.

aws s3 sync <local-directory> s3://<bucket-name>/<prefix>

<local-directory>: 동기화할 로컬 디렉토리 경로.
<prefix>: 동기화할 S3 경로(선택).

예제

aws s3 sync ./local-folder s3://my-example-bucket/remote-folder

AWS CLI를 사용하면 Amazon S3 작업을 빠르고 효율적으로 수행할 수 있습니다. 이 가이드를 따라 파일 업로드, 다운로드, 동기화, 버킷 생성과 같은 작업을 자동화하거나 쉽게 관리할 수 있습니다. 반복적인 작업을 자동화하면 시간을 절약하고 작업의 일관성을 유지할 수 있습니다.

[Python] 함수형 프로그래밍

Theo (테오) — Sun, 24 Nov 2024 00:54:23 +0900

함수형 프로그래밍은 함수를 일급 객체로 취급하며, 불변 데이터와 순수 함수를 중심으로 하는 프로그래밍 패러다임입니다. Python은 객체지향 언어이지만, 함수형 프로그래밍의 강력한 기능도 제공합니다. 이 글에서는 Python에서 제공하는 함수형 프로그래밍 기법과 이를 활용하는 방법을 다룹니다.

1. 함수형 프로그래밍이란?

함수형 프로그래밍은 다음과 같은 특징을 가지고 있습니다:

순수 함수: 함수는 입력값만을 사용하며 외부 상태를 변경하지 않습니다.
불변성: 데이터는 변경되지 않고, 항상 새 데이터를 반환합니다.
고차 함수: 함수를 매개변수로 전달하거나 반환할 수 있습니다.

Python에서 함수형 프로그래밍을 지원하는 주요 도구는 map(), filter(), reduce(), 그리고 lambda 함수입니다.

2. `map()` 함수

map() 함수는 반복 가능한 객체의 각 요소에 대해 함수를 적용하여 새 값을 반환합니다.

사용법

map(function, iterable)

function: 각 요소에 적용할 함수.
iterable: 적용 대상 데이터(iterable).

예제

numbers = [1, 2, 3, 4, 5]
squared = map(lambda x: x**2, numbers)
print(list(squared))  # [1, 4, 9, 16, 25]

3. `filter()` 함수

filter() 함수는 조건을 만족하는 요소만 걸러냅니다.

사용법

filter(function, iterable)

function: 조건을 정의하는 함수.
iterable: 필터링 대상 데이터(iterable).

예제

numbers = [1, 2, 3, 4, 5]
even_numbers = filter(lambda x: x % 2 == 0, numbers)
print(list(even_numbers))  # [2, 4]

4. `reduce()` 함수

reduce() 함수는 반복 가능한 객체의 요소를 누적하여 단일 값을 반환합니다. 이 함수는 functools 모듈에서 제공됩니다.

사용법

from functools import reduce

reduce(function, iterable[, initializer])

function: 누적 결과를 처리할 함수.
iterable: 반복 가능한 데이터(iterable).
initializer(선택): 초기값.

예제

from functools import reduce

numbers = [1, 2, 3, 4, 5]
product = reduce(lambda x, y: x * y, numbers)
print(product)  # 120 (1*2*3*4*5)

5. `lambda` 함수

lambda 함수는 이름 없는 익명 함수로, 간단한 함수를 짧게 정의할 때 유용합니다.

사용법

lambda arguments: expression

예제

add = lambda x, y: x + y
print(add(3, 5))  # 8

lambda 함수는 map(), filter(), reduce()와 함께 사용하면 더욱 강력합니다.

6. 재귀 함수 (Recursive Function)

재귀 함수는 함수가 자기 자신을 호출하는 구조로, 특정 문제를 반복적으로 쪼개어 해결합니다.

예제: 팩토리얼 계산

def factorial(n):
    if n == 1:
        return 1
    return n * factorial(n - 1)

print(factorial(5))  # 120

재귀는 간결한 코드 작성을 가능하게 하지만, 무한 루프에 빠지지 않도록 종료 조건이 필수적입니다.

7. 클로저 (Closures)

클로저는 함수가 정의될 때의 변수 환경을 기억하여, 외부 함수의 변수를 참조하는 내부 함수를 반환합니다.

예제

def multiplier(factor):
    def multiply(number):
        return number * factor
    return multiply

double = multiplier(2)
print(double(5))  # 10

클로저는 외부 상태를 유지하면서도 캡슐화를 제공하여 함수형 프로그래밍에서 자주 사용됩니다.

함수형 프로그래밍의 장점

코드 가독성: 데이터 변환 과정을 간결하고 명확하게 표현.
재사용성: 고차 함수와 익명 함수로 유연한 코드 작성.
버그 감소: 불변성을 통해 데이터 변경으로 인한 버그를 줄임.

함수형 프로그래밍의 단점

복잡한 로직: 지나치게 많은 중첩된 함수 사용 시 가독성 저하.
재귀 한계: Python의 재귀 깊이 제한으로 인해 스택 오버플로우 위험.

Python의 함수형 프로그래밍 도구는 데이터를 변환하고 필터링하며, 복잡한 문제를 간결하게 해결하는 데 유용합니다. map(), filter(), reduce()와 같은 함수와 lambda, 재귀 함수, 클로저를 활용하여 더욱 효율적이고 깔끔한 코드를 작성할 수 있습니다.

[Python] 시간과 날짜 처리

Theo (테오) — Sat, 23 Nov 2024 21:58:46 +0900

Python은 날짜와 시간을 다루기 위한 강력한 모듈들을 제공합니다. datetime, time, calendar 모듈을 활용하면 다양한 날짜와 시간 작업을 간단히 수행할 수 있습니다. 이 글에서는 날짜와 시간을 다루는 기본적인 방법, 시간 계산, 특정 포맷 변환 등 유용한 기능들을 소개합니다.

1. `datetime` 모듈: 날짜와 시간 처리의 기본

datetime 모듈은 날짜와 시간 정보를 생성, 조작, 포맷팅 하는 데 사용됩니다.

날짜와 시간 생성

from datetime import datetime

# 현재 날짜와 시간
now = datetime.now()
print("현재 날짜와 시간:", now)

# 특정 날짜와 시간
specific_date = datetime(2024, 12, 25, 15, 30)
print("특정 날짜와 시간:", specific_date)

날짜와 시간 분리

datetime 객체에서 연도, 월, 일, 시간 등을 추출할 수 있습니다.

print("연도:", now.year)
print("월:", now.month)
print("일:", now.day)
print("시간:", now.hour)
print("분:", now.minute)
print("초:", now.second)

날짜와 시간 포맷팅

strftime 메서드를 사용하여 날짜와 시간을 문자열로 포맷할 수 있습니다.

formatted_date = now.strftime("%Y-%m-%d %H:%M:%S")
print("포맷된 날짜와 시간:", formatted_date)

포맷 코드:

%Y: 4자리 연도
%m: 2자리 월
%d: 2자리 일
%H: 24시간 형식의 시간
%M: 분
%S: 초

2. `time` 모듈: 시간 조작

time 모듈은 주로 시간 간격, Unix 타임스탬프를 처리하거나 특정 작업을 지연시키는 데 사용됩니다.

현재 시간 (Unix 타임스탬프)

import time

# 현재 시간
timestamp = time.time()
print("현재 타임스탬프:", timestamp)

시간 지연

time.sleep()를 사용하여 프로그램 실행을 일시 중지할 수 있습니다.

print("3초 대기 중...")
time.sleep(3)
print("다시 실행")

3. `calendar` 모듈: 달력 작업

calendar 모듈은 달력을 생성하거나 특정 날짜의 요일을 확인하는 데 유용합니다.

연도와 월의 달력 출력

import calendar

# 2024년 11월의 달력
print(calendar.month(2024, 11))

특정 날짜의 요일 확인

# 요일 반환 (0: 월요일, 6: 일요일)
weekday = calendar.weekday(2024, 11, 11)
print("2024년 11월 11일의 요일:", calendar.day_name[weekday])  # "Monday"

윤년 확인

# 윤년인지 확인
is_leap = calendar.isleap(2024)
print("2024년은 윤년인가요?", is_leap)

4. 시간 계산

timedelta 객체를 사용하면 날짜와 시간 간격을 쉽게 계산할 수 있습니다.

날짜 더하기 및 빼기

from datetime import timedelta

# 현재 날짜
today = datetime.now()

# 7일 후
next_week = today + timedelta(days=7)
print("7일 후:", next_week)

# 30일 전
last_month = today - timedelta(days=30)
print("30일 전:", last_month)

두 날짜 간의 차이

# 특정 날짜
future_date = datetime(2025, 1, 1)

# 날짜 차이 계산
difference = future_date - today
print("2025년 1월 1일까지 남은 일수:", difference.days)

5. 문자열과 날짜 간 변환

문자열 → 날짜 (`strptime`)

strptime 메서드를 사용해 문자열을 datetime 객체로 변환할 수 있습니다.

date_string = "2024-11-11 15:30:00"
parsed_date = datetime.strptime(date_string, "%Y-%m-%d %H:%M:%S")
print("문자열에서 변환된 날짜:", parsed_date)

날짜 → 문자열 (`strftime`)

반대로 datetime 객체를 포맷팅 하여 문자열로 변환할 수 있습니다.

formatted_string = parsed_date.strftime("%A, %d %B %Y")
print("포맷된 문자열:", formatted_string)  # 예: "Monday, 11 November 2024"

6. 타임존 처리

pytz 라이브러리를 사용하면 타임존을 쉽게 다룰 수 있습니다.

타임존 추가

pip install pytz

from datetime import datetime
import pytz

# UTC 시간
utc_time = datetime.now(pytz.UTC)
print("UTC 시간:", utc_time)

# 특정 타임존으로 변환
korea_time = utc_time.astimezone(pytz.timezone("Asia/Seoul"))
print("한국 시간:", korea_time)

Python의 datetime, time, calendar 모듈은 날짜와 시간을 다루는 데 필요한 강력한 도구를 제공합니다. 날짜와 시간을 계산하거나 포맷팅, 변환하는 작업을 손쉽게 처리할 수 있으며, 타임존 처리 및 시간 간격 계산 같은 고급 작업도 가능합니다.

[OpenCV] Basic 14 - 텍스트 추가하기 (Add Text)

Theo (테오) — Fri, 22 Nov 2024 00:12:26 +0900

OpenCV에서는 이미지에 텍스트를 추가하여 설명이나 주석을 넣을 수 있습니다. 예를 들어, 객체 인식 후 객체의 이름을 표시하거나, 특정 위치에 정보를 표시할 때 유용하게 사용할 수 있습니다. putText 함수를 사용하여 이미지를 원하는 스타일과 위치로 꾸밀 수 있습니다.

Import packages

import cv2
import numpy as np
import matplotlib.pyplot as plt

Function to Display Images in Jupyter Notebook

Jupyter Notebook 및 Google Colab에서 이미지를 표시할 수 있도록 Function으로 정의합니다.

def img_show(title='image', img=None, figsize=(8, 5)):
    plt.figure(figsize=figsize)

    if type(img) == list:
        titles = title if type(title) == list else [title] * len(img)

        for i in range(len(img)):
            rgbImg = cv2.cvtColor(img[i], cv2.COLOR_GRAY2RGB) if len(img[i].shape) <= 2 else cv2.cvtColor(img[i], cv2.COLOR_BGR2RGB)
            plt.subplot(1, len(img), i + 1)
            plt.imshow(rgbImg)
            plt.title(titles[i])
            plt.xticks([]), plt.yticks([])

        plt.show()
    else:
        rgbImg = cv2.cvtColor(img, cv2.COLOR_GRAY2RGB) if len(img.shape) < 3 else cv2.cvtColor(img, cv2.COLOR_BGR2RGB)
        plt.imshow(rgbImg)
        plt.title(title)
        plt.xticks([]), plt.yticks([])
        plt.show()

Load Image

이미지를 불러옵니다.

cv2_image = cv2.imread('asset/images/test_image.jpg')
img_show("Original Image", cv2_image)

1. 기본적인 텍스트 추가 (Basic Text)

putText 함수를 사용해 텍스트를 이미지에 추가할 수 있습니다. 주요 파라미터로는 텍스트 내용, 위치, 글꼴, 크기, 색상, 두께 등이 있습니다.

text_image = cv2_image.copy()
text = "Hello, OpenCV!"
position = (50, 50)  # 텍스트의 시작 좌표 (x, y)
font = cv2.FONT_HERSHEY_SIMPLEX  # 글꼴 설정
font_scale = 0.5  # 글꼴 크기
color = (255, 0, 0)  # 텍스트 색상 (파란색)
thickness = 1  # 텍스트 두께

cv2.putText(text_image, text, position, font, font_scale, color, thickness)
img_show("Text Added", text_image)

2. 다양한 글꼴 사용

OpenCV는 여러 가지 기본 글꼴을 제공합니다. 필요에 따라 다른 글꼴을 선택할 수 있습니다.

font_styles = [
    cv2.FONT_HERSHEY_SIMPLEX,
    cv2.FONT_HERSHEY_COMPLEX,
    cv2.FONT_HERSHEY_DUPLEX,
    cv2.FONT_HERSHEY_TRIPLEX,
    cv2.FONT_HERSHEY_COMPLEX_SMALL,
    cv2.FONT_HERSHEY_SCRIPT_SIMPLEX,
    cv2.FONT_HERSHEY_SCRIPT_COMPLEX
]

text_image = cv2_image.copy()
y = 20
for font in font_styles:
    cv2.putText(text_image, f"Font Style {font}", (10, y), font, 0.5, (0, 255, 0), 1)
    y += 30  # Y 좌표를 아래로 이동하여 각 글꼴을 보여줌

img_show("Various Fonts", text_image)

3. 텍스트 크기와 두께 변경

font_scale와 thickness 값을 조절하여 텍스트의 크기와 두께를 변경할 수 있습니다.

text_image = cv2_image.copy()
cv2.putText(text_image, "Small Thin Text", (10, 50), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 255), 1)
cv2.putText(text_image, "Large Bold Text", (10, 100), cv2.FONT_HERSHEY_SIMPLEX, 1.5, (255, 255, 0), 3)
img_show("Text Size and Thickness", text_image)

4. 텍스트 배경 추가 (Text with Background)

텍스트를 가독성 있게 만들기 위해 배경 색상을 추가할 수 있습니다. 먼저 배경을 그린 다음, 그 위에 텍스트를 추가합니다.

text_image = cv2_image.copy()
text = "Text with Background"
position = (30, 130)

# 텍스트 크기 측정
(text_width, text_height), _ = cv2.getTextSize(text, font, font_scale, thickness)

# 배경 그리기
cv2.rectangle(text_image, (position[0], position[1] - text_height), (position[0] + text_width, position[1]), (0, 0, 0), -1)

# 텍스트 그리기
cv2.putText(text_image, text, position, font, font_scale, (255, 255, 255), thickness)
img_show("Text with Background", text_image)

5. 텍스트 회전 (Rotated Text)

OpenCV에서 텍스트 회전을 직접 지원하지 않으므로, 먼저 빈 이미지를 만들고 텍스트를 추가한 후 회전하는 방식으로 구현합니다.

# 텍스트가 포함될 빈 이미지 생성
text_image = np.zeros_like(cv2_image)

# 텍스트 추가
text = "Rotated Text"
position = (50, 150)
cv2.putText(text_image, text, position, font, font_scale, (255, 255, 255), thickness)

# 이미지 회전
center = (position[0] + 100, position[1] - 20)
rotated_matrix = cv2.getRotationMatrix2D(center, 45, 1.0)
rotated_text = cv2.warpAffine(text_image, rotated_matrix, (text_image.shape[1], text_image.shape[0]))

# 원본 이미지와 합치기
combined_image = cv2.addWeighted(cv2_image, 1, rotated_text, 1, 0)
img_show("Rotated Text", combined_image)

요약

putText 함수를 사용하여 이미지에 다양한 스타일의 텍스트를 추가할 수 있습니다. 텍스트 크기, 색상, 두께뿐 아니라 배경을 넣거나 회전된 텍스트를 추가하는 등 다양한 응용이 가능합니다. 텍스트 추가는 이미지에 설명이나 주석을 넣어 이미지의 의미를 전달하는 데 유용하게 활용됩니다.

[OpenCV] Basic 13 - 윤곽선 검출 (Contour Detection)

Theo (테오) — Thu, 21 Nov 2024 00:38:28 +0900

윤곽선 검출은 이미지 내 객체의 경계를 찾아내는 방법으로, 주로 이미지에서 객체를 분리하거나 추적할 때 사용됩니다. OpenCV에서 findContours 함수를 이용해 윤곽선을 검출할 수 있습니다. 윤곽선은 연속된 경계의 좌표 목록으로 반환되며, 이를 활용해 윤곽선을 그리거나 특정 모양을 검출할 수 있습니다.

Import packages

import cv2
import numpy as np
import matplotlib.pyplot as plt

Function to Display Images in Jupyter Notebook

Jupyter Notebook 및 Google Colab에서 이미지를 표시할 수 있도록 Function으로 정의합니다.

def img_show(title='image', img=None, figsize=(8, 5)):
    plt.figure(figsize=figsize)

    if type(img) == list:
        titles = title if type(title) == list else [title] * len(img)

        for i in range(len(img)):
            rgbImg = cv2.cvtColor(img[i], cv2.COLOR_GRAY2RGB) if len(img[i].shape) <= 2 else cv2.cvtColor(img[i], cv2.COLOR_BGR2RGB)
            plt.subplot(1, len(img), i + 1)
            plt.imshow(rgbImg)
            plt.title(titles[i])
            plt.xticks([]), plt.yticks([])

        plt.show()
    else:
        rgbImg = cv2.cvtColor(img, cv2.COLOR_GRAY2RGB) if len(img.shape) < 3 else cv2.cvtColor(img, cv2.COLOR_BGR2RGB)
        plt.imshow(rgbImg)
        plt.title(title)
        plt.xticks([]), plt.yticks([])
        plt.show()

Load Image

이미지를 불러옵니다.

cv2_image = cv2.imread('asset/images/test_image.jpg')
gray_image = cv2.cvtColor(cv2_image, cv2.COLOR_BGR2GRAY)

1. 이미지 이진화 (Binary Thresholding)

윤곽선 검출을 하기 전에 이미지를 이진화(흑백)하여 경계선만 남기도록 만듭니다. threshold 함수를 사용해 간단한 이진화를 적용할 수 있습니다.

ret, thresh_image = cv2.threshold(gray_image, 50, 255, cv2.THRESH_BINARY)
img_show(["Original Image", "Thresholded Image"], [cv2_image, thresh_image])

2. 윤곽선 검출 (Contour Detection)

findContours 함수를 사용하여 이미지에서 윤곽선을 검출합니다. 검출된 윤곽선은 contours 리스트에 저장되며, 각 윤곽선의 좌표 정보를 가지고 있습니다.

contours, hierarchy = cv2.findContours(thresh_image, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
print(f"Number of contours found: {len(contours)}")

RETR_EXTERNAL: 가장 바깥쪽 윤곽선만 검출합니다.
CHAIN_APPROX_SIMPLE: 윤곽선의 꼭짓점만 저장하여 메모리 사용을 줄입니다.

3. 윤곽선 그리기 (Draw Contours)

검출된 윤곽선을 원본 이미지에 그려서 시각화할 수 있습니다. drawContours 함수를 사용하여 윤곽선을 그립니다.

contour_image = cv2_image.copy()
cv2.drawContours(contour_image, contours, -1, (0, 255, 0), 10)
img_show("Contours", contour_image)

contours: 검출된 윤곽선 리스트
-1: 모든 윤곽선을 그립니다. 특정 윤곽선만 그리려면 인덱스를 사용합니다.
(0, 255, 0): 윤곽선의 색상 (녹색)
10: 윤곽선 두께

4. 윤곽선의 특징 계산

윤곽선 검출 후 각 윤곽선의 면적과 둘레를 계산할 수 있습니다. 예를 들어, 첫 번째 윤곽선의 면적과 둘레는 다음과 같이 계산할 수 있습니다.

# 첫 번째 윤곽선의 면적과 둘레
area = cv2.contourArea(contours[0])
perimeter = cv2.arcLength(contours[0], True)

print(f"Contour Area: {area}")
print(f"Contour Perimeter: {perimeter}")

5. 윤곽선 근사화 및 경계 상자 그리기

윤곽선의 복잡도를 줄이기 위해 근사화하여 경계 상자(Rectangle) 또는 다각형을 그릴 수 있습니다. 이 방법은 특정 모양을 검출할 때 유용합니다.

# 윤곽선을 직사각형 경계 상자로 표시
for contour in contours:
    x, y, w, h = cv2.boundingRect(contour)
    cv2.rectangle(contour_image, (x, y), (x + w, y + h), (255, 255, 255), 10)

img_show("Bounding Boxes", contour_image)

위 코드에서는 각 윤곽선을 둘러싸는 경계 상자를 생성하고, 이를 이미지에 그립니다.

요약

윤곽선 검출은 이미지에서 객체를 식별하고, 모양과 크기 분석을 수행하는 데 유용한 기법입니다. OpenCV를 사용해 다양한 윤곽선 검출 방법을 적용하고, 특징을 추출하여 이미지 분석에 활용할 수 있습니다.

[OpenCV] Basic 12 - 이미지 필터 (Filters) 적용

Theo (테오) — Wed, 20 Nov 2024 11:34:44 +0900

이미지 필터는 이미지에 다양한 효과를 적용하거나, 특정 특징을 강조하고 노이즈를 제거하는 데 사용됩니다. OpenCV는 여러 가지 필터를 제공하며, 상황에 따라 적절한 필터를 선택해 이미지를 처리할 수 있습니다. 기본적으로 많이 사용하는 필터에는 블러링 필터와 샤프닝 필터, 엠보싱 필터가 있습니다.

Import packages

import cv2
import numpy as np
import matplotlib.pyplot as plt

Function to Display Images in Jupyter Notebook

Jupyter Notebook 및 Google Colab에서 이미지를 표시할 수 있도록 Function으로 정의합니다.

def img_show(title='image', img=None, figsize=(8, 5)):
    plt.figure(figsize=figsize)

    if type(img) == list:
        titles = title if type(title) == list else [title] * len(img)

        for i in range(len(img)):
            rgbImg = cv2.cvtColor(img[i], cv2.COLOR_GRAY2RGB) if len(img[i].shape) <= 2 else cv2.cvtColor(img[i], cv2.COLOR_BGR2RGB)
            plt.subplot(1, len(img), i + 1)
            plt.imshow(rgbImg)
            plt.title(titles[i])
            plt.xticks([]), plt.yticks([])

        plt.show()
    else:
        rgbImg = cv2.cvtColor(img, cv2.COLOR_GRAY2RGB) if len(img.shape) < 3 else cv2.cvtColor(img, cv2.COLOR_BGR2RGB)
        plt.imshow(rgbImg)
        plt.title(title)
        plt.xticks([]), plt.yticks([])
        plt.show()

Load Image

이미지를 불러옵니다.

cv2_image = cv2.imread('asset/images/test_image.jpg')
img_show("Original Image", cv2_image)

1. 평균 블러 (Average Blur)

평균 블러는 주변 픽셀의 평균값을 사용하여 이미지의 노이즈를 제거하고 부드러운 효과를 만듭니다.

2. 가우시안 블러 (Gaussian Blur)

가우시안 블러는 가우시안 커널을 사용하여 이미지를 부드럽게 처리합니다. 이 방식은 노이즈 제거에 유용하며, 특히 Gaussian 분포에 따라 가중치를 적용해 블러링 효과를 줄 수 있습니다.

3. 미디안 블러 (Median Blur)

미디안 블러는 커널 내 픽셀 값의 중간값으로 대체하여 노이즈를 제거합니다. 특히 점 노이즈(Salt and Pepper Noise)를 제거하는 데 효과적입니다.

average_blur = cv2.blur(cv2_image, (5, 5))
gaussian_blur = cv2.GaussianBlur(cv2_image, (5, 5), 0)
median_blur = cv2.medianBlur(cv2_image, 5)
img_show(["Average Blur", "Gaussian Blur", "Median Blur"], [average_blur, gaussian_blur, median_blur])

4. 샤프닝 필터 (Sharpening)

샤프닝 필터는 이미지를 더 선명하게 만들어주며, 엣지(Edge)를 강조하는 효과가 있습니다. 커널을 직접 정의하여 샤프닝을 적용할 수 있습니다.

# 샤프닝 커널 생성
sharpening_kernel = np.array([[0, -1, 0], 
                              [-1, 5, -1], 
                              [0, -1, 0]])
sharpened_image = cv2.filter2D(cv2_image, -1, sharpening_kernel)
img_show("Sharpened Image", sharpened_image)

5. 엠보싱 필터 (Emboss)

엠보싱 필터는 이미지에 입체감(엠보싱) 효과를 부여합니다. 주로 회색조 이미지에 적용하며, 커널을 사용해 엠보싱 효과를 줍니다.

# 엠보싱 커널 생성
emboss_kernel = np.array([[-2, -1, 0], 
                          [-1, 1, 1], 
                          [0, 1, 2]])
emboss_image = cv2.filter2D(cv2_image, -1, emboss_kernel)
img_show("Embossed Image", emboss_image)

6. 커스텀 필터 (Custom Filter)

사용자가 원하는 커널을 정의하여 특정 효과를 줄 수 있습니다. 예를 들어, 엣지 검출, 흐림, 선명함 등 다양한 효과를 직접 만들 수 있습니다.

# 예시: 간단한 엣지 검출 필터
edge_kernel = np.array([[-1, -1, -1],
                        [-1, 8, -1],
                        [-1, -1, -1]])
edge_image = cv2.filter2D(cv2_image, -1, edge_kernel)
img_show("Edge Detection Filter", edge_image)

요약

이미지 필터를 통해 다양한 효과를 적용하여 이미지의 노이즈를 줄이거나, 경계를 강조하고, 입체감을 줄 수 있습니다. OpenCV의 기본 필터뿐만 아니라 커스텀 커널을 활용하여 원하는 효과를 자유롭게 적용할 수 있습니다.

[OpenCV] Basic 11 - 이미지 히스토그램 (Histogram) 분석

Theo (테오) — Tue, 19 Nov 2024 00:11:38 +0900

이미지 히스토그램은 이미지에서 색상 분포나 밝기 정보를 시각적으로 표현한 그래프입니다. 히스토그램을 분석하면 이미지의 명도, 대비, 색상 정보를 알 수 있어 이미지 처리에서 중요한 역할을 합니다. 예를 들어, 히스토그램을 사용해 이미지의 밝기나 대비를 조정할 수 있습니다.

Import packages

import cv2
import numpy as np
import matplotlib.pyplot as plt

Function to Display Images in Jupyter Notebook

Jupyter Notebook 및 Google Colab에서 이미지를 표시할 수 있도록 Function으로 정의합니다.

def img_show(title='image', img=None, figsize=(8, 5)):
    plt.figure(figsize=figsize)

    if type(img) == list:
        titles = title if type(title) == list else [title] * len(img)

        for i in range(len(img)):
            rgbImg = cv2.cvtColor(img[i], cv2.COLOR_GRAY2RGB) if len(img[i].shape) <= 2 else cv2.cvtColor(img[i], cv2.COLOR_BGR2RGB)
            plt.subplot(1, len(img), i + 1)
            plt.imshow(rgbImg)
            plt.title(titles[i])
            plt.xticks([]), plt.yticks([])

        plt.show()
    else:
        rgbImg = cv2.cvtColor(img, cv2.COLOR_GRAY2RGB) if len(img.shape) < 3 else cv2.cvtColor(img, cv2.COLOR_BGR2RGB)
        plt.imshow(rgbImg)
        plt.title(title)
        plt.xticks([]), plt.yticks([])
        plt.show()

Load Image

이미지를 불러옵니다.

cv2_image = cv2.imread('asset/images/test_image.jpg')

1. Grayscale 히스토그램

Grayscale 이미지의 히스토그램은 이미지의 밝기 분포를 나타냅니다. 히스토그램의 x축은 밝기 값 (0~255), y축은 각 밝기 값의 픽셀 개수를 나타냅니다.

gray_image = cv2.cvtColor(cv2_image, cv2.COLOR_BGR2GRAY)
hist = cv2.calcHist([gray_image], [0], None, [256], [0, 256])

plt.figure(figsize=(8, 5))
plt.plot(hist, color='black')
plt.title("Grayscale Histogram")
plt.xlabel("Pixel Value")
plt.ylabel("Frequency")
plt.show()

2. RGB 히스토그램

컬러 이미지의 경우 각 채널(BGR)에 대해 별도의 히스토그램을 그릴 수 있습니다. 이를 통해 이미지에서 각 색상의 분포를 확인할 수 있습니다.

colors = ('b', 'g', 'r')
plt.figure(figsize=(8, 5))

for i, color in enumerate(colors):
    hist = cv2.calcHist([cv2_image], [i], None, [256], [0, 256])
    plt.plot(hist, color=color)
    plt.xlim([0, 256])

plt.title("RGB Histogram")
plt.xlabel("Pixel Value")
plt.ylabel("Frequency")
plt.show()

3. 히스토그램 평활화 (Histogram Equalization)

히스토그램 평활화는 이미지의 대비를 개선하여 더 뚜렷한 이미지를 얻는 데 유용합니다. 이 방법은 이미지의 픽셀 밝기 값을 재분배하여, 히스토그램이 고르게 분포되도록 합니다.

Grayscale 이미지 평활화:

equalized_image = cv2.equalizeHist(gray_image)

# 원본 및 평활화 이미지 비교
img_show(["Original Grayscale", "Equalized Image"], [gray_image, equalized_image])

# 평활화 이미지의 히스토그램
equalized_hist = cv2.calcHist([equalized_image], [0], None, [256], [0, 256])

plt.figure(figsize=(8, 5))
plt.plot(equalized_hist, color='black')
plt.title("Equalized Grayscale Histogram")
plt.xlabel("Pixel Value")
plt.ylabel("Frequency")
plt.show()

4. CLAHE (Contrast Limited Adaptive Histogram Equalization)

CLAHE는 히스토그램 평활화의 개선된 방법으로, 작은 영역마다 히스토그램을 평활화하여 지나친 밝기 왜곡을 방지합니다. 이는 특히 조명이 고르지 않은 이미지에 유용합니다.

clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8, 8))
clahe_image = clahe.apply(gray_image)

# 원본 및 CLAHE 적용 이미지 비교
img_show(["Original Grayscale", "CLAHE Image"], [gray_image, clahe_image])

# CLAHE 이미지 히스토그램
clahe_hist = cv2.calcHist([clahe_image], [0], None, [256], [0, 256])

plt.figure(figsize=(8, 5))
plt.plot(clahe_hist, color='black')
plt.title("CLAHE Histogram")
plt.xlabel("Pixel Value")
plt.ylabel("Frequency")
plt.show()

요약

이미지 히스토그램은 이미지의 밝기와 색상 분포를 시각화하여 이미지의 특성을 분석하는 데 유용합니다. 히스토그램 평활화와 CLAHE는 이미지 대비를 개선하여 더 나은 시각적 품질을 제공합니다. 히스토그램을 활용해 이미지 분석 및 전처리를 효과적으로 수행할 수 있습니다.

[Python] 제너레이터 (Generator)

Theo (테오) — Mon, 18 Nov 2024 00:04:58 +0900

Python에서 제너레이터(Generator)는 큰 데이터를 메모리에 효율적으로 처리할 수 있게 도와주는 특별한 이터레이터입니다. 일반적인 함수와 달리, 제너레이터는 값을 한 번에 하나씩 반환하고, 매번 호출될 때 이전 상태를 기억합니다. 제너레이터는 yield 키워드를 사용하여 값을 반환하며, return을 사용하면 더 이상 값을 생성하지 않고 종료됩니다

제너레이터의 특징

메모리 효율성: 제너레이터는 값을 필요할 때마다 하나씩 생성하므로, 큰 데이터를 처리할 때 메모리를 아낄 수 있습니다.
Lazy Evaluation(지연 평가): 모든 값을 한꺼번에 생성하지 않고, 요청할 때마다 값을 생성하여 반환합니다.
상태 유지: yield 키워드 덕분에 함수의 상태가 유지되며, 중단된 위치에서 다시 시작할 수 있습니다.

기본 예제: 간단한 제너레이터 함수

아래의 예제는 yield를 사용하여 1부터 3까지의 값을 하나씩 반환하는 제너레이터 함수입니다.

def simple_generator():
    yield 1
    yield 2
    yield 3

for value in simple_generator():
    print(value)
# 출력:
# 1
# 2
# 3

yield가 호출될 때마다 함수의 상태를 기억하며, 다음 for 루프에서 호출하면 이전 위치에서 다시 시작합니다.

제너레이터로 큰 데이터 처리하기

일반적으로 range() 함수를 사용할 때 큰 범위를 다루게 되면 많은 메모리를 차지하게 됩니다. 이럴 때 제너레이터를 사용하면 효율적으로 메모리를 사용할 수 있습니다.

def large_range(n):
    for i in range(n):
        yield i

for number in large_range(100):
    print(number)
# 이 예제에서는 0부터 100까지의 값을 생성하면서, 매번 하나씩 출력합니다.

제너레이터 표현식

제너레이터 표현식은 리스트 내포와 비슷한 문법을 사용하여 간단히 제너레이터를 생성할 수 있습니다. () 괄호를 사용해 리스트 내포를 제너레이터로 변환합니다.

squared_numbers = (x**2 for x in range(5))
for num in squared_numbers:
    print(num)
# 출력:
# 0
# 1
# 4
# 9
# 16

`yield`와 `return`의 차이점

yield는 값을 반환하면서 함수의 상태를 유지하고, 다음에 호출될 때 이어서 실행됩니다.
return은 값을 반환하고 함수의 실행을 종료합니다.

제너레이터는 메모리 효율성을 높이고, 큰 데이터 처리를 쉽게 해주는 Python의 중요한 도구입니다. 큰 데이터 파일을 읽거나, 연속적인 계산을 처리할 때 매우 유용합니다.

Anthropic의 프롬프트 엔지니어링 도구: Prompt Improver 출시

Theo (테오) — Sun, 17 Nov 2024 00:51:52 +0900

앤트로픽(Anthropic)이 11월 15일, 개발자들을 위한 새로운 프롬프트 엔지니어링 도구를 공개했습니다. 프롬프트 최적화와 예시 관리를 자동화할 수 있는 이 도구들에 대해 자세히 살펴보겠습니다.

Improve your prompts in the developer console

Today, we're introducing the ability to improve prompts and manage examples directly in the Anthropic Console.

www.anthropic.com

프롬프트의 품질이 AI의 품질을 결정

AI 모델과 대화할 때 우리가 어떤 방식으로 질문하고 지시하느냐에 따라 결과물의 품질이 크게 달라집니다. 이를 '프롬프트 엔지니어링'이라고 하는데, 사실 이 작업이 만만치 않습니다. AI 모델마다 다른 방식으로 접근해야 하고, 최적의 결과를 얻기 위한 노하우도 필요합니다.

앤트로픽은 이런 문제를 해결하기 위해 'Prompt Improver'를 개발하여 발표했습니다.

Prompt Improver의 주요 기능

프롬프트 임프루버의 핵심은 기존 프롬프트를 자동으로 최적화한다는 점입니다. 다음과 같은 방법들을 활용합니다:

1. 사고의 흐름 추가 (Chain-of-thought reasoning)

AI가 문제를 체계적으로 분석하고 해결하도록 단계별 사고 과정 추가
정확도와 신뢰성 향상에 큰 도움

2. 예시 표준화 (Example standardization)

XML 형식을 활용한 일관된 예시 구조화
명확한 입/출력 형식 제시

3. 예시 강화 (Example enrichment)

구조화된 프롬프트에 맞춰 기존 예시들을 보강
사고 과정이 반영된 더 풍부한 예시 제공

4. 자동 개선 (Rewriting)

문법이나 맞춤법 오류 수정
구조를 더 명확하게 다듬기

5. 응답 가이드 추가 (Prefill addition)

Claude의 응답 방향을 명확히 지정
원하는 출력 형식을 정확히 얻을 수 있도록 안내

검증된 성능 향상

이 도구의 효과는 이미 실제 테스트에서 입증되었습니다:

다중 라벨 분류 작업에서 정확도 30% 향상
요약 작업에서 단어 수 제한 준수율 100% 달성

통합 예시 관리 시스템

프롬프트에 적절한 예시를 추가하는 것만으로도 AI의 응답 품질이 크게 개선될 수 있습니다. 이번에 추가된 예시 관리 기능을 통해 더욱 체계적인 예시 관리가 가능해졌습니다.

구조화된 형식으로 예시 관리 가능
입력/출력 쌍을 명확하게 정의
Claude를 활용한 자동 예시 생성 기능

앤트로픽 콘솔에서 바로 사용 가능

프롬프트 임프루버, 예시 관리, 이상적인 출력 설정 등 소개된 모든 기능은 현재 앤트로픽 콘솔에서 사용할 수 있습니다. 앤트로픽 콘솔에서는 다음과 같은 세 가지 방식으로 프롬프트를 작업할 수 있습니다:

Write a prompt from scratch (프롬프트 직접 작성)
- 새로운 프롬프트를 처음부터 작성
- 구조화된 템플릿 제공
- 모범 사례 가이드라인 참조 가능
Generate a prompt (프롬프트 자동 생성)
- 원하는 작업 설명 입력
- AI가 자동으로 최적화된 프롬프트 생성
- 생성된 프롬프트 추가 수정 가능
Improve an existing prompt (기존 프롬프트 개선)
- 기존 프롬프트 업로드
- 자동 최적화 및 구조화
- 단계별 개선 과정 확인

더 자세한 사용 방법은 앤트로픽의 공식 문서를 통해 확인할 수 있습니다.