일든 컨텍스트 뭐 그딴거 안씁니다
그거 정리할 노력으로 직접 코딩하는게 빠른거 같고요
일단 오늘 바이브 코딩으로 뭐 하나 기능 넣으려고 했다가
후회하고 롤백했는데
일단 ai 이놈은 뭔가 똑똑하게 코딩하려고 하고
그러다보니까 코드가 어렵네요
누군 컨텍스트 정리 잘하면 잘한다는데...
일단 이놈이 한 50줄 코딩했는데 가독성도 별로고
해서 그냥 롤백하고
대충 잔머리써서 한 10줄로 간단하게 코딩했는데
뭐 일단 원하는대로 돌아는 갑니다
아... 저는 바이브 코딩이랑은 안맞나봐요
언젠가 버스팩터가 0에 수렴하는 코드들이 판을 치겠죠...
가장 이해하기 쉽고
가정 가독성이 좋조.
내가 보기에..
물론 저도 "바이브 코딩"이라부르는 행위를
몹시 부정적으로 생각합니다.
아주 단순한 케이스 아니면
생각보다 그것도 쉽지 않더라구요.
개발자의 롤에 대해서 생각해 볼 시기인거 같아요
다릅니다! 버스팩터가 0인 산출물들이 넘쳐 나는 와중에 버스팩터가 1보다 큰 산출물들이 더 인정 받을거라 생각합니다
반례가 버스팩터라고 하신다면 제가 앞서 말씀드린 식판 예시에서 칸의 크기를 조정하고 이 칸들의 경계를 어디에 붙일까는 아직 사람의 영역이라고 말씀드렸습니다. 이게 다시 말해서 칸의 구획을 나누는 패키지 경로, 클래스 이름, 적용할 디자인 패턴 의사결정입니다.
그러면 이 프로젝트 구조와 철학, 개념을 프로젝트 팀원이 공유한다면 정말 사람이 교체되어도 ai가 찍어내는 코드는 오히려 더 일관성이 있습니다. 그래서 제가 지금은 이 식판 하나 직접 주도적으로 만드는 위치에 있어서 밥벌이가 되는데 그냥 이 식판 자체가 그냥 나오는 시간이 얼마나 걸릴지가 관건입니다. 그 이후의 세상에는 식판을 5개든 10개든 쌓아서 만든 프로젝트 단위를 혼자 해야할텐데 이런 프로젝트를 발주할 대기업이 몇 개나 있을까요.
그리고 코드를 너무 완벽하게 짤려고 하는거 같아서 더 불편합니다
저는 그냥 대충 술렁술렁 짜는 스타일이라 ㅎㅎ
아 그리고 간혹가다 뭐 하나 고치고나면 뭐하나 고장내는 케이스가 종종 있더라고요
그런데 실제로는, 잘 설계된 구조 안에서 일부 보조 역할로 활용하면 오히려 버스팩터를 줄이고 일관성을 높이는 경우도 많습니다.
루비온님 스스로도 ‘나만의 코딩 스타일이 있다’고 하셨는데, 그만큼 독창적이고 자유로운 방식은 강점이면서 동시에 다른 사람과의 협업에서는 이해 장벽이 될 수 있지 않을까 싶습니다.
물론 이 글 하나로 생각이 쉽게 바뀌긴 어렵겠지만, 같은 개발자로서 드리고 싶은 말씀은 지금이 개발 생태계의 큰 변곡점이라는 점입니다. 이미 많은 변화가 시작되고 있고, 앞으로 이 변화에 어떻게 적응하느냐가 커리어에 큰 차이를 만들 것 같습니다. 루비온님도 그 흐름을 잘 타고 넘어가시길 진심으로 바랍니다.
2년뒤면 좌절감
3년뒤면 날라다니실겁니다.
제 경험상 그러네요