원래 하고 싶은 말은 훌륭한 팀장님은 무엇일까이다.
하지만 이에 대해서 얘기하기 전에 개인적으로 생각하는 훌륭한 개발자란 무엇인가에 대해서 말해보고 싶다.

(개인적으로 생각하는) 훌륭한 개발자의 조건

1. 데드라인을 엄격하게 엄수한다(또는 그러려고 노력한다).

회사 소속으로서 월급을 받으며 근무를 하거나
프리랜서로서 계약을 맺고 근무를 하는 모든 개발자들은
개발자이기에 앞서 직장인이다.

개발자 개인 입장에서의 우선순위와 회사 입장에서의 우선순위는 서로 일치하지 않을 수도 있다.
사회라는 조직체에서 여럿이 함께 어우러져서 살아가려면 어느 정도 숙이고 타협하는 자세가 중요한 것 같다.

나같은 경우에는 클린 코드에 대한 열망이 상당히 강하다.
그리나 나 혼자서 완벽한 클린 코드를 추구하느라 마감기한을 넘긴다거나 하는 것은 직장인으로서 바람직한 행동이 아니다.
사실 예전에는 개발자라면 당연히 누구라고 클린코드가 더 중요하다고 생각할 줄 알았다.
하지만 여러 사람들과 의견을 나누면서 생각이 완전히 바뀌었다.

누군가가 이런 말을 했다.

아주 완벽에 가까운 클린코드이지만 제대로 돌아가지 않고 곳곳에서 치명적 에러를 일으키는 코드와
엉망진창에 가까운 스파게티처럼 복잡하지만 사소한 오류 몇 개 외에는 아주 정상적으로 동작하는 코드가 있다면
둘 중에 무엇을 선택할 것인가?
당연히 후자를 선택해야 한다.
정상적으로 실행되는 코드에서 시작해서 리팩터링을 해 나가는 것이 맞다.
당신이 토이 프로젝트를 하는게 아니고 회사 업무를 하고 있다면 당연히 그렇게 해야 한다.

이런 명언을 듣고 처음부터 끝까지 클린코드만 추구하는 나의 자세가 매우 성숙하지 못한 가치관이라는 것을 깨달았다.

1번 조건에 대해서는 다른 측면에서도 생각해볼 수 있다.
어떤 기능을 구현하면서 A라는 방식으로 하고 있는데
그 과정에서 A는 야매같은 방법이고 B가 더 훌륭하고 올바른 방법이라는 걸 알게 됐다고 가정하자.
이럴 때 B로 재구현하는 것이 항상 정답이 되지는 않는다.
마감기한까지 남은 기간을 고려해서 자신의 업무 능숙도를 고려해보고 팀원들과의 논의 후에 결론적으로
이번 이터레이션에는 A를 선택하는게 전체적으로는 더 바람직한 결정이 될 수도 있다.

시간 엄수는 사회 구성원들 간의 신뢰 형성에 크게 기여하는 요수 중 하나이다.
데드라인을 지키지 못하는 팀원은 사람들에게 불안감을 심어준다.
업무를 맡겼을 때 언제 완료될지 모른다거나
예상했던 시간보다 지나치게 늦어진다면 해당 팀원과 협력하기기 쉽지 않다고 느낄 것이다.
또한, 한 명의 잘못이지만 회사 윗사람들의 눈에는 해당 개발팀 전체의 잘못이라고 보이기 쉽기 때문이다.

데드라인 엄수는
사회 구성원으로서 책임감있는 행동하는 것이라고 생각한다.

2. 코드 퀄리티를 높이려고 노력한다.

위에서 언급한 1번 데드라인 엄수가 회사에 대해서 책임감 있게 행동하는 것이라면
코드 퀄리티 향상을 위해서 노력하는 것은 우리팀에 올 미래의 개발자에게 책임감있게 행동하는 것이다.
자신이 구현한 코드도 몇 주만 지나면 뭐가 뭔지 이해하기 힘들다는 말을 들어본 적이 있다.
정말 시급한 상황에서 구현한 코드라면 그렇게 될 수도 있을 것 같다.

그런건 개발자의 바람직한 태도가 아니라고 생각한다.
개발 업무를 혼자하는 경우는 왠만한 규모의 기업만 가도 거의 없고 언제나 협력의 연속이다.
내가 보고 있는 코드는 앞서 이 팀에 근무한 다른 누군가가 만든 코드이고
내가 지금 만드는 코드는 미래의 나 자신 아니면 미래에 이 팀에서 근무하게 될 누군가가
읽고 유지보수하게 되는 코드이다.
어떤 통계 자료에 따르면 어떤 개발자가 코드를 작성하는데 들이는 시간이 1이라면
눈앞의 코드를 읽고 이해하려고 노력하는 시간은 8, 9 정도라고 한다.
그렇기에 누군가의 생산성을 억제하고 헤치려는 의도가 아니라면
코드 퀄리티를 가능한 최대한 높이려고 노력하는 것이 옳다고 생각한다.

어떤 이유에서든지 제대로 관리되지 않은
엉망진창인 코드 베이스를 읽고 유지보수하려고 노력해본 사람이라면
코드 퀄리티의 중요성에 대해서 느끼는 이 감정이 무엇인지 알 거라고 생각한다.

