GitHub Universe’25 Recap Seoul이란
GitHub Universe'25 Recap Seoul ( 즉, 미국 샌프란시스코에서 열린 GitHub Universe 2025 의 주요 발표와 업데이트를 아시아/태평양 지역 개발자들에게 소개하기 위해 서울 포함 여러 도시에서 연달아 열린 리캡 행사)이다.
이 행사는 본행사에서 발표된 GitHub의 최신 기능, AI 개발 플랫폼 전략, 보안 & 협업 관련 소식 등을 한국어 또는 로컬 언어로 요약해 전달하는 자리였다.
올해는 다음과 같은 아젠다들이 있었다.
회사에서 깃허브 코파일럿을 지원해줘서 열심히 사용 중이기도 하고,
그 외에도 깃허브 octokit을 활용해서 다양한 서비스들을 구현 중이고 기획할 예정이기 때문에! 행사에 신청해서 다녀왔다.
사실 CTO님이 인사이트도 얻을 겸 다녀와보라고 메일 주셔서 냉큼..
나는 아래 두 개 내용들에 집중하면서 세션을 들었다:
- 깃허브의 새로운 기능들과 업데이트 사항들에 대해 내가 속한 조직의 업무에 어떻게 적용할 수 있을지
- 변화무쌍한 AI agent와 AI 관련 서비스들로 내 개발 생산성을 어떻게 극대화할 수 있을지
특히, GitHub이나 Microsoft 같은 회사들이 어떤 방식으로 AI를 업무에 적용하는지 굉장히 궁금했었는데🙃
실제 활용 사례들을 소개해주시고, Microsoft 측에서는 시연까지 해주셔서 매우 인상 깊었다.
세미나가 끝난 후 머리에 가장 크게 남았던 부분은 spec이었다.
개발자의 역할이 단순한 서비스 유지보수에서 점차 “서비스 + 유지보수 스펙 관리”로 바뀌고 있다. 따라서 개발을 할 때, 또 AI 에이전트를 프롬프트할 때에도 simple + specific + structured context를 제시하는 게 중요하다는 메시지가 크게 와닿았다. 하지만 내내 강조하셨던 것은 Human-in-the-Loop!! human review는 필수~~
Human-in-the-Loop
: AI가 생성·판단·자동화한 결과를 사람이 반드시 중간(또는 최종 단계)에서 검토·승인·보정하는 구조
< 간단하고 구체적이고 구조적인 프롬프트 + 꼼꼼한 리뷰 > 어쩌면 당연한 메세지이지만 알면서도 그게 참 어려워서 삽질을 많이 했던 것 같다. 동시에 “내 반복되는 업무들도 전부 다 자동화하고 싶다”는 생각이 강하게 들었다. 디자인도 해봤는데 아키텍처가 생각보다 복잡하길래 일단 보류ㅎ
Microsoft 연사님께서 GitHub Spec Kit을 활용한 spec-driven development 과정으로 간단한 앱을 개발하는 과정을 시연해주셨따.
spec-driven development
스펙 기반 개발(Spec-Driven Development, 이하 SDD)은 코드가 중심이 아니라 “스펙(specification)” 그 자체를 출발점으로 삼는 개발 방식이다. 전통적인 코드 중심 개발 방식을 뒤집는다. 따라서 코드를 잘 짜는 방법보다는, AI 시대에 개발자의 사고와 역할을 재정의하는 개발 방식에 가깝다는 느낌을 받았다.
SDD의 핵심은 코드보다 앞서는 스펙, 그리고 모든 판단의 기준이 되는 명세다.
예를 들어, 새 기능을 구현할 때 단순히 “이렇게 동작했으면 좋겠다” 수준으로 AI에게 요청하는 대신, Spec Kit으로 “기능의 목적, 사용자 플로우, 입력/출력, 에러 조건, 보안 요구사항”까지 포함한 명세를 작성한 뒤 AI agent 또는 팀이 그것을 바탕으로 코드를 생성하게 한다. 이렇게 하면 AI의 ‘추측으로 인한 코드 삽질(vibe coding)’을 줄이고, 요구사항 누락, 설계 불일치, 보안 취약점 등의 리스크를 낮출 수 있다.
SDD의 각 단계에 대해 자세히 설명해보자면~ (설명해주셨던 내용 + 내가 작성한 내용)
1. spec-first: “무엇을 만들 것인가(What) / 왜 필요한가(Why)”
SDD에서 가장 중요한 출발점은 “일단 만들어보고 고친다”가 아니라 무엇을 왜 만들 것인지부터 명확히 정의하는 것이다.
요구사항, 문제의 배경, 기대 결과, 제약 조건을 먼저 글로 구조화하고, 그 스펙이 이후 모든 구현과 논의의 기준점이 된다.
AI를 활용한 개발에서는 이 단계가 특히 중요하다. 스펙이 모호하면 AI는 추측하고, 추측은 곧 결과물의 흔들림으로 이어지기 때문이다.
2. spec-anchored: 팀 표준과 규약을 사양 중심으로
스펙은 한 번 작성하고 버리는 문서가 아니라, 개발 전 과정에 ‘닻(anchor)’처럼 고정되어 있는 기준이 된다.
* Github Spec Kit → 개발자의 명확한 의도 작성을 도와주는 도구
GitHub Spec Kit은 이러한 spec-anchored 접근을 실제 개발 흐름에 녹여내기 위한 도구다.
Spec Kit에서는 아래와 같은 흐름을 따른다.
Constitution(대원칙)
- Specify – 요구사항 정의
무엇을 만들 것인지, 어떤 문제가 해결되어야 하는지 명확히 서술 - Plan – 기술 정의
사용할 기술, 아키텍처 방향, 제약 조건 정리 - Tasks – 작업 정의
구현 단위로 쪼갠 실질적인 작업 목록 - 1-3 반복 후 스펙 픽스
충분히 사고하고 수정한 뒤 스펙을 고정 - Implement – 구현
고정된 스펙을 기반으로 코드 작성 및 AI 활용
이 구조가 인상 깊었던 이유는, ‘생각 → 정리 → 고정 → 실행’의 흐름을 강제로 만들어 준다는 점이었다.
AI에게 바로 “코드 짜줘”라고 하기 전에, 개발자 스스로 사고를 정제하도록 유도한다.
* Github MCP Registry
MCP Registry는 spec-driven 환경에서 도구·에이전트·프레임워크를 표준화하여 연결하는 역할을 한다.
여러 AI 에이전트나 자동화 도구들을 임의로 쓰는 것이 아니라, 명세에 맞춰 어떤 도구들이 어떤 역할을 맡을지를 구조적으로 관리할 수 있다.
이는 특히 팀 단위, 혹은 장기적으로 유지보수해야 하는 서비스에서 AI 활용이 ‘개인 노하우’로 흩어지지 않도록 잡아주는 장치로 느껴졌다.
3. spec-as-source: 코드와 테스트, 설계 문서의 근원
마지막 단계는 스펙을 단순 참고 문서가 아닌, 진짜 ‘단일 진실의 근원(Single Source of Truth)’으로 삼는 것이다.
즉,
- 코드가 스펙을 따르고
- 테스트가 스펙을 검증하며
- AI 역시 스펙을 기준으로 판단하고 생성한다
이 구조에서는 스펙이 바뀌면, 구현과 테스트, AI 프롬프트 전략까지 함께 바뀌어야 한다.
개발자는 점점 “코드를 직접 다루는 사람”이라기보다 스펙을 설계·관리하고 시스템 전체를 조율하는 역할에 가까워지는 것 같다.
그리고 함께 사용하면 좋은 MCP나 프레임워크들도 소개해주셨당
듣는 내내 “어떻게 내 업무와 결합할 수 있을까?”를 고민하는 시간이었다.
그리고 보안과 관련된 세션도 있었다.
나는 주로 자동 배포와 관련되 업무를 하고 있고, 사용자 credential이나 API-key를 자주 다루기 때문에 보안 이슈에 민감하다.
지금도 종종 실수로 민감한 정보들을 push해서 허걱😱하고 성급히 만료시키거나 삭제하고 refresh 한다. 종종 조심하라고 혼나기도 한다ㅎㅎ
이번 행사에서는, 단순한 코드 호스팅이나 협업 툴로서의 GitHub을 넘어서 에이전트 워크플로우에 대한 보안·관리·감사 로그, 그리고 접근 제어 정책을 통합적으로 제공하는 모습을 알게 되어 인상적이었다. 깃허브의 코드 관리 이상의 다양한 기능들이 있다는 게 신기했고, 앞으로 내가 사용하는 인터페이스나 서비스들을 좀 더 깊이 탐구해보고, 현재 사용하는 방식과 비교해보면 좋을 것 같다는 생각이 들었다.
마지막으로~~ 쉬는 시간, 그리고 행사 끝난 후 제공됐던 음식들과 디저트가 정말 많아서 아주 행복했다 크크
아 그리고 또또! 깃허브랑 마이크로소프트 수건을 받았는데 부들부들하고 좋았따ㅎ
'개발일기' 카테고리의 다른 글
| git worktree로 브랜치 전환 없이 두 작업하기 (0) | 2026.09.11 |
|---|---|
| 엑셀 Power Query로 CSV 합치기 실습 (0) | 2026.09.09 |
| [2024 Google Solution Challenge Top 100 회고] 1. 아이디어 도출 과정 (9) | 2025.05.22 |
| 수퍼클래스 뽑아내기~ (3) | 2024.09.26 |
| [Spring] 카카오 OAuth 소셜로그인 구현(사용자 추가 동의 포함) (0) | 2024.06.27 |
댓글