레벨이 올라갈수록 위 상사와 어떻게 지내느냐가 더 중요해진다. 영어로 이를 "Manage Up"이라고 부를 정도로 중요한 스킬이다.

 1. 일대일 미팅을 하거나 할 때 내가 필요한 것만 이야기하지 말고 매니저의 관점에서 생각해보려고 하고 혹시 어떤 도움이 필요할지 내가 혹은 내가 맡은 팀이 무엇을 해야할지 많이 물어볼 필요가 있다. 매니저도 사람이고 나보다 더 많은 스트레스를 받으며 일을 하고 있을 가능성이 높다.
 2. 즉, 내가 생각하는 나의 공헌이나 내 팀의 공헌을 생각하지 말고 내 매니저의 생각을 많이 들어보고 두 사람이 생각하는 공헌의 방향을 최대한 맞출 필요가 있다. 한 배를 타고 간다는 점을 분명히 인식할 필요가 있다.
 3. 내 상사의 강점과 약점을 명확히 이해하고 상사의 강점에 호소한다. 강점이 분명할 사람일수록 분명한 약점을 갖고 있을 가능성이 높다. 숫자에 굉장히 밝은 사람이지만 상대의 감정을 크게 개의치 않는 상사라면 필요한 것이 있을 때 감정에 호소하는 것보다는 숫자로 설득하는 것이 당연히 잘 동작한다. 하지만 때로는 상사가 내가 열심히 하는 것, 사람이 부족한데도 최선을 다 한다는 걸 이해해주지 못한다는 분노에 계속 상사의 감정에 호소하려는 경우를 보았다. 숫자도 밝고 EQ도 높다면 좋겠지만 그런 사람은 많지 않다.

이렇게 의사소통을 하다보면 나와 내 매니저가 정말 맞는 사람인지 아닌지 판단도 더 잘 할 수 있다. 내 상사는 대화가 힘든 사람이라고 단정짓고 이야기를 꺼내지 않는 경우도 많은데 "호기심"을 갖고 이야기를 꺼내보고 판단하는 것이 좋다.

레벨이 올라갈수록 위 상사와 어떻게 지내느냐가 더 중요해진다. 영어로 이를 "Manage Up"이라고 부를 정도로 중요한 스킬이다. <ol ><li>일대일 미팅을 하거나 할 때 내가 필요한 것만 이야기하지 말고 매니저의 관점에서 생각해보려고 하고 혹시 어떤 도움이 필요할지 내가 혹은 내가 맡은 팀이 무엇을 해야할지 많이 물어볼 필요가 있다. 매니저도 사람이고 나보다 더 많은 스트레스를 받으며 일을 하고 있을 가능성이 높다.</li><li>즉, 내가 생각하는 나의 공헌이나 내 팀의 공헌을 생각하지 말고 내 매니저의 생각을 많이 들어보고 두 사람이 생각하는 공헌의 방향을 최대한 맞출 필요가 있다. 한 배를 타고 간다는 점을 분명히 인식할 필요가 있다.</li><li>내 상사의 강점과 약점을 명확히 이해하고 상사의 강점에 호소한다. 강점이 분명할 사람일수록 분명한 약점을 갖고 있을 가능성이 높다. 숫자에 굉장히 밝은 사람이지만 상대의 감정을 크게 개의치 않는 상사라면 필요한 것이 있을 때 감정에 호소하는 것보다는 숫자로 설득하는 것이 당연히 잘 동작한다. 하지만 때로는 상사가 내가 열심히 하는 것, 사람이 부족한데도 최선을 다 한다는 걸 이해해주지 못한다는 분노에 계속 상사의 감정에 호소하려는 경우를 보았다. 숫자도 밝고 EQ도 높다면 좋겠지만 그런 사람은 많지 않다.</li></ol> 이렇게 의사소통을 하다보면 나와 내 매니저가 정말 맞는 사람인지 아닌지 판단도 더 잘 할 수 있다. 내 상사는 대화가 힘든 사람이라고 단정짓고 이야기를 꺼내지 않는 경우도 많은데 "호기심"을 갖고 이야기를 꺼내보고 판단하는 것이 좋다.

상사와 잘 지내는 사람들의 특징

언제나 호기심을 갖고 상대의 입장에서 생각하는 것이 중요한 것 같아요! 물론 상사를 대할 때도요^^

This is a guest post by Tobias Jensen - he writes the Futuristic Lawyer Newsletter. What do you think about when you think of AI risks? Security and Privacy Military AI Arms Race Corporate AI Arms Race Cybersecurity Threats Visit the AI Risk Repository he

What are the Actual Risks of AI?

지난 8월 14일, MIT 퓨처테크와 그 파트너들은 현재까지 수집된 가장 포괄적인 AI 위험 데이터베이스인 AI 위험 리포지토리를 공개했다. 이 데이터베이스의 목표는 AI로 인한 위험을 이해하고 해결하기 위한 공통의 참조 프레임을 만드는 것이다.

[ AI 위험 리포지토리(Risk Repository) ]
 * MIT 퓨처테크의 피터 슬래터리, 닐 톰슨, 알렉산더 사리, 에밀리 그룬디가 퀸즐랜드 대학의 마이클 노텔과 제스 그레이엄, 하모니 인텔리전스의 제임스 다오와 소루시 푸어, MIT CSAIL의 스티븐 캐스퍼, 미래생명연구소 및 KU 루벤의 리스토 우크와 협력하여 발표했다
 * The AI Risk Repository: https://airisk.mit.edu/

[ AI 리포지토리의 사용 방법 및 도메인 분류 체계 ]
 * 7가지 위험 영역/도메인
 * AI 시스템 안전, 장애 및 한계(76%)
 * 사회경제적 및 환경적 피해(73%)
 * 차별 및 독성(71%)
 * 개인정보 보호 및 보안(68%)
 * 악의적 행위자 및 오용(68%)
 * 잘못된 정보(44%)
 * 인간과 컴퓨터의 상호작용(41%)
 * 23개 하위 도메인
 * 부당한 차별 및 허위 진술(63%)
 * 민감한 정보의 입수, 유출 또는 잘못된 추론으로 인한 프라이버시 침해(61%)
 * 역량 또는 견고성 부족(59%)
 * 사이버 공격, 무기 개발 또는 사용, 대량 피해(54%)
 * 인간의 목표 또는 가치와 상충되는 자체 목표 추구(46%)
 * 허위 정보, 감시, 대규모 영향력(41%)
 * 허위 또는 오해의 소지가 있는 정보(39%)
 * 권력 집중과 불공정한 이익 분배(37%)
 * 독성 콘텐츠에 대한 노출(34%)
 * 불평등 증가 및 고용의 질 저하(34%)
 * 사기, 사기 및 표적 조작(34%)
 * AI 시스템 보안 취약성 및 공격(32%)
 * 인간의 노력에 대한 경제적, 문화적 평가 절하(32%)
 * 거버넌스 실패(32%)
 * 환경 피해(32%)
 * 인간의 주체성 및 자율성 상실(27%)
 * 투명성 또는 해석 가능성 부족(27%)
 * 과잉 의존 및 안전하지 않은 사용(24%)
 * 그룹 간 불균등한 성과(20%)
 * 위험한 기능을 가진 AI(20%)
 * 정보 생태계의 오염 및 합의 현실성 상실(12%)
 * 경쟁적 역학 관계(12%)
 * AI 복지 및 권리(2%)
 
 
[ 캐주얼 분류 ]
 * AI 위험 리포지토리는 식별된 위험을 도메인 범주에 따라 그룹화할 뿐만 아니라 '캐주얼 요인'에 따라 그룹화하기도 한다.
 * 분류
 * 위험의 원인이 AI인지 사람인지에 따라 '주체',
 * 목표 추구로 인한 의도적 또는 비의도적 결과인지에 따라 '의도'
 * 배포 전 또는 배포 후 발생하는 위험인지에 따라 '시기'

