보통 ingress(inbound)만 열심히 방어하지 egress(outbound)까지 막아야되는 경우는 잘 없죠.보안이라는게 참 비용도 많이 들고 요구 사항을 모두 커버하는 네트워크를 구성하기가 참 쉽지가 않습니다.특히 기존에 서비스를 운영하고 있다면 기존 아키텍처를 호환/유지해야되는데SW라면 모를까 하필 최하단의 네트워크를 건들기란 참 쉽지 않은 길입니다.하지만 저는 그 길을 걸어보았고그 여정에 대한 발자취를 공유하고자 합니다.그럼 수요 없는 공급인 centralized egress vpc를 향한 여정 출발합니다.AWS를 사용하면 전공수업 잘 들어둘껄이란 생각을 하게 되는 서비스인 VPC입니다.처음에 아무런 지식 없이 AWS에서 MVP레벨의 서비스를 구축하게 되면 요런 모습을 가집니다.저도 처음 AWS를 사용했을때 이렇게 만들었던거 같네요 ㅎㅎ...그냥 EC2에 Elastic IP(EIP)를 달고 도메인 연결하고spring mvc, tomcat, mysql, redis 다 때려박아서 서비스를 했던 기억이 있습니다.당연히 이렇게 된다면 EC2를 재시작하거나 트래픽이 몰리거나 DB에 부하가 생기면 서비스에 장애가 생기겠죠?그래서 Scaling 가능한 구조로 바꾸기 위해서 AWS에서 제공해주는 Managed Service를 도입하게 됩니다.가장 처음으로 도입하는게 Elastic Load Balancer(ELB)와 Auto Scaling Group, RDS, ElastiCache이죠.Auto Scaling Group을 사용해서 웹서버인 EC2를 Scaling하고ELB 서비스에서 제공하는 ALB(Application Load Balancer)를 사용해서 Scaling되는 EC2를 라우팅해주고RDS, ElastiCache를 사용해서 DB를 Scaling하는 아주 기초적인 구조입니다.보안을 아주 살짝 곁들여봅시다잘동작하고 돈만 많다면(?) 기존 구조로도 안정적으로 서비스할 수 있겠죠?하지만 Auto Scaling Group에 있는 EC2와 RDS, ElastiCache 등이 외부에 노출되기 때문에보안을 위해서 그 다음 스탭으로는 아래와 같이 네트워크를 분리해서 구성합니다.외부에 서버나 DB를 직접 노출하지 않기 위해서죠.위처럼 구성한다면 EC2, ElastiCache, RDS 등에 EIP(=Public IP)를 주지 않아도 되고그러면 외부에서 서버에 접근할 방법이 없기 때문에 안전합니다.다만 이러면 EC2는 Public IP가 없이 때문에 인터넷이 안되는데EC2의 인터넷 통신을 위해서 중간에 NAT Gateway(NAT)를 두고 EIP를 할당해서EC2는 NAT를 통해서 Public IP를 할당 받아서 인터넷 통신을 할 수 있게 됩니다.그래서 보통 Public Subnet에는 NAT와 ELB만 두고Private Subnet에는 웹서버 역할을 하는 EC2만 두고DB Subnet에는 DB만 둬서 외부 공격에 대해 네트워크 레벨로 방어진을 구성합니다.ALB 앞단에 NLB(Network Load Balancer)를 둬서 정적IP를 사용자에게 제공할 수 있습니다.이러면 사용자가 접근해야되는 시스템에서 방화벽에 IP를 등록해야된다고 하면 우린 NLB의 EIP를 알려주면 되죠.대신 기존에 ALB에 연결했던 도메인을 NLB로 옮겨줘야되긴 합니다.이정도면 외부 공격에 대해서 모두 막은걸까?보안이란게 100%는 불가능하지만지금 구조라면 약간 아쉬운점이 있습니다.바로 가장 기본적인 DDoS나 SQL Injection, 악성 봇 등에 대한 방어가 없죠!!ORM만 써도 SQL Injection을 막을 순 있다곤 하지만그건 정말 기본적인 안전장치이고 네트워크 레벨에서 1차적으로 막아주는게 가장 중요합니다.그래서 도입하게 되는게 바로 WAF(Web Application Firewall)라는 서비스죠.서드파티 방화벽을 쓰는 경우도 보긴 했는데 WAF 정도만 달아줘도 대부분의 공격을 잘 막아주긴 합니다.다만 비싼게 흠이긴한데 DDoS 한번 당해보면 싸다고 느껴지실겁니다.요금제는 트래픽당 과금 방식이라 대충 얼마 나온다고 예측하기 힘들기 때문에 직접 보고 판단하시는게 좋습니다.아래 링크에서 요금 예시를 보면 생각보다 얼마 안하네?라고 생각하실텐데실제 워크로드에 적용해보시면 어마어마하게 나올겁니다 ㅎㅎ...제가 예전 언급했던 내용이지만outbound가 열려있다면 해커 입장에서는 1번이라도 뚫어내면 데이터를 다 빼갈 수 있습니다.제목은 "Gradle 프로젝트 빌드하기"이지만Log4j 취약점이나 공급망 공격에 대해서 언급한 내용이 있으니 참고하시면 좋을듯합니다.어쨋든 요점은 해커 입장에서는 악성코드를 1번이라도 심을 기회가 생겨서 심는다면outbound가 다 열려있는 상태라면 해당 프로그램을 통해서 데이터를 빼갈 수 있습니다.대표적인게 최근 유행(?)하고 있는게 eBPF죠.eBPF는 github에 공개된 오픈소스이고 커널 레벨에서 실행되기 때문에어떤 프로세스가 어떤 파일에 접근하고 네트워크 통신을 하는지 감시할 수 있습니다.그렇다면 우리가 구축한 아키텍처에서 EC2의 outbound만 볼까요?예를 들어서 EC2에서 git push/pull하거나 docker push/pull, slack api 호출 등이 outbound에 해당되죠.보통 security group의 outbound는 기본이 any open(=0.0.0.0/0 all port 허용)이기 때문에이제까지 문제 없이 사용하고 계셨을겁니다.만약 사용자가 업로드한 첨부파일이 악성코드였고 그게 EC2에 설치가 됐다면?SQL Injection 공격으로 명령어를 삽입해서 RCE(Remote code execution) 공격을 시도했다면?공격 당한 EC2 디스크에 있는 데이터는 물론이고해당 EC2에서 접근 가능한 DB까지 싹싹 긁어서 해커의 서버로 퍼다 날랐을겁니다.그렇다고 outbound를 무작정 막자니 애매한 부분이 있습니다.security group은 IP기반으로만 허용이 가능해서 특정IP를 차단하기엔 어려움이 있습니다.예를 들어서 IPv4에서 1개의 IP만 차단하려면security group은 차단할 IP 1개를 제외한 약 43억 개 IP를 등록해야되거든요.하지

