The URL Pattern API defines a syntax that is used to create URL pattern
matchers. These patterns can be matched against URLs or individual URL
components. The URL Pattern API is used by the URLPattern
interface.

URL Pattern API - Web APIs | MDN

https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API

https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API

MDN Web Docs

항해 플러스 AI 7주차는 본격적으로 HuggingFace를 활용한 LLM Pre-training과 Fine-tuning을 제대로 경험하고, Python Logging과 Wandb라는 두 가지 강력한 도구까지 배우면서 그야말로 AI 개발자로서의 역량을 한층 높일 수 있었던 알찬 시간이었습니다.

이번 글에서는 7주차에 배운 핵심 내용과, GPT 모델 Fine-tuning 실습 과정에서 배운 값진 경험들을 생생하게 전달하고자 합니다.

📌 Python Logger: print()의 시대는 갔다!
이전까지 저는 모델의 학습 상태를 확인할 때면 습관적으로
print()
를 남발했어요. 하지만 모델 학습이 복잡해질수록 터미널에서 로그가 뒤엉키는 현상이 잦았죠. 이번 주 Python Logger를 배우고 나서는 이 모든 문제가 마법처럼 사라졌답니다.

logging
라이브러리는 로그 레벨을 조절해 원하는 정보만 선택적으로 확인할 수 있고, 로그를 파일에 깔끔하게 저장할 수도 있어서 너무 편했어요. 특히 로그 포맷을 설정할 수 있어, 가독성을 높이니 모델의 상태를 빠르게 파악하는 데 정말 큰 도움이 됐습니다.

예를 들어, 학습 초기에는 디버깅을 위해
DEBUG
로 세부 사항을 모두 찍다가, 안정화 단계에서는
INFO
로 설정을 바꾸면 깔끔하게 요점만 남길 수 있었어요. 작은 변화였지만 생산성에 엄청난 차이를 만들었습니다.

📌 Wandb: 모델의 심장 소리를 실시간으로 듣다
Logger가 일종의 ‘진단 장비’라면, Wandb(Weights & Biases)는 제 모델의 생생한 심장 소리를 들려주는 ‘모니터링 시스템’ 같았습니다. 특히 Wandb는 단순히 숫자를 출력하는 것을 넘어 실험 결과를 실시간으로 웹에서 시각화하고 공유할 수 있게 해주는 서비스였어요.

Wandb의 장점 중 가장 인상적이었던 건:
 * 실험 모니터링: 실시간으로 loss를 그래프로 확인하며 모델의 건강 상태를 빠르게 체크할 수 있었습니다.
 * 데이터 시각화: GPU 사용률, grad_norm 등 다양한 지표를 한 화면에서 깔끔하게 볼 수 있어 직관적이었습니다.
 * 협업의 용이성: 팀원들과 Wandb 링크만 공유하면, 원격으로 실험 상태를 함께 보며 빠르게 피드백을 받을 수 있었습니다.
   
   
덕분에 학습 도중 GPU 메모리가 터지거나 loss가 폭주하는 상황을 즉시 발견하고 조치할 수 있었어요. Wandb 덕분에 개발의 품질이 확 올라가는 느낌을 강하게 받았습니다!

📌 GPT Fine-tuning 실습: Validation으로 완성도를 높이다
이번 주차의 메인 과제는 HuggingFace Trainer를 활용한 GPT 모델 Fine-tuning이었어요. HuggingFace를 이용하면 데이터셋 로딩, 토큰화, 모델 설정까지 간단하게 처리할 수 있어서 이전보다 훨씬 편했습니다.

특히 이번에는 validation 데이터를 추가하여 평가 단계에서 과적합 여부까지 확인하는 부분이 가장 인상적이었어요. 기존에 과적합을 단순히 "직감"으로만 판단했다면, 이번에는 확실히 수치적으로 파악할 수 있었죠.
 * 데이터셋: wikitext-2-raw-v1 (95% train, 5% valid)
 * 모델: GPT (openai-community/openai-gpt)
 * 평가 주기: logging_steps=100, eval_steps=500
   
   
학습을 진행하면서 Wandb를 통해
train/loss
와
eval/loss
를 동시에 확인하니, 처음엔 같이 내려가다가 일정 시점부터 eval loss가 높아지는 현상을 볼 수 있었어요. 이때 바로 학습을 멈추고 early stopping을 적용해 성능 저하를 미연에 방지했습니다. Wandb 덕분에 시각적으로 빠르게 대응할 수 있어, validation 데이터의 중요성을 온몸으로 느낄 수 있었어요.

📌 삽질의 교훈: Precision과 GPU 메모리의 치열한 싸움
모델 학습 과정 중 가장 기억에 남는 삽질은
torch_dtype
선택 문제였어요. 처음에는 메모리를 아끼려고 float16으로 설정했는데, 학습 중 gradient가 터지면서 loss가 nan이 되는 바람에 많이 고생했죠. 결국, bfloat16을 사용하고 gradient accumulation을 적용해 메모리와 안정성을 동시에 잡았어요.

이 경험을 통해 Precision 설정이 단순히 성능뿐 아니라 안정성까지 좌우할 수 있다는 중요한 교훈을 얻었습니다.

📌 LLM Pre-training부터 SFT, DPO까지: LLM의 성장 과정 완벽 정리
이번 주는 이론 학습도 풍성했어요. LLM의 전반적인 학습 과정인 Pre-training, Instruction-Tuning(SFT), 그리고 최근 주목받고 있는 DPO(Direct Preference Optimization)까지 상세히 배웠습니다.
특히 Preference Data를 사용해 LLM의 답변을 더 정교하고 사람이 원하는 형태로 align하는 RLHF, DPO 같은 기법을 통해 LLM이 어떻게 발전하고 있는지를 이해할 수 있었어요. DPO는 별도의 Reward Model 없이 Preference 데이터만으로 한 단계 만에 alignment를 완성할 수 있다는 점이 흥미로웠습니다.

📌 마무리하며
이번 7주차는 모델을 학습시키는 과정에서 놓치기 쉬운 로그 관리와 모니터링을 체계적으로 배울 수 있었던 귀중한 시간이었습니다. Python Logger로 효율적으로 학습 로그를 관리하고, Wandb를 통해 학습 과정을 직관적으로 모니터링하면서, 이전보다 훨씬 안정적이고 체계적인 실험 환경을 구축할 수 있었어요.

특히, HuggingFace Trainer로 GPT 모델을 Fine-tuning하며 validation 데이터를 활용하여 성능을 평가하는 과정을 통해 모델이 더 이상 숫자로만 존재하지 않고, 학습을 통해 실제로 발전해 나가는 생생한 과정을 직접 느낄 수 있었습니다. 앞으로도 이런 디테일한 부분까지 놓치지 않고 챙기며, 더욱 견고하고 섬세한 AI 개발자로 성장하겠습니다.

항해 플러스 — 추천인 코드: CF7LUQ

#항해99 #항해플러스AI후기 #AI개발자 #LLM #Wandb #HuggingFace #GPT

항해 플러스 AI 7주차는 본격적으로 HuggingFace를 활용한 LLM Pre-training과 Fine-tuning을 제대로 경험하고, Python Logging과 Wandb라는 두 가지 강력한 도구까지 배우면서 그야말로 AI 개발자로서의 역량을 한층 높일 수 있었던 알찬 시간이었습니다. 이번 글에서는 7주차에 배운 핵심 내용과, GPT 모델 Fine-tuning 실습 과정에서 배운 값진 경험들을 생생하게 전달하고자 합니다. 📌 Python Logger: print()의 시대는 갔다!이전까지 저는 모델의 학습 상태를 확인할 때면 습관적으로 <code >print()</code>를 남발했어요. 하지만 모델 학습이 복잡해질수록 터미널에서 로그가 뒤엉키는 현상이 잦았죠. 이번 주 Python Logger를 배우고 나서는 이 모든 문제가 마법처럼 사라졌답니다. <code >logging</code> 라이브러리는 로그 레벨을 조절해 원하는 정보만 선택적으로 확인할 수 있고, 로그를 파일에 깔끔하게 저장할 수도 있어서 너무 편했어요. 특히 로그 포맷을 설정할 수 있어, 가독성을 높이니 모델의 상태를 빠르게 파악하는 데 정말 큰 도움이 됐습니다. 예를 들어, 학습 초기에는 디버깅을 위해 <code >DEBUG</code>로 세부 사항을 모두 찍다가, 안정화 단계에서는 <code >INFO</code>로 설정을 바꾸면 깔끔하게 요점만 남길 수 있었어요. 작은 변화였지만 생산성에 엄청난 차이를 만들었습니다. 📌 Wandb: 모델의 심장 소리를 실시간으로 듣다Logger가 일종의 ‘진단 장비’라면, Wandb(Weights &amp; Biases)는 제 모델의 생생한 심장 소리를 들려주는 ‘모니터링 시스템’ 같았습니다. 특히 Wandb는 단순히 숫자를 출력하는 것을 넘어 실험 결과를 실시간으로 웹에서 시각화하고 공유할 수 있게 해주는 서비스였어요. Wandb의 장점 중 가장 인상적이었던 건:<ul ><li>실험 모니터링: 실시간으로 loss를 그래프로 확인하며 모델의 건강 상태를 빠르게 체크할 수 있었습니다.</li><li>데이터 시각화: GPU 사용률, grad_norm 등 다양한 지표를 한 화면에서 깔끔하게 볼 수 있어 직관적이었습니다.</li><li>협업의 용이성: 팀원들과 Wandb 링크만 공유하면, 원격으로 실험 상태를 함께 보며 빠르게 피드백을 받을 수 있었습니다. </li></ul>덕분에 학습 도중 GPU 메모리가 터지거나 loss가 폭주하는 상황을 즉시 발견하고 조치할 수 있었어요. Wandb 덕분에 개발의 품질이 확 올라가는 느낌을 강하게 받았습니다! 📌 GPT Fine-tuning 실습: Validation으로 완성도를 높이다이번 주차의 메인 과제는 HuggingFace Trainer를 활용한 GPT 모델 Fine-tuning이었어요. HuggingFace를 이용하면 데이터셋 로딩, 토큰화, 모델 설정까지 간단하게 처리할 수 있어서 이전보다 훨씬 편했습니다. 특히 이번에는 validation 데이터를 추가하여 평가 단계에서 과적합 여부까지 확인하는 부분이 가장 인상적이었어요. 기존에 과적합을 단순히 "직감"으로만 판단했다면, 이번에는 확실히 수치적으로 파악할 수 있었죠.<ul ><li>데이터셋: wikitext-2-raw-v1 (95% train, 5% valid)</li><li>모델: GPT (openai-community/openai-gpt)</li><li>평가 주기: logging_steps=100, eval_steps=500 </li></ul>학습을 진행하면서 Wandb를 통해 <code >train/loss</code>와 <code >eval/loss</code>를 동시에 확인하니, 처음엔 같이 내려가다가 일정 시점부터 eval loss가 높아지는 현상을 볼 수 있었어요. 이때 바로 학습을 멈추고 early stopping을 적용해 성능 저하를 미연에 방지했습니다. Wandb 덕분에 시각적으로 빠르게 대응할 수 있어, validation 데이터의 중요성을 온몸으로 느낄 수 있었어요. 📌 삽질의 교훈: Precision과 GPU 메모리의 치열한 싸움모델 학습 과정 중 가장 기억에 남는 삽질은 <code >torch_dtype</code> 선택 문제였어요. 처음에는 메모리를 아끼려고 float16으로 설정했는데, 학습 중 gradient가 터지면서 loss가 nan이 되는 바람에 많이 고생했죠. 결국, bfloat16을 사용하고 gradient accumulation을 적용해 메모리와 안정성을 동시에 잡았어요. 이 경험을 통해 Precision 설정이 단순히 성능뿐 아니라 안정성까지 좌우할 수 있다는 중요한 교훈을 얻었습니다. 📌 LLM Pre-training부터 SFT, DPO까지: LLM의 성장 과정 완벽 정리이번 주는 이론 학습도 풍성했어요. LLM의 전반적인 학습 과정인 Pre-training, Instruction-Tuning(SFT), 그리고 최근 주목받고 있는 DPO(Direct Preference Optimization)까지 상세히 배웠습니다.특히 Preference Data를 사용해 LLM의 답변을 더 정교하고 사람이 원하는 형태로 align하는 RLHF, DPO 같은 기법을 통해 LLM이 어떻게 발전하고 있는지를 이해할 수 있었어요. DPO는 별도의 Reward Model 없이 Preference 데이터만으로 한 단계 만에 alignment를 완성할 수 있다는 점이 흥미로웠습니다. 📌 마무리하며이번 7주차는 모델을 학습시키는 과정에서 놓치기 쉬운 로그 관리와 모니터링을 체계적으로 배울 수 있었던 귀중한 시간이었습니다. Python Logger로 효율적으로 학습 로그를 관리하고, Wandb를 통해 학습 과정을 직관적으로 모니터링하면서, 이전보다 훨씬 안정적이고 체계적인 실험 환경을 구축할 수 있었어요. 특히, HuggingFace Trainer로 GPT 모델을 Fine-tuning하며 validation 데이터를 활용하여 성능을 평가하는 과정을 통해 모델이 더 이상 숫자로만 존재하지 않고, 학습을 통해 실제로 발전해 나가는 생생한 과정을 직접 느낄 수 있었습니다. 앞으로도 이런 디테일한 부분까지 놓치지 않고 챙기며, 더욱 견고하고 섬세한 AI 개발자로 성장하겠습니다. 항해 플러스 — 추천인 코드: CF7LUQ #항해99 #항해플러스AI후기 #AI개발자 #LLM #Wandb #HuggingFace #GPT

