정부는 수출이 증가해 경상수지 흑자가 늘어나면 경제가 좋아진다고 말해왔다. 6월 수출은 9개월 연속 늘었고, 경상수지 흑자 규모는 6년 9개월 만에 최고를 기록했다. 그런데 2분기 경제성장률은 -0.2%였다. 수출의 온기가 민생까지 퍼지지 않았다는 뜻이다. 이유를 알아봤다. "올해 수출이 일본을 앞지를 수 있다는 전망까지 나온다. 수출의 활력이 더 크게 살아나고 내수 시장으로 온기가 골고루 퍼지도록 더욱 힘을 쏟아야 한다."

수출 연속 흑자인데 GDP 역성장 이유 : 낙수효과의 '종언'

우리나라 제조업은 이미 자동화가 끝났기 때문이다. 국제로봇연맹이 지난 1월 10일 발표한 ‘2023 세계 로봇공학 보고서’에 따르면 한국의 로봇밀도는 근로자 1만명당 1012대로 압도적인 세계 1위다. 2위 싱가포르가 1만명당 산업로봇이 73대, 2위 독일이 415대다. 그런데도 우리는 2017년 이후 산업현장에 로봇을 연평균 6%씩 더 늘리고 있다. 

https://www.thescoop.co.kr/news/articleView.html?idxno=302856

제조업의 나라에서 많은 일자리가 로봇으로 대체되고 있습니다. 언젠가 이런 뉴스를 프로그래밍 영역에서도 볼지 모르겠단 생각이 듭니다.

과연 지금하는 일만 가지고 그 흐름을 타고 넘을 수 있을지 스스로에게 질문해봐야할 시기 같네요.

우리나라 제조업은 이미 자동화가 끝났기 때문이다. 국제로봇연맹이 지난 1월 10일 발표한 ‘2023 세계 로봇공학 보고서’에 따르면 한국의 로봇밀도는 근로자 1만명당 1012대로 압도적인 세계 1위다. 2위 싱가포르가 1만명당 산업로봇이 73대, 2위 독일이 415대다. 그런데도 우리는 2017년 이후 산업현장에 로봇을 연평균 6%씩 더 늘리고 있다.&nbsp; https://www.thescoop.co.kr/news/articleView.html?idxno=302856 제조업의 나라에서 많은 일자리가 로봇으로 대체되고 있습니다. 언젠가 이런 뉴스를 프로그래밍 영역에서도 볼지 모르겠단 생각이 듭니다. 과연 지금하는 일만 가지고 그 흐름을 타고 넘을 수 있을지 스스로에게 질문해봐야할 시기 같네요.

더스쿠프

자동화의 시대

누구나 축구할 때 공격을 하고 싶어 합니다. 제일 재밌으니까. 모든 스포트라이트를 받으니까. 골을 넣는 것만큼 짜릿한 게 없으니까.

레거시 처리 개발자

카카오에 처음 입사했을 때 무슨 일을 하고 싶냐고 물어봐서 카톡 서버를 하겠다고 했습니다.
가장 핵심 서비스니까.
가장 중요한 일을 해서 내가 스포트라이트를 다 받아야지.

어려운 일 투성이라 적응하는 데 시간이 걸렸습니다.
6개월 정도 잠 못 자고 고생한 후에야 맘이 좀 편안해졌던 기억이 납니다.

핵심적인 팀에서 일하고 있는 건 분명했는데…
실제로 하고 있는 일은 짜친 일 투성이였습니다.

서버 교체하기.
어드민 만들기.
스팸 찾아내서 처리하기.
카톡 더보기에 배너 달아주기.
이런 Api 만들어 줄 수 있냐는 상담해 주기.
그리고 끝이 없는 고객 문의와 장애 처리.

아, 이런 일하려고 지원한 게 아니었는데.
이래서 신기능 개발은 언제 해?

찾아오는 사람들은 항상 많았습니다.
어떤 날은 두세 팀이 동시에 찾아와서 줄 세워 놓고 얘기하기도 했습니다.

뭔가 핵심적인 일을 하는 것 같긴 한데…
왜 이렇게 짜친 느낌이 들지?
신규 기능을 만들기 보다 서비스를 지키기 위해 더 많은 힘을 쏟았습니다.
이거 공격수가 아니라 완전히 수비수잖아?

이렇게 몇 년 하다가 공격수를 하겠다고 말했습니다.
나도 신규 서비스 만들고 싶다구!
그리고 카카오 플레이스를 만들었습니다.
대차게 말아 먹었습니다.
풀타임 출전, 0골.

수비수를 한다는 것이 얼마나 가치 있는 일이고 중요한지는 나중에 알게 되었습니다.
든든한 수비수들이 있어서 공격도 마음껏 할 수 있는 거라는걸.
공격수가 대차게 말아 먹어도 그들 덕분에 지지 않을 수 있다는 걸.

중요한 일을 하고 싶다는 마음이야 당연한 것이지만…
공격수가 가장 중요한 것이라는 생각은 잘못된 것이었습니다.

축구에서처럼 서비스 회사에서도 서비스를 만들어 나가는 사람들과 지켜 내는 사람들이 있습니다.
레거시를 지켜내는 사람들은 좀처럼 스포트라이트를 받지 못합니다. 백업하는 존재로 인식될 뿐.
최근에 김민재라는 국가대표 수비수를 보며 자란 아이들은 축구할 때 수비수를 하고 싶다는 말을 한답니다.
지켜내는 사람들이 지금보다 나은 대우를 받고 멋진 모습을 보여 주면 새로 들어온 사람들도 레거시를 다루는 일을 기꺼이 하려 하지 않을까?

요즘에 축구할 땐 수비수를 합니다.
수비가 중요한 것뿐만이 아니라 심지어는 재미까지 있다는 것도 알게 되었습니다.
다시 회사에 가면 이제는 수비수를 잘 즐길 수 있을 것 같습니다.
가치 있고 중요한 일을 하는 거니까. 그런 마음으로 잘 생각해 보면 이 일도 참 재밌거든.

https://jeho.page/essay/2024/08/08/defense-fun.html

카카오에 처음 입사했을 때 무슨 일을 하고 싶냐고 물어봐서 카톡 서버를 하겠다고 했습니다. 가장 핵심 서비스니까. 가장 중요한 일을 해서 내가 스포트라이트를 다 받아야지. 어려운 일 투성이라 적응하는 데 시간이 걸렸습니다. 6개월 정도 잠 못 자고 고생한 후에야 맘이 좀 편안해졌던 기억이 납니다. 핵심적인 팀에서 일하고 있는 건 분명했는데… 실제로 하고 있는 일은 짜친 일 투성이였습니다. 서버 교체하기. 어드민 만들기. 스팸 찾아내서 처리하기. 카톡 더보기에 배너 달아주기. 이런 Api 만들어 줄 수 있냐는 상담해 주기. 그리고 끝이 없는 고객 문의와 장애 처리. 아, 이런 일하려고 지원한 게 아니었는데. 이래서 신기능 개발은 언제 해? 찾아오는 사람들은 항상 많았습니다. 어떤 날은 두세 팀이 동시에 찾아와서 줄 세워 놓고 얘기하기도 했습니다. 뭔가 핵심적인 일을 하는 것 같긴 한데… 왜 이렇게 짜친 느낌이 들지? 신규 기능을 만들기 보다 서비스를 지키기 위해 더 많은 힘을 쏟았습니다. 이거 공격수가 아니라 완전히 수비수잖아? 이렇게 몇 년 하다가 공격수를 하겠다고 말했습니다. 나도 신규 서비스 만들고 싶다구! 그리고 카카오 플레이스를 만들었습니다. 대차게 말아 먹었습니다. 풀타임 출전, 0골. 수비수를 한다는 것이 얼마나 가치 있는 일이고 중요한지는 나중에 알게 되었습니다. 든든한 수비수들이 있어서 공격도 마음껏 할 수 있는 거라는걸. 공격수가 대차게 말아 먹어도 그들 덕분에 지지 않을 수 있다는 걸. 중요한 일을 하고 싶다는 마음이야 당연한 것이지만… 공격수가 가장 중요한 것이라는 생각은 잘못된 것이었습니다. 축구에서처럼 서비스 회사에서도 서비스를 만들어 나가는 사람들과 지켜 내는 사람들이 있습니다. 레거시를 지켜내는 사람들은 좀처럼 스포트라이트를 받지 못합니다. 백업하는 존재로 인식될 뿐. 최근에 김민재라는 국가대표 수비수를 보며 자란 아이들은 축구할 때 수비수를 하고 싶다는 말을 한답니다. 지켜내는 사람들이 지금보다 나은 대우를 받고 멋진 모습을 보여 주면 새로 들어온 사람들도 레거시를 다루는 일을 기꺼이 하려 하지 않을까? 요즘에 축구할 땐 수비수를 합니다. 수비가 중요한 것뿐만이 아니라 심지어는 재미까지 있다는 것도 알게 되었습니다. 다시 회사에 가면 이제는 수비수를 잘 즐길 수 있을 것 같습니다. 가치 있고 중요한 일을 하는 거니까. 그런 마음으로 잘 생각해 보면 이 일도 참 재밌거든. https://jeho.page/essay/2024/08/08/defense-fun.html

