책임감 있는 개발자를 위한 AI 코딩 도구의 실질적인 활용법

지난 2년 동안 Work & Co의 저희 팀과 저는 대중이 사용하는 웹 경험을 출시하는 데 도움을 얻기 위해 Copilot, Cursor, Claude, ChatGPT와 같은 AI 코딩 도구들을 테스트하고 점진적으로 통합해 왔습니다. 솔직히 말해서, 초기에는 회의적인 시각도 있었고 몇 번의 깨달음(aha moments)을 얻은 후, 다양한 AI 도구들이 저의 일상적인 사용 방식에 자리 잡게 되었습니다. 시간이 흐르면서 AI에게 맡기는 것이 합리적이라고 판단되는 애플리케이션 목록이 늘어났고, 이에 따라 저는 제가 이른바 "책임감 있는 개발자"라고 부르는 이들을 위한 AI 도구의 **실질적인 활용 사례(practical use cases)**를 공유하기로 했습니다.

제가 말하는 책임감 있는 개발자란 무엇일까요?

우리는 이해관계자와 클라이언트가 기대하는 대로 품질 높은 코드를 전달해야 합니다. 우리의 기여(즉, 풀 리퀘스트 (pull requests))가 우리의 작업을 리뷰하고 테스트해야 하는 동료들에게 부담이 되어서는 안 됩니다. 또한, 회사에 다니고 있다면 다음과 같은 점을 유의해야 합니다. 우리가 사용하는 도구는 고용주로부터 승인을 받아야 합니다. 보안 및 개인정보 보호와 같은 민감한 측면은 적절하게 처리되어야 합니다. 정책 승인 없이 비밀 키(secrets), 고객 데이터(PII), 또는 독점 코드를 도구에 붙여넣지 마십시오. 이를 인터넷상의 낯선 사람이 작성한 코드처럼 취급하십시오. 항상 테스트하고 검증하십시오.

참고: 이 기사는 VSCode 내의 Copilot이나 Cursor와 같은 AI 코딩 도구에 대한 매우 기본적인 친숙함이 있다고 가정합니다. 만약 이 모든 것이 완전히 새롭고 생소하게 느껴진다면, Github Copilot 비디오 튜토리얼이 훌륭한 시작점이 될 수 있습니다.

AI 코딩 도구의 유용한 활용 사례

참고: 다음 예시들은 주로 React, Vue, Svelte 또는 Angular와 같은 JavaScript 기반 웹 애플리케이션에서 작업하는 것에 초점을 맞춥니다.

생소한 코드베이스 이해하기

기존에 구축된 코드베이스에서 작업하는 것은 흔한 일이며, 거대한 레거시(legacy) 코드베이스에 합류하는 것은 위협적으로 느껴질 수 있습니다. 단순히 프로젝트와 AI 에이전트(저의 경우 VSCode의 Copilot Chat)를 열고, 동료에게 질문하듯이 질문을 시작해 보세요. 일반적으로 저는 어떤 AI 에이전트와 대화하든 동료 인간과 대화하는 것처럼 대하는 것을 선호합니다.

더 정교하게 다듬어진 프롬프트(prompt) 예시는 다음과 같습니다:

“고수준 아키텍처 개요(high-level architecture overview)를 알려줘: 엔트리포인트(entrypoints), 라우팅(routing), 인증(auth), 데이터 레이어(data layer), 빌드 도구(build tooling). 그다음 읽어야 할 파일 5개를 순서대로 나열해줘. 설명은 가설로 취급하고, 참조된 파일로 바로 이동하여 확인해줘.”

“라우팅(routing)이 구체적으로 어떻게 작동해?” 또는 “인증(authentication) 프로세스와 방식에 대해 설명해줘”와 같은 후속 질문을 계속 던질 수 있으며, 이는 익숙하지 않은 코드베이스(codebase)의 불투명한 부분을 밝혀낼 수 있는 유용한 방향으로 여러분을 안내할 것입니다.

의존성 업그레이드 시 중대한 변경 사항(Breaking Changes) 분류하기

npm 패키지를 업데이트하는 작업, 특히 중대한 변경 사항(breaking changes)이 포함된 경우에는 지루하고 시간이 많이 걸리는 작업이 될 수 있으며, 상당한 양의 회귀(regressions) 버그를 디버깅해야 할 수도 있습니다. 최근 저는 데이터 시각화 라이브러리인 plotly.js를 메이저 버전 2에서 3으로 업그레이드해야 했는데, 그 결과 일부 그래프의 축 레이블(axis labeling)이 작동하지 않게 되었습니다.

