얼마전 후배로부터 이런 문의를 받았습니다. 
회사에서 QA 채용을 위한 프로세스에 사전 과제와 필기 전형을 진행하고자 하는데 어떻게 진행하면 좋을지? 어떤 과제나 필기 문제를 내면 좋을지? 어떤 내용들이 들어가야 되는지? 하는 문의였죠. 
그에대한 답변을 하고보니..다른 분들께도 도움이 될 수 있을 것 같아 글을 옮겨와 봅니다. 

Q. 과제나 필기 전형을 진행하는 시기
A. 과제의 경우, 일반적으로 온라인으로 진행하게되고 경우에 따라 아래와 같이 진행됩니다.
   1) 지원서류 제출시 과제 결과물을 함께 제출하도록 해서 서류전형에 포함하여 심사를 진행하거나, 
   2) 1차 서류통과 한 인원에 대해 면접전 과제를 내어주고 그에대한 결과물을 받아 1.5차~2차 전형으로 진행하게됩니다. 여기서 Pass하면 면접전형으로 진행되는 거죠.

   필기 전형의 경우, 대게 오프라인으로 진행되고 
   1) 1차 서류심사 후 통과된 인원에 대해 면접 당일에 인터뷰 직전 필기 전형을 병행 진행하거나,
   2) 면접을 n차로 나뉘어 1차 또는 2차 면접에서 필기 전형을 진행합니다.  
        (1차 필기 → 2차 면접  OR  1차 면접 → 2차 필기)

   추가로, 
   과제와 필기 전형을 둘다 진행하는 경우도 있는데요. 이런 경우 대게, 위 케이스에서 과제 1)번과 필기 전형 1)번 순으로 진행하는 것이 일반적입니다. 

Q. 과제나 필기 문제에 포함되는 내용과 예시
A. QA 채용에서 과제는 대부분 'TC 작성 + α' 로 진행됩니다. α에는 테스트 계획, Test Scope 등이 포함될 수 있습니다. (참고로, 여기서 말하는 QA채용은 성능이나 자동화 등 기술부서를 제외한 기능QA 또는 SQA에 한정합니다.)

제출용 과제의 범위는 너무 광범위 한 것보다 특정 케이스나 한가지 상황에 집중해서 결과물을 산출 할 수 있도록 범위를 지정해주는 것이 좋습니다. 범위를 한정하는 것이 채용하는 입장에서도 해당 인력의 역량을 쉽게 파악하는데 좋은 방법이 될 수 있습니다. 예를들어, 모바일앱 플랫폼에 한정한 과제를 선정했다면 앱이 가지고 있는 공통적인 특성을 잘 알고 있는 인력이라면 과제로 낸 문제 이외에 애플리케이션 버전별로 업다운 그레이드 테스트까지 포함해서 test scope을 선정할 수 있는 역량을 보유했는지 확인해볼 수 있습니다. 

[과제 예시]
 * 회사에서 서비스하는 플랫폼의 주요 기능 중 하나(ex)로그인, 결제 등)를 선택하여 유저 시나리오로 TC 작성
 * 상태전이가 있는 기능 또는 경계값에서 발생되는 오류가 많은 기능을 선정하여 테스트 설계기법을 활용한 전략적인 테스트가 가능할 수 있는 test case를 설계하는 능력을 보유한 역량 확인
 * 사내에서 발생된 특정 케이스나 프로젝트 진행 중 확인된 실제 사례가 있다면 해당 케이스를 예시로 과제를 제시하여 테스트 수행 계획을 세우고 test scope을 지정하고 test case를 작성하게하여 실무 대응 능력을 확인

필기 전형은 QA가 공통으로 가져야 할 '소프트웨어 테스팅 전문 지식과 실무에서 발생할 수 있는 상황에 대한 대응 능력, 트러블슈팅에 대한 대처, 지원자의 QA 직무에 대한 업무가치관과 철학' 등 전문 지식과 채용하는 부서에 해당하는 실무 경험(ex) 모바일앱을 테스트 하는 부서의 경우 모바일에 집중된 경험치와 지식을 확인할 수 있는 용도로 문제를 준비)을 두루 확인할 수 있는 내용으로 문제를 선정하는 것이 좋습니다. 

특히 문제를 선정할 때, 관리자 입장에서 먼저 어떤 인력으로 채용이 되었으면 하는지..지원자의 주 역량을 희망 목표로 두고 해당 역량을 보유한 지원자를 캐치하기위한 문제로 선정하는 것이 좋습니다. 추가로, 역량별로 파악하기 위해서 각 문제마다 "검증 항목"을 미리 지정해두면 누락되거나 불필요하거나 또는 역량을 체크하기 위한 목적을 파악하는데 도움을 받을 수 있습니다. (ex) 검증 항목: 소프트웨어 테스팅 도구 선택 능력 확인을 위한 문제)

[필기 전형 문제 예시]
*QA 공통 전문 지식 문제 예시
1. 프로젝트에 제약을 가하는 3가지 요소로 묶인것은? (검증 항목 : 소프트웨어 공학 기본 이론)  
    1) 과정, 비용, 제도
    2) 행정, 법규, 일정
    3) 품질, 비용, 일정
    4) 일정, 시간, 비용
    5) 인력, 환경, 관리
  [정답: 3
   설명: 프로젝트에 가장 제약을 가한다는 의미는 프로젝트에서 가장 중요하게 생각 해야하는 부분을 말합니다. 즉 프로젝트의 성공 여부를 결정하는 중요 요소라고 할 수 있죠. '일정, 비용, 품질'은 프로젝트의 성공 요소라고 바꿔서 말할 수도 있습니다. 일정 내에 완성하고 계획된 비용 내에 완성하며 품질이 예상대로 만족된 프로젝트는 성공했다고 할 수 있습니다.]

2. 보기에 제시된 소프트웨어 개발 단계를 순서에 맞게 나열하시오.(검증 항목 : 소프트웨어 공학 기본 이론)
    보기 : 구현, 설계, 요구 분석, 계획, 유지 보수, 테스트
  [정답: 계획→요구 분석→설계→구현→테스트→유지 보수]

3. 살충제 패러독스(Pesticide paradox)를 설명하고 이를 해결 할 수 있는 방안을 제시하시오. (검증항목 : 소프트웨어 테스팅의 일반적인 원리)
[정답
 개념 : 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행하면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다는 원리  
해결 방안 : 1) 테스트 케이스의 주기적인 개선-시스템에 잠재된 보다 많은 결함을 발견하지 위해 테스트 기법을 다른 모듈이나 다른 시각에서 재적용하고 지속적으로 리뷰하여 개선
2) 경험 기반 접근 : 탐색적 테스팅, Ad-hoc 등의 경험 기반 접근법을 통해 새로운 테스트 케이스를 지속적으로 추가]

* 모바일앱 테스트 또는 실무 능력 확인용 문제 예시
1.   모바일 어플리케이션에서 제공하는 장보기 기능은 사용자가 장보기 목록을 작성해서 스마트폰에 저장할 수 있게 해주며, 동시에 최대 3개의 목록을 저장할 수 있게 해준다. 각 목록에는 최대 50개의 품목을 저장할 수 있다. 다음 중 경계값 분석 기법을 활용할 경우 100% 커버리지 달성을 위한 최소한의 테스트 세트는 무엇인가? (검증 항목: 소프트웨어 테스트 설계 기법의 적용)
    1) 47개의 품목으로 구성된 목록
    2) 0개, 1개, 50개, 51개의 품목으로 구성된 목록 & 0개, 1개, 3개, 4개의 저장된 목록 
    3) 0개, 25개, 51개의 품목으로 구성된 목록 & 3개의 저장된 목록 
    4) 0개, 12개, 58개의 품목으로 구성된 목록 & 0개, 3개, 7개의 저장된 목록  
 [정답:2
  설명: 1은 저장된 목록 조건을 고려하지 않고, 품목 조건의 비 유효값을 고려하지 않기 때문에 틀리다. 3은 저장된 목록 조건에 대한 커버리지를 달성하지 못하기 때문에 틀리다. 4는 동등 분할 커버리지를 달성하지만, 경계값을 충족하고 있지는 않다.]

2. 마케팅 부서로부터 앱 최초 다운로드 이후 이탈률이 높다는 정보가 들어왔다. 뿐만 아니라 많은 사람들이 어플리케이션을 다운로드한 후 실제 사용하지도 않은 것으로 보인다. 가장 핵심적인 이유는 낮은 성능이라고 판단되며 이 때문에 사람들이 어플리케이션을 포기하는 것으로 보인다. 문제의 진의를 판단하기 위해서 어플리케이션의 어느 부분에 초점을 맞춰 테스트하는 것이 필요한가? (검증 항목: 소프트웨어 테스팅 전략 수립)
    1) 사용자 인터페이스 지연
    2) 불규칙적인 성능 
    3) 자원 활용
    4) 어플리케이션이 시작하는데 걸리는 시간  
 [정답: 4
  설명: 사람들이 다운로드 후 사용하지 않는 것으로 보아, 다운로드하고 최초 실행하는 데까지 너무 많은 시간이 걸리는 것이 원인일 수 있다. 진짜 문제가 그것이 아니라고 할지라도 테스트 중 가장 먼저 확인해야 하는 부분임에는 틀림없어 보인다. 1과 2는 사용자가 소프트웨어를 사용하지 않고 있으므로 이런 문제를 겪어보지 못했을 것으로 생각되기 때문에 정답이 아니다. 3은 4의 원인일 수 있다.]

3. 결정/조건 커버리지의 개념을 설명하고, 다음과 같은 코드가 있을 경우 결정/조건커버리지를 100% 달성하려면 어떻게 해야하는가? 또한 테스트케이스는 어떻게 작성하는가? (검증 항목: 테스트 커버리지)
      1:  IF ((X > 1) AND (Y==1))
      2:  Z = Z / X
      3:  END
      4:  IF ((X==2) OR (Z>1))
      5:  Z = Z+1
      6:  END
 [정답: 결정/조건 커버리지란, 각 개별조건들의 참(true)과 거짓(false)을 모두 커버하고, 전체조건식의 참(true)과 거짓(false)을 모두 커버될수 있도록 테스트케이스 만드는 방법이다.
    [테스트케이스 작성]
     TC1 : (X=2,Y=1,Z=4), TT
     TC2 : (X=1,Y=2,Z=0), FF]

추가로 개인적인 의견이나, 
과제나 필기전형을 진행할 경우 채용하는 인력의 보유 경력 연차를 고려하여 문제를 달리 제시하는 것이 좋습니다. 10년차 이상되는 시니어 엔지니어에게 (신입채용에 사용되는 과제와 동일한) 로그인 프로세스에 대한 TC를 작성하게 하는 것보다 해당 년차가 보유한 역량 중 회사 입사시 활용할 수 있는 역량에 중점을 두고 해당 업무를 수행할 수 있는 능력을 보유하고 있는지+해당 연차가 보유해야할 능력을 실제 보유하고 있는지 검증할 수 있도록 과제(ex)프로세스 수립이나 개선 방안을 확인하는 문제 등)를 제시하는 것이 바람직합니다. 

Q. 과제 제출시 번외로 포함되어야 할 내용
A. 과제 제출시 결과물의 양을 정해주어야 하는지?와 같은 질문도 있었는데요. 이건 관리자의 선택에 따른 부분이라 "반드시 이렇게 해야한다"라는 기준은 없습니다. 저의 경우, 특별히 과제양에 대한 제한은 두지 않고 자유롭게 결과물을 작성하도록 하는 편입니다. 제한을 둠으로 인해서 오히려 틀에 갇혀서 지원자의 역량을 제한하는 것이 지원자에게는 아쉬움이 될 수 있고, 채용하는 입장에서는 지원자의 충분한 역량을 확인 할 수 있는 기회를 빼앗을 수 있다고 생각하기 때문입니다. 
(but, 지원자 입장에서 유도리를 발휘해서 3~4장 수준으로 스스로 한계를 둘 수 있다면 좋겠지요?)

이 외 번외로 했던 질문에 외부 노출에 대한 경고나 안내도 있어야 할까?에 대해서도 문의를 주었는데, 이건 당연히 포함하는 것이 좋습니다. 외부로 유출될 경우 채용 담당자는 채용시마다 과제나 필기문제를 바꿔야 하는 불편이 생길 수 있고, 지원자 입장에서는 외부 유출로 인해 채용이 취소되거나 응시자격이 박탈되는 등 불이익이 생길 수 있습니다. 또 해당 기업에 채용을 희망하는 인원들 중 외부 유출로 인해 지망생 간에 불평등이 발생될 수 있어서 외부 노출에 대한 경고나 안내는 반드시 표기해주는 것이 좋고 노출될 경우 대응방안에 대해 사내 법무팀이나 상위 관리자를 통해 사전에 규정을 마련해두는 것이 좋습니다.