항해 플러스 AI 7주차 후기 — Python Logging과 Wandb

부대끼는 실리콘밸리 사람들 사이에서 샘 알트만의 탈출구는 농장이다. 샘의 넓은 농장은 나파 밸리의 포도나무가 우거진 언덕을 관통하는 도로 끝에 있다. 나는 널찍한 베이 윈도우(사다리꼴 모양으로 튀어나온 창)가 있는 집의 오픈 키친에서 약간 헝클어진 머리를 한 40세의 샘 알트만을 봤고, 바로 들어간다. 그의 당혹스러운 표정을 보니 나는 예상치 못한 손님이다. 알고 보니 내가 거의 한 시간 일찍 도착했다. ChatGPT의 배후자인 이 남자는 회의를 마무리하고 정원에서 나와 합류할 것이다. 나는 집과 이어진 포도나무 그늘 퍼골라 아래에서 기다린다.‘런치 윗 FT’를 위해, 알트만은 사람들로 둘러싸일 가능성이 높은 식당에서의 만남 대신 자기 농장에서 간단한 채식 식사를 만들어주겠다고 제안했다. 그가 운영하는 오픈AI 가 2022년 생성형 AI를 출시한 뒤, 알트만은 순식간에 세계적인 ‘셀럽’이 되었다. 작년 그는 소프트웨어 엔지니어인 남자친구와 결혼했고 최근 대리모를 통해 아들을 낳았다(그는 어떤 아기 침대를 구매할지 ChatGPT에 문의했다). 그래서 그는 요즘 나파 밸리의 농장에서 더 많은 시간을 보낸다.단 몇 분 후에 알트만이 정원에 나왔다. 그는 오픈 AI를 인류 역사상 가장 빠르게 성장하는 회사 중 하나로 발전시켰다. 기업가치는 놀랍게도 2500억 달러 이상으로 평가된다. 또 AI 패권을 향한 경쟁도 계속 치열하게 펼쳐나가고 있다. 이 경쟁은 인공 일반 지능(artificial general intelligence)의

샘 알트만: "지금 당신이 o3보다 더 똑똑하다고 생각하세요?" : 오호츠크 리포트

샘 알트먼의 농장에 가서 약간 맛없고 건강한 걸 해주는 알트먼과 이야기하는 파이낸셜 타임즈 기자와의 이야기입니다. o3 과 향후 인공지능에 관한 이야기인데 너무 재미있네요.

그들이 먹은 음식은.

메뉴
샘 알트먼의 농장
나파 밸리, 캘리포니아

고추, 마늘, 호두, 파슬리, 페코리노 치즈가 들어간 파스타
구운 당근
당근과 무우 샐러드
에스프레소
차

샘 알트먼의 농장에 가서 약간 맛없고 건강한 걸 해주는 알트먼과 이야기하는 파이낸셜 타임즈 기자와의 이야기입니다. o3 과 향후 인공지능에 관한 이야기인데 너무 재미있네요. 그들이 먹은 음식은. 메뉴샘 알트먼의 농장나파 밸리, 캘리포니아 고추, 마늘, 호두, 파슬리, 페코리노 치즈가 들어간 파스타구운 당근당근과 무우 샐러드에스프레소차

55check.com

샘 알트만: "지금 당신이 o3보다 더 똑똑하다고 생각하세요?"

MS 6000명, 메타 3600명 AI가 일으킨 해고 칼바람 빅테크, 대규모 인력 감원 가속

MS 6000명, 메타 3600명… AI가 일으킨 해고 칼바람

트렌드 강연과 컨설팅할 때마다 이야기해왔던 가장 우려스러웠던 일이 현실화되고 있다. 새로운 기술이 새로운 일자리를 만들어내면서 더 경제규모를 키워낼 거라는 샐럽 미래학자들과 샐럽 기술쟁이들의 기술 찬양은 민망한 일이 되었다. 그들 말이 완전히 틀린 건 아니다. 단지 기술이 가져온 사회경제적 변화가 경제와 산업구조를 바꾸고 새로운 일자리를 많이 만들어내기까지 시간이 얼마나 오래 걸리는지 이야기를 안했을 뿐이다. 그렇게 되어도 다음 세대, 다다음 세대의 일일 뿐 당장 내 밥벌이가 사라지고 삶이 무너지는게 문제지 말이다.

이제 시작일 뿐 이 여파는 IT업계를 넘어 제조업과 유통업 등 전산업으로 한창 확대되고 있다. 기술 발전 속도로 볼 때 어디까지 어떤 속도로 진행되어 어떤 변화가 일어날 지 1단계로 먼저 모든 걸 재구성하게 될텐데, 그 1단계의 끝을 정확하게 예상해내는게 개인이나 기업이나 살아남는 방법이 아닐까 싶다.

https://www.chosun.com/economy/tech_it/2025/05/15/VMAPIYFGOVGMLMRMABUGWTOL4Y/

트렌드 강연과 컨설팅할 때마다 이야기해왔던 가장 우려스러웠던 일이 현실화되고 있다. 새로운 기술이 새로운 일자리를 만들어내면서 더 경제규모를 키워낼 거라는 샐럽 미래학자들과 샐럽 기술쟁이들의 기술 찬양은 민망한 일이 되었다. 그들 말이 완전히 틀린 건 아니다. 단지 기술이 가져온 사회경제적 변화가 경제와 산업구조를 바꾸고 새로운 일자리를 많이 만들어내기까지 시간이 얼마나 오래 걸리는지 이야기를 안했을 뿐이다. 그렇게 되어도 다음 세대, 다다음 세대의 일일 뿐 당장 내 밥벌이가 사라지고 삶이 무너지는게 문제지 말이다. 이제 시작일 뿐 이 여파는 IT업계를 넘어 제조업과 유통업 등 전산업으로 한창 확대되고 있다. 기술 발전 속도로 볼 때 어디까지 어떤 속도로 진행되어 어떤 변화가 일어날 지 1단계로 먼저 모든 걸 재구성하게 될텐데, 그 1단계의 끝을 정확하게 예상해내는게 개인이나 기업이나 살아남는 방법이 아닐까 싶다. https://www.chosun.com/economy/tech_it/2025/05/15/VMAPIYFGOVGMLMRMABUGWTOL4Y/

조선일보

테스트 결과는 4가지 김밥 중 하나! 내 포폴 스타일은?

UX/UI 포트폴리오 진단하러 가기

2분이면 내 포폴 상태가 어떤지 감을 잡을 수 있어요.
(4가지 김밥 유형으로 쉽게 분류해 보았습니다)
현재 1300명+ 참석해 주셨습니다 :)

UX/UI 포트폴리오 기준으로
이직 준비 중이거나 방향이 헷갈릴 때
한 번 해보시길 추천드립니다!

https://simte.xyz/woodydesignlab

2분이면 내 포폴 상태가 어떤지 감을 잡을 수 있어요.(4가지 김밥 유형으로 쉽게 분류해 보았습니다)현재 1300명+ 참석해 주셨습니다 :) UX/UI 포트폴리오 기준으로이직 준비 중이거나 방향이 헷갈릴 때한 번 해보시길 추천드립니다! https://simte.xyz/woodydesignlab

<UX/UI 포트폴리오, 미니 진단 테스트>

AI 기술이 우리 일상과 산업 전반에 스며들면서 소프트웨어 개발 환경 역시 큰 변화의 물결을 맞이하고 있다. 특히 코딩을 돕는 AI 에이전트의 등장은 개발 생산성에 대한 큰 변화를 만들고 있다. 나 역시 이러한 변화를 체감하며, 나에게 익숙한 소프트웨어 개발의 대표적인 두 축인 프론트엔드와 백엔드 영역에서 AI 기술이 미치는 영향과 그로 인해 변화하는 소프트웨어 엔지니어의 역할에 대해 개인적인 생각을 정리해 본다.