2025년 LLM 필드에서 가장 중요한 키워드 하나를 꼽으라면 바로 'Reasoning'일 것입니다.Test-time-computing을 통해서 LLM은 사람처럼 생각하는 과정을 거쳐 답변을 이끌어냈고, 이는 다양한 벤치마크 성능을 극적으로 끌어올렸습니다.하지만 이 Reasoning 모델은 일반 사용자들 (단순한 태스크에 LLM을 적용하려는) 에게는 큰 영향을 주지 못했습니다.금방 대답할 수 있는 질문들에도 쓸데없는 사고과정을 거치면서 답변을 기다리는 사용자들을 지치게 만들곤 했기 때문입니다.그래서 제안된 방식 중 하나가 바로 Think-fusion입니다. 이전 블로그 글에서 Qwen3에 적용된 Hybrid think mode 에 대해서 살펴본 바 있습니다.Think-fusion이 적용된 LLM은 단일 모델 (unified model)이 reasoning과 non-reasoning 방식을 모두 지원합니다.이 글에서는 think-fusion을 구현하는 여러 방식과, 최근 모델들의 think-fusion 방식을 통해 LLM의 방향성을 살펴보려 합니다.Think fusion은 기본적으로 사용자가 'Think 모드'를 활성화했을 때, 모델이 형태의 답변을 생성하도록 학습됩니다.하지만 모델별로, 그리고 'Non-think 모드'일 때의 응답 형태에 따라 세 가지 구현 방식의 차이가 존재합니다.각각의 방식을 조금 더 자세히 살펴보겠습니다.가장 직관적인 방식입니다. 사용자가 Think 모드를 끄면, 모델은 추론 과정을 생략하고 최종 답변([resp])만 내놓습니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.사용자가 Think 모드를 끄면, 태그를 출력한 후 답변을 제공합니다. 이는 빈 reasoning을 생성한 것과 동일합니다.이는 모델이 항상 '생각' 단계를 거치도록 구조적으로 템플릿을 유지하되, Non-think 모드에서는 그 내용을 비워두는 방식으로 응답 형태의 일관성을 유지하려는 시도입니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 하고,Non-think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.사용자가 Think 모드를 끄면 뒤에 바로 토큰이 나타나고, 그 이후에 답변 생성되는 다소 특이한 형태입니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 하고,Non-think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.세 가지 방식이 별로 다를 것 없어 보이지만, 확률적으로 다음 토큰을 생성하는 LLM의 특성을 생각해보면 큰 차이가 있습니다.LLM 은 next token prediction loss에 의해서 학습된 모델입니다.따라서 학습 때 본 적 있는 sequence 라면 해당 token 이 생성될 가능성이 존재합니다.Case 1의 경우, Non-think 모드를 사용하기 위해서 뒤에 아무것도 붙이지 않고 inference 를 수행하는 상황을 가정해보겠습니다.Think 모드를 위해서 뒤에 토큰이 있는 데이터가 학습된 적 있기 때문에 Non-think 모드라고 할지라도 토큰이 생성될 수 있습니다.만약 생성된다면 think 모드로 답변하게 됩니다.반면 Case 2의 경우, Think 모드를 사용하기 위해 만 붙여 inference 를 했는데, 바로 가 나오면서 Non-think 모드가 되어버릴 수 있습니다.Case 3의 경우, 앞의 경우와는 다르게 두 모드가 완전히 분리되어 있습니다. 로 시작한다면 가 나올때까지 reasoning 을 하게 될 것이고,로 시작한다면 바로 응답이 생성될 것입니다.따라서 Case 1과 Case 2의 경우, 각각 Non-think 모드와 Think 모드에서는 사용자가 아닌 모델이 모드를 선택하게 됩니다.학습된 데이터의 비율이나 학습 레시피에 따라서 그 비중이 결정될겁니다.그렇다면 반드시 Case 3가 좋은 것일까요? 장담할 수는 없습니다. Case 1과 Case 2는 Think/Non-think 에서 사용하는 템플릿이 일관성을 유지합니다.반면 Case 3는 특정 토큰이 나오면서 이후에 아예 다른 distribution 을 가지게 됩니다. 이는 모델 학습시에는 sample efficiency 를 떨어뜨릴 가능성이 있습니다.다시 말해, Case 1과 Case 2가 학습이 더 효율적일 수도 있습니다. 반면 Case 1과 Case 2는 모델이 Think/Non-think 를 잘 결정할 수 있도록 하는 데이터 mixture 를 잘 찾아야 하겠습니다.Think-fusion을 사용하지 않고 다시 모델 분리그런데 최근 공개된 GPT-5는 오히려 Reasoning 모델 (gpt-5-thinking) 과 Instruct 모델 (gpt-5-main) 을 아예 분리해 버렸습니다.그리고 모델 앞에 Router를 붙였습니다. 사용자의 질문을 router가 먼저 분석하고 이 질문이 복잡한 추론을 요구하는지, 아니면 간단한 지시 수행이나 정보 검색으로 충분한지를 판단합니다.그리고 판단에 따라 요청을 전문화된 각 모델로 전달합니다.Alibaba의 Qwen3-235BA22B도 2507 버전으로 Instruct-only 모델을 내놓았습니다.기존의 think-fusion 을 업그레이드 하지 않고, instruct-only 모델로 변경하여 내놓은 것입니다.GPT-5와 Qwen3는 Think/Non-think 모델을 분리하여 학습 하고 있고,think-fusion의 case 3방식을 사용하는 DeepSeek-V3.1 또한 Think/Non-think의 distribution 분리하려는 시도를 한 것을 볼 수 있습니다.비교적 최신 모델들이 think-fusion 을 분리하려는 이유는 무엇일까요?몇 가지 추론을 해볼 수 있습니다.• None 성능 저하의 가능성: 하나의 모델에게 복잡한 추론 태스크와 간결한 답변 생성이라는 두 가지 작업을 모두 잘 해내도록 학습시키는 것은 둘 중 하나의 태스크에서 성능 저하를 가져올 수 있습니다. 실제로 Think-fusion을 적용한 모델들은 Non-think모드 성능이

