안녕하세요 인프랩의 향로입니다.
최근 인프랩 팀은 적극적으로 개발자 채용을 하고 있습니다.

지원하시는 분들 입장에서는 인프랩 개발팀은 어떤 것을 추구할까, 나와 가치관이 비슷할까 등등의 고민이 있을 수 있습니다.

그래서 저희 개발팀이 추구하는 미션과 가치를 소개합니다.
저희팀의 미션과 가치에 공감이 되신 분들이라면 언제든 인프랩 팀에 지원해주세요.

이후부터는 평어체를 사용합니다.

아래 내용은 조직이 더 커질때마다 더 추가될 수 있습니다.

1. 개발팀의 미션

프로덕트 엔지니어로서 내/외부 고객의 신뢰를 얻기 위해 적절한 시기에 적합한 도구로 고객의 문제를 해결한다

  • 외부의 고객: 서비스를 사용하는 사용자
  • 내부의 고객: 개발팀을 필요로 하는 사내 모든 구성원들

적합한 도구를 선택하기 보다 먼저 방점이 찍혀있는 것은 적절한 시기이다.
어떤 문제는 당장 해결이 필요로 하고,
어떤 문제는 당장 해결할 필요가 없다.

내/외부 고객의 문제를 만난다면 그걸 언제까지 해결하는 것이 좋은지 판단 후, 그 시기를 위한 가장 적절한 도구를 선택할 수 있는 조직이 되는 것이 중요하다.

그리고 이를 통해 내/외부 고객들의 신뢰를 얻어야 한다.

배우는 관객이 필요하고
프로덕트 엔지니어는 고객이 필요하다.

고객의 문제를 해결하는 것에 방점이 찍힌 조직이 되어야 한다.

2. 개발팀이 추구하는 가치

위에서 언급한 미션을 달성하기 위해 크게 4가지 가치를 추구한다.

  • 존중

    • 단순히 예의 바른 행동을 의미하진 않으며, 팀 원들을 한명의 전문가로서, 동료로서 진심으로 존중하는 것을 의미한다.
    • 다른 사람에게 더 관심을 갖고, 더 잘 호응하고, 더 친절해야 한다.
    • 할당된 목표만 달성하면 뭐든 마음대로 해도 괜찮다” 혹은 ”기술만 뛰어나면 어떤 무례한 말을 해도 괜찮다” 가 조직의 암묵적인 실제 문화 가 되어선 안된다.
  • 탁월성

    • 모든 개발팀원은 평범한 수준에 안주하지 않고, 높은 기준의 성과를 내기 위해 노력한다.
    • 단순히 새로운 기술을 많이 아는 것을 의미하진 않는다.
    • 같은 문제를 만난다면 이전 보다 더 나은 방법을 선택할 수 있어야 한다.
    • 어떠한 일을 맡는다면 최선의 결과를 내도록 노력한다.
  • 신뢰

    • 내/외부의 고객들이 개발팀을 신뢰할 수 있도록 한다.
    • 여기선 개발팀 간에도 서로간의 신뢰가 있는 관계를 유지하는 것을 의미한다.
    • 동료들간 대화에는 말한 그대로를 투명하게 믿을 수 있는 건강한 관계를 유지해야 한다.
    • 이 신뢰가 없다면 항상 그 사람의 의도를 파악하기 위해 일에 집중하지 못한다.
  • 실행

    • 너무 많은 고민을 하지 않는다.
    • 항상 바로 실행에 옮기며, 실행하면서 전략을 수정한다.
    • 완벽하지 않은 전략일지라도 이를 잘 실행하는 조직은 쉽게 지지 않는다.

3. 일하는 방법

하나의 미션을 달성하기 위해 4가지의 가치가 있으며,
이 4가지의 가치는 아래의 방법들을 수행하면서 지킬 수 있다.

상대를 먼저 인정한다.

여기 있는 모두는 기존 구성원들의 기술면접과 CTO & CEO의 문화면접을 통과하여 합류한 사람들이다.
따라서 다른 구성원들이 본인 보다 부족한 사람임을 전제하고 대화를 하지 않는다.
왜 다른 구성원이 그러한 주장을, 의견을 하는지 다시 한번 생각해보자.

감정을 뱉어내는 것과 명확한 소통은 다른 문제이다.

“이것 모르세요?” 등의 문장은 적절하지 않다.
내가 무엇을 모른다고 솔직하게 이야기하기 위해서는 내 부족한 점을 드러내도 저 사람에게 부정적인 표현을 듣지 않는다는 심리적 안정감이 있어야만 가능하다.

우리는 더 큰일을 더 잘하기 위해서 모인 전문가 집단이다.
상대가 모르는 것이 무엇인지, 아는 것은 무엇인지 빠르게 확인해서 문제를 해결해야만 한다.
상대를 주눅들게 하여 커뮤니케이션의 장벽을 쌓는 것은 더 빠르게 문제를 해결하는 방식이 아니다.

고압적인, 강압적인 태도로 상대를 존중하지 않는 커뮤니케이션을 한다면 점점 그 동료와의 대화는 회피하게 된다.

