Meta 서비스 (페이스북, 인스타그램 등)

링크드인 (LinkedIn)

X (구, Twitter)

Github 코드 리포지터리

(Disclaimer – 이 설정 변경이 권장 사항은 아니며, 여러분의 검토와 선택에 달려 있습니다.)

1. 모든 것을 대체할 수는 없다

AI가 모든 것을 바꾸고 삼켜버릴 것처럼 이야기하지만, 현실의 모든 것을 바꾸기는 어렵습니다. 세상에는 여전히 AI가 경험하지 못한 것들이 많고, 앞으로 나올 새로운 것을 미리 학습하는 건 불가능합니다. 과거에도 어떤 기술이 세상을 완전히 바꿀 것처럼, “이번에는 다르다”고 늘 이야기했지만 그렇지 못했습니다. 세상은 새로운 무언가가 모두 대체하는 것이 아니라, 과거와 현재의 모든 것들이 함께 공존합니다. 획일성이 아니라 다양성이 우주의 본질이기 때문입니다.

2. 변화에는 시간이 필요하다

트렌드를 앞서가는 선구자들이 많은 실험과 시도를 하며 좋은 정보를 공유하지만, 그것을 실제로 도입해서 변화시키는 것은 또 다른 시간축이 필요합니다. 현재 AI만 보더라도, AI 기반 애플리케이션을 구축하는 기술 개념, 프로토콜, 아키텍처, 프레임워크가 계속 나오고 있습니다. 이에 대한 인간의 학습 시간은 여전히 병목이 될 수밖에 없습니다. AI 기술은 필연적으로 인간 통제하에 놓이도록 규제될 것입니다. 따라서 인간 병목은 그 자체로 문제가 아니라, 새로운 통찰을 생성하는 시간이 될 것입니다.

3. 누구나 쓸 수 있는 기술이 승리한다

자주 했던 이야기인데, 세상을 바꾸는 기술은 진입 장벽을 낮추고 누구나 접근 가능하여(easy to access), 많은 사람이 참여함으로써 새로운 시장을 창출했습니다. IT 역사상 오픈소스 소프트웨어, 웹 표준, 오픈 API, 클라우드 등이 대표적인 사례입니다. AI 기술도 머리 아픈 수식이 아니라, 이제 누구나 쉽게 접근 가능하도록 진화하고 있습니다. 아직은 비용에 대한 장벽이 있지만, 이것도 더 많은 투자와 시장 확대로 해결될 것입니다. 만약 지금 당신에게 AI가 복잡하고 어렵게 느껴진다면, 그냥 조금 기다려도 된다는 뜻입니다.

개인적으로 제가 하는 실천 방법은 좀 더 “초심으로 돌아가 기본에 더욱 충실하는 것”입니다. 내가 현재 하고 있는 일에서 변화를 시도해보고, 조금씩 바꿔 가는 것입니다. 예를 들어, 현재 제가 하고 있는 본업은 AI가 가장 잘하는 글쓰기이지만, 앞으로 AI가 나의 스토리텔링 기법을 따라할 수 있는 독창적인 스타일을 만들 수 있는 방법을 찾아보고 있습니다. AI에게 계속 물어보고, 오히려 AI가 하지 못하는 이야기를 더 많이 써 볼 생각입니다.

“AI가 내 일자리를 대체할까?”

이 질문은 요즘 개발자들 사이에서 가장 뜨거운 화두일 것입니다. 마치 1960년대 코볼(COBOL)이나 1990년대 비주얼 프로그래밍이 등장했을 때처럼, 기술의 거대한 물결 앞에서 우리는 또다시 ‘개발자의 역할 변화’라는 숙명적인 질문에 직면했습니다. 하지만 버너 보겔스 박사님은 이 변화를 종말이 아닌, 새로운 시작, 즉 새로운 르네상스(Renassance)의 도래로 규정합니다. AI가 코드를 생성하는 속도는 놀랍지만, 그 코드가 만들어내는 가치와 시스템의 본질을 이해하고 책임지는 일은 여전히 인간 개발자의 몫으로 남습니다. 이제 우리는 AI라는 강력한 도구를 손에 쥐고, 과거 르네상스 시대의 선구자들처럼 새로운 차원의 창조자로 거듭나야 할 때입니다.

이 새로운 시대에 성공적으로 적응하고 앞서나가기 위해, 보겔스 CTO는 개발자가 갖춰야 할 다섯 가지 핵심 자질, 즉 르네상스 개발자 프레임워크를 제시했습니다. 이 자질들은 단순히 새로운 기술을 익히는 것을 넘어, 사고방식과 태도의 근본적인 전환을 요구합니다. 우리는 이제 개별 부품을 넘어선 시스템 전체를 이해하고, 모호한 자연어 속에서 명확한 의도를 전달하며, AI가 생성한 결과물에 대한 최종적인 품질 책임을 지는 ‘주인 의식’을 가져야 합니다. 이 다섯 가지 자질을 내재화할 때, 우리는 AI의 도움을 받아 이전에는 상상할 수 없었던 복잡한 문제들을 해결하는 진정한 빌더로 자리매김할 수 있을 것입니다.

르네상스 개발자는 과거의 장인들처럼 경계를 허물고 깊이와 넓이를 동시에 추구합니다. 베르너 보겔스가 제시한 다섯 가지 핵심 역량은 다음과 같습니다.

1. 호기심을 잃지 않는 개발자 (Curiosity)

호기심은 학습과 발명의 원동력이며, 개발자라면 당연히 가져야 할 본능입니다.

• 끊임없이 무언가를 분해하고 이해하려는 본능을 보호해야 합니다.
• 실패를 두려워하지 않는 실험 정신이 중요하며, 이는 곧 학습으로 이어집니다.

2. 시스템 전체를 보는 사고방식 (Systems Thinking)

개별 부품이 아닌, 전체 시스템의 피드백 루프와 상호작용을 이해하는 능력입니다.

• 옐로스톤 국립공원의 늑대 사례처럼, 작은 변화(포식자 재도입)가 전체 시스템(강의 흐름, 식생)을 어떻게 바꾸는지 이해해야 합니다.
• 모든 서비스, API, 큐는 더 큰 시스템의 일부이므로, 격리된 변경은 전체에 영향을 미친다는 점을 인지해야 합니다.

3. 정밀한 소통 능력 (Communication with Precision)

AI 시대에는 모호한 자연어 대신 명확한 사양(Specification)을 통해 기계와 소통하는 능력이 중요해집니다.

• 자연어는 본질적으로 모호하지만, AI에게 정확한 로직을 생성시키려면 모호성을 줄여야 합니다.
• 스펙 주도 개발(Spec-driven development)은 AI와의 소통에서 요구사항, 설계, 태스크를 명확히 분리하여 정밀도를 높이는 핵심 방법론입니다. 스펙 주도 AI 코딩 도우미, Kiro를 소개합니다!

4. 품질에 대한 주인의식 (Ownership of Quality)

AI가 생성한 코드라도 최종적인 책임은 개발자에게 있으며, 이는 규제 준수와 직결됩니다.

• AI 코딩은 도박이 아닌 공학이어야 하며, 생성된 코드를 주의 깊게 검토하는 것이 필수입니다.
• AI 시대에는 코드 생성보다 검토(Review)의 중요성이 커지며, 이는 검증 깊이(Verification Depth)를 확보하는 핵심 메커니즘입니다.

5. 다방면에 능통한 폴리매스 (Polymath) 지향

깊이 있는 전문성(Depth)과 더불어 여러 분야를 아우르는 지식의 폭(Breadth)을 갖춰야 합니다.

• 레오나르도 다빈치처럼 여러 분야를 넘나들 필요는 없지만, T자형 인재를 넘어 지식의 폭을 넓혀야 합니다.
• 데이터베이스 전문가였던 짐 그레이처럼, 자신의 전문 분야를 넘어 비즈니스와 기술 전반을 이해할 때 더 나은 아키텍처 결정을 내릴 수 있습니다.

결국, AI 시대의 개발자는 코드를 ‘작성’하는 사람에서 코드를 ‘이해하고 검증하며 시스템을 설계’하는 사람으로 진화해야 합니다. 고객들은 우리가 밤새워 구축한 데이터베이스의 안정성이나 롤백의 정교함에 대해 칭찬하지 않을 것입니다. 그들은 단지 버튼을 눌렀을 때 작동하는 결과 만을 볼 뿐입니다.

하지만 바로 그 보이지 않는 곳의 가치, 즉 운영의 탁월함(Operational Excellence)에 대한 전문가적 자존심이야말로 최고의 개발자를 정의하는 기준입니다. AI가 아무리 많은 코드를 쏟아내도, 그 모든 것의 최종 책임과 가치는 오직 당신, 즉 개발자에게 있습니다. 이제 당신의 호기심을 무기로 삼아, 이 새로운 르네상스를 이끌어 갈 여정을 시작하십시오.

솔직히 그의 마지막 기조 연설이라서 매우 아쉽습니다. 그는 마지막에 “빌더 여러분, 정말 자랑스럽습니다.”라고 하셨는데, “Werner 박사님, 당신은 훌륭한 사상가이자 비전가이자 엔지니어였습니다. 그동안 감사했습니다”라고 말하고 싶습니다.

P.S AWS re:Invent 2025 행사의 기조 연설, 이노베이션 토크, 주요 강연 세션은 AWS Events 유튜브 채널에 올라오고 있습니다. 검색 후, 흥미로운 강연 세션을 들어 보시길 바랍니다. 요즘은 자동 번역 자막도 너무 잘되어 있어서, 영어에 대한 부담 없이 들으실 수 있어요.

그리고, Werner 박사님 기조 연설 장에는 의자 마자 The Kernel이라는 종이 신문이 하나씩 놓여져 있었다고 합니다. 기조 연설의 중요한 배울 점을 Amazon의 엔지니어 분들과 함께 녹아 놓은 콘텐츠라서 추천 합니다.

https://thekernel.news/

이제 생성형 AI를 넘어 자율적으로 추론하고 계획하며 작업을 수행하는 에이전틱 AI(Agentic AI) 시대에 도래했습니다. 어떤 분들은 지금 AI에게 코딩을 맡기는 것에도 회의감을 품고 있기도 합니다. 과거에도 C언어를 배울 시절에는 어셈블리를 모른다고, Java를 배울 시절에는 C언어를 모른다고 하는 우려가 있었습니다. 역사는 반복됩니다. AI가 뱉어내는 코드의 신뢰성 논쟁은 결국 새로운 도구에 대한 ‘신뢰의 문제’이며, 우리는 이 변화를 어떻게 받아들여야 할지 생각해 보려고 합니다.

바이브 코딩에서 스펙 기반 개발로 전환

최근 유행하는 ‘바이브 코딩(Vibe Coding)’은 AI 에이전트에게 요구 사항을 던져 코드를 즉석에서 생성하게 하는 방식입니다. 이는 프로토타입 제작에는 유용하지만, 프로젝트의 전체 개발 사이클(설계 부터, 구현, 배포, 유지 보수) 걸쳐 일관된 제어와 품질을 보장하기 어렵다는 명확한 한계를 드러냈습니다.

이러한 한계를 극복하기 위해 등장한 것이 바로 스펙 기반 개발(Spec-Driven Development)인데요. 이는 단순히 코드를 생성하는 것을 넘어, 요구사항 정의(스펙)를 개발의 근간으로 삼아 일관성을 유지하는 방법론입니다. AWS에서 만들고 있는 ‘키로(kiro)’ AI 코딩 도구는 앱의 요구사항을 AI가 미리 스펙 문서로 정의하고, 이 스펙을 기반으로 코드를 생성하며, 이후의 테스트, 문서화, 배포까지 에이전트 훅(Agent Hook)을 통해 자동화하는 구조를 제시합니다.

AI 전환기의 개발자 역할 재정의

이러한 전환은 개발자의 역할을 근본적으로 재정의합니다. 이제 개발자는 코드 한 줄 한 줄을 만들고 다듬는 데 집중하는 것이 아니라, 제품 자체와 요구사항을 명확히 정의하는 능력에 더 많은 노력을 기울여야 합니다. 그리고, 애플리케이션의 장기적인 안정성, 확장성, 그리고 복잡한 환경에 대한 전체적인 통찰을 제시하는 데는 여전히 인간의 판단이 필요합니다. 개발자는 AI의 판단을 넘어서는 구조적 결정을 내리고, 시스템을 어떻게 녹여낼지에 대한 특히, 시스템 아키텍처 통찰력을 갖춰야 합니다. 이는 다양한 환경과 제약 조건을 고려하는 인간 고유의 영역입니다.

요즘 같은 기술 전환기에는 ‘어떻게 해야 하는가’에 대한 정답이 없습니다. 가장 효과적인 대응은 새로운 변화에 능동적으로 참여하고, 새로운 도구를 끊임없이 실험해보는 자세입니다. AI 활용으로 남는 시간을 활용하여 동료 개발자들과의 대화, 커뮤니티 활동을 통해 통찰을 공유하고 함께 문제를 헤쳐나갈 방법을 모색하는 것도 중요합니다.

AI는 강력한 도구이지만, 개발자의 역할은 사라지지 않습니다. 오히려 요구사항을 명확히 하고, 시스템의 뼈대를 세우며, 사람들과 소통하는 더욱 고차원적인 역할로 진화하고 있는 것입니다. 두려움 대신 호기심을 가지고 이 새로운 흐름에 올라타야 할 때입니다.

1.
집에서 가끔 쫄면을 직접 해 먹고 있다. 면 뿐만 아니라 양배추, 당근, 사과를 듬뿍 잘게 썰어서 넣고 양념장에 비비면 일품이다. 그런데, 다 먹고 나면 항상 후회되는 점이 있었다. 매번 맛있는 면을 먼저 먹다 보니, 마지막에 안 먹은 채소들이 남는다. 그래서, 언제부터 인가 면과 채소를 같은 비율로 의도적으로 먹기 시작했다. 그래야 마지막에 채소만 먹는 고역이 사라지기 때문이다. 운동, 업무, 인생에서도 마찬가지다. 좋아하는 것만 하다 보면, 귀찮고 하기 싫은 일은 계속 밀리게 된다. 누군가 “뭔 생각을 해. 그냥 해.”라고 했던 것처럼… 곁들어지는 단순하고도 귀찮은 일을 미루지 않고 함께 해 내야만, 한 단계 성숙할 수 있다. 회사 블로그 글 쓰기도 마찬가지다. 개인 블로그처럼 한번 쓰고 끝났다 하면 좋겠지만, 계속 담당자들의 피드백과 수정을 거듭하는 지난한 과정을 거친다. 그래야 좋은 글이 나온다. 글로벌 회사의 블로거가 된지 5년이다. 앞으로 그 이야기를 써 보려한다. (2025년 11월 23일)

