아래에는 팀 내 슬랙에 공지했던 내용인데, 상반기 회고를 하며 다시금 생각해보고자 블로그에 아카이빙 한다. 2번에서 조금 더 그간 추가된 생각을 첨언한다면, ‘코딩만 잘하는 것이 좋은 개발자가 아니라 코딩은 “당연히” 잘하고, 더 나아가 근본적인 문제를 잘 풀 수 있어야 좋은 개발자이다’

---

오늘 김태호 대표님과 이야기를 나누면서 제 스스로 이런저런 생각이 많이 들고, 최근 고민되던 부분에 대해서 정리가 되어 여기에 공유합니다.

1.우리의 모든 행동은 고객(사용자)의 문제를 해결해주기 위해 존재한다 – 링크한 자료는 당근 첫 회의에서 공유한 발표자료라 합니다

이 이야기는 사용자라 해달라는대로 모든 것을 다 들어준다는 의미가 아니라, 진정으로 우리의 모든 행동이 고객의 문제를 풀어주는데 쓰이고 있느냐 하는 것입니다. 고객의 문제를 우리가 제공하는 서비스로, 그리고 그 서비스라는 형태는 디자인과 개발이라는 도구로 이루어져 있습니다. 쉽게 말해 우리가 만들고 싶어하는 것을 만들고 있는 것은 아닌지 고객이 정말로 이것을 해결하고 싶어했는지 중심으로 우리의 사고와 행동을 집중할 필요가 있습니다. 그렇기에 서버엔지니어는 도메인 전문가가 되어야 하며, 프론트엔지니어는 유저경험 전문가, 프로덕트 디자이너는 유저가 생각하지 않아도 (유저를 헷갈리게 하지 않는) 디자인을 고민해야 하는 것입니다.

2. 성장이란 무엇인가?
사실 회사의 성장이란 상당부분 정량화될 수 있고 가시성이 있습니다. 계약 수, 유저트래픽, 매출.. 하지만 개인의 성장이란 때로 정의하기 어렵고 사람마다 받아들이는 바가 다릅니다. 커리어 초기에는 다양한 스킬셋에 집중하는 경향이 있지만, 결국 우리가 그 스킬셋을 익히고 배우는 것은 어떤 문제(고객의 문제)를 풀기 위함입니다. 다시 말해 위의 고객의 문제를 풀어주는데 그 스킬셋이 (소잡는데 쓰이는 칼, 닭잡는데 쓰이는 칼..) 도움 될 수 있으나 칼에 익숙해지거나, 칼을 좀 더 잘 휘두르거나, 새로운 신상칼을 잘 사용할 줄 아는 것이 성장은 아닙니다. 개인의 성장도 이런 맥락에서 생각될 수 있고, 현재 우리 회사의 상태는 여기저기 산재한 문제를 해결하는 것 자체가 사실 개인의 성장과 직결될 수 있는 좋은 환경입니다.

그렇기에 이러한 고민을 많이, 다양하게 한 외국의 IT 회사들에서는 각 레벨 별 소프트웨어 엔지니어에게 요구되는(기대되는) 부분을 문서화합니다. 쉽게 말해, 성과평과를 받을 때 이 기준으로 받는다 생각하면 되는데,

• 레벨1: I deliver lots of high quality production-ready code with direction from the team
• 레벨2: I am prolific at delivering resilient and sustainable software projects from design to implementation and rollout
• 레벨3: I independently identify and deliver software solutions through a set of milestones spanning a specific product focus or a multi-component system
• 레벨4: I autonomously deliver ongoing business impact across a team, product capability, or technical system
• 레벨5: I set the multi-year, multi-team technical strategy and deliver it through direct implementation or broad technical leadership

(레벨 3정도까지를 보통 주니어로 봅니다.) 소프트웨어 엔지니어 framework지만 레벨2부터는 code라는 용어가 들어가지 않습니다. 레벨 4부터는 business impact라는 용어가 들어갑니다.

제가 이번 워케이션에서 인스파이어드라는 책을 같이 읽고 싶었던 것도 이 부분입니다. “기능을 구현하는 것이 아닌 문제를 해결한다”

3. 위험은 마지막보다는 초기에 대응한다 + uncertainty 보다는 risk가 낫다
오늘 김태호 대표님과 이야기를 나눴던 부분 중에서 인상적이었던 부분은 ‘uncertainty와 risk의 차이를 아는 팀이 좋은 팀이다’라는 이야기를 해주셨는데 제가 고민하고 있었던 부분을 잘 설명해주신 부분이라 정리해서 공유하고 싶었습니다.

uncertainty와 risk는 동일하게 부정적인 뉘앙스를 담은 이슈…이지만, 우리가 알고 있는 영역에 존재하는 것이냐 아니면 모르는 영역에 존재하는 것이냐에 따라서 다릅니다. 다시 말해,

• uncertainty: we don’t know that we don’t know
• risk: we know that we don’t know

그리고 ‘상대적으로’ uncertainty가 많은 방식으로 일하는 것은 매우 좋지 않습니다. 왜냐하면 risk는 우리가 문제가 있을 수도 있을 영역을 사전이 인지하고 있기에 risk 자체는 manageable하고 조절할 수 있습니다. 우리가 컨트롤하고 준비할 수 있는 부분에 있지만, uncertainty에 있는 영역이 터지면 쉽게 말해 그 downside가 얼마나 될 지 가늠조차 되지 않는 영역입니다. 특히 우리가 컨트롤 할 수 있는 부분 – product building방법에서 uncertainty를 늘려가는 것은 제일 하지 말아야 할 방법입니다. 이미 시장환경이나 유저반응 등.. 회사가, 서비스가 갖고 있는 컨트롤 가능하지 않는 uncertainty는 무수히 많으니까요.

4. 커뮤니케이션과 업무 가시성이 중요하다
1-3의 모든 부분을 위해서는 팀 내 커뮤니케이션과 업무에 대한 가시성이 정말 중요합니다. 왜냐하면, 우리가 정말로 1-3에 팀 전체가 잘 sync되어서 하나의 가치로 나아가고 있는지 매번 확인할 방법은 팀 내 커뮤니케이션과 업무 가시성 밖에 없으니까요. (혹은 다른 방법이 있을 수도 있겠지만.. 지금 제가 생각나는 것은 그것..) 그런 부분에 저희가 지난 6개월 동안 정말 많이 나아졌지만, 저는 충분히 더 개선될 수 있는 여지가 있다고 생각하고 이 부분을 계속 설파하려고 합니다.