~ 8/5 일 까지의 회고 (웅진 프로젝트 후기 등)

 

 

#글에 대한 반성 

 

퇴고는 정말 중요하다.

 

개인적으로 일상에서 사람들과 주고받는 문자나 말 같은 것 에는 

 

혹시 내 말에 가시 가 있어 상처를 줄까봐 , 의도하지 않았다 , 생각하지 않았다는 말로 나의 무지함이나 관계에 불성실함을 드러내 불쾌감을 주지않을까 싶은 생각과

 

 

개인적으로 가장 듣기 싫은 변명이기도 한 이미 다 저지르고 막대해놓고   

 

'사실 진짜 마음은 정말 널 사랑하고 좋아하는데...  ' 같은 말을 하면서 앞에서는 막대하는

 

앞뒤 행동과 매치되지 않은채  뒤에 덧붙이는 느낌의 변명을 하게 될까봐

 

실제 생활에서 문자를 쓰거나 대면해서 말하기 전에는 정말 많은 퇴고와 생각을 하는 편인데

 

블로그 글의 경우에는 상처 줄 직접적인 타인도 없겠다  한 큐에 막쓰는 감이 있지 않았나 싶다.

 

 

 

 

결국 초심의 태도로 반성하고 돌아가는것이다. 

 

그 동안 잠시 분량이나 양에 매몰되서 살았던 삶에서 이제 또 다시 양 질을 따지는 삶으로.

 

매일 같이 재 다짐하는 것만이 죽을때까지 그렇게 사는 유일한 방법이니  공자의 제자 안회 가 말했듯이 '이미 알고있는 좋은 것 을 다 실현하지도 못했는데 더 좋은것을 알게 될까봐 두렵다' 는 말을 그 동안 경외시 한 것은 아닌가 싶다  

 

나는 객관적으로 개발 쪽으로 아는 게 엄청 많은 편도 아니고 특별한 지위가 있는 사람도 아니다. 

 

하지만 그렇다고 해서 이제 완전 초기 입문할 때 처럼 단순 기록용 일기같은 

 

"오늘 HTML로 TABLE을 만들어보았다." 같은 회고를 쓸 시기 도 지났다. (참고로 지금은 비공개지만 처음 배울때 실제로 썼던 글이다 )

 

그러니 지금이니까 쓸 수 있는 글들을 솔직하게 계속 써내려 가보고자 한다

 

그리고 좀 더 재미있는 글을 위해 밑에도 나오는 이야기 이지만  그 동안 가능하면 개발관련 이슈가 아니면 내 일상과는 거의 완전 단절시켜놓은 글을 작성했는데 

 

그렇게 하다보니 결과적으로 글의 재미 요소라곤 온전히 이미지에 의존하게 되었다.

 

그러나 내가 이미지 짤을 모으는 수집가는 아닌지라.

 

글 자체의 재미? 인간성? 을 위해서라도 

 

앞으로는 조금 개발과 관련 없는 분야의 이야기나 사담도 섞어 볼 생각이다.

 

 

 

 

# 개발자로써의 나에 대한 단상 

 

늘 하는 생각이지만 기술 블로그 라고 표방 하고 있는 시점에서 어느정도로  개발을 기준으로 공과 사를 구별해서 작성해야 될지 모르겠다. 

 

나름 여지껏 깔끔하게 개발 관련 주제만 분리해서 글을 썼다고 생각하지만 

 

이번엔 조금 인간적인 이야기도 적어보려고한다. 

 

 

 

 

 

나는 독립적인 것을 좋아한다. 

 

나는 어려서 부터 혼자 있는 것을 좋아했다. 그 이유에 대해서 물론 나야  세세한 사건,생각 하나하나 정확히 알고있지만 간단히 추리자면 

 

혼자 있는 것을 추구하는 이유는  그게  ' 내 개성을 온전히 지키는 길' 이라고 생각했기때문이다.

 

