김민혁

김민혁님의 아티클

김민혁

김민혁

나는 아직도 협업이 어렵다...!

그냥 함께 일하는 것이 아닌, 함께 최대한의 시너지를 내는 것

이렇게 나는 협업을 정의했다.

무엇이 협업인지는 인지했으나, 어떻게 협업을 할 것인지는 매 프로젝트마다 달랐다.

매번 다른 성격을 가진 사람들, 다른 능력을 가진 사람들, 다른 열정을 가진 사람들.

매번 다른 내용의 프로젝트, 다른 상황들.

이 '다름'에 익숙해지고 잘 협업을 하기란 정말 어려웠고, 지금도 어렵다.

나조차도 매번 다른 내용의 프로젝트 이기에 다른 능력과 열정으로 프로젝트에 임하는데, 같은 사람과 일을 한다고 해서 똑같은 방식으로 협업한다면 실패할 가능성이 높다.

매번 다르기에 협업에서 가장 중요했던 것은 '투명한 공유' 라고 생각한다.
성격이 어떤지, 어떤 능력 치를 가지고 있는지, 얼만큼의 열정을 쏟을 수 있는지 등을 서로 공유하는 것으로 시작해야, 어떻게 협업할 것인지 파악할 수 있기 때문이다.

투명한 공유가 이루어지지 않고 협업을 시작한다면, 협업을 하는 도중에 투명한 공유가 이루어지지 않는다면,

'쟤는 왜 저래?', '나만 일 하는건가?' 등 사소한 갈등과 의문이 각자의 머릿속에 하나 둘 떠오르게 될 것이다.

결국, 투명한 공유가 되지 않으면, 신뢰도 떨어질 뿐더러, 점차 모든 팀원이 지쳐가는 상황에까지 이를 수 있다.

이전에 있었던, 나의 프로젝트 경험을 예로 들자면,

유독 나와 의견이 많이 부딪히는 사람이 있었다. 그래서 나는 못된 마음으로 그 사람이 말하면 더 반박하고 싶었고, 다시는 같이 일 하고싶지 않다는 생각까지 들었다. 결국 프로젝트는 산으로 갔고, 완성하지 못한 채 흐지부지 되었다.

그때를 생각하면, 다시는 그렇게 일 하고싶지 않다. 많은 지나고나서 그 사람과 대화할 기회가 생겼는데, 우리는 그때 일했던 기억을 이야기했다.

우리는 그때의 감정과 생각을 서로 공유했고, 어떠한 마음으로 프로젝트를 임했는지 나누었다. 그래서 그 사람에 대해 평소에 어떠한 말투로 소통을 하는지, 궁금한 것이 있으면 끝까지 물고 늘어져서 질문하는 성격 등등 에 대해서 알 수 있었다.

이러한 것들을 알고 그때로 돌아간다면, 나는 절대로 잘못 생각하고 행동하지 않았을거라 생각한다. 프로젝트 또한 더 원활하게 진행될 수 있지 않았을까?

그 사람도 마음이 어려웠을 텐데, 나는 이 대화가 정말로 고맙고 소중한 시간이었다고 생각했다.

투명한 공유, 협업을 할 때에 영향이 가는 모든 것에 대한 공유가 중요하다. 나에 대한 공유 뿐만 아니라, 상대방에게 좋지 않은 의문점이 든다면, 말을 좋게 바꾸어서라도 상대방이 어떤 생각을 하고 있는 것인지 공유받는 것이 중요하다.

그러나, 나도 아직 이것이 어렵다. 그래서 협업이 어렵다.

잘 되진 않지만, 노력하자는 다짐을 하고자 끄적여보았다.

8
0
김민혁

김민혁

해야한다면, 다 하게 되더라.

지난 3년간 내가 성장할 수 있었던 가장 큰 마음가짐 이었던 것 같다.

해야한다면, 다 하게 되더라.


전역 후 앱개발자가 되겠다고 다짐하고 난 후 개인, 팀 단위의 프로젝트를 시작할 때마다

사소한 부분부터 큰 부분까지 정말 막막하고 벅차보일 때가 많았다.

다 처음 해보는 일이기 때문이다.

매번 새로운 것을 경험하고 싶었다.

안드로이드, 크로스플랫폼, iOS 개발을 거쳐오면서,

하나만 팔걸, 후회가 되는 부분도 있고, 새로운 것에 지친 적도 있었지만,

그때마다 프로젝트를 완수하기 위해 나에게 많이 외쳤던 것 같다.

“해야한다면, 다 하게 되더라”

내가 벌린 일, 내가 결심한 일이기에 해야했다.

그런데, 돌이켜보면 “해야한다.” 라고 나에게 줬던 압박이

