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

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

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

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

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

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

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

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

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

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

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

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

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

LLM 계속 써보면 결과가 일정치 않아서 불편합니다. 그런데 사람과 비교하면 안정적인 결과를 낸다고 볼 수 있다고 하네요.

왜 그럴까 생각하다가
사람은 체력이나 감정에 따라 결과가 다를 수 있겠더라고요.

라스트 댄스에서 봤던 올타임 레전드라는 문구가 떠오릅니다. 사람이 꾸준히 좋은 결과를 낸다는게 얼마나 대단한 일인지 다시금 생각하게 됐습니다

https://x.com/emollick/status/1828078306521944115

LLM 계속 써보면 결과가 일정치 않아서 불편합니다. 그런데 사람과 비교하면 안정적인 결과를 낸다고 볼 수 있다고 하네요. 왜 그럴까 생각하다가사람은 체력이나 감정에 따라 결과가 다를 수 있겠더라고요. 라스트 댄스에서 봤던 올타임 레전드라는 문구가 떠오릅니다. 사람이 꾸준히 좋은 결과를 낸다는게 얼마나 대단한 일인지 다시금 생각하게 됐습니다 https://x.com/emollick/status/1828078306521944115

X (formerly Twitter)

LLM에 관한 재미있는 관점

일 하다 눈이 가는 소식을 큐레이션해서 공유합니다

TREND REPORT "2024년 8월에 본 것"

방콕의 우기를 닮은 날씨에도 어김없이 한 달을 보내느라 애쓰셨습니다. 출근하는 것만으로도 에너지가 소진되는 것을 유난히 느꼈던 8월, 어려웠지만 다정해야겠다고 다짐했던 순간들이 있습니다. 그때마다 제가 다시 봤던 메모로 뉴스레터를 시작합니다. 어쩌면 다정함이란 타고나는 것이 아니라 애를 쓰는 상태가 아닐까요? 동료의 다정함과 흔쾌함이 당연하다고 여기는 대신, 애를 써주는 모습에 고마워하는 마음을 갖는 것만으로도 조금 괜찮아지는 순간들이 있었습니다. 날씨에 취약해지는 제 모습을 보면서 사람은 환경과 행동의 함수라는 것을 체감했던 8월. 이번 달에 제가 관심 있게 봤던 것들을 모아 8월의 마지막 월요일에 보냅니다.

[ 큐레이터의 문장 🎒 ]

1️⃣ Intro - 잘 배운 다정함 💚
2️⃣ 저속노화와 도파민, 지속가능한 자극 🍾
3️⃣ 우리가 오해하는 집중력, 사실은 지루함을 견디는 힘 🏃🏻
4️⃣ 공공성에 개인이 기여하는 한 가지 방법과 표창장 (feat. KRDS) 🎖️
5️⃣ UT를 했다고 사랑받을까? 그럼에도 롱런하는 서비스에 필요한 것, UX 리서치 🧑🏻‍🍳
6️⃣ 우리는 왜 태풍의 이동경로를 보면서 또 오해할까? 🌀
7️⃣ Outro - 매달 하는 모임 <리서치 하는데요> 📖

https://maily.so/redbusbagman/posts/03ab5508

방콕의 우기를 닮은 날씨에도 어김없이 한 달을 보내느라 애쓰셨습니다. 출근하는 것만으로도 에너지가 소진되는 것을 유난히 느꼈던 8월, 어려웠지만 다정해야겠다고 다짐했던 순간들이 있습니다. 그때마다 제가 다시 봤던 메모로 뉴스레터를 시작합니다. 어쩌면 다정함이란 타고나는 것이 아니라 애를 쓰는 상태가 아닐까요? 동료의 다정함과 흔쾌함이 당연하다고 여기는 대신, 애를 써주는 모습에 고마워하는 마음을 갖는 것만으로도 조금 괜찮아지는 순간들이 있었습니다. 날씨에 취약해지는 제 모습을 보면서 사람은 환경과 행동의 함수라는 것을 체감했던 8월. 이번 달에 제가 관심 있게 봤던 것들을 모아 8월의 마지막 월요일에 보냅니다. [ 큐레이터의 문장 🎒 ] 1️⃣ Intro - 잘 배운 다정함&nbsp;💚2️⃣ 저속노화와 도파민, 지속가능한 자극&nbsp;🍾3️⃣ 우리가 오해하는 집중력, 사실은 지루함을 견디는 힘&nbsp;🏃🏻4️⃣ 공공성에 개인이 기여하는 한 가지 방법과 표창장 (feat. KRDS)&nbsp;🎖️5️⃣ UT를 했다고 사랑받을까? 그럼에도 롱런하는 서비스에 필요한 것, UX 리서치&nbsp;🧑🏻‍🍳6️⃣ 우리는 왜 태풍의 이동경로를 보면서 또 오해할까?&nbsp;🌀7️⃣ Outro - 매달&nbsp;하는 모임 &lt;리서치 하는데요&gt;&nbsp;📖 https://maily.so/redbusbagman/posts/03ab5508

