지난 주에 소프트웨어 개발자로서 너무 부끄러운 실수를 했습니다. 비슷한 일이 오픈소스 생태계에서 다시는 일어나지 않기를 바라는 마음으로 제가 겪은 경험과 그 과정에서 뉘우친 점을 공유합니다. 이 글이 AI 코딩 도구를 사용하는 분들께 작은 경각심이라도 되었으면 좋겠습니다.

프로젝트에서 오픈소스 라이브러리를 사용하다가 문제가 발생했습니다. Claude Code에게 물어봤더니 라이브러리 자체의 문제라며, 원인 분석부터 재현 코드, 버그 수정과 테스트 코드까지 순식간에 만들어주더군요. AI의 능력에 감탄하며 그 내용을 의심없이 그대로 해당 라이브러리 저장소에 이슈와 PR로 올렸습니다. AI가 없던 시절에는 이런 문제가 발생하면 며칠씩 쩔쩔매고는 했는데, 시간을 크게 절약한 것 같아 흐뭇하기까지 했습니다.

하지만 다음 날 메인테이너로부터 전혀 예상하지 못한 답변을 받았습니다. 제가 올린 이슈의 코드가 실행조차 되지 않는다는 것이었습니다. 코드를 고쳐 실행해봐도 버그는 전혀 재현되지 않는다는 내용이었습니다. 놀란 마음으로 제가 올린 코드를 직접 실행해보니 컴파일조차 되지 않더군요. 제가 얼마나 어처구니없는 일을 저지른 건지... 눈앞이 캄캄해졌습니다.

결국 저는 AI가 만들어낸 허위 버그를 사실처럼 올린 셈이었고, 메인테이너분께서는 그것을 확인하고 환각임을 밝혀내느라 많은 시간을 허비해야 했습니다. 하필이면 갓 태어난 아이와 시간을 보내야 하는 중요한 시기셨는데, 제 무책임한 기여가 그 귀한 시간을 앗아가고 말았습니다.

같은 아빠로서 그 마음이 어떤지 알기에 더욱 죄송스러웠고, 오랫동안 오픈소스의 가치를 지지해온 개발자로서 쥐구멍에라도 숨고 싶었습니다. 오픈소스 생태계에 도움이 되기는커녕 오히려 피해를 드리는 행동을 저지르고 말았다는 사실에 일주일 내내 마음이 무거웠습니다. 그래서 저의 잘못을 숨기기보다 이렇게 공유하고 용서를 구하는 것이 제가 할 수 있는 최소한의 도리라 느꼈습니다.

돌이켜보면 저는 여러 함정에 빠졌습니다. AI가 확신에 찬 어조로 "버그는 여기서 발생하고 해결책은 이겁니다"라고 단언하기에 저도 모르게 그냥 믿게 되었습니다. 제가 해당 라이브러리의 내부를 잘 모르다보니 오히려 AI를 더 신뢰했던 것 같습니다. 게다가 AI가 작성해준 코드와 테스트는 너무 그럴듯해 보였고 "설마 틀리겠어?"라는 안일함이 생겼습니다. 제가 몇 분만 썼으면 사전에 검증하고 충분히 예방할 수 있던 일인데, 결국 제 무책임함으로 메인테이너의 수십 분을 낭비하게 만들었습니다.

저는 메인테이너분께 제 과오를 있는 그대로 설명하고 사과드렸고, 오히려 솔직하게 인정해줘서 고맙다며 제 사과를 받아주셨습니다. 하지만 저는 정말 운이 좋았을 뿐, 사실 더 많은 질책과 비판을 받아도 할 말이 없는 무례를 범했다고 생각합니다. 모든 메인테이너가 이렇게 너그럽기를 기대할 수도 없고, 그래야 할 의무도 없습니다. 이와 같은 일 하나로 오픈소스 생태계에 부정적인 영향을 줄 수도 있다고 생각합니다.

오픈소스는 누군가의 자발적인 선의와 제한된 시간을 모아 쌓아올린 신뢰 기반의 생태계입니다. 이슈나 PR이 올라오면 메인테이너는 "이 사람이 최소한의 검증은 했겠지"라는 믿음으로 시간을 투자합니다. 코드 리뷰도, 피드백도, 모두 기여자가 진지하게 노력했다는 전제 아래 이루어집니다. 그런데 AI 도구가 몇 초 만에 그럴듯한 이슈와 PR을 만들어내면서 이 신뢰가 흔들리고 있습니다. 무책임한 기여가 만들어낸 잡음을 걸러내는 데 낭비되는 시간은 메인테이너에게 큰 기회비용이며 프로젝트에도 손실을 초래합니다. 이런 경험이 반복되면, 안 그래도 열악한 환경에서 헌신하고 있는 메인테이너들은 더욱 지칠 수밖에 없고, 결국 오픈소스 생태계 전체가 약해질 것입니다.

AI 코딩 도구는 분명 강력합니다. 하지만 그 강력함이 검증 없이 사용될 때 누군가에게 피해로 돌아갈 수 있다는 사실을 이번에 깊이 깨달았습니다. AI를 맹신하는 순간 개발자로서의 역할을 소홀히 하게 되고, 그 피해는 결국 다른 사람에게 전가될 수 있습니다. 이번 일을 계기로, AI가 코드를 대신 써줄 수는 있어도 책임만큼은 끝까지 인간의 몫이라는 사실을 절대 잊지 않으려 합니다.

이번 일로 불쾌함과 좌절감을 느끼셨을 메인테이너분께 다시 한번 진심으로 사과드립니다. 또한 리뷰할 가치조차 없는 제 PR에 소중한 시간을 내어 따끔한 피드백을 남겨주신 점도 깊이 감사드립니다. 개발자로서 다시는 이런 무책임한 실수를 반복하지 않겠습니다.

여러분, AI를 사용하는 것은 개발자의 자유이지만 그 결과로 발생하는 영향에 대한 책임은 온전히 우리에게 있습니다. 오픈소스에 기여하실 때 AI가 만들어낸 코드는 반드시 스스로 검증하시고, 메인테이너의 시간을 절대 가볍게 여기지 말아주세요. 함께 노력해 더 건강하고 성숙한 오픈소스 생태계를 지켜나갔으면 좋겠습니다.