< 마커저커버그의 오픈 소스 AI가 앞으로 나아갈 길 >
 * 의도하지 않은 피해와 의도적인 피해
 * 의도하지 않은 피해
 * AI 시스템을 실행하는 사람이 의도하지 않았음에도 불구하고 AI 시스템이 피해를 입힐 수 있는 경우
 * 의도적인 피해
 * 악의적인 행위자가 해를 끼칠 목적으로 AI 모델을 사용하는 경우
 * 예) 딥페이크를 이용한 거짓정보 생성
 * 해결 방법 = 오픈소스
 * 시스템이 더 투명하고 광범위하게 조사할 수 있는 오픈소스 활용
 * 모델 사용자가 철저한 보안 테스트를 수행하고 실수를 보고하고 수정할 수 있기 때문에 시스템 오류로 인한 의도하지 않은 피해에 대해 더 잘 보호

[ OpenAI vs Google ]
 * OpenAI
 * 총 4개의 위험 식별: www.futuristiclawyer.com/p/openai-is-a-world-leader-in-ai-unsafety
 * GPT-4o가 프레임워크의 4개 위험 범주 중 '사이버 보안', '생물학적 위협', '모델 자율성'의 3개 범주에서 낮은 평가
 * 정치적으로 민감한 주제에 대한 설득력 있는 텍스트를 생성하는 모델의 능력으로 인해 네 번째 범주인 '설득'에서는 중간 점수를 받았다고 평가
 * Google
 * AI 위험 분류와 관련하여 가장 많이 인용된 상위 20개 논문 중 5개가 모두 AI 위험 리포지토리에 리소스로 포함
 * 구글 딥마인드는 최근 274페이지에 달하는 또 다른 보고서인 '고급 AI 비서의 윤리(2024)' 발표: Google's The Ethics of Advanced AI Assistants (2024): https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/ethics-of-advanced-ai-assistants/the-ethics-of-advanced-ai-assistants-2024-i.pdf

 * source: https://www.linkedin.com/pulse/what-actual-risks-ai-michael-spencer-exswc/

지난 8월 14일, MIT 퓨처테크와 그 파트너들은 현재까지 수집된 가장 포괄적인 AI 위험 데이터베이스인 AI 위험 리포지토리를 공개했다. 이 데이터베이스의 목표는 AI로 인한 위험을 이해하고 해결하기 위한 공통의 참조 프레임을 만드는 것이다. [ AI 위험 리포지토리(Risk Repository) ]<ul ><li>MIT 퓨처테크의 피터 슬래터리, 닐 톰슨, 알렉산더 사리, 에밀리 그룬디가 퀸즐랜드 대학의 마이클 노텔과 제스 그레이엄, 하모니 인텔리전스의 제임스 다오와 소루시 푸어, MIT CSAIL의 스티븐 캐스퍼, 미래생명연구소 및 KU 루벤의 리스토 우크와 협력하여 발표했다</li><li>The AI Risk Repository: https://airisk.mit.edu/</li></ul> [ AI 리포지토리의 사용 방법 및 도메인 분류 체계 ]<ul ><li>7가지 위험 영역/도메인<ul ><li>AI 시스템 안전, 장애 및 한계(76%)</li><li>사회경제적 및 환경적 피해(73%)</li><li>차별 및 독성(71%)</li><li>개인정보 보호 및 보안(68%)</li><li>악의적 행위자 및 오용(68%)</li><li>잘못된 정보(44%)</li><li>인간과 컴퓨터의 상호작용(41%)</li></ul></li><li>23개 하위 도메인<ul ><li>부당한 차별 및 허위 진술(63%)</li><li>민감한 정보의 입수, 유출 또는 잘못된 추론으로 인한 프라이버시 침해(61%)</li><li>역량 또는 견고성 부족(59%)</li><li>사이버 공격, 무기 개발 또는 사용, 대량 피해(54%)</li><li>인간의 목표 또는 가치와 상충되는 자체 목표 추구(46%)</li><li>허위 정보, 감시, 대규모 영향력(41%)</li><li>허위 또는 오해의 소지가 있는 정보(39%)</li><li>권력 집중과 불공정한 이익 분배(37%)</li><li>독성 콘텐츠에 대한 노출(34%)</li><li>불평등 증가 및 고용의 질 저하(34%)</li><li>사기, 사기 및 표적 조작(34%)</li><li>AI 시스템 보안 취약성 및 공격(32%)</li><li>인간의 노력에 대한 경제적, 문화적 평가 절하(32%)</li><li>거버넌스 실패(32%)</li><li>환경 피해(32%)</li><li>인간의 주체성 및 자율성 상실(27%)</li><li>투명성 또는 해석 가능성 부족(27%)</li><li>과잉 의존 및 안전하지 않은 사용(24%)</li><li>그룹 간 불균등한 성과(20%)</li><li>위험한 기능을 가진 AI(20%)</li><li>정보 생태계의 오염 및 합의 현실성 상실(12%)</li><li>경쟁적 역학 관계(12%)</li><li>AI 복지 및 권리(2%)</li></ul> </li></ul>[ 캐주얼 분류 ]<ul ><li>AI 위험 리포지토리는 식별된 위험을 도메인 범주에 따라 그룹화할 뿐만 아니라 '캐주얼 요인'에 따라 그룹화하기도 한다.</li><li>분류<ul ><li>위험의 원인이 AI인지 사람인지에 따라 '주체',</li><li>목표 추구로 인한 의도적 또는 비의도적 결과인지에 따라 '의도'</li><li>배포 전 또는 배포 후 발생하는 위험인지에 따라 '시기'</li></ul></li></ul> &lt; 마커저커버그의 오픈 소스 AI가 앞으로 나아갈 길 &gt;<ul ><li>의도하지 않은 피해와 의도적인 피해<ul ><li>의도하지 않은 피해<ul ><li>AI 시스템을 실행하는 사람이 의도하지 않았음에도 불구하고 AI 시스템이 피해를 입힐 수 있는 경우</li><li>의도적인 피해<ul ><li>악의적인 행위자가 해를 끼칠 목적으로 AI 모델을 사용하는 경우</li><li>예) 딥페이크를 이용한 거짓정보 생성</li></ul></li></ul></li></ul></li><li>해결 방법 = 오픈소스<ul ><li>시스템이 더 투명하고 광범위하게 조사할 수 있는 오픈소스 활용</li><li>모델 사용자가 철저한 보안 테스트를 수행하고 실수를 보고하고 수정할 수 있기 때문에 시스템 오류로 인한 의도하지 않은 피해에 대해 더 잘 보호</li></ul></li></ul> [ OpenAI vs Google ]<ul ><li>OpenAI<ul ><li>총 4개의 위험 식별: www.futuristiclawyer.com/p/openai-is-a-world-leader-in-ai-unsafety</li><li>GPT-4o가 프레임워크의 4개 위험 범주 중 '사이버 보안', '생물학적 위협', '모델 자율성'의 3개 범주에서 낮은 평가</li><li>정치적으로 민감한 주제에 대한 설득력 있는 텍스트를 생성하는 모델의 능력으로 인해 네 번째 범주인 '설득'에서는 중간 점수를 받았다고 평가</li></ul></li><li>Google<ul ><li>AI 위험 분류와 관련하여 가장 많이 인용된 상위 20개 논문 중 5개가 모두 AI 위험 리포지토리에 리소스로 포함</li><li>구글 딥마인드는 최근 274페이지에 달하는 또 다른 보고서인 '고급 AI 비서의 윤리(2024)' 발표: Google's The Ethics of Advanced AI Assistants (2024): https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/ethics-of-advanced-ai-assistants/the-ethics-of-advanced-ai-assistants-2024-i.pdf</li></ul></li></ul> <ul ><li>source: https://www.linkedin.com/pulse/what-actual-risks-ai-michael-spencer-exswc/</li></ul>

Linkedin

[AI Report] AI 위험 리포지토리의 분류 체계

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다.

기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다.

AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다.

AI에게 개발을 시킨다 -> 문제가 생긴다 & 문제를 만든다 -> 문제를 해결한다.

이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다)

부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다. 기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다. AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다. AI에게 개발을 시킨다 -&gt; 문제가 생긴다 &amp; 문제를 만든다 -&gt; 문제를 해결한다. 이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다) 부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

현대 사회에서 교육은
현재의 세대에게 가치 있는 지식을 제공하는 방향으로 나아가고 있습니다.