LY Corporation은 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '함수만 보고 관계는 보지 못한다'입니다.함수만 보고 관계는 보지 못한다코드를 작성하다 보면 종종 루프를 중첩해야 할 때가 있습니다. '페이지'나 '청크(chunk)'로 분할된 데이터를 처리하는 것이 그 대표적인 예 중 하나입니다.여러 으로 청크가 생성되고, 다시 이 청크가 모여 페이지를 구성하는 상황을 생각해 보겠습니다. 페이지의 데이터 모델 는 다음과 같이 정의했습니다.각 는 에 따라 순서가 정해지며, 뒤따르는 가 존재한다면(해당 가 마지막 페이지가 아니라면) 는 입니다. 이 를 사용해 모든 의 메타데이터를 저장하는 함수 를 다음과 같이 구현했습니다. 이 함수는 가 면 다음 를 가져와서 그 안에 포함된 의 메타데이터를 저장합니다.이 함수는 과 로 중첩된 루프가 있어 가독성이 좋지 않습니다. 그래서 다음과 같이 내부 루프를 함수로 추출했다고 가정해 보겠습니다.이렇게 추출해도 가독성이 크게 개선되었다고 볼 수는 없습니다. 더 나은 리팩토링 방법은 없을까요?관계에서 숲을 보기앞서 설명한 리팩토링으로 가독성이 크게 개선되지 않은 이유 중 하나는 함수의 경계와 의미 단위의 경계가 일치하지 않기 때문입니다. 가 수행하는 일을 요약하면 다음 두 가지로 나타낼 수 있습니다.를 추출하면 '모든 조회하기'라는 코드가 두 군데로 나뉩니다. 그 결과 ' 가 무엇을 하는지'를 이해하기가 오히려 더 어려워졌습니다. 단순히 추출하기 쉽다는 이유로 내부 구조를 그대로 추출하면 이런 상황이 발생할 수 있습니다. 따라서 리팩토링으로 추출할 때는 추출의 용이성보다는 어떻게 개선될지에 초점을 맞춰야 하며, 이를 위해서는 추출할 때 '코드가 무엇을 하는지' 그 의미 단위에 주의를 기울여야 합니다.위 사례의 경우 내부 루프를 추출하는 대신 의 열을 조회하는 함수를 생성하는 것이 좋습니다. Kotlin에서는 또는 와 같은 클래스로 표현할 수 있습니다. 다음 에서는 의 열을 로 반환합니다.이렇게 하면 중첩된 루프를 하나의 루프로 보이게 할 수 있습니다. 결과적으로 의 내용을 이해할 필요 없이 를 읽는 것만으로 '각 의 메타데이터를 생성하고 저장한다'는 흐름을 파악할 수 있게 되었습니다.이와 같은 리팩토링 접근 방식은 루프 중첩뿐 아니라 조건 분기 중첩이나 데 이터 구조 중첩에도 적용할 수 있으니, 추출할 때는 기존 구조를 유지하는 것이 좋을지 아니면 재구성하는 것이 좋을지 고려해 보시길 바랍니다.

안녕하세요, 데브옵스 엔지니어 포카입니다.최근 인프런의 ”클린 코더스: 실전 객체 지향 프로그래밍과 TDD 마스터 클래스” 강의 영상 업스케일링 작업을 위해 GPU 클러스터를 운영하던 중, 예상치 못한 문제에 직면했습니다. GPU 노드가 정상적으로 생성되었음에도 불구하고 약 10-11분 후 갑자기 교체되는 현상이 반복되었습니다.이번 글에서는 Amazon EKS Bottlerocket AMI 환경에서 발생한 NVIDIA DCGM 관련 오류로 인한 GPU 노드 반복 교체 문제를 해결한 과정을 공유하겠습니다.인프런에서는 강의 영상의 품질 향상을 위해 AI 기반 업스케일링 작업을 수행하고 있습니다. 이를 위해 다음과 같은 환경을 구축했습니다:GPU 워크로드를 안정적으로 운영하기 위해 Karpenter의 Node Auto-Repair 기능을 도입했습니다. 이 기능을 도입한 이유는 다음과 같습니다:Bottlerocket AMI 환경에서 메모리 부족으로 인해 kubelet이 OOM으로 종료되면, EC2 인스턴스는 살아있지만 Kubernetes에서는 상태로 인식되는 좀비 노드 문제가 있었습니다.이를 해결하기 위해 Karpenter의 Node Auto-Repair 기능을 활성화했습니다:Node Auto-Repair 기능을 도입한 후, 예상치 못한 새로운 문제가 발생했습니다.GPU를 사용하는 Pod를 실행하자 다음과 같은 현상이 반복되었습니다:• GPU 노드가 정상적으로 생성되고 상태가 됨• 약 10-11분 후, 노드가 갑자기 비정상으로 간주되어 Karpenter에 의해 교체됨• 새로 생성된 노드에서도 동일한 문제가 반복됨• 결과적으로 GPU Pod들이 지속적으로 재시작되어 작업이 제대로 진행되지 않음Node Event 분석 결과, 다음과 같은 메시지를 발견했습니다:NVIDIA DCGM(Data Center GPU Manager) 라이브러리 누락이 문제의 핵심이었습니다.그림 1: 시간순 이벤트 로그 - DCGM 오류 발생부터 Karpenter의 노드 교체까지의 전체 과정이벤트 로그를 시간 순으로 정리하면 다음과 같은 흐름을 확인할 수 있었습니다:이 시점까지는 모든 것이 정상적으로 진행됩니다.노드가 상태가 된 지 약 1분 후, 상태가 에서 로 변경됩니다. 이는 GPU 하드웨어를 사용할 수 없는 상태임을 의미합니다.상태가 되자 Karpenter는 해당 노드를 비정상으로 판단하고 복구 절차를 시작합니다.문제의 근본 원인: DCGM 라이브러리 누락NVIDIA DCGM(Data Center GPU Manager)은 데이터센터 환경에서 GPU를 체계적으로 관리하기 위한 종합 솔루션입니다.• • GPU 노드의 스케줄링 가능 여부 결정Bottlerocket AMI의 라이브러리 누락으로 인해 다음과 같은 연쇄 반응이 일어났습니다:• GPU 노드의 Node Condition이 로 설정됨• Kubernetes 및 Karpenter가 해당 노드를 비정상으로 판단함• 결과적으로 노드가 자동으로 교체되는 무한 루프 발생Karpenter가 노드를 교체한 이유DCGM 오류를 발견했지