저는 ChatGPT에게 다음과 같이 질문했습니다:

“Plotly를 사용하는 Angular 프로젝트를 업데이트했어. plotly.js — dist 패키지를 버전 2.35.2에서 3.1.0으로 업데이트했는데, 이제 x축과 y축의 레이블이 사라졌어. 무슨 일이 일어난 거지?”

에이전트는 즉시 해결책을 제시했습니다(아래에서 직접 확인해 보세요).

참고: 저는 수정 사항을 배포하기 전에 공식 마이그레이션 가이드(migration guide)를 통해 해당 설명을 여전히 검증했습니다.

여러 파일에 걸친 리팩터링(Refactors)을 안전하게 복제하기

성장하는 코드베이스(codebases)는 코드 통합(code consolidation)의 기회를 반드시 제공합니다. 예를 들어, 여러 파일에 걸쳐 중복된 코드가 있어 이를 하나의 함수나 컴포넌트로 추출할 수 있다는 것을 발견할 수 있습니다. 결과적으로, 대신 포함할 수 있는 공유 컴포넌트를 만들기로 결정하고 한 파일에서 해당 리팩터링(refactor)을 수행합니다. 이제 남은 파일들에 대해 수동으로 변경 사항을 적용하는 대신, 에이전트에게 리팩터링을 대신 수행하도록 요청할 수 있습니다.

에이전트 (Agents)를 사용하면 여러 파일을 컨텍스트 (context)로 선택할 수 있습니다. 한 파일에 대한 리팩터링 (refactor)이 완료되면, 리팩터링된 파일과 수정되지 않은 파일을 모두 컨텍스트에 추가한 뒤 에이전트에게 다음과 같이 프롬프트 (prompt)를 입력하여 다른 파일에도 변경 사항을 적용하도록 요청할 수 있습니다: “파일 A에서 수행한 변경 사항을 파일 B에도 동일하게 적용해줘”.

익숙하지 않은 기술로 기능 구현하기

AI 코딩 도구를 사용하면서 제가 가장 짜릿함을 느꼈던 순간 중 하나는, 제가 상당히 생소했던 언어인 GLSL을 사용하여 꽤 복잡한 애니메이션 그라데이션 (animated gradient) 애니메이션을 만드는 데 도움을 받았을 때였습니다. 최근 프로젝트에서 디자이너들이 3D 오브젝트의 로딩 상태로 사용할 애니메이션 그라데이션을 제안했습니다. 저는 그 컨셉이 정말 마음에 들었고, 고객들에게 독특하고 흥미로운 결과물을 전달하고 싶었습니다. 문제는 구현할 시간이 이틀밖에 없었다는 점과, GLSL은 학습 곡선 (learning curve)이 상당히 가파르다는 것이었습니다.

이번에도 AI 도구 (이 경우에는 ChatGPT)가 유용하게 쓰였습니다. 저는 우선 캔버스 (canvas)를 렌더링하고 매우 단순한 애니메이션 컬러 그라데이션을 보여주는 독립적인 HTML 파일을 만들어 달라고 아주 간단하게 프롬프트를 입력하며 시작했습니다. 단계별로 AI에게 더 정교한 디테일을 추가하도록 프롬프트를 입력했고, 마침내 실제 코드베이스 (codebase)에 셰이더 (shader)를 통합할 수 있을 만큼 괜찮은 결과물에 도달했습니다.

최종 결과: 고객들은 매우 만족해했고, 저희는 AI 덕분에 짧은 시간 안에 복잡한 기능을 구현하여 전달할 수 있었습니다.

테스트 작성하기

제 경험상, 프로젝트 진행 중에 적절한 유닛 테스트 (unit test) 및 통합 테스트 (integration test) 세트를 지속적으로 작성하고 유지 관리할 수 있는 시간은 거의 부족하며, 게다가 많은 개발자가 테스트를 작성하는 작업을 그리 즐기지 않습니다. AI 도우미에게 테스트를 설정하고 작성하도록 프롬프트를 입력하는 것은 완전히 가능하며 짧은 시간 안에 수행할 수 있습니다. 물론 개발자로서 여러분은 테스트가 애플리케이션의 핵심 부분을 실제로 검토하고 있는지, 그리고 합리적인 테스트 원칙을 따르고 있는지 반드시 확인해야 하지만, 테스트 작성 자체는 AI 도우미에게 "외주"를 줄 수 있습니다.

