의견 감사합니다! 오픈소스 문서를 사용하는 용도로도 충분히 의미가 있으니 자주 사용해주세요! 다른 오픈소스 더 많이 올려보도록 하겠습니다. 감사합니다!

수정하였습니다. 제보 감사드립니다!!

진짜 여러 부분에서 공감 ㅋㅋ 개 답답해서 걍 내려놓고 돈 받는만큼만 일하자 모드 되니 오히려 일이 스무스 하게 진행된다고 좋아함. 실제론 리스크가 있는 개발방향성이 보여도 알바아님 상태가 된건데

https://news.hada.io/topic?id=21170
이 글하고 같이보면 좋겠네요

써보고 있는데 회사 정보는 올리기 좀 무섭긴 하지만 오픈소스 문서들 MCP 서버로 쓰기에 좋네요
다른 소스들 문서들 많이 추가되면 좋겠어요

다만 권한 모델이 구현되어 있지 않아 토큰 권한을 제어할 수 없음 (내가 틀렸다면 알려주길 바람)

현재는 지원하고 있습니다.

제목 및 단어로 검색이 안되는줄 모르고 있었네요. 수정했습니다!
(기사에 좋아요 하시면 모아서 보실 수도 있어요)
피드백 감사드립니다.

1. "속도감은 활력소다" (긍정파)

  • 입장: 지루한 작업을 AI가 빠르게 처리해주어 오히려 에너지가 넘치고, 새로운 기술 스택 학습 비용을 줄여주어 긍정적임.
  • 사례: 낯선 언어나 프레임워크를 사용할 때 AI 에이전트 덕분에 지루한 학습 과정을 건너뛰고 바로 구현에 집중할 수 있었음.

2. "바이브 코딩의 정의 논쟁" (용어 혼란)

  • 논쟁: '바이브 코딩'이 단순히 AI의 도움을 받는 것인지, 아니면 생성된 코드를 검토하지 않고 결과만 확인하는 것인지에 대한 정의가 분분함.
  • 합의점: 원래는 '코드 미검토'를 뜻하는 부정적 뉘앙스였으나, 현재는 AI 보조 코딩 전반을 가리키는 용어로 의미가 확장됨.

3. "검증 없는 속도는 기술 부채" (신중파)

  • 비판: 코드를 이해하지 못한 채 AI가 생성한 결과물만 믿는 것은 위험함. 나중에 발생할 버그나 유지보수 비용(기술 부채)이 더 클 것임.
  • 비유: "운전자가 어디로 가는지 모르고 자율주행차에 탄 꼴"이라며, 이해 없는 구현은 결국 문제 해결 능력을 떨어뜨림.

4. "문맥 전환의 피로감" (공감파)

  • 동의: AI가 코드를 생성하는 동안 잦은 문맥 전환(Context Switching)이 발생하여 뇌의 인지 부하가 급증함.
  • 증상: AI의 결과물을 검토하고 수정하는 과정이 반복되면서, 직접 코딩할 때보다 정신적 소모가 큼. 4시간 작업이 하루 종일 일한 것처럼 피곤함.

5. "코딩의 즐거움 상실" (도파민 부족)

  • 경험: 직접 문제를 해결했을 때의 성취감(도파민)이 사라짐. 레고를 직접 조립하는 재미 대신 완성품만 보는 느낌이라 허무함.
  • 결과: 과정의 즐거움 없이 결과물만 빠르게 내놓는 작업은 개발자를 지치게 만듦.

6. "초보자에겐 독, 숙련자에겐 약" (숙련도별 차이)

  • 분석: 숙련된 개발자는 AI의 실수를 빠르게 캐치하고 수정할 수 있어 생산성이 높지만, 초보자는 잘못된 코드를 그대로 사용하여 학습 기회를 잃고 엉터리 코드를 양산할 위험이 큼.

7. "관리자 역할로의 강제 전환" (역할 변화)

  • 현상: 개발자가 직접 코드를 작성하는 '창작자'에서, AI가 쏟아내는 코드를 검토하고 수정하는 '관리자/리뷰어'로 역할이 강제 전환됨.
  • 부담: 5명의 주니어 개발자(AI)가 짠 코드를 혼자서 실시간으로 리뷰하는 것과 같은 극심한 스트레스를 유발함.

8. "비즈니스 로직 이해의 부재" (한계 지적)

  • 문제: AI는 코드는 잘 짜지만 비즈니스 맥락이나 전체 아키텍처는 이해하지 못함.
  • 현실: 결국 비즈니스 요구사항을 코드에 맞게 조율하고, 엣지 케이스를 처리하는 복잡한 작업은 여전히 인간의 몫이며, 이 과정에서 병목 현상이 발생함.