그렇다고 해서 내가 사회생활이나 팀플에서 협조적이지 않았던 것은 아니다.

 

오히려 독립적인 것을 추구하는 이유는 내가 스스로 느끼기에 관계 속 에서 과하게 협조적이였기 때문이기도 하다.

 

함께있으면  거기에 맞춰 '부화뇌동' 한다고 느꼈기 때문에 나는 오히려 혼자 있기를 선호했던 것 같다.

 

내가 스스로 이런 사람 이라고 말하는 것 뿐 아니라 유명 심리 검사나 인적성 검사를 하면 늘 대인관계 능력이 항상 굉장히 높게 나오곤 했다. 

 

그래서 상담 선생님께 "저 근데 친구가 많이 있지 않은데요?"  (=없는데요) 라고 말하기도 했으나 상담 선생님 께서 말하시길 

 

"이 검사 항목에서 대인 관계 능력이 말하는 건 친구가 많고 적고를 말하는 것이 아니에요. 대인 관계속에서 자기가 어떻게 해야될지 어떻게 사람들과 잘 어울릴 수 있는 지에 대한 이해,행동 능력이 대인관계 능력이랍니다"

 

라고 말해주셨는데 어느정도 납득이 갔다.

 

 

 

 

 

그간 내가 스스로 정의한 독립적이라는것이 조금은 우물 안 개구리같은 어떤 편협한 정의가 아니였나 하고 생각했던 게 작년 말의 일이였다. 

 

<만일 내가 인생을 다시 산다면 >이라는 김해남님의 책을 읽고 있는 데 마치 니체의 책을 읽다가 망치로 두드려 맞은 듯한 깨달음이 있었다고 들 많이 표현하듯이 내 독립적임에 대한 정의를 재고해 볼 만한 문장이 있었다.

 

"독립과 고립은 다른 것  이다"

 

이 말이 나오기 까지 다른 이야기들이나 부차적인 설명들이 있지만 어찌되었건 내 게 큰 충격을 준 문장은 저 한 문장이였다. 

 

부차적인 설명들이나 말들에 동의하지 않는 부분도 있지만 이 문장 만큼은 내 인생을 되돌아보게 만들었다.

 

마침 이때 즈음에는 그 전에 <프로그래머의 길 멘토에게 묻다>라는 책도 읽은지 얼마 되지 않은 시기여서 여러모로 전에는 생각해본 적 없는 멘토라는 존재 에 대해서도 생각해보며 프로그래머로써의 여러가지 성장욕구와 겹쳐 더 많이 세상과 소통하고 성장하고 싶다는 욕구를 행동으로 옮겼다.

 

결과적 으로 스스로를 되돌아보고 여러 생각들이 맞물리면서 내 독립에 대한 정의와 행동방침은 조금 변화가 생긴 셈이다.

 

지금까지도 이미 개발외 분야 여러 곳 에서 일하면서 사람의 종류 자체는 별에 별 사람 많이 만나 봤지만. 

 

더 좋은 사람들과  함께 일하고싶고 그들과 섞이면서 더 많이 배우고싶다는 건전한 소망이 피어오른 건  이전에 없던 소망이였다. 

 

그리고 그보다 내가 먼저 더 괜찮은 사람이 되고싶다. 고 생각한다.

 

 이런 변화가 이전 보단 좀 더 건강한 개발자이자 건강한 사람으로 변한것 같아서 나는 지금 개발자로써의 내 마인드가 썩 나쁘지않게 느껴진다. 

 

함께하는 독립적인 사람.  지금은 그것이 내가 가고싶은 길이다 

 

 

 

 

#  팀 프로젝트 리더 

 

몰라

 

딱히 원하진 않았지만 기업 프로젝트의  팀 리더를 맡았다.

 

 

사다리 타기 같은 건 아니였고 자원해서 하긴 했는데  내 성격상 

 

1. 모두가 희망하지 않음

2. 특별히 저 사람이 했으면 좋겠다 싶은 사람이 없음 

 

