"바쁘니까 디자인은 나중에 챙기자" 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다. 시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이...

왜 디자인 시스템을 만들까?

원문: https://designcompass.org/2024/04/14/why-design-system/

“바쁘니까 디자인은 나중에 챙기자“ 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다.
시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이 나올 수 있게 만듭니다. 그렇다면 디자인 시스템을 만들면 어떤 효과를 얻을 수 있을까요?

1. 방향을 잡는 일관된 원칙
디자인이 효과를 내려면 올바른 방향으로 나아가야 합니다. 같은 것을 만들더라도 추구하는 방향성에 따라 고객 경험이 크게 달라집니다. 고객에게 최고라 생각하는 것 단 한 개를 제시할 수도 있고 고객이 직접 자신이 원하는 경험을 선택하게 만들 수도 있습니다.

디자이너가 문제 해결이나 메시지 표현에만 집중하다 보면 길을 잃어버리는 경우가 많습니다. 이 때 시스템은 우리가 미아가 되는 것을 막아줍니다. 고객이 쉽고 편하게 기대하는 것을 얻을 수 있게 ’간결함‘을 추구한다면 최소한의 시각 기법을 사용합니다. 고객의 기억 속에 각인 되기 위한 ’고유함‘을 추구한다면 남들이 시도하지 않는 새로운 도전을 합니다.

시스템은 이러한 가치를 명문화하고 의사결정을 위한 중요한 판단 기준이 됩니다. 앞으로 일어날 모든 경우의 수를 위한 규칙보다는 스스로 질문하는 원칙이 됩니다. 버튼의 동작법이나 사진 톤 & 매너와 같은 구체적인 가이드는 추상적인 디자인 원칙의 구체적인 사례가 되어줍니다. 그렇게 회사나 서비스가 제공하는 결과물이 일관된 원칙에 기반해 고객에게 전달될 수 있습니다.

2. 균일한 품질을 위한 기준
고객의 선택 받을 수 있을만큼 좋은 것을 만들어야 합니다. 우리는 하루에도 수십, 수백 개의 디자인을 만듭니다. 고객은 이 중에서 한 두 개 정도의 디자인을 볼까 말까입니다. 고작 1~2초 정도의 짧은 시간에 고객이 훑어본 결과물의 품질이 곧 내 브랜드의 전체 품질이 됩니다. 그렇기 때문에 고객이 브랜드를 경험하는 모든 순간을 최대한 높은 품질을 유지해야 하죠.

하지만 모든 것을 언제나 잘 만들기는 어렵습니다. 항상 시간이 없고 투자 가치를 예측하기 어렵습니다. 혼자서도 어려운데 여럿이 함께 만들 때는 좋은 품질을 지키기가 더욱 어려워집니다. 작업자에 따라 문제를 해결하는 방식과 품질이 달라지죠. 매번 모니터링하고 소통하기 어렵다 보니 쉽게 포기하게 되죠.

시스템은 효과가 검증된 방법을 전체에 전파합니다. 원칙에 기반한 좋은 사례를 정의하고 동료를 설득해 미래에 비슷한 문제가 생겼을 때 같은 방식으로 해결하게 합니다. 디자인 결과물의 효과에 관한 불확실성을 줄이고 새로운 영역에 도전할 수 있는 여력을 만들어주죠. 그렇게 조직 전체 품질의 평균을 높이고 하한선을 끌어올립니다.

3. 빠른 제작을 위한 재료
방향이 맞고 품질이 좋으면 이제 빨리 만들어야 합니다. 아무리 좋은 것이라도 고객에게 전달되지 않으면 의미가 없습니다. 전달하기 전에 좋은지 나쁜지 모르는 경우도 많죠. 심지어 경쟁사는 호시탐탐 우리보다 더 잘하기 위해 노력하고 있습니다. 언제 어디서 우리가 역전당할지 알 수 없습니다.

고객에게 빨리 전달하기 위해서는 결과물을 생산하는 속도가 빨라져야 합니다. 같은 시간에 만들어내는 결과물의 개수가 늘어나야 하죠. 사람을 갈아서 속도가 엄청나게 빨라질 수 있지만 오래갈 수 없죠. 그렇다면 만들어야 하는 결과물의 숫자를 줄여야 합니다.

시스템은 디자이너가 만들 결과물의 수를 줄입니다. 과거의 반복을 바탕으로 미래의 반복을 예측합니다. 미래에도 계속 쓸 디자인을 작은 단위로 쪼개 시스템에 등록합니다. 디자이너는 효과를 예측할 수 있는 여러 요소를 결합해 패턴을 만듭니다. 매번 새로운 요소를 만들 필요가 없어져 제작 속도가 빨라집니다.

#디자인시스템 #디자인 #디자인나침반 #인사이트

원문: https://designcompass.org/2024/04/14/why-design-system/ “바쁘니까 디자인은 나중에 챙기자“ 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다.시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이 나올 수 있게 만듭니다. 그렇다면 디자인 시스템을 만들면 어떤 효과를 얻을 수 있을까요? 1. 방향을 잡는 일관된 원칙디자인이 효과를 내려면 올바른 방향으로 나아가야 합니다. 같은 것을 만들더라도 추구하는 방향성에 따라 고객 경험이 크게 달라집니다. 고객에게 최고라 생각하는 것 단 한 개를 제시할 수도 있고 고객이 직접 자신이 원하는 경험을 선택하게 만들 수도 있습니다. 디자이너가 문제 해결이나 메시지 표현에만 집중하다 보면 길을 잃어버리는 경우가 많습니다. 이 때 시스템은 우리가 미아가 되는 것을 막아줍니다. 고객이 쉽고 편하게 기대하는 것을 얻을 수 있게 ’간결함‘을 추구한다면 최소한의 시각 기법을 사용합니다. 고객의 기억 속에 각인 되기 위한 ’고유함‘을 추구한다면 남들이 시도하지 않는 새로운 도전을 합니다. 시스템은 이러한 가치를 명문화하고 의사결정을 위한 중요한 판단 기준이 됩니다. 앞으로 일어날 모든 경우의 수를 위한 규칙보다는 스스로 질문하는 원칙이 됩니다. 버튼의 동작법이나 사진 톤 &amp; 매너와 같은 구체적인 가이드는 추상적인 디자인 원칙의 구체적인 사례가 되어줍니다. 그렇게 회사나 서비스가 제공하는 결과물이 일관된 원칙에 기반해 고객에게 전달될 수 있습니다. 2. 균일한 품질을 위한 기준고객의 선택 받을 수 있을만큼 좋은 것을 만들어야 합니다. 우리는 하루에도 수십, 수백 개의 디자인을 만듭니다. 고객은 이 중에서 한 두 개 정도의 디자인을 볼까 말까입니다. 고작 1~2초 정도의 짧은 시간에 고객이 훑어본 결과물의 품질이 곧 내 브랜드의 전체 품질이 됩니다. 그렇기 때문에 고객이 브랜드를 경험하는 모든 순간을 최대한 높은 품질을 유지해야 하죠. 하지만 모든 것을 언제나 잘 만들기는 어렵습니다. 항상 시간이 없고 투자 가치를 예측하기 어렵습니다. 혼자서도 어려운데 여럿이 함께 만들 때는 좋은 품질을 지키기가 더욱 어려워집니다. 작업자에 따라 문제를 해결하는 방식과 품질이 달라지죠. 매번 모니터링하고 소통하기 어렵다 보니 쉽게 포기하게 되죠. 시스템은 효과가 검증된 방법을 전체에 전파합니다. 원칙에 기반한 좋은 사례를 정의하고 동료를 설득해 미래에 비슷한 문제가 생겼을 때 같은 방식으로 해결하게 합니다. 디자인 결과물의 효과에 관한 불확실성을 줄이고 새로운 영역에 도전할 수 있는 여력을 만들어주죠. 그렇게 조직 전체 품질의 평균을 높이고 하한선을 끌어올립니다. 3. 빠른 제작을 위한 재료방향이 맞고 품질이 좋으면 이제 빨리 만들어야 합니다. 아무리 좋은 것이라도 고객에게 전달되지 않으면 의미가 없습니다. 전달하기 전에 좋은지 나쁜지 모르는 경우도 많죠. 심지어 경쟁사는 호시탐탐 우리보다 더 잘하기 위해 노력하고 있습니다. 언제 어디서 우리가 역전당할지 알 수 없습니다. 고객에게 빨리 전달하기 위해서는 결과물을 생산하는 속도가 빨라져야 합니다. 같은 시간에 만들어내는 결과물의 개수가 늘어나야 하죠. 사람을 갈아서 속도가 엄청나게 빨라질 수 있지만 오래갈 수 없죠. 그렇다면 만들어야 하는 결과물의 숫자를 줄여야 합니다. 시스템은 디자이너가 만들 결과물의 수를 줄입니다. 과거의 반복을 바탕으로 미래의 반복을 예측합니다. 미래에도 계속 쓸 디자인을 작은 단위로 쪼개 시스템에 등록합니다. 디자이너는 효과를 예측할 수 있는 여러 요소를 결합해 패턴을 만듭니다. 매번 새로운 요소를 만들 필요가 없어져 제작 속도가 빨라집니다. #디자인시스템 #디자인 #디자인나침반 #인사이트

디자인 나침반

📝 왜 디자인 시스템을 만들까?

