AI 시대에 개발자가 여전히 프로그래밍을 배워야 하는지에 대해 지난 글을 썼을 때, 저는 사람들이 구문(syntax), 프로그래밍 언어, 그리고 일자리에 대해 토론할 것이라고 예상했습니다.

대신, 댓글들은 대화를 훨씬 더 흥미로운 방향으로 이끌었습니다.

어떤 분이 제가 계속해서 생각하게 만드는 지점을 짚어주었습니다.

우리는 수십 년 동안 코드를 검토하기 위한 프로세스를 구축해 왔습니다.

우리에겐 코드 리뷰 (code reviews)가 있습니다.

QA (Quality Assurance)가 있습니다.

단위 테스트 (unit tests)가 있습니다.

통합 테스트 (integration tests)가 있습니다.

보안 검토 (security reviews)가 있습니다.

하지만 AI는 우리가 거의 갖추지 못한 검토 프로세스를 드러냈습니다.

우리가 올바른 문제를 해결하고 있는지 누가 검토할까요?

이 질문이 제 머릿속을 떠나지 않는 이유는, 이것이 AI가 소프트웨어 엔지니어링 (software engineering)에서 만들어내고 있는 가장 큰 변화를 가리키고 있다고 생각하기 때문입니다.

우리는 코드를 검토하는 방법을 알고 있습니다

하나의 기능 (feature)이 막 완료되었다고 상상해 보십시오.

풀 리퀘스트 (pull request)가 열립니다.

코드는 깔끔합니다.

네이밍 (naming)도 좋습니다.

아키텍처 (architecture)도 합리적으로 보입니다.

테스트를 통과합니다.

애플리케이션이 작동합니다.

대부분의 엔지니어링 팀은 이를 성공적인 구현 (implementation)이라고 부를 것입니다.

하지만 우리가 자주 묻는 것을 잊어버리는 또 다른 질문이 있습니다.

애초에 이것이 구축해야 할 올바른 것이었는가?

이것은 코드 리뷰의 문제가 아닙니다.

이것은 사고 (thinking)의 문제입니다.

AI는 구현 비용을 변화시켰습니다

AI 이전에는 기능을 구현하는 데 시간이 걸렸습니다.

보일러플레이트 (boilerplate) 작성.

문서 (documentation) 찾아보기.

구문 오류 (syntax errors) 수정.

리팩터링 (Refactoring).

테스트.

그 마찰 (friction)이 항상 즐거운 것은 아니었지만, 그것은 우리가 생각하도록 강제했습니다.

오늘날 AI는 놀라울 정도로 빠르게 작동하는 구현물을 만들어낼 수 있습니다.

그것은 놀라운 일입니다.

하지만 이는 병목 현상 (bottleneck)이 이동했음을 의미하기도 합니다.

비싼 부분은 더 이상 코드를 작성하는 것이 아닙니다.

비싼 부분은 좋은 결정을 내리는 것입니다.

한때 구현하는 데 2주가 걸렸던 나쁜 아이디어가 이제는 오후 한나절 만에 다듬어진 기능이 될 수 있습니다.

속도는 인상적입니다.

위험 요소는 우리가 이제 잘못된 것을 훨씬 더 빠르게 만들 수 있게 되었다는 점입니다.

좋은 코드라도 여전히 잘못된 문제를 해결할 수 있습니다

이 부분은 많은 개발자가 경험하기 시작한 부분이라고 생각합니다.

AI는 보통 지저분한 코드를 작성해서 실패하는 것이 아닙니다.

AI는 종종 당신이 준 문제를 자신 있게 해결하지만, 정작 당신이 해결했어야 할 문제는 아니라는 이유로 실패합니다.

저는 제품을 만드는 과정에서 이런 일이 발생하는 것을 목격해 왔습니다.

당신은 어떤 기능을 요청합니다.

구현(Implementation)은 기술적으로 정확합니다.

코드는 깔끔합니다.

테스트도 통과합니다.

그러고 나서 실제 사용자가 그것을 사용해 봅니다.

즉시 그들은 아무도 고려하지 않았던 행동을 합니다.

또는 모두가 가정했던 것과는 다르게 기능을 사용합니다.

혹은 원래의 문제가 사실은 해결할 가치가 있는 문제가 아니었음을 드러내기도 합니다.

구현이 실수는 아니었습니다.

가정(Assumptions)이 문제였습니다.

우리는 방향보다 실행을 더 많이 검토합니다

제 이전 글에 달린 한 댓글이 이를 완벽하게 요약했습니다.

우리는 주로 우리가 이미 수용한 결정에 대해 실행(Execution)을 평가하고 있습니다.

그 문장은 AI 보조 개발(AI-assisted development)에 대한 제 생각을 바꾸어 놓았습니다.

우리의 엔지니어링 관행 대부분은 우리가 이미 방향을 결정한 후에 일어납니다.

우리는 다음과 같은 질문을 던집니다:

• 구현이 정확한가?
• 보안상 안전한가?
• 성능(Performant)이 좋은가?
• 유지보수(Maintainable)가 가능한가?

이것들은 중요한 질문들입니다.

하지만 이 질문들은 모두 무언가를 전제하고 있습니다.

원래의 결정이 옳았다는 것을 전제합니다.

