추상화에 대하여

AI와 일하면서 느낀 것

요즘 하루 대부분을 AI와 대화하면서 보냅니다. 코드를 짜거나, 문서를 정리하거나, 업무 흐름을 설계하거나, 그런 일들을 합니다. 그러면서 여러 문제를 겪었습니다.

규칙을 문서로 정리해서 전달했는데 매번 무시당했습니다. 자유도를 주면 제멋대로 하고, 지침을 좁히면 지침 밖의 것을 판단하지 못했습니다. 구현을 맡겼더니 설계까지 바꿔버리는 일도 있었습니다.

처음에는 프롬프트를 다듬거나, 규칙을 더 추가하는 식으로 대응했습니다. 크게 달라지지는 않았습니다.

어디서 본 구조

그러다 문득, 이 문제들이 낯설지 않다는 걸 느꼈습니다.

프론트엔드 개발을 할 때도 같은 고민을 했었거든요. 주의해서 설계해도, 사람이 하다 보면 결국 불가능한 상태를 받는 코드가 생깁니다. 그래서 타입 설계 자체를 바꿔서, 불가능한 상태가 아예 표현될 수 없게 만듭니다. "하지 말자"가 아니라 "할 수 없게" 만드는 겁니다.

AI한테도 비슷한 일이 있었습니다. 규칙을 문서로 정리해서 전달해도, 세션이 바뀌면 다시 원점이었습니다. 결국 린트 룰로 강제했더니 그제야 안정됐습니다.

"하지 말자"가 아니라 "할 수 없게". 같은 방향이었습니다.

같은 것을 알아보는 눈

AI와 일할 때 겪는 문제와 코드를 짤 때 겪는 문제가 같은 구조라는 걸 알아보는 것. 도구를 선택하는 고민과 프로세스를 설계하는 고민이 같은 범주에 있다는 걸 발견하는 것. 저는 그게 추상화라고 생각합니다.

구체적인 구현은 AI가 잘 해줍니다. 하지만 "이것과 저것이 사실 같은 구조다"라고 알아보는 눈은 사람의 영역입니다.

순서의 문제

추상화에는 순서가 있다고 생각합니다.

이론이 먼저 오는 경우가 있습니다. 멋진 개념을 배우고, 적용할 곳을 찾습니다. 겉보기에는 체계적이고 전문적으로 보이지만, 실제 문제의 본질을 가리는 경우가 많습니다. 단순한 문제를 오히려 복잡하게 만듭니다.

문제가 먼저 오는 경우가 있습니다. 무언가를 하다가 불편함을 느끼고, "왜 불편하지?"를 파고들고, 거기서 패턴을 뽑아내는 것입니다. 이론은 그다음에 와도 됩니다. 아니, 이론 없이 끝나도 됩니다.

도구를 선택할 때도 이 순서가 중요했습니다. 자동화 도구 두 개를 놓고 어느 걸 써야 할지 한참 고민한 적이 있는데, 비교할수록 답이 안 나왔습니다. 그러다 "이 일의 경계가 어디까지인가"를 먼저 정했더니, 도구는 자연스럽게 따라왔습니다.

코드에서 패턴에 맞춰 추상화하는 것과, 도구를 먼저 고르고 역할을 끼워맞추는 것. 겉보기에는 다른 상황인데, 결국 같은 실수라는 생각이 들었습니다.

저도 가끔 순서가 뒤집힐 때가 있습니다. 뭔가 배우고 나면 적용하고 싶어지거든요. 그래서 더 의식적으로 생각합니다. 지금 이론이 먼저 온 건 아닌지.

결국 같은 이야기

경우의 수를 줄이는 것. 도구의 설계 의도대로 쓰는 것. 문제에서 출발해서 구조를 꺼내는 것.

코드에서든 AI와의 협업에서든, 결국 같은 이야기였습니다.

이론으로 배운 것도 있지만, 더 많은 것은 "왜 이게 안 되지?"를 반복해서 물으면서 쌓였습니다. 그렇게 쌓인 직관이 다른 영역에서도 같은 구조를 알아보게 해주는 것 같습니다.