함께 자라기 프로젝트 회고 - 1. 개발자의 빠른 성장을 위한 방정식 세우기

본 시리즈의 글은 개발자뿐만 아니라 IT 교육 업계에 종사하시는 분들도 흥미롭게 읽을 수 있을 것 같습니다. 개인적인 생각들도 꽤 담겨있어서, 더 논의해보고 싶거나 아니라고 생각되는 부분들이 있다면 댓글로 남겨주거나 편한 방식으로 연락을 주시면 감사하겠습니다.

더 나은 성장에 대한 고민을 할 때 좋은 영향을 주었던 최진석 교수님의 '탁월한 사유의 시선'도 읽어보는 것을 추천합니다.

 

0. 시리즈를 시작하기에 앞서

주니어 개발자를 위한 '함께 자라기' 프로젝트 모집 공고

글쓴이는 현재 스타트업에서 데이터 플랫폼 엔지니어로 재직하고 있는 동시에, 개발자의 성장을 촉진하는 교육을 만드는 것에 관심이 많다. 그래서 비개발 직군, 비전공자 개발자, 주니어 개발자를 위한 콘텐츠를 만들고 교육을 진행했다. 요새는 팀에 신입으로 들어온 개발자 동료들을 보고 도와주고 싶은 마음에 주니어 개발자들이 더 빠르게 성장하려면 어떻게 해야 할까에 대한 고민들을 많이 하고 있다. 

 

이 과정에서 개발자 부트캠프 기관인 '코드스테이츠'와 8주간 진행한 '함께 자라기' 프로젝트를 진행했었다. 본 프로젝트는 “주니어 개발자들이 알아두어야 할 소프트웨어 엔지니어링 기술“을 주제로 하여 첫 4주는 강의 수강 및 질의응답 + 남은 4주는 본인의 프로젝트를 직접 리팩토링하는 방식으로 진행했다. 소프트웨어를 더 나은 방향으로 개선하는 행위는 특정 도메인에 종속되지 않는다고 생각한다. 따라서 이번 스터디에는 프론트엔드, 백엔드 엔지니어 모두 모집하여 진행했다 
(프로젝트의 구체적인 이야기는 다음 편에서 작성할 예정) 

 

본 프로젝트를 회고하면서 크게 아래와 같이 나눠서 글을 작성해보려고 한다.

1. 개발자의 빠른 성장을 위한 방정식 세우기
2. 효율적으로 성장할 수 있는 교육 설계하기
3. 함께자라기 프로젝트 회고

 

사고의 흐름을 적용한 상황 예시들도 종종 넣었으니, 글을 읽는 독자들이 조금 더 구체적으로 와닿을 수 있으면 좋겠다.

 

1. 빠른 성장을 위한 3가지 조건 

성장한다는 것은 본인이 추구하는 ‘방향’으로 ‘이동’하는 것을 내포한다. 결국 잘 성장하기 위해선, 본인이 목표하는 올바른 방향으로 빠른 속도로 나아가는 것이 필요하다.

남들보다 더 빠르게 성장하기 위해선 어떤 요소들이 필요할까? 존경하는 개발자분들이 하시던 이야기와 쓰셨던 글들을 접하다 보면 공통점을 추출할 수 있다. 바로 문제 정의 역량, 환경, 태도이다.

 

1-1. 문제 정의 역량

문제가 문제다

문제 정의 역량은 이번 글에서 가장 핵심이 되는 영역이다. 요즘 스타트업들의 유행하는 슬로건들 중 하나로 “우리는 문제를 해결하는 사람이다“가 있다. 맞다! 우리 개발자들은 프로그래밍 언어와 각종 소프트웨어를 도구로 삼아 문제를 해결한다. 사실 여기에 조금 더 첨언하고 싶다. 바로 “문제를 올바르게 정의하고 해결하는 사람이다”이다.

 

요새 내 자신에게 있는 변화가 하나 있다면, 전보다 코드를 치는 시간이 줄어들고 문제를 정의하고 고민하는 시간이 더 길어지고 있다는 점이다. 그러다 보면 현상에서 문제를 포착하고, 문제를 날카롭게 다듬는데 시간을 많이 소모하는 편이다. 사실 잘 정의된 문제일수록 해결책들도 더 구체적이고 적절하다. 실제로 뛰어난 개발자일수록 키보드를 두드리는 시간이 적다고 하지 않는가.

 

