[3팀 박준형] Chapter 3-2 프론트엔드 테스트 코드 🦍

by BBAK-jun2025. 8. 26.

과제 피드백

수고했습니다. 이번 과제는 TDD 방법론을 실제로 경험해보면서 테스트 주도 개발의 Red-Green-Refactor 사이클을 체험하는데 목적이 있었습니다.

준형은 AI에 대해서 정말로 관심이 많아서 흥미로운 결과들을 계속 선보이고 있는 부분이 아주 재밌어 보입니다. BMAD Method라는 AI 멀티에이전트 협업 방식으로 접근한 점이 정말 흥미롭네요. 캘린더라는 이미 검증된 도메인이긴 했지만 192개 테스트를 모두 통과시키고 90% 이상 커버리지를 달성한 것은 상당히 놀랍네요. 협업 에이전트를 바탕으로 컨텍스트 엔지니어링을 통해 태스크를 만들어 진행한 부분은 단순히 구현이 아니라 매니징의 측면에서도 상당히 인사이트가 있었습니다.

다음은 제가 생각하는 질문에 대한 답변입니다. 다분히 주관적인 답변이라는 점 참고해주세요!

멀티에이전트 협업 방법론 평가 Q) 현재 구현한 BMAD Method(Brownfield Multi-Agent Development)가 실제 업무 환경에서도 적용 가능한지, 그리고 이 방법론을 더욱 발전시킬 수 있는 방향에 대해 조언해주실 수 있나요? 특히 에이전트 간 역할 분담과 품질 게이트 시스템의 효과성에 대한 피드백을 받고 싶습니다.

과제의 경우 캘린더라는 검증된 도메인이지만 실제 업무 환경에서는 학습이 많이 되어 있지 않은 내용을 다룬다거나 거대 소스코드와 컨텍스트를 다루게 되므로 이 부분이 AI가 소화해낼 수 있는 분량일지는 검토가 필요하겠네요.

현재 방식은 결과적으로 상당히 많은 문서를 만들어 내고 있는데요, 이 모든 것들을 관계자들이 안 읽어볼수는 없을 거라고 생각합니다. 각자가 컨텍스트를 쌓아두어야 소통이 되면서 다음 업무 진행이 가능할텐데 내가 한게 아니라 그냥 스팸메일처럼 될거라 만들어진 컨텍스트를 관리하고 기억하고 담당하는 사람의 속도에 매이게 될거에요.

1-2명의 관리자 체계에게 AI가 만들어내는 문서를 끊임없이 읽고 정리하고 관리하는 사람

컨텍스트 엔지니어링 전략 검토 Q) 거대한 컨텍스트를 마이크로 태스크로 분해하여 연속 실행하는 방식이 복잡도 관리에 효과적인지 평가해주실 수 있나요? 현재 Story당 2-4시간 단위로 세분화했는데, 이 단위가 적절한지, 그리고 더 효율적인 태스크 분해 기준이 있는지 알고 싶습니다.

=> step-by-step은 AI씬에서 가장 검증된 방법입니다. 이걸 어떻게 만드느냐가 기술인데 현재 claude code가 제일 잘하고 있죠. 실제 업무에서도 요구사항의 일을 조각내어 분배하고 순서대로 정렬한 다음에 서로에게 넘겨줘야할 결과물을 정리하고 관리하는 매니저의 힘이 조직이 커지면 커질수록 더욱더 중요하죠. 결국 이러한 매니징을 잘하면 주니어도 수행할 수 있는 업무가 되듯이 AI가 실행할 수 있는 단위로 쪼개어 내는 것은 현재도 많은 연구를 하고 있는 과제입니다.

