요즘 일론 머스크의 전기가 핫합니다. 서점 가도 가장 메인 가판대에 올라와 있는 것을 알 수 있지요. 일론 머스크도 핫하지만, 저자인 월터 아이작슨도 뜨거운 사람입니다. 스티브 잡스의 전기 저자로 유명한 분이시기도 하지만, 언론 쪽에서는 끝판왕 커리어를 갖추신 분이지요. 과거에 CNN 의장이자, 타임지의 편집장을 역임했으면 말 다한것 아닐까요? 두 책의 저자인 월터아이작슨이 출연한 인터뷰의 일부를 번역했습니다.

일론머스크와 스티브잡스의 공통점 (월터 아이작슨)

요즘 일론 머스크의 전기가 핫합니다. 서점 가도 가장 메인 가판대에 올라와 있는 것을 알 수 있지요. 일론 머스크도 핫하지만, 저자인 월터 아이작슨도 뜨거운 사람입니다. 스티브 잡스의 전기 저자로 유명한 분이시기도 하지만, 언론 쪽에서는 끝판왕 커리어를 갖추신 분이지요. 과거에 CNN 의장이자, 타임지의 편집장을 역임했으면 말 다한것 아닐까요?

두 책의 저자인 월터아이작슨이 출연한 인터뷰의 일부를 번역했습니다. 영상은 잡스와 머스크의 'cruelty' (빡셈) 에 대해서 이야기하고 있습니다. 그들의 빡셈은 업무의 완벽함을 추구하는 과정에서 나오는 '빡셈'일 텐데요. 세계에서 가장 '괴짜인' 둘을 옆에서 지켜보며 전기를 집필한 저자의 코멘트를 보는 것도 흥미롭습니다. 아마 둘을 가장 세상 가까이에서 본 사람일 테니까요. 책을 읽으시는 분들은 영상과 함께 보시면 재미가 배가되지 않을까 합니다.

한글 번역 : https://www.youtube.com/watch?v=QKSKqm0PPnk

YouTube

커리어 코칭 일기 (Work & Tech) 712

채용과 모집의 차이를 아십니까? 채용은 인재를 영입하여 고용하는 것입니다. 모집은 인재를 훈련 기관에 입소시키거나 플랫폼에 일자리를 연결하는 것입니다. 그러니까 모집은 직접 채용이 아니라 필요에 의해 선발하는 과정을 의미합니다.

모집도 채용과 마찬가지로 선발 기준이 있습니다. 물론 채용보다 모집 기준이 높지 않습니다. 모집은 일정 기간 동안 채워야 하는 인원 숫자가 분명하기 때문입니다. 모집 기간 내에 기대하는 인원수가 채워지지 않을 때 기준에 약간 부합하지 않더라도 숫자를 채우기 위해 더 노력합니다.

모집이 어려운 이유는 참여하는 인원에게 줄 혜택이 명확하지만, 금전적 보상을 확답할 수는 없기 때문입니다. 플랫폼에 일자리를 연결하는 모집도 마찬가지로 시급이나 일당을 보장할 순 없습니다. ‘최선을 다해 노력해 줄 테니 믿고 우리에게 기회를 달라’는 정도가 가장 합리적인 어필입니다.

모집을 통한 교육이나 일자리 제공의 맞은편에는 결과 품질이라는 잣대가 기다리고 있습니다. 좋은 교육을 제공하여 훌륭한 일꾼으로 거듭난다면 좋겠지만, 이 또한 100% 장담할 수 없습니다. 모집은 노력으로 채울 수 있지만, 사람에게 지식을 불어넣는 일은 타의로 불가능한 미션입니다. 그래서 모집도 기준을 준수하여 인원을 선발하는 과정이 매우 중요합니다.

인원을 채워야 하는 미션과 훌륭한 결과를 만들어야 하는 미션 중 무엇이 더 중요하냐고 묻는다면 둘 다 중요하다고 답변할 수밖에 없습니다. 그래서 모집이 어렵습니다. 강태공처럼 세월을 낚는 채용 업무가 어쩌면 더 많이 양해 받고 수월한 미션인지도 모릅니다. 

각 분야의 모집 담당자님들, 파이팅입니다! 오늘도 내일도 불철주야 머리 싸매고 노력하시는 분들을 진심으로 응원합니다.

‘모집’이 어려운 이유

초점을 옮기는 가장 효과적인 방법은 질문을 활용하는 것이다. 우리가 던지는 모든 질문에 대해 뇌는 답을 내놓는다.

예를 들어 "그 사람은 왜 나를 그런 식으로 이용하는 거지?"라는 의문을 품는다면, 사실이든 아니든 자신이 어떻게 이용당했는지에 대해서만 생각하게 된다.

반면 "이 상황을 어떻게 호전시킬 수 있을까?"라고 묻는다면 분명 적극적인 대처 방법을 제시하는 답을 얻을 수 있다.

#토니로빈스 #거인의생각법
#하루한문장 📚

< 질문으로 방향 전환하기 >

  테스트 기법은 소프트웨어를 분석하고 이를 바탕으로 테스트 케이스를 도출하는 방법입니다. 품질을 전문적으로 검증하는 부서에서만 사용하는 기법은 아닙니다. 예시로 구조기반 기법의 경우, 코드 기반 테스트로 화이트박스 테스트를 수행할 수 있는 인원이 활용하거나 개발자가 수행하는 개발 단계 테스트에서도 활용할 수 있습니다. 

 테스트 설계 기법은 ‘테스트 케이스를 도출'하여 '테스트 보장성을 확보'하는데 목적과 목표가 있습니다. 테스트 수행을 위해 어떤 종류의 테스트 기법으로 케이스를 도출할지 방법론을 제시합니다. 
하지만, 실무에서는 기대하는 바와 다르게 기법에 따른 설계가 잘 작동되지 않습니다. 설계기법을 열심히 공부하고 실무에 돌아와서는 기존 방식대로 기능을 나열하는 수준으로 TC를 작성하고 사용합니다. 결제와 같은 복잡한 테스트 수행 조건과 기능들이 얽혀있는 컴포넌트와 같은 경우에는 결정 테이블이나 구조기반 기법을 사용해서 테스트 케이스를 도출하나 그 외 일반적인 기능 테스트는 대부분 설계기법이 잘 사용되지 않습니다.

이는 단순히 ‘테스트 케이스를 작성하는 방법'으로만 설계 기법을 접근하기 때문이라고 생각합니다. 

테스트 기법을 실무에 잘 활용하려면 접근 방법을 달리 생각해야합니다. 
‘테스트 케이스를 어떤 기법을 사용해서 작성' 할 것인가 하는 테스트 케이스 작성 방법론으로서 접근이 아니라, ‘전략적으로 테스트를 실행하기 위한 테스트 설계기법 활용'을 목적으로 접근해야 합니다. 
즉, 테스트에 보장성을 확보하고자 테스트 케이스를 설계기법에 따라 다양하게 도출하는 것이 아닌 프로젝트 상황에 맞는 테스트 전략을 계획하고 계획된 목표와 목적 달성에 가장 적합한 테스트 기법을 선택하여 테스트 케이스를 설계 하는 것입니다. 

예를들어 제품 출시를 위해 테스트를 계획할 때 QA는 테스트 일정(시간적 제약), 투입 인원 (보유지식/역량수준), 시스템 복잡도, 리스크 수준, 요구사항 기준 등을 고려하여 테스트를 설계합니다. 주어진 테스트 일정과 투입된 리소스가 매우 부족한 상황이라고 가정할 때, 투입된 인원을 적절히 분산하여 테스트 대상을 가능한 범위에서 빠짐없이 테스트할 것인지 또는 주요 기능에 선택&집중하여 테스트할 것인지 등 주어진 조건안에 최대한 품질을 확보할 수 있는 전략을 세우고 전략에 따라 테스트케이스를 설계할 것 입니다. QA가 최종 선택한 전략이 ‘주요 기능에 대한 선택과 집중'이라면 테스트 설계 기법 중 동등분할 기법을(입출력값 영역을 수학적 등가집합으로 만든뒤 대표값 하나를 선택해서 테스트케이스를 만드는 기법) 사용하거나 조합테스트 중 Each choice testing기법을(입력 값을 최소 한번 이상 테스트하는 기법) 사용하여 테스트케이스를 설계하는 것입니다.

