밤 2시, 화면을 보며 '이 구현, 어떻게 해야 깔끔할까'라고 혼잣말하던 시절이 있었습니다. 옆에 선배가 앉아 있는 것 같은데, 신경 쓸 필요 없는 동료가 생긴 기분이었습니다. AI 어시스턴트를 도입한 후로는 코드를 작성하는 '속도'보다 '사고의 깊이'가 변했다고 실감하고 있습니다. 저처럼 'AI를 잘 활용하고 있는지 모르겠다', '어느 정도까지 맡겨야 할지 왠지 모르게 불안하다'고 막연해하는 초보자 여러분께, 제가 지난 반년 동안 겪었던 시행착오를 그대로 공유하고 싶습니다.
도입 직전에는 Twitter나 기술 블로그에서 '생산성이 10배가 되었다', '코드를 작성할 필요가 없어졌다'는 글들을 많이 보았습니다. 솔직히 저 역시 '이거면 야근 제로다', '어려운 아키텍처도 순식간에 해결한다'며 들떠 있었습니다. 하지만 막상 실무 레포지토리에서 '이 기능을 베스트 프랙티스(best practice)로 구현해 줘'라고 던져보니, 돌아온 것은 언뜻 보기엔 작동할 것 같지만 프로젝트의 규약이나 기존 설계 사상을 완전히 무시한 '그럴듯한 코드'였습니다.
왜 그럴까요? AI는 우리 머릿속에 있는 '암묵지(tacit knowledge)'—이 프로젝트에서는 왜 이 라이브러리를 사용하는지, 왜 이 네이밍 규칙인지, 팀이 중요하게 생각하는 트레이드오프(trade-off)가 무엇인지—를 모르기 때문입니다. 제가 단순히 '인증 부분을 리팩토링해 줘'라고만 전달하고 기존 미들웨어의 사양이나 에러 핸들링 방식을 알려주지 않으면, AI는 일반적인 교과서 통의 구현만을 내놓을 뿐입니다.
한번은 권한 로직 수정을 요청했더니, 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 전제로 한 코드를 내놓았습니다. 하지만 저희 프로젝트는 속성 기반(Attribute-Based Access Control, ABAC)이고, 특정 조건에서만 권한을 완화하는 독자적인 확장이 들어가 있었습니다. AI의 제안을 그대로 머지(merge)했다가는 실제 서비스에서 권한 상승 버그가 발생할 뻔했습니다. 코드 리뷰에서 동료에게 지적받고 식은땀을 흘렸던 그 순간, 'AI는 유능한 주니어 엔지니어다. 하지만 컨텍스트(context)를 제공하지 않으면, 위험한 코드를 자신만만하게 작성한다'라는 것을 깨달았습니다.
그 이후로는 프롬프트에 '이 파일은 ○○이라는 역할을 하고, ○○이라는 제약 조건이 있다', '기존의 ○○ 패턴에 맞춰줬으면 좋겠다'라며 문서나 관련 파일의 경로를 붙여 넣게 되었습니다. 처음에는 귀찮았지만, 이 '컨텍스트 제공'의 질에 따라 출력 정확도가 극적으로 달라지는 것을 체감한 후로는 당연한 의식이 되었습니다.
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
최신 툴/트렌드 정보를 즈んだもん×めたん이 해설하는 YouTube 채널을 운영하고 있습니다!
좋아요와 채널 구독을 해주시면 감사하겠습니다🙇♂️
Hajimeru.dev: https://hajimeru-dev.vercel.app/
'혼자 계속하기 어렵다', '무엇부터 배워야 할지 모르겠다'는 분들을 위해,
프로그래밍 1:1 레슨 서비스 'Hajimeru.dev'도 운영하고 있습니다.
미경험 OK, 온라인 완결, 월정액/위약금 없음이니 편하게 무료 상담 받아보세요🙇♂️
해외 테크 뉴스를 따라가고 싶지만, 영어나 정보량이 많아 힘들다는 분들을 위해,
Hacker News의 화제를 일본어로 간편하게 추적할 수 있는 'HackerNews 일본어 요약 & AI 요약'
을 개인 개발했습니다!
기술 트렌드 수집에 사용해 주시면 감사하겠습니다🔥🙇♂️
→ HackerNews 일본어 요약 & AI 요약: https://hn-matome-2ht.pages.dev/
'냐ㄴ파이아 서바이버(Nyanpaire Survivor)'라는 뱀파이어 서바이버 리스펙트의 게임을 만들었습니다!
혹시 괜찮으시면 플레이해 주시면 감사하겠습니다😭
학원 선생님들을 위해, SNS 게시물/학생 모집/학부모 통지문 문구를 AI로 생성하는 웹 서비스 'おしらせAI'를 개인 개발했습니다. Next.js + Supabase + LLM으로 구성되어 있으며, 무료로 월 10회까지 체험할 수 있습니다. 한번 사용해 보세요.
→ おしらせAI: https://oshirase-ai.vercel.app/
전하고 싶은 말이 잘 전달되지 않는다'는 분들을 위해, 대화 표현을 첨삭하는 '伝え方ラボ(Tsutaekata Lab)'를 개발 중입니다.
상황에 맞춰 자신의 말로 답변하면, 무엇이 전달되지 않았는지 지적과 함께 바로 사용할 수 있는 대체 표현이 돌아옵니다.
ChatGPT와 상담할 경우 칭찬으로 시작해서 고쳐야 할 부분이 남는 경향이 있어, 지적하는 쪽으로 방향을 잡았습니다.
현재는 공개 시 공지 이메일 등록만 받고 있습니다🙇♂️
→ 伝え方ラボ: https://tsutaekata-lab.pages.dev/
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
어느 정도 프롬프트 엔지니어링(Prompt Engineering)에 익숙해지자, 다음 단계에서 빠진 함정은 바로 '모든 것을 AI에게 맡기려 하고 스스로 생각하는 것을 멈추는' 것이었다. 복잡한 도메인 로직을 '요구사항 정의서(Requirement Specification Document)를 줄 테니 구현해 줘'라며 통째로 위임하면, 작동하는 코드는 돌아온다. 하지만 막상 버그가 발생하거나 사양 변경이 생겼을 때 '왜 이 설계를 했는지' 스스로 설명할 수 없게 된다. 코드의 오너십(Ownership)이 자신에게 없는 상태, 즉 '블랙박스를 안고 가는' 공포를 느꼈다.
전환점은 한 성능 개선 작업이었다. N+1 문제 해결은 단순히 includes나 joins를 넣는 것만으로는 부족했다. 캐시 전략(Cache Strategy), 데이터베이스 인덱스(Database Index), API의 응답 형식 호환성, 프론트엔드의 렌더링 타이밍 등 여러 레이어에 걸친 트레이드오프(Trade-off)가 존재했다. 처음에는 AI에게 '최적화해 줘'라고 던지고 나온 SQL과 코드를 바라보았다. 하지만 '이게 정말 맞는 건가? 여기서 캐시를 넣으면 다른 엔드포인트에서 일관성이 깨지지는 않을까?'라는 의문이 생겨나, 직접 손을 움직여 쿼리 플랜(Query Plan)을 보거나 기존 코드를 추적하기 시작했다.
그때부터 AI를 '지금은 이런 가설로 검증하고 있는데, 이 접근 방식의 리스크는 뭐라고 생각해?', '이 쿼리 플랜 읽는 거 맞지?'와 같이 질문하는 형태로 사용하기 시작했다. 그러자 AI는 '그 가설이라면 여기가 병목(Bottleneck)이 될 것 같다', '그 캐시 무효화 타이밍은 레이스 컨디션(Race Condition) 리스크가 있습니다'라며 내가 미처 깨닫지 못했던 시점을 돌려주기 시작했다.
'만들어내게 하는 것'이 아니라 '사고의 벽치기 상대'로 사용하는 것이다. 스스로 가설을 세우고, 조사하고, 여러 설계안을 준비한 뒤 '어느 쪽이 더 나아? 왜?'라고 묻는 방식이다. 이 스타일로 바꾼 후 코드 품질은 올라갔고, 무엇보다 '내가 설계했다'라는 납득감과 자신감을 가질 수 있게 되었다. AI는 답을 주는 선생님이 아니라, 너무 똑똑해서 가끔 폭주하는 페어 프로그래머(Pair Programmer) 같다. 핸들은 항상 내가 잡는다. 그렇게 결정한 후 정신적인 여유가 생겼다.
팀 개발에서 시간이 가장 많이 소요되는 것이 풀 리퀘스트(Pull Request, PR) 리뷰 왕복이다. '변수명이 규칙과 달라', '이 로직은 공통화할 수 있어', '테스트 케이스가 부족해'── 지적받는 내용의 80%는 스스로 깨달을 수 있었던 '사소한 실수(凡ミス)'나 '정형적인 체크'들이다. 하지만 마감일이 다가오면, 무심코 git push를 하고
AI에게 "이 PR, 체크리스트에 빠진 게 없는지 봐"라고 던져서 더블체크하게 하는 것도 방법이다. 다만, 최종 판단은 사람이 해야 한다. AI가 "문제없다"고 해도, 비즈니스 로직의 타당성까지는 판단할 수 없기 때문이다. 이 "기계적인 체크는 AI에게 맡기고, 본질적인 설계 판단은 사람이 하는" 역할 분담이 팀 전체의 심리적 안정감에도 연결되는 것 같다. 리뷰어들도 "사소한 지적을 할 죄책감"에서 해방되어, 아키텍처나 UX에 대한 깊은 논의에 시간을 쓸 수 있게 되었다.
6년 차가 되어서도, 다뤄본 적 없는 기술 스택에 배정되는 경우가 있다. 지난달 갑자기 "다음 달부터 Next.js의 App Router로 신규 프로젝트를 시작할 거니까, 따라잡아 줘"라는 말을 들었을 때, 솔직히 "또 처음부터 공부해야 하나..."라며 무거운 몸이 움직이지 않았다. 공식 문서를 읽어도 Server Components와 Client Components의 경계선, Suspense와 Streaming의 동작 방식, Server Actions의 보안 모델 등 개념이 너무 많아서 어디서 손대야 할지 모르겠다.
그래서 AI에게 "Next.js App Router의 전체 개요를, 기존 Pages Router 경험자들을 위해, 개념도와 코드 예시가 포함된 튜토리얼을 30분 만에 이해할 수 있도록 만들어줘"라고 요청했다. 그러자 AI는 "마인드셋의 변화", "데이터 페치(data fetch)의 패러다임 시프트", "렌더링 라이프사이클의 차이" 같은 목차로, 비교표와 최소한으로 작동하는 샘플 코드를 정리해 주었다. "use client를 작성해야 하는 기준", "generateStaticParams의 사용처", "폼 전송의 Server Action 전환 패턴" 등, 정말 "현장에서 즉시 활용 가능한 지식"만 추출해 주고 있었다.
더 나아가, "이 코드는 왜 Client Component로 해야 해?", "Server Component에서 useState를 쓰면 어떻게 망가져?"와 같은 "왜?"라는 질문을 그 자리에서 할 수 있다는 점이 크다. 문서를 읽고 '흥미롭네' 하고 끝내는 것이 아니라, 자신의 언어로 의문을 제기하고 AI의 답변을 자신의 언어로 요약해서 메모한다. 이 "질문 → 답변 → 자신의 언어로 재구성" 사이클을 빠르게 돌릴 수 있는 것이 AI 동반 학습(AI-assisted learning)의 강점이다.
실제로 1주일 만에 따라잡아서 팀 내 스터디를 열고 "App Router 전환 시 핵심 포인트"를 발표할 수 있었다. 자료 제작도 AI에게 "이 내용으로 슬라이드 구성안 내줘", "다이어그램의 Mermaid 문법 써줘"라고 부탁해서 시간을 단축했다. 물론, 공식 문서나 RFC(Request for Comments)를 1차 정보로 확인하는 것은 빠뜨리지 않았다. 하지만 "무엇부터 읽어야 할지", "어디가 걸리는 부분인지"를 AI에게 알려주는 것만으로도 학습 비용이 체감상 1/3로 줄었다. 미지의 영역에 대한 공포심, 즉 '또 제로(zero)부터인가'가 '일단 AI에게 전체 개요를 물어보자'로 바뀐 순간, 기술 따라잡기가 고통이 아니라 '탐험'이 되었다.
이렇게 편리하다 보니, 무의식적으로 "생각하는 것을 AI에 위임해 버리면 안 되나?"라는 유혹을 느낀다. 실제로 나도 피곤할 때는 "이 버그 수정해 줘"라며 통째로 던져주고, 나온 수정을 테스트도 제대로 하지 않고 커밋할 뻔한 적이 있다. 하지만 그 지점에서 브레이크를 거는 규칙을 스스로에게 만들었다.
'왜 이 수정으로 고쳐지는지'를 자신의 언어로 설명할 수 없는 코드는 머지(merge)하지 않는다.
AI가 제안한 여러 선택지 중 '왜 이것을 골랐는지'를 커밋 메시지나 PR 설명에 남긴다.
주 1회는 'AI 없이 1시간 동안 코드를 쓰는 시간'을 확보한다 (근력 운동과 같다).
세 번째가 특히 효과적이다. AI 없이 쓰면, 자동 완성이나 리팩토링 제안이 없다. 변수 이름을 고민하고, 타입 정의를 오가며, 테스트 케이스를 손으로 작성한다. 엄청 느리고 스트레스다. 하지만 그 '느리고 힘든 시간'이야말로 자신의 엔지니어로서의 기초 체력, 즉 "코드의 냄새를 맡는 후각", "설계의 핵심 포인트", "디버깅의 가설 설정 능력"을 유지하는 유일한 트레이닝임을 깨달았다.
AI는 프로틴이나 보충제와 같다. 트레이닝(스스로 생각하고 손으로 움직이는 것) 없이 섭취해도 근육(엔지니어링 역량)은 생기지 않는다. 반대로, 트레이닝을 제대로 한 후에 AI를 보조적으로 사용하면 믿을 수 없을 만큼 빠르게 성장할 수 있다. 이제 막 시작하는 너에게 특별히 전하고 싶은 것이 있다. "AI가 작성하게 하는 연습"보다 "AI와 토론하며 자신의 설계를 다듬는 연습"을 쌓아줬으면 한다. 그쪽이 5년 후, 10년 후에 "그때 AI에게 전부 맡기지 않길 잘했다"라고 진심으로 생각할 수 있는 커리어가 될 것이다.
Claude Code를 포함한 AI 어시스턴트와 반년을 보내면서, 저의 개발 스타일은 '코드를 작성하는 사람'에서 '설계하고 판단하며, AI를 능숙하게 활용하는 사람'으로 변화했습니다. 마법 지팡이도, 자신을 대체할 위협도 아닌, **'맥락을 주면 유능하게 일하지만, 약간 참견하기 좋아하는 주니어 엔지니어'**로 대하는 것이 현재 가장 편안합니다.
문맥(Context)을 풍부하게 전달하고, 벽치기 상대처럼 질문하며, 기계적인 검토를 자동화하여 본질에 집중하고, 미지의 기술 지도를 그려내게 하는 것. 그리고 무엇보다도 핸들을 스스로 잡고 계속 운전하는 것. 이러한 점들을 의식하기 시작하면서, 코드를 작성하는 것이 '작업'에서 '지적 게임'으로 변한 느낌이 듭니다.
여러분도 오늘 밤 에디터를 열기 전에 AI에게 단 한 번만 "지금 할 작업에 이런 배경과 이런 제약 조건이 있는데, 어떻게 접근하면 좋을까?"라고 물어봐 주었으면 합니다. 돌아온 답변에 납득이 가지 않는다면, 자신의 아이디어를 제시해 보면 됩니다. 이러한 상호작용의 축적이 분명 여러분만의 '최강 파트너'를 만드는 방법이 될 것입니다. 내일부터도 함께 즐겁게 코드를 작성해 나갑시다.
