AI 코딩이 개발자를 더 빠르게 만들지만, 우리는 더 나쁜 엔지니어가 되고 있는가?

AI는 몇 초 만에 React 컴포넌트를 생성하고, 몇 분 만에 API 엔드포인트를 작성하며, 우리가 문서로 읽는 것보다 빠르게 생소한 코드베이스를 설명할 수 있습니다.

정말 놀랍게 들립니다.

그리고 솔직히 말해서, 정말 그렇습니다.

하지만 제가 계속 되돌아오는 질문이 하나 있습니다:

우리가 더 나은 소프트웨어 엔지니어가 되고 있는 것일까요, 아니면 단순히 완전히 이해하지 못하는 코드를 생산하는 속도가 빨라지고 있는 것일까요?

저는 이것이 AI 시대에 개발자들이 스스로에게 던져야 할 가장 중요한 질문 중 하나라고 생각합니다.

1. 코드를 작성하는 것이 더 이상 가장 어려운 부분이 아니다

수년 동안, 개발자가 된다는 것은 프로그래밍 언어를 배우고, 알고리즘을 이해하고, 오류를 디버깅하며, 무언가가 작동하지 않는 이유를 알아내기 위해 몇 시간을 보내는 것을 의미했습니다.

오늘날 AI 도구들은 이 모든 작업에 거의 도움을 줄 수 있습니다.

REST API 엔드포인트가 필요합니까? AI가 하나를 생성할 수 있습니다.

로딩 상태와 오류 처리가 포함된 React 컴포넌트가 필요합니까? AI가 초안을 작성할 수 있습니다.

생소한 라이브러리를 이해해야 합니까? AI가 기본 개념을 설명하고 예시를 보여줄 수 있습니다.

이것은 엄청난 생산성 향상입니다.

하지만 코드를 생성하는 것과 코드를 이해하는 것 사이에는 차이가 있습니다.

다음 예를 고려해 보세요:

AI 어시스턴트에게 인증 시스템을 만들도록 요청합니다. AI는 라우트, 미들웨어, 토큰 처리 및 데이터베이스 쿼리를 생성합니다. 모든 것이 깨끗해 보이고 초기 테스트 동안 애플리케이션은 작동합니다.

하지만 토큰이 만료될 때 무슨 일이 일어나는지 이해하고 있습니까?

권한이 어떻게 적용되는지 설명할 수 있습니까?

두 요청이 동시에 같은 레코드를 업데이트하면 어떻게 되나요?

외부 서비스가 프로세스 중간에 실패하면 어떻게 되나요?

만약 이러한 질문들에 답할 수 없다면, 당신은 자신이 유지 관리 책임을 지는 시스템을 완전히 이해하지 못한 채 작동하는 소프트웨어를 가질 수도 있습니다.

그리고 바로 그곳에서 진짜 문제가 시작됩니다.

2. 작동하는 코드의 위험한 안락함

AI가 생성한 코드가 가장 매력적인 점 중 하나는 얼마나 설득력 있게 보일 수 있느냐입니다.

익숙한 패턴과 의미 있는 변수 이름, 전문적으로 보이는 구조를 사용할 수도 있습니다.

하지만 겉보기에 올바른 코드가 반드시 정확하다는 것을 의미하지는 않습니다.

AI가 생성한 코드에는 다음 내용이 포함될 수 있습니다:

• 비즈니스 요구사항에 대한 잘못된 가정.
• 엣지 케이스(edge-case) 처리 누락.
• 보안 취약점.
• 불필요한 의존성 및 추상화.
• 비효율적인 데이터베이스 쿼리.
• 실제 문제를 숨기는 오류 처리.
• 개발 환경에서는 작동하지만 운영(production) 환경에서 실패하는 로직.

위험은 AI가 항상 나쁜 코드를 생성한다는 것이 아닙니다. 종종 유용한 코드를 생성합니다.

진짜 위험은 개발자들이 자신이 제대로 평가하지 않은 코드를 편하게 받아들이게 될 수 있다는 점입니다.

AI가 생성한 500줄의 변경 사항이 포함된 풀 리퀘스트(pull request)를 검토한다고 상상해 보세요. 애플리케이션은 성공적으로 빌드되고, 행복 경로(happy path)는 작동하며, 테스트도 통과합니다.

당신은 이 구현이 미묘한 권한 부여 버그(authorization bug)를 유발하는지 알 수 있을까요?

데이터셋이 커질 때 데이터베이스 쿼리가 비용이 많이 들게 되는 것을 알아차릴 수 있을까요?

제안된 아키텍처가 미래의 변경을 불필요하게 어렵게 만든다는 것을 인식할 수 있을까요?

