𝗠𝗼𝘀𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗨𝘀𝗲 𝗔𝗜. 𝗙𝗲𝘄 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝗪𝗶𝘁𝗵 𝗜𝘁. 대부분의 엔지니어는 AI를 사용하지만, AI로 엔지니어링을 하는 사람은 드뭅니다.

이제 대부분의 소프트웨어 엔지니어는 AI를 사용합니다.

디버깅, 테스트 작성, 또는 SQL 쿼리 생성 등에 AI를 활용하죠. AI를 사용하는 것은 쉽습니다. 하지만 AI를 활용해 엔지니어링을 하는 것은 훨씬 더 어렵습니다.

실제 저장소(repository) 작업을 하며 AI를 사용하던 중 한 가지 문제를 발견했습니다. 잘못된 변경 사항은 단순히 나쁜 결과물을 내놓는 데 그치지 않습니다. 구조를 망가뜨리고, 테스트를 깨뜨리며, 향후 유지보수성까지 해칩니다.

코드 생성 부분은 쉽습니다. 광범위한 프롬프트를 입력하면 코드가 빠르게 생성됩니다. 언뜻 보기에는 깔끔해 보이죠.

유용한 결과는 지루한 작업을 먼저 수행할 때만 얻을 수 있습니다. 반드시 다음을 수행해야 합니다:

핵심 역량은 프롬프팅이 아닙니다. 핵심 역량은 업무의 형태를 잡아가는(shaping) 능력입니다.

AI는 출력 속도를 높여주지만, 검증의 품질을 높여주지는 않습니다. 코드가 더 빠르게 생성될수록, 불분명한 요구사항은 더 큰 비용을 초래합니다. 부실한 리뷰는 더 위험해집니다.

AI는 기존의 엔지니어링 루프를 증폭시킵니다.

요구사항이 불분명해도 AI는 일단 무언가를 만들어냅니다. 아키텍처가 엉망이면 AI는 그 엉망인 상태를 그대로 복제합니다. 결과물을 제대로 리뷰할 수 없다면, 속도는 곧 리스크가 됩니다.

문제는 AI가 엔지니어를 대체하느냐가 아닙니다. 문제는 코드가 흔해진 세상에서 엔지니어링의 어떤 부분이 더 중요해지느냐 하는 것입니다.

제 대답은 이렇습니다: 구현하기 전에 명확하게 생각하는 것.

AI는 오래된 조언들을 더욱 중요하게 만듭니다:

엔지니어링은 코드를 작성하는 것에서 올바른 변경 사항을 설계하는(shaping) 것으로 변화하고 있습니다.

AI를 구조화가 필요한 협업자로 대하십시오. 좋은 루프는 다음과 같습니다: 요구사항 → 공백(Gaps) → 계획 → 작은 변경 → 리뷰 → 검증 → 기록.

진정한 엔지니어링은 코드를 생산하는 것이 아니라, 신뢰할 수 있는 변경을 만들어내는 것입니다.

강점은 가장 많은 코드를 생성하는 데 있지 않습니다. 무엇을 만들어야 하는지, 그리고 그것이 시스템에 어떻게 맞물리는지를 아는 데 있습니다.

승리하는 엔지니어는 프롬프트를 가장 빨리 쓰는 사람이 아닙니다. 도구를 중심으로 더 나은 워크플로우를 설계하는 사람입니다.

Source: https://dev.to/jeelvankhede/most-engineers-use-ai-few-engineer-with-it-3pd

Optional learning community: https://t.me/GyaanSetuAi