"내 동료는 AI입니다" 세미나 후기: AI, '제대로' 사용하는 법

[안내]

본 포스팅은 구름 9월 COMMIT 에서 진행된 '내 동료는 AI입니다: 코딩 위임 1년, 그 과정과 개발 조직의 변화' 세션의 내용을 듣고, 핵심 내용을 요약 및 정리한 후기입니다.

 

들어가며.

최근 개발자 커뮤니티의 가장 뜨거운 화두는 단연 AI입니다. 많은 분들이 cursor, claude code, codex 등과 같은 도구를 사용합니다. 하지만 솔직히 얼마나 그 결과물을 신뢰하시나요? AI가 짜준 코드를 의심 없이 그대로 쓰기보다, 내가 짠 코드의 '오타 수정'이나 조금 편한 ‘자동 완성’, '보일러플레이트 생성' 수준에서 활용하고 있지는 않으신가요? (사실 저도 별반 다르지 않습니다.)

 

최근 채널톡 리드 웹 엔지니어 송동욱 님의 "내 동료는 AI입니다: 코딩 위임 1년, 그 과정과 개발 조직의 변화" 세미나에 참석했습니다. 이 세션은 AI를 단순 보조 도구가 아닌, 코딩 작업을 위임할 수 있는 '동료'로 삼으며 개발 패러다임을 전환한 경험을 공유하는 자리였습니다. 개인적으로 꽤 신선한 충격을 받았는데요. 이 글을 통해 세미나의 핵심 내용을 공유하고자 합니다.

---

패러다임의 전환: AI는 보조가 아닌 '주체'.

이번 세미나의 핵심 메시지를 한 줄로 요약하면 다음과 같습니다.

"AI가 코드를 짜고, 사람은 리뷰한다."

 

혹시 '바이브 코딩' 이야기일까요? 어쩌면 그럴지도요. 하지만 이 방법론은 '감'에 의존하는 막연한 바이브 코딩이 아니라, 충분한 ‘맥락’ 제공, 철저한 '설계', 그리고 꼼꼼한 ‘리뷰’에 기반하고 있다는 점이 큰 차이점입니다.

 

우리는 종종 AI가 생성한 코드가 마음에 들지 않을 때 "역시 AI는 아직 멀었어"라고 생각하곤 합니다. 하지만 세미나에서는 그 이유가 AI의 능력이 부족해서가 아니라, 우리가 '충분한 맥락(Context)'을 제공하지 않았기 때문이라고 지적합니다.

 

연사자 동욱님이 아주 적절한 비유를 들어 해당 내용을 강조해주셨는데요.

"그냥 코드를 짜달라고 하는 건 길 가던 사람을 붙잡고 '우리 집 냉장고에 있는 재료로 최고의 요리를 만들어줘'라고 하는 것과 같다. 그 사람은 우리 집 냉장고에 뭐가 있는지, 내가 어떤 요리를 좋아하는지 전혀 모른다."

 

AI도 마찬가지입니다. 비즈니스 요구사항, 기존 코드의 문제점, 기술 스택, 팀의 코딩 컨벤션 등 충분한 맥락 없이는 절대 만족스러운 코드를 내놓을 수 없습니다. 사람의 생각을 풀어내며, 이를 체계적으로 정리하고, 그 과정을 통해 AI가 코드를 작성하도록 하면 성공적인 위임이 가능하다고 설명합니다.

 

이 설명을 듣고 저는 요즘 뜨고 있는 컨텍스트 엔지니어링(Context Engineering)의 이야기라고 생각했습니다. 과연 프롬프트를 통해 얼마나 충분한 정보 (맥락)을 AI에게 제공했느냐에 따라 코드 생성의 결과물이 무척 달라지기 때문이죠.

---

AI와의 효과적인 협업을 위한 실천 가이드.

이번 세미나에서는 어떤 식으로 맥락을 잘 만들어서 주입시킬 수 있는지 구체적인 액션 방법을 제시하였습니다.

무작정 코드 생성을 막는 것부터 시작하기

가장 먼저 할 일은 AI가 성급하게 코드를 생성하지 못하게 막는 것입니다. Cursor와 같은 툴의 User Rules에 다음과 같은 규칙을 설정하는 것이죠.

"질문을 받으면 바로 코드를 생성하지 마. 먼저 문제 분석과 해결 방향에 대해 제안하고 내 확인을 받아줘. 코드 작성은 가장 마지막 단계야."

 