K리그 프로그래머

미국 반도체 기업 인텔이 당장 내달 계획돼 있던 연례 개발자 대회 '인텔 이노베이션 2024′를 취소하기로 했다. 지난 1일 시장 전망치를 하회하는 실적을 발표한 뒤 주가가 곤두박질치자 연례 최대 행사까지 취소하기로 했다. 8일 인텔은 "신중하게 검토한 끝에 우리는 9월 열릴 예정이었던 '인텔 이노베이션 2024′ 행사를 2025년까지 연기하기로 결정했다"

개발자 대회 취소... 인텔 '끝모를 추락'

컴퓨터 광고 뒤에 인텔 인사이드 라는 말이 따라오던 때가 있었죠.
프로세서 = 인텔
감히 이렇게 생각하고 살았습니다.

프로그래머로 업을 이어가면서 조립 PC를 다룰 일이 없어서 점차 인텔과 멀어져서 살았는데요. 최근 기사를 보니 인텔이 실적저조로 개발자 대회까지 취소하는 지경에 이르렀다고 하네요.

세월이 흘러가는걸 저만 놓치고 있었나보네요.

https://v.daum.net/v/20240812013709200

컴퓨터 광고 뒤에 인텔 인사이드 라는 말이 따라오던 때가 있었죠.프로세서 = 인텔감히 이렇게 생각하고 살았습니다. 프로그래머로 업을 이어가면서 조립 PC를 다룰 일이 없어서 점차 인텔과 멀어져서 살았는데요. 최근 기사를 보니 인텔이 실적저조로 개발자 대회까지 취소하는 지경에 이르렀다고 하네요. 세월이 흘러가는걸 저만 놓치고 있었나보네요. https://v.daum.net/v/20240812013709200

다음 - 조선일보

화무십일홍

10년쯤 전의 이야기입니다. 2012년 2월쯤이었나.
네이버의 이해진 의장님이 이런 말씀을 하신 적이 있습니다.

"여러분들 네이버란 간판 떼고 나가서 아무 서비스나 한번 만들어보세요.
몇 명이나 써줄 것 같아요? 10명이나 다운 받아줄까요?
지금 네이버란 간판이 여러분들이 만드는 서비스를 지켜주고 있다는 걸 깨닫게 될 거예요.
못 믿겠으면 나가서 한 번 해보세요. 그게 여러분들 진짜 실력이에요."

가슴이 두근두근 뛰고 약간의 반항심도 들었던 것 같습니다. 저 말이 진짜일까?
아니, 난 잘할 수 있을 것 같은데.
이 이야기는 제 가슴에 꽂혀 오랜 시간이 지나도록 잊히지 않았습니다.

---

회사 다닐 때 이런 생각을 가끔씩 했던 것 같습니다.
내가 회사 다니면서 연봉 1억을 받는다면 사실 내가 회사에 가져다준 가치는 그 이상이야. 적어도 1억 5천은 되겠지. 회사는 내게서 5천만 원을 수수료처럼 떼 가고 있는 거야. 그렇다면 내가 회사를 그만두고 혼자 일한다면 1억 5천 이상을 벌 수 있는 사내가 되겠군.

그리고 이런 생각은 이해진 의장님의 이야기와는 반대였고 저는 정말 궁금했습니다.
내가 나만의 서비스를 만든다면 결과가 어떨까? 내 실력은 진짜일까 가짜일까.
남이 만든 회사가 아니라 내가 창조해낸 제품으로 단 돈 만원이라도 벌어보고 싶다. 딱 만원만 벌고 실패해도 좋으니 내 진짜 실력이라는 걸 테스트해보고 싶어.

---

어릴 때 스포츠 선수들이 연봉 때문에 재계약을 안 하고 싸우는 것을 보면 이상했습니다.
돈을 저렇게 많이 받는데 그깟 몇 프로 더 받으려고 저렇게 싸워가면서 뻐팅긴다고?
이런 질문을 어른들에게 하면 어김없이 이런 대답이 돌아왔습니다.
"스포츠 선수들은 연봉을 실력으로 생각하는 거야. 자기 실력을 인정받고 싶은 거지."

이제는 조금 이해할 수 있을 것 같습니다.
이 세상에서 진실을 테스트할 수 있는 것 중 돈 만한 게 없다는 걸 깨닫게 되었거든요.
내 음식이 맛있다 맛없다 하는 말은 별로 중요하지 않습니다. 손님들이 지갑을 열어 기꺼이 지불해주는 돈이 진실인 것입니다.

이런 관점으로 바라보면 본인의 연봉이 곧 그 업에서의 실력이라고 말할 수 있습니다.

---

저는 결국 궁금증을 풀어냈습니다.

1. 이해진 의장님이 한 말은 사실이었습니다.
제가 만든 앱은 하루에 1명도 설치하지 않은 날들이 많았습니다. 너무 우울해서 독한 술로 슬픈 패배감을 달래곤 했습니다. 마음이 어찌나 쓰린지 맥주 같은 술로는 달래지지 않더군요.

2. 회사에서 수수료를 떼어간다는 제 생각은 옳았습니다.
회사에서 연봉 1억을 받는다면 회사를 그만두면 같은 노력으로 그 이상을 벌 잠재력을 가지고 있습니다.
사람들이 많이 오해하는 부분은 '같은 노력' 부분인 것 같습니다.
적어도 회사에서 하는 만큼은 일해야 하는데 덜 노력하고 더 벌려고 하니 쉽지가 않습니다.

3. 이 잠재력은 쉽게 발현되지 않습니다.
최소한 1년. 통상 3년 정도는 해봐야 결과가 나옵니다. 10년이 걸릴 수도 있습니다.
사람들은 충분한 잠재력을 가지고 있지만 결과가 나오기 전에 포기합니다.
하지만 이 날 이해진 의장님은 또 한 가지 말씀을 해주셨습니다.
"성공은요, 실패하고 실패하다가 더 물러설 곳 없는 마지막 한 걸음에 나오는 거예요."

이 말은 제가 포기하지 않을 수 있게 도와줬습니다.

4. 저는 실력이 있는 사람이었습니다.
이걸 알게 된 것이 가장 큰 소득입니다.
4년의 노력 끝에 드디어 회사 다닐 때의 연봉을 넘어섰습니다.
더 이상 제 자신에 대해 의심하지 않게 된 것이 너무너무 기쁩니다.
저는 스스로의 힘으로 세상에 가치를 만들어 낼 수 있고 돈을 벌 수 있는 존재라는 것을 깨닫게 되니 그제야 평안을 얻게 되었달까요? 더 이상 다른 사람들이 부럽지 않게 되었습니다.

본인이 진짜 얼마짜리 사람인지 알고 싶나요?
회사를 그만두고 혼자서 도전해보는 것만큼 좋은 방법도 없는 것 같습니다.
어쩌면 회사는 자신의 온전한 가치를 드러낼 수 없게 상한선을 막고 있는 존재 아닐까 하는 생각을 합니다.
이 울타리를 깨고 나와야만 자신을 테스트해볼 수 있습니다.
외롭고 고된 길이지만 도전할만한 가치가 있습니다.
이 길은 자기가 누구인지 찾아가는 과정이고 그 열매는 너무 달콤하거든요.
이제야 저는 저를 찾았습니다.

