개인적으로 느낀 개발자 좋은 습관들 끄적

n년차 개발자로 일하면서, 개발 선배님들께 조언을 듣거나 스스로 부딪히면서 깨닫게 된 점들이 꽤 있다. "잘 먹고 잘 자야 건강해진다" 같은 뻔한 말이지만, 결국 그 뻔한 말들이 옳은 방향이었음을 느낀다.

지금부터 개발자 좋은 습관을 적어보려고 한다. (*개인적인 의견임을 밝힙니다)

일단 기록하자

프로젝트 투입 시 업무, 회의, 개발하면서 발생하는 모든 것들을 요약하여 기록하는 습관을 만들자.

중요한 회의에 참석 시 녹음하여 회의록에 복기한다. 회의와 관련된 내용 (회의일자, 논의주제, 참석자, 담당자 답변 예정 일자 등)을 적어두면 이것은 내 논리의 뒷받침이자 무기가 된다.

상사며 동료며 후배며, 업무 관련해서 구두로 나눈 얘기도 메일이나 메신저로 남겨놓는다. 특히 업무 지시와 보고 내용은 확실하게 적어두는 게 좋다. 그게 나를 지켜준다. (뒤통수 몇 번 맞다 보면 기록하게 됨....)

빡빡해 보일 수 있지만, 주변 사람들에게 꼼꼼한 인상을 심어준다. 내 기억의 뒷받침에는 증빙이 있는 셈이라고 선언하는 셈이다.

귀찮지만 녹음의 효과는 좋다! 플젝 투입 시 처음 업무설명을 들을 때 양해를 구하고 녹음을 트는 편인데, 이는 업무 숙지를 더 빠르고 원활하게 해 준다. 여러 번 같은 것을 물어보는 것보다 녹음 복기하면서 모르는 점을 정리해서 여쭤보는 것이 훨씬 낫다고 본다.

노력하자

사람들에게 일 잘하는 사람으로 인식받으려고 노력하자. 자연스럽게 일거리가 몰릴 수도 있지만, 본인이 성장하고 싶다면 일단 노력하는 게 중요하다고 생각한다.

그렇다고 너무 격하게 열심히 하는 모습을 보여주면 기대치가 높아진다. 적당한 스탠스를 취하면서 내 맡은 할 일을 착실히 하자.

초급 때 독하고 끈덕지게 하자. 이때 한 고생은 나중에 자산이 된다. 나이 들어서 실력 없는 개발자가 되기 싫으면 꾸준히 노력하는 수밖에 없다.

가만히 있지 말자. pm이 일을 줄 때까지 조용히 기다리는 수동적인 사람이 생각보다 많았다. '내가 이건 안 해본 거라서...' 이런 핑계는 대지말자. 이런 말을 하는 개발자들도 많았다. 해본 거만 해볼 수는 없다. 안 해봤더라도 부딪혀보고 배우면 된다.

구체적인 업무 노력들

• 인덱스를 기억하자. 파일서버나 제공된 문서의 인덱스를 살펴본다. 인덱스를 기억했다가 필요한 것을 제때 꺼내쓸 수 있도록 기억해놓자.
  
  
• API를 살펴보자. 예를 들어 웹스퀘어를 사용한다면 전반적인 API를 참고하거나, 스프링 부트로 개발한다면 spring.io 사이트와 친해지는 것이 좋다.
  
  
• DB 실데이터와 ERD 구성도를 살펴보면서 업무흐름도(flow) 그려보자. 실제 데이터를 보고 흐름을 파악하라는 부장님들의 조언이 많았다.
  
  
• 소스를 가져다 쓸 때 증빙을 가지고 있는다. 왜 이 소스를 가져다썻는지 구체적인 증빙을 가지고 있자. 추측으로 끝내지 않는 게 중요하다. "오류 나는 곳이 여기겠지? 이렇게 사용하는 게 맞겠지?" 구글링이든 소스에서 확인하든 추측을 사실로 만드는 과정이 필요하다.
  
  
• 디버깅과 테스트를 잘 활용하자. 업무 효율성이 높아진다.
  
  
• 프로젝트의 관련 용어를 숙지하자. 예를 들어 보험 프로젝트에 투입되었다면 인바운드, 아웃바운드 같은 기본 용어를 숙지하고 보험약관에서 용어들을 읽어보자.
  
  
• excel이나 notepad를 잘 활용하자. 경력이 높아질수록 문서 작업이 많아진다. 엑셀 vlookup 같은 기능을 잘 활용하고 notepad는 열작업이나 정규표현식으로 원하는 데이터 추출하는 것 등을 알아두자.

