Forge Fate
한국어
AI

AI가 계속 좋아지는데, 개발자인 나는 무엇을 배워야 할까?

약 8분

나는 Codex에 프롬프트로 요청해 개발 문제를 해결하고 있다. 그래서 활용법을 더 배워야 한다는 이야기를 접해도 선뜻 공감하기 어렵다. 지금도 원하는 결과를 얻는 것 같은데, 새 기능을 익히는 데 시간을 쓰면 무엇이 달라질까? 동작 방식은 어디까지 알아야 할까? 이것은 내 작업의 효과를 측정해서 내린 결론이 아니라, 내가 품고 있는 질문이다. [S1]

도구가 바뀔 때마다 사용법을 따라가려 하면 배울 목록에는 끝이 없어 보인다. 반대로 프롬프트가 통한다는 이유만으로 지금의 방식에 머물러도 되는지는 확신하기 어렵다. 결국 내가 묻고 싶은 것은 세 가지다. 추가 학습이 필요한 순간은 언제인가. 동작을 어느 깊이까지 이해해야 하는가. 한정된 시간을 어떤 역량에 써야 하는가.

새 사용법을 익히면 무엇을 얻을까?

새 기능을 배우는 데는 사용법을 읽고, 내 작업에 맞게 시도하고, 나중에도 쓸 만한지 판단하는 시간이 든다. 그 시간을 들일 이유가 있으려면 막연히 기능을 더 아는 것보다 구체적인 이득이 보여야 한다. 지금 반복해서 설명하는 내용이 줄어드는가? 작업 중 놓치는 판단을 더 잘 알아차리게 되는가? 그 답은 내 작업을 살펴보기 전에는 정할 수 없다.

배운 요령이 계속 유효하리라는 보장도 없다. OpenAI는 모델이 달라질 때 기존 프롬프트와 프로젝트 지침, Skill을 다시 살피고, 지나치게 길거나 오래된 지침을 덜어낼 필요가 있다고 권한다. 이는 특정 모델에 관한 제작사의 권고이지, 내 프로젝트에서 지침을 줄이면 더 좋은 결과가 나온다는 증거는 아니다. [S2] 새 사용법을 익히는 일에는 무엇을 추가할지뿐 아니라 이미 쓰는 요령 중 무엇을 그만둘지 판단하는 일도 포함될 수 있다.

한편 위임하는 작업이 커지면 다른 종류의 학습이 필요해질 가능성도 있다. OpenAI가 소개한 사용 흐름에는 진행 중인 작업의 방향 수정, 변경 코드 검토와 승인 요청이 등장하고, 한 엔지니어의 사례에는 계획을 사람이 검토하고 실행 결과와 선택 이유를 기록하는 과정이 포함된다. [S4][S5] 내 작업에서도 위임이 늘수록 이런 판단이 중요해질지는 아직 모른다. 다만 기능의 이름을 외우는 일보다 어디까지 맡기고 언제 개입할지를 정하는 일이 더 큰 학습 과제가 될 수 있다는 질문은 남는다.

프롬프트만으로 해결됐다는 인상

내가 요청을 적고 결과를 받았다면, 자연스럽게 프롬프트로 해결했다고 느낄 수 있다. 하지만 그 결과에 무엇이 기여했는지는 별개의 질문이다. 내 실제 작업 기록은 이 글의 자료에 없으므로, 프롬프트와 기존 코드, 프로젝트 지침, 도구 실행 결과가 각각 어떤 역할을 했는지 확인할 수 없다. [S1]

공식 사례는 이 질문을 좀 더 구체적으로 만들어 준다. OpenAI는 저장소의 AGENTS.md에 적힌 규칙을 Codex Code Review가 활용할 수 있다고 설명한다. 다른 작업 사례에는 실행 명령과 결과의 기록, 검증 명령, 사람의 검토가 함께 등장한다. [S3][S5][S6] 이것이 내 작업에서도 같은 비중으로 작용했다는 뜻은 아니다. 다만 다음에 결과를 받아 들었을 때는 이런 질문을 해볼 수 있다. 내가 적은 요청 외에 기존 코드의 구조는 무엇을 알려주었을까? 에이전트는 어떤 실행 결과를 보고 방향을 바꾸었을까? 나는 무엇을 직접 확인한 뒤 결과를 받아들였을까?

이 질문은 프롬프트의 가치를 낮추려는 것이 아니다. 내가 이미 잘하고 있는 일이 무엇인지, 그리고 추가로 배워야 할 부분이 실제로 어디에 있는지 구분하기 위한 출발점이다.

동작 방식은 어디까지 이해해야 할까?

‘원리를 알아야 한다’는 말은 범위가 너무 넓다. 나는 이해의 깊이를 세 단계로 나눠 생각해 보려 한다.

첫째는 작업 기록을 읽는 능력이다. 무엇을 바꾸었고, 어떤 명령을 실행했으며, 결과를 보고 어떤 결정을 내렸는지 따라갈 수 있는가? OpenAI가 공개한 작업 사례에는 명령과 결과, 선택 이유를 남기거나 단계별 확인 기준을 두는 방식이 나온다. [S5][S6] 기록을 읽을 수 있다면 결과가 마음에 들지 않을 때도 막연히 프롬프트를 다시 쓰기보다 확인할 지점을 고르기 쉬울 것 같다. 이것은 내게 유용할지 살펴볼 가설이다.