안녕하세요, 카카오 서비스보안팀에서 취약점 진단 업무를 담당하고 있는 Hex와 Michael입니다.2025년 8월, 세계에서 가장 큰 해킹 대회인 DEFCON 33의 CTF 본선에 참가하였습니다. 이번 글에서는 본선팀 중 유일하게 한국인으로만 구성된 해킹 그룹 연합팀 Cold Fusion의 일원으로서 DEFCON 예선을 통과하고 본선에 진출하여 Attack & Defense 방식의 CTF 대회에 도전했던 경험을 공유하고자 합니다.특히 DEFCON 대회는 단순한 문제 해결 방식이 아닌, 실제 공격과 방어를 동시에 수행해야 하는 실전형 대회였기에 더욱 의미 있는 경험이었습니다. 보안 업계에 관심 있는 분들과 향후 DEFCON 참가를 고려하고 계신 분들에게 도움이 되길 바라며 시작하겠습니다.DEFCON은 1993년부터 매년 미국 라스베이거스에서 개최되는 세계 최고 권위의 해킹 방어대회이자 글로벌 보안 컨퍼런스입니다. 전 세계 보안 전문가와 해커들이 모여 최신 해킹 기술과 방어 전략을 논의하고, 그 중에서도 DEFCON CTF는 '해커들의 올림픽’이라 불리는 최고 난이도의 해킹 대회입니다.DEFCON CTF는 예선과 본선으로 구성되며, 본선에는 총 12팀만이 참가할 수 있습니다. 본선 진출 자격은 다음과 같이 부여됩니다:• 예선 통과: DEFCON 공식 예선에서 상위 7팀 안에 진입한 팀들그림 1. 대회가 진행된 라스베이거스 컨벤션 센터DEFCON 33 CTF 본선은 기존의 단순 문제 해결 방식(Jeopardy)과는 달리 Attack & Defense, King of the Hill, LiveCTF 등 3개 분야의 종합 점수로 순위가 결정됩니다.• Attack & Defense: 모든 팀이 동일한 서비스를 받아 공격과 방어, 패킷 모니터링을 동시에 수행• King of the Hill (KotH): 특정 리소스나 서비스를 장악하여 지속적으로 점수 획득• LiveCTF: 분야별 대표가 1:1로 문제 해결 속도를 겨루는 실시간 대결대회는 5분 주기의 ‘Round’ 시스템으로 운영되며, 매 라운드마다 시스템의 Flag 값을 탈취하거나 방어하여 점수를 획득합니다.올해 DEFCON은 Null@Root 팀 소속으로 Cold Fusion이라는 한국 해킹 그룹 연합팀으로 참가하게 되었습니다. (Cold Fusion은 Null@Root, Anops, CatFlag, SaturnX, CyKor, Plus등 한국의 해킹 팀으로 구성되어 있습니다.)DEFCON 예선은 온라인 방식으로 48시간(2025년 4월 12일 오전 9시 ~ 14일 오전 9시 KST) 동안 진행되었습니다. 전 세계 약 200개 팀이 참가한 가운데 Reversing, System, Web, Crypto 등 다양한 분야의 보안 문제들을 해결하여 Flag 값을 획득하는 방식으로 진행되었습니다.그림 5. 예선 결과 - 8등으로 본선 진출예선전에서는 8등으로 마무리하여 턱걸이로 본선에 참여할 수 있는 자격을 얻었습니다. 48시간 동안 진행되는 대회인 만큼 상당한 체력전이었고, 본선 합격을 확인하는 순간 너무 기뻐서 누적된 피로가 다 날아갔던 것 같네요! 😭DEFCON 본선은 2025년 8월 8일(금요일)부터 8월 10일(일요일) 까지 진행되었습니다.대회는 컨벤션 센터 내 본선장 또는 원격에서 접근하게 됩니다.그림 6. 본선장에서 참여중인 Cold Fusion그림 7. 본선장 인근 원격 공간(아지트)에서 참여중인 모습그림 8. 대회에 참여중인 Hex(좌) 와 Michael(우)대회에서 필요한 도구는 팀별로 직접 마련해야 했습니다. 반복되는 업무는 수작업으로는 한계가 있어 가능한 범위까지 자동화를 추진했고, 익스플로잇 자동 전송, PCAP 분석, 바이너리 diffing, flag 자동 제출까지 한 번에 처리하는 인프라를 구축했습니다. 구축한 인프라는 사전에 여러 차례 드라이런으로 검증했으며, 본선 현장 인프라와의 안정적인 통신을 위해 원격 접속 VPN도 함께 구성했습니다.각 팀에게는 모두 동일한 서비스가 구동되고 있는 고유의 IP와 서버가 주어집니다.대회 서버들은 오전 10시부터 오후 5시까지만 접근이 가능하며, 그 외 시간에는 서비스 도커 이미지를 미리 Pull하여 분석하고 공격과 방어를 준비해야합니다.역할은 다음과 같이 분배하여 진행했습니다.저희가 속한 Attack 파트는 서비스 취약점 식별과 flag 확보를 맡았습니다. DEFCON 서버로부터 Docker 이미지를 받은 후 바이너리를 추출해 분석하고 취약점을 규명했으며, 이를 바탕으로 라운드마다 자동으로 동작하는 익스플로잇 코드를 작성해 공격을 자동화했습니다.Defense 파트는 네트워크 트래픽 분석과 바이너리 패치에 집중했습니다. 팀 서버로 들어오는 트래픽을 면밀히 살펴 플래그가 유출되었는지, 또 어떤 방식으로 침투가 이뤄졌는지를 추적했고, 발견된 취약점은 바이너리 수준에서 패치하여 타 팀이 공격으로 flag를 가져가지 못하도록 방어했습니다.King of the Hill 파트는 대상 자산을 신속히 스캔해 진입점을 찾고, 취약점을 이용해 접근권을 얻은 뒤 권한을 높여 소유권 표시를 남겼습니다. 그다음 서비스가 죽지 않도록 상태를 지속적으로 확인하고 필요한 최소한의 하드닝을 적용했습니다.대회 기간 동안 구축한 인프라를 운영하며 예상치 못한 문제를 실시간으로 처리했습니다. 무엇보다 VPN을 구축하고 상시 관리해 연결이 끊기지 않도록 했고, 운영 과정에서 새 요구가 생기면 필요한 기능을 곧바로 설계·개발해 서비스에 적용했습니다.LiveCTF는 배정받은 상대와 1시간의 1:1 대결을 통해 누가 더 빨리 문제를 풀 수 있는지 대결하는 방식입니다.참여자들의 화면이 실시간 생중계 되며, 참여자는 AI를 제외한 외부의 도움 없이 문제를 풀어야합니다.보다 자세한 내용이 궁금하면 아래 영상을 참고해주세요!데프콘은 대회 뿐만 아니라 컨퍼런스도 함께 운영되고 있습니다. 여러 분야의 보안 종사자들이 참석하는 행사인 만큼 본선 이외에도 크고작은 CTF, 테마별 체험 부스, 발표 세션 등 다양한 이벤트들이 많은데요! 아쉽게 대회 참여로 인해 체험은 못했지만, 독자분들께 현장감을 전하기 위해 촬영한 사진과 전달받