inspireX

⟪43개월 동안 지속하고 있는 집중력, 뉴스레터⟫

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

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 위험 리포지토리의 분류 체계

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다.

단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면

 * 가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.
 * 모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.
 * 문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.
 * 마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.

요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다. 단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면 <ul ><li>가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.</li><li>모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.</li><li>문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.</li><li>마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.</li></ul> 요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

좋은 코드란?

A/B 테스트에서 개별 그룹 간 샘플 크기가 대등한 비율을 갖기를 기대하지만, 때때로 이 균형이 깨질 수 있습니다. 그런데 얼마나 차이가나야 불균등한 것 일까요? 그리고 대처방법은 없을까요? 물론 있지요! 함께 살펴봅시다. A/B 테스트에서 개별 사용자를 실험 그룹에 할당할 때, 그룹이 2개인 경우 50% : 50%, 그룹이 3개인 경우 33.3% ...

A/B 테스트 과정에서 맞닥뜨릴 수 있는 문제2. 불균등한 샘플 분배, 어느 정도 차이가 문제인걸까? 그리고 해결방법은?

핵클에서 근무하고 계신 데이터 과학자분의 글입니다. AB Test에서 그룹 간 샘플 크기가 대등하길 바라지만, 균형이 깨질 때 어떻게 해야할지에 대한 글입니다. 실용적인 관점의 글이니 실험 고민이 있다면 읽어보셔요.

Q) 그룹간 샘플 크기가 균등하게 분배가 안되면 어떤 문제가 발생하는지?
 * P value가 왜곡될 수 있음
 * 실험 결과의 신뢰성을 저하시킬 수 있고, 잘못된 의사 결정을 유도함
 * 해결 방법
   * 샘플 크기 재조정
   * 가중치 적용
   * Welch's t-test 검정
   * 재시작

불균등 분배를 사전에 감지하는 방법 : SRM(Sample Ratio Mismatch)
Q) SRM을 어떻게 감지하나요?
 * 관찰된 빈도가 기대되는 빈도와 유의미하게 다른지 검증할 때 사용하는 Chi-Squared Goodness of fit test(카이스퀘어 적합도 검정)을 사용

Q) SRM은 어떤 경우에 발생하나요?
 * 가장 빈번한 원인 : 트래픽 할당 로직 오류

https://medium.com/@khjin1002/a-b-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B3%BC%EC%A0%95%EC%97%90%EC%84%9C-%EB%A7%9E%EB%8B%A5%EB%9C%A8%EB%A6%B4-%EC%88%98-%EC%9E%88%EB%8A%94-%EB%AC%B8%EC%A0%9C2-%EB%B6%88%EA%B7%A0%EB%93%B1%ED%95%9C-%EC%83%98%ED%94%8C-%EB%B6%84%EB%B0%B0-%EC%96%B4%EB%8A%90-%EC%A0%95%EB%8F%84-%EC%B0%A8%EC%9D%B4%EA%B0%80-%EB%AC%B8%EC%A0%9C%EC%9D%B8%EA%B1%B8%EA%B9%8C-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95%EC%9D%80-de287bce1643

