NEW 기획 디자인 개발 프로덕트 아웃소싱 프리랜싱

기획

내가 테크 리더로 일하면서 얻은 8가지 교훈

본문은 요즘IT와 번역가 Jay Eum과 함께 만든 해외 번역 콘텐츠입니다. 글의 필자인 Tyler Hawkins는 수석 소프트웨어 엔지니어로 개인 웹 사이트를 통해 개발에 관한 다양한 글을 올리고 있습니다.

 

이번 글은 회사에서 우리가 테크 리더를 맡았을 때 두려움 없이 원활하게 직책을 수행하기 위해서는 무엇을 해야 하는지를 설명하고 있습니다. 이 글을 통해 리더로서 무엇을 해야 하는지 알 수 있기를 기대합니다.

 
테크 리더 경험
출처: Unsplash

 

저는 지난 수년간 다양한 회사에서 테크 리더(Tech Lead)로 일했습니다. 수행했던 직책별로 다소 다르긴 했지만, 업무를 진행하는 과정에서 공통점이 있었습니다. 이번 글에서는 테크니컬 리더가 무엇이며, 어떤 일을 하는지 등을 살펴보고, 이 과정에서 습득한 몇 가지 교훈을 공유하고자 합니다.

 

테크 리더란?

가장 먼저 알아야 할 점은 테크 리더는 관리자가 아니라는 것입니다. 테크 리더는 여전히 개별적으로 기여하는 직책이며, 팀을 도와주는 동시에 상당한 업무성과를 낼 것으로 기대를 받습니다. 일반적으로 테크 리더는 팀에서 관리자의 입장이지만, 항상 그런 것은 아닙니다. 직속 부하직원이 없기 때문에 팀원들과 1:1 관계가 이루어지거나 성과에 대한 검토를 하지 않습니다. 하지만, 팀원들에게 멘토링을 제공하여 도움을 줍니다.

 

 

테크 리더의 책임

테크 리더는 다양한 직책을 수행합니다. 아키텍트, 프로젝트 관리자, 소프트웨어 엔지니어, 멘토 및 팀원 역할을 동시에 수행합니다. 또한 팀이 수행하는 업무에 관하여 높은 수준의 아키텍처적인 토론을 주도하는 것을 도와줄 책임이 있습니다. 디자인 회의와 기술 분야를 세부적으로 살펴보는 과정을 주도합니다. 극단적인 상황을 극복할 수 있는지 질문을 던지고, 아이디어의 미비점을 찾기 위해 노력합니다.

 

이와 함께 제품의 진행 상황을 이야기와 임무로 나누어 업무 준비를 돕습니다. 이러한 작업은 개별적으로 수행하거나 다른 팀원들과 함께 수행할 수 있으며, 이는 기업마다 상이합니다. 업무 우선순위를 정하고, 적절한 업무가 적시에 완료될 수 있도록 관리합니다.

 

테크 리더는 장애요소를 제거할 수 있도록 해야 합니다. 여기에는 프로덕트 책임자, UX 디자이너 (User eXperience designer)[1] 또는 다른 팀의 엔지니어를 위한 질문에 대한 답변을 처리하는 업무도 포함될 수 있습니다. 또한, 개발 의뢰서에 대한 여러 승인 기준을 명확히 하기 위해 팀원과 협력하기도 합니다. 여기에는 매일 코드를 검토하고, 풀 리퀘스트(pull request)[2]가 관심을 받지 못한 상태로 너무 오래 유지되지 않도록 확인하는 것이 포함됩니다.

 

또한, 팀원들에게 멘토링을 제공하고, 팀의 수준을 올리는 것을 도와줄 책임이 있습니다. 최적의 적용 사례를 구현하고, 준수하도록 합니다. 페어 프로그래밍(pair programming)[3]과 코드 검토를 통해 교육도 시킵니다. 때로는 관련 기사나 조언, 아이디어를 공유하기도 합니다.

 

