Connect with us

사상 리더

API 폭발은 실재하다 – 그리고 Vibe Coding이 불을 지피고 있다

mm
AI 붐은 우리에게 많은 것을 가져다주었습니다: 생산성 향상, 새로운 창의적 워크플로, 그리고 최근에는 API의 아발란체. 내부 및 외부 API의 수가 회사에서 하룻밤 사이에 두 배로 증가한 것처럼 느껴진다면, 당신은 상상하는 것이 아닙니다. 우리는 API 폭발을 겪고 있으며, 생성적 AI는 주요 가속기입니다.

몇 년 전, 성숙한 코드베이스에서 새로운 API 엔드포인트를 생성하는 것은 높은 마찰의 노력이었다. 여러 코드 도메인의 소유권을 탐색하고, 성가신 아키텍트로부터 승인을 얻고, 때로는 수주 또는 수개월 동안 kéo되는 검토를 수행해야 했습니다. 마찰은 고통스러웠지만, 모든 새로운 API는 검토와 기관의 기억을 동반했습니다.

지금? AI 기반 개발 도구가 그 병목을 없애버렸습니다.

GenAI 에이전트는大量의 컨텍스트 데이터를 소비하고 수백 개의 파일에 걸쳐 코드 변경을 생성할 수 있습니다. 그것은 엔지니어뿐만 아니라 제품 매니저와 지원 팀과 같은 비기술적 역할을 위해 API를 생성하는 능력을 민주화했습니다. (충격적인 공포) 이제 그들은 실험을 직접 프로덕션에 배포할 수 있습니다.

それは 소프트웨어 개발 프로세스에서 권력을握する 사람들의 대규모 변화를 의미합니다. 그리고 그것은 반드시 나쁜 것은 아닙니다. 특히 속도와 반복을 우선하는 비즈니스 환경에서는 그렇습니다. 그러나 결과는 급속히 배포된 API의 와일드파이어입니다. 많은 것이 “실험적”으로 출시되거나 기능 플래그 뒤에 숨겨져 있지만, 비즈니스 요구 사항이 발전함에 따라 빠르게 필수적인 인프라가 됩니다. 빠른 프로토タイプ로 시작하는 것이 주요 통합이 됩니다. 그리고 이제는 그것을 풀어헤칠 수 없습니다.

“Vibe Coding”의 부상

이 새로운 종류의 AI 생성 API는 종종 아키텍처, 문서화 또는 테스트가 거의 없는 상태로 도착합니다. 우리는 이것을 “바이브 코딩”이라고 부릅니다 – 시스템이나 디자인 패턴에 대한 깊은 이해가 아니라, 대략적인 직관, 느슨한 프롬프트 및 “작동해야 할” 일반적인 감각에 따라 소프트웨어를 작성하는 것입니다.

불행히도, 이러한 방식으로 생성된 API는 일관된 규칙을 따르지 않으며, 강력한 유효성 검사를欠如하며, 종종 내부 기준을 무시합니다. 더 나쁘게는, 그것은 민감한 데이터 또는 외부에 노출된 엔드포인트에 연결될 때 심각한 보안 또는 규제 위험을 도입할 수 있습니다. AI는 귀하의 회사 거버넌스 모델 또는 규정 준수 요구 사항을 알지 못합니다. 명시적으로 지시하지 않는 한, 그것은 그들을 염두에 두고 작성하지 않을 것입니다.

그리고 문제는 빠르게 누적됩니다. AI는 또한 테스트를 생성하는 데 사용됩니다. 그러나 깨진 코드가 AI 생성 유효성 검사와 함께 테스트되면, 테스트는 단지 결함이 있는 동작을 확인합니다. 개발자는 자신이 작성하지 않은 코드에 대해 테스트를 작성하기를 주저하며, 기계에 의해 생성된 코드에 대해서도 vậy입니다. 따라서 AI가 부족한 코드를 테스트하고 “검증”하는 동일한 불안정한 스카폴딩을 생성합니다.

패치워크 API와 소유권 위기