핵클에서 근무하고 계신 데이터 과학자분의 글입니다. AB Test에서 그룹 간 샘플 크기가 대등하길 바라지만, 균형이 깨질 때 어떻게 해야할지에 대한 글입니다. 실용적인 관점의 글이니 실험 고민이 있다면 읽어보셔요. Q) 그룹간 샘플 크기가 균등하게 분배가 안되면 어떤 문제가 발생하는지?<ul ><li>P value가 왜곡될 수 있음</li><li>실험 결과의 신뢰성을 저하시킬 수 있고, 잘못된 의사 결정을 유도함</li><li>해결 방법<ul ><li>샘플 크기 재조정</li><li>가중치 적용</li><li>Welch's t-test 검정</li><li>재시작</li></ul></li></ul> 불균등 분배를 사전에 감지하는 방법 : SRM(Sample Ratio Mismatch)Q) SRM을 어떻게 감지하나요?<ul ><li>관찰된 빈도가 기대되는 빈도와 유의미하게 다른지 검증할 때 사용하는 Chi-Squared Goodness of fit test(카이스퀘어 적합도 검정)을 사용</li></ul> Q) SRM은 어떤 경우에 발생하나요?<ul ><li>가장 빈번한 원인 : 트래픽 할당 로직 오류</li></ul> https://medium.com/@khjin1002/a-b-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B3%BC%EC%A0%95%EC%97%90%EC%84%9C-%EB%A7%9E%EB%8B%A5%EB%9C%A8%EB%A6%B4-%EC%88%98-%EC%9E%88%EB%8A%94-%EB%AC%B8%EC%A0%9C2-%EB%B6%88%EA%B7%A0%EB%93%B1%ED%95%9C-%EC%83%98%ED%94%8C-%EB%B6%84%EB%B0%B0-%EC%96%B4%EB%8A%90-%EC%A0%95%EB%8F%84-%EC%B0%A8%EC%9D%B4%EA%B0%80-%EB%AC%B8%EC%A0%9C%EC%9D%B8%EA%B1%B8%EA%B9%8C-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95%EC%9D%80-de287bce1643

AB Test 중 불균등한 샘플 분배에 대한 글

지난주 약 8개월간 준비한 프로젝트를 런칭했습니다. 🙂

네이버의 두 번째 사옥인 1784의 이야기를 담은 책 ⟪1784 THE TESTBED⟫를 출간한 것인데요, 저 개인적으로 회사 생활을 통틀어 가장 크고 긴 프로젝트였던 1784의 이야기를 책으로 풀어낼 수 있다는 것에 큰 감사함과 뿌듯함이 동시에 솟아났습니다.
(물론 쉽고 재밌기만 한 것은 결코 아니었습니다... 여전히 더 잘할 수 있지 않았을까 하는 아쉬움도 있고요...😭)

저는 이 프로젝트의 PM을 맡았고, 원고는 1784 TF 멤버가 함께 썼으며, 편집은 디자인프레스, 디자인은 신신에서 맡아주셨습니다.

현재 온,오프라인 서점에서 모두 구매가 가능합니다 🙌

지난주 약 8개월간 준비한 프로젝트를 런칭했습니다. 🙂 네이버의 두 번째 사옥인 1784의 이야기를 담은 책 ⟪1784 THE TESTBED⟫를 출간한 것인데요, 저 개인적으로 회사 생활을 통틀어 가장 크고 긴 프로젝트였던 1784의 이야기를 책으로 풀어낼 수 있다는 것에 큰 감사함과 뿌듯함이 동시에 솟아났습니다. (물론 쉽고 재밌기만 한 것은 결코 아니었습니다... 여전히 더 잘할 수 있지 않았을까 하는 아쉬움도 있고요...😭) 저는 이 프로젝트의 PM을 맡았고, 원고는 1784 TF 멤버가 함께 썼으며, 편집은 디자인프레스, 디자인은 신신에서 맡아주셨습니다. 현재 온,오프라인 서점에서 모두 구매가 가능합니다 🙌

네이버의 두 번째 사옥을 다룬 이야기, 1784 THE TESTBED

무더운 8월, 썸원과 함께 좋은 콘텐츠를 향한 탐험을 떠나보시지요

[2024년 8월] 썸원 프라임 멤버십 모집 안내

1. 많은 사람들이 지적하듯, ‘주의집중력’과 ‘문해력’은 시간이 지날수록 점점 더 중요한 자산이 되어가고 있는데요. 콘텐츠와 정보가 넘쳐흐를 정도로 범람하다 보니, 자극적이고 저품질의 콘텐츠에 본인의 소중한 집중력을 낭비하기 그 어떤 시대보다 쉽기 때문이지 않을까 싶어요.

2. 따라서 요즘처럼 콘텐츠가 넘치는 시대에는, 좋은 콘텐츠에 자신의 집중력을 잘 투자하는 것이 점점 더 중요해지고 있고, 좋은 콘텐츠를 온전히 잘 이해하기 위해 문해력과 이해력을 키우는 것도 필수적인 일이 되고 있는데요.