나 없이 조직이 돌아가지 않으면 내가 트롤이다 | 조직의 중요한 결정은 다 나 몰래 내려진다. '윗분들은' 정말 쉬쉬하고 싶은 것일까?' 에 이어 다시 IT 원주민들의 회사 생활을 엿보자. 원준팀의 '애니메이션 커뮤니티' 서비스는 점점 성장해서 직원 수도 100여 명이 넘고 다음 시리즈 유치도 성공하며 업계에서 꽤 이름 난 스타트업이 되었다.

리더가 없어도 의사결정할 수 있어야 한다.

팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다.

예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다   

 1. 팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.
 2. 의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.
 3. 상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.

IT기업은 대부분 역할 조직의 형태를 따르고 있다. 역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다.  역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다. 

내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다.

문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다.  불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다.  리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다.

역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다. 각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다

의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다. 속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다.

이를 해결하기 위해서는 다음과 같은 실행이 뒤따라야 한다.

1. 의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다.

리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다.

2. 프로젝트 관련된 정보가 공유되고 원칙이 세워진다.

프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다.

3. 정보가 적시에 전달된다.

정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다. 시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다.

https://brunch.co.kr/@kgbtomas/291

팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다. 예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다 &nbsp;&nbsp; <ol ><li>팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.</li><li>의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.</li><li>상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.</li></ol> IT기업은 대부분 역할 조직의 형태를 따르고 있다. 역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다.&nbsp;&nbsp;역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다.&nbsp; 내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다. 문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다. &nbsp;불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다.&nbsp;&nbsp;리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다. 역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다.&nbsp;각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다 의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다. 속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다. 이를 해결하기 위해서는 다음과 같은 실행이 뒤따라야 한다. 1. 의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다. 리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다. 2. 프로젝트 관련된 정보가 공유되고 원칙이 세워진다. 프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다. 3. 정보가 적시에 전달된다. 정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다. 시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다. https://brunch.co.kr/@kgbtomas/291

Brunch Story

리더가 없어도 결정은 내려진다.

제 22대 국회의원선거가 어느새 D-2입니다. 사전투표율이 31.27%로 집계되어 총선 사전투표제가 도입된 이래 역대 최고 투표율입니다. 지난 6일 중앙선거관리위원회는 전체 유권자 4428만11명 가운데 1384만9043명이 참여했다고 밝혔습니다. 선거가 귀찮은 의무가 아니라 꼭 해야하는 책임이 된 것 같습니다. 이번 사전투표는 5일과 6일 아침 6시부터...

제22대 국회의원선거: 서비스별 경험은 어떻게 다를까?

제22대 국회의원선거가 어느새 D-2입니다. 사전투표율이 31.27%로 집계되어 총선 사전투표제가 도입된 이래 역대 최고 투표율입니다. 지난 6일 중앙선거관리위원회는 전체 유권자 4428만11명 가운데 1384만9043명이 참여했다고 밝혔습니다. 선거가 귀찮은 의무가 아니라 꼭 해야하는 책임이 된 것 같습니다.

이번 사전투표는 5일과 6일 아침 6시부터 오후 6시까지 전국 3,565개 사전투표소에서 실시되었습니다. 신분증만 있으면 어느 투표소에서나 투표할 수 있게 되었죠. 저는 토요일에도 할 수 있다는 사실을 끝나기 1시간 전에 알아 간신히 투표할 수 있었습니다. 효율적으로 발전하는 행정에 역시 한국이라는 생각이 들었습니다.

문득 사람들의 투표 경험이 어떨지 궁금했습니다. 그래서 오늘은 간단하게 지역 생활에 큰 영향을 끼치는 네이버, 다음, 당근이 투표와 관련된 정보를 어떻게 제공하는지 비교해 봤습니다.

더 자세한 내용은 링크에서 확인하세요.
https://designcompass.org/2024/04/08/22th-congress-election/

제22대 국회의원선거가 어느새 D-2입니다. 사전투표율이 31.27%로 집계되어 총선 사전투표제가 도입된 이래 역대 최고 투표율입니다. 지난 6일 중앙선거관리위원회는 전체 유권자 4428만11명 가운데 1384만9043명이 참여했다고 밝혔습니다. 선거가 귀찮은 의무가 아니라 꼭 해야하는 책임이 된 것 같습니다. 이번 사전투표는 5일과 6일 아침 6시부터 오후 6시까지 전국 3,565개 사전투표소에서 실시되었습니다. 신분증만 있으면 어느 투표소에서나 투표할 수 있게 되었죠. 저는 토요일에도 할 수 있다는 사실을 끝나기 1시간 전에 알아 간신히 투표할 수 있었습니다. 효율적으로 발전하는 행정에 역시 한국이라는 생각이 들었습니다. 문득 사람들의 투표 경험이 어떨지 궁금했습니다. 그래서 오늘은 간단하게 지역 생활에 큰 영향을 끼치는 네이버, 다음, 당근이 투표와 관련된 정보를 어떻게 제공하는지 비교해 봤습니다. 더 자세한 내용은 링크에서 확인하세요.https://designcompass.org/2024/04/08/22th-congress-election/

계란후라이 904

학교 밖에서 무엇을 가르쳐 줄 수 있을까? 어떻게 가르쳐 줄 수 있을까요?
초등학교 6년, 중학교 3년, 고등학교 3년, 그리고 대학교를 진학한다면 2-4년 이상 우리는 교육을 받습니다. 개인마다 다르겠지만 저는 16년 초, 중, 고등학교와 대학교 졸업까지 교육을 받았습니다. 그 후 직장에 취업을 했고, 16년 동안 직장에 근무하며 직장인으로 살고 있습니다. 살면서 받는 기초 교육과 고등 교육을 폄하하는 사람들이 있습니다. 중학교와 고등학교, 대학교까지 나와서 그와 관련 없는 일을 한다고, 학교에서 배운 지식을 자신의 일자리에서 적극적으로 활용하고 있지 못하는 것을 아쉬움에 하는 소리라고 생각합니다. 하지만 저는 중학교와 고등학교, 대학을 다니는 동안 사람으로서 갖추어야 할 기본 소양을 배웠고, 지식을 습득하는 방법과 인내를 배웠다고 생각합니다. JTBC 뉴스에서 진행한 설문 조사에 따르면 직장인 10명 중 4명만 전공을 살려 취업했다는 결과를 보았습니다. 전공을 살려 취업한 비중이 생각보다 높다는 것에 놀랐습니다. 최근 5년 동안 500명 정도 커리어 코칭을 제공한 사람들은 30% 미만으로 전공을 따라 취업에 도전하는 데이터가 있었기 때문입니다.
중요한 건 과반수가 되지 않는 사람들이 직업을 선택할 때 이전에 받았던 교육에 관계없이 직업을 선택하고 있다는 것이 문제라고 생각합니다. 이것이 왜 문제냐 하면 학교 교육을 통해 배우면서 직업적 목표를 연관 지어 꿈꾸지 못하는 것과 그렇게 직업을 선택하는 순간 주변 지인 즉, 부모님과 선생님으로부터 강한 직업 추천 또는 직업 선택의 개입이 되는 것, 그리고 첫 직업을 갖고 3년 미만 동안 경험을 통해 자신이 원했던 직업이 아니었음을 깨닫고 방황하게 되는 것입니다.
수학과 과학, 국어와 영어, 체육과 미술, 전공과 교양 등 다양한 과목을 배우는 중에 자연스럽게 떠오르는 일이 있을 법도 한데, 제 자신의 초등학교와 중학교, 고등학교와 대학 시절을 떠올려 보거나 커리어 상담을 통해 만난 사람들 500명의 과거를 들여다보면, 학교에서 배운 내용과 연과 지어 직업적 목표를 갖게 되었다고 이야기하는 사람은 20% 미만이었습니다. 추측건대 학교에서 배우는 내용이 재미없어서 억지로 공부했기 때문이 아닐까요? 공부가 좋고 제일 쉬웠다고 이야기하는 사람보다 그 반대의 경우가 훨씬 많은 군집을 이룰 것입니다.
최근에 읽은 퍼블리 아티클에서 본 내용이기도 하고, 교육 회사에 근무하고 있는 사람으로서 궁금해졌습니다. 이런 학교 교육을 받고 갖게 된 직업이 교육과 관련 없다고 생각하는 우리는 다음 세대에게 무엇을 알려 줘야 하며, 알려 줄 수 있을까요?
어쩌면 답이 뻔하게 나온 질문일 수도 있고, 진짜 더 창의적인 아이디어가 나올 수도 있겠다는 호기심 생기는 질문입니다. 적어도 국어, 영어, 수학, 등을 조기 교육하는 것보다 더 중요한 것을 우리 부모님들이 놓치고 있는 것은 아닐까요? 초등학생과 유치원을 다니는 자녀 둘을 양육하는 부모로서 항상 기억하고 되새겨야 하는 질문이라고 생각합니다.

