AI 시대에 공부하는 방법
면접 털리고 쓰는 공부법 되짚기
최근에 T사의 면접을 보고왔는데 좀 부끄러운 경험이었습니다. (부끄럼 많은 생애를 보냈습니다.. 개발자실격)
제 기준 그리 어렵지 않은 질문이었는데 충분히 답할 수 있는 문제를 추론하지 못해서 생긴 일이었는데..
이번 글에서는 뭣이 중하고(?) 어떤 인지적인 노력이 필요할지 어떻게 공부하면 좋을지 생각나는대로 적어봤습니다.
근본은 역시 CS(Computer science)
말해 뭐하냐마는 모든 기초는 CS에서 나온다는 것입니다.
이번 면접에서 CS의 중요성을 다시 한 번 크게 깨닫게 되었는데, 컴퓨터 과학이 해결하고자 하는 거의 모든(?) 문제는 추상화 계층이 추가되어있을 뿐 비슷합니다.
대부분 프렉탈(유사성)처럼 발생하는 이 문제를.. 면접 뒤에 복기를 해보니 당연한 문제를 너무 어렵게 해석하려는 시도를 했다는 것입니다.
CS에 대한 전반적인 베이스가 깔려있다면 기술이 동작하는 방식이나 해결 방법에서 어떠한 문제점이 생길 수 있는지 추론이 가능하다는 점이 가장 큰 깨달음이었습니다. (CS파러 갑니다)
‘틀린 답’보다 위험한 ‘빠른 정답’
사실 이것 때문에 글쓰려고 한게 과언이 아닌데.. 서비스 운영 상황에서 발생할 수 있는 문제는 여러 기업 및 개발자들의 시행착오에 기반한 기술 아티클이나 레퍼런스를 통해서 입맛에 맞는 해결 방법을 얻을 수 있습니다. (저도 이렇게 공부했구요)
참조할 만한 지식이 넘쳐나기 때문에 결과까지 도달하는게 쉽지만, 이렇게되면 생각의 가지(?)가 뻗을 틈이 없습니다.
LLM을 잘못된 방향으로 사용하는 방법 중 하나는 과정을 생략하고 결과를 쫓아가는 것이라고 생각하는데요:
결과가 중요하지 않다는게 아니라 결과를 쫓는데에 LLM에 생각을 상당부분 의탁해서 머리에 남지 않는 경험이 종종 있었습니다.
정답을 묻기 전에 내 예상을 먼저 생각한 뒤에 결과가 어떻게 나올지, 왜 이렇게 나올지 생각한 뒤에 이를 문답하면서 LLM을 사용하며 튜터로 써먹는 방향으로 인지적인 노력이 필요하다고 생각했습니다.
답을 즉각적으로 요구하기보다 내가 이걸 얼마나 알고있는지 질문으로 확인시켜달라고 유도하여 막히는 부분을 찾아서 개선하는 방법이 좋겠네요.
이건 비단 개발 공부에만 해당되는 내용은 아닌 것 같아서 어떻게 할 수 있을지 추가적인 고민을 해봐야겠습니다.
이해했다는 착각
‘빠른 정답’의 연장선인데 결과에 쉽게 도달할 수 있어서 알았다는 착각에 빠지기 쉬운 것 같습니다.
1~2달 전부터 아는 것과 모르는 것의 경계를 나누기 위해 신경쓰고자하는데 꽤 효과있었던 방법은..
시간을 정해놓고 학습하고자 하는 주제에 대해 최소로 파악(ex: kafka는 클러스터, 토픽, 파티션으로 구성되어 있다)만하고 이를 구현하려면 어떤 요소가 필요할지 손코딩 해본 뒤에 실제 구현된 레퍼런스와 비교해서 맞았다면 넘기고 부족한 부분만 캐치하여 보강하는 방식이 도움이 많이 되었습니다.
여기서 추가로 스터디를 통해 남에게 쉽게 설명할 수 있도록 하는 시간을 가져볼까 합니다.
맺음
이제 알았으니 액션으로 옮기기만 하면 되는데.. (나믿너믿)
최근에 존 카맥이 ‘시대에 뒤떨어진 쿵푸 마스터가 되지 말라’고 비유했는데 너무 와닿았습니다.
이제 개발 환경에서 LLM 없이 개발하는 환경은 생각못할정도로 의존성이 커지고 있는데, LLM이라는 괴물을 잘 길들여서 잡아먹히지 않도록 훈련을 계속 해야겠습니다.