언제나 처럼 내가 생각한 나의 한계를 넘게 해주고,

“다 하게 되더라.” 라고 나에게 줬던 용기가

계속해서 나를 나아가게 했던 것 같다.

지금도 “PARD”라는 동아리의 운영팀으로 있으면서,

프로그램의 기획에 대해서 생각하고, 여러 서류를 작성하고,

아직 부족하지만, 해야할 일을 스스로 찾아야하고,

4년 내내 코딩만 했던 감자에게는 모든 것이 새로운 일이고 도전이다.

내게 맡겨진 일이 생전 처음해보고 겁도 나고, 때론 너무 많더라도

그것 때문에 스트레스 받으면 끝도 없다.

해보지도 않고 겁만 먹으면, 아무것도 못하기 때문이다.

내게 맡겨진 책임감을 위해, 나의 성장을 위해

해야하니까, 해보자. 어차피 다 하게 되니까.

8
3
김민혁

김민혁

아무것도 할 수 없다는 막막함

안녕하세요 포항시 IT 협업 동아리 PARD 3기 iOS파트 김민혁입니다.

지난주 금, 토요일 간 진행된 동아리 내 무박 2일의 해커톤. 일명 숏커톤에 참여하게 되었습니다.

저에게는 1기와 더불어 두번째 숏커톤 참여였는데요. 그때와는 또다른 경험을 할 수 있었습니다.

사실상 이번 숏커톤에서는 저는 제가 할 수 있었던 것이 거의 없었습니다.

그 이유는 제 맥북의 Xcode의 iOS 버전이 팀원들과 맞지 않았고,

제가 가진 MacOS의 버전이 해당 버전을 지원하지 않아서 OS를 업그레이드 하고, Xcode까지 업그레이드 하기 위해서는 많은 시간이 소요될 것이라 판단 되었기 때문입니다.

1기 때에는 몇일 전 어느정도 팀원이 누구인지 파악이 가능했기에, 숏커톤 전 팀원들과 버전을 맞추고, 코드스타일 및 파일구조, git 사용 등에 대한 것들을 어느 정도 align 할 수가 있었지만, 이번에는 팀원의 정보를 숏커톤 시작 전까지 알 수가 없었기에 이러한 것들을 미리 맞춰 놓을 수가 없었습니다.

저는 절망했습니다. 1기보다 더 성장한 모습으로 더 많은 자신감을 가지고 시작했고, 여러 UI 프레임워크들을 사용해 봄으로써 생긴 자신감으로 인해, 기획단계에서 나오는 어떠한 아이디어든 다 해낼 수 있다고 믿고 있었기 때문입니다. 몰라서 못하는 것보다 아는데 하지 못한다는 점이 저에게는 너무나도 큰 절망감을 주었습니다...

아무튼!!

기획 단계, 개발 첫단계에서의 이러한 상황들로 인해서 제가 개발을 시작할 수 있었던 시간은 새벽 2시가 조금 넘은 시각부터였습니다. OS를 업그레이드 하는 부분은 포기를 했고, 다른 버전의 프로젝트이기에 당연히 팀원들과 동일한 github repository를 사용하는 것또한 포기할 수 밖에 없었습니다.

저는 팀원들에게 너무나도 미안했지만, "어쩔수 없다. 할 수 있는 것이라도 하자"라는 마음으로 제 개인 프로젝트를 만들어서 제 코드를 공유하여 팀원들이 복사 붙여넣기 하는 식으로라도 참여를 할 수가 있었습니다.

결과적으로는, 우리팀은 프로덕트를 완벽히 완성할 수 없었습니다. 모든 사람이 1인분의 역할을 하더라도 좋은 프로덕트를 완성하는 것이 쉽지 않은 일이며, 저는 1인분의 역할을 하지 못했기 때문입니다. 이번 경험을 통해서 저는 경험의 부족에 대해 깨달을 수 있었습니다. 처음 겪는 어려움에 당황하여서 어떻게 해결해야할 지 판단하는 능력이 흐려졌고, 그것은 바로 무의미한 시간의 소비와 이어졌습니다. 4학년인 저는 아직도 습득해야할 지식이 많지만, 현업에 들어가기 전, 더 다양한 경험을 해야할 필요성을 느낄 수 있었습니다.

짧은 제 회고 및 푸념글 읽어주셔서 감사합니다.

11
0
김민혁

김민혁

개발자의 협업 🗒️코드 컨벤션

안녕하세요 Pard 1기 앱파트, 3기 iOS 김민혁입니다.

Pard는 협업이라는 키워드를 목표로 삼고 달려가고 있는 동아리입니다.