이를 통해 우리는 AI와 함께 문제의 본질을 파고들고, 해결책에 대한 깊이 있는 논의를 시작할 수 있습니다.

특히 cursor의 agent(composer) 모드를 사용하는 경우, 요청 사항에 대해 거의 즉각적으로 코드부터 작성하는 경험을 자주 했는데요, 섣불리 잘못 작성된 코드나 수정된 코드를 보면서 불필요한 핑퐁을 더 해야 하는 경우가 있었습니다.

동욱님이 알려주신 이 같은 규칙을 설정하는 것이 AI와의 불필요한 커뮤니케이션 핑퐁과 토큰 낭비를 막아주며, 제가 원하는 코드를 작성하도록 하는 데에 더 용이하다는 생각이 들었습니다.

 

기대치 맞추기 - 'Why, What, Where'를 명확히 하기

AI와 대화를 시작할 때는 다음의 맥락을 명확히 전달해야 합니다.

• Why: 왜 이 코드를 수정해야 하는가? (비즈니스 요구사항, 버그, 성능 개선 등)
• What: 구체적인 요구사항은 무엇인가?
• Where: 이 코드가 사용되는 범위는 어디인가?

결국, 좀 더 나은 코드 생성을 위해서는 보다 구체적인 프롬프트 작성이 필요해졌습니다. LLM에게 어떻게 내가 가진 정보를 잘 조합해서 넘겨주느냐가 중요해졌고, 이로 인해 문서화를 잘 해두는 것이 역설적이게도 AI 시대에 더욱 중요해졌다고 할 수 있습니다.

세미나에서는 AI에게 도움이 되는 문서화를 위해 아래와 같은 액션들을 실행해 볼 것을 권장했습니다.

• 자주 쓰이는 프롬프트는, 커서룰 (claude.md)로 만들기
• 프로젝트의 기술 스택, 컨벤션 등은 지속적으로 커서룰을 다듬기
• 도메인 별로 중요한 비즈니스 로직도 적어두기
• 테크 스펙을 Repository 안에 보관해보기
• pr 리뷰하는 커서룰을 만들어 리뷰 과정을 간소화 하기
• 팀에서 커서 룰을 지속적으로 관리하고 코드의 일부처럼 다루기

 

문제와 작업을 쪼개기

본격적인 작업을 시작할 때는 해결하려는 큰 문제를 AI가 이해하고 다룰 수 있는 작은 단위로 나누는 것입니다. 왜 AI와의 협업에서는 작업을 작은 단위로 나누는 것 중요할까요?

 

세미나에서는 다음과 같은 이유로 작업 단위를 작게 나누는 것이 좋다고 설명합니다.

• AI 변경 제어 및 리뷰 용이성: AI가 생성한 코드나 답변 등 모든 결과물은 사람이 반드시 리뷰해야 합니다. 작업을 작은 단위로 지시하고(작게 변경시키고) 그 결과를 바로바로 리뷰하는 것은 AI의 변경 사항을 효과적으로 제어하고 검토를 용이하게 만드는 핵심 수단입니다.
• 작업 결과 보존: 작업이 길어질 경우, AI와의 대화나 작업 결과물을 기록으로 남겨 보존할 필요가 있습니다.

[여기서 잠깐] 긴 작업의 컨텍스트(대화 맥락) 관리 방법

AI는 정해진 '컨텍스트 윈도우(Context Window)' 때문에 대화가 길어지면 앞부분을 잊어버리는 문제가 발생합니다. 따라서, 현재 작업과 관련이 없는 부가적인 질문은 새로운 채팅 세션을 이용하는 것이 좋고, 장기 작업은 대화 내용을 마크다운 파일로 정리해두는 것이 추후 작업을 이어나가는 데에 좋다고 합니다.

 

AI에게 질문 받아보기

작업 단위가 정해졌다면, AI에게 바로 코드를 요청하는 것이 아니라 시니어 동료와 대화하듯 문제에 대해 깊이 논의합니다.

"이 문제를 해결하기 위해 내가 더 알려줘야 할 정보가 있을까?" 와 같이 AI가 질문하도록 유도하거나, "내가 제안한 해결책의 잠재적인 문제점을 비판적으로 검토해줘." 라고 요청하며 함께 최적의 해결책을 찾아 나갑니다.

 

디자인 패턴을 활용하기

