전 NASA 개발자 팁: AI 에이전트 활용 꿀팁! 코드 작성 시간 90% 단축 비법 대공개!

코딩 에이전트랑 놀지 말고 일하자!

요즘 코딩 에이전트들 진짜 똑똑하잖아? 문제도 척척 풀어주고. 근데 얘네가 혼자서는 좋은 코드를 못 만들어. 우리가 옆에서 잘 도와줘야 해.

가장 많은 사람들이 놓치는 게 바로 프로그램 설계야. 에이전트한테 일을 맡기기 전에, 얘네가 어떤 결정을 내릴지 미리 생각해야 해. 안 그러면 나중에 후회할 수도 있거든.

핵심은 이거야:

• 측정 가능한 결과를 알려주면 에이전트는 뭐든 해낼 수 있어.
• "이렇게 해줘"라고 구체적으로 알려주면 좋지만, 안 알려주면 에이전트가 더 좋은 방법을 찾아낼 수도 있어.

데스터(Dexter) 이야기

이 사람 이름은 데스터(Dexter)인데, '컨텍스트 엔지니어링'이라는 용어를 만들고 AI 에이전트가 4개월 동안 사람 도움 없이 돌아가는 소프트웨어 공장을 만든 사람이야.

이 팟캐스트에서는 왜 벤치마크가 중요하지 않은지, 데스터만의 프로그램 설계 시스템은 뭔지, 그리고 왜 '풀 리퀘스트'가 사라질 거라고 생각하는지에 대해 이야기해.

벤치마크, 왜 별로일까?

보통 벤치마크는 한두 문제만 딱 풀고 끝나는 식이야. 근데 실제 세상에서는 그렇지 않잖아. 데스터는 이런 벤치마크가 에이전트의 진짜 능력을 보여주지 못한다고 생각해.

소프트웨어 공장, 어떻게 변해왔을까?

옛날 소프트웨어 공장 (AI 없을 때):

1. 사람들이 할 일 목록을 만들어 (이슈 트래커 같은 거).
2. 누군가 그걸 만들고, 코드 리뷰를 하고, 테스트를 거쳐.
3. 문제가 있으면 다시 만들고, 고치고... 계속 반복.
4. 결국 배포하고, 사용자들이 불평하면 다시 처음으로 돌아가.
5. 밤에 알람 울리면 엔지니어가 일어나서 고치고... (이런 거 정말 싫잖아!)

AI 등장 후 소프트웨어 공장:

1. 사람이 만들던 부분을 AI 에이전트가 만들기 시작해.
2. 이 과정이 훨씬 빨라져 (몇 시간 또는 며칠 걸리던 게 몇 분 또는 몇 시간으로).
3. 하지만 코드 리뷰나 최종 검토는 여전히 시간이 오래 걸려.

AI 에이전트가 코드 리뷰까지 하면?

• 작은 오류들은 에이전트가 잡아줘.
• 에이전트가 앱을 테스트해주기도 해.
• 하지만 진짜 중요한 코드를 사람이 직접 보거나, 나중에 문제가 생기지 않을지 확신하는 건 여전히 어려워.

AI 에이전트, 어디까지 왔나?

• 문제 해결: 에이전트는 문제를 정말 잘 풀어.
• 코드 리뷰: 수만 줄의 코드를 사람이 다 볼 수는 없어. 에이전트가 도와주지만, 완벽하진 않아.
• 신뢰 쌓기: 에이전트가 찾은 오류를 다 고치면 좀 더 믿을 수 있겠지.
• 자동화: 밤에 알람이 울리면 내가 직접 일어나는 대신, 에이전트가 자동으로 고쳐서 풀 리퀘스트를 보내주는 식으로 발전하고 있어. 사용자 요청도 에이전트가 바로 처리해주기도 하고.

실제 사례:

• 어떤 사람은 에이전트한테 모든 오류 보고서를 검토하게 해서, 원인을 파악하고 해결 방법을 알려주게 하고 있어.
• 또 다른 사람은 에이전트가 직접 코드를 고치고 풀 리퀘스트까지 보내도록 하고 있어.

코딩 에이전트, 어떻게 써야 할까?

• 프로그램 설계가 중요해: 에이전트한테 일을 맡기기 전에, 어떻게 만들지 미리 계획해야 해.
• 측정 가능한 결과: "이걸 이렇게 만들어줘"라고 명확하게 알려주면 에이전트가 훨씬 잘해.
• 새로운 방법: 에이전트한테 방법을 안 알려주면, 얘가 예상치 못한 더 좋은 방법을 찾아낼 수도 있어.
• 테스트 자동화: 에이전트가 만든 코드를 스스로 테스트하게 만들고, 실패하면 원인을 파악해서 다시 시도하게 하는 거야.
• 코드 리뷰: 에이전트가 만든 코드를 다 읽지 않아도 되도록, 테스트나 다른 도구들을 더 튼튼하게 만드는 거지.