왜 AI로 데이터를 만들어야만 할까?더 좋은 AI를 만들기 위해선 학습, 검증 등에 필요한 더 많은 데이터가 필요하지만, 이에 필요한 데이터를 확보하는 일은 갈수록 어려워지고 있습니다. 또한 수집, 선별하고 요구사항에 맞게 정제하는데 드는 막대한 비용, 그리고 결코 무시할 수 없는 개인정보보호, 저작권, 보안 이슈는 언제나 우리 발목을 잡고 있습니다. 특히 데이터 중 다수는 실제 문제에 맞지 않거나, 품질이 일정하지 않아 결국 사용되지 못하는 경우도 많습니다.이러한 맥락 속에서, 패러다임을 바꿀 새로운 아이디어가 부상하고 있습니다. 바로 데이터를 ‘수집’, ‘선별’하는 것을 넘어, 필요에 맞게 ‘설계하고 생성’하는 생성형 AI 기반 합성 데이터(Synthetic Data Generation)의 등장입니다. 이는 단순히 필요한 데이터를 자동으로 만드는 걸 넘어, 우리가 데이터를 다루고 활용하는 방식을 바꿔볼 수 있는 기회가 될 수 있습니다.생성형 AI 기반 합성 데이터(Synthetic Data Generation)는 기존에 존재하지 않는 데이터를 AI가 목적에 맞춰 새롭게 만들어내는 기술입니다.이때 해당 결과물은 단순한 무작위 샘플이 아니라, 사용자의 요청이 담긴 프롬프트, 조건을 바탕으로 실제처럼 보이는 데이터를 만들어냅니다.예를 들어, “보험금 청구 거절 사례 100건을 만들어줘. 단, 사유는 명확하고 어투는 정중하게.”라고 AI에게 지시하면, 실제 고객 민원을 바탕으로 구성된 것처럼 보이는 데이터 셋이 자동으로 생성됩니다.이러한 방식은 사람이 직접 만드는 것보다 쉽고 빠르며, 실제 개인정보를 쓰지 않고도 현실과 유사한 데이터 생성이 가능하기 때문에, 모델 학습, 기능 테스트, 민감 정보 대체 등 다양한 영역에서 활용될 수 있습니다.최근 연구를 통해 본 ‘합성 데이터 생성’의 가능성‘AI가 만든 합성 데이터’와 관련하여, 아래 두 논문을 비롯해 대규모 언어 모델과 생성형 AI를 활용한 합성 데이터 생성의 원리, 실제 도구 적용, 품질 및 책임성 기준 등 다양한 분야에서 활발한 연구가 이루어지고 있습니다.• 생성형 AI는 단순히 데이터를 만들어내는 데 그치지 않고, 소프트웨어 품질을 검증하는 데 필요한 테스트 데이터를 생성할 수 있는가?라는 질문이 제기되고 있습니다. 특히 일부 기능 검증에는 개인 정보나 민감 정보가 포함되지 않은 가짜 데이터가 필요합니다.이 논문은 대형 언어 모델(LLM)을 활용해 도메인 규칙과 문화적 맥락을 반영한 고품질 테스트 데이터와 생성기를 자동으로 생성하는 방법을 제안합니다.• 해당 논문에서는 GPT-4 등 최신 LLM을 활용해 실제 테스트 케이스에 사용할 수 있는 데이터와 생성기를 만들고, 이를 검증 과정에 활용할 수 있는지를 실험했습니다. 이를 위해 다양한 도메인과 언어에 맞는 테스트 데이터, 실행 가능한 생성 코드, 기존 faking 라이브러리와 연동 가능한 코드 등을 실제로 생성하고 평가했습니다.생성된 결과는 문화적 맥락, 도메인 규칙, 기술적 실행 가능성 측면에서 검토되었으며, 코드 실행과 테스트 프레임워크 적용을 통해 현업에서의 활용 가능성도 확인했습니다.어떤 의미가 있고 어떻게 활용할 수 있는가?• 이 연구는 생성형 AI가 단순한 ‘데이터 생성기’를 넘어, 품질 검증에 필요한 테스트 데이터를 자동으로 생성하는 도구로 활용될 수 있음을 실험을 통해 보여주고 있습니다.특히 결과물은 단순 문장이 아닌, 테스트 목적에 맞춰 도메인 규칙과 실행 가능성을 갖춘 데이터 및 생성기 코드로 구성되어 있어 실제 검증 환경에서의 활용 가능성을 보여주고 있습니다.• AI 모델 학습과 평가 과정에서 합성 데이터의 역할, 가능성, 한계에 대해 폭넓게 분석하였습니다.또한 데이터 부족, 비용, 프라이버시 등 현실적인 제약을 합성 데이터를 통해 어떻게 극복할 수 있는지 살펴봤으며, 품질·편향·신뢰성 문제도 함께 다뤘습니다.다양한 영역의 합성 데이터 생성 기술과 실제 활용 사례를 종합적으로 조사했습니다.• 텍스트: 자연어 질문/답변, 수학 문제 생성 등 다양한 학습·테스트 데이터의 대규모 자동 생성 사례• 코드: 코드 생성과 실행 결과를 활용한 AI 모델 강화 및 검증(Test case 자동화, 리팩토링 데이터 생성 등)• 멀티모달: 이미지-텍스트 페어, 그래프, 차트 데이터 등 복합 데이터에서의 합성 생성 및 활용 적용• 다언어/언어 다양성: 소수 언어, 번역, 다국어 QA 등에서 실제 활용(예: 백 트랜슬레이션(역번역), 다국어 QA 쌍 자동 생성)또한 다음과 같은 실제 응용 사례들을 통해 활용 가능성을 검토했습니다• 모델 사전학습 데이터 증강: 기존 오픈소스 데이터 부족 영역 보완, 드문 조건이나 극단 상황 데이터 확보• 모델 검증 및 품질 평가: 합성 데이터로 한계 상황·변형 조건 테스트, 자동화된 레드 팀 테스트 시나리오 구축• 공정성·편향 완화: 특정 성별·인종·지리적 편향을 최소화하는 데이터 설계 및 검증 전략 연구• QA 테스팅/산업별 실전 적용: 의료, 법률, 금융 등 개인정보 이슈가 큰 도메인에서 현실 데이터 대체로 활용, 실제 QA·평가 프로토콜 구축그 외, 품질·편향·팩추얼리티(사실성) 이슈, 책임성(Responsible AI), 대규모화(Scaling) 전략, 평가 contamination 문제점 등 합성 데이터 현장 활용과 한계까지 심층 분석하였습니다.※ 팩추얼리티(사실성) : ‘AI가 답한 내용이 사실인지 아닌지 따지는 기준’어떤 의미가 있고 어떻게 활용할 수 있는가?• 합성 데이터가 데이터 부족이나 민감 정보 문제를 해결할 수 있는 현실적인 대안임을 강조하고 있습니다.특히 AI 모델 개발과 검증의 패러다임을 바꿀 수 있는 새로운 표준으로서의 가능성을 제시했으며, 실제로 다양한 도메인에서의 적용 사례를 통해 활용 방안을 구체적으로 설명했습니다.하지만 품질, 편향, 사실성 등의 이슈가 여전히 존재하기 때문에, 책임 있는 생성 기준과 평가 체계 마련의 필요성도 함께 시사했습니다.3. 글로벌 기업의 합성 데이터 활용 사례 및 효과• 일부 글로벌 기업들은 합성 데이터를 단순 생성에 그치지 않고, 테스트 케이스 작성, 추천 모델 검증, 금융