얼마전 후배로부터 이런 문의를 받았습니다.&nbsp;회사에서 QA 채용을 위한 프로세스에 사전 과제와 필기 전형을 진행하고자 하는데 어떻게 진행하면 좋을지? 어떤 과제나 필기 문제를 내면 좋을지? 어떤 내용들이 들어가야 되는지?&nbsp;하는 문의였죠.&nbsp;그에대한 답변을 하고보니..다른 분들께도 도움이 될 수 있을 것 같아 글을 옮겨와 봅니다.&nbsp; Q. 과제나 필기 전형을 진행하는 시기A. 과제의 경우, 일반적으로 온라인으로 진행하게되고 경우에 따라 아래와 같이 진행됩니다.&nbsp;&nbsp;&nbsp;1) 지원서류 제출시 과제 결과물을 함께 제출하도록 해서 서류전형에&nbsp;포함하여 심사를 진행하거나,&nbsp;&nbsp;&nbsp;&nbsp;2) 1차 서류통과 한 인원에 대해 면접전 과제를 내어주고 그에대한 결과물을 받아 1.5차~2차 전형으로&nbsp;진행하게됩니다. 여기서 Pass하면 면접전형으로 진행되는 거죠. &nbsp;&nbsp;&nbsp;필기 전형의 경우, 대게 오프라인으로 진행되고&nbsp;&nbsp;&nbsp;&nbsp;1) 1차 서류심사 후 통과된 인원에 대해 면접 당일에 인터뷰 직전 필기 전형을 병행 진행하거나,&nbsp;&nbsp;&nbsp;2) 면접을 n차로 나뉘어 1차 또는 2차 면접에서 필기 전형을 진행합니다.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(1차 필기&nbsp;→ 2차 면접&nbsp;&nbsp;OR&nbsp;&nbsp;1차 면접&nbsp;→ 2차 필기) &nbsp;&nbsp;&nbsp;추가로,&nbsp;&nbsp;&nbsp;&nbsp;과제와 필기 전형을 둘다 진행하는 경우도 있는데요. 이런 경우 대게, 위 케이스에서 과제 1)번과 필기 전형&nbsp;1)번 순으로 진행하는 것이 일반적입니다.&nbsp; Q. 과제나 필기 문제에 포함되는 내용과 예시A.&nbsp;QA 채용에서 과제는 대부분 'TC 작성 +&nbsp;α' 로 진행됩니다.&nbsp;α에는 테스트 계획, Test Scope 등이 포함될 수 있습니다. (참고로, 여기서 말하는 QA채용은 성능이나 자동화 등 기술부서를 제외한 기능QA 또는 SQA에 한정합니다.) 제출용 과제의 범위는 너무 광범위 한 것보다 특정 케이스나 한가지 상황에 집중해서 결과물을 산출 할 수 있도록 범위를 지정해주는 것이 좋습니다. 범위를 한정하는 것이 채용하는 입장에서도 해당 인력의 역량을 쉽게 파악하는데 좋은 방법이 될 수 있습니다. 예를들어, 모바일앱 플랫폼에 한정한 과제를 선정했다면 앱이 가지고 있는 공통적인 특성을 잘 알고 있는 인력이라면 과제로 낸 문제 이외에 애플리케이션 버전별로 업다운 그레이드 테스트까지 포함해서 test scope을 선정할 수 있는 역량을 보유했는지 확인해볼 수 있습니다.&nbsp; [과제 예시]<ul ><li>회사에서 서비스하는 플랫폼의 주요 기능 중 하나(ex)로그인, 결제 등)를 선택하여 유저 시나리오로 TC 작성</li><li>상태전이가 있는 기능 또는 경계값에서 발생되는 오류가 많은 기능을 선정하여 테스트 설계기법을 활용한 전략적인 테스트가 가능할 수 있는 test case를 설계하는 능력을 보유한 역량 확인</li><li>사내에서 발생된 특정 케이스나 프로젝트 진행 중 확인된 실제 사례가 있다면 해당 케이스를 예시로 과제를 제시하여 테스트 수행 계획을 세우고 test scope을 지정하고 test case를 작성하게하여 실무 대응 능력을 확인</li></ul> 필기 전형은 QA가 공통으로 가져야 할 '소프트웨어 테스팅 전문 지식과 실무에서 발생할 수 있는 상황에 대한 대응 능력, 트러블슈팅에 대한 대처, 지원자의 QA 직무에 대한 업무가치관과 철학' 등 전문 지식과 채용하는 부서에 해당하는 실무 경험(ex) 모바일앱을 테스트 하는 부서의 경우 모바일에 집중된 경험치와 지식을 확인할 수 있는 용도로 문제를 준비)을 두루 확인할 수 있는 내용으로 문제를 선정하는 것이 좋습니다.&nbsp; 특히 문제를 선정할 때, 관리자 입장에서 먼저 어떤 인력으로 채용이 되었으면 하는지..지원자의 주 역량을 희망 목표로 두고&nbsp;해당 역량을 보유한 지원자를 캐치하기위한 문제로 선정하는 것이 좋습니다. 추가로, 역량별로 파악하기 위해서 각 문제마다 "검증 항목"을 미리 지정해두면 누락되거나 불필요하거나 또는 역량을 체크하기 위한 목적을 파악하는데 도움을 받을 수 있습니다.&nbsp;(ex)&nbsp;검증 항목: 소프트웨어 테스팅 도구 선택 능력 확인을 위한 문제) [필기 전형 문제 예시]*QA 공통 전문 지식 문제 예시1. 프로젝트에&nbsp;제약을 가하는 3가지 요소로 묶인것은? (검증 항목 : 소프트웨어 공학 기본 이론)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1) 과정, 비용, 제도&nbsp;&nbsp;&nbsp;&nbsp;2) 행정, 법규, 일정&nbsp;&nbsp;&nbsp;&nbsp;3) 품질, 비용, 일정&nbsp;&nbsp;&nbsp;&nbsp;4) 일정, 시간, 비용&nbsp;&nbsp;&nbsp;&nbsp;5) 인력, 환경, 관리&nbsp;&nbsp;[정답: 3&nbsp;&nbsp;&nbsp;설명: 프로젝트에 가장 제약을 가한다는 의미는 프로젝트에서 가장 중요하게 생각 해야하는 부분을 말합니다. 즉 프로젝트의 성공 여부를 결정하는 중요 요소라고 할 수 있죠. '일정, 비용, 품질'은 프로젝트의 성공 요소라고 바꿔서 말할 수도 있습니다. 일정 내에 완성하고 계획된 비용 내에 완성하며 품질이 예상대로 만족된 프로젝트는 성공했다고 할 수 있습니다.] 2.&nbsp;보기에 제시된 소프트웨어 개발 단계를 순서에 맞게 나열하시오.(검증 항목 : 소프트웨어 공학 기본 이론)&nbsp;&nbsp;&nbsp;&nbsp;보기 :&nbsp;구현, 설계, 요구 분석, 계획, 유지 보수, 테스트&nbsp;&nbsp;[정답: 계획→요구 분석→설계→구현→테스트→유지 보수] 3.&nbsp;살충제 패러독스(Pesticide paradox)를 설명하고 이를 해결 할 수 있는 방안을 제시하시오. (검증항목 : 소프트웨어 테스팅의 일반적인 원리)[정답&nbsp;개념 : 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행하면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다는 원리 &nbsp; 해결 방안 : 1)&nbsp;테스트 케이스의 주기적인 개선-시스템에 잠재된 보다 많은 결함을 발견하지 위해 테스트 기법을 다른 모듈이나 다른 시각에서 재적용하고 지속적으로 리뷰하여 개선 2) 경험 기반 접근 : 탐색적 테스팅, Ad-hoc&nbsp;등의 경험 기반 접근법을 통해 새로운 테스트 케이스를 지속적으로 추가] * 모바일앱&nbsp;테스트 또는 실무 능력 확인용 문제 예시1.&nbsp;&nbsp;&nbsp;모바일&nbsp;어플리케이션에서 제공하는 장보기 기능은 사용자가 장보기 목록을 작성해서 스마트폰에 저장할 수 있게 해주며, 동시에 최대 3개의 목록을 저장할 수 있게 해준다. 각 목록에는 최대 50개의 품목을 저장할 수 있다. 다음 중 경계값 분석 기법을 활용할 경우 100% 커버리지 달성을 위한 최소한의 테스트 세트는 무엇인가? (검증 항목: 소프트웨어 테스트 설계 기법의 적용)&nbsp;&nbsp;&nbsp;&nbsp;1)&nbsp;47개의 품목으로 구성된 목록&nbsp;&nbsp;&nbsp;&nbsp;2) 0개, 1개, 50개, 51개의 품목으로 구성된 목록 &amp; 0개, 1개, 3개, 4개의 저장된 목록&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) 0개, 25개, 51개의 품목으로 구성된 목록 &amp; 3개의 저장된 목록&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4) 0개, 12개, 58개의 품목으로 구성된 목록 &amp; 0개, 3개, 7개의 저장된 목록 &nbsp;&nbsp;[정답:2 &nbsp;&nbsp;설명: 1은 저장된 목록 조건을 고려하지 않고, 품목 조건의 비 유효값을 고려하지 않기 때문에 틀리다. 3은 저장된 목록 조건에 대한 커버리지를 달성하지 못하기 때문에 틀리다. 4는 동등 분할 커버리지를 달성하지만, 경계값을 충족하고 있지는 않다.] 2.&nbsp;마케팅 부서로부터 앱 최초 다운로드 이후 이탈률이&nbsp;높다는 정보가 들어왔다. 뿐만 아니라 많은 사람들이 어플리케이션을 다운로드한 후 실제 사용하지도 않은 것으로 보인다. 가장 핵심적인 이유는 낮은 성능이라고 판단되며 이 때문에 사람들이 어플리케이션을 포기하는 것으로 보인다. 문제의 진의를 판단하기 위해서 어플리케이션의 어느 부분에 초점을 맞춰 테스트하는 것이 필요한가? (검증 항목: 소프트웨어 테스팅 전략 수립)&nbsp;&nbsp;&nbsp;&nbsp;1)&nbsp;사용자 인터페이스 지연&nbsp;&nbsp;&nbsp;&nbsp;2) 불규칙적인 성능&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3) 자원 활용&nbsp;&nbsp;&nbsp;&nbsp;4) 어플리케이션이 시작하는데 걸리는 시간 &nbsp;&nbsp;[정답: 4&nbsp;&nbsp;설명: 사람들이 다운로드 후 사용하지 않는 것으로 보아, 다운로드하고 최초 실행하는 데까지 너무 많은 시간이 걸리는 것이 원인일 수 있다. 진짜 문제가 그것이 아니라고 할지라도 테스트 중 가장 먼저 확인해야 하는 부분임에는 틀림없어 보인다. 1과 2는 사용자가 소프트웨어를 사용하지 않고 있으므로 이런 문제를 겪어보지 못했을 것으로 생각되기 때문에 정답이 아니다. 3은 4의 원인일 수 있다.] 3.&nbsp;결정/조건 커버리지의 개념을 설명하고, 다음과 같은 코드가 있을 경우 결정/조건커버리지를 100% 달성하려면 어떻게 해야하는가? 또한 테스트케이스는 어떻게 작성하는가? (검증 항목: 테스트 커버리지)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1: &nbsp;IF ((X &gt; 1) AND (Y==1))&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2:&nbsp;&nbsp;Z = Z / X&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3: &nbsp;END&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4: &nbsp;IF ((X==2) OR (Z&gt;1))&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5:&nbsp;&nbsp;Z = Z+1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6: &nbsp;END&nbsp;[정답: 결정/조건 커버리지란, 각 개별조건들의 참(true)과 거짓(false)을 모두 커버하고, 전체조건식의 참(true)과 거짓(false)을 모두 커버될수 있도록&nbsp;테스트케이스 만드는 방법이다.&nbsp;&nbsp;&nbsp;&nbsp;[테스트케이스 작성]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TC1 : (X=2,Y=1,Z=4), TT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TC2 : (X=1,Y=2,Z=0), FF] 추가로 개인적인 의견이나,&nbsp;과제나 필기전형을 진행할 경우 채용하는 인력의 보유 경력 연차를 고려하여 문제를 달리 제시하는 것이 좋습니다. 10년차 이상되는 시니어 엔지니어에게 (신입채용에 사용되는 과제와 동일한) 로그인 프로세스에 대한 TC를 작성하게 하는 것보다 해당 년차가 보유한 역량 중 회사 입사시 활용할 수 있는 역량에 중점을 두고 해당 업무를 수행할 수 있는 능력을 보유하고 있는지+해당 연차가 보유해야할 능력을 실제 보유하고 있는지 검증할 수 있도록 과제(ex)프로세스 수립이나 개선 방안을 확인하는 문제 등)를 제시하는 것이 바람직합니다.&nbsp; Q. 과제 제출시 번외로 포함되어야 할 내용A. 과제 제출시 결과물의 양을 정해주어야 하는지?와 같은 질문도 있었는데요. 이건 관리자의 선택에 따른 부분이라 "반드시 이렇게 해야한다"라는 기준은 없습니다. 저의 경우, 특별히 과제양에 대한 제한은 두지 않고 자유롭게 결과물을 작성하도록 하는 편입니다. 제한을 둠으로 인해서 오히려 틀에 갇혀서 지원자의 역량을 제한하는 것이 지원자에게는 아쉬움이 될 수 있고, 채용하는 입장에서는 지원자의 충분한 역량을 확인 할 수 있는 기회를 빼앗을 수 있다고 생각하기 때문입니다.&nbsp;(but, 지원자 입장에서 유도리를 발휘해서 3~4장 수준으로 스스로 한계를 둘 수 있다면 좋겠지요?) 이 외 번외로 했던 질문에 외부 노출에 대한 경고나 안내도 있어야 할까?에 대해서도 문의를 주었는데, 이건 당연히 포함하는 것이 좋습니다. 외부로 유출될 경우 채용 담당자는 채용시마다 과제나 필기문제를 바꿔야 하는 불편이 생길 수 있고, 지원자 입장에서는 외부 유출로 인해 채용이 취소되거나 응시자격이 박탈되는 등 불이익이 생길 수 있습니다. 또 해당 기업에 채용을 희망하는 인원들 중 외부 유출로 인해 지망생 간에 불평등이 발생될 수 있어서 외부 노출에 대한 경고나 안내는 반드시 표기해주는 것이 좋고 노출될 경우 대응방안에 대해 사내 법무팀이나 상위 관리자를 통해 사전에 규정을 마련해두는 것이 좋습니다.&nbsp;

[관리자용] QA 채용을 위한 과제와 필기전형 예시

ML 모델 개발 과정에서 자주 발생하는 공통적인 문제점들은 다양하다. 처음 한번은 어떻게 전체 프로세스를 돌리고 모델을 만들고 배포할 수 있지만 다음 번에 모델을 다시 빌드해야 한다면 얼마나 빠르게 실수없이 할 수 있느냐가 정말 중요한 포인트가 되며 여기서 경쟁력이 달라진다.

왜 모델을 다시 빌드할 필요가 있느냐고 반문할지도 모르겠다. 그 이유는 데이터의 패턴이 달라지는 경우 옛날 데이터로 빌드된 모델의 성능이 떨어지기 시작하기 때문이다. 이를 Data Drift라고 부른다. 실제로 야후 때 경험을 놓고 보면 검색 랭킹을 ML 모델로 만들고 이걸 1년 동안 방치(?)해보니 결과의 클릭률이 30%가 떨어지는 걸 관찰한 적이 있었는데 그 이유는 웹에 만들어지는 문서의 패턴이 바뀌고 쿼리의 패턴이 바뀌면서 모델을 훈련할 때 사용했던 훈련 데이터와 지금 모델로 들어오는 데이터가 달라졌기 때문이었다. 즉 머신 러닝 모델의 중요 피처의 데이터 분포(평균, 표준편차 등등)를 계속해서 모니터링하다가 달라지면 모델을 다시 빌드할 필요가 있다.