특히 AI를 도입함으로써 효율성과 정확성이 크게 향상된 구체적인 사례를 공유한다면, 이는 기업 문화에 AI를 적용하도록 유도하는 강력한 동기 부여가 될 수 있습니다.

또한, 실무를 담당하는 이해관계자들이 직접 AI를 사용하고 참여할 수 있도록 유도하는 것이 중요합니다. 생성형 AI를 포함한 다양한 AI 교육은 글쓰기, 연구, 리서치 등 여러 과제를 효과적으로 해결할 수 있는 방법을 제공할 수 있습니다.

AI 교육은 다음 세대를 위한 더 나은 미래를 만들기 위한 비전을 제공할수 있습니다. 이를 위해서는 다양한 기업 및 개인과의 협업과 콜라보레이션을 통해 AI 기반 교육 프로그램을 육성하는 것이 중요합니다.

#데이터리차드 #AI #인사이트

현대 사회에서 교육은 현재의 세대에게 가치 있는 지식을 제공하는 방향으로 나아가고 있습니다. 특히 AI를 도입함으로써 효율성과 정확성이 크게 향상된 구체적인 사례를 공유한다면, 이는 기업 문화에 AI를 적용하도록 유도하는 강력한 동기 부여가 될 수 있습니다. 또한, 실무를 담당하는 이해관계자들이 직접 AI를 사용하고 참여할 수 있도록 유도하는 것이 중요합니다. 생성형 AI를 포함한 다양한 AI 교육은 글쓰기, 연구, 리서치 등 여러 과제를 효과적으로 해결할 수 있는 방법을 제공할 수 있습니다. AI 교육은 다음 세대를 위한 더 나은 미래를 만들기 위한 비전을 제공할수 있습니다. 이를 위해서는 다양한 기업 및 개인과의 협업과 콜라보레이션을 통해 AI 기반 교육 프로그램을 육성하는 것이 중요합니다. #데이터리차드 #AI #인사이트

우리 기업에 AI 관련 교육 및 도입을 유도하는 방법

프론트엔드 개발자들의 축제, 2024 FEConf에 다녀왔어요! 총 2편의 영상이 업로드될 예정인데요 📹 첫 영상은 구글, 아임웹, 숨고, F-Lab의 굿즈 리뷰입니다. 굿즈로 티셔츠를 받은 덕분에 옷장이 든든-해졌어요 😊 다음은 FEConf 현장 영상으로 찾아올게요. 구독과 좋아요하고 기다려주세요!

개발자가 옷장을 채우는 방법 | 2024 FEConf 부스 굿즈 리뷰

티셔츠를 3벌이나 받은 덕분에 옷장이 든든-해졌어요 😊

FEConf 관련해서 총 2편의 영상이 업로드될 예정인데요. 첫 영상은 구글, 아임웹, 숨고, F-Lab의 굿즈 리뷰입니다.

다음은 FEConf 현장 영상으로 찾아올게요. 구독과 좋아요하고 기다려주세요!
https://youtu.be/8CIRWOxeT_M?si=qZ1QhbHQFuie2eTJ

티셔츠를 3벌이나 받은 덕분에 옷장이 든든-해졌어요 😊 FEConf 관련해서 총 2편의 영상이 업로드될 예정인데요. 첫 영상은 구글, 아임웹, 숨고, F-Lab의 굿즈 리뷰입니다. 다음은 FEConf 현장 영상으로 찾아올게요. 구독과 좋아요하고 기다려주세요!https://youtu.be/8CIRWOxeT_M?si=qZ1QhbHQFuie2eTJ

YouTube

개발자가 옷장을 채우는 방법

데이터 도메인에서 일을 한다면 직군과 관계없이, 처리하는 데이터의 크기와 관계없이 가장 기본이 되는 기술은 SQL이다. 이는 구조화된 데이터를 다룬다면 빅데이터 세상에서도 마찬가지이다. 순차적인 프로그래밍에 익숙한 개발자들의 경우 SQL을 무시하기 쉬운데 (내가 데이터 도메인에서 일을 하기 전에 그랬다 ^^) 행과 열로 나누어볼 수 있는 구조화된 데이터를 처리함에 있어 SQL처럼 신뢰할 수 있는 언어는 없다. 몇 가지 장점을 이야기해보자면 아래와 같다.

 1. 1970년대초 IBM에 의해 만들어진 언어이다보니 오래 동안 연구가 되었기에 여러모로 신뢰할 수 있다.
 2. 일반적인 프로그래밍보다는 비개발자들이 배우기에 어려움이 조금 덜하다.
 3. 원하는 결과를 순차적으로 기술하는 것(판다스에서 데이터프레임으로 데이터 조작을 하는 경우)이 아니라 한번에 원하는 걸 기술하는 구조이기에 사용하는 데이터베이스 시스템이 최적화하기에 좋다.

파이썬 판다스를 많이 사용한 개발자들은 판다스에서도 SQL 문법을 사용할 수 있다는 점을 잘 모르는데 예를 들어 아래처럼 pandasql을 설치한 다음에 데이터 프레임 변수 이름을 테이블 이름으로 sqldf라는 함수를 사용해 SQL을 실행할 수 있다. 아래 예를 하나 들었는데 measure_type이 TMIN인 레코드들만 선택해서 stationID별로 최소 온도를 구해보는 작업을 판다스에서 SQL로 구현해본 것이다.

import pandasql as psql

# df라는 이름의 데이터프레임이 앞에 이미 존재
query = """
SELECT stationID, MIN(temperature) minTemp
FROM df
WHERE measure_type = 'TMIN'
GROUP BY 1
"""

result = psql.sqldf(query)

만일 이를 판다스 데이터프레임 함수들만을 사용해 구현한다면 몇 번의 함수 호출을 연달아 사용해야 하며 이 경우에도 구현을 하는 사람에 따라 SQL 보다 훨씬 더 많은 수의 변종들이 가능하다. 즉 코드의 가독성이 떨어지게 된다. 아래 앞서 SQL으로 실행해본 결과를 데이터프레임 함수를 사용해 재구성해본 한가지 예를 들어봤다.

# 레코드 필터링을 먼저 수행
pd_minTemps = df[df['measure_type'] == "TMIN"]
# 필요한 필드만 선택
pd_stationTemps = pd_minTemps[["stationID", "temperature"]]
# Group By 작업 수행
pd_minTempsByStation = pd_stationTemps.groupby(["stationID"]).min("temperature")

이는 Spark에서도 마찬가지이다. Spark 자체가 판다스를 레퍼런스로 만들어진 것이기 때문에 기본적으로 데이터프레임으로 빅데이터 조작을 하게 되지만 구조화된 데이터라면 SQL을 사용하지 않을 이유가 없기에 현업에서는 대부분 SparkSQL을 사용한다. 즉 데이터의 크기와 상관없이 구조화된 데이터를 처리한다면 SQL만한 기술은 없다.

폴리보어(야후가 2015년에 인수)와 유데미(2021년 나스닥 상장)에서의 경험과 다수의 스타트업과 한국 대기업에서의 데이터 관련 일 경험을 바탕으로 데이터 도메인에서 SQL에 관한 강의를 인프런에서 얼마 전에 만들었는데 댓글 링크 참고. 해당 내용은 내가 겸임 교수로 일하는 실리콘밸리 소재 산호세 주립 대학에서 동일하게 가르치는 내용이기도 하다.