이 두가지 사항이 동시충족된다면   차라리  자원 해서 분위기를 이끌어가는것도 나쁘지 않다고 생각하는 편이다. 

 

나는 개발 리딩을 해본 적도 없거니와 이번 프로젝트의 경우 개발 외적 으로도 해야하는 일이 명확하게 많아 보였다.

 

예를 들자면 팀 수당이 주어지는데 돈 관리도 팀장이 해야 됬고.

 

책임 이 전부 팀장 한테 몰려있었기 때문에  아예 손떼고 개발 하나만 할 수 없는 요건 이였다.

 

역할을 나눠도 결국 최종적으로 책임이 팀장에게 있다보니 관련 사항 들을 전부 알고있거나 확인하지 않으면 결국 불똥이 팀장에게 튈 운명이였다. 

 

그런 서사로 인해 단순 이벤트성 인원체크나 하는 바지 팀장 직책 이랑은 좀 거리가 멀어 보였고, 딱히 평소에 팀장에 대한 야망이 있어서 준비 해 온 것 도아니라  오히려 정말로 하기싫었다. 

 

 

 

 

보통 나는 팀장 이나 일반 조원 보단 팀장의 적극적 보좌를 희망하는 편이다.

 

요새는 안한지 오래 됬지만 이전에는 자원해서든 누가 추천해서든 할 사람이 없어서든 종종 '장' 을 해봤어서  '장' 이라는 것의 고충을 어느정도는 이해하는 편이다. 

 

그래서 일반 조원보단 열심히 적극적으로 보조하지만 팀장은 아닌 뭐 그런 정도의 역할이 내가 부담없이 열심히 할 수 있는 나랑 잘 맞는 역할이 아닌가 생각한다. 

 

어찌되었건, 뭔가의 역할이 주어지거나 하면 나는 성실하게 하는 편이기 때문에 

 

그렇게 나는 나대로 팀 리딩이라는 내 역할을 다하기 위해서 고민하고 다음의 시도들을 했다.

 

 

 

1. 생각 맞추기 작업 

 

생각을 맞추기 위해서 내가 주도한 활동은 두 가지 툴로 정리할 수 있을것같다. 

 

  1-1 ) 피그잼 

 

우리의 프로젝트는 웅진 씽크빅이라는 클라이언트가 존재했다.

 

생각보다 상세하게 프로젝트 제안서를 통해 기능에 대한 구체적인 예시 들도 있었음으로

 

나는 첫날 부터 테오의 스프린트에서 활용했던 피그잼을 팀원들에게 권유하며 다같이 모여서 비슷한 레퍼런스 조사와  부담없이 각자 말하는 분위기를 형성하여 기능 명세를 조금이나마 구체화하고 각자 둥둥 떠다니는 생각을 하나로 합 치고자했다.

 

동시에 노션 을 활용해서 간략하게 회의록을 정리하기도 했는데

 

노션을 통한 정리는 꼭 누굴 위해서라기보다 내가 그걸 하면서 더 명확해짐을 알고 , 문서화의 중요성을 알기에 한 일이였다. 

 

노션 정리는 나만 한 건 아니고 다른 팀원들도 적극 활용해주어서 좀 더 참고하고 다음 회의나 멘토링에도 도움이되었다.

 

이런 상황을 방지하기 위한 작업

 

  1- 2 ) Vs코드 Live Share

 

사실 원래 라이브 쉐어 기능으로 내가 하려고 했던 건  '페어 프로그래밍'  이였으나 이걸로 생각 맞추는 작업 역시 함께 진행했다. 

 

첫 주에 처음으로 작업범위를 나누고 작업한 컴포넌트들을 전부 각각 리뷰하고 머지 -> 풀 받아서 다같이 최신화 한다음에 

 

라이브 쉐어로

 