3. 사람에 따라서는, 앞으로는 이 집중력과 문해력에서부터 한 사람이나 조직의 경쟁력이 결정될 것이라고 주장하기도 합니다. 저품질의 콘텐츠에 본인의 집중력을 낭비 혹은 탕진하는 사람과 좋은 콘텐츠에 본인의 집중력을 온전히 투자하는 사람 사이의 격차는 생길 수밖에 없다는 것이죠.

4. 그런 의미에서 여전히 부족함이 많지만, ‘썸원 프라임 멤버십’은 멤버십 회원분들께서 양질의 콘텐츠를 보다 쉽게 발견하고, 보다 잘 경험하시는 데 기여하는 것을 목표로 하고 있는데요.

5. 이를 위해 멤버십 회원분들께서만 볼 수 있는 ‘독점적인 콘텐츠들’과 제가 본 흥미로운 콘텐츠를 평일 저녁마다 보내드리는 ‘데일리 브리프'를 제공하고 있습니다.

6. 이뿐 아니라, 멤버십 회원분들께서 다양한 사람들과 연결되고, 글쓰기를 비롯해 본인의 창의성과 세상에 대한 이해력을 높일 수 있는 다양한 멤버십 행사들도 열고 있는데요.

7. 이를 통해 ‘양질의 콘텐츠가 흘러넘치는 밀도 높은 멤버십 네트워크'를 만드는 것이 저의 목표랍니다.

8. 그리고 다가오는 9월이면, 제가 사업을 시작한지도 어느새 만으로 4년이 되는데요. 아직도 걸음마 단계라서 부끄러운 면이 없지 않지만, 그래도 그동안 나름의 추진력을 쌓아왔다는 생각도 하고 있어요.

9. 일개 개인이 처음부터 끝까지 혼자서 손수 운영하는 유료 멤버십이라는 게 실제 현실에서 굴러갈 수 있다는 것 자체가 나름 신기한 부분도 있다고 생각하고 있고요.

10. 물론 멤버십 회원분들에게 더 높은 만족감과 더 좋은 콘텐츠를 전해드리기 위해선 나아갈 길이 멀고도 험한데요. 그래도 지금까지 열심히 달려온 만큼, 5년, 10년, 더 달려갈 수 있도록 계속해서 최선을 다하겠습니다.

11. 그런 의미에서 9월 멤버십 모집을 시작하고자 하오니 많은 관심 부탁드리옵고, 매월 수동으로 멤버십을 이용하는 것이 불편한 분들을 위해 9월에는 특별히 한 번에 12월까지 멤버십을 이용할 수 있는 멤버십 시즌권도 모집하고 있답니다 (호호) 많은 관심 부탁드리옵고, 앞으로도 잘 부탁드리겠습니다. 늘 감사합니다 ;)

https://somewon.notion.site/2024-9-eccdb331d1ab4fdc9d77e5dd4a36d941

