마이크로 컨텍스트 전환

Source: Dev.to

※ 이 글은 나이 든 소프트웨어 엔지니어이자 AI 회의론자의 머릿속 독백입니다.

컴퓨터 코드를 작성하는 일은 신중하게 편지를 쓰는 일과 조금 비슷합니다. 두 경우 모두 우리가 말하고 싶은 내용을 미리 계획하고, 그 텍스트를 미시적인 수준(각 문장·구문)과 거시적인 수준(문서·애플리케이션 전체) 모두에서 고려해야 합니다. 그런데 AI가 개입하면, 양쪽 모두에서 사고 흐름을 방해한다는 느낌이 듭니다.

예전에는 “소프트웨어 개발자는 코드를 쓰기 위해 돈을 받는 것이 아니라, 생각하고 문제를 해결하기 위해 돈을 받는다”라고 말하곤 했습니다. AI 시대가 찾아왔지만 이 말은 여전히 사실이며, 오히려 더 강해졌다고 봅니다. 코드를 타이핑하는 행위 자체가 사고 과정의 일부이자 문제 해결의 한 단계이기 때문입니다. 어떤 사람은 코드를 소프트웨어 설계 과정의 최종 표현이라고도 할 수 있겠죠.

하지만 통합 개발 환경(IDE)에 내장된 AI 도구는, 유용하게 느낄 수도 있지만, 큰 방해 요소가 될 수 있고 사고와 코딩 흐름을 깨뜨릴 수 있습니다.

AI 도구를 끄든 켜든, 그 전후의 작업 흐름은 더 쉬웠습니다. 작업 설명서를 읽고 후보 솔루션을 고민한 뒤, 코드를 살펴보며 접점(touch point)을 찾습니다. 어떤 코드를 제거하거나 바꿔야 할지 파악하고, 적절한 해결책을 구현하기 위해 필요한 코드의 정신적 지도를 그려 나갑니다. 처음부터 하나의 해결책만을 염두에 두지는 않으며, 기존 코드를 통해 판단을 보완합니다.

이는 “계획은 적과 처음 마주했을 때 살아남기 어렵다”는 관찰과 일맥상통합니다.

덧붙여, 포괄적인 단위 테스트 모음이 얼마나 큰 도움이 되는지 말하고 싶습니다. 물론, 코드를 변경하면(단순 리팩터링이 아니라면) 단위 테스트를 수정해야 할 가능성이 높고, 추가 작업이 필요합니다. 하지만 깨지는 변경 사항이 실패한 단위 테스트에 의해 잡히면, 그 변화가 단순한 패치가 아니라 다른 유닛 외부까지 영향을 미치는 큰 변화라는 것을 깨닫게 됩니다. 결국 다른 사람에게 부정적인 영향을 주기 전에 문제를 발견한 것이죠.

AI “도움” 없이 작업을 진행하면, 코드를 읽고, 현재 구축 중인 정신 모델과 적용하려는 해결책의 맥락에서 코드를 이해한 뒤, 필요한 변경을 가하고, 다시 반복합니다. 일방향 피드백 루프가 도파민을 쏘아 올리는 느낌을 줍니다.

AI가 개입하면 그 흐름이 깨집니다. 코드를 읽고 이해한 뒤 변경을 시작했는데, 갑자기 AI가 제안하는 팝업이 나타나 생각이 산만해집니다. “코드를 타이핑했으니 AI에게 물어본 것”이라고 말할 수도 있겠지만, 저는 동의하지 않습니다. 피드백 루프가 이제 양방향이 된 것이죠.

“그럼, 나는 어디까지 왔지? 기대했던 도파민은 어디에 있지?”

이 정신적 방해는 동료가 어깨를 두드리며 커피 브레이크를 제안하는 것보다도 더 크게 느껴집니다. 문제에 부딪혔을 때는 오히려 도움이 될 수도 있지만, 화면에 새 이메일이나 소프트웨어 업데이트 알림이 떠오르는 정도의 방해는 견딜 수 있습니다.

AI는 끈질기게 당신의 생각을 자신이 더 잘 안다고 주장합니다. 맞을 수도 있지만, 내 생각을 내 방식대로 유지하고 적용할 권리는 분명히 제게 있습니다. 결국 제가 받는 급여는 바로 그 때문이잖아요?

제발, AI가 만든 코드를 검토하기 전에 제 뇌를 쓸 수 있게 해 주세요. 뇌가 위축되거나 부패하기 전에요.