제가 이때까지 경험한 Pard는 나와 다른 분야의 학생들과 협업을 경험하기에 너무나도 좋은 기회이며, 그렇기에 다른 분야의 사람들이 어떠한 방식으로 생각하고, 또, 그들의 어려움은 무엇인지 많은 것을 배울 수 있었습니다.

그러나, 다른 분야와 협업을 하기에 앞서 하나의 프로젝트에는 여러 개발자가 참여하게 됨으로, 다른 분야 뿐만아니라 개발자 끼리도 협업을 잘하는 것이 중요합니다.

그래서 오늘 가져온 것은 코드 컨벤션에 관한 것입니다. 물론, 다른 여러 프로젝트나, 산학 프로젝트를 하고 있는 우리 Pard의 Pardy, Pardo들은 익히 알고 있겠지만, 아직 그렇지 못해 처음 협업을 할 개발자들(Pard 이외에도)이 코드컨벤션에 대하여 알았으면 좋겠다 하는 마음에 글을 작성해 봅니다...

코드 컨벤션이란,

코드를 읽고 이해하기 쉽게 하기 위한 개발자들의 코딩 스타일 규약입니다.

  1. 파일구조 및 파일 네이밍규칙

  2. import 규칙 (ex: 알파벳 순)

  3. 변수 네이밍 및 정의방법 (swift의 경우 let variable: type = value or let variable : type = value)

  4. 괄호, 들여쓰기, 줄바꿈, 공백 규칙

  5. 파일 구조, 변수 외 패키지, 클래스, 함수, 파라미터, 상수 등의 네이밍 규칙

이 외에도 많은 것들에 대한 규약이 포함되어 있는 문서를 뜻합니다.

코드 컨벤션이 중요한 이유

코드 컨벤션의 목표는 개발자가 '서로의 코드를 읽고 이해하기 쉽게 하자'입니다. 모두가 같은 스타일로 코드를 작성하기에 다른 사람의 코드를 더 이해하기 쉽고 이로써 불필요하게 시간을 들여 코드를 이해하는 일을 줄일 수가 있습니다.

파일명을 예로 들자면, 내가 productListView 와 같은 형식으로 파일명을 작성했는데, 같은 상황에서 다른 사람은 ListProductView와 같은 형식으로 작성을 한다고 하면, 나는 productListView에 해당하는 파일을 찾기 위해서 가장 앞의 글자인 p를 기준으로 파일을 찾기 시작할 것입니다. 또한 폴더 안의 파일들의 이름이 대소문자 가리지 않고 뒤죽박죽 이라면 정리되지 않은 느낌도 있으면서 일관성도 없을 것입니다.

이미 회사에 종사하시고 있는 분들께서는 물론 코드 컨벤션을 많이들 이용하고 계시겠지만, 디스콰이엇을 이용하고 있으신 많은 미래의 개발자 분들께서 코드 컨벤션에 대한 중요성을 아시고, 경험하시고 익숙해 질 수 있으시면 좋겠다는 마음이 이 글을 작성하게 되었습니다.

개발자의 협업에는 github와 같은 좋은 tool들이 있지만, 기획단계의 기본, 상세 설계서와 같은 산출물들 처럼 개발자들의 협업을 위해 이러한 약속들이 얼마나 중요한지를 느끼고 회고하게 되었습니다. 비록 자신의 코드가 훌륭하고, 깔끔하더라도 자만하지 않고, 협업을 잘하는 개발자로 함꼐 성장했으면 좋겠습니다.

사실 제가 적은 코드 컨벤션의 장점은 학생의 기준으로 작성된 것이지만, 저의 짧은 생각으로는 코드 컨벤션의 문서화에 대해 회사의 입장으로는 코드의 일관성으로 유지보수의 측면이 클 것이라 생각됩니다. 그러나 그보다도, 학생인 제가 생각하기로 코드 컨벤션은 개발자가 협업하기 위한 가장 첫번째 순서라고 생각합니다. 그저 말로만 하는 간단한 약속은 코드를 작성하면서 아차 하는 순간에 잊을 수 있으므로 협업읋 하는 학생 개발자들도 네이밍 규칙 및, 파일 구조와 같은 간단한 규칙이라도 코드 컨벤션으로 문서화 하여 개발자의 협업을 경험하며 함께 성장했으면 하는 바람입니다.

비록 코드 컨벤션에 대한 설명은 짧을 수 있겠지만, 익히 많이 알려진 것이므로 검색하시면 많은 정보들을 찾을 수 있을 것입니다. 협업에서 필수적으로 사용되는 것인줄은 압니다만, 학생의 차원에서 많이 경험할 수 없다는 생각에 이렇게 글을 작성해 보았습니다.