지난 주에 소프트웨어 개발자로서 너무 부끄러운 실수를 했습니다. 비슷한 일이 오픈소스 생태계에서 다시는 일어나지 않기를 바라는 마음으로 제가 겪은 경험과 그 과정에서 뉘우친 점을 공유합니다. 이 글이 AI 코딩 도구를 사용하는 분들께 작은 경각심이라도 되었으면 좋겠습니다. 프로젝트에서 오픈소스 라이브러리를 사용하다가 문제가 발생했습니다. Claude Code에게 물어봤더니 라이브러리 자체의 문제라며, 원인 분석부터 재현 코드, 버그 수정과 테스트 코드까지 순식간에 만들어주더군요. AI의 능력에 감탄하며 그 내용을 의심없이 그대로 해당 라이브러리 저장소에 이슈와 PR로 올렸습니다. AI가 없던 시절에는 이런 문제가 발생하면 며칠씩 쩔쩔매고는 했는데, 시간을 크게 절약한 것 같아 흐뭇하기까지 했습니다. 하지만 다음 날 메인테이너로부터 전혀 예상하지 못한 답변을 받았습니다.&nbsp;제가 올린 이슈의 코드가 실행조차 되지 않는다는 것이었습니다. 코드를 고쳐 실행해봐도 버그는 전혀 재현되지 않는다는 내용이었습니다. 놀란 마음으로 제가 올린 코드를 직접 실행해보니 컴파일조차 되지 않더군요. 제가 얼마나 어처구니없는 일을 저지른 건지... 눈앞이 캄캄해졌습니다. 결국 저는 AI가 만들어낸 허위 버그를 사실처럼 올린 셈이었고, 메인테이너분께서는 그것을 확인하고 환각임을 밝혀내느라 많은 시간을 허비해야 했습니다. 하필이면 갓 태어난 아이와 시간을 보내야 하는 중요한 시기셨는데, 제 무책임한 기여가 그 귀한 시간을 앗아가고 말았습니다. 같은 아빠로서 그 마음이 어떤지 알기에 더욱 죄송스러웠고, 오랫동안 오픈소스의 가치를 지지해온 개발자로서 쥐구멍에라도 숨고 싶었습니다. 오픈소스 생태계에 도움이 되기는커녕 오히려 피해를 드리는 행동을 저지르고 말았다는 사실에 일주일 내내 마음이 무거웠습니다. 그래서 저의 잘못을 숨기기보다 이렇게 공유하고 용서를 구하는 것이 제가 할 수 있는 최소한의 도리라 느꼈습니다. 돌이켜보면 저는 여러 함정에 빠졌습니다. AI가 확신에 찬 어조로 "버그는 여기서 발생하고 해결책은 이겁니다"라고 단언하기에 저도 모르게 그냥 믿게 되었습니다. 제가 해당 라이브러리의 내부를 잘 모르다보니 오히려 AI를 더 신뢰했던 것 같습니다. 게다가 AI가 작성해준 코드와 테스트는 너무 그럴듯해 보였고 "설마 틀리겠어?"라는 안일함이 생겼습니다. 제가 몇 분만 썼으면 사전에 검증하고 충분히 예방할 수 있던 일인데, 결국 제 무책임함으로 메인테이너의 수십 분을 낭비하게 만들었습니다. 저는 메인테이너분께 제 과오를 있는 그대로 설명하고 사과드렸고, 오히려 솔직하게 인정해줘서 고맙다며 제 사과를 받아주셨습니다. 하지만 저는 정말 운이 좋았을 뿐, 사실 더 많은 질책과 비판을 받아도 할 말이 없는 무례를 범했다고 생각합니다. 모든 메인테이너가 이렇게 너그럽기를 기대할 수도 없고, 그래야 할 의무도 없습니다. 이와 같은 일 하나로 오픈소스 생태계에 부정적인 영향을 줄 수도 있다고 생각합니다. 오픈소스는 누군가의 자발적인 선의와 제한된 시간을 모아 쌓아올린 신뢰 기반의 생태계입니다.&nbsp;이슈나 PR이 올라오면 메인테이너는 "이 사람이 최소한의 검증은 했겠지"라는 믿음으로 시간을 투자합니다. 코드 리뷰도, 피드백도, 모두 기여자가 진지하게 노력했다는 전제 아래 이루어집니다. 그런데 AI 도구가 몇 초 만에 그럴듯한 이슈와 PR을 만들어내면서 이 신뢰가 흔들리고 있습니다. 무책임한 기여가 만들어낸 잡음을 걸러내는 데 낭비되는 시간은 메인테이너에게 큰 기회비용이며 프로젝트에도 손실을 초래합니다. 이런 경험이 반복되면, 안 그래도 열악한 환경에서 헌신하고 있는 메인테이너들은 더욱 지칠 수밖에 없고, 결국 오픈소스 생태계 전체가 약해질 것입니다. AI 코딩 도구는 분명 강력합니다. 하지만 그 강력함이 검증 없이 사용될 때 누군가에게 피해로 돌아갈 수 있다는 사실을 이번에 깊이 깨달았습니다. AI를 맹신하는 순간 개발자로서의 역할을 소홀히 하게 되고, 그 피해는 결국 다른 사람에게 전가될 수 있습니다. 이번 일을 계기로, AI가 코드를 대신 써줄 수는 있어도 책임만큼은 끝까지 인간의 몫이라는 사실을 절대 잊지 않으려 합니다. 이번 일로 불쾌함과 좌절감을 느끼셨을 메인테이너분께 다시 한번 진심으로 사과드립니다. 또한 리뷰할 가치조차 없는 제 PR에 소중한 시간을 내어 따끔한 피드백을 남겨주신 점도 깊이 감사드립니다. 개발자로서 다시는 이런 무책임한 실수를 반복하지 않겠습니다. 여러분, AI를 사용하는 것은 개발자의 자유이지만 그 결과로 발생하는 영향에 대한 책임은 온전히 우리에게 있습니다.&nbsp;오픈소스에 기여하실 때 AI가 만들어낸 코드는 반드시 스스로 검증하시고, 메인테이너의 시간을 절대 가볍게 여기지 말아주세요. 함께 노력해 더 건강하고 성숙한 오픈소스 생태계를 지켜나갔으면 좋겠습니다.

