클로드코드가 바이브코딩 툴 (다이어그램 시각화 및 실행 툴) 을 써서 바이브코딩할 수 있게끔 하는 프로젝트임
이번에 실험한건 메인 패키지에서 기능을 새로 개발할 때 프론트엔드 백엔드에 자동으로 코드를 추가하는 작업인 'code generation' 을
코드로 짜는 대신 다이어그램을 짜게 하는 실험임
코드를 가다듬은 결과 클로드 코드는 아래와 같은 code generation 다이어그램을 만들어냈음
어우 너무 복잡하다 싶은데
어? 보니까 이어져선 안될 선이 보임
워크플로우는 말 그대로 선이 이어진 순서대로 실행하는건데
저기에 선이 있으면 앞에서 선행돼야 하는 작업이 끝나기 전에 저 작업이 실행되어 버림
그동안에 code generation 워크플로우에 애매하게 에러가 계속 나서 뭐가 문제인지 잘 몰랐는데
다이어그램을 그리게 하니까 한방에 문제를 포착해서 저 부분 연결을 지우고 순서대로 실행시킬수 있게 수정했음
그냥 이건 후기 같은거고 정식으로 프로젝트 뭔가 잘 만들어지면 그때 제대로 설명서랑 같이 올려봄
무슨말이지..
이럴바엔 내가 그냥 코딩하는게 낫겄다
저걸 너가 짜겠다고?
@약팔이아님 뭑
무한 재귀가 온다
재귀 개선
바이브로 바이브 해버리기 ㄷㄷㄷ ㅎㅎ
좋은 프로젝트에요. 다만 탑다운 방식의 코드 생성은, 기능별 순환 의존성 검증이 어려워서 경험상 어느정도 사이즈까지는 편하게 스케일업 ( 5만줄 언더)이 가능할 것 같아요. 대충 2-3만줄? 멋집니다.
질문있어요. 저게 왜 탑다운 방식이에요? 바텀 업 방식이나 스타형이 아니라요. 초보라 잘 모르겠어요. 실례가 안된다면 알려주시면 좋겠어요.
탑다운이라기보다 래핑에 가깝긴함
@약팔이아님 고마어.. 나 완전 초보라서 되게 궁금했거든.
@약팔이아님 잠깐만.. 나 더 알아보고 왔는데 이거 나쁜 패턴 아니냐고 물어본거네? 진짜 나빴다.. 미안해. 나 코드 갓 배우는 중이라 진짜 몰랐어.. 내가 정말 무례했구나. 퍼플렉시티한테 물어보면서 배우는 중이거든
@솔담비딸기카나페 며칠 술을 좀 마셔서 늦게 왔습니다. 개발을 할 때의 접근 방법에 따라서 편의상 이런저런 방식으로 부르는데... 프로젝트가 엄청나게 비대해지고 (경험상 대충 2천개 파일 이상, 코드라인 20만줄 이상부터?) 나면, 전체 프로젝트를 한명의 개발자가 전부 명령해가면서 만들기가 어려워집니다. 그러다보니 보통 하나의 모듈화 된 기능을 소규모의 팀이 맡아서 개발을 담당하게 됩니다. 하지만 소규모-중규모 ( 코드라인 10만줄 밑, 파일수 500개 밑 정도?)에서는 소수의 CTO/PM이 전부 의사결정을 할 수가 있는 편인데 탑다운 방식의 매니지먼트가 가능하지요...
@솔담비딸기카나페 즉, 프로젝트의 규모가 아주 커지지 않은 상태에서, 관리/개발자가 전체 프로젝트를 그의 머리속에 다 담고 있을때에는 그런 개발이 가능한데 생각보다 그 시기가 빠르게 찾아옵니다. 저는 빡통이라서 코드 한 2만줄만 넘어가도 슬슬 무슨 코드를 작성했었는지 잊어버릴때가 많습니다. 그런데 그런걸 이렇게 시각화 해 두면 그 가시범위가 너 넓고 장기화 되니까, 초기 MVP의 사이즈 제한을 더 넓게 잡을 수가 있게 되지 않을까 싶더군요...
@솔담비딸기카나페 여전히 바텀업의 소규모 애자일 팀의 모듈 개발에도 적용 가능한 솔루션이기 때문에 제가 말한 '프로젝트'단위의 적용은 커지면 어렵다 라는건 잘못 된 말 일 수도 있겠습니다.
@아브소 고맙습니다. 저 그동안 공부 열심히 해서 이제 조금 더알게됐어요. 저게 얼마나 멋진 설계인지 자꾸 배우고 있어요. 병렬 테스크를 부딪치지 않게 세심히 조율한,예술작품이더라고요..그리고 받아서 흩뿌리는 의도적 설계인 것도 배웠어요. 왜 탑다운인지도 알았고.. 되게 존경해요.
@솔담비딸기카나페 .........????????????????????
@솔담비딸기카나페 조금씩 뭔가 알게 된다는 느낌