요즘 개발자는 단순히 뛰어난 코드를 작성하는 것만으로는 성공하기 어렵습니다. 저 역시 주니어 개발자일 때, 능력의 부족함을 많이 느꼈습니다. 다만 그때는 ‘일잘러’가 된다기보다 개발 스킬을 키우려고만 노력했습니다. 그래서인지 기술적인 측면에서 성장했지만 능력만큼 인정받지 못하거나 때로는 같이 일하기 힘들다는 말을 듣기도 했습니다. 다른 개발자들도 어떠한 계기가 있어, 조금이라도 빨리 이러한 측면에 관심을 가지고 시도해 봤으면 좋겠다는 생각이 들었습니다. 그런 마음에 이 글을 쓰기 시작했습니다. 개발자도 ‘일잘러’가 되어야 하는 이유와 커리어 단계별로 필요한 역량, 주니어를 위한 성장 가이드를 정리했습니다.

개발자도 ‘일잘러’가 되어야 하는 이유 | 요즘IT

개발자로 커리어를 이어가다 보면 주니어, 미드 레벨, 시니어 단계에 따라 조금은 다른 역량이 요구되는 것을 느낄 수 있습니다. 주니어 개발자부터 미드 레벨, 시니어 개발자 각각의 영역마다 요구되는 역량의 차이가 있습니다.

개발자도 ‘일잘러’가 되어야 하는 이유와 커리어 단계별로 필요한 역량, 주니어를 위한 성장 가이드 내용이 있어 공유해봅니다. 보다 자세한 내용은 원문 링크를 참고해주시기 바랍니다.

> 왜 ‘일잘러’가 되어야 할까?: 개발자의 역할 변화
 * 코드 작성이 전부였던 과거
 * 협업과 문제 해결 능력이 중요해진 현재

> ‘일잘러’의 첫 번째 역량: 효율적인 커뮤니케이션
 * 주니어 개발자: 기본적인 커뮤니케이션 능력 기르기
 * 미드 레벨 개발자: 협력과 조율의 중추 역할 맡기
 * 시니어 개발자: 전략적 소통과 의사결정의 주체로

> ‘일잘러’의 두 번째 역량: 문제 해결과 우선순위 관리
 * 주니어 개발자: 기술적 문제 해결 능력 키우기
 * 미드 레벨 개발자: 여러 문제의 우선순위 관리하기
 * 시니어 개발자: 전략적 문제 해결과 리스크 관리하기

> ‘일잘러’의 세 번째 역량: 팀워크와 리더십
 * 주니어 개발자: 협업/협력하는 방법 학습하기
 * 미드 레벨 개발자: 팀 내에서 리더십을 발휘해 보기
 * 시니어 개발자: 팀 전체를 이끄는 리더십 갖추기

> 기술 외적인 역량이 경력에 미치는 영향
 * 소프트 스킬의 중요성 인식
 * 프로젝트를 성공적으로 이끌고 다른 개발자와 협업하는 능력
 * 비즈니스 관점에서의 통찰력

> ‘일잘러’를 꿈꾸는 주니어 개발자를 위한 가이드
 * 어떤 마음가짐을 가질까?
   * 매일 조금씩이라도 새로운 것을 배우고, 안다고 생각한 것도 깊이 파고드는 태도가 중요합니다.
   * 실수를 두려워하기보다 시도하고, 동료나 선배들에게 적극적으로 피드백을 구해 보세요.
   * 큰 목표보다는 작은 목표를 설정하고 이를 꾸준히 달성해 나가는 것이 좋습니다.
 * 역량 향상을 위한 활동은 무엇이 있을까?
   * 개인 프로젝트는 실무에서 경험하지 못하는 기술을 다뤄보거나 새로운 아이디어를 실험할 좋은 기회입니다.
   * 오픈 소스 프로젝트에 기여해보는 것도 좋습니다.
   * 개발자 커뮤니티에 참여해 최신 트렌드를 공유하고 다른 개발자와 교류하는 것도 자극이 됩니다.
   * 글쓰기 역시 추천하는 활동입니다. 블로그에 학습 내용을 정리하고 공유하면 자기 학습의 깊이를 더할 수 있습니다.
 * 꾸준한 성장 마인드 셋은 어떻게 만들까?
   * 자신의 한계를 정해놓지 말고 꾸준히 발전하려는 자세를 유지하세요.
   * 자신의 경험을 공유하며 나보다 경력이 적은 개발자를 도와주는 것도 내 성장으로 돌아옵니다.
   * 마지막으로 추천하고 싶은 것은 멘토링입니다. 회사 내에 좋은 선배 개발자가 있다면 고민을 털어놓고 도움을 요청해 보세요.

 * source: https://yozm.wishket.com/magazine/detail/2785/

개발자로 커리어를 이어가다 보면 주니어, 미드 레벨, 시니어 단계에 따라 조금은 다른 역량이 요구되는 것을 느낄 수 있습니다. 주니어 개발자부터 미드 레벨, 시니어 개발자 각각의 영역마다 요구되는 역량의 차이가 있습니다. 개발자도 ‘일잘러’가 되어야 하는 이유와 커리어 단계별로 필요한 역량, 주니어를 위한 성장 가이드 내용이 있어 공유해봅니다. 보다 자세한 내용은 원문 링크를 참고해주시기 바랍니다. &gt; 왜 ‘일잘러’가 되어야 할까?: 개발자의 역할 변화<ul ><li>코드 작성이 전부였던 과거</li><li>협업과 문제 해결 능력이 중요해진 현재</li></ul> &gt; ‘일잘러’의 첫 번째 역량: 효율적인 커뮤니케이션<ul ><li>주니어 개발자: 기본적인 커뮤니케이션 능력 기르기</li><li>미드 레벨 개발자: 협력과 조율의 중추 역할 맡기</li><li>시니어 개발자: 전략적 소통과 의사결정의 주체로</li></ul> &gt; ‘일잘러’의 두 번째 역량: 문제 해결과 우선순위 관리<ul ><li>주니어 개발자: 기술적 문제 해결 능력 키우기</li><li>미드 레벨 개발자: 여러 문제의 우선순위 관리하기</li><li>시니어 개발자: 전략적 문제 해결과 리스크 관리하기</li></ul> &gt; ‘일잘러’의 세 번째 역량: 팀워크와 리더십<ul ><li>주니어 개발자: 협업/협력하는 방법 학습하기</li><li>미드 레벨 개발자: 팀 내에서 리더십을 발휘해 보기</li><li>시니어 개발자: 팀 전체를 이끄는 리더십 갖추기</li></ul> &gt; 기술 외적인 역량이 경력에 미치는 영향<ul ><li>소프트 스킬의 중요성 인식</li><li>프로젝트를 성공적으로 이끌고 다른 개발자와 협업하는 능력</li><li>비즈니스 관점에서의 통찰력</li></ul> &gt; ‘일잘러’를 꿈꾸는 주니어 개발자를 위한 가이드<ul ><li>어떤 마음가짐을 가질까?<ul ><li>매일 조금씩이라도 새로운 것을 배우고, 안다고 생각한 것도 깊이 파고드는 태도가 중요합니다.</li><li>실수를 두려워하기보다 시도하고, 동료나 선배들에게 적극적으로 피드백을 구해 보세요.</li><li>큰 목표보다는 작은 목표를 설정하고 이를 꾸준히 달성해 나가는 것이 좋습니다.</li></ul></li><li>역량 향상을 위한 활동은 무엇이 있을까?<ul ><li>개인 프로젝트는 실무에서 경험하지 못하는 기술을 다뤄보거나 새로운 아이디어를 실험할 좋은 기회입니다.</li><li>오픈 소스 프로젝트에 기여해보는 것도 좋습니다.</li><li>개발자 커뮤니티에 참여해 최신 트렌드를 공유하고 다른 개발자와 교류하는 것도 자극이 됩니다.</li><li>글쓰기 역시 추천하는 활동입니다. 블로그에 학습 내용을 정리하고 공유하면 자기 학습의 깊이를 더할 수 있습니다.</li></ul></li><li>꾸준한 성장 마인드 셋은 어떻게 만들까?<ul ><li>자신의 한계를 정해놓지 말고 꾸준히 발전하려는 자세를 유지하세요.</li><li>자신의 경험을 공유하며 나보다 경력이 적은 개발자를 도와주는 것도 내 성장으로 돌아옵니다.</li><li>마지막으로 추천하고 싶은 것은 멘토링입니다. 회사 내에 좋은 선배 개발자가 있다면 고민을 털어놓고 도움을 요청해 보세요.</li></ul></li></ul> <ul ><li>source: https://yozm.wishket.com/magazine/detail/2785/</li></ul>

요즘IT

개발자도 ‘일잘러’가 되어야 하는 이유

동료에게 “놀랍지 않은 사람”이 되어보세요.

성과는 놀랍지만 일과는 예측 가능한 사람이 되어보세요.

예측 가능성은 상호 신뢰로 이어져요. 이후에는 척하면 척하는 팀이 되더라고요.

핵심은 주도적인 과정의 공유라고 생각해요. 여러분의 업무 과정을 애써 공유하세요.

공유했던 대로 업무를 끝낸 여러분을 보고 동료들은 ”역시! 믿고 있었다고!“라고, 생각할 거예요.

동료에게 “놀랍지 않은 사람”이 되어보세요. 성과는 놀랍지만 일과는 예측 가능한 사람이 되어보세요. 예측 가능성은 상호 신뢰로 이어져요. 이후에는 척하면 척하는 팀이 되더라고요. 핵심은 주도적인 과정의 공유라고 생각해요. 여러분의 업무 과정을 애써 공유하세요. 공유했던 대로 업무를 끝낸 여러분을 보고 동료들은 ”역시! 믿고 있었다고!“라고, 생각할 거예요.

예측 가능한 사람되기

Hacktoberfest: a month-long celebration of open-source projects, their maintainers, and the entire community of contributors.

Hacktoberfest 2024

10월이면 시원한 바람과 함께 매년 찾아오는 핵토버페스트!

이제 공짜 티셔츠는 없지만 ^_ㅠ 그래도 오픈소스에 기여해보고싶다! 어떻게 하는지 우루루 할때 함께 해보고싶다! 하는 분들에게는 여전히 매력적인 시간입니다!

