최근에 흥미로운 개발 용어를 알게 되었는데요. 바로 '버스팩터(Bus Factor)' 입니다. 버스팩터란 소프트웨어 개발 업계에서 프로젝트의 지속가능성과 리스크를 측정하는 지표인데요. 이 용어는 "만약 핵심 개발자가 갑자기 버스에 치여 프로젝트를 떠나게 된다면 어떻게 될까?"라는 다소 극단적인 가정에서 유래했습니다.

버스팩터는 아래와 같은 특성이 있습니다.
 1. 낮은 버스팩터 (1~2 명):
    * 프로젝트가 높은 리스크에 노출됨
    * 소수의 핵심 인력에 과도하게 의존
    * 지식 편중으로 인한 병목 현상 발생 가능
 2. 높은 버스팩터:
    * 프로젝트의 지속가능성과 안정성 향상
    * 지식의 균형 있는 분배
    * 팀 전체의 역량 강화

따라서 버스팩터가 너무 낮다면 아래와 같은 개선 전략을 고려해 볼 수 있습니다.
 1. 지식 공유 강화:
    * 정기적인 기술 공유 세션 개최
    * 내부 위키나 문서화 시스템 구축
 2. 페어 프로그래밍 도입:
    * 두 명의 개발자가 한 작업을 공동으로 수행
    * 실시간 코드 리뷰와 지식 전파 효과
 3. 교차 훈련(Cross-training):
    * 팀원들이 서로 다른 영역의 업무를 학습하고 경험
    * 다기능 팀(Cross-functional team) 구성
 4. 문서화 개선:
    * 코드, 아키텍처, 프로세스에 대한 상세 문서 작성
    * 신규 입사자를 위한 온보딩 문서 준비

버스팩터를 개선하기 위한 노력은 단기적으로는 약간의 비용과 시간이 소요될 수 있지만, 장기적으로 볼 때 프로젝트의 안정성과 팀의 생산성을 크게 향상시킬 수 있습니다.

개발자, 프로젝트 관리자, 그리고 기술 리더들은 버스팩터의 개념을 이해하고 이를 개선하기 위한 전략을 지속적으로 실행해야 합니다. 이를 통해 더 탄력적이고 지속 가능한 소프트웨어 개발 환경을 구축할 수 있습니다.

최근에 흥미로운 개발 용어를 알게 되었는데요. 바로 '버스팩터(Bus Factor)' 입니다. 버스팩터란 소프트웨어 개발 업계에서 프로젝트의 지속가능성과 리스크를 측정하는 지표인데요. 이 용어는 "만약 핵심 개발자가 갑자기 버스에 치여 프로젝트를 떠나게 된다면 어떻게 될까?"라는 다소 극단적인 가정에서 유래했습니다. 버스팩터는 아래와 같은 특성이 있습니다.<ol ><li>낮은 버스팩터 (1~2 명):<ul ><li>프로젝트가 높은 리스크에 노출됨</li><li>소수의 핵심 인력에 과도하게 의존</li><li>지식 편중으로 인한 병목 현상 발생 가능</li></ul></li><li>높은 버스팩터:<ul ><li>프로젝트의 지속가능성과 안정성 향상</li><li>지식의 균형 있는 분배</li><li>팀 전체의 역량 강화</li></ul></li></ol> 따라서 버스팩터가 너무 낮다면 아래와 같은 개선 전략을 고려해 볼 수 있습니다.<ol ><li>지식 공유 강화:<ul ><li>정기적인 기술 공유 세션 개최</li><li>내부 위키나 문서화 시스템 구축</li></ul></li><li>페어 프로그래밍 도입:<ul ><li>두 명의 개발자가 한 작업을 공동으로 수행</li><li>실시간 코드 리뷰와 지식 전파 효과</li></ul></li><li>교차 훈련(Cross-training):<ul ><li>팀원들이 서로 다른 영역의 업무를 학습하고 경험</li><li>다기능 팀(Cross-functional team) 구성</li></ul></li><li>문서화 개선:<ul ><li>코드, 아키텍처, 프로세스에 대한 상세 문서 작성</li><li>신규 입사자를 위한 온보딩 문서 준비</li></ul></li></ol> 버스팩터를 개선하기 위한 노력은 단기적으로는 약간의 비용과 시간이 소요될 수 있지만, 장기적으로 볼 때 프로젝트의 안정성과 팀의 생산성을 크게 향상시킬 수 있습니다. 개발자, 프로젝트 관리자, 그리고 기술 리더들은 버스팩터의 개념을 이해하고 이를 개선하기 위한 전략을 지속적으로 실행해야 합니다. 이를 통해 더 탄력적이고 지속 가능한 소프트웨어 개발 환경을 구축할 수 있습니다.

핵심 개발자가 떠난다면? 버스팩터로 알아보는 프로젝트 지속가능성

"세계적인 선수들의 스승 중 60% 이상은 대부분 평균적인 실력을 가진 지도자였고, 그들은 제자에게 특별한 기술과 노하우를 전수하는데 집중하기 보다는 제자가 스스로 그 활동을 좋아하도록 만드는데 집중했다.

그렇게 되면 제자들 스스로 그 활동에 몰입하며 성장하기 위한 방법을 찾아 나선다는 것이었다."

저 문장을 볼 때마다 저는 비전공자 시절, 데이터 사이언스라는 과목을 처음 만났을 때가 생각이 납니다.

심리학과 출신의 유학생이였던 저는, 그 전에는 데이터, IT, 프로그래밍이라는 단어와는 전혀 접점이 없던 찐 문과 출신이였어요.

그랬던 제가 처음 MATH325 (Intermediate Statistics)라는 수업을 듣게 되었을 때, 그 막막함과 좌절감은 직접 경험하지 않는 이상, 누구도 알 수 없을 거에요.

약 3개월이라는 기간 동안, R이라는 프로그램을 사용해, 통계적인 실험을 설계하고 검증하는 과정을 증명하고 결과를 제출해야 했습니다.

영어도 아직 제대로 하지 못하던 제가, 그 수업을 끝까지 포기하지 않고 완수할 수 있었던 이유는 바로 아래의 3가지였어요.

1. 포기하지 않고 계속 도전하는 마음가짐
2. 주변 친구들의 지속적인 도움과 지원
3. 교수님의 열정적인 가르침과 친절한 설명

학기 말 다른 수업들에 치여,
마지막 프로젝트를 완수하지 못하고 포기하려 했던 저에게
교수님은 저에게 조용히 말씀해주셨습니다.

"물론 어렵고 시간이 많이 걸리겠지만, 난 너가 꼭 해낼거라고 믿는다"

그 후 2시간 뒤, 저는 마지막 5분을 남겨두고, 최종 프로젝트를 제출했고, A-라는 성적으로 과목을 수료하게 되었어요.

그 후로 저는 데이터 분석가의 길을 걷기로 했고, 다른 사람들에게도 데이터와 AI를 재미있고 가치있게 배울 수 있도록 돕고 있습니다.

지금까지 배운 많은 데이터 사이언스 지식들과 성과들, 그리고 많은 경험들은 단순히 숫자나 성과가 아니라, 제 주변에 있던 훌륭한 사람들에 의해 만들어졌다고 생각해요.

많은 사람들이 성과와 숫자를 중요하게 생각하겠지만,
저는 그 성과와 숫자를 만들기 위해 뒤에서 든든히 지원해준
사람을 더 믿습니다.

숫자나 성과가 아니라, 사람이 남습니다.

#데이터리차드 #숫자와성과 #사람이남는다