회사를 다니면 이미 정의된 문제가 있기에, 우리는 해결만 하면 된다고 이야기할 수 있다. 그러나 이는 큰 오산이다. 그 누구도 명확히 정의된 문제를 전달해주지 않는다. 해외 유명 IT 기업들(FAANG) 취직에 관심이 있었던 사람들이라면 ‘시스템 디자인’ 영역의 코딩 인터뷰가 있다는 걸 다들 알고 있을 것이다. 해당 인터뷰에서는 단순히 문제를 해결하는 것을 테스트하지 않는다. 보통 애매모호한 요구사항을 제공하고 설계를 요구하기 때문에, 주어진 문제를 바로 풀어내는 인터뷰이는 보통 좋은 점수를 받지 못한다. 대신 정확한 문제를 정의하기 위해 질문들을 더 하고, 명확해진 상황에서 여러 해결책들을 바탕으로 최선의 선택지를 뽑는 방향이 더 나은 점수를 받을 수 있다.

 

예시

요 내용은 중요하기에 조금 더 구체적인 예시를 들어보겠다.

쇼핑몰 웹 서비스의 백엔드 개발자로 일을 하고 있는 김그랩씨는 어느 날 팀 회의에서 ‘상품 선물하기’ 기능을 개발해야 한다는 이야기를 들었다.

 

김 그랩 씨가 주어진 문제를 빠르게 해결하려는 Solver의 관점이라면, 상품 API 기능을 개발하기 위해 계획을 세우고 코드를 바로 작성하기 시작한다. 요구사항에 맞게 데이터베이스 스키마를 추가하고, 사용 중인 프레임워크에 맞게 Controller 로직을 개발하고 Router에 추가한다. 그리고 프론트엔드 개발자가 사용할 것을 고려해 API 문서를 작성하고 Jira 티켓을 깔끔하게 쓱 Done으로 마무리한다. 이 경우 김 그랩 씨의 해결하려는 문제는 ‘상품 선물하기 API 기능을 개발한다’가 된다.

 

만약 스스로 문제를 정의하는 태도를 가졌다면 어땠을까? 우선 ‘상품 선물하기 ’요구사항을 더 명확하게 하기 위해 마감기한, 우선순위, 검증하려고 하는 가설, 비즈니스 임팩트와 계획 등을 파악한다.

이를 바탕으로 선물하기 기능은 현재 비즈니스적 임팩트가 충분히 크고 앞으로 해당 도메인에서 더 많은 실험 및 발전이 있을 것을 판단이 된다. 따라서 김그랩씨가 해결하려는 문제는 ‘상품 선물하기 기능을 정확하게 구현하고 상품 도메인의 유연성을 높인다’로 확장된다. 여기서 만약 ‘선물하기 기능’이 신속하게 가설을 검증해보는 AB 테스트 성이거나 일시적 이벤트 성의 기능이었다면 어땠을까? 속도감을 높이기 위해 코드 퀄리티를 어느 정도 포기할 수도 있을 것이며 다른 우선순위가 높은 일에 집중했을 수 있을 것이다.

 

그렇게 되면 위에서 언급했던 ‘상품 선물하기 API 기능을 개발한다’는 여럿 중 하나의 해결 방안이 된다.. 더불어 상품 도메인의 유연성을 높이기 위해 “기존에 사용했던 레거시 모듈들을 리팩토링하기", 정확한 구현을 위해 “ 견고한 테스트 코드 작성하기”도 하나의 해결 방안들이 될 것이다.

 

결국 문제를 잘 해결하기 위해선 문제를 잘 정의하는 것에서부터 시작된다. 내가 풀려고 하는 문제가 정말 맞는가? 해결 방법에 대한 고민도 충분히 중요하지만 문제가 잘 정의되었는지에 대한 의문을 계속 가져보는 것이 더 중요하다. 잘 다듬어진 문제는 더 뚜렷한 문제 해결법을 낳을 것이고 이는 자연스럽게 문제 해결 역량의 증가로 이어질 것이다. 글은 이렇게 쓰고 있지만 사실 나도 아직 부족하기에 더 잘하기 위해서 노력하는 영역이다.

 

원 글을 피드백받는 과정에서 대체 뭐가 문제야? 라는 책을 추천받았는데, 관심이 있으신 분들은 읽어보시는 것도 좋을 것 같습니다 👍🏻

 

1-2. 환경

양댕이

사실 성장에 있어 가장 중요한 요소는 환경이지 않을까 싶다. 인간은 사회적 동물로서 가까이 있는 사람들 과 생활하는 문화에 따라 정체성은 많이 영향을 받는다. 사실 이와 관련해 맹모삼천지교라는 고사성어부터 옛 말부터 시작해서, 강남 8 학군으로 아이들을 보내기 위한 부모님들의 열정은 이미 너무 잘 알려져 있다.

 