데이터 도메인에서 일을 한다면 직군과 관계없이, 처리하는 데이터의 크기와 관계없이 가장 기본이 되는 기술은 SQL이다. 이는 구조화된 데이터를 다룬다면 빅데이터 세상에서도 마찬가지이다. 순차적인 프로그래밍에 익숙한 개발자들의 경우 SQL을 무시하기 쉬운데 (내가 데이터 도메인에서 일을 하기 전에 그랬다 ^^) 행과 열로 나누어볼 수 있는 구조화된 데이터를 처리함에 있어 SQL처럼 신뢰할 수 있는 언어는 없다. 몇 가지 장점을 이야기해보자면 아래와 같다. <ol ><li>1970년대초 IBM에 의해 만들어진 언어이다보니 오래 동안 연구가 되었기에 여러모로 신뢰할 수 있다.</li><li>일반적인 프로그래밍보다는 비개발자들이 배우기에 어려움이 조금 덜하다.</li><li>원하는 결과를 순차적으로 기술하는 것(판다스에서 데이터프레임으로 데이터 조작을 하는 경우)이 아니라 한번에 원하는 걸 기술하는 구조이기에 사용하는 데이터베이스 시스템이 최적화하기에 좋다.</li></ol> 파이썬 판다스를 많이 사용한 개발자들은 판다스에서도 SQL 문법을 사용할 수 있다는 점을 잘 모르는데 예를 들어 아래처럼 pandasql을 설치한 다음에 데이터 프레임 변수 이름을 테이블 이름으로 sqldf라는 함수를 사용해 SQL을 실행할 수 있다. 아래 예를 하나 들었는데 measure_type이 TMIN인 레코드들만 선택해서 stationID별로 최소 온도를 구해보는 작업을 판다스에서 SQL로 구현해본 것이다. <pre ><code class="language-notebook-python">import pandasql as psql

# df라는 이름의 데이터프레임이 앞에 이미 존재
query = """
SELECT stationID, MIN(temperature) minTemp
FROM df
WHERE measure_type = 'TMIN'
GROUP BY 1
"""

result = psql.sqldf(query)</code></pre>만일 이를 판다스 데이터프레임 함수들만을 사용해 구현한다면 몇 번의 함수 호출을 연달아 사용해야 하며 이 경우에도 구현을 하는 사람에 따라 SQL 보다 훨씬 더 많은 수의 변종들이 가능하다. 즉 코드의 가독성이 떨어지게 된다. 아래 앞서 SQL으로 실행해본 결과를 데이터프레임 함수를 사용해 재구성해본 한가지 예를 들어봤다. <pre ><code class="language-notebook-python"># 레코드 필터링을 먼저 수행
pd_minTemps = df[df['measure_type'] == "TMIN"]
# 필요한 필드만 선택
pd_stationTemps = pd_minTemps[["stationID", "temperature"]]
# Group By 작업 수행
pd_minTempsByStation = pd_stationTemps.groupby(["stationID"]).min("temperature")</code></pre>이는 Spark에서도 마찬가지이다. Spark 자체가 판다스를 레퍼런스로 만들어진 것이기 때문에 기본적으로 데이터프레임으로 빅데이터 조작을 하게 되지만 구조화된 데이터라면 SQL을 사용하지 않을 이유가 없기에 현업에서는 대부분 SparkSQL을 사용한다. 즉 데이터의 크기와 상관없이 구조화된 데이터를 처리한다면 SQL만한 기술은 없다. 폴리보어(야후가 2015년에 인수)와 유데미(2021년 나스닥 상장)에서의 경험과 다수의 스타트업과 한국 대기업에서의 데이터 관련 일 경험을 바탕으로 데이터 도메인에서 SQL에 관한 강의를 인프런에서 얼마 전에 만들었는데 댓글 링크 참고. 해당 내용은 내가 겸임 교수로 일하는 실리콘밸리 소재 산호세 주립 대학에서 동일하게 가르치는 내용이기도 하다.

데이터 도메인에서 가장 중요한 기술은 SQL

인프런 강의 링크: https://inf.run/VuNLS  

실습 대상이 되는 DB는 DuckDB이며 모든 실습은 Google Colab을 통해 진행이 되기에 복잡한 별도 설치가 필요없다는 장점이 있다.

"렉라자의 미국 식품의약국(FDA) 승인은 유한양행이 국내 1등을 넘어 인류 건강을 위해 글로벌 제약사로 발돋움하는 데 이정표 역할을 할 것입니다." ○유일한 박사의 창업 정신 '결실' 조욱제 유한양행 사장은 21일

"렉라자는 제약·벤처 협업 성공모델...글로벌 1위 될 것"

유한양행은 다양한 오픈 이노베이션 전략을 수립했다. 제2, 제3의 렉라자와 같은 블록버스터 신약 후보물질을 조기에 발굴하기 위해서다. 10년 전부터 유한양행은 50여 개 바이오회사에 전략적 투자(SI)를 해왔다. 총 5000억원 규모다. 지난해 말부터 초기 단계 물질을 외부에서 도입한 후 직접 연구를 진행해 가치를 높이는 데 집중하고 있다. 현재 신약 파이프라인 33개 중 절반 이상을 외부에서 들여왔다.

https://n.news.naver.com/article/015/0005024117?sid=101

유한양행은 다양한 오픈 이노베이션 전략을 수립했다. 제2, 제3의 렉라자와 같은 블록버스터 신약 후보물질을 조기에 발굴하기 위해서다. 10년 전부터 유한양행은 50여 개 바이오회사에 전략적 투자(SI)를 해왔다. 총 5000억원 규모다. 지난해 말부터 초기 단계 물질을 외부에서 도입한 후 직접 연구를 진행해 가치를 높이는 데 집중하고 있다. 현재 신약 파이프라인 33개 중 절반 이상을 외부에서 들여왔다. https://n.news.naver.com/article/015/0005024117?sid=101

Naver

근데 진짜 내 코가 석자.. 남의 고민 들어 줄 때가 아닌디.. 🥹

근데 진짜 내 코가 석자.. 남의 고민 들어 줄 때가 아닌디.. 🥹

LLM 모델을 자체 구축할까의 조건에는 항상 데이터와 모델을 학습시키는 것에 대한 어려움과 비용만을 이야기하는데, 그와함께 운영상의 문제를 반드시 함께 고려해야합니다.

기술 진보의 사이클은 신기술 발명과 운영 기술 확보의 단계를 반복하는데, 운영 기술의 개발과 확보가 신기술의 발명 만큼이나 어렵고 비용이 많이 듭니다.

따라서 자체 모델 구축을 고려한다면 자체 모델 확보의 당위성에서 운영상의 어려움, 효율, 비용이 더 큰 관건일 수 있음을 인지해야합니다.

LLM 모델을 자체 구축할까의 조건에는 항상 데이터와 모델을 학습시키는 것에 대한 어려움과 비용만을 이야기하는데, 그와함께 운영상의 문제를 반드시 함께 고려해야합니다. 기술 진보의 사이클은 신기술 발명과 운영 기술 확보의 단계를 반복하는데, 운영 기술의 개발과 확보가 신기술의 발명 만큼이나 어렵고 비용이 많이 듭니다. 따라서 자체 모델 구축을 고려한다면 자체 모델 확보의 당위성에서 운영상의 어려움, 효율, 비용이 더 큰 관건일 수 있음을 인지해야합니다.

Data persistence is crucial in most applications. While it is not mandatory for an application to keep its data persisted, it is a common practice for large applications from various fields ranging...

JPA vs Hibernate vs Spring Data JPA

Java에서 데이터 지속성은 시간이 지남에 따라 많은 관심을 받았으며, 눈에 띄는 발전을 이뤄왔습니다. 처음에는 JDBC API를 직접 사용하는 것에서 시작하여, 점점 더 추상화되고 개발자가 사용하기 쉬운 표준화된 메커니즘으로 발전해왔습니다.
 
이러한 진화 과정에서 많은 지속성 기술이 개발되었으며, 이들 간의 차이는 종종 개발자들 사이에서 혼란을 일으킬 수 있습니다. 이러한 기술로는 Hibernate, JPA, Spring Data JPA가 있습니다.
 
개발할 때 이 중 하나를 선택해야 할까요? 아니면 이들 모두를 동시에 사용할 수 있을까요?

Hibernate
Hibernate는 가장 인기 있는 Java ORM(Object Relational Mapping) 프레임워크 중 하나로, Java 애플리케이션과 데이터베이스 간의 상호작용을 보다 효율적으로 관리하기 위해 사용됩니다. 이 프레임워크는 Java 클래스와 데이터베이스 테이블을 양방향으로 매핑할 수 있으며, 객체/관계 불일치 문제에 대한 완전한 솔루션을 제공합니다.

Hibernate는 주석(annotations)을 사용하여 매핑이 이루어지는 메타데이터를 생성합니다. 가장 많이 사용되는 주석 중 일부는 아래에 나와 있습니다.
@Entity
@Table(name = "CAR")
public class Car {