❖ 전략적으로 테스트를 실행하기 위한 테스트 설계 기법 활용 Ⅰ - 명세기반 기법
  계획된 전략에 맞게 테스트 설계기법을 활용하여 테스트케이스를 작성하는 방법을 구체적으로 살펴보겠습니다. 본 장의 구성은 일반적으로 알고 있는 테스트 설계 기법 종류 중 '명세기반 기법'에 해당하는 기법의 개요과 해당 설계기법을 전략적으로 활용할 수 있는 예시로 작성하였습니다.

{{각 기법에 대한 충분한 이해를 위해 기법별로 TestCase를 작성하는 방법도 예시로 넣고싶었으나, 표와 같은 에디터 기능이 제공되지 않아서 작성 하지 못했습니다. 검색을 통해 쉽게 각 기법별 TC 작성 방법에 대한 예시를 찾아볼 수 있으니 테스트 설계기법을 공부해보고자 하시는 분들은 꼭 TC도 함께 작성해보시기 추천드립니다.}}

1. 등가(동등)분할
  시스템 입력의 결과로 나타나는 결과값이 동일한 경우 하나의 그룹으로 간주합니다. 한 그룹 내 입력값은 어떠한 값을 선택해도 항상 같은 결과를 기대할 수 있다는 것을 전제로 합니다. 등가 분할은 이 원리를 이용해서 입/출력값 영역을 수학적 등가 집합으로 만든 뒤 대표값 하나를 선택하여 테스트 케이스를 만드는 기법입니다.

예를들어 A클래스에 해당되는 입력값이 1~100이고, 결과값이 N으로 동일할 경우 1~100까지 모든 값으로 테스트 케이스를 만들지 않고 1~100 중 하나의 대표값만 선택하여 테스트 케이스를 만드는 것입니다. 클래스가 A~Z로 수가 많을 경우 입력 대표값 하나씩과 각 클래스별 출력값을 확인했다는 것이 보장되어 테스트 커버리지를 달성하게 됩니다. 테스트 담당자에 따라 하나의 대표값만 확인하기 불안해서 같은 클래스 내에 2~3개 정도 케이스를 추가 할 수 있지만 결과적으로 등가 분할의 보장성은 대표값 하나로 테스트 하는 것과 결과가 동일합니다.  

이런 특징으로 인해 등가 분할은 모든 경우의 수에서 테스트 케이스 갯수를 줄여줄 수 있습니다. 하지만 항상 같은 결과를 기대하는 것을 “가정"하여 테스트가 실행되고 테스트 강도가 약해서 실무에서는 특수한 상황(ex_입/출력값이 방대하나 테스트 일정/투입인력이 부족할 경우 샘플링테스팅 일환으로 등가 분할 기법을 사용하여 테스트를 진행)에서만 테스트 기법이 활용되고 있습니다. 

등가 분할의 또 다른 특징으로는 명세 기반 기법으로 분류되어있지만 구조기반기법/경험기반 기법에서 입/출력값이 있는 경우 모든 상황에서 기법을 활용할 수 있습니다. 또한 단위/통합/시스템/인수 테스트 등 모든 테스트 레벨에서와 기능/비기능/리그레션 등 모든 테스트 타입에서도 활용이 가능합니다.

✻ 전략을 반영한 등가 분할 기법 활용 예시
• 테스트 일정 + 투입인력이 충분할 경우, “강한 등가 분할 테스팅"으로 등가 집합 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 테스트 할 수 있도록 설계한다.
• 테스트 일정 + 투입인력이 부족할 경우, “약한 등가 분할 테스팅"으로 등가 집합에서 하나의 대표값만 선택해서 테스트 케이스를 설계한다.
• 데이터 테이블 검증 시 테스트할 데이터의 양이 몇 만건에 해당된다. 이 경우, 모든 등가집합의 조합에 대한 테스트를 수행하는 것은 비효율적이다. 약한 등가 분할 테스팅을 선택하여 등가 집합에서 하나의 대표값에 대한 테스트를 수행하도록 설계한다. 

2. 경계값 분석
  등가 분할 후 각 범위의 경계에 해당되는 입력값에서 결함이 발생되는 경우가 많다는 경험에 기반하여 결함 검출 가능성을 높일 수 있도록 경계값을 포함하여 테스트 케이스를 설계하는 기법입니다. 
경계값은 임의의 데이터를 사용하지 않고 class 경계에 있는 실 데이터를 이용합니다. 예를들어 A클래스에 해당되는 입력값이 ‘1 <= X < 100’ 일 경우 경계부분에 해당되는 최소값과 최대값, 즉 0, 1과 99, 100 이 경계값에 해당됩니다. 

    보통 경계값 분석은 하나의 기법이 단독으로 사용되지 않고 등가 분할 기법과 함께 테스트 범위 확장 형태로 함께 사용됩니다. 이렇다 보니 등가 분할과 마찬가지로 모든 테스트 레벨, 테스트 타입에 적용할 수 있고 테스트 커버리지를 보장할 수 있습니다. 

✻ 전략을 반영한 경계값 분석 기법 활용 예시
• 등가 집합에서 하나의 대표값만 선택해서 테스트하기에 테스트 강도가 약하다 판단될 경우 등가 분할 기법 + 경계값 분석 기법을 함께 활용하여 테스트 강도 및 커버리지를 확보하고 품질을 보장하는 형태로 활용한다.
• 시간/초기화 조건이 있는 이벤트 또는 컨텐츠(ex_00시 컨텐츠 초기화, 출석보상 등) 검증 시, 경계값에서 이슈가 발생되는 경험이 많다. 테스트 범위에 이런 조건이 포함되어있는 경우, 경계값 분석 기법을 적극적으로 활용한다.

3. 결정테이블 테스팅
  결정 테이블 테스팅은 발생 조건에 따른 결과를 테이블 형태로 나열한 것으로 시스템의 동작을 유발시키는 조건(conditions)과 처리(actions)의 모든 가능한 조합을 고려하고 조합에 대한 예상 결과를 포함하여 테스트 케이스를 설계하는 기법입니다. 

결정 테이블 테스팅은 요구사항을 도출하거나 내부 시스템 설계를 문서화 하는데 유용하며 명세서 또는 시스템 설계 자체를 테스트 하는데 주로 적용됩니다. 명세서의 품질이 낮다면 모든 조건과 정확한 처리를 찾기 어려울 수 있고 시스템 설계 자체에 결함이 있을수 있어 테스트 전문가의 시각에서 결정 테이블 기법을 적용한 테스트 케이스를 설계하는 것만으로도 개발 초기 명세서와 내부 시스템에서 오류를 발견할 수 있습니다. 

한가지 유의할 점은, 결정 테이블 테스팅을 전체 시스템에 적용할 경우 너무 많은 경우의 수가 도출될 수 있어서 가급적 해당 기법은 중요한 코어 시스템에서만 사용하는 것을 권장해드립니다. 

✻ 전략을 반영한 결정 테이블 테스팅 기법 활용 예시
• 결정 테이블 기법을 활용하여 테스트를 수행하기 전 명세서와 시스템 설계 단계에서 결함을 발견하여 개발 초기 단계부터 품질을 향상할 수 있다   
• 일정 이슈 등으로 유효 케이스에 대한 테스트만 진행이 가능한 상황일 경우 모든 가능한 동작을 유발하는 조건의 조합을 커버할 수 있어서 결정 테이블 테스팅 기법이 유용하다  

4. 상태전이 테스팅
  명세를 구성하는 모델이 ‘상태 다이어그램'이라면, 소프트웨어가 상태 다이어그램에 맞게 구현되어있는지 확인하기위해 상태 전이 테스팅 기법을 사용하여 모든 입출력 상태의 입력 조합과 상태간에 전이되는 것, 상태를 변화 시키는 이벤트와 상태의 변화로 유발되는 동작까지 보장하는 테스트 케이스를 생성할 수 있습니다.

✻ 상태 전이 테스팅 기법으로 테스트케이스를 설계하는 방법
 [1] 상태 전이 기법으로 테스트 케이스 도출  
- 전형적인 상태의 순서를 커버하는 방식              
- 특정한 상태 전이 순서를 실행하는 방식
- 모든 상태를 커버하는 방식(유효케이스)
- 불가능한 상태 전이를 테스트 하는 방식 (비유효 케이스)
- 모든 상태 전이를 커버하는 방식
테스트 전략에 따라 하나만 선택 또는 복수 선택으로 설계 할 수 있습니다.