AI Lab 은 올 상반기에 “마리트 크몽" 이라는 프로그램을 런칭하고 운영했습니다. “마리트 크몽”은 사내의 다양한 부서와 현업 팀이 실제 업무에서 마주치는 문제를 발굴하고, 이를 빠르게 해결하기 위해 개발 지식이 있는 다른 팀원이 AI와 자동화 기술을 통해 해결해보는 사내 프로그램입니다. 이 프로그램을 통해 각 팀은 반복적이거나 비효율적인 업무를 개선할 수 있는 기회를 얻고, 문제를 해결한 임직원의 AI 및 자동화의 리터러시를 올리기 위해 계획되었죠.이번 사례는 마케팅파트너 팀에서 발생한 정산 업무의 비효율 문제를, 정산개발팀의 국승현 님이 AI와 자동화 기술을 활용하여 해결한 프로젝트입니다. 구체적인 해결 과정과 성과는 아래 내용에 이어집니다.매월 반복되는 4200건의 반복 작업마케팅 파트너 팀은 다양한 마케팅 파트너들과 협업하고 있는데요, 이분들에 대한 정산 업무는 상당한 시간이 소요돼요.“한 달 동안 마케팅 파트너분들이 열심히 활동을 하시면 한 달에 한 번 정산금을 지급합니다. 현재는 약 1,400명의 파트너들이 정산을 받고 있고 계속 증가하는 추세입니다.”문제는 각 파트너마다 단순히 정산금만 지급하는 것이 아니라는 점이에요. 정산금, 국세, 지방세까지 총 3건씩 처리해야 하니까 4,200건을 처리해야 하는 거죠. 그런데 외부 ERP 시스템의 기술적 제약으로 인해 한 번에 100건밖에 처리할 수 없어서, 같은 작업을 42번 반복해야 했어요. 각 작업마다 예금주 조회 등의 유효성 검사가 필요해서 처리 시간이 더욱 늘어났고요. 42개의 결의서마다 별도의 결재를 올리는 과정까지 더하면, 담당자가 하루 종일 이 반복 작업에만 매달려야 했습니다.AI와 함께한 바이브 코딩 여정이 문제를 해결하기 위해 결제&정산개발팀의 국승현 님이 선택한 방법은 ‘AI 바이브 코딩’으로 크롬 확장프로그램을 만드는 것이었는데요. 바이브 코딩이란 개발자가 직접 코드를 작성하기보다, AI에게 자연어로 원하는 기능을 설명하고 AI가 코드를 생성하도록 유도하는 새로운 프로그래밍 방식을 말해요. 흥미로운 점은 크롬 확장 프로그램을 만들 줄 몰랐지만 AI의 도움으로 기능 구현에만 집중할 수 있었다는 점이에요.“크롬 확장 프로그램을 만들어본 적이 없었고, 어떻게 만드는지도 몰랐어요. 그런데 AI한테 시키니까 UI까지 알아서 해줬습니다.”탐색 기반 접근법의 적용단순히 AI에게 무작정 요청하는 대신, 체계적인 ‘탐색 기반 접근법’을 활용했어요. 이는 충분한 정보 없이 시작할 때 효과적인 문제 해결 방법론이에요. 웹 브라우저 기반의 자동화 작업에 대해 경험이 없었기 때문에 좀 더 체계적으로 접근해보고자 했습니다.“어떤 문제나 현상에 대해서 충분한 정보 없이 시작할 때, 가설을 설정하기보다는 정보를 탐색하고 개념적으로 구조를 잡으면서 이해를 확장하고 문제를 정의하려는 시도입니다.”이 접근법은 5단계로 구성되어 있어요:현상 인식 & 문제 탐지 (Sensing & Surfacing Issues)정보 수집 및 스캐닝 (Environmental Scanning)의문 생성 & 프레임 설