계란후라이 904 학교 밖에서 무엇을 가르쳐 줄 수 있을까? 어떻게 가르쳐 줄 수 있을까요?초등학교 6년, 중학교 3년, 고등학교 3년, 그리고 대학교를 진학한다면 2-4년 이상 우리는 교육을 받습니다. 개인마다 다르겠지만 저는 16년 초, 중, 고등학교와 대학교 졸업까지 교육을 받았습니다. 그 후 직장에 취업을 했고, 16년 동안 직장에 근무하며 직장인으로 살고 있습니다. 살면서 받는 기초 교육과 고등 교육을 폄하하는 사람들이 있습니다. 중학교와 고등학교, 대학교까지 나와서 그와 관련 없는 일을 한다고, 학교에서 배운 지식을 자신의 일자리에서 적극적으로 활용하고 있지 못하는 것을 아쉬움에 하는 소리라고 생각합니다. 하지만 저는 중학교와 고등학교, 대학을 다니는 동안 사람으로서 갖추어야 할 기본 소양을 배웠고, 지식을 습득하는 방법과 인내를 배웠다고 생각합니다. JTBC 뉴스에서 진행한 설문 조사에 따르면 직장인 10명 중 4명만 전공을 살려 취업했다는 결과를 보았습니다. 전공을 살려 취업한 비중이 생각보다 높다는 것에 놀랐습니다. 최근 5년 동안 500명 정도 커리어 코칭을 제공한 사람들은 30% 미만으로 전공을 따라 취업에 도전하는 데이터가 있었기 때문입니다.중요한 건 과반수가 되지 않는 사람들이 직업을 선택할 때 이전에 받았던 교육에 관계없이 직업을 선택하고 있다는 것이 문제라고 생각합니다. 이것이 왜 문제냐 하면 학교 교육을 통해 배우면서 직업적 목표를 연관 지어 꿈꾸지 못하는 것과 그렇게 직업을 선택하는 순간 주변 지인 즉, 부모님과 선생님으로부터 강한 직업 추천 또는 직업 선택의 개입이 되는 것, 그리고 첫 직업을 갖고 3년 미만 동안 경험을 통해 자신이 원했던 직업이 아니었음을 깨닫고 방황하게 되는 것입니다.수학과 과학, 국어와 영어, 체육과 미술, 전공과 교양 등 다양한 과목을 배우는 중에 자연스럽게 떠오르는 일이 있을 법도 한데, 제 자신의 초등학교와 중학교, 고등학교와 대학 시절을 떠올려 보거나 커리어 상담을 통해 만난 사람들 500명의 과거를 들여다보면, 학교에서 배운 내용과 연과 지어 직업적 목표를 갖게 되었다고 이야기하는 사람은 20% 미만이었습니다. 추측건대 학교에서 배우는 내용이 재미없어서 억지로 공부했기 때문이 아닐까요? 공부가 좋고 제일 쉬웠다고 이야기하는 사람보다 그 반대의 경우가 훨씬 많은 군집을 이룰 것입니다.최근에 읽은 퍼블리 아티클에서 본 내용이기도 하고, 교육 회사에 근무하고 있는 사람으로서 궁금해졌습니다. 이런 학교 교육을 받고 갖게 된 직업이 교육과 관련 없다고 생각하는 우리는 다음 세대에게 무엇을 알려 줘야 하며, 알려 줄 수 있을까요?어쩌면 답이 뻔하게 나온 질문일 수도 있고, 진짜 더 창의적인 아이디어가 나올 수도 있겠다는 호기심 생기는 질문입니다. 적어도 국어, 영어, 수학, 등을 조기 교육하는 것보다 더 중요한 것을 우리 부모님들이 놓치고 있는 것은 아닐까요? 초등학생과 유치원을 다니는 자녀 둘을 양육하는 부모로서 항상 기억하고 되새겨야 하는 질문이라고 생각합니다.

꿈을 찾는 사람에게 보내는 91 번째 편지

📌 이럴 때 추천해요 : "빡센 경제, 경영서 읽느라 지친 나에게 치팅데이를 선물하고 싶을 때"

01 . 비교적 책을 좋아하는 분이라면 '밸런스를 맞춰가며 읽는다'는 의미를 알고 계실 겁니다. 대부분 각자가 좋아하고 익숙한 분야의 책에 먼저 손이 가지만 어느 순간 이르러 지루하거나 지치는 포인트가 생기면 평소에 관심이 없던 분야 쪽으로도 기웃거리게 되기 때문이죠.

02 . 한편 이와는 결이 조금 다른 '밸런스'도 있습니다. 이건 일종의 시각 넓히기이기도 한데요, 한 가지 주제를 두고 이런 사람 이야기도 들어보고 싶고, 저런 사람 이야기도 들어보고 싶은 마음이 생길 때가 대표적입니다. 특히 제 경우엔 다그치듯 말하는 사람의 책을 읽고 나면 그다음엔 타이르듯 말해주는 사람의 책이 읽고 싶어지고, 불안감을 자극하는 책을 읽고 나면 어김없이 희망을 이야기하는 책이 읽고 싶어지거든요.

03 . 그래서 현실적인 경제, 경영 서적들의 타이트함(?)에 조금씩 피로도가 쌓여갈 때면 저는 '세스 고딘'의 작품들을 의도적으로 선택합니다. 고딘의 글이 비현실적이라는 건 절대 아니고, 그가 가지고 있는 선도적인 안목과 유쾌한 메시지, 때론 과감하기도 하고 어떨 땐 기상천외하기도 한 사례들을 접하는 게 일종의 '치팅 데이'처럼 느껴지기 때문이죠.

04 . 작년 연말에 출간된 ⟪의미의 시대⟫는 앞으로 일과 일터가 어떻게 바뀔 것인지에 대한 통찰을 담고 있는 책입니다. 몇 년 전 출간한 ⟪린치핀⟫이 '앞으로 나는 어떤 역할을 해야 하는가'에 초점이 맞춰졌다면 이번 책에서는 '앞으로 우리가 일하게 될 판은 어떻게 변할 것인가'를 이야기한다고 봐도 무방하죠. 비록 '일 잘하는 법'이라거나 '다가올 미래 예측서'와 같은 책들에 견주면 말랑말랑하고 가벼운 이야기를 담고 있지만 그래도 저는 이런 말들이 필요한 순간이 있다고 생각합니다.

05 . 특히 좋았던 점 중 하나는 제목에서처럼 '의미'를 찾고 부여할 수 있는 대상들을 잘 포착했다는 것이었습니다. 전인류가 AI라는 것에 관심을 가지는 시대라면, 그래서 머지않아 수많은 것들이 AI로 대체될 것임이 명확하다면 우리는 무엇에 의미를 부여하고, 무엇을 더 의미 있게 받아들일 것이며, 무엇의 의미를 탐색할 것인가가 아주아주 중요해질 테니 말이죠.

06 . 그러니 세세한 주제나 전문적인 항목들을 다루는 책들에 치우쳐져 있었다면 의도적으로 '뭣이 중헌디?'라는 질문을 던지는 책으로도 눈길을 돌릴 필요가 있습니다. 내 성향에 맞든 맞지 않든 이런 책을 한 번 만나고 나면 그 다음 책을 고르는 안목 역시 높아지더라고요.
'웬일로 안먹던 돌체라떼를 시키냐'는 질문에 '가끔 또 이렇게 마셔줘야 평소 아아의 소중함을 더 간절히 느끼기 때문이지'라는 친구의 말이 책에도 적용될 수 있단 생각을 해보며, 요즘같이 목을 죄어오는 책들이 쏟아지는 현실 속에서 ⟪의미의 시대⟫란 시즌 메뉴를 하나 추천해 봅니다.

📌 이럴 때 추천해요 : "빡센 경제, 경영서 읽느라 지친 나에게 치팅데이를 선물하고 싶을 때" 01 . 비교적 책을 좋아하는 분이라면 '밸런스를 맞춰가며 읽는다'는 의미를 알고 계실 겁니다. 대부분 각자가 좋아하고 익숙한 분야의 책에 먼저 손이 가지만 어느 순간 이르러 지루하거나 지치는 포인트가 생기면 평소에 관심이 없던 분야 쪽으로도 기웃거리게 되기 때문이죠. 02 . 한편 이와는 결이 조금 다른 '밸런스'도 있습니다. 이건 일종의 시각 넓히기이기도 한데요, 한 가지 주제를 두고 이런 사람 이야기도 들어보고 싶고, 저런 사람 이야기도 들어보고 싶은 마음이 생길 때가 대표적입니다. 특히 제 경우엔 다그치듯 말하는 사람의 책을 읽고 나면 그다음엔 타이르듯 말해주는 사람의 책이 읽고 싶어지고, 불안감을 자극하는 책을 읽고 나면 어김없이 희망을 이야기하는 책이 읽고 싶어지거든요. 03 . 그래서 현실적인 경제, 경영 서적들의 타이트함(?)에 조금씩 피로도가 쌓여갈 때면 저는 '세스 고딘'의 작품들을 의도적으로 선택합니다. 고딘의 글이 비현실적이라는 건 절대 아니고, 그가 가지고 있는 선도적인 안목과 유쾌한 메시지, 때론 과감하기도 하고 어떨 땐 기상천외하기도 한 사례들을 접하는 게 일종의 '치팅 데이'처럼 느껴지기 때문이죠. 04 . 작년 연말에 출간된 ⟪의미의 시대⟫는 앞으로 일과 일터가 어떻게 바뀔 것인지에 대한 통찰을 담고 있는 책입니다. 몇 년 전 출간한 ⟪린치핀⟫이 '앞으로 나는 어떤 역할을 해야 하는가'에 초점이 맞춰졌다면 이번 책에서는 '앞으로 우리가 일하게 될 판은 어떻게 변할 것인가'를 이야기한다고 봐도 무방하죠. 비록 '일 잘하는 법'이라거나 '다가올 미래 예측서'와 같은 책들에 견주면 말랑말랑하고 가벼운 이야기를 담고 있지만 그래도 저는 이런 말들이 필요한 순간이 있다고 생각합니다. 05 . 특히 좋았던 점 중 하나는 제목에서처럼 '의미'를 찾고 부여할 수 있는 대상들을 잘 포착했다는 것이었습니다. 전인류가 AI라는 것에 관심을 가지는 시대라면, 그래서 머지않아 수많은 것들이 AI로 대체될 것임이 명확하다면 우리는 무엇에 의미를 부여하고, 무엇을 더 의미 있게 받아들일 것이며, 무엇의 의미를 탐색할 것인가가 아주아주 중요해질 테니 말이죠. 06 . 그러니 세세한 주제나 전문적인 항목들을 다루는 책들에 치우쳐져 있었다면 의도적으로 '뭣이 중헌디?'라는 질문을 던지는 책으로도 눈길을 돌릴 필요가 있습니다. 내 성향에 맞든 맞지 않든 이런 책을 한 번 만나고 나면 그 다음 책을 고르는 안목 역시 높아지더라고요. '웬일로 안먹던 돌체라떼를 시키냐'는 질문에 '가끔 또 이렇게 마셔줘야 평소 아아의 소중함을 더 간절히 느끼기 때문이지'라는 친구의 말이 책에도 적용될 수 있단 생각을 해보며, 요즘같이 목을 죄어오는 책들이 쏟아지는 현실 속에서 ⟪의미의 시대⟫란 시즌 메뉴를 하나 추천해 봅니다.