[2] 도출된 테스트 케이스로 연속된 테스트 시나리오 작성 
    상태 전이 테스팅 기법으로 테스트 케이스를 설계할 때 유의해야 할 사항은 테스트 효율성을 높이고 더 깊이 있는 테스트 결과를 얻기 위해 테스트 실행 순서를 연속된 상태 전이를 이어서 테스트 할 수 있도록 테스트 시나리오를 작성해야 합니다. 
상태 전이 테스팅 기법을 사용해서 테스트 케이스를 도출하고 도출한 순서대로 순차적으로 테스트를 수행하는 것이 아니라 테스트 수행 절차가 연속된 시나리오를 가지고 테스트가 실행될 수 있도록 작성되어야 하는 것입니다. 
예를 들어, 상태전이 기법으로 도출된 테스트 케이스가 아래와 같다면,
   TC 1) 1 → 2 → 4
   TC 2) 1 → 3 → 5
   TC 3) 4 → 6
연속된 상태 전이를 이어서 테스트 수행할 수 있도록 테스트 시나리오를 작성해야합니다.
   TC 1) 1 → 2 → 3 → 4 
   TC 2) 3 → 4 → 5 → 6

✻ 전략을 반영한 상태 전이 기법 활용 예시
• 테스트 일정 + 투입인력이 충분할 경우, 모든 상태 전이를 커버할 수 있도록 설계한다.
• 개발자 테스트 또는 스모크 테스트 또는 리그레션 테스트로 사용하는 경우, 전형적인 상태 전이를 커버할 수 있도록 설계한다. 
• 일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효+비유효 상태를 커버할 수 있도록 설계한다. 
• 기획/개발 담당자의 보유 지식/경험이 부족한 경우, 특정한 상태 전이를 추가로 설계하여 예외처리에 대응할 수 있도록 테스트 케이스를 설계한다.

5. 유즈케이스 테스팅
  유즈 케이스 또는 시나리오 테스팅은 유저와 시스템 사이 상호작용을 사용자의 시각에서 표현한 시나리오이며, 비즈니스 시나리오 또는 프로세스 흐름을 기반으로 테스트 케이스를 설계하는 기법입니다. 
유즈 케이스는 시스템을 실제로 사용하는 행위의 절차로 기술되기 때문에 흐름상 예상하지 못했던 정보나 존재할 수 있는 결함을 발견할 수 있고 인수테스트나 통합 테스트 단계에서 각각의 컴포넌트 사이의 상호작용으로 발생되는 결함을 발견하는데 유용합니다. 

  유즈 케이스 테스팅 기법이 “사용자 시각에서 표현"되는 시나리오다 보니 작성자의 경험치/역량수준/보유지식에 따라 시나리오 품질과 해석의 차이가 발생될 수 있고 표준으로 사용할 수 있는 테스트 케이스도 존재하지 않아서 해당 기법 사용시 일정 수준의 품질 결과를 얻을 수 있도록 작성에 각별히 유의해야 합니다.

시나리오 품질과 해석의 차이를 줄이기 위한 방법으로 다른 테스트 기법을 활용하여 시나리오를 작성하는 것도 좋은 방법이 될 수 있습니다. 
예를들어 시스템 레벨 시나리오 테스팅은 ‘상태 전이 테스팅 기법'을 활용하여 수행순서(흐름)을 전이로 간주하여 시나리오를 작성하거나, 단위 레벨 시나리오 테스팅은 결정테이블/등가분할&경계값 분석/구조기반기법 등을 활용할 수 있습니다.

✻ 전략을 반영한 유즈 케이스 테스팅 기법 활용 예시
• 상태는 다르나 수행 순서(흐름)에 반복이 많은 경우 상태 전이 기법의 테스트 케이스 도출 전략을 활용하여 흐름의 반복 횟수를 줄여 제한적으로 커버리지를 달성 할 수 있도록 테스트 케이스를 설계한다. 
   a) 테스트 일정 + 투입인력이 충분할 경우, 전형적인 상태 순서 + 모든 상태 전이를 커버할 수 있도록 설계
   b) 일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효케이스의 상태 전이를 커버할 수 있도록 설계
• 입력값의 조합 수가 많은 경우 등가 분할+경계값 분석 기법 활용 또는 조합 테스팅 기법을 활용하여 테스트 케이스를 설계한다.

6. 조합 테스팅
  조합 테스팅은 입력값을 조합해서 최대 커버리지를 가지는 최소 개수의 테스트 케이스를 설계하는 기법입니다. 
잠재적 조합 요소의 거대한 양을 처리하기 위해 테스트 케이스를 선정하는데 도움을 주는 통계적 테스트 기법으로 테스트 할 입력값의 양에 따라 All Combinations Testing, Pairwise Testing, Each Choice Testing으로 분류되며 이 중 대표적인 조합 테스팅인 페어와이즈 기법은 대부분 결함이 2개 요소의 상호작용에서 발생된다는 경험에 기반하여 테스트 하는데 필요한 각 값들이 최소한 한번씩은 조합을 이루도록 설계하는 기법입니다. 

    조합 테스팅은 의도적으로 테스트 케이스 수를 줄여서 테스트 하는 기법인 만큼 리스크 수준이 높지만 입력값의 누락없이 잘 조합된 최소 개수의 테스트 케이스로도 일정 수준의 품질은 보장될 수 있습니다. 그래도 가급적 pairwise 기법과 each choice 기법은 일정 및 투입 리소스가 부족한 상황 등 제한적인 테스트 환경에서만 사용할 것을 권장합니다.

✻ 조합 테스팅 기법 종류  
All Combinations Testing
: 입력값의 모든 조합을 모두 테스트 
Pairwise Testing
: 입력 값의 모든 쌍의 조합이 TC내에 최소 한번 이상 들어가도록 설계
Each Choice Testing
: 입력 값을 최소 한번 이상 테스트

✻ 전략을 반영한 조합 테스팅 기법 활용 예시
• 테스트 일정 + 투입인력이 부족할 경우,  Pairwise 또는 Each Choice 기법으로 테스트 케이스를 설계한다.
• 테스트 투입 인력에 테스트 전문가 또는 테스트 리더가 포함된 경우, 주어진 입력값 외 경험에 기반하여 의미있고 결함이 발견될 가능성이 높다고 판단되는 입력값(유효/비유효 포함)도 포함하여 테스트 케이스를 설계한다.
--
테스트 설계 기법을 전략적으로 테스트를 실행하기 위한 활용방법의 목적으로 접근해본 이유는, 이렇게 좋은 설계 기법들이 실무에 잘 사용되지 않는것이 늘 아쉬웠기 때문입니다. 무엇이 문제여서 쉽게 접근하기도, 사용하기도 어려운 것인지..오랜 시간 고민했던 것 같습니다. 그에 대한 개인적인 해답을 얻은 것이 우리가 너무 방법론적으로만 설계기법을 인식하고 있기때문이 아닌가라는 결론에 이르게 된것이었고, 테스트 전략에 맞춰 테스트를 효율적으로 수행하는 것과 유용한 품질의 제품을 얻기위한 방법으로 설계 기법을 활용했을때 만족스러운 결과를 얻을 수 있었습니다. 

별것 아닐수 있지만 경험을 통해 얻은 바를 공유하고자 한 것은, 
그 내용이 너무 자그마하지만(너무 작아서 귀여울 지경인..) 지금도 현장에서 저와 같은 고민을 하고 있을 동료나 후배QA들에게 이 글을 읽기 이전보다 업무를 좀 더 효율적으로 수행할 수 있게되고, 효과적인 결과를 얻을 수 있는데 도움이 될 수있지 않을까하는 바램으로 글을 공유해봅니다.

전략적 테스트 실행을 위한 테스트 설계 기법 활용 Ⅰ : 명세기반 기법

Dr. Kathleen Allen explores topics relating to Leading from the Roots, which will be released in 2018, as well as innovations in emergent practices in organizational leadership.

The Iceberg of Ignorance - Dr. Kathy Allen

회사 내 직책 레벨별로 팀이 마주한 문제들을 어디까지 인지하느냐에 대한 흥미로운 이야기입니다.

무지의 빙산(The Iceberg of Ignorance)은 고위 경영진이 문제를 이해할 수 있는 수준과 문제가 위로 전달되지 않는 과정을 설명한 1989년에 진행된 연구에요.