10년쯤 전의 이야기입니다. 2012년 2월쯤이었나.네이버의 이해진 의장님이 이런 말씀을 하신 적이 있습니다. "여러분들 네이버란 간판 떼고 나가서 아무&nbsp;서비스나 한번 만들어보세요.몇 명이나 써줄 것 같아요? 10명이나 다운 받아줄까요?지금 네이버란 간판이 여러분들이 만드는 서비스를 지켜주고 있다는 걸 깨닫게 될 거예요.못 믿겠으면 나가서 한 번 해보세요. 그게 여러분들 진짜 실력이에요." 가슴이 두근두근 뛰고 약간의&nbsp;반항심도 들었던 것 같습니다. 저 말이 진짜일까?아니, 난 잘할 수 있을 것 같은데.이 이야기는 제 가슴에 꽂혀 오랜 시간이 지나도록 잊히지 않았습니다. --- 회사 다닐 때 이런 생각을 가끔씩 했던 것 같습니다.내가 회사 다니면서 연봉 1억을 받는다면 사실 내가 회사에 가져다준 가치는 그 이상이야. 적어도 1억 5천은 되겠지. 회사는 내게서 5천만 원을 수수료처럼 떼 가고 있는 거야. 그렇다면 내가 회사를 그만두고 혼자 일한다면 1억 5천 이상을&nbsp;벌 수 있는 사내가 되겠군. 그리고 이런 생각은 이해진 의장님의 이야기와는 반대였고&nbsp;저는 정말 궁금했습니다.내가 나만의 서비스를 만든다면 결과가 어떨까? 내 실력은 진짜일까 가짜일까.남이 만든 회사가 아니라 내가 창조해낸 제품으로 단 돈 만원이라도 벌어보고 싶다. 딱 만원만 벌고 실패해도 좋으니 내 진짜 실력이라는 걸&nbsp;테스트해보고 싶어. --- 어릴 때 스포츠 선수들이 연봉 때문에 재계약을 안 하고 싸우는 것을 보면 이상했습니다.돈을 저렇게 많이 받는데 그깟 몇 프로 더 받으려고 저렇게 싸워가면서 뻐팅긴다고?이런 질문을 어른들에게 하면&nbsp;어김없이 이런 대답이 돌아왔습니다."스포츠 선수들은 연봉을 실력으로 생각하는 거야. 자기&nbsp;실력을 인정받고 싶은 거지." 이제는 조금 이해할 수 있을 것 같습니다.이 세상에서 진실을 테스트할 수 있는 것 중&nbsp;돈 만한 게 없다는 걸 깨닫게 되었거든요.내 음식이 맛있다 맛없다 하는 말은 별로 중요하지 않습니다. 손님들이 지갑을 열어 기꺼이 지불해주는 돈이 진실인 것입니다. 이런 관점으로 바라보면 본인의 연봉이 곧 그 업에서의 실력이라고 말할 수 있습니다. --- 저는 결국 궁금증을 풀어냈습니다. 1. 이해진 의장님이 한 말은 사실이었습니다.제가 만든 앱은 하루에 1명도 설치하지 않은 날들이 많았습니다. 너무 우울해서 독한 술로 슬픈 패배감을 달래곤 했습니다. 마음이 어찌나 쓰린지 맥주 같은 술로는 달래지지 않더군요. 2. 회사에서 수수료를 떼어간다는 제 생각은 옳았습니다.회사에서 연봉 1억을 받는다면 회사를 그만두면 같은 노력으로 그 이상을 벌 잠재력을 가지고 있습니다.사람들이 많이 오해하는 부분은 '같은 노력' 부분인 것 같습니다.적어도 회사에서 하는 만큼은 일해야 하는데 덜 노력하고 더 벌려고 하니 쉽지가 않습니다. 3. 이 잠재력은 쉽게 발현되지 않습니다.최소한 1년. 통상 3년 정도는 해봐야 결과가 나옵니다. 10년이 걸릴 수도 있습니다.사람들은 충분한 잠재력을 가지고 있지만 결과가 나오기 전에 포기합니다.하지만 이 날 이해진 의장님은 또 한 가지 말씀을 해주셨습니다."성공은요, 실패하고 실패하다가 더 물러설 곳 없는 마지막 한 걸음에 나오는 거예요." 이 말은 제가 포기하지 않을 수 있게 도와줬습니다. 4. 저는 실력이 있는 사람이었습니다.이걸 알게 된 것이 가장 큰 소득입니다.4년의 노력 끝에 드디어 회사 다닐 때의 연봉을 넘어섰습니다.더 이상 제 자신에 대해 의심하지 않게 된 것이 너무너무 기쁩니다.저는 스스로의 힘으로 세상에 가치를 만들어 낼 수 있고 돈을 벌 수 있는 존재라는 것을 깨닫게 되니 그제야 평안을 얻게 되었달까요? 더 이상 다른 사람들이 부럽지 않게 되었습니다. 본인이 진짜 얼마짜리 사람인지 알고 싶나요?회사를 그만두고 혼자서 도전해보는 것만큼 좋은 방법도 없는 것 같습니다.어쩌면 회사는 자신의 온전한 가치를 드러낼 수 없게 상한선을 막고 있는 존재 아닐까 하는 생각을 합니다.이 울타리를 깨고 나와야만 자신을 테스트해볼 수 있습니다.외롭고 고된 길이지만 도전할만한 가치가 있습니다.이 길은 자기가 누구인지&nbsp;찾아가는 과정이고 그 열매는 너무 달콤하거든요.이제야 저는 저를 찾았습니다.

나는 얼마짜리 사람인가?

많은 공감과 위로가 되는 글이네요. 저도 회사를 나와서 이용자가 하루에 몇명 안되는 서비스를 개발 운영하고 있는데, 참 위로가 많이 되네요.
본인을 찾게 되기까지 4년의 시간에 축하를 보내고, 앞으로 더욱 번창하실 개발자님의 미래를 응원 합니다.
댓글 쓰다 다시 글쓴이를 보니 예전에 본 글 주인이시네요. 글쓴이님 글 보고 용기를 내서 창업했습니다~ 좋은 글 감사합니다.

Java가 느리고 무겁다는 말도 이제 다 옛날 말이긴 하다. Java 생태계가 좋아진 것도 있긴 하지만, 그보다 Java/Spring은 가만히 있었는데 걍 다른 애들이 무거워짐..(…)

Java가 느리고 무겁다는 말도 이제 다 옛날 말이긴 하다. Java 생태계가 좋아진 것도 있긴 하지만, 그보다 Java/Spring은 가만히 있었는데 걍 다른 애들이 무거워짐..(…)

가만보면 프레임워크들은 무게로 나이를 먹어가는거 같네요

LLM 의 수학 성능 논란 중, 9.9 보다 9.11 이 더 크다고 하는 것이 있었는데, 나는 이상함을 눈치채지 못했었다. 그 이유는 뇌가 SemVer(Semantic Versioning)에 절여져 있기 때문.. 🫠

이 문제는 토크나이저 문제가 영향을 준 것이긴 해서, 실제로 SemVer 때문에 발생한 것일 수도 있을 것 같긴 함.

LLM 의 수학 성능 논란 중, 9.9 보다 9.11 이 더 크다고 하는 것이 있었는데, 나는 이상함을 눈치채지 못했었다. 그 이유는 뇌가 SemVer(Semantic Versioning)에 절여져 있기 때문.. 🫠 이 문제는 토크나이저 문제가 영향을 준 것이긴 해서, 실제로 SemVer 때문에 발생한 것일 수도 있을 것 같긴 함.

이런 현상은 생각하지 못했는데요… 와… 😹

In this report, we analyze more than 5 million pull requests from over 35,000 engineers to examine the current state of code review. Here's what we found:

Graphite's State of code review 2024

Stacked Pull Request 서비스를 하는 Graphite에서 만든 코드 리뷰 현황에 대한 보고서입니다.

Stacked PR 혹은 Stacked chages라고 하는 것은 Pull Request로 변경사항을 만들어서 올리면 동료나 메인테이너의 코드리뷰와 승인을 받아야 하기 때문에 어느정도 시간이 걸리기 마련입니다. Pull Request를 올리고 그냥 기다릴 수 없으므로 다른 작업을 이어서 하게 되는데 상황에 따라서는 올려놓은 변경사항을 기반으로 해야 하는 경우가 종종 생깁니다. 그리고 Pull Request를 올릴때는 변경사항이 작아야 더 리뷰를 빨리 받을 수 있고 리뷰하는 사람도 쉽게 할 수 있기 때문에 하나의 작업이라도 단위를 작게 나누어서 올리는 것을 더 권장하는데 이러면 자연히 Pull Request를 올려놓고 그 코드 위에서 추가 작업을 해야 합니다.

이렇게 Pull Request가 서로 의존성을 가지고 쌓아진 것을 Stacked PR이라고 부릅니다. Git으로도 할 수는 있지만 리뷰할 때도 stacked에서 아래부분부터 하는게 좋기 때문에 PR에 그러한 내용도 표시해야하고 PR의 코드 변경사항이 계속 누적되지 않게 하려면 앞의 PR의 브랜치를 타켓으로 올리고 가장 아래 있는 PR이 되었을 때만 main을 보게 하는게 좋기 때문에 리뷰진행에 따라서 계속 git rebase 등을 해주어야하는 번거로움이 있는데 이러한 과정을 자동화해주는 서비스가 Graphite입니다.

Graphite를 쓴다는 것은 코드리뷰를 한다는 의미이므로 (아마도) 고객을 대상으로 3만여명의 엔지니어가 올린 500만건 이상의 Pull Request를 분석한 보고서입니다.

 1. 코드 리뷰로 인해서 작은 조직이 큰 조직보다 3배 빠르게 코드를 배포합니다.
 2. 스타트업에서 TypeScript는 새로운 JavaScript입니다.
 3. 모노레포를 사용하는 회사는 Pull Request를 머지하는데 64% 더 오래 걸립니다.
 4. 이상적인 Pull Request는 50라인 이하입다. 50라인 이하는 머지까지 100분 정도의 시간이 걸리고 라인 수가 늘어나면 시간이 크게 증가합니다.
 5. 50명 이상 기업의 CI 실행시간이 50명 이하 기업보다 2배 더 오래 걸립니다.
 6. 100명 이상의 기업은 Merge Queue를 사용할 가능성이 작은 기업보다 2배 이상 높습니다.

