글쓴이: songji13

‘WHY’ over ‘WHAT’, and ‘HOW’

~ songji13 ~ 댓글 남기기

최근에 팀원 피드백을 주면서 1년 전 쯤 정리했던 이 포스팅이 생각나서 생각을 다시금 정리해본다.

이슈: To do list를 먼저 정하고, why를 생각하는 경우의 문제점

무슨 일을 할 지 정할 때, 일의 순서가 중요하지 않다고 하는 경우도 있는데, 나는 일의 순서가 결국 디테일을 결정하고, 큰 방향을 가르게 된다고 본다.

그렇기에 what을 정하고 그 다음에 why를 생각해보는 것이 아니라, why를 먼저 생각하고 what을 정하는게 (거의 대부분) 더 전략적으로 나은 선택을 만든다. what을 생각하고 why를 정하다보면 (사람의 머리구조상) what을 설명하기 위한 why가 나올 수 밖에 없다. 이걸 똑같은 what을 도출하기 위한 두괄식적인 접근이라고 보면 곤란하다.

이 일을 왜 하는지, 해야하는지 고민하다보면 가장 본질적이고, 때로는 창의적인 what이 나오는 경우를 자주 목격했기 때문이고, 그게 전략적인 접근이기 때문이다.

그래서 ‘무엇을 만들 것이냐’를 고민할 때, 제일 중요한 것은 ‘무엇을 만들겠다’라는 목표가 아니라, ‘왜 그것을 만들어야 하는지’, 또는 ‘그게 왜 문제인지’에 대한 유저접근부터 시작해야 한다고 생각한다.

‘왜 이것을 만들어야 하는 것인가’를 완벽하게 설득할 수 있는 것이 가장 중요한 PO의 자질이라는 말과도 일맥상통한다는 생각도 든다.

최근 위의 피드백이 다시 필요한 팀원이 있어서, 이번에는 어떤 식으로 전달하면 좋을까 고민하다 다시금 1년 전에 썼던 내용을 더 쉽고 이해가 갈 수 있는 버전으로 정리 중이다.

[예시]

저 포스팅을 작성하며 들었던 가장 대표적인 예는 우리 서비스의 기능 중 하나인 ‘주소입력 없이 자동인증’이었다. 당시 우리가 파악했던 문제는 ‘집주인 인증 시 주소 입력에서 이탈이 크다’라는 것이었다. 만약 이 당시에 우리가 빨리 To do list를 고민했다면 당장할 수 있는 선택지(그리고 쉽게 To do list를 뽑으라면 생각해낼 수 있는 선택지)는 ‘주소검색 엔진을 고도화한다’라거나, ‘더 다양한 주소 DB를 확보한다’ 등 상당히 작업량은 많으면서도 고민되는 부분이 많았다.

그러나 우리는 문제인 ‘주소 입력을 어려워한다’ 라는 부분에 집중했고, ‘도대체 왜 주소입력을 어려워할까?’라는 근본적인 질문(WHY)을 던졌다. 약간의 필드리서치의 경험을 통해 해당 질문에 대한 답을 찾아냈고, 주소 입력에서 이탈이 많았던 유저들의 진짜 이유(root cause)는 ‘주소를 잊어버려 기억하기 어려워한다’였다.

다시말해, 흔히 생각할 수 있는 ‘주소검색 엔진을 고도화한다’라거나, ‘더 다양한 주소 DB를 확보한다’의 HOW로는 해결할 수 없는 문제였다.

거기서부터 생각난 해결 방법은 ‘아예 주소 입력을 하지 않고 인증을 할 방법은 없을까?’ 였고, 결국 우리는 아예 주소입력을 하기 이전에 인증을 시켜버리는 방법을 가져오게 된다. 물론 말할 것도 없이 전환율은 급격하게 개선되었다. 그냥 주소엔진을 고도화하는 방법으로는 비교도 할 수 없이, 그리고 유저에게는 더 쉽고 편한 방법을 제공하며 문제를 해결하게 된 것이다.