요약하자면, 테크 리더가 된다는 것은 직접적인 권한은 없지만 영향력을 행사하는 것입니다.

 

이제 테크 리더가 무엇이고, 무엇을 하는지를 충분히 이해했으니 제가 리더로 일한 경험을 통해 습득한 몇 가지 교훈을 살펴보겠습니다.

 

 

1) 팀의 요구사항을 우선적으로 처리하기

테크 리더는 자신의 성공에 더 이상 관심을 갖지 않게 됩니다. 대신 팀 전체의 성공에 투자하는 것입니다. 이는 팀의 요구사항이 개인적인 요구사항보다 중요하다는 것을 의미합니다.

 

저는 통상적으로 모든 풀 리퀘스트를 검토하고, 슬랙으로 받은 질문에 답하며, 새로운 오류를 분류하는 데 하루에 1시간에서 3시간 정도를 보냅니다. 한 마디로, 팀원들이 기다리고 있는 어떤 것이라도 해결하기 위해 할 수 있는 모든 것들을 합니다.

 

이 모든 일을 마치고 나서야 그날 저에게 주어진 일을 시작합니다. 나머지 시간에도 슬랙을 확인하거나 코드를 검토하지만, 제 업무 흐름을 방해하지 않고 자연스럽게 잠시 멈출 수 있을 때에만 합니다.

 

2) 시간 관리를 잘하기

제가 직접 해야 하는 업무와 팀 업무 사이에서 시간 균형을 맞추는 것은 매우 어려운 일입니다. 어떤 날에는 장시간 코딩을 해야 하는 ‘개발자 일정’에 참여해야 합니다. 또 다른 날에는 업무에 집중할 수 있는 시간이 없고, 많은 회의에 참가해서 방해를 받게 되는 ‘관리자 일정’을 소화해야 하기도 합니다. 이런 두 가지가 섞이는 날이 대부분입니다.

 

코드를 검토하거나 팀원들의 질문에 답해주다 보면 코드를 직접 작성할 수 있는 시간이 거의 없습니다. 자신의 고유 업무에 집중할 수 있도록 방해받지 않는 시간을 위해 일정표에 범위를 정해서 시간을 비워 놓는 방법을 배워야 합니다.

 

팀이 더욱 스스로 업무를 할 수 있도록 하고, 각자의 의문사항에 답을 찾을 수 있게 도와주어야 합니다. 위임해 줄 수 있는 업무를 찾아야 하는 것입니다.

 

3) 일을 위임하기

모든 것을 혼자 하려고 하는 것은 잘못된 생각입니다. 팀을 구성하는 이유는 업무를 분담하고, 각자가 혼자서 해낼 수 있는 것보다 함께 더 많은 것을 달성하기 위해서입니다.

 

업무의 부담을 혼자 짊어지려고 하면 곧 지치고 말 것입니다. 어떤 일에 대해서 자기 자신이 그 일을 해야 할 때와 이를 위임해 줄 때를 안다는 것은 까다로운 일입니다.

 

4) 프로세스를 개선하기

팀을 위해 끊임없이 화재를 진압하러 다니는 자신을 발견한다면 잠시 시간을 내어 그 문제의 근본적인 원인을 생각해 보십시오.

 

예를 들면, 팀원들이 같은 질문을 반복적으로 한다면 이런 기회를 자신의 프로세스로 문서화할 수 있는 기회로 활용해야 합니다. 이를 통해 다음에 동일한 질문을 받게 되면 사람들에게 본인이 정리한 문서를 공유할 수 있어야 합니다.

 

팀의 풀 리퀘스트를 모두 검토해야 하나요? 왜 그런 것일까요? 모든 팀원들이 코드를 검토할 책임이 있다는 사실을 정해야 합니다. 무엇을 찾아야 할지 가르쳐 주고, 자신의 사고 과정을 자세히 설명해 주세요. 코드 리뷰에 대한 최적의 적용 사례와 지침도 문서화해 주십시오. 코드 리뷰 몇 개를 다른 팀원에게 넘겨주기만 해도 일주일에 몇 시간 정도를 확보할 수 있습니다.

 