반성문: 저는 AI를 맹신하여 오픈소스에 피해를 끼쳤습니다.

1. 일에는 두 종류가 있다. 실행하면 원하는 결과를 바로 얻을 수 있는 일, 그리고 여러 일들의 결과가 모여야 비로소 가치가 만들어지는 일. 회사에서 우리가 하는 일 대부분은 후자다.

2. 팀은 언제나 개인보다 크다. 혼자서는 만들 수 없는 결과를 팀은 만들어낸다. 그게 조직이 존재하는 이유다. 다른 사람들의 결과와 내 일이 맞물릴 때 우리는 더 큰 성과를 만든다.

3. 그렇다면 복잡한 일들 사이의 관계는 어떻게 바라봐야 할까. ‘인과관계’와 ‘상관관계’로 나눠볼 수 있다.

4. 인과관계는 원인과 결과가 명확하게 연결된 구조다. 콩을 심으면 콩이 나는 것처럼, 반복하면 같은 결과를 얻는 공식이 있다. 누가 해도 재현된다. 하지만 현실에서는 이런 관계가 생각보다 드물다.

5. 상관관계는 두 사건이 연관은 있어 보이지만, 명확히 설명하기 어려운 관계다. 반복해도 결과가 조금씩 달라지고, 때로는 원인과 결과가 뒤바뀌기도 한다. 우리가 다루는 대부분의 일이 여기에 가깝다. 그래서 어렵다.

6. 일의 결과를 측정하는 지표 역시 ‘선행지표’와 ‘후행지표’로 나눌 수 있다. 선행은 앞서가고 후행은 따라온다. 둘 사이가 명확한 인과라면 선행지만 움직여도 원하는 결과를 만들 수 있다. 문제는 그 공식을 찾기 어렵다는 점이다.

7. 동시에 어떤 지표들은 상관관계이기도 하다. 연관은 있어 보이지만 명확한 공식은 없다. 선행이 후행을 움직이는 것 같지만 확신할 만큼은 아니다. 까마귀 날자 배 떨어지는 식으로 우리의 판단이 빗나갈 수도 있다.

8. 새해를 맞아 다이어트를 한다고 해보자. 3개월 동안 5킬로그램 감량이 목표다. 주 3회 헬스장에서 30분씩 달리기로 정했다. 3개월 뒤 몸무게는 얼마나 변할까.

9. 일주일 3회와 30분은 선행지표다. 내가 직접 실행할 수 있는 부분이다. 몸무게는 그 뒤를 따라오는 후행지표다. 우리는 운동이 체중 감량에 도움을 준다는 걸 경험적으로 안다. 다만 매번 같은 결과가 나오진 않는다. 명확한 인과는 모르지만 상관은 존재한다.

10. 현실에서는 변수가 더 추가된다. 대표적으로 식단이다. 섭취 칼로리를 또 하나의 선행지표로 정의해보자. 이제 선행지표가 둘이 되었고, 몸무게와의 관계는 더 복잡해졌다. 하지만 둘이 같은 방향으로 움직이면 목표에 가까워지는 건 분명하다.

11. 결국 원하는 결과를 얻으려면 선행지표에 집중해야 한다. 주 3회 30분 달리고, 섭취 칼로리를 줄이는 실행이 쌓여야 몸무게가 줄어든다. 반면 “5킬로그램만 빠져라” 하고 바라보는 것만으로는 아무 변화도 없다. 기업의 가장 후행지표인 수익도 마찬가지다. 수익을 바라보는 것만으로는 달라지지 않는다. 거래액, 매출, 비용 같은 앞단의 지표를 움직여야 한다.

12. 알고도 잘 안 되는 이유는 대부분 실행 문제다. 다이어트와 같다. 구조는 단순하지만 실행과 의지는 어렵다. 우리의 일은 구조를 찾는 것조차 쉽지 않다. 변수도 많다. 그럼에도 방법은 단순하다. 결국 실행이 답이다.

13. 직접 만들 수 있는 작은 결과들이 궁극적인 결과를 만든다. 목표를 정하고, 필요한 일을 정의하고, 그 일을 잘게 나누고, 순서를 정해 하나씩 실행한다. 작은 실행들이 모여 큰 결과를 만든다.