만약 우리가 전환율을 빨리 올리기 위해 당장 검색엔진을 개선하였다면 어떻게 되었을까? 오히려 ‘아, 이 문제는 해결할 수 없어’라며 빨리 해당 문제를 포기하게 되지 않았을까 싶다. 당장 To do list를 세우고 일로 뛰어들어가고 싶은 마음은 이해할 수 있지만, 정말 문제를 그렇게 간절하고 풀고 싶기에 To do list를 세우고 전파하기 전에 무엇보다도 ‘왜’라는 질문을 하고 파고들어야 진짜 문제를 해결할 수 있다.

그렇다면, Why에 집중하기 위한 커뮤니케이션 방법은 무엇일까

Why는 쉽게 찾아지지 않는다. 특히 어려운 문제일수록 더 그렇다. 그렇기에 반년 전에 의사소통을 효과적으로 하기 위한 4단계 커뮤니케이션 방법에 대해서 팀원에게 공유했고, 이 방법은 무엇보다도 Why로 가기 전에 How와 What으로 생각이 흘러가지 않게 하기 위한 사고의 툴로 권유할만하다고 생각된다.

잠시, 현상을 공유하고 거기서 5번만 WHY라는 질문을 Top grading 방식으로 질문하다보면 보이는 것들이 있다. 그리고 무엇보다도 타인에게 간결하게 설명하지 못한다면 문제를 이해하지 못한 것이다. 설명하지 못하는데 ‘그냥 원래 그렇다’거나 ‘그래야만 해’라는 것들은 우리가 믿고 있는 종교와 법령 이외에는 없다.

[레퍼런스]

  • Simon Sinek ‘Golden Circle’도 비슷한 (하지만 완벽하게 같지는 않다) 사고 구조를 따른다
  • 5 Why – 5번 정도 Why를 물어보다보면, 문제의 본질을 깨달아 근본원인을 파악하여 해결할 수 있게 된다

The ‘why’ will guide the ‘what’ and the ‘how’

The design guru Tim Brown, CEO of IDEO, writes in Change by Design “Don’t ask what? ask why?” and continues: “asking ‘why?’ is an opportunity to reframe a problem, redefine the constraints, and open the field to a more innovative answer. […] There is nothing more frustrating than coming up with the right answer to the wrong question”

최근 가장 인상적인 영상

~ songji13 ~ 댓글 남기기

아마존 설립 이후 약 9.5년이 지난 후 제프베조스의 영상

  • 모든 이야기의 귀결은 고객에게 주는 혜택, 고객이 5-10년이 지나도 변하지 않을 원하는 것을 경쟁사보다 더 잘 파악하고, 더 잘 해결하고, 더 변하지 않게 만족시켜 주는 것

==========================

지난 주에 제프베조스가 아마존을 세운지 9.5년 정도가 지난 후 강연을 한 영상을 봤는데요, 너무 좋은 부분이 많아 공유해봅니다. (영상 내 번역 잘 되어 있어요)

아마존의 혁신을 다음과 같은 이야기를 했는데요

1.Helplessness – people adapt and feel it is useless (익숙한 것을 극복하기)


사람들은 익숙한 것을 더 편리하다고 하고 거기서 벗어나기 어렵다고 합니다. 쉽게 말해, 처음에 새로운 혁신적인 것도 도입할 때에는 익숙함을 극복하기 위해 더 큰 노력과 저항이 있습니다. 하지만 결국에 혁신은 새롭고 편리한 방식을 채택하고 바뀌길 기다리는, 소위 말해 ‘존버’하는 사람들이 가져가게 되구요.

If you encounter a problem for a long enough duration, human are so remarkably adaptive – we don’t even notice them, so great inventors and people they’re very good at ordinary things bother them. It’s very difficult to do to kind of push through this learned helplessness you get used to something.

2. Reject either/or thinking (둘 다 선택하기 – 둘 중의 하나만 선택해야 한다는 사고는 혁신을 제한한다)

상당히 신선한 사고방식이었는데요. 저는 문제를 해결할 때 항상 근본원인을 잘 찾아야 한다 라고 해석했습니다. 너무나 예가 신선해서 그대로 가져오면

고객의 문의가 늘어남 -> 고객의 문의의 질과 양을 모두 향상해야 함 -> 그렇다면 고객이 문의를 하는 이유는 무엇인가? (다음의 원인들)
1. 고객이 감사를 표하기 위해 (안타깝게도 매우 소수)
2. 고객의 서비스에 대한 불만
3. 고객의 서비스에 대한 궁금함

