"글쓰기" 태그로 연결된 6개 게시물개의 게시물이 있습니다.

들어가며​

3월~4월은 flutter-web로 구현된 오픈닥터 웹 서비스를 Next.js로 마이그레이션하는데 집중했던 2개월이었다. 이번 회고에서 오픈닥터 고객(의사)/개발팀이 겪었던 문제와 솔루션을 공유하고 결과를 정리해보며 마이그레이션을 마무리하고자 한다. 장기적인 성과는 6개월 후에 적어보려고 한다.

먼저 결과부터​

Q. 마이그레이션을 통해 고객에게 무엇이 좋아졌나요?

A1. [의사] "강남 피부과 개원 분석" 같은 자연 검색으로 새 고객이 오픈닥터를 발견할 수 있게 됨.

• A1. [SEO] 구글 노출/클릭(수) 이/가 15.2배/1.67배 상승
  • ※ 측정 기준: 11월 10일 기준 6.7개월 전후 비교
• A2. [SEO] SEO에 중요한 수치인 FCP 16배 상승

A2. [의사고객/사내고객] 문의가 빠르게 제품에 반영됨.

• 마이그레이션 이후 배포 빈도 약 2배 증가
  • ※ 측정 기준: 11월 10일 기준 6.7개월 전후 비교

문제​

• 오픈 닥터를 모르는 잠재 고객이 네이버/구글 검색으로 우리 서비스를 알 수 있는 기회가 적다.
• 오픈 닥터 서비스를 유지 보수하기 어려운 환경이다.

1. 오픈닥터 관련 검색 결과가 적다.

• "강남 피부과 개원 분석" 같은 자연 검색으로 새 고객이 오픈닥터 페이지로 유입될 수 있는 경로가 존재하지 않음
• 월 노출 9,390회에 정체 - 이미 "오픈닥터"를 아는 사람(브랜드 검색)만 유입 가능
  • 일 단위로 환산하면 하루 노출 313회, 실제 클릭(유입)은 하루 10명 남짓

1. 서비스 기능 수정에 시간이 많이 소요돼 개선이 활발하지 못하다.

• 오픈닥터 지도 영역 수정이 필요할 경우 3개의 프로젝트를 동시에 실행하여 수정해야함.
  • 한 곳 수정하면 여러 곳에 영향을 주는 환경
• 개발 서버에서 지도 UI를 수정 시 결과를 확인하려면 15초 ~ 30초 정도 대기 발생. 윽… 비효율

솔루션​

SEO 지원이 안되고 잘 모르는 “플러터”에서 “넥스트”로 마이그레이션한다. 다만 한 번에 없애지 않고 점진적으로 없앤다.

Why. 왜 한 번에 없애지 않고 점진적으로 없애야하나요?

1. 운영 중인 서비스 : 고객이 실시간으로 사용 중
2. 프로젝트 규모 : 입지 분석 / 매물 / 의원 / 리포트 등 여러 도메인이 존재

2가지의 이유로 조금씩 플러터의 영역을 축소하는 방식으로 진행하였다.

How 1. [2025년 7월] 조금씩 갈아끼울 수 있는 환경 구축​

철훈님이 플러터웹 안에 리액트로 개발할 수 있는 환경을 만들었다. 첫 적용은 아래의 두 상담 신청 기능이었다.

• 입지 상담 신청
• 매물 상담 신청

How 2. [2025년 11월] SEO를 위한 Next.js 최상위 이중 iframe​

위와 같이 조금씩 넥스트로 갈아끼우던 와중 커뮤니티를 위한 SEO 작업이 시급한 상황이었다. 그래서 개발팀 논의가 진행됐고 결과적으로 아래 그림과 같이 아키텍처를 개선하는 작업을 하기로 결정됐다.

넥스트를 최상위에 두고 SEO를 챙기는 동시에 기존 플러터를 안에 넣음으로써 사용자에게는 어떤 영향도 가지 않도록 한 설계이다.

How 3. [2026년 2월] 마이그레이션 마무리를 위한 업무 프로세스 설계​

개발팀 미팅을 통해 26년 3월 말까지는 마이그레이션을 끝내는 것을 목표로 했다. 약 3개월간 목표한 마이그레이션 범위의 50퍼센트를 진행했었다. 그러던 와중 AI의 발전이 계속되었고 그 전과 확연하게 결과물도 달라지는 것을 느꼈다. 그래서 작업 방향을 바꿔서 어떻게 AI에게 더 잘 시킬 수 있을까 고민하기 시작했다.

