시리즈: AI를 팀원으로 삼아 SaaS 구축하기

이전 포스트에서 저는 AI를 단순한 코드 생성기가 아니라 팀에 합류한 새로운 엔지니어처럼 대하는 것에 대해 이야기했습니다.

그 실험은 흥미로웠습니다.

저를 놀라게 한 것은 AI가 버그를 생성했다는 점이 아니었습니다.

제가 말한 적 없는 가정(assumptions)을 바탕으로, AI가 지속적으로 완벽하게 합리적인 엔지니어링 결정을 내렸다는 점이었습니다.

그리고 그 가정들이 서서히 제 프로젝트의 아키텍처(architecture)를 형성해 나갔습니다.

첫 번째 놀라움: 패키지 선택 📦

구현을 시작할 때, 저는 AI에게 프로젝트에 대한 많은 컨텍스트(context)를 제공했습니다.

AI는 기술 스택(tech stack)을 알고 있었습니다.
목표를 알고 있었습니다.
이것이 사이드 프로젝트라는 것도 알고 있었습니다.

그래서 저는 AI에게 애플리케이션의 스캐폴딩(scaffold)을 요청했습니다.

AI가 선택한 패키지들은 완전히 합리적이었습니다.

결국, AI는 이것이 거대한 엔터프라이즈 애플리케이션(enterprise application)이 될 의도가 아니라는 것을 알고 있었으니까요.

풀 리퀘스트(pull request, PR)를 검토한 후에야 저는 무언가를 깨달았습니다.

저는 제가 원하는 '품질(quality)'에 대해 실제로 설명한 적이 없었습니다. 😅

제 머릿속에서 이 프로젝트는 다음 사이의 어딘가에 위치해 있었습니다:

• 주말 해커톤 프로젝트
• 자신 있게 배포할 수 있는 프로덕션 준비 완료(production-ready) 서비스

저는 빠르게 움직일 수 있을 만큼 가벼우면서도, 6개월 후에 내린 결정들을 후회하지 않을 만큼 구조화된 것을 원했습니다.

AI는 그것을 알 방법이 없었습니다.

AI는 제가 설명한 그대로, 즉 '사이드 프로젝트'에 최적화했습니다.

그리고 그때 저는 깨달았습니다:

AI는 당신이 무엇을 만들고 있는지 이해할 필요가 있을 뿐만 아니라, 당신이 그것을 어떻게 만드는지에 대해 어떻게 생각하는지도 이해해야 합니다.

작은 기술적 결정이 나중에 커집니다 🧐

PR을 더 많이 검토할수록, 더 많은 사례를 발견하게 되었습니다.

AI가 생성한 한 마이그레이션(migration)은 다음과 같았습니다:

• updated_at 컬럼 없음
• up.sql만 존재
• down.sql 없음

다시 말하지만...

기술적으로 잘못된 것은 아무것도 없었습니다.

만약 이것이 빠른 프로토타입(prototype)이었다면, 저는 아마 두 번 생각하지 않고 병합(merge)했을 것입니다.

하지만 저는 스스로에게 질문하기 시작했습니다:

"잠깐... 이 마이그레이션(migration)을 롤백(rollback)해야 할 때는 어떻게 되지?" 🤔

"나중에 자동으로 타임스탬프(timestamps)를 찍고 싶어지면 어떻게 되지?" 🤔

"AI는 왜 이걸 선택했을까?" 🤔

답은 간단했습니다.

제가 다르게 말한 적이 없었기 때문입니다.

AI는 장기적인 유지보수성(maintainability)을 위해 최적화하고 있었던 것이 아닙니다.

AI는 다음을 위해 최적화하고 있었습니다:

"이 기능을 작동하게 만들어라."

그리고 솔직히 말해서, 다음과 같이 말했을 때 그것은 완전히 합리적인 가정입니다:

"이것은 사이드 프로젝트(side project)입니다."

문제는 무엇일까요?

"사이드 프로젝트"는 많은 의미를 가질 수 있습니다.

그것은 다음과 같은 의미일 수 있습니다:

• 다음 달에 삭제할 무언가 🗑️
• 몇 년 동안 개인적으로 사용할 무언가 🚀
• 결국 실제 제품이 될 수도 있는 무언가 🌱

AI는 당신이 말해주지 않는 한, 당신이 어떤 의미로 말했는지 알지 못합니다.