=> 효율적인 태스크 분해라고 하니 어렵네요. 실제로는 사람마다 한번에 해낼 수 있는 양이 달라서 일단 일을 줘보고 못한다 싶으면 옆에서 직관적으로 태스크를 분해하고 애해했는지 물어보는 커뮤니케이션을 하잖아요? 프론트엔드 개발은 폴더구조를 바탕으로 IN -> OUT과 구조가 거의 분리되어 있으니 컴포넌트, 순수함수, 상태, API 등등 정해진 모듈을 만들어내는 공장처럼 분해하도록 하고 구현하도록 만들 수 있으면 좋겠다 싶네요.

테스트 전략의 실무 적합성 Q) 팀에서 합의한 "회귀 테스트 중심 + 단위 테스트 보완" 전략이 실제 프로덕션 환경에서도 지속 가능한지 검토해주실 수 있나요? 특히 브라운필드 개발에서 기존 기능을 보호하면서 새 기능을 안전하게 추가하는 방법론으로서의 효과성에 대한 의견을 듣고 싶습니다.

=> 프론트엔드에서 테스트 코드가 보편적이지 않음에도 회귀 테스트들은 주로하는건 QA들 덕분이죠. 릴리즈를 하기 위해서는 기존 동작이 문제없다는 것들을 항상 테스트를 해야하니까요. 테스트 코드는 AI에게 특정 구현을 강제하도록 하는 아주 좋은 방법이라 생각합니다. 효과적이겠네요!

아키텍처 설계의 확장성 Q) 현재 구현한 레이어드 아키텍처(types → utils → hooks → components)가 더 복잡한 도메인으로 확장될 때도 유지될 수 있는지, 그리고 SOLID 원칙 적용 수준이 실무 기준에 부합하는지 평가해주실 수 있나요?

=> 컨벤션을 유지하고 충분한 rule이 있으면 유지될수 있겠다 싶지만 기왕이면 AI에게 시킬거라면 AI가 자주 쓰는 구조를 따라가는게 더 좋더라구요. 아무리 내가 rule을 만들어도 LLM이 생성하는 걸 보면 컨벤션이나 지시보다 본인의 학습된 습관이 훨씬 더 크게 발현되는 경향이 있습니다. 물론 언젠가는 고쳐지겠지만 현재의 AI 구조상으로는 모델이 재학습을 하지 않다보니 아키텍쳐를 가급적 보편적인것을 고르는게 좋다고 생각합니다.

=> 지금 과제 수준에서는 SOLID 원칙 적용을 평가하기가 어렵습니다. 규모가 작을 때는 설계 문제가 크게 드러나지 않아서, 과제를 잘 완수했다고 해서 실제 복잡한 실무 환경에서도 잘 적용될 것이라고 단정하기 어려워요.

Zero Hand-Coding 개발의 혁신성 Q) 단 한 줄의 코드도 직접 작성하지 않고 AI 멀티에이전트로만 구현한 이 접근 방식이 미래 개발 트렌드로서 어떤 가능성과 한계를 갖는지에 대한 견해를 듣고 싶습니다. 이 방법론이 개발자의 역할을 어떻게 변화시킬 수 있을까요?

=> 흥미로운 질문입니다. 몇 가지 관점이 떠오르네요. 우선 컨텍스트와 히스토리의 학습 이슈입니다. 코드를 작성하지 않더라도 누군가는 이 것을 관리해야 하고 그러기 위해서는 히스토리를 기억해야 합니다. 일종의 외주 회사를 운영하는 느낌이겠죠? 외주관리를 하는 경우 코드를 한줄로 작성하지 않고서 원하는걸 굴릴 수 있으니까요. 현재도 IT가 주가 아닌 대기업의 개발자들이 주로 맡고 있는 역할입니다.

=> 일반적인 개발자들은 스스로는 매니저라기 보다는 엔지니어라고 생각하는 경향이 있어서 외주관리를 하는 것에 큰 흥미를 보이진 않습니다만 돈을 많이 준다고 하면 얼마든지 수요는 있을 거라고 생각합니다. 코딩을 하나도 하지 않는 대기업 외주 관리 개발자가 실제 외주에서 개발을 하는 사람보다는 대우를 더 잘 받는 경우도 많죠. 이런 역할에 가치를 부여한다면 코딩이 없어도 그 일을 하려는 개발자들이 나올 수 있겠죠."