그 결과 AI가 더 잘 이해하기 쉽게 작업 목록을 작게 쪼개는 작업을 시도했다. 왜냐하면 우리 프로젝트에는 AI가 모르는 맥락이 많기 때문에. 예를 들어 어느 부분은 iframe이고 상태는 어떻게 관리해야 하는 등 그런 맥락이 많기에 더 작게 쪼개서 쪼개진 작업에 대한 맥락만 넣어주고~

이 과정에서 문제를 더 명확하게 나누어 AI에게 요청해야 하는 게 얼마나 중요한지 알게 됐다. 결국 기획은 사람이 해야 하는 게 맞다.

How 4. [2026년 3월] 배포 후 혹시 문제가 있으면 되돌릴 수 있도록 안전망 확보​

마무리 단계에서 또 하나의 중요한 의사결정이 있었다. 배포했을 때 빠르게 되돌릴 수 있도록 피처플래그를 도입하자는 규석님의 의견이었고, 이를 기반으로 마이그레이션을 진행하기로 했다.

배포 환경은 환경 변수를 활용하여 배포할 때 Next.js 화면을 보일 지 Flutter 화면을 보일 지 결정하게 하고 개발 환경에서는 토글을 활용하여 각 화면을 비교해보면서 기능에 문제가 없는지 확인할 수 있었다. 이 덕분에 마이그레이션 완료한 UI에 문제가 없는지 혹은 누락된 기능은 없는지 빠르게 확인할 수 있게 됐다.

이와 같이 마이그레이션이 마무리됐고 그로 인해 결과는 아래와 같다.

결과​

• [A1] SEO 증가

  • 총 노출수: 15.2배 상승 (+1,421%) (9.73천 ➔ 14.8만)
  • 총 클릭수: 1.67배 상승 (+67%) (4.28천 ➔ 7.18천)
    • ※ 측정 기준: Next.js 아키텍처 개선 시점(25.11.11) 기준, 개선 전/후 동일 기간(약 6.7개월) 구글 서치 콘솔 데이터 대조

• [A1] 성능 증가

  • FCP : 15.9s ⇒ 1.0s 16배 개선
  • LCP : 18s ⇒ 5.4s 3.4배 개선

• [A2] 배포 빈도 약 2배 증가로 고객 피드백 즉각 반영 체제 구축

  • 마이그레이션을 통해 프론트엔드 개발 생산성이 대폭 향상되었으며, 이는 실제 배포 횟수의 획기적인 증가로 증명됨. (AWS Amplify 배포 로그 기준, 개선 전/후 동일 기간 6.7개월 대조) - 개선 전 (Flutter 환경): 총 92회 배포 - 개선 후 (Next.js 환경): 총 180회 배포 약 2배 증가 - 결과: 고객의 요구사항이 병목 없이 당일 제품에 즉각 반영되는 쾌적한 환경 구축

마무리하며​

마이그레이션을 진행하면서 AI를 통해 업무 난이도가 낮아지는 것을 실제 체감했다. 마이그레이션 초반에는 백엔드 API의 DTO 및 Entity들을 살펴보며 분석하고 그에 따라 화면에 어떻게 변화하는지 일일이 추적하며 Next.js로 구현했었는데

마이그레이션 중반서부터 AI에게 DTO 및 Entity 그리고 화면이 어떻게 설계되었는지 분석을 시키고 이를 이해한 후 Next.js로 어떻게 구현할지 AI와 논의하고 구현을 시켰다. 이런 방향으로 업무를 진행하는 방식이 조금씩 변화되는 과정이었다.

AI시대에 개발자는 어떻게 성장해야 하는지 말이 많다. 어떤 것이 맞는지도 모르겠다. 26년 상반기의 나의 가결론은 우선 '나'를 제대로 알고 기본기를 닦아야겠다였다. 내가 무엇을 좋아하고 무엇을 싫어하는지 무엇을 잘하고 무엇을 못하는지 조금 더 업무 환경에서 파악해보려고 한다. 의식적으로 업무 일지를 작성해보려고 하고 이를 회고에서 공유하는 식으로 나를 더욱 찾아가보려고 한다.

결국 빠르게 변화하는 사회에서 유연하게 적응하기 위해선 자신만의 기준이 있어야함을 다시금 깨닫는 시간이었다.

그래서 '나는 어떤 사람인지?'를 하반기에 잘 정리해서 회사에서 Impact를 낼 수 있는 인재로 거듭나고 싶다.

또한 다가오는 5월에는 개발팀에 큰 변화가 있을 예정이다. 개발 리더 포지션으로 한 분이 입사하실 예정이어서 어떤 변화가 있을지 기대된다. 그래서 5월에는 개발팀장님 오시면 적응 도와드리고 우리도 덩달아 긴장하고 있는데 잘 적응하는 게 목표이다.

다들 파이팅입니다.