아직 2024에 뭔갈 더 이루고 싶은 개발자분들에게는 절호의 기회가 아닐까 싶어요!

https://hacktoberfest.com/

10월이면 시원한 바람과 함께 매년 찾아오는 핵토버페스트! 이제 공짜 티셔츠는 없지만 ^_ㅠ 그래도 오픈소스에 기여해보고싶다! 어떻게 하는지 우루루 할때 함께 해보고싶다! 하는 분들에게는 여전히 매력적인 시간입니다! 아직 2024에 뭔갈 더 이루고 싶은 개발자분들에게는 절호의 기회가 아닐까 싶어요! https://hacktoberfest.com/

hacktoberfest.com

핵토버페스트 2024

빅테크의 개발 문화는 여러분의 회사에 맞는 개발 문화를 찾아가는 과정에 참고 자료로만 활용하세요.

그들의 문화를 정답인 것처럼 그대로 받아들이기엔 체급이 너무 달라요.

여러분은 속한 회사에 맞는 문화를 직접 만들 수 있어요. 작은 회사라고 여러분이 만들어낸 문화의 가치도 작은 건 아니에요.

빅테크의 개발 문화는 여러분의 회사에 맞는 개발 문화를 찾아가는 과정에 참고 자료로만 활용하세요. 그들의 문화를 정답인 것처럼 그대로 받아들이기엔 체급이 너무 달라요. 여러분은 속한 회사에 맞는 문화를 직접 만들 수 있어요. 작은 회사라고 여러분이 만들어낸 문화의 가치도 작은 건 아니에요.

빅테크 개발 문화는 빅테크니까 가능한 일

How can small companies effectively identify and implement cultural values that align with their specific goals and team dynamics? https://buildnow-gg.io

완벽한 경영 교보재 | 온 가족이 모여서 이번 주에 올라온 흑백요리사 5~7화를 봤다. 지난주 4화까지 볼 때는 재밌다고만 생각했는데, 이번 5~7화 단체 미션은 팀워크나 리더십, 경영에 대해서도 교훈이 많아서 보면서 딸에게도 이런저런 이야기를 해주었다. 웃긴 건 하은이가 아직 초등학교 6학년인데도 저기는 팀장을 잘못 뽑았다느니 저러면 안 된다느니 공감하더라.  팀 대결 미션에서

흑백요리사 팀 대결에서 배우는 리더십과 팀워크

요즘 흑백요리사가 정말 화제인데요!
저도 나오는 날 3개씩 쭉쭉 보고 있습니다..ㅋㅋㅋㅋ 너무 재밌네요

보다 보면 최현석 셰프는 정말 예능에서 탐낼 완벽한 캐릭터인 것 같아요. 리더십도 좋고, 전문성도 있으면서 한없이 가벼워질 수도 있고 말도 재밌게 하고 방송 대결 주제를 요리만이 아닌 대결 플랫폼 자체를 이해하고 시작하죠.

리더십이 돋보이는 대결에서 배울 것이 많았습니다.
 1. 얻고자 하는 결과물(또는 성과)이 명확해야 한다.
 2. 리더는 결정을 내려야 한다.
 3. 결정했으면 따라야 한다.

https://brunch.co.kr/@younghakjang/157

요즘 흑백요리사가 정말 화제인데요!저도 나오는 날 3개씩 쭉쭉 보고 있습니다..ㅋㅋㅋㅋ 너무 재밌네요 보다 보면 최현석 셰프는 정말 예능에서 탐낼 완벽한 캐릭터인 것 같아요. 리더십도 좋고, 전문성도 있으면서 한없이 가벼워질 수도 있고 말도 재밌게 하고 방송 대결 주제를 요리만이 아닌 대결 플랫폼 자체를 이해하고 시작하죠. 리더십이 돋보이는 대결에서 배울 것이 많았습니다.<ol ><li>얻고자 하는 결과물(또는 성과)이 명확해야 한다.</li><li>리더는 결정을 내려야 한다.</li><li>결정했으면 따라야 한다.</li></ol> https://brunch.co.kr/@younghakjang/157

Brunch Story

링크드인 (LinkedIn) 프로필 최적화하기

빠른 노트 | Notion

안녕하세요, 데이터 리차드입니다.

저는 벌써 거의 4년째 링크드인을 사용하고 있는 헤비 유저입니다. 시간이 흐를수록, 링크드인(LinkedIn)에서 정말 다양한 전문가분들이 점차 많이 활동하는 것을 느끼고 있습니다. 하지만 아직 링크드인이 익숙하지 않거나, 좀 더 자신의 강점을 잘 나타내는 방법을 찾고 계시는 분들도 많은 것 같아요.

제가 느끼기에는 링크드인에서 커리어 브랜딩을 시작하는 데 가장 중요한 단계는 바로 프로필 최적화라고 생각합니다.

자신만의 최적화된 링크드인 프로필을 통해 고유의 전문성과 가치를 효과적으로 표현할 수 있습니다. 프로필 사진, 배너, 그리고 간결하면서도 핵심을 짚는 자기소개는 첫인상을 결정짓는 중요한 요소입니다.

배너 이미지, 프로필 사진, 그리고 자기소개 섹션을 어떻게 꾸미느냐에 따라 온라인에서 자신의 첫인상이 결정됩니다. 또한, 경력 사항과 프로젝트는 구체적이고 성과 중심으로 작성하는 것이 중요해요.

특히 자신의 강점을 강조하고 싶은 부분이 있다면 CTA(Call To Action)를 설정하는 것이 좋아요. 프로필 방문자들이 CTA를 통해 쉽게 이력서나 포트폴리오를 탐색할 수 있도록 유도하는 문구를 추가하세요.

어떻게 시작할 수 있을 지 아직까지도 막막하다면,
저의 세컨드 브레인에서 작성한 [🔗링크드인 프로필 최적화 가이드]를 한번 살펴보세요.

아래 링크에서 프로필 가이드를 확인하고, 링크드인에서 자신만의 프로필을 만들어보시길 바랍니다.

앞으로도 DATA/AI를 재미있고 가치있게 배울수 있도록 함께하는 데이터 리차드가 되겠습니다 :)

#데이터리차드 #커리어브랜딩 #링크드인최적화 #가이드

안녕하세요, 데이터 리차드입니다. 저는 벌써 거의 4년째 링크드인을 사용하고 있는 헤비 유저입니다. 시간이 흐를수록, 링크드인(LinkedIn)에서 정말 다양한 전문가분들이 점차 많이 활동하는 것을 느끼고 있습니다. 하지만 아직 링크드인이 익숙하지 않거나, 좀 더 자신의 강점을 잘 나타내는 방법을 찾고 계시는 분들도 많은 것 같아요. 제가 느끼기에는 링크드인에서 커리어 브랜딩을 시작하는 데 가장 중요한 단계는 바로 프로필 최적화라고 생각합니다. 자신만의 최적화된 링크드인 프로필을 통해 고유의 전문성과 가치를 효과적으로 표현할 수 있습니다. 프로필 사진, 배너, 그리고 간결하면서도 핵심을 짚는 자기소개는 첫인상을 결정짓는 중요한 요소입니다. 배너 이미지, 프로필 사진, 그리고 자기소개 섹션을 어떻게 꾸미느냐에 따라 온라인에서 자신의 첫인상이 결정됩니다. 또한, 경력 사항과 프로젝트는 구체적이고 성과 중심으로 작성하는 것이 중요해요. 특히 자신의 강점을 강조하고 싶은 부분이 있다면 CTA(Call To Action)를 설정하는 것이 좋아요. 프로필 방문자들이 CTA를 통해 쉽게 이력서나 포트폴리오를 탐색할 수 있도록 유도하는 문구를 추가하세요. 어떻게 시작할 수 있을 지 아직까지도 막막하다면, 저의 세컨드 브레인에서 작성한 [🔗링크드인 프로필 최적화 가이드]를 한번 살펴보세요. 아래 링크에서 프로필 가이드를 확인하고, 링크드인에서 자신만의 프로필을 만들어보시길 바랍니다. 앞으로도 DATA/AI를 재미있고 가치있게 배울수 있도록 함께하는 데이터 리차드가 되겠습니다 :) #데이터리차드 #커리어브랜딩 #링크드인최적화 #가이드

동찬 임's Notion on Notion

링크드인 프로필 최적화 방법을 소개합니다.

Imagine this: You’re an SRE, drowning in a sea of direct messages. New databases, fresh regions, even the occasional “How to access this…

Why we skipped SRE and switched to Platform Engineering

Electrolux라는 유럽 가전 회사의 SRE 직군이 있다가 회사가 성장함에 따라 SRE 업무가 업무의 병목이 되어 갔다고 합니다.

회사 규모가 작을 때는 SaaS를 최대한 사용하도록 정책을 만들고 얻은 시간에 개발자가 요청하는 작업을 자동화하기 시작했다고 합니다. 처음에는 오픈소스인 Backstage를 도입해서 사용했으나 새로운 기능은 새로운 플러그인을 사용할 수 있지만 사용자들이 새로운 플러그인에 적응하는 것이 쉽지 않다는 것을 깨닫고 내부 개발자 플랫폼(IDP)를 만들기로 결정을 했다고 합니다.

이미 사용중인 Backstage의 Scaffolder 플러그인을 사용해서 UI까지 작성한 후에 직접 리소스를 만들 수 있게 되었습니다. 이후 IDP가 처리 못하는 리소스도 필요하다는 것을 깨달게 되어 InfraKitchen이라는 오픈소스 제품으로 IDP를 재구축해서 SRE에서 플랫폼 엔지니어링으로 전화하게 된 과정입니다.

https://medium.com/@kristina.kondrashevich/why-we-skipped-sre-and-switched-to-platform-engineering-b1f05979c6c6