그러면 모델의 재빌딩이란 측면에서 어떤 문제들이 있는지 이야기해보자. 몇 가지만 이야기해봐도 다음과 같은 것들이 있다.

 * 훈련용 데이터셋의 관리가 큰 문제로 작용할 수 있다. 데이터의 품질, 양, 그리고 다양한 조건에 따라 모델 성능이 크게 달라지기 때문에 데이터를 체계적으로 관리하고 업데이트하는 것이 중요하다. 무엇보다 마지막 모델 빌드시 사용했던 훈련용 데이터셋이 무엇인지 알고 다시 사용할 수 있게 관리해야 한다.
 * 피처를 계산하는 방법, 즉 피처 엔지니어링 과정에서 사용되는 코드의 관리도 중요한 이슈다. 이 코드를 GitHub 등에 관리하면서 유닛 테스트등을 도입해야 일관성 있는 결과를 도출할 수 있다. 이는 소프트웨어 개발자에게는 당연하게 받아들여지는 과정일 수 있지만 데이터 과학자들에게는 익숙하지 않은 과정인 경우가 많고 여기서 생기는 이유가 생각보다 많다.
 * 모델을 처음 빌딩할 때 어떤 머신러닝 알고리즘을 사용하고 이와 함께 사용한 하이퍼 파라미터들이 무엇인지, 그리고 이들을 어떻게 조정했는지도 중요한 문제이며 이 모든 것들이 문서화가 되고 기록이 되어야 나중에 모델을 다시 만들 때 시간 낭비를 하지 않는다.
 * 초기 개발 단계에서는 노트북에서 수동으로 모델을 빌딩하는데, 이러한 과정을 체계화하거나 자동화하지 않으면 나중에 재현하기 어렵고, 팀 간의 협업이 어려워질 수 있다.
 * 만들어진 모델을 배포하는 것도 중요하다. 보통 API 형태로 배포하는 것이 일반적인데 이 경우 백엔드 엔지니어링 팀이나 데브옵스 엔지니어링 팀과 밀접한 협업이 필요하다. 배포할 때마다 긴밀하게 협업을 해야한다면 이는 배포의 주기가 잦은 경우 큰 문제가 된다. 즉, 이 부분은 최대한 자동화하고 프로세스(monitoring & troubleshooting)를 만들 필요가 있다. 모니터링이란 측면에서는 data drift와 API의 수행시간 (latency) 등이 중요한 포인트가 된다.
 * 마지막으로, 모델의 성능을 평가하기 위한 AB 테스트 프로세스도 매우 중요하다. 실제 사용자에게 제공하기 전에 모델이 제대로 작동하는지 확인하고, 새로운 모델이 기존 모델보다 나은 성능을 보이는지를 평가하는 것이 필수적이다.

즉 위의 일은 머신 러닝 모델만 빌드하던 데이터 과학자나, 데이터 파이프라인만 관리하던 데이터 엔지니어나, 온라인 시스템을 모니터링하고 트러블슈팅을 하던 데브옵스 엔지니어가 혼자 하기에는 벅찬 일이다. 그래서 생긴 직군이 바로 MLOps 직군이며 다음 3가지 역할을 수행하게 된다. 즉 주니어가 하기에는 많은 경험을 필요로 하는 일이라 할 수 있다.

 1. 데이터 과학자 (혹은 ML 엔지니어)
 2. 데이터 엔지니어
 3. 데브옵스 엔지니어

그렇다고 MLOps 엔지니어가 머신 러닝 모델을 직접 빌드하는 역할은 하지는 않는다. 그런 관점에서는 데브옵스 엔지니어와 비슷한 부분이 있는데 데브옵스 엔지니어의 경우 서비스 코드를 직접 작성하지는 않지만 다른 개발자들이 만든 코드를 테스트하고 패키지하고 배포하고 모니터링하고 트러블슈팅을 하며 이 과정을 최대한 자동화하게 된다. MLOps 엔지니어의 경우에는 다른 사람들(보통 데이터 과학자)이 만든 모델을 대상으로 동일한 일을 수행하게 된다.

머신 러닝 모델이 점점더 많은 영역에서 사용되다보니 MLOps와 같은 직군이 중요해지고 그러다보니 관련한 툴/프레임웍들이 많이 나오고 있다. 개인적으로 많이 사용해본 것은 AWS의 SageMaker이고 가볍게 사용해본 것으로는 Databricks에서 만든 MLflow가 있다.

다음 포스팅에서 프라이버시 엔지니어에 대해 이야기해보고자 한다.

ML 모델 개발 과정에서 자주 발생하는 공통적인 문제점들은 다양하다. 처음 한번은 어떻게 전체 프로세스를 돌리고 모델을 만들고 배포할 수 있지만 다음 번에 모델을 다시 빌드해야 한다면 얼마나 빠르게 실수없이 할 수 있느냐가 정말 중요한 포인트가 되며 여기서 경쟁력이 달라진다. 왜 모델을 다시 빌드할 필요가 있느냐고 반문할지도 모르겠다. 그 이유는 데이터의 패턴이 달라지는 경우 옛날 데이터로 빌드된 모델의 성능이 떨어지기 시작하기 때문이다. 이를 Data Drift라고 부른다. 실제로 야후 때 경험을 놓고 보면 검색 랭킹을 ML 모델로 만들고 이걸 1년 동안 방치(?)해보니 결과의 클릭률이 30%가 떨어지는 걸 관찰한 적이 있었는데 그 이유는 웹에 만들어지는 문서의 패턴이 바뀌고 쿼리의 패턴이 바뀌면서 모델을 훈련할 때 사용했던 훈련 데이터와 지금 모델로 들어오는 데이터가 달라졌기 때문이었다. 즉 머신 러닝 모델의 중요 피처의 데이터 분포(평균, 표준편차 등등)를 계속해서 모니터링하다가 달라지면 모델을 다시 빌드할 필요가 있다. 그러면 모델의 재빌딩이란 측면에서 어떤 문제들이 있는지 이야기해보자. 몇 가지만 이야기해봐도 다음과 같은 것들이 있다. <ul ><li>훈련용 데이터셋의 관리가 큰 문제로 작용할 수 있다. 데이터의 품질, 양, 그리고 다양한 조건에 따라 모델 성능이 크게 달라지기 때문에 데이터를 체계적으로 관리하고 업데이트하는 것이 중요하다. 무엇보다 마지막 모델 빌드시 사용했던 훈련용 데이터셋이 무엇인지 알고 다시 사용할 수 있게 관리해야 한다.</li><li>피처를 계산하는 방법, 즉 피처 엔지니어링 과정에서 사용되는 코드의 관리도 중요한 이슈다. 이 코드를 GitHub 등에 관리하면서 유닛 테스트등을 도입해야 일관성 있는 결과를 도출할 수 있다. 이는 소프트웨어 개발자에게는 당연하게 받아들여지는 과정일 수 있지만 데이터 과학자들에게는 익숙하지 않은 과정인 경우가 많고 여기서 생기는 이유가 생각보다 많다.</li><li>모델을 처음 빌딩할 때 어떤 머신러닝 알고리즘을 사용하고 이와 함께 사용한 하이퍼 파라미터들이 무엇인지, 그리고 이들을 어떻게 조정했는지도 중요한 문제이며 이 모든 것들이 문서화가 되고 기록이 되어야 나중에 모델을 다시 만들 때 시간 낭비를 하지 않는다.</li><li>초기 개발 단계에서는 노트북에서 수동으로 모델을 빌딩하는데, 이러한 과정을 체계화하거나 자동화하지 않으면 나중에 재현하기 어렵고, 팀 간의 협업이 어려워질 수 있다.</li><li>만들어진 모델을 배포하는 것도 중요하다. 보통 API 형태로 배포하는 것이 일반적인데 이 경우 백엔드 엔지니어링 팀이나 데브옵스 엔지니어링 팀과 밀접한 협업이 필요하다. 배포할 때마다 긴밀하게 협업을 해야한다면 이는 배포의 주기가 잦은 경우 큰 문제가 된다. 즉, 이 부분은 최대한 자동화하고 프로세스(monitoring &amp; troubleshooting)를 만들 필요가 있다. 모니터링이란 측면에서는 data drift와 API의 수행시간 (latency) 등이 중요한 포인트가 된다.</li><li>마지막으로, 모델의 성능을 평가하기 위한 AB 테스트 프로세스도 매우 중요하다. 실제 사용자에게 제공하기 전에 모델이 제대로 작동하는지 확인하고, 새로운 모델이 기존 모델보다 나은 성능을 보이는지를 평가하는 것이 필수적이다.</li></ul> 즉 위의 일은 머신 러닝 모델만 빌드하던 데이터 과학자나, 데이터 파이프라인만 관리하던 데이터 엔지니어나, 온라인 시스템을 모니터링하고 트러블슈팅을 하던 데브옵스 엔지니어가 혼자 하기에는 벅찬 일이다. 그래서 생긴 직군이 바로 MLOps 직군이며 다음 3가지 역할을 수행하게 된다. 즉 주니어가 하기에는 많은 경험을 필요로 하는 일이라 할 수 있다. <ol ><li>데이터 과학자 (혹은 ML 엔지니어)</li><li>데이터 엔지니어</li><li>데브옵스 엔지니어</li></ol> 그렇다고 MLOps 엔지니어가 머신 러닝 모델을 직접 빌드하는 역할은 하지는 않는다. 그런 관점에서는 데브옵스 엔지니어와 비슷한 부분이 있는데 데브옵스 엔지니어의 경우 서비스 코드를 직접 작성하지는 않지만 다른 개발자들이 만든 코드를 테스트하고 패키지하고 배포하고 모니터링하고 트러블슈팅을 하며 이 과정을 최대한 자동화하게 된다. MLOps 엔지니어의 경우에는 다른 사람들(보통 데이터 과학자)이 만든 모델을 대상으로 동일한 일을 수행하게 된다. 머신 러닝 모델이 점점더 많은 영역에서 사용되다보니 MLOps와 같은 직군이 중요해지고 그러다보니 관련한 툴/프레임웍들이 많이 나오고 있다. 개인적으로 많이 사용해본 것은 AWS의 SageMaker이고 가볍게 사용해본 것으로는 Databricks에서 만든 MLflow가 있다. 다음 포스팅에서 프라이버시 엔지니어에 대해 이야기해보고자 한다.

데이터 이야기 #7:  기타 데이터 직군 - MLOps 엔지니어

한국에서 일할 때는 제 주변에 대부분의 직장인들이 성장에 목말라 했었습니다. 막 입사한 개발자들은 어떻게 하면 빨리 신입 딱지를 땔 수 있을지 물어봤었고, 주니어 개발자들은 어떻게 하면 빨리 시니어가 될 수 있는지 궁금해했습니다. 동기들은 다 진급하는데 본인만 누락될까봐 걱정하시는 분들이 많았습니다. 그래서 주로 이러한 갈증을 해소시켜주는 멘토링을 했던 기억이 있습니다.

이러한 경험을 갖고 저는 캐나다에 와서 직장 생활을 하면서 문화 충격을 받는데요. 현재 자신이 맡고있는 역할에 충분히 만족하며 딱히 더 성장할 마음이 없는 직장인들이 많기 때문입니다. 이러한 엔지니어들과 얘기를 해보면 소프트웨어 개발 직군이 다른 직군 대비 처우가 얼마나 좋은지 잘 인지하고 있으며 그래서 더 이상 바랄 게 없다고 합니다. 진급과 함께 늘어난 권한만큼 무거운 책임도 부담스럽다고 하고요.

한국에서 어렸을 때 부터 치열한 경쟁 속에 살아온 저는 처음에 이러한 캐나다 동료들이 나태하고 한심하다고 느껴졌습니다. 아마도 예전에 교양 수업에서 들었던 열심히 일하지 않아도 되는 복지 선진국의 폐해일 수도 있겠다고 생각했습니다. 하지만 이러한 엔지니어들을 직접 멘토링하게 되면서 제 관점이 조금씩 바뀌게 되었습니다.

처음에는 이러한 멘티들의 성장을 독려하는 것이 저의 임무라고 생각했습니다. 업무에서 사용하고 있는 기술에 대해서 좀 더 깊이 공부하기를 바라는 마음에 여러 책과 온라인 강의를 추천해주었습니다. 이 친구들이 조직에서 더 두각을 내고 진급을 하려면 어떤 부분에서 더 실력을 키워야 하는지 얘기해 주었습니다. 이렇게 성장하는 방법을 알려주면 고마워할 줄 알았죠.

하지만 저의 이러한 멘토링 방향에 반발하는 멘티를 만났고, 이 친구와 우리는 왜 성장해야 하는가 대해서 수 차례 깊은 대화를 나누었습니다. 그러다가 저는 태어나서 한 번도 의심해보지 않았던 성장이라는 가치에 대해서 자문하게 되었습니다. 나는 왜 이렇게 성장에 집착하는 거지? 왜 다른 사람에게 성장을 강요하려는 거지?? 생각을 해보니 반드시 모든 사람이 성장하고 싶어야 할 이유도 없더군요! 제 생각이 얼마나 편협했었는지를 느끼게 되었습니다.

그래서 이제는 새로운 멘티가 생기면 성장을 하고 싶은지에 대해서 먼저 꼭 물어봅니다. 엔지니어로서 성장을 원치 않는 친구들은 보통 인생의 다른 부분에 열정을 갖고 있더라고요. 어떤 친구는 퇴근 후에 아마추어 하키팀 코치로 투잡을 뛰고, 다른 친구는 영화 감독이 꿈이라서 주말마다 독립 영화를 찍고 있다고 하네요. 이런 친구들은 성장보다는 효율에 초점을 두어 멘토링을 합니다.

저처럼 소프트웨어 개발을 천직으로 삼고 계속해서 공부하며 엔지니어로 성장하고 싶은 사람도 있지만, 그냥 소프트웨어 개발을 괜찮은 돈벌이 수단으로 생각하고 직업 그 이상 이하로도 생각하지 않는 사람도 많습니다. 멘토가 멘티의 성장을 도와줄 수는 있지만, 절대 강요할 수는 없다는 것을 배웠습니다.