이것들은 코드 생성 문제가 아니라 엔지니어링 문제입니다.

그리고 여전히 판단력이 필요합니다.

3. 디버깅이야말로 진정한 이해를 가시화하는 곳

소프트웨어 개발에 대해 흥미로운 점이 있습니다. 코드를 작성하는 것과 코드를 디버깅하는 것은 서로 다른 종류의 사고방식을 요구한다는 것입니다.

새로운 기능을 생성할 때는 종종 받아들여질 수 있는 여러 해결책이 존재합니다.

하지만 운영상의 문제(production issue)를 디버깅할 때는 시스템이 실제로 무엇을 하고 있는지, 왜 그렇게 하는지, 그리고 근본적인 원인을 수정하면서 또 다른 문제를 만들지 않을 변경 사항이 무엇인지 이해해야 합니다.

AI는 로그를 조사하고, 가능한 원인을 제안하며, 수정 방안을 제시하는 데 도움을 줄 수 있습니다.

하지만 시스템의 근본적인 이해가 없다면, 어떤 설명이 정확한지 알지 못한 채 제안된 수정 사항들을 계속 적용하게 될 수도 있습니다.

예를 들어, 트래픽이 증가할 때 느려지는 API를 상상해 보세요.

AI 어시스턴트는 캐싱(caching)을 제안하거나, 데이터베이스 인덱스를 추가하고, 쿼리를 최적화하거나, 작업을 백그라운드 작업으로 옮기는 등의 방법을 제시할 수 있습니다.

이 모든 것들은 적절한 상황에서는 합리적인 해결책일 수 있습니다.

하지만 어떤 것이 적절할까요?

증거가 필요합니다.

쿼리 성능을 검사하고, 요청 흐름을 이해하며, 응답 시간을 측정하고, 실제 병목 지점을 식별해야 합니다.

문제를 이해하지 못한 채 캐싱을 추가하면 오래된 데이터(stale data)를 도입할 수 있습니다. 워크로드를 검토하지 않고 인덱스를 추가하는 것은 주요 문제를 해결하지 못하면서 스토리지 및 쓰기 비용만 증가시킬 수 있습니다.

AI는 가능한 해결책들을 제안할 수 있지만, 엔지니어링이란 시스템이 실제로 어떤 해결책을 필요로 하는지 알아내는 것을 의미합니다.

4. 주니어 개발자가 직면하는 다른 학습 과제

주니어 개발자들은 항상 무언가를 만들고, 실수를 하고, 문서를 읽고, 자신의 코드를 디버깅하면서 배워왔습니다.

AI는 그 학습 과정을 변화시키고 있습니다.

초보자도 이제 모든 부분을 이해하지 못한 채 놀라울 정도로 정교한 애플리케이션을 구축할 수 있게 되었습니다.

이것은 기회이자 위험입니다.

기회는 명확합니다. 사람들은 즉각적인 도움을 받아 실험하고, 프로젝트를 만들고, 개념을 배울 수 있습니다.

위험은 한때 이해의 격차를 드러냈던 고군분투가 사라질 수 있다는 것입니다.

예를 들어 React를 배우고 있다고 가정해 봅시다.

훅(hooks), 상태 관리(state management), API 호출을 사용하여 컴포넌트를 만들도록 AI에게 요청합니다. AI는 완전한 구현체를 생성합니다.

실행해 보고, 작동하는 것을 확인했습니다.

하지만 이 컴포넌트가 왜 다시 렌더링(re-render)되는지 설명할 수 있나요?

이펙트 의존성(effect dependencies)이 어떻게 작동하는지 이해하나요?

오래된 클로저(stale closure)나 불필요한 네트워크 요청을 식별할 수 있나요?

요구사항이 변경될 때 컴포넌트를 수정할 수 있나요?

만약 그렇지 않다면, 개념을 숙달하지 못한 채 작업을 완료했을 수도 있습니다.

이것은 초보자들이 AI를 피해야 한다는 의미는 아닙니다.

AI가 이해를 대체하는 것이 아니라, 이해를 강화하는 방식으로 사용해야 한다는 의미입니다.

유용한 습관은 생성된 코드를 수락하기 전에 자신의 말로 설명하는 것입니다. 중요한 부분을 설명할 수 없다면, 그것을 조사해야 합니다.

이러한 추가 단계는 생성된 솔루션을 학습 경험으로 바꿀 수 있습니다.

5. 시니어 개발자는 다른 책임을 갖는다

경험 많은 개발자들도 이러한 문제에서 자유롭지 않습니다.