"세계적인 선수들의 스승 중 60% 이상은 대부분 평균적인 실력을 가진 지도자였고, 그들은 제자에게 특별한 기술과 노하우를 전수하는데 집중하기 보다는 제자가 스스로 그 활동을 좋아하도록 만드는데 집중했다. 그렇게 되면 제자들 스스로 그 활동에 몰입하며 성장하기 위한 방법을 찾아 나선다는 것이었다." 저 문장을 볼 때마다 저는 비전공자 시절, 데이터 사이언스라는 과목을 처음 만났을 때가 생각이 납니다. 심리학과 출신의 유학생이였던 저는, 그 전에는 데이터, IT, 프로그래밍이라는 단어와는 전혀 접점이 없던 찐 문과 출신이였어요. 그랬던 제가 처음 MATH325 (Intermediate Statistics)라는 수업을 듣게 되었을 때, 그 막막함과 좌절감은 직접 경험하지 않는 이상, 누구도 알 수 없을 거에요. 약 3개월이라는 기간 동안, R이라는 프로그램을 사용해, 통계적인 실험을 설계하고 검증하는 과정을 증명하고 결과를 제출해야 했습니다. 영어도 아직 제대로 하지 못하던 제가, 그 수업을 끝까지 포기하지 않고 완수할 수 있었던 이유는 바로 아래의 3가지였어요. 1. 포기하지 않고 계속 도전하는 마음가짐 2. 주변 친구들의 지속적인 도움과 지원 3. 교수님의 열정적인 가르침과 친절한 설명 학기 말 다른 수업들에 치여, 마지막 프로젝트를 완수하지 못하고 포기하려 했던 저에게 교수님은 저에게 조용히 말씀해주셨습니다. "물론 어렵고 시간이 많이 걸리겠지만, 난 너가 꼭 해낼거라고 믿는다" 그 후 2시간 뒤, 저는 마지막 5분을 남겨두고, 최종 프로젝트를 제출했고, A-라는 성적으로 과목을 수료하게 되었어요. 그 후로 저는 데이터 분석가의 길을 걷기로 했고, 다른 사람들에게도 데이터와 AI를 재미있고 가치있게 배울 수 있도록 돕고 있습니다. 지금까지 배운 많은 데이터 사이언스 지식들과 성과들, 그리고 많은 경험들은 단순히 숫자나 성과가 아니라, 제 주변에 있던 훌륭한 사람들에 의해 만들어졌다고 생각해요. 많은 사람들이 성과와 숫자를 중요하게 생각하겠지만, 저는 그 성과와 숫자를 만들기 위해 뒤에서 든든히 지원해준 사람을 더 믿습니다. 숫자나 성과가 아니라, 사람이 남습니다. #데이터리차드 #숫자와성과 #사람이남는다

숫자나 성과가 아니라, 사람이 남습니다

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

국내 개발자로서 자부심을 불어넣는 오픈소스 생태계가 있습니다. 바로 토스(Toss)가 주도하는 오픈소스 생태계 인데요.

es-hangul
이라고 하는 한글을 다루기 위한 라이브러리는 이미 1,000개가 넘는 GitHub 스타를 획득했습니다. 또한
lodash
보다 2배 더 빠른 유틸리티 라이브러리인
es-toolkit
은 이미 6,100개의 스타를 받고 국내를 넘어 세계적으로 많은 개발자들의 관심을 받고 있는데요. 이번 토스 모닥불 EP.4 영상에서는 토스에서 오픈소스 생태계를 운영하는 개발자들의 이야기를 만나볼 수 있습니다.

특히나 주목할 만한 점은, 패널로 참여한 토스의 오픈소스
suspensive
를 운영하고 계시는 분인데요. 이 개발자분은 요즘은 필수로 사용되고 있는
TanstackQuery
의 최상위 기여자입니다.
Jotai
외에도 토스 오픈소스에도 적극적으로 기여를하고 결국에는 토스에 합류하신게 참 대단하게 느껴지네요.

또한 오픈소스 생태계 구축을 통해 기술 커뮤니티에 긍정적인 영향을 미치고자 하는 토스의 노력도 대단한것 같습니다. 한국 개발 생태계의 경쟁력을 높이고, 개발자들에게 새로운 도전과 성장의 기회를 제공하는데 있어서, 토스의 이러한 행보를 응원합니다.

https://www.youtube.com/watch?v=SdBL-p597Dw

국내 개발자로서 자부심을 불어넣는 오픈소스 생태계가 있습니다. 바로 토스(Toss)가 주도하는 오픈소스 생태계 인데요. <code >es-hangul</code>이라고 하는 한글을 다루기 위한 라이브러리는 이미 1,000개가 넘는 GitHub 스타를 획득했습니다. 또한 <code >lodash</code>보다 2배 더 빠른 유틸리티 라이브러리인 <code >es-toolkit</code>은 이미 6,100개의 스타를 받고 국내를 넘어 세계적으로 많은 개발자들의 관심을 받고 있는데요. 이번 토스 모닥불 EP.4 영상에서는 토스에서 오픈소스 생태계를 운영하는 개발자들의 이야기를 만나볼 수 있습니다. 특히나 주목할 만한 점은, 패널로 참여한 토스의 오픈소스 <code >suspensive</code> 를 운영하고 계시는 분인데요. 이 개발자분은 요즘은 필수로 사용되고 있는 <code >TanstackQuery</code> 의 최상위 기여자입니다. <code >Jotai</code> 외에도 토스 오픈소스에도 적극적으로 기여를하고 결국에는 토스에 합류하신게 참 대단하게 느껴지네요. 또한 오픈소스 생태계 구축을 통해 기술 커뮤니티에 긍정적인 영향을 미치고자 하는 토스의 노력도 대단한것 같습니다. 한국 개발 생태계의 경쟁력을 높이고, 개발자들에게 새로운 도전과 성장의 기회를 제공하는데 있어서, 토스의 이러한 행보를 응원합니다. https://www.youtube.com/watch?v=SdBL-p597Dw

www.youtube.com

토스의 오픈소스 생태계: 한국을 넘어 글로벌로

오늘 포스트는 데이터 이력서 자랑대회를 위해 참여해주신 3번째 심사위원님을 소개하고,
심사위원님들이 여러분들께 보내드리는 메세지를 전달하고자 해요.

[3번째 심사위원님 소개 ]
- Sanghak Lee (이상학)님 -

현재 글로벌 서치펌 스텝업파트너스 대표 헤드헌터로 활동 중입니다.
전에는 외국계 제약회사 영업을 담당하였고 마케팅 13년 경력을 가지고 있습니다. 링크드인 팔로워 15K를 바탕으로 취준생과 이직러들을 위한 커리어 멘토로서 활동하고 있습니다.

Sanghak Lee (이상학) 심사위원님과 함께 멋진 이력서 & 포트폴리오 자랑대회를 만들어 가길 바랍니다.

🙏감사합니다.

데이터 이력서 & 포트폴리오 자랑대회에 참여하고 싶다면, 아래의 링크를 확인해주세요!

헤드헌터 대표가 직접 심사하는 이력서 자랑대회 참여하기:
https://datarichard.notion.site/Feat-Notion-1ccfe21e802341f4a78ba9d1fb65bf7b

#데이터이력서자랑대회

오늘 포스트는 데이터 이력서 자랑대회를 위해 참여해주신 3번째 심사위원님을 소개하고, 심사위원님들이 여러분들께 보내드리는 메세지를 전달하고자 해요. [3번째 심사위원님 소개 ] - Sanghak Lee (이상학)님 - 현재 글로벌 서치펌 스텝업파트너스 대표 헤드헌터로 활동 중입니다. 전에는 외국계 제약회사 영업을 담당하였고 마케팅 13년 경력을 가지고 있습니다. 링크드인 팔로워 15K를 바탕으로 취준생과 이직러들을 위한 커리어 멘토로서 활동하고 있습니다. Sanghak Lee (이상학) 심사위원님과 함께 멋진 이력서 &amp; 포트폴리오 자랑대회를 만들어 가길 바랍니다. 🙏감사합니다. 데이터 이력서 &amp; 포트폴리오 자랑대회에 참여하고 싶다면, 아래의 링크를 확인해주세요! 헤드헌터 대표가 직접 심사하는 이력서 자랑대회 참여하기: https://datarichard.notion.site/Feat-Notion-1ccfe21e802341f4a78ba9d1fb65bf7b #데이터이력서자랑대회

📄데이터 이력서 & 포트폴리오 자랑대회 심사위원 소개