저의 워크플로우(workflow)가 바뀌었습니다 🔄

원래 저의 워크플로우는 다음과 같았습니다:

AI에게 프롬프트(Prompt) 입력
↓

...

단순했습니다.

빠릅니다.

하지만 위험하기도 합니다.

이제는 다른 엔지니어와 협업하는 것과 훨씬 더 비슷해졌습니다:

코드 생성(Generate code)
↓

...

그리고 솔직히 이것은 AI 이전의 엔지니어링 방식에 훨씬 더 가깝게 느껴집니다.

AI 이전에는 우리는 다음과 같이 했습니다:

• 공식 문서(documentation) 읽기 📚
• GitHub 이슈(issues) 검색하기
• Stack Overflow 토론 찾아보기
• 엔지니어링 블로그 읽기
• 서로 다른 접근 방식 비교하기

지금의 차이점은 무엇일까요?

AI는 훨씬 더 빠르게 시작점(starting point)을 제공합니다.

저는 다음과 같이 물을 수 있습니다:

"트레이드오프(tradeoffs, 절충안)는 무엇인가요?"

그다음:

"이 접근 방식이 실패하는 사례를 하나 들어주세요."

그다음:

"만약 엔지니어가 한 명에서 다섯 명으로 늘어난다면 어떻게 될까요?"

그러면 갑자기, 몇 시간의 조사가 필요했을 결정이 훨씬 더 빠른 대화로 변합니다.

AI가 아키텍처 결정(architectural decisions)을 소유해서는 안 됩니다 🚫🤖

제가 주의하게 된 한 가지는 AI가 솔루션을 "추천"하도록 내버려 두는 것입니다.

대규모 언어 모델(Large language models)은 매우 설득력이 있습니다.

때로는 심지어 이렇게 말하기도 합니다:

"개인적으로는 옵션 A가 더 타당하다고 생각합니다."

그러면 가끔 저도 모르게 이런 생각을 하게 됩니다:

"음... 네 말이 맞을지도 모르겠네." 👀

하지만 자신감(confidence)이 정확성(correctness)과 같은 것은 아닙니다.

그래서 다음과 같이 묻는 대신:

"어떤 것을 선택해야 할까요?"

저는 이렇게 묻습니다:

• 트레이드오프 (tradeoffs)는 무엇인가?
• 각 접근 방식이 실패하는 경우는 언제인가?
• 나중에 어떤 문제들이 발생하는가?
• 어떤 상황이 이 결정을 후회하게 만들 것인가?

목표는 AI가 나를 대신해 결정을 내리는 것이 아닙니다.

목표는 AI가 내가 더 나은 결정을 내릴 수 있도록 돕는 것입니다.

이 프로젝트는 진정한 실험입니다 🧪

내가 만들고 있는 애플리케이션은 단순한 사이드 프로젝트가 아닙니다.

이것은 문맥 (context)이 불완전할 때 AI가 어떻게 행동하는지를 이해하기 위한 실험이 되었습니다.

AI가 나를 놀라게 할 때마다, 나는 즉시 이렇게 생각하지 않습니다:

"AI가 틀렸어."

대신 나는 이렇게 묻습니다:

"내가 충분한 정보를 주지 않았기 때문에 AI가 어떤 가정을 한 것일까?" 🤔

그러한 순간들이 실제로 이 프로젝트에서 가장 가치 있는 부분이 되었습니다.

결여된 모든 문맥 (context) 조각들이 내가 추가할 수 있는 또 다른 지침 (instruction)이 되기 때문입니다.

모든 리뷰는 또 다른 교훈이 됩니다.

모든 결정은 내가 원하는 AI 팀원이 어떻게 작동하기를 바라는지에 대한 또 다른 정보가 됩니다.

그리고 서서히...

AI는 자동 완성 (autocomplete) 도구처럼 느껴지기보다,

우리 엔지니어링 팀이 어떻게 일하는지를 이해하는 팀원처럼 느껴지기 시작합니다. 🤝

파트 3에서는 내가 발견한 또 다른 흥미로운 패턴을 탐구해보고자 합니다. 바로 프롬프트 (prompt)를 일회성 요청으로 취급하는 것을 멈추고, 재사용 가능한 엔지니어링 문맥 (engineering context)을 구축하기 시작할 때 AI가 어떻게 변화하는지에 대한 내용입니다.