AI를 겪어보니 개발자는 끝났네요
조회 39,926 · 공감 16 · 댓글 164
1주일 작업이 AI 에 몇마디 물어보니
하루면 마무리가 되네요. 디버깅도 에러메세지 몇번 던져주면 해결되고 .. 개발자는 물론이고
경제적 독립 안되어서 나이들어서 까지 일해야 할 사람들은 할수 있는직업이라곤 요양보호사 말고는 딱히 떠오르질 않네요.
이건 선택의 문제가 아닌것 같습니다
모두의공원 최근 글
- 북한, 대남확성기 시범 테스트 시작했네요
- 성범죄자알림e로 성산시영 가양6단지 이런데 봐보세요
- 여당에서 가덕도신공항 특별법 개정 추진 [2]
- 어차피 공공임대 공급은 임기내 불가능해요
- 임대주택출신으로서 임대주택은 필요합니다. 다만 조건이 있습니다. [5]
- 제가 임대싫어하는 이유는 좀 다른데 임대아파트 많은 동네를 가보면 [14]
- 청년청년 지겹지만 '안'산 선택의 댓가도 치뤄야죠 [9]
- 민주당의 부동산 안정화? 정책에 대해 [5]
- 임대주택 반대합니다. [13]
- 저는 공공임대를 구독 서비스 같은 개념으로 접근하면 어떨까 합니다. [12]
- 클리앙에 부동산 전문가들이 참 많이 계시내요 [8]
- 임대성애자 오세훈 삽질만 봐도 장기임대가 얼마나 허황된건지 [10]
- 전작권, 제미나이 한테 물었습니다 [11]
- 민주당 '닥공' 승부수…공공주택에 38조 역대급 투입 추진 [8]
- 임대비율 높은 아파트 집값 [14]
- 기왕이면 외노자 대신 한국인 많이 쓰자는건데 정말 지엽적이네요 [14]
- 퇴근 할 때 장 봐야 하는데 날이 추워서 장 보기 싫네요 [5]
- 지방 거주민도 서울 임대 아파트 들어가고 싶습니다. [6]
- 사형 구형에 '뿔'난 尹변호인 '윤석열 사형? 대한민국 사법 무너지고 있다' [5]
- ..미군 장성 또 '축출'...'미군 내부 술렁' [4]
- 민주당 김문수 의원 외 11명, '학원 선행학습시 6개월 영업정지' 발의 [30]
- 돌고래유괴단 2심도 패소 [11]
- 만약에 말입니다. [2]
- 찾아보면 나오는 답에 대한 글
- 김민석이는 민석티비 없앴겠죠?? [2]
- 서울 임대주택, 이 정책은 도대체 무엇을 해결하려는 걸까요? [17]
- 신규 공공임대 후보지 내부협의없이 발표, 김포시장 '매우유감' [8]
- 저녁 뭐먹을지 고민입니다 [8]
- 홈페이지 보안 관련하여 이런 공문을 받았습니다. [13]
- 누구나 양질의 주거 욕구는 당연한거고.. [12]
댓글 164
AI의 윤리적 판단을 인간 기준에 맞게 개발하는 개발자는 살아 남을 수 있을까도 싶네요.
이마저도 AI가 대체하면 인류는 어떻게 될지...
개발이 문제가 아니고 그냥 자본주의가 흔들릴거예요.
사람들이 거리로 나앉고 은행이무너지고 집이 경매로 넘어가고
그래도 인간의 역할이 줄어들긴 할듯 합니다. 그 폭을 줄이기 위한 제도 법 정치. 윤리가 성숙해야겠지요
https://www.clien.net/service/board/park/17032665CLIEN
저는 설계 분야인데... 이쪽은... 뭐 아직 멀었습니다. 쥬니어 급도 안되더라구요.
계산도 틀리기 일쑤고...
특이점이라는게 한번 오면 그 파급력은 어마무시할겁니다
ai가 해결한게 해결된게 아니고 오히려 다른 문제들을 야기하는 방향일 경우가 워낙 많아서요
이게 시니어급 개발자의 입지는 더 확고해질것 같은데 문제는 신입 및 쥬니어죠.
시니어가 쥬니어 끼고 같이 작업하는것 보다 시니어 혼자 AI를 이용해서 작업하는게 훨씬 능률이나 결과물이 좋게 나오더라구요.
완료 된다고해도 숙련공 성장 이슈 문제가 있어요.
지금은 괜찮은데 앞으로는 AI를 활용할 숙련공으로 성장이 안되니..
의무적으로라도 신입 받고 교육하고 AI활용할수있는 인재키워내야지요
성향차이는 있을 수 있겠지만 시니어가 주니어를 싫어하지 않습니다 젊은이들이 오면 좋죠
시간이 지나도 이문제는 쉽게 해결안됩니다.
바이브 코딩이 활성화될수록 고급프로그래머 연봉만 쭉 올라갑니다
필요 인력이 줄어드는게 문제인거 같습니다
시니어 3명, 주니어 10명가 필요한 프로젝트가 시니어 2명으로 줄어들수 있죠
시니어 2명은 연봉은 좀 오를 수 있어도,,,,결국 전체 파이가 줄어 들거 같네요
완전히 대체는 안될지라고요... 10명이 할 일을 이미 1명이 하고 있으니...
이렇게 단정하실 정도는 아닐텐데요?
An Empirical Study on the Impact of AI Code Generators on Software Development. 라는 논문이 이론적인 배경을 제공하고 있습니다.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253508
AI 에게 요약 부탁하면 잘 해줍니다.
저는 개발 경력이 10년이 넘는데도 최신버전의 ai들 써보고 내리 결론은 확실히 ai가 모든 걸 다 하지는 못하겠지만 주니어 개발자들 일자리를 잠식 하겠다는 겁니다. 올초 1,2분이랑 지금이랑 또달라요. 빅테크들은 이미 SDLC에서 AI DLC로 빠르게 전환중이에요. 개발 라이클 사이클 전반에 필요한 요구사항의 수집과 정제부터 플래닝 개발 테스트 배포 모니터링까지 모두 ai가 도입되고 mcp server를 통한 agentic ai의 아키텍처가 말씀하신 단위별로 세세하게 컨트롤 할 수 있도록 변해가고 있습니다
결국 코드를 리뷰하고 컨펌하는 것은 경험있는 개발자가 될 수 밖에 없는 것이 현실이라 숙련된 개발자는 꼭 필요합니다.
Ai가 한 건 전부 다시 리뷰해서 체크해야 합니다. 이게 아는 사람이 아니면 되지도 않습니다.
작업은 대충 해주는데 책임은 안되는 거 같습니다.
솔직히 예전 빅데이타 같은 거처럼 커다란 물결 한번 지나가면 다들 잘 기억도 못할 거 같아요.
또 시작이시네요 (2)
검수부터 실 적용까지 다 사람이 해야됩니다.
AI로 인해 제작환경이 달라지고 구조가 바뀔수는 있지만 IT 산업이 쪼그라들기 보다는
전체 산업 파이가 커져서 종사하는 인력이 더 많아 질 수도 있다고 생각합니다
ai 엔진 개발자 연봉 알면 후덜덜해요.
코스프레 시작이신가요?
할수 있지만 답 나와있지만 잠깐 기억안나는거 프로토타이핑으로는 써도 저런 한계 때문에 골아픈 문제가 있죠.
본거 많고 기억력 끝내주고 손빠른 신입이지만 검증되지 않은 말을 막 하는... 검증이란 현실세계의 문제에는 아직 먼 거 같아요. 달리 말하면 충분히 답이 나와 있는거에서 빨리 답을 내는 수준으론 신입을 대체할수 있단 거긴하겠지만요.
https://www.clien.net/service/board/park/19056632?po=0&sk=id&sv=sangje&groupCd=&pt=0CLIEN
유료 AI 개발 서비스 이용해보고 있는데, 프론트엔드 퍼블리싱이나 구현은 정말 효율적이라는 점에 동의를 하는데
서버 사이드는 디테일한 요구사항에 맞추어 아키텍처를 설계하고 서비스를 구현하는 것을
바이브 코딩 방식만으로 대체하기는 어렵습니다. 아직까지는...
그리고 그런 업체들은 필요한 백엔드 서비스들을 충분히 갖추어 놓고 연동만 하는 수준이어서 없는 것을 구현하려면 일반인들은 할 수가 없는 구조입니다. 그리고 프론트엔드나 백엔드 둘 다 아주 디테일한 요구사항이나 장르로 들어갔을 때 전혀 구현을 하지 못하고, 특정 프레임워크에 한정되어 구현 가능했습니다.
ai로 하는 바이브코딩이라 하던데
실무에선 어디서 어떻게 만들어졌는지 모르는 코드들이 떠받치로 있어서 새로 짜고 싶어도 짤 수 없는것들이 수두룩 하죠
라이브러리가 지금은 버전 23.10.2 막 이런데 정작 시스템에선 9.8.6 이래서..
ai한테 물어봐도 업뎃하란 소리하고 안된다 하고 업뎃 방법 알려주고 리빌딩 알려주는데
이거 업뎃했다 뭔 사단 날줄알고 ㅎㅎㅎㅎㅎ
신입때 선배들이 왜케 업뎃안하고 옛날 코딩스타일 쓰는지 이해 안갔는데 그게 이해가 가야만 진정한 개발자구나 싶더군요
정보를 확인시 거짓을 진짜처럼 이야기해서 믿지 않습니다.
인터넷에 거짓 정보가 많을수록 엉망이 되는 것 같아요.
번역도 엉망으로 해주는 경우가 꽤 많더군요. 초안만 보고 수정해서 사용합니다.
부하의 문제 때문인지 제대로 일안하는 경우도 종종 보입니다.
기능 컴포넌트단위로 기가막히게 뽑아주는데
문제는 아직 전체적인 비즈니스 로직에 대한 컴포넌트간 연결이 안됩니다.
게다가 비즈니스 로직에 대한 방향성을 어느정도 개발자가 잡아줘야 쓸만한 결과물이 나와서
전체적인 로직을 담고 그것을 연결성 있게 만들어 줄 수 있는 혁신적인 메모리 기술이 나온다면 모를까 현재까지는 개발자의 입지가 좀 더 확고해진 상태입니다.
그래서 요즘 유행하는 것 중에 하나가
기능을 쪼개서 컴포넌트단위로 만든다음 컨테이너화해서 올리는 건데
전체적인 성능에 대해선 비효율적이어도 개발자없이 서비스 런칭이 가능해졌습니다.
물론 서비스가 커지면 최적화 과정을 위해 개발자나 엔지니어가 필요해지는데...
AI최적화를 기가막히게 해주지면 결국 그 컴포넌트를 연결해서 하나로 만드는건 아직까지는 사람입니다.
그래서 이런 컴포넌트간의 간극을 줄여주는 SaaS서비스가 당분간은 흥할것 같습니다.
개인적으로는 이런 간극을 줄여주는 주요한 서비스들중에 쇼핑몰쪽은 shopify나 stripe가 꽤 줄여줄 거 같고
요즘은 로직을 연결해서 flow대로 AI가 작성된 코드를 나올 수 있게 해주는 보조적인 서비스들도 많이 있고, 만들어진 결과물은 container화해서 올릴 수 있는 서비스가 있어야하니 오늘 오른 오라클같은 클라우드 서비스가 더 흥할 거 같습니다.
당분간은 이런 SaaS의 성장세가 미친듯이 커질거 같습니다.
기획자가 더 빨리 대체될 지도 모른다는 생각입니다.
모든 직업이 자유롭지 못하죠.
사실 이 부분은 AI의 문제라기 보다 기존 레가시가 AI에 적합하도록 구성이 안되어 있어서 그런 경우가 더 많습니다.
예전에 전산화 안된 업무를 전산화 할때 업무 표준 부터 수립해서 체계를 바꾼것 처럼 기존의 레가시 시스템 역시 AI에 적용을 하려면 좀 표준화 및 적절한 프롬프팅이 필수적인 요소인것 같아요.
레거시 코드를 어떻게 AI에 분석하도록 요청하셨나요?
레거시 코드 어시스턴트 시스템이 있으신가요, 아님 망 외로 코드를 전송하셔서 테스트 하신건가요?
저도 망분리 환경에서 AI 쓰고 싶은데 어떻게 하면 될지 고민입니다. 뭔가 회사 정책상 지원해 줘야 되는 거겠죠?
사명이나 AI서비스명을 알려드릴수는 없어 죄송합니다
요구사항 분석도 안되고..설계도 힘들고...
인간 개발자는 이제 이태리 명품 가죽공예의 영역이 될거라 봅니다.
인간의 순간사고능력을 넘어서버린 "수많은 세월동안 인간이 쌓아놓은 방대한 데이터"를 정리,요약해주는 영리한 툴에 지나지 않다고 봅니다.
AI를 두려워한다던가 맹신한다는건 결국 인간이 자신의 사고와 지능을 주체못해 스스로 먹히는 꼴이 아닐까 하는 생각이 듭니다. 마치 제 꼬리를 입에 문 뱀처럼.
AI의 편리함은 증명되었지만 그게 모든걸 다 해주진 않지요.
진행중인 모든 단계에서 신뢰받던 AI가 한번,딱한번 사고를 치면 최종단계에선 아주 큰 대형사고를 치게 되지요.(스카이넷?) 그래서 AI를 잘알고 이해하는 개발자들이 기획단계부터 관리를 않거나 아예 없으면 그상황엔 손도 못대지 않을까요. 현재 AI뿐 아니라 혁신적인 기술발전을 이루고 있는 모든 분야가 다 그렇습니다.
생각같아선 컴퓨터가 다 알아서 완벽하게 처리할 것 같은데 모든걸 알고 일을 시키는 사람과 그저 막연하게 말로만 일을 시키는 사람에 대한 AI결과물이 같을까요?
AI뿐 아니라 어느 분야던지 대게 그 분야에 대한 깊은 이해도와 경험을 가진분보다 업계초보분들이 이런 두려움을 가지시더군요. 시중 사람들의 기대와 달리 지금 당장 AI의 태생적인 한계를 정확히 느낄수 있는 부분이 AI상담사들입니다.
계속 발전이야 하겠지만 이건뭐..^^
윗분말씀대로 신입수는 많이 줄어들 겁니다. 소수의 경력자가 AI의 도움을 빌어 해결할 수 있으니.
그러면 이젠 많은 이들이 AI로 파생되는 다른 분야로 퍼지겠지요. 산업구조가 바뀔지언정 경력자나 전공자가 도태될일을 걱정할 정도로 심각한 상황은 아니지 않나 싶습니다.
프로그램 언어를 읽을줄 모르는 사장이 혼자 AI로 대량의 소스를 짜서 분석하고 최종 결정을 내리려면 결국 고급 개발자급이 되어야할거니까요
인공지능은 오늘이 제일 멍청합니다. 신입이든 시니어든 육체노동이든 지능 노동이든 전부 대체되는 건 시간문제에요. 그냥 인간 이상의 지능이 나오는 것이고 대체 못할 분야는 단 하나도 없어요. 인간은 무엇을 위해 사는가, 뭘 하면서 살아야하는가에 대해 고민할 시간이라고 봅니다.
지금은 오히려 백앤드쪽이 직접적으로 도움되는게 많은것 같습니다.
어차피 올해까지 일하다 말것도 아니라면 내년말쯤에는 AI는 어디까지 할까요?
어제도 1년이상 운영되던 서비스를 이틀정도 AI 이용해서 작업하고 30%정도 속도 개선되었다는 분이랑 이야기를 했네요.
아무래도 코딩관련 자료가 많고 개발자들이 만들고 있으니 코딩쪽 개선이 빠른데 멀티모달 도입되고 이미지나 영상을 인식하기 시작한 후로 대체불가능한 사무직 있을까 싶습니다.
- 어차피 프로덕선용 코드는 못만듬
- 조금만 복잡해지면 이상한짓 함
어차피 AI한테 시키는것도 아는 사람이 시켜야 결과물이 잘 나올수밖에 없습니다.
.....물론 신입/주니어 개발자들에게는 최대 위기죠
현실은 클로드코드랑 커서 기업 사용량이 미친듯이 폭주하고 있죠.. 본인 분야에서만 무리이고 남들은 다 잘 사용중인가 봅니다
생각할 가치조차 없이 다 틀려먹은 글이네요.
/Vollago
개인적으로 바이브 코딩할 때 Zone 경험의 유무가 초급과 고급을 나눌 수 있는 것 같은데 아직 우리나라에서는 생각과 손과 코드가 하나되고 2~3시간이 훌쩍 지나버리는 Zone 경험을 말하는 사람이 거의 없는 듯 합니다. 그 경험이 있다면 자랑스럽게 이야기할텐데요. 아직 초급 수준만 경험한 사람들이 많다는 것의 반증이겠지요.
많이 좋아졌는데 잘 가다가도 기존 코드를 싹 갈아입고 다른 기능만 남긴채 다 날려버리기도하고;
UI도 계속 바꾸거나; 뭔가 좀 그래요. ㅋㅋㅋ
하지만 이것도 전보단 나아진거라 점점더 좋아질 것 같아요.
AI가 알아서 할 수 있다는게 아닌데요;
마치 반자율주행기능 쓰면 완벽하게 자율주행되는줄 착각하는 부류랑 똑같은 ......한심하네요 좀
산업화 이후로 인간 한명이 할 일이 엄청 늘었다죠. 기술이 발전할 수록 사람 한명이 할 일은 더 많이늘어나서 과연 이게 좋은지는 잘 모르겠네요.
ai 로 노벨상을 받은 제프리힌턴 박사 인터뷰만 봐도 그렇습니다.
이게 말이 안되는 거면 노벨상을 아무나 주진 않겠죠.
요즘은 휴머노이드 로봇 분야의 발달도 엄청 가속화 되고 있어서 사실상 인간이 할 수 있는 모든일들이 ai 를 탑재한 로봇에 대체될것이야 라고 생각해요. 인간이란 종이 사라질지도 모른다고 이야기 하는 사람들도 있구요.
한번도 인간이 겪어보지 못한 변화이기 때문에 어딜 보고 참고할 만한것도 비견할만한 것도 없는것 같습니다.
그저 현재에 충실하고 꿋꿋하게 지금처럼 내가 생각하는 방식으로 미래를 대비하고 현재를 살아가는것 뿐..
과연 인간은 유토피아에 살게 될까요? 아니면 디스토피아 세상에 살게 될까요?
프론트쪽이 대체 속도가 더 빨라졌고 대체 가능성이 한층 더 높아졌습니다. 요즘 많이 사용하는 nextjs + tailwind 이 두개만 사용하더라도 하나 페이지가 거의 뚝딱입니다...
uxpilot 이라는 서비스를 써보면 간단한 관리자페이지나 메인 페이지를 그냥 거의 기획수준으로 디자인해주고 figma -> jsx 파일로 뽑아줍니다. 그냥 거기서 jsx파일 올려서 쓰면 프론트 50%는 끝입니다. 이제 그 내부 구조에 ajax도 붙이고 동작을 조금 붙여야합니다만, store구조도 super cloude한테 요구하면 fetch까지 되는 것으로 모두 완료시켜줍니다..
그런데 백엔드는 약간 어렵습니다. 일단 비즈니스 로직이 녹아 있어야하고 프론트엔드처럼 한페이지 한페이지 컴포넌트로 쪼개서 개발할수 있는게 아니라서 모델 안에 로직이 정말 얽혀있어서 현재 AI모델의 기억의 한계때문에 전체적인 백엔드 구상이 어려운 상태입니다.
로컬 AI기반으로 그동안의 작업을 기억하고 설계를 하나씩 할 수 있는 시대가 온다면 백엔드쪽도 결국 대체가 됩니다.
그래서 요즘 백엔드를 세분화한 SaaS서비스에 의존해서 바이브코딩하는 추세입니다. 그냥 API만 연결하고 컨테이너화해서 배포하면 되게끔 변화되는 추세이지만, 결국 서비스가 커지면 컴포넌트간 오버헤드가 심해져서 비즈니스 로직 통으로 개발해야하는 상황이 와서 백엔드 개발은 아직은 갈길이 멉니다.
정말 아는 만큼 보이는 세상이 다르기 때문에 프론트앤드쪽도 더 공부를 많이 해봐야 할것 같네요. 님의 답변 글에 저도 한 수 배우고 갑니다.
백엔드를 돌릴때 고려해야할 엔지니어링적인 사항이 있기도 하고 분산처리를 위한 코드, 그리고 쿼리 최적화 문제도 있긴합니다만
가장 큰건 비즈니스 로직을 모델에 녹여내는 기술때문이기도합니다. 프론트에서는 이미 백엔드에서 1차로 가공된 비즈니스 로직을 보여주는 역할을 하기도 합니다.
커뮤니티 게시판 개발을 예로 들면
CRUD기반으로 간단한 게시판 로직을 세우면 백엔드량이 프론트보다 적을 수 있겠지만,
대체적으로 어느정도 게시판 크기가 커지고 커뮤니티 내 사용자의 수요가 높아지면
1. 1시간, 3시간, 6시간 추천수 많은 글을 백엔드 스케쥴러로 돌린다음 DB에 적재
2. 무거운 쿼리를 redis같은 메모리 디비로 옮기는 캐시 작업
3. 게시판 댓글에 들어오는 feed 단어를 분석하기 위한 실시간 kafka 스트리밍 작업
4. 불특정 다수의 게시판 오염을 탐지하기 위한 Hbase기반의 빅데이터 분석 추가
5. 업로드 되는 이미지를 object storage에 저장하고 썸네일 이미지, meta tag로 보여주는 og:image 사이즈 등으로 구분한뒤 리사이즈해서 저장하는 로직
대충 생각나는 5가지 작업만 생각해도 작업량이 어마무시합니다.... 물론 구조가 단순한 모델이라면 super claude가 딸깍하면서 바로 만들어주긴하지만, 문제는 비즈니스 로직은 발전하고 변화하기 때문에 그 변화에 맞춰서 디비를 수정하고 백엔드 로직을 수정하는 테세우스 배를 만드는 과정과도 같습니다. 니즈에 맞는 개발을 시작하면 보통 백엔드부터 수행하니까요.
말씀하신대로 백엔드를 프론트처럼 컴포넌트 단위 (백엔드에서 보통 모듈이라고 합니다)로 쪼개면 되긴 하지만, 이걸 합치는 작업이 여간 쉽지 않습니다. 데이터 모델이 작으면 LLM이 모두기억하고 연결을 해주지만, table수가 20개만 넘어가도 연결이 안됩니다. 각 reference key도 자기가 맘대로 바꿔버리는 경우가 허다해서요..
그래서 정말 작은 단위 모듈로 쪼개서 docker로 컨테이너화해서 올리는 코딩이 유행이고 복잡한 백엔드 로직이 이미 어느정도 개발된 SaaS를 이용해서 작은 서비스 단위 구성으로 개발하는게 그나마 가능해진 상황입니다.
다만... 위에서 잠깐 언급했지만, 서비스가 커지면 각 모듈로 쪼개진 컨테이너간 API통신 비효율화 문제로 인해 점점 느려지는 구조가 됩니다. SaaS를 이용할 경우엔 비용이 미친듯이 증가하고요.
그래서 결국 백엔드 개발자가 하나로 통합하고 최적화하는 작업을 하긴해야합니다.
어짜피 msa로 만들어서 배포하더라도 디비는 하나쓰긴하는데
회원가입/로그인/세션 서비스 따로 구독관련 설정 관련 서비스 따로 구독결제 서비스 따로 이런식으로 동작해서 결국 db atomic transaction영향을 받긴합니다.
프론트에서 각 msa로 된 서비스 컨테이너로 API연결하면 문제가 없는데
간혹 각 msa끼리 REST API 통신을 해야할때는 백엔드 개발자 눈에는 성능저하가 보이는 구간이 꽤 많아보이더라구요.
어짜피 가벼운 서비스 만든다고 생각하고 열심히 시키고 있는데, 결과물이 3일만에 구독결제까지 되버려서.... AI 발전이 새삼 대단하구나 싶었습니다 ㅋㅋㅋ
개발하면서 느낀건 stripe는 이미 이런 시대 올 것을 예상했는지 모르겠지만 API를 세분화해서 잘 설계를 했고 그냥 super claude가 알아서 결제쪽은 구현을 해주더라구요. 버그가 나올걸 예상하고 몇번 테스트를 했는데 놀랍게도 버그는 없었습니다.
물론 구독내역을 가져오는 부분에서 보안 취약점이 다수 보였습니다만 그런건 제가 프롬프트를 제대로 지시하지 못한 탓이라고 생각되어서 그 부분은 제가 수동으로 처리했습니다.
다만 현재의 개발자를 완전히 대체하는 건 조금 더 시간이 걸리지 않을까 싶습니다.
아직까지도 몇번은 주고 받아야 제대로 된 결과를 만들어 낼수 있고.. 가끔은 아예 엉뚱한 소릴 하기도하니..
가까운 미래에 기존의 개발자들은 AI가 요구사항을 정확이 이해하고 요청대로 개발이 되었는지 검수만 하면 될 날이 올 것 같네요..
검수하는데 필요한 인원은 지금에 비해서 극소수만 있으면 되겠죠..
AI 발전이 더더더 가속화 되면은 정말 말로서 원하는 프로그램을 만들어서 사용 할 수 있는 시대가 되겠죠.
아직은... 경험있는 개발자 부족해요.
현재의 한계보다는 발전속도와 추세를 봐야죠
코드싸개도 안되는 gpt4에서 여기까지 오는데 2년도 안걸렸습니다
이정도 발전속도로 볼때
내년쯤에는 개발자가 완전히 필요 없어진다해도 전혀 이상하지 않습니다.
BDF 포맷에 있지도 않은 문법을 꾸며내서 말해주는데;;; 한참 구현하다가 뭔가 이상해서 제미나이에게 교차검증했더니 그딴거 없다고 ㅋㅋ
개발한거 유지보수 안하고
완벽한 기획으로 한번에 제품을 뽑아내면
엄청난 도움이됩니다
거기까지만요
탐단위, 규약들어가고
유지보수하기 시작하면 뭐...
부분적으론 큰 도움이 되지만 뭐 모르겠네요
개발자 나부랭이의 경험입니다
덧글 들 보니 링크드인이라도 까시고 말씀하심 좀 더 설득력이 있을지도 ㅎㅎㄹ
개발자가 사라질일은 없죠
허들이 높은 분야에선 처음 도입 시도 하다가 다 안된다는 결론이 중론이죠~ 그래도 유닛테스트 할때는 가끔씩 사용합니다.
진짜 문제는 결정권을 가지신분들이 이미 거기 꽂혀서 인력 감축 가능하다고 믿고 그 방향으로 돌격 앞으로 지시를 내리고 있는 상황이라는걸 아셔야해요
꽃혀서 할 수 있겠지만 바로 후회할 일이기도 하죠
서버 유지에 사람이 필요 없다고 생각하던 사장이랑 같은거죠
학습양을 2배로 늘렸더니 대박이네? 10배로 늘리면 더 대단하겠지? 그럼 10,000배로 늘리면 갑자기 AGI 가 될까요?
인터넷에 학습할 것이 더 이상 없다면 어떻게 될까요? AI가 만들어낸 콘텐츠의 셀프 학습은 효율적일까요?
개발자의 종말은 걱정할게 없는 것이 AGI가 완성되면 모든 직업의 종말일 수 있습니다. 배관공 조차두요.
확실한건 초급자 역할은 훌륭하게 해냅니다. 그래서 본인이 스스로의 힘으로 할 수 없던 어떤 일을 (음악, 개발, 그림, 글쓰기 등) AI와 함께 처음 해보면 놀라지만 실제 전문가들은 그렇게 놀라진 않죠. (그건 초보자도 할 수 있는 일이고 전문가는 초보자는 못보는 한계가 무엇인지 보이니까)
반박이 아닌 여러 견해중 하나입니다.🙂↕️
https://oceancoding.blogspot.com/2025/03/ai.html
휴대폰, 엑셀 , 온라인 플랫폼, 택배서비스 등의 발달로
영업직, 경리직, 관리직들이 20~30년동안 줄어들었지만
직업분야의 특성상 상대적으로 온라인에서는 논란이 없었다고 생각합니다.
당장 가까운 마트 캐셔, 주차장/톨게이트 인원들도 찾아보기 힘들죠...
AI로 인해 it쪽에 인원감축에 대한 바람이 시작되었다고 봐야 할까요?
다른직종을 봤을떼 수년동안 서서히 변화가 왔습니다.
코드가 리얼에 나가 문제가 생기면 누가 책임지죠? 그리고 수정에 대한 검수를 누가 할까요?
그리고 문제를 누가 발견을 할까요?
개발자는 단순 코드 생산만이 아니라 여러 일을 같이 하죠.
만약에 배포와 모니터링 수정까지 완벽하게 ai가 돈다고 가정 하에
도서관 대여 시스템을 ai가 작업해서 리얼에 올렸는데
연체에 대한 검증에 오류가 있다는걸 누군가 발견을 했고 ai 한테 수정해줘 한다음 그걸 그냥 리얼에 배포할
배짱(?)을 가진 사람이 있을까요?!
그리고 연계되는 다른 시스템이 있을텐데 그걸 사람이 한다면 ai가 그 부분까지 커버가 될까요?
그리고 만약 새로운 언어나 프레임워크가 나온다면 그거에 대한 학습 데이터는 누가 만들죠?
'즉 110명의 개발자가 개발하던 조직이 수십대의 AI 개발 시스템과 한두명의 인간개발자로 대체될거라고 생각 합니다'
요 부분은 저도 동감인데 문제는 그 시점이 언제냐의 차이겠죠?
그리고 점진적으로 진행이 될테고요.
저는 빨라도 10년은 더 걸릴거라 보고요.
그 사이 신입은 안 뽑는 방향이겠죠.
'처음부터 실전에 할 필요도 없고 몇번 혹은 몇달 해보면 확신이 서게 되겠죠'
이게 확신이 과연 들까요? 자 이게 모든걸 AI 니가 다해! 정도일텐데 과연?
완전 자율 주행 자동차도 몇년이 걸려도 확신과 법 제도의 문제로 아직 대중화가 안되고 있죠
어찌되었던 해결해야 할 문제의 총량이 늘어나지, 사람이 놀 것 같지는 않습니다.
단순화가 가능한 직업군들이 먼저 설자리를 잃었죠.
어디가 먼저냐의 문제일뿐, 결국 더 많은 일자리를 빼앗길 것입니다.
키오스크도 주문이라는 단순화에서, ai 기자도 사건정리 라는 단순화에서 시작된 대체화라고 생각합니다.
오히려 ai를 지배한다고 생각하시는분들도 있다는게 놀랍네요. 현재 시점에서 그러한 위치에 있는 분들도 충분히 많이
있을거라 생각하지만, 저는 과연 저의 일이, 혹은 이 산업군이 10년, 20년 뒤에도 ai로부터 안전할 수 있을까? 하는 불안감에 휩싸입니다.
일단 제 눈에 안전한 직업은 단 하나도 보이지 않습니다. 심지어 유투브 크리에이터 조차도 ai가 가능한 영역으로 보여지니까요. 왜 ai의 수준이 현재단계에 머문다고 생각하고 안주하는지 이해되지 않네요.
기술적으로는 의사 / 판사 / 검사 들이 AI를 도입하면 제일먼저 필요없어지는 직군중에 하나가 맞다고 생각합니다
하지만 의사 / 판사 / 검사 의 공통점은 제도적인 진입장벽과 자신들의 카르텔을 단단하게 다져 놓은거죠
결국 기술적으로 가능하지만 그들의 기득권으로 인해 대체하기 힘들겁니다
그래서 힘없는 단순직군들 하위직군들부터 갈려나가는거죠
사람 만나고 이야기 듣고 계획 세우고 보여주고 피드백 받고
1차 만들어 올리고 다시 피드백 받아서 고치고 UI 다듬고 또 고치고
안된다는 전화받고 다시 고치고 만나서 이야기하고 전화하고 ... 중간PT하고 최종PT하고
다 만들어 놨더니 뜬금없이 새로운 것 만들어 달라하고 ... 코딩이 문제가 아니더라구요
솔까 코딩은 코더에게 오더 내리면 끝이라는
부사수 역할로는 만족하고 있습니다.
몇몇 개발자 유투버들이 디버깅 리스크를 언급하는데,
이 부분도 결국 시간 문제라고 보여집니다.
결국 ai를 잘 다루는 사람들은 디버깅 문제도 나름의 노하우로 헤쳐나갈거 같네요
그렇다고 수학자라는 직업이 사라졌나요? 아니죠. 오히려 학문이 더 고도화되고 있습니다.
개발자가 끝났다고요? 그정도의 개발만 하시는 거겠죠.
그런데 적어도 지금 현업에 있는 사람들은 ai로 대체될 가능성이 높거나, ai를 완전히 제 손발처럼 이용하지는 못할 가능성이 높지 않을까요?
옛날 천공카드 프로그래머 뭐 주판하던 직업이 다른 직업으로 대체되었다며 개발자는 죽지 않는다 이러지만,
천공카드 프로그래밍 하던 바로 그 사람이 곧바로 다른 직업을 찾아서 일을 다시 했나? 그건 또 다른 문제입니다.
ai시대가 와도 개발자는 계속 존재할겁니다. 그런데 그 존재하는 사람이 나는 아니라는게 문제겠죠.
지금은 육아휴직 기간이라 시간이 약간 생겨 새롭게 공부한 영역이 있는데, 이게 막상 손이 잘 나가지 않더라구요. 모든 실력은 연습으로부터 오기 때문에 코드를 계속 생산해내야 감이 잡히고 실력이 늘텐데, 아시다시피 집안일이 계속 생깁니다. 아이들 밥도 줘야하구요. 그래서 claude code를 적용해봤습니다. 손을 담그지는 않았지만 학습 하면서 코드 보는 눈은 생겨서 많은 도움이 됐습니다. 이걸 사용하면서 느낀 가장 큰 점은 아래와 같습니다.
** 바이브 하게 코딩 하면 바이브 하게 망한다.**
유튜브에서 보면 바이브로 원샷 프롬프트 코딩을 하는 모습을 보여주는데요, 실상 그런 제품들은 우리가 회사에서 개발해오는 복잡도 있는 제품과 많이 다릅니다. 물론 유튜브에서 재미 없는 엔터프라이즈 레벨로 개발을 보여줄 수 없는 것이 현실이기는 하지만요. 그래서 Claude Code를 사용한 외국 유튜브를 많이 보기 시작했고요, 공식 문서도 처음부터 꼼꼼하게 읽어보았습니다. 그래서 다음을 깨달았습니다.
** 나는 PM이다. 개발자가 아니다. **
작업방식을 바꿨습니다.
1. 개발명세를 만든다. 기능에 대한 서술은 제가 하고 proposal은 LLM에게 작성을 시킵니다.
2. PRP를 LLM을 사용해서 기능 단위로 vertical slicing 해서 N개의 PRP로 분할한다. (domain layer부터 개발을 시켰던 시도도 있는데 나중에 통합이 쉽지 않았습니다. 그래서 작은 기능 단위의 개발을 도입했습니다. )
3. N개의 PRP를 claude code에서 제가 미리 만들어둔 command를 사용해서 다시 N개로 잘라서 실질적인 개발 기록문서를 만듭니다. 이 최소단위의 문서를 만들 때는 개발과 관련한 pseudo code 또한 들어가게 해뒀습니다. 이렇게 하지 않으면 context window의 문제 때문에 claude code를 효과적으로 사용할 수 없더군요.
4. 의존성 없는 2개 정도의 작업을 추천해달라고 한 다음 git worktree로 돌립니다. 의존성을 적게 가져가기 위해서는 설계단계에서부터 interface를 잘 뽑아두어야 합니다. 그래야 계약으로만 개발이 가능하더군요(이건 회사에서도 그렇죠). 결과물 확인하고 개선할 점 이야기 해주고 다시 review 돌리고.. 이 과정의 반복입니다. 개발 결과는 또 위의 문서에 기록하게 합니다. 새로운 feature branch는 또 위의 문서를 읽고 지식을 습득하죠.
- 한 개의 worktree로 개발했을 때는... 내가 개발하는 것이 빠른가... 라는 생각도 듭니다만, 그건 착각이겠죠. 테스트 코드 양까지 생각하면 그렇지 않겠지요. 물론 각 코드 객체의 연관관계는 이미 제 머리 속에 있어야 합니다.
- 두 개의 worktree는 괜찮습니다. 마치 제가 조훈현 9단이 된 것 같습니다. 여기에서 한 수 두고, 저기에서 한 수 두고...
- 세 개의 worktree는... 쉽지 않습니다. 제가 한 꺼번에 봐야할 것이 많아집니다. 그래도 집중 하면 버틸 만 하지만, 각 IDE가 힙스페이스 부족하다고;;; 해서... 메모리가 크지 않아서 세 개는 무리인 것 같습니다.
이렇게 개발을 해보니, 세상이 달라지고 있구나,라는 생각이 들었습니다. 아직은 개발자가 사라지거나 그런 생각은 하지 않습니다만 효율적인 도구임에는 틀림 없습니다. 저는 백엔드만 해서 프론트엔드는 전혀 모르고 UI/UX에 대한 지식도 전무하지만, 인터넷에서 적절한 프롬프트를 찾아서 디자인을 시키고, 마음 안 들면 iteration을 계속 돌린 후 결과물을 html과 캡쳐로 claude code에 다시 제공해서 화면을 구성하게 할 수도 있더군요. 물론 최소한의 지식은 항상 있어야 합니다. 전혀 바이브 하지 않습니다, 이런 과정은...
주절주절하게 말이 길었네요. 요약하자면.
* 시도해볼만한 가치는 분명히 있습니다. 딸깍 사이트는 딸깍으로 뽑을 수 있겠지만 그 이상 규모는 산으로 가버립니다. 머리 속에 있는 계획을 문서로 표현해서 분해하는 능력이 중요합니다. 그렇기 때문에 경험이 풍부할 수록 유리합니다.
* 시도하고 있는 언어 또는 프레임워크, 분야 등에 대해 최소한의 지식은 있어야 합니다.
* 돈을 태울 수 있는 용기가 있어야 합니다;;; 200달러 쉽지 않아요.
* 회사로 복귀하면 적극적으로 사용하려고 합니다. 기업 마다 쉽지 않은 곳도 있겠지요. 저도 예전에는 금용권에 있었는데, 망분리 등으로 인해 변화에 올라타기 쉽지 않을 겁니다.
* 극히 편한 점: 밥 하러 가기 전, 씻으러 가기 전 몇 개의 작업을 시켜놓고 갔다오면 된다. 시간을 버는 느낌
* 극히 나쁜 점: 파블로프의 개가 된 것 같다. 다른 일을 하다가도 연결된 터미널에서 띵 소리가 나면 달려와서 화면을 보게 된다..
아들이 개발자(서버관련-ㄴㅋㄹㅋㅂ 중에 하나...)인데...
물어보면... 'ㅎ' 하면서 찡긋 웃습니다.
도움이 되는 건 분명한데...
아직은... 멀었다고 하네요.
믿을 수가 없고 어차피 인간의 손이 타야 한다고...
그래서 더 시니어 개발자가 필요합니다
어느정도 이해하고 쓰는 것과 그냥 쓰는 것과 너무 많은 차이가 있는 것같아서요.
개발 그 자체만으로 보면 전망이 낮을지라도, 저는 전망이 더 있을것 같아요.
그러다가 ux가 그냥 동영상으로 보여주며 대화로 끝나고, 포탈은 다 개인화되고 그럴 듯.
모두가 같이 쓰는 앱은 사라짐
프로그래밍이 그렇게 단편적이 업무만 있는게 아니라서요. 본인의 대체가능성을 직의 대체로 착각하진 마세요.
만선이라 저도 한번 올라와봤습니다. 재미있네요.
거짓말을 그럴듯하게 내놔서 검증 하고 수정합니다
단 AI에 질문할 때도 아키텍쳐나 로직을 반영하여 제대로 질문해야 하고 최소한 AI가 답해주는 코드를 모두 이해할 수 있는 수준은 되어야 합니다.
캔버스 라인제한이 있다고 몇 번 적성하다 실패하더니
한줄에 c++함수 하나씩 코딩하더라고요.
라인중간애 #ifdef 까지 넣어서 에러 띄우더군요.
반 농담식으로 말하자면 ai가 클라이언트를 완전 대체하기 전까지 완전 대체는 안될 거 같습니다
개인적으로 느낀 장점과 단점으로는
장점
1.일반적인 오류 발생시에 굉장히 빠르게 체크포인트를 잡아줍니다
2. 테스트코드 생성도 바로바로 해줍니다. 개인적으로 TDD보다는 개발후 테스트 코드를 만드는걸 선호해서 개발시간만큼 테스트 코드를 신경써서 만들곤 했는데 이젠 부담없이 테스트 코드를 만들수 있네요
단점
1. 처음에는 간단한 모듈이나 메소드 정도 만들어 주는것으로 시작하다 심플한 수준의 기능 구성을 의뢰했는데 바로 장애 터져서 진땀 났습니다. (버전이나 사이드이펙트에 대해서 몇번이나 경고했는데 문제없다.. 문제없다.. 이러더니 ㅠ.ㅠ)
2. 위의 많은 분들도 말씀하셨지만 현재까지 작업에 대한 context 관리가 좀 힘들고 동일 프롬프트여도 결과물이 꽤 차이가 나는 경우가 비일비재합니다.
3. 거짓말하는경우가 많아서 꼭 출처를 요구해야됩니다. ㅋㅋ
정리하자면 빠릿한 1인 개발자 까지는 좀 무리고 물으면 바로바로 찾아봐주는 사전 같은 느낌의 조언자 라고 봅니다.
언젠가 개발자가 대체되긴 하겠지만 그나마 당분간은 버틸만 하다고 보는게 어떤 일이건 책임을 지고 자연어로 들어오는 요구 사항에 대해서 잘 정리하고 일의 경중을 판단할수 있는 시니어의 역할은 필요하겠다 정도네요.
변수 명 자기 맘대로 오해하고, 이상한 짓 시키고 그렇습니다.
절대 일 다 시키면 안되고 소스 리뷰 꼼꼼히 해야 합니다.
누가 AI 개발자를 학습하지 않는 신입 개발자라고 했죠. 딱 그 수준입니다. 없는 것 보다 나을 정도지요.