2.
회사 블로그 작가가 된지 5년이 되었다. 지금껏 200여 개를 넘게 썼다. 혼자 쓰는 게 아니라, 서비스팀에서 신규 기능 출시를 담당하는 제품 매니저, 제품 마케팅 매니저, 두서너 명의 소프트웨어 개발자 등 적어도 6명 이상과 두 달가량 협업한 결과물이다. 그냥 다른 회사 블로그처럼 해당 제품 매니저 (혹은 임원)이 쓰면 되지, 왜 굳이 이런 복잡한 과정을 거치는지 의문을 제기하는 사람도 많다. 뉴스 블로그 작가들은 제품 팀이 아니라 고객의 편에서 글을 쓴다. 200개가 넘는 모든 클라우드 서비스에 전문가는 없다. 우리는 초보자의 관점에서 출시될 기능을 먼저 써본 후, 있는 그대로 솔직 담백하게 소개한다. 신규 기능의 첫번째 사용자로서 독자들이 할 수 있는 것만, 군더더기 없이 꼭 필요한 정보만 알리기 위해 노력한다. 제품팀에서 주는 마케팅 미사어구를 배제하고, 실현되지 않은 미래의 약속들은 하지 않는다. 독자들에게는 솔직하고, 핵심적이면서도 짧은 글이 가장 강력하다. (2025년 11월 27일)

3.
홍시의 계절이 돌아왔다. 청도 반시를 멋모르고 주문하면, 딱딱하고 떫은 감이 배달되어 적잖이 당황하게 된다. 상자에 밀봉된 상태에서 상온에서 며칠을 잘 익혀야 맛있는 홍시가 된다. 감이 빨리 잘 익으라고 에틸렌 가스를 배출하는 천연 연화제도 상자 바닥에 부착되어 있다. (어떤 판매자는 연화제 하나를 더 동봉해주는 센스도 있다.) 그런데, 빨리 먹고 싶다고, 궁금해서 매일 상자를 열어보면, 에틸렌 가스가 날아가고, 감은 더 늦게 익는다. 맛있는 홍시를 먹으려면, 적당한 때까지 참고 견디는 것이 중요하다. 너무 익혀도 문제다. 늦으면 물러터진 홍시를 먹을 수도 있다. 적당한 때를 알아야 하고, 이것은 경험을 통해서만 알 수 있다. 글 쓰기도 마찬가지이다. 빨리 게시해야 할 게 있고, 잘 익혔다 천천히 내보내야 할 게 있다. 그럴려면 무조건 많이 써봐야 한다. AI가 아무리 글을 잘 써줘도 경험을 압축할 수 있는 알고리즘은 없다. (2025년 12월 10일)

4.
대개 하나의 블로그 글은 하나의 서비스에 속한 출시만을 담당한다. 어쩌다 보면 A, B, C 서비스의 데이터가 유기적으로 묶이거나 통합되는 경우도 있다. 이때는 각 제품 매니저나 제품 마케팅 매니저가 모두 함께 협업 해야하기 때문에, 조율해야 하는 일도 많아진다. 예를 들어, 제목 정할 때도 각자가 선호하는 용어가 있다. 스크린 캡처를 찍을 때도, 본인 서비스가 주목받는 화면을 원한다. 짧은 블로그 글에서 모든 기능을 다 소개해야 하는 부담도 있다. 복잡성이 증가할 수밖에 없다. 이때, 가장 중요한 것은 독자에게 간단하게 보이면서도, 스스로 활용 가능성을 찾도록 하는 것이다. 입문 사용자에게는 “와! 이건 너무 쉽네”라고 느끼게 하고, 고급 사용자에게는 “이걸 이런 사례에 응용할 수 있겠네”라고 생각하게 해야 한다. 그러려면, 독자들에게 너무 많은 약속을 하면 안 된다. 이건 이렇게 쓸 수 있고, 저렇게도 쓸 수 있다고 나열하지 않고, 스스로 느끼고 상상하게 해야 한다. (2025년 12월 18일)

AWS에서도 개발자 분들의 피드백을 기반으로 AI 코딩 전문 IDE 소프트웨어인 Kiro를 공개했습니다. Kiro는 단순한 에이전트 AI 기반 채팅 뿐만 아니라, 자신이 개발하고 있는 코딩 프로젝트를 이해하고, 개발 워크플로우를 자동화하며, 심지어 외부 지식까지 활용하여 현재 업무 생산성을 극대화할 수 있습니다. 지금 부터 어떻게 시작하는지 같이 알아볼께요!

1. Kiro 시작하기

우선 Kiro를 다운로드 해 보겠습니다! 현재 맥 OS, 윈도우, 리눅스 운영 체제 모두를 지원합니다.

Kiro를 설치하시면, 다양한 로그인을 지원합니다. Google, Github, 그리고 AWS 무료 계정인 AWS Builder ID를 지원하는데요. AWS 계정이 없더라도 무료로 바로 이용 가능합니다.

로그인을 하고 Kiro를 실행해 보면, 만약 본인이 VS Code 등 기존에 사용하는 IDE가 있다면, 개발 환경 세팅을 가져올 지 물어봅니다. 마치 웹 브라우저를 바꾸는 것이랑 비슷한데요. 프로젝트 및 개발 환경 설정, 그리고 확장 기능도 모두 가져올 수 있어요. (Kiro도 오픈 소스 VS Code를 기반으로 만들어져 있기 때문에 모두 호환됩니다.)

Kiro가 처음 실행된 모습은 아래와 같습니다. 거의 VS Code와 같이 생겼죠? 왼쪽 메뉴에 귀여운 유령 아이콘을 눌러 보면, Kiro만의 주요 기능들이 나타납니다. 오른쪽 채팅 창은 여러분이 보던 AI과 대화하기 위한 것입니다. 보시다시피 Vibe와 Spec 모드 두가지가 있습니다. 바이브 모드는 새로운 아이디어를 처음 구현할 때 쓰시면 되구요. 스펙 모드는 코딩하려는 구현하려는 프로젝트를 상세한 사양과 구현을 미리 정하고, 일관된 개발 방식을 유지할 때 쓰시면 됩니다.

이제 제가 개발하고 있는 코딩 프로젝트를 열어볼 거에요. 현재 Kiro는 영어로만 답변하고 있어서, 채팅창에 ‘앞으로 모든 결과는 한국어로 답변해줘’라고 적기만 하면, 앞으로 한국어로 계속 대화 가능합니다. 프로젝트의 목록을 검토해 보고, 계속 개발할 프로젝트를 선정해 주니까, 알아서 앞으로 개선해야 할 사항 등을 잘 추천해 주네요.

채팅 창 하단의 Autopilot 기능을 켜면, AI가 주도적으로 제안을 해주는 기능입니다. AI 코딩에 가장 좋은 성능을 내는 Claude Sonnet 4.0이나 3.7 모델을 선택할 수도 있습니다. 이제 Kiro만의 주요 기능 몇 가지를 알아보도록 하겠습니다.

2. 프로젝트 이해도를 높이는 ‘Steering’

자! 이제 우리는 현업 개발 업무를 위해 Kiro를 써 볼거에요. 여러분의 코딩 프로젝트가 열려 있다면, 우선 왼쪽 메뉴에서 Generate Steering Docs를 선택합니다. Kiro가 여러분의 프로젝트를 완벽하게 이해하도록 돕는 핵심 요소가 바로 ‘스티어링(Steering)’ 문서입니다. Kiro가 자동으로 프로젝트의 코드 베이스, 코딩 규칙, 요구 사항 등을 파악하게 됩니다.

이제 Kiro가 자동으로 .kiro/steering/ 경로에 프로젝트 스티어링 문서를 생성해줍니다. 제품 목적, 기술 스택과 프레임워크, 프로젝트 구조 및 규칙 등에 대한 문서가 정의됩니다. (만약 영어로 만들어졌다면, 채팅창에 한국어로 바꿔 달라고 하시면 됩니다.)

※ 정태환님이 알려주신 Kiro 한국어 사용 가이드입니다. 우선 VSCode IDE 기반이라 Kiro에서 한국어 확장 기능을 설치하면 Kiro UI는 한국어로 바뀝니다. 그리고, 한국어 설치하면 UI가 한국어로 됩니다. 그리고, 한국어로 응답하는 스티어링파일(.kiro/steering/korean-language.md) 하나 추가하시면 됩니다.

# 한국어 응답 규칙
## 언어 설정
- 모든 응답은 한국어로 작성해야 합니다
- 코드 주석도 가능한 한 한국어로 작성합니다
- 기술 용어는 필요시 영어와 한국어를 병행 표기합니다 (예: "컨테이너(container)")
- 에러 메시지나 로그는 원본 언어를 유지하되, 설명은 한국어로 제공합니다
## 예외 상황
- 코드 자체는 영어로 작성 (변수명, 함수명 등)
- 공식 문서나 명령어는 원본 언어 유지
- 사용자가 명시적으로 다른 언어를 요청하는 경우에만 예외 적용

3. 구체적 구현 계획을 위한 ‘Specs’

스펙(Specs) 기능은 고수준의 아이디어를 실제 프로젝트로 구현할 수 있는 상세한 계획을 만들어 줍니다. 스펙은 아래 세 단계를 거쳐 아이디어를 구체화합니다.

1. 요구사항(Requirements): EARS 표기법으로 사용자 스토리를 정의합니다.
2. 설계(Design): 기술 아키텍처와 구현 접근 방식을 문서화합니다.
3. 작업(Tasks): 추적 가능한 개별 구현 단계를 생성합니다.

첫 번째 스펙을 생성하려면 채팅 세션에서 Spec 버튼을 클릭하거나 kiro 패널의 Specs 섹션에서 + 버튼을 누릅니다. 그러면, 아래와 같은 프롬프트가 뜨는데요. 저는 한국어로 AWS에 배포할 수 있는 웹 애플리케이션 구축 스펙을 만들어 달라고 해보았습니다. (앞서 말씀 드린대로, 현재 Kiro는 영어로 답변을 주고 있기 때문에 한국어로 만들거나 답변하라고 지정 해주시는 게 좋습니다.)

이제 Kiro는 단계별 워크플로우를 안내하여 요구사항 정의, 기술 아키텍처 및 컴포넌트 설계 문서화, 그리고 실행을 위한 개별 작업 생성까지 모든 과정을 도와줍니다.

스펙 문서가 완료되면, 각각의 문서들을 검토해 보고 수정하실 게 있으면 수정하세요. 아마 똑똑하게 잘 만들어 주었을 것입니다.

4. 반복 작업을 줄여주는 ‘Agent Hooks’

코딩 하다 보면, 내가 소스 코드 수정을 끝마쳤을 때, 자동으로 수행해 주고 싶은 기능이 있을 수 있을 거에요. 예를 들어, README 문서를 업데이트 하라던지, 유닛테스트 코드를 자동으로 만들라던지, 배포 파이프라인에 태우라던지 말이죠. 즉, 특정 파일 패턴 수정 시 미리 정의된 작업을 자동으로 실행하수 있는 것이 ‘에이전트 훅(Agent Hooks)’ 기능입니다. 여러분의 반복적인 작업을 자동화할 수 있으니, 개발 시간을 크게 절약할 수 있겠죠.

새로운 Hook을 생성하려면 Kiro 패널의 agent hooks 섹션으로 + 버튼을 클릭합니다. 저는 API 수정 시, README 파일을 자동으로 업데이트하라고 했어요. 앗! 그런데, 또 영어로 작성하네요. 제가 아까 말씀 드린대로 한국어로 꼭 만들라고 해주세요.

Hook의 동작을 정의할 때 좀 더 명확하게 설명하면 좋습니다. 즉, 아래와 같이 이벤트 유형과 파일 패턴, 지침을 더 명확하게 내리면 더 똑똑하게 만들어줍니다.

• 이벤트 유형(Event Type): 파일 생성, 파일 저장, 파일 삭제, 수동 트리거 등.
• 파일 패턴(File Pattern): Hook을 트리거할 파일 지정 (예: src/**/*.tsx)
• 지침(Instructions): 수행할 특정 작업 정의

예를 들어, “React 컴포넌트 파일을 저장할 때 해당 테스트 파일을 자동으로 생성 또는 업데이트해 줘”라고 하시면 됩니다.

5. 한계를 뛰어넘는 ‘MCP’

요즘 가장 핫한 MCP (Model Context Protocol)도 지원합니다! MCP를 사용하면 Kiro의 기능을 확장하여 외부 API, 서비스, 전문 지식 베이스와 통합할 수 있습니다. . 즉, 단순히 코드베이스 내의 정보 뿐만 아니라 웹 검색, 데이터베이스, 클라우드 서비스 등 광범위한 외부 정보를 활용할 수 있게 됩니다.

MCP를 설정하려면, Kiro 패널에서 MCP 섹션의 연필 아이콘을 클릭하여 편집 모드로 들어갑니다. 기본적으로 fetch MCP server가 json 파일에 포함되어 있으며, disabled=false로 설정하여 연결할 수 있습니다. 저는 AWS가 제공하는 다양한 AWS MCP 서버 중에서 AWS Diagram 생성기와 AWS 문서 검색기를 추가했습니다.

Amplify를 이용해서 웹 애플리케이션을 배포하는 AWS 아키텍처 다이아그램을 만들어 달라고 요청해봤습니다. Kiro가 AWS 다이아그램 생성 MCP를 활용해서 아이콘 목록을 가져오고 아키텍처 다이아그램을 아주 멋있게 그려줬어요. 상세 설명은 덤이죠.

MCP를 이용하면, 본인 PC에 있는 문서를 검색한다던가, 개발 중인 데이터베이스에 자연어로 SQL 쿼리를 던진다거나, 회사 지식 기반 사이트에서 원하는 답변을 얻는 것도 가능해집니다. 다만, 보안에 대해 유의하시면서 사용하시길 바랍니다. (MCP – Model Context Protocol 보안 위험 참고)