QA가 되기 위해서 무엇을 준비해야 하고 어떤 요건을 갖추어야 할까요?
기업에서는 어떤 요건과 자질을 갖춘 QA를 희망할까요?
‘QA가 되는 방법'보다 확장해서 "보다 나은" QA로 성장하기 위해서 어떤 역량과 태도를 갖추는 것이 좋을까요?

<첨부 이미지 - 레드게이트 스킬맵 참고>

보다 나은 QA로 성장하기 위해 필요한 역량을 나타내는 스킬맵으로 QA에게 요구되는 역량을 살펴봅시다. 이 스킬맵은 제가 만든것은 아니고, 레드게이트라는 기업에서 만든 스킬 맵을 한국어로 번역해보았습니다.

QA가 보유해야할 역량은 기업과 조직 문화에 따라서 조금씩 다를 수는 있습니다. 예를 들어 어떤 기업에서는 기술적 역량을 더 선호할 수 있고 또다른 기업에서는 기본 역량 외에 커뮤니케이션, 협동과 같은 자질을 갖춘 인력을 선호할 수 있습니다. 선호도에 따라 요구하는 요건과 자질은 차이가 있을 수 있으나 공통적으로 QA에게 요구하는 스킬은 화면의 맵 안에 대부분 포함되어 있습니다. 

스킬맵의 구성을 먼저 살펴보면, 화면의 왼쪽에 붉은 계열로 표시된 범위가 QA에 요구되는 전문적인 기술 역량을 나타내고, 회색 범위가 QA로서 갖추어야 할 자질과 태도에 해당됩니다

주요 역량을 골자로 확인해보면, 
보다 나은 QA가 되기위해 기본적으로 필요한 기술 역량의 첫번째는, 소프트웨어 공학에 대한 이해가 필요합니다. 
여기에는 1) Python, Java, C++과 같은 개발 언어에 대한 이해 2) 안드로이드, iOS, 웹 등의 플랫폼 운영체제에 대한 이해 그리고 3) 서버, 데이터베이스, API 등 개발 설계 구조에 대한 이해와 4) 개발 생명주기에 대한 이해가 포함됩니다. 

소프트웨어 공학 ‘지식'이 아니라 ‘이해’가 필요하다라고 말씀드린 이유는, 
개발자가 보유한 수준의 지식이 없더라도 협업 단계에서 개발자와 협업할 수 있는 최소한의 기술과 서비스 구조에 대한 이해, 그리고 코드를 이해하는 역량을 갖추고 있다면 원활한 의사소통과 협업이 가능하기때문에 필요한 역량이라고 이해하시면 됩니다. 

두번째, 소프트웨어 테스팅에 대한 전문 지식이 필요합니다. 
테스트 계획과 전략을 수립하는 방법이나 테스트 설계 능력, 테스트 프로세스 생명주기에 대한 이해와 개선을 위한 프로세스 관리 역량 그리고 테스트 수행 경험이나 방법에 대한 이해가 필요합니다. 
또는 ISTQB나 CSTS 같은 테스팅 관련된 자격증을 보유하는 것도 테스팅 이론과 방법론에 대한 기본 개념을 이해했다는 것이 증명되기 때문에 이를 취득하는 것도 한 방법이 될 수 있습니다. 

보다 나은 QA가 되기위해 필요한 기술 역량의 마지막은, 고급 기술과 테스트 도구 사용이 필요한 테스팅 기법과 스크립팅 경험 그리고 테스팅 환경 구축과 설계 경험에 대한 지식이 필요합니다.
여기에는 1)셀레니움, 앱피움과 같은 테스트 자동화 2)엔그라인더, 제이메터와 같은 서버 성능 테스트 3)포스트맨과 같은 API 테스트 4) 게임벤치와 같은 클라이언트 성능 테스트 마지막으로 실무에서 자주 사용되는 테스팅 지원 도구인 버그 관리 시스템이나, 깃허브, CI/CD 와 같은 도구에 대한 이해와 사용방법과 같은 지식이 필요합니다. 

기술역량의 마지막으로 소개한 역량은 QA 지망생이 필수로 갖추어야 할 스킬이라기 보다는 기술과 지식을 보유하면 장점이 될 수 있는 역량입니다. 하지만 QA 실무자라면 반드시 습득해야할 지식과 기술에 해당되는 범위이니 테스팅 전문가가 되기 위해서 역량 개발이 필요하다면 이부분을 꼭 학습하고 스킬을 보유하는 것이 좋습니다. 

다음으로 “보다 나은” QA로 성장하기 위해서 갖추어야할 자질과 태도를 몇가지만 살펴보겠습니다. 
첫번째, 분석 능력입니다. 
기획서, 개발 설계서, 결함 정보, 성능 자료, 위험 요소 등 품질을 예방하고 향상하기 위한 데이터를 수집하고 수집된 데이터를 분석하고 해석해서 논리적인 타당성을 가지고 판단을 추론할 수 있는 사고가 필요합니다. 

두번째, 협업과 학습을 통해서 훈련된 커뮤니케이션 역량이 필요합니다. 
여기서 말하는 커뮤니케이션은 말하기, 쓰기를 포함해서 의사를 소통할 수 있는 모든 채널을 포함합니다. 또한 일반적인 대화수준을 넘어서 기획, 개발과의 협업 작업을 관찰하고 학습과 질문을 통해서 시스템적으로 사고하고 기술적인 피드백을 교환할 수 있는 의사소통 능력을 의미합니다.
그리고 테스팅 활동과 품질 향상을 위한 목표를 요구할 때, 논리적인 타당성을 가지고 구성원들을 이해시키고 설득하는 능력이 필요합니다. 

마지막으로, 문제 해결 능력입니다. 
업무 진행 상황을 관찰해서 발생되는 문제를 빠르게 인지하고 문제로 인해서 예측되는 결과를 추론해서 해결할 방법을 연구하고 논리적이고 창의적인 사고로 해결책을 구체적인 단계로 변환할 수 있는 능력이 요구됩니다.

<첨부 이미지 - Up-Skilling 참고>

지금까지 살펴본 내용을 기술 등급으로 나누어서, 초급, 중급, 상급으로 발전하는 과정을 단계별로 살펴보겠습니다. 
이렇게 단계별로 Up-skilling에 필요한 스킬을 정리하면 현재 자신이 위치한 단계에서 개발이 필요한 스킬이 무엇인지 그리고 다음 단계로 성장하기 위해서 무엇을 학습해야 할지 방향성을 찾아갈 수 있습니다.

먼저 초급자는, 소프트웨어 공학의 기본 개념을 이해하고 소프트웨어 테스팅의 기본 원리를 학습해서 기본기를 탄탄히 다지는 것이 중요합니다. 
소프트웨어 공학을 통해서 테스트하는 대상 플랫폼과 시스템의 구조를 이해하고 이해를 바탕으로 테스트 설계 기법을 활용해서 목표와 전략에 맞는 테스트 케이스를 작성할 수 있는 능력을 보유해야 합니다. 
테스트 수행 중에는 버그를 추정해서 판단하고 관리 할 수 있는 능력을 습득하고 프로세스의 개선이 필요한 부분을 도출해서 의견을 제시할 수 있어야 합니다. 

그리고 테스트 수행 과정 중에 상급자가 설계한 테스트 계획과 전략, 문제 해결 방법을 학습하고 상급자의 경험과 노하우를 통해서 수행하는 경험 기반 테스팅을 습득해서 자신만의 스킬로 개발할 수 있도록 방법을 습득하는 것이 중요합니다. 
또 QA로 성공적인 경력을 쌓기 위해서 테스팅 지원 도구를 사용해서 기술 테스팅을 수행하는 방법과 하나 정도의 프로그래밍 언어를 읽고 쓸 수 있도록 기술을 습득하는 노력이 필요합니다. 

다음으로 중급자는 테스팅 전문 지식과 도구를 적극 활용한 테스트를 수행하고 데이터 분석을 통해서 품질을 평가하는 역량을 보유해야 합니다. 그리고 개발 구조와 생명주기 단계에 대해 충분히 이해한 상태에서 각 단계별로 필요한 테스팅과 기술을 지원할 수 있어야합니다. 또한 하나 이상의 개발 언어를 습득해서 자동화 스크립트를 작성하고 자동화를 적용하는 능력을 보유하는 것이 좋습니다.