=> 이게 어떤 문화로 작용하게 될지가 중요할 것 같아요. 예전 개발 업계에서 코드없이 홈페이지를 만드는 툴들이 많았죠. 분명 그러한 툴들로 돈을 벌수는 있었지만 개발자의 경력으로 인정해주지는 않았어요. framer는 디자이너들이 배우기 싫어했기에 선택받지 못했습니다. 디자이너에게 경력과 능력으로 봐주지 않았으니까요. 대신 figma는 성공했습니다. figma를 잘 다루는 디자이너를 선호했으니까요.

=> 이러한 멀티엔이전트 도구가 혁신여부도 중요하겠지만 이런 방식에 사람들이 얼마나 많은 가치가 부여하고 커리어로 인정하느냐하는 분위기를 만드느냐에 따라서 변화가 이루어질거라고 생각합니다. 혁신성을 가지고 있다고 한들 모두가 인정해주지 않으면 혼자서만 일을 벌리는 사람이 될테니까요.

AI Native Workflow Framework의 조직적 가치 Q) BMAD Method가 강제하는 규약과 컨텍스트 엔지니어링이 조직 차원에서 어떤 가치를 가질 수 있는지, 그리고 이 방법론이 팀 협업과 프로젝트 관리에 미칠 수 있는 영향에 대해 조언해주실 수 있나요?

=> 5에서 말한 내용과 비슷한 관점입니다. 독자적으로 한명의 개발자가 하는 것으로는 지속하기 어렵습니다. JIRA가 아직까지 유지되는건 모두가 JIRA를 경험했고 알기 때문이죠. git도 React도 내가 알려주지 않아도 누군가는 밖에서 배워서 옵니다. 그리고 그걸 배운 사람은 오면 알수가 있죠. 그렇기에 강제적인 규약과 학습이 가능한 엔지니어링이 조직 차원에서는 아주 중요한 가치를 가집니다.

=> 그러기 위해서는 어떻게든 붐이 불어야 합니다. 대중의 선택을 받아야 해요. 왜인지는 모르겠지만 다수가 그걸 하고 있어야 하고 그것에 가치를 부여해야하죠. 네이버 클라우드를 애써 배우려고 하지는 않지만 AWS는 배우려고 하잖아요? angular와 react를 비교해도 그렇죠. 방법론적 기술의 성공에서 대중의 선택이 정말로 중요합니다.

=> 같은 맥락에서 이 방법론이 지금 유의미해지기 위해서는 적어도 주변 모두의 동의와 합의가 필요하다는 점입니다. 그렇다고 확장된다는 보장은 없겠지만 적어도 같은 비전을 공유하고 있는 팀은 이러한 시스템 아래서 협업을 이어나갈 수 있겠죠.

다시 말하지만 저는 AI쪽 전문가는 아니어서 주관적인 답변이라는거 이해해주고 다양한 사람들에게 물어가면서 좋은 철학과 기준을 만들어가길 바래요. 저 보다 훨씬 더 AI에 관심과 지식이 많은 것 같아 제가 오히려 물어봐야겠네요. ㅎㅎ 다음 과제도 화이팅입니다!

OFF: 안녕하세요! 오프입니다. 제가 결과를 수정했는데요. 심화과제를 불합격 시킨 이유는 전에 공지에 공유드렸듯이 e2e, 시각적 회귀테스트가 없다는 맥락이였습니다. 아쉽지만 참고 부탁드립니다ㅠㅠ

항해플러스 프론트엔드

BBAK-jun 님의 상세페이지 ＞ [3팀 박준형] Chapter 3-2 프론트엔드 테스트 코드 🦍