9. "휴식과 여유의 실종" (기계 시간)

  • 비유: 과거 공장 노동자가 기계 속도에 맞춰 일했던 것처럼, AI의 빠른 생성 속도에 인간이 끌려다니는 '기계 시간'에 갇힘.
  • 필요성: 컴파일 대기 시간 같은 '강제 휴식'이 사라져, 뇌가 정보를 처리하고 쉴 틈이 없음. 의도적인 휴식이 필수적임.

10. "도구의 과도기적 문제" (미래 전망)

  • 진단: 현재의 피로감은 AI 생성 속도에 비해 검증 도구(테스트, 린트 등)가 따라가지 못해 발생하는 불일치 때문임.
  • 해결책: 생성 속도만큼 검증을 자동화하는 도구가 발전하면 피로감 문제는 해결될 수 있음.

보기 굉장히 편합니다~ 감사합니다.

혹시, 제목이나 내용으로도 검색할 수 있을까요?
원하는 기사를 다시 찾으려 할 때 기사 제목을 떠올리곤 하는데, 기사 제목의 단어로 검색하는 것으로 안 되는 경우들이 많이 보여 건의 드립니다.

1. 형식에 대한 호불호 ("링크드인 감성인가?")

  • 비판 우세: 문장마다 줄을 바꾼 형식이 '링크드인 인플루언서의 겉멋 든 글' 혹은 'AI가 생성한 텍스트' 같다는 혹평이 다수. 내용 없이 포장만 요란하다는 지적.
  • 일부 옹호: 현대인의 짧은 집중력을 고려한 가독성 높은 배치거나, 시적 운율을 의도한 문체라는 의견.

2. '두터운 욕망' 실천 간증

  • 성공 사례: 조각(sculpting), 아날로그 회로 설계, 엽서 쓰기 등 물리적이고 시간이 걸리는 취미를 통해 우울감을 극복하고 삶의 밀도를 채운 경험 공유.
  • 빵 굽기 논쟁: 본문의 '비효율적인 빵 굽기' 예시에 대해, 엔지니어들이 오븐을 이용한 '발효 시간 최적화' 팁을 공유하며 역설적인 서브 토론 발생.

3. 철학적·종교적 기원 분석

  • 오래된 지혜의 리브랜딩: 불교의 '아귀(Hungry Ghosts)' 개념이나 서양 철학의 고전적 주제(아우구스티누스 등)를 현대적 용어(Thin/Thick)로 재포장했을 뿐이라는 평.
  • 통찰의 유효성: 새로운 내용은 아니지만, 현대 사회에 맞게 잘 정리된 통찰이라는 점에는 동의.

4. 이분법적 논리의 한계

  • 개념의 단순화 경계: '소비=얄팍함, 창작=두터움'이라는 도식은 위험함. 깊이 있는 독서(소비)도 두터울 수 있고, 상업적 창작도 얄팍할 수 있음.
  • 휴식의 가치: 멍때리기나 게임 등 '얄팍해 보이는' 활동도 회복을 위해 필요한 휴식일 수 있음을 간과했다는 지적.

5. 구조적·환경적 원인 지적

  • 개인 탓이 아님: IT 기업들이 의도적으로 설계한 도파민 보상 체계(System)가 근본 문제임.
  • 현실적 제약: "우리는 이미 풍요롭다"는 전제에 반박. 주거비, 의료비 등 생존의 위협(경제적 빈곤) 때문에 여유 있는 '두터운 욕망'을 추구하기 힘든 현실 호소.

흰건 코드요 검은건 터미널이다 같은 문맹 상태이지 않을까요? 로그 볼 줄 모르거나 복붙 없으면 전혀 개발 못하는 상태랑 마찬가지로요

이 글이 Part 1 examined why senior engineers leave이고 Part 2 The Economic Intervention That Stops Engineer Attrition 글도 있네요.

https://codegood.co/writing/…

어제도 맥 전체 용량 확보(클로드에게 알아서 지우라고 함) 매우 편하다는 페북 게시물을 봤는데 말이죠...

임원이 이글을 볼 수 잇게 못할까..

https://modelcontext.cloud/orgs/test/…

이용약관에 개발 주소가 노출되고 있습니다.

전 이런거 볼때 그냥 툴의 시스템 프롬프트의 중요성을 봅니다. 현재 커서에서 사용할때 개인적으로는 opus >= gpt 5.2 > gemini 3 라고 생각합니다. 그 외 소넷이니 5.1이니... 개인적으로는 더이상 사용하지 않습니다. 다만.. gpt5.2는 effort별 처이가 심합니다.. 근데 항상 높은 effort가 좋지만은 않더라고요.. 그래서 opus랑 gemini를 주력으로 사용하게 됩니다. 가끔 난제를 만나면 3개 모두에게 코딩 시키고 서로서오 코드 평가하게 한 후 제가 확인하고 적용시킵니다.

--dangerously-skip-permissions를 샌드박스 환경에서 돌리지 않는 사람들이 참 많은것 같습니다. danger의 의미를 모르는 걸까요 ㅠㅠ