한국에서 일할 때는 제 주변에 대부분의 직장인들이 성장에 목말라 했었습니다. 막 입사한 개발자들은 어떻게 하면 빨리 신입 딱지를 땔 수 있을지 물어봤었고, 주니어 개발자들은 어떻게 하면 빨리 시니어가 될 수 있는지 궁금해했습니다. 동기들은 다 진급하는데 본인만 누락될까봐 걱정하시는 분들이 많았습니다. 그래서 주로 이러한 갈증을 해소시켜주는 멘토링을 했던 기억이 있습니다. 이러한 경험을 갖고 저는 캐나다에 와서 직장 생활을 하면서 문화 충격을 받는데요. 현재 자신이 맡고있는 역할에 충분히 만족하며 딱히 더 성장할 마음이 없는 직장인들이 많기 때문입니다. 이러한 엔지니어들과 얘기를 해보면 소프트웨어 개발 직군이 다른 직군 대비 처우가 얼마나 좋은지 잘 인지하고 있으며 그래서 더 이상 바랄 게 없다고 합니다. 진급과 함께 늘어난 권한만큼 무거운 책임도 부담스럽다고 하고요. 한국에서 어렸을 때 부터 치열한 경쟁 속에 살아온 저는 처음에 이러한 캐나다 동료들이 나태하고 한심하다고 느껴졌습니다. 아마도 예전에 교양 수업에서 들었던 열심히 일하지 않아도 되는 복지 선진국의 폐해일 수도 있겠다고 생각했습니다. 하지만 이러한 엔지니어들을 직접 멘토링하게 되면서 제 관점이 조금씩 바뀌게 되었습니다. 처음에는 이러한 멘티들의 성장을 독려하는 것이 저의 임무라고 생각했습니다. 업무에서 사용하고 있는 기술에 대해서 좀 더 깊이 공부하기를 바라는 마음에 여러 책과 온라인 강의를 추천해주었습니다. 이 친구들이 조직에서 더 두각을 내고 진급을 하려면 어떤 부분에서 더 실력을 키워야 하는지 얘기해 주었습니다. 이렇게 성장하는 방법을 알려주면 고마워할 줄 알았죠. 하지만 저의 이러한 멘토링 방향에 반발하는 멘티를 만났고, 이 친구와 우리는 왜 성장해야 하는가 대해서 수 차례 깊은 대화를 나누었습니다. 그러다가 저는 태어나서 한 번도 의심해보지 않았던 성장이라는 가치에 대해서 자문하게 되었습니다. 나는 왜 이렇게 성장에 집착하는 거지? 왜 다른 사람에게 성장을 강요하려는 거지?? 생각을 해보니 반드시 모든 사람이 성장하고 싶어야 할 이유도 없더군요! 제 생각이 얼마나 편협했었는지를 느끼게 되었습니다. 그래서 이제는 새로운 멘티가 생기면 성장을 하고 싶은지에 대해서 먼저 꼭 물어봅니다. 엔지니어로서 성장을 원치 않는 친구들은 보통 인생의 다른 부분에 열정을 갖고 있더라고요. 어떤 친구는 퇴근 후에 아마추어 하키팀 코치로 투잡을 뛰고, 다른 친구는 영화 감독이 꿈이라서 주말마다 독립 영화를 찍고 있다고 하네요. 이런 친구들은 성장보다는 효율에 초점을 두어 멘토링을 합니다. 저처럼 소프트웨어 개발을 천직으로 삼고 계속해서 공부하며 엔지니어로 성장하고 싶은 사람도 있지만, 그냥 소프트웨어 개발을 괜찮은 돈벌이 수단으로 생각하고 직업 그 이상 이하로도 생각하지 않는 사람도 많습니다. 멘토가 멘티의 성장을 도와줄 수는 있지만, 절대 강요할 수는 없다는 것을 배웠습니다.

성장을 강요하는 멘토, 성장을 거부하는 멘티

전혀 생각하지 못했네요. 좋은 경험과 글에 깨달음을 얻어갑니다!

Learn how to publish a package to npm with a complete setup including, TypeScript, Prettier, Vitest, GitHub Actions, and versioning with Changesets.

How To Create An NPM Package

npm 패키징관련해서 매우 자세하게 작성해둔 글입니다.
타입스트립트로 만드는 방법도 같이 정리되어 있어서 귀한 글이라고 생각합니다.
npm으로 패키지를 배포해보고 싶으신 분은 보시는거 추천드려요~
https://www.totaltypescript.com/how-to-create-an-npm-package

npm 패키징관련해서 매우 자세하게 작성해둔 글입니다. 타입스트립트로 만드는 방법도 같이 정리되어 있어서 귀한 글이라고 생각합니다. npm으로 패키지를 배포해보고 싶으신 분은 보시는거 추천드려요~ https://www.totaltypescript.com/how-to-create-an-npm-package

Total TypeScript

NPM 패키지 만들기 가이드

앞서 포스팅에서는 기본 데이터 직군이라 할 수 있는 데이터 엔지니어, 데이터 분석가, 데이터 과학자 중 먼저 데이터 분석가와 데이터 과학자에 대해서 이야기해보았다. 이번 포스팅에서는 데이터 엔지니어에 대해 이야기해보고자 한다.

데이터 분석가가 데이터 기반 의사 결정을 가능하게 할 수 있으려면, 데이터 과학자가 머신 러닝 모델을 통해 제품이나 서비스의 품질을 개선할 수 있으려면 누군가 데이터 활용과 관계된 인프라를 만들어야 한다. 그게 바로 데이터 엔지니어가 하는 역할이다.

그러면 이 데이터 인프라를 구성하는 컴포넌트로는 무엇이 있을까? 가장 기본적으로는 아래 두 가지로 구성이 된다.

 1. 데이터 웨어하우스
 2. 데이터 파이프라인

데이터 웨어하우스는 데이터 분석을 이용한 전용 대용량 데이터베이스라 할 수 있고 여기에 필요한 데이터를 적재해주는 역할을 하는 것이 바로 데이터 파이프라인이다. 데이터 웨어하우스는 상황에 맞게 작은 데이터베이스(MySQL, Postgres)로 시작해서 데이터의 크기가 커지면 보통 클라우드 기반의 데이터 웨어하우스(Snowflake, BigQuery, Redshift, ...)로 이전해가는 것이 경제적이며 일반적이다. 데이터 웨어하우스도 관계형 데이터베이스이기에 SQL이 여전히 가장 기본이 되고 중요한 기술이며 데이터 모델링이 중요해진다.

데이터 파이프라인은 보통 Python으로 작성이 되며 다양한 데이터 소스들에 있는 데이터를 추출해서 (Extract) 원하는 포맷으로 변환한 다음에 (Transform) 최종적으로 데이터 웨어하우스에 테이블로 로딩(Load)하는 역할을 하게 되며 보통 데이터 소스별로 하나씩 존재하게 된다. 이때 가장 많이 사용되는 프레임웍으로는 Airflow가 있고 Dagster나 Prefect가 대안으로 떠오르고 있긴 하지만 Airflow과 비교할 정도는 아니다.

여기서 데이터의 크기가 더 커지면 대용량 데이터 처리를 위해 Spark과 같은 대용량 처리 시스템이 필요해지고 데이터의 크기 뿐만 아니라 로그 파일과 같이 비구조화된 데이터가 필요해지기 시작하면 데이터 웨어하우스보다 더 스케일이 크고 경제적인 데이터 레이크 (data lake)가 데이터 인프라를 구성하는 컴포넌트로 필요해진다. 데이터 인프라에 대해서는 별도 포스팅으로 더 써보기로 하고 데이터 엔지니어가 알아야하는 기술에 대해 이야기해보자.

 * Python: 기본적으로 데이터 엔지니어는 소프트웨어 엔지니어이기에 면접 때 코딩 테스트를 하는 것이 일반적이다. 데이터 엔지니어로 시작한 사람들 중의 일부는 백엔드 엔지니어로 직군 전환을 하기도 한다.
 * SQL, Data Warehouse, Data Lake: 구조화된 데이터를 많이 다루기에 SQL에 대한 상당한 지식이 필요하며 데이터 전용 DB라 할 수 있는 데이터 웨어하우스와 데이터 레이크에 대한 지식과 경험이 필요하다.
 * 데이터 파이프라인을 작성하고 운영해야 하기에 Airflow와 같은 프레임웍에 대한 지식과 경험이 필요하다.
 * 작은 데이터를 다룰 때는 Pandas로 충분하지만 커지면 Spark이 필요해진다. Spark은 기본적으로 다수의 서버에 나눠 저장된 빅데이터를 처리해주는 시스템인데 Pandas의 스테로이드 버전이라 할 수 있다. 가끔 데이터가 불균등하게 저장된 경우는 에러가 나고 처리 시간이 너무 오래 걸리는 등의 이슈가 생기며 이를 해결하는 것은 상당한 경험을 필요로 한다. 하지만 이론적으로 Pandas 사용과 비슷하며 구조화된 데이터를 다룰 때는 여전히 SparkSQL이라 불리는 SQL을 사용한다.
 * 여기서 한 단계 더 나가면 데이터 관련 서비스를 작성하고 배포하고 운영하기 위해 Docker와 K8s와 같은 컨테이너 기술에 대한 지식이 필요해질 수 있는데 K8s부터는 주니어가 자유롭게 다룰 수 있는 기술은 아니고 어느 정도의 경험이 필요하다.
 * 머신 러닝과 관련된 일을 하기 시작하면 데이터 웨어하우스나 데이터 레이크에서 처리된 데이터를 프로덕션 시스템으로 푸시하는 일도 하게 되는데 이 때부터는 MongoDB, DynamoDB, Cassandra와 같은 NoSQL 시스템도 사용해야할 일들이 생기곤 한다.

다음 포스팅에서 조금더 특화된 데이터 직군이라 할 수 있는 MLOps, ML 엔지니어, Privacy 엔지니어 등에 대해 이야기해보고자 한다.

앞서 포스팅에서는 기본 데이터 직군이라 할 수 있는 데이터 엔지니어, 데이터 분석가, 데이터 과학자 중 먼저 데이터 분석가와 데이터 과학자에 대해서 이야기해보았다. 이번 포스팅에서는 데이터 엔지니어에 대해 이야기해보고자 한다. 데이터 분석가가 데이터 기반 의사 결정을 가능하게 할 수 있으려면, 데이터 과학자가 머신 러닝 모델을 통해 제품이나 서비스의 품질을 개선할 수 있으려면 누군가 데이터 활용과 관계된 인프라를 만들어야 한다. 그게 바로 데이터 엔지니어가 하는 역할이다. 그러면 이 데이터 인프라를 구성하는 컴포넌트로는 무엇이 있을까? 가장 기본적으로는 아래 두 가지로 구성이 된다. <ol ><li>데이터 웨어하우스</li><li>데이터 파이프라인</li></ol> 데이터 웨어하우스는 데이터 분석을 이용한 전용 대용량 데이터베이스라 할 수 있고 여기에 필요한 데이터를 적재해주는 역할을 하는 것이 바로 데이터 파이프라인이다. 데이터 웨어하우스는 상황에 맞게 작은 데이터베이스(MySQL, Postgres)로 시작해서 데이터의 크기가 커지면 보통 클라우드 기반의 데이터 웨어하우스(Snowflake, BigQuery, Redshift, ...)로 이전해가는 것이 경제적이며 일반적이다. 데이터 웨어하우스도 관계형 데이터베이스이기에 SQL이 여전히 가장 기본이 되고 중요한 기술이며 데이터 모델링이 중요해진다. 데이터 파이프라인은 보통 Python으로 작성이 되며 다양한 데이터 소스들에 있는 데이터를 추출해서 (Extract) 원하는 포맷으로 변환한 다음에 (Transform) 최종적으로 데이터 웨어하우스에 테이블로 로딩(Load)하는 역할을 하게 되며 보통 데이터 소스별로 하나씩 존재하게 된다. 이때 가장 많이 사용되는 프레임웍으로는 Airflow가 있고 Dagster나 Prefect가 대안으로 떠오르고 있긴 하지만 Airflow과 비교할 정도는 아니다. 여기서 데이터의 크기가 더 커지면 대용량 데이터 처리를 위해 Spark과 같은 대용량 처리 시스템이 필요해지고 데이터의 크기 뿐만 아니라 로그 파일과 같이 비구조화된 데이터가 필요해지기 시작하면 데이터 웨어하우스보다 더 스케일이 크고 경제적인 데이터 레이크 (data lake)가 데이터 인프라를 구성하는 컴포넌트로 필요해진다. 데이터 인프라에 대해서는 별도 포스팅으로 더 써보기로 하고 데이터 엔지니어가 알아야하는 기술에 대해 이야기해보자. <ul ><li>Python: 기본적으로 데이터 엔지니어는 소프트웨어 엔지니어이기에 면접 때 코딩 테스트를 하는 것이 일반적이다. 데이터 엔지니어로 시작한 사람들 중의 일부는 백엔드 엔지니어로 직군 전환을 하기도 한다.</li><li>SQL, Data Warehouse, Data Lake: 구조화된 데이터를 많이 다루기에 SQL에 대한 상당한 지식이 필요하며 데이터 전용 DB라 할 수 있는 데이터 웨어하우스와 데이터 레이크에 대한 지식과 경험이 필요하다.</li><li>데이터 파이프라인을 작성하고 운영해야 하기에 Airflow와 같은 프레임웍에 대한 지식과 경험이 필요하다.</li><li>작은 데이터를 다룰 때는 Pandas로 충분하지만 커지면 Spark이 필요해진다. Spark은 기본적으로 다수의 서버에 나눠 저장된 빅데이터를 처리해주는 시스템인데 Pandas의 스테로이드 버전이라 할 수 있다. 가끔 데이터가 불균등하게 저장된 경우는 에러가 나고 처리 시간이 너무 오래 걸리는 등의 이슈가 생기며 이를 해결하는 것은 상당한 경험을 필요로 한다. 하지만 이론적으로 Pandas 사용과 비슷하며 구조화된 데이터를 다룰 때는 여전히 SparkSQL이라 불리는 SQL을 사용한다.</li><li>여기서 한 단계 더 나가면 데이터 관련 서비스를 작성하고 배포하고 운영하기 위해 Docker와 K8s와 같은 컨테이너 기술에 대한 지식이 필요해질 수 있는데 K8s부터는 주니어가 자유롭게 다룰 수 있는 기술은 아니고 어느 정도의 경험이 필요하다.</li><li>머신 러닝과 관련된 일을 하기 시작하면 데이터 웨어하우스나 데이터 레이크에서 처리된 데이터를 프로덕션 시스템으로 푸시하는 일도 하게 되는데 이 때부터는 MongoDB, DynamoDB, Cassandra와 같은 NoSQL 시스템도 사용해야할 일들이 생기곤 한다.</li></ul> 다음 포스팅에서 조금더 특화된 데이터 직군이라 할 수 있는 MLOps, ML 엔지니어, Privacy 엔지니어 등에 대해 이야기해보고자 한다.