먼저 프론트엔드 영역을 살펴보자. 프론트엔드 엔지니어의 주요 업무 중 하나는 디자이너가 만든 시각적 결과물을 실제 사용자와 상호작용할 수 있는 인터페이스로 구현하는 것이다. 최근 커서(Cursor)와 같은 코딩 에이전트는 이 영역에서 놀라운 생산성 향상을 만들었다. 특히 피그마(Figma)와 MCP를 통한 연동 및 디자인 시스템의 활용은 정형화된 UI 구현 작업을 상당 부분 자동화하여, 엔지니어는 반복적인 코드 작성 시간을 줄이고 더 복잡한 문제에 집중할 수 있게 되었다. 물론 아직은 AI가 생성한 코드를 그대로 사용하기보다는 엔지니어의 검토와 수정이 필요하며, 복잡한 상태 관리나 비즈니스 로직 구현, 또는 매우 독창적인 인터랙션 구현에는 한계가 있다. 하지만 UI 구현에 드는 시간과 노력이 크게 줄어든다는 점은 부인할 수 없는 변화로 보인다.

다음으로 백엔드 영역도 살펴보자. 백엔드 엔지니어는 비즈니스 요구사항을 만족시키는 도메인 논리를 구현하고 안정적인 API를 제공하며, 나아가 대규모 시스템을 효율적으로 운영하기 위한 아키텍처 설계와 관리를 담당한다. 내 경험과 주변 동료들의 이야기를 종합해 보면, 백엔드 영역에서 코딩 에이전트의 생산성 향상 효과는 UI 구현만큼 극적이지는 않다. 복잡하게 얽힌 비즈니스 규칙, 레거시 시스템과의 연동, 데이터베이스 설계, 보안 및 성능 최적화 등 고려해야 할 요소가 많고, 도메인 맥락 의존성이 높기 때문일 것이다. 하지만 전혀 도움이 되지 않는 것은 아니다. 특정 로직 구현에 대한 아이디어를 얻거나, 테스트 코드 또는 API 문서 초안을 작성하고, 복잡한 아키텍처 패턴을 학습하거나 설계 대안을 탐색하는 과정에서는 분명 유용한 조력자 역할을 하고 있다. 또한, 클라우드 기술의 발전은 과거 백엔드 엔지니어의 주된 고민거리였던 인프라 구축 및 운영 부담을 상당 부분 덜어주며 비즈니스 요구사항 개발에 더 집중할 수 있는 환경을 만들어주고 있다.

이러한 변화 속에서 주목할 점은 프론트엔드와 백엔드 사이의 경계가 점차 흐릿해지고 있다는 것이다. AI의 도움으로 UI 구현 부담이 줄어든 프론트엔드 엔지니어는 자연스럽게 상태 관리 로직이나 서버와의 통신 너머, 즉 백엔드 영역의 문제 해결에 더 깊이 관여할 여지가 생겼다. 반대로 백엔드 엔지니어 역시 과거보다 표준화되고 있는 프론트엔드 기술(리액트)과 AI의 도움을 받아 사용자 인터페이스 개발에 대한 진입 장벽이 낮아졌다. 물론 각 영역의 깊이 있는 전문성은 여전히 중요하지만, 기술적인 장벽이 낮아짐에 따라 엔지니어들이 특정 기술 스택에 갇히기보다 제품 전체의 맥락을 이해하고 최종 사용자 가치를 중심으로 사고하는 것이 더욱 중요해지고 있다.

최근 여러 기업에서
프로덕트 엔지니어(Product Engineer)
라는 직군을 채용하는 모습은 이러한 변화를 반영하는 현상 중 하나라고 생각한다. 프로덕트 엔지니어는 단순히 프론트엔드와 백엔드 기술을 모두 다룰 수 있는 풀스택 개발자를 의미하는 것을 넘어, 사용자 경험부터 기술 구현, 데이터 분석, 인프라 운영까지 제품 개발의 전 과정에 걸쳐 주도적으로 문제를 정의하고 해결하며 제품의 성공에 기여하는 역할로 기대받고 있다. 불과 몇 년 전만 해도 이상적인 이야기처럼 들렸을지 모르지만, AI 기술의 발전과 개발 생태계의 변화는 이러한 역할의 현실화시키고 있다. 내 주변에서도 이미 기술 영역의 경계를 넘어 제품 자체에 집중하며 일하는 동료들을 어렵지 않게 찾아볼 수 있다.

2010년대 모바일 시대를 맞이하며 전문화되었던 프론트엔드와 백엔드의 역할 분담이, 이제 AI 시대를 맞아 다시 융합되는 듯한 흐름이 관찰된다. 물론 이는 나의 제한적인 경험과 관찰에 기반한 생각이며, 앞으로 기술이 어떻게 발전하고 시장이 어떻게 반응할지는 계속 지켜봐야 할 것이다. 하지만 한 가지 분명한 점은, 앞으로 소프트웨어 엔지니어에게는 깊이 있는 전문성과 더불어, 직군의 경계를 넘어 협력하고 제품 전체의 가치를 높이는 능력이 더욱 중요해질 것이라는 점이다. 이러한 변화의 흐름을 읽고 끊임없이 배우고 적응하는 자세가 그 어느 때보다 필요한 시점인 것 같다.

AI 기술이 우리 일상과 산업 전반에 스며들면서 소프트웨어 개발 환경 역시 큰 변화의 물결을 맞이하고 있다. 특히 코딩을 돕는 AI 에이전트의 등장은 개발 생산성에 대한 큰 변화를 만들고 있다. 나 역시 이러한 변화를 체감하며, 나에게 익숙한 소프트웨어 개발의 대표적인 두 축인 프론트엔드와 백엔드 영역에서 AI 기술이 미치는 영향과 그로 인해 변화하는 소프트웨어 엔지니어의 역할에 대해 개인적인 생각을 정리해 본다. 먼저 프론트엔드 영역을 살펴보자. 프론트엔드 엔지니어의 주요 업무 중 하나는 디자이너가 만든 시각적 결과물을 실제 사용자와 상호작용할 수 있는 인터페이스로 구현하는 것이다. 최근 커서(Cursor)와 같은 코딩 에이전트는 이 영역에서 놀라운 생산성 향상을 만들었다. 특히 피그마(Figma)와 MCP를 통한 연동 및 디자인 시스템의 활용은 정형화된 UI 구현 작업을 상당 부분 자동화하여, 엔지니어는 반복적인 코드 작성 시간을 줄이고 더 복잡한 문제에 집중할 수 있게 되었다. 물론 아직은 AI가 생성한 코드를 그대로 사용하기보다는 엔지니어의 검토와 수정이 필요하며, 복잡한 상태 관리나 비즈니스 로직 구현, 또는 매우 독창적인 인터랙션 구현에는 한계가 있다. 하지만 UI 구현에 드는 시간과 노력이 크게 줄어든다는 점은 부인할 수 없는 변화로 보인다. 다음으로 백엔드 영역도 살펴보자. 백엔드 엔지니어는 비즈니스 요구사항을 만족시키는 도메인 논리를 구현하고 안정적인 API를 제공하며, 나아가 대규모 시스템을 효율적으로 운영하기 위한 아키텍처 설계와 관리를 담당한다. 내 경험과 주변 동료들의 이야기를 종합해 보면, 백엔드 영역에서 코딩 에이전트의 생산성 향상 효과는 UI 구현만큼 극적이지는 않다. 복잡하게 얽힌 비즈니스 규칙, 레거시 시스템과의 연동, 데이터베이스 설계, 보안 및 성능 최적화 등 고려해야 할 요소가 많고, 도메인 맥락 의존성이 높기 때문일 것이다. 하지만 전혀 도움이 되지 않는 것은 아니다. 특정 로직 구현에 대한 아이디어를 얻거나, 테스트 코드 또는 API 문서 초안을 작성하고, 복잡한 아키텍처 패턴을 학습하거나 설계 대안을 탐색하는 과정에서는 분명 유용한 조력자 역할을 하고 있다. 또한, 클라우드 기술의 발전은 과거 백엔드 엔지니어의 주된 고민거리였던 인프라 구축 및 운영 부담을 상당 부분 덜어주며 비즈니스 요구사항 개발에 더 집중할 수 있는 환경을 만들어주고 있다. 이러한 변화 속에서 주목할 점은 프론트엔드와 백엔드 사이의 경계가 점차 흐릿해지고 있다는 것이다. AI의 도움으로 UI 구현 부담이 줄어든 프론트엔드 엔지니어는 자연스럽게 상태 관리 로직이나 서버와의 통신 너머, 즉 백엔드 영역의 문제 해결에 더 깊이 관여할 여지가 생겼다. 반대로 백엔드 엔지니어 역시 과거보다 표준화되고 있는 프론트엔드 기술(리액트)과 AI의 도움을 받아 사용자 인터페이스 개발에 대한 진입 장벽이 낮아졌다. 물론 각 영역의 깊이 있는 전문성은 여전히 중요하지만, 기술적인 장벽이 낮아짐에 따라 엔지니어들이 특정 기술 스택에 갇히기보다 제품 전체의 맥락을 이해하고 최종 사용자 가치를 중심으로 사고하는 것이 더욱 중요해지고 있다. 최근 여러 기업에서 <code >프로덕트 엔지니어(Product Engineer)</code>라는 직군을 채용하는 모습은 이러한 변화를 반영하는 현상 중 하나라고 생각한다. 프로덕트 엔지니어는 단순히 프론트엔드와 백엔드 기술을 모두 다룰 수 있는 풀스택 개발자를 의미하는 것을 넘어, 사용자 경험부터 기술 구현, 데이터 분석, 인프라 운영까지 제품 개발의 전 과정에 걸쳐 주도적으로 문제를 정의하고 해결하며 제품의 성공에 기여하는 역할로 기대받고 있다. 불과 몇 년 전만 해도 이상적인 이야기처럼 들렸을지 모르지만, AI 기술의 발전과 개발 생태계의 변화는 이러한 역할의 현실화시키고 있다. 내 주변에서도 이미 기술 영역의 경계를 넘어 제품 자체에 집중하며 일하는 동료들을 어렵지 않게 찾아볼 수 있다. 2010년대 모바일 시대를 맞이하며 전문화되었던 프론트엔드와 백엔드의 역할 분담이, 이제 AI 시대를 맞아 다시 융합되는 듯한 흐름이 관찰된다. 물론 이는 나의 제한적인 경험과 관찰에 기반한 생각이며, 앞으로 기술이 어떻게 발전하고 시장이 어떻게 반응할지는 계속 지켜봐야 할 것이다. 하지만 한 가지 분명한 점은, 앞으로 소프트웨어 엔지니어에게는 깊이 있는 전문성과 더불어, 직군의 경계를 넘어 협력하고 제품 전체의 가치를 높이는 능력이 더욱 중요해질 것이라는 점이다. 이러한 변화의 흐름을 읽고 끊임없이 배우고 적응하는 자세가 그 어느 때보다 필요한 시점인 것 같다.