✅ 임원: 4%의 문제를 인지하고 있음
✅ 중간관리자: 9%의 문제를 인지하고 있음
✅ 관리자: 74%의 문제를 인지하고 있음
✅ 실무: 100%의 문제를 인지하고 있음

이걸 보면 참여적이고 진실을 마주하길 꺼리지 않는 조직 문화를 만들어서 빙산의 크기를 줄여야 한다는 관점도 좋은데요, 저는 임원이 100%의 문제를 이해하는 게 과연 좋은 걸까 생각을 해봅니다.

임원에게 4%의 문제만 도착하더라도 정말 중요한, 임원 레벨에서 다뤄야 할 고품질의 문제들(?)이 도착하도록 조직 문화를 만드는 게 좋지 않을까, 왜냐하면 임원은 다른 제품과 프로젝트, 회사 밖에서 일어나는 문제들을 바라봐야 할 테니까.. 하는 생각입니다.

고품질의 문제가 위로 누락 없이 올라가기 위해선 managing-up 기술이 조직원 모두에 필요한 역량이 될 것 같습니다. 문제의 중요도에 관련 없이 자기가 겪는 문제들을 줄줄이 읊기만 하는 보고 시간은 정말 지루하기 짝이 없으니까요.

요거 정말 재밌네요:)

Dr. Kathy Allen

🧊 무지의 빙산

구글이 25주년을 맞이해 구글 두들을 공개했습니다. 구글 두들은 특별한 기념일이나 사건을 검색 엔진인 구글의 대문에 거는 것입니다. 자사의 워드마크인 'Google'을 다양한 이미지로 변형하거나 미니게임 등 이스터 에그를 넣기도 합니다. 세르게이 브린과 레리 페이지는 90년대 후반 스탠포드 대학에서 만났습니다. World Wide Web으로 세상이 긴밀하게...

구글 25주년 두들: 25년 디자인 트렌드가 담긴 구글 로고의 역사

구글 두들은 특별한 기념일이나 사건을 검색 엔진인 구글의 대문에 거는 것입니다. 자사의 워드마크인 ‘Google’을 다양한 이미지로 변형하거나 미니게임 등 이스터 에그를 넣기도 합니다.

세르게이 브린과 레리 페이지는 90년대 후반 스탠포드 대학에서 만났습니다. World Wide Web으로 세상이 긴밀하게 연결될 것이며 검색 엔진이 중요하리라 생각했습니다. 임대 차고에서 쉬지 않고 개발하며 1998년 9월 27일 Google Inc.가 탄생했습니다. 그리고 25년이 지난 지금 여전히 전 세계 수십억 명의 사람들이 정보를 보편적으로 접근가능하고 유용하게 만드는 사명을 유지하고 있습니다.

https://designcompass.org/2023/10/04/google-25th-doodle/

디자인 나침반

1 경제 일간지를 보기 시작한지 3개월째다. 종이신문은 빠르게 넓은 관점을 갖는데 도움을 준다. 2 매일 아...

신문배달의 디테일에서 배우는 고객 만족

1
경제 일간지를 보기 시작한지 3개월째다. 종이신문은 빠르게 넓은 관점을 갖는데 도움을 준다.

​

​
2
매일 아침 현관문을 열면 매번 같은 각도로 신문이 놓여있다. 내가 보는 각도로 똑바르게. 세달동안 단한번도 흐트러진 적이 없다.

​

​
3
신문을 집어들때마다 기분이 좋다. 흔히 말하는 고객중심은 특별한게 아니다. 고객 관점의 이런 디테일이다. 작은 배려가 훨씬 큰 만족을 준다.

​

​
4
디테일이 그렇게 중요하냐고? 그렇다. 쿠팡과 컬리는 언제나 박스를 그저 신문 위에 쌓아두고 간다. 옆에 두는게 어려운 일도 아닌데 말이다. 박스를 옮기고 짖눌린 신문을 집어들 때의 기분이 좋을리 없다.

​

​
5
사소한 무심함은 큰 불쾌함을 만들 수도 있다. 그 레버리지는 반대로도 작용한다. 새벽마다 신문을 넣어주시는 분께 감사한 마음이다.

네이버 블로그 | 가장 보통의 스타트업 CEO

< 고객 만족은 디테일에서 온다 >

01. 10월의 첫 영업일(?)이 되었습니다. 출근 일이 시작되었다는 얘기죠. 제가 쓰는 글을 주욱 봐 온 분들은 아시겠지만 저는 이맘때쯤 되면 늘 하는 말이 있습니다. 네 맞습니다. 드디어 올해의 4쿼터이자 마지막 분기인 10월이 시작되었다는 사실이 바로 그것이죠. 

02. (이제 좀 지루하신 분들도 있겠지만) 저는 언제나 정해진 기간을 전반전과 후반전으로 쪼개는 걸 좋아합니다. 그래서 일 년을 크게 상반기와 하반기로 나누고 그중에 하반기가 도래하면 다시 하반기의 전반전과 후반전을 나누죠. 그러니 지금은 하반기에서도 후반전, 잘 아시다시피 2023년의 마지막을 장식할 4쿼터에 들어선 셈입니다.

03. 10월은 잔인한 달입니다. 새로 뭔가를 시작하기엔 너무 촉박한 것 같고, 그렇다고 남은 기간에 온 힘을 쏟아붓기엔 또 서글픔이 밀려오는 시점이기 때문이죠. 제 친구에게 이 얘길 했더니 10월은 마치 '스물아홉 살' 같다는 이야기를 했습니다. 
'뭐 했다고 벌써 스물아홉 살이 되었나' 싶다가도 한편으론 '나도 이제 30대를 준비해야 하는구나' 하는 시점을 몸소 체감하게 되는 지점이라는 거죠. 이 말에 굉장히 크게 공감한 기억이 있습니다.

04. 좀 다른 얘기지만 2007년에 방영한 '9회 말 2아웃'이라는 드라마가 있습니다. 이제 거의 15년이 훌쩍 지난 작품이죠. (너무 고전이군요... 암튼) 거기엔 이런 대사가 나옵니다.
"내 인생 최고의 사치는 오늘 이 자리가 아니라... 이미 경험해 버린 걸지도 몰라. 당연하게 지나쳐 온 청춘 그 하루하루였었을지도 모르지. 청춘과 안녕을 고하려는 이제야 그 중요한 사실을 깨달았어. 언제나 그래. 무언가를 깨달았을 때는 이미 늦는다는 거."

05. 네. 꽤 잔인하지만 어쩌면 지금 우리의 처지와 참 닮았을지 모릅니다. 아마 거리에 캐럴이 울려 퍼지고 스타벅스에서 플래너를 나눠주기 시작할 시점이면 지금 이 10월의 초반이 그리워질지 모릅니다. 
'차라리 그때라도 뭘 해볼걸', '그때라도 방향을 틀어서 다른 선택지를 바라볼걸', '그 즈음부터 신발끈 조여매고 달렸었더라면 지금은 뭐라도 결과물이 나오지 않았을까' 같은 생각을 하기 마련이거든요. 그런데도 우리는 지금 이 시점에서 그런 관점을 갖지 못합니다. 왜냐면 우린 이 계절을 즐기기에도 바쁘기 때문이죠.

06. 일본 극작가인 '요시이 이사무'는 "우리가 한 계절만 앞서 살 수 있어도 저무는 오늘을 안타까워하지 않을 텐데..."라는 말을 남겼습니다. 이 말을 조금 각색해 보자면 '우리가 한 쿼터(1/4)만 먼저 인지하고 대응할 수 있어도 연말에 그렇게 후회하지는 않을 텐데'로 바꿔쓸 수 있지 않을까 싶어요. 여름에서 가을을, 가을에서 겨울을 가늠할 수 있다는 건 두 발을 땅에 딛고도 다가오는 내일을 맞이하는 담담함을 가진 거란 얘기일 테니 말이죠.

07. 말이 좀 돌고 돌았지만 저는 추석 연휴가 끝난 지금, 그리고 4분기에 본격적으로 접어든 지금이야말로 우리 자신에게 연하장을 보내야 하는 시점이라고 생각합니다. 지금 발송한 연하장은 12월이 되어서야 우리에게 다다르겠지만 그 기간이 눈 깜짝하면 지나있을 시간이라는 건 모두가 동의할 테니까요, 적어도 남은 3개월 남짓을 어떻게 살아야 할지 고민해야 하는 시점임은 분명해 보입니다. 