  @Id
  @Column(name = "CAR_ID")
  private Long cardId;

  @Column(name = "COLOR")
  private String color;

  @ManyToOne()
  @JoinColumn(name = "OWNER_ID")
  private Owner owner;
}

Hibernate가 Java에서 매우 인기가 있는 이유는 몇 가지 장점 때문입니다:
 
 * 생산성: 대부분의 구현이 개발자에게 숨겨져 있어 비즈니스 문제에 대한 최선의 해결책에 집중하기가 훨씬 쉬워집니다.
 * 성능: Hibernate는 캐싱(caching) 및 배칭(batching)과 같은 여러 최적화 메커니즘을 사용합니다.
 * 직관성: 대부분의 작업을 애노테이션을 통해 수행하므로 쉽게 이해할 수 있는 코드를 작성할 수 있습니다.
Hibernate는 시간이 지나면서 JPA 표준을 준수하고 그 메서드를 구현하게 되었습니다. 또한, Hibernate는 이전 버전과의 호환성을 유지하고 일부 고유한 기능을 계속 사용하기 위해 자체적인 구현도 유지하고 있습니다. 그렇다면 여기서 말하는 JPA란 무엇일까요?

JPA
JPA(Java Persistence API)는 규격이자, Java에서 데이터를 지속적으로 저장하는 표준화된 메커니즘의 일부가 되고자 하는 ORM 프레임워크가 구현해야 하는 일련의 규칙입니다.
 
JPA는 Hibernate와 같은 프레임워크가 아니라, ORM 프레임워크가 구현해야 하는 인터페이스에 불과합니다.
 
JPA는 지속성 프로세스를 관리하기 위해 EntityManager와 EntityManagerFactory에 의존합니다. EntityManager는 엔티티의 상태 변화를 관리하고 이를 SQL 쿼리로 변환하는 Persistence Context로 작동합니다.

JPA의 주요 장점은 다음과 같습니다:
 * 상호 운용성(Interportability): 두 프레임워크가 JPA를 준수하는 경우, 한 ORM 프레임워크에서 다른 프레임워크로 이동하는 과정이 훨씬 쉬워집니다.
 * 사용 편의성(Usability): JPQL이 쿼리를 정의할 때 엔티티 클래스와 그 필드를 인식할 수 있기 때문에 SQL 쿼리 작성이 더욱 쉬워집니다.

Spring Data JPA
Hibernate와 JPA가 모든 Java 애플리케이션에서 사용할 수 있는 반면, Spring Data JPA는 Spring 애플리케이션의 일부로 사용됩니다. Spring Data JPA는 Spring Data 프로젝트의 일부로, 리포지토리를 생성하는 데 필요한 상용구 코드를 줄여줌으로써 Spring 애플리케이션에서 데이터베이스 작업의 복잡성을 줄이는 것을 목표로 합니다. 이는 JPA 작업을 더욱 생산적으로 만들어주는 추가적인 추상화 수준을 제공합니다.

Spring Data JPA의 가장 큰 장점 중 하나는 Spring의 기능을 활용하여, SimpleJpaRepository의 도움으로 리포지토리의 구현이 런타임에 자동으로 이루어진다는 점입니다. 개발자가 영속성 데이터에 액세스하기 위해 새로운 리포지토리를 만들고자 할 때, JpaRepository를 확장하는 인터페이스만 작성하면 모든 메서드가 자동으로 구현됩니다. 정말 편리하죠!

결론
글의 초반에 제기된 질문에 대한 답은 다음과 같습니다:
 
네, Hibernate, JPA 및 Spring Data JPA는 각자가 개발 단계에서 다른 목적을 가지므로, 그 유사성에도 불구하고 함께 사용할 수 있습니다.

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

Java에서 데이터 지속성은 시간이 지남에 따라 많은 관심을 받았으며, 눈에 띄는 발전을 이뤄왔습니다. 처음에는 JDBC API를 직접 사용하는 것에서 시작하여, 점점 더 추상화되고 개발자가 사용하기 쉬운 표준화된 메커니즘으로 발전해왔습니다.&nbsp;이러한 진화 과정에서 많은 지속성 기술이 개발되었으며, 이들 간의 차이는 종종 개발자들 사이에서 혼란을 일으킬 수 있습니다. 이러한 기술로는 Hibernate, JPA, Spring Data JPA가 있습니다.&nbsp;개발할 때 이 중 하나를 선택해야 할까요? 아니면 이들 모두를 동시에 사용할 수 있을까요? HibernateHibernate는 가장 인기 있는 Java ORM(Object Relational Mapping) 프레임워크 중 하나로, Java 애플리케이션과 데이터베이스 간의 상호작용을 보다 효율적으로 관리하기 위해 사용됩니다. 이 프레임워크는 Java 클래스와 데이터베이스 테이블을 양방향으로 매핑할 수 있으며, 객체/관계 불일치 문제에 대한 완전한 솔루션을 제공합니다. Hibernate는 주석(annotations)을 사용하여 매핑이 이루어지는 메타데이터를 생성합니다. 가장 많이 사용되는 주석 중 일부는 아래에 나와 있습니다.<pre ><code class="language-java">@Entity
@Table(name = "CAR")
public class Car {

 @Id
 @Column(name = "CAR_ID")
 private Long cardId;

 @Column(name = "COLOR")
 private String color;

 @ManyToOne()
 @JoinColumn(name = "OWNER_ID")
 private Owner owner;
}</code></pre>Hibernate가 Java에서 매우 인기가 있는 이유는 몇 가지 장점 때문입니다:&nbsp;<ul ><li>생산성: 대부분의 구현이 개발자에게 숨겨져 있어 비즈니스 문제에 대한 최선의 해결책에 집중하기가 훨씬 쉬워집니다.</li><li>성능: Hibernate는 캐싱(caching) 및 배칭(batching)과 같은 여러 최적화 메커니즘을 사용합니다.</li><li>직관성: 대부분의 작업을 애노테이션을 통해 수행하므로 쉽게 이해할 수 있는 코드를 작성할 수 있습니다.</li></ul>Hibernate는 시간이 지나면서 JPA 표준을 준수하고 그 메서드를 구현하게 되었습니다. 또한, Hibernate는 이전 버전과의 호환성을 유지하고 일부 고유한 기능을 계속 사용하기 위해 자체적인 구현도 유지하고 있습니다. 그렇다면 여기서 말하는 JPA란 무엇일까요? JPAJPA(Java Persistence API)는 규격이자, Java에서 데이터를 지속적으로 저장하는 표준화된 메커니즘의 일부가 되고자 하는 ORM 프레임워크가 구현해야 하는 일련의 규칙입니다.&nbsp;JPA는 Hibernate와 같은 프레임워크가 아니라, ORM 프레임워크가 구현해야 하는 인터페이스에 불과합니다.&nbsp;JPA는 지속성 프로세스를 관리하기 위해 EntityManager와 EntityManagerFactory에 의존합니다. EntityManager는 엔티티의 상태 변화를 관리하고 이를 SQL 쿼리로 변환하는 Persistence Context로 작동합니다. JPA의 주요 장점은 다음과 같습니다:<ul ><li>상호 운용성(Interportability): 두 프레임워크가 JPA를 준수하는 경우, 한 ORM 프레임워크에서 다른 프레임워크로 이동하는 과정이 훨씬 쉬워집니다.</li><li>사용 편의성(Usability): JPQL이 쿼리를 정의할 때 엔티티 클래스와 그 필드를 인식할 수 있기 때문에 SQL 쿼리 작성이 더욱 쉬워집니다.</li></ul> Spring Data JPAHibernate와 JPA가 모든 Java 애플리케이션에서 사용할 수 있는 반면, Spring Data JPA는 Spring 애플리케이션의 일부로 사용됩니다. Spring Data JPA는 Spring Data 프로젝트의 일부로, 리포지토리를 생성하는 데 필요한 상용구 코드를 줄여줌으로써 Spring 애플리케이션에서 데이터베이스 작업의 복잡성을 줄이는 것을 목표로 합니다. 이는 JPA 작업을 더욱 생산적으로 만들어주는 추가적인 추상화 수준을 제공합니다. Spring Data JPA의 가장 큰 장점 중 하나는 Spring의 기능을 활용하여, SimpleJpaRepository의 도움으로 리포지토리의 구현이 런타임에 자동으로 이루어진다는 점입니다. 개발자가 영속성 데이터에 액세스하기 위해 새로운 리포지토리를 만들고자 할 때, JpaRepository를 확장하는 인터페이스만 작성하면 모든 메서드가 자동으로 구현됩니다. 정말 편리하죠! 결론글의 초반에 제기된 질문에 대한 답은 다음과 같습니다:&nbsp;네, Hibernate, JPA 및 Spring Data JPA는 각자가 개발 단계에서 다른 목적을 가지므로, 그 유사성에도 불구하고 함께 사용할 수 있습니다. 번역: [https://ducktopia.tistory.com/131]원문:

Medium

🕊️ [Medium] JPA vs Hibernate vs DataJPA

🕊️ [Medium] JPA vs Hibernate vs Spri

Github Actions 배포 시간을 줄이기 위해 1) Frontend, Backend Job Parallel 분리, 2) Frontend, Backend 빌드 트리거를 선택할 수 있도록 처리, 3) Docker Image Tag 사용, 4) Deploy 병렬 처리, 5) 인트로 분리 등 5가지 개선 작업을 진행했습니다. 이를 통해 배포 시간은 평균 55% 감소(27분 -> 12분)했으며, 특히 프론트엔드와 백엔드의 선택적 빌드를 통해 최대 70%의 