사실, AI는 시니어 엔지니어들에게 또 다른 과제를 만들 수 있습니다. 바로 팀이 평가할 수 있는 능력을 초과하는 속도로 생성된 코드를 검토하고 유지 관리하는 것입니다.

이전에 매일 5개의 잘 검토된 변경 사항을 제공하던 팀을 상상해 보세요. AI의 도움으로 그 팀은 15개의 변경 사항을 생성할 수 있습니다.

듣기에는 승리처럼 들립니다.

하지만 만약 팀이 철저히 검토할 수 있는 양이 6개에 불과하다면 어떻게 될까요?

추가적인 결과물은 아무도 완전히 검사하지 못한 코드의 증가하는 백로그를 만들 수 있습니다.

더 많은 코드는 또한 더 많은 잠재적 유지보수 작업, 구성 요소 간의 상호 작용 증가, 그리고 회귀(regression)할 기회를 의미합니다.

목표는 생성되는 코드의 양을 최대화하는 것이어서는 안 됩니다.

정확하고, 유지 관리 가능하며, 유용한 소프트웨어의 전달량을 최대화하는 것이어야 합니다.

시니어 엔지니어의 가치는 타이핑 속도에 국한된 적이 없습니다. 여기에는 아키텍처, 우선순위 지정, 위험 평가, 코드 검토, 그리고 요구 사항이 불분명할 때 결정을 내리는 것이 포함됩니다.

AI는 이러한 책임을 줄이는 것이 아니라 더 중요하게 만듭니다.

6. 최고의 개발자는 AI를 무비판적으로 신뢰하는 대신 함께 일하는 법을 배울 것이다

저는 개발자들이 전통적인 프로그래밍 기술을 보존하기 위해 AI 사용을 중단해야 한다고 생각하지 않습니다.

그것은 마치 개발자들이 한때 모든 것을 수동으로 검사해야 했기 때문에 디버거를 사용하는 것을 거부하는 것과 같을 것입니다.

도구는 진화합니다. 좋은 엔지니어들은 적응합니다.

진짜 질문은 우리가 이 도구들을 어떻게 사용하느냐입니다.

AI 지원 개발을 더욱 효과적으로 만들 수 있는 여섯 가지 습관이 있습니다.

습관 1: 코드를 요청하기 전에 문제를 이해하라

AI 어시스턴트에게 프롬프트를 보내기 전에, 예상되는 동작, 제약 조건(constraints), 그리고 실패 사례를 정의해야 합니다.

모호한 요구사항은 그럴듯해 보이지만 잘못된 문제를 해결하는 솔루션을 만들어냅니다.

습관 2: 구현 방식뿐만 아니라 설명을 요청하세요

단순히 “이 함수를 작성해 줘”라고만 묻지 마세요.

특정 접근 방식이 왜 합리적인지, 어떤 대안들이 존재하는지, 그리고 고려해야 할 트레이드오프(trade-off)는 무엇인지 물어보세요.

그런 다음 중요한 주장을 코드, 테스트, 관련 문서를 통해 검증하세요.

습관 3: 마치 다른 사람이 작성한 것처럼 코드를 검토하세요

누군가—혹은 무언가가—작성했기 때문에요.

가정(assumption), 보안(security), 오류 처리(error handling), 가독성(readability), 그리고 기존 아키텍처와의 호환성을 확인하세요.

AI가 자신감 있게 생성했다고 해서 변경 사항을 승인해서는 안 됩니다.

습관 4: 코드가 실행되는지 여부뿐만 아니라 동작을 테스트하세요

엣지 케이스(edge case), 유효하지 않은 입력, 권한 경계(permission boundary), 실패 시나리오(failure scenario), 그리고 기존 기능과의 상호작용을 테스트하세요.

성공적인 빌드가 그 기능이 정확하다는 증거가 아닙니다.

습관 5: 제안된 수정 사항을 받아들이기 전에 디버깅하세요

무언가가 실패하면, 근거를 조사하세요.

로그(log), 브레이크포인트(breakpoint), 테스트 결과, 측정값을 사용하여 원인을 이해하세요. AI가 가설을 탐색하는 데 도움을 주게 하되, 그럴듯한 설명과 검증된 설명을 혼동하지 마세요.

습관 6: 기본 지식을 계속 학습하세요

자료 구조(Data structure), 네트워킹(networking), 데이터베이스(database), 운영체제(operating system), 보안(security), 그리고 소프트웨어 아키텍처(software architecture)는 여전히 중요합니다.

모든 API를 암기하거나 모든 줄을 수동으로 작성할 필요는 없습니다. 하지만 잘못된 가정을 인식하고 좋은 기술적 결정을 내릴 만큼의 이해가 필요합니다.