6. 데이터 수집 해제하기

Kiro는 독립형 에이전트 IDE로 작동하는 AWS 기반 애플리케이션으로 Kiro의 보안 프레임워크는 AWS의 보안 인프라를 기반으로 구축되었습니다. 서비스 개선을 위해 사용자의 콘텐츠와 텔레메트리 데이터를 수집할 수 있으며, 다음과 같은 설정으로 수집 해제를 하실 수 있어요.

1. Kiro 설정에서 User (사용자) 하위 탭의 Application (애플리케이션)을 선택합니다.
2. 드롭다운에서 Telemetry and Content(텔레메트리 및 콘텐츠)를 선택합니다.
3. 드롭다운 필드에서 Disabled(사용 안 함 )를 선택하여, 제품 원격 분석 및 사용자 데이터 수집을 비활성화합니다.

Amazon Q Developer Pro를 구독하거나, Pro를 구독하는 AWS 계정을 통해 Kiro에 접근하는 경우, 서비스 개선을 위해 콘텐츠를 사용하지 않습니다. Kiro 개인 정보 보호 및 보안에 대한 더 자세한 사항은 Kiro 공식 문서를 참고하세요.

이제 시작해 보실까요?

이제 Kiro의 핵심 기능을 익히셨으니, 지금 바로 10배 100배 생산성 개발자가 되어 보시면 어떨까요? Kiro와 유사한 Cursor AI를 전사에 도입하고, 6개월이 지난 경험을 쓴 채널톡 기술 블로그에 이런 글이 있더라구요.

가장 중요한 건 기존 개발 방식에서 완전히 벗어나는 거예요. AI에게 최대한 많은 것을 위임하기 위한 노력을 해야 해요. 이 차이가 엄청나게 큰 결과를 만들어냈어요… 단순히 빨라진 것 뿐만 아니라, 마치 피어 엔지니어와 토론하면서 더 좋은 구조를 고민하고, 미리 아키텍트를 그리고 작업을 할 수 있어서 충분히 좋은 코드를 작성할 수 있었습니다… 이 과정에서 가장 중요한 건 사람의 문제 인식과 AI가 인지한 문제 인식을 최대한 동일하게 만드는 것입니다. 구체적인 패턴을 제시하면 AI가 정확히 어떤 구조를 원하는지 이해하고, 일관성 있는 코드를 작성할 수 있어요… 이런 시대일수록 “어떻게 구현할까?”보다 “무엇을 구현할 것인가?”가 더 중요해졌다고 말씀하시며, 문제를 쪼개고 정의하는 능력의 중요성을 강조하셨어요.

Kiro는 AI와 페어 프로그래밍을 하면서 함께 맥락을 공유하면서 개발할 수 있는 다양한 기능이 기본적으로 탑재되어 있습니다. 코딩을 시작하기 전에 미리 디자인을 하는 모범 사례처럼 이제 Kiro와 같이 협업해서 전문적인 AI 코딩을 시작해 보시기 바랍니다.

※ AWS 한국 사용자 모임(AWSKRUG)는 AI 엔지니어링 소모임을 운영하고 있습니다. 앞으로 Kiro에 대한 다양한 실습이랑 정보도 공유할 예정이니 많이 가입해 주시기 바랍니다.

참고 자료

• 자주 묻는 질문 (FAQ): Kiro에 대해 궁금한 점을 알아보세요.
• 인터랙티브 튜토리얼: Kiro를 이요하는 개발 실습 튜토리얼을 참고해 보세요.
• 문서 심화 학습: Kiro의 다양한 기능 개념과 작동 방식에 대해 더 공부해 보세요.
• Kiro 커뮤니티 참여: 다른 Kiro 사용자들과 교류하고 경험을 공유해보세요.

추가 정보 업데이트 (2025.7.16)

• Kiro: 프로토타입에서 프로덕션 레벨까지 지원하는 스펙 기반 Agentic IDE 출시
• Code with Kiro Hackathon
• Kiro 비공식 사용자 가이드 한국어 번역
• Kiro 비공식 한국어 설정 및 한국어 응답 설정
• [유튜브] 아마존에서 출시한 미친 AI 코딩툴 키로(Kiro)! 커서AI 넘을까? | 실제 사용 찐 리뷰
• [유튜브] Cursor, Claude Code 킬러 등장?! 개발자들이 난리난 아마존 Kiro IDE 실체
• [유튜브] 클로드 코드랑 커서 폐업 시키려고 만들었다는 Kiro IDE…
• [유튜브] Cursor와 Taskmaster를 합쳤다!

추가 정보 업데이트 (2025.7.18) – Kiro의 인기가 매우 높아서, 대기자 초대제로 변경되었습니다. 아직 가입하지 못하셨다면, 대기자에 등록하시면 순차적으로 초대됩니다.

개인용 MCP 서버 보안 취약점
제가 이전 글에서 말씀 드린대로 MCP 서버는 여러분의 컴퓨터에 설치되는 것으로 파일 접근, 리소스 제어 등의 기능을 할 수 있습니다. 따라서, 만약 공격자가 마음만 먹는다면 MCP 도구 설명에 그럴듯하게 적어놓고, 실제 코드에는 공격 코드를 삽입할 수 있습니다. 게다가 MCP 서버 업데이트 기능을 통해 알 수 없는 기능을 업데이트할 수도 있습니다. 문제는 일반인들은 그러한 코드의 실제 위험을 확인하기 어렵다는 것입니다.

게다가 로컬 서버에 설치될 뿐만 아니라 최근에 REST 방식을 이용한 원격 서버와 접속을 허용하는 MCP 서버가 늘고 있습니다. 대부분 API 서비스를 제공하는 서드 파티 제공사의 기능을 활용하기 위해 만든 것들인데, 하이재킹을 통해 가짜 서버로 전송해서 데이터를 탈취할 수도 있습니다. 예를 들어, 커서 AI의 취약점 중에 하나인 add()라는 데이터 설정 파일 변경 기능을 통해 해커가 데이터를 탈취하는 일도 있었습니다.

요즘 대부분 로컬에 설치되는 프로그램은 신뢰된 앱 스토어를 통해 검증된 프로그램만 설치되고 있거나, 특정 샌드박스 안에서만 실행되도록 하는 장치가 내장되어 있습니다. 그러나, MCP 서버의 경우 공개된 프로토콜만 있지, 만들어서 배포되고 있는 프로그램에 대한 검증 장치는 아직 없습니다.

아래는 MCP Servers are not safe! – Data Science in Your Pocket라는 글이 있는 보안 취약점과 해결 방법을 요약한 것입니다.

개인 MCP 서버 활용 시 유의 사항
만약, 여러분이 이러한 보안 취약점에 대해 걱정을 하시고 있으시다면, 일단 사용하지 않는 것을 장려합니다. MCP 서버가 유용한 점이 분명 있지만, 결국 AI 모델을 보완하는 기능일 뿐, 킬러앱이 있는 것은 아닙니다. 그리고, 가급적 신뢰할 만한 MCP 서버만 설치하시길 바랍니다. 개인이 만든 것은 가급적 피하시고, Smithery에서도 신뢰된 공급사가 제공하는 오렌지 색 가 있는 것들만 다운로드 해서 사용하시길 바랍니다.

혹시라도 개인이 만든 MCP 서버를 사용하게 된다면, 도구 설명을 완전히 신뢰하기 보다는 수행하는 작업과 실제 작업이 같은지 검증해야 합니다. 이상한 동작이 감지된다면 코드를 확인해 볼 필요가 있습니다. MCP 서버가 최소한의 데이터와 리소스에 접근하도록 설정하고, 업데이트 될 때 마다 어떤 부분이 변경되었는지, 지속적인 모니터링이 필요합니다. 따라서, 바로 바로 업데이트하지 말고 신뢰된 버전만 사용하는 것이 좋습니다.

우리가 설치하는 소프트웨어와 역시 똑같은 보안 취약점이 있기 때문에, 이런 언급이 유별나다고 생각하시는 분들도 있을 수 있습니다. 그러나, 한국에서는 과거에도 Active X 같은 기술을 악용한 악성 프로그램에 노출되어 있었고, 그냥 컴퓨터에 무심코 설치하는 버릇에서 사회적인 보안 비용이 높아졌던 경험이 있습니다. 생성형 AI 에이전트를 일반인들도 많이 쓰는 시대에 살고 있기 때문에, 이 부분은 간과해서는 안됩니다.

기업을 위한 MCP 서버 보안 이슈
기업에서 MCP 서버를 사용할 때 역시 많은 주의 사항이 필요합니다. MCP 서버는 개인이 설치하는 식으로 되어 있기 때문에, 기업 내에서는 중앙에서 MCP 서버를 원격으로 배포하고 권한 부여를 활용하여 리소스 소유자가 데이터에 안전하게 액세스할 수 있는 메커니즘이 부족합니다. 이를 해결하기 위해, MCP 스펙에서 최근 OAuth 2.1을 기반으로 하는 MCP 권한 부여 기능을 도입했습니다만, 여전히 문제가 있습니다.

예를 들어, 이 제안은 MCP 서버를 리소스 서버 및 권한 부여 서버로 함께 취급하기 때문에 기능상 복잡성이 증가하는 문제가 있습니다. 인증 및 권한 부여 위임을 위해 OAuth를 쓰는 경우, 신뢰된 ID 공급자(Auth0, Okta 등)를 통해 수행해야 합니다. 최근에 MCP 인증 스펙 변경을 위한 노력이 진행 중이긴 하지만, MCP 인증 스펙이 좀 더 기업 보안 친화적인 방식으로 바뀌기 전까지는 기업에서 MCP 서버를 직원들이 활용하게 하는 것은 시기 상조로 보입니다.

아래는 The MCP Authorization Spec Is… a Mess for Enterprise라는 글에서 제안한 기업용 MCP 활용을 위한 대안 입니다.

또한, 기업들이 직접 MCP 서버를 일반 사용자에게 배포할 때도 신뢰성을 제공해야 합니다. 앞에서 Smithery의 신뢰된 공급사로 표시되게 하는 방법을 알려드렸지만, 사설 레포지터리 보다는 회사내 공식 홈페이지, 블로그, Github 페이지를 통해 제공하는 것을 권장합니다.

지금까지 이야기한 모든 것은 우리가 잘 알고 있는 보안 상식에 속합니다만, 신기술이 뜰 때 이러한 중요한 부분이 간과되는 것을 많이 보았습니다. 남이 만든 블로그나 가이드를 그냥 맹목적으로 따라하다가, 데이터 유츌이나 과금 문제를 경험하기도 합니다. 따라서, MCP 서버 뿐만 아니라도 여러분의 책임하에 보안 이슈가 없는지 잘 알아보고, 새로운 기술을 활용하시길 권장드립니다.

News Blog와의 인연

저는 2006년에 웹2.0컨퍼런스 강연 차 한국에 방문한 Jeff Barr 부사장님을 처음 뵈었는데, 당시 그는 AWS 테크에반젤리스트이자 개인 블로거셨습니다. 그때부터 그분이 저의 인생의 롤 모델이 되었습니다. 2014년 AWS에 합류했을 때, 제가 가장 먼저 한 일은 AWS 코리아 블로그를 만들고, 그의 블로그 게시물을 한국어로 번역하기 시작한 것이었습니다.

2019년에 Jeff는 저에게 News Blog 팀에 합류하라고 요청했고, 그때부터 AWS News Blog와의 여정이 시작되었습니다. 저는 한국어를 모국어로 사용하면서, 오랜 기간 한국어로 블로그를 써 왔지만, 영어로 글을 쓴다는 것은 쉬운 일이 아니었습니다. 아마존에서 배운 글쓰기 방식과 Jeff가 공유한 AWS News Blogger를 위한 리더십 원칙은 뉴스 블로그 글을 쓰는데 많은 도움이 되었습니다.

AWS News Blog팀은 전 세계에 걸쳐 11명의 블로거가 있습니다. 저희 팀은 Jeff의 유산을 그대로 이어가면서 글로벌 독자들과 만날 것입니다. 저희 팀 멤버들도 함께 만나 보세요!

작년 11월 Anthrophic에서 처음 소개한 MCP는 Claude 모델에 로컬 혹은 원격의 데이터 소스 및 도구를 연결하여 컨텍스트를 제공하는 표준화된 프로토콜입니다. 마치 AI를 위한 USB-C 포트라는 메타포를 가져와서 사람들에게 친근하게 설명하고 있어서, 대충 어떤 기능을 하는지 감을 잡을 수 있습니다.

현재 smithery.ai라는 사설 MCP 서버 리포지터리에는 벌써 3천여개 가까운 MCP 서버가 등록되어 있습니다. 로컬 데이터 처리, 명령어 실행 모드, 지식 메모리 관리, 웹 브라우저 자동화 같은 로컬 머신 기능에다가 웹 검색, 외부 API 연동 같은 다양한 MCP 서버가 만들어져 있습니다. 다들 눈치채셨겠지만, 과거 야후의 웹 사이트 디렉토리, 프로그래머블의 OpenAPI, 애플 앱스토어 등 인기 있었던 앱 생태계로 진입하는 전초 단계로 보여집니다. (물론 개인들이 올린것도 많기 때문에 아무거나 설치하거나 사용하면 안되고, 꼼꼼히 따져 보고 보안에 문제가 없는지 잘 살펴보아야 합니다.)

이 글에서는 MCP에 대한 자세한 기술 사양이나 MCP 서버 구현 방법을 다루지는 않고, AI 기술 생태계에서 어떤 의미를 담고 있는지 몇 가지를 살펴보고자 합니다.

MCP는 개방형 표준이다?
MCP의 기술 명세를 보면, JSON-RPC 2.0 프로토콜을 이용하여 Server-Sent Events (SSE)를 통해 서버에서 클라이언트로 단방향 통신을 제공합니다. 이를 통해 MCP 서버가 Claude Desktop이나 Cursor AI와 같은 MCP 클라이언트를 가진 MCP 호스트에게 수행된 명령 결과 혹은 데이터를 전달할 수 있습니다. MCP 서버에서 받은 데이터는 간단한 JSON 사양으로 정의되어, Claude 모델에서 실행할 프롬프트에 들어가는 정보가 됩니다.