이번 글에서는 지난 아티클에서 소개한 제휴사 Mock 서버를 더 효과적으로 활용하기 위해 어떤 고민을 했는지 를 소개하고자 해요. 이를 위해 통합 테스트 작성 과정과, 유지보수의 어려움을 줄이기 위해 어떤 접근 방식을 시도했는지 경험을 나눠보려 합니다.현재 신용대출 찾기 서비스의 경우, E2E(End-to-End) 테스트가 자동화 되어 있지 않습니다.이로 인해 Mock 서버를 만들었지만 제휴사 코드를 변경할 때마다 사람이 직접 테스트를 해야하고, 이는 곧 테스트를 누락할 수 있음을 의미해요. 완전한 E2E 테스트를 도입하는 것이 가장 이상적이지만, 팀 상황 상 당장 적용하기는 어려웠습니다.이에 Docker 환경에서 Mock 서버를 띄우고 통합 테스트를 Github Action에서 수행하는 방식으로 문제를 해결하고자 했어요.토스는 Spring Cloud Config 를 활용해 프로퍼티를 주입하고 있고, Local, Alpha, Staging, Live 4개의 환경을 운영하고 있습니다. (제휴사 Mock 서버의 경우 Local, Alpha 환경만을 운영하고 있어요.)내부 라이브러리에서 참조하는 프로퍼티들이 Spring Cloud Config 값을 의존하고 있기 때문에, Mock 서버를 띄울 때 Local, Alpha가 아닌 제 3의 Profile을 사용하는 것에는 어려움이 있었습니다.이런 어려움 때문에 2개의 환경 중 하나를 희생해야했고, Alpha 환경은 E2E 테스트를 진행했어야 했기에 Local 환경을 포기하고자 했습니다. 하지만 새로운 서비스들이 Mock 서버 연동을 해야하는 상황에서 Local 환경을 사용할 수 없게 되는 것은, 앞으로의 생산성에 영향을 크게 미치는 문제였고 이 방법을 채택할 수 없었습니다.Spring Cloud Config를 활용하면서, 내가 원하는 값에 대해서만 Mock 서버 기반 통합테스트 환경에서 오버라이드 할 수 있는 방법이 없을까를 고민하다 Multi Profile 을 사용하면 문제를 해결할 수 있음이 떠올랐습니다.Mock 서버 기반 통합테스트를 위한 mockServerTest라는 Profile을 정의하고, 내부적으로 Docker 환경에서 사용할 인프라 정보를 오버라이드 함으로써 문제를 해결할 수 있었습니다.• None mockServerTest 프로파일에 docker 환경에서 사용할 인프라 환경을 구성합니다.• None application-find-loan-mockServerTest.properties 를 config 에 병합함으로써, docker 환경에 맞는 인프라 가 spring config 에 설정됩니다.지난 아티클에서 말씀드렸듯이, Mock 서버는 각 서비스가 모듈로 존재하는 멀티 모듈 프로젝트 구조입니다. 이때 서비스 별로 패키지 구조가 정의되다 보니, 동일한 패키지 경로가 겹칠 수 있는 문제가 있었습니다.이로 인해 패키지 구조가 같은 Entity들이 각각의 DataSource에 중복으로 추가되는 문제가 발생했어요.예를 들어 라는 패키지를 사용하는 모듈과 모듈이 있을 경우, 의 DataSour

빈번하게 실패하는 통합 테스트의 고통우리 팀에서는 Prompt Engineering Platform을 만들고 있습니다.Prompt Engineering Platform은 다양한 외부 Model Provider와 연동을 하고 있는데, 처음에는 Provider 서버를 직접 연동해서 테스트하였습니다.하지만, 이건 녹록지 않더라고요. 실제 연동하는 서버가 동작하지 않기도 했고, 어떤 날은 Azure 쪽에서 이상하게 타임아웃이 나거나 버전 업데이트 때문에 스펙이 바뀌어버리기도 했습니다.🤯그래서 서버 내 Mock Api를 만들어 연동하기도 하였지만, 이것 또한 번거로웠습니다. Api에 변경 사항이 있을 때마다 Mock Api도 함께 변경해 주며 꾸준히 관리해 주어야 했거든요.외부 서버의 상태에 따라서 테스트는 종종 실패했고, 실패 원인이 우리 코드 때문인지 외부 서비스 때문인지 알 수가 없었습니다. 이런 상황이 반복되다 보니, 테스트는 신뢰할 수 없는 존재가 되어버렸죠. “테스트가 실패하는데! 이게 내 코드 문제일까,아니면 또 외부 서버의 문제인 걸까?” 하는 불필요한 검증에 시간을 낭비하는 경우가 많았습니다.그러던 중 팀원분이 WireMock을 소개해 주셨고, 이를 적용해 빠르고, 독립적이며, 반복 가능한 FIRST Unit Test에 한 발짝 다가갈 결심을 하게 됩니다.FIRST 테스트를 위하여 선택한 도구는 바로 WireMock, Docker, 그리고 GitLab CI입니다.외부 API를 Mock하면서 독립적으로 테스트할 수 있는 환경을 만들었고, 이를 자동화된 파이프라인 안에 적용하였습니다.이 글에서는 WireMock과 Docker, GitLab CI를 어떤 방식으로 활용했는지에 대해 차근차근 이야기하려 합니다.안 그래도 바쁜데, 불필요한 테스트 실패로 시간을 빼앗기고 있는 개발자분들께 이 글이 작은 도움이 되길 바랍니다 🙏앞서 언급했듯, 기존에는 외부 서버를 실제로 연동했기 때문에 에러 응답 테스트가 까다로웠고, 외부 서버에 이슈가 발생하면 테스트도 실패하는 문제가 있었습니다.또한, 테스트 시 DB와 Redis를 직접 로컬에서 실행하는 것도 번거로웠습니다.아래는 기존의 전체 아키텍처 구성도입니다.외부 서버 연동을 WireMock으로 대체하고, WireMock, DB, Redis를 모두 Docker로 실행하여 로컬뿐 아니라 GitLab CI 환경에서도 통합 테스트를 수행할 수 있도록 구성하였습니다.이에 대한 자세한 내용은 아래에서 상세히 다루겠습니다.결과적으로 프로젝트의 전체 소스 구조는 아래와 같으며, 여기서 Docker + WireMock + GitLab CI 구성을 한눈에 파악할 수 있습니다.docker 폴더에는 컨테이너로 실행할 WireMock 관련 파일이 위치하며, 프로젝트 루트에는 GitLab CI 설정을 위한 파일이 있습니다.또한, 위에 표기하진 않았지만, 통합 테스트를 위해 MySQL과 Redis도 WireMock과 함께 Docker로 실행하고 있습니다.이와 같이 테스트에 필요한 서비스들을 자유롭게 추가하면 됩니다. 😊WireMock으로 API Stub 만들기WireMock을 이용해 외부 서버의 API를 어떻게 mocking할 수 있는지 살펴보겠습니다.특정 요청이 들어왔을 때 미리 정해둔 응답을 반환하는 "stub"을 mappings 디렉터리 내에 구성하여 줍니다.그리고 아래와 같이 Intellij에서 WireMock을 간단하게 실행해볼 수 있습니다.Docker로 실행하는 방법은 바로 다음 챕터인 "Docker 컨테이너에서 WireMock 구동하기"에서 다루겠습니다.WireMock을 사용하면, 외부 서버와 직접 연동하지 않고 mappings 하위에 정의된 응답을 내려주어 테스트 환경을 외부 시스템과 완전히 분리하여 독립적으로 유지할 수 있습니다.예를 들어, 아래 stub은 요청에 대해 JSON 정상 응답을 반환합니다.다음은 일정 시간 지연 응답을 테스트할 수 있는 Stub 예시입니다.경로로 POST 요청이 오면 1000ms(1초) 후에 200 OK 응답을 반환합니다.상황에 따라서는, 같은 URL Path에 대해 서로 다른 응답을 받아야 하는 경우도 있습니다 (e.g., 정상 응답과 에러 응답)우리 팀은 다양한 에러 상황을 분류하는 테스트가 필요했는데, 이때는 요청 body에 특정 키워드가 포함되어 있는지를 조건으로 stub을 정의했습니다.아래 예시는 "rate_limit_exceeded"나 "internal_error"가 body에 포함된 경우 각각 429, 500 에러를 반환하도록 설정한 stub입니다:• None• None JSON 매핑 파일 안에 응답 내용을 직접 넣을 수도 있지만, 응답이 길어질 경우 디렉터리에 별도 파일로 저장하는 것을 권장합니다.• None 이렇게 하면 매핑 파일은 요청·응답 구조만 간결하게 유지되고, 응답 본문은 재사용하기 쉬워집니다.• None• None 동일한 URL Path라도 요청 조건에 따라 다른 응답을 줄 수 있습니다.• None priority 값이 낮을수록 먼저 매칭되며, 주로 에러 케이스 등 특수 상황에 낮은 값을 부여합니다.• None 기본(default) 응답은 priority를 높게 설정해 마지막에 매칭되도록 합니다.Docker 컨테이너에서 WireMock 구동하기Docker 컨테이너에서 WireMock을 구동하는 가장 간단한 방법은 Docker Hub에 공식적으로 배포된 이미지를 사용하는 것입니다.이 이미지를 사용하면 별도의 설정 없이 손쉽게 WireMock 서버를 실행할 수 있습니다.앞서 만들었던 프로젝트 구조 하위의 project-root/docker/wiremock/Dockerfile을 아래 코드와 같이 만들어 주었습니다.여기서, 도커 이미지에 wiremock 디렉토리의 mappings 파일을 복사해 주었는데, mappings는 앞서 만든 API Stub들 입니다.• None ARG VERSION=3.12.1 → WireMock 버전을 변수로 정의해, 빌드 시 원하는 버전으로 바꿀 수 있게 합니다.• None FROM wiremock/wiremock:${VERSION} → 공식 WireMock 이미지를

