개발 문화

 

 

스스로에게 개발자로서 요구하는 자세가 있습니다

원하는 환경도 있구요(유토피아)

 

 

존재 안 할 수도

 

 

특히 코드 리뷰나 페어로 개발을 하다 보면 자연스레 개발 이상향이 그려집니다

- 이런 곳에서 일하고 싶다

- 이런 사람들과 일하고 싶다

 

 

이런 생각은 '이런 개발자가 되어야겠다'로 이어집니다

이게... 개발...?

 

---

만나본 개발자 유형

 

세상은 넓고 다양한 사람이 존재합니다

개발자도 당연히 다양한 개발자가 존재하고

이제껏 만나본 개발자들도 참으로 다양했습니다

 

 

[만나본 개발자 유형]

/*

- 외향적인 개발자(인싸형)

- Geek / Nerd형 개발자

- 특정 개발언어을 특히 좋아하는 개발자

- 한 분야에 아주 깊게 투자하려는 개발자

- 트렌드에 예민한 개발자 / 관심 없는 개발자

- 꼼꼼한 개발자 / 실수가 잦은 개발자

- 그림으로 표현을 잘하는 개발자

- 일정에 예민한 개발자

- 말로 설명을 잘하는 개발자

- 특정 개념을 특히 싫어하는 개발자

- 굉장히 예의 바르고 친절한 개발자

- 화가 많은 개발자

- 이론에 아주 능통한 개발자

- 불만이 많은 개발자(적절한 이유의)

- 깊진 않지만 이것저것 다양하게 사용해보는 개발자

- 개발이 너무 좋아 하루 종일 하는 개발자

- 협업보단 혼자 일하는 걸 좋아하는 개발자

- 목소리가 큰 개발자(고집이 강한)

*/

 

기계에 논리를 설계 / 구현하는 직업임에도

개성이 강하다는 게 참 재미있기도 합니다ㅋㅋ

 

 

다양한 개발자들이 모여 개발하는 환경과 분위기가 만들어지죠

상용 프로젝트에는 여기에 개발 외의 사람들이 더 추가됩니다

 

---

 

개발자들의 이상향

 

팀 분위기는 사실 수직적인 편이지만

회사 차원에서 수평적인 문화를 만들려고

약간의 노력은 하고 있습니다

(예를 들면 호칭을 모두 OO'님'으로 바꿔 버렸죠)

 

좋은 개발 분위기를 만드는 것은

회사차원에서 중요한 고민이기도 합니다

팀장/부장 직급의 주된 업무이기도 하지요

(문화를 '주도'하기에 좋은 위치이니)

 

하지만 당연히

 

원하는 개발 문화가 있으면

자기 자신이 그런 사람이 되는 것이 먼저라고 생각합니다

 

'나는 이런 개발자이고 싶다'

라는 생각이 들어 정리해봅니다

 

0. 항상 '왜'인지 설명할 수 있도록 하자

개발자라면 {왜?} 라는 것을 항상 되물어야 한다고 생각합니다

스스로 납득하고 남들에게 설명할 수 있어야 (속이 시원합니다)

비로소 이해했다라고 할 수 있다고 생각합니다

 

'그냥 그렇다', '원래 그렇다'는 용납할 수 없죠

'왜'에 집착하며 끝까지 직접 파보려는 정신이 개발자로서의 시작이며

협업의 기본입니다

 

1. 누군가 믿고 맡길 수 있는 사람이 되자

애자일은 각자 담당한 톱니바퀴를 협력적으로 완성하고 맞춰 나가는 일입니다

담당한 톱니바퀴의 완성이 늦을수록 애자일은 더욱더 비효율적인 방법론이 되어버립니다

 

적어도 나에게 맡기면

'어떻게든 결과는 가져오는구나'

'믿고 맡길 수 있겠다'

라는 생각이 드는 개발자가 되고 싶습니다

 

2. 쉽게 물어볼 수 있는 사람이 되자

일을 하다 보면 모르는 게 있고, 물어볼게 당연히 생깁니다

실제로 저나 동료들이나 특정 인물한테 자주 물어보게 되더라고요

- A. 굉장히 박식함(고수)

- B. 설명을 잘함

- C. 편함(친절해서)

A, B, C 모두 궁금한 걸 알고 있을 때

모르는 게 생겼을 때 물어보고 싶은 사람이 되는 건

자연스럽게 C가 되더라고요

 