[ 그때를 위한 책 - vol.37 ] ⟪의미의 시대⟫

작년에는 경영 쪽을 많이 읽다보니 너무 삶이 계산적으로 변하는 것 같아 이번 년도는 문학 쪽도 함께 읽고 있습니다. 

추천해주신 의미의 시대도 조만간 읽고 싶은 도서 목록에 올리겠습니다!

라이팅에 구체성을 더해 매끄러운 UX 만들기 | 구체성은 사용자에게 눈앞의 문제를 해결할 힘을 줍니다. 모호하게 느껴지는 모바일 인터페이스를 살펴보면 라이팅이 구체적이지 않은 경우가 많습니다. 서비스 규모가 커질수록 인터랙션 경우의 수는 방대해집니다. 이 경우 불어난 레이블이나 토스트, 팝업 등에 포괄적인 라이팅을 적용해 대응의 기동성을 선택하는 경우가 많습니다.

14화 모호한 UX 라이팅이 문제라고요?

명확하고 이해하기 쉬운 라이팅은 사용자 경험을 크게 개선할 수 있습니다. 이번 글에서는 UX 라이팅이 모호할 때 발생하는 문제와 이를 해결하기 위한 구체적인 방법을 다룹니다.

- 📖 명확한 커뮤니케이션: 사용자가 정보를 쉽게 이해하고, 신속하게 행동으로 옮길 수 있도록 돕습니다.
- 🚫 모호한 라이팅의 문제점: 혼란과 오해를 초래하며, 사용자 만족도를 저하시킬 수 있습니다.
- 💡 개선 방안: 실제 예시를 통해 어떻게 UX 라이팅을 개선할 수 있는지 제시합니다.

명확하고 이해하기 쉬운 라이팅은 사용자 경험을 크게 개선할 수 있습니다. 이번 글에서는 UX 라이팅이 모호할 때 발생하는 문제와 이를 해결하기 위한 구체적인 방법을 다룹니다. - 📖 명확한 커뮤니케이션: 사용자가 정보를 쉽게 이해하고, 신속하게 행동으로 옮길 수 있도록 돕습니다.- 🚫 모호한 라이팅의 문제점: 혼란과 오해를 초래하며, 사용자 만족도를 저하시킬 수 있습니다.- 💡 개선 방안: 실제 예시를 통해 어떻게 UX 라이팅을 개선할 수 있는지 제시합니다.

🫨모호한 UX 라이팅이 문제라고요?

KRDS

제가 자문위원으로 참여한 대한민국 디지털정부 UI/UX 가이드라인이 공개되었습니다. 행안부 홈페이지에서도 정책자료 > 참고자료에서 보실 수 있습니다. 완벽하지 않지만 공공 서비스에서 제공하는 사용자 경험이 더 나아지는 시작점이 될 거라는 마음으로 참여했습니다 ☺️

기업에서 디자인 가이드라인을 만들 때마다 생각의 속도가 더뎌지는 지점들이 있습니다. 비즈니스에 적합한가, 달라지는 기술요소를 반영할 여력이 있는가, 이해관계자들이 바로 사용할 수 있는가. 묘수는 없었습니다. 가이드라인은 현장의 목소리를 들으며 업데이트 해나가야민 생명력과 효용성을 갖습니다. 대한민국 공공 서비스의 디지털 경험이 더 나아지는 시작점이라는 생각으로 참여했고 계속 의견을 더 할 생각입니다.

http://uiux.egovframe.go.kr

제가 자문위원으로 참여한 대한민국 디지털정부 UI/UX 가이드라인이 공개되었습니다. 행안부 홈페이지에서도 정책자료 &gt; 참고자료에서 보실 수 있습니다. 완벽하지 않지만 공공 서비스에서 제공하는 사용자 경험이 더 나아지는 시작점이 될 거라는 마음으로 참여했습니다 ☺️ 기업에서 디자인 가이드라인을 만들 때마다 생각의 속도가 더뎌지는 지점들이 있습니다. 비즈니스에 적합한가, 달라지는 기술요소를 반영할 여력이 있는가, 이해관계자들이 바로 사용할 수 있는가. 묘수는 없었습니다. 가이드라인은 현장의 목소리를 들으며 업데이트 해나가야민 생명력과 효용성을 갖습니다. 대한민국 공공 서비스의 디지털 경험이 더 나아지는 시작점이라는 생각으로 참여했고 계속 의견을 더 할 생각입니다. http://uiux.egovframe.go.kr

egovframe.go.kr

⟪대한민국 디지털정부 UI/UX 가이드라인⟫

워우 이거에 참여하셨던 것이였군요! 퀄리티가 좋아요!

Today, we're announcing beta for Code Connect, a feature built to improve design system adoption by making code more accessible and useful for developers.

The Right Code for Your Design System | Figma Blog

---------------
개요
The right code for your design system
피그마가 디자인-개발에 프레임웍 효율 향상을 위해 디자인 영역의 더 많은 부분을 베리어블과 스타일로 정의하고 변경할 수 있게 해주고, 조금 더 코드에 가깝게 변환할 수 있는 수단을 만들었다고 발표했습니다.

Code Connect는 Dev-mode에서 대규모 디자인 시스템에 따라 커스텀된 코드 스니펫을 더 효율적으로 만들어주는 도구입니다. 기존에 사용하는 코드를 붙여 넣으면, 피그마에서 사용하기 편리한 상태로 변경해 준다고 합니다. 개발자가 아니어서 정확한 표현은 어렵네요. 곧 베타가 시작되어 피그마에서 볼 수 있습니다.

---------------
요약
Code Connect는 개발자가 디자인 시스템의 코드에 더 쉽게 접근하고 활용할 수 있도록 하는 새로운 도구입니다.

Code Connect를 사용하면 개발자들은 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있어서 개발이 더욱 효율적으로 이뤄집니다. 조직은 디자인 시스템을 보다 일관되게 사용할 수 있게 되며 중복된 구성 요소의 생성과 유지 관리 비용이 줄어듭니다.

Code Connect는 Figma의 디자인 도구에 코드 기능을 도입하여 디자인과 코드 사이의 간극을 줄이는 데 목적이 있습니다. 현재는 Figma Organization 및 Enterprise 요금제의 베타 버전으로 제공되며 일반 출시는 올해 말에 예정되어 있습니다.

---------------
번역
오늘 우리는 개발자가 코드에 더 쉽게 접근하고 유용하게 사용할 수 있도록 하여 디자인 시스템 채택을 개선하기 위해 구축된 기능인 Code Connect의 베타 버전을 발표합니다.

디자인 시스템은 디자인과 코드 사이의 격차를 해소하는 가장 강력한 도구 중 하나입니다. 공유 언어를 생성함으로써 디자이너와 개발자는 각자의 워크플로우에서 효율적으로 협업할 수 있습니다. 우리 는 작년에 출시한 자동 레이아웃 , 변수 , 구성 요소 소품 및 개발 모드 와 같은 기능을 통해 디자인 시스템을 코드에 더 가깝게 만들기 위해 열심히 노력해 왔습니다 .

이러한 발전에도 불구하고 채택이라는 한 가지 주요 과제는 여전히 남아 있습니다. 엔지니어링 관리자로서 저는 이 사실을 직접 목격했습니다. 고객과 대화할 때 우리는 "디자인 시스템을 구축했지만 잠재력을 최대한 활용하지 못하고 있습니다."라는 같은 말을 계속해서 듣습니다. 개발자는 디자인 시스템의 일부를 사용할 수 있지만 포함된 모든 것을 인식하지 못하는 경우가 많습니다. 그리고 이를 사용할 때 시스템의 의도된 지침에 맞지 않는 방식으로 구성 요소나 패턴을 의도치 않게 오용할 수 있습니다. 디자인 시스템의 성공은 이를 사용하는 것뿐만 아니라 올바르고 일관되게 사용하는 사람들에 달려 있기 때문에 이는 매우 중요한 문제입니다.
이것이 개발자가 코드에 더 쉽게 접근하고 유용하게 만들어 조직이 디자인 시스템 채택을 촉진하는 데 도움이 되는 새로운 도구인 Code Connect를 소개하게 된 것을 매우 기쁘게 생각합니다. Code Connect를 사용하면 개발자 모드에 표시되는 코드 조각을 사용자 정의할 수 있으므로 개발자는 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있습니다. 그 결과 개발이 더 빠르고 효율적이며 조직 전체에서 디자인 시스템의 채택률이 높아지고 중복된 일회성 구성 요소의 생성 및 유지 관리가 줄어듭니다.