프롬프트 예시:

“Jest를 사용하여 이 함수에 대한 단위 테스트 (unit tests)를 작성해줘. 해피 패스 (happy path), 엣지 케이스 (edge cases), 그리고 실패 모드 (failure modes)를 모두 포함해줘. 각 테스트가 존재하는 이유를 설명해줘.”

심지어 다음과 같이 테스트 전문가인 Kent C. Dodds의 테스트 모범 사례 (testing best practices)를 가이드라인으로 에이전트에게 전달할 수도 있습니다.

내부 도구 (Internal Tooling)

앞서 언급한 셰이더 (shader) 예시와 다소 유사하게, 최근 저는 코드베이스의 코드 중복 (code duplication)을 분석하고 리팩터링 (refactor) 전후를 비교하는 작업을 맡았습니다. 파일을 수동으로 비교하는 데 시간이 많이 걸리는 방식을 피하고 싶다면, 이는 결코 사소한 작업이 아닙니다. Copilot의 도움을 받아 저는 코드 중복을 분석하고, 출력 내용을 표 형식으로 정리하며, 이를 Excel로 내보내는 스크립트를 생성했습니다. 그 후 한 단계 더 나아갔습니다. 코드 리팩터링이 완료되었을 때, 저는 에이전트에게 기존 Excel 시트를 기준점 (baseline)으로 삼아 현재의 중복 상태를 별도의 열에 추가하고 그 차이 (delta)를 계산하도록 프롬프트를 입력했습니다.

오래전에 작성된 코드 업데이트하기 (Updating Code Written A Long Time Ago)

최근 한 오래된 고객으로부터 연락을 받았습니다. 시간이 흐르면서 그의 웹사이트에 있는 몇몇 기능들이 더 이상 제대로 작동하지 않게 되었다는 내용이었습니다.

문제는 이 웹사이트가 거의 10년 전에 구축되었다는 점이었습니다. JavaScript와 SCSS는 requireJS와 같은 상당히 오래된 컴파일 도구 (compile tools)를 사용하고 있었고, 설정 방식은 제 2025년형 MacBook에서는 실행조차 되지 않는 구버전의 Node.js를 요구했습니다.

빌드 프로세스 (build process) 전체를 수동으로 업데이트하려면 며칠이 걸렸을 것이기에, 저는 AI 에이전트에게 다음과 같이 프롬프트를 입력하기로 했습니다. “JS와 SCSS 빌드 프로세스를 Vite와 같은 간결한 2025년형 스택 (stack)으로 업데이트해줄 수 있어?” 결과는 확실했습니다. 에이전트와 함께 약 한 시간 동안 다듬는 과정을 거친 후, 제 SCSS와 JS 빌드는 Vite로 전환되었고 저는 실제 버그 수정 (bugfixing)에 집중할 수 있었습니다. 다만, 빌드 프로세스에 이토록 중대한 변경을 가할 때는 출력물과 컴파일된 파일 (compiled files)을 반드시 적절히 검증해야 합니다.

요약 및 초안 작성 (Summarizing And Drafting)

최근의 모든 코드 변경 사항을 커밋 메시지(commit message)를 위해 한 문장으로 요약하고 싶으신가요? 아니면 긴 커밋 목록을 세 개의 불렛 포인트(bullet points)로 요약하고 싶으신가요? 문제없습니다. AI에게 맡기되, 반드시 교정(proofread) 과정을 거치시기 바랍니다.

프롬프트(prompt) 예시는 동료에게 메시지를 보내는 것만큼 간단합니다: “최근 변경 사항을 간결한 불렛 포인트로 요약해 줘”.

여기서 저의 조언은 GPT를 사용하여 글을 쓸 때 주의를 기울이라는 것이며, 코드와 마찬가지로 전송하거나 제출하기 전에 반드시 결과물을 확인하십시오.

권장 사항 및 모범 사례 (Recommendations And Best Practices)

프롬프팅 (Prompting)

AI를 사용할 때 그리 명확하지 않은 이점 중 하나는 프롬프트가 더 구체적이고 맞춤화될수록 결과물이 더 좋아진다는 것입니다. AI 에이전트(AI agent)에게 프롬프팅하는 과정은 우리가 코드를 작성하기 전에 **요구 사항을 가능한 한 구체적으로 공식화(formulate)**하도록 강제합니다. 이것이 일반적인 규칙으로서, 제가 프롬프팅 시 가능한 한 구체적일 것을 강력히 권장하는 이유입니다.