각각의 컴포넌트를 붙여 보면서 내가 의도한 게 아니라 상대방이 어떻게 이해하고 사용하는지 그리고 사용법은 어떻게 되는지 어떻게 설계했는지 어떻게 동작하는지 함께 확인하고 질문하며 좀 더 명확하게 모두의 생각을 일체화 하는 작업을 진행 했는데. 

 

이 작업은 사실 코드만 보고 안해도 되는 작업이라면 안해도 되는 작업이였으나

팀 내에 명확한 레벨 차이가 있어서 부담스러워하는 분들도 있었고 하면 좋은 작업임에는 틀림없었기에 진행했다. 

 

각자의 역량에 맡기기 보다는 이런 식의 공동 회의나 시연을 진행해서 마일스톤의 끝  지점마다  생각을 맞추고  명확히 해놔야 개발하는 데 이해가 뒤쳐지거나 ' 아 뭔소리야...' , ' 다음 개발이 부담스럽다..'. 하는 생각도 줄일 수 있다고 생각했기에 모두가 좀 더 몰입도 있게 개발 했으면 좋겠다는 생각하에 진행했다. 

 

사실 코드 리뷰도 하자고 주도하고 내가 먼저 리뷰 하기도 했으나 다들 리뷰하기 꺼려하는 분위기였다.

왜 꺼려하는지 나는 잘 알기 때문에 공개적이고 좀 더 명시적이게 다 같이 한 시연작업이 더욱 의미가 있었다고 생각한다. 

요약하자면 코드리뷰 대신에 라이브쉐어로 다같이 모여서 각자의 코드를 설명하고 이해하는 시간을 가졌다.  

 

 

근데 시연 및 설명 발표 작업은 그동안의 팀 프로젝트에선 안했던 작업이고그냥 내가 생각해서 한 일이라서 사실 현업에서도 이런식의 프로세스가 중간에 껴있는지는 잘 모르겠다. 

 

여담이지만 이날 나는 라이브 쉐어 기능을 처음 썼는데 정말 신세계였다.

(그 전엔 그냥 화면 공유로 페어 프로그래밍 했음)  

 

 

2. 작업 범위, 프로젝트 에서 사용할 기술 설정 

 

1.에서 했던 생각 맞추기 작업을 토대로 

프로젝트에서 어떤 기술을 사용 해야 될지 어떻게 분담해야되고 어떤 부분을 해야될지 같이 고민 하였는데 

 

내가 여기서 주로 한 시도랄건 없었고 적어도 기술을 설정하는 데 있어서 팀원들을 설득할때에 그 기술의 사용 이유를 설명하려고 노력했다.

 

일일이 레퍼런스를 다 뒤져보고 하진 않았고

 

우리 프로젝트는 ui 변경 로직이 많을것으로 예상되니 'js in css 방식을 사용하자'  고 먼저 제안하고 동의하면 => emotion 과 styled-component가 있는데 뭐가 좋을까? => 팀원들과 자료공유 => 그러한 이유로 styled-component로 가자 이런 형식이였다. 

 

Next js를 사용한 건 사실 나중에 로그인 회원가입이나  서버 를 따로 안만들고 한 번에 개발할 것 까지 상정해서 확장성을 고려해서 사용하자고 했는데 팀에서 다들 Next.js를안해봐서 부담스러워 했으나 설득 끝에 납득해줬다. 

 

 

3. 주도 하여 적용하려고 했던 팀 문화 

 

 

그동안 봐왔던 좋아 보이는 것들 , 있었으면 좋겠다 싶은 것들은 거의 다 적용하면서 괜찮은 개발 문화를 형성해보려 노력했다.

 

구체적으로는

 

1. 이슈,PR 템플릿 생성 

2. 자료 공유

3. 코드 리뷰 

4. 위에서 언급한 라이브 쉐어와 피그잼 

5.회고

등등이 있다. 

 

 

그 밖에 팀원이 제안해줘서 깃헙에서 칸반 보드를 만들고 일정 공유를 하기도했는데

 

개인적으로는 트렐로랑 비슷한게 깃헙으로 한번에 관리가 되는게 신기하여 

 