읽어 주셔서 감사합니다:)

+. To developers in Pard, 숏커톤과 롱커톤 전 모인 개발자들이 이 코드 컨벤션에 대해서 한번 더 기억하며 간단한 문서로 정리하며 서로 약속을 문서화했으며 하며, 이로인해 더 좋은 협업을 할 수 있으시길 바랍니다. 또한, 우리 Pard에서 추구하는 협업을 힘껏 느끼셨으면 좋겠습니다.

11
0
김민혁

김민혁

🙊ChatGPT보단 재탕🙉

안녕하세요 1기 앱파트, 3기 iOS파트 김민혁입니다.

재탕

1. 한 번 달여 먹은 한약재를 두 번째 달이는 것. 재전(再煎).

2. 이미 써먹은 것을 다시 이용하는 일을 야유조로 이르는 말.

흔히 재탕이란 말은 안좋은 의미로 사용될 때가 많습니다. 그러나, 코딩에 대해서는 이 재탕이 그렇게 좋을 수가 없습니다.

수많은 생성형 AI의 등장으로 코드를 더 쉽게 만들 수 있게 된 것은 사실입니다. 이로 인해 더 빠른 Product들을 생산할 수 있게 되었고, 이러한 AI들의 이점을 무시할 수 없는 것은 사실입니다.

그러나, 코드를 짜거나 오류가 생길 때 무작정 Instruction이나 에러를 Prompt에 옮겨 적고 있지는 않나요? 어느새 AI에 의존하고 있는 나 자신을 발견하며 개발자로서 실력에 대한 불안함을 느끼지는 않나요?

1기 숏커톤, 롱커톤, 그리고 다른 다양한 프로젝트를 하면서 느낀 것은 "재사용" 할 수 있는 코드를 만들어야 한다는 것이었습니다. 그 이유는 다음과 같습니다.

  1. 내가 다 아는 것이라도 처음부터 만들어야 하기에 불필요한 시간이 소요된다.

  2. 새로 만들게 됨으로써 새로이 생기는 에러를 감당해야한다.

  3. 머리 속에 있는 Logic을 다시 꺼내오려면 더 많은 시간이 걸린다.

  4. 시간을 줄이기 위해 AI를 사용하다보면 코드가 더러워지고, 협업에 좋지 않다.

  5. 같은 이유로 AI를 사용하게 되면 제공된 코드를 이해하고 적용하는 것에 더 시간이 소요된다.

등등 다양한 이유로 a.k.a. 재탕 코드의 필요성을 크게 느낄 수 있었습니다. Pard에서는 모든 기수가 숏커톤, 롱커톤을 겪게 되는데, 한 학기라는 짧은 시간에 새로운 프레임워크를 배우며 성장하는 개발자들은 이 재탕코드가 큰 경쟁력을 가질 수 있을거라 생각합니다.

모든 프로젝트는 제한된 시간 안에서 이루어집니다. 그러나, 재탕 코드를 통해서 불필요한 시간을 줄일 수 있고, 한번 깔끔한 코드를 만들어 놓았다면 큰 노력을 들이지 않고도 깔끔한 코드를 만들어 낼 수 있을 것입니다. 그래서 저는 "재탕 코드 아카이빙"을 통해 쓸데 없는 prompt를 줄이고 빠르고 이해가 쉬운 저의 코드를 더 사용할 수 있도록 노력할 생각입니다.

짧은 글 읽어주셔서 감사합니다.

모두들 에러없는 나만의 재탕코드 아카이빙을 통해 경쟁력 있는 개발자가 되시길 바랍니다.

Pard 화이팅. Pard 개발자 화이팅. Pard iOS 화이팅.🐵

10
2
김민혁

김민혁

ChatGPT가 만들어 준 text 활용에 대한 표절문제를 다루어 보아요 :)

이 글은 교내 AI 프로젝트 입문 강의 수강 중 “ChatGPT가 만들어 준 text를 활용한 경우 표절일까?” 에 대한 주제로 토론을 준비하면서 기록을 남기지 않는 것이 아쉬워서 작성하게 되었다.


사실 나는 반대의 입장으로 참여하게 된 이후 찬성의 입장으로 바꾸고 싶었다. 인간의 양심이나, 창작물에 대해 매우 가치있다고 생각하기 때문이다. 그러나, 나는 반대입장에 대한 근거를 찾아야 했고, 이에 대해 정리한 글을 써보려 한다.

(반대의 입장으로 토론을 해야했다는 상황아래 이 글을 보는 분들이 비난이나 불편하지 않았으면 하는 마음이다.)


먼저, 우리나라서의 표절에 대한 정의와 성립 요건을 찾아보았다.


