AI와 함께 일하기

거의 매주 새로운 모델이 나오고, 하루가 다르게 AI 활용법도 달라진다.

처음 AI를 업무에 도입한 건 GPT-4o나 GPT-4.1을 사용하기 시작했을 때쯤이었다. 그때만 해도 AI가 제시한 코드 중 정확한 건 거의 없었고, 할루시네이션도 심해서 AI와 ‘협업’한다는 느낌을 받기는 어려웠다. Opus가 출시되고 GPT도 어느덧 5.6까지 나온 지금은 새로운 방식으로 일하고 있다고 느낄 만큼 많은 게 달라졌다.

기획부터 배포까지

개발은 대략 이런 순서로 진행된다.

1. 해결이 필요한 문제 → 2. 아이디어 제안 및 고도화 → 3. 기획·디자인 → 4. 개발 → 5. 배포

3번 과정이 시작되기 전까지는 큰 변화를 체감하지 못했다. 하지만 기획과 디자인이 개발로 이어지는 과정, 그리고 실제 개발 과정에는 정말 많은 변화가 있었다.

하나씩 짚어보자.

기획서가 코드가 되기까지

1. 어느 날 기획 초안과 함께 회의 초대 메일이 날아온다.

   아직 정해진 게 많지 않기 때문에 과거의 관련 작업을 찾아본다.

2. 열심히 회의하고 나면 완성된 기획과 디자인이 나온다.

   회의에서 기획자가 묻는다. “이런 식으로 개발할 수 있나요?” 될 것 같기는 한데 확신은 없다. “한 번 확인해 볼게요.”

3. 기획서와 디자인을 보고 작업 계획을 세운다.

   기획을 보고 이 기능이 왜 필요한지, iOS 개발이 필요한 부분은 무엇인지 정리한다. 새로 만들어진 정책이 기존 정책과 충돌하지 않는지 파악한다. 지금 구조에 간단히 추가할 수 있는 작업인지, 대대적인 수정이 필요한지 분석한다. 조정이 필요한 사항이 생기면 의논과 회의를 반복한다.

4. 개발을 시작한다.

   개발하다 보니 될 것 같다고 이야기했던 게 안 될 것 같다. 다시 의논한다.

보통은 위와 같은 과정으로 일이 진행된다. 물론 각 단계 안에는 수많은 세부 작업이 생긴다. 주로 “이거 이렇게 되나요?” → “확인해 볼게요.” → “안 될 것 같은데요.” → “그럼 이렇게는요?” → “그건 될 것 같은데요.”의 반복이다.

지금도 큰 순서는 같지만, 각 단계 안에서 벌어지는 일은 아래처럼 많이 달라졌다.

1. 어느 날 기획 초안과 함께 회의 초대 메일이 날아온다.

   아직 정해진 게 많지 않지만 Confluence MCP로 관련 작업의 문서를 찾아 분석한다.

2. 열심히 회의하고 나면 완성된 기획과 디자인이 나온다.

   회의에서 기획자가 묻는다. “이런 식으로 개발할 수 있나요?” 될 것 같기는 한데 확신은 없다. 클로드에게 빠르게 물어본다. “우리 구조에서 이렇게 할 수 있지?” → “네, 가능합니다.” 물론 과신은 금물이다.

3. 기획서와 디자인을 보고 작업 계획을 세운다.

   미리 만들어 둔 Skill로 기획서와 디자인을 분석한다. 클로드가 기존 정책과 충돌하는 부분을 미리 파악해 줘서 바로 다시 논의할 수 있다.

4. 개발을 시작한다.

   앞서 분석해 둔 자료를 바탕으로 클로드에게 Work Plan 작성을 맡긴다.

불과 얼마 전만 해도 문서를 읽고 분석하거나 회의할 때는 AI를 사용하지 않았던 것 같다. 이제는 개발이 시작되기 전 단계에서도 매번 AI를 사용한다.

코드 작성

1. 클로드가 하네스로 정의해 둔 내용을 토대로 Work Plan을 작성하고, 그 과정에서 나온 질문에 답한다.
   1. “이건 A와 B 중 하나를 결정해야 할 것 같은데요?”
   2. “A로 가자.” 또는 “각 방법의 장단점을 다시 분석해 줘.”