이슈랑 연결시켜서 관리할 수 있도록 여러번 리마인드하고 유도 하기도했다. 

 

 

 

4. 끝으로...

 

사실 그동안 혼자 프로젝트를 해왔기때문에 이슈를 통해 프로젝트를 관리하기도 하고, 모든 게 안 해본 다 도전이였다.  

 

 

개인적으로 어느정도 강단있고 팀을 이끌어가는  리더로써의 부드럽지만 카리스마 있는 덕목 이나 역량 을 갖춘 사람이 리더를 했으면 좋겠다고 생각하는데  어찌됬건 나는 그런 부류의 사람은 아니었다. 

 

그리고 나스스로 애송이 에 불과하다는 사실을 늘 되새기는 편이기 때문에  뭣 모르는데에서  올법 한 무지의 만용이나 빈수레가 요란한 자신감 같은걸 경계하려고 하는 편인지라 

 

'사실 팀원들이 이렇게 좀 더 해줬으면 좋겠다'는 바램이 생길때마다 '나는 이전에 어땠었나 ?' 를 생각해보며 굳이 입밖에 내지는 않았다. 

 

팀원들은 팀장역할 잘 해주셔서 고맙다고 하는데 솔직히 빈말인지 잘 판단이 안선다. 

왜냐면 내 생각에는 내 진행이 썩 쓰무스하지 않아서 별로라고 느꼈기 였기때문이다. 

 

 

이번 자동화 레이아웃 시스템 개발에 대한  개발에 관한 생각이나 진행사항은 아직 끝나지 않은 관계로 끝나고 나서 다시 한번 따로 정리할 생각이다.

 

개발에 관해서만 집중할 수 없어 여러가지로 힘빠지는 상황이 많았어서 개인적으로 조금 아쉬웠다. 

 

 

 

설계 

 

뭣 모르고 혼자 부숴져보면서 설계! 설계!(우가우가) 라고 말하던 내가 우테코부터 테오스프린트나 강의, 내 프로젝트 등을 통해서 더욱 설계지향적이고 테스트 코드와 함께하는 내가 되어가고있는것을 느꼈다. 

 

기능 구현 목록을 작성하고 UX를 고려하고 어떻게하면 유저한테 명시적으로 지금 하고있는 부분에 대해서 잘 느끼게 할 수있을까 같은 고민을 담아낼 수 있게 되기 시작했다. 물론 이건 진행하고있던 프로젝트 특성상 좀 더 드러나기도 했다고 생각은한다. 

 

이벤트의 위임 같은 부분들도 생각하고 고려하면서 문서로 어디를 눌렀을때 뭐가 어떻게 동작하고 어떤 기능이 발생하는 지 명세를 생각하며 , 이런부분들은 공부가 필요하겠다 싶은 부분은 직접 블로그에 정리하여 다시 만드는 작업또한 진행되어서 이런 부분들에서도 발전이 있었다고 스스로 평가하고싶다. 

 

 

 

# SQL 

 

select , from , where

 

사실 한달에 거의 한 번 정도 적는 회고글이지만 모든것을 담아 내고는 있지않은데 , 요번 년도 중반기 였을까? 프로그래머스 인턴 코스에 지원했을때 SQL 문제도 있다는 것을 알게된 것과 , 풀스택 개인 프로젝트로 시작된 sql과의 만남,  headless cms인 sanity 의 모양새가 sql을 닮아있는 것을 보며 나는  sql을 어느정도 할 줄아는 개발자가 되고싶었다.

 

그래서 6월 말 부터 sql을 조금씩 배우고 있었는데 한 50% 정도 들은것같다.   개인적으로 SQL 은 되게 명확해서 아직까진 쿼리문 작성하는게  재미있다.  

 

 

 

 

 

그 밖에도 클린코드나 객체지향에 관한 연습, 읽고있는 도서도 늘어났지만 아직 뭐라고 할 정도는 아닌지라... 글에담지는 않았다