Boaz
요즘 가장 많이 듣는 질문이 있어요. “AI가 다 해주면, 우리는 뭘 해야 하죠?” 오늘은 제가 주니어 분과 나눈 커리어 코칭을 바탕으로, **제가 실제로 어떻게 일하고, 무엇을 가르치고, 왜 그 길이 지금 중요하다고 믿는지**를 정리해봅니다.
저와 만난 주니어분은 시니어의 역할을 이렇게 정의했어요.
시니어라는 직군은 단순히 기술을 잘한다 이런 것보다… 우리가 이런 기술을 도입했을 때 이득이다 아니다를 비용·회사 상황까지 종합적으로 볼 수 있는 사람.”
다만, 아직까지 주니어이기에 시니어처럼 종합적인 판단을 하기가 어려워서, 이 부분에서 AI 에게 도움을 많이 받는다고 하셨어요. 그러면서 도움을 받은 실제 사례를 아래와 같이 말해주셨어요.
“AWS IAM 같이 어렵다고 느껴지는 부분에 대해서도 베스트 프랙티스를 상황에 맞게 뽑아낼 수 있었어요”
이처럼 많은 주니어 분들이 AI 의 결과물을 어느정도 그대로 받아들이는 경향이 있다는 것을 알 수 있었어요. 그러나 AI 의 결과물이 항상 베스트 프랙티스가 아닐 수 있기에, 우리는 AI 가 정해진 길을 달릴 수 있도록 레일을 깔아주어야 해요.
AI는 이제 ‘어떻게(How)’까지 제법 잘합니다. 하지만 베스트 프랙티스인지 검토하는 일, 회사 맥락·비용·리스크를 함께 고려해서 의사결정하는 일은 여전히 사람의 몫이에요.
“AI가 주는 결과물은 검토가 필요하거든요. 검토를 위한 지식을 쌓아야 돼요.”
이 검토는 구체적 체크리스트로 정의하면 더욱 효과적입니다. 예를 들어 저는 인프라/아키텍처를 고를 때 최소한 다음을 봅니다.
AI가 만들어 온 안(A/B/C)을 이 프레임으로 채택 혹은 기각합니다. 그게 ‘시니어가 가진 차이점’인 것 같아요.
저는 기술 스택을 Next.js(App Router)로 고정합니다. 이때 Clean F.S.D 을 지키면서 구현하도록, 이 아키텍처의 규칙을 AI에게 학습시킵니다.
entities/<domain>/action(get*) → 읽기 전용(ViewModel 관점)features/<feature>/action(submit) → 쓰기/변경(폼, 서버액션)*/model/ → 도메인 로직·함수(예: calculateStock)
“수량은 book 테이블에 칼럼 추가 X. 전표 라인아이템을 집계해서
calculateStock(bookId)로 산출.”
이 규칙들을 CLAUDE.md(RULES)로 만들어 Claude Code(혹은 Cursor)가 참조할 수 있게 합니다. 그러면 AI가 “사람이 정한 레일” 위에서 움직입니다.
현실 요구사항을 받으면 저는 먼저 **UX 흐름**으로 풀어 그립니다.
“요구사항을 플로우 차트로 바꿔요. 바코드 스캔 → 오류 여부 → 단건/대량 검수 → 출력…”
그 다음 단계는 기술적 설계입니다.
books/model/calculateStock.ts
이렇게 정리한 문서를 AI에게 먼저 제공하고, 그 다음에 구현을 시킵니다. 이 순서가 바뀌면, “동작은 하지만 잘못된 구조”가 나오기 쉽기 때문이에요.
“AI는 작업 단위가 커지면 길을 잃고 결과물이 애매모호해져요. 그래서 단위를 적절하게 쪼갠 후 작업을 진행하고 결과물을 합칩니다.”
저는 대략 다음 순서로 하나의 기능을 설계하고, 이 전체 과정을 하나의 단위로 구분합니다.
각 단위는 린트/빌드를 통과해야 다음 단계로 넘어갑니다.
"린트·빌드 CLI 통과 전에는 commit 금지. 실패하면 AI가 스스로 수정해서 다시 돌려요.”
“커밋이 세이브입니다. 편집→테스트→커밋→PR을 **명령/훅 체인**으로 활용하여 언제든 실패지점으로 다시 돌아갈 수 있게 관리합니다.”
Claude Code의 command 명령어와 hooks 를 엮어 수정→테스트→커밋→PR 까지 자동화할 수 있어요. 이렇게하면, 생성·수정의 반복에서도 기록이 남습니다. AI가 “가끔 됐다”고 거짓말해도 빌드/린트가 거짓말을 막습니다.
“**모든 구현 디테일을 자세하게 알 필요는 없어요.** 다만 **읽어서 수정할 수 있는 수준의 지식**은 반드시 필요합니다.”
예를 들어 랜딩 페이지의 스크롤 전환이 너무 빨랐던 적이 있어요. 처음엔 자연어로 “더 천천히”라고만 지시했는데, 원하는만큼 안 바뀌더군요. 그때 코드를 열어 **뷰포트 계산 방식**을 파악하고, **정확한 수정 지시**를 내렸습니다. 이 정도 “읽고 고치는 능력”은 아직까지는 필요한 것 같아요.
두 길 모두 유효합니다.
“**정답은 흥미**예요. 무엇에 몰입할 때 시간이 사라지는지, 그 방향이 장기적으로 승률이 높습니다.”
다만 **프론트엔드 기반**이라면 저는 **프로덕트 중심 방향**을 추천합니다. 아래 좀더 자세한 고려사항을 고민해보고 본인의 커리어 패스를 설계하면 좋을것 같아요.
회사 선택의 기준은 단순합니다. 설계·검토·배포 사이클 전체를 맡아서 일해볼 수 있는 곳이 장기적으로 성장하기에 유리합니다. 코드만 치는 포지션이면, 역할을 확장할 수 있도록 **신뢰를 먼저** 쌓는 것을 추천드려요.
“샥스핀·캐비어를 받았는데 한강라면을 끓이고 있다”는 표현, 너무 공감합니다.
다만, 저의 의견을 조금 보태자면,
“실제 주변 사람의 문제를 해결 하려고 시도해요. 그러면 만드는 동안 진짜 많이 배웁니다.”
“AI는 **구현을 다 잘하기 시작**하더니, 이제는 **설계의 일부까지** 올라오고 있어요. 그래서 앞으로는 **자연어 요구→기술 언어 변환** 자체도 많이 대체될 겁니다.”
그렇다면 더더욱 사람 쪽의 ‘왜(Why)’와 ‘검토(Verification)’가 중요해집니다.
사용자 문제를 **정의하고**, 맥락을 **공감**하고, 제약을 고려해 **우선순위를 결정**하는 일.
이건 여전히 **사람의 영역**입니다.
아마도 로보틱스가 본격화되기 전까지는 그럴것 같아요. AI 는 물성이 없기 때문이에요. 따라서, 물리적 존재가 있는 인간은 사용자와 좀 더 다양한 방식의 커뮤니케이션이 가능하고, 이를 통해 더 직관적으로 깊은 인사이트를 발견할 수 있는 것 같아요. 그 결과 **‘왜’**를 더 잘 파악할 수 있고요.
“**AI는 ‘어떻게’까지 올라오고 있다. 우리가 붙잡을 것은 ‘왜’와 ‘검토’다.** 문제를 더 잘 정의하고, 설계로 경계를 세우고, 제어 가능한 단위로 쪼개어 **AI를 동료로 쓰는 사람**—그 사람이 다음 3년을 주도한다.”
저도 계속 배워가는 과정인 것 같아요. 다만 요즘처럼 AI 발전이 빠른 시기에, 주니어 분들에게 가이드를 드려서 도움이 될 수 있다면 하는 마음으로 이런 글을 쓰게 되었어요. 함께 이 시기를 잘 헤쳐나가서 본질적인 경쟁력을 갖추는데 도움이 되면 기쁠 것 같아요.
함께 공부해주셔 감사합니다. 그럼 화이팅입니다! 🤗