Overview
취업을 하고, 현재에 안주하지 않으려 의식적으로 여러 자료를 찾아보는 편이다. GeekNews, Surfit, LinkedIn 등 여러 글을 읽는 시간을 가지며, 그런 곳에서 가장 자주 보이는 주제는 늘 AI였다.
반년쯤 실무를 겪고 나서 느끼는 건 AI가 개발자를 대체한다는 말보단 개발자의 일이 바뀌고 있다는 쪽이 현재로서는 더 실감난다는 점이다. 여러 글들을 읽으며 1년차도 안 된 개발자인 내가 이 변화 속에서 어떤 방식으로 성장할 수 있을지 다시 생각해보게 됐다.
예전이랑은 확실히 다른 분위기
예전에는 AI를 활용한다 하면 거의 ChatGPT 한 탭을 열어두고 막히는 부분을 물어보는 정도를 떠올렸다. 나도 실제로는 그정도로 사용했으며, 궁금한 걸 물어보고, 답변 중 필요한 부분만 가져오고, 다음 작업에서 다시 묻는 식이었다.
근데 요즘은 분위기가 확실히 다르다. Agentic Coding이라는 말이 나오며 여러 에이전트들이 계속 등장하고 있다. 사람들은 상황이나 성향에 따라 도구를 바꿔가며 쓴다. 단순히 "어떤 모델이 더 똑똑하냐"보다, "내 작업 흐름에 어떤 도구가 더 잘 붙느냐"가 더 중요한 기준처럼 느껴진다.
그래서 나도 AI를 잘 쓴다는 게 뭘 의미하는지 다시 생각하게 됐다.
최전선의 AI 활용을 보면서 든 생각
여러 플랫폼에서 글을 읽다가 특히 기억에 남는 내용이 있었다.
먼저 agent-skills다. 이걸 보면서 재밌었던건 Vercel이 AI 활용을 그냥 생산성 도구 소개 정도가 아니라, 구체적인 작업 기준 모음으로 풀어내고 있다는 점이었다.
스킬 목록 안에 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를 많이 쓴다기보단, 이 도구를 내 작업 안에서 어디에 붙이면 도움이 되는지, 어디서부터는 사람이 더 책임지고 봐야 하는지 구분할 수 있는 사람이 되고 싶다.
하지만 이런 것들도 결국 바탕이 받쳐줘야 의미가 있다. 문제를 정의하고, 코드를 읽고, 구조를 이해하고 확인하는 기본기가 약하면 AI를 많이 알고 많이 써도 끝까지 책임질 수 없다고 생각한다.
그래서 요즘 내가 더 많이 붙잡게 되는 것도 결국 그런 부분들이다. 이 구조가 지금 상황에 맞는지, 이 결과가 팀 안에서 유지될 수 있는지, 지금의 선택이 이후에도 괜찮을지. 프론트엔드든 백엔드든, 혹은 그 밖의 다른 영역이든 점점 더 설계와 검증 쪽으로 시선이 가게 된다.
결론적으로 이럴수록 AI라는 도구를 도구답게 활용할 줄 아는 사람에 더 가까워지려한다. 생산성 향상도 중요하지만, 지금은 더 넓은 맥락에서 판단하고 그 판단을 떠받칠 수 있도록 기본기를 더 단단하게 쌓는 사람이 되어야겠다는 생각이 든다.