에이전트가 뭔가 작업하고 있는 동안 내가 뭘 해야 할지 잘 모르겠음.
다음 프롬프트를 처리하는 동안 이전 프롬프트에서 생성한 코드를 읽어보려고도 했는데, 속도가 너무 빠름. CISCO 연구 중에 개발자가 현실적으로 검토할 수 있는 코드는 시간당 약 200 LOC 정도이고, 그 이상부터는 결함률이 기하급수적으로 높아진다는 내용이 있었음. 그런데 AI는 코드뿐 아니라 유닛 테스트, CI 설정, 그리고 굉장히 방대한 문서(spec, ADR 등)까지 그 10배 속도로 만들어냄.
그렇다고 프로젝트의 다른 일을 할 수도 없고, 컴퓨터 과학 원리 같은 걸 읽으며 시간을 보내기도 어려움. 뭘 할지 생각을 정리할 즈음이면 AI가 이미 승인을 요청하거나 다음에 뭘 할지 물어봄.
이 "대기 시간"은 뭔가를 하기에는 너무 짧고, 그냥 멍하니 기다리기에는 너무 김. 그래서 결국 YT Shorts를 넘겨보거나 Reddit을 돌아다니게 됨. 그러다 보면 AI는 이미 10분째 내 입력을 기다리고 있었다는 걸 뒤늦게 알게 됨.
이걸 어떻게 받아들여야 할지 잘 모르겠음. 그래, 데이터센터가 환경에 안 좋은 것도 알고, AI가 엄청난 과대광고를 받고 있다는 것도 앎. 하지만 그렇다고 현실을 못 보는 건 아님. AI에는 분명히 굉장히 좋은 활용 사례가 있음. 다만 그 활용 사례를 실제로 어떻게 제대로 실행해야 하는지 모르겠음.
그리고 꽤 자주, 생산성 향상이 이런 2차 효과들에 의해 상쇄되는 느낌이 듦. 미루는 습관이 늘어난다든가, 내가 작성하는 코드와 점점 분리되는 듯한 느낌 같은 것들 말임.
source: reddit
이거 진짜 공감됨. 우리 회사는 코드 작성에 LLM 도구 사용을 의무화하면서도 어떤 이유로든 명령어 allowlist는 금지해서, 모든 결정을 내가 수동 승인해야 함. 이제 내 시간 상당 부분이 Claude 돌보는 데 들어감. 다들 알다시피 실수하고 뭔가 삭제하는 것도 봤음. 그런데
ls명령어까지 승인해야 하는 건 LLM 이전에는 없던 완전히 다른 방식의 시간 낭비임.승인 루프가 제일 최악임. 그냥 직접 명령어를 입력하는 것보다 에이전트가 뭔 ㅂㅅ짓 하려는 건 아닌지 확인하는 데 정신 에너지를 더 쓰게 됨. 코딩이 이상한 돌보기와 도장 찍기의 혼합물이 되는데, 어느 쪽도 생산적이라는 느낌이 안 듦.
처음에는 안전한 명령어를 충분히 allowlist에 넣으면 위험한 명령어에만 신경 쓰면 돼서 쉬워질 줄 알았음. 근데 아님, 승인 루프 전체가 보안 연극임.
복구 가능한 환경에서 잘못된 명령어를 실행하는 거라면 필요할 때 변경사항을 롤백하면 됨. 복구 불가능한 환경에서 실행하는 거라면 아무리 옆에서 돌봐도 재앙을 막기엔 부족함.뭐, 미리 만든 skills로 제한하고 일반적으로 위험을 더 키우는 건 그냥 거부할 수 있음.
예를 들어 엄격한 shell script가 아닌 코드를 실행하게 한다거나, 잘 알려진 명령어가 아닌 shell script는 일일이 봐줘야 함.
하지만 맞음, 제일 좋은 해결책은 제대로 sandbox에 넣어서 진짜 너무 큰 피해는 못 주게 하는 거임...어제 프로젝트에서 temp 파일 지우다가 내 terraform statefile도 삭제함. 보아하니 terraform state는 임시 파일로 간주되나 봄
"네 말이 완전히 맞음, 나는 아무 근거 없이 무차별 파괴의 길을 가고 있었음. 네가 묻지도 않았는데 내가 다 ㅈ되게 만든 방법은 다음과 같음:"
그러고는 실제 코드 변경 방식 4개 중 5개를 나열하고, 남은 근무 시간 내내 꼬리 물고 쫓아다니게 됨.미안, 그거 하나 덮어써버렸음
이상하네, 어제 나도 비슷한 경험 올렸다가 여기서 십자가형 당했는데 ㅋㅋ
봇들이 이 글은 놓쳤나 봄 ¯_(ツ)_/¯
어제는 있었는데 지금은 없음. 꽤 임시적이네!
ㅋㅋ 그쪽의 정당화는 "git ignore 파일에 포함돼 있으니 보관할 필요가 없다"였음
ㅋㅋ "AI native"가 수많은 코드베이스를 파괴하게 될 거임...
그러다 승인 피로가 와서 AI에 점점 더 많은 권한을 주게 됨. 나도 몇 번, 파괴적인 건 아니어도 자동화에 넘기면 안 되는 걸 승인했다는 걸 뒤늦게 깨달았음. 예를 들면 계정 전체에 적용되는 GH key 추가 같은 거. 과정 자체도 점점 대충 하게 됨.
ls명령어 승인하는 건 진짜 기업 보안 연극의 정점임너희 auto mode 안 씀?
어떤 사람들은 안 씀. 같이 일하는 개발자 한 명이 5분짜리 통화 동안 approve를 20번쯤 누르는 걸 봤음. 우리는 mode 제한도 없는데 진짜 충격이었음.
많은 조직이 금지하고 있는데 이해는 됨. 그래도 최소한 read-only 명령어라도 allowlist에 넣을 수 있으면 도움 됨
read-only 명령어 같은 건 존재하지 않음. 특정 명령어가 read-only인지 점치듯 판단하는 것보다 auto mode가 나음. 조직들이 auto mode 같은 걸 더 잘 활용해야 한다고 봄. 이런 명령어를 수동 승인하는 건 미친 짓임.
나는 회사에서 "모두가 항상 60%의 시간 동안 100% AI를 써야 함!" 같은 정책을 자주 봄.
Fable도 아주 잠깐 썼다가 청구서 들어오니까 패닉해서 바로 플러그 뽑았음 ㅋㅋ.그냥 본인한테 합리적인 로컬 allowlist를 만들면 되는 거 아님?
그러니까... 회사가 어떻게 앎?모든 도구가 중앙에서 관리됨
나도 하루가 이럼. 변경 승인은 기꺼이 하겠는데, "뭔가 가져와서 읽어도 됨?" 같은 요청/명령은 끝도 없이 나오고, 또 애매하게 드문 간격으로 들어와서 현대판 Desert Bus가 됨
Claude에 DB write permissions가 있는 MCP 접근 권한을 안 주고, 스스로 comment하거나 push하는 걸 엄격히 금지하고, repository 하나로만 제한하면 되돌릴 수 없는 일을 할 수 있는 범위는 거의 없음.
ㅈㄴ 별로네. 나는 그냥 모든 명령어 허용해두는데 알아서 자율적으로 잘 작동함.
체스 둠.
여기 댓글들 진짜 믿기 힘들 정도로 우울함. 너무 많은 사람이 그냥 포기한 게 명확함. 진짜 LLM이 코드를 토해내는 걸 구경하면서 본인의 소프트웨어 작성 능력을 잃어가는 데 만족하는 거임? 에이전트를 이런 식으로 쓰는 사람들이 실제로 전부 리뷰하고 있을 리가 없음, 그건 그냥 불가능함.
이거 진짜 암울함.그러기 진짜 어려움. 비디오 게임에서 min-maxing하는 거랑 비슷함. 사실 거의 똑같음. Destiny 2 플레이어들 사이에서 흔한 문제가 있는데, 누가 늘 똑같은 빌드와 총만 써야 해서 질린다고 불평함. 그러면 유저들이 "그냥 다른 거 써, 네가 스스로 그러는 거잖아"라고 함. 그 말이 맞긴 한데, 단지 그러고 싶다는 이유로 업무에서 제일 효과적인 도구를 안 쓰기는 어려움. 이게 심리에 바로 파고드는 것 같고, 물처럼 저항이 제일 적은 길을 따라가게 됨.
나는 이 문제로 정말 크게 힘들어함. 지금 은퇴할 수 있다면 당장 할 거임. 생계를 위해 일하고 싶지 않고, 그냥 살면서 여러 취미 사이를 밀물썰물처럼 오가고 싶음. 하지만 그럴 수 없고, 일해야 함. AI 이전에는 내 머리로 진짜 문제를 풀도록 강제됐기 때문에 직업에 더 만족했음. 지치는 만큼 보람도 있었음. 그런데 이제 Claude 버튼이 나를 쳐다보고 있으니 그냥 눌러버리고 reddit, youtube 같은 데 가서 놀기 너무 쉬움.
음식 문제 있는 우리 같은 사람들한테는 외식과 요리의 차이 같기도 함. 나도 요리할 수 있지만 일이 많고 결과는 그냥 충분히 괜찮은 정도임, 임무는 완수한 셈. 배달은 무한한 선택지를 제공하고 꾸준히 맛있고 편하지만, 수많은 단점도 따라옴.
AI 때문에 내 정신 건강이 안 좋아지고 있는 것 같음.재미까지 최적화해서 없애버리는 거임.
많은 사람들, 특히 엔지니어한테는 최적화 자체가 재미임.
정신 건강이 안 좋아지고 있는 게 맞을 거임! 가만히 앉아 코드가 자동 생성되는 걸 보고 가끔 변경 승인만 하는 건 영적으로 타락한 활동임. 아무도 기계의 노예로 하루를 보내고 싶어 하진 않음.
이런 상황에 갇힌 모든 사람이 안타까움.표현 진짜 잘했음. 완전히 동의함
대부분의 경우 그게 "업무에 가장 좋은 도구"라는 데 회의적임. 최상의 상황에서도 보통 겨우 쓸 만한 수준인 것 같고, 그 대가로 자기 코드베이스 이해도를 내주는 경우가 많음.
물론 네가 쓰는 것보다 더 많은 코드를 만들어주긴 하겠지만, 양 대 질은...최소 기능은 하고 차별점 없는 범용품 수준이라는 의미에서는 좋음. 그냥 통과할 정도 품질이면 괜찮다는 거라면 훌륭하지
이게 암울한 이유는 개발자들이 적응하지 않으면 대체될 거라는 말을 듣고 있기 때문임. 오래되고 경험 많은 회사들은 "AI native" 스타트업에 밀리고 있는데, 경영진은 AI 사용 때문에 그쪽이 더 효과적이라고 인식하고 있고 투자자들도 거기에 동의함.
근데 실제로 더 효과적이라는 걸 제대로 증명한 곳은 없음.
많은 스타트업이 "더 효과적"인 건 오히려 관료주의가 적어서인데, AI native 회사는 제대로 된 아키텍처 자체를 건너뛰기 때문에 더 효과적으로 보일 거고 그건 나중에 발목 잡힐 거임.
나중의 AI가 버그 없이 전부 다시 작성할 만큼 좋아지길 기대하는 게 아니라면 말임.정확히 그걸 기대하는 거임
그래서 몇 년 지나면 시장이 회복될 거라고 꽤 확신함. 이미 동료 대부분을 AI 망상에 잃었음. 이제 자기 머리를 쓰는 법도 모르는 수준임.
지난주 나는 원시인처럼 코드를 약 500줄 직접 타이핑해서 테스트 제외하고 하루 만에 간단한 페이지를 만들었음. 동료는 비슷한 복잡도의 페이지를 AI만 써서 만들었는데 15,000줄이 넘었음. 농담이면 좋겠음. 그 개 ㅈ같은 slop이 내 코드베이스에 못 들어오게 매일 싸우는 중임. 다행히 리더십이 내 말은 들어줌... 지금은...투자자들이 유니콘에 베팅하고 싶어서 개소리를 마구 삼키고 있음. 그 인식 자체도 반드시 맞는 건 아니고, 다들 남들이 하니까 너무 빠르게 만들고 도입하고 있음. 대부분이 실제로 얼마나 실현 가능한지 제대로 검증하는 사람이 없는 느낌임.
대형 테크 회사들이 모든 제품에 밀어 넣으면서 아마 잘못된 정당성을 부여하고 있기도 함. 그러면서 자기 제품을 오히려 더 나쁘게 만들고 있다고 볼 수도 있음.
그런 회사들은 막대한 자본을 뿌려도 살아남을 수 있음. 하지만 실패도 엄청 많이 나오고 시간과 돈도 엄청 낭비될 거임.
투자자와 빅테크가 만들어낸 완전한 개판임. 그렇다고 이 중 뭐라도 "좋다"는 뜻은 아님.100% 그래서 내 글에서도 "인식하고 있다"라고 표현한 거임. 그런데 불행히도 인식이 현실이 되는 경우가 많음. 투자자들은 AI에 베팅하고 있고, 미국 시장 전체가 그걸로 떠받쳐지고 있다고 해도 될 정도임. 경영진은 최대한 빨리 전환하고 도입하지 않으면 뒤처질 거라고 느끼고, 그 지시가 individual contributor까지 내려옴. 지금 최고 모델들이 이 정도로 싸게 유지될 일은 절대 없다는 걸 회사들이 깨닫고, 실제 가치가 아니라 token 단위로 output을 측정하는 건 멍청하다는 걸 알게 되면 심판의 순간이 올 거라고 기대함.
말 잘했음, 동의함. 지금 사이트 migration을 도우라고 Claude와 씨름하면서 그 가치가 있는지 의문을 갖는 중임.
분명 특정 일에는 능력이 있지만, 직원들을 대체하고 심각한 문제를 해결해줄 AGI라는 생각은 그냥 사기약 장사임. 이상하게도 실제로 현장에서 쓰는 사람들보다 윗선이 그걸 더 굳게 믿고 있는 것 같음.
안타깝게도 이성적인 목소리를 내려 해도 해일한테 멈추라고 소리치는 기분임.
나는 돈 벌려고 일함. 취미 코딩은 전부 업무 밖에서 하는데, 아이러니하게도 이제 AI가 상사를 위해 코드를 찍어내는 동안 취미에 쓸 시간은 더 많아짐.
문제가 이거임. 아직도 신경 쓰고 열심히 하는 사람은 보상받지 못함. 오히려 vibe coding하는 동료들보다 느리다고 벌을 받음.
매주 월요일 장애 나기 전까진 내 문제 아님.. ;) 근데 그쯤 되면 slop이 다 잘 섞여서 훌륭한 스튜가 돼 있으니 누구 한 명을 콕 집어 탓할 수도 없음. 조직의 실패고, 안타깝게도 회사는 결국 어렵게 배워야 함.개발자로 일함?
함, 다만 운 좋게도 나 자신을 위해 일함.
걔네 아무것도 리뷰 안 함. 기껏해야 100줄이면 될 기능이 어떻게든 1k+줄 PR이 되어 나옴.
하루에 1k+줄짜리 PR을 5개씩 여는데 당연히 아무것도 리뷰 안 했음.
제일 최악인 건 일부 동료들이 ㅈ같은 걸 쉬지 않고 찍어낼 뿐 아니라, 내가 일을 충분히 빨리 끝내지 않으면 아무도 부탁 안 했는데 내 task까지 가져가서 처리하고 나를 농땡이 피우는 사람처럼 보이게 만든다는 거임.
다행히 아직 AI 의무화로 완전히 미친 곳에서 일하는 건 아니고, 처음에는 거의 안 썼음. 그런데 이제는 다른 사람만큼 slop을 찍어내지 않으면 해고될까 봐 무서워서, 맞음, 포기했음.시간 좀 지나면 네 회사도 굴복할 거임.
에이전트를 이런 식으로 쓰는 사람들이 실제로 전부 리뷰하고 있을 리가 없음, 그건 그냥 불가능함.
글쎄, 실제 제품에 들어가는 건 AI가 만든 모든 줄을 리뷰함.
물론 AI의 "최고 속도"보다는 느리지만 직접 작성하는 것보다는 여전히 빠름. 논리적 불일치, dead code, 쓸데없는 군더더기도 많이 잡음.
boilerplate라 리뷰가 거의 필요 없는 코드도 많음. AI는 그걸 엄청 빠르게 해줌. 아니면 결과만 정확하면 품질은 크게 중요하지 않은 QoL script 같은 것도 있음.
specs나 documentation 작성에도 훨씬 많은 시간을 씀. LLM과 몇 차례 논의하면서 나오는 아키텍처가 내가 혼자 만드는 것보다 낫다고 느낌. 혼자 하면 뭘 원하는지 대략 감이 오는 순간 바로 작성하고 싶은 유혹이 생기기 때문임. LLM과 하면 정확히 어떻게 해야 하는지 설명하고, 그 접근이 맞는지 논의하고, 다른 선택지나 따져볼 장단점이 있는지 묻고, 내가 기대한 방식대로 됐는지 확인해야 함.
적어도 어떤 경우에는 결과가 훨씬 더 좋다고 생각함.LLM은 coder's block 깨는 데도 훌륭함.
가끔은 혼자 동기랑 생각을 끌어내려고 애쓰는 것보다 걔가 ㅈ같이 해놓은 걸 보고 고치는 게 더 빨리 영감을 줌.맞음. 나도 처음부터 쓰는 것보다 기존 코드를 리뷰하고 수정하는 게 더 쉬울 때가 많음.
나도 걔가 만드는 slop 중 일부가 싫어서 리뷰함.
excessivelyLongVariableNameNoRealHumanWouldUse같은 것까지도.
그리고 "컴퓨터야, 이 기능 전체 만들어" 식으로 날뛰게 두지도 않음. 내가 문제 풀 때 하듯 한 단계씩 진행하고 매 단계 리뷰함.
여러 sub task를 동시에 돌리고 전부 orchestration하는 걸 좋아하는 사람도 분명 있겠지만, 나는 미래의 나를 그 정도로 싫어하진 않아서 리뷰함.나는 LLM이 내가 뭔가 이해한 게 맞는지 검증하는 데 쓰는 코드를 많이 작성하게 함. 실제 production code는 이해하려고 하지만, 내가 관리하는 전체 코드에서 그 비중은 점점 줄어들고 있음. 점점 더 많이 관리하는 건 tests, test harnesses, 그리고 AI가 광범위한 regression testing을 할 수 있는 환경을 띄우는 tooling임.
그리고 AI한테 코드 지우라고 하는 데도 시간을 많이 씀. 사실 코드를 간결하고 잘 구조화되게 refactoring하는 건 꽤 잘함. 문제는 시켜야 한다는 거임.우리는 전부 리뷰하고 보통 test case도 직접 작성함. 모두가 모든 걸 vibe coding하는 건 아님. 뭘 했는지 이해가 안 되면 왜 그 방식을 선택했는지 설명하게 하고, well architect framework 같은 것과 어떻게 맞는지도 설명하게 함. 진행하면서 계속 수정해서 사소한 문제가 나머지 전체로 퍼지지 않게 함.
AI가 장악하게 두지 않고도 속도를 높이는 데 쓸 수 있음.
다만 내가 뭔가 하는 데 도움 되는 도구를 만들고, 출력물을 보고 "응, 작동하네"라고 말할 수 있는 경우에는 vibe coding에 훨씬 가까워짐. 뭔가 추출하는 도구들도 여러 개 있고, 뭔가를 만들어내는 앱을 만든 뒤 최종 결과를 보고, 다시 vibe coding한 앱으로 돌아가 수정하고 재export하기도 함.
Ada 83 Language Reference Manual에 이런 문장이 있음:
신뢰성을 높이고 유지보수를 단순화하는 언어가 필요하다는 사실은 잘 확립되어 있음. 따라서 작성 편의성보다 프로그램 가독성에 중점을 두었음.
… 그리고 Robert C. Martin의 Clean Code 같은 곳에서도 비슷하게 표현했음:
실제로 읽는 데 쓰는 시간과 쓰는 데 쓰는 시간의 비율은 10 대 1을 훨씬 넘음. 우리는 새 코드를 작성하는 과정에서 끊임없이 오래된 코드를 읽음. ...[그러므로,] 읽기 쉽게 만들면 쓰기도 쉬워짐.
… 이런 건 늘 사실이었음. LLM이 다양한 품질의 코드를 작성하는 부담을 극적으로 줄여버린 환경에서는 그 비율이 더 커질 뿐임. 즉 업무가 감독에 가까워지는 때와 장소에서는 에이전트가 절대 리뷰할 수 없는 거대하고 난잡한 commit을 주지 못하게 지시하는 걸 최우선으로 둬야 함. 좋은 senior가 junior developer에게 5K LOC pull request를 쪼개라고 지시하듯, 에이전트가 하나의 이야기를 들려주도록 명시적으로 지시해야 함. 작성된 걸 유지보수해야 하는 책임은 네게 있고, LLM은 그렇게 하라고 지시하지 않는 이상 review-ability를 전혀 우선시하지 않기 때문임.업무 시간의 모든 순간을 활동으로 채울 필요 없음. process를 돌리고 있고 끝날 때까지 기다려야 한다면 그냥 기다려도 됨. 그건 미루는 것도 아니고 게으른 것도 아님. 고용주가 너무 세세하게 감시해서 기계가 일하는 동안에도 편하게 쉬면 안 된다고 느낀다면 그건 문화 문제임.
우리는 지식 노동자임. 뇌는 근육 같아서 휴식과 쉬는 시간이 필요함. 뇌에는 고정된 용량이 있고 그걸 넘으면 즉시 회복되지 않음. 뇌한테 잘해줘야 함. 숨 쉴 공간을 줘야 함. 화면에서 눈을 떼고 책을 가져오면 됨. 더 좋게는, prompt 작업을 리뷰할 시간이 되면 돌아오게 알람을 맞추고 가능하면 밖으로 나가 걸으면 됨.
그리고 들어봐, 그걸로 ㅈㄹ 받으면 그 ㅈㄹ하는 사람이 매일 매 순간 단 한 순간도 빠짐없이 일하는지 반드시 확인하고, 네가 늘 지켜보고 있다는 걸 알게 하면 됨. 걔들이 무너질 때까지 그 불안을 되돌려주면 됨. 상사도 번아웃시킬 수 있고, 종종 평직원보다 더 쉬움. 이미 바쁘고 기다리고 있는 사람에게 억지로 일시키는 건 사람 미치게 만드는 아주 좋은 방법임.예전엔 컴파일 기다리면서 놀았고, 이제는 claude 기다리면서 노는 거임
정확함. 나도 몇 년 전에 끊었고 몸에 ㅈ같은 건 알지만, 이런 때 밖에 나가 담배 하나 피우면서 주차장 사람들과 잡담하는 거임. 아니면 돌아다니면서 일하려는 사람들 방해하거나.
나도 똑같음. 이런 식으로 여러 프로젝트를 동시에 진행하면 대부분의 session이 내 input을 너무 오래 기다리는 상황도 생김.
AI가 간단한 걸 가지고도 너무 오래 고생하면서 이상한 rabbit hole에 빠지면, 실제로 생산적이었던 작업에서 절약한 시간을 다 상쇄해버리는 경우도 있음.
이 주제로 영상 올린 YouTuber가 누구임? 오늘 똑같은 질문이 꽤 여러 번 올라왔음.
ADHD가 있어서 flow state에 들어가면 에이전트 두세 개를 동시에 코딩시킴, 심지어 서로 다른 프로젝트일 때도 많음. 그러고 승인이나 후속 prompt를 주러 이쪽저쪽 왔다 갔다 함.
workflow가 어떻게 됨?
기능을 대신 작성하게 하지 마셈. 기능을 어떻게 작성할 건지 물어보고 직접 타이핑하셈.
아무 생각 없이 폰 스크롤하면서 에이전트를 돌보는 방식으로는 실제 업무에서 얻어야 할 학습과 성장을 스스로 빼앗는 거임. 그렇게 쉽게 교육이나 비판적 사고 능력을 뺏기지 마셈.기능을 어떻게 작성할 건지 묻는 것도 실제 학습과 성장을 빼앗는 것 같은데.
그냥… 생각하고 기능을 작성하면 됨.Claude Subscription 하나 쥐여주고 5x 더 빨리 납품하길 기대하는 회사에서 그렇게 해보셈
구체적으로 기대한다고 말하지 않아도 상사는 왜 동료들 속도를 못 따라가냐고 물을 거임.
그러니까 조언이 배우기 위해 Claude가 시키는 걸 직접 작성하라는 거잖음… 그 경우 속도 향상도 버리고 학습도 버리는 느낌임. 둘 다 최악인 조합임.
ㅈ 샌드위치 전문 식당에서 셰프로 일하면서 행운을 빌겠음.
멍청한 의견임. syntax를 직접 타이핑하는 부분에 무슨 사고가 필요함? 반대로 해야 함. 네가 설계하고, 아키텍처 짜고, 코드를 읽고, 뭘 할지 지시하는 거임.
인간만큼 잘 설계하거나 context를 많이 갖는 일은 절대 없을 거임.
나라면
A) 다른 걸 multitask함 - code review, 다른 사람 프로젝트, slack 메시지
B) 그냥 쉬거나 산책감이거 동의함. 지난 일주일 동안 Claude code로 mobile layout 작업을 시켰음. 나는 그쪽 디자인에 능숙하지 않고, Claude가 그럭저럭 해내긴 했지만 걔가 작성한 css 상당 부분이 내겐 black box였음. 작업하는 동안 개발자로서 내 능력이 늘지 않는다고 느꼈음. 큰 틀을 완성하고 나니 당연히 고칠 세부사항이 남았음. 그런데 Claude한테 그걸 고치게 하는 건 다른 5개를 동시에 망가뜨리고 token 수천 개를 씹어먹어서 정말 고통스러웠음.
결국 몇 시간 들여 걔의 변경사항을 전부 읽고, 내가 익숙한 convention에 맞춰 더 말이 되도록 구조를 수정하는 게 훨씬 쉬웠음. 그러고 나니 작은 세부사항은 내가 직접 더 좋은 결과로 끝낼 수 있었음.
내 경험 수준으로는 처음부터 걔가 만든 걸 직접 만들려면 훨씬 오래 걸렸겠지만, 코드를 읽고 배우지 않았다면 아마 polish를 끝내려고 아직도 왔다 갔다 하고 있었을 거임.글쎄, 나는 그냥 AI가 처음부터 내가 원하는 방식으로 작업하게 가르치는 skills를 작성함. 그러고 결과를 한 줄씩 리뷰하고 이해 안 되는 게 있으면 설명해달라고 함. 마음에 안 드는 걸 했다면 skill을 수정하게 함.
그래도 내가 직접 쓰는 것보다 빠름.
결과 코드 품질도 내가 평소 만드는 수준과 비슷함.
다만 CSS는 특히 못하긴 함, 나도 느꼈음.나도 본질적으로 그렇게 함. 다만 모든 코딩을 모델에 맡기는 건 아직 꺼림칙함. 일반적으로는 내가 완전히 자신 있는 것만 모델한테 맡김. 익숙하지 않은 건 ai를 일종의 선별된 Google search처럼 써서 보통 어떤 해결책을 쓰는지 보고 거기서 시작하는 걸 선호함.
그래도 AI가 생산성을 오히려 떨어뜨린 경우를 꽤 겪었음. 보통 걔가 요청하는 백만 번째 코드 수정을 내가 더 이상 제대로 보지 않기 시작했을 때임.
agentic AI에서 내가 느끼는 문제는 직접 코드 작성에서 멀어질수록 코드베이스와 sync를 유지하기 더 어려워진다는 거임. 결국 에이전트 output을 믿을 수 있을 만큼 신뢰를 쌓기 위해 작성, 검증, 재작성 루프에 맞춰 workflow를 조정하게 됨. 생산성 이점은 보이지만 이게 마음에 드는지는 모르겠음. 나는 실제로 코드 작성하는 걸 좋아함, 아니 예전엔 그랬음. 이제는 작성하지 않으니까
시스템 설계나 더 고차원적인 문제를 다루는 걸 좋아했던 거임? 아니면 syntax 줄 작성하는 게 좋았던 거임?
처음부터 허용되는 걸 엄격히 정하면 더 낫다고 봄. 강한 규칙을 주셈. 아키텍처, coding standards/conventions, 사용 가능한 libraries를 정의하고 새로 추가 못 하게 하고, minting도 설정하는 식임. 이 부분이 돌처럼 굳어 있으면 로봇이 멋대로 이탈할 가능성이 줄어듦. 완벽하다는 건 아니지만 도움 됨.
나는 보안 쪽에서 일해서 여러 프로젝트를 자주 동시에 다루는데, 모든 도구의
agents.md에 파일을 수정할 때마다 자체 worktree로 분리하라고 적어둠. 그래서 근무 중 바쁨 정도에 따라 session을 2~4개 돌릴 때도 있음. 그 정도면 downtime이 없음. skill로avoid-ai-writing도 추천함.openspec도 쓰고 spec에 맞춰 코드를 작성해서 drift 일부를 막고 있음.반수동적인 copilot 역할로 네가 계속 붙어 있어야 하지 않는 방식으로 workflow를 구성해보셈. 작업 범위를 정해주고 나중에 결과를 보러 돌아오는 식임. 그러려면 먼저 프로젝트를 agent-friendly 상태로 만들기 위한 선행 작업이 좀 필요할 수 있음.
에이전트가 긴 작업을 하는 동안 나는 운동함.
몇 달 전에 사무실 한쪽에 kettlebell과 yoga mat를 둔 작은 공간을 만들었음. 자세, 에너지, 집중력이 꽤 좋아졌음. 이제 다시 새로운 걸 배울 의욕도 생김.
남는 시간을 자기 개선에 쓰셈, 건강부터 시작하면 됨. 현재의 agentic coding 혁명은 개인 자유시간에 잠깐 생긴 보너스라고 생각함. project management / planning 쪽은 아직 따라오지 못해서, 내 경험상 에이전트를 활용하는 엔지니어는 할 일이 줄어드는 경향이 있음. 그게 지속되는 동안 활용하셈. 자기계발하고, 다른 팀이 뭘 하는지도 둘러보고, 조직 전체 initiative에 기여할 기회가 있는지도 찾아보면 됨.여러 에이전트를 각자 자기 worktree에서 돌리셈.
몇 달 전에 이 빈 시간을 채우려고 poly-clay 조각을 만들기 시작했음. 지금 200개 넘게 있음.
그리고 좀 더 밝고 생산적인 얘기로는, 이제 ticket 3~4개를 동시에 처리하는 감을 잡기 시작해서 항상 내 주의가 필요한 게 하나씩 있음.좋은 옛날 transistor radio로 음악 크게 틀고, steak 좀 굽고, 잔디도 깎고, yeeeaah booi
맞음.. 처음에는 AI가 뱉는 코드를 전부 리뷰하고, 필요한 곳마다 세부적인 선택을 직접 지시하면서 진행할 거라고 생각했음.
그런데 현실은 AI가 나보다 코드를 리뷰하고 생성하는 데 훨씬 빠르고 효율적이라는 걸 느끼는 중임. 여전히 output을 정기적으로 리뷰하는 게 중요하다고 생각하지만 큰 프로젝트에서는 따라잡을 수 없는 경우가 많고, 결국 AI가 만든 걸 리뷰하는 데도 AI 도움을 쓰게 됨. 안 그러면 내가 뒤처지고 전체 속도를 늦춰서 AI를 쓰는 목적 중 하나인 생산성 향상을 무색하게 함.본질적인 질문에 답하는 건 아니지만,
"asks for permissions" 문제는 skip permissions guard를 쓸 수 있음. 어떤 harness를 쓰는지에 따라 다르지만 claude code에는 이미 drive 전체를 날려버리지 않도록 하는 보호 기능이 내장돼 있음. 그래도 일어날 수는 있으니 이상적으로는 프로젝트를 docker containers 안에서 실행하거나, 네가 선호하는 다른 damage management 방식을 쓰면 됨. 파일을 전부 backup해도 되고 선택은 자유임. 어쨌든 계속 permission을 yes로 승인해야 하는 걸 피할 방법은 있음. 많이 쓸 생각이면 장기적으로 시간과 노력을 아끼기 위해 먼저 그 문제 해결에 시간을 투자할 것 같음.이걸로 욕먹을 수도 있겠지만, 나는 명확한 plan이 있는 task에 쓰기 시작했음. 예를 들어 resource type 2개에 대한 dashboard page가 이미 있었고, 세 번째 resource type용 dashboard page가 필요했음. API endpoint shape까지 포함해서 처음 2개가 사실상 template이었던 거임. Claude한테 어디를 봐야 하는지 알려주고 plan을 만들게 한 다음 실행시켰음. 그동안 나는 다른 일을 했음. 나중에 돌아와 test하고 확인했음. 이제 그 resource의 기본 dashboard page가 준비됐고 그 위에 필요한 customization만 더하면 됨. 그 경우 한두 시간 정도 절약했을 거임. 걔가 사용하는 template 자체를 내가 사실상 작성했기 때문에 어떻게 동작하는지도 계속 이해하고 있었고, 시작시키기 전에 plan도 검토해서 이상한 수작 부리는지 확인했음.
나는 우리 업무의 좀 더 "soft한" 측면을 개선하는 데 집중하기 시작했음. Design, layout, readability, accessibility 같은 것들임. 그냥 raw code나 engineering effort에만 매달리는 대신 그런 쪽을 봄.
하지만 동시에 다들 하는 말도 공감됨.미루는 문화는 AI 이전에도 소프트웨어 개발에서 엄청 큰 문제였음. 다만 뭔가 만드는 데 15x 더 오래 걸릴 때는 거기에 빠지기가 더 쉬웠음.
AI가 다음 작업을 하는 동안 전에 작성한 코드를 읽고, 동의하지 않는 부분을 찾으면 고치거나 설명해달라는 prompt를 적어둠.
manual testing도 함.
맞음, AI가 나를 기다리는 경우가 많음. 하지만 내 이름으로 commit되는 코드를 승인하는 데 그만큼 시간이 걸리는 건 그냥 현실임.이런 쉬는 시간에 kettlebell 운동을 micro set으로 하기 시작했는데 진짜 장담함, 하루에 규칙적인 운동을 끼워 넣는 가장 빠른 방법임. Claude Code Workout 곧 뜰 거임.
당연하지. 나도 몇 달 전부터 prompt 사이에 pushup을 하기 시작했고 최근에는 kettlebell도 하나 샀음.
kettlebell workout 추천 있음?
그 "작은 틈"에는 Reddit, 9gag 아니면 그냥 일반 browsing함. 맞음, throughput을 min/maxing하는 건 아니지만 뭐 어차피 큰 차이도 없을 거임.
뭐가 문제인지 모르겠음. AI가 ticket이나 issue 하나를 작업 중이면 너나 AI가 새 work tree에서 다른 일을 하면 됨. Codex 같은 agent coordinator app을 쓰는 거임, 아니면 그냥 IDE에서 씀? IDE는 한 번에 폴더 하나에서 작업하니 좀 어렵지만 전자는 여러 ticket 동시에 처리하는 데 아주 잘 됨.
서로 다른 에이전트들이 서로 다른 프로젝트를 동시에 작업하게 해서 어느 정도 재미를 봤음. 다만 프로젝트에서 프로젝트로 옮겨 다니면 context switching이 많아서 힘들 수 있고, 동시에 AI 도움을 받을 수 있는 프로젝트가 여러 개 있어야 한다는 조건도 있음.
어릴 때 keyboard를 배우던 게 생각남. keyboard가 컴퓨터 바로 옆에 있었음. 그리고 컴퓨터 켜는 데 몇 분씩 걸렸음, 요즘처럼 계속 켜두지는 않았으니까. 그래서 앉아서 컴퓨터를 켜고 boot되는 동안 곡 한두 개를 연습했음.speed cubing 연습하셈.
harness를 더 잘 쓰고, scripting용 python도 더 잘하고, API 접근 같은 것도 더 익혀야 함. 네 attention이 필요할 때 알림 보내게 하고, subagents 등을 써서 장기 task를 처리할 수 있도록 toolchain을 구축하셈.
그러면 X를 하라고 시켜놓고 Y를 할 시간이 생김. X가 끝나면 알 수 있고, 다시 prompt를 주거나 하던 일을 처리한 뒤 로봇을 다시 일시키고 Y로 돌아가면 됨.
이 문제는 완전히 이해함. 회사 lunch break가 짜증 나는 것과 비슷함. 돈은 안 받는 시간인데... 그렇다고 뭘 하기에는 시간이 부족함. 나는 5분이면 밥 먹으니 한 시간이면 그냥 내 하루에서 55분을 도둑맞는 거임."Bypass permissions" mode를 켜면 AI가 approval을 요청하지 않음.
문제는 기다리는 거라고 봄. 4분짜리 실행은 지켜보기엔 너무 길고, 다른 걸 시작하기엔 너무 짧음.
이해함. 예전에 직접 하던 일을 AI가 대신하고 있으면 이상하고, 심지어 쓸모없는 사람이 된 듯 어색하게 느껴짐.
너만 그런 건 아니라는 걸 기억하면 됨. AI는 특히 원래 attention span에 어려움이 있다면 꽤 양날의 검임. 마찰을 너무 많이 없애서 갑자기 떠오른 온갖 생각이 전부 프로젝트처럼 느껴짐 ㅋㅋ. 그리고 그게 "false productivity" 문제로 이어지는 것 같음. AI로 엄청 많은 걸 하고 있는데도 실제로는 아무것도 못 끝낸 느낌이 들 수 있음. 어쩌면 진짜 문제는 AI 때문에 잘못된 곳에 attention을 쓰기가 너무 쉬워졌다는 거임.코드와 분리된 느낌
뭐, 애초에 네 코드가 아니니까. 그냥 네가 리뷰하는 다른 누군가의 코드임. 그리고 그 누군가는 같이 성장하고 배우는 동료조차 아님. 인터넷에서 긁어온 데이터를 그냥 뒤섞어 코드를 토해내는 봇이고, 아마 네가 원하는 걸 할 수도 있고 아닐 수도 있음. 필요 이상으로 훨씬 장황하고 반복적일 가능성이 높고, 네가 따라잡거나 진짜 이해할 시간을 낼 가능성이 없을 정도로 번개처럼 빠르게 만들어냄.> AI가 이미 approval을 요청하거나 다음에 뭘 할지 물어봄
내가 알게 된 건 AI와 대화하는 시간은 처음에 쓰는 게 가장 좋다는 거임. 추가 input 없이 전체 process 동안 AI가 따라갈 수 있는 spec으로 발전하는 plan을 처음부터 만드는 데 쓰는 거임. spec 복잡도에 따라 AI는 몇 시간씩 돌 수 있고, 그동안 나는 다른 plan을 만들거나 코드를 읽거나 다른 걸 할 수 있음. git worktrees를 쓰는 것도 엄청 도움 됨.
지루해짐. 하루가 너무 안 가서 결국 그냥 내가 직접 하고 test만 걔한테 작성시킴.
전 주로 옆사람 괴롭히는데 오키분들은 어떻게 하고 계시나요?