1. 일에는 두 종류가 있다. 실행하면 원하는 결과를 바로 얻을 수 있는 일, 그리고 여러 일들의 결과가 모여야 비로소 가치가 만들어지는 일. 회사에서 우리가 하는 일 대부분은 후자다. 2. 팀은 언제나 개인보다 크다. 혼자서는 만들 수 없는 결과를 팀은 만들어낸다. 그게 조직이 존재하는 이유다. 다른 사람들의 결과와 내 일이 맞물릴 때 우리는 더 큰 성과를 만든다. 3. 그렇다면 복잡한 일들 사이의 관계는 어떻게 바라봐야 할까. ‘인과관계’와 ‘상관관계’로 나눠볼 수 있다. 4. 인과관계는 원인과 결과가 명확하게 연결된 구조다. 콩을 심으면 콩이 나는 것처럼, 반복하면 같은 결과를 얻는 공식이 있다. 누가 해도 재현된다. 하지만 현실에서는 이런 관계가 생각보다 드물다. 5. 상관관계는 두 사건이 연관은 있어 보이지만, 명확히 설명하기 어려운 관계다. 반복해도 결과가 조금씩 달라지고, 때로는 원인과 결과가 뒤바뀌기도 한다. 우리가 다루는 대부분의 일이 여기에 가깝다. 그래서 어렵다. 6. 일의 결과를 측정하는 지표 역시 ‘선행지표’와 ‘후행지표’로 나눌 수 있다. 선행은 앞서가고 후행은 따라온다. 둘 사이가 명확한 인과라면 선행지만 움직여도 원하는 결과를 만들 수 있다. 문제는 그 공식을 찾기 어렵다는 점이다. 7. 동시에 어떤 지표들은 상관관계이기도 하다. 연관은 있어 보이지만 명확한 공식은 없다. 선행이 후행을 움직이는 것 같지만 확신할 만큼은 아니다. 까마귀 날자 배 떨어지는 식으로 우리의 판단이 빗나갈 수도 있다. 8. 새해를 맞아 다이어트를 한다고 해보자. 3개월 동안 5킬로그램 감량이 목표다. 주 3회 헬스장에서 30분씩 달리기로 정했다. 3개월 뒤 몸무게는 얼마나 변할까. 9. 일주일 3회와 30분은 선행지표다. 내가 직접 실행할 수 있는 부분이다. 몸무게는 그 뒤를 따라오는 후행지표다. 우리는 운동이 체중 감량에 도움을 준다는 걸 경험적으로 안다. 다만 매번 같은 결과가 나오진 않는다. 명확한 인과는 모르지만 상관은 존재한다. 10. 현실에서는 변수가 더 추가된다. 대표적으로 식단이다. 섭취 칼로리를 또 하나의 선행지표로 정의해보자. 이제 선행지표가 둘이 되었고, 몸무게와의 관계는 더 복잡해졌다. 하지만 둘이 같은 방향으로 움직이면 목표에 가까워지는 건 분명하다. 11. 결국 원하는 결과를 얻으려면 선행지표에 집중해야 한다. 주 3회 30분 달리고, 섭취 칼로리를 줄이는 실행이 쌓여야 몸무게가 줄어든다. 반면 “5킬로그램만 빠져라” 하고 바라보는 것만으로는 아무 변화도 없다. 기업의 가장 후행지표인 수익도 마찬가지다. 수익을 바라보는 것만으로는 달라지지 않는다. 거래액, 매출, 비용 같은 앞단의 지표를 움직여야 한다. 12. 알고도 잘 안 되는 이유는 대부분 실행 문제다. 다이어트와 같다. 구조는 단순하지만 실행과 의지는 어렵다. 우리의 일은 구조를 찾는 것조차 쉽지 않다. 변수도 많다. 그럼에도 방법은 단순하다. 결국 실행이 답이다. 13. 직접 만들 수 있는 작은 결과들이 궁극적인 결과를 만든다. 목표를 정하고, 필요한 일을 정의하고, 그 일을 잘게 나누고, 순서를 정해 하나씩 실행한다. 작은 실행들이 모여 큰 결과를 만든다.

< 일을 잘하는 사람들은 왜 '선행지표'에 집착할까 >

[3부:분석편] AI 시대 QA는 무엇을 대비해야하나?

(Next.js 15/16 app router를 사용한다면 점검이 필요합니다)
최근 공개된 RSC 보안 취약점(CVE-2025-55182)은 단순한 패치 이슈로 끝날 만큼 가벼운 사건은 아니었습니다. 많은 팀이 실제로 영향을 받았고, 그보다 더 중요한 것은 이번 일이 현대 웹 아키텍처가 가진 구조적 위험을 드러냈다는 것입니다.


개발 환경이 편리해질수록 우리는 종종 “프레임워크가 알아서 해주겠지”라고 믿습니다.
하지만 이번 이슈는 그 믿음이 어디까지 유효한지 다시 생각하게 합니다..!


👉 이번 취약점의 핵심 -> 직렬화와 역직렬화가 곧 보안 경계라는 사실
React Server Components는 클라이언트가 서버에 서버 함수를 호출할 수 있도록 Flight 프로토콜을 사용합니다. 클라이언트가 직렬화한 payload를 서버가 역직렬화하여 어떤 함수를 어떻게 실행할지 결정하는 구조입니다.


이 구조가 핵심 문제입니다. 공격자가 조작한 payload를 서버가 정상 호출로 받아들이면서, 인증 없이 원격 코드 실행(RCE)이 가능해졌습니다. Server Action을 직접 만들지 않았더라도, 프레임워크 내부의 RSC 엔드포인트가 노출되어 있다면 공격 가능한 부분이 있었습니다. “우리는 RSC를 크게 쓰지 않는데요?”라고 하더라도, 안전을 보장할 수 없습니다.


영향을 받은 버전 범위
- React 19.0.0~19.2.0
- 이를 기반으로 동작하는 Next.js 15.x / 16.x(App Router)
- React Router RSC 프리뷰, Waku, Vite RSC plugin 등 RSC를 구현한 도구들 전반


위 버전을 사용하고 있거나, 서버에서 RSC 또는 Server Actions를 사용하고 있다 에
해당된다면 즉시 패치하는 것이 가장 현실적인 대응입니다.
(패치는 React 19.0.1 / 19.1.2 / 19.2.1, Next.js는 15.0.5+ 혹은 16.0.7 이상에서 제공됩니다.)


저는 이 사건을 보면서 개발 방식에 대해 몇 가지 생각을 다시 정리하게 되었습니다.
첫째, 추상화 뒤에 무엇이 있는지, 어떻게 동작하는지 이해하지 못하면, 결국 리스크 관리에 실패한다는 것입니다. Server Actions는 생산성을 극적으로 높이지만, 그 내부는 결국 RPC 구조이며, 직렬화 포맷과 역직렬화 로직이 공격 포인트가 될 수 있습니다. 이는 일반적으로 추상화 되어있기에 신뢰하며 보안 취약점에서 놓치기 쉬운 부분입니다.


둘째, 보안은 기능의 문제가 아니라 구조의 문제입니다. 어떤 코드가 실행되느냐보다, 그 코드가 어떻게 선택되고, 어떻게 검증되는지가 훨씬 중요합니다.


셋째, AI가 구현을 대신하는 시대일수록 개발자의 역할은 더욱 설계로 이동한다는 점입니다. 구현 자체는 자동화될수록 쉬워지지만, 구조를 읽고 판단하는 능력은 오히려 더 중요해지고 있습니다.