“내 차 주변에서 운전 조심하세요“ 보다 “아이가 타고 있어요” 가 훨씬 더 안전운전에 효과적인 문장인 것을 누구나 안다.

사용하는 문장과 단어도 마찬가지이다.
누군가에게 메세지를 전달할 때, 진짜 전달과 설득이 목적이라면, 가장 효과적으로 전달할 수 있는 방법을 고민해야한다.

상대에 대한 배려가 부족하거나, 내가 갖고 있는 단어의 부족을 무례한 화법으로 표현하지 말라.

무례한 것은 취향이 아니다.

모든 팀원들간에는 상호 존중해야한다.

신뢰 자본을 쌓는다.

회사라는 조직의 특성상 여러 사람들의 협업을 이끌어내야하는 경우가 대다수이다.

이때 필요한 것은 토론에서의 승리가 아니다.

말도 안되는 방향이라도 나를 믿고 따라갈 수 있을정도로 동료와의 신뢰관계를 쌓는 것이 중요하다.

전략, 전술보다 실행이 중요하다. (4번째 가치)

이를 위해서는 결론적으로 별로인 전략이라도 먼저 실행에 옮기면서 함께 수정해나가는 것이 중요하다.

나를 신뢰하고 계속해서 실행을 옮길 수 있도록 동료들과의 신뢰 관계를 구축한다.

계몽보다는 전염시킨다.

좋은 문화를 만들고 싶다면 내가 먼저 좋은 사람이 되어서 팀원들이 나를 닮고 싶도록 한다.
좋은 조직 문화는 서로가 서로에게 닮고 싶은 것이 있을때 발전할 수 있다.

여기는 모두 다 성인이 모여있는 조직이다.
어린이들을 훈계하듯이 한다고 변화시킬 수 있는 것이 아니다.

타자를 변화시키는 것은 계몽이 아니라 전염이다. - 은유 작가님 <올드 걸의 시집> 중

아침 출근 길 누군가의 밝은 아침 인사는 오늘 하루를 기분 좋게 한다.
그리고 나도 누군가에게 밝게 아침 인사를 하고 싶게 만든다.
“아침엔 꼭 밝은 인사를 해주세요” 라고 훈계하는 것보다 훨씬 더 효과적이다.

옳고 그름의 잣대로 누군가의 삶과 태도를 옳게 계몽하는 게 아니라, 그냥 선한 기운을 본인으로부터 옆으로 옆으로 전염시키는 것이 더 효과적이다.

전염은 주변 사람들을 사람들을 물들인다. 주변을 전염시키는 것을 항상 고려한다.

모든 보고는 사실에 기반한다.

본인이 원하는 것을 얻기 위해 추측성 정보를 전달하거나 작은 일을 크게, 혹은 큰 일을 작게 하는 등의 정보의 비대칭을 이용하지 않는다.

사실관계만이 올바른 의사결정을 내리는데 도움이 된다.

보고 받는 사람 (C레벨이든 동료든 관계없이) 이 선입견이 없도록 우선 사실에 기반한 내용을 정리하고 이를 공유한다.

그리고 이후에 자신의 의견과 견해는 사실관계와 구분해서 덧붙인다. 자신의 의견과 견해를 사실과 섞어서 전달하지 않는다.

본 것은 그대로 보고하라.
들은 것은 들은 대로 보고하라.
본 것과 들은 것을 구별해서 보고하라.
보지 않은 것과 듣지 않은 것은 일언반구(一言半句) 도 보고하지 말라

  • 이순신

기분이 태도가 되지 않도록 한다.

대부분 회사에서 일하는 직장인들이 힘들어 하는 부분은 일이 아닌, 사람이다.
출근할때마다 팀장님, 부장님의 기분에 따라 눈치를 보는가 하면, 경력이 제법 쌓인 나의 기분에 따라 사람들이 눈치를 보는 것을 느끼기도 한다.

본인의 마음 상태는 상대방도 똑같이 느낄 수 있다.
내 기분에 따라 행동이 달라지면, 주변 동료들은 매번 내 눈치를 본다.
그리고 일에 집중할 수 없게 된다.

참을 수 없는 기분에 따라 우발적인, 동료들이 예상하지 못한 행동을 취하지 않는다.
동료에게 영향을 주는 행동은 항상 한번 더 고민하고 실행에 옮긴다.
동료들이 “저 사람 갑자기 왜저래” 등의 생각이 들게 하지 않는다.

본인의 감정과 회사에서의 일은 별개다.
회사에선 일을 해야 한다.
본인의 감정과 일을 분리하고 기분이 태도가 되지 않도록 한다.

역할에 집착 하지 않는다.

일과 일 사이에는 빈 공간이 존재한다.
전문가 집단으로 발전하면서 특히 이 빈 공간들은 계속해서 생긴다.
이 애매한 영역을 누가 할 것 인가에 대해 끊임없이 논의가 발생한다.