https://graphite.dev/blog/state-of-code-review-2024

Stacked Pull Request 서비스를 하는 Graphite에서 만든 코드 리뷰 현황에 대한 보고서입니다. Stacked PR 혹은 Stacked chages라고 하는 것은 Pull Request로 변경사항을 만들어서 올리면 동료나 메인테이너의 코드리뷰와 승인을 받아야 하기 때문에 어느정도 시간이 걸리기 마련입니다. Pull Request를 올리고 그냥 기다릴 수 없으므로 다른 작업을 이어서 하게 되는데 상황에 따라서는 올려놓은 변경사항을 기반으로 해야 하는 경우가 종종 생깁니다. 그리고 Pull Request를 올릴때는 변경사항이 작아야 더 리뷰를 빨리 받을 수 있고 리뷰하는 사람도 쉽게 할 수 있기 때문에 하나의 작업이라도 단위를 작게 나누어서 올리는 것을 더 권장하는데 이러면 자연히 Pull Request를 올려놓고 그 코드 위에서 추가 작업을 해야 합니다. 이렇게 Pull Request가 서로 의존성을 가지고 쌓아진 것을 Stacked PR이라고 부릅니다. Git으로도 할 수는 있지만 리뷰할 때도 stacked에서 아래부분부터 하는게 좋기 때문에 PR에 그러한 내용도 표시해야하고 PR의 코드 변경사항이 계속 누적되지 않게 하려면 앞의 PR의 브랜치를 타켓으로 올리고 가장 아래 있는 PR이 되었을 때만 main을 보게 하는게 좋기 때문에 리뷰진행에 따라서 계속 git rebase 등을 해주어야하는 번거로움이 있는데 이러한 과정을 자동화해주는 서비스가 Graphite입니다. Graphite를 쓴다는 것은 코드리뷰를 한다는 의미이므로 (아마도) 고객을 대상으로 3만여명의 엔지니어가 올린 500만건 이상의 Pull Request를 분석한 보고서입니다. <ol ><li> 코드 리뷰로 인해서 작은 조직이 큰 조직보다 3배 빠르게 코드를 배포합니다.</li><li>스타트업에서 TypeScript는 새로운 JavaScript입니다.</li><li>모노레포를 사용하는 회사는 Pull Request를 머지하는데 64% 더 오래 걸립니다.</li><li>이상적인 Pull Request는 50라인 이하입다. 50라인 이하는 머지까지 100분 정도의 시간이 걸리고 라인 수가 늘어나면 시간이 크게 증가합니다.</li><li>50명 이상 기업의 CI 실행시간이 50명 이하 기업보다 2배 더 오래 걸립니다.</li><li>100명 이상의 기업은 Merge Queue를 사용할 가능성이 작은 기업보다 2배 이상 높습니다.</li></ol> https://graphite.dev/blog/state-of-code-review-2024

Graphite.dev

최근 커리어 코칭 이야기이다. 비전공으로 시작해서 지난 7년간 어떻게 꾸역꾸역해왔지만 본인이 7년차에 해당하는 능력이나 경험이 있는지 의문이 있었고 어떻게 커리어를 이끌어가야할지 질문을 가지고 있었다.

일단 본인에게 7년간 일하면서 생긴 상처와 문제에 대해 어느 정도 인지를 하고 있었다. 사실 이는 생각보다 쉽지 않다. 상처는 일단 인지가 되면 치유되기 시작한다. 이야기를 계속하며 느낀 점은 본인의 지금까지의 경험을 안 좋은 쪽에서만 바라보고 있다는 점이었다. 모든 관점은 양면이 밸런스가 되어야 의미가 있다. 우리는 보통 회고를 하거나 복기를 하라고 하면 장점, 강점, 좋은 점보다는 단점, 약점, 아쉬운 점에 집중하며 이는 부정적인 마음으로 이어지기 쉽다.

내가 해준 조언은 다음과 같았다.

 1. 본인을 사랑해야 하며 이는 본인의 과거 경력을 물경력이 아닌 땀경력이라 바라보며 나에게 그 동안 수고했다고 이야기해주자
 2. 다음으로 연차의 압박은 보통 본인의 나이가 많다고 생각할 때 더 고통스럽기에 본인의 나이가 많다고 생각하지 말고 아직 남은 시간들을 생각해보자. 생각보다 내 앞에 많은 시간들이 남아있다.

마지막으로 이 분의 메인 질문이었던 진정한 시니어 개발자가 되는 길에 대해서는 문제해결 능력을 가져야 하는데 개인기로 문제를 해결하는 단계에서 다른 사람들과의 협업을 통해 그룹 단위로 더 큰 문제를 해결할 수 있어야 하며 이게 되려면 의사소통 능력이 중요하다는 이야기를 해주었다.

메타인지가 좋았고 발전에 대한 의지가 있었기에 이 분은 커리어를 잘 발전시킬 수 있으리라 믿는다. 우리 모두 나이나 연차의 압박을 받으며 조급하기 보다는 현재에 집중하며 커리어를 길게 바라보며 나를 사랑하자!

최근 커리어 코칭 이야기이다. 비전공으로 시작해서 지난 7년간 어떻게 꾸역꾸역해왔지만 본인이 7년차에 해당하는 능력이나 경험이 있는지 의문이 있었고 어떻게 커리어를 이끌어가야할지 질문을 가지고 있었다. 일단 본인에게 7년간 일하면서 생긴 상처와 문제에 대해 어느 정도 인지를 하고 있었다. 사실 이는 생각보다 쉽지 않다. 상처는 일단 인지가 되면 치유되기 시작한다. 이야기를 계속하며 느낀 점은 본인의 지금까지의 경험을 안 좋은 쪽에서만 바라보고 있다는 점이었다. 모든 관점은 양면이 밸런스가 되어야 의미가 있다. 우리는 보통 회고를 하거나 복기를 하라고 하면 장점, 강점, 좋은 점보다는 단점, 약점, 아쉬운 점에 집중하며 이는 부정적인 마음으로 이어지기 쉽다. 내가 해준 조언은 다음과 같았다. <ol ><li>본인을 사랑해야 하며 이는 본인의 과거 경력을 물경력이 아닌 땀경력이라 바라보며 나에게 그 동안 수고했다고 이야기해주자</li><li>다음으로 연차의 압박은 보통 본인의 나이가 많다고 생각할 때 더 고통스럽기에 본인의 나이가 많다고 생각하지 말고 아직 남은 시간들을 생각해보자. 생각보다 내 앞에 많은 시간들이 남아있다.</li></ol> 마지막으로 이 분의 메인 질문이었던 진정한 시니어 개발자가 되는 길에 대해서는 문제해결 능력을 가져야 하는데 개인기로 문제를 해결하는 단계에서 다른 사람들과의 협업을 통해 그룹 단위로 더 큰 문제를 해결할 수 있어야 하며 이게 되려면 의사소통 능력이 중요하다는 이야기를 해주었다. 메타인지가 좋았고 발전에 대한 의지가 있었기에 이 분은 커리어를 잘 발전시킬 수 있으리라 믿는다. 우리 모두 나이나 연차의 압박을 받으며 조급하기 보다는 현재에 집중하며 커리어를 길게 바라보며 나를 사랑하자!

시니어 개발자가 되려면 어디에 집중을 해야할까요?

Step up your game and make your next kickoff the best meeting you've ever facilitated - a meeting that people will remember for months.

10 tips for a great project kickoff - LogRocket Blog

여러분들은 프로젝트 킥오프 어떻게 하고 계시나요? 팀이 무엇을 해낼 것인지 목표를 명확히하고 성공 지표를 함께 고민하고, 서로의 사기를 높이는 것! 프로젝트의 첫 단추인 만큼 프로젝트 성공에 있어서도 중요한 열쇠가 되어 줄 수 있는 킥오프. 그만큼 잘 준비해야겠죠?

# 킥오프 전 준비
 1. 팩트팩 공유: 중요한 정보를 미리 공유해 회의 준비를 돕습니다.
 2. 즉석 게스트 초대: 특정 주제에 전문가를 초대해 회의를 효율적으로 운영합니다.
 3. 의제 공유: 회의 전에 의제를 공유하고 피드백을 받습니다.
 4. 오후 회의 피하기: 중요한 회의는 오전에 진행해 집중도를 높입니다.