이것이 개발자가 코드에 더 쉽게 접근하고 유용하게 만들어 조직이 디자인 시스템 채택을 촉진하는 데 도움이 되는 새로운 도구인 Code Connect를 소개하게 된 것을 매우 기쁘게 생각합니다. Code Connect를 사용하면 개발자 모드에 표시되는 코드 조각을 사용자 정의할 수 있으므로 개발자는 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있습니다. 그 결과 개발이 더 빠르고 효율적이며 조직 전체에서 디자인 시스템의 채택률이 높아지고 중복된 일회성 구성 요소의 생성 및 유지 관리가 줄어듭니다.

대규모 디자인 시스템 채택은 우리가 오랫동안 생각해 왔던 것입니다. 채택의 장벽은 단순히 개별 워크플로나 선호도의 문제가 아닙니다. 이는 디자인과 코드 사이의 더 넓은 단절을 보여주는 증거입니다. CEO Dylan Field가 설명 했듯이 디자인과 코드는 전통적으로 서로 다른 세계를 차지했습니다. “디자인과 코드 사이에는 자연스러운 긴장이 있습니다. 디자인의 세계에서 초점은 무엇을 구축할지 결정하는 것입니다. 코드의 세계에서 초점은 그것을 구축하는 것입니다. 실제로 그들은 제품에 생명을 불어넣기 위해 노력하는 파트너입니다.”

디자이너와 개발자는 서로 다른 제약 조건과 고려 사항을 바탕으로 서로 다른 도구를 사용하여 작업합니다. 디자이너는 창의성과 탐구를 위해 최적화하고, 개발자는 구조와 유지 관리 가능성을 위해 최적화합니다. Figma에서는 디자이너와 개발자가 자유 형식 탐색과 구조화되고 체계적인 구현 사이를 원활하게 이동할 수 있는 세상을 상상합니다. Code Connect는 그 방향으로 나아가는 또 다른 단계입니다.

Code Connect는 코드의 힘을 디자인 도구에 도입하여 이러한 격차를 해소하는 것을 목표로 합니다. 내부적으로 Code Connect는 JavaScript 및 TypeScript 프로젝트용 npm 과 SwiftUI 프로젝트용 Swift Package Manager를 통해 제공되는 유틸리티입니다. 이를 통해 개발자는 작업 중인 플랫폼에 관계없이 자신의 프로젝트에 Code Connect를 쉽게 설치하고 사용할 수 있습니다. 곧 더 많은 플랫폼 지원이 예정되어 있는 Code Connect는 개발자가 있는 곳에서 기존 도구 및 작업 흐름에 원활하게 통합되는 것을 목표로 합니다.
패키지 및 설정 지침은 GitHub에 있으며 개발자는 간단한 명령줄 인터페이스를 통해 설치할 수 있습니다. 이는 개발자가 이미 알고 사용하는 도구 및 워크플로에 매핑됩니다.

Code Connect를 설치하면 디자인 시스템 팀은 상황에 맞게 모형과 연결된 디자인 시스템 사용 방법에 대한 모범 사례와 문서를 표면화하고 배포할 수 있습니다. 따라서 개발자가 모형을 클릭할 때 디자인 시스템에서 모형을 구축하는 방법을 파악하기 위해 수많은 문서와 코드를 검색할 필요가 없습니다. 대신, 이를 클릭하면 디자인 시스템 팀에서 게시한 필요한 승인되고 유지 관리되는 코드 샘플을 얻을 수 있습니다.

여기에는 큰 이점이 있습니다. 개발자가 구성 요소를 다시 작성하지 않으므로 유지 관리할 코드가 줄어듭니다. 처음부터 구성 요소를 만드는 대신 이미 있는 것을 사용함으로써 개발자는 보다 효율적이고 효과적으로 작업할 수 있습니다. 그리고 디자인 시스템을 더 잘 준수하면 애플리케이션 전반에 걸쳐 접근성과 일관성을 더 쉽게 향상시킬 수 있습니다.

개발자가 Code Connect를 사용하면 새 코드가 생성되지 않습니다. 그들은 디자인 시스템 팀이 게시한 승인되고 유지 관리되는 코드 샘플과 문서에 액세스하고 있습니다. 이는 오류나 불일치를 초래할 수 있는 자동화된 코드 생성에 의존하지 않고 디자인 시스템 지침의 일관성과 준수를 보장하는 데 도움이 됩니다. Code Connect는 디자인 시스템에서 기존 코드와 문서를 표면화하고 배포하는 것입니다. 디자인 시스템을 저항이 가장 적은 경로로 만듦으로써 채택을 장려하고 모든 사람이 동일한 소스에서 작업하도록 할 수 있습니다.

이는 팀 규모가 커질 때 특히 중요합니다. 소규모 팀인 경우 모든 사람이 동일한 정보를 공유하는 것이 쉽습니다. 그러나 성장함에 따라 사일로가 형성되기 시작합니다. 디자이너와 개발자는 분리되어 작업하기 시작하고 디자인 시스템은 공유 표준이라기보다는 느슨한 지침 집합에 가깝습니다. Code Connect를 사용하면 팀의 규모에 관계없이 팀이 쉽게 동기화를 유지할 수 있기를 원합니다.

Code Connect는 시작에 불과합니다. 앞으로 Code Connect는 설계 및 개발 워크플로를 더욱 통합하기 위한 많은 흥미로운 가능성을 열어줍니다. 예를 들어 코드와 디자인 모두에서 디자인 시스템 사용에 대한 자동 감사를 활성화하여 디자인과 코드가 동기화되지 않은 영역을 식별할 수 있습니다. 또한 디자인 시스템 사용에 대한 분석 및 통찰력을 제공하여 팀이 시스템이 실제로 어떻게 사용되는지 더 잘 이해할 수 있는 기회를 열어줄 수도 있습니다. 또 다른 가능성은 구성 요소 업데이트에 대한 설계와 엔지니어링 간의 승인 흐름을 활성화하여 디자인 시스템의 변경 사항을 팀 전체에서 적절하게 검토하고 조정할 수 있다는 것입니다.

이러한 특정 기능은 현재 로드맵에 없지만 디자인과 코드를 연결하면 미래 탐색과 혁신을 위한 완전히 새로운 기회의 세계가 열립니다. 우리의 비전은 단순한 디자인 시스템이나 구성 요소를 넘어 디자인과 코드 사이에 더욱 깊은 연결을 만드는 것입니다. 변수, 아이콘, 타이포그래피 등 디자인과 관련된 모든 것들이 연결되는 미래를 상상해 보세요. Code Connect는 그 기반을 다지고 있으며, 이 기술이 앞으로 더욱 강력한 워크플로를 지원하도록 어떻게 발전할지 기대됩니다.

Code Connect는 Figma Organization 및 Enterprise 요금제 에 대해 베타 버전으로 제공될 예정 이며 일반 출시는 올해 말에 예정되어 있습니다. 베타는 아이디어를 제시하고, 테스트하고, 커뮤니티로부터 피드백을 받는 것입니다. 우리는 Android 및 웹 프레임워크와 같은 추가 플랫폼에 대한 지원을 통해 구성 요소 플레이그라운드를 포함하여 Code Connect를 Figma 워크플로에 완전히 통합할 계획입니다.

https://www.figma.com/blog/introducing-code-connect/