따라서 고객 문의가 발생하는 근본원인을 해결한다면 – 예를 들어 고객이 문의하기 전에 알 수 있다면, 고객이 물어보기도 전에 궁금한 것을 알 수 있다면, 고객이 불만을 가지는 부분을 개선할 수 있다면 – 고객에게는 더 좋은 사용자 경험을 제공하면서도, 비용을 절감할 수 있다라고 문제를 새롭게 정의한 부분입니다.

그냥 ‘고객 문의의 양과 질’이라는 것에만 집착한다면 이런 근본 원인을 찾지 못하지 않았을까 싶습니다.

3.Maximize experimentation


2번과 연결되어 있는 내용인데, 문제를 정의한 후 해당 문제에 관한 솔루션을 찾는 것은 기본적으로 ‘가정’을 내포하고 있습니다. 그렇기에 최종적으로 내 가설이 맞는지 아닌지를 데이터를 통해 봐야 한다고 하는 것이구요.

다만, 아직 이 부분은 얼마집에는 강조하고 싶지 않습니다 (앞으로 서비스가 성숙되며 점점 더 강조될 거 같긴 합니다만) 우리는 가설과 추측이 필요한 영역이 아니라 본질적으로 digital transformation의 부족한 부분을 메꿔가며 하고 있는 상황이어서요. 쉽게 말해 커머스에서 물건을 고르고, 장바구니에 담고, 결제하는 과정 중에서 일부가 아직 안되거나 여전히 불편하게 오프라인에 있는 상황이니 기본 고객의 목적한 행동에 맞는 부분을 갖추면서 이런 부분을 강화하면 좋을 것 같습니다.

4.Obsess about the customer

이 부분도 정말 여러 아티클에서 자주 들었던 내용인데, 다시 들으니.. 또 좋더라고요. 경쟁사를 베끼는 것은 빠르게 변하는 산업에서는 승리할 수 없는 전략입니다. 물론 경쟁사가 뭘하는지, 어떻게 하는지는 지켜봐야겠지요. 하지만 중요한 것은 경쟁사가 어떻게 하는지가 아니라 고객이 무엇을 원하는지, 고객이 5-10년이 지나도 무엇을 원하는지입니다. 우리는 그런 변하지 않는 고객니즈를 더 빠르고, 정교하게 맞춰주면 자연스레 경쟁에서 이기게 되는 것이구요.

다시 말해, 10년이 지나도 변하지 않을 것은, 고객이 아마존에게 원하는 것은 ‘더 많은 선택지’, ‘낮은 가격’, ‘편리함’이고, 저는 처음부터 아마존이 그 핵심 가치를 잘 발견하고, 잘 정의하고, 잘 지켜왔다고 생각이 됩니다.

그런 점에서 우리가 우리의 핵심 가치를 정의할 시기가 되었다고 생각이 듭니다. 잘 고민해서 워케이션에서 같이 이야기 나눠보시죠. 주말 보람차게 보내고 월요일에 봐요!

가을

~ songji13 ~ 댓글 남기기

거의 올해 내내 조금씩 나의 한계를 넓혀가는 느낌이지만 진짜 쉽지 않은 가을이다. 그냥 일들에 내가 먹혀가는 느낌이랄까, 뭔가 설명할 수 없는데 한마디로 요약하면 내가 할 수 있는 이상이 나에게 다가오는데 어떻게든 이걸 해내야 한다.

조금만 더 힘내보자, 아니 오늘 하루 매일 하루하루씩 힘내보자

현명함과 raw intelligence

~ songji13 ~ 댓글 남기기

예전부터 어떤 사람이 되고 싶냐는 이야기를 들으면 ‘현명하고 지혜로운 사람이요’라고 대답했는데, 여전히 나는 ‘현명하고 지혜로운 것’이 무엇인지 정의내리지는 못하겠다. 다만, 어떤 경우에는 ‘답을 알면서도 이야기하지 않는 것’이 현명함을 의미하는 것이라는 것을 알아가게 되는 것 같다.

물론 이 현명함은 raw intelligence가 기본이 되어야 한다. 요새 계속 고민하는 – 하지만 분명하게 실재하는 – raw intelligence. 누군가는 이 raw intelligence를 알기 위해 brain teaser를 물어보고, IQ 테스트를 해보고, 혹은 그것의 signaling을 한다는 학교를 보기도 한다. 나는 어떻게 찾아야 할까?