물론 귀찮은 일일 수도 있고 설명을 반복하는걸 굉장히 싫어하는 사람도 있지만

알려주는 사람도 한번 더 되짚게 되니 서로 윈윈 한다고 생각합니다

 

저도 그런 사람이 되고 싶어 항상 친절하려고 노력하고 있습니다

(시스템팀에서 궁금한 게 생기면 제가 개발한 부분이 아니어도

저한테 조용히 먼저 물어보러 오면 꽤 뿌듯해집니다)

 

3. 개발/비개발 간에도 쉽게 의논할 수 있는 환경

한때 개발자들끼리만 모여서 일하는 게 당연하지 않나 생각했습니다

하지만 실제로 상용(Production) 업무에서는 꼭 그렇지 않더라고요

 

고려해야 할 점도 많고 의논하고 맞춰야 하는 부분이 많은데

대부분 메일로만 주고받으니 오해도 생기고 원활하게 진행되지 않습니다

 

실제로 발등에 불이 떨어졌을 때 해당 프로젝트 관련 인원들이

회의실에 모여 몇 주간 일을 한 적이 있습니다

PM, 사업팀, 시스템팀, 개발팀, QA팀 등이 같이 모여서 일한 건 처음이었는데

 

신기하게 굉장히 빠른 속도로 업무가 진행되더라고요

(단점으로는 장소가 협소하면 시끄럽고 집중하기 힘듦...)

(뭔가 스타트업 체험하는 느낌...)

 

물론 의견이 강한사람끼리 부딪히며 목소리가 커지는 불상사가 있기도 했지만

다들 프로젝트가 잘되길 바라는 마음은 같았다고 생각합니다

 

서로 전혀 모르는 분야지만

자세한 설명과 협의가 바로 가능하니

유연하고 빠르게 대처할 수 있었고

프로젝트의 전반적인 형태를 머릿속에 그릴 수 있었다는 점이 좋았습니다

(애자일의 원칙을 되새겨봅니다)

 

4. 쉽게 개발 협업할 수 있는 환경

저희 회사는 공간에 비해 사람이 많은 편이라

페어나 회의를 하기 참 쉽지 않은 환경이었습니다

 

자연스레 각자의 공간에서 개발을 하게 되는데

오해도 생기고 개발이 꽤 진행된 후에야 잘못된 걸 깨닫는 불상사도 일어났습니다

특히나 1번에서 얘기했듯이 서로 적극적인 자세로 협업한다면

가볍게라도 의견을 나누며 리뷰도 할 수 있고

협업의 장점을 극대화할 수 있습니다

(이 부분에 대해선 나중에 애자일 방법론 포스팅에서 자세히 말하고 싶네요!)

 

5. '모르면 알아오면 된다'라는 환경

당장 모르는 게 큰 문제는 아닙니다

 

물론 알아야 되는 건 머리에 넣어두는 게 좋겠지만

시간이 꽤 지나서 안 쓰게 되면 잊게 되거나

많은 양을 학습하거나 백업받게 되면 놓치는 부분이 있습니다

(사람이니까!)

 

모르는 쪽도 '모르겠다, 꼭 알아오겠다'라는 확실한 자세가 필요하고

요구하는 쪽도 상대가 기억할 수 있도록 유도하는 대화나

가볍게 설명할 수 있는 내용이면 설명해주는 자세가 좋다고 생각합니다

 

우물쭈물하거나 꾸짖는 쪽 둘 다 효율적이라고 생각하진 않습니다

개발자 이전에 사람대 사람이기 때문에 자신이 모르는걸

감추려 할 수 있으며 이런 분위기가 만들어지면

오히려 서로에게 해가 됩니다

 

6. 동료들과 자유롭게 자주 논의하라

사실 수평적인 문화와 직결되는 이야기 같습니다

IT, 개발은 특히나 다른 업종에 비해 분야가 넓고, 자료가 방대합니다

다들 관심분야는 조금씩 다르며 다른 정보를 갖고 있습니다

 

특히나 트렌드에 예민할 필요가 있기도 하며

누구보다도 의견교환이나 정보교환이 필요하고 중요하다고 생각합니다

환경적인 이유라던가, 관계적인 이유로 이런 장점을 놓친다면 큰 손해가 아닐 수 없습니다

 

스스로 그런 사람은 아니었는지 되짚어보고

말하기 편한 사람이 되도록 다짐해봅니다

 