--------------- 개요 The right code for your design&nbsp;system 피그마가 디자인-개발에 프레임웍 효율 향상을 위해 디자인 영역의 더 많은 부분을 베리어블과 스타일로 정의하고 변경할 수 있게 해주고, 조금 더 코드에 가깝게 변환할 수 있는 수단을 만들었다고 발표했습니다. Code Connect는 Dev-mode에서 대규모 디자인 시스템에 따라 커스텀된 코드 스니펫을 더 효율적으로 만들어주는 도구입니다. 기존에 사용하는 코드를 붙여 넣으면, 피그마에서 사용하기 편리한 상태로 변경해 준다고 합니다. 개발자가 아니어서 정확한 표현은 어렵네요. 곧 베타가 시작되어 피그마에서 볼 수 있습니다. --------------- 요약 Code Connect는 개발자가 디자인 시스템의 코드에 더 쉽게 접근하고 활용할 수 있도록 하는 새로운 도구입니다. Code Connect를 사용하면 개발자들은 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있어서 개발이 더욱 효율적으로 이뤄집니다. 조직은 디자인 시스템을 보다 일관되게 사용할 수 있게 되며 중복된 구성 요소의 생성과 유지 관리 비용이 줄어듭니다. Code Connect는 Figma의 디자인 도구에 코드 기능을 도입하여 디자인과 코드 사이의 간극을 줄이는 데 목적이 있습니다. 현재는 Figma Organization 및 Enterprise 요금제의 베타 버전으로 제공되며 일반 출시는 올해 말에 예정되어 있습니다. --------------- 번역 오늘 우리는 개발자가 코드에 더 쉽게 접근하고 유용하게 사용할 수 있도록 하여 디자인 시스템 채택을 개선하기 위해 구축된 기능인 Code Connect의 베타 버전을 발표합니다. 디자인 시스템은 디자인과 코드 사이의 격차를 해소하는 가장 강력한 도구 중 하나입니다. 공유 언어를 생성함으로써 디자이너와 개발자는 각자의 워크플로우에서 효율적으로 협업할 수 있습니다. 우리 는 작년에 출시한 자동 레이아웃 , 변수 , 구성 요소 소품 및 개발 모드 와 같은 기능을 통해 디자인 시스템을 코드에 더 가깝게 만들기 위해 열심히 노력해 왔습니다 . 이러한 발전에도 불구하고 채택이라는 한 가지 주요 과제는 여전히 남아 있습니다. 엔지니어링 관리자로서 저는 이 사실을 직접 목격했습니다. 고객과 대화할 때 우리는 "디자인 시스템을 구축했지만 잠재력을 최대한 활용하지 못하고 있습니다."라는 같은 말을 계속해서 듣습니다. 개발자는 디자인 시스템의 일부를 사용할 수 있지만 포함된 모든 것을 인식하지 못하는 경우가 많습니다. 그리고 이를 사용할 때 시스템의 의도된 지침에 맞지 않는 방식으로 구성 요소나 패턴을 의도치 않게 오용할 수 있습니다. 디자인 시스템의 성공은 이를 사용하는 것뿐만 아니라 올바르고 일관되게 사용하는 사람들에 달려 있기 때문에 이는 매우 중요한 문제입니다. 이것이 개발자가 코드에 더 쉽게 접근하고 유용하게 만들어 조직이 디자인 시스템 채택을 촉진하는 데 도움이 되는 새로운 도구인 Code Connect를 소개하게 된 것을 매우 기쁘게 생각합니다. Code Connect를 사용하면 개발자 모드에 표시되는 코드 조각을 사용자 정의할 수 있으므로 개발자는 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있습니다. 그 결과 개발이 더 빠르고 효율적이며 조직 전체에서 디자인 시스템의 채택률이 높아지고 중복된 일회성 구성 요소의 생성 및 유지 관리가 줄어듭니다. 이것이 개발자가 코드에 더 쉽게 접근하고 유용하게 만들어 조직이 디자인 시스템 채택을 촉진하는 데 도움이 되는 새로운 도구인 Code Connect를 소개하게 된 것을 매우 기쁘게 생각합니다. Code Connect를 사용하면 개발자 모드에 표시되는 코드 조각을 사용자 정의할 수 있으므로 개발자는 자동 생성된 CSS 대신 실제 디자인 시스템 코드를 볼 수 있습니다. 그 결과 개발이 더 빠르고 효율적이며 조직 전체에서 디자인 시스템의 채택률이 높아지고 중복된 일회성 구성 요소의 생성 및 유지 관리가 줄어듭니다. 대규모 디자인 시스템 채택은 우리가 오랫동안 생각해 왔던 것입니다. 채택의 장벽은 단순히 개별 워크플로나 선호도의 문제가 아닙니다. 이는 디자인과 코드 사이의 더 넓은 단절을 보여주는 증거입니다. CEO Dylan Field가 설명 했듯이 디자인과 코드는 전통적으로 서로 다른 세계를 차지했습니다. “디자인과 코드 사이에는 자연스러운 긴장이 있습니다. 디자인의 세계에서 초점은 무엇을 구축할지 결정하는 것입니다. 코드의 세계에서 초점은 그것을 구축하는 것입니다. 실제로 그들은 제품에 생명을 불어넣기 위해 노력하는 파트너입니다.” 디자이너와 개발자는 서로 다른 제약 조건과 고려 사항을 바탕으로 서로 다른 도구를 사용하여 작업합니다. 디자이너는 창의성과 탐구를 위해 최적화하고, 개발자는 구조와 유지 관리 가능성을 위해 최적화합니다. Figma에서는 디자이너와 개발자가 자유 형식 탐색과 구조화되고 체계적인 구현 사이를 원활하게 이동할 수 있는 세상을 상상합니다. Code Connect는 그 방향으로 나아가는 또 다른 단계입니다. Code Connect는 코드의 힘을 디자인 도구에 도입하여 이러한 격차를 해소하는 것을 목표로 합니다. 내부적으로 Code Connect는 JavaScript 및 TypeScript 프로젝트용 npm 과 SwiftUI 프로젝트용 Swift Package Manager를 통해 제공되는 유틸리티입니다. 이를 통해 개발자는 작업 중인 플랫폼에 관계없이 자신의 프로젝트에 Code Connect를 쉽게 설치하고 사용할 수 있습니다. 곧 더 많은 플랫폼 지원이 예정되어 있는 Code Connect는 개발자가 있는 곳에서 기존 도구 및 작업 흐름에 원활하게 통합되는 것을 목표로 합니다. 패키지 및 설정 지침은 GitHub에 있으며 개발자는 간단한 명령줄 인터페이스를 통해 설치할 수 있습니다. 이는 개발자가 이미 알고 사용하는 도구 및 워크플로에 매핑됩니다. Code Connect를 설치하면 디자인 시스템 팀은 상황에 맞게 모형과 연결된 디자인 시스템 사용 방법에 대한 모범 사례와 문서를 표면화하고 배포할 수 있습니다. 따라서 개발자가 모형을 클릭할 때 디자인 시스템에서 모형을 구축하는 방법을 파악하기 위해 수많은 문서와 코드를 검색할 필요가 없습니다. 대신, 이를 클릭하면 디자인 시스템 팀에서 게시한 필요한 승인되고 유지 관리되는 코드 샘플을 얻을 수 있습니다. 여기에는 큰 이점이 있습니다. 개발자가 구성 요소를 다시 작성하지 않으므로 유지 관리할 코드가 줄어듭니다. 처음부터 구성 요소를 만드는 대신 이미 있는 것을 사용함으로써 개발자는 보다 효율적이고 효과적으로 작업할 수 있습니다. 그리고 디자인 시스템을 더 잘 준수하면 애플리케이션 전반에 걸쳐 접근성과 일관성을 더 쉽게 향상시킬 수 있습니다. 개발자가 Code Connect를 사용하면 새 코드가 생성되지 않습니다. 그들은 디자인 시스템 팀이 게시한 승인되고 유지 관리되는 코드 샘플과 문서에 액세스하고 있습니다. 이는 오류나 불일치를 초래할 수 있는 자동화된 코드 생성에 의존하지 않고 디자인 시스템 지침의 일관성과 준수를 보장하는 데 도움이 됩니다. Code Connect는 디자인 시스템에서 기존 코드와 문서를 표면화하고 배포하는 것입니다. 디자인 시스템을 저항이 가장 적은 경로로 만듦으로써 채택을 장려하고 모든 사람이 동일한 소스에서 작업하도록 할 수 있습니다. 이는 팀 규모가 커질 때 특히 중요합니다. 소규모 팀인 경우 모든 사람이 동일한 정보를 공유하는 것이 쉽습니다. 그러나 성장함에 따라 사일로가 형성되기 시작합니다. 디자이너와 개발자는 분리되어 작업하기 시작하고 디자인 시스템은 공유 표준이라기보다는 느슨한 지침 집합에 가깝습니다. Code Connect를 사용하면 팀의 규모에 관계없이 팀이 쉽게 동기화를 유지할 수 있기를 원합니다. Code Connect는 시작에 불과합니다. 앞으로 Code Connect는 설계 및 개발 워크플로를 더욱 통합하기 위한 많은 흥미로운 가능성을 열어줍니다. 예를 들어 코드와 디자인 모두에서 디자인 시스템 사용에 대한 자동 감사를 활성화하여 디자인과 코드가 동기화되지 않은 영역을 식별할 수 있습니다. 또한 디자인 시스템 사용에 대한 분석 및 통찰력을 제공하여 팀이 시스템이 실제로 어떻게 사용되는지 더 잘 이해할 수 있는 기회를 열어줄 수도 있습니다. 또 다른 가능성은 구성 요소 업데이트에 대한 설계와 엔지니어링 간의 승인 흐름을 활성화하여 디자인 시스템의 변경 사항을 팀 전체에서 적절하게 검토하고 조정할 수 있다는 것입니다. 이러한 특정 기능은 현재 로드맵에 없지만 디자인과 코드를 연결하면 미래 탐색과 혁신을 위한 완전히 새로운 기회의 세계가 열립니다. 우리의 비전은 단순한 디자인 시스템이나 구성 요소를 넘어 디자인과 코드 사이에 더욱 깊은 연결을 만드는 것입니다. 변수, 아이콘, 타이포그래피 등 디자인과 관련된 모든 것들이 연결되는 미래를 상상해 보세요. Code Connect는 그 기반을 다지고 있으며, 이 기술이 앞으로 더욱 강력한 워크플로를 지원하도록 어떻게 발전할지 기대됩니다. Code Connect는 Figma Organization 및 Enterprise 요금제 에 대해 베타 버전으로 제공될 예정 이며 일반 출시는 올해 말에 예정되어 있습니다. 베타는 아이디어를 제시하고, 테스트하고, 커뮤니티로부터 피드백을 받는 것입니다. 우리는 Android 및 웹 프레임워크와 같은 추가 플랫폼에 대한 지원을 통해 구성 요소 플레이그라운드를 포함하여 Code Connect를 Figma 워크플로에 완전히 통합할 계획입니다. https://www.figma.com/blog/introducing-code-connect/

Figma

Figma가 Code Connet를 발표했습니다.