물론 표준 기술 명세를 사용한다고, 개방형 표준이라고 부르기는 어렵습니다. 실제로 OpenAI는 2023년 초에 ChatGPT Plug-in을 출시한 바 있는데, MCP와 유사하게 LLM 모델에 외부 데이터를 연동하는 데 사용할 수 있습니다. 그런게 있었느냐라고 기억하지 못하는 분들이 있을 텐데요. 크게 성공했다고 보기는 어렵죠. ChatGPT 플러그인은 ChatGPT에서만 쓸 수 있는 독점 표준이고, MCP 역시 작년 11월에 처음 나왔을 때 Claude 모델에서만 사용할 수 있었던 독점 표준이었습니다. MCP가 조금 달랐던 것은 서버-클라이언트 방식의 소프트웨어 아키텍처를 차용했다는 점입니다.

MCP가 빠르게 부상하게 된 것은 Cursor AI가 지원하기 시작했기 때문입니다. 현재, CursorAI는 기존 통합 개발 도구(IDE)를 통한 SW 개발 방식을 AI를 통해 획기적으로 바꾸었습니다. 바이브코딩이라는 용어가 뜨게 된 것도 사실상 CursorAI의 덕분이기도 합니다. 여기서 그치지 않고, 어제 OpenAI가 MCP를 자사의 OpenAI Agents SDK에 포함시켰으며, 이것은 매우 큰 변화입니다. 원래 한 회사가 쓰면, 독점 표준이고, 두 회사가 쓰면, 산업 표준이 되고, 세 회사가 쓰면, 개방형 표준이 될 수 있습니다. 웹 표준이 웹 브라우저에 채택될 때, 비슷한 과정을 거치게 됩니다. 따라서, 좋든 싫든 MCP는 AI 생태계에서 개방형 표준의 위치로 가게 되었습니다.

MCP는 범용적인 아키텍처이다?
많은 분들이 MCP가 서버-클라이언트 아키텍처가 되었는지 의아해 하는 분들이 많습니다. 이미 훌륭한 개방형 API 사양과 REST 방식의 프로토콜이 있는데도, 약간 고전적인(?) RPC 방식을 쓰는가 하는 점입니다. MCP 붐에 편승해서 새로 MCP 서버를 만드는 대부분이 기존 API를 래핑하는 과정에서 복잡하다고 느끼는 것 같습니다. 그래서, 현재 MCP 아키텍처가 기존에 앱 생태계에서 사용하는 범용적인 API 방식과 부합하지 않습니다.

어떤 기술도 태동하게 된 동기가 있습니다. MCP는 Claude Desktop에서 모델 작업에 외부 데이터와 연동할 목적으로 만들어졌고, 그 데이터 소스 대부분은 로컬 머신에서 나오는 것입니다. 예를 들어, 모델로 이미지를 생성했을 때, 데스크톱에 이미지 파일을 생성한다던가, 텍스트 파일이나 PDF 파일을 읽어서 모델의 프롬프트 컨텍스트에 추가한다던가 하는 케이스이죠. 그러기 위해서는 독립적인 기능을 수행할 로컬 MCP 서버와 클라이언트 방식이 유리하고, 로컬 통신에서 좀 더 가벼운 RPC를 이용하게 된 것입니다.

MCP가 뜨면서 많은 기업들이 자사의 API를 MCP 서버로 만들어 제공하려는 욕구가 생기고 있습니다. 기존 WebAPI를 제공하려면, 원격 MCP 서버를 만들어 다시 감싸는 과정이 있어야 합니다. 아무래도 기존 REST 방식 보다 복잡하기 때문에 범용적이지 않다고 느끼는 분들이 많습니다. 앞에서 이야기한 대로, 이것은 MCP의 주효한 사용 사례는 아니었습니다. 이것은 일시적인 현상이고, 원격 MCP 서버와 API 연동하는 방법을 손쉽게 하는 방법들이 쏟아져 나올 것이라고 예상합니다. 예를 들어, Cloudflware Worker를 이용해서 MCP 서버를 배포하는 방법이나 Amazon Bedrock에서 MCP 서버를 연동하는 방법도 소개되었습니다.

MCP는 AI 앱 생태계가 될 것이다?
앞서 언급한 대로, 시장 지배력을 가지고 있었던 ChatGPT 플러그인은 실패했습니다. 표준적인 REST API를 지원하고 있었기 때문에 기술 사양의 문제도 아닙니다. 다만, 2년 전에는 ChatGPT 데스크톱도 없었고, 기업들도 생성형 AI에 대해 아직 확신하지는 못하는 상태였습니다. 몇몇 기업이 빠르게 플러그인 개발을 했지만, 수요가 폭발하지도 않았습니다.

제 생각에는 무엇보다 ChatGPT 플러그인은 개발자들의 지지를 얻는 데 실패했습니다. OpenAI는 시장 지배력만 믿고, 일반 소비자에게만 어필하기 위해, 몇몇 기업들과 독점적인 플러그인 개발에만 매진했습니다. 따라서, 개발자를 위한 도구 지원이나 흔히 말하는 개발자 관계 활동(Developer Relation)이 전무했습니다. 저처럼 새로운 기술에 관심이 많은 사람은 새로운 게 나오면 시도해 보는 편인데, ChatGPT 플러그은 전혀 그렇지 못했습니다.

MCP는 확실히 다른 길을 걷고 있습니다. Anthropic은 처음 시작부터 개발자들에게 친근한 표준 사양과 SW 아키텍처를 선보였고, 결과를 내기 위해 유명한 업체들과 협력해서 뭔가를 만들어내는 게 아니라, 개발자들의 호응을 기다려 왔습니다. 최근의 AI 호사가들이 떠들어 대는 것은 가볍게 무시할 수 있습니다만, 적어도 MCP에 대해 개발자들에게서 오는 피드백은 진짜입니다. 역사적으로 소프트웨어 기술 산업에서 개발자의 목소리와 커뮤니티 반응이 중요한 이유입니다.

Update (2025년 4월 7일) – 개인이나 기업이 MCP 기술을 활용하실때, MCP – Model Context Protocol 보안 위험이라는 글도 꼭 참고하시기 바랍니다.

뉴스 기사에 회자되는 내용만 보자면, 대규모 언어 모델(LLM)을 통한 생성형 AI의 도움을 받아 자유로운 느낌에 따라 코딩을 하는 활동을 지칭하는 것이라고 합니다만… 실제로 Andrej Karpathy가 처음 그 용어를 사용한 맥락은 다음과 같습니다.

제가 “바이브 코딩”이라고 부르는 새로운 종류의 코딩 방식이 있는데, 느낌에 따라서 만든 엄청나게 많은 코드를 받아들이고, 실제로 코드가 존재한다는 사실조차 잊어버리는 것입니다. LLM(예: Cursor Composer w Sonnet)이 너무 좋아지고 있기 때문에 가능합니다. 또한 SuperWhisper로 Composer와 대화하기 때문에 키보드를 거의 건드리지 않습니다.

Andrej Karpathy가 말한 원문에서 말하는 바이브 코딩은 새로운 아이디어를 구현하거나 실험하기 위해 LLM을 이용해서 좀 더 빠르게 프로토타이핑을 하기 위한 방안의 하나로 LLM을 사용하는 것입니다. AI가 생성한 코드를 직접 읽어보거나, 코드 리뷰를 하지도 않고, 그냥 다 수락하면서, 원래 원했던 기능 구현에만 중점을 둡니다. 오류가 생겨도 그냥 LLM에게 수정하라고 명령만 내리고, 어떤 코드가 어떻게 수정됐는지에 상관없이 다음 기능 개발로 나아가는 것이죠. 원래 맥락으로 보자면, 한마디로 바이브코딩은 AI가 해주는 대로 하는 사실상 무대뽀 개발 방식입니다.

바이브 코딩, SW 개발의 진입 장벽을 낮추다
여기까지 들으면, 기존 소프트웨어 개발자들은 AI가 생성하는 코드를 어떻게 믿느냐? 이걸 회사에서 쓸 수 있냐? 이런 말을 할 것 하실 것 같습니다. 원래 소프트웨어 개발은 프로그램 코드를 직접 작성 혹은 리뷰하면서 성능, 접근성, 보안, 비용 효율성을 고려해야 합니다. 특히나, 다른 개발자들과 협업을 통해 계속 변화하 나가기 위한 유지 보수와 코드 관리 및 배포 등에도 신경써야 합니다. 따라서, 전통적인 방식의 SW 개발에는 맞지 않는 방식일 것입니다.

하지만, 세상이 변하는 걸 느끼는 분들은 이게 무엇을 의미하는지 직관적으로 느끼실 것 같습니다. 제가 생성형 AI가 처음 뜨기 시작했을 때, 스테이블 디퓨전과 ChatGPT를 다룬 글에서 인용을 하자면요.

제가 입버릇처럼 하는 말이 있습니다. 세상을 바꾸는 IT 기술은 진입 장벽이 낮추고 누구나 접근 가능(easy to access)하여, 많은 사람이 참여함으로서 새로운 시장을 창출한다구요. IT 역사상 오픈 소스 소프트웨어, 오픈 웹 표준, 오픈 API, 오픈 지식 플랫폼 등이 대표적인 예입니다.

컴퓨터 프로그래밍 방식 역시 크게 다르지 않습니다. 아주 오래 전 어셈블리 언어로 부터 컴파일언어, 인터프리터언어, 웹 프로그래밍 등으로 발전하면서, 이전에 알아야 했던 지식을 더 이상 필요치 않고 좀 더 쉬운 방식으로 계속 변화해 왔기 때문입니다. 사실 프로그래밍 진입 장벽을 낮추려는 시도는 “Nocode”, “Less-code”라는 이름으로 과거에도 수도 없이 많이 있었습니다만, 이러한 노코드 도구들 역시 우리가 원하는 바이브, 즉 자유도를 충족시켜주지는 못했습니다.

요즘 바이브 코딩 같은 용어가 뜬다는 것은 AI 기반 코딩의 임계점과 장벽도 이미 넘어섰다는 것을 의미합니다. 1인 개발자나 작은 스타트업들이 새로운 아이디어를 구현하고, 프로토타입을 만들때, AI에만 완전히 의존하는 개발 방식이 가능하다는 점을 시사해 주고 있습니다.

바이브 코딩의 한계점
기존 SW 개발자들도 이런 기술 풍조를 완전히 무시하기는 어렵습니다. 현재 하는 일과 상관 없이 우리는 항상 이것 저것 시도를 하면서 새로운 기술과 방식을 배워야 하기 때문이죠. 그 과정에서 현업에 대한 신기술도 익히지만, 언젠가 독립해서 나만의 제품을 만들려는 꿈도 꿀수 있습니다.

AI 기반 코딩에 대해 다양한 실험을 하고 있는 Simon Willison도 그의 글에서 기존 AI 기반 개발과 차이를 말하면서, 바이브 코딩을 할 때 어떤 점을 유의해야 하는지 알려주고 있습니다. 한마디로, 위험성이 낮은 프로젝트에 대해 SW 보안 및 개인 정보에 대해서 최소한의 검토를 하면서 Cursor 같은 AI 전문 도구와 Claude Artifact 샌드박스 내에서 개발을 하라고 조언합니다.

마찬가지로, 저는 바이브코딩의 결과물을 프로덕션에 내보내는 것은 신중해야 한다고 생각합니다. 개인 정보를 다루지 않는 가벼운 기능이나 프로토타입은 괜찮지만, 여러 사람이 함께 개발해 나가는 좀 더 복잡한 프로젝트로 나아갈 때는 아예 처음 부터 다시 코드를 다시 짜는 수준의 리팩토링을 해야 할 수도 있으니까요.

따라서, 바이브코딩을 해서 뭔가를 만들었다고 해서 이것을 다른 개발자에게 주면 계속해서 추가 기능 개발 할 수 있다고 생각해서는 안될 것입니다. AI가 만들어 낸 코드의 수준을 못 믿는 것이 아니라, 기능을 만들어 나간 과정에 대한 맥락이 전혀 공유되지 않았기 때문입니다. 바이브코딩이 제품 수준에서 유의미한 수준이 되려면, AI를 이용한 코드 개발로 나아가는 자연어에 대한 완전한 맥락이 공유될 수 있어야 할 것입니다. 또한, 개발 속도와 비용에 더 집중하여 AI가 만든 코드 품질, 유지 보수성 및 기술 부채라는 트레이드오프를 정말 받아들일 것인가라는 기업의 의지에 좌우될 것입니다.

AI가 바이브 코더에게 경고를 하다
한편으로 이런 에피소드도 있습니다. 코딩 어시스턴트인 커서(Cursor)가 Janswist라고 소위 바이브 코더에게 Cursor에 너무 의존하지 말고 대신 직접 코드를 작성하라고 조언을 했다고 합니다. 해커뉴스에 올라오면서 입소문을 타서 Arstechnica 같은 뉴스 매체에도 많이 기사화 되었는데요.

한 시간 정도 커서로 코드 작성을 하고 난 후, 특정 시점에서 비즈니스 로직은 직접 짜라고 말하면서, 그래야 시스템을 이해하고 적절하게 유지 관리할 수 있다고 조언했다고 하네요. (정말 똑똑한 조언이죠.) AI가 어느 정도 분량의 코드를 생성하고 나면, 어떤 시점에서 그런 응답을 하는 버그라고 추측하는 사람도 있습니다. 스택오버플로 같은 개발자 포럼에서 초보자들에게 하는 답변과 매우 유사하기 때문에, 자연스런 LLM 학습의 결과라고 보는 분들도 많습니다.

세상의 모든 일이 그렇듯 뭔가 새로운 것을 시작하거나 배울 때는 즐겁거나 쉬워야 합니다. 다만, 거기에서 멈추지 말고, 좀 더 잘하고 전문가가 되려면, 다른 사람이 알 수 없는 끝없는 훈련과 고뇌의 과정이 있게 됩니다. 프로그래밍을 처음 시작할 때는 바이브 코딩이든 뭐든 쉬운 것을 성취하는 즐거운 과정을 거치세요. 어느 정도 익숙해지면, 한계를 극복해 나가면서 새로운 기술을 받아들이며 자신만의 방식 만들어 나가야 합니다. 시대에 따라 코딩을 하는 도구와 방식은 변화했지만, 학습을 통한 성숙의 과정은 변하지 않았습니다.

