요즘 회사에서도 그렇고, 동네 카페에서 노트북 펴놓고 일하다 보면 옆자리에서도 은근히 AI 바이브 코딩 얘기가 들리더라고요. 예전 같으면 “에이, 또 새로운 도구 하나 나왔나 보다” 하고 넘겼을 텐데, 저도 개발밥을 20년쯤 먹다 보니 이제는 감이 와요. 어떤 도구는 그냥 유행이고, 어떤 도구는 일하는 방식을 조금 바꿔놓거든요.
그래서 최근에 Task Master AI를 꽤 진지하게 써봤습니다. 특히 제가 관심을 가진 건 작업분해였어요. 개발할 때 제일 귀찮으면서도 중요한 게 결국 “이 큰 일을 어디서부터 쪼갤 거냐”잖아요. 처음엔 그냥 “로그인 기능 좀 나눠줘” 정도로 가볍게 던져봤는데, 며칠 써보니까 생각보다 꽤 쓸 만하더라고요. 아니, 솔직히 말하면 몇 번은 좀 놀랐습니다.
저는 원래 여행 갈 때도 항공권, 숙소, 동선, 식당, 비 오는 날 대안까지 쭉 쪼개놓는 편이에요. 좀 피곤한 스타일이죠. 그런데 개발 업무에 Task Master AI를 붙여보니까, 여행 계획 짤 때의 그 감각이랑 묘하게 비슷했어요. 다만 차이가 있다면, 얘는 제가 깜빡한 짐까지 옆에서 챙겨주는 느낌이랄까요.
처음 써보고 살짝 멈칫했어요, “어라? 이걸 이렇게 나눈다고?”
처음에는 “로그인 모듈 개발”이라는 꽤 뭉뚱그린 작업을 넣어봤어요. 저는 당연히 회원 조회, 비밀번호 검증, 토큰 발급 정도로 나눠주겠지 싶었거든요. 그런데 Task Master AI가 15개가 넘는 하위 작업으로 쪼개서 보여주더라고요. 더 신기했던 건, 그 방향이 제가 머릿속으로 대충 그리던 흐름이랑 꽤 비슷했다는 겁니다.
물론 20년 개발했다고 해서 매번 완벽하게 작업을 쪼개는 건 아니에요. 오히려 오래 하다 보면 “이 정도는 당연히 나중에 하면 되겠지” 하고 넘기는 것도 생기거든요. 그런데 그 당연한 것들이 실제 장애나 일정 지연으로 돌아올 때가 있습니다. 아, 이건 진짜 몇 번 당해보면 압니다.
최근에 제가 OAuth2.0 기반 인증 시스템을 리팩토링할 일이 있었어요. 그때 Task Master AI에게 “사용자 인증 시스템 고도화”라는 식으로 작업을 던져봤습니다. 나온 결과 중 일부는 이런 느낌이었어요.
| 작업명 | 우선순위 | 예상 시간 | 의존성 |
|---|---|---|---|
| OAuth2.0 Authorization Code Flow 정리 | 높음 | 2시간 | 없음 |
| Access Token 저장소 설계, Redis 기준 | 높음 | 3시간 | Flow 정리 후 |
| Refresh Token 만료 로직 구현 | 중간 | 1.5시간 | 저장소 설계 후 |
| API Gateway 연동 테스트 | 낮음 | 4시간 | 토큰 정책 확정 후 |
여기서 제가 뜨끔했던 게 Refresh Token 만료 로직이었어요. 사실 처음 설계할 때는 Access Token 쪽에만 신경이 가 있었거든요. 실무에서는 이런 일이 꽤 자주 있어요. 눈앞의 핵심 기능에 집중하다 보면, 만료 정책이나 예외 흐름 같은 게 뒤로 밀립니다. 당장은 잘 돌아가니까요. 그런데 꼭 나중에 로그에서 툭 튀어나옵니다.
실제로 며칠 뒤 테스트 환경에서 이런 류의 로그가 보였어요.
[AUTH-403] refresh_token_expired userId=18492 provider=google
[AUTH-WARN] access_token renewal failed: refresh token ttl not found in Redis그때 속으로 “아, 이거 미리 나눠놔서 다행이다” 싶었습니다. 제가 혼자 작업분해했으면 아마 Redis 저장소 설계 정도까지만 적어놓고 넘어갔을 가능성이 높아요. 이런 작은 차이가 나중에 반나절을 아껴줍니다. 반나절이면 점심 먹고 커피 한잔하면서 코드 리뷰까지 할 수 있는 시간이잖아요.
Task Master AI 작업분해, 그냥 던지면 아깝고 맥락을 줘야 살아나요
몇 달 가까이 써보면서 느낀 건 이거예요. Task Master AI는 똑똑하긴 한데, 내 머릿속을 자동으로 읽지는 못합니다. 당연한 말인데 은근히 많이들 놓쳐요. 그냥 “주문 시스템 개발해줘”라고 하면 결과도 딱 그 정도로 나옵니다. 무난하고, 평범하고, 어디선가 본 듯한 작업 목록이요.
저는 어느 순간부터 프롬프트에 프로젝트 상황을 꽤 자세히 넣기 시작했어요. 예를 들면 이런 식입니다.
주문 시스템 개발 작업을 분해해줘.
현재 구조는 마이크로서비스 아키텍처야.
메시지 큐는 RabbitMQ를 사용하고 있고,
이벤트 소싱 패턴을 일부 적용 중이야.
데이터베이스는 PostgreSQL이고,
결제 흐름은 Saga 패턴으로 구현할 계획이야.
장애 상황에서 보상 트랜잭션이 중요해.이렇게 맥락을 주니까 결과가 확 달라졌어요. “주문 생성 API 구현” 같은 뻔한 작업만 나오는 게 아니라, “결제 Saga 보상 트랜잭션 정의”, “주문 상태 머신 전이 규칙 정리”, “이벤트 중복 처리 기준 작성” 같은 작업이 같이 나오더라고요.
이건 꽤 중요합니다. AI 도구를 잘 쓰는 사람과 그냥 한두 번 써보고 마는 사람의 차이가 여기서 갈려요. 작업분해 AI는 질문이 얕으면 얕게 답하고, 맥락이 깊으면 제법 깊게 들어옵니다. 마치 후배 개발자한테 업무 설명할 때랑 비슷해요. “이거 해줘”와 “왜 이걸 해야 하는지, 지금 시스템이 어떤 상태인지”까지 설명하는 건 결과물이 완전히 다르거든요.
작업이 너무 많아질 땐, 그룹으로 묶어야 숨통이 트입니다
Task Master AI가 처음부터 마음에 쏙 들었던 건 아니에요. 오히려 초반에는 결과가 너무 많아서 좀 부담스러웠습니다. 작업이 30개 넘게 나오면, 그 순간 기분이 묘해요. 분명 도움을 받으려고 쓴 건데 갑자기 일이 늘어난 느낌이거든요. 노트북 화면 보면서 “야, 나 퇴근은 할 수 있는 거냐” 싶었습니다.
그때 꽤 유용했던 게 작업 그룹화 기능이었어요. 분해된 작업을 인프라, 도메인 로직, 테스트, 배포 같은 묶음으로 정리해주는데, 이게 생각보다 심리적으로 큰 도움이 됩니다. 작업이 흩어져 있을 때는 산더미처럼 보이는데, 묶어놓으면 “아, 지금은 도메인 로직만 보면 되겠네” 하고 시야가 좁혀지거든요.
| 그룹 | 포함된 작업 예시 | 제가 조정한 부분 |
|---|---|---|
| 인프라 | Redis 설정, RabbitMQ 연결, 환경 변수 정리 | 로컬 개발 환경과 운영 환경 작업을 분리 |
| 도메인 로직 | 주문 상태 전이, 결제 승인, 취소 정책 | 상태 머신 검토 작업을 별도로 추가 |
| 에러 핸들링 | 토큰 만료, 외부 API 실패, 메시지 중복 수신 | 제가 수동으로 새 그룹을 만들어 따로 모음 |
| 테스트 | 단위 테스트, 통합 테스트, 장애 시나리오 테스트 | 장애 시나리오 테스트를 우선순위 높음으로 변경 |
여기서 제 나름의 기준이 하나 생겼습니다. 작업을 그룹화할 때는 동시에 할 수 있는 일과 순서대로 해야 하는 일을 꼭 나눠봐야 해요. AI가 의존성 그래프를 만들어주긴 하는데, 실제 조직의 사정까지 다 알 수는 없거든요. 예를 들어 백엔드 작업은 끝났는데 프론트엔드 담당자가 다른 프로젝트에 묶여 있으면, 그건 의존성 그래프만 보고 판단할 일이 아니죠.
그래서 저는 Task Master AI가 만든 결과를 그대로 쓰기보다는, 회의 전에 초안으로 뽑아놓고 사람들과 맞춰보는 용도로 많이 씁니다. 이게 꽤 괜찮아요. 회의 시작하자마자 빈 화면 보고 “자, 뭐부터 할까요?” 하는 시간이 줄어듭니다. 다들 아시죠. 그 침묵. 은근히 길고 피곤한 그 시간요.
체크리스트를 코드 수준까지 내려보면 진짜 쓸모가 보입니다
제가 Task Master AI를 계속 쓰게 된 이유는 단순히 작업 목록을 잘 만들어줘서가 아니에요. 각 작업을 열어보면 체크리스트나 의사 코드 수준으로 더 내려갈 수 있다는 점이 꽤 좋았습니다. 이게 실무에서는 은근히 큽니다.
예를 들어 Refresh Token 만료 로직 작업을 열어보면 이런 식으로 정리할 수 있었어요.
- Redis에서 Refresh Token TTL 확인, 기본값은 7일 기준으로 검토
- Access Token 만료와 Refresh Token 만료 로그를 분리해서 남기기
- 403 응답 시 클라이언트에서 재로그인 플로우로 이동할 수 있게 에러 코드 정의
- Redis 장애 시 DB 조회 fallback이 필요한지 검토
- 토큰 재발급 요청이 짧은 시간에 반복될 때 rate limit 적용 여부 확인
이런 체크리스트가 있으면 코딩할 때 꽤 든든합니다. 특히 오후 5시쯤 되면 집중력이 조금씩 떨어지잖아요. 그때는 머릿속 설계만 믿으면 꼭 하나씩 놓쳐요. 젊을 때는 밤새면서 커버했는데, 이제는 그렇게 일하면 다음 날 허리가 먼저 항의합니다. 그래서 저는 이런 체크리스트가 좋습니다. 몸을 덜 갈아 넣고도 품질을 지키는 장치 같거든요.
퇴근 전에 작업을 끊을 때도 유용했어요. 예전에는 “어디까지 했더라?” 하고 다음 날 아침에 기억을 더듬는 시간이 있었는데, 이제는 체크리스트에 상태만 남겨둡니다.
[완료] Redis TTL 확인 로직 구현
[진행 중] refresh_token_expired 에러 코드 매핑
[대기] 프론트엔드 재로그인 플로우 확인 필요
[메모] Redis 장애 시 fallback은 운영 정책 논의 후 결정별거 아닌 것 같죠. 그런데 이런 메모가 다음 날 아침의 나를 살립니다. 커피 한 모금 마시고 바로 이어서 할 수 있거든요. 저는 이걸 꽤 높게 평가합니다. 생산성이라는 게 거창한 게 아니라, 다시 시작하는 데 드는 시간을 줄이는 일이기도 하니까요.
그래도 Task Master AI를 너무 믿으면 곤란합니다
좋은 얘기만 하면 좀 그렇죠. 사실 Task Master AI가 만능은 아니었습니다. 제가 초반에 했던 가장 큰 실수는 AI가 분해한 작업을 거의 그대로 Jira에 옮긴 것이었어요. 그때는 신기하기도 했고, 결과가 그럴듯해서 그냥 믿고 싶었던 것 같아요. 그런데 개발을 시작해보니 현실과 살짝 안 맞는 작업들이 보였습니다.
예를 들어 “외부 API 호출 실패 시 재시도 로직 구현”이라는 작업이 있었어요. 말만 들으면 맞는 얘기입니다. 외부 API는 실패할 수 있고, 재시도 로직은 필요할 수 있죠. 그런데 실제로 그 API는 단순 조회용이었고, 응답이 느린 상태에서 재시도를 걸면 오히려 전체 성능이 더 나빠지는 상황이었어요.
AI는 그 API의 성격, 트래픽 패턴, 우리 서비스의 병목 지점을 몰랐던 겁니다. 그러니 일반적으로 그럴듯한 답을 낸 거죠. 이건 AI가 못났다기보다, 제가 충분한 정보를 안 준 탓도 있습니다. 그래도 실무에서는 이 차이가 중요해요. 그럴듯한 작업과 필요한 작업은 다릅니다.
그래서 지금은 이런 식으로 씁니다.
- Task Master AI로 작업분해 초안을 만든다
- 도메인 지식이 필요한 부분은 직접 검토한다
- 코드 구조와 실제 장애 이력을 기준으로 작업을 줄이거나 합친다
- Jira나 이슈 트래커에는 검증된 작업만 옮긴다
- 성능 최적화 작업은 AI 결과를 참고만 하고, 최종 판단은 사람이 한다
특히 성능 최적화 쪽은 아직 사람이 많이 봐야 한다고 느꼈어요. “데이터베이스 쿼리 최적화”라고 요청하면 인덱스 추가, 쿼리 분석, 실행 계획 확인 같은 기본적인 항목은 잘 나옵니다. 그런데 실제로 필요한 게 캐싱 전략인지, 읽기 복제본인지, 비정규화인지, 아니면 애초에 화면 요구사항을 줄여야 하는 문제인지는 AI가 쉽게 판단하기 어렵습니다.
뭐랄까, Task Master AI는 좋은 내비게이션 같아요. 길을 꽤 잘 알려줍니다. 그런데 공사 중인 골목길이나 내가 자주 다니는 지름길은 아직 운전자가 알아야 해요. 저는 그 정도 거리감을 두고 쓰는 게 제일 편했습니다.
개발 말고 여행 계획에도 써봤는데, 이건 좀 웃기게 좋았습니다
제가 여행을 좋아해서 그런지, 어느 날 문득 이런 생각이 들더라고요. “이거 여행 계획에도 써먹을 수 있지 않을까?” 개발 작업을 쪼개는 도구라면, 여행 준비도 꽤 잘 나눌 것 같았거든요. 그래서 장난 반, 기대 반으로 “일본 오사카 4박 5일 여행 계획을 작업으로 분해해줘”라고 넣어봤습니다.
결과가 생각보다 재미있었어요. 단순히 관광지 목록을 뽑는 게 아니라, 준비해야 할 일을 꽤 현실적으로 나눠주더라고요.
| 대분류 | 중분류 | 세부 작업 |
|---|---|---|
| 항공과 숙소 | 예약 확인 | 항공권 시간 재확인, 호텔 조식 여부 체크, 체크인 전 짐 보관 가능 여부 확인 |
| 관광 | 동선 정리 | 오사카성, 도톤보리, 유니버설 스튜디오 이동 시간과 체류 시간 계산 |
| 식사 | 예약 필요 여부 | 타코야키, 오코노미야키 후보 식당 정리, 대기 시간 긴 곳은 대체 식당 확보 |
| 예산 | 현지 지출 | 교통패스, 식비, 입장권, 비상금 구분해서 계산 |
솔직히 말하면, 제가 직접 짠 여행 계획보다 꼼꼼한 부분도 있었어요. 특히 “대기 시간이 길면 대체 식당 확보” 같은 건 개발로 치면 fallback 설계잖아요. 여행도 똑같습니다. 계획대로 안 되는 순간이 꼭 오거든요. 비가 오거나, 줄이 너무 길거나, 갑자기 같이 간 사람이 “나 오늘은 그냥 쉬고 싶어”라고 할 수도 있고요.
이걸 보고 좀 웃었습니다. 개발에서 장애 대응하던 습관이 여행 계획에도 그대로 들어가는구나 싶어서요. 그래도 이런 게 40대 직장인의 여행 방식 아닐까요. 즉흥도 좋지만, 최소한의 안전장치는 있어야 마음이 편합니다.
제가 느낀 Task Master AI의 가장 현실적인 쓰임새
몇 달 써보고 나니 제 생각은 꽤 분명해졌습니다. Task Master AI는 개발자를 대신하는 도구라기보다, 개발자가 생각을 정리하도록 도와주는 도구에 가깝습니다. 특히 복잡한 프로젝트 초반에 머릿속이 엉켜 있을 때 효과가 좋아요.
제가 특히 도움을 받았던 상황은 이런 때였습니다.
- 큰 기능을 시작해야 하는데 어디서부터 나눌지 막막할 때
- 회의 전에 대략적인 작업 목록 초안이 필요할 때
- Jira 이슈를 만들기 전에 누락된 작업이 없는지 점검할 때
- 인증, 결제, 메시징처럼 예외 흐름이 많은 기능을 설계할 때
- 퇴근 전에 내일 이어서 할 작업을 체크리스트로 남기고 싶을 때
반대로 이런 상황에서는 조금 조심해야 했습니다.
- 도메인 특성이 강해서 일반적인 패턴으로 판단하기 어려운 작업
- 성능 병목처럼 실제 데이터와 운영 경험이 중요한 작업
- 조직 내부 사정이나 담당자 일정이 크게 영향을 주는 작업
- 외부 API 정책처럼 문서와 실제 동작이 다른 경우가 많은 작업
그러니까 제 기준에서는 이렇습니다. Task Master AI가 만든 작업분해 결과를 “정답”으로 보면 위험하고, “좋은 초안”으로 보면 꽤 강력합니다. 이 차이를 알고 쓰면 만족도가 확 올라가요.
이런 분들이 읽으면 꽤 도움 될 것 같아요
이 글은 복잡한 프로젝트 앞에서 머리가 살짝 하얘지는 분들께 특히 도움이 될 것 같습니다. 주니어 개발자라면 큰 기능을 어떻게 작은 단위로 나누는지 감을 잡는 데 좋고, 시니어 개발자라면 본인이 놓친 예외나 의존성을 점검하는 용도로 괜찮아요. 프리랜서처럼 혼자 일정과 작업을 다 관리해야 하는 분들에게도 꽤 잘 맞습니다.
저처럼 오래 개발한 사람도 가끔은 놓칩니다. 아니, 자주 놓칩니다. 경력이 쌓이면 실력이 느는 것도 맞지만, 익숙함 때문에 대충 넘기는 부분도 생기거든요. 그럴 때 Task Master AI 작업분해는 옆에서 “이것도 한번 봐야 하지 않을까요?” 하고 조용히 말 걸어주는 동료 같은 느낌이었습니다.
처음에는 저도 “AI가 개발자 일을 어디까지 가져가려나” 하는 마음이 조금 있었어요. 그런데 지금은 생각이 달라졌습니다. 잘 쓰면 일을 빼앗기는 느낌보다, 내 머릿속을 정리해주는 비서에 가깝습니다. 물론 최종 판단은 여전히 사람이 해야 하고요. 그게 저는 마음에 듭니다. 도구는 도구답게, 개발자는 개발자답게.
복잡한 기능을 앞두고 작업 목록부터 막히는 분, AI 바이브 코딩을 해보고는 싶은데 어디에 써야 할지 애매했던 분, 그리고 일정 관리 때문에 늘 머릿속이 시끄러운 분이라면 한 번쯤 써보셔도 좋겠습니다. 너무 기대를 크게 걸 필요는 없고요. 그냥 다음 프로젝트 시작 전에 “이 일 좀 쪼개봐” 하고 한번 맡겨보세요. 생각보다 꽤 괜찮은 대화가 시작될지도 모릅니다.
댓글
댓글 쓰기