이번 보안 이슈는 단순한 버그라기보다, 우리가 기술을 선택할 때 어떤 관점으로 봐야 하는지 다시 생각하게 하는 사건이었습니다. 프레임워크가 많은 것을 대신해주는 시대지만, 결국 개발자가 구조를 이해하고 있느냐가 중요합니다.
여러분은 이번 사건을 어떻게 바라보고 계신가요? 프레임워크의 추상화를 어디까지 신뢰할 수 있다고 생각하시나요? 그리고 AI가 구현을 대신하는 시대에, 개발자는 어떤 위치에서 설계를 바라봐야 할까요? 여러분의 생각이 궁금합니다..!

(Next.js 15/16 app router를 사용한다면 점검이 필요합니다)최근 공개된 RSC 보안 취약점(CVE-2025-55182)은 단순한 패치 이슈로 끝날 만큼 가벼운 사건은 아니었습니다. 많은 팀이 실제로 영향을 받았고, 그보다 더 중요한 것은 이번 일이 현대 웹 아키텍처가 가진 구조적 위험을 드러냈다는 것입니다. 개발 환경이 편리해질수록 우리는 종종 “프레임워크가 알아서 해주겠지”라고 믿습니다.하지만 이번 이슈는 그 믿음이 어디까지 유효한지 다시 생각하게 합니다..! 👉 이번 취약점의 핵심 -&gt; 직렬화와 역직렬화가 곧 보안 경계라는 사실React Server Components는 클라이언트가 서버에 서버 함수를 호출할 수 있도록 Flight 프로토콜을 사용합니다. 클라이언트가 직렬화한 payload를 서버가 역직렬화하여 어떤 함수를 어떻게 실행할지 결정하는 구조입니다. 이 구조가 핵심 문제입니다. 공격자가 조작한 payload를 서버가 정상 호출로 받아들이면서, 인증 없이 원격 코드 실행(RCE)이 가능해졌습니다. Server Action을 직접 만들지 않았더라도, 프레임워크 내부의 RSC 엔드포인트가 노출되어 있다면 공격 가능한 부분이 있었습니다. “우리는 RSC를 크게 쓰지 않는데요?”라고 하더라도, 안전을 보장할 수 없습니다. 영향을 받은 버전 범위- React 19.0.0~19.2.0- 이를 기반으로 동작하는 Next.js 15.x / 16.x(App Router)- React Router RSC 프리뷰, Waku, Vite RSC plugin 등 RSC를 구현한 도구들 전반 위 버전을 사용하고 있거나, 서버에서 RSC 또는 Server Actions를 사용하고 있다 에해당된다면 즉시 패치하는 것이 가장 현실적인 대응입니다.(패치는 React 19.0.1 / 19.1.2 / 19.2.1, Next.js는 15.0.5+ 혹은 16.0.7 이상에서 제공됩니다.) 저는 이 사건을 보면서 개발 방식에 대해 몇 가지 생각을 다시 정리하게 되었습니다.첫째, 추상화 뒤에 무엇이 있는지, 어떻게 동작하는지 이해하지 못하면, 결국 리스크 관리에 실패한다는 것입니다. Server Actions는 생산성을 극적으로 높이지만, 그 내부는 결국 RPC 구조이며, 직렬화 포맷과 역직렬화 로직이 공격 포인트가 될 수 있습니다. 이는 일반적으로 추상화 되어있기에 신뢰하며 보안 취약점에서 놓치기 쉬운 부분입니다. 둘째, 보안은 기능의 문제가 아니라 구조의 문제입니다. 어떤 코드가 실행되느냐보다, 그 코드가 어떻게 선택되고, 어떻게 검증되는지가 훨씬 중요합니다. 셋째, AI가 구현을 대신하는 시대일수록 개발자의 역할은 더욱 설계로 이동한다는 점입니다. 구현 자체는 자동화될수록 쉬워지지만, 구조를 읽고 판단하는 능력은 오히려 더 중요해지고 있습니다. 이번 보안 이슈는 단순한 버그라기보다, 우리가 기술을 선택할 때 어떤 관점으로 봐야 하는지 다시 생각하게 하는 사건이었습니다. 프레임워크가 많은 것을 대신해주는 시대지만, 결국 개발자가 구조를 이해하고 있느냐가 중요합니다.여러분은 이번 사건을 어떻게 바라보고 계신가요? 프레임워크의 추상화를 어디까지 신뢰할 수 있다고 생각하시나요? 그리고 AI가 구현을 대신하는 시대에, 개발자는 어떤 위치에서 설계를 바라봐야 할까요? 여러분의 생각이 궁금합니다..!

React Server Components 보안 이슈가 남긴 것들

AI계의 모두의 선생님이라고 불리는 안드레이 카파시가 오늘 매우 유익한 팁을 줬는데요. 이거 매우 중요한 내용이네요. 모두들 두 번 읽어보세용~ ㅎㅎ (의미를 잘 전달하기 위해 약간 의역함)

—

LLM을 어떤 “존재”로 생각하지 말고 시뮬레이터로 생각하세요. 예를 들어, 어떤 주제를 탐구할 때 이렇게 묻지 마세요:

“너는 xyz에 대해 어떻게 생각해?”

“너”라는 존재는 없습니다. 대신에 이렇게 시도해보세요:

“어떤 그룹이 xyz를 탐구하기에 좋은 사람들일까? 그들은 뭐라고 할까?”

LLM은 다양한 관점을 전달/시뮬레이션할 수 있지만, xyz에 대해 오랜 시간 스스로 “생각해본” 적이 없고, 자신의 의견을 형성한 것도 아닙니다.

따라서 질문에 “너”라는 표현으로 강제하면, 파인튜닝 데이터의 통계에 암시된 특정 페르소나 임베딩 벡터를 채택해 그걸 시뮬레이션 할 뿐입니다.

그렇게 물어봐도 괜찮지만, 사람들이 “AI에게 묻는다”는 것에 부여하는 신비함은 사실 생각보다 훨씬 덜합니다.