Electrolux라는 유럽 가전 회사의 SRE 직군이 있다가 회사가 성장함에 따라 SRE 업무가 업무의 병목이 되어 갔다고 합니다. 회사 규모가 작을 때는 SaaS를 최대한 사용하도록 정책을 만들고 얻은 시간에 개발자가 요청하는 작업을 자동화하기 시작했다고 합니다. 처음에는 오픈소스인 Backstage를 도입해서 사용했으나 새로운 기능은 새로운 플러그인을 사용할 수 있지만 사용자들이 새로운 플러그인에 적응하는 것이 쉽지 않다는 것을 깨닫고 내부 개발자 플랫폼(IDP)를 만들기로 결정을 했다고 합니다. 이미 사용중인 Backstage의 Scaffolder 플러그인을 사용해서 UI까지 작성한 후에 직접 리소스를 만들 수 있게 되었습니다. 이후 IDP가 처리 못하는 리소스도 필요하다는 것을 깨달게 되어 InfraKitchen이라는 오픈소스 제품으로 IDP를 재구축해서 SRE에서 플랫폼 엔지니어링으로 전화하게 된 과정입니다. https://medium.com/@kristina.kondrashevich/why-we-skipped-sre-and-switched-to-platform-engineering-b1f05979c6c6

Medium

You are being redirected...

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다.

# 소프트웨어 침식의 원인과 문제
 * 지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.
 * 불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.
 * 중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.

# 소프트웨어 침식을 방지하는 방법
 * 지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.
 * 품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.
 * 설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.

소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요?

https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다. # 소프트웨어 침식의 원인과 문제<ul ><li>지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.</li><li>불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.</li><li>중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.</li></ul> # 소프트웨어 침식을 방지하는 방법<ul ><li>지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.</li><li>품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.</li><li>설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.</li></ul> 소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요? https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

www.softwaretestingnews.co.uk

내 눈 앞에서 소프트웨어가 침식되고 있다

The idea of self-healing code with LLMs is exciting, but balancing automation and human oversight is still crucial.

How to Use Self-Healing Code to Reduce Technical Debt

자가 치유 코드라는 말도 등장했네요!! ㅎㅎ LLM 기반으로 AI 페어프로그래밍이 증가하게 되어 생산성이 오르는 듯 했지만, 너무 급진적인 적용으로 인해서 오히려 기술 부채가 쌓이고 있다는 이야기도 들었던 것 같습니다.

그렇다면 다시 LLM이 등장해서 해결해내겠죠? LLM을 이용하여 다시 소프트웨어 스스로 문제를 식별하고 수정해내는 방식을 자가 치유 코드라고 불리운다고 하네요. 하지만 문제를 만들어 낸 것이 AI 인 만큼 이에 대한 사람의 모니터링과 평가가 빠질 수 없고, 어디까지 목표로 할 것인가가 참 중요할 것 같습니다.

 * 2028년 기업 소프트웨어 엔지니어의 AI 코드 어시스턴트 사용 증가
   * 2023년 초 10% 미만에서 2028년 75%로 증가 예상
   * AI 사용은 워크플로우 간소화 및 생산성 향상에 기여
 * 기술 부채(Technical Debt)의 문제와 영향
   * 기술 부채는 빠른 해결책 선택에 따른 비용으로 생산성 저하를 초래
   * 개발 시간의 23%에서 43%가 기술 부채 문제 해결에 소모됨
   * 유지보수 비용 증가, 개발 속도 저하, 유연성 감소 문제 발생
 * AI 도구와 기술 부채
   * AI 도구의 급격한 통합이 기술 부채를 증가시킬 가능성 있음
   * 복잡한 모델이 유지보수 문제를 일으킬 수 있음
   * AI 도구를 올바르게 사용하면 기술 부채 감소 가능성 존재
 * LLM과 자가 치유 코드의 역할
   * LLM(대형 언어 모델) 시스템이 기술 부채 해결의 잠재적 솔루션으로 부상
   * 자가 치유 코드: 소프트웨어가 스스로 문제를 식별하고 수정
   * LLM 기반 코드 리뷰 도구는 코드 품질을 높일 수 있음
   * 버그 자동 수정, 코드 리팩토링 도구를 통한 성능 최적화 가능
 * 조직 내 기술 부채 감소를 위한 내부 프로세스
   * AI와 인간의 균형 잡힌 감독 필요
   * 수동 리뷰를 통해 AI 솔루션의 정확성과 프로젝트 목표 달성 보장
   * 지속적인 학습 기회를 제공해 직원들이 최신 도구와 기술을 익힐 수 있도록 지원
   * AWS 자격증과 같은 교육 프로그램과 보너스를 통한 추가 학습 장려
     
     
https://thenewstack.io/how-to-use-self-healing-code-to-reduce-technical-debt

자가 치유 코드라는 말도 등장했네요!! ㅎㅎ LLM 기반으로 AI 페어프로그래밍이 증가하게 되어 생산성이 오르는 듯 했지만, 너무 급진적인 적용으로 인해서 오히려 기술 부채가 쌓이고 있다는 이야기도 들었던 것 같습니다. 그렇다면 다시 LLM이 등장해서 해결해내겠죠? LLM을 이용하여 다시 소프트웨어 스스로 문제를 식별하고 수정해내는 방식을 자가 치유 코드라고 불리운다고 하네요. 하지만 문제를 만들어 낸 것이 AI 인 만큼 이에 대한 사람의 모니터링과 평가가 빠질 수 없고, 어디까지 목표로 할 것인가가 참 중요할 것 같습니다. <ul ><li>2028년 기업 소프트웨어 엔지니어의 AI 코드 어시스턴트 사용 증가<ul ><li>2023년 초 10% 미만에서 2028년 75%로 증가 예상</li><li>AI 사용은 워크플로우 간소화 및 생산성 향상에 기여</li></ul></li><li>기술 부채(Technical Debt)의 문제와 영향<ul ><li>기술 부채는 빠른 해결책 선택에 따른 비용으로 생산성 저하를 초래</li><li>개발 시간의 23%에서 43%가 기술 부채 문제 해결에 소모됨</li><li>유지보수 비용 증가, 개발 속도 저하, 유연성 감소 문제 발생</li></ul></li><li>AI 도구와 기술 부채<ul ><li>AI 도구의 급격한 통합이 기술 부채를 증가시킬 가능성 있음</li><li>복잡한 모델이 유지보수 문제를 일으킬 수 있음</li><li>AI 도구를 올바르게 사용하면 기술 부채 감소 가능성 존재</li></ul></li><li>LLM과 자가 치유 코드의 역할<ul ><li>LLM(대형 언어 모델) 시스템이 기술 부채 해결의 잠재적 솔루션으로 부상</li><li>자가 치유 코드: 소프트웨어가 스스로 문제를 식별하고 수정</li><li>LLM 기반 코드 리뷰 도구는 코드 품질을 높일 수 있음</li><li>버그 자동 수정, 코드 리팩토링 도구를 통한 성능 최적화 가능</li></ul></li><li>조직 내 기술 부채 감소를 위한 내부 프로세스<ul ><li>AI와 인간의 균형 잡힌 감독 필요</li><li>수동 리뷰를 통해 AI 솔루션의 정확성과 프로젝트 목표 달성 보장</li><li>지속적인 학습 기회를 제공해 직원들이 최신 도구와 기술을 익힐 수 있도록 지원</li><li>AWS 자격증과 같은 교육 프로그램과 보너스를 통한 추가 학습 장려 </li></ul></li></ul>https://thenewstack.io/how-to-use-self-healing-code-to-reduce-technical-debt

The New Stack

자가 치유 코드를 사용하여 기술 부채를 줄이는 방법

Prompt Engineering is Dead! Is it?

LLM 모델들이 하루가 다르게 더 발전된 모습을 보여주면서, 이제는 길게 프롬프트 엔지니어링 안해도 되는거 아니냐. 이제는 짧게 말해도 알아서 잘 알아듣던데?! 하는 의견들이 많이 들리는 것 같습니다.

이와는 반대로 프롬프트 엔지니어링이 죽지 않았으며, 오히려 AI 기술의 발전과 함께 더욱 중요해질 것이라고 주장하는 글을 읽어보았습니다. 프롬프트 엔지니어링의 형태는 변할 수 있지만, 그 본질적인 역할은 계속될 것이며, 더욱 정교하고 전문화된 기술로 발전할 것이라고 예측하고 있는데요. 여러분들의 생각은 어떠신가요?

 1. 프롬프트 엔지니어링의 중요성:
    * 단순한 작업보다는 복잡한 애플리케이션이나 데이터 과학 분야에서 더욱 중요합니다.
    * 모델이 정확하고 적절한 응답을 생성하도록 하는 데 필수적입니다.
    * 특히 비즈니스 맥락, 법적 요구사항, 윤리적 고려사항 등을 AI 모델에 전달하는 데 중요한 역할을 합니다.
 2. 프롬프트 엔지니어링이 "죽었다"는 주장들:
    * 모델이 더 똑똑해져서 간단한 지시만으로도 작업을 이해할 것이라는 주장
      * 예: GPT-4의 능력 향상으로 인한 기대
    * 개인화된 모델이 사용자의 요구를 더 잘 이해할 것이라는 예측
      * 예: 사용자의 과거 상호작용을 학습한 모델
    * 모델이 자체적으로 프롬프트를 생성하거나 개선할 것이라는 전망
      * 예: AutoGPT나 GPT-Engineer와 같은 도구
    * 에이전트 기반 AI가 복잡한 작업을 자동으로 처리할 것이라는 기대
      * 예: 여러 단계의 작업을 자동으로 수행하는 AI 에이전트
 3. 저자의 반박:
    * 모델의 능력이 향상될수록 더 복잡한 작업이 가능해지므로, 오히려 프롬프트 엔지니어링의 중요성이 커집니다.
      * 예: 법률 문서 분석이나 의료 진단 지원과 같은 고도의 전문성이 필요한 분야
    * 개인화된 모델도 여전히 구체적인 지시가 필요합니다.
      * 사용자의 의도를 정확히 파악하고 적절한 맥락을 제공하는 것은 여전히 중요
    * 자동 프롬프트 생성이나 최적화는 유용하지만, 인간의 의도를 완전히 이해하기는 어렵습니다.
      * 복잡한 비즈니스 로직이나 특수한 요구사항을 자동으로 파악하는 것은 여전히 한계가 있음
    * 에이전트 기반 AI도 복잡한 비즈니스 맥락에서는 상세한 지시가 필요합니다.
      * 예: 기업의 특정 정책이나 규정을 준수하면서 작업을 수행해야 하는 경우
 4. 프롬프트 프로그래밍의 미래:
    * 프롬프트를 프로그래밍 언어로 작성하는 방식이 등장하고 있습니다.
      * 예: Prompt flow, LangChain과 같은 도구들
    * 이는 프롬프트 최적화를 자동화할 수 있지만, 일반 사용자에게는 더 복잡할 수 있습니다.
    * 프롬프트 엔지니어링은 더 구조화되고 체계적인 형태로 발전할 것으로 예상됩니다.
 5. 프롬프트 엔지니어링의 진화:
    * 단순한 텍스트 입력에서 복잡한 구조와 맥락을 포함하는 방향으로 발전할 것입니다.
    * 도메인 특화 언어(DSL)나 시각적 프로그래밍 도구가 등장할 수 있습니다.
    * AI 모델과 인간 사용자 사이의 인터페이스 역할을 더욱 중요하게 수행할 것입니다.

