Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 개발 역량은 타고나는 것이 아니라 직접 수행하고 고민하는 과정에서 만들어지며 유지된다는 점을 강조합니다. 특히, AI에 과도하게 의존하여 사고 과정을 건너뛰고 결과물만 검토하는 방식의 위험성을 지적하며, 비판적 사고와 숙련도를 유지하기 위한 '사고 과정'의 중요성을 역설합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글은 두뇌 역량이 타고나며 일정하게 유지된다고 가정하지만, 실제로는 직접 수행하면서 만들어지고 유지됨. 직접 하지 않으면 샌드위치 바깥쪽 두 단계의 역량도 퇴화함. 두 번째 단계를 완전히 위임하면 측정 가능한 수준의 숙련도 저하가 일어난다는 사실을 놓치고 있음.
직접 수행한다는 말에는 많은 것이 숨어 있음. Matheus의 글에서는 과제와 범위, 변경 내역, 절충점, 설명을 읽고 이해하는 것이 수행의 핵심이라고 봄.
어려운 부분은 자신을 성장시키는 필수적인 고민과 시행착오를, 파일에 UTF-8 문자를 입력하는 기계적 작업이나 2년 뒤면 쓸모없어질 사소한 지식을 익히는 소모적인 작업과 구분하는 것임. 둘은 같지 않지만 경계가 모호하고 계속 움직여 깔끔하게 분리하기 어려움. 그래도 전자는 최대화하고 후자는 최소화하고 싶은 것임.
주니어가 이 방법으로 시니어까지 성장할 수 있을까?
주니어를 시니어로 만드는 것은 수많은 실패와 시행착오임. 옳고 그른 길을 모두 탐색하고, 처음에는 좋아 보이던 해결책의 함정이 몇 년 뒤 드러나는 과정을 겪어야 함. 디자인 패턴에 빠져 남용하다 단순함의 가치를 배우고, 객체 지향과 함수형 프로그래밍의 장단점을 저울질하며 자기 신념과 익숙한 영역을 벗어나는 과정도 필요함.
구식이라고 해도 학습의 핵심은 정답이 아니라 정답에 이르는 여정이라고 봄. 사고 과정을 건너뛰고 해결책만 들여다보며 배울 수 있다는 것은 착각임.
추리소설에서 단서와 결말만 읽으면 해답이 단서에 맞는지 쉽게 확인할 수 있음. 수천 편을 그렇게 검토해도 직접 추론해 본 적이 없다면 새로운 사건 앞에서는 영원한 초보 탐정에 머물게 됨. 영화의 완성도를 평가한다고 좋은 감독이 되거나, 아들과 Michael Jordan의 농구 실력을 비교할 수 있다고 좋은 선수가 되는 것도 아님. 남의 결과물만 검토하고 샌드위치 겉부분만 먹으면서 어떻게 숙련된 탐정·감독·선수·프로그래머가 될 수 있을까?
내게는 이 방식이 잘 맞음. 검토 단계가 필수적이고 좋은 피드백 순환을 만들어 줌. 대충 넘기고 싶어도 검토자가 확인하지 않은 AI 생성 변경을 눈치채면 그냥 넘어가지 않을 것이고, 나 역시 검토자라면 마찬가지임. 덕분에 이 단계를 철저하게 수행하도록 빠르게 배우게 됨.
이 틀이 마음에 들어 직접 시도했지만, 늘어나는 업무량이 걸림돌임. 회사가 더 많은 산출물을 요구하면 속도를 맞추려고 처음의 사고 과정이나 마지막 검토를 생략하고, 결국 둘 다 버리게 됨. 어느새 AI 에이전트에 일을 넘기고 돌아온 결과를 그대로 배포하는 것이 기본 작업 방식이 되기 쉬움.
15년 넘게 일한 시니어 엔지니어인 나에게도 이런 변화가 나타남. 기존 책임에 더해 주니어가 하던 업무까지 빠르게 처리하라는 요구가 커지면서, 생각할 시간을 지키기 어려워짐. 비판적 사고가 무뎌지는 것을 느끼며 AI에 모든 일을 맡기는 편리함에 빠지지 않으려 의식적으로 노력해야 함.
그래서 이제는 빠르게 주고받을 수 있는 모델을 선호함. 그래야 문제 해결 과정에 계속 참여하게 됨. 크고 느린 모델을 쓸 때는 과제를 던지고 커피를 마신 뒤 완성된 구현을 보고 “이 정도면 괜찮네, 배포하자”라고 하면서 스스로를 과정에서 조금씩 빼고 있었음.
15년 경력으로도 의식적인 저항이 필요한데, 이런 환경에서 주니어가 시니어에게 필요한 판단력과 비판적 사고를 어떻게 기를지 상상하기 어려움. Brain Sandwich는 좋은 원칙이지만, 이를 지킬 시간과 여유를 주는 환경도 필요함.
주니어에게 업무를 맡기는 과정과 닮아 있음. 함께 앉아 과제를 설명하고 논의하되 일부는 스스로 발견하고 판단하도록 남겨 둔 다음, 직접 작업하게 하고 나중에 검토하는 방식임.
최근 담당 API의 익숙하지 않은 인증 코드를 변경하면서 테스트 모음부터 구축하기로 했음. 결정론적 시뮬레이션 테스트와 속성 기반 테스트를 만들고 LLM에도 버그를 찾게 했더니, 실제 결함부터 단순한 코드 스타일 문제까지 많이 발견됨. 병렬로 실행한 에이전트 세션 두 개에 수정을 맡겼는데, 둘 다 권한 관리에 쓰는 Casbin 저장소의 샤딩을 제안함.
결국 검토할 코드가 산더미처럼 쌓였고, 방해받지 않고 코드를 읽고 이해할 시간이 별로 없다는 사실을 깨닫게 됨. 애초에 테스트부터 시작한 이유도 바로 그 시간 부족이었음. 지금은 변경 사항을 조금씩 추려 내고 LLM끼리 서로 검토하게 하면서, 각 계층의 변경을 이해하고 무엇이 실제로 필요하거나 도움이 되는지 아주 천천히 확인하는 중임.
이 글은 구체적인 설명이 부족해 기법을 평가하거나 비판하기 어렵지만, 적극적인 감독 없이 LLM에 본격적인 업무를 맡겨도 된다고 생각해서는 안 됨. Brain Sandwich의 AI 단계에도 훨씬 많은 사람의 개입이 필요하므로, 실제 과정은 샌드위치보다 라자냐에 가까움.
다만 충분한 기능과 견고함을 갖춘 도구나 애플리케이션이 완성된 뒤에는 AI가 기준 유지, 기술 부채 관리, 통제 적용을 잘할 수 있다고 봄. 이 역시 개발 과정에서 AI를 얼마나 잘 제어하도록 해 두었는지에 달려 있음.