AI계의 모두의 선생님이라고 불리는 안드레이 카파시가 오늘 매우 유익한 팁을 줬는데요. 이거 매우 중요한 내용이네요. 모두들 두 번 읽어보세용~ ㅎㅎ (의미를 잘 전달하기 위해 약간 의역함) — LLM을 어떤 “존재”로 생각하지 말고 시뮬레이터로 생각하세요. 예를 들어, 어떤 주제를 탐구할 때 이렇게 묻지 마세요: “너는 xyz에 대해 어떻게 생각해?” “너”라는 존재는 없습니다. 대신에 이렇게 시도해보세요: “어떤 그룹이 xyz를 탐구하기에 좋은 사람들일까? 그들은 뭐라고 할까?” LLM은 다양한 관점을 전달/시뮬레이션할 수 있지만, xyz에 대해 오랜 시간 스스로 “생각해본” 적이 없고, 자신의 의견을 형성한 것도 아닙니다. 따라서 질문에 “너”라는 표현으로 강제하면, 파인튜닝 데이터의 통계에 암시된 특정 페르소나 임베딩 벡터를 채택해 그걸 시뮬레이션 할 뿐입니다. 그렇게 물어봐도 괜찮지만, 사람들이 “AI에게 묻는다”는 것에 부여하는 신비함은 사실 생각보다 훨씬 덜합니다.

AI계의 모두의 선생님이라고 불리는 안드레이 카파시가 오늘 매우 

그 힘을 키우려면 ‘통합 시너지’를 반드시 만들어야 합니다 | 아래 글은 2025년 12월 03일에 발행된 뉴스레터에 실린 글입니다. 전체 뉴스레터를 보시려면 옆의 링크를 클릭하시면 됩니다. [뉴스레터 보러 가기]  처음에 큰 기대 없이 방문했던 건  성수, 트렌드, 그리고 편의점. 이마트24의 첫 플래그십 매장 ‘트렌드랩 성수점’을 설명하는 키워드들입니다. 처음 들었을 때 솔직한 감정은 “참 기대가 안 된다”였죠. 

이마트24의 미래, 트렌드보다 ‘상품’ 아닐까?

1. 성수, 트렌드, 편의점의 만남? 이마트24 첫 플래그십 ‘트렌드랩 성수점’이라는 말을 처음 들었을 때 솔직히 기대가 안 됐음


2. 그간 편의점에 트렌드를 접목하려는 시도는 많았지만 점포 전체로 확장하는 데 한계가 있었고, 유행 상품으로 차별화를 노린 시도도 성과가 제한적이었기 때문임


3. 하지만 트렌드랩 성수를 실제로 가보니 이야기가 달랐음. 굿즈 같은 트렌드 요소보다 이마트24만의 단독 상품과 이마트 계열사 협업이 중심에 있었음


4. 예를 들어 한쪽 벽면에는 W컨셉 전용 매대, 주류 코너에는 신세계 L&B 와인 전문가가 고른 ‘BEST 와인 셀렉션’, 냉장 매대에는 신세계푸드의 노하우를 담은 버거가 자리 잡고 있었음


5. 이런 구성은 ‘오직 이마트24에서만 만날 수 있음’이라는 점에서 분명한 매력 포인트임, 더욱이 이는 거대 유통 기업 이마트만이 가능한 그림이라는 점에서 CU나 GS25가 따라하기 어려움


6. 다만 아쉬운 지점도 있음. 새로 선보인 자체 브랜드 ‘옐로우’가 대표적인데, 이마트24의 구조적 약점인 적은 점포 수를 오히려 더 도드라지게 만들기 때문임


7. 작년부터 의욕적으로 도입한 노브랜드의 효과가 제한적이었다는 해석도 있긴 함, 다만 노브랜드로도 풀리지 않던 과제를 인지도가 낮은 신규 PB ‘옐로우’로 풀겠다는 판단은 직관적으로 설득력이 약함


8. 여기서 근본적인 질문이 생김. 이마트 내부 계열사 간 시너지가 충분히 작동하고 있는가임, 흡수·합병된 이마트·이마트에브리데이와 달리, 별도 법인으로 남은 이마트24만 각자도생하는 인상을 줌


9. 이마트24의 미래는 ‘트렌드’가 아니라 ‘상품’이고, 상품의 경쟁력은 ‘계열사 통합’에서 나온다는 점을 기억해야 앞으로 그나마 희망이 있지 않을까?


🥤트렌드라이트 구독하기
https://m.site.naver.com/1Ew5V

1. 성수, 트렌드, 편의점의 만남? 이마트24 첫 플래그십 ‘트렌드랩 성수점’이라는 말을 처음 들었을 때 솔직히 기대가 안 됐음 2. 그간 편의점에 트렌드를 접목하려는 시도는 많았지만 점포 전체로 확장하는 데 한계가 있었고, 유행 상품으로 차별화를 노린 시도도 성과가 제한적이었기 때문임 3. 하지만 트렌드랩 성수를 실제로 가보니 이야기가 달랐음. 굿즈 같은 트렌드 요소보다 이마트24만의 단독 상품과 이마트 계열사 협업이 중심에 있었음 4. 예를 들어 한쪽 벽면에는 W컨셉 전용 매대, 주류 코너에는 신세계 L&amp;B 와인 전문가가 고른 ‘BEST 와인 셀렉션’, 냉장 매대에는 신세계푸드의 노하우를 담은 버거가 자리 잡고 있었음 5. 이런 구성은 ‘오직 이마트24에서만 만날 수 있음’이라는 점에서 분명한 매력 포인트임, 더욱이 이는 거대 유통 기업 이마트만이 가능한 그림이라는 점에서 CU나 GS25가 따라하기 어려움 6. 다만 아쉬운 지점도 있음. 새로 선보인 자체 브랜드 ‘옐로우’가 대표적인데, 이마트24의 구조적 약점인 적은 점포 수를 오히려 더 도드라지게 만들기 때문임 7. 작년부터 의욕적으로 도입한 노브랜드의 효과가 제한적이었다는 해석도 있긴 함, 다만 노브랜드로도 풀리지 않던 과제를 인지도가 낮은 신규 PB ‘옐로우’로 풀겠다는 판단은 직관적으로 설득력이 약함 8. 여기서 근본적인 질문이 생김. 이마트 내부 계열사 간 시너지가 충분히 작동하고 있는가임, 흡수·합병된 이마트·이마트에브리데이와 달리, 별도 법인으로 남은 이마트24만 각자도생하는 인상을 줌 9. 이마트24의 미래는 ‘트렌드’가 아니라 ‘상품’이고, 상품의 경쟁력은 ‘계열사 통합’에서 나온다는 점을 기억해야 앞으로 그나마 희망이 있지 않을까? 🥤트렌드라이트 구독하기https://m.site.naver.com/1Ew5V

