유럽에서 개발자로 재직중인 K입니다.
이제 개발자들이 그냥 AI코드를 여과없이 올리는 상황이고
매니저들은 암튼 기능 추가가 빠르니까 그걸 그냥 받아들이는 형국까지 와버렸네요.
그 결과, 예전같았으면 feature별로 커밋 쪼개라, 관계없는 수정 빼라, human readable 하게 해라 등등 수많은 리뷰달릴 코드들이
하루에도 몇개씩 머지가 되어버립니다. 이제는 어차피 개발을 계속 AI가 할 꺼니까 human readable 할 필요조차 없다는거죠.
특히 인력이 절반 가까이 줄어든 상태인데 일정은 그대로인 상태이니 점점 AI에 의존하고 있는거 같습니다.
매니저 입장에선 효율성이 2배이상 늘어난거긴 할텐데,
더미코드, 테스트코드, 커밋만 봐서는 무슨 피쳐인지도 모를만큼 뒤죽박죽 섞인 코드들이 하루에 몇개씩 머지되고 있는거 보니까 참 맘이 착잡하네요. 이 팀이 특히 좀 개판이긴 합니다만...ㅎㅎ;
심지어 sanity check fail 뜨니까 AI가 sanity check 되게 고치는게 아니고 우회해서 sanity check를 무력화시켰더라고요 ㅋㅋ 그리고 그걸 그냥 머지... 아 진짜 무슨짓이야ㅏㅏㅏ
배관이나 전기기사를 공부할 때가 되었나봅니다.
특히 내가 작성한 대규모 코드 다른 사람이 AI로 수정하고 문제 생긴거 뒤치닥거리 할 때 열불터짐..;;
그게 몇번 반복되다 보니까 스파게티 코드란 말도 안나올 정도가 되더라구요.
모양이나 주석은 깔끔한데 분석을 해보면.........
저도 코드 들은 안 보게 되네요
여기서 꼰대스럽게 피쳐별로 커밋 가르고 어쩌고 를 해야할지 그냥 납득하고 넘어가야될지 너무 고민되네요.
(대충 두통 앓는 짤방)
은퇴하려면 20년이나 남았는데 이게 무슨 꼴입니까 ㅠㅠㅠ
개별 구현보다 설계와 테스트 결과를 중심으로 검증하는 방향은 맞다고 봅니다.
다만 그래도 최소한 시스템이 어떤 구조로 구성되어 있는지
주요 컴포넌트가 어떻게 연결되어 있는지,
현재 구현이 원래의 설계 방향과 일치하는지 정도는 사람이 지속적으로 추적할 수 있어야하는데
매니저가 코드와 구조를 거의 이해하지 않은 상태에서
AI가 만든 결과물을 테스트 통과 여부만 보고 머지하기 시작하면
단기적인 개발 속도는 빨라질 수 있어도 장기적으로는 아키텍처 일관성, 기술 부채, 장애 원인 추적 측면에서 상당한 리스크가 생길 수 있을텐데요.
언젠가 터질 폭탄인데 미리 준비는 해야죠.
코드를 바이너리 취급한다는게 딱 좋은 설명인거 같습니다.
이제 코드 읽는건 어셈코드 읽는 취급 받을 거 같아요 ㅎㅎ
"단기적인 개발 속도는 빨라질 수 있어도 장기적으로는 아키텍처 일관성, 기술 부채, 장애 원인 추적 측면에서 상당한 리스크가 생길 수 있을텐데요."
일정 및 매년 신제품 발표에 쫒기는 제조회사들이다 보니 어쨌든 올해 낼 제품만 챙기는거 같습니다.
경직된 C레벨은 그냥 내놓으라고만 하고, 퀄리티는 떨어지고, 매출도 떨어지는데 C레벨은 수십억씩 보너스 받고..
아이고 머리야 ㅡ,.ㅡ;;
LLM 이랑 컴파일러는 달라요. 컴파일러에 같은 코드 10번을 빌드시킨다고 결과 다르게 나오진 않죠. LLM 은 이 세션 저 세션의 문제 해결 방향이 판이하게 다를수도 있어요. 코드=바이너리 프롬프트=코드 로 대체되는 개념은 아니라고 봅니다.
독일 임베디드는 멸망중이라 ㅠㅠ.....
추측하자면 commit 및 issue-ID 작성은 개발자가 하겠다고 해놓고 그걸 제대로 안해서 계속 문제생기니 우회해버린거 아닌가 싶습니다.
무엇을 이라는 목표만 정해서 알려주면 어떻게라는게 말씀하신것처럼 신뢰가 안가요.
어떻게를 잘 구현했는지를 ai 로 검토시키는 방법이 현재 방안 중에 하나가 아닐까 생각됩니다.
다들 어떻게라는 것을 이제 ai 가 더 잘 한다고 하지만 제 경험상으로는 확률적으로 잘 했던 것일 뿐이더라고요.
이게 다 그렇게 해야하는데, 거대 프로젝트다 보니 사방에서 코드가 난리네요.
정신차려보면 70바이트가 넘는 정규표현식을 넣어놓지를 않나,
딱 Test Case 만 통과하는 코드가 작성되어있질 않나.... 아이고 혈압이야... ㅠㅠ
언제 무슨 짓을 할지 모르는 놈들이군요 ㄷㄷㄷ
Issue-ID 를 적어야 하는데 Issue-ID 를 체크 안하도록 Flag를 추가했더라구요. (....)
러다이트 운동이라도 해서 20년만 더 버티면 은퇴인데...
금속노조 뭐하냐!! (*독일 금속노조 소속입니다.)
뭔가 코드에 대한 애착도 안생기고, 수정사항 검토도 대충 보고,
나중에는 permission 도 다 주고 알아서 하라하고, 심지어 crendential 한 정보도 그냥 다 주게되더라고요 ㅋ
문제 생기면 또 고치라고 하고, 나중에 보면 땜빵에 땜빵에 땜방 ㅋㅋㅋ
제 모듈의 미래를 보는거 같군요 (...)
의 반복을 통해서 토큰량은 더 늘어나고, 사람은 도저히 새로 생성되는 코드량을 따라갈 수 없게되고...
분명히 올바른 방향은 아닌거같아요..
그냥.. 똑똑하게 쓰려고 하지말고 발전된 편리한 구글처럼 쓰고, 사람이 보면서 수정하는게 낫지않나 라는 생각을 합니다.
저도 그렇게는 생각하는데 매니저는 당장 할당량이 중요하다 보니...
후 샏...걱정됩니다 ㅎㅎ
저희는 개발리더가 설계, 구현은 ai가 하더라도 ai가 지라에 이슈 남기고 체크해서
개발방향성 체크는 하려고 하는데 그정도에도 다들 뒤에서 꼰대, 낙오자 취급합니다.
문제는 저희회사는 그 AI를 쓰는 사람조차도 인건비 낮은 인도에게 외주를 주는지라..........
개발자의 연속성도, 퀄리티도, 책임감도 낮은데 AI가 그 전체적 개발 일지를 다 공유하는것도 아니라서...
근데 이렇게 적고보니 Readme.MD 같은데에 AI의 사고 및 추론을 기록해가면서 하라고 하면 여러 개발자의 AI가 다른 세션에서 일할지라도 좀 일관성이 생길까 싶기도 하네요. 다음번에 제가 컴포넌트를 맡으면 한번 해봐야겠어요.
개발자 연봉은 떨어졌는데 SE 연봉은 올랐다고
인프라가 개발보다 좀 더 버틸거 같다고 하시더라구요.
클라우드 RDS도 자동 튜닝에 운영지원하고 힘드네요.
사실 그런 효율화(?)덕에 세계구 남바완급이던 회사가 나락 급행열차 탄 건데 아직도 임원들은 수십억씩 인센받으며 생산직을 추가급여없이 4시간 더 일하게 해야한다고 난리더라구요 ㅎㅎ
뭐 구세대로써 불안한거죠 ㅎㅎ "이해할 수 없는 무엇인가에 몸을 맡겨도 되는 것인가" 라는거죠.