행정안전부에서 디지털 정부 서비스의 사용자 편의성을 위한 '디지털 정부서비스 UI/UX 가이드라인'을 배포했습니다. 행정/공공기관에서 웹사이트를 새로 만들 때 참고할 수 있는 PDF 파일과 웹사이트를 공개했습니다. 한국의 행정이라고 하면 세계적으로도 알아주죠. 하지만 디지털 서비스는 아직 개선할 점이 많았습니다. 정부는 더 나은 서비스를 제공하기 위해...

KRDS: 대한민국 정부 디자인 시스템

행정안전부에서 디지털 정부 서비스의 사용자 편의성을 위한 ‘디지털 정부서비스 UI/UX 가이드라인’을 배포했습니다. 행정/공공기관에서 웹사이트를 새로 만들 때 참고할 수 있는 PDF 파일과 웹사이트를 공개했습니다.

한국의 행정이라고 하면 세계적으로도 알아주죠. 하지만 디지털 서비스는 아직 개선할 점이 많았습니다. 정부는 더 나은 서비스를 제공하기 위해 2023년 전자정부 서비스 이용 실태조사를 실시했습니다.

주로 받은 피드백은 동일한 행동을 반복적으로 요청하고 직관적이지 않은 설명과 일관되지 않은 표현 때문에 사용하기 어렵다는 것이었습니다. 정부는 부서가 각자 최적화하는 것에 한계를 느끼고 범정부적 차원에서 효율을 위해 가이드라인을 개발했습니다.

더 자세한 내용은 링크에서 확인하세요.
https://designcompass.org/2024/04/17/krds/

#디자인시스템 #대한민국 #행정안전부

행정안전부에서 디지털 정부 서비스의 사용자 편의성을 위한 ‘디지털 정부서비스 UI/UX 가이드라인’을 배포했습니다. 행정/공공기관에서 웹사이트를 새로 만들 때 참고할 수 있는 PDF 파일과 웹사이트를 공개했습니다. 한국의 행정이라고 하면 세계적으로도 알아주죠. 하지만 디지털 서비스는 아직 개선할 점이 많았습니다. 정부는 더 나은 서비스를 제공하기 위해 2023년 전자정부 서비스 이용 실태조사를 실시했습니다. 주로 받은 피드백은 동일한 행동을 반복적으로 요청하고 직관적이지 않은 설명과 일관되지 않은 표현 때문에 사용하기 어렵다는 것이었습니다. 정부는 부서가 각자 최적화하는 것에 한계를 느끼고 범정부적 차원에서 효율을 위해 가이드라인을 개발했습니다. 더 자세한 내용은 링크에서 확인하세요.https://designcompass.org/2024/04/17/krds/ #디자인시스템 #대한민국 #행정안전부

60세 이상 감독은 10% 감점, 전작 망했으면 가점 수익률 176%의 비결 은행권 유일 기업은행 문화투자부 천만영화 투자 비법을 말하다 500만명도 언감생심이라던 예상을 깨고 천만영화에 등극한 파묘의 뒤에서 크게 웃은 이들이 있다. 제작사도 아닌데 잘했다는 격려를 잇

60세 이상 감독은 10% 감점, 전작 망했으면 가점... 수익률 176%의 비결

극한직업부터 파묘까지, 정량화한 객관적 자료에 기반하여 판단했습니다

[아티클 3문장 요약📑]

1️⃣ IBK기업은행의 문화콘텐츠금융부는, 은행권 내 유일무이한 문화 콘텐츠 전담 부서로, 최근 파묘에 10억 원을 투자하여 수익률 100%를 넘긴 것을 비롯하여, 명량, 신과함께, 국제시장, 극한직업 등 역대 천만 영화 32편 중 11편을 미리 알아보고 투자한 것으로 유명합니다.

2️⃣ 기업은행의 영화 투자 성공 비결은 모든 정성적인 요소를 최대한 정량화한 객관적 자료에 기반하여 결정한다는 것으로, 1단계에서 검토 대상을 결정하고, 2단계에서 무려 16가지 요소 별로 점수를 매긴다고 합니다.

3️⃣ 특히 이들의 노하우가 빛나는 건 최종 조정 단계로, 60대 감독인 경우 주위 사람들이 이견을 내기 어려워 하므로 10% 감점하고, 반대로 30,40대 감독의 데뷔작이면 젊은 의욕으로 만들어 성공 가능성이 높아진다고 보아 10% 가점을 하는 등 독특한 기준을 적용하는데 적중 확률이 높다고 합니다.

💡기묘한 관점➕
콘텐츠 트렌드를 계속 반영하는 것은 물론, 감독의 전작의 성공 여부가 끼치는 영향까지 판단하는 등 다방면으로 정량화한 점수를 부여하는 점이 매우 흥미로웠는데요. 이를 통해 어떤 과업을 수행 할 때, 영화의 좋은 시나리오처럼 준비된 조건이나 상황의 유불리도 중요하지만, 이를 수행하는 사람의 태도나 몰입도에 따라 결국 최종적으로 결과가 달라질 수 있다는 점을 다시 한번 깨달을 수 있었습니다.

🥤트렌드라이트 구독하기
https://bit.ly/3iSbx4e

극한직업부터 파묘까지, 정량화한 객관적 자료에 기반하여 판단했습니다 [아티클 3문장 요약📑] 1️⃣ IBK기업은행의 문화콘텐츠금융부는, 은행권 내 유일무이한 문화 콘텐츠 전담 부서로, 최근 파묘에 10억 원을 투자하여 수익률 100%를 넘긴 것을 비롯하여, 명량, 신과함께, 국제시장, 극한직업 등 역대 천만 영화 32편 중 11편을 미리 알아보고 투자한 것으로 유명합니다. 2️⃣ 기업은행의 영화 투자 성공 비결은 모든 정성적인 요소를 최대한 정량화한 객관적 자료에 기반하여 결정한다는 것으로, 1단계에서 검토 대상을 결정하고, 2단계에서 무려 16가지 요소 별로 점수를 매긴다고 합니다. 3️⃣ 특히 이들의 노하우가 빛나는 건 최종 조정 단계로, 60대 감독인 경우 주위 사람들이 이견을 내기 어려워 하므로 10% 감점하고, 반대로 30,40대 감독의 데뷔작이면 젊은 의욕으로 만들어 성공 가능성이 높아진다고 보아 10% 가점을 하는 등 독특한 기준을 적용하는데 적중 확률이 높다고 합니다. 💡기묘한 관점➕콘텐츠 트렌드를 계속 반영하는 것은 물론, 감독의 전작의 성공 여부가 끼치는 영향까지 판단하는 등 다방면으로 정량화한 점수를 부여하는 점이 매우 흥미로웠는데요. 이를 통해 어떤 과업을 수행 할 때, 영화의 좋은 시나리오처럼 준비된 조건이나 상황의 유불리도 중요하지만, 이를 수행하는 사람의 태도나 몰입도에 따라 결국 최종적으로 결과가 달라질 수 있다는 점을 다시 한번 깨달을 수 있었습니다. 🥤트렌드라이트 구독하기https://bit.ly/3iSbx4e

조선일보

🎬기업은행 문화투자부가 천만영화를 알아보는 법

Netflix는 Java, RxJava 및 Spring Boot를 활용해 마이크로서비스 아키텍처를 발전시켰으며, GraphQL Federation으로의 전환을 통해 더욱 발전했다. 이 글에서는 Netflix의 아키텍처 변화와 Java 사용 변천사를 설명한다.

Netflix의 Java 사용 변천사 (번역)

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰

현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃

팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만,
적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다
는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다.

Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다.

전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr

📌 목차
 1. Groovy 시대 with BFF(Backend For Frontend)
 2. RxJava와 리액티브 프로그래밍 사용
 3. GraphQL Federation으로 전환
 4. Netflix가 사용하는 Java 버전
 5. Netflix가 사용하는 Spring Boot

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰 현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃 팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만, <code >적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다</code>는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다. Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다. 전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr 📌 목차<ol ><li>Groovy 시대 with BFF(Backend For Frontend)</li><li>RxJava와 리액티브 프로그래밍 사용</li><li>GraphQL Federation으로 전환</li><li>Netflix가 사용하는 Java 버전</li><li>Netflix가 사용하는 Spring Boot</li></ol>

1nteger 🏄🏻‍♂️

Mobile development is a dynamic field that evolves rapidly, demanding developers to be proactive in keeping up with the latest trends, tools, and technologies. As the app landscape continuously...

How to Stay Up-to-Date as a Mobile Developer

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다.

 1.  개발자 블로그 및 뉴스레터 구독하기
     iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다.
     
     
 2.  소셜 미디어 및 온라인 커뮤니티에 참여하기
     트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...)
     
     
 3.  컨퍼런스 및 모임 참석
     온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요!
     
     
 4.  온라인 강좌를 통한 지속적 학습
     코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다!
     
     
 5.  출퇴근 시간에 팟캐스트 듣기
     통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠.
     
     
 6.  GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기
     GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다.
     
     
 7.  베타 릴리즈 사용해 보기
     얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠.
     
     
 8.  업계 보고서 읽기
     보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다.
     
     
 9.  개인적인 개발 계획 수립
     커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다.
     
     
 10. 지속적인 네트워킹
     네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다.
     
     본문에 대한 원글은 아래 링크에서 볼 수 있습니다.
     https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다. <ol ><li>개발자 블로그 및 뉴스레터 구독하기iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다. </li><li>소셜 미디어 및 온라인 커뮤니티에 참여하기트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...) </li><li>컨퍼런스 및 모임 참석온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요! </li><li>온라인 강좌를 통한 지속적 학습코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다! </li><li>출퇴근 시간에 팟캐스트 듣기통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠. </li><li>GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다. </li><li>베타 릴리즈 사용해 보기 얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠. </li><li>업계 보고서 읽기보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다. </li><li>개인적인 개발 계획 수립커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다. </li><li>지속적인 네트워킹네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다. 본문에 대한 원글은 아래 링크에서 볼 수 있습니다.https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc</li></ol>