브런치

🏪이마트24의 미래, 트렌드보단 '상품'에 있습니다

흔히 일을 하면서 누구나 '눈치를 본다'라고 합니다. 하지만 누군가는 눈치를 잘 보고, 누군가는 못 보더군요. '왜일까?' 고민해보다가 깨달은 것이 있습니다. 그저 자기 중심으로 눈치를 보는가, 아니면 타인을 중심으로 눈치를 보는가의 차이였습니다. 1. 자기 중심적인 눈치 : '저 사람이 또 뭐라고 할까?', '내 아이디어가 반려되면 어쩌지?' 자신만의 생각을 기준으로 상황을 봅니다. 이건 눈치를 보는게 아니라, 그저 '불안'에 가깝습니다. 2. 타인 중심적인 눈치 :'저 사람은 왜 이런 말을 했을까?', '왜 이 아이디어가 반려되었을까?' 상대방의 말 뒤에 숨겨진 실제 의도를 파악하고, 시뮬레이션 하는 능력입니다. 물론 타인에 대한 이해가 부족하다면 실패할 수도 있습니다. 하지만 중요한 건, 후자의 경우 고민하고 경험이 쌓이다 보면 충분히 발전시킬 수 있는 역량이라는 점입니다. 단, 여기에 결정적인 전제조건이 하나 있습니다. "나만의 명확한 기준은 있어야 한다." 요구사항을 분석한다고 고객의 요청을 모두 다 수용하면 프로그램이 누더기가 되는 것처럼, 타인의 맥락을 읽되 내 주관이 없다면 그저 줏대 없는 사람이 될 뿐이니까요. 상대방의 Why를 읽어내고, 나의 기준을 명확히 지키는 것. 그것이 제가 생각하는 '눈치 잘 보는 사람'입니다. 혹시, 여러분은 눈치를 '잘' 보고 계신가요?

흔히 일을 하면서 누구나 '눈치를 본다'라고 합니다. 하지만 누군가는 눈치를 잘 보고, 누군가는 못 보더군요.

'왜일까?'

고민해보다가 깨달은 것이 있습니다. 그저 자기 중심으로 눈치를 보는가, 아니면 타인을 중심으로 눈치를 보는가의 차이였습니다.

1. 자기 중심적인 눈치 : '저 사람이 또 뭐라고 할까?', '내 아이디어가 반려되면 어쩌지?' 자신만의 생각을 기준으로 상황을 봅니다. 이건 눈치를 보는게 아니라, 그저 '불안'에 가깝습니다.

2. 타인 중심적인 눈치 :'저 사람은 왜 이런 말을 했을까?', '왜 이 아이디어가 반려되었을까?' 상대방의 말 뒤에 숨겨진 실제 의도를 파악하고, 시뮬레이션 하는 능력입니다.

물론 타인에 대한 이해가 부족하다면 실패할 수도 있습니다.
하지만 중요한 건, 후자의 경우 고민하고 경험이 쌓이다 보면 충분히 발전시킬 수 있는 역량이라는 점입니다.

단, 여기에 결정적인 전제조건이 하나 있습니다.
"나만의 명확한 기준은 있어야 한다."

요구사항을 분석한다고 고객의 요청을 모두 다 수용하면 프로그램이 누더기가 되는 것처럼, 타인의 맥락을 읽되 내 주관이 없다면 그저 줏대 없는 사람이 될 뿐이니까요.
상대방의 Why를 읽어내고, 나의 기준을 명확히 지키는 것. 그것이 제가 생각하는 '눈치 잘 보는 사람'입니다.

혹시, 여러분은 눈치를 '잘' 보고 계신가요?

눈치를 잘 본다는건 뭘까요?

* 몇몇 분들께서 1:1 메시지를 통해 질문사항을 보내주시곤 합니다. 그중 같이 한번 이야기해 보면 좋겠다 싶은 내용들을 추려서 Q&A로 다뤄보고자 합니다. 몇 편의 시리즈가 될지는 모르겠지만 우선은 제 생각을 성심성의껏 적어봅니다.

01. DM을 통해 제게 질문을 주신 분은 플랫폼 기업에서 9년 차 콘텐츠 기획자로 일하고 계신다고 하셨습니다. 사회에 첫발을 딛일 때부터 기획자였고, 지금도 기획자고, 앞으로도 아마 기획 일을 계속할 것 같다고 하셨죠. 
하지만 오래 일해오며 나름 스스로를 다독이는 법을 터득했다고 해도 쉽게 적응이 안 되는 영역이 있다고 하셨습니다. 질문의 원문 그대로를 옮겨보면 이렇습니다.

02. " 연차가 높아도 여전히 부정적인 피드백은 당황스럽습니다. 특히 제가 기획한 것들에 대해 부정적인 피드백이 오면 더 그렇습니다. 단순히 기분이 나빠서 그런 것은 아닙니다. 오히려 피드백이 너무 크게 느껴져서 자신감이 바닥으로 떨어지는 느낌입니다. 정답이 없는 콘텐츠 분야에서 일하고 있기 때문에 그런 건지 순전히 제 문제인지 헷갈립니다. 상대방이 강한 어조나 불편한 워딩을 쓰면 이 또한 커버가 잘 안됩니다. 
기획자로 일하시면서 부정적인 피드백은 어떻게 극복하시는 지가 궁금합니다. "

03. 일단 결론부터 말씀드리면 저도 극복을 잘 못합니다... 제가 이 질문을 받고 크게 공감한 포인트가 있는데요. '내가 기획한 것에 대한 부정적인 피드백이 더 크게 느껴진다'라는 것이 바로 그 대목입니다. 
저 역시 그런 것 같아요. 소위 제가 기획한 것이 여지없이 까이거나 아예 방향성을 부정당하면 그 느낌은 꽤 처참합니다. 시간이 해결해 주는 경우도 있고 얼른 수정해서 최대한 좀 빠르게 만회하는 방법도 있지만 그게 근본적인 해결책은 아니죠. 