“표절” 이란 타인의 창작물의 전부 또는 일부를 자신의 창작물로 허락 없이 사용하여 자신의 이름으로 작품을 공표하는 것을 말한다.


[표절 성립 요건]

  1. 침해자가 저작자의 저작물을 이용하였을 것, 즉 창작적 표현을 복제하였을 것
  2. 침해자가 저작자의 저작물에 의거하여 이를 이용하였을 것
  3. 저작자의 저작물과 침해자의 저작물 사이에 실질적 유사성이 있을 것

출처 https://easylaw.go.kr/CSP/OnhunqueansInfoRetrieve.laf?onhunqnaAstSeq=87&onhunqueSeq=3667


표절의 정의를 보면 가장 먼저 ‘타인’이라는 말이 있다. 그러나, ChatGPT는 인간이 아니며, 텍스트 생성을 위해 훈련된 인공지능 모델에 불과하다. 또한 chatGPT 는 사용자와의 대화를 통해 text를 만들어 가는 것이기 때문에 타인의 창작물이라고 정의하기에는 그 기준이 모호하다. 또한, 그 주체가 인간이 아니기에 데이터를 분석하고 조합한 결과물이므로 그 안에 감정이나 사상이 들어 있는 것도 아니다. ‘허락’이라는 단어도 마찬가지이다. 만들어진 text를 사용하기에 표절을 피하기 위해 허락을 받아야하는데, 그 대상이 인공지능이라는 점에서 그 능력이 없다. 그러므로 ChatGPT가 만들어준 text를 활용하는 것은 표절의 정의와 모순이다.

성립요건도 마찬가지이다.


  1. 창작적 표현의 복제가 아니다. ChatGPT는 텍스트 데이터를 학습하여 새로운 텍스트를 생성하는 인공지능 모델이다. 생성한 텍스트는 기존의 텍스트를 직접적으로 복제한 것이 아니라, 다양한 아이디어와 문장의 조합을 통해 새롭게 생성된 것이다. 또한 위에서 설명한 것과 같이 이 창작물은 인공지능과 사용자로부터 나온 것임으로 더 주체성이 있는 사용자에게 더 권한이 있다고 본다.
  2. 원작자의 저작물에 의거하지 않는다. 1번과 마찬가지로 ChatGPT는 다양한 데이터 세트에서 학습되었으며, 따라서 특정한 저작자의 저작물을 직접적으로 의존하지 않는다. 또한 다양한 소스에서 얻은 정보와 아이디어의 조합으로 이루어져 있으며, 특정 저작자의 저작물에 대한 의존성이 없다. 예를 들어서 우리도 리포트를 쓸 때, 수많은 자료를 인터넷으로 부터 서치할 때가 있는데, 이로부터 학습한 것을 바탕으로 자신의 생각을 작성한다면 표절이라고 할 수 없다.
  3. 실질적인 유사성이 없다. ChatGPT는 물론 텍스트의 패턴과 구조를 학습하고 재현할 수 있지만, 사용자가 ChatGPT를 어떻게 사용하느냐에 따라 그 구조가 정확히 일치 하지 않을 것이다. 오히려 사용자의 텍스트 패턴과 구조에 더 맞춰질 것이다.

우리나라뿐 아니라, 다른 여러 나라에서도 인공지능이나 기계 등 사람이 아닌 것들에 대한 저작권을 인정하지 않고 있다.

인공지능은 아니지만 동물에 관한 저작권문제의 사례로는,

원숭이가 자신을 찍은 사진의 경우 저작권이 문제가 된 일이 있다. 영국의 사진작가 데이비드 슬레이터는 2011년 인도네시아 술라웨시섬의 정글을 돌아다니며 ‘검정 짧은 꼬리 원숭이’ 사진을 찍었는데, 잠시 카메라를 내려 놓은 사이에 한 마리가 그의 카메라를 낚아채어 갔다. 얼마 후 사진기를 되 찾았는데, 원숭이가 자신을 찍은 사진이 있었고 그 사진을 팔아 수입을 올릴 수 있었다. 그러나, 2014년 1월 이 사진이 위키 미디어에 공개되어 있다는 사실을 알게 되고, 내려달라고 요청했으나 거절 당했다. 이 문제에 대해 미국 저작권청은 위 사진에 대해 저작권을 인정해 주지 않았으며, 샌프란시스코 미국연방지방법원도 같은 판결을 내렸다. 그 이유는 저작권은 사람이 만든 창작물에만 주어진다는 것이였다.

출처 http://daemun.or.kr/?p=1808