여러분은 뭔가 잘못되었을 때 이런 곤란한 문제를 해결하 는데 항상 참여합니까? 이런 과정을 팀원에게 가르치기 위한 시간을 활용할 필요가 있습니다. 문제를 진단하고, 해결할 때 팀원이 항상 따라다니거나 짝을 지어 함께 하도록 해봅시다. 그러면 비슷한 일이 일어났을 때 도움을 줄 준비가 된 또 다른 인원이 팀에 있게 됩니다.

 

5) 개발자 경험 최적화하기

개발 프로세스를 더 쉽게 하고, 팀의 생산성을 높이는 데 도움을 줄 수 있도록 최적화할 수 있는 것들을 찾아야 합니다.

 

  • 누락된 문서가 있습니까? 해당 문서를 작성합시다.
  • 어떠한 저장소에 대해 로컬에서 앱을 실행하는 절차를 알고 있습니까? README에 이런 절차를 문서화합시다.
  • 자주 중단되는 영역에 테스트가 누락되었습니까? 해당 테스트를 작성해야 합니다.
  • CI 파이프라인이 느립니까? 파이프라인에서 병렬로 실행할 수 있는 단계나 줄일 수 있을 다른 작업이 있는 확인해 봅시다.
  • 팀의 수준을 올리기 위한 교육 기회가 있습니까? 팀원의 숙련도에서 부족한 부분을 찾고, 이러한 부분을 채우는 데 도움을 주기 위한 계획을 수립하기 위해 팀원과 협력하는 게 중요합니다.

 

6) 어려운 피드백을 잘하기

리더로서 가장 어려운 부분 중 하나는 부정적인 피드백을 제공하는 것입니다. 어려운 대화를 나누는 방법을 익혀야 합니다. Kim Scott은 자신의 책 에서 개인적으로 관심을 갖고, 직접 도전해야 한다고 말했습니다. 팀원들이 성장할 수 있도록 좋은 질문을 계속해야 합니다.

 

누군가가 자신의 역할을 충분히 해내지 못한다면, 이에 대한 근본적인 원인을 찾고, 해결 방안을 모색할 수 있도록 함께 노력해야 합니다. 이러한 문제가 동기 부여나 숙련도의 문제일까요? 숙련도에 관한 문제라면 해당 팀원에게 더욱 적합한 직무나 프로젝트가 있는 것일까요?

 

이때 테크 리더와 관리자 사이의 경계가 다소 모호해지기 때문에 이러한 상황에서 해당 담당자와 긴밀하게 협력하는 것이 중요합니다. 테크 리더로서 성과에 관한 논의를 하거나 해고 결정을 할 책임은 없지만, 자신의 의견은 상당한 영향을 미칩니다. 팀원들이 성공할 수 있도록 최선을 다해야 합니다. 하지만, 때로는 팀원들이 계속 업무를 할 수 있을 정도로 돕는 것이 가장 친절한 일이기도 합니다.

 

7) 올바른 판단 내리기

앞으로 나아갈 길이 불확실할 때 팀원들은 테크 리더가 조언을 해주거나 방향 제시를 기대할 것입니다. 소프트웨어 엔지니어링은 기술적 결정을 내릴 때 절충할 수 있는 각종 요소로 가득합니다.

 

예를 들어, 이 기능에 대한 테스트를 작성해야 할까요? 일반적으로 이 질문에 대한 답은 거의 언제나 ‘그렇다’입니다. 하지만, 저장된 코드가 지난 5년간 수정하지 않은 지금까지 내려오던 코드이고, 오래된 기술 스택을 사용하고 있으며, 기존의 테스트 세트가 없는 경우에는 어떻게 해야 할까요? 특정 테스트의 작성에 추가하여 이런 코드에 대한 테스트 기반 구조를 갖추는 데 시간을 보내야 할까요? 아니면, 이런 상황에서 테스트 작성을 생략해야 할까요?

 

