Talk Lowy(kr)

서론: 왜 지상의 엔지니어들이 우주(Space)로 눈을 돌리는가? 2026년 현재, 구글 트렌드(Google Trends) 및 주요 기술 플랫폼에서 가장 인상적인 상승세를 보이는 대목은 바로 'AI(인공지능)'와 '우주 기술(Space Tech)'의 결합 입니다. 불과 몇 년 전만 해도 우주 공학은 국가 주도의 순수 과학 영역에 가까웠지만, 온디바이스 AI, 차세대 위성 통신, 민간 우주 발사체(SpaceX Starship 등)의 대중화로 인해 테크 생태계의 패러다임이 전면 재편되고 있습니다. 지구상의 데이터센터가 맞닥뜨린 전력난, 수자원 부족, 토지 및 환경 규제 의 장벽을 극복하기 위해, 빅테크와 연구소들은 이제 컴퓨터 서버와 AI 추론 엔진을 지구 저궤도(LEO)로 쏘아 올리기 시작했습니다. 본 글에서는 2026년 AI × 우주 기술의 3대 핵심 트렌드와 독자 여러분이 챙겨야 할 실질적인 테크 인사이트를 정리합니다. 1. 궤도 데이터센터 (Orbital Data Centers: ODCs)의 등장 지상 데이터센터의 한계와 우주라는 새로운 대안 거대언어모델(LLM)과 멀티모달 AI가 보편화되면서 데이터센터의 전력 소비량과 쿨링(Cooling)용 수자원 소모는 폭발적으로 증가했습니다. 2026년의 주요 이슈 중 하나는 지상 전력망의 셧다운 및 탄소 배출 규제입니다. 무제한 태양광 에너지 : 지구 대기의 간섭 없이 24시간 내내 획득할 수 있는 고효율 태양광 에너지를 이용합니다. 자연 진공 및 극저온 쿨링 : 우주의 진공 환경과 열 방사 메커니즘을 활용하여 쿨링 비용을 획기적으로 절감합니다. 지정학적 리스크 분산 : 특정 국가의 전력망이나 물리적 재난으로부터 독립된 글로벌 클라우드 인프라를 구축할 수 있습니다. 2026년은 실험 단계를 넘어 고성능 얇은 궤도 서버(COTS 기반 상용 GPU/TPU 아키텍처)가 실제로 배치되어 가동되는 첫 해로 기록되고 있습니다. 2. 위성 탑재 엣지 AI (Onboard ...

최근 스타트업 대표나 SES 영업 담당자를 만나면 비슷한 질문을 듣는다. “개발자를 더 채용하지 않고 AI로 서비스를 만들 수 없을까?” “고객 프로젝트에 투입할 엔지니어가 부족한데 AI가 대신할 수 없을까?” “코드는 AI가 작성한다는데, 운영 인력까지 줄일 방법은 없을까?” ChatGPT, Claude, Gemini 같은 범용 AI는 문서 작성, 조사, 회의 정리 등 일반적인 오피스 업무를 빠르게 처리한다. Cursor, Claude Code, GitHub Copilot, Devin과 같은 AI 코딩 에이전트는 소스코드를 분석하고 기능을 구현하며 테스트와 Pull Request 작성까지 수행한다. 그러나 기업이 실제로 필요로 하는 것은 단순히 코드를 작성하는 AI 가 아니다. 고객이 돈을 내고 사용할 수 있는 서비스를 만들려면 개발 이후에도 다음 작업이 계속 필요하다. 개발·스테이징·운영 환경 구축 데이터베이스와 네트워크 구성 WAF, CDN, 로드밸런서와 보안 정책 적용 CI/CD와 프로덕션 배포 모니터링과 장애 대응 성능 튜닝과 클라우드 비용 최적화 승인 기록, 변경 이력과 롤백 관리 이 지점에서 AI 코딩 도구와 AI 개발·운영 자동화 플랫폼 의 차이가 발생한다. AI 개발 자동화 경쟁 서비스는 이미 존재한다 GIIP와 비교할 만한 서비스가 전혀 없는 것은 아니다. 다만 시장은 크게 세 종류로 나뉜다. 1. AI 코딩 에이전트 대표적으로 GitHub Copilot, Claude Code, Cursor, Devin 등이 있다. 이들은 기존 저장소를 분석하고 코드를 수정하며 테스트를 실행하거나 Pull Request를 만드는 데 강하다. 실제 AI 코딩 에이전트 비교 연구에서도 Codex, Copilot, Devin, Cursor, Claude Code가 기능 개발, 버그 수정, 문서화 등 서로 다른 작업에서 활용되고 있는 것으로 나타났다. 다만 어떤 에이전트도 모든 작업 유형에서 가장 뛰어난 것은 아니었으며, 최종...

AI가 코드를 작성하는 시대가 되었습니다. Claude, ChatGPT, Gemini, Codex는 이제 간단한 웹 서비스 정도는 몇 분 만에 만들어 냅니다. 그런데 실제로 서비스를 운영해 본 사람이라면 한 가지를 잘 알고 있습니다. 서비스는 코드를 만드는 것이 끝이 아니라, 운영을 시작하는 것이 진짜 시작입니다. 왜 대부분의 AI 서비스는 "릴리스"에서 멈출까? 많은 사람들이 AI에게 이렇게 요청합니다. 쇼핑몰을 만들어줘 예약 시스템을 만들어줘 고객 관리 시스템을 만들어줘 AI는 정말 놀라운 속도로 프로그램을 만들어 냅니다. 하지만 실제 서비스를 공개하려고 하면 그때부터 해야 할 일이 폭발적으로 늘어납니다. 서버는 어디에 배포하지? 데이터베이스는 어떻게 만들지? SSL 인증서는? 도메인은? CDN은? 로드밸런서는? 백업은? 장애가 나면? 보안은? 로그는 어디서 보지? 비용은 어떻게 줄이지? 이때부터는 개발이 아니라 인프라 운영 의 영역입니다. 바로 이 지점 때문에 많은 프로젝트가 출시 직전에서 멈춥니다. AI 코딩 도구가 해결한 것은 "만드는 속도"이고, 아직 남아 있는 것은 "운영 가능한 상태까지 가는 거리" 입니다. 인프라는 사람이 직접 만드는 시대가 끝나고 있다 예전에는 인프라 엔지니어가 서버를 하나씩 만들었습니다. 하지만 지금 AWS, Azure, GCP에서는 대부분의 인프라를 코드로 정의(Infrastructure as Code, IaC) 할 수 있습니다. 예를 들어 웹 서버 3대 데이터베이스 2대 로드밸런서 방화벽 모니터링 이 모든 것을 사람이 콘솔에서 클릭하는 것이 아니라 코드 한 번 실행으로 자동 생성 합니다. Terraform, Kubernetes, GitOps 같은 방식은 이미 현대 클라우드 운영의 표준으로 자리 잡았습니다. 즉, 인프라는 더 이상 수작업이 아니라 자동 생성되는 소프트웨어 가 되고 있습니다. 그런데 ...

Kimi K3가 등장하자마자 익숙한 장면이 반복됐습니다. 2025년 초 DeepSeek R1이 "적은 자원으로 GPT급"을 내세웠을 때처럼, "이제 GPU도 HBM도 덜 필요해진다"는 이야기가 다시 돌기 시작한 겁니다. 이번 방아쇠는 Kimi K3가 채택한 **KDA(Kimi Delta Attention)**라는 선형 어텐션 계열 구조입니다. KV 캐시 부담을 크게 줄인다는 점에서 "메모리·네트워킹 수요가 꺾인다"는 해석이 나온 것이죠. 그런데 실제로 뜯어보면 결론이 오히려 반대에 가깝습니다. 이 글은 Kimi K3를 둘러싼 이슈를 정리하고, 무엇이 검증된 사실이고 무엇이 아직 논쟁 중인 해석인지 를 구분한 뒤, "그래서 나는 이걸 직접 써볼 가치가 있는가"를 스스로 판단할 수 있도록 정리했습니다. 먼저, 사실관계부터: Kimi K3는 무엇인가 논쟁을 다루기 전에 확인 가능한 스펙부터 정리합니다. (아래는 Moonshot AI 공개 자료와 다수 매체 보도로 교차 확인되는 부분입니다.) 공개일 : 2026년 7월 16일, Moonshot AI가 Kimi K3를 공개. 전체 가중치(open weights)는 7월 27일경 공개 예정(Modified MIT 계열 라이선스). 규모 : 총 파라미터 약 2.8조(2.8T) 의 MoE(Mixture of Experts) 모델. 세계 최초의 "오픈 2.8T급"으로 소개됨. 전문가 구성 : 총 896개 expert 중 토큰당 소수(약 16개)만 활성화하는 sparse 구조. KDA(Kimi Delta Attention) : 선형 어텐션 계열. 선형 어텐션 3층 + 풀 어텐션 1층을 3:1 비율 로 교차 배치해, 국소 문맥은 싸게 처리하고 전역 정보 흐름은 풀 어텐션이 보존. 백만 토큰 구간에서 디코딩 속도 최대 수 배 개선 주장. 컨텍스트 : 최대 100만(1M) 토큰 , 네이티브 비전(이미지 이해) 지원. 여기...

얼마 전 이런 질문을 받았습니다. "GIIP FDE Box는 Claude Cowork와 무엇이 다른가요?" 좋은 질문입니다. 그리고 요즘 AI 업무 도구를 검토하는 스타트업 CEO와 기업 관계자라면 누구나 한 번쯤 던지게 되는 질문이기도 합니다. Claude Cowork를 비롯해 ChatGPT의 업무 기능, Perplexity Computer, Genspark, Manus 같은 서비스들은 문서 작성, 조사, 자료 정리, 보고서 작성 등 일반적인 오피스 업무를 지원하는 데 강점이 있습니다. GIIP FDE Box 역시 Slack을 중심으로 이러한 업무를 처리할 수 있습니다. 하지만 GIIP FDE Box의 핵심은 단순한 오피스 업무 보조가 아닙니다. GIIP FDE Box의 핵심은 '실제 시스템을 만들고 운영하는 능력'입니다 GIIP FDE Box는 아이디어를 정리하거나 코드를 작성하는 단계에서 끝나지 않습니다. 외주 개발팀의 기획과 디자인, 기능 설계, 코드 작성부터 실제 서비스가 운영되는 인프라 환경까지 하나의 흐름으로 연결합니다. 예를 들면 다음과 같은 업무를 수행합니다. 요구사항을 정리하고 개발 계획 수립 화면 및 서비스 구조 설계 프론트엔드와 백엔드 코드 작성 Dev, Staging, Production 환경 구성 서비스에 적합한 데이터베이스 설계 및 구축 보안 정책과 접근 권한 설정 ALB, NLB, CDN을 이용한 부하 분산 구조 구성 배포 후 시스템 운영 및 장애 대응 데이터베이스와 애플리케이션 성능 분석 병목 구간 개선과 성능 튜닝 사용량과 아키텍처 분석을 통한 클라우드 비용 최적화 즉, GIIP FDE Box는 질문에 답하거나 코드를 제안하는 도구가 아닙니다. 기획에서 개발, 인프라 구축, 배포, 운영, 성능 최적화까지 실제 결과물을 만들어내는 AI 기반 기술 조직에 가깝습니다. 정말 이런 업무가 가능할까요? GIIP는 어느 날 갑자기 만들어진 데모 프로젝트가 ...

SE, SRE, FDE는 무엇이 다를까? 어원부터 역할, 성향, 학습 방향까지 정리하는 엔지니어 직무 비교 IT 업계의 직무명은 생각보다 위험하다. 같은 “엔지니어”라는 이름을 쓰지만 실제로 하는 일은 완전히 다를 수 있다. Software Engineer, Systems Engineer, Site Reliability Engineer, Forward Deployed Engineer는 모두 엔지니어지만, 문제를 바라보는 관점과 성공 기준이 다르다. 특히 SE라는 약어는 국가와 업계에 따라 의미가 흔들린다. 한국과 일본의 SI 업계에서는 SE를 Systems Engineer로 쓰는 경우가 많고, 한국에서는 Server Engineer를 줄여 SE라고 부르는 경우도 있다. 반면 글로벌 IT 기업의 채용 공고에서 SE는 대개 Software Engineer에 가깝다. 따라서 직업을 선택하려는 사람이라면 단순히 직무명만 볼 것이 아니라, 그 직무가 무엇을 만들고, 무엇을 책임지며, 어떤 성향의 사람에게 맞는지를 봐야 한다. 이 글에서는 SE, SRE, FDE를 어원부터 역할, 성향, 학습 방향까지 비교해 보려고 한다. 1. SE의 어원과 의미 SE는 가장 혼동이 큰 표현이다. 일반적으로는 다음 세 가지 의미로 쓰인다. 첫째, Software Engineer 이다. 글로벌 IT 업계에서 가장 일반적인 의미다. 소프트웨어를 설계하고 구현하는 엔지니어를 뜻한다. 웹 서비스, 모바일 앱, 백엔드 API, 데이터 처리 시스템, SaaS 제품 등을 개발하는 사람이 여기에 해당한다. 둘째, Systems Engineer 이다. 한국과 일본의 SI 업계에서는 오래전부터 SE를 Systems Engineer의 약자로 많이 사용해 왔다. 이 경우의 SE는 단순 프로그래머라기보다 요구사항 분석, 기본 설계, 상세 설계, 고객 조율, 테스트, 프로젝트 관리 일부까지 포함하는 넓은 의미의 시스템 엔지니어에 가깝다. 셋째, Server Engineer 이다. 한...