1년 전 쯤에 좋은 개발자에 대한 글을 쓴 적이 있다. 지금도 그 기준에 대해 아직도 동의한다. 지금 생각해보면 당시의 고민이 꽤 심도있었다는 것을 방증하는 듯 보인다. 다만 좋은 개발자가 일 잘하는 개발자인가? 라는 질문에는 의문이 든다.
돌이켜보면 좋은 동료였지만 일이 잘 흘러가지 않았던 동료도 있었고, 함께 일하기 버거울 정도로 안맞는 동료지만 이상하게도 그 사람과 일을 하면 술술 풀리고 성과가 잘 나왔던 경험도 가지고 있다. 좋은 개발자가 일 잘하는 개발자가 아닐 수 있고, 좋은 동료가 항상 일을 잘한다고도 보장할 수 없다는 뜻이다.
민감한 주제지만, 지극히 주관적인 관점에서 일 잘하는 개발자에 대해 말해보고자 한다.
개발
무슨 말이 더 필요할까. 여러 덕목중에 개발 실력을 가장 먼저 내세운 이유는 너무나도 명확하다. 개발자가 개발을 못하면 일을 잘할 수 없다. 이게 밑에 나오는 소프트 스킬과 상충하는 부분이 있긴 해도 절대적으로 모두가 동감하리라 믿는다.
개발을 잘해야한다.
개발 실력은 엔지니어링 역량으로도 불린다. 프로라면 비즈니스 요구에 상응하는 결과를 만들어내야 한다. 이는 어떤 직무에서든 통용된다고 생각한다.
예를 들어 막무가내로 뭔가를 만들거나 고치라고 하면 개발자만이 할 수 있는 액션들로 해낼 수 있어야한다. 그 과정에서 더 세련된 프로세스에서 충분한 논의를 통해 개발이 착수되기도 하고, 너무 급하거나 그런 우아한 체계가 없어서 유야무야 요구를 받아 시작되기도 한다. 결론은 그러한 추상화된 비즈니스 요구들을 현실세계로 가져와 사용자에게 전달하는 역할을 하는게 개발자다.
예전에 학교다닐 때도 봤고, 요즘 회사 다니면서도 보는 사람들 중에 개발을 정말 사랑하고, 취미로 개발을 한다. 보통 이런 사람들이 실력도 괴물처럼 좋다. 순수하게 개발 실력이 좋다는 점은 개발자에게 정말 기초적이고 중요한 요소다. 일단 개발을 잘 하자. 가진 방법을 모두 써도 안될 때, 만약 그 문제를 개발로도 풀 수 없다면 개발자가 있을 이유가 없다.
업무로써의 개발
흔히 개발자 출신 대표가 이끄는 스타트업은 잘 될거라고 보는 시선이 많다. 대표가 스스로 자사 프로덕트를 관리하고 문제를 최일선에서 볼 수 있을거라는 기대 때문이 아닐까? 하지만 그렇다고 다 잘되지도 않는다. 업무로써의 개발은 프로덕트를 좋아하고 개발을 사랑하는 일과는 거리가 있기 때문이다.
보통 업무 프로세스를 러프하게 3단계로 나눠보면 다음과 같다.
- 요구사항을 분석한다.
- 착수 전 논의 및 페이퍼워크 (일정 산정, 업무 분할, 문서작업, 협업 스케쥴)
- 기능 개발
업무를 처음 하거나 협업에 익숙치 않은 개발자들은 3번만을 하길 원한다. 나도 개발만 하는 시간이 많으면 많을수록 좋아하고 1, 2번에 시간을 뺏기기 싫어했다. 하지만 1, 2번 과정은 협업에 있어 매우 중요하다. 이것이 업무로써의 개발이다. 바꿔 말하면, 일이 잘 되기 위한 개발자의 역할이라는 뜻이다.
개발자의 눈으로 본 요구사항은 다른 직군의 시선과 비슷하면서 다르다. 일정 산정이나 협업을 위한 소통을 할 때 꼭 필요한 과정이고, 이 과정에서 미스가 나면 날수록 3번이 지연된다. 프로덕트를 만드는 것은 혼자 하는게 아니기 때문이다.
개발자 경험
우리는 당연하게도 협업을 한다. 그게 효율이 좋기 때문이다. 가끔 어떤 안좋은 경험들이 쌓여서 그냥 혼자하는게 낫다고 생각하는 사람들도 있긴 하다. 하지만 도저히 혼자서는 거대한, 추상적인 문제를 풀기에는 무리가 있다. 그렇다면 개발자 조직에서의 협업이라면 어떤게 있을까? 이 개념을 개발자 경험(DX)이라고 부른다.
개발자 경험은 아주 사소하게는 코드 작성 컨벤션이나 스타일 가이드부터 넓게 보면 조직의 전반적인 개발문화와도 관련이 있다. 목적은 단순하다. 개발자들이 협업을 하면서도 빠르고 안전하게 비즈니스 목적을 달성할 수 있게 함이다.
그래서 일 잘하는 개발자는 DX를 중요하게 생각한다.혼자 일한다고 생각하지 않는다. 당장 주어진 목표가 달성되었다고 하더라도, 협업을 위해 정한 개발 원칙이나 구성원의 러닝커브 등을 고려한다. 더 나아가 사내 세션이나 위클리 미팅 등을 통해 협업을 위한 얼라인을 지속적으로 맞춰간다.
조직에서 프리랜서나 1인 개발자들을 채용하기 주저하는 이유 중 하나도 이런 협업이나 개발자 경험에 대한 검증이 힘들어서이기도 하다.
측정과 공표
이전엔 몰랐는데, 일을 아무리 잘해도 남들이 몰라주면 의미가 없다. 의미가 없다는 말이 조금 속물처럼 느껴질 수도 있지만, 일을 잘한다는 것은 나만 알아선 아무 의미가 없다. 그러니 일을 잘하고 싶다면 나는 이 챕터를 주의깊게 읽었으면 좋겠다. 나도 몰랐고 경험해서 배운 것이다. 남들이 내가 하는 일의 성과에 대해, 시작과 끝맺음에 대해 아는 것은 생각보다 순기능이 많고 스스로에게도 중요하다.
내가 만약 어떤 문제를 해결해야 한다면 루틴하게 두가지를 하고 시작한다.
- 일의 시작과 끝을 정의
- 관련 지표 측정
일의 시작은 내가 어떤 문제를 해결하는지를 명확히 하는 것이다. 문제를 재정의함으로써 얻는 점이 많다. 작성해야 할 코드가 줄어들기도 하고 미쳐 발견하지 못했던 결함을 발견하기도 한다. 가끔은 받은 일이 실제 해결하려는 문제를 효과적으로 해결하지 못한다는 사실을 발견하기도 한다.
일의 끝은 그래서 그 문제가 해결되었느냐를 말한다. 일이 잘 끝났다면, 우리는 아래와 같이 말할 수 있어야한다.
어떤 문제를 풀기로 했고, 내가 어떤 작업을 해서 어떤 결과를 냈다. 그렇게 이 문제를 효과적으로 해결했다.
측정
이렇게 말하기 위해서는 관련 지표를 측정할 줄 알아야한다. 일을 시작하기 전에 지표를 측정해두자. 이걸 측정하는것도 개발자 실력이다. 가령 프론트엔드 개발자라면 LightHouse, 웹 페이지 속도측정, web vitals와 같은 성능 측정도구를 예로 들 수 있겠다. 브라우져마다 제공되는 개발자 도구를 상세하게 활용하는 것도 좋은 예시가 된다. SEO 지표와 같이 외부 도구를 써야하는 항목의 경우 그 도구에 대한 지식도 필요하다.
성능 개선을 한다면 위와 같이 성능을 측정하고, 그 점수 차이를 기록할 수 있다.
SEO 작업을 했다면 위와 같은 SEO 측정 도구에서의 지표 상승이나 서치콘솔, 서치 어드바이저 상의 점진적 결과물에 대한 내용이 들어갈 수 있다.
공표
마지막으로 일을 하나 했으면 위에서 이야기했던 것처럼 데이터와 함께 공표를 해야한다.
내가 우리 조직의 목표를 위해 이런 문제를 해결했다.
라고 말할 수 있어야한다. 이것이 비로소 업무가 마무리된 것이고, 일을 잘 끝낸 것이며, 주변 사람들도 기여하는 사람, 해내는 사람. 일이 되게 하는 사람으로 인식한다.
소프트 스킬
일 잘하는 개발자들에게 정말 중요하지만 개발 실력에 묻혀 가끔 간과하되는게 이 소프트 스킬이다. 소프트 스킬이 뛰어는 개발자들은 남들보다 적은 시간에 문제는 배로 해결해낸다. 결국 본질은 조직이 해결하고자 하는 문제를 해결한다라는 사실을 이해해야한다.
커뮤니케이션 능력
소프트 스킬 중 빠지지 않는 항목이다. 어떤 직군이든 이건 적용된다. 나는 커뮤니케이션 능력을 측정할 때 '커뮤니케이션 비용'이라는 용어를 많이 쓰는데, 어떤 문제를 해결 할 때 얼마나 적은 커뮤니케이션 리소스로 문제를 해결하느냐를 말한다.
우리는 단순히 어떤 문제를 해결하기 위해 커뮤니케이션이라는 도구를 활용하는 것이다. 그 과정에 비개발자 직군이나 리더, 의사결정권을 가진 구성원과의 대화가 섞여 있는 것일 뿐이고, 본질적으로는 어떻게하면 당면한 문제를 효율적으로 해결할 수 있는지에 대해 이야기한다.
커뮤니케이션을 통해 문제를 해결해나가는 것은 아래 그림과 같다. 나는 이를 Problem Narrowing이라고 부르는데, 구성원들이 커뮤니케이션을 통해 정-반-합을 반복하며 문제의 본질과 그 해답에 가까워지는 것을 말한다.
처음부터 문제에 대한 해답을 찾기보다는 좁혀갈 줄 아는 것은 정말 중요하다. 이는 "나도 틀릴 수 있음"을 인지하고 상대방의 의견을 존중하는 마음으로부터 시작한다. 무턱대고 기술로 모든것을 해결하려는 사람이나 엔지니어만 알아들을 수 있는 용어들로 대화의 비용을 증가시키고 본질을 어지럽히는 사람은 일을 잘 하지 못하는 사람이라고 생각한다.
쉬운 문제를 어렵게 푸는 사람이 되면 안된다. 우리의 리소스는 물론 협업하는 구성원들의 리소스도 덩달아 깎여나가기 때문이다. 그만큼 커뮤니케이션 역량은 광범위하게 영향을 준다.
문제 해결 능력
"A라는 문제를 해결하기 위해 a라는 기능을 추가하기로 했습니다"
만약 우리에게 이렇게 업무가 하달되었다면, 우리는 이런 의심을 해봐야한다.
- 정말 a를 추가하면 A가 해결되는가?
- b로 A를 해결할 순 없나?
- 근데 A는 정말 문제인가?
5 whys라는 유명한 문제해결 방법론이 있다. 이게 정말 문제인지 딥다이브 하다보면 엉뚱한 해결책을 내놓았다는 사실을 자각할 때가 있다.
물론 이 업무를 위해 많은 이해관계자들의 수많은 인사이트가 오갔을 것이고 그들에 대한 신뢰와 존중을 바탕으로 일해야하지만, 개발자로써 어떤 문제를 해결할 수 있는 더 좋은 방법을 제시하는 것은 당연한 것이다. 그 과정에서 문제를 새롭게 정의하고 다시 풀어나가는 시발점을 제공하는 것은 조직의 리소스를 아끼고 더 큰 임팩트를 사용자에게 전달하는 것으로써 꼭 필요한 덕목이다.
흔히 입개발자라고 부르는 부류가 있는데, 그냥 말로만 안된다 안된다 하면서 실제로 하는건 없는 공수레를 말한다. 하지만 반대로 코드 한 줄 작성하지 않고도 문제를 해결하는 사람은 정말 능력이 좋은 것이다. 입개발자와 이 고수를 만드는 차이는 개발실력보다 "문제를 푸는 능력"에 달렸다. 진짜 문제가 뭔지 꿰뚤어보는 능력이 중요하다.
마치며
나도 일을 잘 못한다. 내 성과를 잘 챙기지 못했고, 실제 그런 피드백도 들었다. 나도 소위 말하는 "이 사람이랑 일하면 일이 잘 되더라" 라는 말을 듣는 구성원이 되고 싶었다. 그래서 주변에 일 잘하는 개발자에게 질문하고 피드백을 받으며 배운 내용을 업무에 적용해봤다. 이 글은 그 내용을 정리한 글이자 복기이며 의지를 다지는 글이다. 일 잘하는 개발자를 넘어 좋은 개발자가 되는 날까지, 고민은 이어지지 않을까.