어쩌면 우리에게는 새로운 엔지니어링 습관이 필요할지도 모릅니다

저는 코드를 작성하기 전에 다른 무언가를 작성하는 데 더 많은 시간을 써야 한다고 생각하기 시작했습니다.

구현 노트(Implementation notes)가 아닙니다.

아키텍처 다이어그램(Architecture diagrams)도 아닙니다.

바로 가정(Assumptions)입니다.

다음과 같은 질문들 말이죠:

• 우리가 실제로 해결하려는 문제는 무엇인가?
• 우리가 하고 있는 가정은 무엇인가?
• 그 가정을 뒷받침하는 근거는 무엇인가?
• 우리가 받아들이고 있는 트레이드오프(Trade-offs)는 무엇인가?
• 이 결정이 틀렸음을 증명하려면 무엇이 필요한가?

마지막 질문이 제가 가장 좋아하는 질문입니다.

이 결정이 틀렸음을 증명하려면 무엇이 필요한가?

이 질문은 불편합니다. 왜냐하면 단 한 줄의 코드도 작성하기 전에 우리가 틀렸을 수도 있다는 사실을 인정하게 만들기 때문입니다.

하지만 바로 그 점 때문에 가치가 있습니다.

AI는 자신의 숙제를 스스로 검토해서는 안 됩니다

이것은 문서화(Documentation)에 대한 제 생각도 바꾸어 놓았습니다.

저는 아이디어를 정리하는 데 AI를 사용하는 것을 좋아합니다.

저는 문서화 (Documentation)를 개선하는 데 AI를 사용합니다.

저는 명확성 (Clarity)을 높이는 데 AI를 사용합니다.

하지만 저는 무언가를 더 의식하게 되었습니다.

만약 동일한 컨텍스트 (Context)가 아이디어를 생성하고, 아이디어를 설명하며, 아이디어를 검증한다면, 우리는 실제로 다른 관점을 도입한 것이 아닙니다.

우리는 단지 하나의 관점을 더 효율적으로 만들었을 뿐입니다.

좋은 문서화는 우리가 왜 무언가를 선택했는지만을 설명해서는 안 됩니다.

그 결정이 무엇 때문에 실패할 수 있는지도 드러내야 합니다.

그것이 바로 다른 엔지니어가 이의를 제기할 수 있는 부분입니다.

그곳에서 진정한 논의가 시작됩니다.

훌륭한 엔지니어는 실패를 조기에 생각합니다

제가 코딩을 배울 때, 엔지니어링은 주로 무언가를 작동하게 만드는 것이라고 생각했습니다.

소프트웨어를 더 오래 구축해 올수록, 좋은 엔지니어링은 종종 사물이 어떻게 실패하는지를 이해하는 것과 관련이 있다는 점을 더 많이 깨닫게 되었습니다.

결제는 성공했지만 이메일이 발송되지 않는다면 어떻게 될까요?

사용자가 버튼을 두 번 클릭한다면 어떻게 될까요?

두 개의 요청이 동시에 도착한다면 어떻게 될까요?

진행 도중에 네트워크가 사라진다면 어떻게 될까요?

AI는 그러한 상황에 대한 코드를 생성하는 데 도움을 줄 수 있습니다.

하지만 그러한 상황이 존재한다는 것을 인식하는 데에는 여전히 엔지니어링적 판단 (Engineering judgment)이 필요합니다.

어쩌면 이것이 우리의 새로운 강점이 될지도 모릅니다

AI가 계속해서 발전함에 따라, 코드를 작성하는 것은 차별화 요소가 되지 못할 것입니다.

생각하는 것은 아마 그렇지 않을 것입니다.

두드러지는 개발자는 단순히 AI에게 효과적으로 프롬프트 (Prompt)를 줄 수 있는 사람이 아닐 것입니다.

그들은 프롬프트가 작성되기도 전에 지속적으로 더 나은 질문을 던지는 사람들이 될 것입니다.

왜냐하면 일단 AI를 잘못된 방향으로 안내하면, AI는 그곳에 매우 빠르게 도달하는 데 탁월하기 때문입니다.

마지막 생각

저는 AI가 소프트웨어 아키텍트 (Software architects)를 대체한다고 생각하지 않습니다.

저는 AI가 아키텍처를 더 중요하게 만들고 있다고 생각합니다.

상자와 화살표의 의미에서의 아키텍처가 아닙니다.

구현 (Implementation)이 시작되기 전에 좋은 결정을 내리는 의미에서의 아키텍처입니다.

우리는 코드를 리뷰하는 데 매우 능숙해졌습니다.

어쩌면 소프트웨어 엔지니어링에 다음에 필요한 규율은 코드 이전에 따르는 사고 과정을 리뷰하는 것일지도 모릅니다.

왜냐하면 AI가 구현(implementation) 비용을 저렴하게 만들었다면, 판단력(judgment)은 우리가 가진 가장 가치 있는 기술 중 하나가 되었기 때문입니다.

공개 사항(Disclosure): 저는 아이디어를 정리하고 명확성을 높이기 위해 AI를 글쓰기 파트너로 사용합니다. 여기에 표현된 의견, 경험 및 기술적 결정은 저의 개인적인 견해입니다.