Strategy over planning

~ songji13 ~ 댓글 남기기

여름 휴가를 맞아 밀린 책, 동영상을 한번에 보면서 생각도 정리하고 있는 중인데, 첫번째로 문화에 대한 글을 썼지만 생각이 잘 정리되지 않아 더 빠르게 정리된 글부터 퍼블리시 해봅니다. 회사의 6개월 전략에 대한 내용을 전체 팀 슬랙에 공유하려 쓴 글의 도입부가 될 듯하여, 간단한 글로 마무리해봅니다.

———————————————

스타트업에게는 계획(planning), 특히나 장기계획은 필요없다고 생각하는데 (시장도, 고객도 계속 발견하며 절벽에서 뛰어내리며 비행기를 조립해야 하는 과정이니까) 일부 팀원들의 경우 long term planning이 없는 것이 회사가 문제가 있는 것이 아니냐는 견해를 갖고 있는 듯도 하여 strategy와 planning의 차이를 아래에 정리해보았다.

계획과 전략의 차이

계획(planning)은 우리가 뭔가를 할 것이라는 것을 정하는 것을 말한다 – 예를 들어, 몇 명을 채용할 것이고 이런 제품을 만들 예정 등 – 다시 말해, 계획은 철저히 cost side story이며 분명하게 예상되는 결과가 있지만 그것이 회사가 달성하는 목표를 나타내지는 않는다.

반면에 전략(strategy)은 일종의 특정 가설을 의미한다. 회사가 처한 시장의 위치, 유저의 반응에 따라 특정 가설을 세우고 그에 따라 논리적이고 실행가능한 결과물을 만드는 것을 목표로 한다.

strategy has theory, and must be coherent and doable – competitive outcome. If our theory is right about what we can do, and how the market will react, this will position us in an excellent way

따라서 전략이 수립되지 않은 상태에서의 planning은 정말 위험하다. 왜냐하면 어떻게 유저를 가치를 줄 수 있다는 가설과 시장에 대한 계획도 없으면서 돈/리소스를 쓸 계획만 쓰는 것이니, 정말 위험할 수 있다.

더 정확하게 이야기한다면, 전략이 확실하지 않은 상태에서는, 혹은 전략이 충분히 tweak 되지 않은 상태라면 (스타트업의 경우) 비용을 최소화하면 맞는 전략을 찾아가나는 것이 제일 필요하며, 전략이 변경될 때마다 단기간의 계획을 빠르게 수정해나가는 것이 최선이라고 할 수 있다.

또한 전략이라는 것도 어디까지나 이론적인 가정이기에 유저, 시장의 상황에서 나오는 교훈이 있을 때마다 빠르게 수정하고 방법을 찾아가는 것이 중요하다. 그렇기에 회사가 가야할 목표/비전을 설정해놓되, 그 과정을 찾아나가는 전략과 계획은 장기적이기보다는 빠르고 민첩하게 변경해야 한다.

Outro

구체적으로 전략이라는 것은 무엇인지에 대해 생각하기 쉬운 동영상을 아래에 첨부하며 계획과 전략에 대한 차이에 대한 생각을 끝맺음한다.

Complexity isn’t a vice

~ songji13 ~ 댓글 한 개

오늘 팀에서 조금 불편한 커뮤니케이션이 있었기에 복기를 위해 적어본다. 팀원 중 한명이 다음과 같은 커뮤니케이션을 통해 이야기를 하는 부분이 지속적으로 내 마음에 무엇인가 불편하게 느껴졌고, 이런 비슷한 패턴의 커뮤니케이션에 내가 불편함을 느끼는 과거 사례가 있었기에 한번 어떤 부분에서 내가 불편함을 느꼈는지 복기해보려 한다.

1)오늘 *** 이슈가 있었어요 (= 사실)

2)*** 와 비슷한 패턴의 이슈가 발생하고 이것은 문제라고 생각해요 (= 의견)

3)이 원인은 *** 인 것 같아요 (= 판단)

4)그래서 당장 ***을 바꿔야/개선해야 해요 (= 판단)