08. 그마저도 벅차다면 또 하나 옵션이 있습니다. 바로 남은 이 4분기 역시 전반전과 후반전으로 구분해 보는 겁니다. 오늘부터 딱 11월 15일까지 할 수 있을만한 것들을 리스트업 해보고 이를 달성하기 위한 계획을 세워보는 것은 어떨까 싶어요. 그럼 11월 14일에 남은 후반전을 맞이하는 느낌은, 그걸 기획해 본 사람과 아닌 사람의 차이만큼 클 테니 말이죠. 쪼개고 쪼개서 더 이상 쪼갤 수 없는 원자의 수준에 이른다고 해도 전반전과 후반전이 주는 매력은 여전히 유효할 거라는 게 제 개인적인 생각이기도 하거든요. 

09. 저는 '간절기'라는 말을 좋아합니다. 계절과 계절 사이라는 이 말은 어찌 보면 일종의 그레이 존(Gray Zone)이라는 생각도 들고요. 
잘 알다시피 그레이 존은 활용하기 나름입니다. 누군가는 그냥 지나쳐가는 지점일지 몰라도 또 누군가에게는 더없이 훌륭한 기회가 될 수 있거든요. 이 간절기의 끝을 붙잡고 얼마 되지 않는 기간 동안 내가 할 수 있는 일들을 리스트업 해보는 것도 정말 의미 있는 일이 될 거라고 봅니다. 어쩌면 그게 우리를 성장하게 만드는 것일지도 모르기 때문입니다. 

10. 절반을 의미하는 'half'는 그 어원이 불분명한 단어로 구분되지만, 언어학계의 추론에 따르면 '자르다'에서 왔다는 가설이 힘을 얻고 있습니다. 보충 설명을 하자면 반으로 쪼개는 것에 집중한 게 아니라 뭔가를 자른다은 지금 내 앞에 남아있는 것에 집중한 게 'half'가 되었다는 거죠. 
그런 의미에서 보면 1,2,3 분기 모두 시원하게 말아 드셨더라도 지금 내 눈앞에 남아있는 이 4분기, 마지막 쿼터에 힘을 실어볼 수도 있는 겁니다. 그게 내 몫이자 내 결과물일 수 있을 테니 말이죠. 
그러니 연휴가 지난 이후 후유증이 오려고 할 때쯤엔 이런 마인드를 가져보는 것도 좋습니다. '이제 진짜 내가 집중할 수 있는 마지막 half and half가 남았다'고 말이죠.

하반기의 하반기, 2023년은 이제 시작일 지 모릅니다.

혼자서 소개팅 앱을 운영하며 월 1000만원의 순수익을 벌어가는 한국인 개발자 (feat. 2년 동안 버텼다)

네이버, 카카오에서 개발자로 일하다가, '커피한잔'이라는 사이드 프로젝트를 통해 독립에 성공하신 재호님의 인터뷰입니다. ('건물주의 기쁨과 슬픔'이라는 책을 쓰신 분이기도 하구요.  예전에 김단테님 유튜브 게스트로 나오신 적도... ㅎㅎ)  재호님 트위터를 팔로우하면서 올려주시는 글들 재미있게 읽고 있는데, 모처럼 인터뷰에 등장하신 걸 보고 반가운 마음에 공유합니다.

차우진의 TMI.FM

[커피한잔 창업자 재호님 인터뷰]

일론 머스크에 대한 기사들 혹은 인터뷰를 들어보면 빠지지 않는 이야기가 있죠. 바로 일론의 '공학적 역량' 에 대한 찬사입니다. 위대한 경영자이자 부자로 알려져 있지만, 사실 테슬라부터 스페이스 X까지 그의 손길이 닿지 않은 제품은 없습니다. 테슬라의 디자인 헤드로서 오리지널 '로드스터' 설계에 직접 참여했고, 스페이스 X의 CTO로서 뛰어난 엔지니어들과 함께 로켓 설계 및 개선에 힘쓰고 있죠.

설계보다 생산이 훨씬 더 어렵습니다 (일론 머스크)

일론 머스크에 대한 기사들 혹은 인터뷰를 들어보면 빠지지 않는 이야기가 있죠. 바로 일론의 '공학적 역량' 에 대한 찬사입니다. 위대한 경영자이자 부자로 알려져 있지만, 사실 테슬라부터 스페이스 X까지 그의 손길이 닿지 않은 제품은 없습니다. 테슬라의 디자인 헤드로서 오리지널 '로드스터' 설계에 직접 참여했고, 스페이스 X의 CTO로서 뛰어난 엔지니어들과 함께 로켓 설계 및 개선에 힘쓰고 있죠. 심지어 로켓에 관련된 모든 지식은 어떤 학위 없이 직접 독학했다고 합니다. 

일론은 무대에서 더 나은 스타쉽을 만들기 위한 치열한 고민을 공유합니다. 핵심 개발자 혹은 실무를 담당하는 엔지니어가 아니라, CEO가 직접 나와서 설명합니다. 우주선의 재료 선정이나 설계의 중요성처럼 모든 실무를 훤히 꿰뚫고 있지 않으면 나올 수 없는 디테일도 덧붙이죠. 직접 고민해보지 않았다면 절대 나올 수 없는 깊이입니다. 인터뷰 내내 감탄을 금치 못했습니다. 큰 그림부터 디테일까지 모든 것을 아는 리더. 자신이 모르는 건 끝까지 파고드는 리더. 살아있는 동안 얼마나 많은 혁신이 이런 리더와 유능한 인재들에 의해 탄생할까요?

연휴가 끝나가네요. 연휴가 시작되도, 끝나도 항상 같은 마음입니다. 오늘도 즐거운 밤 되시길 바랍니다. 

번역 : https://www.youtube.com/watch?v=yjccsHwl0dc

쿠키 1부: HTTP로 설명하는 쿠키(cookie)

“쿠키는 클라이언트에 저장되고… 음,,, 보안에 좋지 않습니다.” 😅

개발자 면접을 볼 때 쿠키에 대해서 물어보면 가장 흔하게 들을 수 있는 대답인데요. 완전히 틀린 말은 아니지만 뭔가 알맹이가 빠진 느낌이 듭니다.

“그럼 보안을 위해서 쿠키는 안 쓰는 게 좋겠네요?”

라고 반문을 하면 오랫동안 웹 개발을 한 분들도 머뭇거리시는 경우가 많은데요. 아무래도 대부분의 서버 프레임워크에서 쿠키를 직접 다루지 않아도 되도록 추상화 잘 되어 있기 때문에 오히려 쿠키를 직접 다루거나 쿠키에 대해 깊이 생각해볼 기회가 많지 않아서 그런 것 같습니다.

사실 쿠키는 웹에서는 빼놓을 수 없는 핵심적인 기술이죠? 프런트 개발을 하든 백엔드 개발을 하든 웹 개발자로서 쿠키를 제대로 이해해두시면 두고두고 유용한 지식이 될 거라 생각합니다. 그래서 2개의 포스팅에 걸쳐서 쿠키를 기술적으로 깊게 파해쳐보려고 합니다. 🔪

첫 번째 포스팅에서는 쿠키가 어떻게 서버와 브라우저 간에 이동을 하는지, 그리고 쿠키의 유효 기간과 적용 범위를 설정하는 방법과, 쿠키의 한계와 대체 기술에 대해서도 살펴보겠습니다.

📝 포스팅: https://www.daleseo.com/http-cookies/

우리가 웹에서 쿠키를 사용할 수 밖에 없는 결정적인 이유인 세션 기반 사용자 인증에 대해서는 아래 두 번째 게시물을 참고 바랍니다.

🎵 쿠키 2부: 세션은 쿠키가 필요해: https://careerly.co.kr/comments/91233

Daleseo

쿠키 1부: HTTP로 설명하는 쿠키 🍪

이번 포스팅에선 아주 중요하지만 프로그래밍 교육 과정에서 크게 다루지 않는 보안 에 대해 이야기 해보려고 한다. 최근엔 프레임워크나 라이브러리 차원에서 잘 막아주기 때문에 큰 언급없이 넘어가는 경우가 많지만 소프트웨어 개발자는 꼭 보안 전문가가 아...