Medium

개발자가 실생활에서 실천할 수 있는 스터디 방법 소개 🔑

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다.

내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다.

그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다.

다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다.

결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다. 내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다. 그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다. 다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다. 결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

좋은 개발자가 알아야하는 9가지 포인트들 - 2. 학습 능력 키우

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음.

사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async.

자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음. 사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async. 자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

📝 메타의 스레드, 모놀리틱 아키텍처 사용

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌

자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂

📝 블로그: https://bun.sh/blog/bun-v1.1
📺 영상: https://youtu.be/yXTFOeGly9o

많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯

Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다.

📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌 자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂 📝 블로그: https://bun.sh/blog/bun-v1.1📺 영상: https://youtu.be/yXTFOeGly9o 많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯 Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다. 📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

🥟 Bun v1.1 출시 소식

디자인 시스템, 코드를 넘어서

https://so-so.dev/react/design-system-beyond-code/

같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

https://so-so.dev/react/design-system-beyond-code/ 같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

So-so

디자인시스템 3번만든 이야기

HashMap is Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is...

Barclays Java Spring-Boot Micro-service Interview Question with answer 2024

Finally 블록에서 예외가 발생하면 어떻게 되나요?
자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다. 
 
[Try-Catch 블록의 예외]
 * 정상적인 플로우가 중지됩니다.
 * 예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.
 * catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.
[Finally 블록의 예외]
 * 원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.
 * finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.
[키 포인트]
 * finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.
 * finally 블록의 예외는 원래의 예외를 억제합니다.
 * finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.
[Finally 블록의 쓰임새]
 * 리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.
 * 예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.
 
자바의 다이아몬드 문제란 무엇인가요?
"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다.

 1. 자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다. 
 2. 자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.
interface InterfaceA {
    default void display() {
        System.out.println("Inside InterfaceA");
    }
}

interface InterfaceB {
    default void display() {
        System.out.println("Inside InterfaceB");
    }
}

class MyClass implements InterfaceA, InterfaceB {
    // Here, we must provide our own implementation of display to resolve the ambiguity.
    @Override
    public void display() {
        InterfaceA.super.display(); // calling InterfaceA's default implementation
        InterfaceB.super.display(); // calling InterfaceB's default implementation
    }
}

어떻게 해결할 수 있을까요?

1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        System.out.println("Hello world");
    }
}

2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다. 
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        InterfaceA.super.display(); // or InterfaceB.super.display()
        // Additional logic if needed
    }
}

 
Multilevel 상속이란 무엇인가요?
Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.
 
자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.
 
String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?
(번역/원문 참고)
 
메서드 오버라이딩과 오버로딩은 무엇인가요?
[메서드 오버로딩]
 * 단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.
 * 메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.
class Calculator {
  public int add(int a, int b) {
    return a + b;
  }

  public double add(double a, double b) {
    return a + b;
  }
}

[메서드 오버라이딩]
 * 상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.
 * 메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.
class Animal {
  public void makeSound() {
    System.out.println("Generic animal sound");
  }
}

class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

 
예외 클래스의 계층구조는 무엇인가요?
Arraylist와 Linkedlist의 차이는 무엇인가요?
Set과 Arraylist의 차이는 무엇인가요?
(번역/원문 참고)
 
번역: [https://ducktopia.tistory.com/119]
원문:

Finally 블록에서 예외가 발생하면 어떻게 되나요?자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다.&nbsp;&nbsp;[Try-Catch 블록의 예외]<ul ><li>정상적인 플로우가 중지됩니다.</li><li>예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.</li><li>catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.</li></ul>[Finally 블록의 예외]<ul ><li>원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.</li><li>finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.</li></ul>[키 포인트]<ul ><li>finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.</li><li>finally 블록의 예외는 원래의 예외를 억제합니다.</li><li>finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.</li></ul>[Finally 블록의 쓰임새]<ul ><li>리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.</li><li>예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.</li></ul>&nbsp;자바의 다이아몬드 문제란 무엇인가요?"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다. <ol ><li>자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다.&nbsp;</li><li>자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.</li></ol><pre ><code class="language-java">interface InterfaceA {
 default void display() {
 System.out.println("Inside InterfaceA");
 }
}

interface InterfaceB {
 default void display() {
 System.out.println("Inside InterfaceB");
 }
}

class MyClass implements InterfaceA, InterfaceB {
 // Here, we must provide our own implementation of display to resolve the ambiguity.
 @Override
 public void display() {
 InterfaceA.super.display(); // calling InterfaceA's default implementation
 InterfaceB.super.display(); // calling InterfaceB's default implementation
 }
}</code></pre>어떻게 해결할 수 있을까요? 1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 System.out.println("Hello world");
 }
}</code></pre>2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다.&nbsp;<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 InterfaceA.super.display(); // or InterfaceB.super.display()
 // Additional logic if needed
 }
}</code></pre>&nbsp;Multilevel 상속이란 무엇인가요?Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.&nbsp;자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.&nbsp;String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?(번역/원문 참고)&nbsp;메서드 오버라이딩과 오버로딩은 무엇인가요?[메서드 오버로딩]<ul ><li>단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.</li><li>메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.</li></ul><pre ><code class="language-java">class Calculator {
 public int add(int a, int b) {
 return a + b;
 }

 public double add(double a, double b) {
 return a + b;
 }
}</code></pre>[메서드 오버라이딩]<ul ><li>상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.</li><li>메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.</li></ul><pre ><code class="language-java">class Animal {
 public void makeSound() {
 System.out.println("Generic animal sound");
 }
}

class Dog extends Animal {
 @Override
 public void makeSound() {
 System.out.println("Woof!");
 }
}</code></pre>&nbsp;예외 클래스의 계층구조는 무엇인가요?Arraylist와 Linkedlist의 차이는 무엇인가요?Set과 Arraylist의 차이는 무엇인가요?(번역/원문 참고)&nbsp;번역: [https://ducktopia.tistory.com/119]원문:

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 

Learn to become an Data Analyst using this roadmap. Community driven, articles, resources, guides, interview questions, quizzes for modern backend development.

Data Analyst Roadmap

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?
최근 데이터분석가의 로드맵도 업데이트되어 공유합니다!

사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요!

https://roadmap.sh/data-analyst

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?최근 데이터분석가의 로드맵도 업데이트되어 공유합니다! 사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요! https://roadmap.sh/data-analyst

roadmap.sh

데이터분석가 로드맵 🤓

1. 감정은 전염되기 때문에 매우 중요하다.

2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다.

3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다.

4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다.

5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다.

6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다.

#권력을경영하는7가지원칙

1. 감정은 전염되기 때문에 매우 중요하다. 2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다. 3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다. 4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다. 5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다. 6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다. #권력을경영하는7가지원칙

< 리더의 자신감은 전염된다 >

Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started. Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are...

What I Wish Someone Had Told Me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다.

2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다.

3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요.

4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다)

5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과)

6. 커뮤니케이션은 명확하고 깔끔하게 하세요.

7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요.

8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다)

9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요!

10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다.

11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요)

12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다)

13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다.

14. 스케일은 급부상하고 있는 신흥 자산입니다.

15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요.

16. 쓰러져도 다시 일어나 계속 나아가세요.

17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다.

- 샘 알트만

https://blog.samaltman.com/what-i-wish-someone-had-told-me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다. 2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다. 3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요. 4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다) 5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과) 6. 커뮤니케이션은 명확하고 깔끔하게 하세요. 7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요. 8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다) 9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요! 10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다. 11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요) 12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다) 13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다. 14. 스케일은 급부상하고 있는 신흥 자산입니다. 15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요. 16. 쓰러져도 다시 일어나 계속 나아가세요. 17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다. - 샘 알트만 https://blog.samaltman.com/what-i-wish-someone-had-told-me

Sam Altman

창업을 하고자 하는 사람들에게 해주고 싶은 말들

Calculating ROI for Design Projects (Video)

[😶디자인 ROI 측정하기(overview)]
투자를 받을 때나 새로운 프로젝트를 시작해야 하는 단계에서, 디자인이 어떤 이익, 비용 절감 등을 해낼 수 있는지 설득해야 하는데, 그때 ROI를 측정해서 근거를 만드는 방법에 대한 영상.

Nielsen Norman Group

그래픽 디자이너

미니니

프로덕트 디자이너

정우영

Product Designer

Suryeon Kim

건강한 문화를 바탕으로 많은 사람들이 유용하게 쓸 수 있는 제품과 서비스를 만들고 싶습니다.
#ProductDesign #UI/UX #0에서1만들기 #끊임없이배우기

UX writer

Editor

어려운 정보를 쉽게 가공하는 일에 관심이 많습니다.

김자유

어려운 정보를 쉽게 가공하는 일에 관심이 많습니다. 긴 글은 브런치에서 쓰고 있어요. 커리어리 메시지는 답변이 어려워요. 
제안/문의는 메일로 주세요. linakim0102@naver.com

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필