둘째는 작업 조건을 파악하는 능력이다. 에이전트가 참고하는 맥락과 프로젝트 지침은 무엇인지, 도구로 무엇을 확인했는지, 어떤 행동에는 권한이나 승인이 필요한지 아는 것이다. OpenAI의 설명에서도 프롬프트와 지침, 저장소별 검토 규칙, 승인 흐름은 각각 작업에 관여한다. [S2][S3][S4] 이 층위의 이해가 필요하다면, 모델의 모든 세부 동작을 배우기 전에 내가 맡기는 작업의 조건부터 분명히 할 수 있다.

셋째는 실행 구조와 모델 내부 원리다. 앞의 두 단계로 설명되지 않는 문제가 생기거나, 특정한 기술적 판단을 해야 할 때 더 깊이 공부할 이유가 있을 수 있다. 그러나 지금 가진 자료만으로는 내부 원리를 공부하는 일이 내 개발 작업에 얼마나 도움이 될지 판단할 수 없다. 깊이 이해한다는 목표 자체보다, 풀려는 문제가 어떤 설명을 요구하는지 먼저 묻고 싶다.

학습의 가치를 무엇으로 볼까?

토큰 사용량이나 결과가 나오기까지의 속도는 비교하기 쉬운 기준처럼 보인다. 하지만 내가 알고 싶은 것은 그것만이 아니다. 결과를 얻기까지 같은 설명을 몇 번 다시 했는지, 중간에 얼마나 개입했는지, 변경 사항을 검토하는 데 얼마나 부담이 있었는지, 받아들인 뒤 재작업이 필요했는지도 중요하다. 무엇보다 왜 코드가 그렇게 바뀌었는지 이해하고, 다음 요구가 왔을 때 어디부터 확인할지 판단할 수 있는지 살펴보고 싶다.

이것은 검증된 생산성 공식이 아니라 앞으로 내 작업을 돌아볼 때 쓸 질문이다. 공식 사례가 보여주는 승인, 검토, 결정 기록 역시 그런 질문을 떠올리게 하는 소재일 뿐, 내게 같은 방식이 유리하다는 결론은 아니다. [S3][S4][S5] 빠른 답을 받았더라도 변경 이유를 이해하지 못해 다음 작업에서 다시 헤맨다면 그 경험은 어떻게 평가해야 할까? 반대로 새 기능을 배우느라 시간을 썼지만 이후에도 쓸 일이 없다면 그 학습은 내게 얼마나 가치가 있을까?

유용할 때와 미뤄도 될 때

다음 두 경우는 설명용 가정이다. 내가 수행하거나 비교한 작업의 결과가 아니다.

한 프로젝트에서 같은 규칙을 에이전트에게 매번 다시 설명한다고 가정해 보자. 그 반복이 부담이라면 프로젝트 지침을 정리하는 방법을 배워볼 이유가 생긴다. 지침이 에이전트의 작업과 코드 검토에 쓰일 수 있다는 공식 설명은 이 선택을 생각할 근거가 된다. 다만 지침을 만드는 일 자체에도 유지 비용이 있으므로, 실제로 도움이 되는지는 해당 작업에서 확인해야 한다. [S2][S3]

반대로 간단한 변경을 요청했고, 나온 코드를 이해하고 검토할 수 있으며, 다음 수정 위치도 알겠다고 가정해 보자. 그때는 새 기능을 당장 익히기보다 현재 방식을 유지하는 편이 자연스러울 수 있다. 두 가정의 차이는 기능의 우열이 아니다. 반복되는 부담이 있는지, 학습이 그 부담을 다룰 수 있는지에 있다.

도구가 바뀌어도 남을 질문

나는 문제를 분명히 정의하고, 판단의 근거를 확보하고, 결과를 검증하고, 설계의 선택을 설명하는 능력에 시간을 쓰는 편이 오래 도움이 될지 궁금하다. 이것 역시 확인할 가설이지, 일반 개발 역량이 도구 사용법보다 언제나 우월하다는 선언은 아니다. 프로젝트 규칙을 어떻게 정하고 변경을 어디까지 받아들일지에 따라 도구 사용법 자체가 중요한 판단 능력이 될 수도 있다. 공식 사례에 나타난 규칙, 검토, 결정 기록은 이 관계를 생각하게 하지만 어느 역량의 장기적 가치를 입증하지는 않는다. [S2][S3][S5][S6]

그래서 이 시리즈에서는 우선 학습의 필요를 묻고, 이어서 이해의 깊이, 위임과 결정, 코드 판단, 규칙과 Skill을 만들고 유지하는 비용, 잠정적인 학습 우선순위를 차례로 생각해 보려 한다. 여섯 가지 질문을 기본 방향으로 삼되, 그 과정에서 실제로 생기는 질문에 따라 전체를 열두 편 안팎으로 넓힐 수 있다. 지금 정하는 것은 결론이나 확정 일정이 아니라 탐구할 순서다.

최근 AI와 함께 한 개발 작업 하나를 떠올려 보자. 편했던 점 하나와 내가 직접 판단하거나 반복해서 개입했던 지점 하나를 적어 보면, 지금 배울 만한 질문이 조금 더 선명해질지 모른다. 나는 그 지점에서 다음 글을 시작하려 한다. 에이전트의 동작을 어디까지 이해해야 할까?

Sources

오류 제보·의견 보내기

글 제목과 주소가 포함된 메일 초안을 엽니다. 내용과 받는 사람을 확인한 뒤 보내주세요.

받는 사람: [email protected]

메일 앱에서 작성

메일 앱이 열리지 않으면 아래 내용을 복사해 평소 쓰는 이메일에 붙여 넣으세요.

문의 안내

관련 글