웹 개발을 위해 꼭 알아야하는 보안 공격

보안은 웹 개발에서 굉장히 중요한 분야 중 하나지만, 프로그래밍 교육이나 개인 포트폴리오로 프로젝트를 진행할 때 크게 다루지 않는걸 종종 보곤 했습니다.

아마도 요즘 사용하는 프레임워크나 라이브러리에서 대부분의 보안 공격이나 실수에 대해 방어할 수 있도록 구현이 잘 되어있기 때문이겠습니다만

웹 개발자 혹은 소프트웨어 개발자라면 보안 전문가 수준까진 아니더라도 기초적인 보안 공격에 대한 이해와 이를 방어할 수 있는 방법을 알아둠으로써 혹시나 발생할 수 있는 실수를 사전에 막을 수 있어야 합니다.

오늘은 알아두면 나중에 반드시 도움이 되는 보안 공격에 대해 잘 정리된 글이 있어 공유드립니다.
글에서 언급된 대표적인 보안 공격을 요약하자면 다음과 같습니다.

📌 SQL Injection
서버에서 실행되는 SQL을 악의적으로 이용하는 공격입니다. 
이름처럼 기존 SQL에 악의적인 SQL 구문을 삽입하여 데이터 탈취, 삭제 등을 할 수 있습니다.

📌 Cross-Site Scription (XSS)
웹 페이지에 악성 자바스크립트를 삽입하는 공격입니다. 
최근엔 SPA(Single-Page Application)로 배포되는 서비스가 많은데, 이렇게 배포되는 서비스 대부분이 인증 관리를 위해 토큰을 Cookie 혹은 localStorage 에 저장합니다. 
이때 XSS 방어 준비가 되어있지 않은 경우 자바스크립트를 통해 불특정 다수의 사용자 토큰을 손쉽게 탈취 할 수 있습니다.

📌 CSRF Attack
Cross-Site Request Forgery라고 부른다. 공격자가 서비스 사용자를 이용하여 요청을 보내는 공격을 말합니다.
예를 들어 네이버 로그인과 똑같은 화면을 제공하는 피싱 사이트를 사용자가 피싱 사이트인 것을 모르고 아이디와 비밀번호를 입력하고 로그인 버튼을 누른다면 피싱 사이트는 진짜 네이버 로그인 URL 에 요청할 수 있게 됩니다. 
만약 CSRF 에 대한 방어가 제대로 안되어 있다면 성공/실패 Response 가 내려올 것이고 이를 통해 해커는 성공한 계정 정보를 판단하여 탈취할 수 있습니다.

📌 Command Injection
쉘을 실행시키는 로직을 이용한 공격으로 시스템 권한이 탈취되는 것이나 마찬가지기 때문에 매우 치명적입니다.
각 언어마다 쉘 명령을 실행할 수 있는 API 가 존재하는데 이러한 API 를 해커가 호출할 수 있게 방어가 안되어있다면 치명적인 결과를 불러올 수 있다.

📌 File Upload Attack
공격 스크립트가 담긴 파일을 서버로 업로드하는 공격입니다. 
WebShell 이 가능한 코드가 담긴 파일을 업로드하고 해커가 URL을 통해 접근 가능해지면 Command Injection 과 같은 효과를 볼 수 있습니다.

📌 JavaScript Injection
브라우저에서 자바스크립트를 삽입시키는 공격입니다. 
브라우저에서 제공하는 Console 을 통해 Javascript 코드 조작이 가능하기 때문에 Client-Side 에 민감한 데이터를 넣어놨다면 해당 공격을 통해 탈취가 가능합니다.

📌 DDoS
꽤 유명한 보안 공격중 하나입니다.
Distributed Denial of Service 라고 부르는데, 직역하면 분산 서비스 거부 공격이라고 할 수 있습니다. 
이름처럼 분산된 시스템을 이용하여 서버에 비정상적으로 많은 트래픽을 보내 마비시키는 공격입니다.
공격자는 수 많은 PC 를 이용하여 서버에 트래픽을 보내는데 몰래 심어 놓은 좀비 PC 를 이용할 수도 있고 본인이 사용할 수 있는 PC 를 이용할 수도 있습니다. 
많은 트래픽이 발생하기 때문에 공격을 받는 서비스는 부하가 생겨 느려지거나 서버가 죽을 수 있습니다.

📌 Dictionary Attack
미리 데이터베이스에 등록해놓은 수많은 문자열을 암호로 대입하는 공격으로 Brute Force의 일종입니다.
"하나만 걸려라" 공격이라고도 볼 수 있는데 많은 웹 사이트에서 간단한 단어로 비밀번호를 등록하지 못하게 하는 이유기도 합니다.

📌 Rainbow Table
평문을 해시 함수로 만든 문자열을 모두 저장시켜 놓은 표를 가지고 탈취한 계정 데이터의 암호 원문을 알아내는 공격입니다.

각 보안 공격에 대한 대응 방법과 주의사항등은 공유드린 원문에 자세히 설명되어있으니 관심있으신 분들은 참고해주시면 좋겠습니다.

📚 원문
- https://kciter.so/posts/basic-web-hacking

📚 함께보면 좋은글
- 🔐 암호화의 종류: https://careerly.co.kr/comments/89377?utm_campaign=self-share

kciter.so

🔐 웹 개발을 위해 꼭 알아야하는 보안 공격

Swagger는 API 문서를 쉽고 자동으로 작성하는 데 도움이되는 강력한 도구입니다. 이 기사에서는 Swagger를 사용하여 프로젝트의 API 문서를 자동으로 생성하는 방법을 살펴 봅니다.

Swagger는 소프트웨어 개발 커뮤니티에서 널리 사용되는 개방형 표준화 된 API 개발 프레임 워크입니다. API를 자동으로 쉽게 작성, 설계 및 문서화하는 도구를 제공합니다. Swagger는 JSON 또는 YAML 파일을 사용하여 API를 설명하고 아름답고 이해하기 쉬운 API 문서를 생성합니다.

✌️Swagger를 사용하여 API 문서를 작성하는 방법:

✅ API 정의 : JSON 또는 YAML 파일을 사용하여 경로, HTTP 메소드, 매개 변수, 설명 및 기타 관련 요소를 지정하여 API를 정의 할 수 있습니다.

✅ API 문서 생성 : Swagger 도구를 사용하면 API 정의에서 API 문서를 자동으로 생성 할 수 있습니다. Swagger는 JSON 또는 YAML 파일에 정의 된 정보를 사용하여 API의 리소스, 메소드 및 매개 변수에 해당하는 API 문서 페이지를 생성합니다.

✅ API 문서 표시 : Swagger에서 생성 된 API 문서는 아름답고 친숙한 사용자 인터페이스를 통해 액세스 할 수 있습니다. 사용자는 API와 관련된 리소스, 메소드, 매개 변수 및 기타 정보를 쉽게 볼 수 있습니다.

✌️Swagger를 사용하여 API 문서를 만들면 다음과 같은 이점이 있습니다:

✅ 문서 생성 프로세스 자동화 : Swagger를 사용하면 API 정의에서 API 문서를 자동으로 생성하여 수동 작업을 줄이고 시간을 절약 할 수 있습니다.

✅ 읽고 이해하기 쉬운 문서를 작성하십시오. Swagger는 표준 형식, 명확한 구조로 API 문서를 작성하며 읽기 쉽습니다. 이를 통해 사용자는 API의 중요한 측면을 쉽게 파악할 수 있습니다.

✅ 상호 작용 성 및 테스트 가능성 향상 : Swagger에서 생성 된 API 문서는 사용자 인터페이스에서 직접 API를 테스트 할 수있는 기능을 제공합니다. 이것은 상호 작용 성을 높이고 테스트 시간을 줄이는 데 도움이됩니다.

✅ 소스 코드와 문서 동기화 : Swagger를 사용하면 API 문서를 소스 코드와 동기화 할 수 있습니다. 소스 코드가 변경되면 Swagger는 수동으로 수행하지 않고도 해당 문서를 자동으로 업데이트 할 수 있습니다.

✅ API 문서를 수동으로 작성하려면 많은 시간과 노력이 필요합니다. 그러나 Swagger를 사용하면이 프로세스가 자동화되어 아름답고 이해하기 쉬운 API 문서를 쉽게 만들 수 있습니다. Swagger를 사용하여 프로젝트에 대한 API 문서를 작성하고이 프로세스를 자동화하는 이점을 누리십시오.