아니면, 다음과 같은 시나리오를 고려할 수 있습니다. 새로운 기능의 출시가 임박했지만 출시 마감 직전에 오류를 식별했습니다. 오류를 수정하기 위해 코드 배포를 연기해야 할까요? 아니면, 생산단계로 진행하기 위해 오류를 허용해야 할까요? 이 문제의 답은 오류의 심각성, 코드 배포의 빈도, 오류를 얼마나 신속하게 수정할 수 있을지 등 여러 요소에 달려 있을 것입니다.

 

여기서 핵심은 100% 정확한 해결 방안이 없는 상황에서 어려운 결정을 내리게 되는 경우가 많다는 것입니다. 올바른 판단력을 사용하고, 제한된 정보로 결정을 내리며, 자신의 결정을 지지하는 법을 배우십시오.

 

일이 잘못되면 자신의 실수를 인정하고, 이를 통해 배워나갈 수 있는 방법을 찾아야 합니다.

 

8) 언제나 공부하기

마지막으로, 자만하지 말아야 합니다. 팀의 수준을 지속적으로 높이려면 계속 배워야 합니다. 테크 리더가 지속적으로 성장하는 모범을 보이면 팀원들에게도 배움의 문화를 만들어 갈 수 있습니다. 자신이 읽고 있는 흥미로운 기사나 책이나 진행하고 있는 부가 프로젝트를 공유하십시오. 이를 통해 팀과 공유할 수 있는 풍부한 아이디어를 제공해 줄 것입니다.

 

 

결론

테크 리더는 쉽지 않지만, 성장할 수 있는 기회로 가득 찬 직책입니다. 요약하면, 본인이 아래와 같이 행동한다면 더욱 원활하게 직책을 수행할 수 있을 것입니다.

 

1) 개인의 요구사항보다 팀의 요구사항을 우선적으로 고려해야 합니다.

2) 시간을 현명하게 관리해야 합니다.

3) 위임하는 법을 배워야 합니다.

4) 프로세스 문서화를 개선할 방법을 찾아야 합니다.

5) 개발자 경험을 최적화하는 방법을 찾아야 합니다.

6) 부정적인 피드백을 제공하고, 어려운 대화를 나누는 방법을 배워야 합니다.

7) 좋은 판단을 내리기 위해 자신을 믿어야 합니다.

8) 항상 배움의 자세를 잊지 말아야 합니다.


[1] 소비자가 제품이나 서비스 등을 선택하거나 사용할 때 발생하는 제품과의 상호작용을 제품 디자인의 주요소로 고려하는 것을 설계하는 직책
[2] 프로그램의 분산 버전 관리를 위해 개발자가 변경한 사항을 유지보수 관리자에게 반영 요청하는 작업
[3] 2명이 함께 프로그램을 개발하여 한 사람은 코드를 작성하고, 나머지 한 사람은 코드를 검토하여 프로그래밍을 수행하는 방법

 

<원문 링크>

8 Lessons I Learned as a Tech Lead

 

위 번역글의 저작권은 Tyler Hawkins에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.

댓글 0

요즘IT의 번역글들

이 프로필을 만든 저만 해도 영어가 서툴러 영어로 된 기사는 읽는 게 더딥니다. 그래서 준비했습니다. 읽어볼만한 해외 소식들을 번역해 전합니다. We are the world.

디자인, 산출물 그 이상을 넘어

디자인

이 회사는 디자인에 투자하고 있는 회사일까요?

디자인

애자일은 정말 디자인을 배제하나요?

디자인

평판 관리가 프리랜서 경력에 미치는 영향

프리랜싱

리액트 네이티브 개발자들이 겪는 가장 빈번한 5가지 문제와 해결책

개발

“솔직히 우리가 하는 것은 스크럼이 아닙니다!”

기획