Github Actions 배포 시간 줄여볼까?

최근 저도 Github이 무거워지면서 Action 보고 있었는데,
역시 미리 고민해주신 분이 있었군요..!!!! 너무 감사합니다 👍🏻👍🏻👍🏻

좋은 글은 함께 봐야겠죠!? 공유합니다!

효과
 * 배포 시간 55% 감소(27분 -> 12분)
 * 최대 70% 시간 단축 가능, 인프라 비용 절감, 제품 개발 생산성 향상.
 * 추가 이점
   * Workflow 모듈화를 통해 재사용성 및 유지보수 용이성 향상
   * 문제 해결 시간 단축, 시스템 안정성 증대

https://blog.lemonbase.team/github-actions-%EB%B0%B0%ED%8F%AC-%EC%8B%9C%EA%B0%84-%EC%A4%84%EC%97%AC%EB%B3%BC%EA%B9%8C-5725b92e36d9

최근 저도 Github이 무거워지면서 Action 보고 있었는데,역시 미리 고민해주신 분이 있었군요..!!!! 너무 감사합니다 👍🏻👍🏻👍🏻 좋은 글은 함께 봐야겠죠!? 공유합니다! 효과<ul ><li>배포 시간 55% 감소(27분 -&gt; 12분)</li><li>최대 70% 시간 단축 가능, 인프라 비용 절감, 제품 개발 생산성 향상.</li><li>추가 이점<ul ><li>Workflow 모듈화를 통해 재사용성 및 유지보수 용이성 향상</li><li>문제 해결 시간 단축, 시스템 안정성 증대</li></ul></li></ul> https://blog.lemonbase.team/github-actions-%EB%B0%B0%ED%8F%AC-%EC%8B%9C%EA%B0%84-%EC%A4%84%EC%97%AC%EB%B3%BC%EA%B9%8C-5725b92e36d9

Github Action 배포 시간 줄이기

파워포인트 사용자를 위한 폰트, 프리젠테이션

Freesentation

각자가 가진 디자인 감각이 다르죠. 그래서 같은 내용으로 프리젠테이션을 만들어도 누군가는 미려하고 누군가는 가슴 답답한 결과를 만듭니다.

제가 딱 후자 같은 사람인데요.

여기 누구나 막 써도 예쁜 그런 폰트가 있네요.

Freesentation은 상업용으로 사용 가능한 완전 무료 폰트 라고 제작자가 말하고 있습니다. 꼭 살펴보세요!

https://freesentation.blog

각자가 가진 디자인 감각이 다르죠. 그래서 같은 내용으로 프리젠테이션을 만들어도 누군가는 미려하고 누군가는 가슴 답답한 결과를 만듭니다. 제가 딱 후자 같은 사람인데요. 여기 누구나 막 써도 예쁜 그런 폰트가 있네요. Freesentation은 상업용으로 사용 가능한 완전 무료 폰트 라고 제작자가 말하고 있습니다. 꼭 살펴보세요! https://freesentation.blog

누구나 막 써도 예쁜, 그런 폰트

스프링 개발자들이 Jakarta EE를 이해하고 관심을 가져야 하는 이유... Spring 6는 2022년 4분기에 Java 17과 Jakarta EE 10+를 기반으로 출시되었다. 이는 Spring 5.3.x에서 사용하던 Java 8-17과 Java EE 7-8에서 큰 도약을...

SpringRunner on LinkedIn: Spring Framework Overview

최근 스프링과 Jakarta EE의 관계와 학습할 필요가 있는지에 대해 궁금하다는 질문을 받은 적이 있다. 이에 대한 답변으로, 2022년 Spring 6의 출시와 함께 일어난 변화, Java EE에서 Jakarta EE로의 전환 과정, 그리고 이 두 기술 생태계의 관계에 대해 글로 정리해봤다.

이 글에서는 Jakarta EE의 주요 변화와 미래 방향성, 스프링과 Jakarta EE의 상호 영향, 그리고 왜 스프링 개발자들이 Jakarta EE에 관심을 가져야 하는지에 대해 설명했다. 엔터프라이즈 자바 개발의 현재와 미래에 관심 있는 개발자들에게 유용한 정보가 되길 바란다.

https://www.linkedin.com/feed/update/urn:li:activity:7230001657135120384/?actorCompanyId=104095129

최근 스프링과 Jakarta EE의 관계와 학습할 필요가 있는지에 대해 궁금하다는 질문을 받은 적이 있다. 이에 대한 답변으로, 2022년 Spring 6의 출시와 함께 일어난 변화, Java EE에서 Jakarta EE로의 전환 과정, 그리고 이 두 기술 생태계의 관계에 대해 글로 정리해봤다. 이 글에서는 Jakarta EE의 주요 변화와 미래 방향성, 스프링과 Jakarta EE의 상호 영향, 그리고 왜 스프링 개발자들이 Jakarta EE에 관심을 가져야 하는지에 대해 설명했다. 엔터프라이즈 자바 개발의 현재와 미래에 관심 있는 개발자들에게 유용한 정보가 되길 바란다. https://www.linkedin.com/feed/update/urn:li:activity:7230001657135120384/?actorCompanyId=104095129

스프링 개발자들이 Jakarta EE를 이해하고 관심을 가져야 하

만일 이후에 소프트웨어 개발자 신입을 채용한다면 컴퓨터 과학/공학 전공자이거나, 그에 준하는 기초 과목을 온라인 강의나 책으로라도 공부했는지를 필수 조건으로 내 걸 것이며, 코딩 테스트와 면접은 그것을 확인하기 위한 과정이 될 것임.

왜냐하면 프로그래머는 이제 너드만의 직업이 아닌 일반적인 직업이 되었고, 더불어 응용 프로그램 개발이 너무 쉬워졌기 때문에, 프레임웍이나 엔진 수준을 만들어 본 것이 아닌, 그걸 이용해 뭘 만들어 봤다는 것 정도는 이제는 망치 한 번 두들겨 봤음을 증명하는 것 이상의 의미가 없으므로, 기초가 더더욱 중요한 시대가 되었기 때문.

만일 이후에 소프트웨어 개발자 신입을 채용한다면 컴퓨터 과학/공학 전공자이거나, 그에 준하는 기초 과목을 온라인 강의나 책으로라도 공부했는지를 필수 조건으로 내 걸 것이며, 코딩 테스트와 면접은 그것을 확인하기 위한 과정이 될 것임. 왜냐하면 프로그래머는 이제 너드만의 직업이 아닌 일반적인 직업이 되었고, 더불어 응용 프로그램 개발이 너무 쉬워졌기 때문에, 프레임웍이나 엔진 수준을 만들어 본 것이 아닌, 그걸 이용해 뭘 만들어 봤다는 것 정도는 이제는 망치 한 번 두들겨 봤음을 증명하는 것 이상의 의미가 없으므로, 기초가 더더욱 중요한 시대가 되었기 때문.