이처럼 저작권에 대한 문제는 그 주체가 누구인지가 매우 중요하다. 권한이기 때문이다. 저작권 문제를 다루기 위해서는 그 주체가 권한을 행사하기에 알맞은 존재인가에 대해서 생각해 볼 필요가 있다.

13
1
김민혁

김민혁

첫걸음이 중요한거니까 - PARD 숏커톤 회고

[숏커톤 전]

우리 조는 처음부터 되게 잘 맞았다. 모두가 서로의 의견에 귀를 기울였으며, 의욕이 타올랐다. 비록 서로의 시간이 맞지 않아서 숏커톤 전 평일에 대면으로 모두가 만나지는 못했지만, ZOOM 화상회의로 새벽 1시에 모임을 가지고 기획 디자인 파트 별로 따로 만나고, 개발 디자인 별로도 따로 더 만나면서 서로의 싱크를 맞추기 위해서 부단히 노력했다. 그래서 숏커톤 전에도 상당히 많은 것을 배울 수 있었다. 숏커톤 1주일전 파드에서 타임 어택으로 프로그램을 수행하며, 시간의 중요성과 효율적 판단의 중요성을 깨닫을 수 있었으며, 서로 수긍만 하는 팀이 좋은 것이 아니라, 반대되는 의견이 있으면 바로 바로 소통할 수 있는 분위기의 팀이 좋은 팀이라는 것을 느꼈다. 또한 의견은 주관적인 것이므로 객관적인 것으로 서로의 의견의 싱크를 맞추는 것이 소통에 중요하다는 것을 배울 수 있었다.

[아이디어 회의]

17시간동안 하나의 Product를 만드는 경험은 나에게 매우 신선하게 다가왔다. ‘Change’라는 주제로 서비스를 만들게 되었는데, 나에게는 다소 무거운 주제로 다가왔다. 유저에게 쉽게 다가가기 위해서는 좀 더 가벼워져야 하는데, 생각의 틀에서 벗어나기란 쉬운일이 아니었다.

처음 우리 조의 아이디어는 수십개의 질문에 답변을 저장하고 질문이 끝나면 다시 첫 질문으로 돌아와서 답변을 저장하며 내가 어떻게 한 질문에 답변이 변화하고 있는지 유저에게 보여주는 서비스였다. 나는 되게 마음에 드는 아이디어였다. 그러나, 운영진에게 피드백을 한번 받고 나서는 완전히 반대의 분위기가 되었다. 가장 기억에 남는 피드백은 ‘느린 우체통 같다’라는 것이었다. 유저는 몇십일 동안 기다릴 수 없다는 것이었다. 생각도 못한 답변이였다. 물론 팀 내에서의 협업과 분위기도 중요하지만, 완전한 제 3자의 입장에서 들어보면 그것이 내 아이디어가 아니기 때문에 나올 수 있는 입장이였다. 여러 사람의 피드백을 최대한 많이 받는 다는 것이 얼마나 중요한 일인가를 느낄 수 있었다.

결국 우리는 카카오톡 오픈채팅인 ‘거지방’을 모방하여, ‘거지촌’이라는 서비스를 만들기로 결정했다. 거지촌이란 유저들 간에 절약정신을 키워주는 서비스인데, 서로가 소비를 할 때마다 다수가 이에 대한 반박글을 올리고 때론 농담을 하면서 함께 절약하자는 커뮤니티 서비스이다.

[개발]

사실 가장 충격이였던게 이 시간이였다. 알고는 있었지만, 나는 개발자로서 기획과 디자인이 어느정도 되어야 시작을 할 수 있었고, 이제껏 코딩만 하던 나는 기다리는 시간동안 무엇을 해야하나 우왕좌왕하였다. 물론 사용할 Package를 찾아보는 등 아무것도 안한 것은 아니였지만, 처음 경험하는 상황에 기다려야 하는 것을 알았음에도 불구하고 헤메었던 것 같다.

본격적으로 코딩을 시작하면서 곧바로 벽을 느낄 수 있었다. 처음 보는 Package를 사용하려니 그 코드를 이해해야 했고, 숏커톤이라는 짧은 시간은 나를 기다려주지 않았다. 미리 쓸만한 Package를 탐색하고 더 공부할걸 이란 후회가 되었다. 그러나 이미 시간은 가고 있었다.

한 번 집중하기 시작하면 주위의 말이 잘 들리지 않는 나는 코딩을 하면서 계속되는 수정에 서로 피드백하고 소통하는 것이 어렵게 느껴졌다. 어찌됐건 맡은바를 완수하기는 하였지만, 뜻대로 되지 않고, 더 좋은 기능과 디테일에 대한 아쉬움은 아직까지도 남아있다.

[숏커톤을 마치며]