데이터 이야기 #6: 기본 데이터 직군 - 데이터 엔지니어

안녕하세요. 그린입니다 🍏이번 포스팅에서는 WWDC 2024에서 소개된 Meet Swift Testing 세션을 보면서 Swift Testing에 대해 알아보려합니다 🙋🏻  Meet Swift Testing우리는 그전까지 테스트하면 XCTest를 사용했습니다.그런데 이제 Swift 6부터는 Swift Testing이 도입되었어요.테스팅에서도 이제는 매크로와 같은 최신 기능을 도입하고 동시성과 원활하게 통합해줄 수 있습니다 😃또 중요한건 크로스 플랫폼을 염두해 개발되었다는 점이에요!이제 Swift Testing의 비전 자체는 기본 테스트 솔루션이 되는것에 중점을 두고 있습니다. 그럼 본격적으로 알아볼까요? Building blocks먼저 Swift Testing의 구성 요소를 살펴보겠습니다. 만약 ..

Meet Swift Testing (feat. WWDC 2024)

Swift 6로 버전 업되면서 Swift Testing이 새로 등장했습니다 🙋🏻
기존 XCTest에서 더 발전하여 매크로와 새로운 언어 기능들을 적극 활용하여 개발되었어요.

엄청 단순해지고 테스트 코드 짜기 편해졌다고 느껴집니다.
XCTest로 테스트 코드를 짜고 있었어도 마이그레이션을 손쉽게 할 수 있도록 되어 있습니다.

이러한 Swift Testing을 WWDC 2024의 Meet Swift Testing 세션에서 소개하고 있길래 한번 정독하며 정리해봤습니다!

이제 테스트 코드에 대한 두려움이 많이 반감될것 같아요 😄

Swift 6로 버전 업되면서 Swift Testing이 새로 등장했습니다 🙋🏻기존 XCTest에서 더 발전하여 매크로와 새로운 언어 기능들을 적극 활용하여 개발되었어요. 엄청 단순해지고 테스트 코드 짜기 편해졌다고 느껴집니다.XCTest로 테스트 코드를 짜고 있었어도 마이그레이션을 손쉽게 할 수 있도록 되어 있습니다. 이러한 Swift Testing을 WWDC 2024의 Meet Swift Testing 세션에서 소개하고 있길래 한번 정독하며 정리해봤습니다! 이제 테스트 코드에 대한 두려움이 많이 반감될것 같아요 😄

iOYES

Swift Testing으로 테스트 코드 구현하기

원문 : An SSR Performance Showdown 💡 노트: 첫 번째 버전의 벤치마크에서 몇 가지 실수가 있었으며, 이는 Theo Browne의 이 트윗에 요약되어 있습니다. 먼저 이러한 오류에 대해 사과드리며, Rich Harris, Ryan Carniato, Dan…

(번역) SSR 성능 대결

오늘 소개해드릴 글은 당근의 임유진님이 번역해주신 글입니다.

이제는 나름 주류로 자리잡은 SSR 인데요, 프런트엔드 생태계에서 어떤 툴이 고성능의 SSR을 구현하는데 도움을 줄까 궁금했던 적 있으신가요? Fastify의 리드 메인테이너가 작성한 이 글은 최근 프런트엔드 생태계에서 가장 인기 있는 라이브러리들의 SSR 성능 상태를 조사하여 소개하고 있습니다. 아주 짧은 글이라, 출근길에 가볍게 살펴보기 좋아 번역으로 소개해드립니다 :)

글 링크: https://emewjin.github.io/ssr-performance-showdown/

오늘 소개해드릴 글은 당근의 임유진님이 번역해주신 글입니다. 이제는 나름 주류로 자리잡은 SSR 인데요, 프런트엔드 생태계에서 어떤 툴이 고성능의 SSR을 구현하는데 도움을 줄까 궁금했던 적 있으신가요? Fastify의 리드 메인테이너가 작성한 이 글은 최근 프런트엔드 생태계에서 가장 인기 있는 라이브러리들의 SSR 성능 상태를 조사하여 소개하고 있습니다. 아주 짧은 글이라, 출근길에 가볍게 살펴보기 좋아 번역으로 소개해드립니다 :) 글 링크: https://emewjin.github.io/ssr-performance-showdown/

emewjin.github.io

SSR 성능 대결

The company says the updated version responds to your emotions and tone of voice and allows you to interrupt it midsentence.

OpenAI released its advanced voice mode to more people. Here’s how to get it.

OpenAI가 ChatGPT의 새로운 기능인 Advanced Voice Mode를 출시했습니다.
이 혁신적인 기능은 AI 모델과의 대화를 한층 더 자연스럽고 역동적으로 만들어 준다고 합니다.

아래 5가지 새로운 기능이 추가되었습니다. 이제 ai가 언어를 더 자연스럽게 인식하는 시대가 됐군요!

 1. 중간 개입 가능: 사용자는 AI의 응답 중간에 끼어들어 대화의 방향을 바꿀 수 있습니다.
 2. 감정 인식: 사용자의 음성 톤을 분석해 감정을 파악하고, 그에 맞춰 응답을 조절합니다.
 3. 개인화: 사용자 정보를 기억하여 맞춤형 대화가 가능합니다.
 4. 다국어 지원: 비영어권 언어의 발음이 개선되었습니다.
 5. 새로운 AI 음성: 'Arbor', 'Maple', 'Sol', 'Spruce', 'Vale'이라는 다섯 가지 새로운 AI 음성이 추가되었습니다.

https://www.technologyreview.com/2024/09/24/1104422/openai-released-its-advanced-voice-mode-to-more-people-heres-how-to-get-it/

OpenAI가 ChatGPT의 새로운 기능인 Advanced Voice Mode를 출시했습니다. 이 혁신적인 기능은 AI 모델과의 대화를 한층 더 자연스럽고 역동적으로 만들어 준다고 합니다. 아래 5가지 새로운 기능이 추가되었습니다. 이제 ai가 언어를 더 자연스럽게 인식하는 시대가 됐군요! <ol ><li>중간 개입 가능: 사용자는 AI의 응답 중간에 끼어들어 대화의 방향을 바꿀 수 있습니다.</li><li>감정 인식: 사용자의 음성 톤을 분석해 감정을 파악하고, 그에 맞춰 응답을 조절합니다.</li><li>개인화: 사용자 정보를 기억하여 맞춤형 대화가 가능합니다.</li><li>다국어 지원: 비영어권 언어의 발음이 개선되었습니다.</li><li>새로운 AI 음성: 'Arbor', 'Maple', 'Sol', 'Spruce', 'Vale'이라는 다섯 가지 새로운 AI 음성이 추가되었습니다.</li></ol> https://www.technologyreview.com/2024/09/24/1104422/openai-released-its-advanced-voice-mode-to-more-people-heres-how-to-get-it/

MIT Technology Review

AI와 자연스러운 대화를 할 수 있는 Advanced Voice모드 출시

Examples and guides for using the OpenAI API. Contribute to openai/openai-cookbook development by creating an account on GitHub.

GitHub - openai/openai-cookbook: Examples and guides for using the OpenAI API

OpenAI의 API를 어떻게 사용하면 될지 코드와 함께 설명을 추가해둔 openai cookbook입니다.

openai의 공식 저장소라서 믿고 보셔도 됩니다.
몇 개 문서를 살펴보니 설명도 깔끔하고 예시들도 재밌는거 많습니다.

openai의 api 사용하면서 뭐라도 만들고 싶으신분은 꼭 읽어보세요!

https://github.com/openai/openai-cookbook

OpenAI의 API를 어떻게 사용하면 될지 코드와 함께 설명을 추가해둔 openai cookbook입니다. openai의 공식 저장소라서 믿고 보셔도 됩니다. 몇 개 문서를 살펴보니 설명도 깔끔하고 예시들도 재밌는거 많습니다. openai의 api 사용하면서 뭐라도 만들고 싶으신분은 꼭 읽어보세요! https://github.com/openai/openai-cookbook

GitHub

openai cookbook

Stack Auth is the open-source Auth0 alternative.

OAuth from First Principles - Stack Auth

OAuth가 어떻게 동작하는지를 설명한 글입니다.

사용자가 클라우드 드라이브를 사용하고 있는데 클라이드 드라이브 관리를 도와주는 서드파티 서비스에 클라우드 드라이브의 권한을 주는 일반적으로 0Auth가 필요한 상황을 예시로 발전 과정을 설명합니다.

처음에 사용자가 서드파티에 비밀번호와 아이디를 알려주는 상황주고 보안상 문제가 되는 부분을 알려주면서 서드파티에 접근 권한을 주기 위한 안전한 방법으로 개선해 나가는 과정을 보여주고 OAuth의 초기 모형을 알려줍니다.

이때부터는 훨씬더 정교한 공격인 리다이렉션 URI 조작, USRF, 엑세스 토큰 감청 등의 공격 사례를 보여주면서 이를 막기 위해 개선된 흐름으 ㄹ아렬주면서 PKCE까지 사용하는 OAuth 2.0의 인증흐름을 알려줍니다.

공격 방법을 하나씩 알려주기 때문에 OAuth의 복잡한 인증 흐름이 왜 필요한지 이해하기 좋은 글이었습니다.

https://stack-auth.com/blog/oauth-from-first-principles

OAuth가 어떻게 동작하는지를 설명한 글입니다. 사용자가 클라우드 드라이브를 사용하고 있는데 클라이드 드라이브 관리를 도와주는 서드파티 서비스에 클라우드 드라이브의 권한을 주는 일반적으로 0Auth가 필요한 상황을 예시로 발전 과정을 설명합니다. 처음에 사용자가 서드파티에 비밀번호와 아이디를 알려주는 상황주고 보안상 문제가 되는 부분을 알려주면서 서드파티에 접근 권한을 주기 위한 안전한 방법으로 개선해 나가는 과정을 보여주고 OAuth의 초기 모형을 알려줍니다. 이때부터는 훨씬더 정교한 공격인 리다이렉션 URI 조작, USRF, 엑세스 토큰 감청 등의 공격 사례를 보여주면서 이를 막기 위해 개선된 흐름으 ㄹ아렬주면서 PKCE까지 사용하는 OAuth 2.0의 인증흐름을 알려줍니다. 공격 방법을 하나씩 알려주기 때문에 OAuth의 복잡한 인증 흐름이 왜 필요한지 이해하기 좋은 글이었습니다. https://stack-auth.com/blog/oauth-from-first-principles

stack-auth.com

OAuth가 어떻게 동작하는지를 설명한 글입니다.

사용자가 클라

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

 - YouTube

발표자는 최근 몇 년간 CSS에 다양한 새 문법들이 추가되었지만 사람들은 쓰던 기능만 쓴다며 작업자들에게 실제로 도움 될만한 CSS 문법들을 소개하는 내용의 영상입니다. 50분 영상 중에 기억에 남는 내용만 하나 정리해보았습니다.

14:36 Fluid Typography (유동적 타이포그래피)
font-size: clamp(1rem, 0.6522rem + 1.7391vw, 2rem);

레이아웃이 맘에 안 들 때마다 매번 새 중단점(Breakpoints)을 추가하는 대신에 CSS의
clamp
문법을 사용해서 뷰포트 크기에 따라 요소의 크기가 유동적으로 조정되는 시스템을 만드는 방법을 소개합니다. clamp는 글꼴 크기뿐만 아니라 글자 사이의 공백(whitespace) 간격도 조정해 줍니다.

clamp
는 (최소값, 기본값, 최대값) 순서대로 입력하며 Chrome 79, Safari 13.1부터 지원되는 문법으로, 96.3%의 브라우저 버전에서 사용 가능하므로 현재 시점에서 호환성이 꽤 높습니다.
개발자와 디자이너의 협업도 Utopia라는 Figma 플러그인을 사용하면 가능합니다. Utopia를 사용하면 유형별로 clamp CSS 변수 코드를 생성해 주고 이를 타이포그래피 별로 지정하면 시스템화 할 수 있습니다. 반응형을 중요시 여기는 서비스라면 도입해 볼 만한 가치가 있을 것 같습니다.

웹사이트 제작은 팀 스포츠고, 디자이너와 개발자가 긴밀히 협력해서 CSS의 잠재력을 최대한 활용해야 한다는 내용도 기억에 남았습니다. 디자이너가 CSS를 배우고, 개발자도 디자인에 참여해야 한다고 하는데 맞는 말인것 같습니다.

https://www.youtube.com/watch?v=su6WA0kUUJE&ab_channel=WebConferencesAmsterdam

발표자는 최근 몇 년간 CSS에 다양한 새 문법들이 추가되었지만 사람들은 쓰던 기능만 쓴다며 작업자들에게 실제로 도움 될만한 CSS 문법들을 소개하는 내용의 영상입니다. 50분 영상 중에 기억에 남는 내용만 하나 정리해보았습니다. 14:36 Fluid Typography (유동적 타이포그래피)<pre ><code class="language-css">font-size: clamp(1rem, 0.6522rem + 1.7391vw, 2rem);</code></pre>레이아웃이 맘에 안&nbsp;들 때마다 매번 새 중단점(Breakpoints)을 추가하는 대신에 CSS의 <code >clamp</code> 문법을 사용해서 뷰포트 크기에 따라 요소의 크기가 유동적으로 조정되는 시스템을 만드는 방법을 소개합니다. clamp는 글꼴 크기뿐만 아니라 글자 사이의 공백(whitespace) 간격도 조정해 줍니다. <code >clamp</code>는 (최소값, 기본값, 최대값) 순서대로 입력하며 Chrome 79, Safari 13.1부터 지원되는 문법으로, 96.3%의 브라우저 버전에서 사용 가능하므로 현재 시점에서 호환성이 꽤 높습니다. 개발자와 디자이너의 협업도 Utopia라는 Figma 플러그인을 사용하면 가능합니다. Utopia를 사용하면 유형별로 clamp CSS 변수 코드를&nbsp;생성해 주고&nbsp;이를 타이포그래피 별로&nbsp;지정하면 시스템화 할 수 있습니다. 반응형을 중요시 여기는 서비스라면&nbsp;도입해 볼 만한&nbsp;가치가 있을 것 같습니다. 웹사이트 제작은 팀 스포츠고, 디자이너와 개발자가 긴밀히 협력해서 CSS의 잠재력을 최대한 활용해야 한다는 내용도 기억에 남았습니다. 디자이너가 CSS를 배우고, 개발자도 디자인에 참여해야 한다고 하는데 맞는 말인것 같습니다. https://www.youtube.com/watch?v=su6WA0kUUJE&amp;ab_channel=WebConferencesAmsterdam