소프트웨어 테스팅에서는 테스트케이스를 작성하고 실행하고 버그를 추적하는 단계를 넘어서 직접 계획을 수립하고 테스트 커버리지를 산정할 수 있어야 합니다. 그리고 테스트 활동 중에 작성되는 테스트 산출물을 점검하고 보완을 요청할 수 있어야 하고, 전반적인 테스트 활동을 제어하고 관리할 수 있어야 합니다. 
마지막으로 테스트 데이터를 분석해서 품질 상태를 평가하고 발생되는 리스크를 예측해서 예방하는 활동을 수행할 수 있어야 합니다. 

마지막으로 상급자 단계에서는 테스팅 활동에 집중하기보다 예방과 관리, 전략과 지원, 평가와 심사 등 개발생명주기 전반에 걸쳐서 리더십과 프로젝트 관리에 집중된 기술이 필요합니다. 
상급자는 하나 이상의 개발 언어를 사용할 수 있고 화이트박스 테스트와 테스트 주도 개발이 가능하도록 개발과 테스트를 지원하는 역량을 보유하는 것이 좋습니다. 

소프트웨어 테스팅 전문가로서 프로젝트에 맞는 프로세스를 직접 설계하고 적용할 수 있어야 하고, 프로세스 준수여부를 심사해서 업무가 체계적인 절차로 진행 될 수 있도록 통제하고 관리할 수 있어야 합니다.
또 리스크 관리, 형상관리, 일정이나 리소스 관리 그리고 테스트 전략을 계획하고 관리하는 능력을 발휘해서 품질 검증 활동을 지원하도록 합니다. 
마지막으로 QA팀의 목표 달성을 위해서 동기를 부여하고 초~중급자를 교육해서 테스트 전문 지식의 확장을 위한 도구와 관련 지식을 지원하는 능력이 필요합니다. 

초급자부터 상급자에 이르기까지, 
보다 나은 QA로 성장하기위해서 지속적인 학습과 실천을 통해 필요한 기술을 개발하고 향상시켜 나가는 것이 중요합니다. 
이렇게 개발한 기술과 지식, 습득된 경험과 노하우, 자신만의 경쟁력있는 역량과 핵심 가치는 프로젝트를 성공하게하고 품질을 확신할 수 있으며 팀 내/외부의 협업 관계를 강화하고 프로젝트 목표 달성을 위한 협력적인 환경을 조성할 수 있게 할 것입니다.