숏커톤이 이렇게 빨리 다가올줄은 몰랐다. 군복학 후 첫 도전으로 시작한 파드활동이 어느새 학기 막바지에 다다랐고, 처음으로 기획, 디자인과 개발이 모여 함께 Product를 만들어가는 경험을 할 수 있었다. 이제껏 혼자서만 개발했던 나에게는 무척이나 신선한 경험이었다. 숏커톤으로 인해 종강직후 있을 롱커톤에 대한 의욕이 샘솟았다. 아쉬움을 보완하고 더 좋은 Product를 만들고 싶은 욕심이 생겼다. 비록 밤을 새워가며 컴퓨터를 바라봐야 했던 힘든 점도 있었지만, 많은 점을 배웠다는 것에 뿌듯하고 기쁘다.

8
6
김민혁

김민혁

사람과의 관계, 대화, 관심

어제 '함께 자라기' 북스터디 두번째 모임을 가지고 나서 회고 및 정리

  1. 협업이라고 다 좋은 것인가?

 협업이라고 다 좋은 것은 아니고 몇가지 전제조건이 필요하다고 한다. 그 중 책에서 말하고 있는 것은 추상화라는 것이다.

 추상화라는 개념이 프로그래밍에서도 굉장히 중요한데, 저자가 프로그래머라서 이런 말을 쓴 것 같다. ‘객체지향언어’라는 것이 있는데, 자바, 그리고 현재 앱파트에서 쓰는 플러터의 다트또한 같은 ‘객체지향언어’이다. 객체지향언어가 나온 이유는 세상과 컴퓨터가 너무 달라서 세상의 개념을 보다 쉽게 컴퓨터로 표현하기 위함이다.

 이처럼 협업에서도 머리에 있는 것을 잘 표현하고 상대방이 알 수 있도록 매체를 통해 추상화, 즉, 시각화 하는 것이 중요하다. 

 조환 기획 파트장이 발제를 위한 모임에서 이 ‘추상화’라는 것이 협업에서 서로의 생각의 싱크를 맞추는 일이라고 했는데, 협업에서 이러한 추상화가 이루어지지 않으면, 서로 목적이 달라질 수 있기 때문에 협업의 시너지를 올리기 힘들다. 


실력이 뛰어난 개발자는 혼자 방에 틀어박혀서 코딩 하는게 낫지 않을까?

 조환 기획 파트장이 줌 미팅을 하면서 던졌던 질문인데, 나온 결론이 코딩을 같이 해야하는 이유는 더 나은 Product를 만들 수 있고, 더 빨리 만들 수 있다는 점이다. 

 아무리 뛰어난 개발자라도 프로그래머는 계속 바뀌는 정보들에 취약하고, 그래서 각 팀원이 가진 정보는 다 다르다. 그래서 더 나은 Product를 만들기 위해서는 많은 사람들의 의견이 필요하다. 

 또한 일반적으로 코딩을 잘하면 혼자 하는게 훨씬 빠르다 라고 생각하는데, 요즘은 분업을 위한 소프트웨어 디자인 패턴들이 많이 나오고 있다. 예를 들어서 MVC 모델이라고, 모델, 뷰, 컨트롤러 라는 파트로 개발을 나누는 것이다. 물론 분업과 협업은 다르지만 각 파트가 긴밀하게 연결되어 서로 정보를 공유해야 하므로 협업 또한 중요하다. 작은 프로젝트라면 물론 뛰어난 개발자가 더 빠를 수는 있겠지만, 프로젝트가 커지면 코드가 복잡해져서 수정이 힘들어지고, 시간적으로도 한명이 협업을 이기기는 힘들다.


2. ISTP 남자, 어떻게 꼬시나요?

 얼마전까지 하도 MBTI에 대해서 사람들이 이야기해서 나도 MBTI가 좋은 것은 아닌데, 책에서는 MBTI를 예로 들면서 사람마다 다가가야 하는 방법이 다름을 설명하고 있다.

 이 장에서는 계속해서 사람관계에서 대화하는 방법에 대해서 설명하고 있는데, 이처럼 사람의 특성에 따라 다르게 대화하고 설득해야 한다. 즉, 그 사람과 대화하기 전 그 사람에 대해 조금이라도 이해하는 것이 먼저다.

 그런데, 여기의 MBTI 자료를 봤을 때, 논리성과 객관성에 대한 환상이 떠올랐는데, MBTI 또한 사람의 성향을 나누는 객관적인 지표이기 떄문이다. 그래서 우리가 누군가를 설득하고자 할 떄에는 그 사람만의 개성에 집중하여 이해해야할 필요가 있다.