그러면 어떤 환경이 성장에 좋은 환경일까? 좋은 환경이라는 건 사람마다 해석하기 나름이겠지만, 내가 생각했을 때 좋은 환경은 ‘피드백’의 질과 양이 모두 뛰어난 곳이다. 내 생각과 행동이 과연 적절했는지, 더 나아가 앞으로의 방향에 대한 피드백은 생각보다 빠른 성장을 위한 방향성을 더 날카롭게 다듬어주며 내적 동기부여를 통해 성장에 가속도를 붙여준다.

 

피드백은 그러면 수직적 성향을 띄는가? 절대 그렇지 않다. 생각보다 나와 같은 교육적 수준에 있는 사람들에게 더 영향력 있는 피드백을 받는 경우도 많다. 사실 나보다 조금 더 뛰어난 사람들이 현실적으로 더 많은 동기부여를 주고 피드백을 받을 수 있다. 왜냐하면 동질감을 느끼고 공감할 수 있는 상황과 맥락을 공유하고 있기 때문이다.

 

또한 피드백은 꼭 직접적으로 주고받는 게 아니어도 괜찮다. 직접적으로 피드백을 주고받는 게 아니고 간접적인 피드백도 꽤 큰 영향을 준다. 주변에서 동료들이 짜는 코드들을 보고 내적 깨달음을 얻을 수도 있고, 동료들의 잘하는 모습을 보며 나도 저렇게 해야겠다는 내적 동기부여로 이어질 수도 있다.

 

결국 성장을 위해서는 피드백이 있는 환경이 정말 중요하다. 지금 피드백을 잘 받을 수 있는 환경에 있는가에 대해 스스로 질문해보자. 만약 피드백을 잘 받을 수 있는 환경이 아니라면, 스스로 그런 환경을 만들어보는 것부터 시도해보자.

작성한 코드에 리뷰를 받고 싶은 부분을 구체적으로 적고, 주변에 배울 수 있는 개발자들에게 부탁을 드려볼 수도 있다. 혹은 스스로 이 달의 목표를 세우고, 잘 달성했는지를 확인하고 주변 동료, 상사에게 1 on 1을 통해 피드백을 요청하는 것도 만들 수 있다. 만약 통제 불가능한 환경이라면? 더 좋은 환경으로 가기 위해 준비를 하는 게 나을 수도 있다.

 

1-3. 태도

보통 회사에서 신입, 주니어 개발자를 뽑을 때 가장 중요하게 보는 것 중 하나가 바로 태도이다(꽤나 범용적인 용어로 쓰이고 있긴 하지만). 사실 개발자가 임해야 하는 태도와 관련해 좋은 글이나 영상이 많다(‘주니어 개발자 태도’라는 키워드로 한 번 검색해보자). “포기하지 않는 끈기(Grit)”, “피드백 적극 수용하기”, “끊임없는 학습과 새로운 것에 대한 호기심” 같은 태도들은 여러분들도 이미 어느 정도 인지하고 있을 것이라고 생각하고 따로 적지 않겠다.

 

다만 여기서 조금 더 이야기하고 싶은 건 실천하는 태도다. 인지와 행동은 엄연히 다른 영역이기 때문이다. 인지하고 있는 것들을 행동으로 그대로 옮기는 것은 쉽지 않다. 기존 사고 방식과 행동 패턴은 관성이 강하기 때문이다. 이는 자기 계발 영상을 본 당시에 가득 찬 고양감이 다음날 눈을 떴을 때는 사라져 있는 것과 유사하다.

 

성장을 견인할 수 있는 태도들을 내재화하기 위해서 우리에게 필요한 것은 실천이다.

그렇다면 더 잘 실천하기 위해서 필요한 건? 바로 주기적인 ‘자기 회고’다.

보통 회고를 하는 이유는 1. 현재 목표하는 대로 잘 행동하고 있는지를 2. 되돌아보면서 점검하고 3. 더 나은 방향으로 가기 위해 계획을 세우기 위함이다. 앞만 보고 달려가다 보면 생각보다 놓치는 것들이 많고, 계획과 다르게 행동하고 있을 때가 많다. 이때 주기적인 회고를 통해 방향성을 조정하고 집중할 것들을 명확하게 한다면 생각보다 원하는 목표를 빠르게 달성할 수 있을 것이다.

 

