AI가 코딩을 쉽게 만든다고요? 오히려 더 엄격해져야 합니다

요즘 개발자 커뮤니티에서 가장 자주 들리는 말이 있습니다. “AI가 코딩을 대신해주니 이제 엔지니어링이 쉬워졌다"는 이야기인데요. 그런데 이 흐름에 정면으로 반기를 드는 사람이 있습니다. 관측가능성(Observability) 분야의 권위자이자 Honeycomb의 공동창업자인 Charity Majors입니다. 그의 주장은 간단합니다. “AI는 엔지니어링 규율을 덜 요구하는 게 아니라, 더 많이 요구한다.” 왜 이런 반직관적인 이야기가 나오는지 한번 짚어보겠습니다.

참고: 이 주제는 최근 30일간 커뮤니티 데이터가 충분히 모이지 않았습니다. 그래서 이 글은 실시간 반응보다는 Charity Majors가 꾸준히 펼쳐온 논지와 업계의 일반적인 흐름을 바탕으로 정리했다는 점을 먼저 밝혀둡니다.

코드를 짜는 일은 원래 엔지니어링의 일부일 뿐이었습니다

많은 사람들이 착각하는 지점이 여기 있습니다. 소프트웨어 엔지니어링을 “코드를 작성하는 일"과 동일하게 여기는 건데요. 실제로 코드를 타이핑하는 시간은 엔지니어 업무 전체에서 작은 부분에 불과합니다.

나머지 대부분은 어디에 쓰일까요. 요구사항을 이해하고, 시스템이 어떻게 망가질지 예측하고, 장애가 났을 때 원인을 추적하고, 운영 환경에서 코드가 실제로 어떻게 동작하는지 확인하는 일입니다. Charity Majors가 늘 강조하는 표현을 빌리면, “소프트웨어의 진짜 비용은 작성이 아니라 유지보수”입니다.

AI는 이 중에서 가장 쉬운 부분, 즉 코드를 생성하는 단계를 자동화합니다. 문제는 코드 생성이 빨라질수록 그 코드를 검증하고, 이해하고, 운영하는 부담이 함께 줄어드는 게 아니라 오히려 늘어난다는 점입니다.

더 많은 코드는 더 많은 책임을 의미합니다

생각해보면 단순합니다. 예전에는 한 명의 개발자가 하루에 작성할 수 있는 코드 양에 자연스러운 한계가 있었는데요. AI 코딩 도구는 그 한계를 단숨에 무너뜨립니다. 몇 시간이면 수천 줄짜리 기능이 뚝딱 만들어집니다.

그런데 여기서 핵심 질문이 생깁니다. 그 코드를 이해하는 속도도 같이 빨라졌을까요. 아닙니다. 코드를 읽고, 이게 왜 이렇게 동작하는지 파악하는 인간의 속도는 거의 그대로입니다.

결과적으로 우리는 “내가 직접 쓰지 않았고, 깊이 이해하지도 못한 코드"를 운영 환경에 점점 더 많이 밀어넣게 됩니다. 장애가 터졌을 때 “이 부분은 AI가 짠 거라서 제가 잘 모릅니다"라는 말이 통할까요. 사용자 입장에서는 누가 짰든 알 바 아닙니다. 책임은 여전히 엔지니어에게 있습니다.

진짜 병목은 ‘작성’이 아니라 ‘이해’로 옮겨갔습니다

Charity Majors의 통찰 중 가장 날카로운 부분이 바로 이 지점입니다. AI가 코드 작성이라는 병목을 풀어버리면서, 이제 진짜 병목이 코드를 이해하고 신뢰하는 능력으로 이동했다는 것입니다.

이 말은 곧 그동안 “있으면 좋은 것” 정도로 여겨지던 엔지니어링 규율들이 갑자기 “없으면 안 되는 것"이 됐다는 뜻입니다. 예를 들면 이런 것들입니다.

• 코드가 운영 환경에서 실제로 어떻게 동작하는지 들여다보는 관측가능성
• 작은 단위로 자주 배포하고, 문제가 생기면 빠르게 되돌리는 능력
• 코드 리뷰와 자동화된 테스트로 신뢰의 안전망을 까는 일
• 시스템이 망가지는 방식을 예측하고 대비하는 설계

AI 이전에는 이런 규율이 부족해도 어떻게든 굴러갔습니다. 사람이 직접 짠 코드라 그나마 머릿속에 그림이 있었으니까요. 하지만 이해하지 못한 코드가 쏟아지는 시대에는 이 안전망이 없으면 그대로 추락합니다.

시니어 엔지니어의 가치는 오히려 올라갑니다

흥미로운 역설이 하나 더 있습니다. “AI가 주니어 개발자를 대체한다"는 이야기가 많은데요. Majors의 논리를 따라가면 그 반대의 결론에 가까워집니다.

AI가 생성한 코드를 보고 “이건 위험하다”, “여기서 이렇게 망가질 수 있다”, “이 부분은 운영에서 문제가 된다"고 판단하는 능력은 결국 경험에서 나오는 직관입니다. 코드를 그럴듯하게 짜는 일이 흔해질수록, 그 코드를 의심하고 검증하는 사람의 가치가 올라갑니다.

다만 여기에 우려도 있습니다. 주니어가 AI에 의존해 코드를 양산하기만 하면, 정작 시니어로 성장하는 데 필요한 “직접 헤매며 배우는 경험"을 놓칠 수 있다는 점입니다. 판단력은 코드를 짜본 사람에게서 나오는데, 그 과정을 AI가 건너뛰게 해버리면 다음 세대 시니어는 어디서 길러질까요. 이건 업계가 함께 고민해야 할 숙제입니다.

마무리

정리하면 이렇습니다. AI는 코드 작성을 쉽게 만들었지만, 그 코드를 책임지는 일까지 쉽게 만들지는 못했습니다. 오히려 이해하지 못한 코드가 늘어나면서 관측가능성, 테스트, 빠른 배포와 롤백 같은 엔지니어링 규율의 중요성은 더 커졌습니다. 도구가 강력해질수록 그 도구를 다루는 사람의 기준은 더 높아져야 한다는 이야기인데요.

여러분의 팀은 어떤가요. AI로 코드를 더 빨리 찍어내는 데만 집중하고 있나요, 아니면 그렇게 늘어난 코드를 감당할 안전망도 함께 두텁게 만들고 있나요. 속도가 빨라질수록 한 번쯤 멈춰서 던져볼 질문입니다.