2025년 CES 키노트 발표에서 젠슨 황은 Disney Research, Google DeepMind와의 협력으로 개발된 첨단 AI 로봇 "블루(Blue)"를 소개했습니다.스타워즈에서 영감을 받은 이 드로이드형 로봇은 NVIDIA의 물리 AI 기술력을 보여주는 상징적인 데모였습니다.블루의 상세 스펙은 알려지진 않았으나, 최신 엔비디아 컴퓨팅 플랫폼 2대가 사용되었다는 언급이 있는 것으로 보아 아마도 Jetson Thor가 사용된것이 아닌가 하는 추측이 있습니다.두 대만 있으면 누구나? 로봇을 가질 수 있는 시대가 올 수 있는걸까요?"그래서 Jetson Thor 가 뭔데?" 하시는 분들을 위해 간단히 소개 드리도록 하겠습니다.Jetson Thor는 기존 Jetson Orin의 대체재가 아닌, Jetson 제품군의 최고급 모델인 최신 Blackwell GPU 아키텍처로 포지셔닝되어 있습니다.128GB LPDDR5X 메모리와 함께 최대 2,070 TOPS의 AI 연산 성능을 제공하며, 휴머노이드 로봇과 생성형 AI와 같은 자원 집약적 애플리케이션의 하드웨어 요구사항을 충족합니다.Jetson Thor의 핵심인 Blackwell GPU 아키텍처는 NVIDIA의 최신 GPU 기술을 집약한 혁신적인 설계입니다.최근 출시된 NVIDIA DGX Spark도 같은 Blackwell 아키텍처를 공유 합니다.Jetson Thor는 다음과 같은 핵심 특징을 제공합니다.• None Multi-Instance GPU(MIG) 지원: 10개의 TPC로 워크로드 분할 실행• None 8K@30Hz 출력: 초고해상도 디스플레이 지원T5000을 포함한 Thor Developer Kit에서 제공되는 스팩은 다음과 같습니다:기존 Jetson 시리즈와의 비교• None 네트워크 고도화: 25GbE 4포트로 초고속 데이터 전송요약하자면, Jetson Thor는 LLM 추론용으로도 사용 가능하며, 로봇에 들어가는 AI 보드의 새로운 기준을 제시합니다.휴머노이드, 로봇, 의료, 산업 자동화 전반에 걸쳐 사용 가능한 현존하는 최고 성능의 보드 입니다.NVIDIA DGX Spark 와 마찬가지로 Jetson Thor 또한 Arm 기반의 아키텍처로 구성되어 있습니다.Jetson Thor 개발자 키트가 도착했습니다. 상자를 열자마자 눈에 들어온 것은 예상보다 큰 크기의 메인 모듈이었습니다.실제 로봇에 들어가야 하는보드치곤 큰 편이었지만 개발자 킷으로 제공된 만큼 히트싱크, 팬 및 다양한 연결을 위한 장치들이 포함되어 있기 때문입니다.만약 로봇에 들어가야 한다고 가정할 때 T5000 모듈과 커스텀하게 만들어진 보드로 구성한다면 그렇게 큰 사이즈가 될 것 같진 않습니다.패키지에는 다음과 같은 내용물이 포함되어 있었습니다:첫인상은 예상보다 크다는 점이었습니다. 이전에 경험했던 다른 보드와 케이블만 덩그러니 들어 있던 개발자 키트와는 달리, 포장부터 세심함이 느껴졌습니다.실버 방열판과 팬이 멋스러움을 주고 테스트용 보드가 아니라 완성도 높은 미니 PC를 꺼내는 듯한 느낌이 듭니다.책상 위에 올려두면 보드라기보다 미니 PC 같은 느낌이 들 것 같습니다.실제로 사양을 고려해보면 개인용 AI 추론 워크스테이션으로도 충분히 활용할 수 있을 것 같습니다.Mac mini처럼 일상적으로 사용해도 손색이 없어 보입니다. 물론 그렇게 쓰라고 나온 제품 은 따로 있지만요.지금까지 Jetson Thor의 상세 사양과 실제 개봉기를 소개 했습니다.다음편에서는 Jetson Thor를 셋팅하는 방법 그리고 제공된 예제를 돌려본 결과를 보여드리도록 하겠습니다.