Swagger 홈페이지 👉 https://swagger.io
Swagger Gin-Golang 👉 https://github.com/swaggo/gin-swagger

모든 기사는 실제 작업에서 수행, 경험 및 사용한 후의 개인적인 견해입니다. 잘못된 정보와 혼란이있는 경우 모든 사람이 아래 의견에 의견을 제시 할 수 있기를 바랍니다.👇👇👇

Swagger를 사용하여 API 문서 자동 생성

Developers and Open Source authors now have a massive amount of services offering free tiers, but it can be hard to find them all to make informed decisions.

Free for Developers

프리티어(free tiers)로 사용할 수 있는 소프트웨어(SaaS, PaaS, IaaS...) 등을 정리해둔 사이트입니다. 토이 프로젝트나 작은 프로젝트에서 활용하기 좋을 정보가 많네요!

https://free-for.dev

Free-for

📌 무료로 사용할 수 있는 개발 도구들

한빛미디어

한빛 MSA 시리즈의 하나로 깃헙 코파일럿 특강이 올라왔습니다! 

코파일럿이 무엇인지, 어떻게 사용할 수 있는지, 그리고 어떠한 자세로 우리가 AI 어시스턴트를 이용해야할지에 대해서 풀어보았습니다 :) 

https://www.hanbitn.com/product/msa2003-copilot/

https://www.hanbitn.com

코딩 친구 넘어 코딩 선생님으로, GitHub Copilot

번(Bun) 1.0이 출시되며 많은 관심을 받고 있습니다. 이 글은 번을 사용해서 간단한 리액트 SSR 프로젝트를 만들어 볼 수 있는 가이드입니다. 아직 번을 사용해 프로젝트를 만들어보지 못하셨다면 이 가이드를 천천히 따라와보세요:)

[번역] 번(Bun)과 리액트로 서버사이드 렌더링(SSR) 구현하기

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다. 최근 번(Bun) 1.0이 출시되며 많은 관심을 받고 있습니다. 이 글은 번을 사용해서 간단한 리액트 SSR 프로젝트를 만들어 볼 수 있는 가이드입니다. 이야기는 많이 들었지만 아직 번을 사용해 프로젝트를 만들어보지 못하셨다면, 혹은 이번 기회에 번에 대해 알아가고 싶으시다면 이 가이드를 천천히 따라와보셔도 좋을 것 같습니다:)

> 글 링크: https://velog.io/@eunbinn/server-side-rendering-ssr-with-bun-and-react

Velog

번(Bun)과 리액트로 서버사이드 렌더링(SSR) 구현하기

나 실리콘밸리를 가야겠다 (1)

안녕하세요 :)

글을 보면서 "와 정말 대단하다. 실행력 대박"이라는 말이 나온 글입니다

실리콘밸리를 가야겠다 생각하시고 실행하는 부분이 너무 인상적이였어요.

시리즈 글인데 모두 올라와서 링크 타시고 보시면 좋을 것 같아요

최근 본 글 중 실행력 제일 좋다고 생각한 글이에요

https://www.junsoor.com/silicon-valley-1

Junsoor

나 실리콘밸리를 가야겠다

ChatGPT 쓸 때 질문을 영어로 번역해 주고, 답변도 한글로 번역해 주는 번역기입니다.

프롬프트 지니: ChatGPT 자동 번역기

ChatGPT를 쓰다보면 불편한 점들이 몇가지 있는데 그런 부분들을 보완해주는
없어서는 안되는 필수 크롬 익스텐션을 3가지 소개합니다!

1/ 프롬프트 지니 : ChatGPT 자동 번역기 (필수!)

ChatGPT 입력창에 한글로 입력하면 자동으로 영문으로 전환해서 물어보고, 결과가 영어로 나오면 한글로 자동 번역해서 보여줍니다.

ChatGPT의 영문 학습량이 한글보다 많아서 더 정확한 결과를 얻으려면 영어로 프롬프트를 작성해야 할 경우가 많습니다. 

번역기를 왔다 갔다하면서 입력해야 하는 번거로움을 한방에 해결해주는 필수 익스텐션 입니다.

https://chrome.google.com/webstore/detail/프롬프트-지니-chatgpt-자동-번역기/lhkgpdljnlplgbkonflbhifackjhjmdj?hl=ko

2/ AIPRM : 원클릭 프롬프트

막상 ChatGPT를 열어서 원하는 결과를 얻으려면 프롬프트를 쓰는걸 시작하기 쉽지 않습니다. 너무 간단하게 물어보면 추상적인 답변이 나오고, 맥락을 설명 하면서 해야하는데 어떻게 효과적으로 물어봐야하는지 잘 떠오르지 않죠. 그리고 복잡하고, 구체적인 답변을 원한다면 빌드업에 많은 시간이 걸립니다.

AIPRM은 이런 프롬프트 작성의 문제를 해결해줍니다.

3600개 이상의 검증된 프롬프트를 활용해서 빠르게 원하는 질문을 만들고, 원하는 답변을 받을수 있도록 도와줍니다.

https://chrome.google.com/webstore/detail/aiprm-for-chatgpt/ojnbohmppadfgpejeebfnmnknjdlckgj?hl=ko

3/ WebChatGPT: 인터넷 액세스 가능한 ChatGPT

ChatGPT는 최신 데이터를 가지고 있지 않습니다. 

특정 시점 이전의 데이터만 학습해서 모델을 만들었고, 인터넷에 있는 정보를 실시간으로 반영하지 않습니다. 그래서 최신 정보를 물어보면 대답이 틀리거나, 모른다고 답변합니다.

WebChatGPT는 ChatGPT에게 인터넷에 접근가능하게 만들어 줍니다.

그 외에도 AIPRM 처럼 프롬프트 라이브러리를 제공하고, 검색 서비스옆에서 AI가 생성한 답변을 볼수 있게도 해줍니다.

https://chrome.google.com/webstore/detail/webchatgpt-chatgpt-with-i/lpfemeioodjbpieminkklglpmhlngfcn?hl=ko

Google

ChatGPT 사용할때 꼭 필요한 크롬 익스텐션 3가지

'따라 하기'보다는 '업의 본질'에 집중하기 : 네이버 블로그

1. 자신이 하고 있는 일의 본질이나 몸담고 있는 업의 본질을 이해하는 데는 꽤 많은 시간이 걸릴 수밖에 없다. 본질이라는 게 대충 몇 년 했다고 쉽게 알 수 있는 게 아니니까.

2. 그리고 업의 본질을 이해하기 위해선 초기 지나친 확장은 경계하는 것이 좋다. 확장하고 성장하는 것은 너무나 좋고 아름다운 일이지만, 자칫 잘못하면 이로 인해 늘어난 수많은 부수적인 일에 휩쓸려, 지금 내가 하고 있는 일의 본질이 무엇인지, 코어가 무엇인지에 대해 고민하는 것을 놓칠 수 있기 때문.

3. 그러다 보면 바쁜 업무 속에서 정신없이 지내기 마련인데, 정작 정말 중요한 일이 아니라 부수적인 일만 하다가 어느 순간 거품이 꺼져서 돌아보면 결국에는 아무것도 한 게 없는 꼴이 된달까?

