시니어 소프트웨어 엔지니어 - 몇 달 동안 코드를 한 줄도 작성하지 않았음
source reddit
AI는 이제 제가 직접 코드를 쓰지 않아도 될 정도까지 왔습니다.
예전에는 인터넷도 안 되는 환경에서 디버거를 붙잡고 깊이 파고들던 회사들에서 일했습니다. 그런데 지금은 Claude/Codex/Perplexity와 함께 제품의 의도와 장기적인 엔지니어링 의사결정을 이끌고 있습니다. 저는 100명이 조금 넘는 중간 규모 스타트업에서 일하고 있습니다.
이제는 굳이 직접 코드를 써야 할 이유를 잘 모르겠습니다. 언어, 프레임워크, 프로토콜, 클라우드, 인프라, 보안 같은 걸 익히는 데는 스트레스도 많고, 머리를 쥐어뜯는 시간도 끝없이 들어가죠. 그런데 그 시간과 에너지를 시스템 설계, UX, 지식 그래프 같은 쪽에 쓰는 편이 훨씬 낫다고 느껴집니다. 제가 배운 가장 큰 교훈들 중 일부는 정말 고생하면서 얻은 것들이었지만, 이제는 뭐든 너무 쉬워져서 큰 기능도 2일이면 끝냅니다. 물론 그 과정에서 새로운 걸 배우긴 하겠지만, 예전 같은 성취감은 없습니다. 시간을 가장 잘 쓰려면 스택의 다른 영역에 더 집중해야 한다는 느낌이 듭니다.
물론 이런 생각은 제가 그런 일들을 오랫동안 직접 해온 경험 위에서 나오는 것이기도 합니다. 그래도 Gemini 2.0이 나온 뒤로 제가 배우게 된 양은 정말 엄청났다고 생각합니다.
그렇다고 이걸 비관적으로 보는 건 아닙니다. 오히려 반대에 가깝습니다. 버그 하나를 잡거나 시스템 소프트웨어를 완성했을 때 예전 같은 도파민이 확 오는 느낌은 덜합니다. 대신 시간이 좀 지난 뒤, 시스템 전체가 완벽하게 돌아가는 걸 볼 때 만족감이 옵니다. 저는 사실 시스템 레벨에서 설계하고 생각하는 일을 정말 좋아합니다. 일주일 내내 버그 하나에 갇혀 있는 것보다 훨씬, 훨씬 더요. 다만 예전과는 감각이 다를 뿐입니다. 솔직히 말하면 지금이 예전보다 훨씬 더 재미있습니다.
이게 그냥 커리어가 무르익으면서 자연스럽게 드는 감정일까요? 그럴 수도 있죠.
하지만 저는 AI가 업계를 바꿨다고도 생각합니다. 이제는 새로운 언어를 기초나 트레이드오프 이상으로 깊게 배우는 데 흥미가 잘 안 생깁니다. 설령 흥미가 생긴다 해도, 그게 제 시간을 잘 쓰는 방식이라는 생각이 들지 않습니다. AI가 너무 잘하기 때문에, 거기에 시간을 많이 들일 이유가 없어요. 이 말이 통하지 않는 거의 유일한 경우는 면접입니다.
그래서 면접 얘기로 넘어가 보죠. 시스템 설계 문제를 어떻게 풀 기술 스택으로 구현할지 저와 대화하는 능력은 부족한데, 특정 xyz 언어를 잘한다는 이유만으로 왜 그런 사람을 채용해야 할까요? Rust와 Azure의 전문가라는 사실을 왜 제가 중요하게 봐야 할까요? Claude는 이미 대부분의 개발팀보다 코드를 작성하고 유지보수하는 일을 더 잘합니다. 물론 경험 많은 소프트웨어 엔지니어가 혼자 처음부터 끝까지 코드베이스를 만들어 나가면 더 나은 결과를 낼 수도 있겠죠. 하지만 업계 현실에서 그건 분명 비현실적입니다.
이건 지금 회사에서 실제로 승진도 하고, 동료와 상사에게 좋은 평가도 받고 있는 사람이 하는 말입니다. 그러니 적어도 지금 제 방식이 통하고 있는 건 맞습니다.
다른 사람들도 이런 변화를 비슷하게 느끼고 있는지 궁금해서 올려봅니다.
여기서도 같은 경험임. 10YOE
여기서도 완전히 같은 경험임. 9YOE
같음. 30YOE, 실무 + 관리.
더 재밌고, 관리직으로 넘어가는 것과 비슷함, 성취감도 매우 다르고 달성 가능한 규모도 다름.나도 같음, 나도 30YOE.
솔직히 AI 싫어하지만, 나이 들고 지쳐서 코드 한 줄 한 줄 다 안 쳐도 되는 건 좋음.
나는 AI를 세밀하게 씀, 모든 걸 포괄하는 모호한 프롬프트는 절대 안 쓰고, 꽤 잘 먹힘.
생산성은 올랐고, 속도도 개선되고, MR 반려도 줄었고, 솔직히 내가 귀찮아서 안 읽는 문서를 Claude가 읽어줘서 예전보다 훨씬 많이 배우고 있음.
Claude를 작고 타게팅된 방식으로 써서 환각 문제는 거의 없음. 근데 얘가 나한테 진짜 당당하게 거짓말할 수 있다는 건 증명했음ㅋㅋ
나도 같음 25 YOE - 내 말은 좋긴 함, 많이 만들 수 있고 생산성이 엄청남. Claude가 훨씬 넓은 지식을 갖고 있어서 엄청 배울 수 있음. 근데... 내가 아는 걸 알고 있어서 다행이고, 주니어 엔지니어들이 그걸 어떻게 배울지는 모르겠음, 그 많은 게 고통을 통해 내 뇌에 박힌 거라서
여기서도 같은 경험임. 2026 YOE, 내가 예수님 웹사이트 코딩했음.
서버 재부팅에 3일 걸리는 건 그냥 용납 안 됨, 우리 마케팅 룰에는 99.99% uptime 약속돼 있음
이 말 r/experienceddevs에서 하지 마셈, 걔들 뚜껑 열림
올해 상위 게시글로 보는 r/ExperiencedDevs 미리보기임!
#1: 어떤 AI CEO가 드디어 솔직한 말을 함
#2: 내 새 취미: AI가 Microsoft 직원들을 서서히 미치게 하는 걸 구경하기
#3: AI 쓰레기(sl업) 청소 시대가 시작됨
나는 봇임, 삐빕 | 삭제하려면 다운보트 | Contact | Info | Opt-out | GitHubㅋㅋ 봇이 너무 적절함
맞음 나도 30 YOE. 다만 이 스레드에서 사람들이 그걸로 놀리는 중이긴 함 😂 매니저가 되기로 선택한 적은 없지만 결국 코딩은 더 이상 안 하게 됨 🥲. SW 회사에서 IC5/6은 중간관리자 급여와 같음.
모든 시니어 개발자는 이제 하루 종일 에이전트식으로 코딩함. 라인 매니저보다 더 많이 받는 상황에서 주니어 개발자 / 수동 코드 몽키 생산성은 더 이상 용납 안 됨.
새 프로세스를 배우는 건 재밌고, IDE가 구식이 됐으니 Emacs로 돌아갈 수 있는 것도 좋음. 근데 하루에 CC 세션 4개 멀티태스킹하면 뇌가 좀 뒤섞임!
은퇴까지 4년밖에 안 남아서 다행임. 코드 작성이 끝난 지금, 그보다 더 오래 코드 프롬프터로 살고 싶진 않음.나도 같음. 그리고 객관적으로 내 인생 최고의 프로덕션 코드를 쓰는 중임.
음, 이제 코드를 쓰는 건 네가 아니잖음. 그러면 핸들을 조종한 공로를 받아야 함, 아니면 차 전체를 만든 공로를 받아야 함?
키스트로크를 네가 치는 건 아니고, 그보다 한두 단계 위도 아닐 수 있지만, vibe-coding이 아니라면 그래도 코드를 쓰는 건 여전히 너임. 초점이 옮겨져서 예전보다 훨씬 오래 높은 레벨에 주의를 둘 수 있게 된 것뿐임. 적어도 지금까지 내 경험은 그럼.
여기서도 같은 경험임, 85YOE
내가 ㅂㅅ임?
이런 도구 계속 쓰고 있고 엄청 유용하긴 한데, 그래도 나는 확실히 코드를 써야 하고 에이전트를 계속 만져줘야 함.
최근 예:
- 기본적인 dark/light 기능 있는 tailwind용 classless css theme 작업 중 Agent가 코드를 생성함.
그다음 css 파일을 800줄에서 350줄로 줄이고, 테마 전환 버튼을 300줄에서 40줄로 줄이고, 테마가 실제로 제대로 작동하면서 브라우저 새로고침 때 깜빡이지 않게 만들기까지, 또 2일 동안 수동으로 코드를 쓰거나 프롬프트를 주고받았음.
할 일이 진짜 많음.AI가 매번 제대로 하는 건 당연히 아니지만, 80-90% 정도까지는 해줌. 안 되는 건 에이전트랑 만지면서 대안 설계 같은 걸 검토함. 그래도 몇 달 동안 내가 코드 한 줄 안 썼다는 핵심은 그대로임.
나는 어떤 건 AI한테 계속 시키는 것보다 그냥 내가 직접 수정하는 게 더 쉬운 것 같음.
프로그래밍 언어가 존재하는 이유가 있음, 네 의도를 정확히 표현함. 그리고 개발 도구는 매우 빠르고 즉각적인 피드백을 줌.
세부 사항은 그냥 내가 직접 고치고, "save" 누르고, 바로 결과를 보는 게 더 빠를 때가 많음. LLM이 이번에는 제대로 해주길 바라며 영어로 설명하고, LLM이 작업할 때까지 5초 기다리고, 검토하고 확인하고, 그 수정에 0.05$ 내는 것보다 말임. 그래도 원하는 게 아니면, "충분히 괜찮음" 지점에 도달할 때까지 과정을 반복해야 하고, 쓸데없는 왔다 갔다로 컨텍스트가 더럽혀지지 않게 세션 트리까지 관리해야 함. 그냥 필요한 대로 바로 했으면 됐을 일을
모든 언어에서 똑같음... AI는 경험 많은 엔지니어와 같은 품질의 작업을 하지 못함. 초반 작업 대부분을 AI에게 맡길 수는 있지만, 그다음 몇 주/몇 달 동안 내가 절반을 재설계하고 다시 써야 한다는 걸 알고 있음. 생성된 CSS 결과가 마음에 안 든다면, 멀티스레드 코드와 동기화 프리미티브에서는 뭘 할지 상상 가능함.
이런 게시글 중 상당수는 봇/마케팅 사람들이 씀.
균형이 있다고 봄 - 어느 정도는 AI 생성 코드가 인간 생성 코드와 똑같이 맞아야 할 필요는 없음. CSS는 Java 같은 것보다 항상 무질서하게 만들기 쉬웠고, 당연히 시간을 들여 정리할 수는 있지만, 비용 대비 이득의 문제임.
22년 경력. AI를 많이 쓰지만, 그래도 매일 의도적으로 코드를 직접 씀. 쓰는 걸 좋아하고 그 기술이 퇴화하는 걸 원치 않음.
사람들이 어떻게 Claude를 맹목적으로 돌리고 아무것도 안 하는지 아직 이해 안 됨.
내 작업이 충분히 메인스트림이 아닌 걸 수도 있지만, Claude를 제멋대로 두기만 했다면 난 직장을 잃었거나 법정에 있었을 거임.
코드 쓰는 걸 좋아하지만 그래도 여기저기 직접 써야 할 일이 생김. 게다가 main 파일은 Claude보다 내가 더 잘 쓴다고 생각함, 적어도 가끔은.코드 한 줄 안 씀 !== Claude를 맹목적으로 돌리고 아무것도 안 함.
여기 있는 경력자들은 그 빌어먹을 걸 작동하게 만드는 게 진짜 가치라는 걸 알아야 함.
나는 더 이상 코드를 쓰지 않지만 코드는 많이 읽고 Claude에게 고치는 방법을 말함. 그다음 수정본을 읽고 더 잘 고치는 방법을 말함
가끔은 AI한테 고치라고 하는 것보다 그냥 직접 고치는 게 더 빠름, 토큰도 낭비 안 하고
솔직히 그냥 직접 고치는 게 더 빠른 경우가 점점 줄어드는 중임.
가끔은 그렇긴 함. 근데 원하는 걸 더 잘 설명하면 에이전트가 해줌.
올바른 지시와 올바른 컨텍스트를 주기만 하면, 못 하는 건 없음.
또 한 에이전트가 작업하는 동안 다른 에이전트로 전환할 수 있어서 기본 개발 루프(fix, run lints and tests 등)에 드는 시간을 많이 아낄 수 있음.
비용은 더 들긴 함, 맞음.이 얘기가 충분히 안 나오는 것 같음. 모두가 이 부분에서 탈숙련되고 있고, 그 대가는 계속 올라갈 거임. 어느 순간 이런 반복 수정에 토큰으로 드는 돈이 개발자에게 돈 주는 것보다 더 비싸질 거임.
그리고 비즈니스 관점에서 반복 수정 프로세스가 더 비싸진다는 점도 완전히 간과됨. 토큰 비용도 내고, 프롬프트 치는 개발자 비용도 내니까.그래, hype는 이해하지만 또... 구독 기반 모델임. 언제든 가격을 올릴 수 있고, 그러면 네 돈 버는 기술 스택이 구독에 기반하게 되며, 걔들이 네 급소를 쥐게 됨.
경영진 지시가 한 가지 이유임. AI가 모든 결정을 하게 두라는 말을 수없이 들었음
새 직장 지원하기로 하고 코딩 인터뷰용 LeetCode를 다시 해야 할 때까지 기다려보셈.
10살 때부터 코딩했으니 40년, 업계에서는 30년 일했음 - 나도 1월 이후로 코드 한 줄 안 썼음 - 최근 시니어 개발자 포지션 면접을 봤는데 몇 가지 red flag 때문에 코딩 테스트로 돌아갔음. 자전거 타기 같은 것에 더 가까운 듯함. 잊어버리진 않고, 조금만 복습하면 그 기술이 다시 살아남.
10+년 코딩했음. 작년에 agentic engineering으로 전환했고, 정확히는 Sonnet 3.7부터임. 오늘 big tech 회사 중 하나와 코딩 인터뷰를 봤음. 준비 시간은 9일 있었음. 맞음, 다시 자전거에 올라탈 수는 있었지만, 와, 절대 공원 산책은 아니었음.
맞음 100%. 그래서 면접이 실제로 코드를 쓰는 마지막 보루라고 말한 거임. 회사들이 실제 업무에서 너한테 시키고 싶은 것과는 전혀 다르지만, 다들 테스트할 줄 아는 게 그것뿐임.
그거 진짜 안 좋아 보임. 회사가 코드를 쓰는 방식으로만 제일 잘 테스트할 줄 안다면, 나머지 기술들, 특히 시스템 설계는 부차적이라는 거 아님? 그 회사와 거기 사람들에 대해 뭘 말해주는 거임?
나도 요즘 아무도 코드를 안 쓰는데 누군가를 면접해야 할 때 그 사람에게 언어의 세부 사항을 물어야 한다는 점이 매우 혼란스러움… 왜?
나는 기술 문제보다 상황에 집중함. 예를 들어 X 상황에 처했다면 뭘 할 거냐? 시스템에 문제가 있다. 에러는 이렇다. Claude가 개소리를 했다. 뭘 할 거냐? 여기서 초점은 그 사람이 어떻게 생각하고 문제에 어떻게 접근하는지임, 보통 우리 팀 문제가 아니라 다른 팀 문제이고 우리가 조치해야 한다는 결론으로 이어짐. 그리고 조용히 사람 기술로 전환해서 다른 팀과 어떻게 협업할지, 이슈를 어떻게 제시할지 물음.
기능은 개발될 거임, 아마 의도한 품질의 100%는 아니겠지만. 그 팀/회사가 sdd나 어떤 형태의 open spec을 따르고, 가치 있는 e2e와 unit tests를 성실히 추가한다면, 나머지 일은 설계, 아키텍처, PM 업무와 사람 기술 + 조율, 그리고 견고한 guardrails가 있는 agentic development 중심의 잘 강제된 프로세스임.
한 번 software customer support engineer 면접을 진행해야 했던 적이 있음, 맞음, 여기서 주장하는 것에 좀 편향된 사례인 건 앎. 나는 코드/언어/유사 이슈보다 위 기준 때문에 대부분의 후보자를 탈락시켰음. 대부분은 coding/algorithm/framework 쪽은 통과했고 다른 쪽에서 처참하게 실패함.
실제 알고리즘과 코드 구현을 테스트하는 회사들은 AI 시대 전에도 잘못된 걸 테스트한다고 생각했음. LeetCode만 죽어라 푼 사람들이 팀에 들어오게 하고, 그들은 팀과 회사에서 매일 어떻게 일해야 하는지에 대한 최소한의 지능도 없고, 복잡한 비코드 이슈에 대해 주도적으로 해결하는 자율성도 0임.
내 생각이고 개인 경험에서 말하는 거임.
회사가 아직도 LeetCode 문제를 쓰고 있다면, 나는 면접 자리에서 일어나 나갈 거임. 그들은 AI 보조 소프트웨어 엔지니어가 아니라 프로그래머를 찾는 거임.
솔직히 이게 새로운 표준이라고 생각하고, 나는 즐김. 나도 10 yoe 시니어 엔지니어고, 엄청 힘을 실어준다고 느끼지만 위험함.
지금 업무 시간 대부분은 스펙 작성과 코드 리뷰에 씀. 그리고 리뷰가 CRITICAL임, 이걸 “vibe coders”가 건너뜀.
실제로 꽤 놀랍고 훨씬 다양한 작업 방식에 잘 맞음. Obsidian은 이제 단순한 노트 앱이 아니라 어디서든 쓸 수 있는 내 모바일 개발 환경임. 버스에 앉아서 폰으로 obsidian에 스펙을 쓰고, 출근하면 Claude에 넣고, 하루 종일 Claude 결과물을 리뷰하고, 내 피드백을 Claude가 구현하게 함. 이제 직접 코드를 쓰는 일은 거의 없고, 스펙의 일부일 때만 함.
품질이 떨어지지 않게 하는 게 매우 중요하고, 그게 이 도구들을 효과적으로 쓰는 방식임 - 코드 품질은 지금 훨씬, 훨씬 더 높아져야 함 - 예전에는 높은 코드 품질을 비싸게 만들었던 대규모 리팩터링, test suites, 광범위한 문서화 같은 것들이 이제 AI가 써주기 때문에 훨씬 저렴해졌음. 하지만 어떻게 할지 의도적으로 해야 함.리드 개발자임. 내 일상은 “몇 달 동안 코드 한 줄 안 쓴” 시니어 엔지니어 몇 명이 작성한 프로젝트를 살리려고 싸우는 것임. 그들은 “모든 코드를 리뷰했다”고 함. 이 제품 개발 내내 칭찬받았음. 너처럼 정확히 말함.
쓰레기임. 품질과 신뢰성이 쓰레기라 시장에서 고통받는 중임. 계속되는 hotfix와 support escalation에 파묻혀 있어서 아무것도 개선하지 못함. 나는 약간의 AI를 쓰는 팀을 이끌고, 그들이 만든 난장판을 풀어내려고 쉬지 않고 일하는 중임.
확증편향이 너를 위험한 길로 끌고 가고 있음. 과도한 AI 사용에 따른 인지 위축은 이미 연구에서 보이고 있음.
너는 말 그대로 ClaudeCode subreddit에 말하고 있음. 여기서는 네 편향이 확인될 거임.Unit tests? Integration tests? CI/CD? 버그 하나 고칠 때마다 regression test 추가? 그런 거 하고 있음? Claude는 프롬프트를 주거나 이를 따르는 예시가 있으면 그런 걸 잘함.
Opus는 본질적으로 assert version == “1.0.0” 같은 테스트를 쓰는 경향이 있음, 그게 line coverage 말고 뭘 실제로 테스트하는 것처럼. 못 한다는 건 아닌데 가끔 진짜 고통스러움
테스트를 보고 가끔 헛소리 그만하라고 말해야 함
그리고 반복 개선을 다들 잊은 거임? 첫 번째 계획은 40%까지 가고, 두 번째는 -70%, 세 번째는 보통 80%까지 가는 느낌임. 그래도 마지막 20%가 여전히 제일 어려움. 거기까지 가면 관련 있다고 판단한 n개 시스템에 대해 범주별 감사 요청하고 개선 제안을 받으면 격차를 메우는 데 도움이 됨, 적어도 오디오 소프트웨어에서는
맞음, 근데 대부분의 "시니어" 개발자는 그렇게 안 함. 예전보다 더 많은 테스트를 리뷰해야 하고 절반을 표시해야 함. 미친 시대임
사람들은 프롬프트를 정말 못 하거나 엄청 게으름. 좋은 테스트를 작성하게 하셈. 노력을 들이셈. 좋은 테스트를 쓰는 법을 몰라도 됨. 어떤 코드에 대해 훈련 데이터의 best testing practices를 사용해 테스트를 작성하라고 말하셈. 참고 테스트를 가리키는 테스트 원칙 가이드를 작성하셈. 그 가이드는 테스트를 가치 있게 만드는 원칙을 추출함. 특정 테스트를 가리키면 그 원칙을 연결할 예시가 생김. CLAUDE.md에서 그 가이드를 참조하셈. 무시하면, 가끔 그럴 거임, 다시 가이드를 보게 하셈. 문제 해결임. 진짜 그 정도로 쉬움. miss rate를 줄이는 방법도 있지만, 사람들은 프로세스를 최적화하려 하기 전에 핵심 메커니즘에 익숙해져야 함.
맞음, 내 말은 기능을 만들 때 들이는 것과 같은 노력을 줘야 한다는 거임. 스스로 테스트를 리뷰하게 하고, 테스트 작성 방식에 대한 지침을 주고, 개소리 같은 테스트를 지적하셈. 아무도 hands-off라고 말하는 게 아님.
테스트도 AI에 오염되면 도움이 안 됨. "시니어 개발자"들이 "하지만 테스트가 있다"고 주장하는 걸 보는데, 그 테스트도 Claude가 작성했고 이 소위 시니어 개발자들은 너무 멍청하고 현실과 분리돼서 테스트가 무엇을 검증하는지도 이해 못 함.
나도 이런 주장을 하곤 했는데, 인간이 작성한 "production" 코드의 98%도 쓰레기라는 지적을 받고 그만둠.
... 그리고 AI는 그 98%로 학습됨.
솔직히 맞고, 그게 정당한 불만임. 안정적으로 평범한 코드임. 트레이드오프는 시간당 출력량이 내가 할 수 있는 것과 비교해 너무 압도적이라 품질 부족을 충분히 상쇄한다는 것임.
9개월 들여 엄청 훌륭하게 만들 수도 있고, 주말에 대충 작동하는 쓰레기를 만들 수도 있음.그게 나한테 핵심임. "올인"하지 않아도 엄청난 힘의 배율기로 쓸 수 있음. 개발에 AI를 쓰는 건 비판하지 않음. IDE를 영구히 닫고도 스스로를 전문가라고 부를 수 있다는 생각을 비판함.
내가 진짜 말하는 건 3-4x에서 10x로 뛰는 건 장기적으로 가능하지 않다는 거임. 도구를 피하고 1x에 머물라는 말은 아님, 말이 된다면.
그렇긴 해도, 대충 작동하는 쓰레기면 충분한 경우에는 당연히 좋은 접근임.지금은 훨씬 더 나빠짐.
AI를 많이 쓰는 모든 주요 회사에서 품질 저하가 아주 눈에 띔.
평생 Google.com이 망가진 적은 없었음. 버그가 0이었음. 그냥 작동했음.
지금은 iOS, Safari에서 뭔가 검색해보셈. AI 답변을 먼저 줌. AI에게 더 물어보려고 텍스트 박스에 뭔가 입력함. 그러고 메시지를 보내는 대신 입력창 밖을 클릭함.
키보드가 사라지고 입력 박스가 화면 가운데 텍스트 위에 떠 있음.
그게 Google.com, 그들의 메인 제품임. 망가짐.
예전엔 이런 일이 없었음. 그리고 모든 곳에서 이럼. Microsoft가 만드는 모든 게 더 나빠졌고, Amazon, Google도 마찬가지임.
Anthropic은 2개월도 안 돼 3건의 보안 사고를 냈고 제품을 망가뜨린 post mortem을 썼음, 겉보기엔 초강력 Mythos 모델을 쓰면서 말임.
AI로 인해 소프트웨어 품질은 크게 떨어졌음
AI 이전에도 이렇게 하던 시니어 엔지니어들이 있었음.
그런 상황의 본질은 현대 개발 관행에 대한 무지, 적절한 테스트를 작성하지 않음, 어떤 아키텍처를 적용해야 하고 적용하지 말아야 하는지 이해하지 못함, 다른 관점을 받아들이기엔 너무 오만함이었음.
실제로는 시니어가 아닌 시니어가 많음.
AI는 좋은 엔지니어링 관행의 필요성을 바꾸지 않았고, 아키텍처를 따르고 테스트 가능하고 유지보수 가능한 코드를 얻는 엔지니어들과, 티켓을 최대한 빨리 닫으려고 쓰레기를 던지는 엔지니어들을 한 묶음으로 보는 건 틀린 것 같음.미안하지만 그건 vibe code 문제가 아닌 것 같음. 나쁜 엔지니어가 있는 것 같음. 그 사람들한테 자기 코드를 직접 쓰라고 하면 더 나빠질 거라고 봄.
실력 문제임 친구야. 그래도 RFC, architecture reviews, CI, testing 등은 필요함.
쓰레기를 곱하면 두 배 쓰레기임. 그들은 AI 전에도 그냥 쓰레기였음. 내 작업은 greenfield에서도 고품질이고, 나는 코드를 안 만짐. 그나저나 원자력 발전소 컴퓨터 커널이든 네가 만드는 비행기든 꼼꼼히 리뷰해서 모두를 안전하게 지켜줘서 고마움.
완전 동의함. 나는 대기업에서 일하는데, 기존 인간 작성 legacy code 중 끔찍한 게 많음. 일부 AI 회의론자들은 AI가 등장하기 전에는 모든 게 아름답게 엔지니어링돼 있었다는 듯 행동함.
그렇긴 해도, AI로 소프트웨어를 잘 작성하는 건 분명히 기술임. 처음부터 멀쩡한 아키텍처와 스택을 고르고, guardrails를 세우고, conventions를 강제하고, docs와 context를 코드 가까이에 두고, 모델이 잘하는 것과 흔들리는 지점을 알아야 함.
그 workflow가 맞춰지면, 정말 놀라운 속도로 고품질 코드를 뽑아낼 수 있음.
30YOE임.
앞으로 엄청난 양의 AI 쓰레기(sl업)가 밀려오고 있음. 나는 AI를 활용하고, AI 덕분에 더 빠르고 AI 없이 했을 때보다 더 높은 품질로 일을 끝내지만, AI가 충분한 품질로 못 하는 코드에는 매일 반드시 소매를 걷어붙이고 도와야 하는 영역이 있음. 어떤 때는 제대로 만들기 위해 반복적으로 여러 라운드를 돌고, AI의 "engineering taste" 학습을 메모리에 기록함. 다른 때는 그게 헛수고라 그냥 내가 쓰는 게 더 빠름.
Claude와 Codex는 특히 logging, telemetry, async correctness, invariants, over-engineering에 약함.
내가 대부분보다 품질을 더 신경 쓰는 건 사실임. 내 동료들은 "때로는 가장 빠른 방법이 처음부터 제대로 하는 것" 같은 캐치프레이즈로 날 부름. AI 전에도 내 코드 리뷰는 동료들에게 invariants를 문서화하고 증명하라고 요구하는 경우가 많았음. 나는 C# language design team에 들어갈 때 그들이 잘못된 covariance를 shipped했다는 수학적 증명을 제시해서 직장을 얻었음. 그리고 세상에는 이런 수준의 quality bar가 필요 없는 소프트웨어도 많다는 건 이해함...나도 30+ YoE이고 할 말은 이것뿐임: 동의함.
나는 LLM을 좋아하고 3090s에서 local models를 돌리며 copilot과 다른 모델들도 쓰지만, 다른 개발자들이 게으르게 수락한 것들을 고치고 리뷰하는 데 많은 시간을 씀.
더 주니어한 개발자들이 게을러지고 품질을 판단할 수 없는 걸 수락하는 건 놀랍지 않음.
오늘 나는 서로 다른 두 개발자에게 LLM에게 묻기만 하지 말고 실제로 THINK하라고 말해야 했음. 그들은 단순히 "delete temporary folders"인 해결책을 찾고 있었는데, LLM 해결책은 헛소리였음.
많은 개발자가 인지를 보강하는 게 아니라 대체하고 있다고 진짜 생각함.나는 이제 현업 2년 차인 개발자이고, 게으른 게 아니라 그냥 속도만이 중요하다는 말을 계속 듣고 있음. 1년 전에는 PR이 탄탄하도록 많은 노력을 들였지만, 이제는 비기술 프로젝트 오너가 느리게 일한다고 ㅈㄹ하지 않을 만큼 빨리 PR을 올리는 데 많은 노력을 들임. 내가 듣는 유일한 피드백은 더 빨리 해야 한다는 것뿐이라, 이제 내가 신경 쓰는 것도 그것뿐임.
이 업계에서 커리어 성장이 뭔지도 잘 모르겠음. 품질과 상관없이 코드를 가장 많이 shipped한 사람이 승진하는 구조임? 안타깝게도 내겐 그렇게 보임.
20년 경력. 우리 회사에서는 지난 6개월 동안 아무도 손으로 코드를 작성하지 않았음. 우리는 여전히 엔지니어링 문제를 해결하지만 코드는 100% AI가 작성함, 다만 모든 pull request는 사람이 리뷰하고 승인함, 이제 리뷰가 병목임
토큰이 떨어지고 실제로 직접 해야 할 때는 어떻게 됨? 기술 스택을 잃어가고 있다고 느낌?
10 YOE C/C++ AAA rendering programmer.
내가 받는 인상은 이 영향을 가장 심하게 받는 사람들은 새로운 일을 하는 게 아니라 X framework를 Y generic business logic에 다시 얹는 webdevs라는 것임, 그게 나쁘다는 건 아님.
비즈니스 로직 의도를 소프트웨어로 바꾸기 위해 매우 정교한 프롬프트를 만드는 것을 가리키는 다른 단어가 이미 있다는 깨달음이 임원들에게 오기를 기다리는 중임, 그건 프로그래밍이라고 부름.
여기 모두에게 상황이 나아지고 균형을 찾을 수 있기를 바람.나는 1년도 더 전에 쓰기를 멈췄음, 그때 사람들은 "AI는 절대 .... 어쩌고저쩌고" 하면서 나를 놀렸음
솔직히 1년 전에는 최고 모델들도 코딩 면에서는 주니어 수준도 아니었음.
맞음 이전 댓글은 매우 걱정스러움.
1년 전에는 codex에게 어떤 항목을 작업하라고 하면 git repository를 가져오고, 코드를 조금 쓰고 commit했음, 마음에 안 들면 다시 요청하고, debug하고, 여기저기 수동으로 수정했음
Gemini cli는 그냥 아무것도 안 하는 loop에 빠졌음
그러고 매달 모든 도구가 개선됨
네 코드를 이해함?
기억함?
네가 휴가 중일 때 다른 사람이 유지보수할 수 있음?그들도 ai 도구가 있음.
나는 각 프로젝트마다 skills files를 만들고, generic 및 회사별 dev skills 위에 얹음. 그게 꽤 잘 전달되는 것 같음.
사람들이 의견 말하기 전에 "10YOE"라고 붙이는 게 유효성 도장인 것처럼 구는 게 웃김. 이런 식으로 특권의식 가진 나쁜 엔지니어들을 본 적 있음
요약하면, 너는 이 짓으로 네 무덤을 파는 중임. AI가 모든 걸 하게 두면서 인지 능력을 천천히 잃고 있음. 언젠가 AI 코드 일부를 건드려야 할 때, 어디서부터 시작해야 할지도 모를 거임
행운을 빔업무용으로는 코드 한 줄도 안 썼음.
하지만 취미 프로젝트로는 여전히 기술을 날카롭게 유지하고 있음. 퇴화를 느끼고 있고, 그걸 해결하려고 조치를 취하는 중임.
나는 또한 내가 선택한 프로그래밍 언어 C#을 버리고 raw C를 택하고 있음. high level languages가 구식이 될 거라는 데 크게 베팅하는 중임. 언어의 learning curve가 더 이상 문제가 아니라면, 왜 python 같은 언어가 필요함? LLM이 알아서 해결해줄 수 있다면 memory managed languages의 모든 overhead가 왜 필요함? 등등. 그래서 이 수준에서 코드를 작성하는 것에 대해 더 근거 있는 의견을 갖기 위해 C를 배우려고 최선을 다하는 중임. LLM은 C를 배우는 데만 쓰고, 전부 내가 직접 씀. 절대 LLM이 대신 쓰게 하지 않음. LLM에게 맡기기 전에 내가 먼저 잘해야 함.
그리고 약간 딴소리지만... holy fuck, C는 대단함. 12개월 넘게 해왔는데, 세상에, 프로그래밍에 대한 내 관점을 완전히 바꿔놨음. 그리고 현대 소프트웨어 품질에 대해서는 훨씬 더 비관적이게 됐음. 우리는 정말 너무나 많은 ㅈ같은 것들, 느린 소프트웨어를 참고 살고 있었고, holy fuck, 그냥 C로 뭔가를 만들어보면 우리가 수십 년 동안 굶주려왔던 게 뭔지 깨닫게 됨... 소프트웨어는 이렇게 되어야 하는 거임. 놀라움. 내가 정말 많이 알게 된 느낌임.Rust를 발견할 때까지 기다려보셈. 😝
진심인지 비꼬는 건지 모르겠음
Edit:
진심이라면, 왜 LLM에게 실수가 더 비용 큰 더 위험한 언어를 시키고 싶음?
그리고 context는 제한돼 있음. thinking windows도 제한돼 있음. 같은 기능을 위해 훨씬 더 많은 일을 하게 만들면 LLM에서 더 신뢰할 수 있는 output을 얻을 거라고 왜 생각함?
어제는 Opus 4.6으로 문제 하나를 해결하려고 하루 종일 썼지만 아무 성과가 없었고, 오늘 내가 직접 들여다봐서 30분 만에 해결했음. 그 해결책은 어제 생성된 코드에서 "hinted"된 것도 아니었고, 그냥 완전히 빗나가 있었음. 직접 코딩이 죽었다는 데 동의하지 않음, 게다가 나는 내 기술을 유지하고 싶음. 뭐가 잘못됐는지 이해한 뒤라면 해결책을 프롬프트로 뽑을 수도 있었겠지만, 그 지점에서는 굳이 왜 함? (Master's comp sci engineer + 9yoe)
Claude는 기술 스택을 고르는 것도 너보다 잘함.
솔직히 채용에서 가장 필요한 건:
모험심임. 지난 한 달 동안 시도한 새 도구나 접근법 목록이 길게 없으면, 그건 시대 뒤처진 dino라는 큰 red flag임. 나는 이렇게 물을 거임: "동시에 돌린 agent sessions의 최대 개수는 몇 개였나요." 답이 0-3이면, 그냥 정중히 마무리할 거임. 이 판은 너무 빠르게 진화해서, 이게 없으면 절대 따라잡지 못함.
극도로 강한 커뮤니케이션 능력. 관찰을 매우 명확한 프롬프트로 바꿀 수 있어야 하고, 그걸 빠르게 해야 함
위임하려는 의지와 통제를 조금 내려놓는 것. 이제 모든 것은 효율적 위임에 관한 것임. 위임된 작업 확인도 이제 위임된 작업임. 프롬프트 작성도 마찬가지임.
AI에 대한 강한 theory of mind. AI가 무엇을 추론할지 알고, 무엇을 명시해야 하는지 알고, AI가 뭘 망칠 가능성이 큰지 알아서 reviewer agents 30개 무리가 그것을 찾게 하는 능력임.
이 게시글은 대부분 AI가 작성한 게 아님 btw.1번에 대해서는 올바른 반응이 “define simultaneous”일 것 같음
그리고 Claude subscription 비용은 누가 내는지도 정의해야 함?
> 모험심임. 지난 한 달 동안 시도한 새 도구나 접근법 목록이 길게 없으면, […] 이 판은 너무 빠르게 진화해서, 이게 없으면 절대 따라잡지 못함
이건 도를 넘게 멍청함. 여기서 본 최악의 의견 중 하나임완전 맞음! reviewer agents 30개가 왜 필요함? 30개의 서로 다른 규칙? 그건 agentic systems의 완전히 멍청한 사용임. 에이전트의 역할은 정의되고 범위가 명확해야 함, reviewer agent 1개면 됨. 100개 에이전트를 띄울 수 있다고 해서 각각 코드 2줄씩 쓰라고 시키고 싶은 건 아님.
그리고 reviewer agents를 vulnerability detection, code smells 등으로 나누고 싶어도, 그래도 30개는 필요 없음.
multi agent system을 multiprocessing처럼 생각하는 사람과는 면접 보고 싶지 않음, 많다고 항상 더 좋은 게 아님.좋은 엔지니어라면 그 멍청한 질문에 1이나 2라고 답할 거임
에이전트를 3개 넘게 돌리는 게 무슨 의미임? 변경사항을 리뷰하고 스펙과 일치하는지 확인해야 함. 동시에 3개 에이전트 이상으로 어떻게 갈 수 있는지 모르겠음. spec/product를 확인하고, AI에게 묻거나 front/back/db의 현재 상태를 확인하고, 원하는 걸 적고, 그걸 5~6번 하고, 의도대로 구현됐는지 다시 봐야 함... 뇌에 너무 피곤함.
어, 맞음.
나는 코드도 안 읽음.사람들이 12월 이후 코드를 안 썼다는 걸 공개적으로 인정하기까지 5개월 정도 걸렸음. 아마 5개월 더 지나면 사람들은 봄부터 코드를 읽는 것도 그만뒀다고 인정할 것 같음.
나는 코드를 읽지 않음.나는 코드를 읽지만, 함수명과 코드의 전체 방향이 맞으면 내부 함수의 로직은 무시한다고 인정함.
네가 전문가라면 Claude의 코드는 그리 좋지 않음. 생성에는 매우 유용하지만, Claude가 놓치는 게 엄청 많이 보이지 않는다면 충분히 꼼꼼히 리뷰하지 않는 것이고 결국 spaghetti가 될 거임.
Claude는 매우 근시안적이고, bloat를 유발할 거임.여기서도 완전히 같은 경험임. 나는 매일 엄청난 양의 것을 만들고 shipped하고 있지만, 코드는 쓰지 않고 있고 이건 쓰레기가 아님. 많은 테스트가 있는 고품질 코드이고 고객 가치를 전달함. 하지만 몇 달 동안 코드 한 줄 안 썼음
추상화의 층, 수단과 방법. 결국 중요한 건 가치 있는 제품을 만드는 것임. AI가 너의 작업을 더 높은 단계로 올려주고 있는 것처럼 들림. 세부사항에 들어가본 경험은 계속 가치 있을 거라고 확신함.
성취감이 없다면, 너는 builder가 아니라 coder임. 적응하거나 죽으셈
동의함, 내 요지는 성취감이 이동했다는 거였음. 이제 프로그래밍 언어에는 관심 없음, 너무 "쉬워졌기" 때문임. 성취감은 스택의 더 높은 곳에서 오고, 그게 그냥 이상한 느낌임.
댓글을 남기려면 로그인이 필요합니다.
로그인 후 이 페이지로 돌아와 바로 댓글을 남길 수 있습니다.