# 킥오프 중
 1. 아이스 브레이커 활용: 팀원들 간의 관계 형성과 이해를 돕습니다.
 2. Q&A에 집중: 프레젠테이션보다 토론과 질문에 중점을 둡니다.
 3. 이름 자주 사용하기: 이름을 자주 사용해 집중력과 참여도를 높입니다.

# 킥오프 후
 1. 상세 요약 발송: 회의 후 요약을 상세히 작성해 공유합니다.
 2. 후속 회의 설정: 후속 회의를 통해 진행 상황을 점검하고 책임감을 높입니다.
 3. 피드백 수집 및 교훈 기록: 피드백을 모아 다음 회의에 반영합니다.

https://blog.logrocket.com/product-management/10-tips-for-a-great-project-kickoff/

여러분들은 프로젝트 킥오프 어떻게 하고 계시나요? 팀이 무엇을 해낼 것인지 목표를 명확히하고 성공 지표를 함께 고민하고, 서로의 사기를 높이는 것! 프로젝트의 첫 단추인 만큼 프로젝트 성공에 있어서도 중요한 열쇠가 되어 줄 수 있는 킥오프. 그만큼 잘 준비해야겠죠? # 킥오프 전 준비<ol ><li>팩트팩 공유: 중요한 정보를 미리 공유해 회의 준비를 돕습니다.</li><li>즉석 게스트 초대: 특정 주제에 전문가를 초대해 회의를 효율적으로 운영합니다.</li><li>의제 공유: 회의 전에 의제를 공유하고 피드백을 받습니다.</li><li>오후 회의 피하기: 중요한 회의는 오전에 진행해 집중도를 높입니다.</li></ol> # 킥오프 중<ol ><li>아이스 브레이커 활용: 팀원들 간의 관계 형성과 이해를 돕습니다.</li><li>Q&amp;A에 집중: 프레젠테이션보다 토론과 질문에 중점을 둡니다.</li><li>이름 자주 사용하기: 이름을 자주 사용해 집중력과 참여도를 높입니다.</li></ol> # 킥오프 후<ol ><li>상세 요약 발송: 회의 후 요약을 상세히 작성해 공유합니다.</li><li>후속 회의 설정: 후속 회의를 통해 진행 상황을 점검하고 책임감을 높입니다.</li><li>피드백 수집 및 교훈 기록: 피드백을 모아 다음 회의에 반영합니다.</li></ol> https://blog.logrocket.com/product-management/10-tips-for-a-great-project-kickoff/

LogRocket Blog

프로젝트 킥오프 10가지 팁

Hey, I'm Vince I'm a self-taught developer that changed careers during the Covid... Tagged with productivity, beginners, learning, indiehacker.

Why you should ship your app, even if it sucks

"Done is better than perfect."

제품을 개발하는 사람들이라면 한번쯤은 분명 들어봤겠지만, 또 자식같은 내 제품이 이왕이면 예쁜 모습, 제대로 된 모습으로 보이고 싶은 마음에 조금만 더 조금만 더, 아직 구리니까 더 시간을 들여보자. 하는게 또 우리의 모습인 것 같습니다.

그럼에도 불구하고! 구린 모습이라도 반드시 배포되어야 하는 이유는 뭘까요?

결과에 집착하지 말기
 * 결과에 너무 집착하면 부정적인 생각에 빠지기 쉽습니다.
 * 자신의 가치와 결과물을 분리하고, 피드백을 받아들여 앞으로 나아가는 것이 중요합니다.

학습을 멈추고 실행하기
 * 더 이상 학습에만 몰두하지 말고 코딩을 시작하세요.
 * 학습은 중요하지만, 지금 당장 필요한 문제 해결에 집중하는 것이 더 효과적입니다.

다른 사람의 작업을 참고하기
 * 라이브러리나 오픈 소스 코드, 디자인을 적극적으로 활용하세요.
 * 시간을 절약하고 더 많은 것을 배울 수 있습니다.

하나의 기능씩 개발하기
 * 과도한 계획보다는 기능 단위로 작업을 나누어 진행하세요.
 * 작은 성취감을 통해 동기부여를 유지할 수 있습니다.

초기에 배포하기
 * 초기의 불완전한 상태에서도 배포를 두려워하지 마세요.
 * 피드백을 통해 더 나은 방향으로 개선해 나갈 수 있습니다.

끝까지 완성하기
 * 만족스럽지 않더라도 끝까지 완성하는 습관을 길러야 합니다.
 * 완성하는 과정에서 많은 것을 배우게 됩니다.

제품에 있어서 완벽이란 없습니다. 그저 계속해서 발전해나가는 것 뿐이죠.

https://dev.to/wasp/why-you-should-ship-your-app-even-if-it-sucks-23k7

"Done is better than perfect." 제품을 개발하는 사람들이라면 한번쯤은 분명 들어봤겠지만, 또 자식같은 내 제품이 이왕이면 예쁜 모습, 제대로 된 모습으로 보이고 싶은 마음에 조금만 더 조금만 더, 아직 구리니까 더 시간을 들여보자. 하는게 또 우리의 모습인 것 같습니다. 그럼에도 불구하고! 구린 모습이라도 반드시 배포되어야 하는 이유는 뭘까요? 결과에 집착하지 말기<ul ><li>결과에 너무 집착하면 부정적인 생각에 빠지기 쉽습니다.</li><li>자신의 가치와 결과물을 분리하고, 피드백을 받아들여 앞으로 나아가는 것이 중요합니다.</li></ul> 학습을 멈추고 실행하기<ul ><li>더 이상 학습에만 몰두하지 말고 코딩을 시작하세요.</li><li>학습은 중요하지만, 지금 당장 필요한 문제 해결에 집중하는 것이 더 효과적입니다.</li></ul> 다른 사람의 작업을 참고하기<ul ><li>라이브러리나 오픈 소스 코드, 디자인을 적극적으로 활용하세요.</li><li>시간을 절약하고 더 많은 것을 배울 수 있습니다.</li></ul> 하나의 기능씩 개발하기<ul ><li>과도한 계획보다는 기능 단위로 작업을 나누어 진행하세요.</li><li>작은 성취감을 통해 동기부여를 유지할 수 있습니다.</li></ul> 초기에 배포하기<ul ><li>초기의 불완전한 상태에서도 배포를 두려워하지 마세요.</li><li>피드백을 통해 더 나은 방향으로 개선해 나갈 수 있습니다.</li></ul> 끝까지 완성하기<ul ><li>만족스럽지 않더라도 끝까지 완성하는 습관을 길러야 합니다.</li><li>완성하는 과정에서 많은 것을 배우게 됩니다.</li></ul> 제품에 있어서 완벽이란 없습니다. 그저 계속해서 발전해나가는 것 뿐이죠. https://dev.to/wasp/why-you-should-ship-your-app-even-if-it-sucks-23k7

DEV Community

당신의 제품이 아무리 구려도 꼭 배포되어야 하는 이유

개발 업무를 하다 보면, 해당 프로그래밍 언어에 익숙해져야 하는 건 물론이지만,

그 전에 영어에 익숙해져야 하는 게 기본이겠죠?

저는 학창시절에 영어를 그렇게 열심히 공부하지 않아서, 고생을 많이 한 편인데,
이 고생은 경력이 쌓일 수록 '영어로 커뮤니케이션이 필요한 때' 가 많아져서 더 어려움을 겪게 되는 것 같아요.

길벗에서 '개발자가 영어도 잘해야 하나요?' 란 책을 마침 보내주셔서 읽어보았는데,
업무에서 부족한 영어실력으로 어려움을 겪고 있거나, 조금 더 영어에 익숙해졌으면 하는 소망을 가지고 있는 분들이 있다면 도움이 많이 될 책인 것 같아요.

책 크기도 얇고 작아서, 출퇴근 길에 조금씩 읽기에도 좋을 듯 해요.

책은 크게
1. 개발자 영어 학습을 위한 기초 준비
 2. 소프트웨어 개발 단계별 실무 영어
 3. 소프트웨어 개발 분야별 실무 영어
 4. 개발자 비즈니스 실전 영어
 5. 미국 대학원(CS) 진학을 위한 영어
 6. 해외 개발자 취업을 위한 영어
 7. 개발자를 위한 영어 사전
챕터로 이루어져 있는데요.

제가 책에서 가장 좋았던 부분은,
 * 간혹 레딧등 해외 기술 커뮤니티나 GitHub PR 에서 사용되는 약어들(FYI, BTW, YAGNI...) 에 대한 설명
 * AWS 등 Service Provider에 영문으로 Support Case를 쓸 때 참고할 수 있는 현재 문제되는 (장애상황, 특정 이슈로 개발이 지연되는)상황을 설명하기 위한 표현
 * 회의나, 업무 요청에서 정중하게 상대방의 양해를 구하며, 요청을 할 수 있는 표현
 * 실전 예제로 설명된 영어권 IT 기업의 기술인터뷰에서 사용할 수 있는 간결한 문법들
 * 고객에게 이메일 보내는 법 등