무너지고 있는 프론트엔드, 백엔드 직군의 경계에 대한 고찰

React 19와 Next.js 15가 새롭게 제안하는 방향은
꽤 도발적이에요.

useActionState와 serverAction만으로도,
ReactQuery 같은 클라이언트 상태 관리 도구 없이
폼 처리와 상태 업데이트를 할 수 있게 되었어요.

물론 모든 걸 대체하긴 어려워요.
하지만 단순한 폼 처리부터 CRUD 까지는
이 방향이 괜찮은 선택지가 될 수 있을것 같아요.

그래서 직접 예제 코드를 준비했고,
유튜브에 공유 드려요.
(댓글에 영상주소 참고)

기존 방식(React Query)과 새로운 방식(Next.js)에 대해
실무 기준에서 어떤 차이가 있고, 왜 이런 구조가 필요한지를
FSD 관점에서 살펴보며 풀어봤어요.

React Query의 전역 상태가 과하게 느껴졌던 분,
혹은 server action 시대의 프론트엔드 흐름을 따라가고 싶은 분이라면
이번 영상을 확인해보셔도 좋을 것 같아요.
(댓글에 영상주소 참고)

React 19와 Next.js 15가 새롭게 제안하는 방향은 꽤 도발적이에요. useActionState와 serverAction만으로도, ReactQuery 같은 클라이언트 상태 관리 도구 없이 폼 처리와 상태 업데이트를 할 수 있게 되었어요. 물론 모든 걸 대체하긴 어려워요. 하지만 단순한 폼 처리부터 CRUD 까지는 이 방향이 괜찮은 선택지가 될 수 있을것 같아요. 그래서 직접 예제 코드를 준비했고, 유튜브에 공유 드려요. (댓글에 영상주소 참고) 기존 방식(React Query)과 새로운 방식(Next.js)에 대해 실무 기준에서 어떤 차이가 있고, 왜 이런 구조가 필요한지를 FSD 관점에서 살펴보며 풀어봤어요. React Query의 전역 상태가 과하게 느껴졌던 분, 혹은 server action 시대의 프론트엔드 흐름을 따라가고 싶은 분이라면 이번 영상을 확인해보셔도 좋을 것 같아요. (댓글에 영상주소 참고)

React Hooks Testing Library 사용법

React v16.8에서 리액트 훅(React Hook)이 소개된 이후로 많은 프로젝트에서 커스텀(custom) 훅 함수를 사용하고 있는 것 같은데요. 이번 포스팅에는 React Hooks Testing Library 사용하여 리액트 훅(React Hook)을 테스트하는 방법에 대해서 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/react-hooks-testing-library/

프론트엔드 테스팅의 표준이 되어 가고 있는 React Testing Library에 대해서 더 알고 싶으시다면 다음 게시물을 참고바랍니다.

📕 React Testing Library 사용법: https://careerly.co.kr/comments/98831
📗 유저 이벤트 테스트 (@testing-library/user-event): https://careerly.co.kr/comments/100167
📘 React Testing Library - 비동기 테스트: https://careerly.co.kr/comments/101030

React v16.8에서 리액트 훅(React Hook)이 소개된 이후로 많은 프로젝트에서 커스텀(custom) 훅 함수를 사용하고 있는 것 같은데요. 이번 포스팅에는 React Hooks Testing Library 사용하여 리액트 훅(React Hook)을 테스트하는 방법에 대해서 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/react-hooks-testing-library/ 프론트엔드 테스팅의 표준이 되어 가고 있는 React Testing Library에 대해서 더 알고 싶으시다면 다음 게시물을 참고바랍니다. 📕 React Testing Library 사용법: https://careerly.co.kr/comments/98831📗 유저 이벤트 테스트 (@testing-library/user-event): https://careerly.co.kr/comments/100167📘 React Testing Library - 비동기 테스트: https://careerly.co.kr/comments/101030

www.daleseo.com

React Hooks 🪝 Testing Library 사용법

라이브러리 정보 & 리뷰 커리어리 팀 | 1. 개요 : TypeScript를 우선으로 하는 스키마 선언 및 유효성 검증 라이브러리 2. 주간 다운로드... | 커리어리

라이브러리 정보 & 리뷰 / 라이브러리 Zod 상세 정보 리뷰 | 커리어리

수많은 라이브러리 중, 어떤 라이브러리를 활용할지 고민되시나요?
이제 커리어리에서 GitHub와 NPM에 게시된 인기 유효성 검증 라이브러리 정보와 생생한 리뷰를 바탕으로 비교 후 결정하세요!

리뷰는 각 라이브러리 게시물의 댓글에서 보실 수 있어요.
사용해봤던 라이브러리라면 다른 유저분들을 위해 리뷰를 남겨주세요. 리뷰를 작성해주시는 분들께는 감사의 마음을 담아 스타벅스 기프티콘을 보내드릴게요.
각자의 개발 경험을 나누고, 때론 도움을 얻을 수 있는 공유의 장이 되기를 바라요 💡

 1. Zod (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92542)
    1. 개요 : TypeScript를 우선으로 하는 스키마 선언 및 유효성 검증 라이브러리
    2. github star : 26k
    3. 라이센스 : MIT License
    4. 공식 문서 링크 : https://zod.dev/
 2. Yup (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92543)
    1. 개요 : 매우 간단한 객체 스키마 유효성 검증 라이브러리
    2. github star : 21.3k
    3. 라이센스 : MIT License
    4. 공식 문서 링크 : https://github.com/jquense/yup
 3. Joi (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92544)
    1. 개요 : 가장 강력한 JavaScript 데이터 유효성 검증 라이브러리
    2. github star : 20.3k
    3. 라이센스 : MIT License
    4. 공식 문서 링크 : https://joi.dev/

Zod vs Yup vs Joi 비교 데이터 (npm trends)
 * https://npmtrends.com/joi-vs-yup-vs-zod

📭라이브러리 추가 / 정보 추가 / 기능 제안 등 피드백 남기기 > https://tally.so/r/3y4zy0

수많은 라이브러리 중, 어떤 라이브러리를 활용할지 고민되시나요?이제 커리어리에서 GitHub와 NPM에 게시된 인기 유효성 검증 라이브러리 정보와 생생한 리뷰를 바탕으로 비교 후 결정하세요! 리뷰는 각 라이브러리 게시물의 댓글에서 보실 수 있어요.사용해봤던 라이브러리라면 다른 유저분들을 위해 리뷰를 남겨주세요. 리뷰를 작성해주시는 분들께는 감사의 마음을 담아 스타벅스 기프티콘을 보내드릴게요. 각자의 개발 경험을 나누고, 때론 도움을 얻을 수 있는 공유의 장이 되기를 바라요 💡 <ol><li>Zod (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92542)<ol><li>개요 : TypeScript를 우선으로 하는 스키마 선언 및 유효성 검증 라이브러리</li><li>github star : 26k</li><li>라이센스 : MIT License</li><li>공식 문서 링크 : https://zod.dev/</li></ol></li><li>Yup (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92543)<ol><li>개요 : 매우 간단한 객체 스키마 유효성 검증 라이브러리</li><li>github star : 21.3k</li><li>라이센스 : MIT License</li><li>공식 문서 링크 : https://github.com/jquense/yup</li></ol></li><li>Joi (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92544)<ol><li>개요 : 가장 강력한 JavaScript 데이터 유효성 검증 라이브러리</li><li>github star : 20.3k</li><li>라이센스 : MIT License</li><li>공식 문서 링크 : https://joi.dev/</li></ol></li></ol> Zod vs Yup vs Joi 비교 데이터 (npm trends)<ul><li>https://npmtrends.com/joi-vs-yup-vs-zod</li></ul> 📭라이브러리 추가 / 정보 추가 / 기능 제안 등 피드백 남기기 &gt; https://tally.so/r/3y4zy0

커리어리

주요 유효성 검증 라이브러리 모음.zip

