팁1. 자신의 기예(craft)에 관심을 가져라

여기서 기예란 ‘컴퓨터에게 우리가 시키고 싶은 일을 하게 끔 만드는 것’을 의미한다. 좀더 자세하게 자신이 어떤 기예를 가지고 있고, 어떤 부분에 능숙하고 부족한지를 알아야 한다. 그래야만 실제 직면한 문제들에 대해 해결할 수 있고, 기예를 단련하기 위해 어떤 방향으로 나아가야 할지도 잡히기 때문이다.

이는 실용주의 프로그래머가 갖는 여러 특징 중 공통적이면서 기본적인 특징이다.

그 외에도 여러 특징이 있다.

새로운 것에 빨리 적응하는 것
새로운 기술이 나오거나, 새로운 환경이 등장 했을 때 이를 적극적으로 학습하고 적응하는 특징을 말한다.
호기심
잘 모르는 것에 대해 궁금해하고 학습하려 하는 것. 내부 구현에 대해서 궁금해 하거나 원리에 대해 궁금해 하는 특징이다. 이전 특징과 어느 정도 비슷한 부분이 있다.
비판적인 사고, 현실적인 사고
무언가에 대해 이론이나 의견이 아닌, 실제로 실현 가능 여부에 대해서 사고하는 것을 의미한다. 기한 내에 충분히 가능한지, 뭔가 문제가 발생 했을 때 근본적인 원인 제거가 가능한지 등이 포함된다.
다방면에 능숙
백엔드 개발자라고 해서 백엔드에만 능숙한 것이 아니라, OS, 네트워크, 인프라, 프론트 엔드, 모바일 등의 비전문 분야에 대해서도 어느정도 능숙 혹은 이해가 있어야 한다. 원활한 소통과 문제해결에 있어 도움이 되기 때문에 이러한 특징을 강조하는 것으로 보인다.

팁3. 당신에게는 에이전시(agency)가 있다.

에이전시는 대리권, 대리 업무, 대리 기관 등의 명사적인 의미를 가지는데, 에이전시 회사는 다른 사람 혹은 기업을 대신해서 업무 또는 교섭을 대신하는 회사라고 볼 수 있다. 사전적인 의미와는 연결되지는 않지만, 책에서는 좀 더 자세한 설명으로 아래와 같이 덧 붙였다.

스스로 행동을 결정할 수 있어야 하며, 문제를 고치기 위해 노력할 수 있어야 하고, 주도적으로 행동해서 기회를 잡을 수 있어야 함을 강조했다. 수동적이지 않고 적극적인 태도를 가지고 스스로 결정함으로써 문제 해결 할 수 있어야 한다는 의미로 보인다.

다만 이게 에이전시와 어떤 연결성이 있는지는 모르겠다. 영상 댓글로 문의한 상태이다.

팁6. 변화의 촉매가 되라

촉매란 어떤 일을 유도하거나 변화시키는 일을 의미한다.

이 팁에서 강조하는 것은 한 번에 크게 바꿔서는 안된다는 사실이다. 변화의 대상이 너무 크고 장대할 경우 좌절하게 되고, 결과적으로 포기로 이어질 수 있기 때문이다. 그래서 그 변화의 대상을 작게 쪼개어서 점진적으로 진행하고 이를 통해 작은 성취를 계속해서 이어감으로써 변화의 흐름이 이어질 수 있도록 할 것을 강조했다. 그리고 이러한 작은 성취는 주변에도 영향을 주게 됨에 따라 변화에 동참하려 합류하는 움직임으로 까지 이어질 수 있다.

팁9. 지식 포트폴리오에 주기적으로 투자하라.

새로운 것을 배우는 능력은 가장 중요한 전략 자산이다. 이러한 자산을 공급하기 위한 자산을 위한 제안 사항은 다음과 같다.

매년 새로운 언어 배우기
기술 서적 읽기
수업 듣기(온라인 세미나), 지역 모임 참여
트렌드 분석

이러한 자산들은 당장 프로젝트 혹은 실무에 사용되지 않더라도 사고 확장에 도움이 되거나, 향후에 필요할 때 즉각적으로 활용할 수 있다.

팁18. 최종 결정이란 없다.

프로젝트 진행에 따라서 결정됐던 사항이 번복되거나 변경되는 경우가 많다. 사실 초기에 최선의 결정을 하는 것 자체가 굉장히 어렵고, 중요한 결정은 쉽게 되돌릴 수 없으므로 프로젝트 초기에는 최종 결정을 줄여야 한다.