데이터 시각화가 인류를 위기에서 구한 세 가지 역사적 사건

디자인

NFT의 장밋빛 미래는 사실일까?

기획

피그마 토큰으로 디자인 시스템 만들기

디자인

디자이너+개발자 = 슈퍼팀 만들기

기획

1인 개발자로서 테크 스타트업을 운영하며

기획

웹 디자이너가 PX대신 REM을 사용해야 하는 이유

디자인

100개의 스타트업을 멘토링하며 깨달은 성공의 비밀

기획

중화권 앱 UI가 영미권 앱 UI와 다른 점 알아보기

프로덕트

모두가 즐길 수 있는 디자인 검토 회의 만들기

디자인

프로덕트 매니저에서 프로덕트 마스터로

기획

10배 이상 뛰어난 개발자가 되는 법

개발

제품 디자인 관점에서 바라보는 NFT 아바타 열풍

디자인

에어비앤비: 대규모 iOS 앱 개발 생산성을 위해 바꾼 것들

개발

스포티파이: 맞춤형 플레이리스트 개발 비하인드 스토리

개발

프리랜서가 일하게 될 15가지 유형의 프로젝트

프리랜싱

슬랙: 제품 원칙을 통해 다시 태어난 알림 기능

프로덕트

페이팔: 실시간 그래프 데이터베이스 분석을 통해 사기를 방지하는 방법

개발

트위터: 수십억 개의 이벤트를 실시간 처리하기

개발

슬랙: 4가지 애자일 가치와 방법

기획

스퀘어: 모바일 우선을 넘어 웹에서 누리는 모바일앱 경험

디자인

스포티파이: 카피를 언어로 만드는 UX 라이팅

기획

마이크로소프트: 디자인의 미래를 위한 4가지 원칙

디자인

메타: AR/VR 경험까지 고려한 디자인 청사진

프로덕트

슬랙: 훌륭한 마케팅 카피를 위한 5가지 원칙

기획

2022년 UX/UI 디자인 트렌드

디자인

구글: 가변 폰트의 놀라운 활용법

디자인

에어비앤비: 위기 상황에서의 디자인 원칙 5가지

디자인

어떻게 두 명의 인턴이 수백만 개의 코드들을 보호할 수 있었나

개발

Lattice로 마이크로 프론트엔드를 구축하는 법

개발

Cool Cats NFT를 구축하면서 배운 것

개발

웹 컴포넌트가 프론트엔드 프레임워크를 대신할까?

개발

당신이 NFT에 대해 알아야 할 모든 것

개발

우리에겐 이상하지만 개발자들에겐 일상인 일들

개발

Next.js 12에서 주목해야 할 5가지 변화

개발

스벨트 vs 리액트, 누가 더 뛰어날까?

개발

개발자를 위한 iOS 15의 새로운 기능

개발

내가 오픈소스를 싫어하는 이유

개발

프로덕트 매니지먼트 고객 여정 5단계

기획

클럽하우스의 인기는 모두 거품이었다?

프로덕트

데이터 기반 의사결정의 장점

기획

시각 디자인의 폐쇄성 법칙이란?

디자인

사용자 경험(UX) vs 서비스 디자인

기획

프로덕트 매니저는 하루 종일 무슨 일을 할까?

기획

제품 주도 성장은 어떻게 이루어지는가?

기획

UX를 망치지 않는 설득력 있는 배너 디자인

디자인

팝업(Pop-up)으로 불리는 것들에 대하여

디자인

드롭다운(Drop-down)으로 불리는 것들에 대하여

디자인

당신의 생각을 표현하는 새로운 이모지

디자인

가장 똑똑한 소프트웨어 엔지니어에게 배운 10가지 교훈

개발

성공적인 UX 프로젝트를 위한 가장 중요한 질문

디자인

2021년, UI 디자이너가 모바일 앱에서 흔히 저지르는 실수

디자인

IT 매니저가 되는 방법과 성공하기 위한 요소