1. 많은 사람들이 지적하듯, ‘주의집중력’과 ‘문해력’은 시간이 지날수록 점점 더 중요한 자산이 되어가고 있는데요. 콘텐츠와 정보가 넘쳐흐를 정도로 범람하다 보니, 자극적이고 저품질의 콘텐츠에 본인의 소중한 집중력을 낭비하기 그 어떤 시대보다 쉽기 때문이지 않을까 싶어요. 2. 따라서 요즘처럼 콘텐츠가 넘치는 시대에는, 좋은 콘텐츠에 자신의 집중력을 잘 투자하는 것이 점점 더 중요해지고 있고, 좋은 콘텐츠를 온전히 잘 이해하기 위해 문해력과 이해력을 키우는 것도 필수적인 일이 되고 있는데요. 3. 사람에 따라서는, 앞으로는 이 집중력과 문해력에서부터 한 사람이나 조직의 경쟁력이 결정될 것이라고 주장하기도 합니다. 저품질의 콘텐츠에 본인의 집중력을 낭비 혹은 탕진하는 사람과 좋은 콘텐츠에 본인의 집중력을 온전히 투자하는 사람 사이의 격차는 생길 수밖에 없다는 것이죠. 4. 그런 의미에서 여전히 부족함이 많지만, ‘썸원 프라임 멤버십’은 멤버십 회원분들께서 양질의 콘텐츠를 보다 쉽게 발견하고, 보다 잘 경험하시는 데 기여하는 것을 목표로 하고 있는데요. 5. 이를 위해 멤버십 회원분들께서만 볼 수 있는 ‘독점적인 콘텐츠들’과 제가 본 흥미로운 콘텐츠를 평일 저녁마다 보내드리는 ‘데일리 브리프'를 제공하고 있습니다. 6. 이뿐 아니라, 멤버십 회원분들께서 다양한 사람들과 연결되고, 글쓰기를 비롯해 본인의 창의성과 세상에 대한 이해력을 높일 수 있는 다양한 멤버십 행사들도 열고 있는데요. 7. 이를 통해 ‘양질의 콘텐츠가 흘러넘치는 밀도 높은 멤버십 네트워크'를 만드는 것이 저의 목표랍니다. 8. 그리고 다가오는 9월이면, 제가 사업을 시작한지도 어느새 만으로 4년이 되는데요. 아직도 걸음마 단계라서 부끄러운 면이 없지 않지만, 그래도 그동안 나름의 추진력을 쌓아왔다는 생각도 하고 있어요. 9. 일개 개인이 처음부터 끝까지 혼자서 손수 운영하는 유료 멤버십이라는 게 실제 현실에서 굴러갈 수 있다는 것 자체가 나름 신기한 부분도 있다고 생각하고 있고요. 10. 물론 멤버십 회원분들에게 더 높은 만족감과 더 좋은 콘텐츠를 전해드리기 위해선 나아갈 길이 멀고도 험한데요. 그래도 지금까지 열심히 달려온 만큼, 5년, 10년, 더 달려갈 수 있도록 계속해서 최선을 다하겠습니다. 11. 그런 의미에서 9월 멤버십 모집을 시작하고자 하오니 많은 관심 부탁드리옵고, 매월 수동으로 멤버십을 이용하는 것이 불편한 분들을 위해 9월에는 특별히 한 번에 12월까지 멤버십을 이용할 수 있는 멤버십 시즌권도 모집하고 있답니다 (호호) 많은 관심 부탁드리옵고, 앞으로도 잘 부탁드리겠습니다. 늘 감사합니다 ;) https://somewon.notion.site/2024-9-eccdb331d1ab4fdc9d77e5dd4a36d941

Somewon on Notion

9월 멤버십 신청하기

🕊️ [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에 'React 질문하기' 토픽이 새로 생겼다는 소식을 전해드렸는데요!
React 질문하기 토픽에 올라오는 질문의 95%가 24시간 내에 답변을 받고 있답니다😎
오늘은 더 편하게 질문을 올릴 수 있도록 새로 추가된 기능을 소개하려고 해요.
-
커리어리 Q&A 질문에 코드를 남길 수 있는 기능이 추가되었어요.
이제 코드를 포함해서 다양한 질문을 남길 수 있답니다!

🎈 질문에 코드 입력하는 법
1. 커리어리 Q&A에서 '익명 질문하기' 버튼을 누른다.
2. 'Github Gist로 코드 추가' 부분에 코드가 포함된 Github Gist 링크를 남긴다.
3. 질문 등록을 완료한다.
-
여기에 더해서, 질문에 추천/비추천을 누를 수 있는 기능도 함께 추가되었어요.
정성스럽고 좋은 질문에 추천 버튼을, 설명이 부족한 질문에 비추천 버튼을 눌러 주시면 질문자 분들께 많은 도움이 된답니다!
그럼, 바뀐 Q&A를 확인하러 가 볼까요?

(커리어리 Q&A는 웹에서는 상단 현직자 Q&A 버튼을, 앱에서는 홈 피드 상단의 현직자 Q&A 버튼을 눌러 확인할 수 있어요.)

Product Designer

정다희

Product Manager

김은서

라인플러스 소프트웨어 엔지니어

이원형

👨‍🎓무선 통신 분야 석사를 마치고 💾반도체 펌웨어를 개발하다가
지금은 💻메신저를 개발하고 있습니다.

❗ 본 계정에서 작성되는 모든 의견은 특정 회사와는 무관합니다.

💌 Q&A 업데이트: 질문에 코드를 남길 수 있어요!

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

공식 계정

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

커리어리

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

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

⏬ 커리어리 앱 다운받기

🔎 커리어리 공식 블로그

💙 커리어리 공식 페이스북

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

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

💌 Q&A 업데이트: 질문에 코드를 남길 수 있어요!

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필