Overview
취업을 하고, 현재에 안주하지 않으려 의식적으로 여러 자료를 찾아보는 편이다. GeekNews, Surfit, LinkedIn 등 여러 글을 읽는 시간을 가지며, 그런 곳에서 가장 자주 보이는 주제는 늘 AI였다.
반년쯤 실무를 겪고 나서 느끼는 건 AI가 개발자를 대체한다는 말보단 개발자의 일이 바뀌고 있다는 쪽이 현재로서는 더 실감난다는 점이다. 여러 글들을 읽으며 1년차도 안 된 개발자인 내가 지금 어떤 방향으로 AI를 공부해야 할지 다시 생각해보게 됐다.
예전이랑은 확실히 다른 분위기
예전에는 AI를 활용한다 하면 거의 ChatGPT 한 탭을 열어두고 막히는 부분을 물어보는 정도를 떠올렸다. 나도 실제로는 그정도로 사용했으며, 궁금한 걸 물어보고, 답변 중 필요한 부분만 가져오고, 다음 작업에서 다시 묻는 식이었다.
근데 요즘은 분위기가 확실히 다르다. Agentic Coding이라는 말이 나오며 여러 에이전트들이 계속 등장하고 있다. 사람들은 상황이나 성향에 따라 도구를 바꿔가며 쓴다. 단순히 "어떤 모델이 더 똑똑하냐"보다, "내 작업 흐름에 어떤 도구가 더 잘 붙느냐"가 더 중요한 기준처럼 느껴진다.
그래서 나도 AI를 잘 쓴다는 게 뭘 의미하는지 다시 생각하게 됐다.
최전선의 AI 활용을 보면서 든 생각
여러 플랫폼에서 글을 읽다가 특히 기억에 남는 내용이 있었다.
먼저 agent-skills다. 이걸 보면서 재밌었던건 AI 활용을 그냥 생산성 도구 소개 정도로 다루지 않는다는 점이었다. 특히 Vercel이 이런 주제를 구체적인 방식으로 풀어내고 있다는 점이 인상 깊었다.
스킬 목록 안에 react-best-practices 같은 항목이 따로 들어가 있는 것도 눈에 띄었다. 좋은 결과를 내려면 모델 성능뿐 아니라, 어떤 코드를 좋다고 볼지 기준을 미리 정해두는 것도 중요하다고 느꼈다.
everything-claude-code는 그걸 더 크게 보여줬다. 이 레포는 AI를 단순한 채팅 도구가 아니라 skills, hooks, rules, memory를 포함한 하나의 시스템처럼 다룬다. 프롬프트를 잘 쓰는 것보다 작업 흐름 전체를 어떻게 설계할 것인가에 더 가까워 보였다.
결국 둘 다 반복해서 설명해야 하는 기준과 맥락을 사람 머릿속에만 두지 않고, 바깥으로 꺼내서 쌓아두는 쪽이 더 강하다는 점을 보여줬다. AI를 잘 쓴다는 건 질문을 잘 던지는 능력만이 아니라, 자주 반복되는 판단과 맥락을 시스템으로 만드는 능력이라는 생각이 들었다.
그래서 나의 생각은..
AI를 활용한 코딩은 이제 피하기 어려운 흐름처럼 느껴진다. 이런 흐름을 보면서 나도 AI를 더 잘 활용하려면 뭘 갖춰야 할지 생각하게 됐다.
프론트엔드냐 백엔드냐보다 먼저, 결국 설계와 검증 쪽에 눈이 갔다. 지금 내가 중요하다고 느끼는 기준은 크게 세 가지다.
1. 문제를 정의하고 맥락을 정리하는 능력
AI는 대충 시키면 대충 답한다. 너무 당연한 말인데 실제로 써보면 이게 제일 어렵다.
무엇을 만들 건지, 어떤 제약이 있는지, 어떤 기준으로 결과를 판단할 건지 먼저 정리하지 않으면 답변도 자꾸 흐려진다. 내가 원하는 게 구현 코드인지, 설계 방향인지, 디버깅인지부터 명확해야 한다.
특히 문제를 잘 정의하는 능력이 더 중요하다는 말에 공감하게 됐다.
또한 필요한 맥락을 같이 주는 것도 중요하다. 팀 컨벤션, 현재 코드 구조, 원하는 설계 방향 같은 것들은 결과에 큰 영향을 준다. 반대로 불필요한 설명이 너무 많으면 맥락이 흐려지기도 한다.
최근에는 이런 맥락을 md 파일이나 룰 파일로 정리해서 에이전트가 읽게 하는 방식도 자주 보인다. 나도 이런 흐름을 보면서, 결국 AI 시대의 문서화는 사람만을 위한 문서가 아니라 AI와 협업하기 위한 문서이기도 하다는 생각이 들었다.
2. 검증하는 능력
여전히 가장 중요한 건 검증이다. AI는 빨리 답해주지만, 그 답이 항상 맞는 건 아니다. 틀린 정보를 자신 있게 말할 수도 있고, 내 프로젝트 문맥에 맞지 않는 걸 그럴듯하게 제안할 수도 있다.
그래서 AI를 잘 쓰는 사람은 AI를 많이 믿는 사람이 아니라, 빠르게 검증하는 사람이라고 생각한다. 내가 결과를 받았을 때 확인해야 하는 것도 결국 비슷하다.
- 논리가 맞는가
- 엣지 케이스가 빠지진 않았는가
- 프로젝트의 구조와 제약에 맞는가
- 유지보수할 수 있는 형태인가
결국 검증 능력은 개발자 본인의 실력과 직결된다. 이 부분은 AI가 대신해주기 어렵다. 어떤 분야를 하든, 마지막에 결과를 책임지는 쪽은 여전히 사람이라는 생각이 든다. 책임도 좀 줘주라..
3. 워크플로우에 녹여내는 능력
AI를 한두 번 물어보는 도구로만 쓰면 한계가 빨리 온다. 반복되는 질문은 템플릿으로 만들고, 자주 쓰는 기준은 룰이나 문서로 남기고, 반복 작업은 스크립트나 자동화 흐름으로 바꾸는 식의 접근이 필요하다.
everything-claude-code 같은 흐름을 보면서 특히 이 부분을 많이 느꼈다. 잘 쓰는 사람들은 매번 처음부터 새로 묻지 않는다. 자신의 기준을 쌓아두고, 작업 흐름 안에 AI를 붙인다.
결국 중요한 건 AI를 쓰느냐보다 원하는 수준의 결과를 반복해서 안정적으로 얻을 수 있느냐에 더 가깝다고 느꼈다.
직접 써보면서 더 실감한 것
얼마 전에는 지인이 LinkedIn에서 어떤 글을 보고, 글에서 설명하는 개발 환경을 맥에서도 잘 호환되게 직접 손봐서 공유해주었다. 멀티 에이전트 기반 환경이었는데 직접 써보니 왜 이런 흐름이 계속 나오는지 조금 감이 왔다.
특히 인상적이었던건 AI를 그냥 하나의 채팅창으로 쓰는 게 아니라 오케스트레이터와 역할별 서브 에이전트처럼 나눠서 바라본다는 점이었다. 파일 몇 개를 프로젝트에 붙여서 규칙과 역할을 먼저 깔고 그 위에서 작업을 분담시키는 접근 자체가 나에게는 신선했다. 내가 앞에서 봤던 글들이 말하던 방향이 실제로는 이런 식으로 굴러갈 수도 있겠구나 싶었다.
직접 써보니 재미있기도 했지만, 동시에 한 가지가 더 분명해졌다. 내가 직접 코드타이핑을 덜 하게 되더라도 해야 할 판단이 줄어드는 건 아니라는 점이다.
오히려 더 많이 보게 된다. 지금 이 방향이 맞는지, 이 결과를 바로 써도 되는지, 어느 수준까지 자동화할지, 어디서 사람이 끼어들어야 하는지 같은 것들 말이다. 예전보다 구현의 비중은 줄 수 있어도, 방향을 잡고 검증하는 비중은 커진다.
마무리
이 과도기에서 내가 개발자로 계속 살아남으려면 AI를 무조건 많이 쓰는 것보다 제대로 쓰는 방법을 익혀야 한다고 생각한다. 생산성이 실제로 올라가는지 보고, 비용과 컨텍스트를 관리하고, 결과를 검증하고, 그걸 내 워크플로우 안에 자연스럽게 녹여내는 것. 지금은 이런 기본기가 더 중요해 보인다.
그리고 요즘 내가 더 많이 붙잡게 되는 것도 결국 그런 부분들이다. 이 구조가 맞는지, 이 자동화가 지금 상황에 맞는지, 이 결과가 팀 안에서 유지될 수 있는지, 지금의 선택이 이후에도 괜찮을지. 프론트엔드든 백엔드든, 혹은 그 밖의 다른 영역이든 점점 더 설계와 검증 쪽으로 시선이 가게 된다.
아직은 배워야 할 게 많지만, 앞으로는 단순히 코드를 빨리 치는 사람보다는 더 넓은 맥락에서 판단하고 끝까지 검증할 수 있는 사람이 되어야겠다는 생각이 든다.