4. 성장 중독이 난무하는 스타트업 씬에서 괜히 ‘(초기에는) 확장성 없는 일을 하라(Do thing that don't scale)’는 말이 나온 게 아닌 셈.

5. 지금 하고 있는 일의 본질이 무엇인지, 고객들이 우리 제품이나 회사에게 기대하는 바가 정확히 무엇인지를 이해하려면 성장보다는 본질에 대해 이해하는 시간을 가져야 하니까.

6. 그리고 정말 고객들이 원하는 것이 무엇인지, 지금 시대에 필요한 것이 무엇인지, 업의 본질이 무엇인지를 알고, 이를 구현할 실행력까지 가지고 있다면 성장은 당연히 일어나는 것 같고.

7. 다만, 여기서 정말 어려운 문제는 업의 본질이나 자신이 하는 일의 본질을 이해하는데, 그리고 고객이 정말로 원하는 것이 무엇인지를 온전히 이해하는데, 얼마의 시간이 걸릴지는 그 누구도 알 수 없다는 점이다. 10년이 걸릴지, 20년이 걸릴지, 아니면 평생이 걸릴지는 그 누구도 알 수 없으니까.

8. 그래서 사람들 중에는 업의 본질을 이해하는 데 자신의 시간과 자원을 베팅하기보다는, 지금 잘 되는 누군가를 따라 하는 일에 더 많은 시간과 자원을 베팅하는 경우가 많다.

9. 그렇게 요즘 인기 있다는 마케팅 방식을 쫓아다니고, 인기 있는 밈을 추종하며, 뭔가 그럴듯한 컨셉이 있으면 따라 하는데,

10. 물론 그렇게 해서 순간적으로 관심을 얻고, 인기를 얻는 경우는 의외로 많다. 추세와 트렌드가 가진 힘이 있으니까. 그래서 그게 콘텐츠 마케팅이든, 소셜 미디어 마케팅이든, 퍼스널 브랜딩이든, 관련한 강의를 하는 사람들 중에는 메시지의 형태는 다소 다를 수 있으나 대부분 뭔가를 보고 따라 하라는 얘기를 하는 경우가 많다.

11. 업의 본질이나 자신이 추구하는 가치의 본질이 무엇인지를 고민하고 실행하고 찾아가는 지루한 과정보다는 그게 훨씬 쉽고, 운이 좋으면 성과도 빨리 낼 수 있으니까.

12. 하지만 뭔가 잘 따라 한다고 해서 게임이 끝나는 경우는 거의 없다. 아무리 많은 관심을 얻고, 인기를 얻고, 매출을 잘 발생시켜도, 이를 유지하려면 결국에는 코어가 단단해야 하고, 끈기가 있어야 하며, 실패를 딛고 일어설 수 있어야 하는데,

13. 잘 되는 것만 따라 해서는 이 단계를 극복하지 못한다. 잘 된 것들은 너무 많아서 따라 하기 쉽고 따라 할 것도 많지만, 잘 안 되었을 때는 어떻게 해야 하는지를 참고할 수 있는 건 그리 많지 않으니까. 그땐 정말 진정성을 가지고, 공부를 하든, 사람을 찾아다니든 해야 하고, 뭐가 문제인지를 숙고해야 하는데,

14. 쉽게 따라 할 수 있는 것에 너무 익숙해지면, 어렵고 시간이 걸리는 해결책을 선택하기란 점점 어려워진달까?

15. 그래서 이런 사람들은 대체로 질문이 자기중심적인 경우가 많다. 자신의 문제를 해결할 답을 알려달라는 식이다. 특히 창작자나 콘텐츠 업계로 넘어오면, 이 질문들은 더욱 노골적으로 변한다. “썸원 님, 저는 어떤 콘텐츠를 만들어야 하죠? 어떻게 돈을 벌어야 하죠?”

16. 이런 질문을 받을 때면 대충 아무말을 하면서 넘기긴 하는데, 그렇다고 해서 이 질문들이 구린 질문이라는 점은 변하지 않는다.

17. 콘텐츠를 만드는 것이 업의 핵심인 창작자가 어떤 콘텐츠를 만들어야 하는지를 다른 사람에게 묻고, 사업을 하는 것이 업의 기본이 사업자가 돈을 어떻게 벌어야 하는지를 다른 사람에게 묻는다는 건 스스로 자신이 해야 할 일의 기본에 대해 별로 고민하지 않았다는 뜻이니까.

18. 과연 봉준호 감독이나 유명 감독들이 다음 작품을 뭘 해야 할지에 대해 다른 사람들에게 의견을 묻고 그걸 따를까? 그보다는 자신의 아이디어에 대한 다른 사람들의 반응을 보고 개선하지 않을까?

19. 게다가 창작자는 그게 구리든 아니든, 자기 삶의 모든 순간을 콘텐츠로 만들 수 있는 일종의 특권 같은 걸 가지고 있는데, 남에게 아이디어를 구하는 것이 맞을까? 단순히 인기 있는 무언가를 추종하는 것이 맞을까? 만약 추종한다면 내가 그걸 왜 추종하는지에 대한 자신만의 명확한 이유가 있어야 할 것 같고.

20. 무튼 답은 모르지만, 지금 당장 답을 모른다는 건 그리 큰 문제가 아니다. 열린 태도를 가지고 가설을 세우고 검증을 하면서 나아가면 되니까. 정말 큰 문제는 남에게서 쉬운 답을 얻으려는 태도일지도 모르지. 무튼 나 화이팅 ;) 

https://blog.naver.com/somewon_co/223218034742

'따라 하기'보다는 '업의 본질'에 집중하기

TypeScript Origins: The Documentary features core contributors and community members like Anders Hejlsberg, Steve Lucco, Luke Hoban, Daniel Rosenwasser, Ryan Cavanaugh, Amanda Silver, Matt Pocock, Josh Goldberg & many more! It also covers adoption stories

TypeScript Origins: The Documentary

https://youtu.be/U6s2pdxebSo?si=RAfp1o8HtA-rRcnw

Microsoft는 왜 TypeScript를 개발할 가치가 있다고 생각했을까요?
이 다큐멘터리는 Microsoft가 TypeScript를 제작하게된 배경과 과정에 대해 깊이있게 다루고 있습니다.

다가올 추석, 여유롭게 시청하며 TypeScript와 더 가까워지는 시간이 될 수 있겠네요.

TypeScript 다큐멘터리: TypeScript Origins

NIO launches BaaS battery rental service, brings car prices down by about $10,000 - cnTechPost

“값비싼 전기차 배터리까지 구독할 수 있다면?!”

‘중국판 테슬라’로 불리는 전기차 업체 니오(NIO)가 배터리 판매량 2위인 CATL과 합작하여 전기차 배터리 대여/교환 서비스를 도입한다고 합니다. 

전기차의 가격은 배터리가 좌지우지 한다고 하는데요, 니오는 자동차와 배터리를 분리하여 자동차는 구매하고 배터리는 구독하는 Baas(Battery as a Service)를 선보여
전기차 초기 비용을 최대 40%까지 낮출 수 있으며 낮아진 비용으로 잠재적 전기차 구매 고객층을 넓힐 수 있다고 합니다. 

✏️니오의 창업가 ‘Li Bin’에 따르면 배터리 대여 서비스를 통해 
     1) 배터리 성능저하를 체계적으로 해결할 수 있고 2) 배터리가 업그레이드 되는 즐거움을 누릴 수 있으며 3) 차량의 유지가치 또한 높일 수 있다고 합니다. 

💡 TaaS(Transportation as a Service, MaaS(Mobility as a Service)에 이어서 BaaS(BaaS:Battery as a Service)의 등장까지
      미래 모빌리티 플랫폼을 선점하기 위한 기업들의 다양한 시도가 확장 되는것 같아 기대가 됩니다.  

* 참고로! 배터리 교환 사업을 제일 먼저 시도한건 2010년 초반 프랑스 르노와 이스타엘 베타플레이스지만, 당시에는 사업성이 떨어져 3년여만에 중단했다고 합니다.😭

cnTechPost

김민섭

더 나은 방법을 고민합니다.
Down for good reads and inspiration!

김하은

연세대학교에서 컴퓨터과학, 경제학을 전공했으며 넥슨에서 소프트웨어 엔지니어로 커리어를 시작했습니다. 신영증권에서 시장 리스크 관리를 담당하던 중 이머징 마켓에 대한 관심을 가졌고, 인도네시아 및 동남아 시장을 타겟으로 하는 스타트업 파이브잭으로 이직했습니다. 파이브잭에서 itemku.com을 총괄하면서 처음으로 제품 관리자로서의 커리어를 시작하였고, 현재는 한국에 돌아와 PUBLY에서 CPO를 맡고 있습니다.

Advisor/Coach, 10+yrs CPO, 1x Exit

이승국

- 10년+ Chief Product Officer
- 스타트업 매각, 시리즈 B 경험
- 도메인 경험: 소셜미디어(커리어리), B2B SaaS(위하이어), 커머스(itemku), 컨텐츠/직무교육(퍼블리)

UX/GUI 디자이너

노재연

우리는 앞으로 어떻게 이동하며 살게될까 고민하며 스마트 모빌리티 관련 UX업무를 하고 있습니다. 정보는 필요하지만 긴 글만 보면 앞이 깜깜해지는 나와 같은 사람들에게 도움이 되고 싶습니다.

댓글 0