복습하자

신기하게도 프로젝트를 끝나고 다음 프로젝트를 하면, 전 프로젝트의 내용은 기가 막히게 잊어버리게 된다.

내가 짠 소스도 기억이 안 날 수 있다. 상사가 내가 담당한 소스에 대해 '그거 뭐였지?' 물어본다면, 곧잘 대답할 수 있는 정도의 복습정도는 해야 한다. 그것이 진짜 내 것이 된 거니까. 내 것을 만들어야 한다.

현재 프로젝트를 설명할 수 있는가? 만약 면접이라면, 내 담당업무 및 전체흐름을 일목요연하게 말할 수 있는가? 내가 경험했던 업무를 A4용지 1장씩으로 정리해 보자. 그것을 면접관한테 설명한다고 생각하고 업무팀 설명을 요약한다. 매년 본인의 업무에 대해서 이런 상태를 유지해 놓으면 내 자신감이자 자산이 된다.

기능이 돌아가게끔만 구현하는 SI 개발자들이 많다. 기한 내에 개발하는 것은 우선시 되어야 하는 게 맞지만, 그 후 시간이 된다면 복습하면서 이게 꼭 필요한 소스였을까? 너무 가져다 쓰진 않았을까? 대체제는 없을지 고민해 보자.

센스를 가지자

인사는 항상 밝고 적극적인 태도로 할수록 좋다. 상대방에게 좋은 인상을 심어주는 것이 중요하다고 생각한다.

출근시간에는 최소 10분 전에는 도착해서 앉아있자. 지각 안 하고 성실한 태도를 보여주는 것이 좋다. 

내 퇴근과 휴가는 내가 챙겨야 한다. 너무 눈치 보지 말고 일 없을 때 스스로 챙겨야 한다.

모르는 게 있으면 확실하게 물어본다. 지레짐작하다 엉뚱한 방향으로 굳혀질 수 있다. (기껏 코드를 짜놨는데 일을 두번해야 할 수도 있다)

다만 궁금한 게 생길 때마다 질문하지 말고, 충분한 고민을 하고 여러 질문을 모아서 질문하자.

맡은 일이 기간 내 불가능하다고 생각한다면, 구체적인 완료시간과 대안을 제시한다.

완벽주의는 버리자. 선개발 후개선을 하더라도 기간은 웬만하면 엄수해야 한다.

SI의 장점

SI 프로젝트의 장단점이 많지만, 내가 프로젝트에서 느낀 SI의 제일 큰 장점을 말해보자면 '계속 발전해 나갈 수 있는 것'이다.

이 프로젝트에서 팀장에게 질문하는 걸 잘하지 못했다면? 다음 프로젝트에서 질문을 시도해 보면 된다. 이번 프로젝트에서 상사에게 뒤통수를 몇 번 맞았다면? 다음 프로젝트에서 문서로 기록하는 걸 시도하면 된다. 이번 프로젝트에서 대충 코딩을 짰다면? 다음 프로젝트에서는 좀 더 나은 코드를 짜기 위해 노력하면 된다.

새로운 프로젝트에 들어갈 때마다, 새로운 마음으로 나 스스로를 조금씩 업그레이드시킨다는 마음으로 임할 수 있는 게 장점이라고 생각한다.

지금까지 내가 느꼈던 개발자 습관을 두서없이 적어봤다.