04. 그런데 이렇게 생각해 볼 필요는 분명히 있다고 봅니다. 지금 나에게 피드백 주는 사람에게서 팩트만 걸러낼 수 있는가를 고민하는 거죠. 전 부정적인 피드백이 우리에게 주는 데미지가 더 커지는 이유는 결국 누가 전달하느냐에 대한 차이가 매우 크다고 생각하거든요. 같은 말이라도 충분히 상대방을 배려해 개선점 위주로만 던지는 A라는 사람이 있고, 개선점 하나에 자기감정 아홉 개를 실어서 미사일처럼 날리는 B라는 사람이 있다면 당연히 B에게서 받는 감정적 상처가 훨씬 클 테니 말입니다. 

05. 그래서 저는 B에게서 부정적인 피드백을 받았을 땐 A라는 사람의 화법을 필터로 써봅니다. 
즉 A가 저 의견을 나에게 전달해 줬다면 어떤 형태로 말해줬을까를 고민해 보면 그중에서 제가 취할 것과 버릴 것이 보이더라고요. B가 인간적으로 싫다고 해서 그 사람의 피드백을 모두 무시할 수는 없으니 최대한 나의 감정선을 지키며 팩트와 마주하는 방법을 써본 겁니다.

06. 그래도 멘탈이 너무 흔들린다 싶을 때는 양해를 구하고 A에게 직접 대화를 요청하는 방법도 있습니다. '제가 B에게서 이런 피드백을 들었는데 제 관점에서 팩트는 이것인 것 같습니다. 혹시 제가 이해한 게 맞을까요?'라고 한 번쯤 확인을 거치는 것이죠. 그때마다 저는 B에게서 들었던 감정적인 워딩들은 모두 뜰채로 걷어내고 진짜 내가 남겨야 하는 말들만 손에 담을 수 있었습니다.
매번 A에게 이렇게 묻고 확인받을 수는 없겠지만 가끔씩이라면 이 방법이 크게 도움이 된다고 얘기해 주고 싶습니다. (제 경험상 고민을 거듭하다 다시 B에게 되묻는 건 큰 도움이 되지 않았습니다...참고해 두시면 좋을 것 같네요...)

07. 여기서 한 가지 질문이 있을 수 있습니다. '주위에 A 같은 동료가 없으면요?' 
저도 이 질문을 스스로 던진 다음 좀 곰곰이 생각해 봤는데요, 그럼 정말 그 조직에 계속 있어야 할지 떠나야 할지를 고민해 봐야 하는 것 같습니다. 극단적이라고 생각되실지 모르겠지만 내가 속한 조직에 그 누구도 이성적이고 합리적이고 긍정적인 애티튜드로 피드백을 줄 수 없다면 그건 불행의 한 가운데 있는 것과 같다고 생각되거든요. 그럼 내가 어떤 일을 하고 어떤 기획을 한다고 한들 그게 객관적인 피드백과 평가를 받을 확률은 거의 없다는 게 제 결론입니다. 

08. '명상을 하며 부정적인 기억을 지워보세요', '회사에서 훌쩍 벗어나 기분 좋은 순간들을 찾아보세요' 같은 조언은 지금 타이밍과는 조금 거리가 있어 보입니다. (제가 수양이 덜 된 탓도 있겠지만..) 그래도 가급적 현장에서 해결해 볼 수 있는 방법을 찾고 그래도 안되면 저만치 좀 떨어져서 사건을 바라보는 게 맞다고 생각하니까요. 아직까지는 문제가 발생한 곳에서 해결 방법을 구해봤으면 하는 마음입니다. 

09. 오늘 질문에 대한 한 줄 정리를 해본다면 저는 이렇게 말씀드리고 싶습니다.

'부정적인 피드백이 내 감정을 건드렸다면 피드백 하는 화자의 영향일 확률이 크다. 그땐 내 주위에 좋은 애티튜드로 정확한 피드백을 주는 사람을 떠올리자. 그리고 그 사람의 화법을 통해 1차로 필터링을 해보자. 그래도 안된다면 직접 고민을 털어놓고 팩트를 분리해 내자.'

10. 딴소리지만 어쩌면 우리가 늘 주변에 좋은 사람을 가까이 두려는 이유도 이와 일맥상통하는 것 같습니다. 세상에 나쁜 영향들을 좋은 사람의 관점을 통해 걸러내기 위해서 말이죠. 말은 이렇게 번지르르하게 했지만 부디 저 또한 그런 필터를 줄 수 있는 사람인지 돌이켜 봐야겠네요. 이래서 질문을 받으면 답을 한 뒤에 꼭 스스로를 체크하는 과정이 필요한가 봅니다.

[ Q. 부정적 피드백을 받았을 땐 어떻게 감정을 극복해야 할까요

팔로워랑 좋아요 많다고 마케팅 잘하는 거 아닌데요

'SNS 마케팅의 본질을 파악하는 방법' 

SNS를 보다보면 팔로워와 좋아요 갯수가 많은 계정에 저절로 눈이 가는 경우가 있습니다. 

숫자로 보여지는 좋아요 갯수가 마치 신뢰의 상징처럼 느껴지는 경험은 모두 있었을텐데요,
그러다보면  판단력이 흐려져 컨텐츠의 질이나 내용을 제대로 파악하지 못하는 경우가 종종 있습니다. 

SNS의 좋아요나 팔로워 숫자에 현혹되지 않고 마케팅의 목적과 본질에 대해 생각해볼만한 글이 있어 공유드립니다.

Brunch Story

프로덕트 매니저/서비스 기획

한주현

벤처캐피털

박문석

#문제를해결하는 #스타트업 #0에서1만들기

웹디자이너

Orhen

노재연

우리는 앞으로 어떻게 이동하며 살게될까 고민하며 스마트 모빌리티 관련 UX업무를 하고 있습니다. 정보는 필요하지만 긴 글만 보면 앞이 깜깜해지는 나와 같은 사람들에게 도움이 되고 싶습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필