업무를 하면서 누구나 한번쯤 영어의 어려움으로 부딪혔을 법한 예제들과 표현으로 책이 쓰여져있다는 부분이었어요.

특히 3장 개발분야별 영어에서는 프론트엔드, 백엔드, DB, 모바일 어플리케이션 개발 등에서 동료와 커뮤니케이션을 위해 사용할 수 있는 표현들이 예제로 나열되어 있어서 영어로 PR 리뷰를 진행하는 오픈소스에 참여하거나, 해외 동료들과 프로젝트를 함께하는 분들에게도 도움이 될 것 같아요.

생각해보면 한국어로도 명사는 계속 바뀌지만, 업무를 하다보면 반복되는 표현들이 있고, 한국에서 쭉 개발을 하다, 해외로 떠나 개발을 계속 하시는 저자 분이 그런 가려운 부분을 잘 긁어주셨다는 생각이 들어요.

물론 책 한권으로 비즈니스 영어를 전부 마스터 할 수는 없겠지만, 어디서 부터 '개발자를 위한 영어공부' 를 시작해야 할지 감을잡지 못해 고민이거나, 매일 조금씩 업무에서 사용할법한 영어 표현들을 공부하고자 마음먹은 분들이 있다면 '개발자가 영어도 잘해야 하나요?' 로 시작해보면 어떨까 하고 생각했어요.

저는 8월부터 휴직 중에 있는데, 이 기간동안 영어공부도 해야지! 하고 마음먹고 있다가 마침 좋은 책을 보내주셔서 쉬는 틈틈이 읽어보고 있어요. 프로그래밍 언어만큼이나, 더 공부하고 익숙해질수록 나의 가능성을 넓혀주는 영어공부, 미루지말고 지금부터 꾸준히 시작해보면 어떨까요?

개발 업무를 하다 보면, 해당 프로그래밍 언어에 익숙해져야 하는 건 물론이지만, 그 전에 영어에 익숙해져야 하는 게 기본이겠죠? 저는 학창시절에 영어를 그렇게 열심히 공부하지 않아서, 고생을 많이 한 편인데,이 고생은 경력이 쌓일 수록 '영어로 커뮤니케이션이 필요한 때' 가 많아져서 더 어려움을 겪게 되는 것 같아요. 길벗에서 '개발자가 영어도 잘해야 하나요?' 란 책을 마침 보내주셔서 읽어보았는데,업무에서 부족한 영어실력으로 어려움을 겪고 있거나, 조금 더 영어에 익숙해졌으면 하는 소망을 가지고 있는 분들이 있다면 도움이 많이 될 책인 것 같아요. 책 크기도 얇고 작아서, 출퇴근 길에 조금씩 읽기에도 좋을 듯 해요. 책은 크게1. 개발자 영어 학습을 위한 기초 준비<ol start="2"><li>소프트웨어 개발 단계별 실무 영어</li><li>소프트웨어 개발 분야별 실무 영어</li><li>개발자 비즈니스 실전 영어</li><li>미국 대학원(CS) 진학을 위한 영어</li><li>해외 개발자 취업을 위한 영어</li><li>개발자를 위한 영어 사전</li></ol>챕터로 이루어져 있는데요. 제가 책에서 가장 좋았던 부분은,<ul ><li>간혹 레딧등 해외 기술 커뮤니티나 GitHub PR 에서 사용되는 약어들(FYI, BTW, YAGNI...) 에 대한 설명</li><li>AWS 등 Service Provider에 영문으로 Support Case를 쓸 때 참고할 수 있는 현재 문제되는 (장애상황, 특정 이슈로 개발이 지연되는)상황을 설명하기 위한 표현</li><li>회의나, 업무 요청에서 정중하게 상대방의 양해를 구하며, 요청을 할 수 있는 표현</li><li>실전 예제로 설명된 영어권 IT 기업의 기술인터뷰에서 사용할 수 있는 간결한 문법들</li><li>고객에게 이메일 보내는 법 등</li></ul> 업무를 하면서 누구나 한번쯤 영어의 어려움으로 부딪혔을 법한 예제들과 표현으로 책이 쓰여져있다는 부분이었어요. 특히 3장 개발분야별 영어에서는 프론트엔드, 백엔드, DB, 모바일 어플리케이션 개발 등에서 동료와 커뮤니케이션을 위해 사용할 수 있는 표현들이 예제로 나열되어 있어서 영어로 PR 리뷰를 진행하는 오픈소스에 참여하거나, 해외 동료들과 프로젝트를 함께하는 분들에게도 도움이 될 것 같아요. 생각해보면 한국어로도 명사는 계속 바뀌지만, 업무를 하다보면 반복되는 표현들이 있고, 한국에서 쭉 개발을 하다, 해외로 떠나 개발을 계속 하시는 저자 분이 그런 가려운 부분을 잘 긁어주셨다는 생각이 들어요. 물론 책 한권으로 비즈니스 영어를 전부 마스터 할 수는 없겠지만, 어디서 부터 '개발자를 위한 영어공부' 를 시작해야 할지 감을잡지 못해 고민이거나, 매일 조금씩 업무에서 사용할법한 영어 표현들을 공부하고자 마음먹은 분들이 있다면 '개발자가 영어도 잘해야 하나요?' 로 시작해보면 어떨까 하고 생각했어요. 저는 8월부터 휴직 중에 있는데, 이 기간동안 영어공부도 해야지! 하고 마음먹고 있다가 마침 좋은 책을 보내주셔서 쉬는 틈틈이 읽어보고 있어요. 프로그래밍 언어만큼이나, 더 공부하고 익숙해질수록 나의 가능성을 넓혀주는 영어공부, 미루지말고 지금부터 꾸준히 시작해보면 어떨까요?

'개발자가 영어도 잘해야 하나요?' 를 읽고...

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다.

어설프게 설계부터 먼저하면 나중에 고통 받는 일이 더 많아진다. 처음부터 완성되어 있는 설계가 어딨나. 많은 메이저 소프트웨어들이 처음 설계 보면 겁나 구리고, 그래서 하위 호환을 무시하고 완전히 새로운 패러다임으로 넘어가는 것이 비일비재하다.

분야에 따라 다를 수 있지만, 보통 소프트웨어 설계는 구현에서 따라오는 것으로 단계적으로 진행되는 것이지, 설계부터 시작하는 건 패망의 지름길이다.

더군다나 코딩 속도가 빨라지고 자동화되는 AI 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다.

설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다. 어설프게 설계부터 먼저하면 나중에 고통 받는 일이 더 많아진다. 처음부터 완성되어 있는 설계가 어딨나. 많은 메이저 소프트웨어들이 처음 설계 보면 겁나 구리고, 그래서 하위 호환을 무시하고 완전히 새로운 패러다임으로 넘어가는 것이 비일비재하다. 분야에 따라 다를 수 있지만, 보통 소프트웨어 설계는 구현에서 따라오는 것으로 단계적으로 진행되는 것이지, 설계부터 시작하는 건 패망의 지름길이다. 더군다나 코딩 속도가 빨라지고 자동화되는 AI 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다. 설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.

소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다.

어

Intense competition among juniors, AI taking over jobs, and ongoing crises - why these shouldn't... Tagged with productivity, beginners, career, ai.

Starting from Scratch in IT in 2024: Things you shouldn't worry about

모두에게 "처음" 이라는 순간이 존재하는데, 그걸 알면서도 마음이 불편한건 어쩔 수 없는 것 같습니다. 이제 개발 분야에 처음 입문하려는 분들에게는 시니어들은 모두 "그땐 그런거야" 라고 하지만, 아무리 그런 조언을 들어도 걱정스러운 것들이 참 많은 것 같습니다. 거기다 유튜브며 트위터며, 오히려 그 걱정을 자극적인 소재로 '이런 것도 잘 모르고, 경험 없는 나는 어쩌지...?' 라는 공포심마저 들게 하는 안타까운 상황들도 종종 보이곤 합니다.

여기 10년을 일하며 느낀 미리 걱정 안했어도 되는 4가지에 정리한 글이 있어 공유해봅니다.

 * 경쟁에 대한 두려움 : IT 분야는 경쟁이 치열하지만, 꾸준히 노력하고 자신을 발전시키는 사람에게는 오히려 기회가 더 많이 찾아옵니다! 자신만의 강점을 찾고 집중하세요.
 * AI에 대한 걱정 : AI는 적이 아니라 도구입니다. AI를 활용해 학습과 생산성을 높이고, 더 나은 결과를 만들어낼 수 있습니다.
 * 경제적 불안 : 경제 위기에도 불구하고, 기술이 뛰어난 인재는 항상 수요가 있습니다. 자신의 기술을 끊임없이 업데이트하고 발전시키는 것이 중요합니다.
 * 개인적인 노력과 지속적인 학습 : 성공적인 IT 커리어를 위해서는 끊임없는 학습과 노력이 필요합니다. 새로운 기술과 트렌드를 따라가며 자신을 꾸준히 발전시키세요.
   
   