정리되지 않은 코드는 사람 뿐 아니라 LLM (AI)에게도 이해하기 어렵기 때문에, 우리는 보다 정제된 코드로 소통을 해야 합니다. 세미나에서는 그 방법 중 하나로 디자인 패턴을 활용하도록 제안합니다. 디자인 패턴이 사용된 깨끗한 코드 베이스는 AI와 논의를 더 수월하게 만들어 줍니다. 잘 정리된 코드는 AI가 시스템의 구조와 의도를 더 정확하게 파악하도록 도와주며, 이는 곧바로 결과물의 품질로 이어집니다. "이 부분은 Factory 패턴을 적용해서 리팩터링하고 싶어"와 같이 명료한 의도를 전달할 수 있게 됩니다.

이 부분은 특히 연사자 동욱님이 강조하셨던 부분이었고, 저 역시도 크게 공감했던 부분이었습니다.

 

최종 리뷰 단계

이제 코드를 생성하기 전, 마지막 리뷰를 통해 어떤 식으로 코드가 생성될 지 예측해봅니다. Mermaid 다이어그램 등 다이어그램을 그려달라고 요청하여, 코드 얼개가 어떻게 될 지 충분히 고민하고, 만약 원하는 방향이 아니라면 프롬프팅을 다시 하면 됩니다.

충분히 만족스러운 다이어그램이 완성되면, 리뷰를 마치고 코드 작성 단계로 나아가면 됩니다.

 

코드 작성하기

이제 바로 코드 생성을 진행하면 됩니다. 여기서 생성되는 코드는 범위가 명확하기 때문에 예측 가능하고, 다이어그램을 충분히 검토했기 때문에 코드 리뷰 또한 쉽습니다. 게다가 이미 작게 나뉘어진 단위로 작업을 진행했기 때문에, 커밋을 쪼개는 것도 어렵지 않게 됩니다.

 

이렇게 올라간 PR은 코드래빗 같은 도구를 활용하여 보다 쉽게 PR 리뷰를 하게 됩니다. 충분한 리뷰가 이뤄진 다음에 승인과 머지의 과정을 거쳐 작업이 마무리됩니다.

---

AI를 제대로 활용하는 엔지니어가 되려면.

정리하자면, 우리가 원하는 방향대로 AI가 개발을 하도록 하려면 우선 AI에게 최대한 많은 정보를 전달해야 합니다. 공통 정보는 저장을 하고, 언어로 전달이 어려운 경우라면 Indexing이나 MCP 등 다른 방법을 사용해야 합니다. 이렇게 전달할 정보를 만들고 2차 가공하는 것 또한 AI에게 위임할 수도 있습니다.

 

결국 AI를 적극적으로 활용하는 엔지니어는 LLM에게 어떻게 내가 가진 정보를 잘 조합해서 넘겨주느냐의 문제를 해결하는 사람이 될 것입니다. 각종 비즈니스 로직과 컨벤션들, 외부 정보들을 잘 정리하여 관리할 수 있어야 할 것입니다. 이러한 패러다임이 정착되면 엔지니어의 시간 배분은 극적으로 변합니다.

• AS-IS: 1시간 고민 + 9시간 코딩
• TO-BE: 4시간 고민/설계 + 1시간 코딩

단순 반복적인 코딩 작업은 AI에게 위임하고, 개발자는 비즈니스를 더 깊이 이해하고, 더 나은 아키텍처를 설계하며, '진짜 문제'를 해결하는 데 시간을 쏟게 됩니다. 엔지니어의 본질은 결국 문제를 해결하는 사람이기 때문입니다.

---

마치며.

이번 세미나는 AI 시대를 살아갈 개발자들에게 매우 중요한 질문을 던졌습니다. 우리는 AI라는 강력한 레버리지를 어떻게 활용하여 개인의 성장과 조직의 생산성을 모두 잡을 수 있을까요?

 

이제 코딩은 AI에게 맡기고, 우리는 더 창의적이고 본질적인 문제 해결에 집중해야 할 때가 오고 있다고 느껴졌습니다. 그동안 AI 도구를 사용하면서 AI의 결과물에 만족하지 못한 저 스스로를 되돌아보게 만들었던 시간이었고, AI에게 코딩을 '위임'하는 연습을 좀 더 해야겠다는 생각이 들었습니다.

 

채널톡 기술 블로그에서는 위 내용 외에도 실제 AI 생산성 증진 사례를 상세히 소개하고 있으니, 관심 있으신 분들은 한번 방문해보시길 추천합니다.