Remix의 공동 저자인 Ryan Florence는 초기 프롬프트를 다음과 같은 문장으로 끝냄으로써 이 과정을 개선할 수 있는 간단하면서도 강력한 방법을 제안합니다:

“시작하기 전에, 나에게 질문할 것이 있나요?”

이 시점에서 AI는 보통 사용자의 구체적인 의도를 명확히 할 수 있는 유용한 질문을 던지며, 에이전트가 작업에 대해 **더욱 맞춤화된 접근 방식(more tailored approach)**을 제공하도록 유도합니다.

버전 관리 사용 및 소화 가능한 단위로 작업하기 (Use Version Control And Work In Digestible Chunks)

git과 같은 버전 관리(version control)를 사용하는 것은 팀으로서 단일 코드베이스(codebase)에서 협업할 때 유용할 뿐만 아니라, 개인 기여자로서 비상 상황 발생 시 되돌아갈 수 있는 안정적인 지점을 제공합니다. AI는 비결정론적(non-deterministic) 특성 때문에 때때로 통제를 벗어나 사용자가 달성하려는 목적에 전혀 도움이 되지 않는 변경을 가하거나, 결국 복구 불가능하게 시스템을 망가뜨릴 수 있습니다.

작업을 **여러 개의 커밋 (multiple commits)**으로 나누면, 상황이 잘못되었을 때 되돌릴 수 있는 안정적인 지점을 만드는 데 도움이 됩니다. 또한, 코드가 의미론적으로 잘 구조화된 덩어리로 나뉘어 있으면 팀원들이 코드를 리뷰하기가 더 쉬워지므로 동료들도 당신에게 고마워할 것입니다.

철저하게 리뷰하기 (Review Thoroughly)

이는 일반적인 권장 사항(best practice)에 가깝지만, 제 생각에는 개발 작업에 AI 도구를 사용할 때 훨씬 더 중요해집니다. 바로 당신의 코드에 대한 첫 번째 비판적 리뷰어가 되라는 것입니다. 다른 사람의 코드를 리뷰할 때와 마찬가지로, 변경 사항을 한 줄씩 검토하는 시간을 반드시 갖고, 스스로의 셀프 리뷰(self-review)를 통과했을 때만 작업을 제출하십시오.

“현재 저에게는 두 가지 사실이 모두 진실입니다. AI 에이전트(AI agents)는 놀랍고 생산성을 크게 높여줍니다. 하지만 뇌를 끄고 완전히 통제권을 놓아버린다면, 그것들은 거대한 슬롭 머신 (slop machines, 저질 콘텐츠 생성기)이 됩니다.”

— Armin Ronacher, 그의 블로그 포스트 'Agent Psychosis: Are We Going Insane?' 중에서

결론 및 비판적 고찰 (Conclusion And Critical Thoughts)

제 생각에 AI 코딩 도구는 개발자로서 우리의 일상적인 생산성을 향상시키고, 더 많은 계획과 고차원적인 사고를 할 수 있도록 정신적 여유를 제공할 수 있습니다. 또한 AI는 우리가 원하는 결과를 세밀하고 상세하게 설명하도록 강제합니다.

어떤 AI든 때때로 환각 (hallucinate)을 일으킬 수 있으며, 이는 기본적으로 확신에 찬 어조로 거짓말을 한다는 것을 의미합니다. 따라서 특히 의구심이 들 때는 반드시 확인하고 테스트하십시오. AI는 만능 해결책 (silver bullet)이 아니며, 저는 개발자로서의 탁월함과 문제 해결 능력은 결코 유행을 타지 않을 것이라고 믿습니다.

이제 막 커리어를 시작하는 개발자들에게 이 도구들은 작업의 대부분을 대신 해주는 매우 유혹적인 존재가 될 수 있습니다. 여기서 놓칠 수 있는 부분은, 디버깅하고 해결하기 까다로운 버그와 이슈를 처리하는 과정, 즉 소위 "고된 반복 작업 (the grind)"이라 불리는 지치고 고통스러운 과정입니다. Cursor AI의 Lee Robinson조차 자신의 포스트 중 하나에서 이 점에 대해 의문을 제기합니다:

AI 코딩 도구 (AI coding tools)는 빠른 속도로 진화하고 있으며, 저는 다음에 무엇이 올지 기대됩니다. 여러분이 이 글과 제가 제안한 팁들이 도움이 되었기를 바라며, 여러분도 직접 이 기능들을 시도해 보고 싶다는 기대감을 느끼셨기를 바랍니다.