기술 부채(technical debt)라는 용어로 부르기도 한다.
부채는 처음에는 한 두 달 월급만 열심히 모으면 되는 것처럼 별거 아니라고 치부할 수 있겠지만
복리로 불어나면서 어느 순간에는 평생을 목숨 받쳐 일해도 다 갚지 못하는 양이 될 수도 있다.

모든 개발자들이 조금만 더 프로다운 자세로
각자의 위치에서 코드 퀄리티를 높이려고 노력하면
개발 생태계가 전체적으로 긍정적인 방향으로 흘러갈 거라고 믿는다.

3. 긍정적인 사고 방식

개발자의 업무는 쉽지 않다.

어디에서 어떤 이슈를 맞닥뜨리게 될지 예상하기 힘들다.
기존의 아키텍처로 별다른 문제없이 서비스를 운영해 왔더라도
비즈니스가 크게 대박나서 트래픽이 폭증한다면
기존에 일하던 방식으로는 일해서는 오류를 막을 수 없는 상태가 된다.
그럼에도 불구하고 개발자는 이슈없이(또는 사용자에게 이슈가 드러나지 않도록 조치를 취해서라도)
서비스를 운영해야 한다.

개발자는 죽을 때까지 아니면 은퇴하는 순간까지 공부해야 하는 직업이라고들 말한다.
매년 새로운 언어와 프레임워크가 등장하고
매초 새로운 라이브러리가 몇 개씩 생겨나고 한다.
이렇게 끊임없이 등장하는 새로운 언어와 프레임워크를 공부해서 실무에 적용하는 것은 상당히 피곤한 일이다.
언어마다 패러다임이 다르고
디테일을 신경쓰지 않으면 바로 바로 오류가 발생할테니
꽤 긴 시간을 긴장 상태로 보내야 한다.

그렇기 때문에 개발자는 긍정적인 사고 방식이 중요한 것 같다.
어떤 복잡하고 해결하기 힘든 이슈를 만나더라도
결국에는 해결할거라고 자기 자신과 팀원들을 믿고 한 발씩 앞으로 나아가야 하는 것 같다.
이 긍정은 근거가 있는 없든 상관이 없다.
어떻게 해결해야 할지 알고 있어서 긍정적인 자세가 된다면 그게 최고겠지만
설령 솔루션을 모르더라도 어떻게든 방법을 찾으면 된다.
소프트웨어는 순수하게 논리에 기반해서 동작하기 때문에 불가능이란 없다고 생각한다.

4. 소통 능력(프로그래밍 언어가 아닌 인간의 언어를 이해하는 능력)

개발 업무에 있어서 개인적으로
가장 중요하다고 생각하는 요소 중 하나는 '요구사항 분석'이다.

예전에 요구사항을 잘못 이해한 채로 한 두 달 정도 시간이 흐른 뒤에
고객사에게 피드백을 받는 과정에서 고객사가 원한 것과 완전히 다른 서비스를 만들어버려서
구조를 처음부터 다시 재설계해야 했던 경험이 있다.

사람은 누구나 완벽하지 않다.
기획 문서도 마찬가지이다.
한 번에 완벽하게 처음부터 끝까지 서비스 기획이 완료되는 경우는 없다.
점진적으로 기능이 추가되고 버그를 고치면서 조금씩 진화한다.

개발자가 맡는 업무는
기획 회의에서 건의된 내용이나 기획 문서에 존재하는 내용을 코드로 구현하는 경우가 많다.
회사 업무는 무에서 상상 속 유니콘을 만들어내는 작업이 아니고
사람이 경험하는 현실세계의 서비스를 반영하는 게 핵심 중 하나라고 생각한다.

또한, 업무를 하다보면 동료 개발자나 다른 팀과 협력하는 경우도 많다.
이때 소통 능력이 좋은 사람 또는 눈치가 좋은 사람이면 적은 시간으로도 더 많은 정보를 주고 받을 수 있으므로
효율적으로 업무를 진행할 수 있다.

5. 기타

이외에도 중요한 능력은 너무 많다.
최근에 느낀 것은
역사를 공부하는게 생각보다 이득이 되는 것 같다.
자신이 다루는 언어, 프레임워크, 플랫폼의 변화 과정을 알고 있으면
역사를 모르는 사람이 단순히 한 두 번 보고 이해하기 어려운 부분도 다 알고 있게 되어서
구현하거나 이슈 트래킹을 할때 생산성이 훨씬 높아지는 것 같다.

CS 지식이나 내부 구현에 대한 관심도 소홀히 하면 안 되는 것 같다.
사실 일상적인 업무를 할때는 빠르게 문법을 익혀서 무조건 많이 타이핑해보는 것이 도움이 된다.
매일의 업무에서는 컴퓨터 공학 그런게 왜 필요할까 싶기도 하다.
그러나 결정적으로 이슈가 발생했을 때
네트워크 관련 지식, 운영체제 관련 지식, 빠식하게 알고 있는 라이브러리/패키지 내부 구현에 대한 지식 등이
큰 도움이 된다.