Update – 많은 분들이 관심을 가지는 것 같아서, Amazon Q Developer CLI를 이용한 바이브 코딩이라는 주제를 가지고 모임을 하나 열었습니다. 제가 직접 Amazon Q Developer CLI를 이용해서 앱 구현을 하면서도, 문서작성, 유닛테스트, 코드리뷰, 보안 취약점 및 배포까지 하는 방법을 다릅니다. 관심 있는 분들은 커뮤니티 모임에 참여해보세요.

Q: 안녕하세요. Jeff 간단히 자기 소개 부탁드립니다.

차니님,초대해 주셔서 감사드립니다. 직접 여러분을 찾아 뵙고 싶지만 상황이 아직 여의치 않네요 제 이름은 Jeff Barr이며 AWS 부사장이자 최고 에반젤리스트로 활동 중입니다. 독특하면서도 즐겁게 일할 수 있는 직업이라 생각됩니다. (시공간에 얽매이지 않고, 주로 집에서 재택으로 일하면서) AWS 내의 수많은 팀들과 소통하며 개발 중에 있는 서비스와 제품에 대해 파악하고 이러한 놀라운 서비스와 제품에 대해 블로그에 글을 작성하여 공유하고 있습니다. 다시 말해, 먼저 이해하고 학습하여 공유하는 것이죠. 이후 구체적으로 설명 드릴 텐데요. 저는 바로 이것이 다양한 작업을 진행하고 이해하며 함께 공유하는 방법에 대한 모범적인 모델이 아닐까 생각합니다.

Q: 재택 근무를 도움이 되는 AWS가 있나요?

좋은 질문입니다. 저는 Amazon WorkSpaces를 아주 오래 전부터 애용하고 있는데요. 블로그를 작성할 때 특히나 유용했습니다. 저는 어떤 서비스를 사용하든 직접 체험을 해야 하는 편입니다. 담당 팀에서 모든 관련 정보를 공유해주며 어떻게 구성되어 있고 어떤 기능을 하는지 등을 알려주죠. 그리고 저는 항상 직접 사용해 봅니다. WorkSpaces도 마찬가지였는데요. 직접 사용해 보기 전까지는 데스크톱이 로컬이 아니. 분명 느리게 동작하거나 지연 시간이 길 것이라고 예상했습니다. 그런데 직접 사용해 본 후, 바로 알 수 있었습니다. 출시 전에 직접 사용해 보았는데 정말 구동이 잘되고 빠르며 반응이 뛰어났습니다. 지금은 재택근무가 주를 이루지만 사무실에 나가야 할 때에도 집에서 스크린에 띄워 진 여러 앱들의 연결이 끊기지 않고 책상에서 일어나 회사로 가기만 하면 되었죠. 지금까지 WorkSpaces를 중심 운영 환경으로 아주 만족하며 사용하고 있습니다.

Q: 혹시 한국에 방문하신 적이 있으신가요?

꽤 오래 전인 것 같은데요. 2006년 초로 서울에 여행을 갔었습니다. 정말 흥미로운 도시였어요. 한국어를 전혀 읽거나 말할 수 없어서 어려움은 있었지만 정말 즐거운 시간을 보냈던 기억이 납니다. 유능한 개발자들도 많이 만날 수 있었죠 이곳 저곳 둘러보며 시장에서 맛본 한국 음식들도 정말 훌륭했습니다. 정말 좋은 시간이었습니다. 또 하나 인상적이었던 점은 호텔 체크인 후, 노트북을 처음 연결했을 때 속도가 정말 빨랐다는 점이에요 2006년 당시에 호텔에서 GB급 속도를 경험하리라 고는 상상을 하지 못했죠

Q: AWS의 서비스 원칙이 무엇인가요?

AWS는 2002년 아마존웹서비스(Amazon Web Services)라는 이름으로 웹 API들을 제공하기 시작했었고, 당연히 서비스 수가 많지 않았어요. E-커머스 서비스 일부만 출시됐는데, Amazon 상품 카테고리도 있었고요. 그런데, 그때나 지금이나 중요하게 생각하는 부분은 같습니다. 바로 개발자에게 집중한다는 것이죠. API나 서비스를 개발자에게 제공하면서 이렇게 말합니다. 고민하며 상상력을 발휘해 보고 창의적으로 무엇을 구축할 수 있을지 생각 해보라고 말이죠. 첫 E-커머스 서비스를 구축했을 때나 200개 이상의 서비스를 제공하는 지금. 이 점에서는 변함이 없습니다.

Q: AWS 블로그의 시작에 대해서도 알려주세요.

2004년 AWS 블로그를 처음 시작하였습니다. E-커머스 서비스를 출시했을 때로 당시에 저희는 이미 스토리지, 컴퓨팅, 네트워크, 데이터베이스 서비스에 대한 플랜이 세워져 있었죠 제가 유일한 에반젤리스트여서 서비스 하나 만으로도 매우 바빴을 때였습니다. 그때부터 저는 새로운 서비스를 어떻게 잘 알릴 수 있을까 고민했습니다. 대면으로 소개하는 것에 그치지 않고 글로벌로 알릴 방법을 고민했죠 그리고 2004년 11월, AWS 뉴스 블로그를 시작하였습니다. Amazon SQS에 이어 Amazon S3와 EC2가 출시될 당시에는 블로그를 활용한 효과적인 제품 출시 홍보 모델이나 방안이 전혀 없었습니다. 그래서 부딪혀 보는 수밖에 없었죠. 제가 직접 알리거나, 회사 차원 또는 팀 차원에서 블로그를 작성할 수도 있겠죠 여러 실험 끝에 블로그를 쓸 때에는 직접 소통하기로 결정했습니다. 그래서 항상 블로그 독자와 직접 대화하는 느낌으로 ‘저는 요즘 이 제품을 사용하고 있는데 이렇게 사용해 보세요’라고 글을 씁니다.

Q: AWS 블로그가 사랑 받는 비결은 무엇일까요?

첫 블로그 포스트는 Amazon S3 출시에 대한 것으로 기억합니다. 아주 간단하게 작성하여 두개 정도 문단으로 아주 짧았지만 메시지는 매우 분명하고 단도직입적이었습니다. 새로 출시된 서비스가 무엇인지, 어떤 장점이 있으며 어떻게 사용하고, 어떻게 결제하는지를 설명하였죠 저는 이러한 출시를 하나의 초대로 봅니다. 우리가 이러한 흥미로운 서비스를 출시했으니 다양하게 활용해 보세요라고 말입니다. Amazon SQS, S2, EC2 등 기반 서비스를 둘러보고 체험해보고 자신에게 맞으면 사용해 보라고 초대하는 것이죠.

Q: AWS 역사 중 중요한 이정표가 되는 서비스가 무엇일까요?

몇 가지 떠오르는 것이 있는데요. 첫 번째는 Amazon VPC로 가상 프라이빗 클라우드입니다. Amazon EC2를 처음 출시할 당시는 상대적으로 간단한 네트워킹 모델이었지만 핵심적인 구성은 모두 갖추었죠 IP 주소와 보안 그룹도 있고 고객들이 자신의 인스턴스 액세스를 컨트롤할 수 있도록 하였습니다. 그런데 고객들의 반응을 보면 자사의 기업 네트워크는 좀 더 복잡하기 때문에 보다 세밀화된 컨트롤이 필요하며 대규모 네트워크나 서브넷을 구축할 때 이를 구분하여 액세스를 컨트롤하길 원하고 있었습니다. 이를 고려하여 Amazon VPC가 출시되자 고객들이 AWS를 완전히 다른 시각으로 바라보기 시작했습니다. 단순한 서버가 아닌 아주 다채롭고 정교한 서비스라는 인식을 갖게 되면서 복잡한 대규모 엔터프라이즈 환경에서도 바로 적용 가능하다는 반응이었죠

Q: 컴퓨팅 분야에서도 AWS 서비스 한가지 꼽아주세요?

첫번째가 Amazon VPC이고 다음으로 중요한 것이 서버리스(Serverless)라고 생각합니다. 서버리스의 역사는 아주 길지 않은데요. AWS Lambda도 출시된 지 10년이 채 되지 않았습니다. 하지만 애플리케이션 구축 방법에 대한 사람들의 인식에 큰 변화를 가져왔습니다. 물론 인스턴스를 런칭하고 서버 상에 애플리케이션을 구축하여 서버 단위로 확장하거나 축소를 선호하는 애플리케이션도 여전히 존재합니다. 하지만 서버리스로 전환하면 고객은 애플리케이션 아키텍처와 코드에 집중할 수 있습니다. Lambda 환경에서 안심하고 코드를 호스트하며 실행, 확장하고 운영 시스템 관련 모든 이슈를 처리할 수 있습니다. 고객은 코드 작성에 온전히 시간을 쏟을 수 있고 여러가지 서버 관리 작업에서 벗어날 수 있는 것이죠. 저희는 Lambda 출시를 시작으로 이러한 환경을 구현하고 계속해서 발전시켜 오고 있으며 서버리스는 이제부터 시작이라는 생각으로 개발을 지속하고 있습니다. 서버리스 데이터베이스를 예로 들면 앞서 다양한 서버리스 컴포넌트들에 대해 말씀해 주셨는데 복잡성을 줄이고 개발자들에게 본연의 역할에 충실할 수 있도록 더욱 많이 시간을 주는 것이죠.

Q: 최근 인공 지능 분야에도 하나 더 소개해 주신다면요?

인공지능과 기계학습 측면에서. Amazon SageMaker를 들고 싶습니다. SageMaker는 모델을 직접 설계하고 테스트하며 훈련하는 방법을 배울 수 있는 정말 유용한 툴입니다. 구축한 모델을 이해하고 평가하며 배포까지 도움을 주죠. 인공지능과 기계학습은 상대적으로 젊은 분야로 경험한 시간이 아주 길지는 않지만 많은 고객들이 이러한 기술의 혜택을 경험하고 있으며 저희도 계속해서 이 분야에 집중 투자하며 새로운 기능들을 출시하고 있습니다.

Q: 가장 좋아하는 AWS 서비스는 무엇인가요?

마치 우리 아이들이나 손주들 중에서 한 명만을 고르는 것처럼 답을 하기 어려운 질문 같아요 가장 애착이 가는 서비스 하나만을 꼽는 것은 불가능할 것 같습니다. 하지만 굳이 하나를 생각한다. 관계형 데이터베이스 서비스인 Amazon RDS를 출시할 때가 떠오릅니다. RDS 출시 직후, 고객사에 방문하여 데모를 보여준 적이 있었는데요. 1~2분 만에 데이터베이스 인스턴스를 만들어 런칭하고 대기한 후, 로그인하여 쿼리를 실행하는 5분 밖에 걸리지 않았죠 뒤에서 지켜보던 분들이 서로 의아해하며 눈빛을 교환하더라고요. 저는 외부인이라 왜 놀라는지 영문을 몰. ‘왜 그러세요, 무슨 문제가 있나요’라고 물어보았죠 대답하시길 내부 팀에 신규 데이터베이스 하나를 셋업 요청하면 6개월이 넘게 걸리고 셋업을 했다 해도 여기저기서 문제가 나타났다고 합니다. 그런데 제가 그 작업을 5분 안에 그것도 제대로 완료한 것이죠. RDS를 통해 고객의 데이터베이스 접근성과 사용 편의성을 대폭 향상시킬 수 있겠다는 확신이 바로 그때 들었습니다.

Q: AWS가 복잡하다고 느끼시는 분들이 많습니다.

저는 고객들을 만나면 항상 이렇게 말합니다. 200개 이상의 AWS 서비스를 모두 공부하고 시작할 필요는 없다고 말이죠. 자리에 앉아 서비스를 하나하나 열거하는 데도 한참의 시간이 걸릴 것입니다. 저는 대신 고객에게 하나의 서비스를 골라서 흥미롭고 유용해 보이는 기능이 있다면 무엇이든 구축해 보라고 말합니다. 그것을 실제 적용해보고 한번 성공을 하. 그때 다른 서비스도 하나 씩 해보는 것이죠. 직접 체험해 보고 배우면서 실제 서비스가 필요할 때, 자세히 배우는 것입니다. 만약 뭔가를 시작하기 전에 모든 서비스에 대해 알아야 한다고 생각한다면 구축은 시작도 해보지 못하고 시간이 다 흘러버릴 것입니다. 간단한 것을 선택하여 뭐든 해보는 것이 훨씬 낫습니다. AWS Lambda이든 S3나 Amazon DynamoDB이든 하나를 선택하여 뭔가 구축해 보는 것이죠. 장기적인 계획을 세우기 보다는 오늘 당장 구축해 보는 것입니다. 가장 기초적인 ‘Hello, world!’나 간단한 데이터베이스부터 시작하는 것이죠. 시간을 정해 놓고 하나의 이벤트를 처리해 보고 이렇게 성공한 경험을 바탕으로 늘려 가는 것입니다.

Q: Jeff의 평소 취미가 무엇인지도 궁금합니다.

여러 취미가 있는데, 그 중에서 가장 좋아하는 것은 레고입니다. 몇 가지 즐기는 방식이 있죠 우선은 제가 원하는 대로 창의적으로 조립할 수 있다는 점이죠. 화면에는 많이 보이지 않지만 한쪽 공간에 모아 두었는데 블록이 20만 개 정도, 더 많을 수도 있고요. 블록으로 새로운 것들을 구상하며 조립하는 것을 좋아합니다. 한편으로 시중에 판매하는 세트 상품을 구매하. 설명에 따라 차례대로 조립하여 계획한 결과물을 얻는 재미도 큽니다. 창의적으로 조립할 때 흥미로운 점은 어떤 결과물이 나올 지 알 수 없다는 것이겠죠 약간의 걱정은 되겠지만 두려운 정도는 아니고 끝까지 가기 전까지는 결과를 알 수 없죠 그리고 때로는 주어진 설명대로 단계별로 따라가며 보장된 결과물에 도달하는 즐거움도 큽니다. 저는 이 두 가지를 모두 즐기고 있죠

Q: 클라우드 기반 개발자의 경력 개발을 어떻게 하는게 좋을까요?