https://ai.gopubby.com/prompt-engineering-is-dead-is-it-c99769315d81

LLM 모델들이 하루가 다르게 더 발전된 모습을 보여주면서, 이제는 길게 프롬프트 엔지니어링 안해도 되는거 아니냐. 이제는 짧게 말해도 알아서 잘 알아듣던데?! 하는 의견들이 많이 들리는 것 같습니다. 이와는 반대로 프롬프트 엔지니어링이 죽지 않았으며, 오히려 AI 기술의 발전과 함께 더욱 중요해질 것이라고 주장하는 글을 읽어보았습니다. 프롬프트 엔지니어링의 형태는 변할 수 있지만, 그 본질적인 역할은 계속될 것이며, 더욱 정교하고 전문화된 기술로 발전할 것이라고 예측하고 있는데요. 여러분들의 생각은 어떠신가요? <ol ><li>프롬프트 엔지니어링의 중요성:<ul ><li>단순한 작업보다는 복잡한 애플리케이션이나 데이터 과학 분야에서 더욱 중요합니다.</li><li>모델이 정확하고 적절한 응답을 생성하도록 하는 데 필수적입니다.</li><li>특히 비즈니스 맥락, 법적 요구사항, 윤리적 고려사항 등을 AI 모델에 전달하는 데 중요한 역할을 합니다.</li></ul></li><li>프롬프트 엔지니어링이 "죽었다"는 주장들:<ul ><li>모델이 더 똑똑해져서 간단한 지시만으로도 작업을 이해할 것이라는 주장<ul ><li>예: GPT-4의 능력 향상으로 인한 기대</li></ul></li><li>개인화된 모델이 사용자의 요구를 더 잘 이해할 것이라는 예측<ul ><li>예: 사용자의 과거 상호작용을 학습한 모델</li></ul></li><li>모델이 자체적으로 프롬프트를 생성하거나 개선할 것이라는 전망<ul ><li>예: AutoGPT나 GPT-Engineer와 같은 도구</li></ul></li><li>에이전트 기반 AI가 복잡한 작업을 자동으로 처리할 것이라는 기대<ul ><li>예: 여러 단계의 작업을 자동으로 수행하는 AI 에이전트</li></ul></li></ul></li><li>저자의 반박:<ul ><li>모델의 능력이 향상될수록 더 복잡한 작업이 가능해지므로, 오히려 프롬프트 엔지니어링의 중요성이 커집니다.<ul ><li>예: 법률 문서 분석이나 의료 진단 지원과 같은 고도의 전문성이 필요한 분야</li></ul></li><li>개인화된 모델도 여전히 구체적인 지시가 필요합니다.<ul ><li>사용자의 의도를 정확히 파악하고 적절한 맥락을 제공하는 것은 여전히 중요</li></ul></li><li>자동 프롬프트 생성이나 최적화는 유용하지만, 인간의 의도를 완전히 이해하기는 어렵습니다.<ul ><li>복잡한 비즈니스 로직이나 특수한 요구사항을 자동으로 파악하는 것은 여전히 한계가 있음</li></ul></li><li>에이전트 기반 AI도 복잡한 비즈니스 맥락에서는 상세한 지시가 필요합니다.<ul ><li>예: 기업의 특정 정책이나 규정을 준수하면서 작업을 수행해야 하는 경우</li></ul></li></ul></li><li>프롬프트 프로그래밍의 미래:<ul ><li>프롬프트를 프로그래밍 언어로 작성하는 방식이 등장하고 있습니다.<ul ><li>예: Prompt flow, LangChain과 같은 도구들</li></ul></li><li>이는 프롬프트 최적화를 자동화할 수 있지만, 일반 사용자에게는 더 복잡할 수 있습니다.</li><li>프롬프트 엔지니어링은 더 구조화되고 체계적인 형태로 발전할 것으로 예상됩니다.</li></ul></li><li>프롬프트 엔지니어링의 진화:<ul ><li>단순한 텍스트 입력에서 복잡한 구조와 맥락을 포함하는 방향으로 발전할 것입니다.</li><li>도메인 특화 언어(DSL)나 시각적 프로그래밍 도구가 등장할 수 있습니다.</li><li>AI 모델과 인간 사용자 사이의 인터페이스 역할을 더욱 중요하게 수행할 것입니다.</li></ul></li></ol> https://ai.gopubby.com/prompt-engineering-is-dead-is-it-c99769315d81

프롬프트 엔지니어링은 죽었다?

The guide to Git I never had.

Rebasing 과 Merging
Rebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.
 
Squashing
Git Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다.

Cherry-picking
Cherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다.

Signing commits
Signing commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다.

Git Reflog
Git references는 Git 히스토리의 명명된 지점으로, 사용자가 저장소의 타임라인을 탐색하고 프로젝트의 특정 스냅샷에 접근할 수 있게 합니다. Git references를 탐색하는 방법을 알고 있으면 유용하며, 이를 위해 git reflog를 사용할 수 있습니다. 다음과 같은 장점이 있습니다:
 * 잃어버린 커밋 또는 브랜치 복구
 * 디버깅 및 문제 해결
 * 실수 취소

Interactive rebase
인터랙티브 리베이스는 커밋 히스토리를 대화형으로 재작성할 수 있는 강력한 Git 기능입니다. 커밋을 적용하기 전에 수정, 재정렬, 결합, 삭제할 수 있습니다.

Origin vs Upstream
origin은 로컬 Git 저장소와 연관된 기본 원격 저장소입니다. 저장소를 복제(clone)하면 해당 복제본이 기본적으로 origin 원격 저장소로 설정됩니다. 저장소를 포크(fork)했다면, 그 포크가 기본적으로 origin 저장소가 됩니다.
 
반면, upstream은 저장소가 포크된 원래 저장소를 가리킵니다.
 
포크된 저장소를 원래 프로젝트의 최신 변경 사항과 동기화하려면 upstream 저장소에서 변경 사항을 가져와(git fetch) 로컬 저장소에 병합(merge)하거나 리베이스(rebase)해야 합니다.
 
Conflicts
브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.
 
Feature Branch Workflow
각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다.
 * 장점: 변경 사항의 격리 및 충돌 감소
 * 단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요

Gitflow Workflow
Gitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다.
 * 메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다.
 * 장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합
 * 단점: 소규모 팀에는 너무 복잡할 수 있음

Forking Workflow
이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다.
 * 이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다.
 * 장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지
 * 단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음

Pull Request Workflow
포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다.
 * 장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진
 * 단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음

Trunk-Based Development
빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다.
 * 장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중
 * 단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음
 
Git Cheatsheet
 
# Clone a Repository
git clone <repository_url>

# Stage Changes for Commit
git add <file(s)>

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch <branch_name>

# Switch to a Different Branch
git checkout <branch_name>

# Merge Changes from Another Branch
git merge <branch_name>