이게 문제가 맞다면,
내가 먼저 문제를 제기할 수 있고, 내가 먼저 문제를 해결할 수도 있어야 한다.
그런 적극적인 자세가 결국 성과 내는 조직을 만든다.

사무실의 쓰레기를 치우는 것은 여사님의 역할이고,
개발자의 역할이 아니라고 생각하여
눈 앞의 쓰레기를 치우지 않는다면 그 조직은 망한다.

눈 앞에 쓰레기가 있다면 치울 수 있어야하고
책상 밖으로 나온 의자가 있다면 넣을수 있어야 한다.
문제가 있다면 그게 누구의 역할인지 구분하기 전에 문제를 제기하고 해결하는 것을 우선하는 조직이 되어야 한다.

적정한 해결 방법을 선택한다.

어떤 의사도 병이 무엇인지 확신을 얻기전에 무턱대고 처방을 내리진 않는다.
마찬가지로, 고객의 문제를 만나자마자 바로 해결책부터 내놓으려고 하지 않는다.
문제가 정확히 무엇인지 확인하는 것 부터 진행한다.

고객의 문제를 만났다면, 먼저 다음의 질문에 답해본다.

  • 그 문제는 문제인가?
  • (문제가 맞다면) 그 문제는 해결해야 할 문제인가?
  • (해결해야할 문제가 맞다면) 그 문제는 언제까지 해결해야할 문제인가?
  • (해결해야할 일정이 정해졌다면) 그 문제는 꼭 프로그래밍으로 풀 수 밖에 없는 문제인가?
  • (프로그래밍으로 풀어야 하는 문제라면) 그 문제를 풀기 위한 가장 적정한 기술은 무엇인가?

어떤 경우엔 내가 쓰고 싶은 도구를 위해 지금 당장 해결해야할 문제가 아니거나 문제가 아닌 것도 문제로 정의해서 푸는 경우도 있다.

개발조직이 풀어야할 문제는 굉장히 많다.
모든 문제를 프로그래밍으로 풀려고 하지말아야 하며, 일정을 지킬 수 있는 범위 내에서 가장 적절한 해결 방법을 선택한다.

기술적 전문성을 추구한다.

적정 기술을 선택하기 위해서는 아이러니하게도 엔지니어가 스스로 구현할 수 있는 기술의 범위내에서만 나온다.

그러므로 엔지니어가 가장 적정한 기술을 선택하기 위해서는 많은 분야의 기술을 습득하고, 구현하고, 깊이있게 탐구가 필요하다.

내가 알고 있는 기술의 범위가 좁으면 적정 기술이란 단어 뒤에 숨어서 매번 같은 방법만 선택할 뿐이다.

항상 전문성을 쌓기 위해 노력하며, 적정 기술의 선택 범위를 넓힌다.

가지고 있는 한정된 자원과 시간 안에서 사용할 수 있는 가장 부채가 적은 기술과 방법을 찾아내고 선택할 수 있는 사람을 우리는 전문가라고 한다.

더 높은 생산성을 추구한다.

똑같은 문제를 매번 같은 방식으로 해결한다면 매번 같은 시간이 필요로 한다.

같은 문제를 다음엔 더 효율적으로 해결할 수 있는 방법들을 고민하고 적용하고, 숙련도를 쌓는다.

대표적인 예로 테스트 코드 작성이 있다.
테스트 코드에 대한 숙련도가 낮을때는 테스트 코드를 작성하는 것이 개발 속도를 더 늦추는 원인이 된다.
이로 인해 테스트 코드를 작성하지 않는 것이 더 높은 생산성을 추구하는 것처럼 착각할 수도 있다.
반면, 테스트 코드에 대한 숙련도가 충분하면 테스트 코드를 작성하는 것이 훨씬 더 높은 생산성을 낸다.

로컬 서버를 실행하고
Postman으로 입력값을 모두 채우고 API를 호출해보고
API 결과를 눈으로 검증해본뒤
문제가 있으면 다시 코드를 수정하고
위 내용을 반복하는 방식과
테스트 코드로 1초만에 빠르게 피드백 받고 수정/개선할 수 있는 방식에서는 수십배 ~ 수백배의 생산성 차이를 낸다.

숙련도의 문제를 도구의 탓으로 돌리지 않아야 한다.

이외에도
IDE 등 개발 도구의 숙련도
주로 사용하는 프레임워크, 라이브러리의 숙련도
수동적으로 하고 있던 일들의 자동화
불 필요하게 긴 회의 시간
등등 개선할 수 있는 곳은 많다.

항상 지금 보다 더 많은 시간을 확보하기 위한 노력을 한다.

개발 조직에는 생산성에 관심있는 팀원들이 많다. 이들과 함께 본인의 생산성을 항상 점검한다. 지금의 일을 더 생산성있게 해결할 방법이 있는지 검토하고 적용해본다.

마무리

저희의 가치와 미션은 계속해서 개선/추가해나갈 계획입니다.
이런 저희 개발팀의 가치와 미션에 공감하시는 분들이라면 인프랩 개발팀에서 함께 일하길 바래봅니다.