좋은 질문입니다. 만약 여러분이 클라우드에 대해 공부하고 커리어로 삼고 싶다면 아주 긴 여정을 예상해야 할 것입니다. 계속해서 배워야 하고 클라우드 스킬을 적용할 기회가 많기 때문이죠. Amazon에서 항상 강조하듯 우리에게 매일이 ‘Day 1’인 것처럼 AWS는 올해로 15살이 된 서비스도 계속해서 발전시키며 기능면에서 큰 변화를 이어가고 있습니다. 만약 여러분이 개발자로서 클라우드 서비스를 한두 개 또는 모든 서비스를 공부한다면 이를 아주 다양한 상황에서 사용할 수 있을 것입니다. 업무나 취미로도 적용하고 컨설턴트, 강사 또는 AWS Hero로 활동할 수도 있고 커뮤니티에서 일할 수도 있겠죠 정말 다양한 서비스와 선택권이 있습니다. 상대적으로 쉽게 사용하고 애플리케이션을 구축할 수 있습니다. 저는 지금이 클라우드 스킬을 배워서 다양한 용도로 활용할 수 있는 적기라고 생각합니다.

Q: 왜 개발자 커뮤니티를 통한 지식 공유를 해야 할까요?

저는 공유를 매우 중요하게 생각하는데요. 저만의 노하우를 말씀드리자면 저는 항상 뭔가를 한번 해보고 얻으려고 하죠 새로운 역량을 쌓아 얻게 된 것이 생기면 그것이 무엇이든 어떤 방식이든 공유하는 것이죠. 영상을 찍거나 트윗을 하고 블로그에 글을 쓰거나 책을 집필할 수도 있고요. 샘플 코드를 작성하거나 행사에 참여하여 발표를 하는 것도 좋습니다. 분명 처음 학습할 때만큼 힘들지는 않을 것입니다. 처음의 학습 경험에서 어떤 가치를 얻은 후 공유라는 행위를 통해 더 많은 가치와 관심, 또는 명성을 얻을 수도 있겠죠 어떤 방식이든 결국에는 더 많은 지식을 쌓게 될 것입니다. 학습한 것을 이해하고 설명하는 과정에서 전보다 더 많은 것을 얻게 될 수밖에 없습니다. 그래서 저는 사람들에게 항상 약간의 시간이라도 투자해. 얻은 것이 무엇이든 망설이지 말고 공유하자고 강조하죠 Amazon S3나 VPC, Lambda, SageMaker에 대한 블로그 글들이 이미 많은데 왜 나까지 해야 하나라고 생각할 수도 있죠 하지만 여러분이 무엇을 하든 어떤 방법을 사용하든 상관없습니다. 독자는 여러분의 글을 통해 배우길 원하고 이를 통해 독특한 스타일과 브랜드를 구축할 것입니다. 자신만의 콘텐츠를 생성하고 공유하는 방법을 찾으시기 바랍니다.

Q: AWS에서 오픈 소스 커뮤니티 활동에 대해서도 궁금합니다.

AWS Github 레포에 수백가지의 다양한 프로젝트를 참고하면 됩니다. 오픈소스 커뮤니티가 매우 활성화되어 있습니다. 다양한 샘플 코드를 사용할 수도 있습니다. 경량 가상화 기술인 Firecracker와 같은 전체 프로젝트들도 활용 가능합니다. 다양한 AWS SDK와 툴, 명령줄 인터페이스 등이 오픈소스로 제공되고 있죠 저희도 Pull Request를 지원하며 오픈소스 커뮤니티에서 적극 참여하고 있습니다. 당장은 업무에서 AWS를 사용하지 않더라도 오픈소스 코드의 이슈 리스트를 살펴보. 하나를 골라 분석해보고 수정하여 Pull Request로 내보내는 거죠 그러다 보면 어느 새 결과물이 쌓여 해당 오픈소스 프로젝트에서 인지도가 높아져 있을 것입니다.

Q: AWS에 대해 궁금한 것을 알려주는 서비스도 있나요?

추천하고 싶은 것은 AWS re:Post 인데, 쉽게 말해 커뮤니티 상의 Q&A를 하는 창구입니다. 고객들이 re:Post 상에 질문을 남기면 커뮤니티 내의 누군가 답을 해주는 것이죠. AWS 직원들이 답을 리뷰하고요. 커뮤니티 내에서 답이 달리지 않거나 답하기 어려운 경우 AWS 직원들이 참여하여 해결할 수 있도록 도움을 주고 있습니다. 다시 말해 커뮤니티가 중심이 되고 AWS가 서포트를 하는 것이죠. (그리고 AWS에는 전 세계에 많은 사용자 커뮤니티가 있습니다. 거기에서 묻고 답할 수도 있습니다. 한국에서도 AWSKRUG라는 훌륭한 커뮤니티가 있다고 들었습니다. 커뮤니티에 꼭 참여해 보세요.)

Q: AWS를 처음 시작하는 분들에게도 조언을 주신다면요?

수많은 서비스나 API의 숫자에 압도되지 말라고 말씀드리고 싶습니다. 아무것도 하지 않는 것보다 하나라도 알아가는 것이 당연히 낫습니다. Amazon S3의 PDF 문서를 열어 보았더니 600 혹은 800페이지가 넘는다면 모든 기능을 다 알 필요는 없습니다. 숫자에 압도되지 마시고 여러분에게 도움이 되는 몇 가지의 기능만 찾아보세요 어쩌면 당장 모든 질문의 답을 찾지 못할 수도 있습니다.

하지만 하나를 해결하고 또 하나를 해결해 보는 것이죠. 코드를 실행해 보는 것만으로도 하나의 승리입니다. ‘Hello, world!’처럼 가장 간단하게 할 수 있는 것을 파악하고 버킷을 나열해 보세요 객체를 가져와서 새로운 객체를 넣어보는 것이죠. 모든 것이 환상적일 필요는 없습니다. 뭔가를 작동시켜 보는 것이죠. 가장 최고의 방법은 직접 경험해 보는 것입니다. 수많은 코드들과 자료들을 찾아서 읽으면서 고개를 끄덕이며 ‘맞아, 알겠어’라고 생각할 수도 있겠죠 하지만 직접 키보드를 눌러보고 코드를 작성하여 실행해 보기를 바랍니다.

사람마다 선호하는 방법이 다를 수도 있겠죠. 어떤 자료를 열어보면 코드가 있으면, 복사해서 붙여서 사용하라는 설명이 있어도, 저는 항상 직접 타자를 쳐보려고 합니다. 직접 하다 보면 보다 더 실감이 나는 것이죠. 라인을 하나씩 보다 보면 각각의 라인과 명령문이 어떤 역할을 하는지 이해가 됩니다. 코드를 꼼꼼히 살피고 단계별로 디버거에 돌리면 시간은 걸리겠지만 큰 도움이 되죠.

Q: 40년 넘게 IT 경력을 만들어 오셨는데, 비결이 있을까요?

글쎄요, 저는 항상 젊음을 유지하려고 합니다. 저는 항상 유연하고 새로운 것에 적응하는 것이 젊음이라 생각합니다. 우리는 늘 어떤 종류의 시스템, 소프트웨어, 언어, 데이터베이스, 컴퓨터를 사용하죠 이 정도면 충분해라고 쉽게 생각하죠 우리는 늘 어떤 종류의 언어, 데이터베이스, 개발자 툴, 컴퓨터 등을 사용합니다. 그리고 선택한 것이 최고이고 이 정도면 충분해라고 생각하죠 하지만 한편으로 항상 다음을 생각합니다. 지금은 이 버전의 언어를 기쁜 마음으로 사용하지. 다음 버전과 또 다음 버전을 또 기대하는 것이죠. 지나치게 과거에 집착하지 않고 항상 미래를 향하는 것입니다. 저는 개발자처럼 이렇게 젊음을 유지하려고 합니다. ‘개발자로서’가 아니라 ‘개발자처럼’이라고 말한 이유는 이제는 제가 직접 개발하지는 않기 때문이죠.

Q: 마지막 인사 부탁드립니다.

시청해 주신 여러분 대단히 감사드리며 Summit에서 많은 경험하시길 바랍니다. 최선을 다해 귀를 기울이고 배우시기 바랍니다. 네트워킹 기회도 잘 활용하여 새로운 사람들을 만나세요 후회하지 않으실 겁니다. 오늘 제가 여러분께 도움이 되었으면 좋겠습니다. 시청하신 분들은 Twitter나 LinkedIn을 통해 편하게 연락주세요 새로운 사람들과의 만남은 늘 기대됩니다. 오늘 참여하신 소감도 공유해 주시고요.

웹 프론트엔드 기술 변화

최근 10년 동안 웹 프론트엔드는 주로 자바스크립트 생태계로 발전하였고, 리액트와 타입스크립트의 도입으로 생산성이 높아지면서, 백엔드와 비슷하게 웹 개발 방식이 변화하고 있으며, 백엔드와 프론트엔드의 경계가 모호해졌습니다. 패키징 기술이 발전하면서 웹팩과 파셀이 주요 도구로 자리잡았으며, 자바스크립트 백엔드에서는 SWC 컴파일러가 널리 사용되고 있습니다.

현재 웹 개발은 리액트와 넥스트 JS 두 가지 기술에 주로 의존하고 있으며, 싱글 페이지 애플리케이션으로 통칭되는 클라이언트 사이드 렌더링에서 다시 서버 사이드 렌더링으로의 전환이 이루어지고 있습니다. 대부분의 웹 애플리케이션배포는 현재 클라우드기반으로 이뤄지고 있으며, 클라우드플랫폼의 역할이 중요해지고 있습니다.

백엔드 기술 변화

백엔드아키텍처는 전통적인 서비스 지향 아키텍처(SOA)에서, 마이크로서비스(Microservices) 그리고 이벤트 기반 (Event-driven)아키텍처르 변화하면서 복잡한 애플리케이션을 단순화하는 경향이 있습니다. 백엔드에서 활용하던 MVC 패턴은 이제 프론트엔드 기술에서도 활용되고 있구요. 웹2.0이 촉발한 오픈 API 기술은 클라우드 컴퓨팅을 태동시키는 원동력이 되었습니다.

여기에는 서비스 빌딩블록을 작게 구성할 수 있게 도와주는 AWS 같은 클라우드 서비스가 큰 역할을 하였는데, 과거의 인프라 관리의 필요성을 줄이고, 이를 통해 사용자는 원하는 작업에 집중할 수 있도록 해주었습니다. 클라우드 플랫폼은 사용자 요구에 따라 물리적 장비에서, 가상 머신, 완전 관리형 서비스, 서버리스 방식으로 계속 진화하는 중입니다.

클라우드 서비스가 가져온 것

최근 쿠버네티스를 포함해서 잘 나가는 오픈 소스프로젝트들은 거의 클라우드 기반으로 변화하고 있으며, 클라우드 네이티브 컴퓨팅 재단 (CNCF)에서 주도적으로 관리되고 있습니다. 이들 클라우드 네이티브 오픈 소스들은 사용자의 수를 확대하며, 선순환 구조를 형성하고 있습니다.

클라우드 산업의 발전으로 인해 기존 백엔드, 프론트엔드 등의 SW 직군 외에 클라우드와 직접적으로 관련된 새로운 직업, 특히 솔루션즈 아키텍터와 서포트 엔지니어 등이 많아지고 있습니다. 과거 데이터센터에서 시스템 엔지니어로 일하던 사람들이 현재는 주로 프로그램 기반으로 클라우드를 운영하고 배포하는 데브옵스 엔지니어 혹은 사이트 신뢰성 엔지니어 (SRE)쪽으로 이동하고 있구요. 이들 신규 직업군들은 높은 연봉을 제공하고 있으며, 이러한 변화는 클라우드사용 고객이 많아짐에 따라 가속화되고 있다.

오픈 소스 소프트웨어 생태계는 지난 10년간 GPL, LGPL과 같은 라이센스에서 아파치, BSD, MIT 라이센스로의 변화가 두드러지며 상업 친화적인 방향으로 바뀌고 있습니다. 특히, 클라우드 업체들이 오픈 소스 배포와 관리형 서비스를 기반으로 사용자층을 확보하면서, 기존에 오픈 소스를 만든 기업이나 커뮤니티가 혜택을 받지 못하는 상황이 발생하고 있으며, 이러한 갈등이 촉발되어 새롭게 공유 소스 (Shared Source) 소프트웨어가 생겨났습니다. 앞으로 자유/오픈/공유 소스 라이센스를 가진 소프트웨어들이 시장에 공존할 것으로 예상됩니다.

생성형 AI의 발전과 향후 미래 전망

생성형 AI는 클라우드의 발전과 밀접한 관련이 있습니다. 2014년 부터 클라우드가 준 대용량 컴퓨팅과 데이터 처리 능력으로 인해 그동안 빛을 보지 못했던 딥러닝 신경망 모델이 발전하기 시작했고, 이는 현재의 생성형 AI까지 진화하였습니다.

생성형 AI기반의 애플리케이션은 기존의 우리가 일반적으로 만드는 애플리케이션과 다릅니다. 사람이 만든 서비스 기획과 코드 구현, 그리고 데이터베이스를 활용해서 원하는 결과를 내는 것과 달리 사용자의 프롬프트 입력과 기존의 데이터 맥락을 가지고, 대규모 언어 모델이라고 불리는 파운데이션 모델을 활용해서 결과는 내는데요.

이것은 AI 엔지니어링이라는 새로운 기술 세트를 만들어냅니다. 예를 들어 사전에 정확한 요구 사항을 제시하는 프롬프트 엔지니어링, 기존 데이터에서 맥락을 검색해서 더 정확한 결과를 얻는 검색증강생성(RAG)과 벡터 데이터베이스, 모델의 성능을 직접 조정하는 파인튜닝 등입니다. 이제는 생성형 AI 파운데이션 모델이 애플리케이션 실행의 역할을 하며, 기업에서 생성형 AI를 비지니스 및 업무에 직접 활용하기 시작하고 있습니다.

강연을 간단하게 요약하면 다음과 같습니다.

• 프론트엔드 기술: 자바스크립트 생태계를 기반으로 웹 호환성을 높이는 패키징, 클라우드 기반의 풀스택 배포로 진화하고 있다.
• 백엔드 기술: 클라우드 기반 컨테이너 기술과 마이크로 서비스 아키텍처로 진화하고 있으며, 다양한 클라우드 기반 오픈 소스 생태계를 기반으로 새로운 기술 직군이 추가되고 있다.
• 오픈 소스 생태계: 기업 친화적 상업화가 진행되었고, 클라우드로 인한 공유 소스 소프트웨어가 대두되어, 자유/오픈/공유 소스 SW가 공존하고 있다.
• 생성형 AI: 대용량 컴퓨팅과 대규모 데이터로 인한 딥러닝 기술이 대규모 언어 모델(LLM) 발전을 촉발하였고, 프롬프트엔지니어링, 검색증강생성을 통한 생성형 AI 앱이 기업 업무 생산성 및 비지니스 도구에 활용되고 있다.