www.youtube.com

새 CSS 문법으로 웹 디자인 엔지니어링하기

서버 구성/배포쪽도 그렇지만, 앱 개발도 진짜 편해졌다. 고릿적엔 애플 개발자 등록하는 것부터 진짜 피곤했는데, 이젠 진짜 클릭클릭만 해서 등록 완료하고, iOS는 물론 안드로이드도 테스트 앱 빌드하고 배포하는데 클릭클릭만 몇 번하니 끝. 웹 프론트, 백엔드, 안드로이드, iOS 까지 프로토타입 만들고 프로젝트 기반을 구성하는데 3일도 안걸림.

게다가 샘플 앱 정도는 ChatGPT나 Claude한테 시키면 원샷으로 만들어주니, 이제 진짜 기초가 탄탄한 엔지니어링 실력을 갖추지 않고서는 개발자라고 말하기도 어려울 듯. 아니, 10년 전쯤 잠깐 퍼블리셔와 프론트엔드 개발자를 급으로 나눴던 시대처럼, 이제는 단순히 구현만하는 개발자와 컴퓨터 과학 지식이 있는 엔지니어를 급으로 나누게 될 것 같다.

서버 구성/배포쪽도 그렇지만, 앱 개발도 진짜 편해졌다. 고릿적엔 애플 개발자 등록하는 것부터 진짜 피곤했는데, 이젠 진짜 클릭클릭만 해서 등록 완료하고, iOS는 물론 안드로이드도 테스트 앱 빌드하고 배포하는데 클릭클릭만 몇 번하니 끝. 웹 프론트, 백엔드, 안드로이드, iOS 까지 프로토타입 만들고 프로젝트 기반을 구성하는데 3일도 안걸림. 게다가 샘플 앱 정도는 ChatGPT나 Claude한테 시키면 원샷으로 만들어주니, 이제 진짜 기초가 탄탄한 엔지니어링 실력을 갖추지 않고서는 개발자라고 말하기도 어려울 듯. 아니, 10년 전쯤 잠깐 퍼블리셔와 프론트엔드 개발자를 급으로 나눴던 시대처럼, 이제는 단순히 구현만하는 개발자와 컴퓨터 과학 지식이 있는 엔지니어를 급으로 나누게 될 것 같다.

서버 구성/배포쪽도 그렇지만, 앱 개발도 진짜 편해졌다. 고릿적엔

코드 조커, 오프 | 이 강의를 통해 전반적인 프런트엔드 테스트 종류를 파악하고, 상황에 맞는 적절한 테스트 선택을 통해 신뢰감 있는 테스트를 작성하는 방법을 배웁니다., 🎊 이벤트 🎊&nbsp;
1부 30% 쿠폰 받아가세요! (~2024.03.31)
📌 쿠폰 번호:

실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트 강의 | 코드 조커, 오프 - 인프런

jaesung Lee형님과 실무에서 몇 년간 실무에서 경험한 다양한 프런트엔드 테스트 전략을 담아보자고 강의 준비를 시작했던게 엊그제 같은데 벌써 인프런에 출시한지 9달이 지났네요.

강의는 저희 예상보다 훨씬 더 많은 분들이 수강해주셨고 벌써 "실무에 바로 적용하는 프런트엔드 테스트" 총 수강생이 1,000명이 넘었습니다. 다른 훌륭한 인프런 강의들에 비해 수강생이 많다고 할 수는 없지만 사실 저희 예상을 훨씬 넘는 수치였었기 때문에 많이 놀랐습니다.

많은 프런트엔드 개발자분들이 해당 주제에 관심을 갖고 있다는 것을 새로 알게 된 순간이였고 질문에 답변을 나누면서 많은 것을 배우기도 한 시간이였는데요.

감사의 의미로 앞으로도 꾸준히 재밌는 테스트 소식이 있으면 공유 드리고, 혹시 해당 주제에 궁금증이 있으시지만 가격 때문에 고민하셨던 분들을 위해 큰 할인을 준비했습니다.

추가로 혹시 프런트엔드 테스트 관련해서 궁금한 점이 있으시거나 이야기를 나눠보고 싶으신 분이 있다면 편하게 연락주셔도 좋을 것 같습니다. 그럼 즐거운 한가위 되시길 바랍니다!

-----
 * 1부: https://inf.run/ba6qp
   * 쿠폰: 17510-432e3ef69dde (61% 할인)
 * 2부: https://inf.run/qwKc6
   * 쿠폰: 17511-7be3e434af63 (54% 할인)

[수강바구니 → 쿠폰선택], [대시보드 → 쿠폰함]에서 보유한 쿠폰코드를 입력하면 쿠폰이 발급됩니다.

jaesung Lee형님과 실무에서 몇 년간 실무에서 경험한 다양한 프런트엔드 테스트 전략을 담아보자고 강의 준비를 시작했던게 엊그제 같은데 벌써 인프런에 출시한지 9달이 지났네요. 강의는 저희 예상보다 훨씬 더 많은 분들이 수강해주셨고 벌써 "실무에 바로 적용하는 프런트엔드 테스트" 총 수강생이 1,000명이 넘었습니다. 다른 훌륭한 인프런 강의들에 비해 수강생이 많다고 할 수는 없지만 사실 저희 예상을 훨씬 넘는 수치였었기 때문에 많이 놀랐습니다. 많은 프런트엔드 개발자분들이 해당 주제에 관심을 갖고 있다는 것을 새로 알게 된 순간이였고 질문에 답변을 나누면서 많은 것을 배우기도 한 시간이였는데요. 감사의 의미로 앞으로도 꾸준히 재밌는 테스트 소식이 있으면 공유 드리고, 혹시 해당 주제에 궁금증이 있으시지만 가격 때문에 고민하셨던 분들을 위해 큰 할인을 준비했습니다. 추가로 혹시 프런트엔드 테스트 관련해서 궁금한 점이 있으시거나 이야기를 나눠보고 싶으신 분이 있다면 편하게 연락주셔도 좋을 것 같습니다. 그럼 즐거운 한가위 되시길 바랍니다! -----<ul ><li>1부: https://inf.run/ba6qp<ul ><li>쿠폰: 17510-432e3ef69dde (61% 할인)</li></ul></li><li>2부: https://inf.run/qwKc6<ul ><li>쿠폰: 17511-7be3e434af63 (54% 할인)</li></ul></li></ul> [수강바구니 → 쿠폰선택], [대시보드 → 쿠폰함]에서 보유한 쿠폰코드를 입력하면 쿠폰이 발급됩니다.

인프런

실무에 바로 적용하는 프런트엔드 테스트 할인 안내

토스의 개발자 컨퍼런스인 SLASH 24를 다녀왔습니다!

이번 행사는 참가 경쟁률이 8대 1을 기록했다고 해요. 감사하게도 저는 VIP로 초대받아 다녀왔어요.

덕분에 프론트엔드 세션도 듣고 토스뱅크, 토스증권의 CTO분들의 스페셜 세션도 들을 수 있었어요.

영상으로 현장 모습과 후기를 담았으니 확인해보세요!

https://youtu.be/twIbs1bql-4

토스의 개발자 컨퍼런스인 SLASH 24를 다녀왔습니다! 이번 행사는 참가 경쟁률이 8대 1을 기록했다고 해요. 감사하게도 저는 VIP로 초대받아 다녀왔어요. 덕분에 프론트엔드 세션도 듣고 토스뱅크, 토스증권의 CTO분들의 스페셜 세션도 들을 수 있었어요. 영상으로 현장 모습과 후기를 담았으니 확인해보세요! https://youtu.be/twIbs1bql-4

SLASH 24, VIP는 어떤 혜택이?

구매 전환율을 폭발적으로 올릴 수 있는 밴드웨건 효과, 앵커링 효과, 넛지 효과와 같은 소비자 심리학 법칙과 통찰을 하나씩 알아보겠습니다.

구매 전환율이 2배가 되는 7가지 소비자 심리학 법칙 | Hyper Conversion

밴드웨건 효과: 대세를 따라가려는 소비자 심리학
편승 효과라고도 부르는 밴드웨건 효과는 사람들이 유행이나 대세를 따라가는 경향을 말합니다. 쉽게 말해 ‘남들이 많이 산데는 이유가 있다’라는 심리예요. 이 효과를 잘 활용하면 전환율을 크게 높일 수 있습니다.

권위의 법칙: 전문가의 말은 신뢰하는 소비자 심리학
권위의 법칙은 권위 있는 전문가는 나보다 더 잘 알 것이라고 여기고 그렇기에 전문가가 하는 말을 신뢰하거나 따르는 경향을 말합니다. 이 심리를 활용하면 브랜드의 신뢰도를 높이고 보다 쉽게 구매 결정을 유도할 수 있습니다.

앵커링 효과: 가치는 상대적이라는 소비자 심리학
앵커링 효과는 사람들이 의사 결정을 할 때 처음 접한 정보를 기반으로 가치를 다르게 판단하는 경향을 이야기해요. 쉽게 말해, 처음 제공된 정보가 이후 제공되는 정보를 판단하는 데 큰 영향을 미친다는 거죠. 이 원리를 잘 활용하면 고객의 구매 결정에 결정적인 영향을 줄 수 있습니다.

손실 회피 편향: 이익보다 손실을 더 크게 느끼는 소비자 심리학
손실 회피 편향이란 사람들이 이익이 주는 행복보다 손실이 주는 고통을 더 강하게 느끼며, 손실을 피하려는 경향이 강하다는 심리학 법칙을 말합니다. 특히 할인 이벤트나 프로모션을 진행할 때 이 현상을 잘 활용하면 구매 욕구를 효과적으로 자극할 수 있어요.

본 게시글은 ‘hyperconversion’의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

밴드웨건 효과: 대세를 따라가려는 소비자 심리학편승 효과라고도 부르는 밴드웨건 효과는 사람들이 유행이나 대세를 따라가는 경향을 말합니다. 쉽게 말해 ‘남들이 많이 산데는 이유가 있다’라는 심리예요. 이 효과를 잘 활용하면 전환율을 크게 높일 수 있습니다. 권위의 법칙: 전문가의 말은 신뢰하는 소비자 심리학권위의 법칙은 권위 있는 전문가는 나보다 더 잘 알 것이라고 여기고 그렇기에 전문가가 하는 말을 신뢰하거나 따르는 경향을 말합니다. 이 심리를 활용하면 브랜드의 신뢰도를 높이고 보다 쉽게 구매 결정을 유도할 수 있습니다. 앵커링 효과: 가치는 상대적이라는 소비자 심리학앵커링 효과는 사람들이 의사 결정을 할 때&nbsp;처음 접한 정보를 기반으로 가치를 다르게 판단하는 경향을 이야기해요. 쉽게 말해, 처음 제공된 정보가 이후 제공되는 정보를 판단하는 데 큰 영향을 미친다는 거죠. 이 원리를 잘 활용하면 고객의 구매 결정에 결정적인 영향을 줄 수 있습니다. 손실 회피 편향: 이익보다 손실을 더 크게 느끼는 소비자 심리학손실 회피 편향이란 사람들이&nbsp;이익이 주는 행복보다 손실이 주는 고통을 더 강하게 느끼며, 손실을 피하려는 경향이 강하다는 심리학 법칙을 말합니다. 특히 할인 이벤트나 프로모션을 진행할 때 이 현상을 잘 활용하면 구매 욕구를 효과적으로 자극할 수 있어요. 본 게시글은 ‘hyperconversion’의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

Hyper Conversion

구매전환율 2배가 되는 심리학 법칙 7가지

스타 팟캐스터로서 케빈 밀러가 오늘날 가장 영향력 있는 200여 명의 ‘체인지 메이커’와 나눈 대화에서 얻은 성장과 성공의 통찰이 담겨 있다.

해내는 사람에게는 한 가지가 있다

매일 조금씩만 하면 365일째에는 분명히 달라져 있을 거라고 생각하면서도 왜 우리는 일어나 운동화 끈을 묶고 밖으로 나가거나, 영어 공부를 위해 어플을 열지 않을까? 오늘 작은 몫을 해낸다면 변화는 분명히 나의 것이라는 걸 알면서도 왜 우리는 실행하지 않을까?

케빈 밀러는 여기서 질문을 던진다. 당신은 ‘무엇이 나를 움직이는지’ 생각해본 적이 있는가? 당신 삶의 원동력은 무엇인가? 케빈 밀러는 말한다. “당신의 세계는 내면의 원동력으로 만들어진다.”

많은 이들이 원대한 꿈을 꾸지만 잠재력을 불태울 수 있는 부싯돌이나 촉매제에 대해서는 생각하지 않는다. 목표도 있고 구체적인 계획도 있지만 실행하지 못하는 이유는 바로 “삶의 원동력”을 살피지 않았기 때문이다.

실제로 내가 무엇을 원하는지 정확하고 구체적으로 인식하고, 실행력을 끌어내는 핵심 동기를 에너지원 삼아 달려 나가는 것. 이것이 원동력의 핵심이다. 우리에겐 원동력이 필요하다.

밀러는 ‘원동력’이라는 가치를 구체적으로 7가지로 나누었다. 하나의 무기보다 일곱 개의 무기를 갖췄을 때 더 큰 힘을 얻고 두려움 없이 목표까지 나아갈 수 있다.

1️⃣삶의 목적
무엇을 믿느냐가 아니라 얼마나 크고 강력하게 믿느냐가 당신의 원동력을 결정한다. 인생의 목적을 명확히 하고 거기에 헌신하라. 이것이 당신이 가질 수 있는 가장 큰 자산이다.

2️⃣관계
좋은 관계를 찾기 위해 먼저 살펴봐야 할 곳은 거울과 과거이다. 나 자신과의 관계가 관계의 최우선이다.

3️⃣몸
왜 우리는 몸의 기능에 대해서는 ‘으레 떨어지는 것’이라며 차차 포기하고 꾸준히 관리하지 않을까? 좋은 운동은 ‘뭐가 됐든 당신이 하는 운동’이다.

4️⃣마음
우리는 본래 지닌 잠재력보다 훨씬 더 적은 능력을 쓰고 있다. 그러나 자신에게 잠재력이 있다는 것을 깨닫는 것만으로는 잠재력을 실현할 수 없다. 잠재력은 전등 스위치가 아니라 마라톤이기 때문이다.