기술 변화, 경제적 불안, 경쟁은 시간이 지나도 사실 변치 않는 도전 과제인 것 같습니다. 불안함을 고통이 아닌 나를 움직일 수 있는 수단으로 바꾸어 끊임없이 노력하는 자세가 나의 10년 아니 더 긴 시간을 바꿀 수 있는 발판이 되어줄 것입니다.

https://dev.to/vorniches/starting-from-scratch-in-it-in-2024-things-you-shouldnt-worry-about-4p17

모두에게 "처음" 이라는 순간이 존재하는데, 그걸 알면서도 마음이 불편한건 어쩔 수 없는 것 같습니다. 이제 개발 분야에 처음 입문하려는 분들에게는 시니어들은 모두 "그땐 그런거야" 라고 하지만, 아무리 그런 조언을 들어도 걱정스러운 것들이 참 많은 것 같습니다. 거기다 유튜브며 트위터며, 오히려 그 걱정을 자극적인 소재로 '이런 것도 잘 모르고, 경험 없는 나는 어쩌지...?' 라는 공포심마저 들게 하는 안타까운 상황들도 종종 보이곤 합니다. 여기 10년을 일하며 느낀 미리 걱정 안했어도 되는 4가지에 정리한 글이 있어 공유해봅니다. <ul ><li>경쟁에 대한 두려움 : IT 분야는 경쟁이 치열하지만, 꾸준히 노력하고 자신을 발전시키는 사람에게는 오히려 기회가 더 많이 찾아옵니다! 자신만의 강점을 찾고 집중하세요.</li><li>AI에 대한 걱정 : AI는 적이 아니라 도구입니다. AI를 활용해 학습과 생산성을 높이고, 더 나은 결과를 만들어낼 수 있습니다.</li><li>경제적 불안 : 경제 위기에도 불구하고, 기술이 뛰어난 인재는 항상 수요가 있습니다. 자신의 기술을 끊임없이 업데이트하고 발전시키는 것이 중요합니다.</li><li>개인적인 노력과 지속적인 학습 : 성공적인 IT 커리어를 위해서는 끊임없는 학습과 노력이 필요합니다. 새로운 기술과 트렌드를 따라가며 자신을 꾸준히 발전시키세요. </li></ul>기술 변화, 경제적 불안, 경쟁은 시간이 지나도 사실 변치 않는 도전 과제인 것 같습니다. 불안함을 고통이 아닌 나를 움직일 수 있는 수단으로 바꾸어 끊임없이 노력하는 자세가 나의 10년 아니 더 긴 시간을 바꿀 수 있는 발판이 되어줄 것입니다. https://dev.to/vorniches/starting-from-scratch-in-it-in-2024-things-you-shouldnt-worry-about-4p17

처음부터 걱정하지 않았어도 되었던 것들

이걸 확 관둬? 말어? 사직서를 던질지, 한 번 더 참을지 고민하고 있다면 주목. 하버드 경영 대학원이 발표한 퇴사할 때가 되었다는 지표를 준비했다. 아래 내용 중 과반수 이상에 '그렇다'는 답변이 나왔다면 이제 그곳을 떠나도 좋다.➊ 일이 나를 성장시키지 않는다운동선수들은 때때로 운동

하버드 석학이 알려주는, 회사 그만둘지 버틸지 구별하는 방법 5

1. 지금 회사에서 하는 일이 더 이상 내 성장에 도움이 되지 않는다고 느낄 때

2. 일에 대한 열망이 사라지고, 회사에서 더 이룰 것이 없다고 느낄 때

3. 몰입이 안 되고 회사에서 일을 하기 너무나 싫을 때

4. 가치관과 생각이 맞지 않아 회사에서 자꾸 나쁜 사람이 될 때

5. 신체적으로나 정신적으로 망가졌을 때

1. 지금 회사에서 하는 일이 더 이상 내 성장에 도움이 되지 않는다고 느낄 때 2. 일에 대한 열망이 사라지고, 회사에서 더 이룰 것이 없다고 느낄 때 3. 몰입이 안 되고 회사에서 일을 하기 너무나 싫을 때 4. 가치관과 생각이 맞지 않아 회사에서 자꾸 나쁜 사람이 될 때 5. 신체적으로나 정신적으로 망가졌을 때

GQ korea

하버드 석학이 알려주는 퇴사 타이밍

Alexander Isora 👽 on X: "I stopped writing code entirely in 2024.

I only copy-paste code generated by AI ✌️🤓

How do I do that? 10 hints:

Hint 1: if you have a creative task such as code architecture, you want to use so called chain of thoughts. You add "Think step-by-step" to your prompt and enjoy a https://t.co/cVTTGBKFWs" / X

https://x.com/alexanderisorax/status/1819671375759487270

원문 작성자는 2024년 코드 작성을 멈추고 생성AI가 제공하는 코드만 복붙했다고 하네요.

그러면서 10가지 팁을 남겼습니다. 그중 5번 팁이 인상깊었습니다.

작업을 사람에게 설명하는것처럼 프롬프트를 작성하는데 시간을 보내라고 하네요.

조금더 이 작업을 쉽게하려면 생성AI가 도구가 아니라 공동작업자로 생각해야겠네요.

Hint 5: Use clear and specific prompts. The more precise and detailed your request, the better the AI can understand and generate the code you need. Include details about the desired functionality: input/output type, error handling, UI behaviour etc. Spend time on writing a good prompt like if you were spending time explaining your task to a human.

https://x.com/alexanderisorax/status/1819671375759487270 원문 작성자는 2024년 코드 작성을 멈추고 생성AI가 제공하는 코드만 복붙했다고 하네요. 그러면서 10가지 팁을 남겼습니다. 그중 5번 팁이 인상깊었습니다. 작업을 사람에게 설명하는것처럼 프롬프트를 작성하는데 시간을 보내라고 하네요. 조금더 이 작업을 쉽게하려면 생성AI가 도구가 아니라 공동작업자로 생각해야겠네요. Hint 5: Use clear and specific prompts. The more precise and detailed your request, the better the AI can understand and generate the code you need. Include details about the desired functionality: input/output type, error handling, UI behaviour etc. Spend time on writing a good prompt like if you were spending time explaining your task to a human.

X (formerly Twitter)

복붙 엔지니어의 등장

바로 좋은 태도입니다.

사전에 따르면 태도란 어떤 일이나 상황 따위를 대하는 마음가짐.
또는 그 마음가짐이 드러난 자세를 의미합니다.

모르는 문제나 상황에도 주눅이 들지 않는 마음가짐.
자신의 문제를 함께 해결해 줄 수 있는 사람을 찾아 나서는 자세.

연차가 많아도 자기 생각이 늘 정답은 아니란 걸 아는 마음가짐.
모르는 건 솔직하게 물어보는 자세.

모른다고 말해도 사람들이 자신을 이해해 줄 거라고 믿는 마음가짐.
아는 척하지 않고 아는 것만을 말하고, 모르는 사람을 무시하지 않는 자세.

상황과 사람을 탓하지 않는 마음가짐.
할 수 있는 일을, 하던 대로 꾸준히 해내는 자세.

좋은 태도를 가진 사람이 뛰어난 실력을 갖춘 사람보다 낫습니다.
아니, 어쩌면 좋은 태도가 뛰어난 실력을 만드는 것일지도 모릅니다.

바로 좋은 태도입니다. 사전에 따르면 태도란 어떤 일이나 상황 따위를 대하는 마음가짐.또는 그 마음가짐이 드러난 자세를 의미합니다. 모르는 문제나 상황에도 주눅이 들지 않는 마음가짐.자신의 문제를 함께 해결해 줄 수 있는 사람을 찾아 나서는 자세. 연차가 많아도 자기 생각이 늘 정답은 아니란 걸 아는 마음가짐.모르는 건 솔직하게 물어보는 자세. 모른다고 말해도 사람들이 자신을 이해해 줄 거라고 믿는 마음가짐.아는 척하지 않고 아는 것만을 말하고, 모르는 사람을 무시하지 않는 자세. 상황과 사람을 탓하지 않는 마음가짐.할 수 있는 일을, 하던 대로 꾸준히 해내는 자세. 좋은 태도를 가진 사람이 뛰어난 실력을 갖춘 사람보다 낫습니다.아니, 어쩌면 좋은 태도가 뛰어난 실력을 만드는 것일지도 모릅니다.

실력보다 중요한 것