+ 논리성과 객관성에 대한 환상: 누군가를 설득하기 위해서는 우리는 논리적이고 객관적인 자료로 그 사람을 설득할 수 있다고 믿는데, 그 사람과 관계가 좋지 않다면 그 사람은 나의 설득을 어떤 이유를 들어서라도 막고자하는 경향이 있다.


3. Slack DM 왜 사용하지 말라는건가요?

 파드 모임을 시작할 때 Slack에서 DM을 자제 하자는 이야기가 있었다. 그 이유는 무언가를 공유했을 때 DM으로 하면 그 사람과 나, 즉 두사람만 그 정보를 알 수 있기 때문이다. 이 내용에 대해서 책에서는 삼투압적 의사소통이라는 개념으로 다루고 있다.

 삼투압이 무엇인가? 삼투압은 농도가 낮은 곳에서 높은 곳으로 용매가 이동하는 것, 즉 삼투압적 의사소통은 정보를 더 많이 가진 사람이 그것을 공유하면 자연스럽게 주위 사람들이 그 정보에 스며든다는 것이다. 이를 통해 그 집단의 각 사람들의 역량이 은연중에 배가 되는 효과를 얻을 수 있다.


이 책 내용을 함께 나누면서, 각기 다른 사람들의 의견과 생각이 다른 것을 보고 그 사람의 개성에 집중해서 이해할 필요가 있다는 말을 확실히 느낄 수 있었다. 또한, 완벽하다고 생각한 논리를 가지고 갔지만, 사람과의 관계 문제 때문에 프로젝트가 힘들었던 전날의 예시들을 나누면서 논리성과 객관성에 대한 환상이 정말로 작용하는구나 라는 것을 느꼈다.

 

10
4
김민혁

김민혁

함께자라기 북스터디 2차 모임 발제를 준비하며

타 파트 사람들과 더 알아가고, 이해하기 위해 지난 월요일 부터 함께 자라기 북스터디 (기디반)에 참여를 시작했습니다. 어제는 내일 발제를 맡은 조환 기획파트장님과, 웹파트 윤성현 님과 함께 줌 미팅을 가졌습니다. 


1차 스터디 모임의 후기에 대해 나눌 수 있는 시간이 있었는데, ‘협업을 어떻게 해야 더 좋은 방향으로 함께 시너지를 낼 수 있을까?’ 에 대해 생각해 볼 수 있었을 뿐더러 ‘내가 함께 협업하고 싶은 사람들에게 어떻게 하면 협업의 방향(ex. 애자일)을 잘 설득할 수 있을까?’에 대한 고민도 해볼 수 있었던 시간이었습니다. 그리고 발제 전에 미리 책의 이해가 가지 않았던 부분이나, 인상깊은 점들을 나누며 머릿속에 정리되어 있지 않던 ‘암묵지’가 추상화(시각화)를 통해 더 많은 정보로 정리가 되는 경험을 할 수 있었습니다.


<책 내용을 정리하며 가장 인상깊었던 두가지>

  1. "남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 한다." 우리는 누군가를 설득할 때에 누구나 납득할만한 객관적인 자료를 가져와야 한다고 믿고, 그 사람과의 관계를 중요시 하지 않고 객관적 자료만 무수히 들고 오는 경우가 있다. 그러나, 아무리 객관적인 자료를 가지고 와서 누구나 인정할만한 기획일지라도, 그 사람과의 관계가 나쁘면 그 사람은 어떠한 이유든 들어서 그 기획을 무너지게 하려는 경향이 있다. 남을 설득할 때는 객관적인 자료도 물론 중요하지만 가장 중요한 것은 그 사람과의 관계이다.
  2. "애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고, 나쁜 일에 대해서는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾸는 경향이 있습니다. 저자가 프로그래머 출신이라서 이러한 말을 한 지는 모르겠지만, 컴퓨터공학을 전공하고 있는 나는 이 말이 애자일의 특성에 대해서 조건문으로 표현하고 있다는 점에서 매우 인상이 깊었다. 식으로 정리하자면, A, B 라는 사람이 있을 때, '좋은 일' = A or B, '나쁜 일' = A and B 로 정리할 수 있는데, A와 B중 누구라도 좋은 일이 있으면 함께 좋은 일이 된다는 것이고, A와 B둘다 나쁜일이 아니라면 그것은 나쁜일이 아니라는 것이다. 즉, 애자일은 항상 서로 상황을 공유하고 서로 수정해 주기 때문에 서로를 항상 보완해 줄 수 있다는 설명이다.


책을 이해하고 나니 좋은 말들이 많아서 내일 스터디에서 다른 사람들의 책에 대한 생각을 들을 수 있다는 것에 기대됩니다.

10
4