5️⃣일
지금 당장 어떤 일을 하고 싶은가? 첫 번째 단계는 가능하다고 믿는 것이고, 두 번째 단계는 선택지를 탐색하는 것이다.

6️⃣돈
돈이란 단순히 재화를 교환하는 수단이 아니라 라이프스타일이다. 당신이 진정 재정적으로 원하는 것은 무엇인가?

7️⃣성취
삶의 마지막에 남는 후회는 ‘내가 원하는 삶을 살지 못한 것’이라고 한다. 누구에게나 각자만의 위대함이 있다. 남들보다 탁월한 자신만의 영역에서 우리는 고유하게 위대하다. 후회 없이, 고유의 영역에서 최고가 되라.

저자는 타인의 영향력을 리셋하고 완전히 새로운 기반에서 자신을 바라보라고 말한다. 우리는 성장 배경, 사회적, 문화적 기대에 생각보다 크게 영향을 받는다.

우리가 수행하는 역할과 의무는 어쩌면 부모님이 우리에게 심어준 긍정적 기대나 부정적 편견, 또는 성인이라면 이래야 하고 저래야 한다는 사회적 기대에 따른 것일 수도 있다. 지금 당신은 모든 영향력에서 벗어나 자유롭게 자신을 펼치고 있는가? 변화를 꿈꾼다면 자신의 모습을 진정으로 그렇게 그려볼 수 있는가?

우리는 진실이라고 믿는 것에 따라 자신을 인식한다. 성장하고 싶다면 성장한 나를 그릴 수 있어야 한다. 그리고 그렇게 될 수 있다고 믿어야 한다. 또한 미래의 변화를 마음속에 그리려면 변화를 위해 노력하는 자신의 모습을 마음속에 그려야 한다.

“나는 누구에게나 각자만의 위대함이 있다고 굳게 믿는다. 남들과 차별화되고 남들보다 탁월할 수 있는, 남들과 다른 위대함 말이다. 남들보다 더 위대하기 때문에 위대한 일을 하는 것이 아니라, 남들보다 탁월한 자신만의 영역에서 우리는 고유하게 위대한 일을 하는 것이다.“

”그것은 우리 모두가 할 수 있는 일이며, 우리가 받아들이기만 한다면 우리에게 예정된 운명이다. 우리는 우리가 기대하는 대로 된다.“

저자는 원동력을 폭발적으로 키우는 ‘성장 마인드셋’을 이야기한다. ‘해야 한다(have to)’는 그만두고 ‘하고 싶다(want to)’로 바꾸어 생각하는 것이다. 우리는 좋은 것을 선택할 수 있다. 그 차이가 모든 것을 결정한다. 모든 것은 관점에 달려 있다.

선택은 우리가 처한 상황과 상관없이 우리를 자유롭게 하고 자율권을 주는, 인생에서 가장 자유로운 행동이다. 우리가 주인 의식을 가지고 삶에서 선택권과 통제권을 쥐면, 상황은 획기적으로 바뀐다.

외부의 환경은 통제할 수 없지만, 생각을 바꿈으로써 내면을 통제할 수 있다. 그리고 이러한 내면의 힘으로 우리는 꿈꿔 왔던, 폭발적인 성장의 경로에 올라탈 수 있다.

“관점을 키우는 가장 좋은 방법은 무언가를 추구할 때의 위험 시나리오 대신 그것을 하지 않을 때의 위험에 집중하는 것이다. 1년이 지나도 ‘χ’가 일어나지 않는다면 나는 괜찮을까? 그때도 내가 지금에 머문다면 1년 후의 자신에 대해 어떻게 느끼게 될까?” p.91

“당신의 몸 중 괜찮은 곳은 어디인가? 왜 우리는 우리 몸이라는 ‘수단(vehicle)’에는 큰 기대를 품지 않으며, 왜 꾸준히 관리하지 않을까?” p.129

“자신의 잠재력과 능력에 대한 믿음을 바꾸면 잠재력과 능력은 조금 더 커진다. 성장은 이러한 믿음을 품고 행동할 때 일어난다. 마라톤을 완주할 수 있다고 믿는다고 해서 결승선에 이르는 것은 아니다. 그러나 믿음은 당신이 문밖으로 나와 훈련을 시작하도록 동기를 부여해준다.” p.157

“현재 연봉은 5000만 원이지만, 3억 원을 벌고 싶다면 자유롭게 상상해보라. 반대로 더 단순하고 더 검소한 삶을 살고 싶다면 그런 삶을 자유롭게 머릿속에 그려보라. 이런 식으로 계속 생각하는 연습을 해보면, 돈이란 단순히 재화를 교환하는 수단이 아니라 라이프스타일이기 때문에, 돈에 대한 진정하고 건강한 동기를 찾는 데 도움이 된다.” p.215

“부모님은 안 좋은 일이 벌어지면 “이 일을 어떻게 써먹을 수 있을까?”라고 자문하셨다. 부모님의 질문에는 어려운 문제를 통찰력과 지혜를 얻는 기회로 삼을 수도 있다는 의미가 담겨 있다. 이런 생각의 전환은 우리를 더 강하게 만든다. 우리는 좋은 것을 선택할 수 있다. 그 차이가 모든 것을 결정한다. 모든 것은 관점에 달려 있다.” p.254

매일 조금씩만 하면 365일째에는 분명히 달라져 있을 거라고 생각하면서도 왜 우리는 일어나 운동화 끈을 묶고 밖으로 나가거나, 영어 공부를 위해 어플을 열지 않을까? 오늘 작은 몫을 해낸다면 변화는 분명히 나의 것이라는 걸 알면서도 왜 우리는 실행하지 않을까? 케빈 밀러는 여기서 질문을 던진다. 당신은 ‘무엇이 나를 움직이는지’ 생각해본 적이 있는가? 당신 삶의 원동력은 무엇인가? 케빈 밀러는 말한다. “당신의 세계는 내면의 원동력으로 만들어진다.” 많은 이들이 원대한 꿈을 꾸지만 잠재력을 불태울 수 있는 부싯돌이나 촉매제에 대해서는 생각하지 않는다. 목표도 있고 구체적인 계획도 있지만 실행하지 못하는 이유는 바로 “삶의 원동력”을 살피지 않았기 때문이다. 실제로 내가 무엇을 원하는지 정확하고 구체적으로 인식하고, 실행력을 끌어내는 핵심 동기를 에너지원 삼아 달려 나가는 것. 이것이 원동력의 핵심이다. 우리에겐 원동력이 필요하다. 밀러는 ‘원동력’이라는 가치를 구체적으로 7가지로 나누었다. 하나의 무기보다 일곱 개의 무기를 갖췄을 때 더 큰 힘을 얻고 두려움 없이 목표까지 나아갈 수 있다. 1️⃣삶의 목적무엇을 믿느냐가 아니라 얼마나 크고 강력하게 믿느냐가 당신의 원동력을 결정한다. 인생의 목적을 명확히 하고 거기에 헌신하라. 이것이 당신이 가질 수 있는 가장 큰 자산이다. 2️⃣관계좋은 관계를 찾기 위해 먼저 살펴봐야 할 곳은 거울과 과거이다. 나 자신과의 관계가 관계의 최우선이다. 3️⃣몸왜 우리는 몸의 기능에 대해서는 ‘으레 떨어지는 것’이라며 차차 포기하고 꾸준히 관리하지 않을까? 좋은 운동은 ‘뭐가 됐든 당신이 하는 운동’이다. 4️⃣마음우리는 본래 지닌 잠재력보다 훨씬 더 적은 능력을 쓰고 있다. 그러나 자신에게 잠재력이 있다는 것을 깨닫는 것만으로는 잠재력을 실현할 수 없다. 잠재력은 전등 스위치가 아니라 마라톤이기 때문이다. 5️⃣일지금 당장 어떤 일을 하고 싶은가? 첫 번째 단계는 가능하다고 믿는 것이고, 두 번째 단계는 선택지를 탐색하는 것이다. 6️⃣돈돈이란 단순히 재화를 교환하는 수단이 아니라 라이프스타일이다. 당신이 진정 재정적으로 원하는 것은 무엇인가? 7️⃣성취삶의 마지막에 남는 후회는 ‘내가 원하는 삶을 살지 못한 것’이라고 한다. 누구에게나 각자만의 위대함이 있다. 남들보다 탁월한 자신만의 영역에서 우리는 고유하게 위대하다. 후회 없이, 고유의 영역에서 최고가 되라. 저자는 타인의 영향력을 리셋하고 완전히 새로운 기반에서 자신을 바라보라고 말한다. 우리는 성장 배경, 사회적, 문화적 기대에 생각보다 크게 영향을 받는다. 우리가 수행하는 역할과 의무는 어쩌면 부모님이 우리에게 심어준 긍정적 기대나 부정적 편견, 또는 성인이라면 이래야 하고 저래야 한다는 사회적 기대에 따른 것일 수도 있다. 지금 당신은 모든 영향력에서 벗어나 자유롭게 자신을 펼치고 있는가? 변화를 꿈꾼다면 자신의 모습을 진정으로 그렇게 그려볼 수 있는가? 우리는 진실이라고 믿는 것에 따라 자신을 인식한다. 성장하고 싶다면 성장한 나를 그릴 수 있어야 한다. 그리고 그렇게 될 수 있다고 믿어야 한다. 또한 미래의 변화를 마음속에 그리려면 변화를 위해 노력하는 자신의 모습을 마음속에 그려야 한다. “나는 누구에게나 각자만의 위대함이 있다고 굳게 믿는다. 남들과 차별화되고 남들보다 탁월할 수 있는, 남들과 다른 위대함 말이다. 남들보다 더 위대하기 때문에 위대한 일을 하는 것이 아니라, 남들보다 탁월한 자신만의 영역에서 우리는 고유하게 위대한 일을 하는 것이다.“ ”그것은 우리 모두가 할 수 있는 일이며, 우리가 받아들이기만 한다면 우리에게 예정된 운명이다. 우리는 우리가 기대하는 대로 된다.“ 저자는 원동력을 폭발적으로 키우는 ‘성장 마인드셋’을 이야기한다. ‘해야 한다(have to)’는 그만두고 ‘하고 싶다(want to)’로 바꾸어 생각하는 것이다. 우리는 좋은 것을 선택할 수 있다. 그 차이가 모든 것을 결정한다. 모든 것은 관점에 달려 있다. 선택은 우리가 처한 상황과 상관없이 우리를 자유롭게 하고 자율권을 주는, 인생에서 가장 자유로운 행동이다. 우리가 주인 의식을 가지고 삶에서 선택권과 통제권을 쥐면, 상황은 획기적으로 바뀐다. 외부의 환경은 통제할 수 없지만, 생각을 바꿈으로써 내면을 통제할 수 있다. 그리고 이러한 내면의 힘으로 우리는 꿈꿔 왔던, 폭발적인 성장의 경로에 올라탈 수 있다. “관점을 키우는 가장 좋은 방법은 무언가를 추구할 때의 위험 시나리오 대신 그것을 하지 않을 때의 위험에 집중하는 것이다. 1년이 지나도 ‘χ’가 일어나지 않는다면 나는 괜찮을까? 그때도 내가 지금에 머문다면 1년 후의 자신에 대해 어떻게 느끼게 될까?” p.91 “당신의 몸 중 괜찮은 곳은 어디인가? 왜 우리는 우리 몸이라는 ‘수단(vehicle)’에는 큰 기대를 품지 않으며, 왜 꾸준히 관리하지 않을까?” p.129 “자신의 잠재력과 능력에 대한 믿음을 바꾸면 잠재력과 능력은 조금 더 커진다. 성장은 이러한 믿음을 품고 행동할 때 일어난다. 마라톤을 완주할 수 있다고 믿는다고 해서 결승선에 이르는 것은 아니다. 그러나 믿음은 당신이 문밖으로 나와 훈련을 시작하도록 동기를 부여해준다.” p.157 “현재 연봉은 5000만 원이지만, 3억 원을 벌고 싶다면 자유롭게 상상해보라. 반대로 더 단순하고 더 검소한 삶을 살고 싶다면 그런 삶을 자유롭게 머릿속에 그려보라. 이런 식으로 계속 생각하는 연습을 해보면, 돈이란 단순히 재화를 교환하는 수단이 아니라 라이프스타일이기 때문에, 돈에 대한 진정하고 건강한 동기를 찾는 데 도움이 된다.” p.215 “부모님은 안 좋은 일이 벌어지면 “이 일을 어떻게 써먹을 수 있을까?”라고 자문하셨다. 부모님의 질문에는 어려운 문제를 통찰력과 지혜를 얻는 기회로 삼을 수도 있다는 의미가 담겨 있다. 이런 생각의 전환은 우리를 더 강하게 만든다. 우리는 좋은 것을 선택할 수 있다. 그 차이가 모든 것을 결정한다. 모든 것은 관점에 달려 있다.” p.254

aladin

매일 조금씩만 하면 365일째에는 분명히 달라져 있을 거라고 생각

블로그나 SNS 등에서 보면 많은 개발자들이 개발을 더 잘하기 위한 고민 상담을 하는 것을 볼 수 있다. 나는 이러한 고민 속에 개발 실력뿐만 아니라 일을 잘하는 방법에 대한 고민거리도 녹아 있다고 생각한다. 내가 개발 커뮤니티에서만 이러한 고민을 보게 되다 보니 그런 것일 수도 있지만 개발자들이 질문하는 고민은 유독 “개발 실력”이라는 것에 국한되어 있어 보인다. “개발을 잘하려면 어떻게 해야 할까요?”, “좋은 개발자가 되려면 어떻게 해야 할까요?”, “어떻게 하면 코딩 실력을 키울 수 있을까요?” 등등 말이다.

개발자가 ‘일’ 잘하는 방법

좋은 포스트가 있어 공유해요!

개발자 경호님의 깔끔한 개발자가 일 잘하는 방법입니다!
목차를 보시고 자세한 내용은 링크를 참고하세요!

 * 단순하고 명확하게 이야기 하세요.
 * 문제는 해결책과 함께 얘기하는 겁니다.
 * 복잡할수록 단순하게 쪼개주면 쉬워집니다.
 * 간접적이고 비언어적인 표현은 해석하기 어렵습니다.
 * 업무 요청은 디테일하게, 이게 매너입니다.
 * 상대방을 바꾸려 하지말고 같은 편에 섭니다.
 * 모든 주장에는 근거가 있어야 합니다.
 * 모르는 걸 솔직히 말하면 더 매력적입니다.
 * 협상을 겁내지 마세요, 대부분 가능합니다.