이야기하다가 나온 불편한 지점을 곰곰히 복기해보니 내가 보통 이런 이야기의 흐름에서 잘 정제되지 않은(깊이 생각하지 않은 결론을) 생각을 좋아하지 않는 것 같다. 1)과 2)까지는 충분히 issue raising 측면에서 이야기할 수 있는 부분이 있지만 3)과 4)로 갈수록 레벨에 따라 ‘보이는 그림’이 다르고 판단하는 사람의 경험의 양과 폭이 다르기에 때로는 대답하기 쉬워보이지만 쉽게 이야기할 수 없는 경우가 많다. Don’t jump into the conclusion, because you might be wrong too fast.

이는 살면서 주니어 시절에는 3)이라고 판단했지만, 일하면서 경험의 폭을 넓혀가며 시니어 레벨이 되면 인과관계를 고려하는데 더 많은 것들을 고려하는 복잡성이 더해진다. 그렇다고해서 결정을 미룬다는 의미는 아니다. 3)의 결론으로 가기 전에 ‘우리는 이 판단을 내리기 위해 ***와 ***를 확인해봐야 할 것 같아요’라는 이야기를 할 수 있다. (혹은 2)를 좀 더 분석해야 할 때도 있다) 그리고 때로 3)은 중요한 결정을 내포하는 경우가 많기에 (one way door decision) 그 원인을 잘 생각해보는 것이 더 좋다.

(개인적으로 이렇게 하는 친구들을 deep thinker라고 생각하고 내가 선호하는 타입의 사람인 거 같다. 어쩔 수 없이 나도 사람이니 선호하는 타입의 사람이 있다)

관련해서 내가 제일 좋아하는 West wing에서 이런 구절이 있다. (complexity isn’t a vice라는 대사가 나온다. 정말 멋진 대사가 아닌가)

Every once in a while… every once in a while, there’s a day with an absolute right and an absolute wrong, but those days almost always include body counts. Other than that, there aren’t very many unnuanced moments.

Outro

복잡한 내용일수록 문제에 집중해야 하고, 커뮤니케이션은 간결할 수 있지만 그 안에 담긴 생각은 간결할 수 없다. 누군가를 선동하기 위해서는 간결한 캐치프레이즈가 필요하지만, 우리에게 필요한 것은 복잡한 문제를 해결하는 과정이다.

내가 더 나은 사람이 되면 된다

~ songji13 ~ 댓글 남기기

최근 체력저하와 함께 감정적인 버퍼가 낮아지다보니 유독 팀에서 잘 안맞는 팀원이 있어 커뮤니케이션을 힘들어하다가, 다른 한 팀원분에게 건네준 이야기를 스스로 기록하고 싶어 적어본다.

어떤 식으로든 살면서 힘든 사람은 만나게 되어 있고 피할 수는 없고, 더 나은 대표가 되기 위해서는 거쳐야 하는 일들이다. 그리고 그 중에서 그 문제를 해결할 수 있는 유일한 방법은 “내가 더 나은 사람이 된다”는 것이고 지금은 그러한 과정 중이다.

누군가를 비난하는 에너지가 나를 잠식하기 전에, 내가 더 나은 사람이 되는 것에 집중해보자.

세상에 쉬운 일은 없다

~ songji13 ~ 댓글 남기기

항상 엄마가 ‘이 세상에 쉬운 일은 없다’고 이야기해주시곤 했는데 그 말이 계속 실감나는 요즈음이다.

회사는 몇 달 간 계속 트래픽이 평균 20% 이상 상승하고, 계약 건도 증가하고, 좋은 협업 건도 많이 생기고 있다. 팀원들은 성장하고 있고, TIPS도 한번에 선정되어 수고로움을 덜었으며, 우리가 고대하던 분야에서의 규제 샌드박스 기회가 열렸다.

그럼에도 불구하고, 여전히 내가 신경쓰지 않으면 제대로 마무리되지 않는 일의 갯수는 줄어들지 않고 있으며 주니어 팀원들은 아직 주니어 레벨이다. 일부 팀원은 걱정이 되는 이슈를 갖고 있으며 내가 무엇을 할 수 있을지 모르겠다. 팀을 위해 시니어 팀원이 필요하다고 느끼는 시점이며, 체력이 고갈되고 있다. 체력이 고갈되는만큼, 여유의 버퍼가 낮아져 마음의 평정이 쉽지 않음을 느끼고 있다. 좋은 오퍼를 낼 만한 시니어 팀원은 보이지 않고, 이제 어디서 귀인을 만날지 사방으로 기도해야만 한다.