7. 일정한 긴장감 유지하기

텐션을 유지하는 것은 성장과 직결되어 있습니다

개발자에게 텐션은 너무 없어도, 너무 높아도 문제라고 생각합니다

크게 스트레스받지 않는 선과 느슨해지지 않는 사이가 유지되어야

지치지 않고 노력하며 스스로 다듬을 수 있습니다

개발자라면 자신에게는 엄하고, 남에게는 관대하도록 합시다

 

8. 스케줄 관리

업무에 스케줄과 데드라인을 정하는 것은 적당한 텐션을 유지할 수 있습니다

또한, 일반적으로 MM을 산정하긴 하지만 개발이란 게

절대량이 정해져 있지 않아 스케줄 관리가 단순하진 않습니다

 

일정이란 것은 정말 다양한 문제들로 지연되곤 하지요

그럴 때 발생하는 피해를 최소화하려면 우선순위를 정하고

유연하게 스케줄을 변경하며 처리하는 게 좋습니다

 

툴을 사용하는 것도 좋습니다

저희 회사는 Confluence, JIRA를 통해 일정을 관리합니다

 

9. 모르는 것 / 배움에 대한 두려움을 없애라

모르면 배우면 됩니다

물론 쉽게 배울 수 있는 게 있는가 하면 배우는데 한참 걸리는 것들도 있습니다

(MONAD...)

 

하지만 개발자는 다른 어떤 직종들보다도 배움을 가까이해야 합니다

다른 사람의 스킬을 흡수하고 지적도 받아들일 수 있어야 하며

성장할 수 있습니다

 

트렌드와 상황에 맞춰

새로운 기술의 필요성과 의도를 파악하며 적극적으로 검토해볼 필요가 있습니다

(물론 Production 환경에서는 확실히 검증된 기술만 사용해야겠죠)

 

아마 영원히 공부해야 하는 직업이 아닐까 생각합니다

(누군가에겐 일거리, 누군가에겐 흥밋거리)

 

10. 완벽할 순 없다 필요한 순간 가져다 쓸 수 있을 정도로 익히기

사람은 언젠가 까먹습니다

1년 내내 쓰던 기술도 놓아두고,

다른 프로젝트 몇 개월 몇 년 하다 보면 기억이 가물가물해져요

저는 메모에 내용들을 정리를 해두려고 노력합니다

 

석사과정부터 이런저런 정보들을 구글에 메모해두었었는데

전문연으로 입사하고부터 맥북을 사용하니

맥북의 메모 기능을 열심히 활용하고 있습니다

 

기록하기도 편하고 찾기도 편합니다

꽤 많이 쌓였네요

 

이때 발생했던 문제, 명령어, 설명 등을 잘 메모해두면 후에 

크게 도움받는 경우가 많습니다

 

11. 일상에서도 효율적으로 움직이려 노력함

평소의 생각이나 생활도 효율적으로 바꿔봅시다

개발이란 것, 설계란 것은 효율적인 목표의 달성을 수행하기 위함입니다

문제를 해결하기 위해서는 문제 해결 능력 등의 능력이 요구되며

이는 개발과 마찬가지로 자주 겪을수록 향상됩니다

 

특별한 걸 말하는 건 아닙니다

하루 일정, 더 좋은 상품 구매, 목적지 도착 경로 등 일상에서도 고려할 것들이 많습니다

사소한 일도 빠르고 효율적인 수행을 목표로 삼아봅시다

 

우당탕탕 개발이란 말이 있듯이 많은 시행착오를 겪으면서 배우고 성장할 수 있습니다

평소에 이러한 사고방식을 담아두는 것이 업무 수행에도 도움이 됩니다

 

12. 변화에 유연하기

사실 제가 만나본 모든 개발자들은 트렌디합니다

굳이 옛날 기술이나 스택에 목매는 분을 본 적은 없어요

그만큼 개발자에겐 기본적인 마음가짐이라고 생각합니다

 

무작정 수용하고 교체하자는 이야기는 아니에요

업계는 빠르게 바뀌고 그 흐름 중 정확하게 이해할 수 있는 건 많지 않습니다

하지만 트렌드가 발생하는 데는 개연성이 있습니다

적어도 발생하게 된 계기, 필요성이 무엇인지는 파악해두면 커리어 향상과

기술 선택에 도움이 됩니다

(물론 상용에 사용하기 위해선 충분한 검증이 필수이며

사실 이러한 비용 때문에 변화하지 못하는 경우가 많죠)

 

