AI를 활용한 화면 개발 방식을 보고 자료로 정리하는 일이 있었습니다. 디자인 시스템과 개발 컴포넌트를 연결하고, 화면 코드 생성과 검토 방식을 검증한 내용을 짧은 문서에 담아야 했습니다.

처음에는 준비한 구조와 도구의 동작을 설명하면 될 것 같았습니다. Figma에서 디자인을 확인하고, 기존 공통 컴포넌트를 활용해 코드를 생성하는 흐름을 보여주면 적용 방향도 전달할 수 있다고 생각했습니다.

하지만 보고 내용을 정리하려면 무엇을 검증했고, 어디부터 실제 업무에 적용할 것이며, 어떤 효과는 앞으로 확인해야 하는지 나누어 설명할 필요가 있었습니다.

검증한 범위를 성과의 기준으로 삼았습니다

이번에 준비한 것은 Figma 디자인 시스템의 공통 컴포넌트를 React UI Library로 코드화하고, Storybook으로 문서화한 개발 기반이었습니다. 디자인 컴포넌트와 개발 컴포넌트의 연계, 화면 코드 생성 및 검토 방식에 대한 검증도 진행했습니다.

이는 신규 화면 개발에 AI를 활용할 수 있는 기반을 마련했다는 의미였습니다. 다만 실제 업무 전반에서 생산성이 얼마나 달라졌는지까지 확인한 것은 아니었습니다.

보고서에서는 준비한 자산과 검증한 방식을 먼저 설명하고, 신규 업무 적용과 효과 확인은 향후 계획으로 두었습니다. 기반을 확보한 일과 그 기반으로 얻을 효과를 구분해야 다음에 무엇을 확인할지도 분명해졌습니다.

코드 생성 이후의 책임도 설명해야 했습니다

AI가 화면 코드를 생성한다는 설명만으로는 서비스에 적용하는 과정을 충분히 보여주기 어려웠습니다. 결과를 누가 확인하고, 필요한 수정을 거쳐 어떻게 실제 개발에 사용할지가 함께 있어야 했습니다.

이번 적용 방식에서는 기존 공통 컴포넌트를 우선 활용하고, 생성된 결과를 개발자가 검토·보완한 뒤 서비스 개발에 사용하는 흐름을 담았습니다. 컴포넌트 생성과 검토, 페이지 구현, 품질 검증을 연결하는 역할 구분도 포함했습니다.

역할을 나누었다고 검토 책임이 사라지는 것은 아닙니다. 코드가 생성되었다는 사실과 업무에 사용할 수 있다는 판단은 구분해야 합니다. 개발자의 검토·보완을 적용 과정에 명시한 이유도 여기에 있었습니다.

업무 적용 계획은 범위와 확인할 효과로 나누었습니다

적용 범위는 신규 모바일웹 화면과 UI 개발부터 시작하는 것으로 정리했습니다. 이후에는 디자인 검증, 코드 리뷰, 테스트로 확대하는 방향을 두되, 지금 준비한 범위와 앞으로 확장할 범위를 함께 묶어 성과로 표현하지 않았습니다.

실제 적용 과정에서 확인할 항목도 보고 자료에 남겼습니다.

  • 화면 개발의 생산성이 어떻게 달라지는가
  • 생성 결과가 디자인 의도와 얼마나 일치하는가
  • 기존 공통 컴포넌트를 얼마나 재사용하는가
  • 적용 경험을 바탕으로 어떤 운영 기준을 보완해야 하는가

이 항목들은 실제 업무에 적용하면서 확인하려는 대상이었습니다. 코드 생성이 가능하다는 검증에서 나아가, 검토와 보완을 포함한 개발 과정에서 효과를 살펴볼 필요가 있다고 생각했습니다.

디자인과 개발의 협업 기준도 실제 적용 과정에서 구체화할 계획으로 남겼습니다. 공통 컴포넌트를 우선 활용한다는 방향은 정했지만, 세부 운영 기준은 함께 조정해야 할 부분이었습니다.

보고를 준비하며 다음 업무의 기준이 보였습니다

자료를 정리하는 과정에서 이미 준비한 기반, 실제로 적용할 범위, 이후 확인할 효과가 서로 다른 설명이라는 점을 다시 보게 되었습니다. 각각을 분명하게 적어야 현재 위치와 다음 작업을 함께 전달할 수 있었습니다.

이번 보고에서 생산성 향상을 숫자로 말할 수는 없었습니다. 대신 어떤 자산을 활용하고, 누가 결과를 검토하며, 무엇을 확인하면서 적용 범위를 넓힐 것인지는 설명할 수 있었습니다.

보고를 준비하면서 검증한 범위를 출발점으로 삼고, 실제 업무에서 확인할 것을 정할 수 있었습니다.

AI 업무 적용은 코드 생성 기능의 도입보다, 생성된 결과를 팀이 검토하고 활용할 수 있는 기준을 세우는 일에 가까웠습니다.