QA가 되기 위해서 무엇을 준비해야 하고 어떤 요건을 갖추어야 할까요?기업에서는 어떤 요건과 자질을 갖춘 QA를 희망할까요?‘QA가 되는 방법'보다 확장해서 "보다 나은" QA로 성장하기 위해서 어떤 역량과 태도를 갖추는 것이 좋을까요? &lt;첨부 이미지 - 레드게이트 스킬맵 참고&gt; 보다 나은 QA로 성장하기 위해 필요한 역량을 나타내는 스킬맵으로 QA에게 요구되는 역량을 살펴봅시다. 이 스킬맵은 제가 만든것은 아니고, 레드게이트라는 기업에서 만든 스킬 맵을 한국어로 번역해보았습니다. QA가 보유해야할 역량은 기업과 조직 문화에 따라서 조금씩 다를 수는 있습니다. 예를 들어 어떤 기업에서는 기술적 역량을 더 선호할 수 있고 또다른 기업에서는 기본 역량 외에 커뮤니케이션, 협동과 같은 자질을 갖춘 인력을 선호할 수 있습니다.&nbsp;선호도에 따라 요구하는 요건과 자질은 차이가 있을 수 있으나&nbsp;공통적으로 QA에게 요구하는 스킬은 화면의 맵 안에 대부분 포함되어 있습니다.&nbsp; 스킬맵의 구성을 먼저 살펴보면, 화면의 왼쪽에 붉은 계열로 표시된 범위가 QA에 요구되는 전문적인 기술 역량을 나타내고, 회색 범위가 QA로서 갖추어야 할 자질과 태도에 해당됩니다 주요 역량을 골자로 확인해보면,&nbsp;보다 나은 QA가 되기위해 기본적으로 필요한 기술 역량의&nbsp;첫번째는, 소프트웨어 공학에 대한 이해가 필요합니다.&nbsp;여기에는 1) Python, Java, C++과 같은 개발 언어에 대한 이해 2) 안드로이드, iOS, 웹 등의 플랫폼 운영체제에 대한 이해 그리고 3) 서버, 데이터베이스, API 등 개발 설계 구조에 대한 이해와 4) 개발 생명주기에 대한 이해가 포함됩니다.&nbsp; 소프트웨어 공학 ‘지식'이 아니라 ‘이해’가 필요하다라고 말씀드린 이유는,&nbsp;개발자가 보유한 수준의 지식이 없더라도 협업 단계에서 개발자와 협업할 수 있는 최소한의 기술과 서비스 구조에 대한 이해, 그리고 코드를 이해하는 역량을 갖추고 있다면&nbsp;원활한 의사소통과 협업이 가능하기때문에 필요한 역량이라고 이해하시면 됩니다.&nbsp; 두번째, 소프트웨어 테스팅에 대한 전문 지식이 필요합니다.&nbsp;테스트 계획과 전략을 수립하는 방법이나 테스트 설계 능력, 테스트 프로세스 생명주기에 대한 이해와&nbsp;개선을 위한 프로세스 관리 역량 그리고 테스트 수행 경험이나 방법에 대한 이해가 필요합니다.&nbsp;또는 ISTQB나 CSTS 같은 테스팅 관련된 자격증을 보유하는 것도&nbsp;테스팅 이론과 방법론에 대한 기본 개념을 이해했다는 것이 증명되기 때문에 이를 취득하는 것도 한 방법이 될 수 있습니다.&nbsp; 보다 나은 QA가 되기위해 필요한 기술 역량의 마지막은,&nbsp;고급 기술과 테스트 도구 사용이 필요한 테스팅 기법과 스크립팅 경험&nbsp;그리고 테스팅 환경 구축과 설계 경험에 대한 지식이 필요합니다.여기에는 1)셀레니움, 앱피움과 같은 테스트 자동화 2)엔그라인더, 제이메터와 같은 서버 성능 테스트 3)포스트맨과 같은 API 테스트 4) 게임벤치와 같은 클라이언트 성능 테스트 마지막으로 실무에서 자주 사용되는 테스팅 지원 도구인 버그 관리 시스템이나, 깃허브, CI/CD 와 같은 도구에 대한 이해와 사용방법과 같은 지식이 필요합니다.&nbsp; 기술역량의 마지막으로 소개한 역량은 QA 지망생이 필수로 갖추어야 할 스킬이라기 보다는 기술과 지식을 보유하면 장점이 될 수 있는 역량입니다.&nbsp;하지만 QA 실무자라면 반드시 습득해야할 지식과 기술에 해당되는 범위이니 테스팅 전문가가 되기 위해서 역량 개발이 필요하다면&nbsp;이부분을 꼭 학습하고 스킬을 보유하는 것이 좋습니다.&nbsp; 다음으로 “보다 나은” QA로 성장하기 위해서 갖추어야할 자질과 태도를 몇가지만 살펴보겠습니다.&nbsp;첫번째, 분석 능력입니다.&nbsp;기획서, 개발 설계서, 결함 정보, 성능 자료, 위험 요소 등&nbsp;품질을 예방하고 향상하기 위한&nbsp;데이터를 수집하고 수집된 데이터를 분석하고 해석해서 논리적인 타당성을 가지고 판단을 추론할 수 있는 사고가 필요합니다.&nbsp; 두번째, 협업과 학습을 통해서 훈련된 커뮤니케이션 역량이 필요합니다.&nbsp;여기서 말하는 커뮤니케이션은 말하기, 쓰기를 포함해서 의사를 소통할 수 있는 모든 채널을 포함합니다.&nbsp;또한 일반적인 대화수준을 넘어서 기획, 개발과의 협업 작업을 관찰하고&nbsp;학습과 질문을 통해서 시스템적으로 사고하고&nbsp;기술적인 피드백을 교환할 수 있는 의사소통 능력을 의미합니다.그리고 테스팅 활동과 품질 향상을 위한 목표를 요구할 때,&nbsp;논리적인 타당성을 가지고 구성원들을 이해시키고 설득하는 능력이 필요합니다.&nbsp; 마지막으로, 문제 해결 능력입니다.&nbsp;업무 진행 상황을 관찰해서 발생되는 문제를 빠르게 인지하고&nbsp;문제로 인해서 예측되는 결과를 추론해서 해결할 방법을 연구하고&nbsp;논리적이고 창의적인 사고로 해결책을 구체적인 단계로 변환할 수 있는 능력이 요구됩니다. &lt;첨부 이미지 - Up-Skilling 참고&gt; 지금까지 살펴본 내용을 기술 등급으로 나누어서, 초급, 중급, 상급으로 발전하는 과정을 단계별로 살펴보겠습니다.&nbsp;이렇게 단계별로 Up-skilling에 필요한 스킬을 정리하면&nbsp;현재 자신이 위치한 단계에서 개발이 필요한 스킬이 무엇인지 그리고&nbsp;다음 단계로 성장하기 위해서 무엇을 학습해야 할지 방향성을 찾아갈 수 있습니다. 먼저 초급자는, 소프트웨어 공학의 기본 개념을 이해하고&nbsp;소프트웨어 테스팅의 기본 원리를 학습해서 기본기를 탄탄히 다지는 것이 중요합니다.&nbsp;소프트웨어 공학을 통해서 테스트하는 대상 플랫폼과 시스템의 구조를 이해하고&nbsp;이해를 바탕으로 테스트 설계 기법을 활용해서 목표와 전략에 맞는 테스트 케이스를 작성할 수 있는 능력을 보유해야 합니다.&nbsp;테스트 수행 중에는 버그를 추정해서 판단하고 관리 할 수 있는 능력을 습득하고&nbsp;프로세스의 개선이 필요한 부분을 도출해서 의견을 제시할 수 있어야 합니다.&nbsp; 그리고 테스트 수행 과정 중에 상급자가 설계한 테스트 계획과 전략, 문제 해결 방법을 학습하고&nbsp;상급자의 경험과 노하우를 통해서 수행하는 경험 기반 테스팅을 습득해서 자신만의 스킬로 개발할 수 있도록 방법을 습득하는 것이 중요합니다.&nbsp;또 QA로 성공적인 경력을 쌓기 위해서 테스팅 지원 도구를 사용해서 기술 테스팅을 수행하는 방법과 하나 정도의 프로그래밍 언어를 읽고 쓸 수 있도록 기술을 습득하는 노력이 필요합니다.&nbsp; 다음으로 중급자는&nbsp;테스팅 전문 지식과 도구를 적극 활용한 테스트를 수행하고&nbsp;데이터 분석을 통해서 품질을 평가하는 역량을 보유해야 합니다.&nbsp;그리고 개발 구조와 생명주기 단계에 대해 충분히 이해한 상태에서&nbsp;각 단계별로 필요한 테스팅과 기술을 지원할 수 있어야합니다. 또한&nbsp;하나 이상의 개발 언어를 습득해서 자동화 스크립트를 작성하고 자동화를 적용하는 능력을 보유하는 것이 좋습니다. 소프트웨어 테스팅에서는 테스트케이스를 작성하고 실행하고 버그를 추적하는 단계를 넘어서&nbsp;직접 계획을 수립하고 테스트 커버리지를 산정할 수 있어야 합니다.&nbsp;그리고 테스트 활동 중에 작성되는 테스트 산출물을 점검하고 보완을 요청할 수 있어야 하고,&nbsp;전반적인 테스트 활동을 제어하고 관리할 수 있어야 합니다.&nbsp;마지막으로 테스트 데이터를 분석해서 품질 상태를 평가하고&nbsp;발생되는 리스크를 예측해서 예방하는 활동을 수행할 수 있어야 합니다.&nbsp; 마지막으로 상급자 단계에서는 테스팅 활동에 집중하기보다&nbsp;예방과 관리, 전략과 지원, 평가와 심사 등 개발생명주기 전반에 걸쳐서 리더십과 프로젝트 관리에 집중된 기술이 필요합니다.&nbsp;상급자는 하나 이상의 개발 언어를 사용할 수 있고 화이트박스 테스트와 테스트 주도 개발이 가능하도록&nbsp;개발과 테스트를 지원하는 역량을 보유하는 것이 좋습니다.&nbsp; 소프트웨어 테스팅 전문가로서 프로젝트에 맞는 프로세스를 직접 설계하고 적용할 수 있어야 하고, 프로세스&nbsp;준수여부를 심사해서 업무가 체계적인 절차로 진행 될 수 있도록 통제하고 관리할 수 있어야 합니다.또 리스크 관리, 형상관리, 일정이나 리소스 관리&nbsp;그리고 테스트 전략을 계획하고 관리하는 능력을 발휘해서 품질 검증 활동을 지원하도록 합니다.&nbsp;마지막으로 QA팀의 목표 달성을 위해서 동기를 부여하고 초~중급자를 교육해서&nbsp;테스트 전문 지식의 확장을 위한 도구와 관련 지식을 지원하는 능력이 필요합니다.&nbsp; 초급자부터 상급자에 이르기까지,&nbsp;보다 나은 QA로 성장하기위해서 지속적인 학습과 실천을 통해 필요한 기술을 개발하고 향상시켜 나가는 것이 중요합니다.&nbsp;이렇게 개발한 기술과 지식, 습득된 경험과 노하우,&nbsp;자신만의 경쟁력있는 역량과 핵심 가치는&nbsp;프로젝트를 성공하게하고 품질을 확신할 수 있으며&nbsp;팀 내/외부의 협업 관계를 강화하고 프로젝트 목표 달성을 위한 협력적인 환경을 조성할 수 있게 할 것입니다.&nbsp;

'보다 나은' QA로 성장하기

제2회 계약관리팀 해커톤 이야기 | 안녕하세요. 모두싸인 계약관리팀의 루디와 조니입니다! 지난 5월 저희 팀에서 진행한 해커톤 이야기를 들려드리고 싶어서 글을 쓰게 되었습니다.  모두싸인의 제품그룹은 크게 3개의 팀으로 나누어져 있는데요. 모두싸인이 SaaS로서 동작하기 위한 플랫폼으로서의 가치를 다루는 'SaaS 플랫폼팀' 전자계약을 전송/체결하는 가치를 다루는 '계약체결팀' 계약서를 작성

모두싸인 제품팀이 해커톤으로 고객경험을 끌어올리는 방법

모두싸인 제품팀이 진행한 해커톤에 관한 글입니다. 글에서는 다음과 같은 내용이 나와요!
이 중 가장 재미있는 부분은 기능 고도화를 위해서 해커톤을 했다는 점입니다.

무언가 개발하다보면 사무실 앞 계단처럼 어쩌면 누구도 관심을 안주는 곳이 생기기도 하죠. 이런 곳을 살필 수 있는 회사라는 점에서 모두싸인 멋지네요!

 * 해커톤 개최: 모두싸인 계약관리팀이 두 번째 해커톤을 개최하여 대량전송 기능을 고도화
 * 준비 과정: 2개월 동안 8번의 회의를 통해 굿즈 제작, 주제 선정, 기술적 논의 등을 진행
 * 개발 결과: 대량전송 기능의 UI/UX를 개선하고, 브라우저에서 직접 데이터를 설정할 수 있는 에디터 기능을 추가
 * 성과: 내부 구성원과 고객들로부터 긍정적인 반응을 얻었으며, 팀의 결속력과 소통 능력을 향상

https://brunch.co.kr/@modusign/77