최근 LLM의 환각현상(Hallucination)을 줄이기 위한 대안으로 최근 떠오르는 방법론 중 하나는 "Abstention"입니다. 단어의 뜻은 "기권, 자제"인데요, 우리 말로는 "답변 포기"정도가 될 것 같습니다.

즉, LLM이 스스로가 불확실한 정보에 대해서는 답변을 거부할 수 있도록 하는 방법에 대한 연구인데요, 요즘 관련 연구가 많이 나오는 것 같습니다. 관심 있으신 분들은 시작하기 좋은 논문 3편을 아래에 소개해두었으니 간단하게 살펴보셔도 좋을 것 같습니다.

The Art of Refusal: A Survey of Abstention in Large Language Models
 * LLM의 답변 포기(Abstention) 방법에 대한 Survey Paper
 * 아래 세가지 관점을 기준으로 기존 연구를 분석합니다.
   * (1) The Query: 질문 자체의 모호성으로 답변 회피가 필요한 경우
   * (2) The Model: 모델 지식의 부족으로 답변 회피가 필요한 경우
   * (3) Human Values: 윤리적/사회적 가치 등의 이유로 답변 회피가 필요한 경우
 * https://arxiv.org/pdf/2407.18418

The Art of Saying No: Contextual Noncompliance in Language Models
 * 답변하지 않아도 되는(Noncompliance) 질문 유형을 세분화하고 관련 데이터셋을 제공
 * "(1) The Query" 유형에 해당하는 방법론과 데이터를 소개합니다.
 * AllenAI, University of Washington, Microsoft Research 등 굵직한 기관들이 참여한 논문이네요.
 * https://www.arxiv.org/pdf/2407.12043

R-Tuning: Instructing Large Language Models to Say ‘I Don’t Know’
 * Instruction Tuning 단계에서 모델이 Parametric Knowledge 를 벗어나는 질문에 대해서는 답변하지 않도록 하기 위해 1) 무엇을 모르는 지를 파악하고 2) 모르는 것에 대해서는 답변하지 않도록 학습하는 방법 제시
 * "(2) The Model" 유형에 해당하는 방법론을 제시합니다.
 * 최근 NAACL 2024에서 Outstanding Paper awards를 수상했어요.
 * https://aclanthology.org/2024.naacl-long.394/

최근 LLM의 환각현상(Hallucination)을 줄이기 위한 대안으로 최근 떠오르는 방법론 중 하나는 "Abstention"입니다. 단어의 뜻은 "기권, 자제"인데요, 우리 말로는 "답변 포기"정도가 될 것 같습니다. 즉, LLM이 스스로가 불확실한 정보에 대해서는 답변을 거부할 수 있도록 하는 방법에 대한 연구인데요, 요즘 관련 연구가 많이 나오는 것 같습니다. 관심 있으신 분들은 시작하기 좋은 논문 3편을 아래에 소개해두었으니 간단하게 살펴보셔도 좋을 것 같습니다. The Art of Refusal: A Survey of Abstention in Large Language Models<ul ><li>LLM의 답변 포기(Abstention) 방법에 대한 Survey Paper</li><li>아래 세가지 관점을 기준으로 기존 연구를 분석합니다.<ul ><li>(1) The Query: 질문 자체의 모호성으로 답변 회피가 필요한 경우</li><li>(2) The Model: 모델 지식의 부족으로 답변 회피가 필요한 경우</li><li>(3) Human Values: 윤리적/사회적 가치 등의 이유로 답변 회피가 필요한 경우</li></ul></li><li>https://arxiv.org/pdf/2407.18418</li></ul> The Art of Saying No: Contextual Noncompliance in Language Models<ul ><li>답변하지 않아도 되는(Noncompliance) 질문 유형을 세분화하고 관련 데이터셋을 제공</li><li>"(1) The Query" 유형에 해당하는 방법론과 데이터를 소개합니다.</li><li>AllenAI, University of Washington, Microsoft Research 등 굵직한 기관들이 참여한 논문이네요.</li><li>https://www.arxiv.org/pdf/2407.12043</li></ul> R-Tuning: Instructing Large Language Models to Say ‘I Don’t Know’<ul ><li>Instruction Tuning 단계에서 모델이 Parametric Knowledge 를 벗어나는 질문에 대해서는 답변하지 않도록 하기 위해 1) 무엇을 모르는 지를 파악하고 2) 모르는 것에 대해서는 답변하지 않도록 학습하는 방법 제시</li><li>"(2) The Model" 유형에 해당하는 방법론을 제시합니다.</li><li>최근 NAACL 2024에서 Outstanding Paper awards를 수상했어요.</li><li>https://aclanthology.org/2024.naacl-long.394/</li></ul>

🤐 LLM 분야의 떠오르는 화두: Abstention (기권)

VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다. - 관련 포스팅: https://www.daleseo.com/vscode-cursor/ 목차: 0:00 소개 0:44 영역 선택하기 2:32 단어 단위로 점프 5:54 줄 맨 앞/뒤로 바로 이동 8:19 페이지 단위로 스크롤 12:28 파일 맨 위/아래로 바로 이동 14:02 정리 #vscode #단축키 #코드편집기#커서 #키보드

VSCode 오직 키보드로 커서 제어하기

VSCode에서 효과적으로 코드 편집을 하려면 무엇보다 마우스 커서(cursor)를 원하는 위치로 빠르게 이동하고 원하는 영역을 빠르게 선택하는 것이 매우 중요한데요. 양손으로 키보드로 타이핑을 하다가 커서를 옮기거나 드래그를 하기 위해서 잠깐 잠깐 한 손을 마우스나 트랙패트로 옮기는 것이 은근히 개발 생산성을 떨어뜨릴 수 있기 때문입니다.

이번 영상에서는 VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다.

📺 동영상: https://youtu.be/N2R1tCKT0a8

VSCode에서 효과적으로 코드 편집을 하려면 무엇보다 마우스 커서(cursor)를 원하는 위치로 빠르게 이동하고 원하는 영역을 빠르게 선택하는 것이 매우 중요한데요. 양손으로 키보드로 타이핑을 하다가 커서를 옮기거나 드래그를 하기 위해서 잠깐 잠깐 한 손을 마우스나 트랙패트로 옮기는 것이 은근히 개발 생산성을 떨어뜨릴 수 있기 때문입니다. 이번 영상에서는 VSCode에서 커서를 키보드로 자유자재로 제어하시려면 꼭 알고 계셔야 하는 필수 단축키를 정리해드리겠습니다. 📺 동영상: https://youtu.be/N2R1tCKT0a8

YouTube

코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 하지만 이 글에서는 반복을 줄이기 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. 흔히 겪을 수 있는 사례를 예로 들고 있으니 스스로의 경험을 되돌아보며 읽어보시기 좋은 글입니다:)

[번역] DRY - 잘못된 추상화의 일반적인 원인

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다.

코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 이를 보통 DRY (Don’t Repeat Yourself) 라고 하는데요, 이 글에서는 이런 DRY를 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. DRY를 위해 작업하다가 어떻게 코드가 잘못 추상화되어 변경하기 어려운 코드가 되어가는지 술술 읽히는 글입니다.

개인적으로 이 글에서 들고있는 사례가 쉽게 겪을 수 있는 사례이기도 하고 저 또한 겪어봤던 일이어서 더욱 공감하며 읽을 수 있었습니다. 스스로의 경험을 되돌아보며 읽어보시면 좋을 것 같습니다:)

> 글 링크: https://velog.io/@eunbinn/dry-the-common-source-of-bad-abstractions

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다. 코드를 작성하며 반복을 줄이는 것은 기본적인 작업입니다. 이를 보통 DRY (Don’t Repeat Yourself) 라고 하는데요, 이 글에서는 이런 DRY를 위해 시도한 방법이 불러올 수 있는 잘못된 추상화의 예시를 설명하고 있습니다. DRY를 위해 작업하다가 어떻게 코드가 잘못 추상화되어 변경하기 어려운 코드가 되어가는지 술술 읽히는 글입니다. 개인적으로 이 글에서 들고있는 사례가 쉽게 겪을 수 있는 사례이기도 하고 저 또한 겪어봤던 일이어서 더욱 공감하며 읽을 수 있었습니다. 스스로의 경험을 되돌아보며 읽어보시면 좋을 것 같습니다:) &gt; 글 링크: https://velog.io/@eunbinn/dry-the-common-source-of-bad-abstractions

Velog

DRY - 잘못된 추상화의 일반적인 원인

정렬알고리즘(sort algorithm) 완벽 정리 액기스만!! 사진은 클릭해서 보시고 캡쳐 저장 마음대로 편하게 하셔욤💕💕💕

codingbarbie

코딩바비

👸🏻@sarangkang_
👩🏻‍💻iOS Developer 
👙Bikini Competitor 
🧘🏻‍♀️Pilates Instructor


정렬알고리즘(sort algorithm) 완벽 정리

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필