TMI로 하나 더 이야기하자면 회고라는 것을 ‘개발자’라는 직업을 넘어 인생 전반에 걸쳐 해보는 걸 추천한다. 앞으로 인생을 어떻게 살아야 하는가에 대한 질문은 우리가 평생을 거쳐 계속해서 고민하고 답을 내기 위한 가장 어려운 문제이기 때문이다. 우리의 삶의 목표가 단순히 잘하는 개발자가 되고 싶다는 것은 생각보다 Fragile(부서지기 쉬운)할 수 있다. 나보다 잘하는 개발자들은 세상에 정말 많고, 알아야 할 것들은 매일매일 폭포처럼 쏟아져 나오기 때문이다. 그래서 나는 삶의 중심을 ‘개발자로서의 나’가 아닌 ‘온전한 나’로 잡아가 보는 것도 중요하다고 생각한다.

 

2. 개발자의 수평적 성장과 수직적 성장

개발을 처음 배우는 입장으로 돌아가보면 정말 즐거웠다. 사용자의 입장에서 바라본 소프트웨어를 개발자의 입장에서 접근할 수 있다는 것은 참 신기한 경험이었다. 프로그래밍을 하기 위한 기본 문법과 해당 분야의 지식들을 쌓아가고 이를 바탕으로 작게나마 특정 역할을 하는 소프트웨어를 만들어가면서 코딩을 할 수 있는 근육들을 점점 붙여나간다(마치 처음에 헬스를 시작했을 때 빠르게 근육이 붙는 것처럼)
이렇게 초기에는 모르는 것들을 알아가면서 수직적인 성장을 해왔다면, 어느 시점부터는 정체기와 함께 수평적인 성장이 주를 이루게 된다. 여기서 이야기하는 수직적, 수평적 성장은 무엇일까?

 

수평적인 성장은 How에 기반한 성장이다. 문제를 해결하기 위한 방법들을 알아가는 단계의 성장이다. 예를 들어보면 웹 서버의 인증 로직을 구현한다고 했을 때 처음에 token based auth으로 구현을 했다면 session based auth로 구현해서 기본적인 웹서버의 인증 방식들을 익힐 수 있다.

 

수직적인 성장은 Why에 기반한 성장이다. 현상에서 보이는 문제를 더 높은 차원에서 바라볼 수 있도록 하는 성장이다. 예를 들어 웹 서버 인증을 구현한다고 했을 때, 현 상황에서 어떤 인증 방식을 선택해야 적합한지에 대한 고민을 해결하는 과정을 들 수 있다. 만약 세션 기반으로 선택했다면 왜 세션 기반으로 선택하려고 하는지? 더 나아가 서비스의 트래픽이 늘어나게 되면 어떤 문제점들이 발생할 수 있는지?(세션의 정합성 문제 같은) 등의 질문들에 답을 찾아가는 과정이다.

 

성장하는 개발자는 수직적 성장과 수평적 성장을 함께 가져가는 사람이라고 생각한다. 그러기 위해선 계속해서 질문하고 문제를 다듬어가는 과정이 필요하다. 문제가 잘 정의될수록, 더 다양한 해결 방안들을 찾아낼 수 있으며, 이들을 학습하고 해결해 나가는 과정에서 자연스럽게 수평적 성장을 견인할 수 있을 것이다.

 

3. 코더가 아닌 소프트웨어 엔지니어가 되자

요새 화두가 된 '구글 엔지니어는 이렇게 일한다'

최근에 ’구글 엔지니어는 이렇게 일한다’라는 책을 봤다 내가 추구하는 방향에 더 많은 살을 붙여주는 정말 좋은 책이었다. 동시에 아직도 나도 부족함을 느끼고 더 성장해야 함에 좌절감을 느끼는 한편으로는 아직까지 모르는 것들을 알아갈 수 있다는 뭔지 모를 정복욕이 들기도 했다.

 

우리가 이야기하는 개발을 한다는 것을 무엇이라고 생각하는가. 위키피디아의 ‘개발’이라는 것의 정의에 따르면 “무엇인가를 보다 쓸모 있거나 향상된 상태로 변화시키는 행위”이다. 소프트웨어 개발이라는 것은 소프트웨어를 더 나은 방향으로 나아가게 하는 행위이며 이를 하는 사람을 소프트웨어 엔지니어라고 한다. 구글 엔지니어 책에서는 소프트웨어 엔지니어링은 시간이라는 차원을 함께 고려하게 되면서 이야기한다.

 