Zod (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92542)

 1. 개요 : TypeScript를 우선으로 하는 스키마 선언 및 유효성 검증 라이브러리
 2. 주간 다운로드 수 : 6,000,905
 3. 버전 정보 : 3.22.4 (23.10.04)
 4. github star : 26k
 5. 라이센스 : MIT License (https://github.com/colinhacks/zod/blob/master/LICENSE)
 6. 공식 문서 링크 : https://zod.dev/
 7. 패키지 페이지 링크 : https://www.npmjs.com/package/zod
 8. 리뷰 : 👇아래 댓글에서 확인할 수 있어요 👇
    * 도움이 된 리뷰엔 좋아요도 잊지 말고 눌러주세요 👍
    * 리뷰 양식 (리뷰 작성 시 복사해서 활용하세요!)
      * -무엇을 위해 쓰(썼)는지 (용도/적용한 기능) :
        -어떤 이유 때문에 이 라이브러리를 사용했는지 :
        -만족 점수 & 이유 : /10

<ol><li>개요 : TypeScript를 우선으로 하는 스키마 선언 및 유효성 검증 라이브러리</li><li>주간 다운로드 수 : 6,000,905</li><li>버전 정보 : 3.22.4 (23.10.04)</li><li>github star : 26k</li><li>라이센스 : MIT License (https://github.com/colinhacks/zod/blob/master/LICENSE)</li><li>공식 문서 링크 : https://zod.dev/</li><li>패키지 페이지 링크 : https://www.npmjs.com/package/zod</li><li>리뷰 : 👇아래 댓글에서 확인할 수 있어요 👇<ul><li>도움이 된 리뷰엔 좋아요도 잊지 말고 눌러주세요 👍</li><li>리뷰 양식 (리뷰 작성 시 복사해서 활용하세요!)<ul><li>-무엇을 위해 쓰(썼)는지 (용도/적용한 기능) : -어떤 이유 때문에 이 라이브러리를 사용했는지 :-만족 점수 &amp; 이유 : /10</li></ul></li></ul></li></ol>

[라이브러리] Zod 상세 정보 & 리뷰

- 무엇을 위해 썼는지: API 요청 파라미터, URL 쿼리 파라미터 유효성 검증 (validation).

- 어떤 이유 때문에 이 라이브러리를 사용했는지: 클래스 annotation 기반의 라이브러리보다 직관적이고, 유효성 검증 후에 값을 리턴하기 때문에 타입이 자연스럽게 추론되도록 할 수 있으며, from-to Zod 로 변환하는 등의 라이브러리 생태계가 잘 갖추어져 있어서. 

- 만족 점수 & 이유: 9/10. 값의 유효성을 검증하기 전/후에 값을 변환해줘야 하는 니즈가 있는데, 그 때 사용법에 제약이 좀 있다고 느꼈기 때문에. 

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다.

개발자의 장애 공유 문화

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다.

작고 큰 장애들이 자주 발생했습니다.
장애가 발생하면 즉시 전파하고, 원인을 파악하고 후속 대응까지 실시간으로 공유했습니다.
누구에게? 회사의 모든 사람들에게.
CS 부서나 운영팀처럼 상황을 빠르게 파악해야 하는 팀에게는 멘션까지 하면서.

'와, 이 사람들 특이한 사람들이네. 이런 건 살다 살다 처음 보는군.'
'다들 실수를 숨기고 싶어 하는데, 이 사람들은 실수한 걸 마치 자랑하듯이 게시판에 올리잖아? 그것도 전사 게시판에. (미친 사람들인가?)'

장애 공유 글에는 항상 좋아요가 많이 달렸습니다.
쪽팔림 같은 건 저기 던져버리고 자신의 얼간이 짓을 솔직하게 쓰면 쓸수록 좋아요가 더 많이 달렸습니다.

원인과 후속 조치, 여전히 가시지 않는 의문점들에 대해 댓글로 논의하기도 했습니다만…
장애를 낸 사람을 탓하는 경우는 한 번도 보지 못했습니다.
이건 불문율이었습니다. 이 불문율을 깨트리면 누구도 더 이상 솔직하게 공유하지 않을 테니까.

자신이 발생시킨 장애를 전 직원들에게 공유한다는 것이 절대 쉬운 일이 아닙니다.
직접 해봐야 그 당혹스러움과 부끄러움을 알 수 있습니다.
처음 겪으면 그냥 도망쳐버리고 싶다는 생각이 들 정도로 아찔합니다만…
몇 번 하다 보면 이 짓도 편안해집니다.

'아 오늘도 장애 공유 써야 되네, 젠장. 뭐 일하다 보면 장애 낼 수도 있는 거지.'
'열심히 코딩하고 배포하다 보니 장애를 많이 내는 것일 뿐, 내가 진짜 얼간이여서 그런 게 아니라고.'
(그래도 다음엔 실수하지 말아야겠다)

카카오에서보다 더 놀랐던 기억도 납니다.
2017년의 GitLab 장애.
rm -rf로 프로덕션 데이터베이스 전체를 날려먹었던가?
엄청난 장애를 어린 엔지니어 혼자 수습했습니다. 그것도 유튜브에 라이브 스트리밍을 하면서. (사람들이 댓글로 이걸 고쳐봐라 저걸 확인해 봐라… ㅋㅋㅋ)
와, 진짜 미친 사람들이 여기 있었구나. 저걸 회사의 다른 동료들이 아무도 뭐라 하지 않는 건가? 아니, 어쩌면 의도적으로 저렇게 공유하기로 한 건가?
문제를 공유하고 소통하는 것에 저 정도로 열려 있다면 GitLab의 다른 문화들도 충분히 멋질 거야. 라고 생각했던 것 같습니다.

https://jeho.page/essay/2025/05/15/failure-sharing.html

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다. 작고 큰 장애들이 자주 발생했습니다. 장애가 발생하면 즉시 전파하고, 원인을 파악하고 후속 대응까지 실시간으로 공유했습니다. 누구에게? 회사의 모든 사람들에게. CS 부서나 운영팀처럼 상황을 빠르게 파악해야 하는 팀에게는 멘션까지 하면서. '와, 이 사람들 특이한 사람들이네. 이런 건 살다 살다 처음 보는군.' '다들 실수를 숨기고 싶어 하는데, 이 사람들은 실수한 걸 마치 자랑하듯이 게시판에 올리잖아? 그것도 전사 게시판에. (미친 사람들인가?)' 장애 공유 글에는 항상 좋아요가 많이 달렸습니다. 쪽팔림 같은 건 저기 던져버리고 자신의 얼간이 짓을 솔직하게 쓰면 쓸수록 좋아요가 더 많이 달렸습니다. 원인과 후속 조치, 여전히 가시지 않는 의문점들에 대해 댓글로 논의하기도 했습니다만… 장애를 낸 사람을 탓하는 경우는 한 번도 보지 못했습니다. 이건 불문율이었습니다. 이 불문율을 깨트리면 누구도 더 이상 솔직하게 공유하지 않을 테니까. 자신이 발생시킨 장애를 전 직원들에게 공유한다는 것이 절대 쉬운 일이 아닙니다. 직접 해봐야 그 당혹스러움과 부끄러움을 알 수 있습니다. 처음 겪으면 그냥 도망쳐버리고 싶다는 생각이 들 정도로 아찔합니다만… 몇 번 하다 보면 이 짓도 편안해집니다. '아 오늘도 장애 공유 써야 되네, 젠장. 뭐 일하다 보면 장애 낼 수도 있는 거지.' '열심히 코딩하고 배포하다 보니 장애를 많이 내는 것일 뿐, 내가 진짜 얼간이여서 그런 게 아니라고.' (그래도 다음엔 실수하지 말아야겠다) 카카오에서보다 더 놀랐던 기억도 납니다. 2017년의 GitLab 장애. rm -rf로 프로덕션 데이터베이스 전체를 날려먹었던가? 엄청난 장애를 어린 엔지니어 혼자 수습했습니다. 그것도 유튜브에 라이브 스트리밍을 하면서. (사람들이 댓글로 이걸 고쳐봐라 저걸 확인해 봐라… ㅋㅋㅋ) 와, 진짜 미친 사람들이 여기 있었구나. 저걸 회사의 다른 동료들이 아무도 뭐라 하지 않는 건가? 아니, 어쩌면 의도적으로 저렇게 공유하기로 한 건가? 문제를 공유하고 소통하는 것에 저 정도로 열려 있다면 GitLab의 다른 문화들도 충분히 멋질 거야. 라고 생각했던 것 같습니다. https://jeho.page/essay/2025/05/15/failure-sharing.html

K리그 프로그래머

﻿
세상에서 내가 제일 어렵고 힘든 상황에 놓여 있는 것 같지만, 주위를 둘러보면 위로와 격려가 필요한 사람이 더 많습니다. 어제는 전 직장 동료의 부고 소식을 전해 들었습니다. 갑작스러운 사고로 인해 하늘나라로 간 고인과 그의 가족들 소식을 듣고 마음이 먹먹했습니다. 가족들의 슬픔을 어떤 말로 위로하기 어렵겠지만, 진심으로 기도하여 빠르게 평안을 찾길 바란다고 메시지를 보냈습니다.

그 어느 때보다 뚫기 어려운 취업 시장에서 매일 탈락 안내를 받고 마음이 무너진다는 소식을 듣습니다. 3개월 전에 직접 겪었던 상황이 떠올라 마음이 아팠습니다. 얼마나 힘들고 답답할까 상황이 잘 이해와 공감되었기에 더 마음이 쓰였습니다. 입사 지원한 결과를 알려주지 않거나 채용 전형에서 아쉽게 탈락했다고 해서 절대 지원자가 부족한 것은 아니니 너무 실망하지 말자고 격려했습니다. 제 말이 무슨 힘이 있어서 취업에 도전하는 사람들을 얼마나 위로할 수 있겠습니까. 다만, 진심으로 그의 어려움이 공감되어 상황에 무릎 꿇지 않고 담대한 용기를 갖기를 바라는 마음입니다.

우리의 직장 동료들도 자세히 들여다보면 하나같이 위로와 격려가 필요합니다. 동료가 하는 일과 그의 컨디션에 관심을 갖고, 자세히 보면 저마다 어려움을 안고 일을 하고 있습니다. 우리가 관심이 없으니 동료가 겪고 있는 고충이 보이지 않을 뿐입니다. 오히려 왜 저렇게 말하고 행동하는지 동료에 대한 불평과 불만을 갖고 있습니다. 알고 보면 각자 다 그럴만한 사정이 있고, 동료에게 필요한 건 조언이 아니라 위로입니다. 

매일 아침 눈을 뜨면 만나는 가족도 마찬가지입니다. 아내와 아들, 딸에게도 힘든 부분이 있을 것입니다. 직장을 다니는 아내에게 일과 사람에 대한 스트레스가 있을 것이고, 학교와 유치원을 다니는 아들과 딸에게도 공부하고 친구들과 지내는 관계에 어려움이 있을 것입니다. 매일 어려움을 가족에게 이야기하지 않을 뿐 각자 마음속으로 끙끙 앓고 있는 아픔이 있습니다. 그들에게 필요한 건 잔소리가 아니라 사랑이 담긴 말 한마디와 따뜻한 포옹입니다. 내 생활 방식과 다르다고 핀잔을 주는 것이 아니라 오늘은 어떤 일로 힘들지 않았나 세심하게 살펴보고 정성스럽게 대화를 나누는 것입니다.

아파트 경비 아저씨는 얼마나 힘들까요? 매일 쏟아져 나오는 쓰레기를 정리하고 처리해야 합니다. 날마다 방문하는 사람들에게 문을 열어주고, 붐비는 주차장을 관리하느라 실랑이를 벌입니다. 잠도 편하게 주무시지 못하고 추운 밤을 쓸쓸하게 혼자 보내는 마음은 어떨까요? 제가 도울 수 있는 일은 분리수거 잘하고, 엘리베이터에 붙은 아파트 주민으로 해야 할 일을 제때 잘 처리하는 것뿐입니다. 그리고 오늘도 마주친다면 반갑게 인사드리고, 수고해 주셔서 감사하다는 표현입니다. 이것으로 경비 아저씨가 힘을 얻을 수 있다면 만날 때마다 해야죠.

퇴근길을 터벅터벅 걸어오는 이웃의 발걸음을 보면 오늘 하루 얼마나 고되었을까 상상해 봅니다. 매일 아침 출근길에 만나는 이웃도 너무 일을 하고 싶어서 룰루랄라 일터로 가는 건 아니겠지요? 먹고살기 위해 고군분투하고 집으로 돌아오는 길이 힘없어 보이는 건 하루 종일 지지고 볶고 에너지를 쏟았을 쓸 이웃의 험난한 여정이 공감되었기 때문입니다. 일을 하느라 바빠서 자신을 돌아볼 여유도 없이 보냈을 하루가 정말 피곤했을 것 같습니다. 부디 저녁에는 편안하게 쉬고 에너지를 충전하길 마음으로 응원해 봅니다.

어제 만나고 떠오른 사람들 말고도 위로와 격려가 필요한 분들이 많이 계실 줄 압니다. 그들이 직접 힘들다고 우리에게 적극적으로 표현하지 않을 것입니다. 우리가 먼저 그런 시선을 가지면 좋겠습니다. 우리가 힘들었던 상황을 떠올려보면 공감하는 것이 그리 어려운 일은 아닙니다. 시선은 전적으로 우리 마음에 달려있습니다. 날카로운 눈으로 바라보는 것이 아니라 사랑으로 바라보면 모든 사람과 상황이 이해와 공감할 수 있다고 믿습니다. 오늘은 주변 사람들을 사랑의 눈으로 바라보고, 진심을 담아 응원하는 하루가 되면 좋겠습니다.

﻿세상에서 내가 제일 어렵고 힘든 상황에 놓여 있는 것 같지만, 주위를 둘러보면 위로와 격려가 필요한 사람이 더 많습니다. 어제는 전 직장 동료의 부고 소식을 전해 들었습니다. 갑작스러운 사고로 인해 하늘나라로 간 고인과 그의 가족들 소식을 듣고 마음이 먹먹했습니다. 가족들의 슬픔을 어떤 말로 위로하기 어렵겠지만, 진심으로 기도하여 빠르게 평안을 찾길 바란다고 메시지를 보냈습니다. 그 어느 때보다 뚫기 어려운 취업 시장에서 매일 탈락 안내를 받고 마음이 무너진다는 소식을 듣습니다. 3개월 전에 직접 겪었던 상황이 떠올라 마음이 아팠습니다. 얼마나 힘들고 답답할까 상황이 잘 이해와 공감되었기에 더 마음이 쓰였습니다. 입사 지원한 결과를 알려주지 않거나 채용 전형에서 아쉽게 탈락했다고 해서 절대 지원자가 부족한 것은 아니니 너무 실망하지 말자고 격려했습니다. 제 말이 무슨 힘이 있어서 취업에 도전하는 사람들을 얼마나 위로할 수 있겠습니까. 다만, 진심으로 그의 어려움이 공감되어 상황에 무릎 꿇지 않고 담대한 용기를 갖기를 바라는 마음입니다. 우리의 직장 동료들도 자세히 들여다보면 하나같이 위로와 격려가 필요합니다. 동료가 하는 일과 그의 컨디션에 관심을 갖고, 자세히 보면 저마다 어려움을 안고 일을 하고 있습니다. 우리가 관심이 없으니 동료가 겪고 있는 고충이 보이지 않을 뿐입니다. 오히려 왜 저렇게 말하고 행동하는지 동료에 대한 불평과 불만을 갖고 있습니다. 알고 보면 각자 다 그럴만한 사정이 있고, 동료에게 필요한 건 조언이 아니라 위로입니다.&nbsp; 매일 아침 눈을 뜨면 만나는 가족도 마찬가지입니다. 아내와 아들, 딸에게도 힘든 부분이 있을 것입니다. 직장을 다니는 아내에게 일과 사람에 대한 스트레스가 있을 것이고, 학교와 유치원을 다니는 아들과 딸에게도 공부하고 친구들과 지내는 관계에 어려움이 있을 것입니다. 매일 어려움을 가족에게 이야기하지 않을 뿐 각자 마음속으로 끙끙 앓고 있는 아픔이 있습니다. 그들에게 필요한 건 잔소리가 아니라 사랑이 담긴 말 한마디와 따뜻한 포옹입니다. 내 생활 방식과 다르다고 핀잔을 주는 것이 아니라 오늘은 어떤 일로 힘들지 않았나 세심하게 살펴보고 정성스럽게 대화를 나누는 것입니다. 아파트 경비 아저씨는 얼마나 힘들까요? 매일 쏟아져 나오는 쓰레기를 정리하고 처리해야 합니다. 날마다 방문하는 사람들에게 문을 열어주고, 붐비는 주차장을 관리하느라 실랑이를 벌입니다. 잠도 편하게 주무시지 못하고 추운 밤을 쓸쓸하게 혼자 보내는 마음은 어떨까요? 제가 도울 수 있는 일은 분리수거 잘하고, 엘리베이터에 붙은 아파트 주민으로 해야 할 일을 제때 잘 처리하는 것뿐입니다. 그리고 오늘도 마주친다면 반갑게 인사드리고, 수고해 주셔서 감사하다는 표현입니다. 이것으로 경비 아저씨가 힘을 얻을 수 있다면 만날 때마다 해야죠. 퇴근길을 터벅터벅 걸어오는 이웃의 발걸음을 보면 오늘 하루 얼마나 고되었을까 상상해 봅니다. 매일 아침 출근길에 만나는 이웃도 너무 일을 하고 싶어서 룰루랄라 일터로 가는 건 아니겠지요? 먹고살기 위해 고군분투하고 집으로 돌아오는 길이 힘없어 보이는 건 하루 종일 지지고 볶고 에너지를 쏟았을 쓸 이웃의 험난한 여정이 공감되었기 때문입니다. 일을 하느라 바빠서 자신을 돌아볼 여유도 없이 보냈을 하루가 정말 피곤했을 것 같습니다. 부디 저녁에는 편안하게 쉬고 에너지를 충전하길 마음으로 응원해 봅니다. 어제 만나고 떠오른 사람들 말고도 위로와 격려가 필요한 분들이 많이 계실 줄 압니다. 그들이 직접 힘들다고 우리에게 적극적으로 표현하지 않을 것입니다. 우리가 먼저 그런 시선을 가지면 좋겠습니다. 우리가 힘들었던 상황을 떠올려보면 공감하는 것이 그리 어려운 일은 아닙니다. 시선은 전적으로 우리 마음에 달려있습니다. 날카로운 눈으로 바라보는 것이 아니라 사랑으로 바라보면 모든 사람과 상황이 이해와 공감할 수 있다고 믿습니다. 오늘은 주변 사람들을 사랑의 눈으로 바라보고, 진심을 담아 응원하는 하루가 되면 좋겠습니다.﻿

위로

1. 뇌를 재설계하려면 무엇이 필요할까?

2. 많은 게 필요하지 않고 딱 다음 세 가지만 있으면 된다. 그나마 한 가지는 선택 사항이다.

3. 집중, 반복, 감정(두려움, 행복, 증오, 사랑, 열정 등)

4. 감정이란 치트키를 쓰면 뇌의 신경 회로가 가장 빨리 재구성된다. 하지만 감정 없이 리프레임에 집중하고 반복하기만 해도 뇌를 원하는 대로 재설계할 수 있다.

5. 뇌는 입력하는 자극에 반응하여 새로운 구조를 만든다. 집중과 반복은 아이디어(또는 리프레임)를 개념적인 것에서 물리적인 것으로 바꾼다.

6. 다시 말해 뇌 구조에 물리적인 변화를 가져온다.

7. 여기에 감정을 더하면 뇌가 더 빨리 재설계 되지만, 다시 말하는데 이 부분은 선택 사항이다.

#더리프레임 📚
#스콧에덤스
#하루한문장

1. 뇌를 재설계하려면 무엇이 필요할까? ​2. 많은 게 필요하지 않고 딱 다음 세 가지만 있으면 된다. 그나마 한 가지는 선택 사항이다. ​3. 집중, 반복, 감정(두려움, 행복, 증오, 사랑, 열정 등) ​4. 감정이란 치트키를 쓰면 뇌의 신경 회로가 가장 빨리 재구성된다. 하지만 감정 없이 리프레임에 집중하고 반복하기만 해도 뇌를 원하는 대로 재설계할 수 있다. ​5. 뇌는 입력하는 자극에 반응하여 새로운 구조를 만든다. 집중과 반복은 아이디어(또는 리프레임)를 개념적인 것에서 물리적인 것으로 바꾼다. ​6. 다시 말해 뇌 구조에 물리적인 변화를 가져온다. ​7. 여기에 감정을 더하면 뇌가 더 빨리 재설계 되지만, 다시 말하는데 이 부분은 선택 사항이다. #더리프레임 📚 #스콧에덤스 #하루한문장

< 뇌를 가장 빠르게 바꾸는 3가지 방법 >

현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠.

이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/github-dependabot/

Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃허브 플랫폼에 완전히 통합되어 무료로 사용할 수 있습니다. 덕분에 Dependabot에 대한 접근성과 사용성이 크게 개선되어 복잡한 과정없이 코드 저장소에 간단한 설정만으로 바로 쓸 수 있습니다.

Dependabot은 다음 세 가지 기능으로 이루어져 있습니다.
 * Alerts(알람): 코드 저장소의 보안 취약점을 감지하여 경고합니다.
 * Security Updates(보안 업데이트): 보안 취약점이 발견된 의존성을 업데이트하는 Pull Request을 자등으로 생성합니다.
 * Version Updates(버전 업데이트): 보안과 무관하게 의존성을 최신 상태로 유지하기 Pull Request을 자등으로 생성합니다.

npm이나 Maven, PyPI, RubyGems, Docker Hub 등과 같은 패키지 저장소를 통해 의존성을 내려받는 프로젝트는 모두 잠재적인 공급망 공격(Supply Chain Attack) 위험에 처해 있습니다. Dependabot은 점점 정교해지고 있는 공급망 공격을 방어하고, 알려진 보안 취약점으로부터 프로젝트를 지킬 수 있는 강력한 보안 도구입니다.

현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠. 이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/github-dependabot/ Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃허브 플랫폼에 완전히 통합되어 무료로 사용할 수 있습니다. 덕분에 Dependabot에 대한 접근성과 사용성이 크게 개선되어 복잡한 과정없이 코드 저장소에 간단한 설정만으로 바로 쓸 수 있습니다. Dependabot은 다음 세 가지 기능으로 이루어져 있습니다.<ul><li>Alerts(알람): 코드 저장소의 보안 취약점을 감지하여 경고합니다.</li><li>Security Updates(보안 업데이트): 보안 취약점이 발견된 의존성을 업데이트하는 Pull Request을 자등으로 생성합니다.</li><li>Version Updates(버전 업데이트): 보안과 무관하게 의존성을 최신 상태로 유지하기 Pull Request을 자등으로 생성합니다.</li></ul> npm이나 Maven, PyPI, RubyGems, Docker Hub 등과 같은 패키지 저장소를 통해 의존성을 내려받는 프로젝트는 모두 잠재적인 공급망 공격(Supply Chain Attack) 위험에 처해 있습니다. Dependabot은 점점 정교해지고 있는 공급망 공격을 방어하고, 알려진 보안 취약점으로부터 프로젝트를 지킬 수 있는 강력한 보안 도구입니다.

Dependabot을 통한 안전한 의존성 관리

롱블랙 프렌즈 C 여러분은 일할 때 가장 설레는 순간이 언제세요? 저는 어디서도 듣지 못한 이야기를 접했을 때예요! 2025년 4월 30일에 열린 <롱블랙 스토리 컨퍼런스 2025

스토리 2025 : 반짝거림에 기대지 않는, 스토리텔러 8인의 이야기 발견법

1️⃣ 불편한데 그래야만 할까?

“어느 시대든 성공한 비즈니스에는 그 업계의 감수성과 상식이라는 게 존재합니다. 그 상식에 도전하고, 부수면서 나아가는 것. 그것이 우리의 역할입니다. 그래서 우리는 기획할 때 ‘기성세대가 품은 상식을 어떻게 돌파할 수 있을지’를 중요하게 보죠.” - 다카하시 야스노리 CCC CEO (CCC는 일본의 1위 서점 츠타야 운영사)

① 왜 서점에는 책 파는 진열장만 있는 걸까? → ‘머무는 공간’을 만들기 위해 서점과 스타벅스를 경계 없이 융합했다.

② 왜 가전 매장은 할인 위주의 판매에만 집중할까? → ‘상상할 수 있는 공간’을 만들기 위해 고객이 가전제품을 체험할 수 있는 매장, 츠타야 일렉트릭스를 제안했다.

③ 왜 은행은 번화한 곳에 있는데 주말마다 문을 닫을까? → ‘가고 싶은 공간’을 만들기 위해 은행 영업시간 외에 문을 여는 공유오피스, 쉐어 라운지를 기획했다.

2️⃣ 아파트에 전기차 충전기를 설치하기 위한 솔루션, '출차 알림 시계'

2023년에 만든 ‘출차 알림 시계’를 소개했어요. 아파트의 이중주차 문제를 해결하기 위해, 차 위에 ‘나의 출차 시간’을 표시할 수 있는 시계였어요. 표시된 시간보다 먼저 나갈 차는 그 앞에 이중주차를 할 수 있게 한 거였죠.

"현장에 가니 답이 쉽게 보였어요. 이중주차 문제로 싸움까지 나는 아파트가 적잖았거든요. 주차 공간도 부족한데 전기차 충전기를 놓자고 하면? 당연히 반대가 나올 만했어요. 그래서 사람들의 근본적인 괴로움을 풀 방법을 찾았습니다. 그렇게 출차 알림 시계를 떠올렸죠. 이렇게 저는 누군가의 문제를 발견해 해결할 수 있다면, 형식이나 표현 방식에 제약을 둘 필요가 없다고 생각합니다. 눈에 보이는 모든 것을 미디어 삼아 광고할 수 있죠.” - 이승재 아이디엇 대표

https://www.longblack.co/note/1438?ticket=NT25205127e745725a7423751d7cce7b464a39

1️⃣ 불편한데 그래야만 할까? “어느 시대든 성공한 비즈니스에는 그 업계의 감수성과 상식이라는 게 존재합니다. 그 상식에 도전하고, 부수면서 나아가는 것. 그것이 우리의 역할입니다. 그래서 우리는 기획할 때 ‘기성세대가 품은 상식을 어떻게 돌파할 수 있을지’를 중요하게 보죠.” - 다카하시 야스노리 CCC CEO (CCC는 일본의 1위 서점 츠타야 운영사) ① 왜 서점에는 책 파는 진열장만 있는 걸까? → ‘머무는 공간’을 만들기 위해 서점과 스타벅스를 경계 없이 융합했다. ② 왜 가전 매장은 할인 위주의 판매에만 집중할까? → ‘상상할 수 있는 공간’을 만들기 위해 고객이 가전제품을 체험할 수 있는 매장, 츠타야 일렉트릭스를 제안했다. ③ 왜 은행은 번화한 곳에 있는데 주말마다 문을 닫을까? → ‘가고 싶은 공간’을 만들기 위해 은행 영업시간 외에 문을 여는 공유오피스, 쉐어 라운지를 기획했다. 2️⃣ 아파트에 전기차 충전기를 설치하기 위한 솔루션, '출차 알림 시계' 2023년에 만든 ‘출차 알림 시계’를 소개했어요. 아파트의 이중주차 문제를 해결하기 위해, 차 위에 ‘나의 출차 시간’을 표시할 수 있는 시계였어요. 표시된 시간보다 먼저 나갈 차는 그 앞에 이중주차를 할 수 있게 한 거였죠. "현장에 가니 답이 쉽게 보였어요. 이중주차 문제로 싸움까지 나는 아파트가 적잖았거든요. 주차 공간도 부족한데 전기차 충전기를 놓자고 하면? 당연히 반대가 나올 만했어요. 그래서 사람들의 근본적인 괴로움을 풀 방법을 찾았습니다. 그렇게 출차 알림 시계를 떠올렸죠. 이렇게 저는 누군가의 문제를 발견해 해결할 수 있다면, 형식이나 표현 방식에 제약을 둘 필요가 없다고 생각합니다. 눈에 보이는 모든 것을 미디어 삼아 광고할 수 있죠.” - 이승재 아이디엇 대표 https://www.longblack.co/note/1438?ticket=NT25205127e745725a7423751d7cce7b464a39

LongBlack

⟪스토리를 만드는 사람들⟫

2019년 2월 7일, 브런치에 첫 글이 발행 되었습니다. 매일 치열하게 고민한 것들이 휘발되는 것이 아깝기도 했고, 새로운 자극이 필요한 시기이기도 했습니다. 그렇게 브런치는 디자인 일기장 같은 공간이 되었습니다.

요즘처럼 트래픽이 흔해진 시대에, 6년간 151편의 글, 100만이라는 숫자가 자랑할 만한 일인지는 모르겠습니다. 다만 디자인이라는 단일 주제로 꾸준히 기록하며 여기까지 왔다는 것에서는 의미를 부여하고 싶습니다.

그 사이 세 권의 책을 냈고, 훌륭한 디자이너 분들과 소중한 교류의 기회를 얻었습니다. 좋은 기업들을 거쳐 현재는 독립을 했습니다. 돌아보니 그 여정 가운데 브런치와 글쓰기가 있었습니다.

긴 시간 제 글을 읽어주고 반응해준 분들께 감사함이 큽니다. 앞으로도 계속 디자인과 디자이너에 대한 기록을 이어가고자 합니다.

2019년 2월 7일, 브런치에 첫 글이 발행 되었습니다. 매일 치열하게 고민한 것들이 휘발되는 것이 아깝기도 했고, 새로운 자극이 필요한 시기이기도 했습니다. 그렇게 브런치는 디자인 일기장 같은 공간이 되었습니다. 요즘처럼 트래픽이 흔해진 시대에, 6년간 151편의 글, 100만이라는 숫자가 자랑할 만한 일인지는 모르겠습니다. 다만 디자인이라는 단일 주제로 꾸준히 기록하며 여기까지 왔다는 것에서는 의미를 부여하고 싶습니다. 그 사이 세 권의 책을 냈고, 훌륭한 디자이너 분들과 소중한 교류의 기회를 얻었습니다. 좋은 기업들을 거쳐 현재는 독립을 했습니다. 돌아보니 그 여정 가운데 브런치와 글쓰기가 있었습니다. 긴 시간 제 글을 읽어주고 반응해준 분들께 감사함이 큽니다. 앞으로도 계속 디자인과 디자이너에 대한 기록을 이어가고자 합니다.

브런치에서의 6년, 그리고 100만뷰

📰 인공지능만으로 운영된 스타트업의 실패

카네기 멜론 대학교의 연구자들은 “TheAgentCompany”라는 회사를 만들었다. 이 회사는 AI 모델들이 소프트웨어 엔지니어, 재무 분석가, 프로젝트 매니저로 일하는 곳.

인공지능 직원들은 인터넷에서 정보를 찾고, 사내 규정집을 참고하며, 웹사이트와 슬랙 같은 채팅 프로그램을 사용하고, 코드도 작성하고, 스프레드시트로 정보를 정리하고, ‘동료’들과 소통까지 했다.

그래서 결과는 어땠을까? 실패했다. 거의 코미디 수준으로.

인공지능 직원들은 회의하는 데 탁월했고 엄청나게 많은 회의를 했다. 내부 갈등도 많았다. 그리고 결국 아무 제품도 만들어내지 못했다. 우리가 맹목적으로 신뢰하는 인공지능이 회사를, 그것도 스타트업을 운영하면 어떻게 될까? 그 대답은 출시 제품 없이 실패하는 것이었다.

마치 스타트업에 관한 코미디 쇼의 패러디 같았다.

—

아니 근데, 이건 패러디 같은게 아니라 걍 인간 세상에 늘 있는 일인데요?..(…)

📰 인공지능만으로 운영된 스타트업의 실패 카네기 멜론 대학교의 연구자들은 “TheAgentCompany”라는 회사를 만들었다. 이 회사는 AI 모델들이 소프트웨어 엔지니어, 재무 분석가, 프로젝트 매니저로 일하는 곳. 인공지능 직원들은 인터넷에서 정보를 찾고, 사내 규정집을 참고하며, 웹사이트와 슬랙 같은 채팅 프로그램을 사용하고, 코드도 작성하고, 스프레드시트로 정보를 정리하고, ‘동료’들과 소통까지 했다. 그래서 결과는 어땠을까? 실패했다. 거의 코미디 수준으로. 인공지능 직원들은 회의하는 데 탁월했고 엄청나게 많은 회의를 했다. 내부 갈등도 많았다. 그리고 결국 아무 제품도 만들어내지 못했다. 우리가 맹목적으로 신뢰하는 인공지능이 회사를, 그것도 스타트업을 운영하면 어떻게 될까? 그 대답은 출시 제품 없이 실패하는 것이었다. 마치 스타트업에 관한 코미디 쇼의 패러디 같았다. — 아니 근데, 이건 패러디 같은게 아니라 걍 인간 세상에 늘 있는 일인데요?..(…)

📰 인공지능만으로 운영된 스타트업의 실패

카네기 멜론 대학교의 

ChatGPT의 Deep Researh에 GitHub을 연결 할 수 있게 되었군요!

와우! 대박! 와우! 대박적! 지금 만나러갑니다!

ChatGPT의 Deep Researh에 GitHub을 연결 할 수 있게 되었군요! 와우! 대박! 와우! 대박적! 지금 만나러갑니다!

ChatGPT의 Deep Researh에 GitHub을 연결 할 

www.55check.com공유하기게시하기웹에서 보기#레오 14세 즉위Cubs 팬 or Sox 팬? 새 교황님의 신상을 털어보자한국시간 금요일 새벽, 미국 시카고 출신의 로버트 프레보스트(Robert Prevost, 69) 추기경이 가톨릭 교회의 새 교황으로 선출. 레오 14세로 즉위. (첫 등장 영상. 소리 on 필수)레오 14세는 여러 면에서 독특한데,사진에도 보듯 흑인 + 백인 혼혈이심. 놀랍게도 노스트라다무스가 예언(!)고향 미국은 가톨릭 국가도 아님. (개신교 40%, 가톨릭 20%)페루에서 오랫동안 선교활동을 해서 미국-페루-바티칸 3중 국적 보유.영국 출신 하드리아노 4세(1154년~1159년 재위) 이후 두 번째로 영어가 모국어인 교황.800년 역사를 가진 아우구스띠노 수도회의 첫 교황. 이 수도회의 유명 멤버로는 종교개혁을 이끈 마르틴 루터(파문당함), 완두콩 덕후 그레고어 멘델, 철학자 에라스무스 등.레오14세는 레오13세(1878~1903)을 롤모델로 삼아 고른 이름으로 추측. 레오13세는 교회가 현대사회에 맞게 공장노동자들에게 더 다가가야한다고 주장했던 사람.코스트코에서 본 듯?레오 14세는 미국 출신이시다보니 이전 교황들보다 신비감은 떨어지고 좀 친근하게 느껴짐.아버지는 2차대전 해군 참전용사 출신이며 공립학교 교장. 어머니는 도서관 사서이며 독실한 가톨릭 신자.성직자가 되기 전 펜실베니아 주에 있는 명문 빌라노바대 수학과 전공. 이 학교 재학생들의 반응.MLB 시카고 컵스 팬이라는 소문이 돌았으나

2025년 5월 9일 (금) - 새 교황님 신상털기 총정리 : 오호츠크 리포트

OpenAI, 코딩 AI 서비스 Windsurf 인수

 * 금액은 4.2조원. 2025년 AI 스타트업 업계 첫 1조원 이상의 딜.
 * 현재 연간 반복 매출(ARR)은 560억원. 비슷한 코드에디터 기반의 경쟁사인 Cursor는 2년 만에 연매출 1억 달러(1400억원) 돌파해 주목 받아.
 * Windsurf는 프로그램 코드를 자동으로 짜주는 에디터 서비스. OpenAI는 윈드서프를 AI 에이전트와 연동해 문서 작성, 메모장, 노션 같은 기능의 생산성 도구 출시할 듯.
 * 또 웹 검색해 자료 정리하고, 그래프도 자동 제작하고, 이를 하나의 문서로 만들어주는 통합 도구까지 만들 듯. MS 오피스에 도전하기 위한 밑밥.
   
OpenAI 기업 구조 대변신, 그러나 마이크로소프트는 반대

 * OpenAI가 기존과 연결되는 새로운 회사 구조 발표. 기존 영리법인(LLC)을 공익법인(PBC)으로 전환 예정.
 * 최근 소프트뱅크(56조)와 마이크로소프트(13조)가 이 영리법인에 투자했었는데, 이번 회사 구조를 변경하는데 있어서 마이크로소프트가 반대하고 나섰음.
 * 핵심 이슈는 수익 배분. 2030년까지 매출의 20%를 인프라 사용료로 MS에 줄 예정이었으나 공익법인으로 바꾸면서 그 액수를 반으로 줄이겠다는 계획
 * 한편 OpenAI는 창업자 일론 머스크와도 소송 중. 머스크는 "비영리로 운영하겠다고 해서 돈도 주고 밀어줬는데, 영리 추구해 계약 위반했다" 주장.
 * 계약서에 명시된 내용이라 OpenAI에게 여러모로 골치 아픈 상황. 비영리냐 영리냐의 정체성 혼란.

아마존, 클라우드 시장을 넘어 우주 시장으로.

 * 아마존이 저궤도 위성 발사로 위성 기반 인터넷 제공 사업 본격화. 프로젝트명 카이퍼(Kuiper).
 * 최대 2600km 떨어진 위성끼리 안정적 양방향 링크 유지 가능. 이번에 27개 위성 탑재해 발사 및 연결 완료.
 * 최종 목표는 3200개 위성 연결로 지구 상당 부분 커버. 이미 80번 이상의 발사 예정
 * 흥미로운 점: 계열사인 블루오리진 로켓에 의존하지 않고 다른 회사 로켓들을 더 활용한다는 계획.
 * 저궤도 위성 인터넷은 해상 선박, 오지에서도 연결 가능한 아직 블루오션 시장. 일론 머스크의 스타링크가 압도적 1위. 2024년 기준 7135개 위성 띄워 전 세계에 서비스 제공 중. 우크라이나에서도 쓰고 각종 선박과 항공기들도 사용.
 * 블루 오리진은 SpaceX와 맞불, 아마존은 스타링크와 맞불. 아마존은 손해를 감수하고서라도 대량으로 밀어붙이는 스타일의 회사라 앞으로 위성 인터넷 시장의 경쟁 심화될 듯.

https://55check.com/newsletters?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=163564390&t=board

OpenAI, 코딩 AI 서비스 Windsurf 인수 <ul ><li>금액은 4.2조원. 2025년 AI 스타트업 업계 첫 1조원 이상의 딜.</li><li>현재 연간 반복 매출(ARR)은 560억원. 비슷한 코드에디터 기반의 경쟁사인 Cursor는 2년 만에 연매출 1억 달러(1400억원) 돌파해 주목 받아.</li></ul><ul ><li>Windsurf는 프로그램 코드를 자동으로 짜주는 에디터 서비스. OpenAI는 윈드서프를 AI 에이전트와 연동해 문서 작성, 메모장, 노션 같은 기능의 생산성 도구 출시할 듯.</li><li>또 웹 검색해 자료 정리하고, 그래프도 자동 제작하고, 이를 하나의 문서로 만들어주는 통합 도구까지 만들 듯. MS 오피스에 도전하기 위한 밑밥. </li></ul>OpenAI 기업 구조 대변신, 그러나 마이크로소프트는 반대 <ul ><li>OpenAI가 기존과 연결되는 새로운 회사 구조 발표. 기존 영리법인(LLC)을 공익법인(PBC)으로 전환 예정.</li><li>최근 소프트뱅크(56조)와 마이크로소프트(13조)가 이 영리법인에 투자했었는데, 이번 회사 구조를 변경하는데 있어서 마이크로소프트가 반대하고 나섰음.</li><li>핵심 이슈는 수익 배분. 2030년까지 매출의 20%를 인프라 사용료로 MS에 줄 예정이었으나 공익법인으로 바꾸면서 그 액수를 반으로 줄이겠다는 계획</li><li>한편 OpenAI는 창업자 일론 머스크와도 소송 중. 머스크는 "비영리로 운영하겠다고 해서 돈도 주고 밀어줬는데, 영리 추구해 계약 위반했다" 주장.</li><li>계약서에 명시된 내용이라 OpenAI에게 여러모로 골치 아픈 상황. 비영리냐 영리냐의 정체성 혼란.</li></ul> 아마존, 클라우드 시장을 넘어 우주 시장으로. <ul ><li>아마존이 저궤도 위성 발사로 위성 기반 인터넷 제공 사업 본격화. 프로젝트명 카이퍼(Kuiper).</li><li>최대 2600km 떨어진 위성끼리 안정적 양방향 링크 유지 가능. 이번에 27개 위성 탑재해 발사 및 연결 완료.</li><li>최종 목표는 3200개 위성 연결로 지구 상당 부분 커버. 이미 80번 이상의 발사 예정</li><li>흥미로운 점: 계열사인 블루오리진 로켓에 의존하지 않고 다른 회사 로켓들을 더 활용한다는 계획.</li><li>저궤도 위성 인터넷은 해상 선박, 오지에서도 연결 가능한 아직 블루오션 시장. 일론 머스크의 스타링크가 압도적 1위. 2024년 기준 7135개 위성 띄워 전 세계에 서비스 제공 중. 우크라이나에서도 쓰고 각종 선박과 항공기들도 사용.</li><li>블루 오리진은 SpaceX와 맞불, 아마존은 스타링크와 맞불. 아마존은 손해를 감수하고서라도 대량으로 밀어붙이는 스타일의 회사라 앞으로 위성 인터넷 시장의 경쟁 심화될 듯.</li></ul> https://55check.com/newsletters?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&amp;bmode=view&amp;idx=163564390&amp;t=board

5월 둘째주 - OpenAI 인수부터 마소에 반기까지. 다 하는군

주니어 개발자가 읽어보면 좋을 기술 블로그 글들과 포인트에 대해서 이야기해 보고자 한다.

주니어 개발자들이 읽으면 좋은 테크 아티클 모음

F-Lab 에서 주니어 개발자들이(사실 개발자라면 누구나) 보시면 좋을 아티클 모음을 공유해 주었네요!

검색엔진부터 비동기 처리, NoSQL 등 다양한 분야의 아티클들이 공유되어 있으니 관심있으신 분들은 보시면 좋겠습니다.

F-Lab 에서 공유해주신 아티클 주제를 나열해보면 다음과 같습니다.

📌 구글이 직접 말하는 검색엔진의 원리 (tali.kr)
📌 검색 엔진은 어떻게 작동하는가 (xo.dev)
📌 네이버의 검색엔진의 특징과 알고리즘 (tistory.com)
📌 [네이버 블로그]네이버 검색의 원리 : 네이버 블로그 (naver.com)
📌 지마켓 대기열 시스템 파헤치기 (gmarket.com)
📌 인증/인가는 어디에 어떻게 구현해야 할까? (gmarket.com)
📌 Sharded MySQL Cluster 도입 배경과 개발기 (부제: 우당탕탕 좌충우돌 개발기) (gmarket.com)
📌 웹 브라우저에 URL을 입력하면 어떤 일이 생기나요? | Amazon Web Services 한국 블로그
📌 네이버 메인 페이지의 트래픽 처리 (naver.com)
📌 How Discord Stores Trillions of Messages
📌 What ScyllaDB Is and Why You Should Care | by Mottakin Chowdhury | Better Programming
📌 How Discord Supercharges Network Disks for Extreme Low Latency
📌 비동기 서버에서 이벤트 루프를 블록하면 안 되는 이유
📌 카카오가 직접 회고한 1015 장애사태 원인과 대책 (brunch.co.kr)
📌 Lessons learned from operating our data serving layer | Coupang engineering | Coupang Engineering Blog (medium.com)
📌 The Missing Semester of Your CS Education (mit.edu)
📌 고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들 (slideshare.net)

F-Lab : 상위 1% 개발자들의 멘토링

주니어 개발자들이 읽으면 좋은 테크 아티클 모음📚

'BTS' 빅히트 엔터테인먼트, 상장한다

BTS의 빅히트엔터테인먼트 기업공개 작업 착수

주관사입찰제안서(RFP)는 국내 2개사(NH투자증권, 한국투자증권)과 외국계 2개사(Citi, JP모건)에만 발송

국내 빅3 엔터사-SM, JYP, YG-의 PER 25-40배 적용 시 2조 원 이상의 상장 밸류 인정 가능

2대 주주 넷마블(25.22%) 2018년 투자 당시 기업가치는 약 8,000억 원 


댓글 0

함께 읽은 게시물

개발자의 장애 공유 문화

《전업 소설가로서 방법을 찾지 않으면 안 되었다》

《어중간한 실패가 남기는 후회》

그림자로 마케팅하는 맥주 브랜드 Brahma의 기발한 옥외광고 활용법

< '네이버 다녀요'라는 말에 아무도 무슨 일을 하는지는 묻지 않았다 >

주간 인기 TOP 10