# Rebase Changes onto Another Branch (use with caution)
git rebase <base_branch>

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore <file(s)>

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3

 
번역: [https://ducktopia.tistory.com/134]
원문:

Rebasing 과 MergingRebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.&nbsp;SquashingGit Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다. Cherry-pickingCherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다. Signing commitsSigning commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다. Git ReflogGit references는 Git 히스토리의 명명된 지점으로, 사용자가 저장소의 타임라인을 탐색하고 프로젝트의 특정 스냅샷에 접근할 수 있게 합니다. Git references를 탐색하는 방법을 알고 있으면 유용하며, 이를 위해 git reflog를 사용할 수 있습니다. 다음과 같은 장점이 있습니다:<ul ><li>잃어버린 커밋 또는 브랜치 복구</li><li>디버깅 및 문제 해결</li><li>실수 취소</li></ul> Interactive rebase인터랙티브 리베이스는 커밋 히스토리를 대화형으로 재작성할 수 있는 강력한 Git 기능입니다. 커밋을 적용하기 전에 수정, 재정렬, 결합, 삭제할 수 있습니다. Origin vs Upstreamorigin은 로컬 Git 저장소와 연관된 기본 원격 저장소입니다. 저장소를 복제(clone)하면 해당 복제본이 기본적으로 origin 원격 저장소로 설정됩니다. 저장소를 포크(fork)했다면, 그 포크가 기본적으로 origin 저장소가 됩니다.&nbsp;반면, upstream은 저장소가 포크된 원래 저장소를 가리킵니다.&nbsp;포크된 저장소를 원래 프로젝트의 최신 변경 사항과 동기화하려면 upstream 저장소에서 변경 사항을 가져와(git fetch) 로컬 저장소에 병합(merge)하거나 리베이스(rebase)해야 합니다.&nbsp;Conflicts브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.&nbsp;Feature Branch Workflow각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다.<ul ><li>장점: 변경 사항의 격리 및 충돌 감소</li><li>단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요</li></ul> Gitflow WorkflowGitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다.<ul ><li>메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다.</li><li>장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합</li><li>단점: 소규모 팀에는 너무 복잡할 수 있음</li></ul> Forking Workflow이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다.<ul ><li>이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다.</li><li>장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지</li><li>단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음</li></ul> Pull Request Workflow포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다.<ul ><li>장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진</li><li>단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음</li></ul> Trunk-Based Development빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다.<ul ><li>장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중</li><li>단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음</li></ul>&nbsp;Git Cheatsheet&nbsp;<pre ><code class="language-bash"># Clone a Repository
git clone &lt;repository_url&gt;

# Stage Changes for Commit
git add &lt;file(s)&gt;

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch &lt;branch_name&gt;

# Switch to a Different Branch
git checkout &lt;branch_name&gt;

# Merge Changes from Another Branch
git merge &lt;branch_name&gt;

# Rebase Changes onto Another Branch (use with caution)
git rebase &lt;base_branch&gt;

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore &lt;file(s)&gt;

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3</code></pre>&nbsp;번역: [https://ducktopia.tistory.com/134]원문:

🕊️ [Medium] 내가 원했던, Git 가이드 (2)

돌이켜 생각해보면, 지금까지 꽤 많은 '인재 선발을 위한 인터뷰(면접)'를 진행했다. 대학교 시절 S&D 라는 경영학회 활동을 3~4년 하면서 '학회원 선발' 인터뷰를 진행했었고, 그 이후 BCG/Ringle 에서 다수 채용 인터뷰에 참여했다. 그리고, 컨설팅/MBA/스타트업에 입사하고자 했던 지인들의 mock interview를 도운것까지 합치면, '꽤 

기억에 남는 인터뷰(면접)의 특징

면접은 채용 과정에서 중요한 역할을 합니다. 서류 전형과 코딩 테스트를 후, 대부분의 최종 결정이 면접을 통해 이루어지기 때문인데요. 최근 ‘기억에 남는 인터뷰(면접)의 특징’ 이라는 글을 보게 되었는데, 공감도 되고 괜찮은 내용이라 소개드립니다.

 1. 아이컨택을 잘한다.
    아이컨택은 단순 시선 처리 이상의 의미를 갖습니다. 아이컨택을 통해 면접자는 진정성을 전달하고, 암기된 답변이 아닌 소통을 하고 있음을 보여줍니다. 사람은 논리적인 면보다 정서적인 공감에 더 강하게 반응하기 때문에, 이런 자연스러운 아이컨택은 더 깊은 인상을 남길 수 있습니다.
    
    
 2. 어설프게 논리적이지 않고, 자연스럽게 논리적이다.
    근거가 적절하며 자연스럽게 이어지는 대화속에서도 논리와 스토리가 묻어 있는 사람들이 있습니다. 이런 사람은 어설프게 연습해서 면접 답변을 하기 보다는, 평소 소통 방식에서도 자연스럽게 소통하면서 그 안에 구조적 사고와 논리적 표현이 내재화 되어 있음을 보여줍니다.
    
    
 3. 발표가 아닌 대화
    일방적인 발표를 하는 느낌으로 면접을 보는 분들이 많습니다. 그런 답변은 면접관 으로서 흥미와 공감이 떨어집니다. 반면 ‘대화가 통한다’는 느낌을 주는 분들이 있습니다. 핵심적인 답변을 짧고 명확 하게 하고, 인터뷰어는 다시 질문 - 답변 으로 티키타카 식의 소통은 면접관에게 ‘대화가 통한다’는 느낌을 주며, 면접의 전반적인 분위기도 생동감이 듭니다.
    
    
 4. 솔직함
    역량, 리더십, 품성 이 느껴지는 사람의 특징은 매우 솔직합니다. 시행착오나 실패도 덤덤하게 풀어내는 분들은 기억에 오래 남습니다. 이런 솔직함은 면접관에게 강한 신뢰감을 주는데요. 성공 스토리만큼이나 실패를 극복한 경험 역시 중요하기 때문입니다.
    
    
 5. 의지, 생각 보다는 경험
    의지나 생각은 그 사람의 본질이 아닙니다. 개인의 진정한 모습은 과거의 경험을 통해 가장 잘 드러나는데요. 과거 경험을 바탕으로 한 이야기는 면접관의 관심을 끌며, 면접관 자신의 경험 역시도 떠올리게 하여 더욱 깊이 있는 대화로 이어질 수 있습니다.
    
    
 6. 회사에 호기심을 가지고 있다
    회사, 제품에 호기심이 없는 사람은 입사를 하더라도 평범하게 일할 확률이 높습니다. 하지만 회사와 제품에 진정한 호기심을 보이는 면접자라면 입사 후에도 회사에 더 큰 기여를 할 수 있는 잠재력을 보여줍니다.
    
    
 7. 자세/태도가 모두 좋다.
    앉은 자세 및 태도(제스처) 도 중요한 평가 요소입니다. 안정된 자세, 적절한 제스처 는 중요한 비언어적 신호로써, 평소에도 이러한 태도로 일할 가능성이 높음을 시사하기 때문입니다.
    
    
 8. 질문도 한다.
    면접 과정에서도 중간에 질문을 하는 사람이 있습니다. 바로 질문해야 하는 타이밍에, 꼭 해야 할 질문을, 짧고 명확하게 하는 사람들인데요. 이런 질문으로 인해 면접관은 ‘똑똑하다’ 라는 인상을 받게 됩니다. 또한 올바른 질문을 잘 하는 사람은 향후 업무에서도 주체적이고 능동적으로 일할 확률이 높습니다.

개발자의 경우, 소통하는데 있어 솔직한 나의 모습을 직관적으로 전달하기 어려울 때가 있는데요. 결국에는 지속적인 연습과 피드백을 통해 자신의 진정한 모습을 효과적으로 전달할 수 있도록 노력하는 것이 중요할것 같습니다. 그리고 위에서 언급한 특징을 염두에 두고 준비한다면, 자신의 가치를 최대한 드러낼 수 있을 것입니다.

결국 중요한것은 자신의 경험과 역량을 진정성 있게 전달하면서도, 지원하는 회사와 직무에 대한 깊은 이해와 열정이 중요할 것 같습니다.이런 준비와 태도를 통해 면접관에게 깊은 인상을 남기며, 성공적인 면접 결과로 이어질 수 있습니다.

https://brunch.co.kr/@seunghoon82/559

면접은 채용 과정에서 중요한 역할을 합니다. 서류 전형과 코딩 테스트를 후, 대부분의 최종 결정이 면접을 통해 이루어지기 때문인데요. 최근 ‘기억에 남는 인터뷰(면접)의 특징’ 이라는 글을 보게 되었는데, 공감도 되고 괜찮은 내용이라 소개드립니다. <ol ><li>아이컨택을 잘한다.아이컨택은 단순 시선 처리 이상의 의미를 갖습니다. 아이컨택을 통해 면접자는 진정성을 전달하고, 암기된 답변이 아닌 소통을 하고 있음을 보여줍니다. 사람은 논리적인 면보다 정서적인 공감에 더 강하게 반응하기 때문에, 이런 자연스러운 아이컨택은 더 깊은 인상을 남길 수 있습니다. </li><li>어설프게 논리적이지 않고, 자연스럽게 논리적이다.근거가 적절하며 자연스럽게 이어지는 대화속에서도 논리와 스토리가 묻어 있는 사람들이 있습니다. 이런 사람은 어설프게 연습해서 면접 답변을 하기 보다는, 평소 소통 방식에서도 자연스럽게 소통하면서 그 안에 구조적 사고와 논리적 표현이 내재화 되어 있음을 보여줍니다. </li><li>발표가 아닌 대화일방적인 발표를 하는 느낌으로 면접을 보는 분들이 많습니다. 그런 답변은 면접관 으로서 흥미와 공감이 떨어집니다. 반면 ‘대화가 통한다’는 느낌을 주는 분들이 있습니다. 핵심적인 답변을 짧고 명확 하게 하고, 인터뷰어는 다시 질문 - 답변 으로 티키타카 식의 소통은 면접관에게 ‘대화가 통한다’는 느낌을 주며, 면접의 전반적인 분위기도 생동감이 듭니다. </li><li>솔직함역량, 리더십, 품성 이 느껴지는 사람의 특징은 매우 솔직합니다. 시행착오나 실패도 덤덤하게 풀어내는 분들은 기억에 오래 남습니다. 이런 솔직함은 면접관에게 강한 신뢰감을 주는데요. 성공 스토리만큼이나 실패를 극복한 경험 역시 중요하기 때문입니다. </li><li>의지, 생각 보다는 경험의지나 생각은 그 사람의 본질이 아닙니다. 개인의 진정한 모습은 과거의 경험을 통해 가장 잘 드러나는데요. 과거 경험을 바탕으로 한 이야기는 면접관의 관심을 끌며, 면접관 자신의 경험 역시도 떠올리게 하여 더욱 깊이 있는 대화로 이어질 수 있습니다. </li><li>회사에 호기심을 가지고 있다회사, 제품에 호기심이 없는 사람은 입사를 하더라도 평범하게 일할 확률이 높습니다. 하지만 회사와 제품에 진정한 호기심을 보이는 면접자라면 입사 후에도 회사에 더 큰 기여를 할 수 있는 잠재력을 보여줍니다. </li><li>자세/태도가 모두 좋다.앉은 자세 및 태도(제스처) 도 중요한 평가 요소입니다. 안정된 자세, 적절한 제스처 는 중요한 비언어적 신호로써, 평소에도 이러한 태도로 일할 가능성이 높음을 시사하기 때문입니다. </li><li>질문도 한다.면접 과정에서도 중간에 질문을 하는 사람이 있습니다. 바로 질문해야 하는 타이밍에, 꼭 해야 할 질문을, 짧고 명확하게 하는 사람들인데요. 이런 질문으로 인해 면접관은 ‘똑똑하다’ 라는 인상을 받게 됩니다. 또한 올바른 질문을 잘 하는 사람은 향후 업무에서도 주체적이고 능동적으로 일할 확률이 높습니다.</li></ol> 개발자의 경우, 소통하는데 있어 솔직한 나의 모습을 직관적으로 전달하기 어려울 때가 있는데요. 결국에는 지속적인 연습과 피드백을 통해 자신의 진정한 모습을 효과적으로 전달할 수 있도록 노력하는 것이 중요할것 같습니다. 그리고 위에서 언급한 특징을 염두에 두고 준비한다면, 자신의 가치를 최대한 드러낼 수 있을 것입니다. 결국 중요한것은 자신의 경험과 역량을 진정성 있게 전달하면서도, 지원하는 회사와 직무에 대한 깊은 이해와 열정이 중요할 것 같습니다.이런 준비와 태도를 통해 면접관에게 깊은 인상을 남기며, 성공적인 면접 결과로 이어질 수 있습니다. https://brunch.co.kr/@seunghoon82/559

인상적인 면접자의 8가지 특징: 성공적인 면접을 위한 가이드

우아한형제들과 우아하게 이별하기를 해보려 합니다. 떠나는 마당에 코드 한 줄을 더 작성할 수도 있겠지만 이번에는 2022.05–2024.09까지의 회사 생활을 되돌아보고 공유하기로 하였습니다.

우아한형제들 퇴사 부검

iOS 프로그래머인 민호님이 우아한형제들을 떠나며 남긴 퇴사부검 입니다.

기대하는 바가 있었지만 점차 사라져버린 것에 아쉬움을 느껴서 새로운 곳에서 도전을 시작하신다고 하네요.

바람을 극복한 프로그래머로 좋은 소식 기다립니다!

https://medium.com/a-day-of-a-programmer/우아한형제들-퇴사-부검-010ce38609a5

iOS 프로그래머인 민호님이 우아한형제들을 떠나며 남긴 퇴사부검 입니다. 기대하는 바가 있었지만 점차 사라져버린 것에 아쉬움을 느껴서 새로운 곳에서 도전을 시작하신다고 하네요. 바람을 극복한 프로그래머로 좋은 소식 기다립니다! https://medium.com/a-day-of-a-programmer/우아한형제들-퇴사-부검-010ce38609a5

민호님의 우아한형제들 퇴사부검

Begin with the basics to understand Docker and Kubernetes networking: learn how to create and interconnect Linux network namespaces using only command-line tools.


How Container Networking Works: a Docker Bridge Network From Scratch | iximiuz Labs

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 재미있는 사이트입니다.

네트워크는 여전히 저에게 너무 어렵긴 한데 netns, veth, bridge, NAT를 설명하면서 우측에 플레이그라운드를 제공하기 때문에 웹사이트에서 설명에 나온 명령어를 따라해보면서 직접 구성해 볼 수 있습니다.

하나하나 직접 따라해보고 테스트도 해볼 수 있기 때문에 브릿지 네트워크를 이해해 보기 좋은 튜토리얼 사이트라고 생각합니다.

일반적으로는 컨테이너의 네트워크가 잘 동작하기 때문에 다 알아야 할 필요는 없지만 종종 겪게되는 엣지 케이스에서는 이러한 네트워크 구성을 알면 트러블시팅 및 원인 파악에 큰 도움이 되기 때문에 자세한 부분은 그때그때 찾아보더라도 전체적인 구조를 이해해두는 건 큰 도움이 된다고 생각합니다.

https://labs.iximiuz.com/tutorials/container-networking-from-scratch

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 재미있는 사이트입니다. 네트워크는 여전히 저에게 너무 어렵긴 한데 netns, veth, bridge, NAT를 설명하면서 우측에 플레이그라운드를 제공하기 때문에 웹사이트에서 설명에 나온 명령어를 따라해보면서 직접 구성해 볼 수 있습니다. 하나하나 직접 따라해보고 테스트도 해볼 수 있기 때문에 브릿지 네트워크를 이해해 보기 좋은 튜토리얼 사이트라고 생각합니다. 일반적으로는 컨테이너의 네트워크가 잘 동작하기 때문에 다 알아야 할 필요는 없지만 종종 겪게되는 엣지 케이스에서는 이러한 네트워크 구성을 알면 트러블시팅 및 원인 파악에 큰 도움이 되기 때문에 자세한 부분은 그때그때 찾아보더라도 전체적인 구조를 이해해두는 건 큰 도움이 된다고 생각합니다. https://labs.iximiuz.com/tutorials/container-networking-from-scratch

iximiuz Labs

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 

오랫동안 React 프로젝트를 만들기 위해서 Create React App라는 CLI 도구가 사용되었습니다.
State of JS 2023 설문 결과를 보시면 Create React App을 사용해봤다는 응답자가 90%가 넘을 정도로 CRA는 오랫동안 React 생태계에서 프로젝트를 생성하는 표준처럼 여겨졌습니다.

하지만 CRA는 2022년 4월 이후로 업데이트가 전혀 없으며, React 공식 문서에서도 사라지면서 사실 상 폐기(deprecated) 수순을 밟고 있습니다.

Next.js도 React 프로젝트를 만들기 위해서 많이 사용되는데요. 하지만 Next.js는 프로젝트 생성 뿐만 아니라 라우팅, 데이터 패칭(fetching), Server-Side Rendering(SSR), Static Site Generation(SSG), 이미지 최적화 등 온갖 부가 기능을 지원하는 메타 프레임워크입니다. 따라서 제대로 활용하려면 배워야할 것도 많고 CRA처럼 간단하게 React 프로젝트를 만들어 보는데는 적합한 도구가 아니죠.

이러한 이유로 최근에 Vite가 CRA의 대안 기술로 부상하고 있습니다. Vite를 사용하면 CRA처럼 간편하게 React 프로젝트를 만들 수 있을 뿐만 아니라, CRA보다 훨씬 빠르고 쾌적한 개발 서버를 사용할 수 있습니다.

뿐만 아니라, CRA로 만든 프로젝트는 규모가 커지면 결국 돌이킬 수 없는 eject를 해야한다는 부담이 있었는데, Vite는 그런 걱정없이 소규모 프로젝트부터 대규모 프로젝트까지 범용적으로 쓸 수 있도록 설계되어 있습니다.

이번 포스팅에서는 차세대 번들러인 Vite 사용하여 React 프로젝트를 생성하고 설정하는 방법에 대해서 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/vite-react/

Vite에 대한 기초적인 내용에 대해서는 아래 게시물을 참고하세요.
📕 Vite 처음 시작하기: https://careerly.co.kr/comments/110882

오랫동안 React 프로젝트를 만들기 위해서 Create React App라는 CLI 도구가 사용되었습니다.State of JS 2023 설문 결과를 보시면 Create React App을 사용해봤다는 응답자가 90%가 넘을 정도로 CRA는 오랫동안 React 생태계에서 프로젝트를 생성하는 표준처럼 여겨졌습니다. 하지만 CRA는 2022년 4월 이후로 업데이트가 전혀 없으며, React 공식 문서에서도 사라지면서 사실 상 폐기(deprecated) 수순을 밟고 있습니다. Next.js도 React 프로젝트를 만들기 위해서 많이 사용되는데요. 하지만 Next.js는 프로젝트 생성 뿐만 아니라 라우팅, 데이터 패칭(fetching), Server-Side Rendering(SSR), Static Site Generation(SSG), 이미지 최적화 등 온갖 부가 기능을 지원하는 메타 프레임워크입니다. 따라서 제대로 활용하려면 배워야할 것도 많고 CRA처럼 간단하게 React 프로젝트를 만들어 보는데는 적합한 도구가 아니죠. 이러한 이유로 최근에 Vite가 CRA의 대안 기술로 부상하고 있습니다. Vite를 사용하면 CRA처럼 간편하게 React 프로젝트를 만들 수 있을 뿐만 아니라, CRA보다 훨씬 빠르고 쾌적한 개발 서버를 사용할 수 있습니다. 뿐만 아니라, CRA로 만든 프로젝트는 규모가 커지면 결국 돌이킬 수 없는 eject를 해야한다는 부담이 있었는데, Vite는 그런 걱정없이 소규모 프로젝트부터 대규모 프로젝트까지 범용적으로 쓸 수 있도록 설계되어 있습니다. 이번 포스팅에서는 차세대 번들러인 Vite 사용하여 React 프로젝트를 생성하고 설정하는 방법에 대해서 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/vite-react/ Vite에 대한 기초적인 내용에 대해서는 아래 게시물을 참고하세요.📕 Vite 처음 시작하기: https://careerly.co.kr/comments/110882

CRA 대신에 Vite로 React 프로젝트 시작하기

1
단순히 해야 할 일만 적어 넣으면 점점 일이 쌓이는 것 같은 압박감을 느낀다.

2
그런데 그 옆에 언제까지 그 일을 할 것인지 시간을 할당해놓으면, 해야 할 일이 아니라 해결한 일이 더 많아지는 느낌이다. 이는 성취감마저 느끼게 하고 알차게 살고 있다는 뿌듯함을 준다.

3
눈에 보이지 않는 것들을 눈에 보이게 만들면 생산성과 효율성이 획기적으로 증가한다.

4
시간을 할당해 두려움과 걱정을 한곳으로 몰아넣어라. 한곳에 몰아넣으면 그것들을 통제하는 것이 가능해진다. 두려움을 통제하는 사람은 포기하지 않는다.

5
우리에게 필요한 것은 '의식적인 멈춤'이다. 의식적으로 한 걸음 물러나서 흐름을 통찰하는 것이다.

6
나는 수첩에 '멈춰야 할 시간'이란 항목을 마련해놓고 있다. 중요한 의사결정이나 브리핑, 미팅이 있는 날 아침에는 수첩을 열어 호흡을 가다듬고 생각을 차분히 정리하는 시간을 미리 정해놓는다.

7
이런 습관을 들이면 중요한 일이 있을 때 방향을 잃지 않게 된다. 팽팽한 긴장감에서 1분 만이라도 벗어나 침착해지면, 중요한 것들을 놓치고 후회하는 일이 놀랍게 줄어든다.

8
어떤 경험을 하고 났을 때는 그 경험에 이름을 붙여주어라. 긍정적인 이름이나 제목을 붙여 기억은행 속에 예치해둔다. 그러면 그 경험이 비록 끔찍한 것이었다 할지라도 부정적 감정이 아니라 하나의 교훈이 먼저 소환된다.

9
인간의 잠재의식은 언제나 한 번에 한 장면만 불러낼 수 있도록 작동한다. 다시 말해 긍정적인 생각을 하면 부정적 생각이 비집고 들어올 자리가 없다. 모든 행동이 그렇다. 무엇인가를 집중적으로 행하고 주의를 기울이면 두려움이 끼어들 자리가 생겨나지 않는다.

1 단순히 해야 할 일만 적어 넣으면 점점 일이 쌓이는 것 같은 압박감을 느낀다. ​ ​2 그런데 그 옆에 언제까지 그 일을 할 것인지 시간을 할당해놓으면, 해야 할 일이 아니라 해결한 일이 더 많아지는 느낌이다. 이는 성취감마저 느끼게 하고 알차게 살고 있다는 뿌듯함을 준다. ​ ​3​ 눈에 보이지 않는 것들을 눈에 보이게 만들면 생산성과 효율성이 획기적으로 증가한다. ​ ​4 시간을 할당해 두려움과 걱정을 한곳으로 몰아넣어라. 한곳에 몰아넣으면 그것들을 통제하는 것이 가능해진다. 두려움을 통제하는 사람은 포기하지 않는다. ​ ​5​ 우리에게 필요한 것은 '의식적인 멈춤'이다. 의식적으로 한 걸음 물러나서 흐름을 통찰하는 것이다. ​ ​6 나는 수첩에 '멈춰야 할 시간'이란 항목을 마련해놓고 있다. 중요한 의사결정이나 브리핑, 미팅이 있는 날 아침에는 수첩을 열어 호흡을 가다듬고 생각을 차분히 정리하는 시간을 미리 정해놓는다. ​ ​7 이런 습관을 들이면 중요한 일이 있을 때 방향을 잃지 않게 된다. 팽팽한 긴장감에서 1분 만이라도 벗어나 침착해지면, 중요한 것들을 놓치고 후회하는 일이 놀랍게 줄어든다. ​ ​8​ 어떤 경험을 하고 났을 때는 그 경험에 이름을 붙여주어라. 긍정적인 이름이나 제목을 붙여 기억은행 속에 예치해둔다. 그러면 그 경험이 비록 끔찍한 것이었다 할지라도 부정적 감정이 아니라 하나의 교훈이 먼저 소환된다. ​ ​​9 인간의 잠재의식은 언제나 한 번에 한 장면만 불러낼 수 있도록 작동한다. 다시 말해 긍정적인 생각을 하면 부정적 생각이 비집고 들어올 자리가 없다. 모든 행동이 그렇다. 무엇인가를 집중적으로 행하고 주의를 기울이면 두려움이 끼어들 자리가 생겨나지 않는다.

< 할 일을 쉽게 해치우는 시간 관리의 기술 >

What I've learned from spending a summer in SF

[Frontier] 실리콘밸리의 여름.

실리콘밸리에서 여름을 보내며 배운 10가지라고 해주셨는데, 많은 분들이 보시면 좋을 것 같아 공유해보아요. 원문을 꼭 읽어보셔요.

 1.  Have conviction and keep building (자기 확신을 가지고 계속 만들어라.)
 2.  Don't think about A -> Z, focus on A -> B (체계적인 계획이 아니라, 당장 빠르게 잘 실행하는 것에 집중하라)
 3.  10 Loving customers is all you need (10명이 제품을 사랑하게 하라)
 4.  Technical founding team is key (코파운더의 기술적 능력이 필수적이다)
 5.  Keep showing up to YC, a16z SR etc... (미국 진출을 위해 미국 accelerator에 문을 계속 두드리자)
 6.  Follow your energy
 7.  Live the life you would live if you knew you wouldn't fail. (실패하지 않을 거라 가정하고, 가장 기대되는 인생을 살자)
 8.  Obsession and taste (제품과 고객에 대한 집착과 완벽주의)
 9.  AI is really changing the world (AI는 정말 세상을 바꾸고 있다)
 10. Seoul vs San Francisco
     
     
https://frontierbydoyeob.substack.com/p/frontier

실리콘밸리에서 여름을 보내며 배운 10가지라고 해주셨는데, 많은 분들이 보시면 좋을 것 같아 공유해보아요. 원문을 꼭 읽어보셔요. <ol ><li>Have conviction and keep building (자기 확신을 가지고 계속 만들어라.)</li><li>Don't think about A -&gt; Z, focus on A -&gt; B (체계적인 계획이 아니라, 당장 빠르게 잘 실행하는 것에 집중하라)</li><li>10 Loving customers is all you need (10명이 제품을 사랑하게 하라)</li><li>Technical founding team is key (코파운더의 기술적 능력이 필수적이다)</li><li>Keep showing up to YC, a16z SR etc... (미국 진출을 위해 미국 accelerator에 문을 계속 두드리자)</li><li>Follow your energy</li><li>Live the life you would live if you knew you wouldn't fail. (실패하지 않을 거라 가정하고, 가장 기대되는 인생을 살자)</li><li>Obsession and taste (제품과 고객에 대한 집착과 완벽주의)</li><li>AI is really changing the world (AI는 정말 세상을 바꾸고 있다)</li><li>Seoul vs San Francisco </li></ol>https://frontierbydoyeob.substack.com/p/frontier

frontierbydoyeob.substack.com

실리콘밸리에서 깨달은 10가지

사용자가 공유한 콘텐츠

1. “(요즘 데이터로 확인되는 흐름 중 하나는) 직급이 아닌 '이름' 으로 불리는 이들이 늘고 있는 거예요”

2. “(지금까지) 우리 사회는 이름에 참 각박한 사회였어요. 내 이름으로 불리는 기간이 아주 짧았죠. 신입 사원 때 잠깐 이름으로 불리다 직급을 다는 순간 '김 대리'가 돼요. 심지어 퇴직 후 20년이 지나도 옛 동료끼리는 서로를 마지막 직급으로 부른다고 하죠”

3. “물론 (직급을 부른 문화에는) 성취에 대한 인정도 있지만, (어떤 면에선) 부당해요. 각자의 다양성과 다면성을 (직급을 부르며) 제거하는 거니까요. (그러다) 주체적으로 자신의 삶을 사는 (요즘의) '핵개인'들은, 직급이 아닌 자기 이름으로 불린다는 걸 알게 됐어요”

4. “이름으로 부른다는 건 곧 단독자로서의 지칭이자 그의 아이덴티티를 인식한다는 뜻이잖아요? (그러면서 생각했죠) 이제는 홀로 선 각자가 서로의 이름을 부르는 시대로 가는구나, 서로의 소중함을 인식하는구나, 그래서 (시대예보 책 타이틀에) '호명사회'라는 이름을 붙인 거예요”

5. “이런 사회 변화는 (크게) 2가지 키워드로 정리할 수 있어요. 첫 번째는 '유동화(=스트리밍화)'. (이젠) 한 사람이 여러 곳의 일을 동시에 할 수 있게 됐어요. (단순히 사람을 채용하는 것이 아니라) 그 사람이 가진 능력을 사는 시대가 되고 있는 거죠”

6. “두 번째는 극소화(=극단적 효율화)예요. 자동화와 플랫폼의 등장으로 한 명이 할 수 있는 일이 많아졌어요. 무리 지어 일할 필요가 없어진 거죠. 그러면 개인의 영향력이 극단적으로 증강됩니다. '내가 80% 이상을 일하는데, 왜 우리 팀은 4명이지?' 그 의문에서 1인 기업을 택하는 분들이 늘고 있죠. 그게 (더) 합리적인 선택이라고 판단하니까요”

7. “이렇듯 점차 개인의 이름이 드러나는 사회로 가고 있어요. 그런 사회에서는 온전히 자신이 만든 것을 세상에 알리며 성과를 쌓아가는 사람에게 많은 이들이 열광하게 돼요. 내가 한 일이라면 그 결과가 나에게 온전히 귀속되는 사회, 새로운 공정 사회가 오고 있는 거죠”

8. “(바꿔 말하면, 무슨 전문가니, 컨설턴트니, 코치니 하는 온갖 직업명이나 수식어로 자기를 꾸미는 퍼스널 브랜딩의 시대는 끝났고, 그 사람이 무슨 일을 했고, 어떤 결과를 만들었는지를 중심으로, 그 개인의 시간과 능력을 사려는 분위기가 생기고 있다는 얘깁니다)”

9. “(그러니 온갖 미사여구를 동원해 자기 자신을 억지로 브랜딩하려고 하지 말고, 지금부터는 딱 깔끔하게 실력과 능력과 결과로, 자기 이름이 지닌 가치를 높이세요. 그렇게 자기 이름으로 업계에서 네임드가 되세요. 앞으로는 훨씬 더 중요할 겁니다)”

- 송길영 박사

1. “(요즘 데이터로 확인되는 흐름 중 하나는) 직급이 아닌 '이름' 으로 불리는 이들이 늘고 있는 거예요” 2. “(지금까지) 우리 사회는 이름에 참 각박한 사회였어요. 내 이름으로 불리는 기간이 아주 짧았죠. 신입 사원 때 잠깐 이름으로 불리다 직급을 다는 순간 '김 대리'가 돼요. 심지어 퇴직 후 20년이 지나도 옛 동료끼리는 서로를 마지막 직급으로 부른다고 하죠” 3. “물론 (직급을 부른 문화에는) 성취에 대한 인정도 있지만, (어떤 면에선) 부당해요. 각자의 다양성과 다면성을 (직급을 부르며) 제거하는 거니까요. (그러다) 주체적으로 자신의 삶을 사는 (요즘의) '핵개인'들은, 직급이 아닌 자기 이름으로 불린다는 걸 알게 됐어요” 4. “이름으로 부른다는 건 곧 단독자로서의 지칭이자 그의 아이덴티티를 인식한다는 뜻이잖아요? (그러면서 생각했죠) 이제는 홀로 선 각자가 서로의 이름을 부르는 시대로 가는구나, 서로의 소중함을 인식하는구나, 그래서 (시대예보 책 타이틀에) '호명사회'라는 이름을 붙인 거예요” 5. “이런 사회 변화는 (크게) 2가지 키워드로 정리할 수 있어요. 첫 번째는 '유동화(=스트리밍화)'. (이젠) 한 사람이 여러 곳의 일을 동시에 할 수 있게 됐어요. (단순히 사람을 채용하는 것이 아니라) 그 사람이 가진 능력을 사는 시대가 되고 있는 거죠” 6. “두 번째는 극소화(=극단적 효율화)예요. 자동화와 플랫폼의 등장으로 한 명이 할 수 있는 일이 많아졌어요. 무리 지어 일할 필요가 없어진 거죠. 그러면 개인의 영향력이 극단적으로 증강됩니다. '내가 80% 이상을 일하는데, 왜 우리 팀은 4명이지?' 그 의문에서 1인 기업을 택하는 분들이 늘고 있죠. 그게 (더) 합리적인 선택이라고 판단하니까요” 7. “이렇듯 점차 개인의 이름이 드러나는 사회로 가고 있어요. 그런 사회에서는 온전히 자신이 만든 것을 세상에 알리며 성과를 쌓아가는 사람에게 많은 이들이 열광하게 돼요. 내가 한 일이라면 그 결과가 나에게 온전히 귀속되는 사회, 새로운 공정 사회가 오고 있는 거죠” 8. “(바꿔 말하면, 무슨 전문가니, 컨설턴트니, 코치니 하는 온갖 직업명이나 수식어로 자기를 꾸미는 퍼스널 브랜딩의 시대는 끝났고, 그 사람이 무슨 일을 했고, 어떤 결과를 만들었는지를 중심으로, 그 개인의 시간과 능력을 사려는 분위기가 생기고 있다는 얘깁니다)” 9. “(그러니 온갖 미사여구를 동원해 자기 자신을 억지로 브랜딩하려고 하지 말고, 지금부터는 딱 깔끔하게 실력과 능력과 결과로, 자기 이름이 지닌 가치를 높이세요. 그렇게 자기 이름으로 업계에서 네임드가 되세요. 앞으로는 훨씬 더 중요할 겁니다)” - 송길영 박사

www.folin.co

일을 잘 해서 네임드가 되면, 퍼스널 브랜딩 따위는 1도 중요하지

긱뉴스를 처음 보기 시작했던 게 2019년이었던가. 서비스가 나오자마자 보기 시작했습니다. 서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다.

긱뉴스에서 배운 것들

긱뉴스를 처음 보기 시작했던 게 2019년이었던가.
서비스가 나오자마자 보기 시작했습니다.
서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다.

어려울 거라 생각했습니다.
운영자님 혼자만 글을 올리는 개발 뉴스 커뮤니티.
한국이라는 작은 시장.
과연 이게 될까?

뭔가를 꾸준히 한다는 게 참 쉽지가 않습니다.
아무리 쉬운 일이라도 빼먹지 않고 매일 한다는 것.
저는 번번이 실패했습니다.

매일 팔굽혀펴기 100개씩을 해보자, 더도 말고 딱 100개만.
한 달을 조금 넘기고 빵꾸를 냈습니다.
한 번 빵꾸를 내니 더 이상 지속되질 않았습니다.

이번엔 좀 더 쉬운 걸로 해보자.
인스타그램을 만들어서 사진을 하루에 하나씩 올려보는 거야.
여행 사진이든 음식 사진이든.
이건 진짜 쉬운 일 아닌가?
이것도 한 달을 넘기질 못했습니다.

긱뉴스를 보면서 감탄했던 건 운영자님 혼자서 매일 5개의 글을 올렸다는 것.
눈이 오나 비가 오나. 반응이 있건 없건.
그것도 무려 5년 동안이나.

1년간 총 2411개의 기술뉴스가 작성되었습니다. 그중에 제가 작성한 것은 1974개 입니다. 일년간 하루도 빠짐없이 뉴스를 올려서, 평균 5.4개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다.

긱뉴스 1주년 회고 중

지난 1년간총 2225개의 기술뉴스가 작성되어서 현재까지 총 뉴스는 4636개 입니다. 저는 오픈 후 2년간 하루도 빠짐없이 뉴스를 올려서, 총 3764개, 하루 평균 5.1개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다.

긱뉴스 2주년 회고 중

도저히 활성화되지 않을 것 같던 커뮤니티에..
3년 쯤 지나니 다른 사람들도 종종 글을 올리고 댓글들도 달리기 시작했습니다.
와, 이게 되긴 되는구나.
서비스는 이렇게 하는 거구나.

제가 매일 코딩하기를 하는 것.
커피한잔을 만들면서 포기하지 않고 버텨낸 것.
긱뉴스를 운영하는 모습을 보며 영향을 많이 받았습니다.

오늘 긱뉴스에 올라온 한 글에서…
수많은 댓글을 보고 이제 커뮤니티가 많이 커졌구나 느꼈습니다.
피곤할 만한 글에 대한 운영자님의 대응을 보면서 많이 배우기도 했습니다. 감탄했습니다.

한때는 RSS를 500여 개 등록해놓고 매일 아침 눈 떴을 때부터 자기 전까지 틈날 때마다 읽었습니다.
다 읽어야 한다는 부담을 가지고. 아주 고통스럽게.
이제 긱뉴스 덕분에 RSS는 잘 보지 않습니다.
긱뉴스만 읽어도 이전보다 좋은 소식을 더 많이 알게 되는 것 같습니다.
바로 운영자님이 바라던 그 모습 그대로.

정말 대단한 서비스입니다.
항상 응원하고 감사하게 생각합니다.

https://jeho.page/essay/2024/09/30/geek-news.html

긱뉴스를 처음 보기 시작했던 게 2019년이었던가.서비스가 나오자마자 보기 시작했습니다.서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다. 어려울 거라 생각했습니다.운영자님 혼자만 글을 올리는 개발 뉴스 커뮤니티.한국이라는 작은 시장.과연 이게 될까? 뭔가를 꾸준히 한다는 게 참 쉽지가 않습니다.아무리 쉬운 일이라도 빼먹지 않고 매일 한다는 것.저는 번번이 실패했습니다. 매일 팔굽혀펴기 100개씩을 해보자, 더도 말고 딱 100개만.한 달을 조금 넘기고 빵꾸를 냈습니다.한 번 빵꾸를 내니 더 이상 지속되질 않았습니다. 이번엔 좀 더 쉬운 걸로 해보자.인스타그램을 만들어서 사진을 하루에 하나씩 올려보는 거야.여행 사진이든 음식 사진이든.이건 진짜 쉬운 일 아닌가?이것도 한 달을 넘기질 못했습니다. 긱뉴스를 보면서 감탄했던 건 운영자님 혼자서 매일 5개의 글을 올렸다는 것.눈이 오나 비가 오나. 반응이 있건 없건.그것도 무려 5년 동안이나. 1년간 총 2411개의 기술뉴스가 작성되었습니다. 그중에 제가 작성한 것은 1974개 입니다. 일년간 하루도 빠짐없이 뉴스를 올려서, 평균 5.4개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다. 긱뉴스 1주년 회고 중 지난 1년간총 2225개의 기술뉴스가 작성되어서 현재까지 총 뉴스는 4636개 입니다. 저는 오픈 후 2년간 하루도 빠짐없이 뉴스를 올려서, 총 3764개, 하루 평균 5.1개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다. 긱뉴스 2주년 회고 중 도저히 활성화되지 않을 것 같던 커뮤니티에..3년 쯤 지나니 다른 사람들도 종종 글을 올리고 댓글들도 달리기 시작했습니다.와, 이게 되긴 되는구나.서비스는 이렇게 하는 거구나. 제가 매일 코딩하기를 하는 것.커피한잔을 만들면서 포기하지 않고 버텨낸 것.긱뉴스를 운영하는 모습을 보며 영향을 많이 받았습니다. 오늘 긱뉴스에 올라온 한 글에서…수많은 댓글을 보고 이제 커뮤니티가 많이 커졌구나 느꼈습니다.피곤할 만한 글에 대한 운영자님의 대응을 보면서 많이 배우기도 했습니다. 감탄했습니다. 한때는 RSS를 500여 개 등록해놓고 매일 아침 눈 떴을 때부터 자기 전까지 틈날 때마다 읽었습니다.다 읽어야 한다는 부담을 가지고. 아주 고통스럽게.이제 긱뉴스 덕분에 RSS는 잘 보지 않습니다.긱뉴스만 읽어도 이전보다 좋은 소식을 더 많이 알게 되는 것 같습니다.바로 운영자님이 바라던 그 모습 그대로. 정말 대단한 서비스입니다.항상 응원하고 감사하게 생각합니다. https://jeho.page/essay/2024/09/30/geek-news.html

K리그 프로그래머

주변에 커리어 관리를 잘해서 좋은데 들어간 사람들의 이야기를
듣게 되었을 때 사람인 이상 마냥 축하만 해주지는 못하고
부럽다라던가 시샘 할 수도 있는데 저는 아마 후자에 가깝지만
시각은 좀 다릅니다

노력이 부족해서 좋은데를 가지 못하는거다
그런 말을 매우 싫어할 정도로 사실 삶에 많이 지쳐 있는데
남이 잘 된다고 시샘할 에너지도 부족합니다

남을 시샘할 시간에 지금 컨디션 빨리 추스려서
내일 일 할 수 있는 힘 비축하기에도 버겁습니다
잘 될 사람이라서 잘 되는거라 생각하면 끝나는 일입니다

주변에 커리어 관리를 잘해서 좋은데 들어간 사람들의 이야기를듣게 되었을 때 사람인 이상 마냥 축하만 해주지는 못하고부럽다라던가 시샘 할 수도 있는데 저는 아마 후자에 가깝지만시각은 좀 다릅니다 노력이 부족해서 좋은데를 가지 못하는거다그런 말을 매우 싫어할 정도로 사실 삶에 많이 지쳐 있는데남이 잘 된다고 시샘할 에너지도 부족합니다 남을 시샘할 시간에 지금 컨디션 빨리 추스려서내일 일 할 수 있는 힘 비축하기에도 버겁습니다잘 될 사람이라서 잘 되는거라 생각하면 끝나는 일입니다

사장님을 위한 가계부앱 일기월장

전현철


외식업 경력 15년 
사장님을 위한 가계부 앱을 만듭니다. 

It 경력 
2022.10 Flutter 시작
2023.12 주식회사 자람 설립 
2024.02 일기월장 베타 출시
https://litt.ly/jalam


software engineer

김인후

서비스의 이용자, 공급자 모두에게 좋은 경험을 제공하고자 노력하는 개발자 김인후 입니다.

주로 NestJS, Spring Boot를 사용하여 서버를 개발하지만 React, Next를 이용한 Web과 aws, k3s를 사용해 운영 관리도 합니다.

남 잘 되면 시샘하는 것도 따지고 보면 에너지 낭비입니다

반도체

Java

OracleDB

소프트웨어 엔지니어

제조

물류 / 유통

MS SQL

MES POP 생산 관리 시스템 개발 밎 유지보수

보안

컨설팅

데이터 분석

커뮤니케이션

포렌식 서비스 제공 및 비정형 데이터 분석 솔루션 기술지원

스마트팩토리 시스템 구축 및 생산 관리 시스템 개발

플랫폼

MySQL

python

html

javascript

SpringBoot

Docker

React

typescript

Node.js

Spring

Github

시스템 통합 구축 파견 업무 및 배달 중계 플랫폼 추가 기능 개발 및 테스트

백엔드 개발자

django

Linux

자바 서버 모듈 개발 및 원도우 어플리케이션 개발 및 유지보수

남 잘 되면 시샘하는 것도 따지고 보면 에너지 낭비입니다

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필