주어진 요구사항을 묵묵히 개발하는 것 좋다. 이미 주어진 것을 만들어내는 행위도 좋다. 하지만 더 나은 소프트웨어를 만들어가기 위해선 더 메타적인 관점의 시야와 경험들을 필요로 한다. 기존에 있는 소프트웨어를 구성하는 코드와 프로젝트 개발 사이클과 문화 등 고착화되어 있는 것들에 의문을 품고, 더 나은 방향으로 이끌어갈 수 있어야 한다고 생각한다 (더 나은 방향에 물론 정답은 없다). 기존에 있는 지식들과 환경에 고착화되고 익숙해지면 다음 단계에 대한 깊은 고찰과 질문을 끊임없이 해나가야 한다고 생각한다.

 

내가 좋아하는 책인 김창준님의 ‘함께 자라기’ 에서도 나온다. A, B, C의 업무가 있다. A는 본인에게 주어진 걸 하는 것, B는 A를 개선하는 것, C는 B를 개선하는 것이다. 소프트웨어 엔지니어라면 B와 C에 더 집중할 수 있어야 한다(사실 B, C를 잘하기 위해선 A부터 잘해야 한다) [블로그 글 참고 : http://egloos.zum.com/agile/v/2854698]

 

소프트웨어 엔지니어는 주어진 일만을 잘해서는 안된다. 자신이 책임져야 하는 소프트웨어는 비즈니스 상황(혹은 특정 문제 상황)에 맞게 발전하는 동시에, 소프트웨어가 앞으로도 성장할 수 있도록 계속해서 개선해야 한다.

 

4. 실전! 성장하기 위한 사고법 적용하기

질문을 통해 문제의 차원을 높이고 더 다양한 관점의 해결책을 고민하는 과정을 예시로 한 번 들어보며 마무리하겠다. 주어진 문제 상황을 어떻게 정의하냐에 따라 바라보는 시야가 달라질 수 있음을 확인할 수 있다.  

 

쇼핑몰 웹 서비스를 개발하는 김그랩씨는 상품 추천 화면에서 가끔씩 상품 정보가 조회되지 않는다는 피드백들을 주기적으로 받았다

 

1. 왜 에러가 발생하고 있는가?

답변 : (열심히 디버깅 해보니..) 해당 엔드포인트를 구현하는 코드에서 DB 쿼리 Timeout 관련 예외 처리를 할 때 빈 데이터를 넣어서 응답하고 있었다.

액션 : 과거 성능을 고려하지 않고 작성된 쿼리를 수정하고 요청량을 파악해서 DB에 인덱스를 설정해준다
더불어 HTTP 응답 상태를 더 쉽게 파악할 수 있도록 500 에러를 발생시키도록 한다.

 

2. 왜 뒤늦게 문제를 발견했을까?

답변 : 해당 DB 쿼리 코드의 예외 처리를 하는 부분에 별도의 로그도 존재하지 않았다. 또한 WAS 서버에 대한 모니터링 수단이 부족했다.

 

액션 : 에러가 발생할 수 있는 지점들에 Stacktrace를 포함한 에러 로그를 남기고 한다. 더불어 서버의 상태를 잘 진단할 수 있도록 APM 도입을 고려한다.

 

3. 왜 로그를 제대로 남기지 않았을까?

답변 : 팀 내에 별도의 코드 리뷰 프로세스가 없었고, 지켜야 할 컨벤션도 존재하지 않았다.

 

액션 : 레벨에 맞도록 로그를 남기도록 팀 내 컨벤션을 만들고, 주요 API 개발 관련하여 코드 리뷰를 강제할 수 있도록 한다.

 

4.  왜 우리 소프트웨어는 에러가 자주 발생할까?

답변 : 전체적으로 소프트웨어의 가시성이 떨어진다

 

액션: 가시성을 높이기 위해 모니터링 환경을 더 고도화한다. 현재 알럿(alert)의 우선순위를 조정하여 팀 차원에서 빠르게 대응할 수 있도록 문화를 만들어간다. 여유가 되면 팀의 지표가 될 SLO를 함께 설정한다

 

5. 더 나은 소프트웨어란 무엇일까?

답변 : 같이 알아가 봅시다!

 

 

5. 결론

나도 잘하고 싶다구

결국 위 글을 한마디로 정리하자면 “빠른 성장을 위해선 계속해서 질문하고 스스로 문제를 정의해야 한다”라는 것이다.

주어진 문제를 수동적으로 해결하는 자세에서 벗어나 더 높은 관점에서 문제를 정의하고, 이를 해결하는 과정을 계속 반복하다 보면 우리는 점점 더 성장해있을 것이라 확신한다.