2. Master Plan이 작성되면 각 Plan을 작은 Task로 쪼갠다. 물론 이 작업도 클로드가 한다.
   1. Plan A에 대한 Task 1~10이 만들어졌다. 클로드가 나에게 API 스펙을 달라고 한다.
   2. 아직 API 스펙이 확정되지 않아 Plan B부터 실행하기로 하고, Plan B의 Task 1~10을 생성한다.
   3. Task를 만드는 도중 내가 확인해야 할 사항이 생긴다.
      1. 이 사항들을 다시 클로드와 논의한다.
   4. Plan B에 대한 Task까지 확정됐다.
3. Plan B부터 개발하기로 한다.
   1. 클로드: “Plan B의 Task 1부터 시작할까요?” → “그래.”
   2. Code Generator Skill과 Review Skill을 반복해서 사용하며 Task를 완성한다.
   3. Task가 모두 끝날 때까지 이 과정을 반복한다.
4. 개발이 끝나면 PR을 만든다.
   1. 사람이 보기 전에 AI Code Review로 먼저 리뷰한다.

아주 대략적으로 정리하면 위와 같은 과정으로 개발한다. 여기에 적지 않았지만 에이전트와 함께하는 일은 더 많다. 최근 클로드 코드 업데이트에서 iOS 시뮬레이터까지 지원하면서, 코드를 작성한 뒤 빌드하고 실행을 확인하는 절차도 점점 AI에게 넘어가고 있다. 푸시 알림을 확인하려고 시뮬레이터의 환경 설정에 들어가 알림 권한을 켜는 모습을 보고는 꽤 놀랐다.

어디까지 맡길 수 있고, 얼마나 믿을 수 있을까

우리 코드를 난장판으로 만들던 과거의 AI와 달리 요즘 AI는 “와, 이 정도까지 해준다고?”라는 말이 절로 나오는 수준이다. 자연스럽게 개발 과정의 상당 부분이 AI에게 넘어갔다. 나머지 절차를 두고도 “이것도 해줄 것 같은데 맡겨 말아?”, “그래도 이건 좀 그렇지.” 하고 고민하는 중이다.

단순한 비즈니스 로직이나 이미 만들어진 컴포넌트를 활용하는 코드는 편한 마음으로 맡길 수 있었다. 하지만 중요한 로직이나 API 호출, 응답 처리에는 사람의 검증이 필요했다. 피그마를 보고 UI를 작성할 때도 AI가 디자인 파일을 제대로 이해하지 못해 몇 픽셀씩 어긋나거나 잘못된 색상과 폰트를 사용하는 경우가 있었다.

이제는 중요한 로직이나 API 호출·응답에도 AI가 더 꼼꼼한 검증 절차를 만들 수 있게 됐다. UI 관련 코드와 디자인 파일도 전보다 잘 이해해, 결과물을 거의 손댈 필요가 없을 때도 있다.

인간 개발자의 역할은?

예전부터 개발자 사이에는 Coder가 되지 말고 Programmer, Developer가 되라는 유명한 잔소리가 있었다.

AI가 단순하고 반복적인 코드 작업뿐 아니라 복잡한 로직의 구현까지 점점 잘해 주는 만큼, 개발자는 코드 밖으로 관심을 넓혀야 한다. 이 문제가 어떤 문제인지 더 정확히 이해하고, 그 안에 담긴 비즈니스 맥락을 파악하고, 개발 안팎에서 AI를 잘 활용할 방법을 연구해야 한다. 마치 조직장이 된 것처럼 시야를 넓혀야 한다는 생각도 든다.

개발 과정 안에서도 더 고민해 볼 지점이 많다. 코드 리뷰는 어떻게 해야 하는지, AI 시대에도 유지될 소프트웨어 개발 원칙은 무엇이고 달라질 원칙은 무엇인지 등은 다음 글에서 따로 정리해 보려고 한다.

결국 AI와 함께 일한다는 건 코드를 대신 써 주는 도구를 하나 더 사용하는 일이 아니었다. 무엇을 만들지 정하고, 어디까지 맡길지 나누고, 나온 결과를 어떤 기준으로 검증할지 판단하는 쪽으로 개발자의 일이 옮겨가고 있다. AI가 할 수 있는 일이 늘어날수록 개발자의 역할이 사라지는 게 아니라, 개발자가 직접 내려야 할 판단이 더 선명해진다. 요즘 내가 가장 크게 느끼는 변화도 바로 그 지점이다.