나는 오랜 시간 동안 소프트웨어 엔지니어를 인터뷰하는 일에 많은 시간을 할애했다. 이는 분명히 어려운 작업이며, 마법 같은 해결책이 있다고 주장하지는 않는다. 하지만 이를 통해 효과적인 소프트웨어 엔지니어가 실제로 무엇을 하는지 깊이 생각해 볼 기회를 얻었다.
숙련된 엔지니어의 작업 과정을 관찰하면, 다음과 같은 단계를 반복적으로 수행하는 것을 볼 수 있다:
이 과정을 수행하는 방법은 다양하지만, 효과적인 엔지니어의 핵심 능력은 명확한 멘탈 모델을 구축하고 유지하는 데 있다.
공정하게 말하자면, LLM은 코드 작성에 능숙하다. 또한 문제를 파악하고 수정할 때 코드를 업데이트하는 데도 꽤 능하다. 실제 소프트웨어 엔지니어가 하는 모든 일을 할 수 있다: 코드를 읽고, 테스트를 작성하고 실행하며, 로깅을 추가하고, (아마도) 디버거를 사용한다.
하지만 명확한 멘탈 모델을 유지하는 것은 불가능하다.
LLM은 끝없이 혼란스러워한다: 자신이 작성한 코드가 실제로 작동한다고 가정한다; 테스트가 실패하면 코드를 고칠지 테스트를 고칠지 추측할 뿐이다; 그리고 좌절감이 들면 모든 것을 삭제하고 처음부터 다시 시작한다.
이것은 내가 원하는 것과 정반대다.
소프트웨어 엔지니어는 작업을 진행하면서 테스트한다. 테스트가 실패하면 멘탈 모델을 확인해 코드를 고칠지 테스트를 고칠지, 아니면 결정을 내리기 전에 더 많은 데이터를 수집할지 결정한다. 좌절감을 느끼면 문제를 이야기하며 도움을 요청할 수 있다. 그리고 때로는 모든 것을 삭제하고 다시 시작하기도 하지만, 문제를 더 명확히 이해한 상태에서 그렇게 한다.
모델이 점점 더 강력해지면 이런 상황이 바뀔까? 아마도 그럴 것이다. 하지만 모델을 구축하고 최적화하는 방식 자체가 바뀌어야 할 것이다. 소프트웨어 엔지니어링은 단순히 코드를 생성하는 것 이상의 능력을 가진 모델을 필요로 한다.
사람이 문제에 부딪혔을 때, 전체 맥락을 일시적으로 저장해두고 문제를 해결하는 데 집중한 다음, 다시 원래 문제로 돌아갈 수 있다. 또한 큰 그림에 초점을 맞추고 세부 사항을 일시적으로 잊은 채 필요할 때만 작은 부분에 집중할 수 있다. 우리는 단순히 컨텍스트 윈도우에 더 많은 단어를 추가하지 않는다. 그렇게 하면 미쳐버릴 것이다.
단순히 처리해야 할 컨텍스트가 너무 많다는 문제를 넘어서, 현재의 생성형 모델은 명확한 멘탈 모델을 유지하는 능력에 직접적으로 영향을 미치는 여러 문제를 겪고 있다:
이런 문제들은 극복할 수 없는 것은 아니며, 메모리를 추가해 우리와 비슷한 정신적 트릭을 수행할 수 있도록 하는 연구가 진행 중이다. 하지만 아쉽게도 현재로서는 (특정 복잡도를 넘어서면) 실제로 무슨 일이 일어나는지 이해할 수 없다.
이 모델들은 두 개의 유사한 “멘탈 모델”을 유지하고 차이점을 식별한 다음, 코드를 업데이트할지 요구사항을 업데이트할지 결정할 수 없기 때문에 소프트웨어를 구축할 수 없다.
LLM이 소프트웨어 엔지니어에게 유용하다는 것은 분명하다. 코드를 빠르게 생성할 수 있고, 요구사항과 문서를 종합하는 데 뛰어나다. 어떤 작업에서는 이것만으로 충분하다. 요구사항이 명확하고 문제가 단순해서 한 번에 전체를 처리할 수 있는 경우가 있다.
그러나 중요한 작업의 경우, LLM은 충분한 컨텍스트를 정확하게 유지하며 반복적으로 작동하는 솔루션을 제공할 능력이 없다. 소프트웨어 엔지니어인 여러분이 요구사항이 명확한지, 코드가 실제로 의도한 대로 동작하는지 확인할 책임이 있다.
Zed에서는 사람과 에이전트가 협력해 소프트웨어를 구축할 수 있는 세상을 믿는다. 하지만 적어도 지금은 여러분이 주도권을 쥐고 있어야 하며, LLM은 단지 활용할 수 있는 도구 중 하나일 뿐이라고 확신한다.