7. 간단한 테스트: AI가 구축한 것을 유지보수할 수 있는가?

여기는 자신만의 AI 지원 워크플로우를 평가하는 실용적인 방법입니다.

AI가 기능을 생성한 후, 스스로에게 물어보세요:

• 요청(request)부터 응답(response)까지 기능이 어떻게 작동하는지 설명할 수 있는가?
• 주요 실패 사례를 식별할 수 있는가?
• 왜 이 구현 방식이 대안적인 방법보다 선택되었는지 설명할 수 있는가?
• 가장 중요한 동작에 대해 의미 있는 테스트 코드를 작성할 수 있는가?
• 요구사항이 변경될 때 안전하게 수정할 수 있는가?
• 운영 환경(production)에서 실패했을 경우 무엇을 조사해야 하는지 식별할 수 있는가?

모든 줄을 통째로 외울 필요는 없다.

하지만 결과에 대한 책임을 질 만큼은 충분히 알아야 한다.

이 질문들에 답할 수 있다면, AI는 생산성(productivity)과 함께 역량(capability)을 구축하도록 돕고 있는 것이다.

만약 일관되게 답변할 수 없다면, 사용 방식을 바꿀 때가 되었을지도 모른다.

8. 어쩌면 우리는 개발자 생산성을 재정의해야 할지도 모른다

오랫동안 개발자는 얼마나 빨리 기능을 제공하는지, 얼마나 많은 작업을 완료하는지, 그리고 얼마나 많은 코드를 생성하는지에 따라 평가받아 왔다.

AI는 이러한 측정 기준들을 그 자체만으로는 더욱 의미 없게 만든다.

한 명의 개발자가 1,000줄의 코드를 수동으로 작성하고 다른 한 명이 AI를 이용해 3,000줄을 생성했을 때, 후자의 개발자가 반드시 세 배의 가치를 창출했다고 볼 수는 없다.

중요한 것은 소프트웨어가 올바른 문제를 해결하는지, 신뢰성 있게 작동하는지, 유지보수가 용이한지, 그리고 요구사항 변경에 따라 진화할 수 있는지 여부이다.

AI 지원 워크플로우(workflow)에서는, 아무도 검증하지 않은 가정으로 가득 찬 대규모 구현체보다는 작고, 잘 테스트되었으며, 이해하기 쉬운 솔루션을 제공하는 개발자가 더 바람직하다.

AI의 최고의 활용법은 단순히 코드를 더 많이 생성하는 것이 아니다.

반복적인 작업에 쓰는 시간을 줄이고 인간의 판단(human judgment)이 필요한 결정에 더 많은 시간을 할애하도록 돕는 것이다.

최종 생각 (Final Thoughts)

AI 코딩 도구 자체가 개발자를 나쁜 엔지니어로 만들지는 않는다.

진짜 위험은 편리함이 이해를 대체하도록 허용하는 것이다.

우리는 분명히 AI를 사용하여 개발 속도를 높이고, 생소한 기술을 탐색하며, 반복적인 작업을 자동화하고, 그렇지 않으면 훨씬 더 오래 걸릴 무언가를 구축해야 한다.

하지만 우리는 또한 질문을 던지고, 가정을 검토하며, 실패를 조사하고, 우리가 구축하는 시스템이 실제로 어떻게 작동하는지 배우는 노력을 계속해야 합니다.

미래는 아마도 모든 코드를 수동으로 작성하는 개발자나 모든 작업을 AI에 위임하는 개발자에게만 속하지 않을 것입니다.

오히려 AI의 속도를 신뢰할 수 있는 소프트웨어를 구축하는 데 필요한 판단력과 결합하는 방법을 아는 개발자들에게 유리할 것입니다.

왜냐하면 코드를 생성하는 것이 점점 쉬워지고 있기 때문입니다.

어떤 코드가 존재해야 하는지, 그것이 올바른지, 그리고 어떻게 유지보수해야 하는지를 아는 것이 여전히 엔지니어링이기 때문입니다.

논의해 봅시다

저는 다른 개발자들이 이 변화를 어떻게 경험하고 있는지 궁금합니다.

AI 코딩 도구가 개발자가 더 빨리 학습하도록 돕거나, 아니면 기본기를 건너뛰도록 장려한다고 생각하십니까?

그리고 좀 더 실질적인 질문이 있습니다:

AI가 특정 기능을 생성해 줄 때, 그것을 배포할 만큼 충분히 잘 이해했는지 어떻게 결정하시나요?

매일 AI와 함께 작업하는 개발자들의 실제 경험담을 듣고 싶습니다.

#ai #프로그래밍 #웹개발 #논의