모든 것이 대부분의 조직 내에서 펼쳐지는, 산재한 API 계층으로 이어집니다. API는 이제 중복되는 도메인을 가로지르며, 약간 다른 방식으로 유사한 기능을 수행하며, 종종 명확한 소유권이 없습니다. 많은 것이 기본 데이터 모델, 서비스 경계 또는 팀 차터에 대한 깊은 이해 없이 작성되었습니다. 당연히, 유지 보수가 악몽이 됩니다. 이 엔드포인트의 소유자는 누구인가?誰が 수정할 수 있습니까?誰가 그것이 존재한다는 것을 알고 있습니까?

AI 도구는 유틸리티와 속도를 우선합니다. 제어되지 않으면, 그것은 배달에 대한 가장 짧은 경로를 생성할 것입니다. 그것이 귀하의 아키텍처 비전과 일치하는지 여부와 상관없이 말입니다. 시간이 지남에 따라 기술 부채의 무게는 진행을 중단시킬 수 있습니다.

실제적인 단계

1. 가시성

答案은 모든 것을 느리게 하는 것이 아니며, AI를 금지하는 것이 아닙니다. 그것은 현실적이지 않으며, 그것은 엄청난 가치를 테이블에 남겨두게 할 것입니다. 대신, 우리는 생성적 개발의 시대에 소프트웨어를 관리하는 방법을 발전시켜야 합니다.

기초적인 첫 번째 단계는 가시성입니다. 귀하는 볼 수 없는 것을 관리할 수 없습니다. 조직은 정적 문서가 게시된 순간부터 구식이 되는 API 발견을 계속해야 합니다.

런타임과 코드에서 API를 모니터링하는 도구는 필수적입니다. 한 번 귀하가 실제 API 풍경을 매핑할 수 있다면, 귀하는 위험을 평가하고 중복을 식별하고 신뢰할 수 있는 거버넌스를 구축하기 시작할 수 있습니다.

아이러니하게도, AI 자체가 이 프로세스에서 도움이 될 수 있습니다. 프롬프트된 AI 모델을 사용하여 API 맵을 분석하고 감사하면, 이상, 위험한 노출 및 통합 기회를 발견하는 데 도움이 됩니다. 이것은 더 많은 것을 구축하는 것을 도와주는 것이 아니라, 이미 가지고 있는 것을 정리하는 데 AI가 도움을 주는 것입니다.

2. 조직 전체의 프롬프트 엔지니어링 및 툴링 표준화 설정

AI 도구의 출력과 입력을 모두 더 잘 제어하면 코드 생성을 제어하는 데 큰 도움이 됩니다. 단순한 단계로, 조직 내에서 승인된 AI 기반 IDE 및 모델을 정렬하는 것이 변이를 줄이는 데 도움이 됩니다. 이것은 또한 새로운 모델을 롤아웃하는 것을 더 쉽게 만들고, 프롬프트가 엔지니어의 워크스테이션에서 재현 가능하도록 만드는 데도 도움이 됩니다.

더 강력한 것은 rules.md 유형의 파일을 AI 코더가 에이전트에 대한 컨텍스트로 제공하도록 요구하는 것입니다. 코드베이스가 더 복잡할수록, 모든 엔지니어가 동일한 규칙 세트를 사용하여 작동하는 것이 더 도움이 됩니다. AI 에이전트에 기존 구조와 함께 작동하는 코드를 올바르게 생성하는 방법에 대한 컨텍스트를 제공합니다.

우리는 생성적 지니를 다시 병에 넣을 수 없습니다. 그러나 우리는 그것을 안내하고, 폭발 반경을 포함하며, 책임 있는 혁신을 위해 그것을 사용할 수 있습니다. 그 작업은 코드와 함께 시작되는 것이 아닙니다. 그것은 명확성과 함께 시작됩니다.

Bio: Benji Kalman, VP of Engineering and co-founder of Root, 10년 이상의 사이버 보안 및 DevTools 연구 및 개발 경험을 보유하고 있습니다. 8200 Alumni로 사이버 작전을 전공한 Benji는 Snyk의 초기 멤버로, 5년 이상 Snyk의 보안 RnD 그룹 디렉터로 재직하며 회사 보안 지식 베이스의 큐레이션 및 생성을 담당했습니다.