기획

슬랙(Slack) 같은 앱을 만들려면 비용이 얼마나 들까?

개발

아웃소싱이 이토록 인기를 얻게 된 이유는?

아웃소싱

마케터가 UX 관련 역량을 키워야 하는 이유

기획

미니멀리즘 디자인의 핵심적인 요소들

디자인

새로운 소프트웨어 개발사가 필요하다는 7가지 신호

아웃소싱

2021년을 이끌어가는 프론트엔드 개발 트렌드 5가지

개발

PM을 성장시키는 학습 프레임워크

기획

UI 카피라이팅, 어떻게 써야 하나요?

기획

트렌드 예측: 경쟁에서 앞서는 방법

기획

제품 사고(product thinking)의 힘

기획

인하우스 vs 아웃소싱, 소프트웨어 개발 어떻게 하나요?

개발

그림을 못 그리는 사람도 쉽게 와이어프레임 그리는 방법

기획

스타트업 기업들에게 아웃소싱이 중요한 이유

아웃소싱

제품과 기능, 성공적으로 종료하는 방법 (下)

기획

제품과 기능, 성공적으로 종료하는 방법 (中)

기획

제품과 기능, 성공적으로 종료하는 방법 (上)

기획

UX 디자이너에게 반드시 필요한 12가지 스킬

디자인

패스워드 없는 세상이 오고 있다

개발

디자이너를 쉽게 잃는 방법 10가지

디자인

프론트엔드 코딩 작업에 영감을 줄 8가지 아이디어

개발

구글이 아웃소싱을 하는 이유: 아웃소싱 성공사례 5가지

아웃소싱

일 잘하는 PM이 되기 위한 로드맵 도구 5가지

기획

이제는 말할 수 있다! 아웃소싱에 대한 오해 11가지

아웃소싱

디자인 트렌드, 모던 미니멀 스타일의 UI 가이드

디자인

MVP 개발을 아웃소싱으로 해도 될까요?

개발

온보딩 효과를 높이는 '좋은' 귀차니즘 3가지

기획

게임처럼 즐겨라, 게임화 기법 TOP3

기획

시니어 소프트웨어 엔지니어는 어떻게 일할까?

개발

프로덕트 매니저가 글을 잘 써야 하는 이유

기획

2030년엔 사라질 수도 있는 프로그래밍 언어 5가지

개발

고객들이 언제나 옳은 것은 아니다

기획

유저 스토리는 무엇인가?

기획

고객 성공을 위한 14계명

기획

8px 그리드의 시대가 끝나고, 4px 그리드의 시대가 열릴까?

디자인

모바일 앱은 더 이상 스타트업에게 좋은 아이디어가 아니다

기획

과연 구글의 UX 강좌는 도움이 될까요?

디자인

프로덕트 매니저 여러분, ‘소비자의 요구사항 수집’을 그만두십시오

기획

고객 여정과 경험 지도의 차이점

기획

내가 AI 업계를 떠난 이유 5가지

기획

모달윈도우(팝업)를 디자인할 때 생각할 9가지 원칙

디자인

대기업 vs 중소기업, B2B SaaS 스타트업을 위한 시장은?

기획

내가 개발 인터뷰에서 면접자에게 감동한 이유

개발

HTTP의 새로운 메서드, 서치(SEARCH)에 대하여

개발

세상의 모든 프로덕트 디자이너를 위한 5가지 심리학 원칙

디자인

2021년 테스트 자동화 트렌드 리포트 (下)

개발

2021년 테스트 자동화 트렌드 리포트 (上)

개발

아마존과 스포티파이는 어떻게 사용자를 유지하고 측정할까?

기획

UX 디자이너라면 필수적으로 알아야 할 5가지 법칙

디자인

앵귤러 vs 리액트, 2021년의 승자는?

개발

2021년, SaaS 스타트업 시작을 위한 놀라운 아이디어 10가지

기획