요즘은 SNS, 커뮤니티, 트렌드 논문을 보는 것이 뉴스보다 더 도움이 되더라고요

 

13. 개발은 즐거우며 개발자로 일하는 것은 축복이다

다른 직종 친구 업무를 구경한 적이 있습니다

업무 자체가 문서작업(서류, 품의, 결제)에 굉장히 치중되어 있습니다

직종마다 다르겠지만 어찌 되었든...

사무직 중에 개발보다 재밌어 보이는 직종은 없더라고요

 

적성이 안 맞는 분들도 있겠지만 개발은 몰두할 수 있는 흥미로운 업무라는 것을 새겨봅니다

 

14. 다양한 사람을 접하라

요즘은 개발 스킬만 중요한 건 아니죠

'개발'에 깊게 파고드는 것도 중요하지만

주어진 과제만 수행하는 것이 개발의 전부는 아닙니다

 

개발/소비 트렌드는 빠르게 바뀌며 그에 맞춰 늘 새로운 아이템과 서비스가 나옵니다

이에 따라 개발 업무는 협업이 중요해지고 다양한 아이디어를 나누는 것이 중요해졌습니다

더 효과적인 개발 방법론과 협업의 중요성이 강조되는 것도 이 때문이죠

 

개발 업무에서도 사업/영업의 의도를 이해하는 것이 도움이 됩니다

 

개인적인 모임을 통해 다양한 사람들과 만나고 이야기를 나누는 것이

생각을 넓히고 커뮤니케이션 스킬을 더하는데 큰 도움이 됩니다

개발만으론 얻을 수 없는 것이죠

 

15. 지적을 기뻐하라

완벽한 것은 좋지만 인간은 항상 완벽할 순 없으며

세상엔 내가 생각하지 못한 좋은 선택이 존재할 수 있죠

 

지적이나 리뷰를 두려워하지 마라!

제일 크게 성장시킬 수 있는 과정이며(경험치 이벤트)

자신의 시간을 투자해 피드백해주는 이에게 감사를 표해야 합니다

 

왜 이렇게 하였는지, 이렇게 하면 안 되었는지,

이런 점은 이미 고려하였는지, 그렇게 하면 이런 문제가 있다든지

굉장히 영양가 있는 내용이 많아지죠

 

개인적으로 지금은 코드 리뷰가 별로 활성화되지 못한 상황이라 많이 아쉽네요

 

16. 오해로 발생하는 미스가 많으니 주의하자, 메일 등으로 다시 남겨두자 (간단명료가 좋다)

사실 개발과는 별개로 모든 업무에서 중요한 사항이네요

특히나 설명하거나 요구사항이 있는 쪽은 말로 설명하고,

해당 사항을 메일로 정리해서 다시 남겨두는 습관을 들이는 게

많은 문제를 굉장히 줄여줍니다

 

말로 설명하는 것은 빠른 의사소통과 결정을 돕지만

디테일, 정확도 측면으로는 약하며 오래 기억에 남지는 못해요

 

주요 사항을 메일로 한번 더 정리해서 오해가 없도록 합시다

---

[과거의 나]

/*

사실 회사에 다니기 이전, 석사 졸업까지 대학 연구실에서는

프로젝트 담당자들과 모여서

설계하고, 명세서를 작성하고, 역할 분담을 끝내면 끝!

자주 얘기하는 건 시간 낭비야, 설계대로 작성하면 합쳐서 잘 동작해야 해!

 

각자 맡은 개발과 납땜질에 집중하는 게

'개발자스럽다'라고 생각했습니다

 

'주간 회의 때 보고와 피드백만 하면 충분하지!'

 

업무를 하다 보니 생각이 바뀌었습니다

위에 얘기한 건 아주 기본적인 거고,

더 복잡하고 창의적인 업무일수록 잦은 의견 교환이 참 중요해집니다

특히 그 교환에는 배려와 겸손함이 기본 베이스로 있어야 합니다

 

사실 학생 때야말로 다양하고 창의적인 아이디어를 공유하기

제일 좋은 시절이었던 것을.. 아쉽네요

*/

 

 

프로젝트하다 보면 좋은 일, 나쁜 일, 이런저런 일이 있더라고요

확실히 문화라는 것과 환경을 만드는 것이 중요하다고 느끼게 되었습니다

개발자들 모두 화이팅입니다