만일 이후에 소프트웨어 개발자 신입을 채용한다면 컴퓨터 과학/공학

왜 어떤 사람은 직급이 높아질수록 성장하고, 어떤 사람은 도태되는가? 인사 업무를 담당하면서 수많은 사람들을 관찰하고 경험했습니다. 채용하고, 교육하고, 평가하고, 퇴직하는 다양한 과정을 지켜봤습니다. 어떤 사람들은 직급이 올라갈수록 더 성장합니다. 어떤 사람들은 주니어 시절엔...

Do Young kim on LinkedIn: - 왜 어떤 사람은 직급이 높아질수록 성장하고, 어떤 사람은 도태되는가? 인사 업무를 담당하면서 수많은 사람들을 관찰하고...

어떤 사람은 직급이 올라갈수록 더 성장합니다. 반대로 어떤사람은 주니어 시절엔 잘나갔지만 리더가 되면서 성장이 멈추고 도태됩니다. 직급이 올라갈수록 더 성장하는 사람들의 공통점은 어떤게 있는지 정리해주신 내용이 있어 공유드립니다.

👁️ 꾸준히 공부하는 사람
주니어 시절에는 실력과 지식만으로 인정받고 생존할 수 있지만, 시니어가 되면 새로운 세상이 펼쳐집니다. 이 때부터는 빠르게 성장하는 사람과 도태되는 사람으로 나뉩니다. 과거의 지식에만 의존하고 더 이상 공부하지 않는 사람이 있는 반면, 자신의 부족함을 인정하고 계속해서 학습하며 발전해 나가는 사람이 있습니다. 꾸준하게 공부하는 사람은 직급이 높아지면서 J커브로 성장을 합니다. 차이를 만드는 건 끊임없는 학습과 꾸준한 공부입니다.

🧘🏻‍♂️ 인성이 좋은 사람
직급이 높아지면 업무의 범위와 중요성이 커집니다. 주니어 때는 업무를 혼자 처리하면 되지만, 고직급자의 업무는 혼자 해결 할 수 없는 경우가 많습니다. 동료의 지원이 필수적이며 자발적으로 돕고자 하는 마음을 가지도록 만드는 것도 중요합니다. 프로젝트의 성공을 위해서는 동료들의 전문성과 도움이 반드시 필요합니다. 생산성은 협업에 크게 좌우되며, 협업을 잘하려면 인성이 중요합니다.

🏋️ 피드백을 잘 주고받는 사람
피드백은 성장을 위한 핵심 요소이고, 성장에는 자기 인식이 필수적입니다. 직급이 높아져도 성장하는 사람은 자기 인식 수준을 높이기 위해 피드백을 적극적으로 구합니다. 이들은 자존감이 높아 피드백에 방어적이지 않고, 많은 피드백 중 유용한 피드백을 잘 구분하여 받아들입니다.
반대로 자신의 이익을 위해서가 아닌 상대의 성장을 바라며 피드백을 제공하며, 일이 더 잘되기 위해서 피드백을 합니다.

🏃🏻‍♀️ 커뮤니케이션을 잘하는 사람
조직에서 발생하는 많은 문제는 커뮤니케이션을 통해 해결할 수 있습니다. 특히 여러 부서가 얽혀 있는 복잡한 문제일 경우, 리더가 적극적으로 나서서 소통하며 문제 해결을 주도해야합니다. 고직급자일수록 전사적으로 중요한 방향이나 전략을 공유하고, 부서 간 원활한 커뮤니케이션을 통해 업무가 잘 진행되도록 조율하는 역할이 중요합니다.

📈 관계를 잘 맺는 사람
성과와 관계는 양자 택일의 문제가 아닙니다. 성과를 위해 좋은 관계를 맺는 것은 직급이 높아지거나 리더일수록 더욱 중요해집니다. 직급이 높아질수록 어려운 결정을 해야할 순간이 많은데, 이때 직원들에게 헌신과 희생을 요청해야 할 때가 있습니다. 평소 신뢰 관계가 형성되지 않았다면 직원들은 따르지 않습니다. 변화와 혁신을 추진할 때도 마찬가지입니다.

어떤 사람은 직급이 올라갈수록 더 성장합니다. 반대로 어떤사람은 주니어 시절엔 잘나갔지만 리더가 되면서 성장이 멈추고 도태됩니다. 직급이 올라갈수록 더 성장하는 사람들의 공통점은 어떤게 있는지 정리해주신 내용이 있어 공유드립니다. 👁️ 꾸준히 공부하는 사람주니어 시절에는 실력과 지식만으로 인정받고 생존할 수 있지만, 시니어가 되면 새로운 세상이 펼쳐집니다. 이 때부터는 빠르게 성장하는 사람과 도태되는 사람으로 나뉩니다. 과거의 지식에만 의존하고 더 이상 공부하지 않는 사람이 있는 반면, 자신의 부족함을 인정하고 계속해서 학습하며 발전해 나가는 사람이 있습니다. 꾸준하게 공부하는 사람은 직급이 높아지면서 J커브로 성장을 합니다. 차이를 만드는 건 끊임없는 학습과 꾸준한 공부입니다. 🧘🏻‍♂️ 인성이 좋은 사람직급이 높아지면 업무의 범위와 중요성이 커집니다. 주니어 때는 업무를 혼자 처리하면 되지만, 고직급자의 업무는 혼자 해결 할 수 없는 경우가 많습니다. 동료의 지원이 필수적이며 자발적으로 돕고자 하는 마음을 가지도록 만드는 것도 중요합니다. 프로젝트의 성공을 위해서는 동료들의 전문성과 도움이 반드시 필요합니다. 생산성은 협업에 크게 좌우되며, 협업을 잘하려면 인성이 중요합니다. 🏋️ 피드백을 잘 주고받는 사람피드백은 성장을 위한 핵심 요소이고, 성장에는 자기 인식이 필수적입니다. 직급이 높아져도 성장하는 사람은 자기 인식 수준을 높이기 위해 피드백을 적극적으로 구합니다. 이들은 자존감이 높아 피드백에 방어적이지 않고, 많은 피드백 중 유용한 피드백을 잘 구분하여 받아들입니다.반대로 자신의 이익을 위해서가 아닌 상대의 성장을 바라며 피드백을 제공하며, 일이 더 잘되기 위해서 피드백을 합니다. 🏃🏻‍♀️ 커뮤니케이션을 잘하는 사람 조직에서 발생하는 많은 문제는 커뮤니케이션을 통해 해결할 수 있습니다. 특히 여러 부서가 얽혀 있는 복잡한 문제일 경우, 리더가 적극적으로 나서서 소통하며 문제 해결을 주도해야합니다. 고직급자일수록 전사적으로 중요한 방향이나 전략을 공유하고, 부서 간 원활한 커뮤니케이션을 통해 업무가 잘 진행되도록 조율하는 역할이 중요합니다. 📈 관계를 잘 맺는 사람 성과와 관계는 양자 택일의 문제가 아닙니다. 성과를 위해 좋은 관계를 맺는 것은 직급이 높아지거나 리더일수록 더욱 중요해집니다. 직급이 높아질수록 어려운 결정을 해야할 순간이 많은데, 이때 직원들에게 헌신과 희생을 요청해야 할 때가 있습니다. 평소 신뢰 관계가 형성되지 않았다면 직원들은 따르지 않습니다. 변화와 혁신을 추진할 때도 마찬가지입니다.

직급이 높아질수록 성장하거나 도태되는 사람들의 차이

자바스크립트의 배열 함수에 비동기 함수를 인자로 넘기면 안 되는 이유

자바스크립트의 배열은
forEach()
,
filter()
,
map()
,
reduce
,
every()
,
some()
등과 같이 콜백 함수를 인자로 받아 배열에 저장되어 있는 모든 원소로 상대로 호출해주는 함수들을 제공합니다. 이 함수들을 잘 활용하면 소위 함수형 프로그래밍(Functional Programming) 스타일로 코딩을 할 수 있게 되죠.