디지털 제품 관리에서 B2B와 B2C 사이의 차이점은?

기획

빠르게 실행할 수 있는 ‘제품 요구사항 문서(PRD)’ 만들기

기획

더 나은 제품을 위한 프로덕트 메트릭스 가이드

기획

노 코드(No Code) 트렌드로 프로그래머들은 일자리를 빼앗길까?

개발

넷플릭스의 플랫폼: 코스모스(Cosmos)에 대하여

프로덕트

비즈니스와 애자일 조직은 어떻게 친해질 수 있을까요?

기획

효과적인 제품 전략 세우기: 다수의 전략적 트랙(MuST) 활용

기획

1년 만에 이메일 마케팅 효과를 극대화했던 방법

기획

솔루션 아키텍트를 위한 팁: 아키텍처 다이어그램의 5가지 유형

개발

새로운 맥 OS ‘빅서’에 대한 UX 디자이너의 생각

디자인

디자인 트렌드, 뉴모피즘의 정석

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 3편

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 2편

디자인

2021년 모바일 UX 트렌드 10가지

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 1편

디자인

앱 설정 기능의 UX를 개선하는 효과적인 방법

디자인

다크모드 UI 디자인의 원칙

디자인

온라인 고객 경험을 개선하기 위한 5가지 방법

기획

신생 스타트업에서 일하는 프로덕트 매니저를 위한 현실적인 조언

기획

웹 개발자와 소프트웨어 개발자의 차이는 무엇인가요?

개발

랜딩 페이지 디자인을 개선하는 13가지 꿀팁

디자인

오프라인 비즈니스가 온라인에서 존재감을 가져야 하는 이유 5가지

기획

상향식 가격 책정 및 패키징 정책: 사용자 여정을 가이드로 활용하기

기획

B2B 제품의 UX, 그것은 숨겨진 영역인가요?

기획

상단 내비게이션 vs 사이드 내비게이션, 어느 것이 더 나을까?

디자인

자동완성 검색 기능 UX 설계를 위한 8가지 팁

디자인

프로덕트 매니저는 전문적인 IT 기술을 갖춰야 하나요?

기획

실리콘밸리 51개 기업들이 말하는 프로덕트 매니저의 역할 9가지

기획

아웃소싱에 대한 모든 것

아웃소싱

앱 디자인 가이드, 사람들이 즐겁게 사용할 수 있는 앱을 만드는 법

디자인

처음부터 완제품이 아니라 ‘MVP’를 만들어야 한다

기획

플러터 vs 리액트 네이티브 vs 네이티브, 성능이 더 우수한 것은?

개발

스타트업 프로덕트 매니저로 성장하는 법, 30-60-90일 플랜

기획

당신의 두뇌는 진보하고 있다: 성취감을 위한 3가지 전략

기획

디자이너들을 편하게 해주는 HTML/CSS 마법 10가지

디자인

코딩의 미래는 ‘노 코드(No Code)’이다

개발

내가 엔지니어링 매니저로 일하면서 저지른 실수들

개발

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (下)

기획

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (上)

기획

프로그레시브 웹 앱(PWA)이란 무엇이며, 왜 필요한가?

개발

PWA vs 네이티브 앱, 어떤 것을 선택해야 할까?

개발

UI 디자인에 여백을 활용하는 8가지 팁

디자인

마이크로소프트와 링크드인의 새로운 시도, 프리랜서 마켓에 도전장을 던지다

기획

토마스넷은 왜 가입자 수를 폭발적으로 늘려준 테스트 결과를 거부했을까?

기획

잘 팔리는 기업용 소프트웨어 디자인하기

디자인

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 하편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 중편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 상편

개발

업워크(Upwork)가 조사한 요즘 가장 인기 좋은 개발 기술 15가지

개발

일자리 산업이 휴먼 클라우드(human cloud)에 적응하는 방법

기획

팬데믹 이후 세계에서의 디지털 가속화는 어떤 모습일까?

기획

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.