제 발표 이외에도 한국 웹 30주년 기념 세미나에서는 CSS 창시자인 Håkon Wium Lie의 축하 인사와 함께 WWW-KR (김용운), Web2.0WG (허진호), 웹표준 프로젝트 (신현석) 대표 멤버들의 근황 소개, 그리고 W3C 웹 표준 현황 (송효진)과 Web3 브라우저 Brave (홍영기)에 대한 발표도 있었습니다. 조촐한 모임이었지만, 다음에도 꼭 뵈었으면 합니다.

생성형 AI 시장의 변화와 트렌드

최신 대규모 언어 모델(The state of art, SOTA LLM)의 발전이 정체되고 있으며, 올해 GPT-5와 같은 성능을 가진 모델이 발표될 가능성은 낮아 보입니다. 대신, 데이터 학습 규모에 대한 제약으로 인해, 대규모 모놀리식 모델보다는 상대적으로 작은 규모의 모델에 더 많은 학습 데이터를 투입하고, 전체 시스템 구조를 확장하는 방식이 다음 단계 SOTA 모델이 될 것입니다.

미드 마켓에서는 Meta Llama, Anthropic, Mistral 등 다양한 기업들이 70B~400B 규모의 LLM을 경쟁적으로 발표하고 있으며, 각 모델의 오픈 소스 버전도 1-3개월 이내에 출시되고 있구요. SOTA 모델보다 미드 사이즈 모델을 중심으로 기업 사용 사례를 개발하는 것이 향후 몇 년 간 가장 큰 비즈니스 가치를 창출할 것으로 예상됩니다. 작년에는 동영상 생성 모델이 경쟁적으로 발표되었으나, 멀티모달 생성 기술은 문서 작업 중심의 B2B 분야에서의 사용이 주를 이루고 있으며, 동영상 등은 게임과 메타버스 등에서 향후 2-3년간 기회가 확장될 가능성이 큽니다.

생성형 AI 모델 제공사 활용 추세

기업 내 의사 결정자들에 따르면, 회사 내에서 단일 LLM 모델이 아니라 다중 모델을 선택하는 추세로 바뀌고 있습니다. 최소 3개 이상의 파운데이션 모델을 사용하고, 사용 사례에 따라 다른 모델로 라우팅하는 방식을 사용하고 있습니다. 새로운 LLM을 선택할 때, 보안 (46%), 가격(44%), 성능(42%), 확장 기능(41%)을 중요한 요인으로 꼽았습니다.

기업에서는 ChatGPT, Claude, Llama 및 Gemini 모델을 필요에 따라 다양하게 사용하고 있지만, LangChain을 주로 활용하는 개발자들은 아직 ChatGPT 의존도가 높습니다. 특히, 로컬 환경에서 오픈 LLM 모델을 배포하는 Ollama와 클라우드 환경에서 오픈 LLM 모델을 배포하는 Groq 사용량이 꽤 높은 비율을 나타냅니다.

두 보고서의 결과가 약간 차이나는 것은 Menlo Ventures의 설문은 기업 내 의사 결정자에게 얻은 것으로 실제 제품 프로덕션에서 활용하는 추세를 파악한 것이고, LangChain 설문은 주로 GenAI 학습이나 취미 프로젝트를 하는 일반 개발자에게서 얻은 데이터기 때문인 것으로 파악됩니다.

생성형 AI 애플리케이션 설계 패턴 추세

효율적이고 확장 가능한 기업용 생성형 AI 시스템을 구축하기 위하여, 생성형 AI 앱 설계 패턴 역시 빠르게 변화하고 있습니다. 작년에 비해 프롬프트 엔지니어링, 파인튜닝 기법 활용 비율은 급격히 줄어들었으며, 오히려 검색 증강 생성 (RAG)는 51%로 압도적으로, 작년 31%에서 크게 증가한 수치입니다. 앞에서 언급한 AI 에이전트 아키텍처는 작년에 새롭게 선보였으며, 이미 전체 구현의 12%를 점유하고 있습니다. LangChain 사용자 중에서도 에이전트 기반 생성형 AI 앱을 만들 수 있는 LangGraph 사용률이 40% 이상으로 늘어났습니다.

RAG를 강화하기 위해 활용되는 벡터 데이터베이스의 경우, 기업 시장에서는 Pinecone (18%), PostgreSQL (15%) 및 MongoDB (14%) 등이 높은 점유율을 보이고 있습니다. 다만, LangChain 사용자 사이에서는 Chroma와 Facebook AI Similarity Search (FAISS)를 많이 선택하고 있습니다. 이들은 오픈 소스 기반 벡터 DB 혹은 벡터 검색 라이브러리로서, 로컬에서 활용할 수 있다는 장점이 있습니다. 역시 이들 차이점은 기업 시장의 프로덕션 제품과 취미 개발 사이에 간극이 존재하고 있음을 보여주고 있습니다.

생성형 AI 애플리케이션 활용 분야

기업 내 생성형 AI 파운데이션 모델 투자에 여전히 많은 지출을 하고 있지만, 모델 훈련 및 배포, 데이터 인프라, 산업별 혹은 업무별 AI 서비스 도입 등에도 많은 투자를 하고 있습니다. 특히, 개발자를 위한 소프트웨어 코딩 제안 기능이 51%로 가장 높고, 챗봇은 31%입니다. 특히, GitHub Copilot과 Cursor 같은 코딩 도우미 서비스를 빠르게 도입하고 있습니다.

엔터프라이즈 검색, 데이터 추출 및 변환 (각 28% 및 27%)은 기업 전체에 흩어져 있는 데이터 사일로에 숨겨진 지식을 발굴하려는 높은 의지를 반영하고 있구요. 특이하게, 회의 요약이나 카피라이팅, 이미지 생성 같은 업무에 직접적으로 활용하는 기능을 통한 시간 절약이 그 다음으로 높은 빈도를 나타내고 있습니다.

마무리

• 올해는 기업형 AI 시장에서 에이전트(Agent) 방식이 주요 패러다임의 중심으로 부상할 것으로 예상되며, 특히 멀티 에이전트 시스템이 핵심 키워드로 떠오르고 있습니다. 산업별 혹은 업무 영역별 버티컬 AI 서비스를 통해 기존 워크플로우와 조직 구조를 변화시키며, 효율성을 기반한 비즈니스 모델로 진화할 것으로 보입니다.
• 기업들이 멀티 언어 모델 전략을 기반으로 사용 사례에 따라 가격 대비 성능을 중심으로 오픈 및 클로즈드 모델을 필요에 따라 선택할 것으로 보이며, 비용 절감을 위한 다양한 모델 활용 기법(프롬프트 캐싱 및 라우팅, 모델 증류)도 더 많이 사용될 것입니다.
• 개발자들이 가장 첫번째 고객으로서 생성형 AI를 적극적으로 채택하고 활용하고 있으며, 생성형 AI 기반 코딩 도우미 서비스 시장의 경쟁이 일어날 것으로 예상되며 (최근에 GitHub Copolit 무료 제공), 텍스트, 이미지, 동영상 등의 멀티 모달 기반의 챗봇 제작도 대세가 될 것 같습니다.

올 한해도 흥미진진한 해가 될 듯 싶네요.

1. 요구 사항으로서 진화 가능성

아마 오늘 설계하는 아키텍처는 내년에도 똑같지 않을 것입니다. 아키텍처의 진화 및 유지 관리 가능성은 서로 혼동해서는 안 됩니다. 하나는 시간이 지남에 따라 복잡성을 처리하기 위한 장기 전략이고 다른 하나는 단기적으로 시스템이 제대로 작동하도록 하는 것입니다. 예를 들어, Amazon S3는 네트워크(Nitro)와 스토리지가 서로 고정되지 않고 시간이 지남에 따라 진화할 수 있을 만큼 모듈식으로 만들어진 훌륭한 사례입니다.

아키텍처를 계속 바꿀 수 있는 것은 복잡성을 줄이고, 향후 변경 사항을 쉽게 수용할 수 있습니다.

2. 복잡성을 조각으로 나누기

아키텍처가 가진 복잡성을 해소하기 위해 시스템 분리/작은 구성 요소를 만듦으로서 서ㅅ비스간 낮은 결합도/높은 응집도 작은 구성 요소를 구성할 수 있습니다. 이를 위해 각 모듈이 쉽고 빠르게 서로 통신할 수 있도록 잘 정의된 API를 제공해야 합니다. Amazon CloudWatch가 바로 좋은 예입니다. 고객에게 중단 없이 새로운 기능을 제공하기 위해 시간이 지남에 따라 다시 작성되고 다시 작성된 매우 간단한 프론트엔드 서비스를 제공하고 있습니다.

높은 응집성과 잘 정의된 API를 통해 복잡한 기능을 빌딩 블록으로 분해하여 구성해야 합니다.

3. 사내 조직을 아키텍처에 맞추기

복잡한 시스템을 구축하면 조직은 일반적으로 구축하는 소프트웨어만큼 복잡해집니다. 즉, 소규모 팀을 구성하고, 현재 상태에 대해 항상 도전하며, 서비스 제공해주는 것이 좋습니다. 팀이 성공하려면, 팀이 진정으로 제품을 소유하고 있다고 느낄 때, 그들은 결과를 관리할 수 있다는 것을 알고 고객에게 투자했기 때문에 더 나은 결정을 내립니다.

4. 작은 단위로 구성하기

서비스를 작은 셀 기반 아키텍처로 분해하여 각각 독립적으로 작동하도록 하여, (고객에게) 영향 범위를 줄이고 중단을 최소화 해야합니다. 작은 셀은 상상할 수 있는 가장 큰 작업 부하를 처리할 수 있을 만큼 커야 하지만, 전체 규모로 테스트할 수 있을 만큼 작아야 합니다. 더 큰 셀은 규모의 경제성을 제공하지만 문제의 잠재적 영향이 커집니다.

셀 기반 아키텍처는 서비스를 격리되고 관리 가능한 단위로 구성하여 복잡성을 줄입니다. 이 접근 방식은 확장, 테스트 및 배포를 보다 통제 가능하고 예측 가능하게 만듭니다. 이 아키텍처를 자체 시스템에 적용하는 방법에 대한 자세한 지침은 AWS Well-Architected Framework를 확인하세요.

5. 예측 가능한 시스템 설계

우리는 아키텍처의 불확실성을 줄이기 위해 매우 예측 가능한 시스템 구축해야 하는데, 이를 위해서는 단순하게 유지해야 합니다. 단순함에는 규율이 필요합니다. 이 규율은 작은 시스템으로 큰 시스템을 호출하고, 지속적인 작업 패턴을 구현합니다.

예를 들어, Amazon Route 53 상태 점검 기능의 목표는 매우 예측 가능한 처리입니다. 각 상태 점검기는 고정 크기 테이블을 보내고, 집계기는 모든 항목을 처리합니다. Route 53은 결과를 메모리에 저장하고 DNS 쿼리만 참조합니다. 이는 낭비처럼 보일 수 있지만 복잡한 처리를 줄이는 이점은 엄청납니다.

6. 복잡성 자동화

자동화는 복잡하고 대규모 인프라를 관리하는 데 필수적입니다. AWS는 내구성, 확장성, 리전 구축, 소프트웨어 배포 및 물리적 네트워킹(문제의 자동 감지 및 해결)에 자동화를 사용합니다. 높은 판단력이 필요하지 않은 모든 작업은 자동화해야 합니다. “무엇을 자동화해야 할까?”에서 “무엇을 자동화하지 말아야 할까?”로 질문을 바꾸세요.

보안은 자동화를 어떻게 사용할 수 있는지에 대한 대표적인 예입니다. AWS에서 보안은 모든 사람의 일이며, 이는 복잡성을 관리하는 방법 중 하나입니다. 처음부터 보안을 고려하여 설계함으로써, 서비스를 생성할 때 보안을 서비스에 내장합니다. 이를 통해 대규모로 서비스를 실행하는 데 관련된 변수가 줄어들고 운영이 간소화되며 복잡성이 최소화됩니다.

더 자세한 것은 Werner Vogels 박사님 기조 연설 영상을 참고해주세요!

AWS 입사 및 AWS Lambda 출시 10주년

우선 지난 11월 1일이 AWS 입사 10주년이었습니다. 마침 AWS CommunityDay 행사 뒷풀이에서 AWS 강의실 상운님을 비롯해 AWSKRUG 리더분들에게 깜짝 축하를 받았습니다. 축하해 주신 모든 분들께 감사드리고, 늘 첫날(Day 1)의 초심으로 앞으로도 함께 성장해 나갔으면 합니다.

10년이 지났다고 AWS에서의 5년… 글로벌 회사에서 배운 것 이후, 특별히 달라진 것은 없는 것 같습니다. 10년 경력을 설계하는 방법이라는 원칙에 따라 잘 지나온 것 같습니다. 10년을 맞아 몇 가지 마일 스톤을 사진으로 기억해보고자 합니다.

마찬가지로, 올해는 서버리스 컴퓨팅의 개척자, AWS Lambda 출시 10주년이 되었네요! 제가 입사해서 처음 AWS re:Invent를 참여했을 때, 출시된 서비스로 매우 놀라웠던 기억이 있습니다. Amazon CTO이신 Werner Vogels 박사님은 AWS Lambda의 PRFAQ 문서를 공유해주셨습니다. Amazon의 PRFAQ 문화는 유명하지만, 이렇게 전문이 공개되기는 처음입니다. 관심 있는 분들은 꼭 읽어보시길!

Mozilla Firefox 출시 20주년

11월 9일이 Firefox 1.0 출시 20주년이었네요. 인터넷이 누구에게나 무료로 손쉽게 접근 가능하자는 아이디어로 출발한 오픈소스 프로젝트였습니다. 아직도 여전히 Firefox를 사용 중이고, Mozilla 커뮤니티를 후원합니다!

아직도 Mozilla Pontoon은 사용하여, 가끔 번역에도 참여하고 있습니다. Pontoon은 모질라에서 개발한 오픈 소스 소프트웨어 번역 플랫폼으로, 소프트웨어 번역을 효율적이고 협업적으로 진행할 수 있도록 설계되었습니다.

