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

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

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

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

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

책은 크게
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 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다. 설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.

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

어

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

레거시 처리 개발자

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

어려운 일 투성이라 적응하는 데 시간이 걸렸습니다.
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리그 프로그래머

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

DEV Community

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

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

하버드 석학이 알려주는, 회사 그만둘지 버틸지 구별하는 방법 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 - 잘못된 추상화의 일반적인 원인

UX Design Books: What UXers Must Read in 2020 (Updated)？

<40 UX Design Books>

아래 링크에는 UX Design에 관심 있으신 분들이 읽어보시면 좋을 책 목록 40개가 담겨있습니다. 이 책들은 User experience design을 광범위하게 커버하고, 매우 다양한 실무 조언과 가이드라인을 제공한다고 하니 관심 있으신 분들은 살펴보시면 좋을 것 같아요. 1번과 2번은 고전같은 책이라 저도 읽어보았네요. 대부분은 PDF로도 무료이니 살펴보세요!

Mockplus

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

김혜민

Head of People Science

김안나

경영 전략 컨설턴트로 커리어 시작, 리디북스에 3번째 직원으로 입사하며 커리어 피봇. 콘텐츠에 대한 덕업일치를 하고 싶어 퍼블리를 공동 창업했습니다. 과거의 커리어를 통해 경험한 저의 모든 것을 담아 HRD SaaS 레몬베이스에서 일하며 건강한 성장을 하고 있습니다.

Product Manager

Product Owner

불어불문학, 정치외교학

HCI/d MS

이지선

다시 학교로 돌아와 Human-Computer Interaction and design 을 공부하고 있습니다. 네이버 메일, 주소록, 네이버me, 그리고 쿠팡 마케팅 PO 및 프론트 PO로 일했습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필