그런데 혹시 이러한 자바스크립트의 배열에 제공하는 함수에 비동기 함수를 인자로 넘기면 낭패를 볼 수 있다는 것을 아시나요? 이번 포스팅에서는 자바스크립트 배열 함수를 통해서 비동기 함수를 호출할 때 조심해야 할 점에서 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/js-async-array/

자바스크립트의 배열은 <code>forEach()</code>, <code>filter()</code>,<code>map()</code>, <code>reduce</code>, <code>every()</code>, <code>some()</code> 등과 같이 콜백 함수를 인자로 받아 배열에 저장되어 있는 모든 원소로 상대로 호출해주는 함수들을 제공합니다. 이 함수들을 잘 활용하면 소위 함수형 프로그래밍(Functional Programming) 스타일로 코딩을 할 수 있게 되죠. 그런데 혹시 이러한 자바스크립트의 배열에 제공하는 함수에 비동기 함수를 인자로 넘기면 낭패를 볼 수 있다는 것을 아시나요? 이번 포스팅에서는 자바스크립트 배열 함수를 통해서 비동기 함수를 호출할 때 조심해야 할 점에서 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/js-async-array/

Daleseo

자바스크립트의 배열 함수에 비동기 함수를 인자로 넘기면 안 되는 

안녕하세요, 언지니어TF입니다. AI 데이터 분석가 '물어보새'는 생성형 AI를 주제로 한 우아톤 2023(우아한형제들 구성원 누구나 참여할 수 있는 사내 해커톤)을 계기로 탄생한 프로덕트입니다. 당시 '코드 없이 데이터 추출과 시각화를 자동으로 해주는 서비스'로 1등을 차지했습니다. 우아톤 이후에도 구성원들의 요구와 관심이 지속되어 2024년 1월에 본격적인 개발을 위한 언지니어 태스크포스(TF)가 구성되었습니다.

AI 데이터 분석가 '물어보새' 등장 - 1부. RAG와 Text-To-SQL 활용 | 우아한형제들 기술블로그

AI는 이렇게 쓰는 것이다라고 알려주는 듯한 글입니다.
꽤 잘 정리된 글이니 관심있으신 분이라면 일독을 권합니다.
저도 요렇게 유용한것들을 좀 만들고 싶네요.

고민을 좀 해봐야겠습니다.

AI 데이터 분석가 물어보새 1부
https://techblog.woowahan.com/18144/

AI 데이터 분석가 물어보새 2부
https://techblog.woowahan.com/18362/

AI는 이렇게 쓰는 것이다라고 알려주는 듯한 글입니다.꽤 잘 정리된 글이니 관심있으신 분이라면 일독을 권합니다. 저도 요렇게 유용한것들을 좀 만들고 싶네요. 고민을 좀 해봐야겠습니다. AI 데이터 분석가 물어보새 1부 https://techblog.woowahan.com/18144/ AI 데이터 분석가 물어보새 2부 https://techblog.woowahan.com/18362/

우아한형제들 기술블로그 |

AI 데이터 분석가 '물어보새' 를 만든 이야기

리액트 19의 베타 버전이 출시되었습니다. 리액트 18과 비교하면 사용자 친화적인 API가 많이 추가되었지만, 핵심 원칙은 크게 바뀌지 않았습니다. 여러분은 리액트를 꽤 오랫동안 사용해 왔을 텐데, 내부적으로 어떻게 작동하는지 알고 계신가요? 이 글에서는 비동기 업데이트를 지원하고 작업을 중단할 수 있는 리액트를 약 400줄의 코드로 구현하는 방법을...

400줄의 코드로 나만의 리액트 만들기 (부제: 리액트의 원리에 대한 심층 연구)

오늘은 파트리지 시스템즈의 이시연님이 번역해주신 글입니다.

리액트 19의 베타 버전이 출시되었습니다. 이번 버전은 리액트 18과 비교해 사용자 친화적인 API가 많이 추가되었지만, 핵심 원칙은 크게 변하지 않았습니다. 리액트를 오랫동안 사용해 온 개발자들도 있지만, 내부 작동 방식에 대해 궁금해하는 분들이 있을 수 있습니다. 이 글에서는 비동기 업데이트를 지원하고 작업을 중단할 수 있는 리액트의 핵심 기능을 약 400줄의 코드로 구현하는 방법을 살펴보겠습니다.

글 링크: https://bit.ly/3WUa4wU

오늘은 파트리지 시스템즈의 이시연님이 번역해주신 글입니다. 리액트 19의 베타 버전이 출시되었습니다. 이번 버전은 리액트 18과 비교해 사용자 친화적인 API가 많이 추가되었지만, 핵심 원칙은 크게 변하지 않았습니다. 리액트를 오랫동안 사용해 온 개발자들도 있지만, 내부 작동 방식에 대해 궁금해하는 분들이 있을 수 있습니다. 이 글에서는 비동기 업데이트를 지원하고 작업을 중단할 수 있는 리액트의 핵심 기능을 약 400줄의 코드로 구현하는 방법을 살펴보겠습니다. 글 링크: https://bit.ly/3WUa4wU

400줄의 코드로 나만의 리액트 만들기

안녕하세요, 커리어리 팀입니다.
개발자 분들께 도움이 될 Q&A 업데이트 소식을 전해드려요!

커리어리 현직자 Q&A에 React 질문하기 탭이 새로 생겼어요.
React로 개발하시다가 궁금한 점이나 어려운 부분이 있다면 편하게 찾아와주세요!
앗, 참고로 React에 대한 질문이라면 빠르게 대답을 받을 수 있답니다 😎

🎈 React 질문하기 확인하는 법
1. 커리어리 현직자 Q&A로 들어온다.
웹이라면 상단 버튼 혹은 햄버거 버튼을 통해, 앱이라면 피드 맨 위에 있는 현직자 Q&A 버튼을 통해 들어올 수 있어요.
2. 토픽 중 'React 질문하기'를 누른다.

책임급(연구실장) CTO 

M.CHOI ResearchChief

Developers researching computer science science technology AI big data

Product Manager

김은서

햇병아리 서비스 기획자🐰🐥

되고 싶습니다 서비스 기획자가

22.08.08
이커머스 신입 서비스 기획자가 되었습니다🐣
22.07.14
메타버스 커뮤니티 플랫폼 기획자가 되고 싶어요!
20대 후반 비전공생🎓 이제 막 꿈을 튼 새싹입니다!🌱
아는 것도 경험도 많이 부족하지만🪫
열심히 배우겠습니다! 많은 조언부탁드립니다!☺️


프로덕트 매니저

안지원

세상에 있는 문제를 해결하기 위해 몰입해서 일하는 것을 좋아합니다. 개인보다 팀으로 일할 때 더 위대한 일을 할 수 있다고 믿습니다. 
#스타트업 #프로덕트매니저 #팀플레이어 #독서 #끊임없이배우기 #독서모임 #비건지향

React 질문 있으신 분? 🙋‍♀️

- 개발자들의 커리어 SNS
- 직장인들을 위한 커리어 성장 플랫폼
- 현직자들의 '진짜 인사이트'를 얻어가세요!

공식 계정

생산성, 매니지먼트, 비즈니스에서부터 영감과 자극까지. '일하는 사람들'을 위한 읽을거리를 커리어리가 큐레이션 해요. 가끔은 커리어리 팀의 일상이나 일하는 마음에 대한 가벼운 이야기도 할게요. :)

커리어리

 🚀개발자 커리어 업그레이드 자료집 무료 나눔

💗 커리어리 공식 인스타그램

⏬ 커리어리 앱 다운받기

🔎 커리어리 공식 블로그

💙 커리어리 공식 페이스북

📁 [커리어리X김테드] 포트폴리오 키트 무료 나눔

생산성, 매니지먼트, 비즈니스에서부터 영감과 자극까지. '일하는 사람들'을 위한 읽을거리를 커리어리가 큐레이션 해요.
가끔은 커리어리 팀의 일상이나 일하는 마음에 대한 가벼운 이야기도 할게요. 🥰

React 질문 있으신 분? 🙋‍♀️

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필