그럼에도 불구하고, 흔쾌히 펀드레이징을 도와주겠다는 좋은 투자자와 함께 개발팀을 전반적으로 같이 봐주겠다는 좋은 멘토님도 계신다. 또 어떻게든 지나가고 이겨내겠지 싶은 7월의 중순이다.

글 잘 쓰는 방법

~ songji13 ~ 댓글 남기기

유학가서 처음으로 영미권 교육을 받았을 때 가장 충격적이었던 것은 글쓰기에 정말 많은 시간과 노력을 들인다는 것이었다. 500 words memo 글쓰기를 훈련하면서, 문단을, 문장을, 단어를 이렇게 선택하고 훈련해야하는구나 싶어서 그간 이런 훈련을 받지 못했던 시절이 아쉽기도 하고 스스로를 깨닫는 시간도 되어 좋기도 했었다. 시간이 지날수록 말과 글의 힘이 회사를 이끌어나가는데 정말 중요한 역량임을 깨달으며 주말간 생각을 정리하다가 이 영상을 발견해서 그간 생각했던 부분을 위의 영상과 함께 정리해 본다.

글을 잘 쓰는 원칙 – 간결하고, 쉽게 쓰기

  • 짧은 문장
  • 문단의 첫 문장은 짧게 – 생략할 수 있는 단어는 생략하고 간결하게 표현하기
  • 간단하게 쓸 것 – 부정의 부정형 x – 꼬아서 쓰지 말기

clean, straightforward, as simple as possible

글을 잘 쓰는 기본 – 독자의 입장을 고려

어떤 경우에도 간결하게 쓰라는 메시지는 사실 독자의 입장을 고려하는 말의 다른 버전이다. 한정된 머리의 CPU를 생각하면 최대한 적은 단어로, 정확하게 뜻을 전달하는 것이 중요하다. 그렇기에 가능하다면 쉽게 쓰는 것이 좋지만 글자의 제한이 있다면 어려운 단어 – 하나의 단어 안에 많은 컨텍스트를 담는 – 를 쓸 수 밖에 없다.

다만 쉽게 쓰더라도, 독자가 정말 쉽게 이해할 수 있어야 한다. 그리고 그러기 위해서는 단어의 선택과 조합이 매우 중요하다. 문장과 문장의 연결, 문단 내 문장의 배치 모두 중요하다. 퇴고는 이 부분을 살펴보는 것을 위주로 진행한다.

글을 잘 쓰는 방법 – 연습과 퇴고

실제적으로 연습, 그리고 또 연습이 필요하다. 우선 생각하는대로 적지만, 생각은 늘 논리적으로 연결되지 않기도 하고 비약이 생기기도 한다. 글로 적고 다시 살펴보다보면 반드시 부족한 부분이 보인다.

사실 퇴고하지 않아도 될 만큼의 좋은 글을 처음부터 쓸 수 있는 능력을 갖출 수만 있다면 정말로 큰 무기가 될 수 있다. 많은 경우 마스터피스를 전달하는 것이 아닌 뜻이 정확하게 전달할 수 있는 커뮤니케이션 차원에서는 ‘시간’이라는 한정된 자원안에서 좋은 글로 팀 내에 커뮤니케이션 해야하기 때문이다.

Outro

사실 생각이 정리되지 않으면 좋은 글이 나올 수 없다. 그렇기에 어쩌면 좋은 글을 쓰기 위한 가장 필요한 준비는 생각을 잘 정리하는 것이고, 그러기 위해서는 – 위의 영상에서도 생각이 정리되지 않으면 글을 쓰는 시작조차 하지 말라는 조언도 있었다 – 생각을 빠르게 잘 정리할 수 있는 훈련이 필요하다.

2024. 5.30

~ songji13 ~ 댓글 남기기

아래에는 팀 내 슬랙에 공지했던 내용인데, 상반기 회고를 하며 다시금 생각해보고자 블로그에 아카이빙 한다. 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개월 동안 정말 많이 나아졌지만, 저는 충분히 더 개선될 수 있는 여지가 있다고 생각하고 이 부분을 계속 설파하려고 합니다.