결정은 돌에 새겨진 글씨가 아니며 SW 개발 속도는 요구사항, 사용자, HW 변화를 결코 추월할 수 없다.

그렇기 때문에 프로그래머는 선택의 여지를 남겨둘 수 있는 구조를 만들 수 있어야 하며 변화에 유연하게 대응할 수 있는 아키텍처 및 코딩을 할 수 있는 역량을 길러야 한다.

팁42. 작은 단계들을 밟아라. 언제나.

예측할 수 록 틀릴 가능성은 높아진다. 때때로 자신의 경험에 미루어 예측을 하고 이를 기반으로 설계 및 개발하는 경우가 있다. 하지만 그렇게 할 경우 불필요하고 복잡하고 쓸모없는 코드가 만들어질 가능성이 있다.

그렇기 때문에 우리가 지금 바로 볼 수 있는 미래까지만 고려해야하며, 미리 미래를 예측하기 보단 변화에 대응할 수 있는 능력을 키우는게 더 좋다.

팁65. 일찍 리팩터링하고, 자주 리팩터링하라.

리팩터링이 필요한 코드는 일종의 종양과 같다. 가만 놔두면 점점 퍼져 나중에는 제거하는 데 드는 비용이 매우 커진다. 그렇기 때문에 문제가 작을 때 개발하는 동안 함께 진행하는 편이 더 쉬울 수 있다. 리팩터링은 일종의 고통 관리이다. 정상적으로 동작하는 소스를 변경하는 작업이 고통스러울 수 있지만 코드는 건강해진다.

팁70. 여러분의 SW를 테스트하라.

테스트는 프로그래밍의 일부이며, 프로그래머가 당연히 해야할 일을 중 하나이다. 테스트 코드를 만들게 될 경우 반복되는 테스트를 줄 일 수 있고, 리팩토링시 정상 동작을 검증하기 위한 수단도 될 수 있다. 또한 테스트 되는 부분은 중요한 부분일 확률이 높으므로 다른 개발자가 해당 프로그램을 이해하는데 참고하는 도구도 될 수 있다.

팁76. 프로그래머는 사람들이 원하는 바를 깨닫도록 돕는다.

프로그래머, 개발자란 직업의 본질적인 역할을 고객의 문제와 어려움을 해결 하는 것이다. 여기서 고객은 그 범위가 매우 넓으며 회사 내 다른 부서, 혹은 해당 프로그래머를 인터넷을 통해 사용하는 사용자도 될 수 있다.

보통 최초의 요청 사항이 오면 그게 최종 요구 사항이 아니며 함께 요구사항을 정리하기 위한 출발점 정도로 생각하면 된다. 고객은 뭘 원하는지도 정확히 알지 못할 때가 있다. 그렇기 때문에 최초 요구 사항을 받고 바로 해결책을 구현하면 변경 가능성이 높다.

프로그래머는 고객이 진짜 원하는 바를 깨닫게 도와야한다. 왜 요청하는지 이해하고 피드백을 주고 받아야 한다. 이 팁은 ‘팁 96. 사용자를 기쁘게 하라. 그저 코드를 내놓지 말라’과 연결되는 팁이기도 하다.

팁87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

기술적으로 선도하는 기업(마네카라쿠배)가 한다고 해서 무턱대고 따라가서는 안된다. 무조건적인 숭배는 실패할 가능성을 높이게 된다.

그렇기 때문에 맥락을 이해하고 자신이 속한 조직에 맞춰가면서 시도를 해야한다.

대표적인 예로, DB Access Framework로 MyBatis가 아닌 최근 많이 쓰이고 있는 JPA를 선망하고 따라가는 것을 예로 들 수 있을 것이다.

해당 기술을 도입하게 된 배경을 이해하고, 실제 회사가 직면한 문제를 해결 할 수 있는지, 그리고 그 기술에 대해 잘 알 고 있는 엔지니어가 충분히 있는지, 혹은 엔지니어가 조금 적더라도 실무에 적용해서 쓰는데 그렇게 많은 시간이 필요하지 않은지 등 여러 방면에서 고려하고 채택해야 한다.

앞서서는 기술을 중심으로 예로 들었는데 기술이 아니더라도 문화 등도 포함이 될 수 있다.

마지막, 팁 97. 자신의 작품에 서명하라!

자신이 보기에 자랑스러운 작품을 만들어 내자!

전문가가 만든 진정으로 전문가 다운 결과물을 만들자!

저작자표시 비영리 변경금지