https://veluxer62.github.io/explanation/how-developers-can-work-effectively/

좋은 포스트가 있어 공유해요! 개발자 경호님의 깔끔한 개발자가 일 잘하는 방법입니다!목차를 보시고 자세한 내용은 링크를 참고하세요! <ul ><li>단순하고 명확하게 이야기 하세요.</li><li>문제는 해결책과 함께 얘기하는 겁니다.</li><li>복잡할수록 단순하게 쪼개주면 쉬워집니다.</li><li>간접적이고 비언어적인 표현은 해석하기 어렵습니다.</li><li>업무 요청은 디테일하게, 이게 매너입니다.</li><li>상대방을 바꾸려 하지말고 같은 편에 섭니다.</li><li>모든 주장에는 근거가 있어야 합니다.</li><li>모르는 걸 솔직히 말하면 더 매력적입니다.</li><li>협상을 겁내지 마세요, 대부분 가능합니다.</li></ul> https://veluxer62.github.io/explanation/how-developers-can-work-effectively/

Veluxer's Blog

스프링은 다양한 프로그래밍 모델을 제공해 개발자가 웹 애플리케이션을 구축할 때 적합한 방식을 선택할 수 있도록 지원합니다. 이러한 모델들은 개발자가 코드를 어떻게 구성하고 관리할지에 대한 가이드라인을 제시하며, 각 모델은 특정 유형의 애플리케이션이나 개발 스타일에 더 적합할 수 있습니다.

스프링과 프로그래밍 모델

스프링을 제대로 활용하고 싶다면 다양한 프로그래밍 모델에 대한 이해는 필수이다. 스프링은 애플리케이션 개발 방식에 따라 다양한 프로그래밍 모델을 제공하며, 각 모델은 고유한 장점과 특징을 가지고 있다.

이 글에서는 스프링의 주요 프로그래밍 모델인 애노테이션 기반과 경량 함수형을 가볍게 알아본다. 스프링이 지원 또는 제공하는 프로그래밍 모델에 대한 깊이 있는 이해를 통해 소프트웨어 엔지니어로서 문제 해결력을 한 단계 향상시키고, 더욱 효율적이고 유연한 애플리케이션을 개발할 수 있을 것이다.

https://www.linkedin.com/pulse/%25EC%258A%25A4%25ED%2594%2584%25EB%25A7%2581%25EA%25B3%25BC-%25ED%2594%2584%25EB%25A1%259C%25EA%25B7%25B8%25EB%259E%2598%25EB%25B0%258D-%25EB%25AA%25A8%25EB%258D%25B8-springrunner-emnec/

스프링을 제대로 활용하고 싶다면 다양한 프로그래밍 모델에 대한 이해는 필수이다. 스프링은 애플리케이션 개발 방식에 따라 다양한 프로그래밍 모델을 제공하며, 각 모델은 고유한 장점과 특징을 가지고 있다. 이 글에서는 스프링의 주요 프로그래밍 모델인 애노테이션 기반과 경량 함수형을 가볍게 알아본다. 스프링이 지원 또는 제공하는 프로그래밍 모델에 대한 깊이 있는 이해를 통해 소프트웨어 엔지니어로서 문제 해결력을 한 단계 향상시키고, 더욱 효율적이고 유연한 애플리케이션을 개발할 수 있을 것이다. https://www.linkedin.com/pulse/%25EC%258A%25A4%25ED%2594%2584%25EB%25A7%2581%25EA%25B3%25BC-%25ED%2594%2584%25EB%25A1%259C%25EA%25B7%25B8%25EB%259E%2598%25EB%25B0%258D-%25EB%25AA%25A8%25EB%258D%25B8-springrunner-emnec/

www.linkedin.com

1 어떻게 하면 하루를 좀 더 효율적으로 보낼 수 있을까? 모든 직장인의 고민이다. 시간을 능률적으로 쓸 ...

리더를 위한 효율적인 시간 쪼개기 기술 3가지

1
어떻게 하면 하루를 좀 더 효율적으로 보낼 수 있을까? 모든 직장인의 고민이다. 시간을 능률적으로 쓸 수 있는 3가지 팁을 소개한다. 특히 리더라면 꼭 알아야 한다.

2
첫째, 시간을 시각화하기. 구글 캘린더를 쓴다면 할 일 기능을 추천한다. 보통 일정을 이벤트로 잡는다. 해당 시간대에 일정이 찬다. 하루 일정이 한 번에 보여서 편하다.

3
구글 캘린더에는 이벤트 말고 할 일 타입이 있다. 투두 리스트다. 할 일에 시간대를 지정한다. 그럼 할 일이 일정처럼 등록된다. 완료 여부도 체크할 수 있다. 할 일 앱이 별도로 있어 편리하다.

4
큰 차이가 없어 보이지만, 써보면 완전히 다르다. 그냥 오늘 어떤 일을 해야지 와, 언제 해야지는 다르다. 일에는 언제나 Due가 있어야 한다.

5
출근하자마자 오늘의 할 일을 채운다. 10시에는 미팅, 11시에는 내 할 일이 이미 정해져있다. 시간에 맞춰 스스로 움직여서 실행하기 훨씬 쉽다. 딱 일주일만 해보자. 습관이 된다.

6
두 번째는 하루 쪼개기다. 하루는 24시간이다. 이를 4등분 한다. 아침, 오전, 오후, 저녁. 이제 4개의 구분이 생겼다. 각각의 할 일과 목표를 생각해 본다. 그냥 보내는 하루보다 훨씬 더 시간을 효율적으로 쓰게 된다.

7
아침에는 명상, 독서, 운동을 한다. 오전에는 중요한 논의나 결정하는 미팅을 한다. 오후에는 원온원 미팅과 채용 인터뷰가 있다. 저녁에는 개인을 위한 시간을 보낸다. 이런 식이다. 이렇게 시간을 쓰다 보면, 내 시간과 에너지 레벨도 자연스럽게 관리할 수 있다.

8
그냥 보면 별 차이가 없어 보일 수 있다. 하지만 하루를 4번의 루틴으로 보내는 효과는 크다. 마음가짐과 모드도 바뀐다. 역시나 해보면 알 수 있다.

9
세 번째는 한 시간을 쪼개보기다. 1시간은 60분이다. 4등분 한다. 동그란 시계를 4개로 쪼갠 셈이다. 15분짜리 슬롯이 4개가 생긴다.

10
사람의 집중력은 늘 한계가 있다. 1시간 동안 계속 집중하기는 어렵다. 하나의 업무라도 여러 개의 단위가 있다. 15분 단위로 업무를 쪼개보자. 훨씬 능률이 오른다. 해보면 15분이 아닌 내게 맞는 단위도 알게 된다.

11
이런 시간 쪼개기는 특히 리더들에게 더 중요하다. 실무자는 뭉텅이 시간이 중요하다. 집중해서 무언가를 만들어낼 시간이 충분히 있어야 하기 때문이다. 중간에 인터럽트가 걸리면 치명적이다. 집중력을 뺏겼다가 다시 잡아오는 데는 에너지와 노력이 또 들기 때문이다.

12
리더는 반대다. 짧은 시간의 슬롯을 많이 확보해야 한다. 리더가 주로 하는 일은 결정이다. 결정에는 많은 준비와 논의가 필요하다. 하지만 결정하기 자체는 시간이 많이 필요하지 않다.

13
큰 조직의 리더일수록 더욱 많은 결정을 해야 한다. 결정들을 위한 짧은 슬롯이 많이 필요하다. 보통 리더들의 캘린더가 촘촘한 건 이 때문이다. 다양한 방법의 시간 쪼개기는 리더의 시간을 효율적으로 쓰게 만들어 준다. 해보며 나만의 방법을 만드는 게 중요하다.

1 어떻게 하면 하루를 좀 더 효율적으로 보낼 수 있을까? 모든 직장인의 고민이다. 시간을 능률적으로 쓸 수 있는 3가지 팁을 소개한다. 특히 리더라면 꼭 알아야 한다. ​ ​2 첫째, 시간을 시각화하기. 구글 캘린더를 쓴다면 할 일 기능을 추천한다. 보통 일정을 이벤트로 잡는다. 해당 시간대에 일정이 찬다. 하루 일정이 한 번에 보여서 편하다. ​ ​3 구글 캘린더에는 이벤트 말고 할 일 타입이 있다. 투두 리스트다. 할 일에 시간대를 지정한다. 그럼 할 일이 일정처럼 등록된다. 완료 여부도 체크할 수 있다. 할 일 앱이 별도로 있어 편리하다. ​ ​4 큰 차이가 없어 보이지만, 써보면 완전히 다르다. 그냥 오늘 어떤 일을 해야지 와, 언제 해야지는 다르다. 일에는 언제나 Due가 있어야 한다. ​ ​5 출근하자마자 오늘의 할 일을 채운다. 10시에는 미팅, 11시에는 내 할 일이 이미 정해져있다. 시간에 맞춰 스스로 움직여서 실행하기 훨씬 쉽다. 딱 일주일만 해보자. 습관이 된다. ​ ​6 두 번째는 하루 쪼개기다. 하루는 24시간이다. 이를 4등분 한다. 아침, 오전, 오후, 저녁. 이제 4개의 구분이 생겼다. 각각의 할 일과 목표를 생각해 본다. 그냥 보내는 하루보다 훨씬 더 시간을 효율적으로 쓰게 된다. ​ ​7 아침에는 명상, 독서, 운동을 한다. 오전에는 중요한 논의나 결정하는 미팅을 한다. 오후에는 원온원 미팅과 채용 인터뷰가 있다. 저녁에는 개인을 위한 시간을 보낸다. 이런 식이다. 이렇게 시간을 쓰다 보면, 내 시간과 에너지 레벨도 자연스럽게 관리할 수 있다. ​ ​8 그냥 보면 별 차이가 없어 보일 수 있다. 하지만 하루를 4번의 루틴으로 보내는 효과는 크다. 마음가짐과 모드도 바뀐다. 역시나 해보면 알 수 있다. ​ ​9 세 번째는 한 시간을 쪼개보기다. 1시간은 60분이다. 4등분 한다. 동그란 시계를 4개로 쪼갠 셈이다. 15분짜리 슬롯이 4개가 생긴다. ​ ​10 사람의 집중력은 늘 한계가 있다. 1시간 동안 계속 집중하기는 어렵다. 하나의 업무라도 여러 개의 단위가 있다. 15분 단위로 업무를 쪼개보자. 훨씬 능률이 오른다. 해보면 15분이 아닌 내게 맞는 단위도 알게 된다. ​ ​11 이런 시간 쪼개기는 특히 리더들에게 더 중요하다. 실무자는 뭉텅이 시간이 중요하다. 집중해서 무언가를 만들어낼 시간이 충분히 있어야 하기 때문이다. 중간에 인터럽트가 걸리면 치명적이다. 집중력을 뺏겼다가 다시 잡아오는 데는 에너지와 노력이 또 들기 때문이다. ​ ​12 리더는 반대다. 짧은 시간의 슬롯을 많이 확보해야 한다. 리더가 주로 하는 일은 결정이다. 결정에는 많은 준비와 논의가 필요하다. 하지만 결정하기 자체는 시간이 많이 필요하지 않다. ​ ​13 큰 조직의 리더일수록 더욱 많은 결정을 해야 한다. 결정들을 위한 짧은 슬롯이 많이 필요하다. 보통 리더들의 캘린더가 촘촘한 건 이 때문이다. 다양한 방법의 시간 쪼개기는 리더의 시간을 효율적으로 쓰게 만들어 준다. 해보며 나만의 방법을 만드는 게 중요하다.

blog.naver.com

< 리더를 위한 효율적인 시간 쪼개기 기술 3가지 >

사용자가 공유한 콘텐츠

Sự đa dạng không chỉ xuất hiện trong các trò chơi mà còn trong các phần thưởng và ưu đãi mà New88 mang lại. Với các chương trình khuyến mãi đa dạng và hấp dẫn, bạn luôn có cơ hội nhận được các phần thưởng giá trị và trải nghiệm cá cược với chi phí thấp nhất. Địa chỉ: 18 Ng. Quan Thổ 1, Hàng Bột, Đống Đa, Hà Nội, Việt Nam Website: https://new88.ceo/ Email liên hệ: contact@new88.ceo #new88 #nha_cai_new88 #trang_chu_new88 #link_new88
Social:
https://myapple.pl/users/449500-new88ceo
https://app.scholasticahq.com/scholars/290174-new88-ceo
https://www.walleyecentral.com/forums/member.php?u=339923
https://ffm.bio/new88ceo
https://profiles.delphiforums.com/n/pfx/profile.aspx?webtag=dfpprofile000&userId=1891221945
http://www.pvp.iq.pl/user-18804.html
https://participa.terrassa.cat/profiles/New88ceo/timeline
https://bowl.hu/index.php/user/23125
https://careerly.co.kr/profiles/707193

Sự đa dạng không chỉ xuất hiện trong các trò chơi mà còn trong các phần thưởng và ưu đãi mà New88 mang lại. Với các chương trình khuyến mãi đa dạng và hấp dẫn, bạn luôn có cơ hội nhận được các phần thưởng giá trị và trải nghiệm cá cược với chi phí thấp nhất. Địa chỉ: 18 Ng. Quan Thổ 1, Hàng Bột, Đống Đa, Hà Nội, Việt Nam Website: https://new88.ceo/ Email liên hệ: contact@new88.ceo #new88 #nha_cai_new88 #trang_chu_new88 #link_new88 Social:https://myapple.pl/users/449500-new88ceohttps://app.scholasticahq.com/scholars/290174-new88-ceohttps://www.walleyecentral.com/forums/member.php?u=339923https://ffm.bio/new88ceohttps://profiles.delphiforums.com/n/pfx/profile.aspx?webtag=dfpprofile000&amp;userId=1891221945http://www.pvp.iq.pl/user-18804.htmlhttps://participa.terrassa.cat/profiles/New88ceo/timelinehttps://bowl.hu/index.php/user/23125https://careerly.co.kr/profiles/707193

New88Ceo

javascript

SpringBoot

Spring

https://new88.ceo/

Sự đa dạng không chỉ xuất hiện trong các trò chơi mà còn trong các phần thưởng và ưu đãi mà New88 mang lại. Với các chương trình khuyến mãi đa dạng và

New88Ceo

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필