소프트웨어 개발자: 중복인가 회복력인가?

Source: Dev.to

전통적인 워크플로우 (AI 이전)

1. 비즈니스 문제 분석 – 문서를 읽고, 명확한 질문을 하며, 제품 매니저가 이미 일부 분석을 수행했더라도 기본적인 이해를 구축합니다.
2. 구현 계획 수립 – 팀과 접근 방식을 논의하면서 문제에 대한 이해도를 깊게 합니다.
3. 기존 코드베이스 검토 – 확립된 패턴과 재사용 가능한 컴포넌트를 파악하여 코드에 대한 친숙함을 강화합니다.
4. 디자인 패턴 조사 및 평가 – 기존에 맞는 패턴이 없을 경우, 유사한 상황을 찾아 가장 적합한 설계 솔루션을 선택합니다.
5. 기능 구현 – 코딩하면서 지속적으로 개선점과 대안 접근법을 고민해 문제와 해결책에 대한 지식을 늘립니다.

이 단계들을 마치면 팀 토론 중에 구현 세부 사항을 기억해 낼 수 있었고, 버그가 발생했을 때 코드를 바로 살펴보지 않아도 원인을 추론해 내는 경우가 많았습니다. 종종 간과된 엣지 케이스를 발견하기도 했습니다.

이 과정은 학습과 지식 유지에 도움이 되었으며, 대부분의 작업을 스스로 수행하게 만들었습니다. 코드를 작성하는 것이 단순히 코드를 검토하는 것보다 가장 즐거운 부분이었습니다.

AI‑지원 코딩의 영향

오늘날 내 시간의 상당 부분은 AI 도구가 생성한 코드를 검토하는 데 사용됩니다. 검토도 가치가 있지만, 코드를 직접 작성하는 것과는 다릅니다. AI는 대안을 제시할 수 있지만, 비개발자도 AI에게 옵션을 물어보고 자신의 이해를 바탕으로 최선의 선택을 할 수 있습니다.

AI는 아직 통합 작업, 예를 들어 하드웨어 장치와 상호 작용하거나 여러 시스템을 동시에 조정하는 일에서는 어려움을 겪습니다. 이러한 “빠진 다리”는 범위가 제한적이며, 새로운 시스템‑레벨 문제에 도전하는 소수의 엔지니어만이 덜 중복된 느낌을 받을 수 있습니다.

결론

현재 AI 지원 수준을 고려할 때, 많은 개발 역할이 일상적인 작업에서 중복된 느낌을 받습니다. 앞으로의 방향은 기계적인 개발을 넘어 아직 존재하지 않는 시스템을 설계하고 구축하는 진정한 엔지니어링으로 나아가는 것입니다. 이는 AI가 아직 따라올 수 없는 더 깊은 수준의 시스템 사고와 창의성을 요구합니다.