코드를 안 읽어도 될까?

"코드 리뷰 안 해도 된다"는 생각은 위험해.

• 에이전트가 코드를 너무 많이 만들면, 나중에 문제가 생겼을 때 사람이 그걸 이해하고 고치기 어려워.
• 코드의 논리를 이해하는 게 중요해. 코드를 직접 보지 않더라도, 프로그램이 어떻게 돌아가는지 알아야 해.

AI와 함께 일하는 4단계

1. 제품 (Product): 어떤 사용자 문제를 해결할 건지, 성공을 어떻게 측정할 건지 명확히 해.
   • 측정 가능한 결과가 있으면 에이전트가 알아서 최적의 방법을 찾아.
   • 최신 에이전트들은 스스로 테스트를 더 많이 하려고 해.
2. 시스템 아키텍처 (System Architecture): 프로그램이 어떻게 돌아갈지 큰 그림을 그려.
   • 서비스들이 어떻게 연결될지, 어떤 데이터베이스를 쓸지 등을 미리 정하는 거야.
   • 이건 많은 사람들이 이미 AI와 함께 하고 있는 부분이야.
3. 프로그램 설계 (Program Design): 에이전트가 코드를 만들기 전에, 어떤 결정을 내릴지 미리 정하는 거야.
   • 코드 구조나 테스트 방법 등을 미리 계획하는 거지.
   • 핵심은 '레버리지'야. 적은 시간으로 더 좋은 결과를 얻는 거지.
4. 수직적 슬라이스 (Vertical Slices): 한 번에 조금씩 만들고 테스트하는 거야.
   • 에이전트는 보통 한 번에 많은 코드를 만들려고 하는데, 이건 위험해.
   • 조금씩 만들고 테스트하면서 문제가 없는지 확인하는 게 좋아. 마치 새로운 프로그래밍 언어를 배울 때처럼 말이야.

왜 AI 에이전트는 아직 완벽하지 않을까?

• 벤치마크의 한계: 지금 벤치마크들은 대부분 짧은 문제만 다뤄. 실제로는 더 복잡하고 긴 문제들이 많아.
• 품질 문제: 에이전트가 테스트를 통과하기 위해 코드를 이상하게 만들거나, 불필요한 코드를 추가하는 경우가 있어.
• 유지보수 어려움: 에이전트가 만든 코드가 나중에 유지보수하기 어렵게 만들 수 있어.
• 문제 발견: AI는 아직 문제 자체를 처음부터 끝까지 완벽하게 발견하고 해결하는 데는 한계가 있어.

컨텍스트 엔지니어링이란?

• AI 모델이 이해할 수 있는 '컨텍스트 창'을 어떻게 잘 활용하느냐에 대한 거야.
• 모델한테 정확하고 필요한 정보를 최대한 적은 양으로 전달하는 게 중요해.
• 모델이 똑똑해지면서 컨텍스트 창의 중요성이 조금 줄어들기도 하지만, 여전히 중요한 개념이야.

AI와 함께 일할 때 주의할 점

• '멍청한 구간' (Dumb Zone): 모델이 너무 많은 정보를 받거나, 너무 오래 작업하면 성능이 떨어질 수 있어. 이럴 땐 다시 시작하거나 정보를 압축해서 주는 게 좋아.
• 인간의 '멍청한 구간': 사람도 피곤하거나 집중력이 떨어지면 실수를 해. AI도 마찬가지야.
• 병목 현상: 공장에서 가장 느린 부분을 먼저 해결해야 전체 효율이 올라가는 것처럼, 소프트웨어 개발에서도 가장 느린 부분을 찾아 해결해야 해. 코딩 에이전트를 아무리 많이 써도 코드 리뷰가 느리면 소용없어.
• 결과 중심: 단순히 에이전트를 많이 쓰는 것보다, 실제로 좋은 결과물을 만들어내는 게 중요해.

앞으로의 AI와 개발

• AI는 계속 발전할 거야. 하지만 사람의 직관과 경험은 여전히 중요해.
• AI와 함께 일하는 방법을 배우고, AI가 잘하는 것과 사람이 잘하는 것을 구분해서 효율적으로 협업하는 게 중요해.
• AI 때문에 일자리가 없어질까 걱정하는 사람들도 있지만, AI는 새로운 기회를 만들기도 할 거야.
• 가장 중요한 건 즐겁게 배우고, 좋은 결과물을 만드는 것이야.

데스터의 프로그램 설계 시스템은 아래 링크에서 무료로 받을 수 있어!