내가 AI를 구축해 아키텍처 다이어그램을 그리게 한 방법 (위키가 계속 죽어서)

Source: Dev.to

문서 드리프트의 역설 🤖

몇 달 전, 나는 벽에 부딪혔다. LLM을 활용하면서 코드를 그 어느 때보다 빠르게 배포했지만—기능이 연이어 출시되었다. 그런데 3주 뒤, 내가 직접 작성한 모듈을 디버깅하려니 코드는 있었지만 맥락을 잃어버렸다.

나는 속도에 대한 조용한 살인범, 문서 드리프트에 시달리고 있음을 깨달았다. 코드는 진화하지만, 지도는 정체된 채였다.

나는 “좋은 개발자” 의식—주석, Confluence 업데이트, 그리고 Miro에서 수동으로 다이어그램 그리기—을 시도했다. 새로운 PR을 머지하는 순간, 다이어그램은 바로 죽어버렸다.

검증 (우리는 책이 아닌 지도를 원한다) 🧠

이를 해결하기 전에 Reddit에 물었다: “문서를 동기화하는 것이 왜 이렇게 고통스러운가?”

답변들은 내 가설을 확인시켜 주었다:

• 문제는 게으름이 아니다.
• 문제는 아키텍처다.
• “별도의 문서는 금방 오래되고, 종종 쓸모없을 정도다.”

핵심: 우리는 정적인 책이 아니라 살아있는 지도가 필요하다.

해결책: MIVNA 구축 🛠️

문서는 사후 작업이 아니라 CI/CD 파이프라인의 일부가 되어야 한다고 결심했다. 그래서 MIVNA를 만들었다. 개발자들이 머무는 곳, GitHub에 살아 있게 만든 것이다.

결과: 드리프트 제로, 섀도잉 제로 📉

• 시각 우선: 고수준 아키텍처 다이어그램을 자동으로 생성한다.
• 레거시 안전: senior 개발자가 며칠 동안 “섀도우”해 주지 않아도 무섭던 레거시 모듈을 즉시 매핑한다.
• 항상 동기화: 코드가 바뀌면 다이어그램도 바뀐다. 그게 전부다.

여러분의 도움이 필요합니다 (프라이빗 베타) 🧪

“위키 부패”에 지친 엔지니어링 팀을 위해 프라이빗 베타를 열고 있다. 고객을 찾는 것이 아니라, 빌더들을 찾아서 깨뜨려 보고 뭐가 부족한지 알려주길 원한다.

질문:

• MIVNA가 여러분의 워크플로에 맞나요?
• 다이어그램을 PR 안에 두는 것이 좋나요, 아니면 중앙 대시보드가 좋나요?

🔗 여기서 확인해 보세요: https://mivna-diagrams.lovable.app/

댓글로 여러분의 생각을 알려 주세요!