한국 웹 30주년

90년대 중후반 웹 기술 커뮤니티인 웹코리아(WWW-KR), 2000년대 웹 표준 및 웹 플랫폼 기술을 전파했던 Mozilla 커뮤니티, 웹표준프로젝트 및 웹2.0 워킹그룹 OB 운영진들이 함께 모여 조촐한 축하 모임을 만들었습니다. 10년전 있었던 한국 웹 20주년에 비해서 큰 행사는 아니지만, 참석자들 간의 네트워킹과 함께 웹표준, 클라우드, Web3 그리고 생성형AI까지 주제별 강연도 준비했으니 웹 기술에 대해 관심 있는 분들의 많은 참여를 바랍니다.

행사 안내

– 일시: 2024년 12월 23일(월) 19:00-21:00
– 장소: 역삼동 센터필드 이스트 18층 AWS 코리아 (지하철 역삼/선릉역 도보 5분 거리)

행사 일정

– 18:30-19:00 등록 및 입장
– 19:00-19:10 축하 인사말 (동영상) – Hakon Wium Lie (CSS 창시자)
– 19:10-19:30 한국 웹30주년 축하 및 개인/커뮤니티 근황 소개
– 19:30-19:50 식사 및 네트워킹
– 19:50-20:10 W3C 웹 표준 기술 동향 – 송효진 (책임연구원, LG전자)
– 20:10-20:30 클라우드와 생성형 AI로 본 웹서비스 기술 변화 – 윤석찬 (수석테크에반젤리스트, AWS)
– 20:30-20:50 Web3 웹 브라우저, Brave 이야기 – 홍영기 (SW Engineer, Brave)
– 20:50-21:00 클로징

행사 안내 페이지에서 참가 신청하시면 됩니다.

Update – 행사 사진과 영상도 업로드 하였습니다.

그래서, 앞으로는 지속 가능한 소셜 미디어 사용법에 따라 회사와 관련된 정보를 공유할 때는 그 목적을 분명히 하고 올리도록 노력하겠습니다. 또한, 정보 채널(링크드인, 트위터, 페이스북 페이지)과 개인 채널(개인 페북 계정, 인스타그램)을 목적에 따라 분리해서 사용해 왔는데, 정보 채널이 너무 심각하지 않도록 가끔 개인 사진이나 이야기도 정보 채널에 함께 올리도록 하겠습니다.

최근에 가장 좋았던 경험 중 하나는 7월 미국 출장 겸 휴가 때, 요세미티 국립공원을 방문한 것입니다. 미국을 수십번을 갔었는데도 아직 요세미티를 안 가봤던 게 아쉬웠거든요.

땅속에서 서서히 식은 거대한 화강암 암괴가 융기되어 올라와서 빙하에 의해 깍여 만들어진 절벽과 계곡을 보면서 아무리 강한 암석도 부드러운 물에는 당할 재간이 없구나라는 생각을 했습니다. 젊을 때는 시시비비를 가리면서 독불장군처럼 살기도 했는데, 지금은 남의 말을 잘 듣고, 언제나 가는 길을 수정할 수 있는 유연한 인생으로 살아가려고 합니다.

출장 중에 시애틀에서 AWSHero Global Summit 행사도 열렸습니다. 전 세계 250여명 뿐인 클라우드 전문가 커뮤니티로서, 올해 10주년이 되었습니다. 한국에서도 7명이 참석하여, 분야별 AWS 제품팀과 의견을 나누고, 다른 나라 Heroes들과도 즐거운 시간을 보냈습니다!

세 줄 요약

기술적 측면

• GenAI는 대규모 언어 모델(LLM)을 기반으로 하는 기술
• 통계적 기법과 수학적 계산을 활용하지만, 진정한 의미의 “이해”나 “추론”은 하지 못함
• 학습 데이터의 품질이 결과물의 품질을 좌우함
• 복잡한 문제 해결에는 한계가 있으나, 기본적인 지원 업무에는 유용

과대 광고

• 영화나 책의 영향으로 AI의 능력이 과대 평가되는 경향
• 벤처 캐피털이 유행을 쫓아 과도한 투자를 하는 현상
• 최근 들어 과대 선전이 다소 수그러들고 있음

우려되는 점들

• AI가 인류를 위협할 것이라는 공포는 과장된 것
• 실제 우려되는 점은:
  • GenAI 거품이 터졌을 때 유용한 기술마저 버려질 수 있다는 점
  • 다른 중요한 기술 개발에 대한 투자가 줄어드는 점
  • 인력 감축의 도구로 악용될 수 있다는 점

결론적으로, 생성형 AI는 적절히 활용될 때 유용한 도구이지만, 현재의 과대 평가된 기대치는 조정될 필요가 있다는 것입니다. 제임스의 말처럼 생성형 AI와 LLM의 거품이 꺼질때, 그래도 그 기술은 완전히 죽지 않길 바랍니다.

Amazon Bedrock Studio

Amazon Bedrock Studio는 개발자 환경을 설정하고 사용할 필요 없이 Amazon Bedrock 모델과 기능을 사용하는 앱을 쉽게 프로토타입화할 수 있는 웹 앱입니다. 예를 들어, Amazon Bedrock을 사용하여 코드를 작성하지 않고도 Anthropic Claude 모델로 프롬프트를 시도할 수 있습니다. 나중에 Bedrock Studio를 사용하여 코드를 작성하지 않고도 Knowledge Base나 Guardrail과 같은 Amazon Bedrock 모델과 기능을 사용하는 프로토타입 앱을 만들 수 있습니다.

Amazon Q App 서비스

Amazon Q Apps는 모든 직원이 아이디어를 신속하게 생성형 AI 기반 앱으로 전환하여 작업을 간소화하고 개인 및 팀 생산성을 높일 수 있도록 지원합니다. 이러한 안전하고 사용자 정의된 앱은 Amazon Q Business를 통해 엔터프라이즈 지식을 기반으로 구축됩니다. 사용자는 Amazon Q Business와의 대화에서 또는 자연어로 요구 사항을 설명하여 한 단계로 앱을 생성하고, 데이터 소스를 선택하여 출력 품질을 개선하고, Amazon Q Apps 출력을 만들고 사용할 수 있는 API를 통해 Amazon Apps의 힘을 선택한 도구와 애플리케이션에 적용할 수 있습니다.

Amazon Q Developer

Amazon Q Developer는 AWS 애플리케이션을 이해하고, 구축하고, 확장하고, 운영하는 데 도움이 되는 생성형 인공 지능(AI) 기반 대화형 어시스턴트입니다. AWS 아키텍처, AWS 리소스, 모범 사례, 설명서, 지원 등에 대해 질문할 수 있습니다. Amazon Q는 지속적으로 기능을 업데이트하여 질문에 가장 문맥적으로 관련성이 높고 실행 가능한 답변을 제공합니다.

AWS App Studio

AWS App Studio는 자연어를 사용하여 비즈니스 애플리케이션을 구축하는 생성형 AI 기반 서비스로, 새로운 빌더가 몇 분 만에 애플리케이션을 생성할 수 있도록 지원합니다. App Studio를 사용하면 IT 프로젝트 관리자, 데이터 엔지니어, 엔터프라이즈 아키텍트, 솔루션스 아키텍트와 같은 기술 전문가가 심층적인 소프트웨어 개발 기술이 없이도 조직의 니즈에 맞는 애플리케이션을 빠르게 개발할 수 있습니다.

우선 생성형 AI가 제공하는 파운데이션 모델을 이용하여, 업무 및 개발 생산성을 높일 수 있는 다양한 AWS 서비스를 이용할 수 있습니다. 누구나 접근하기 쉬운 노코드 도구인 PartyRock 부터, 기업 내부 업무 생산성을 높여 줄 Amazon Q Business, 그리고 손쉽게 생성형 AI를 구현할 수 있는 Amazon Bedrock Studio와 Amazon Q를 이용한 개발 사이클 전체의 변화를 살펴봅니다. 지난 AWS Summit 2024 기조 연설 중 일부를 요약했습니다.

검색 증강 생성(Retrieval-Augmented Generation)
RAG는 대규모 언어 모델(LLM)의 출력을 최적화하여 응답을 생성하기 전에 학습 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 프로세스입니다. 이 때, 내부 데이터를 벡터 데이터로 변환하는 벡터 임베딩 그리고, 검색에서 사용할 수 있는 벡터 스토어를 이용합니다.

Amazon Bedrock 서비스
Amazon Bedrock은 AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI 및 Amazon과 같은 선도적인 AI 회사의 다양한 고성능 파운데이션 모델(FM)을 단일 API를 통해 제공하는 완전 관리형 서비스입니다. 이 서비스를 사용하면 보안, 개인정보 보호 및 책임형 AI를 포함하여 생성형 AI 애플리케이션을 구축하는 데 필요한 광범위한 기능 세트를 활용합니다.

Amazon Bedrock을 사용하면 사용 사례에 맞게 상위 FM을 쉽게 실험 및 평가하고, 미세 조정 및 검색 증강 생성(RAG)과 같은 기술을 사용하여 데이터로 비공개로 사용자 지정하고, 엔터프라이즈 시스템 및 데이터 소스를 사용하여 작업을 실행하는 에이전트를 구축할 수 있습니다. Amazon Bedrock은 서버리스이므로 인프라를 관리할 필요가 없으며 이미 익숙한 AWS 서비스를 사용하여 생성형 AI 기능을 애플리케이션에 안전하게 통합하고 배포할 수 있습니다.

Amazon Q 서비스
이 서비스는 기업에서 실제 업무가 수행되는 방식을 혁신하는 생성형 AI 어시스턴트입니다. Amazon Q Business는 엔터프라이즈 시스템의 데이터 및 정보를 기반으로 질문에 답하고, 요약을 제공하고, 콘텐츠를 생성하고, 작업을 안전하게 완료할 수 있는 생성형 AI 기반 도우미입니다.

Amazon Q Developer는 애플리케이션 코딩, 테스트 및 업그레이드부터 오류 진단, 보안 스캐닝 및 수정 작업 수행, AWS 리소스 최적화에 이르기까지, 개발자와 IT 전문가의 모든 작업을 지원합니다.

앞으로 개인 유튜브 채널에 짧은 동영상들도 많이 올려볼 예정이니, 많이 봐주세요!

플랫폼 엔지니어링의 개념

플랫폼 엔지니어링은 데브옵스와 신뢰성 엔지니어링과 달리 공통 인프라 세팅과 보안 준수 등 중복되는 영역을 제거하여 개발자 도구를 제공합니다. 과거 온프레미스 환경에서는 개발 팀과 운영 팀이 분리되어 있었으나, 클라우드가 대세가 되면서 데브옵스 환경이 도입되었죠. 데브옵스 환경에서는 개발자가 운영을 함께 수행하며, 이를 바탕으로 하는 SRE 조직이 공통 운영 조직을 담당하게 됩니다. 플랫폼 엔지니어링은 규모가 큰 조직에서 클라우드의 복잡성을 효과적으로 관리할 수 있도록 채택하는 것이 적합합니다. 각각의 애플리케이션은 플랫폼 팀이 제공한 가드레일을 바탕으로 개발 플랫폼을 선택하며, 이를 통해 초기 학습 비용을 줄이고 규정을 준수할 수 있어요.

플랫폼 엔지니어링 사례는?

Intuit는 중소기업 회계사와 개인을 위한 금융 소프트웨어를 만드는 회사로, 2018년도부터 AWS를 운영하고 있는데, 플랫폼 엔지니어링팀은 쿠버네티스 기반의 개발팀용 블루프린트를 만들어 개발팀과 공유합니다. 개발팀은 선택한 블루프린트를 통해 2-3분 안에 DV 스토리지 같은 신규 개발 자산들을 배포할 수 있습니다. 리버티 뮤추얼은 Serverless 퍼스트 전략을 통해 클라우드 기반으로 민첩하고 고객 중심적인 기업으로 변모하고 있는데요. 2019년도에 리버티 뮤추얼은 서버리스 패턴을 제공하여 개발자들이 손쉽게 서버리스 앱을 구성할 수 있도록 했습니다.

AWS 기반 플랫폼 엔지니어링 도구 소개

• AWS Control Tower는 기업의 보안 규정 준수 요구 사항을 관리하면서 여러 AWS 서비스를 쉽게 구성할 수 있는 기능을 제공합니다.
• AWS Organization을 통해 쉽게 AWS 계정을 추가하고, 팀의 계정 및 거버넌스 정책을 관리할 수 있습니다.
• Amazon EKS는 AWS 관리형 쿠버네티스 서비스로, 클러스터 구성 및 관리를 용이하게 하지만, 여전히 어려운 점이 있어요. 이를 보완하기 위해, EKS 블루프린트는 쿠버네티스를 잘 모르는 사용자도 빠르게 구성하고 운영할 수 있도록 도와주는 솔루션을 활용할 수 있습니다.
• AWS Proton은 인프라 관리자와 개발자 간의 협업을 지원하며, 관리자는 배포 템플릿을 설정하고 개발자는 이를 활용해 서비스를 배포할 수 있습니다. AWS 환경 템플릿과 서비스 템플릿을 통해 인프라 및 스키마 설정이 가능하며, 필요한 클라우드 포메이션 템플릿을 포함할 수 있습니다. 배포 후, 사용자에게 제공되는 서비스 엔드포인트와 AWS Proton이 생성한 스택을 통해 자동 배포 및 업데이트가 이루어집니다.

플랫폼 엔지니어링의 모범 사례

AWS Well-Architect 클라우드 모범 사례에 따라 다양한 운영 패턴 및 솔루션을 제공하고 있으며, AWS 솔루션 라이브러리는 AWS와 AWS 파트너가 구축한 검증된 솔루션과 아키텍처를 제공합니다. 특히, AWS CDK는 코드로 클라우드 인프라를 관리할 수 있는 패턴과 코드 샘플을 제공하고, 컨스트럭트 허브에서는 CDK를 활용할 수 있는 다양한 오픈 소스 라이브러리를 검색할 수 있습니다.

더 자세한 것은 AWSKRUG 플랫폼엔지니어링 소모임에 참여해 보시기 바랍니다.

※ 이 글은 콘텐츠 요약 생성형 AI 사이트인 릴리스에이아이(Lilys AI)의 도움을 받았습니다.