모두싸인 제품팀이 진행한 해커톤에 관한 글입니다. 글에서는 다음과 같은 내용이 나와요!이 중 가장 재미있는 부분은 기능 고도화를 위해서 해커톤을 했다는 점입니다. 무언가 개발하다보면 사무실 앞 계단처럼 어쩌면 누구도 관심을 안주는 곳이 생기기도 하죠. 이런 곳을 살필 수 있는 회사라는 점에서 모두싸인 멋지네요! <ul ><li>해커톤 개최: 모두싸인 계약관리팀이 두 번째 해커톤을 개최하여 대량전송 기능을 고도화</li><li>준비 과정: 2개월 동안 8번의 회의를 통해 굿즈 제작, 주제 선정, 기술적 논의 등을 진행</li><li>개발 결과: 대량전송 기능의 UI/UX를 개선하고, 브라우저에서 직접 데이터를 설정할 수 있는 에디터 기능을 추가</li><li>성과: 내부 구성원과 고객들로부터 긍정적인 반응을 얻었으며, 팀의 결속력과 소통 능력을 향상</li></ul> https://brunch.co.kr/@modusign/77

Brunch Story

고객경험을 끌어올리기 위한 해커톤을 하는 회사가 있다?!

`인간의 생존을 위협하고 있는 건 AI가 아니라 인간 자신이다!”2034년 미래 예측부터 인간의 욕망까지기술과 철학을 넘나드는 인공지능 특강AI 산업의 최전선에서 일해온 저자의 가장 객관적인 AI 안내서. 인공지능을 둘러싼 근거 없는 낙관, 지나친 비관이 넘치...

AI 트루스 - 예스24

한빛미디어로부터 재밌는 책을 후원받아 리뷰 공유해봅니다!

여러분들에게 AI는 어떤 기술이며, 여러분의 일상과 미래를 바꾸고 있나요?

모델, 기술 이 모든게 너무나도 빠르게 변화하고 있는 시기라, 어쩌면 그 안에 너무 빠져들어 어느 방향으로 가고 있는지 얼마나 빨리가고 있는지 신경쓰지 못하고 있었던 것 같습니다. AI 관련하여서는 항상 어떻게 내 생활에 활용할까, 이걸로 어떻게 재미나게 놀아볼 수 있을까, 어떤 주식이 오를까(?)에 대해서는 이야기도 하고 생각도 많이 해봤지만, 이 책을 읽고 많이 부끄러워졌네요.

AI가 우리의 미래 모습을 바꿀꺼라 생각하면서도 그에 앞서 윤리적 교육, 우리가 진짜 주목해야하는 것들 그리고 우리가 마주할 미래에 대해서는 깊이 생각 못해봤던 것 같습니다. 다른 AI 책들이 빠르게 변화하는 트렌드를 다루고 있는 반면, 이 책은 급속히 변하는 기술 속에서 우리가 진정으로 집중해야 할 본질에 대한 통찰을 보여주고 있습니다.

과거 AI 연구의 역사에서부터 현재까지의 이야기 그리고 미래에 대한 상상을 다양한 각도로 고민해 볼 수 있는 책입니다. 책의 처음 집필 방향이 개발자를 대체하는 코딩 AI이기 때문에 중반부에서는 코딩 이야기가 좀 나오지만, 전반적으로는 지식 산업 안에서 종사하고 있는 누구나 알아야하는 그리고 생각해봐야하는 인사이트들을 많이 담고 있어 IT업계 모두에게 추천드립니다. :)) 후반부는 법률, 금융, 의료, 제조, 교육 등등 다양한 산업분야를 다 다루고 있습니다.

이번 추석 연휴, 마음의 풍족함과 더불어 생각의 깊이도 더할 수 있는 AI트루스 독서 추천합니다!

https://www.yes24.com/Product/Goods/131926558

한빛미디어로부터 재밌는 책을 후원받아 리뷰 공유해봅니다! 여러분들에게 AI는 어떤 기술이며, 여러분의 일상과 미래를 바꾸고 있나요? 모델, 기술 이 모든게 너무나도 빠르게 변화하고 있는 시기라, 어쩌면 그 안에 너무 빠져들어 어느 방향으로 가고 있는지 얼마나 빨리가고 있는지 신경쓰지 못하고 있었던 것 같습니다. AI 관련하여서는 항상 어떻게 내 생활에 활용할까, 이걸로 어떻게 재미나게 놀아볼 수 있을까, 어떤 주식이 오를까(?)에 대해서는 이야기도 하고 생각도 많이 해봤지만, 이 책을 읽고 많이 부끄러워졌네요. AI가 우리의 미래 모습을 바꿀꺼라 생각하면서도 그에 앞서 윤리적 교육, 우리가 진짜 주목해야하는 것들 그리고 우리가 마주할 미래에 대해서는 깊이 생각 못해봤던 것 같습니다. 다른 AI 책들이 빠르게 변화하는 트렌드를 다루고 있는 반면, 이 책은 급속히 변하는 기술 속에서 우리가 진정으로 집중해야 할 본질에 대한 통찰을 보여주고 있습니다. 과거 AI 연구의 역사에서부터 현재까지의 이야기 그리고 미래에 대한 상상을 다양한 각도로 고민해 볼 수 있는 책입니다. 책의 처음 집필 방향이 개발자를 대체하는 코딩 AI이기 때문에 중반부에서는 코딩 이야기가 좀 나오지만, 전반적으로는 지식 산업 안에서 종사하고 있는 누구나 알아야하는 그리고 생각해봐야하는 인사이트들을 많이 담고 있어 IT업계 모두에게 추천드립니다. :)) 후반부는 법률, 금융, 의료, 제조, 교육 등등 다양한 산업분야를 다 다루고 있습니다. 이번 추석 연휴, 마음의 풍족함과 더불어 생각의 깊이도 더할 수 있는 AI트루스 독서 추천합니다! https://www.yes24.com/Product/Goods/131926558

예스24

[책] AI 트루스

오늘은 지난번 포스트에 이어,
데이터 이력서 자랑대회를 위해 참여해주신 심사위원님을 소개하고,
심사위원님들이 여러분들께 보내드리는 메세지를 전달하고자 해요.

[2번째 심사위원 소개]

- 강슬기님 -
현재 포커스미디어 데이터전략팀 팀장으로 근무 중입니다.

전에는 SMR, 이노션, 오길비, 레오버넷에 근무하였고,
현재 링크드인에서 3500분의 커넥션과 데이터 관련 컨텐츠 소통 중입니다.

그외에도
마케팅 데이터 커넥트 그룹 운영 (회원 300+)
삼성전자, 대상 주식회사, 유니레버 강연
동국대학교, 한국기술교육대학교 강의
Plug N Play 스타트업 강연, 컨설팅
앨리스 코딩 태블로 강사
부산국제광고제 2024 Speaker
데이터리안, 하트카운트 웨비나
등과 같은 활동을 하였습니다.

강슬기 심사위원님과 함께 멋진 대회를 만들어 가길 바랍니다.
🙏감사합니다.

데이터 분석 팀장님이 직접 심사하는
데이터 이력서 자랑대회에 참여하고 싶다면, 아래의 링크를 확인해주세요!

이력서 자랑대회 참여하기:
https://datarichard.notion.site/Feat-Notion-1ccfe21e802341f4a78ba9d1fb65bf7b

#데이터리차드 #데이터이력서 #자랑대회 #심사위원

오늘은 지난번 포스트에 이어, 데이터 이력서 자랑대회를 위해 참여해주신 심사위원님을 소개하고, 심사위원님들이 여러분들께 보내드리는 메세지를 전달하고자 해요. [2번째 심사위원 소개] - 강슬기님 - 현재 포커스미디어 데이터전략팀 팀장으로 근무 중입니다. 전에는 SMR, 이노션, 오길비, 레오버넷에 근무하였고, 현재 링크드인에서 3500분의 커넥션과 데이터 관련 컨텐츠 소통 중입니다. 그외에도 마케팅 데이터 커넥트 그룹 운영&nbsp;(회원 300+) 삼성전자, 대상 주식회사, 유니레버 강연 동국대학교, 한국기술교육대학교 강의 Plug N Play 스타트업 강연, 컨설팅 앨리스 코딩 태블로 강사 부산국제광고제 2024 Speaker 데이터리안, 하트카운트 웨비나 등과 같은 활동을 하였습니다. 강슬기 심사위원님과 함께 멋진 대회를 만들어 가길 바랍니다. 🙏감사합니다. 데이터 분석 팀장님이 직접 심사하는 데이터 이력서 자랑대회에 참여하고 싶다면, 아래의 링크를 확인해주세요! 이력서 자랑대회 참여하기:https://datarichard.notion.site/Feat-Notion-1ccfe21e802341f4a78ba9d1fb65bf7b #데이터리차드 #데이터이력서 #자랑대회 #심사위원

데이터 이력서 자랑대회 (Feat. Notion) - 심사위원 2번째

쉘 리다이렉션(Redirection) 사용법

쉘 프로그래밍을 처음 하시는 분들이 스크립트를 읽으시다가
2>&1
와 같은 알 수 없는 문법을 보고 당황하시는 경우가 있습니다. 이 것을 보통 리다이렉션(Redirection)이라고 하는데요. 어떤 명령의 입력이나 출력을 다른 곳으로 변경하기 위해서 사용됩니다.

이번 포스팅에서는 쉘 리다이렉션의 기본 사용법을 알아보고 다양한 예제를 통해 어떻게 실제 쉘 프로그래밍에 활용할 수 있는지 배워보겠습니다.

📝 포스팅: https://www.daleseo.com/shell-redirection/

 * 표준 스트림
 * 출력 리다이렉션
 * 오류 리다이렉션
 * 통합 리다이렉션
 * 입력 리다이렉션

쉘 프로그래밍을 처음 하시는 분들이 스크립트를 읽으시다가 <code >2&gt;&amp;1</code>와 같은 알 수 없는 문법을 보고 당황하시는 경우가 있습니다. 이 것을 보통 리다이렉션(Redirection)이라고 하는데요. 어떤 명령의 입력이나 출력을 다른 곳으로 변경하기 위해서 사용됩니다. 이번 포스팅에서는 쉘 리다이렉션의 기본 사용법을 알아보고 다양한 예제를 통해 어떻게 실제 쉘 프로그래밍에 활용할 수 있는지 배워보겠습니다. 📝 포스팅: https://www.daleseo.com/shell-redirection/ <ul ><li>표준 스트림</li><li>출력 리다이렉션</li><li>오류 리다이렉션</li><li>통합 리다이렉션</li><li>입력 리다이렉션</li></ul>

www.daleseo.com

'Clean Code' 였는지 정확히 기억은 안나지만 부정적 의미의 변수를 사용하지 말라는 것을 봤던 것 같네요.

그 이유는 부정을 다시 뒤집어서 판단하는 경우도 있기 때문에 한번에 이해되지 않는 코드가 될 수 있어서 그랬던 것 같습니다..

이 글은 부정적 이름으로 선언한 예를 보여주며 어떻게 바꾸는 것이 가독성을 높일 수 있는지 알려줍니다.

guard 문을 사용하는 경우는 예외라고 해서 js에도 guard가 있는 건가 했더니 guard의 의미로 if에서 return하는 경우를 말하는 것이었네요.

여러분은 boolean 변수 이름을 어떻게 짓고 계신가요?

#직독직해 #medium #ios #swift #api #binary #stability
https://youtu.be/t576SbDBzc4

'Clean Code' 였는지 정확히 기억은 안나지만 부정적 의미의 변수를 사용하지 말라는 것을 봤던 것 같네요. 그 이유는 부정을 다시 뒤집어서 판단하는 경우도 있기 때문에 한번에 이해되지 않는 코드가 될 수 있어서 그랬던 것 같습니다.. 이 글은 부정적 이름으로 선언한 예를 보여주며 어떻게 바꾸는 것이 가독성을 높일 수 있는지 알려줍니다. guard 문을 사용하는 경우는 예외라고 해서 js에도 guard가 있는 건가 했더니 guard의 의미로 if에서 return하는 경우를 말하는 것이었네요. 여러분은 boolean 변수 이름을 어떻게 짓고 계신가요? #직독직해 #medium #ios #swift #api #binary #stability https://youtu.be/t576SbDBzc4

youtu.be

변수의 이름을 부정의 의미로 지으신 적 있나요?

혹시 변수명에 notSave 이렇게 지으면 안된다는건가요?

Have you noticed that Git is so integral to working with code that people hardly ever include it in their tech stack or on their CV at all? The assumption is you know it already, or at least enough...

The guide to Git I never had.

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.
 
브랜치 (Branches)
Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다.

커밋 (Commits)
Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다.

커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.
git show abc123def456789

이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.
 
태그 (Tags)
Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다.

헤드 (HEAD)
현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.
 
스테이지 (Stages)
Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다:

 * 작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.
 * 스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.
 * 로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.
 * 원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.
 
Git 시작하기
어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다.

브랜치 작업
로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:
# Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name

브랜치 간 전환을 위해서는:
git switch

또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:
git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name

저장소의 상태를 확인하려면 다음을 사용하십시오:
git status

현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다.

커밋 작업
커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.
git commit -m "의미 있는 메시지"

마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:
# 변경사항을 추가
git add .
git commit --amend

이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.
git push origin your_branch --force

기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.
 
git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.
 

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

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.&nbsp;브랜치 (Branches)Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다. 커밋 (Commits)Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다. 커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.<pre ><code class="language-bash">git show abc123def456789</code></pre>이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.&nbsp;태그 (Tags)Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다. 헤드 (HEAD)현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.&nbsp;스테이지 (Stages)Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다: <ul ><li>작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.</li><li>스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.</li><li>로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.</li><li>원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.</li></ul>&nbsp;Git 시작하기어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다. 브랜치 작업로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:<pre ><code class="language-bash"># Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name</code></pre>브랜치 간 전환을 위해서는:<pre ><code class="language-bash">git switch</code></pre>또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:<pre ><code class="language-bash">git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name</code></pre>저장소의 상태를 확인하려면 다음을 사용하십시오:<pre ><code class="language-bash">git status</code></pre>현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다. 커밋 작업커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.<pre ><code class="language-bash">git commit -m "의미 있는 메시지"</code></pre>마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:<pre ><code class="language-bash"># 변경사항을 추가
git add .
git commit --amend</code></pre>이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.<pre ><code class="language-bash">git push origin your_branch --force</code></pre>기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.&nbsp;git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.&nbsp; 번역: [https://ducktopia.tistory.com/132]원문:

Medium

🕊️ [Medium] 내가 원했던, Git 가이드 (1)

카카오페이에서 프론트엔드 개발을 하며 스켈레톤 UI와 사용자 경험 향상에 대해 고민한 내용을 공유합니다.

무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요? | 카카오페이 기술 블로그

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다.

세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요.

스켈레톤 화면의 효과
 1. 빠른 로딩 (100ms 미만):
    * 스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.
    * 결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.
 2. 느린 로딩 (300ms 이상):
    * 스켈레톤 화면이 유용하게 작용합니다.
    * 사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.

카카오페이의 해결책: 지연된 스켈레톤
카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.
 * 작동 방식:
   * 0-200ms: 빈 화면 표시
   * 200ms 이후:
     * 데이터 로딩 완료 시 → 즉시 데이터 표시
     * 데이터 로딩 중 → 스켈레톤 표시
 * 예시:
   * 100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)
   * 400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시

또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다.

따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다.

https://tech.kakaopay.com/post/skeleton-ui-idea/

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다. 세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요. 스켈레톤 화면의 효과<ol ><li>빠른 로딩 (100ms 미만):<ul ><li>스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.</li><li>결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.</li></ul></li><li>느린 로딩 (300ms 이상):<ul ><li>스켈레톤 화면이 유용하게 작용합니다.</li><li>사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.</li></ul></li></ol> 카카오페이의 해결책: 지연된 스켈레톤카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.<ul ><li>작동 방식:<ul ><li>0-200ms: 빈 화면 표시</li><li>200ms 이후:<ul ><li>데이터 로딩 완료 시 → 즉시 데이터 표시</li><li>데이터 로딩 중 → 스켈레톤 표시</li></ul></li></ul></li><li>예시:<ul ><li>100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)</li><li>400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시</li></ul></li></ul> 또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다. 따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다. https://tech.kakaopay.com/post/skeleton-ui-idea/

Kakaopay

스켈레톤 화면: 언제나 좋은 선택일까요?

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

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

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

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

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

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

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

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 

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

단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 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> 요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

좋은 코드란?

2018년 작성해 오래된 아티컬이긴하지만
그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다.

https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

2018년 작성해 오래된 아티컬이긴하지만그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다. https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

MSA with Spring

Java developers tend to use 'java.util.UUID#randomUUID()' API, to generate a UUID (Universally Unique Identifier) number (i.e., 'b8bbcbed-ca07-490c-8711-5118ee0af2f9'). Under certain circumstances...

Java UUID generation - Performance impact

﻿
랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.
글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.
무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다.

https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

﻿랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다. https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

Java UUID generation-Performance imp

토스와 애플의 조직문화인 DRI는 무엇일까? DRI를 효과적으로 도입하기 위해 꼭 알아야 할 3가지 요소(결정, 실행, 책임)에 대해 알아보겠습니다. | HR 인사이트

DRI를 도입하기 위한 필수 요소 3가지 - 진짜 나를 빛나게, 스펙터 Specter

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.
DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다.

🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?
업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.
이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.
이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다.

💁‍♂️ DRI란
특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.
프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.
DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다.

📈 DRI 도입 이후 직원들에게 일어난 변화
 * 활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다.
 * 전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.

🏄🏻‍♂️ DRI를 구성하는 요소
 * 결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.
 * 실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다.
 * 책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.

🎁 DRI 조직 문화를 만들기 위한 필수사항
 * 신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.
 * 수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다.
 * DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다.

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다. 🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다. 💁‍♂️ DRI란특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다. 📈 DRI 도입 이후 직원들에게 일어난 변화<ul ><li>활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다. </li><li>전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.</li></ul> 🏄🏻‍♂️ DRI를 구성하는 요소<ul ><li>결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.</li><li>실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다. </li><li>책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.</li></ul> 🎁 DRI 조직 문화를 만들기 위한 필수사항<ul ><li>신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.</li><li>수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다. </li><li>DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다. </li></ul>

Specter

토스와 애플 조직문화 DRI

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다.
"우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다."
그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠.
"경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다."

02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다.
그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다.

03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다.

04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요.

05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다.

06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다.
다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다.
"50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다.

07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다.
"매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠.

08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠.

09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠.

10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다. "우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다." 그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠. "경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다." 02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다. 그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다. 03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다. 04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요. 05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다. 06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다. 다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다. "50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다. 07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다. "매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠. 08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠. 09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠. 10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

늘, 꾸준히, 일정 기준 이상으로 '잘하기'

An overview of Go syntax and features. Contribute to a8m/golang-cheat-sheet development by creating an account on GitHub.

GitHub - a8m/golang-cheat-sheet: An overview of Go syntax and features.

Golang을 한번 훓었는데 까먹었거나,
책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.
목차가 아주 알차네요~

- Basic Syntax (기본 문법)
- Operators (연산자)
- Declarations (선언)
- Functions (함수)
- Built-in Types (내장 타입)
- Type Conversions (타입 변환)
- Packages (패키지)
- Control structures (제어 구조)
- Arrays, Slices, Ranges (배열, 슬라이스, 범위)
- Maps (맵)
- Structs (구조체)
- Pointers (포인터)
- Interfaces (인터페이스)
- Embedding (임베딩)
- Errors (오류 처리)
- Concurrency (동시성)
- Printing (출력)
- Reflection (리플렉션)
- Snippets (코드 스니펫)

https://github.com/a8m/golang-cheat-sheet/tree/master

Golang을 한번 훓었는데 까먹었거나,책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.목차가 아주 알차네요~ - Basic Syntax (기본 문법)- Operators (연산자)- Declarations (선언)- Functions (함수)- Built-in Types (내장 타입)- Type Conversions (타입 변환)- Packages (패키지)- Control structures (제어 구조)- Arrays, Slices, Ranges (배열, 슬라이스, 범위)- Maps (맵)- Structs (구조체)- Pointers (포인터)- Interfaces (인터페이스)- Embedding (임베딩)- Errors (오류 처리)- Concurrency (동시성)- Printing (출력)- Reflection (리플렉션)- Snippets (코드 스니펫) https://github.com/a8m/golang-cheat-sheet/tree/master

GitHub

Golang 치트 시트

1
스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고.

2
모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다.

3
그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다.

4
우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다.

5
텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다.

6
돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다.

7
순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다.

8
부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다.

9
기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다.

10
기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다.

11
다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다.

12
'어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다.

13
모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까.

14
시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다.

15
시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

1 스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고. ​ ​2 모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다. ​ ​3 그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다. ​ ​4 우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다. ​ ​5 텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다. ​ ​6 돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다. ​7 순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다. ​8 부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다. ​ ​9 기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다. ​ ​10 기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다. ​ ​11 다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다. ​ ​12 '어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다. ​ ​13 모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까. ​ ​14 시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다. ​ ​15 시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

< 죽음을 기억하라. 중요한 것들은 눈에 보이지 않는다 >

[2024 제2회 ICT콤플렉스 전문가네트워킹 - 인공지능(AI), 빅데이터]

주제 : 인공지능(AI), 빅데이터

세부분야 및 멘토진(1개 분야 선택 가능)
▶ 인공지능(AI)
- 김희원 멘토 / 어치브텍 기술이사
- 백기락 멘토 / 꿈의실현 대표
▶ 빅데이터
- 안창배 멘토 / Kakao corp Data scientist
- 김윤래 멘토 / 삼성전자 수석 연구원
- 박수민 멘토 / (주)위세아이텍 주임

지원대상 : ICT콤플렉스 회원 누구나
※ 비회원의 경우 회원가입 후 신청 가능
※ 회원가입 링크 : https://ictcoc.kr/00_mem_n/mem01.asp

진행일시 : 2024. 8. 8.(목) 14:00~17:00

진행방식 : 오프라인 1:1 멘토링 30분간 진행

장소 : ICT콤플렉스 커뮤니티라운지(마포구 마포대로 122, 프론트원 6층)

문의 : ictcoc@kfict.or.kr / 02-6953-0537

신청기간 : ~ 8.4.(일) 23:59 까지
※ 참가자 선정 결과는 8.5.(월) 중으로 개별 안내될 예정입니다.
※ 8.5.(월) 16시까지 결과 안내를 받지 못할 경우 필히 문의 주시기 바랍니다.

신청링크 : https://forms.gle/fTkMCj54ZTeZNY2m6

[2024 제2회 ICT콤플렉스 전문가네트워킹 - 인공지능(AI), 빅데이터]​주제 : 인공지능(AI), 빅데이터​세부분야 및 멘토진(1개 분야 선택 가능)▶ 인공지능(AI)- 김희원 멘토 / 어치브텍 기술이사- 백기락 멘토 / 꿈의실현 대표▶ 빅데이터- 안창배 멘토 / Kakao corp Data scientist- 김윤래 멘토 / 삼성전자 수석 연구원- 박수민 멘토 / (주)위세아이텍 주임​지원대상 : ICT콤플렉스 회원 누구나※ 비회원의 경우 회원가입 후 신청 가능※ 회원가입 링크 : https://ictcoc.kr/00_mem_n/mem01.asp​진행일시 : 2024. 8. 8.(목) 14:00~17:00​진행방식 : 오프라인 1:1 멘토링 30분간 진행​장소 : ICT콤플렉스 커뮤니티라운지(마포구 마포대로 122, 프론트원 6층)​문의 : ictcoc@kfict.or.kr / 02-6953-0537​신청기간 : ~ 8.4.(일) 23:59 까지※ 참가자 선정 결과는 8.5.(월) 중으로 개별 안내될 예정입니다.※ 8.5.(월) 16시까지 결과 안내를 받지 못할 경우 필히 문의 주시기 바랍니다.​신청링크 : https://forms.gle/fTkMCj54ZTeZNY2m6

[ICT콤플렉스] 2024 제2회 전문가네트워킹(#AI #빅데이터)

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필