안녕하세요.

개발 13년 차, 그리고 CTO 6년 차,

그리고 지금 회사에서 이제 갓 1년을 넘어 근무하고 있는 개발자 배진호입니다.

회사에 적응하고 일 년 정도 되었을 때

늘 회고글을 작성하고 했었는데요.

이번에도 다른 분들께 도움이 될 수 있는

그리고 지금 보고 듣고 느끼고 있는 글들을

글로 남겨둘까 합니다.

https://brunch.co.kr/@chickenmoim/19

10화 CTO의 조건

작은 스타트업 CTO 경험담 | 안녕하세요. 거창한 제목으로 인사드립니다. 현재 작은 스타트업의 CTO를 하고 있습니다. 이 글을 쓰게 된 계기는 최근 개발자로서 미래를 꿈꾸는 많은 분들에게 도전

brunch.co.kr/@chickenmoim/19

지난 글에서

CTO의 조건이라는 거창한 글을 쓴 적이 있는데요.

이 글은 저에게도 나름의 기준이 되고 있어서,

이렇게 말을 한대로 잘 지키고 있는지의 판단 기준이 늘 되고 있습니다.

현재 저는

스튜디오 봄봄 CTO 1년 3개월

SK 브로드 밴드 프로젝트(프리) — PL 9개월

아이고고 CTO 2년 9개월

현) 휴램프로 CTO 1년 3개월

총 6년째 리더를 하고 있습니다

크고 작은 프로젝트들을 경험하면서, 다양한 분들을 만나 뵈었고, 리더로서 잘 성장하고 있는지,

스스로도 늘 돌아보게 되는데요.

지난 스타트업에서의 경험들을 비추어서,

작년부터 올해 한 해를 어떻게 꾸려오고 있는지,

어떤 전략을 가지고 있고, 앞으로는 어떻게 변모되어갈지에 대해서 이야기해 볼까 합니다.

규모가 주는 이점

지난 회사와 지금의 회사의 시작은 비슷했습니다.

지난 회사에서는 개발팀 두 명으로 시작하기도 했고, 이번 회사도 개발팀이 3명으로 시작했습니다.

지난 회사에서는 개발팀이 세명까지 늘어나고, 디자이너를 포함하면 다섯 명 이상으로 늘어나는 경험이 있었지만, 지금은 개발팀이 6명으로 늘어나고, 디자인을 포함하면 9명까지 늘어나는 경험을 하고 있는데요.

지난 회사에서도 제한된 상황 속에서 최고의 분들을 모셨지만, 지금은 또 지금 회사 나름대로의 좋은 분들을 모실 수 있게 되었다는 점입니다.

당시에는 개발팀의 전체를 아우르며, 제가 가지고 있는 권한들을 이양하기에는 한정된 부분이 있었습니다. 따라서 많은 쪼개진 일들이 있었지만, 어느 정도 이상의 개입들이 필요했는데요.

현재 6년 차 12년 차 20년 차 분들이 있어서 프로젝트가 쪼개져서 굴러가고, 프로젝트가 병렬로 동작하게 되었고, 별도의 프로젝트들이 조금씩 살을 붙이고 커져가고 있습니다.

현재까지의 성과

비전 설정 > 문제 발견 > 해결점 모색 > 우선순위 설정 > 문제 해결

회사가 굴러갈 때는, 다양한 문제상황들이 존재합니다.

따라서 저희는 Asana를 통해서 문제들을 기재하여 Backlog 형태로 관리하고 있는데요.

이런 백로그들이 많이 쌓이게 되면, 전체적으로 해야 할 일들이 누적되어서 무거움이 생기게 되어있습니다.

그렇기 때문에 큰 프로젝트 단위로의 꼭지들을 지정하는 것들이 중요한데요.

그런 반면에 운영상으로도 급하게 떨어지는 작은 문제 상황들도 같이 해결하는 것이 중요합니다.

따라서, 업무를 배분하거나 우선순위를 설정하는 부분이 중요한데요. 결과적으로는 운영적인 것들을 처리하느라 프로젝트 단위가 늘어져도 안되고, 프로젝트에 집중하느라 운영적인 부분을 안 하는 부분도 할 수 없기 때문에 시간적인 부분들을 관리하는 것이 중요합니다.

전체적으로

회사에 와서 필요한 전체적인 비전들을 설정하고 점검하는 시간을 가졌는데요.

인사/노무로써 해야 할 것들 부족한 것들 고객에게 어떤 느낌을 주어야 할지 등등에 대해서 세부적인 이야기들을 진행했습니다.

그 과정에서, 저희의 강점인 부분들을 가지고,

근태, 연차, 전자 계약이 굵직한 부분들을 해결하고자 했습니다.

가장 먼저 선택하고 진행한 프로젝트!

전자 계약 프로젝트,

모두 싸인과 같은 근로계약서를 작성하고 선택하고 알림톡으로 전송하는 기능!

이미 알림톡을 이용한 프로젝트에 대한 경험들이 있었기 때문에 해당 부분을 설계하는 것들은 크게 어렵지 않았습니다.

중요한 기능은 사인을 하고, PDF로 저장하는 기술. 그리고, 보호하는 기능.

그 결과 전자 계약을 보내는 기능입니다.

기존에는 없던 부분이었지만,

이렇게 사원이 있을 때, 해당 사원들에 대한 근로 계약을 작성하고,

해당 근로 계약서를 보낼 수 있는 기능입니다.

모바일 카톡으로 메시지를 받으면,

이렇게 근로 계약서를 서명하여 해당 내용들을 언제든 확인할 수 있는데요.

많은 회사들이 해당 기능들을 이용해서 쉽게 근로 계약서를 작성할 수 있도록 했습니다.

올해 1월에 해당 기능을 오픈한 이후로 많은 기업들이 해당 기능을 이용해서 근로 계약서를 작성하고 있습니다.

두 번째는 연차인데요.

많은 회사들이 연차 관련해서 해당 문제들을 해결하고 싶어 합니다.

입사일 기준으로 연차 부분을 해결할 수도 있고,

회계연도 기준으로도 연차를 처리할 수도 있는데요.

해당 부분이 회사별로 차이가 있어서 해당 부분을 처리하기 힘든데요.

저희는 환경설정을 통해서 입사일 기준, 회계연도 기준으로도 연차를 처리할 수 있게 되었다는 것입니다.

또한, 담당자 입장에서 해당 연차 부분을 확인하고 처리하는 부분에 번거로움이 있었는데,

일괄 승인 기능 등을 추가함으로써 담당자들이 보다 쉽게 연차 정보 등을 확인하고, 승인할 수 있도록 변경되었습니다.

마지막으로,

근태 기능인데요.

기존의 근태 기능도 어느 정도 사용가능한 근태기능이었지만, 근태의 신청에 대한 관리가 잘 되어있지 않았었는데요. 이 부분을 개선하여,

근태의 신청과 승인, 그리고 근태 신청의 결재 라인들을 강화함으로써, 근태 기능이 강화되었습니다.

근태 관리 내에 근태 일괄 입력 기능, 근태 일괄 재계산 기능, 근태 세콤 연동 기능들이 추가됨으로써,

근태에 대한 다양한 부분들이 강화되었습니다.

신청/알림 기능등을 통해서,

근태에 대한 승인 대기, 승인 완료 등을 필터링하여 볼 수 있게 되었고,

관련해서, 다양한 기능들이 추가되었습니다.

기존의 휴램 모바일

기존의 휴램의 모바일 화면이었는데요.

웹뷰형태로 진행되어 있어서, 디자인이나 기능에 제한이 된 부분들이 있었는데요!

기존의 앱에 비해서, 확실히, 예쁘게 개선된 느낌이 있는데요.

쉽게 근태를 올리고, 휴가나 급여 정보를 확인할 수 있도록!

결재자 입장에서도 쉽게 결제할 수 있도록 추가적으로 고려가 되었습니다.

회사의 첫 이미지가 그렇지만,

다양한 회사에서 사원들을 관리하고, 해당 사원들의 근태 기록을 어떻게 쉽게 받을 수 있을지를 당연히 고민할 수밖에 없는데요.

결과 개발 시작 3월부터 시작해서 6개월에 기간에 걸쳐서, 예쁜 앱으로 탄생이 되었습니다.

앱 다운로드 : https://hulam.onelink.me/VwlS/uicxtlt2&af_force_deeplink=true

앱을 다운로드하시고 테스트해 보실 수 있는데요!

근태나 연차 등등이 필요한 회사에서는 한 번쯤 고려해 보실 수도 있겠죠!

CTO의 역할 팀빌딩

위에 예쁜 결과인 앱을 하나 소개드렸는데요~!

이런 여러 가지 결과를 내기 위해서

디자이너분들과 PO, 그리고 개발자분들이 힘을 많이 써주셨는데요.

이면에는 좋은 사람들을 면접하고, 채용하는 과정들이 있었습니다.

여기에서, 좋은 사람으로 판단하는 기준이 무엇이었고,

그분들이 어떤 역할을 해주셨고,

또 어떻게 지금 회사 생활을 하고 있는지..!

첫 번째로는 회사에 비전과 기준이 분명했습니다 나름대로 회사의 철학이라고 할 수 있는데요.

우선 개발팀의 비전을 꼽아보면

문제 발견 역량

문제를 적극적으로 발견하려는 문제 발견 역량.

통섭 역량

본인의 전문 분야뿐 아니라 다른 이해관계자와의 협업으로 문제 해결을 시도하려는 통섭 역량.

목표 지향적 마인드

회사의 목표, 팀의 목표에 맞추어 개인적 역량 향상을 추구하고 목표 달성을 하려는 목표 지향적 마인드.

등등의 철학이 존재했습니다.

나름의 기준에 맞는 사람들을 찾기 위해서 백방으로 소문도 하고,

많은 면접들을 보면서 해당 기준에 맞으시는 분들을 찾는 과정이 쉬운 일은 아니었는데요.

다양한 인연들과 기존의 관계들, 그리고 다양한 면접들을 통해서 좋은 분들을 뫼실 수 있었습니다.

여기에는 다양한 플랫폼들의 활용이 존재했는데요!

1. 리멤버 앱

리멤버앱의 정식 채용 기능을 활용하지는 않았지만, 리멤버 커뮤니티를 통해서, 다양한 사람들의 니즈와 이야기들을 들어볼 수 있었고, 그 과정에서 커피챗으로 연결된 분이 최종적으로 채용이 되었습니다.

이처럼 개발 커뮤니티를 활용하면서 좋은 분들을 만나고 매칭할 수 있는 기회들이 있는데요!

이런 모임들이 자주, 더 확대되면 좋을듯합니다.

2. 치킨모임

개인적으로는 개발자 커뮤니티 모임인 치킨 모임을 벌써 8년째 이어오고 있는데요.

모임 안에서도 누구나 채용공고를 올릴 수 있는 1500명 단톡이 존재합니다. 해당 단톡도 활용을 하여서, 채용이 일어나게 되었습니다.

3. 인연

개인적 인연을 통해서도, 한번 회사에 지원해 보라는 이야기를 하고, 정식 절차를 거쳐서 채용까지 이어지게 되었는데요.

평소의 모임과 활동 등, 개인적인 관계들을 구축하는 결과 좋은 분들을 모실 수 있게 되었던듯해요.

팀은 이렇게 모았지만,

좋은 팀이 되기 위해서는 팀 내 조직 문화들을 만들 필요가 있는데요.

팀의 조직 문화들

다양한 회사를 통해서, 어떻게 하면 조직이 계속적으로 동기 부여를 할 수 있는지에 대한 고민이 많이 있습니다.

한 달 내내 밤을 새워서 개발을 해본 적도 있고,

칼퇴를 해본 적도 있고, 밤에 일을 하다가, 자고 일어나면 문제가 해결된 경우들도 있고,

많은 근무 환경 사이에 있었는데요.

조직이란 어떤 방향성을 가지고, 방향을 잘 설정해 줄 필요가 있다고 생각합니다.

일이라는 것들도 계속 변동이 생기고, 변화들이 생기는데요.

일이 너무 없더라도, 조직이 새로움에 직면할 수 없고, 일이 너무 많더라도, 무거움으로 인해서, 조직이 동력을 상실한다고 생각하는데요.

그것에 있어서 가장 중요한 것이 적당한 일의 양과 분배, 그리고 적당한 목표설정이라고 생각하는데요.

좋은 팀이 되기 위해서는 적절한 환경 조성이 먼저라는 생각이 들었고,

PO님과의 논의아래,

일의 양을 배분하면서 적절하게 일을 배분하고, 필요에 따라 적절한 채용도 같이 진행을 했는데요.

그 결과 이런 성과들이 차곡차곡 쌓이게 되지 않았나 생각해 보네요.

재택근무 방향성 논의

개발팀은 현재 주 3일 재택근무의 방향성을 가지고 정착되어가고 있습니다.

초기에는 재택이 없었고, 첫 번째로는 주 1회의 재택을 시행함으로써, 재택을 조금씩 늘려왔는데요.

완전 재택을 하지 않은 이유는, 부서 간 사람들과의 친밀성과,

개발을 진행함에 따라서 필요한 논의 항목들이 필요한데, 실제로 오프라인에서 만나서 회의하는 것보다 더 좋은 의사소통 방식이 없다고 보았기 때문에 필요에 따라서 회의는 오프라인으로 진행합니다.

물론, 재택을 통해서도 관련된 논의들은 충분히 진행할 수 있도록 여러 가지 툴들을 사용했는데요.

Figma, Gathor Town 등을 활용해서, 화면 공유 및 의사소통을 원활하게 진행할 수 있었습니다.

관련해서는 주기적으로 1~2달간에 한 번씩 재택근무의 횟수가 괜찮은지 여부를 체크하고 있는데요.

문화적으로 거리가 먼 직원들의 경우는 이렇게 재택근무를 통해서, 업무적인 만족이 올라가고 있습니다.

분기별 회고

업무를 진행할 때는, 다양한 백로그들이 존재하는데요.

작은 프로젝트부터, 큰 프로젝트까지, 다양한 프로젝트들을 진행해야 하는데요.

관련된 업무들을 배분하고, 결정하고, 그 결과에 대해서 논의할 필요가 있는데요.

늘 회고할 때는, 테스트의 부족, 일정의 문제 등 다양한 문제들이 제기되는데요.

관련된 내용들을 회고하는 과정을 통해서, 배웠던 부분과 문제들을 다시 한번 상기시킬 수 있어서 다음의 분기의 프로젝트에서는 더 좋은 결과들을 예상해 볼 수 있는데요.

그런 차원으로 이런 분기별 회고가 프로젝트의 마침표를 찍는데 도움이 되었다고 할 수 있겠네요.

업무라는 것은 늘 계속 존재하는 것이기 때문에,

어떤 업무에 꼭짓점을 찍는 것이 중요하다고 생각합니다.

그런 의미로, 이번에 앱론칭도 이런 꼭짓점의 일환이라고 생각하는데요.

좋은 팀을 만나서, 프로젝트를 통해서 성장하는 경험!

그리고 결과적으로 회사가 성장하는 경험이 더 많아지면 좋을 것 같다는 생각입니다.

마치며

팀원의 입장이 아니라,

팀장의 입장에서,

좋은 팀을 만들었다고 표현하는 것이 참 낯간지러운 일입니다.

그런데, 팀을 신뢰하는 첫 번째는,

팀장이 팀원들을 신뢰하는 것이라고 생각합니다.

그리고 만들었다기보다는, 함께 만들어 가는 것이 아닌가 생각을 해보게 되는데요.

신뢰와 그 이후의 방향성, 그리고 나아가는 목적에 대한 공유들이 뚜렷하다면,

함께 하는 공간에서 어찌 보면, 조금 더 재미있게 목표를 향해 도달해 갈 수 있지 않을까 하는 생각이 드네요.

함께 소통하는,

그리고, 같은 목표를 향해 나아가는,

그런 기업들이 많아지면 좋겠다는 생각으로 맺음말을 해보네요.

물론, 아직 해야 할 일도 많고, 지금은 완성된 상태가 아니기 때문에 변해야 할 지점도 많고,

도전해야 할 과제들이 많이 남아있습니다.

이제 1년 차, 지점에서, 또 앞으로의 변화들을 기대해 보면서, 후기 마쳐봅니다.

PS. 최근 다양한 목표와 목적을 가지고 CTO를 생각해 보시는 분들이 많으실듯한데요~! 다양한 커피챗을 비롯된 만남에 대해서 긍정적으로 생각하고 있습니다!

2019년 11월

강의를 처음 제안 받았다면?!

강의를 처음 제안받고 나서,

강의를 진행하는 과정과 강의의 장단점들을 한번 글로 작성해 보았는데요.

벌써 2023년 1월이 되었네요.

3년 하고도 2개월이 지났습니다.

지난 글로 CTO의 역할과 현재 하고 있는 업무들에 대해서 기재를 해보았었는데요.

첫 강의 이후에 달라진 것들을 한번 정리하고,

회고 및 공유를 해볼까 합니다.

지난 첫 패캠의 온라인 강의를 진행했을 당시,

사실 15시간 강의에 대해서 너무 얕본 측면이 있었는데요.

3개월간 고생을 하고 나서, 온라인 강의를 진행한다는 것은 마치 영혼을 불살라서 후대에게 자식을 남겨주는 심정으로 한 땀 한 땀 교안도 작성하고, 내용도 정리하고, 어떻게 알고 있는 내용들을 정리해서 보여주어야 할지 정리해야 하는 작업이었는데요.

해당 강의를 오픈하고 난 뒤 2년이 지나고,

해당 강의는 사라지게 되었습니다.

그 이후 진행한 강의

3년이 지난 사이 회사에서의 업무도 다양한 일들이 있었지만,

강의도 다양한 강의들을 진행했었는데요.

. 패스트 캠퍼스 — Spring Boot 프레임 워크 강의 — JPA 강의 — 온라인

. 중앙 ICS [한기대] 클라우드 인프라 네트워크 구성 — 온라인 강의

. KB증권 신입사원 DT 역량 강화 강의 — 비대면 강의

. 웰컴 저축은행 — 재직자 대상 프런트 엔드 역량 업스킬링 과정 강의(오프라인)

. K-Digital 훈련[한국공학대학교] — 서버 강의(온라인+오프라인)

. 스마일 게이트 스토브 신입 인턴 교육과정 강의(오프라인)

. 신한 투자 증권 프로 디지털 아카데미 DevOps 강의(오프라인)

패스트 캠퍼스를 통한 스프링 부트 강의를 시작으로,

한기대, 한국 공학 대학교에서도 서버 관련 강의를 했고,

KB증권, 신한 투자 증권에서도 신입사원 대상, 교육자들 대상으로도 강의를 진행했는데요.

첫 devOps 강의를 진행한 이후에 다양하게 컨택을 주셨고,

시간이 되고 기회가 되는 경우 몇몇 강의들을 진행해 왔습니다.

강의를 통해 얻은 점

강의를 통해서 얻게 된 점은,

강의 교안을 준비하는 과정을 통해서,

공부하고 있고, 알고 있고, 실제로 적용하고 있던 많은 데이터들을

정리하게 된다는 점입니다.

실제로 강의에 들어가기 앞서서,

주로 강의에 사용하는 소스의 경우는 제가 나름대로,

강의용 페이지를 만들어서, 공유하고,

관련 소스들을 직접 테스트해볼 수 있도록 해드렸는데요.

devOps의 경우, 강의 교안을 만들거나 할 때,

실제 사례를 표현하기 어려운 경우들도 많기 때문에,

진짜 내부에 사용하고 있는 지라의 버전과 강의에 사용된 지라의 버전이 달라 힘든 경우도 있고,

강의를 하는 중간에 이 내용은 꼭 들어가야 한다고 해서,

강의 중간에 강의의 내용을 추가하는 경우도 있었지만,

강의를 한다는 자체를 통한 ‘성장’이 추가적으로 있지 않았나 생각해 봅니다.

실제로

아이고고에서는

제가 진행했던 강의를 신입 사원 대상으로 교육해주기도 했었는데요.

그만큼 강의에 대해서 한번 해당 내용들을 정리하고,

흐름이 만들어지고, 해당 내용이 공유되고 나면, 비슷한 플롯의 강의에 대해서는 조금씩 자신감이 더 생기는 차원이 있는듯합니다.

그리고,

‘강의가 강의를 부른다’

강의 제안이 들어오면, 기존의 강의 히스토리를 요청하는 경우들이 있는데요.

이미 강의를 한 이력이 있다면, 추가적으로 다음 강의가 성사(?) 될 가능성이 높습니다.

그리고, 강의를 잘한다고 개발을 잘하는 것도 아닐 테고,

개발을 잘한다고 강의를 잘하는 것도 아닐 텐데요.

그럼에도 불구하고, 강의 이력이 있을 때, 면접을 볼 때 주는 ‘신뢰감’이 추가로

생기는듯합니다.

면접에서 강의를 많이 어필하지는 않았지만,

강의를 한 이력들을 보면, 그래도 어느 정도의 이해도는 있겠다는 생각은 들 테니 말이죠.

일과 강의의 밸런스

회사의 업무와 병행하면서 강의를 할 수 있을지 의문이 들 수 있는데요.

대부분의 강의는 밤늦게 교안을 작성하거나 주말을 이용합니다.

최대한 회사에 지장을 주지 않는 선에서 강의를 받고 진행해 왔습니다.

다만, 가정(?) 에는 조금 영향을 준듯하네요.

실제로 시간이 좀 필요한 경우는, 회사와 어느정도 합의후에, 회사의 연차들을 사용해서, 강의를 진행했는데요. 시간을 잘 정리해서 사용해야 이런 일도 할 수 있는 듯합니다.

치킨모임의 모임장으로써 모임을 운영하는 일.

CTO로써 회사의 업무를 분류하고, 과업을 성취하는 일.

개발자로서, 강의를 제작하고, 다른 사람에게 무엇인가를 전파하는 일.

예전에, 드라마나 웹툰, 게임, 독서 모임 등을 통해서, 취미활동의 영역들을 해왔는데요.

회사의 ‘일’을 하기 시작한 이후로는 개발자로서의 스펙과 ‘성장’에 대한 끊임없는 생각들을 해온듯해요.

그 결과 회사를 다녀오고, 집에 와서, 일반적인 취미 활동들을 한다기보다는,

개발과 관련된 연장선의 생각들을 많이 하게 되고,

그 결과 ‘강의’와 같은 일도 생각하게 되지 않았나 생각해 보네요.

치킨 모임을 운영하는 모임 초기에는

제가 무료로 진행하는 안드로이드 스터디 모임을 4회 차까지 리드하면서 진행했었는데요.

아마도 그런 과정들 하나하나가 모여서, 지금 이런 일들을 수행할 수 있게 된 게 아닌가 싶네요.

결과적으로는, ‘몰입’에 대한 차이가 이런 것들을 가능하게 하지 않았나 생각해 보네요.

아직도, 강의에 대해서는 그런 생각을 합니다.

남에게 가르치기 위해서는 그 내용을 더 딥하게 이해해야 하는데,

그게 공부가 되고, 공부를 멈출 수 없게 하는 또 다른 요인이 된다고 생각합니다.

강의가 들어오는 경로

프리랜서가 일이 들어오는 경로와 비슷한듯합니다.

첫 패캠을 통해서 강의가 들어온 뒤로,

다른 교육업체들에서도 강의들이 들어오게 되었고,

브런치를 통해서도 강의가 들어왔고,

강의 평가가 나쁘지 않게 나오고 나니,

자연스럽게, 다른 기업으로, 다른 곳으로 추천이 흘러갔습니다.

재미있는 것은,

엄청 유명한 대기업도 아니고,

엄청 유명한 책을 쓴 것도 아니고,

모임을 운영하기는 하지만, 그게 저의 개발 강의를 할 수 있는 사람이라는 것을 보증하지는 않는데,

그럼에도 불구하고, 계속 강의 제안이 들어왔다는 것입니다.

물론 CTO란 타이틀이 있지만,

그건 세미나에서나 먹히는 타이틀입니다.

이름 없는 회사에 대해서, 학생들은 관심도 없고, 실제로 CTO가 뭐지? 하는 경우도 많아서,

실제로, 그 학생들이 무엇을 얻는가?

이것에 포커스를 가지는 게 중요한 것이라고 할 수 있는데요.

안드로이드의 기본 개념을 학습할 때는,

생명주기, 라이프 사이클에 대한 설명을 기본적으로 진행합니다.

마찬가지로, 개발이라는 것을 잘 모르는 학생들의 경우,

눈앞에서, 자기가 만든 혹은 수정한 웹사이트가 실제로, 구동되고,

자기가 수정한 내용이 반영되고, 동작하게 만드는 것.

즉,강의를 듣는 사람이 흥미를 갖게 만들어야, 강의가 성공한다고 생각합니다.

그래서,

저는 IF, FOR 이런 기본적인 문법 학습보다는,

카카오톡으로 회원 가입이 되게 하고,

검색했을 때 결과가 눈에 보이게 하고,

AWS에 소스를 올려서 동작하게 하는 것을 시작으로 살을 붙여나가는 방식을 선호합니다.

막연한 것들이 막연하지 않고 실제 하게 만드는 것

그렇게 시작하는데요.

강의는 그래서, 입소문과, 제안을 통해서 들어옵니다.

강의를 하는 두려움 극복하기

온라인 강의를 할 때도,

오프라인 강의를 할 때도,

처음 뭔가를 하면 늘 두려움이 있습니다.

내가 잘할 수 있을까?

나보다 잘하는 사람은 많은데 역량이 될까?

떨면 어떡할 것인가?

학생들이 반응이 없으면 어떡할 것인가?

내가 한 강의가 그들에게 의미는 줄 수 있는가?

다양한 고민들이 없지 않습니다.

아마도, 처음 페어 프로그래밍을 하는 심정과 비슷하지 않을까 싶습니다.

내 소스를 누군가 본다면, 엄청 부끄럽지 않을까? 타박하지 않을까? 이런 걱정과도 같은 거죠.

3년 전 첫 마음은 그랬습니다.

직장도 처음이었던 시절이 있고,

대학생도 신입생이었던 시절이 있습니다.

군대도 이병 시절이 있는 것처럼요.

결국, 어떤 일을 하기로 마음먹었다면, 익숙하지 않은 시점이 존재하는데요.

그 시점들을 지나 돌이키게 되면,

또 어쩌면 너무 익숙해져 버리는 부분도 있는듯하네요.

언젠가 익숙함에 발을 담그게 된다는 것을 미리 알고 있다면,

첫발은 조금 더 가벼워지지 않을까 생각해 보네요.

강의를 해보고는 싶지만, 여러 가지 핑계와 이유 때문에

아직 시도도 못해보신 분들이 계시다면, 비슷한 고민들을 했었고,

그리고 그것들을 극복했을 때, 또 펼쳐지는 새로운 것들이 있음을 말씀드려보고 싶습니다.

온라인 강의와 오프라인 강의의 차이

두어 번의 온라인 강의와

오프라인 강의를 하면서 느꼈던 생각들을 간단히 정리해보려고 합니다.

우선 온라인 강의의 경우,

해야 하는 강의의 분량에 대해서 확인이 필요합니다.

또한, 강의 자료를 어떤 수준으로 얼마큼 만들어야 할지도 생각을 해야 하고,

또 이론만 있는 것인지, 이론 + 실습을 강의로 만드는 것인지, 소스는 어떤 수준으로 제공해야 하며,

보는 학생들의 수준은 어느 정도인지를 체크해야 하는데요.

온라인 강의의 경우, 분량이 중요하고, 발음이나, 시선처리도 중요합니다.

오프라인 강의의 경우, 눈앞에 대상이 있기 때문에 대상에 대한 이해도에 따라서, 강의의 레벨이나 시간들을

자유롭게 조절할 수 있지만,

온라인 강의의 경우, 해당 부분에 대한 조절이 불가능하다는 점이 단점이라고 할 수 있겠네요.

다만, 온라인 강의의 경우, 스크립트를 미리 잘 짜면, 강의 전에 조금 더 당황하지 않고, 강의를 부드럽게 할 수 있는데요.

오프라인의 경우는 딱딱하게 정해진 멘트를 하는 것이 아니라,

해당 상황에 따라서, 자연스럽게 강의를 진행해야 한다는 점이 있습니다.

오프라인 강의의 경우, 실무자와 신입, 전공자와 비전공자에 따라서 확연한 레벨차이가 존재하는데요.

따라서, 강의 레벨을 맞추기가 어려운 경우들이 존재합니다.

특히나 이미 알고 있는 것들을 재 학습하는 경우는 레벨이 낮아서 재미없다고 느낄 수 있고,

너무 난이도 있게 어려운 내용을 다루는 경우, 따라가기 어렵다고 느껴서 또 강의가 힘들다고 느낄 수 있는데요.

그래서, 오프라인 강의의 경우, 미리 알 수 있다면,

해당 강의를 받는 사람들의 성향들을 미리 파악하는 것이 중요합니다.

그리고,

온라인이든, 오프라인이든, 개발 강의의 경우는,

직접 소스를 개발해서, 배포하는 경우가 많이 있는데요.

약간의 디자인이 가미된 화면이라면, 조금 더 성취감이 있지 않나 생각해봅니다.

웰컴 저축은행과 KB증권 신입 사원 경우는 프로젝트 진행 시에

실제로 팀을 짜서 진행했고, 해당 팀의 아이디어를 반영한 프로젝트의 구현을 도와주었는데요.

일상에서 사용 가능한, 계산기, 맛집 목록, 네이버 지도 연동, 오늘의 메뉴, 오늘의 일기 등

다양한 아이디어들을 실제로 ‘구현’ 할 수 있도록 하면서,

성취감을 높였는데요.

강의마다의 ‘특성’을 이해하고 접근하면, 그만큼의 만족도가 있던듯합니다.

강의를 도전하는 개발자들에게 해주고 싶은 말

세상에는

너무 잘하는 사람이 많습니다.

저도 존경하는 분들이 많이 있고,

주변에 강의도 잘하시고, 책도 쓰시고, 유명하신 분들을 보면,

동경하는 마음도 들고, 주눅이 들기도 하는데요.

‘어차피 인생은 마이웨이’라는 말도 있지만,

해보지 않고 결과는 모르는 것이고, 주사위도 던져봐야 안다는 이야기가 있죠.

처음 스타트업에 발을 내딛을 때도 그랬습니다.

망할 수도 있고, 절망할 수도 있고, 실패할 수도 있지만,

도전하지 않으면, 결코 그다음을 볼 수 없으니까요.

아마도 지금도 가끔 블로그를 열심히 하다가 우연히 강의 제안이 들어왔는데,

내가 과연 할 수 있을지 없을지 망설이는 분이 계실지도 모르겠네요.

그리고 어쩌면 작은 회사의 팀장으로서,

혹은 큰 회사의 작은 리더로서,

사수 없이 홀로 성장한 개발자로서,

주변 사람과의 깊이를 가늠하면서, 내가 할 수 있을지 없을지 망설이는 분들에게,

한번 ‘시도’해보라는 말씀을 해 드려 보고 싶네요.

개발자로서, 강의가 최종 목적지는 아닙니다.

책을 쓰는 것도 최종 목적지는 아니죠.

하지만, 한 번쯤 해보고 싶은데 도전을 못하시는 분들에게 ‘용기’를 드려보고 싶네요.

차곡차곡, 레퍼런스가 쌓여 나갈 수 있도록 말이죠.

안녕하세요.

이번 글을 쓰는 목적은,

한 해를 돌아보는 목적도 있지만,

CTO의 업무에는 어떤 부분이 있는지, 그리고 이직 후에는 어떤 업무가 있는지 이야기

해보고자 글을 써 봅니다.

또한,

현재 이직 후 6개월 정도 지난 시점, 회사는 어느 정도 발전했고,

또 앞으로는 어떻게 할 것인지에 대한 이정표를 작성해 보고 함께 공유해보고자 글을 작성해 봅니다.

예전

https://brunch.co.kr/@chickenmoim/19

CTO의 조건이라는 글을 작성한 적이 있는데요.

저도 이 글을 작성하면서, 이와 같은 사람이 되고 있는지, 잘 수행하고 있는지,

계속 스스로를 점검해 보기도 했는데요.

이직을 한지도 벌써 6개월이라는 시간이 지났네요.

이직이라는 조금은 낯설고 어려운 주제를 다루어야 하지만, 그럼에도 불구하고,

이를 통해서 얻을 부분과 배울 점들이 있다고 생각합니다.

이직의 여정

벌써,

개발자로서 12년 차가 되었습니다.

10년 정도 하면 개발자 라이프가 끝이 날 거라고 생각했는데,

10년이 지나면 개발자는 어떤 삶을 살고 있을까? 어떤 계획이 있어야 하고, 또 어떻게

해나가는 것이 좋을지 과도기적인 과정이 있을 것이라고 생각했는데 그렇게 되었네요.

지난 회사는

https://brunch.co.kr/@chickenmoim/23

이런 여정기를 통해서, 회사가 잘 마무리되었는데요.

많이 투자받지 않은 회사였지만,

직원들이 없어져서 힘든 순간들도 있었지만,

그럼에도 앱도 론칭하고, 또 다양한 지원 사업에 선정되기도 하고,

그런 여정들을 통해서 나름의 배움의 과정이 있었습니다.

첫 스타트업으로 이직을 할 때의 두려움과 설렘이 아직도 남아있는데요.

지난 ‘아이고고’에서의 도전도 40대 이전에 한번 열과 성을 다해서 한번 불태워 보자는 측면이

많았었습니다.

마지막 프로젝트로는 내부 앱에 커머스를 심는 작업이었습니다. 유아동 매칭 플랫폼에서 커머스로의 도입은 한 달여의 작업으로 완성된 프로젝트였지만, 나름대로 가치가 있고, 결과도 많이 봤던 프로젝트였던 것 같아요.

이직을 결심하게 된 가장 큰 계기는 ‘대이직시대’를 눈앞에서 경험한,

커뮤니티를 운영하는 운영자 입장에서, 저보다 연봉이 높아지는 5~7년 차 개발자들이 생기는 것에

대한 괴리감이 가장 컸습니다.

물론 회사의 CTO, 책임감 차원에서 버텨야 하는 게 아닌가 싶기도 하지만,

또 한편으로는 아이를 키우는 입장에서, 고물가 시대에 이렇게 막연하게 회사가 잘되기만을 기다려야 하는 상황적인 측면이 가장 괴리가 크지 않았나 싶네요.

아무래도 이상을 쫓기도 하지만, 현실적인 것들도 생각하지 않을 순 없었습니다.

이직을 결심하고 한일은,

제가 했던 일들을 이력에 잘 정리하고, 포트폴리오를 잘 작성한 일이었습니다.

그리고 헤드헌터를 통해서, 다양한 포지션을 보고 듣기 시작했는데요.

‘현실’을 알아야, ‘이직’이 가능하기 때문에,

‘제안’ 받는 연봉의 레인지가 얼마인지, 적합한 연봉의 수준과 적당한 대우가 무엇인지를 정확하게 아는 것이 중요했습니다.

현재 제가 운영 중인 1500명이 참여하고 있는,

https://open.kakao.com/o/gBAhcUSc

익명의 연봉방도 많은 도움이 되었는데요. (비번 money22)

현재 연차에 받고 있는 적당한 연봉, 그리고 좋은 연봉, 그리고 낮은 연봉에 대한 기준이 나름대로 필요했습니다.

한 회사에 오래 근무하다 보면, 보통은 그 회사에서 계속적으로 연봉을 올려주거나 협상이 잘되지 않는 이상, 현재 받아야 할 연봉의 적당한 범주가 얼마인지 괴리에 빠지기 마련인듯해요.

그래서 적당한 연봉의 기준을 잡아 본 적이 있었는데요.

이직의 ‘조건’은

현재 기준과 조건이 나은 조건이어야 하고, 기존에 연봉 상승이 없었다면, 기존의 상승분도 챙겨줄 수 있는 회사였어야 했습니다.

그리고 백엔드 개발자로 이직을 할 것인지 C레벨로 이직을 할 것인지에 대한 고민도 했었는데요.

헤드헌터를 통해서도,

C레벨로의 이직만 오퍼를 열어두겠다고 이야기를 전달했습니다.

전 작은 회사의 CTO였지만, 실제로 오퍼가 들어오는 것들 중에는 큰 회사의 팀장급, 작은 회사의 CTO, 나름 규모가 있는 회사의 CTO 등 다양한 제안들이 들어왔는데요.

이 회사들 중에는 이미 좀 들어본 회사들도 존재했습니다.

즉, 개발자로서, 한 회사에서 CTO가 되기 위해서는 어떻게 해야 할까?라는 부분을 생각해봤을 때,

기존의 회사에서 인정을 받아서 CTO 가 되는 경우도 있겠지만,

이렇게 성장하는 회사들 중에서 좋은 인력들이 부족한 상황에서는

좋은 CTO를 찾기 위해서 회사들도 노력을 많이 하고 있습니다.

그런 가운데에서도 좋은 기회들을 포착할 수 있는 것이죠.

다만, 조건이 좋은 대신에 열악한 환경인 경우들도 있습니다.

1인 체제, 처음부터 끝까지 다 만들어야 하는 상황, 돈은 충분하지만, 팀이 없는 경우 등

다양한 경우의 수들이 존재하는데요.

회사가 안정적이고, 좋은 회사이면서 앞으로의 비전까지 있으려면, 그런 회사를 미리 선별할 수 있는 상황적인 부분도 이해가 필요하긴 합니다.

이미 투자를 받았고, 좋은 개발자만 있으면 되는데, 좋은 팀만 있으면 되는데 하고 생각하고 계신 대표님들의 입장에서는 훨씬 더 공격적이고 적극적인 제안을 하게 됩니다.

즉, 위험에 대해서 어느 정도 인지하고, 해결할 수 있는 ‘능력’만 있다면, 지금의 시대 해서, 충분한 도전들을 해볼 수가 있다는 말이죠.

회사의 면접은 총 8개 회사정도를 면접을 본듯합니다.

마지막으로 연봉이 맞지 않은 경우도 있었고,

서로 조율이 잘 되지 않은 경우도 있었지만,

결국 최종적으로 선택하게 된 곳이 바로.

지금의 ‘휴램’입니다.

https://hulam.co.kr

최근 스타트업들이 어렵다고 하고,

큰 기업에서 스타트업으로 갔던 부분에 있어서 후회하는지를

여쭈어본다면, 개인적으로는

후회하지 않는다가 대답입니다.

헤드헌터들의 다양한 제안들을 통해서, 제가 가진 역량과 실력들을 저울질하면서 확인할 수 있던 것들이 있었는데요. 그건, 제가 큰 회사든, 작은 회사든, 가지고 있는 가치가 변하지 않는다는 사실이었습니다.

그리고 큰 회사에서도 그것을 발휘할 수 있고, 작은 회사에서도 그것을 발휘할 수 있기 때문에,

회사의 크기 유무가 중요한 게 아니라,

내가 어떤 역할을 얼마나 잘 수행할 수 있는지에 대한 그 믿음과 확신이 중요하다는 것을 말이죠.

새로운 회사에 조직 문화 바꾸기

회사에서 처음 이직을 하면, 두려움이 있기 마련입니다.

누구나 이직을 하게 되면,

다 똑같이 첫 환경입니다.

이직한 사람들은 모르는 상태로 모두 같은 상태로 시작하기 때문에,

이직한 사람들에 대한 기대치는 생각보다 높지는 않습니다. 두려워할 필요가 없습니다.

처음 이직하게 되었을때는, 다시 시작해야 한다는 두려움이 있는데요.

적응하게 되면, 그런 두려움은 금새 사라지게 됩니다.

가장 먼저 해야 하는 일은

‘조직’을 파악하고, 상황을 ‘인지’ 하는 일입니다.

개발자가 몇 명인지, 일은 어떻게 진행을 하고 있는지, 그리고 문제는 무엇인지,

그리고 어떤 ‘계획’이 세워져 있는지를 확인해야 합니다.

그리고 그 계획이 합리적인지 이룰 수 있는 목표를 향해서 나아가고 있는지, 그리고 그 목표를 통해서 얻을 수 있는 것이 무엇인지 살펴볼 필요가 있습니다.

처음 이 회사에서 개발자는 이사님 한분과 신입 한 명 딱 두 명이었습니다.

그리고 php로 개발이 되어있었고, 현재까지 이렇게 시스템을 운영해 온 것도 대단하다는 생각이 들었었죠.

가장 먼저 사람을 뽑아야겠다는 생각이 들었습니다.

적당한 인력에 대한 배치 그리고 어떻게 일을 할 것인지에 대한 생각이었는데요.

다행스럽게 미리 조직에 계셨던 분 중에 PO님께서는 나름

이름 있는 회사의 코파운더 이셨고, 지금의 회사의 조직을 잘 운영하기 위한 플랜들을 잘 짜고 계셨습니다.

일정에 대해서 선택을 하거나,

일정을 선택하고 일정을 적용하는 시점에 대한 정리들이 이미 조금 선행되고 있었는데요.

굵직한 일정들을 선택하고, 처리하는 방향들이 잘 짜이고,

업무를 진행하고 나누고 분배하는 방식들이 잘 정리되기 시작하니,

일에 대한 속도도 나기 시작했습니다.

그리고 재택과 같은 것도, 내부적인 회의를 통해, 주 1회에서 주 2회 정도로,

서로의 업무적인 방향과 업무를 잘 선택할 수 있게 되니 자연스럽게 재택을 해도 될 정도로 서로를 신뢰하면서 일을 진행할 수 있게 되었는데요.

이런 회사의 문화를 세팅하고 바꾸는 과정을 통해서,

다들 조금은 일에 대해서 가치를 가지고 접근하게 되지 않았을까 생각을 해보네요.

개발에 있어서는

php 소스로 되어있다 보니,

git으로 소스가 관리가 되어있기는 했지만,

각각 소스에 대해서 통합처리가 안되어있었습니다.

따라서, 모두 내부에서 local로 php를 띄울 수 있는 동일한 환경을 만들고,

php의 개발서버가 유명무실했는데, git과 젠킨스와 개발서버를 연동하고, git에 올려서,

젠킨스를 기동 하면, 개발 서버와 연동되도록 기존의 레거시 시스템도 모두 흩어지지 않도록 모았습니다.

따라서, 각각의 개발에 있어서 따로따로 되고, 재작업을 했던 부분들이 많이 줄어들었는데요.

이런 부분도 회사의 개발 문화가 조금 바뀌게 된 부분이 아닌가 싶네요.

팀빌딩 하기

현재의 개발 팀은 6명입니다.

첫 제가 입사했을 때 3명이었던 것에 비하면 꽤 많은 인원이 되었는데요.

자바와 리엑트로 전환을 하기 위해서

개발자를 채용하고,

디자이너를 채용하고,

다양한 면접들을 보았던 것 같습니다.

현재의 구성으로도 현재 시스템을 잘 운영되고 유지되고 있는데요.

처음 신입으로 있던 개발자 친구가 리엑트도 잘하는 친구였고,

프런트에 재능이 있는 친구여서,

관련해서 소통을 많이 하고 하다 보니, 꽤나 빠른 시간에 회사의 홈페이지를 리뉴얼할 수 있었습니다.

이전의 휴렘

지금의 휴렘

처음 회사의 홈페이지의 느낌이 전문적인 전통적인 회사의 느낌이라면,

지금 회사의 홈페이지의 느낌은 그래도 조금은 최신 트랜드를 반영한 느낌이 느껴지는 느낌인데요.

사실 정석대로라면, 이 회사 홈페이지는 훨씬 더 늦은 시점에 빛을 보아야 하는 상황인데요.

제 생각에는 이 서비스를 이용하는 사람들이 가져야 하는 느낌은 훨씬 더 빨리 좋은 서비스로의 성장을 경험해야 한다고 생각했습니다.

기존에 서비스를 사용하는 사람들이 느끼는 변화가 2년 뒤가 되면, 그 사람들은 고객으로 잡을 수 없을 것 같았으니까요.

그래서, 약간은 파격적으로,

해당 리뉴얼을 빠르게 진행하자고 제안을 했고,

10월 경 해당 경 해당 리뉴얼 작업이 끝이 나서 배포가 완료되었습니다.

바뀌기 전의 내부 화면

바뀐 후의 내부 화면

엄청 디자인이 깔끔해진 걸 알 수가 있는데요! 가독성이나, 사용성의 입장에서,

디자인이 좋으면 아무래도 기분이 훨씬 좋아지겠죠!

팀빌딩의 결과 이런 아웃풋들을 빨리 잘 낼 수 있는 팀이 되었다는 것!!

막혀있는 데이터의 흐름을 만들기

CTO로써

현재 데이터가 흘러가는 방향을 이해하는 게 무척이나 중요하다고 생각을 합니다.

회원은 어느 정도 가입을 하는지, 회사는 몇 개 인지, 그리고 증가하는 속도는 얼마큼인지를 실시간으로

파악하는 게 중요하다고 생각을 하는데요.

회사의 회원가입과 결제, 그리고 다양한 데이터들을 슬랙으로 연동해서,

현재 필요한 가입과 관련된 데이터 및 중요 데이터들을 슬랙 노티로 확인할 수 있도록 연동을 해두었습니다.

다른 업무를 기존에 하고 있던 사람들의 입장에서도,

관련된 데이터를 수기로 찾아보는 일들은 매우 번거로운 일인데요.

관련된 업무들 중에서 어떤 업무들이 막혀있는지를 찾아서 관련 흐름들이 자동화될 수 있도록 도와줍니다.

이런 부분들이 업무의 효율화를 만들어 낼 수 있는데요.

회사 내부에서 연차를 신청하거나,

근로 계약서를 작성했을 때, 해당 부분에 대해서 알림톡으로 받지 못하던 부분이 있었는데,

관련 부분들도 개선을 통해서, 연차 신청들을 알림톡으로 확인할 수 있도록 변경한 부분도 이런 데이터적인 불편함을 개선한 상황인 듯하네요.

굵직한 프로젝트를 진행하기

회사에 오고 나서 몇 가지의 굵직한 프로젝트들이 있었는데요.

마케팅 포인트를 위한

[근로 계약서 무료 프로모션 프로젝트]

https://hulam.co.kr/promotion/hulam_free/index.html?utm_source=chicken&utm_medium=null&utm_campaign=null

[연차 휴가/ 일반 휴가 등록 및 처리 개선 프로젝트]

- 기존에 연차에 대한 기준을 세우고, 화면적으로 복잡한 부분들을 개선해서, 조금 더 쉽게 연차를 등록하고, 알림톡으로 받을 수 있도록 개선한 프로젝트

[부당해고 예방 센터 오픈]

https://hulam.co.kr/hpro/board.php?bo_table=consulting

기존의 게시판을 활용하면서 작업한 작업입니다. 채널톡과의 연동과정을 통해서 다양한 API를 연동해 보았네요.

다양한 회사들의 고충을 올릴 수 있도록 만들어진 프로젝트입니다.

[전자 계약 프로젝트]

근로 계약서 및 동의서등 회사에서 근로 계약서를 작성할 때 필요한,

전자 계약을 요청하고, 서명하고 관리할 수 있는 프로젝트

가장 마지막으로 한 프로젝트 중 하나인데요.

알림톡 연동과 서명 연동 등 가장 복잡하고 어려웠던 프로젝트가 아니었나 생각이 드네요.

근 6개월 이내에 처리한 프로젝트들입니다.

또한 기존에 웹앱으로 만들어진 앱 부분에 있어서 좀 깔끔하지 않은 부분을 정리한 작업도 추가되죠.

작은 시간 내에 결과를 만들어내는 것이 중요합니다.

이런 결과들을 보고 또 내부에서는 또 다른 신뢰가 싹트고, 또 그 신뢰를 토대로 다른 프로젝트들을 진행할 수 있게 되는 것이 아닌가 싶기도 하네요.

현재의 계획 와 내년의 계획 세우기

지금까지는

회사 내에 불편한 것들을 개선하고 답답한 부분들을

해결했다고 한다면,

내년은 조금 더 나아가,

앱을 사용하는 사람들의 입장에서,

회사의 담당자 입장에서, 이 서비스를 좋은 서비스라고

느낄 수 있도록 만들어 주는 것이 목표입니다.

대표님과 다양한 조직의 분들이 비전을 세워주시고, 말씀하신다고 한다면,

개발팀의 입장에서는 내년에 관련된 부분과 분야에 있어서 적시 적소에 다양한 기능들을 풀어주는 것을 목표로 하고 있습니다.

내년에는 개발팀의 인원이 더 충원되고, 앱도 리뉴얼되어서, 관리의 불편함 사용의 불편함들이 최소화되지 않을까 기대해 보네요!

커뮤니케이션을 통한 상호 작용

처음에 회사에 와서,

커뮤니케이션을 위해서 가장 먼저 한 일은

다양한 부서와 밥 먹기였습니다!

모임을 통해서 개발자분 한분이 채용되었을 때는 거의 모든 다른 부서와 밥을 한 번씩 먹었는데요!

밥을 같이 먹는 것만큼 커뮤니케이션을 도모하는 게 없다고 보는데요!

그 결과 부서 간의 의사소통이 조금 더 원활해졌습니다.

그리고 중간중간에 팀끼리만 식사를 하는 게 아니라 다른 분들과도 함께 식사를 하는 과정을 통해서

부족한 부분이 있다면 보완하는 커뮤니케이션 활동을 진행하고 있는데요.

팀 간의 유대, 회사 인원 간의 유대가 생김으로써, 훨씬 더 의견을 낼 때도 적극적으로 의견을 내시고

반영할 수 있게 되는 효과가 있지 않았나 생각을 해보네요.

조직이 안정화되고 있다면!

6월에 입사한 이후에

리뉴얼되기 전에 시스템 곳곳에서 약간의 그 불신과 불안감이 있었다면,

지금은 전체적으로 시스템이 안정화되어가고 있는 느낌들이 생기고 있는데요.

조직도 그만큼 디자이너가 채용된 이후에

디자인 안정감이 생기고,

또 개발자 분들이 채용되면서, 개발에 대한 미래에 대한 믿음들이 생기면서,

현재 시스템들이 개편되는 것들이 가시적으로 보이고 있습니다.

조직이 안정화되어감을 통해서, 새로운 채용,

혹은 기타 다른 시스템들을 바꾸는 것들에 대한 기대감들이 생기고 있는데요.

이것은 현재 회사 내의 조직분들의 사기를 넘어서,

기타 다른 회사들에서 저희 회사에 가입을 하거나 함께 하려고 하시는 분들의 입장에서도

긍정적인 변화의 시그널들이 보이고 있습니다.

CTO로써 역할이라고 한다면, 조직에게 안정감을 부여하고, 또한 미래에 대한 가치를 함께 심어주고,

또 한배를 탄 사람으로서 좋은 제품에 대해서 가능한 방향성을 지속적으로 가치를 주어야 한다는 생각을 해봅니다. 새로운 사람을 뽑을 때는 늘 두려움이 있습니다. 그리고 새로운 사람이 합류하게 될 때도 두려움이 있죠.

해보지 않은 것들을 해야 합니다.

기존에 해보지 않은 것들을 했던 경험과 함께, 세우는 비전.

더 좋은 사람들이 합류할 수 있는 신호가 아닌가 생각을 해봅니다.

내년의 비전 세우기

다양한 회사의 목표가 있습니다.

모두 공유할 수는 없지만,

지금의 회사에서 함께 회사의 시스템을 사용하고 있는 회사입장에서

더 오류가 없고,

좋은 서비스가 되게 하기 위해서 다양한 비전들을 수립해 나가고 있습니다.

고객 대면의 사용성이 강화되고,

회사 기업 담당자들의 사용성이 강화되고,

여러 회사와의 연동 포인트가 늘어나고,

서비스는 더 좋아지게 될 것입니다.

CTO의 역할 중에 하나는 어떻게 하면 더 좋은 제품들을 만들 것인지,

그리고 사용자들이 그 제품을 경험할 때 어떤 가치를 줄 것인지,

그리고 이 제품이 활용이 되었을 때, 비용이 아깝지 않은지 들을 점검하는 역할을 넘어서,

회사가 어떻게 하면 지금보다 훨씬 더 성장하게 될 것인지를 함께 고민하는 게 아닌가 싶습니다.

채용으로써 다양한 사람을 만나기도 해야 하고,

기술적으로써도 부채가 없는 서비스를 구사해야 하고,

현재의 서버 환경에서, 죽지 않는 서비스, 지속 운영 가능한 서비스를 만들어야 하고,

사용자들이 안전하게 안심하고 사용할 수 있는 서비스를 만들어야 합니다.

그런 서비스를 만들기 위해서, 기존의 제품을 계속 점검하고,

보완하고, 관련된 부족된 부분을 채워야 합니다.

시간적으로 분명히 부족합니다.

좋은 사람들이 있더라도, 운영하는 업무적 한계도 분명합니다.

그럼에도 불구하고, 이런 상황 가운데, 장기적 목표와 단기적인 목표들을 수립하고,

하나씩 미션을 클리어해 나가는 과정을 통해서,

결과적으로는 우리가 원하는 서비스의 품질과 퀄리티가 되었을 때,

고객은 그저 사용을 만족하는데 그치지 않고,

품질이 좋은 퀄리티의 제품을 다른 사람들에게 알리는 효과를 기대해 봅니다.

어려운 부분은 없었는지?

초기에 너무 잘한 것과 잘된 이야기만 해서,

어려움에 대한 내용을 이야기를 하지 않았네요!

우선 이름이 널리 알려진 회사의 이름이 아니기 때문에 채용을 하려고 해도,

어떤 좋은 조건으로 이야기 해도, 사실 그 회사에 갈만한 충분한 동기부여가 되지 않았기 때문에

채용상의 어려움이 많이 있었습니다.

지금은 이력서도 들어오고, 면접도 진행하고 해서, 진행이 되어가고 있지만,

초기에 회사의 홈페이지도 그렇지만,

알려지지 않은 회사에서 다른 회사보다 더 큰 베네핏을 주어야 이직을 결심하게 되는데,

그걸 외부적으로 알리기 어려운 상황에서 그런 채용에 있어서 걱정과 고민이 동일하게 있었습니다.

물론 커뮤니티를 운영하는 입장에서, 다양한 사람들과 만날 접점 포인트가 도움이 되어었던 것도 사실이고,

또 통해통해서 이력서를 넣는 경우들도 생겨서,

지금은 채용에 있어서는 안정적으로 흘러가고 있는 듯 하네요.

기존에 레거시 시스템, 이 시스템에 대한 이해도가 부족한 상황에서 프로젝트를 들어가야 하는 순간이 되었을때, 이것들을 어떻게 처리할 것인지에 대한 명확한 기준이 없는 상황에서 현재 돌아가고 있는

시스템의 중요도와 연동에 대한 이해, 그리고 고객에 대한 성향을 좀 진성으로 듣고 이해하기 까지의 시간이 걸렸는데요. 이 부분에 대한 파악이 어려운 부분이 아니었나 생각해보네요.

그리고, 도메인의 전환으로 노무사가 하는 역할이 무엇인지에 대한 정의 부분도,

명확하지 않은 상태로 업무를 시작했는데,

한동안 서칭을 통해서 노무사 협회, 노무사 사이트, 노무사들이 하는 일등등, 어떻게 노무사가 돈을 버는지, 노무사의 수익구조는 무엇인지, 노무사에서 어떤 입장들이 존재하는지, 노무법이 무엇인지 등등

노무사와 관련된 공부도 빼놓을 수 없었던 것 같습니다.

새로움에 있어서 미리 알아야 조금 편해지는 것들이 있는데 그것들을 학습하는데

시간을 들여야 한다는 부분도 약간의 어려움들로 작용한 것 같아요.

지금은 충분한 시간이 흘러서, 구조적인 부분에 대해서 많은 이해가 동반 되어서,

의사 결정에 있어서 제반 사항과 함께 결정할 수 있게 되었지만, 그런 이해가 부족하다면,

또 많은 문제가 생기지 않았을까 싶기도 하네요.

마치며

2022년

6개월이라는 남짓의 시간이었지만,

나름대로 새로운 곳에서 적응하면서,

지금의 수준에서의 괜찮은 제품을 만들기 위해서 계속 달려왔는데요.

새로운 회사에서 새로운 업무에 적응하는 것만으로도 쉽지 않을 수 있습니다.

새로운 도메인을 경험한다는 것은 어려운 일이죠.

기존의 아이들과 선생님을 연결해주는 유아동 플랫폼에서,

인사팀의 인사/근태/근로계약서들의 인사 업무를 편리하게 만들어주는 SaaS 플랫폼으로의 전환,

결코 도메인을 넘나드는 일이 쉬운 일은 아니지만,

새로운 프로젝트를 진행할 때마다, 기존의 경험들은 어떤 선택에 있어서

빠른 선택을 할 수 있도록 의사결정의 과정을 단축시켜주는 것은 분명합니다.

2023년,

도약의 한해를 기원하면서,

이상으로 2022년 회고를 마쳐보도록 하겠습니다!

다양한 업무를 하고 계시고, 고군 분투 하고 계신 CTO 님을 비롯한 많은 분들께

한번 이 글을 드려봅니다.

미래에 CTO가 되고자 하는 분들은 CTO가 어떤 역할을 하는지, 어떤 일을 하는지도 미리 점검해 보는 시간을 가지면 좋을 듯싶네요~!

감사합니다.

안녕하세요.

일전에

아이들랩 — 아이고고 앱의 CTO로 재직했던

배진호입니다.

B2B 기업에서

B2C 기업의 CTO로 경험했던 이야기들을 정리해보고,

회고해보는 시간을 가지려고 합니다.

모든 일에는 시작과 끝이 있고,

어쩌면 그 길이 더 길어질 수도, 짧아질 수도 있지만,

또 남는 것들은 경험들이니까요.

첫 회사는 삼성 엔지니어링의 CI 그룹에서 개발이었습니다.

회사의 그 당시 임직원은 1만 명 정도에 가까웠고,

주 고객은 최대가 만 명이었습니다.

사내에 홈페이지도 만들고, 사내 사람들을 위한 다양한 서비스들을 만들었습니다.

당시 했던 직무는 인사팀 업무, 사내 EP 서비스 운영/개발 업무,

상담 센터 관련 홈페이지 유지보수 및 개발, 사내 블로그 개발 및 유지보수,

IT 자산 관리 개발 업무, 전사 모니터링 시스템 개발에 참여 등등

메일링 및 메신저 연동, 사내 클라우드 서비스

전사적으로 필요한 업무들을 주로 수행했는데요.

그러나 보니 사내에 중요한 시스템과 관련된 업무들이 주축을 이루었고,

대부분의 시간들을 이런 시스템을 분석하고,

이해하는데 주 시간들을 보내었습니다.

하나의 사내 서비스를 론칭하기 위해서는 3개월, 6개월 등등 그런 시간들을 배정하고 할당했었는데요.

첫 스타트업이었던, 스튜디오 봄봄, 그리고 지난 회사였던 아이들랩에서는

B2C로써 B2B와는 다르게 생각해야 할 것들이 많이 있었고,

그 결과 다양한 시도들을 해볼 수 있었습니다.

제가 오래전

https://brunch.co.kr/@chickenmoim/9

06화 앱이냐, 웹이냐 그것이 문제로다.

스타트업, 개발자들의 첫 단추의 기로! 어떤 서비스부터 해야 할까?! | 지금 시대는 웹과 앱으로 서비스는 거의 양분할 되어 있습니다. 경중을 논하긴 애매하지만 분명한 것은 이 선택의 기로는

brunch.co.kr/@chickenmoim/9

이런 문제를 화두로 던진 적이 있습니다.

당시 전 웹 개발자로서, 시장의 변화가 앱에 있다고 생각을 했고,

앱 개발자로 전직을 해야 하는지까지도 고민을 했던 부분이 있었는데요.

아이들랩에서 지난 2년간 했던 것들과

그리고 그 결과들에 대해서 이야기해보겠습니다.

앱으로의 첫 진입

처음 아이들랩의 입사는

기존 프리랜서를 하다가 대표님의 제안으로 입사를 했었습니다.

당시 40세가 되기 전, 스타트업, B2C로서의 성장을 경험해 보는 것에 대해서 무척이나 심취해 있었는데요.

연봉은 크게 중요하지 않다고 생각을 했었고, 그런 부분은 상관하지 않고, 회사에 참여하게 되었습니다.

회사에서는 당시 앱이 없었고,

모두 웹으로 돌아가고 있었고, 웹으로 결제가 이어지고 있었습니다.

참고로 아이들랩에서 개발한 서비스는 아이 고고입니다.

아이고고는 부모와 선생님을 이어주는 서비스입니다. 특히나 보육적인 부분보다는 교육적인 부분에 강점이 있고, 튜터님들은 다양한 클래스를 만들 수 있는 선생님들입니다. 아이 키우는 입장에서, 원어민, 발레, 수학, 코딩 등등 집으로 찾아오는 서비스가 많지 않은데, 일종의 프리미엄 선생님들로, 선생님들이 집에 찾아오는 독특한 서비스를 하고 있었습니다.

제 생각에는 너무나 좋은 서비스고 미래적인 서비스인데, 알려지지 않았기 때문에 아직 성장에 대해서 가능성이 많다는 생각을 했었고, 함께 개발을 시작했는데요.

첫 고민은,

앱을 만들 것인지, 말 것인지였습니다.

제 입장에서, 기존에 없던 것을 만들어야 하는 부담감이 있었는데요.

조금 더 편한 생각으로는 기존의 웹을 유지 보수하고 하던 데로 그냥 하는 부분이었지만,

회사가 성장하고, 매출을 만들고, 지표를 만들기 위해서는

이 시장에서 앱을 론칭하고, 사용자를 모아야겠다는 생각이었습니다.

그 결과

https://brunch.co.kr/@chickenmoim/21

리엑트 네이티브 개발 경험기

웹 개발자로서 앱을 만들어야 한다고 말했다. | “React Native” VS “Flutter” 뭐가 더 쉽나요? 요새 흔하게 시작하는 멘트입니다. “그거 하면, Android, IOS 동시에 개발 가능하다면서요?” 물론 동시에 개발이

brunch.co.kr/@chickenmoim/21

이렇게 앱이 탄생합니다.

총 6~9개월이 걸렸고, 지금은 안드로이드, 아이폰 합쳐 기존 고객 대비 400% 이상 성장을 하고 있습니다.

여기서 중요한 부분은

기존에 웹으로 사용하던 고객이 앱으로 모두 전환을 하지 않으면 어떡할 것인가?

그리고 앱이 생각보다 반응이 없으면 어떡할 것인가?

웹은 광고가 앱보단 쉬운 편인데, 앱으로 어떻게 계속 lock-in을 시킬 것인가?

등등 기존 결제 플로우와 앱으로의 결제 플로우가 다른 부분도 고민해야 하는 부분이었습니다.

그리고 가장 큰 맥락이었던 채팅 시스템을 만들기.

웹으로 서비스를 할 때는 채팅 시스템이 없었습니다.

신규로 앱 서비스를 론칭할 때 부모님과 선생님을 이어주는 중요한 브리지로 채팅 시스템이 가장 중요하다고 판단을 했는데요. 그만큼 채팅에 대한 설계는 복잡하고, 공수도 많이 들어갔던 부분이기도 합니다.

특히나 리엑트 네이티브로 개발하면서, 아이폰과, 안드로이드, 그리고 웹 상에서 모든 소켓들이 자연스럽게 이어지는 부분을 테스트하고 개발하는 과정이 쉽지 않았고, 많은 테스트를 거쳤습니다.

하지만, 그 결과 채팅을 통해서, 기존에 생겨났던 업무들이 많이 줄어들게 되었고, 더 많은 사용자들이 이 앱을 통해서, 유입되고, 검색하고, 결제할 수 있게 되었죠.

B2C에서 뭔가를 개발해야 한다는 건, 시장의 반응을 살피고,

고객의 니즈를 반영해야 한다는 점이었습니다.

그 당시 함께 중간에 함께 합류해주셨던 기획자 분께서 이 많은 일들을 견인해주셨습니다.

가장 크게 감동받고 느꼈던 것 중에 하나는,

실제 고객과의 만남을 자처하셨는데!

실제로 미팅도 하기도 하고, 전화하기도 하면서, 최대한 고객의 눈높이를 맞추기 위해 적극적으로

고객 안으로 들어가셨다는 점입니다.

때로는 상담도 하시고 전화도 하면서 생기는 고객의 정확한 니즈들을 파악하고,

그게 기획이 되고, 운영이 되고, 앱으로 구현되었을 때!

그 결과들의 꽃들은 아주 천천히 서서히, 그리고 다양하게 반영됩니다. 고객의 리뷰로써, 앱의 사용성으로,

앱의 디자인으로..

b2c를 하면서 겪었던 가장 좋았던 것은 고객과 소통하고, 그 발전을 눈으로 함께 볼 수 있었다는 점이었습니다.

함께한 개발자들

작은 회사이지만,

CTO의 직무로 경험하고 생각한 것들 중 하나는 누군가와 함께 개발할 것인가입니다.

이직 후에 개발자는 대학생 개발자 1명이었습니다.

그리고 인턴으로 한 명의 개발자가 더 있었죠. 3명의 개발자가 이런 것들을 다 처리해야 한다.

당연한 스타트업 입장에서, 스타트업스럽게, 다해야 하는 상황이었죠.

개발을 어디까지 해야 하는가?

사실 CTO의 직무보다는 개발 업무가 훨씬 많았습니다. 다만, 관점을 그렇게 가져야 했죠.

대표가 바라보는 관점의 시각을 비슷하게 유지하면서도,

가능한 부분을 조언해야 했고, 동시에 개발자의 관점으로 생각을 해서 일정도 조절해야 했습니다.

자바 개발자인 동시에 리엑트 개발자가 되어야 했고

나중에는 리엑트 네이티브 개발자가 되어야 했죠.

프론트 개발도 하면서, 서버 세팅부터, 배포까지, API 개발도 해야 했고요.

나중에 서버 측 REST API를 만든 개수를 세어보았습니다. 130개 정도 되던데…

아마 이런 부분에 대해서 고통과 고민에 대해서는 아마도 아는 사람만 아는 그런 류일 것입니다.

https://brunch.co.kr/@chickenmoim/17

09화 자바 개발자에서 리엑트 개발자로 전향한다는 것

직종 전환에 대한 이야기 | 누구나 한번쯤은 다른 직종, 혹은 다른 일을 꿈꾸며 살아가는 순간이 올 수 있다고 생각합니다. 특히 이런 개발자로써 언어를 뛰어 넘어 직종을 바꾸는 일은 매우 간

brunch.co.kr/@chickenmoim/17

이런 직종의 전환과 관련된 글도 쓰고 고민도 했었죠.

아직 초기의 스타트업 대표님들, 그리고, 개발자가 부족하고 적어서, 힘들어하시는 분들,

그래도 할 수 있긴 합니다. 인원이 적다고 너무 낙담하지 않기를, 가능하긴 하다! 응원을 드려봅니다.

몇 가지 프로젝트를 진행하고서

첫 개발자는 이름 있는 좋은 기업으로 떠났습니다.

연봉도 대우도 잘 받고! 너무나 축하할 일이었죠.

하지만, 당장 앱을 개발해야 하는데, 인력이 없다는 건, 매우 힘든 일입니다.

모임을 하면서 좋은 점이라면, 좋은 사람들을 많이 알고 있다는 점이죠.

그래서 안드로이드도 개발할 줄 알고, 아이폰도 개발할 줄 아는 친구를 회사로 섭외했습니다.

이런 부분이 CTO의 직무겠죠..

다행스럽게도(?) 그 친구는 기존에 실력에 비해서 너무 좋지 않은 처우를 받고 있었고,

전 그보다는 훨씬 좋은 대우를 줄 수 있었죠. (일종의 WIN-WIN)

그 친구는 리엑트 네이티브도 할 줄 몰랐고, 리엑트도 할 줄 몰랐습니다.

따라서 리엑트 문법은 배워야 하는 상황이었죠.

뭐 저도 배워서 하는 마당이었는데, 그 친구도 충분히 가능할 것이라고 생각했죠.

그래서, 같이 배우면서 하기로 했습니다. 제가 구조는 잡아두고! 살을 같이 붙이도록 말이죠.

다행스럽게도, 안드로이드와 아이폰의 구조를 알고 있다는 건, 생각보다 리엑트 네이티브의 앱 개발의 속도를 더해주었습니다. 그래서 실제로 앱을 론칭하는데 아주 중요한 역할을 했죠.

결과적으로 런칭 완료!

다시 한번 더 짚고 갑니다.

https://play.google.com/store/apps/details?id=com.igogo&hl=en_US&gl=US

아이고고 — 우리아이 맞춤 키즈클래스 플랫폼 — Apps on Google Play

From home visits to non-face-to-face, a must-have app for parents looking for a professional teacher for each field right away!

play.google.com

https://apps.apple.com/us/app/%EC%95%84%EC%9D%B4%EA%B3%A0%EA%B3%A0-%EB%A7%9E%EC%B6%A4-%ED%82%A4%EC%A6%88%ED%81%B4%EB%9E%98%EC%8A%A4-%ED%94%8C%EB%9E%AB%ED%8F%BC/id1524244020

팀원 한 명은 그 뒤로 아쉽게

다른 회사로 가게 되었습니다.

결과적으로 다시 혼자서 개발/운영

CTO?? 팀원?? 팀장?? 인격체가 다양하게 나누어지기 시작했죠.

그 뒤로, 회사는 그래도 꾸역꾸역 계속 성장합니다.

다시 개발자를 뽑아야 하는 시점!

면접들을 다시 보기 시작했습니다. 그 결과 개발자 분들을 더 채용하게 되었는데요.

다른 직무들을 하시다가 개발일을 하려고 오신 분들이었습니다.

가장 먼저 보았던 것은,

가능성, 해보았던 것들도 중요했지만, 성장할 수 있는지,

배우고자 하는지, 그리고, 열의는 어떠한지.. 등등이었습니다.

결과적으로, 일반적인 신입을 뽑기보다는

다른 일을 하다가 직무를 전환하신 분들을 더 뽑게 되었는데요.

기존 직무에 비해서 일을 어려워하지 않을지 걱정하실 텐데,

그보다도, 이미 기존의 직무가 적성이 아니라고 판단하시고, 새로운 일을 접하시고, 열정이 있으셨기 때문에

훨씬 더 일에 대한 적응력이 빠르셨고,

다른 직무에 대해서도 이미 이해도가 있으셔서,

업무적으로도 훨씬 더 자유로운 의사소통이 가능했습니다.

개발자가, 개발만 하는 것보다, 커뮤니케이션이 가능한 상태로 개발에 임하게 되면,

업무적인 효율이 훨씬 더 증대된다고 생각을 하는데요.

그게 잘 되었다는 점이 매우 좋았죠.

업무에 관해서는

새로 오신 분들 입장에서, 프론트 직무, 서버 직무, 이렇게 정해져 있지 않았습니다.

어찌 보면 업무가 너무 많은 거 아니냐 이렇게 생각할 수도 있는데요.

결국 일의 총량이 중요한 것이지, 업무를 바꾸어서 해보는 것 자체는 중요하다고 생각을 합니다.

따라서, 저희는 리엑트쪽 프런트 개발 업무도 있었고,

리엑트 네이티브 앱 쪽 관련 프론트 업무, 그리고 서버 업무도 있었는데…

관련해서 업무들을 쪼개어서, 먼저 하고 싶은 업무들을 정하고, 거기에 서포터를 해주는 방식으로,

업무가 진행되었습니다. 한쪽에서는 서버 업무 & 서버 서포트, 리엑트 네이티브 앱 업무 & 관련 서포트..

결과적으로는 한 번씩 내부적인 교육도 진행을 했었는데요.

서버&인프라에 대해서 교육

리엑트에 대해서 교육

디비 구조에 대해서 교육

https://brunch.co.kr/@chickenmoim/11

강의를 처음 제안 받았다면?!

개발 강의를 제안 받는 것부터 강의를 오픈까지 | 안녕하세요. 현재 아이고고란 유아동 창의 플랫폼에서 개발팀을 리드 하고 있는 배진호라고 합니다.(얼마전까지는 프리랜서였는데 또 다른 일

brunch.co.kr/@chickenmoim/11

첫 강의 이후에, 몇몇 강의들을 진행하고 있는 터라!

어찌 보면, 이런 교육들이 그분들 입장에서는 조금 더 적응하기 좋았던 게 아닌가 생각이 되네요.

나중에는

앱 내에 론칭하는 한정 판매&커머스 부분을 진행하는 데 있어서

두 분이 거의 진행했다고 봐도 무방할 정도로, 잘해주셨다고 생각해요!

제가 생각하는 CTO는 매니징이 필요하면 매니징, 교육이 필요하면 교육, 개발이 필요하면 개발

회사에 기술적으로 부족한 부분이나 성장에 장애가 되는 요인들을 걷어내고,

때로는 의사 결정으로, 때로는 실제 개발로, 때로는 인원 충원 등으로 나아갈 수 있도록 방향을 만들어주고,

동기 부여하고, 또 실행하는 게 아닌가 싶습니다.

업무 효율화에 대하여

관점이라는 건 참 중요하다고 생각합니다.

보는 시각에 따라서, 아 이 회사 망하겠네? 아 이 회사 성공하겠네?

인원이 적으면, 아 인원이 적으니까, 업무로드가 적겠다, 빨리 의사 결정하고, 빨리 실행할 수 있겠다.

반면 인원이 많으면 많을수록, 개선이 어렵겠다. 산으로 갈 확률이 높겠다.

기본적으로 가지고 있는 생각들을에 대하여,

틀을 깨고 관점을 전환하는 것이 중요하다고 생각합니다.

사람들은 하는 업무가 있을 때, 그 업무가 업무로써 자연스러워서, 계속 그 경향을 가지고 그 일을 하려고 하기도 합니다.

제 첫 강의는 devOps 였습니다.

업무의 툴의 요소도 중요하지만, 가장 중요한 것은 업무에 대한 효율을 높이는 것이라고 생각했죠.

개발자로서 기존의 회사들은

배포 담당자가 따로 있었고, 문서를 쓰느라 실제로 개발에 대한 시간들이 2~3배 들어가고 있었죠.

레퍼런스 차원에서 문서가 매우 중요하다고는 하지만, 가끔은 함수에 오타 하나 수정했는데, 이걸 위한 문서를 작성할 때면, 아.. 이거 매우 비효율적이라고 생각하는 부분이 많았는데요.

따라서,

첫 번째는 배포 효율화 — 기존에 로컬에서 작업하고, 배포하던 방식을 깃의 repo를 통해서 개발 배포와 운영 배포를 나누어서, 깃에 있는 것을 내려받고 빌드하고 배포하는 방식으로 전환합니다.

두 번째는 깃과 관련된 내부 원칙 확립 — 브랜치 전략상, 너무 많은 브랜치가 주는 비효율성 때문에, 스타트업으로써 각각 내부에 개발 브랜치 르 및에 하나씩의 브랜치를 두는 방식으로, 심플한 브랙치 전략을 가져갔습니다.

세 번째는 업무 효율화

처음 회사에 와서, 알람 톡을 세팅했는데요. 상호 교차 고객이 어떤 지점에서든 알람을 받을 수 있도록 만든다. 그리고 실제 스케줄이 잡혀있을 때 알람 톡을 활용해서 진행한다.

나중에 알람 톡의 타입 개수만 20개 이상으로 늘어났는데요. 그만큼 고객 간의 브리지를 잡아서, 알람 톡을 효율화하는 작업만으로도 고객 입장에서는 편하다고 느낄 수 있는 포인트를 많이 만들었습니다.

네 번째는 슬랙 알람 활용

고객의 여러 가지 반응에 대해서,

슬랙으로 올 수 있도록 훅을 이용해서, 고객의 리뷰부터 다양한 것들을 알 수 있도록 효율화를 했습니다.

그 결과, 다양한 이슈들을 미리 발견해서 처리할 수 있었죠.

다양한 효율적인 부분들이 결과적으로 업무적인 부분의 부하를 많이 줄였다고 생각합니다.

아쉬웠던 건, 리엑트 네이티브의 빌드 배포 자동화를 하고 싶었는데,

그 부분을 못 해본 부분이 아쉬웠던 부분이었죠.

B2C 경험의 결과 — 새로운 회사

사실

아직도 아이들랩은 성장 중입니다.

날아가는 로켓에 뛰어내려서, 아쉬운 부분도 많이 있습니다.

좋은 기획자분들도 만났고, 좋은 마케터분들, 그리고 좋은 MD와 편집자,

함께 회의하고 의견을 반영하고 개진하는 대표님을 만나서 너무 좋은 시간들이었습니다.

그 결과 고객을 상대하는 다양한 방법과 개발 방식과 원칙들을 배웠고

마케팅에 대해서도 많이 배우고 성장했습니다.

회사를 이직하면서,

롤링페이퍼를 받아보기는 처음이었지만!

비밀스러운 롤링을 공개합니다.

기존 회사에서

이직하게 된 이유와 배경은

새로운 도전, 그리고 다음 회사의 이야기에서 잘 전달해 드리도록 하겠습니다!

B2C 회사의 CTO 로서 많은 제안들이 있었고,

매력적인 회사에서의 매력적인 제안이 이직 사유라고 할 수 있겠네요.

제가 해야 할 남아있던 숙제가 많이 남아있지만, 남은 분들도 너무 잘해주고 계시고,

더 잘할 수 있을 것이라고 기대합니다.

지금 회사는

인사/노무 스타트업은 많이 들어보셨죠?

노무사 대표가 만든 스타트업

어떤 회사든 근로 계약서부터 다양한 인사 업무들을 필요로 하는데요.

관련된 SaaS입니다.

https://hulam.co.kr/

휴램

노무사개발,HR프로그램,연차휴가/수당,퇴직금계산,근로계약서,법정교육확인,인사노무 리스크진단

www.hulam.co.kr

새로운 회사에서의 새로운 이야기들은 다음 글에서 이야기해볼게요!

아! 디자이너와 개발자도 뽑고 있습니다! 많이들 컨택 주세요!

요새 흔하게 시작하는 멘트입니다.

“그거 하면,

Android, IOS 동시에 개발 가능하다면서요?”

물론 동시에 개발이 가능하긴 합니다.

하지만, 꼭 장점만 있는 것도 아니고, 단점만 있는 것도 아닌데요.

앱을 론칭하고 운영하면서 겪은 경험담을 소개해드려 보겠습니다.

원래는 작년 말쯤 론칭이 끝난 직후

이 경험담을 쓰려고 했지만,

차일피일 미루다 보니 벌써 1년이나 지났네요.

원래 시스템이란 도입도 어렵고, 운영 및 유지보수도 어렵지만,

만약 또 이런 서비스를 도입하려고 하시는 분들에게는 조금이라도 더 빨리

이런 경험들이 알려지는 것이 도움이 되겠다고 생각이 되어서 다시 글쓰기를 도전해 봅니다.

앱 개발 착수 일 : 2020년 3월, 앱 론칭일 : 2020년 9월

현재 앱 론칭 이후 약 1년 3개월이라는 시간이 흘렀는데요.

앱의 개발 시작 이야기부터 현재의 앱이 되기까지의 다양한 이야기를 해보도록 하겠습니다.

리엑트 네이티브를 선택한 이유

우선 전 리엑트 개발자가 아니었습니다.

회사에 이직 후에 리엑트를 1~2달 정도 했고, 2019년 10월 이직한 이후로

처음 아이들랩 회사에서 있던 시스템을 익히고 점검 후에 앱 개발에 착수한 건 약 4~5개월 지난 후입니다.

한창 Flutter 가 뜨기 시작한 시점이었고,

현재 웹 서비스만으로 돌아가던 회사의 서비스를 고도화할 필요성을 느끼고 있었습니다.

물론 웹만으로도 서비스의 정체성을 계속 유지하면서 성장을 할 수는 있지만,

모바일에 대한 사람들의 충성도. 그리고 그 편리함을 고려했을 때, 장기적으로 회사가 큰 도약을 하기 위해서 결단이 필요하다는 생각을 했습니다.

과거 앱을 론칭한 경험에 전 스타트업에서 앱을 유지 보수하면서 앱을 관리해본 경험 등을 토대로,

앱을 만들어야겠다고 생각을 했고,

이를 착수하기 위해 자료 조사 및 선택을 하기로 했습니다.

Flutter의 장점은 Dart라는 새로운 언어, 그리고 구글이 서포트해준다는 점, 그리고 나온 지 얼마 나오지 않아서 핫하다는 점 등등이 장점이었고,

리엑트 네이티브의 경우는 시장에 나온지는 그래도 2~3년 정도 되었다는 점, 페이스북이 관리를 좀 잘 안 한다는 점이 단점이라는 대략적인 상황 판단을 하였고, 그리고 리엑트의 언어와 언어적 기반이 매우 흡사하다는 지점이 눈에 들어왔습니다.

자원이라는 건은 늘 한정적 자원 안에서의 최대의 효율을 고려해야 합니다. 제가 이 스타트업의 입사 당시 개발팀의 인원이 몇 명 되지 않았다는 지점에서 앱을 만들기로 결심하는 것은 매우 어려운 일이었습니다.

하지만, 새로운 언어에 대한 도전, 그리고 그 결과가 기대가 되었기 때문에 웹이 어느 정도 안정화된 이후에 개발을 시작하기로 합니다.

리엑트 네이티브를 선택한 가장 큰 이유 중 하나는

https://reactnavigation.org/docs/getting-started/

reactnavigation.org

reactnavigation.org

였습니다.

앱의 구조가 탭의 형태를 띠고 있는데, 탭의 구조를 라우트의 느낌으로 자유자재로 앱 내에서 이동을 가능하게 하는 구조를 찾고 있었는데, 마침 이 리엑트 내비게이션이 업그레이드 소식이 있었고,

5 버전을 적용해보면 딱 좋겠다는 생각이 들어서, 레퍼런스가 부족하기는 했지만,

이 라이브러리의 선택의 지금의 앱을 선택하게 된 결과 인듯하네요.

그리고 Flutter에 비해 라이브러리가 많아서 디자인을 커스텀하기에 좋다는 생각도 들긴 했는데,

사실 충분히 Flutter도 현재는 다 가능해지게 되지 않았을까 생각해 보긴 합니다.

expo와 리엑트 네이티브

첫 리엑트 네이티브의 프로젝트는 expo로 테스트를 하고 진행을 했는데요.

expo로 한 달 정도 진행해보니, 리엑트 네이티브 클리로 한다고 해도 큰 차이가 없을 것 같다는 확신이 들었습니다. expo는 처음 리엑트 네이티브를 시작하는 사람에게 조금 더 접근하기 쉬운 툴입니다. 심지어 안드로이드나, 아이폰 빌드가 없더라도, 실행해볼 수 있고, 웹으로 화면을 볼 수 있다는 것이 가장 큰 장점인데요. 리엑트 네이티브 클리의 경우는 이런 expo에 비해서는 조금 더 기기를 세팅해야 한다던지, 안드로이드 스튜디오나 XCode 같이 안드로이드, 아이폰 빌드 툴이 있어야 해서 약간은 난이도가 더 있다고 볼 수도 있습니다. expo가 쉽다고는 하는데, 보니까, 여러 가지 라이브러리를 적용하는데도 문제가 있고, 웹으로 볼 수 있는 점이 장점이라고는 하는데, 특별한 점이 없어 보였어요.

그래서, 앱을 개발하는 상황이 더 커지고 어려워지기 전에 eject을 해야 한다는 이야기가 많이 있어서 실행하기로 합니다.

과정은 간단한데요.

명령어 : expo eject

이라고 실행하면 됩니다. 다만 안드로이드 폴더와 아이폰 폴더를 확인하고, 안드로이드 스튜디오에서 잘 빌드가 되는지, 아이폰에서 잘 빌드가 되는지를 확인해야 하는 이슈가 있었죠.

이렇게 eject 명령어를 사용하면, 기존에 개발해 놓은 expo로 짜여진 소스를 리엑트 네이티브 클리를 이용해서 빌드할 수 있도록 소스들을 변경해줍니다. 애초에 처음부터 리엑트 네이티브 클리를 이용해서 작성했다면, 이런 고민을 할 필요가 없지만, 조금 더 쉽게 리엑트 네이티브를 사용하기 위해서 expo를 사용한 사람들의 경우는 이 결단을 해야 할 필요가 있습니다. 조금 더 주요한 차이라고 한다면, expo에서도 라이브러리를 사용하고 리엑트 네이티브에서도 라이브러리를 사용하는데요. 이게 expo에서만 사용 가능하고 지원 가능한 라이브러리도 있고, 또 리엑트 네이티브에서만 사용 가능한 경우도 있고, 경우에 따라서는 라이브러리가 되고 안되고의 차이가 있어서, 한 방향으로 하게 되면, 계속 그것을 이용해야 한다는 점이 있습니다. 이 점을 참고하고 개발을 시작하면 됩니다.

socekt js 적용하기 (채팅 서비스 구축)

지금 생각해보면,

그때는 어떻게 서비스가 유지될 수 있었는지 궁금할 정도로,

채팅 서비스를 통해서 현재의 고객들이 대화하고 결제하는 시스템이 잘 동작하고 있는데요!

첫 웹 서비스에서는 고객은 채팅 없이도 결제했었습니다! 그게 더 대단!!

리엑트 네이티브에서 웹소켓을 사용할지, 다른 라이브러리를 사용할지를 고민했었는데요.

https://socket.io/ 를 적용해서 채팅 서비스를 구축했는데요.

해당 서비스는 이미 잘 알려진 라이브러리이기도 하죠!

다만 구축을 하는 입장에서는 해당 예제만으로는 한계가 있었는데요.

문제를 해결하는 게 또 역할이다 보니, 여러 가지로 애로사항이 많았습니다.

또한 함께했던 동료가 있어서 해결해 나갈 수 있었죠!

기존 채팅 화면 -> 현재 채팅 화면

채팅에 대한 설계 부분을 따로 말할 수는 없지만!

쉽지는 않았어요! 두 가지 기종의 안드로이드와 아이폰, 그리고 웹에도 채팅을 가능하게 해야 하는 것과

기존에 있는 서비스 부하를 주지 않기 위해서 따로 구성하는 부분 등등

채팅 서비스가 시작되고 나서

현재 지금의 서비스가 구성이 될 수 있었고,

지금은 이 채팅이 없다면 어떻게 서비스가 돌아갈 수 있을지 상상할 수 없네요!

6개월간의 론칭 여정(시간의 촉박함)

앱을 개발한 시간은

물론, 지금까지도 계속 개발 중이긴 합니다만,

2020년 3월 ~ 2020년 9월 총 6개월 정도 앱에 본격적으로 개발을 시작해서, 론칭까지 걸린 시간입니다.

9월에 오픈을 하긴 했지만,

그 당시에는 약간 허름한 면모도 갖추고 있었습니다.

기능도 많이 빠져있어서, 가게는 오픈했는데, 재료가 좀 부족한 상황이었고,

약간 분주한 느낌이 많았습니다.

하지만, 그 6개월은 어떻게 시간이 흘러갔는지 모르겠네요.

로그인도 해야 하고, 로그인 유저의 계정 정보를 어떻게 해야 할지,

기존에 시스템과 앱과의 연동 상황을 고려해야 하고,

결제도 해야 되고, 채팅도 해야 되고, 저희의 클래스 정보도 예쁘게 보여주어야 하고…

할 일은 정말 끊임이 없습니다.

앱을 개발하거나 서비스를 운영하거나, 뭔가를 시작하려고 계획 중이신 분이라면,

정말이지 모든 것들을 다 하고 싶으실 거예요. 하지만, 그러려면, 끝이 없다는 사실…

따라서, 뼈대를 세우고, 정말 필요한 것만을 우선적으로 설정해서 시동을 건다는 것이 중요하죠.

저의 경우는 백엔드 세팅 및 서버 API도 직접 만들었기 때문에,

프런트에만 에너지를 쏟을 수는 없었는데요. 분산된 상황과 제한된 시간,

나중에 API개수만 100여 개가 넘는 것을 보고…..

결국에는 론칭을 하긴 합니다! 결제도 일어났고요!

6개월이라는 시간은 꽤나 오랜 시간 동안 기억할 것 같은 날이네요.

함께 고생한 영혼을 갈아 넣어준 친구에게 다시 한번 박수와 찬사를 보냅니다.

놀랍게도 이 앱을 2명이 초기에 만들었고, 그 친구는 안드로이드/아이폰 개발을 했던 친구였는데,

현재는 리엑트 네이티브로 안드로이드와 아이폰 둘 다 자유자재로 개발이 가능해진 상황입니다.

그리고 지금은 조금 더 팀원이 늘어나서,

개발 및 유지보수가 가능해진 상황인데요!

지금의 앱은 실력 있는 디자이너의 합류로 훨씬 더 보기 좋아지고 예뻐진 상황입니다. (물론 기존에도 잘해주셨지만! 충분히 앱이 론칭된 이후에 생각과 고민이 디자인으로 녹아지다 보니 또 새로운 앱이 된 느낌이에요!)

초기 화면에 비해서 앱이 너무나 예뻐지고 기능도 많이 개선된 모습입니다.

웹 서비스와 앱 서비스의 특징(빌드의 어려움)

제가 웹 개발을 하다,

앱 개발 서비스를 리드하고, 함께 개발하다 보니,

겪게 된 고민과 이슈들이 있었는데요.

웹의 경우는 npm install이나, 의존성의 문제 때문에 업그레이드하는 경우에 여러 가지 문제들에 직면했었는데요.

앱의 경우는 해당 부분의 모듈과 의존성에 대해서, 빌드 툴에서 설치 시에 정상적인지를 체크하는 첫 번째, 그리고 안드로이드에서 빌드되고, 정상적으로 화면에 나오는지에 대한 두 번째, 마지막으로 아이폰에서 개발된 결과물이 동일한지, 그렇지 않은지에 대한 3번째 단계를 체크해야 하다 보니, 어려움이 많이 있었습니다.

특히나 카카오나 네이버 로그인의 경우, 로컬에서 빌드하고, 체크해보는 것을 테스트하는 환경이 부족하기 때문에 실제로 론칭 한 뒤에야 문제를 발견하게 될 수도 있고,

해당 부분을 테스트하는 과정이 무척 어려웠기 때문에 해당 공수에 대한 시간이 많이 들어갔었는데요.

그 과정 이후에 해당 문제가 해결될 수 있었습니다.

안드로이드의 경우

안드로이드의 경우는 gradle 파일에서 모듈을 추가해주거나 빠지는 부분을 체킹 하는 부분에 시간이 들었습니다. 따라서 빌드 이후에도 여러 가지 문제가 생길 수 있는데, 꼭 테스트를 다 거쳐야지 문제가 있는지 없는지를 확인할 수 없었기 때문에 빌드 이후가 중요했습니다.

아이폰의 경우

대부분의 경우는 큰 문제가 없었는데요. 리엑트, 리엑트 네이티브 버전에 따라서 pod 파일의 문법들이 조금씩 달라지는 부분이 있었는데, 의외로 이 부분에서 막혀서 시간을 잡아먹은 케이스가 좀 있던 것 같습니다.

그래서, 특정 버전과 모듈을 업그레이드하기 위해서는 또 다른 부분을 살펴보아야 하고, 또 너무 업그레이드를 하는 경우, 또 다른 모듈과의 충돌 문제가 발생하는데요.

그 과정에서 node_modules 폴더를 얼마나 많이 지웠는지 모르겠네요.

그리고, 의존성의 문제라던지 아이폰에서는 서로의 라이브러리의 이름이나 h파일을 못 찾아서 꼬이는 경우들이 종종 있는데, 이런 문제로 pod install 이후에도 라이브러리를 세팅하는 과정이 쉽지가 않습니다.

이런 과정을 겪다 보면, 아… 그냥 네이티브가 낫다. 그냥 이렇게 고구마를 먹느니, 그냥 네이티브로 개발하고 만다라는 소리가 절로 나오는데요.

만약 리 엑트 네이티브 개발자가 한숨을 쉬면서, 뭔가 욕하고 있다면 이런 상황이라고 생각해 주시면 되지 않을까 싶네요…

결과적으로는 이런 과정이 옆에서 보기에는 비효율적으로 보여도, 이런 과정이 끝나고 나면 화면을 그리거나 안드로이드나 아이폰을 동시에 변경할 수 있다는 장점이 기다리고 있습니다!

리엑트 네이티브 개발 시 어려운 점(유의사항)

웹을 개발하다가 리엑트 네이티브 개발 시에 참고할 부분, 혹은 안드로이드나 아이폰 네이티브를 하다가 리엑트 네이티브를 해보려고 할 때 참고할 점들을 말씀드려볼게요.

리엑트 문법이 필요

제가 리엑트 네이티브를 선택한 이유 중 하나가 리엑트를 조금 경험했다는 이유였는데요.

실제로 리엑트 네이티브를 개발하기 위해서는 리엑트 문법에 대한 지식이 필요합니다.

따라서 처음에 리엑트에 대한 구조적인 지식이나 앱 설계 경험이 동시에 있어야 한데요. 안드로이드 개발이랑 아이폰 개발도 개발 스타일이 많이 다른데, 리엑트까지 또 공부해야 한다는 생각이 들 수 있습니다. 그러니 리엑트를 경험하지 않은 개발자 입장에서는 당연스레 거부감이 들 수 있습니다.

타입 스크립트 지식

기본적으로 파일명이 jsx도 아니고 tsx 파일입니다. 타입 스크립트에 대한 이해도 전반적으로 깔려있어야 합니다. 사실 타입에 대한 정의를 미리 해주어야 한다는 부분을 제외하고는 문법적으로는 크게 다르진 않은데요. 만약 웹의 소스를 활용해서 앱을 만들어보겠다. 이건 좀 다릅니다. 새로 만들어야 하는 부분이 많아요.

웹과 앱을 동시에 할 수 있나요?

처음에 리엑트 네이티브를 만들 때 은근 이 질문도 많고 오해도 많은데요. 그 이유 중에 하나가 expo를 사용하는 경우 웹으로도 표기할 수 있기 때문인데요. 그 부분이 조금 더 편리하게 화면상에서 웹상에서 모바일 느낌으로 개발할 수 있도록 도와주는 역할을 하긴 하지만, 실제로 이것을 웹 서비스의 형태로 적용하게 하기에는 여전히 문제가 많이 있습니다. 첫 번째는 UI/UX 부분인데요. 전통적인 웹 모바일의 형태와 앱 서비스의 형태가 다르기 때문인데요. 기존에 웹의 경우는 상단 뒤로 가기가 가능하고 조금 더 가벼운 느낌입니다. 그리고 메뉴 바를 통해서 원하는 메뉴로 쉽게 접속하는 게 조금 더 편리한 반면, 앱에서는 탭 바를 통해서 접근성을 한정하더라도 앱이 안정감을 느끼는데요. 모바일 웹으로는 그렇게 진행하기에는 약간 어울리지 않는 측면이 있습니다. 이런 디자인이나 설정 부분도 문제가 있습니다. 마지막으로 리엑트 네이티즈 자체의 소스의 실행이 기본적으로는 react-native run-android, react-native run-ios 이 두 명령어만 보아도 웹을 지원하지는 않고, 안드로이드와 아이폰만 지원하는 것을 알 수 있는데요. 따라서 리엑트 네이티브로 개발한다는 것은 그냥 앱을 만들기 용이한 수준이라고 생각하시면 좋을듯하네요.

다만, 웹으로 이런 문법적인 부분이 비슷하기 때문에 활용할 충분한 가치는 있습니다. 따라서, 웹을 개발하기 위해서 리엑트 네이티브 개발자를 뽑는다고 하면, 조금은 어폐가 있는 것이겠죠! 따라서 웹 개발자와 리엑트 네이티브 개발자를 따로 뽑는 것을 추천합니다.

엠플리튜드 붙이기 (마케터와의 협업)

이런 서비스를 개발하고 나서는 후속 절차도 중요합니다.

A/B 테스트라고 하죠! 고객이 원하는 것이 무엇인가?

고객에게 설문이나 전화 등 등으로 많은 것들을 얻어내려고 하지만, 사실 고객도 모르고, 우리도 모르고, 서로가 형태 없는 무형의 서비스를 하다 보니, 진짜로 원하는 것에 접근하는 것이 쉽지는 않습니다.

거기에서 가장 중요한 것 중에 하나가 고객의 여정을 파악하는 일입니다.

그 일중에 하나가 엠플리튜드를 붙이는 것인데요. 웹으로 따지는 GA 구글 애널리틱스를 많이 붙입니다.

마찬가지로, 엠플리튜드를 붙이기 위해서는, 고객이 어떤 경로로 유입되었고,

어디를 선택하고, 어디를 누르고, 어디에서 결제가 일어나는지 파악하는 게 중요하겠죠!

그 여러 가지 항목들을 세팅하고, 앱 안에 붙여야 합니다. 이런 엠플리튜드를 적시 적소에 잘 붙이는 것도,

이번 프로젝트를 통해서 배운 점이라고 할 수 있겠네요!

이렇게 프로젝트를 진행하고, 인자 값을 넘기다 보면, 간혹, 이런 엠플리튜드에 넣는 인자 값들을 잘못 세팅하는 경우도 있는데, 그럼 버그로 이어지기도 합니다. 따라서, 그냥 가볍게 세팅한다고 생각하지만, 조금 더 꼼꼼하게 볼 필요가 있겠죠!

서비스 고도화를 위한 알람톡 연동 작업 (스케줄과 넛지)

프로젝트가 끝나고 진행되었던 것 중에 하나는 알람톡 연동 작업입니다.

고객과 만나는 지점은 엄청나게 많습니다!

저희 서비스의 핵심이라고도 할 수 있기 때문에 모두 나열할 수는 없지만,

서비스를 더 안정화하고, 고객과 만나는 지점들을 잘 설정하기 위해서는 이런 알람 톡이라던지, 넛지를 주는 장치가 필요합니다.

따라서, 이런 데이터 바인딩과 연동 작업이 쉽지는 않았는데요!

기존에 알림톡 업체에서도 자바나 다른 언어로는 되어있었지만, 리엑트로 연동하는 사람이 없었기 때문에

레퍼런스가 없었어요.

그래도, 한번 해보자는 마음으로, 연동을 시도해보았는데!

연동이 되더군요! 팁 중 하나라면, 제공해주는 코드가 제한된 언어라고 할지라도!

우리 언어가 없더라도 시도해보면 될 수 있다는 점입니다.

그리서 초기에 소통에 약간의 어려움은 있었지만,

한번 뚫리면 그 뒤는 쉽죠! 알림톡을 공통 함수로 만들어 두고는 다양한 서비스에 연결하는 과정 성공!

알림톡도 그 간에 서비스 안에 중요한 성과 중 하나입니다.

특출 난 에디터 분들이 멘트를 가다듬어 주셔서, 지금의 아이고고 멘트들이 만들어졌네요!

디자인 변경 및 검색 고도화 (클래스 검색이 더 쉽도록)

앞에도 살짝 언급했지만,

뛰어난 디자이너의 합류로 아이고고의 디자인은 조금 더 예뻐졌는데요!

동시에, 수업 유형과 교육 분야, 연령 및 지역 등등을 함께 검색할 수 있도록 검색이 고도화되었습니다.

아이고고는 일전에 이미 당근 마켓과 함께 작업을 진행한 일이 있는데요!

기사 한번 보고 가겠습니다.

https://www.news1.kr/articles/?4336188

당근마켓, 내 근처 아이 ‘맞춤형 수업’도 중개한다

사실 앞에 겸손한 민영 종합 뉴스통신사 뉴스1

www.news1.kr

https://www.newstomato.com/ReadNews.aspx?no=1051145

당근마켓, 키즈클래스 플랫폼 ‘아이고고’ 오픈

www.newstomato.com

http://it.chosun.com/site/data/html_dir/2021/06/11/2021061101436.html

당근마켓, 지역기반 어린이 클래스 매칭 서비스 선봬

당근마켓은 11일, ‘내 근처’에서 지역 기반 키즈 클래스 매칭 서비스 ‘아이고고’를 이용할 수 있다고 밝혔다.아이고고는 5~13세 유아동을 대..

it.chosun.com

이렇게 다양한 기사가 나왔는데요!

당근 마켓이 이런 로컬라이제이션에 기반한 중고 거래 앱이라면,

저희는 이런 지역에 기반한 키즈 클래스 매칭 앱입니다.

이 서비스를 론칭하기 위해서도 꽤 많은 시간을 들여서 론칭을 했었는데요!

아이 고고에서도 키즈 클래스를 찾을 수 있고,

당근 마켓에서도 키즈 클래스를 찾을 수 있다! 이색적인 조합이었던 건이었죠.

저희는 지역 안에서 부모님들의 입소문으로 조금씩 더 성장하고 있습니다.

리엑트 네이티브 개발자를 찾는 팁이나 노하우

아마도 이 글을 보고 계신 분들 중에는

개발자나 학생으로서,

리엑트 네이티브로 앱이 어디까지 성장할 수 있는지를 궁금해하셔서 이 글을 보고 계신 분들도 많겠지만,

스타트업의 대표로서, 혹은 앱을 개발하려고 하는 분들 중에서,

리엑트 네이티브로의 개발과 함께, 어떻게 그런 개발자를 찾을지 고민하시는 분들이 있을 것이라고 생각합니다. 몇 가지 팁을 말씀드려보겠습니다.

먼저, 리엑트 네이티브를 처음부터 시작해서, 전향하고, 그렇게 개발자를 하고 계신 분들이 그리 많지는 않다고 생각합니다. 즉 리엑트 네이티브를 뽑으실 때, 리엑트 네이티브 연차를 7년 차 10년 차 이렇게 높게 설정하시면 안 됩니다. 즉, 저도 리엑트 네이티브만 따진다면, 2~3년밖에 안 되겠네요. 즉, 리엑트 네이티브로 앱을 론칭하거나, 만들어본 경험이 있는가? 이 정도면 조건은 충분하다고 생각합니다. 그럼 그다음으로 필요한 것은, 비슷한 앱, 비슷한 다른 프로젝트, 혹은 전체적인 개발에 관련된 연차수나 경험으로 비추어서 찾아야 가능하다고 생각합니다. 즉, 업계에 나온 지 얼마 안 된 기술을 연차라는 것으로 실력을 측정하거나 연봉을 측정할 수 없다는 것이죠. 이제는 프론트로 넘어가면 프런트 경력부터 다시 1년 차, 서버로 넘어가면 다시 서버에서 1년 차, 앱으로 넘어가면 앱에서 1년 차 이렇게 하면서, 경력을 깎아내릴 수는 없습니다. 이제 대 통합의 시대.. 이것도 하고 저것도 하고, 이것저것 한 개발자들이 늘어나고 있죠. 그런 다양한 경험과 경력을 갖춘 인재를 섭외하기 위해서는 개발 전체 경력을 경력으로 보아야 합니다. 이게 첫 번째입니다.

두 번째는 리엑트 네이티브 경험이 없는 사람이 없을 때는 누굴 뽑아야 하는가입니다. 안드로이드만 했던 사람을 뽑아보기도 했고, 리엑트 경험만 있는 사람을 뽑아보기도 했는데요.

일단, 리엑트 네이티브 경험이 있는 사람이 회사 내에 일단 1명은 있어야 합니다. 그 사람이 전파한다면 충분히 가능합니다. 다만, 그런 경험 있는 사람이 한 명도 없다면, 초기 세팅에 많은 시간을 투자해야 할 수 도 있습니다. 따라서, 가르칠 수 있다면, 안드로이드, 리엑트 무엇을 했든 가르치면 된다. 만약 그런 부분이 없다면, 애초에 리엑트 네이티브에 조금이라도 경험이 있는 사람이 낫다입니다.

세 번째는 리엑트, 리엑티브, 노드, 웹 등등 보다 중요한 것은 서비스에 대한 이해가 있는 개발자를 뽑는 것입니다. 즉 주니어나 신입을 뽑을 때는 이런 조건이 포함되지는 않습니다. 처음 서비스를 만들려고 할 때, 결제 서비스를 해본 적은 있는지, 개발 세팅은 어떻게 할 것인지, API를 설계해본 적은 있는지 물론 각각의 개발 역할이 있기 때문에 모든 것을 할 수 있는 사람을 뽑을 필요는 없는데요. 단순히 언어적인 부분으로 이해를 하고 있는 사람을 여러 명을 뽑는다고 하더라도, 개발에 속도가 나지 않을 수 있습니다. 보통 ‘정의’가 중요하다고 말을 많이 합니다. 서비스에 대하여 어떤 서비스를 어떻게 만들 것인지 정의가 잘 내려져야 하는데, 여기에서, 기획자나 PO 등등의 역할도 중요하지만, 그것을 개발해야 할 사람과의 의사소통이 무척 중요합니다. 이 단계에서 합의를 거치고 나서 개발에 들어가야 진짜 개발 일정이 나올 수 있고, 정상적이고, 괜찮은 서비스가 만들어질 수 있겠죠. 이런 부분을 고려할 수 있는 사람을 뽑아야 한다는 점입니다.

마지막으로 안드로이드, 아이폰 앱을 한 번이라도 론칭해 본 사람을 뽑으시는 것을 추천합니다. 물론 리 엑트만 한 사람도 리엑트 네이티브를 충분히 배워서 익힐 수 있고, 테스트로 한번 앱을 만들어본 사람도 뽑을 수 있지만, 론칭해본 사람은 론칭한 이후에 겪는 에러와 문제, 사이드 이팩트들을 충분히 체감한 사람일 수 있습니다. 즉, 문제를 겪고 그 부분을 처리해본 사람을 채용하는 것이, 문제를 겪어 보지 않은 사람을 채용하는 것보다 훨씬 더 효율적이라는 것입니다.

홈 개편 작업과 올해 도약을 준비하며

홈 개편 작업이 거의 끝이 나고 있습니다.

벌써 올해도 2월이 다 되었네요!

아이고고는 작년에도 꽤 많은 성장을 이루었는데요!

올해에도 성장을 이루기 위해서, 다양한 개발과 지점들을 만들어가고 있습니다.

좋은 분들도 꽤 많이 합류했는데요!

아이고고에 관심 가져주시고! 각 서비스들 링크드리오니 한 번씩 감상해주시면 감사하겠습니다.

아이고고 웹 서비스 :

https://igogo.kr/

아이고고 안드로이드 서비스 :

https://play.google.com/store/apps/details?id=com.igogo

아이고고 아이폰 서비스 :

https://apps.apple.com/us/app/id1524244020

‎

이상 리엑트 네이티브 개발 경험기 마치겠습니다.

안녕하세요.

거창한 제목으로 인사드립니다.

현재 작은 스타트업의 CTO를 하고 있습니다.

이 글을 쓰게 된 계기는

최근 개발자로서 미래를 꿈꾸는 많은 분들에게

도전이 될 수 있는 글을 써보고자 이 글을 쓰게 되었는데요.

풀스택 개발자라는 단어가 난무하고, 최신 기술들이 해마다 다르게 나오고 있는 상황 속에서

어느 장단에 맞추어야 하는지 갈피를 잡기 힘든 개발자들을 위해 한번 정리하는 차원으로 이 글을 작성했습니다.

그리고 막연하겠지만, CTO라는 목표를 향해서 하염없이 달려가고 있는 분들을 작게나마 응원하기 위한 바람도 있습니다.

우선 이미 다른 글들을 통해서,

이미 저를 알고 계신 분들도 계시겠지만,

이 글을 통해서 처음으로 저를 보신 분들을 위해서

간략하게 소개를 하고 글을 이어가려고 합니다.

우선 전 삼성 계열사를 통해서 삼성 엔지니어링이라는 회사에서 5년 정도 근무하고,

삼성 SDS 본사에서 ERP 업무를 1~2년 보낸 뒤에

본격 스타트업으로 이직하여, CTO로써 1~2년을 보내었습니다.

그리고 프리랜서로 SK 관련 프로젝트 리더로서 9개월 정도를 보낸 뒤,

패스트 캠퍼스 AWS 관련 강의를 한 뒤,

작년부터 아이고고란 스타트업에 합류해서 CTO로 지금까지 보내오고 있습니다.

https://igogo.kr

개발자로서 짧다면 짧고 길다면 긴 10년째가 되었는데요!

그간 많은 일들이 있었지만, CTO로써의 글을 바로 쓰기에는 부족하다는 생각이 들어서

아이고고 1년을 보낸 이 시점에서 경험담을 한번 공유드려볼까 합니다.

아직은 직원이 12명밖에 되지 않은 회사의

CTO라고 하기에 사실상 개발 팀장이라는 이름이 더 적합하지 않나 생각을 해봅니다만,

작은 회사의 CTO, 큰 회사의 CTO

이런 회사 크기의 유무와 무관하게 CTO라는 직무가 가지는 이름의 무게를 생각하자면,

CTO라 표현하며 글을 쓰는 게 맞는듯합니다.

CTO 가 되기 위해서 무엇을 해야 하고,

어떻게 해야 할까요? 우선 처음 신입사원 때로 돌아가서,

그 당시의 노력들을 떠올려 봅니다.

도약의 계기 (기회를 잡는 것)

당시 엔지니어링 초기 입사했을 때 첫 한 달간의 입사 후에 1달간 무엇을 했는지에 대해서 발표의 시간이 있었습니다. 신입 사원으로는 총 3명이 있었는데요.

3명이 각각 자기소개를 비롯한 다양한 경험들을 발표했던 것으로 기억합니다.

저는 유일하게 회사 안에서 2개의 프로젝트를 진행했다고 말을 했는데요.

지금 생각하면 너무나 유치하고 프로젝트라기엔 너무나 소소한 개발들이었습니다만,

위에서는 그런 패기 어린 모습도 좀 좋게 봐주시지 않았나 생각을 해보네요.

그 당시 기억하기로

인프라 담당자분이 맡겨주신 내부 모니터링 문자 시스템을 손보는 작업.

엔지니어링 내부의 해외 관련 사내 블로그가 있었는데요. 해당 블로그를 개발하는 작업.

인사 프로젝트 작업(토인비)

두 개의 프로젝트였고,

이 프로젝트를 통해서 배운 것들을 6가지로 정리했었습니다.

스트럿츠, 토인비, cgi, jstl, ajax, 리눅스 서버 관련 기동

물론 이 분류가 지금으로써는 맞는지 애매한 부분이 많았지만,

그 당시로서는 “뭐라도 하는 친구”라는 걸 어필하고 싶었나 봅니다.

당시 전 사내 시스템 개발을 너무 하고 싶었는데요.

인사 시스템은 규모가 조금 작고, 레거시라고 부르는 옛날 느낌의 프로그램들로 되어 있어서

다양한 설계나 개발을 경험하기엔 조금 부족하지 않나 생각을 하고 있었습니다.

(물론 추후에는 직무별로 틀리고, 신경 써야 하는 것도 많았기 때문에 간단한 게 아니라는 걸 체감하긴 했습니다. — 약간의 개인적 오해가 있었습니다)

그래서 조금은 빨리 개발을 배우고 싶은 마음에 그런 발표를 했던 것인데요.

첫 6개월을 인사 관련 개발팀에서 개발 작업을 했습니다.

그리고 발표 때문인지 운이 좋게도 몇 개월 안에 내부 포털 및 전체 시스템을 담당하는 부서로 이동하게 되었어요.

결과적으로는 사내에 있는 수많은 소스와 핵심 테이블을 까 볼 수(?) 있는 기회가 생긴 셈이죠.

인사 시스템, 사내 블로그 데이터, 마케팅 모니터링 시스템, 핵심 5대 역량 과제 블로그, 강연 시스템,

포탈 관리, 사우 협의회, 내부 CRM, oden 등 CI/CD 등등

얼추 하나의 기업에 데이터 베이스의 구성이나 구축 방식, 설계적인 측면들에 대해서 조금 더 알 수 있는 기회가 생긴 거죠.

혼자 살아남는 법

보통은 사수에 대한 환상들이 많이 있습니다.

좋은 사수를 만나면 좀 더 나아질 것이라는 기대, 그리고 그 사수가 나를 높은 곳으로 이끌어줄 것이라는 기대.

그리고 많은 것을 알려줄 것이라는 기대 등등 말이죠.

그리고 실제로 그런 사수가 간혹 존재하기는 합니다.

매주 코드 리뷰를 해준다던지, 다양한 훈련을 통해서 좀 더 고차원적인 사람이 되게 한다던지,

스터디를 매주 진행해서 조금 더 많은 것을 체계적으로 알 수 있게 해 준다던지 말이죠.

하지만 전 그런 부분과는 차원이 멀었습니다.

처음 오자마자 개발을 알려준다기보다는 개발할 일거리가 밀려 들어왔고,

인수인계와는 관계없이 바로 투입(?) 되어 일을 시작한 케이스라 실전 경험이 저의 사수였다고 할 수 있는데요. 물론 사수 입장에서는 저를 믿고 맡겼기 때문에 체계적 교육이 없이 일을 진행했을 것이라는 생각을 하긴 합니다. 그래서 조금 쉽지 않은 시간들을 보냈었는데요.

부서가 개발 쪽으로 바뀌고 처음 맡은 게 IT 자산 관리 화면을 만드는 것이었는데요.

기간은 2주, 할당받은 페이지는 14개 거의 하루에 1 페이지 정도씩을 만들어야 겨우 완성이 가능한 수준이었습니다. 선 그나마 기획서와 DB는 있었고, 신입사원으로서 이걸 처리해야 하는 압박과 인정받고자 하는 욕구 등등 서버에 대한 지식도 없고, 그저 mvc에 대한 개념적인 부분과 기존 코드를 토대로 화면을 찍어내야 했는데요.

시간이 생명인 부서에서, 뭔가를 체계적으로 물어보기란 매우 어려운 구조였고, 혼자서 소스만을 보고 이해하고 내 것으로 만들어야 하는 상황들이 계속 연출되었고…

3년이 지난 시점에 마침내 깨닫게 되었습니다.

누가 알려주는 시대는 원래 없었고, 앞으로도 없을 것이라는 것을…

내가 찾아야 하고, 내가 배워야 하고, 내가 알아야 그 넥스트가 존재한다는 것을 말이죠.

혼자로 버틸 수 있게 되니, 프로젝트 단위 업무들도 혼자 할 수 있게 맡겨 주었습니다. 일종의 기회인 셈이죠.

업무 5년 차에 갑자기, 보직이 변경됨에 따라 6개월간 차세대 관련된 프로젝트에 투입되게 되었는데요.

개발자가 총 5~7명 정도 투입이 되었는데, 막상 Faro라는 프레임 워크를 사용해서 개발을 하라는데,

모두 그 해당 지식이 없다 보니 맨땅에 헤딩을 했었는데요.

혼자 버티는 스킬로, 며칠을 홀로 삽질을 하다 보니, 그 해당 프레임 워크 관련된 지식을 그 같은 팀원들에게 공유할 수 있게 되었는데요. 이렇게 혼자 살아남는 생존법을 배우다 보니 어딜 가든 생존할 수 있는 스킬로써, 스타트업에 필요한 스킬 중 하나가 되었습니다.(물론 스타트업이라고 꼭 혼자 뭐든 다 할 수 있어야 하는 건 아니지만, 다양한 경험들은 파트를 넘나들 수 있는 자유를 허락했습니다.)

함께 하는 법 배우기

혼자 살아남는 법에 익숙해지다 보니, 문득 주변 사람들이랑 같이 어울리고, 함께 하는 것에 대해서 조금 소홀해지지 않았나 싶었어요. 그 간 소스들은 주로 svn이나 cvs로 공유를 해왔습니다. 이 것에 익숙하다 보면, git과 같은 소스 공유가 익숙해지지 않더군요. 회사 내에서 몇 번 부서를 옮기면서, 다른 사람들과 소통하고, 교류하고, 또 같이 프로젝트를 진행하기도 했었지만, 계속 그 갈증과 부족함을 채울 수 없었는데요.

수직 상하관계로써, 일을 해야 하는 상황에서는 사실해야 하는 것과 할 일, 그리고 결과만 있으면 되었기 때문에 의사소통 방식은 매우 심플하고, 오히려 일처리의 관점에서는 빠른 결과들이 도출될 수 있었어요. 하지만, 스타트업에 처음으로 가서 해야 했던 일은 의사 결정에 대해서 결정하는 일이었습니다.

어떤 일에 대해서 충분한 회의를 거치고, 그것을 할 것인지 말 것인지를 정하고, 그 정한 일에 대해서 일을 진행해야 했는데요. 이런 회의들이 사실 그 이전 회사에서는 없던 일들이었기 때문에, 이런 일련의 소통을 통해서 일을 진행하는 방식들은 배움이었습니다. 첫 스타트업에서, 대표와 디자이너와 저 이렇게 세 명이서 하나의 새로운 서비스를 만들 때는 이런 과정을 지지고 볶으면서 그래도 꽤 예쁜 서비스가 되었었습니다. 이때 bitBucket을 처음 사용하면서 git의 세계에 입문했죠.

그리고 작년의 프리랜서의 경험에서는 제가 프로젝트를 리딩 하면서, 사람들의 고충도 듣게 되고, 프로젝트를 완성하기 위해서, 여러 가지 방법들을 동원했어야 하는데요.

https://brunch.co.kr/@chickenmoim/5

첫 프리랜서 도전기(개발자, 프로젝트 리더)

- 개발자(정직원), 그리고 프리랜서의 차이(장단점) 공유 | 개발자라면 누구나 한 번쯤. 지금 있는 회사에서 벗어나 프리랜서의 삶을 살아보는 것은 어떨지 생각해보고 상상해 본 적이 있지 않나

brunch.co.kr/@chickenmoim/5

이런 프로젝트를 통해서 사람들과 함께하는 법을 배우게 됩니다. (git을 조금 더 딥하게 사용하게 되고, 여러 사람이 사용하면서 문제 상황도 많이 겪었어요)

그리고 아이고고에 들어와서 팀원들이 하나둘 생기면서, 업무를 분배하고, 또 함께 웃으면서 즐거워하는 법, 그리고 눈높이를 맞추는 것, 그리고 동료로서 서로 성장해가는 것을 배우게 되었는데요.

업무라는 것을 혼자서 잘하고, 그것을 완수했을 때와 또 여럿이 함께 그 일들을 완수하는 것은 또 다른 일이라는 것을 실감했습니다. 어찌 보면 혼자 하는 일이 더 빠를 수도 있고, 그게 더 마음에 들 수도 있지만, 또 다른 사람과의 경험을 공유하고, 소스도 공유하는 과정을 통해서 다른 점들을 더 많이 알게 되고, 또 한편으로 서로의 실력을 보강하기도 하고, 또 작은 한계들도 깨닫는 것 같아요. 지금은 프로젝트별로 git을 관리하고 배포가 용이한 서비스를 구축해 놓은 상황입니다.

CTO 로서 어찌 보면, 혼자서 할 수 있는 능력, 그리고 여러 사람의 마음을 아우르는 능력, 그리고 그 사람의 기반과 기준치를 잡아서 함께 그 위치로 끌어올려주는 것이 필요하지 않나 이런 생각도 해봅니다.

커뮤니티를 통한 커뮤니케이션 스킬 강화

제가 치킨 모임이라는 커뮤니티를 만들고 운영한 것은 5년 정도 된 일입니다. 커뮤니티 초반에는 다양한 스터디를 진행했었는데요. 각종 팀빌딩을 비롯한 브레인스토밍, 안드로이드 스터디로 5사이클 정도 운영하기도 하고, 또 다양한 프로젝트들을 커뮤니티 내에서 만들고 리딩하고 완성까지 시키는 작업을 몇 번 하게 되었습니다.

이런 소중한 경험들은 스타트업에서도 당장 활용 가능한 스킬들이었는데요. 개발자들의 경우 디자이너와의 소통의 부재가 있는 경우들이 꽤 있습니다. 개발자끼리만 일했다거나, 디자이너의 성향을 잘 모른다거나, 혹은 디자이너가 생각하는 바를 이해하지 못한다거나, 제 다른 글 중에 개발자, 디자이너, 기획자의 동상이몽이라는 글에서 다양한 케이스들을 적어두긴 했습니다. 커뮤니티를 통해 다양한 소통방식을 연구하게 되었고, 그 결과 조금은 다른 직군과 대화도 조금 수월해지지 않았나 싶어요. 대표님들과의 다양한 교류들을 통해서 대표의 마음도 알게 되고(무엇보다 빠르게 시장에 제품이 나오고 싶어 하는 마음), 또 수익이 나지 않을 때의 조바심이나, 팀원이 구해지지 않을 때의 조바심 등등 다양한 케이스를 접하게 되다 보니, 역지 사지의 입장에서 생각해 보게 되는 일이 많이 있었는데요. 이런 일들을 기반으로 회사 내에 여러 가지 문제들이 생길 때 대입하다 보니, 약간의 마찰들을 조금은 수월하게 넘길 수 있었던 것 같아요.

결국에는 사람이 하는 일인데, 결국 서로 간에 일을 하는데 마음을 얻지 못하고, 또 감정이 상하면, 또 잘할 수 있는 일들도 잘하지 못하게 되기 때문에, 소통이라는 것은 결국, 상대와의 다름을 이해하는 것에서 비롯하지 않나 생각을 해봅니다.

결과적으로는 이런 커뮤니티에서 활동한 것들이 타인과의 소통의 자양분이 되었던 것 같아요.

대표의 눈으로 보기

앞서 대표의 시각을 많이 깨달았다고 표현을 하긴 했는데요. 스타트업을 나와서 프리랜서로 가기 전, 그리고 그 이후에 많은 대표님들과 차를 한잔하면서 CTO로의 영입 제안을 받으면서, 어떤 사람이 CTO에 맞을까? 이런 생각을 많이 했습니다. 최근에 “스타트업” 드라마를 보면서, 남도산이라는 CTO를 보면서 사람들이 얼마나 CTO에 대한 환상을 가지게 될까? 이런 생각을 해보았습니다. 어떤 느낌이 CTO에 맞는지 고민이 필요했던 것인데요. 드라마에 언급되었던 남도산 캐릭터도 확실히 CTO로써 갖추어야 할 자질을 가지고 있긴 합니다. 바로 남다른 기술력, 물론 그 드라마에서 그 인공지능에 대한 기술력과 방식을 조금은 쉽게 다룬 측면에 있어서 실제로 인공지능을 다루는 곳 입장에서는 조금 난감한 상황이 있었을 듯한데요.

우선 CTO를 뽑는다고 해서 다 같은 CTO는 아니라는 것입니다. 대표 입장에서는 작은 스타트업의 팀장급을 이야기하는 것일 수도 있고, 혹은 조금 더 성장한 곳에서 개발자를 케어하는 PM 입장을 뽑을 수도 있고, 혹은 더 나아가서 20~40명 정도 되는 기업의 입장에서 회사의 방향성을 설정하고, 그것을 결정하는 자리로써의 조금 더 무거운 CTO를 생각할 수도 있습니다.

초기 스타트업의 경우, 자본이 별로 없기 때문에 투자를 받기 위해서 CTO를 필요로 하는 경우가 많이 있습니다. 그 경우 개발을 잘하거나 이미 CTO의 경험이 있는 사람의 경우는 새로운 곳에 가지 않으려고 할 텐데요. 대표 입장에서는 그럼 어떤 사람을 뽑고 싶을까요?

첫 번째는 연륜이 있는 사람입니다. 5년, 적다면 적고 많다면 많은 경력의 숫자입니다. 5년을 기준으로 많이 생각합니다. 물론 중고생, 대학생들 중에서도 꽤나 날고 기는 친구들이 많아서, 작은 회사의 CTO로 가는 것을 종종 보게 됩니다. 물론 그 기업이 커지는 과정들도 있는데요. 보통 대표 입장에서 과감하게 모험을 하는 것이 아니라면, 이미 여러 가지 산전수전을 겪은 사람을 영입하고 싶어 합니다. 5년 정도의 경력이면 대부분의 문제를 처리할 수 있는 시점으로 보는 것인데요. 이 5년은 정말로 애매한 숫자입니다. 대학교에서 4년 안에 컴공의 경우 개발자를 할지 다른 길로 갈지가 결정됩니다. 컴공이라고 해서 다 개발자를 하지는 않는 것이고, 다른 길이 맞다고 생각하는 사람은 일치감치 다른 일로 가거든요. 회사도 마찬가지입니다. 5년 정도 회사의 일을 해보면, 이 사람이 계속 개발을 하고 싶은 건지, 아니면 그냥 회사 일을 하고 싶은 건지 판가름이 나오게 되어있습니다.

대표 입장에서는 개발 직군의 회사원을 뽑아야 하는 게 아니라, 개발 직군의 개발자를 찾아야 합니다. 회사일을 5년 정도 하게 되면, 일로써의 문제가 아니라 개발이라는 것에 대한 적성으로써의 부분이 스스로에게 드러나게 됩니다. 따라서, 5년 정도 된 개발이 능숙하고, 다양한 개발을 더 하고 싶은 개발자가 뽑아야 하고, 뽑고 싶은 인재인 셈이죠.

두 번째는 대표가 하고 싶은 것을 이루어 줄 수 있는 사람입니다. 개발자의 입장에서 시장을 보면, 대부분 시장은 많이 커졌고, 새로운 서비스들은 매번 나오지만, 이 중에 살아남거나 시장을 독식할 수 있는 경우는 매우 드뭅니다. 대부분 실패할 것이라는 것들을 짐작하고 있어요. 물론 시장을 보지 않는 개발자의 경우는 개발이 재미있을지 여부만으로 판단할 가능성도 있습니다. 대표가 하고 싶은 것이 웹인지, 앱인지, 혹은 데이터 시장인지, 인공 지능인지, 3D 인지 등등 대표가 뽑아야 하고 뽑고자 하는 능력을 가진 사람, 결국 그 사람이 CTO에 갈 수 있는 사람일 텐데요. 저의 입장에서는 백엔드, 프런트, 앱 이 세 가지를 다해보았다는 점에서 많은 분들이 좋게 보아주셨습니다. 물론 저도 얕은 부분이 있기 때문에 제 안주신 곳들 중에서 제 능력을 넘어서는 곳들은 과감하게 거절하고는 했었는데요. 자신이 할 수 있는 것들을 파악하는 것도 중요한 것이라고 생각합니다.

세 번째는 학력입니다. 의외의 대답이라고 생각하실 수 있는데요. 스타트업의 초기 투자 이후에 다양한 투자 심사를 받게 되면, CEO, CTO 기타 직원들의 스펙 및 경험, 그리고 학력 등등의 정보들이 투자의 심사에 중요한 정보가 되곤 합니다. 그래서, 간혹 뉴스에 N사 출신의 스타트업, K사 출신의 스타트업이라는 이름을 붙여 스타트업이 생기기도 하고, 그런 곳들이 투자받는다는 내용들도 꽤 접하실 듯한데요. 이렇듯 대표 입장에서는 혼자 매출을 극대화하는 경우가 아니라면, 이 세 번째도 중요한 요인으로 봅니다.

마지막으로는 이 3가지에서 언급되지 않는 것인데요. 개발자도 대표의 스타일을 보지만, 대표도 개발자의 스타일을 보게 됩니다. 보통 “결이 맞다” 이렇게 표현들을 하는데요. 서로가 아무리 능력이 출중하고 서로 실력이 맞아도, 이 부분이 맞지 않으면, 결별하는 사례들이 있습니다. 서로 마음이 맞아야 바퀴가 굴러갑니다. 그래서 이런 시행착오가 있던 대표님들은 이런 부분도 살펴봅니다. 이런 요인이 다 맞아야 결국 콜링을 하고 함께 해보자는 제안이 오는 것이죠.

이런 내용들을 알고서 대표님들을 만나게 되면, 합류하는 데 있어서 많이 수월해집니다. 물론 부가적으로 스타트업 경험, 대용량 트래픽 경험, 프로젝트 구축 경험, 앱 출시 경험, PM 경험이나 팀장 경험 등등 조건을 늘어놓자고 하면 끝이 없이 이어질 수 있습니다. 반대로 개발자도 엮으로 이 조건은 끝이 없이 펼쳐질 수 있겠죠. 그래서 보통 이렇게 스타트업에 입장에서 서로의 합이 맞아서 딱 잘 굴러가는 케이스는 많지 않습니다. 하지만 위 조건은 절대적 조건이 아닙니다. 대표가 양보할 수도 있고, 개발자가 양보할 수도 있죠. 다양한 협의와 조율을 통해서 조건들은 변경됩니다. 그래서 서로 경험이 있는 경우, 더 빠르게 일이 진행되기도 합니다.

전반적인 얕은 지식

얕은 지식이라고 하니 “지대넓얕”이라는 책이 떠오르는데요.

일부러 지식을 조금씩 알고 있으라는 의미는 아닙니다. 모든 것을 깊게 알고 있으면 좋습니다. 다만 다양한 부분에 대한 어느 정도의 지식이 필요합니다. 모르면 말을 안 했으면 좋겠다.라고 간혹 생각하신적들이 있을듯합니다. 너무나 잘 모르는 윗사람이 뭔가를 지시할 때 나오는 그 북받침.. 아 퇴사 욕구들 등등..

얕은 지식은 최소한 모르는 분야에서도 서로 이해가 가능한 범주 정도의 지식을 의미합니다. CTO의 경우 프런트 지식이 전무할 수 있습니다. 백엔드 출신이라면 더 그럴 가능성이 있겠죠. 이제 리엑트, 엥귤러, 뷰 등등 프런트에서도 PO를 뽑는 시대가 되었습니다. 그만큼 프런트를 경시할 수 없고 중요한 입장이 되었다는 이야기인데요. 이런 트렌트를 읽지 못한다면, 회사는 점점 옛날 방식을 답습하게 될 것입니다. 이건 모두가 원하는 방식은 아니죠. CTO는 최소한 현재 어떤 기술이 발전하고 있고, 어떻게 기술이 사용되는지, 그리고 지금 이 기술을 가지고 있을 때 앞으로 나오는 기술보다 뒤처지게 될 때 어떤 문제점이 생길지에 대한 대비가 되어있어야 한다고 생각합니다. 물론 이 시대에는 회사의 숫자만큼 CTO 가 있기 때문에 각각의 생각은 다를 듯한데요. 어찌 보면, 회사가 추구하는 안정성에 따라서는 과거의 유물을 놓아두는 것이 나은 경우도 있을 것입니다. 하지만, 빠르게 변해야 하는 업종에 가서 개발 중인데 실제로 그렇지 못한 것을 개발하게 되면, 결과가 따라가지 못할 수도 있습니다. 물론 CTO의 역할 중 하나는 안 되는 것을 안된다고 말해주는 것이기도 합니다. 기술적으로 과도하거나, 가질 수 없는 역량을 대표가 밀어붙인다면 그걸 브레이크 해주는 역할도 CTO가 해야 할 역할이라는 점입니다. 예를 들어서 꽃 어플을 개발 중인데, 사용자의 기호나 취향을 분석해서 꽃을 추천해주는 것을 개발해보자. 한데, 갑작스럽게 얼굴을 인식해서 사람들의 꽃에 대한 기호나 취향을 분석해보자고 하면 막아주는 사람이 필요하겠죠. 대표가 어떤 시스템을 만들려고 할 때, 그 시스템이 구현 가능한지 유무를 판단하고, 실제로 구축까지 할 수 있는 지식은 있어야 또 아니라는 판단이 들 때는 아니라고 이야기해주고, 대신 다른 대안들을 제안해 줄 수 있어야 합니다.

프로젝트 개발 역량

다소 CTO의 역할에 이 프로젝트 개발 역량은 필수적 덕목은 아닙니다. 좋은 설계자란 꼭 개발하지 않아도 그것을 할 수 있게 만들어 줍니다. 기획자의 역할과 대표의 역할, CTO의 역할 사이에 어떤 설계자의 역할이 들어간다면, 그 설계자는 CTO일 확률이 높겠죠. 하지만 좋은 기획자의 경우는 CTO나 개발자의 경험도 대체할 수 있습니다. 첫 회사에서 저보다는 20년 앞선 분을 만나고 존경했었는데요. 그분은 개발자가 아니셨지만, 개발에 대한 이해도 하고 계셨고, 설계도 하실 수 있었고, 문제를 찾아내고 짚어내실 수 있었습니다. 점점 관리자의 영역에서 개발을 손대지 않아도 그 그림을 그리고 전체를 볼 수 있는 안목을 가지고 계셨던 건데요. 회사의 구석구석을 알고 있고, 무엇을 어떻게 해야 하는지 알고 있고, 또 서비스나 시스템이 필요한 것들을 알고 대응하실 수 있었던 분이셨습니다. 그런 경우라면, 프로젝트 개발 역량은 필요 없을 것입니다.

하지만, 성장해 나가는 스타트업의 CTO 혹은 이제 갓 프로젝트를 시작하는 입장에서 CTO의 역할에는 프로젝트 개발 역량은 매우 필요한 역할일 것입니다. 그럼 학생들 입장에서, 혹은 이미 2~5년 차 개발자 입장에서 물어볼 수 있겠죠. 프로젝트를 안 하는데, 혹은 안 해봤는데 그런 역량은 어떻게 키울 수 있나요?라고요.

이 부분이 사실상 현재 스타트업 대표의 입장에서, 개발자의 입장에서 풀어야 할 숙제입니다. 개발자는 이 프로젝트 경험을 해야 하고, 대표는 이 경험을 가진 사람을 찾아야 하고, 이 두 사이의 간극이 있기 때문에, 프로젝트를 리딩 해본 경험이 있는 사람들은 더 많은 기회가 생기는 셈이죠.

개발 운영을 하는 것과 프로젝트를 시작부터 끝까지 해보는 것은 확실히 다릅니다. 누군가가 개발환경을 세팅해주는 것, 처음부터 개발환경을 만드는 일은 다른 일이니까요. 첫 회사에서는 struts, spring 으로 프로젝트가 되어있었습니다. 너무 오래된 버전들이어서, 나중엔 이런 버전들이 올라가면서 개념이 복잡해지고 달라져서 적응하기 어려웠는데요.

추후 프로젝트 시작 시에 spring boot, (maven or gradle), (tiles or sitemesh), (mysql or oracle), (jsp or vue) 기본적인 세팅을 진행할 때 어떤 것을 사용할 지에 대한 고민들을 하게 되고, 이런 세팅 과정들을 또 공유하고 나누는 과정들을 토대로 프로젝트가 굴러가게 되었는데요. 이런 경험들 뒤에 다른 프로젝트를 진행할 때는 조금 더 나은 선택들을 하게 되고 조금 더 복잡하지 않게 프로젝트를 구성하게 되었던 것 같아요.

결국 이런 프로젝트를 많이 진행하다 보면, 많은 지름길들을 알게 되고, 같은 프로젝트여도, 조금은 더 속도를 낼 수 있는 방식들을 알게 되는 거죠.

실패를 통한 성장 기회

첫 스타트업에서 나왔습니다. 첫 CTO 이기도 했는데요. 열심히 만든 개발이 무용지물이 되었을 때, 그 아쉬움은 이루 말할 수 없네요. 아마 저보단 대표님께서 더 아쉬우셨겠지만 말이죠. 첫 포부와 달리, 그 결과가 그 기대에 미치지 못했을 때, 실패란 생각이 들지 않을 순 없었는데요. 여러 가지 요인들이 있었겠지만, 개발적 관점에서, 개발을 완수하지 못한 것은 아니었지만, 기술적인 부분 이외에도, 사업적이고 돈이 되는지에 대한 부분에 있어서 개발자라는 생각 때문에 개입하지 못하고, 그저 바라보기만 했던 건 아닌가 생각이 들었습니다.

실패의 쓴 맛 뒤에는 성장 기회들이 찾아왔는데요. 프리랜서의 경험이 그러했습니다. 그리고 다양한 면접들을 토대로, 깨달은 것이 있습니다. 실패하더라도 그다음이 있다는 점인데요. 제일 처음에 스타트업으로 이직을 결심하고 이직하게 되었을 때 가장 두려웠던 부분 중에 하나는 그다음이 없을 것 같아서, 마치 불구덩이로 뛰어드는 건 아닌가 생각이 들었거든요. 다들 실패에 대해서 만류하기도 했고, 하지만 정작, 첫 스타트업이 아쉬운 결말이었지만, 다음 단계들이 있었기 때문에 좋은 경험이었다는 생각이 들었어요. 그래서 도전해 보고자 하는 분이 계신다면, 실패를 두려워하지 않아도 좋다고 말씀드려보고 싶네요. 만약 제가 그 넥스트가 없었다면, 이런 글은 쓰지 않았겠지만 말이죠.

선택의 순간 고려할 것들

최근 몇 년 사이 선택의 순간들이 있었고, 그 선택의 결과들을 후회하지 않습니다. 매번의 선택에서 나름대로의 원칙들이 있었는데요. 첫 번째 회사가 어렵다는 것을 직감했을 때, 그전에 먼저 이직 제안이 왔었지만, 이직을 하지 않았어요. 더 좋은 연봉에 괜찮은 회사로 갈 수 있었지만, 처음 제 손을 잡은 대표님이어서, 그 신뢰를 무너뜨릴 수 없어서였는데요. 한번 가기로 한 것 그래도 끝까지 해보자라는 마음이었는데, 결국 회사를 떠나야 했지만, 그 결정 때문인지, 회사를 떠난 이유를 묻는 말에 거리낌 없이 대답할 수 있게 되었고, 마음의 짐 없이 다른 일들을 해볼 수 있게 되었어요.

두 번째 선택은 프리를 하기로 결정한 이후에 연봉 7~8천 대의 약간은 이름 있는 회사의 CTO 제안이 2군데 왔었어요. 정확한 금액을 이야기할 순 없지만, 프리보다는 계속 경력을 있는 게 더 괜찮다는 생각이 들었는데요. 이미 프리를 하겠다고 결정하고 들어온 제안에 있어서, 프리를 안 하겠다고 결정할 수 없었는데요. 이 결정도 잘했다고 생각하고 있습니다. 다른 곳에 들어갔어도 분명 잘할 순 있었지만, 급박한 시일에 있어서 저의 결정이 다른 사람에게 피해를 줄 수도 있었던 상황이었기 때문에, 아쉬움도 있었지만 프리를 선택했습니다. 이 선택도 후회하지 않는 결정입니다. 그 덕분에 프리랜서의 생리도 알 수 있었고, 또 프로젝트 리더의 경험도 하게 되었으니 말이죠.

세 번째 선택은 다시 스타트업으로 오기로 한 결정입니다. 프리랜서의 기간이 잘 끝이 나고, 기간이 3개월 연장되었고, 계속 연장하거나 더 큰 기업의 프리 자리도 있던 타이밍이었는데요. 계속 프리를 한다고 하면 아마 더 좋은 조건으로 계속 다른 경험들을 쌓을 순 있었을 것 같아요. 절묘한 시점이었는데요. 곧 아이가 태어나는 시점이기도 했기 때문에, 프리랜서의 불확실성과 회사라는 안정성 중에서 회사를 선택하게 되었어요. 그리고 이미 스타트업을 경험한 입장에서 일반적인 회사를 지원해서 갈 수도 있었지만, 스타트업으로써의 도전을 조금 더 이어가고 싶은 마음도 있었는데요. 1년이 지난 시점, 그 결정 역시 잘했다고 생각합니다.

늘 했던 생각들이 있어요. 프리랜서를 하면 어떨까? 프리랜서에서 다시 정규직이 될 수 있을까? 스타트업에 간 뒤에 삶은 어떨까? 스타트업 뒤에 다시 대기업을 갈 수 있을까? 등등 다양한 고민들이 꼬리에 꼬리를 물었던 것 같아요. 그래서인지 조금 더 선택에 있어서 과감한 결단을 내려야 할 때 조금 주저하는 부분들이 있었는데요.

다른 사람이 이랬기 때문에 이래야 한다. 이런 타인의 말에 결정을 내리는 것들은 핑계의 여지를 주는듯해요. 남의 시선과 남의 생각이 아니라, 자기의 생각과 기준이면 충분한 것 같아요. 운영을 한다. 개발을 한다. 백엔드, 프런트, 앱, 등 하나의 역할에 충실한다. 등등 다양한 자기 기준안에 있다면, 다른 사람의 경험과 결과에 휘둘리지 않을 수 있게 되는데요. 시간은 또 빠르게 흐르고, 많은 것들이 빠르게 움직이면 자신만 도태된 것 같은 그 느낌과 착각이 들게 되는데요. 그 걸 극복하는 게 중요한 것 같습니다.

문제의 인식과 해결

아이고고에 처음 와서 한일은 시스템에 문제가 무엇인지 살펴보는 일이었어요. CTO로 왔지만, 앞서 개발자 친구가 있었기 때문에, 함께 이야기하면서 우선순위를 결정하기는 했는데요. 저희는 유아 방문 수업이었고, 많은 일들이 수동으로 이루어지고 있었어요. 그래서 다양한 일들이 필요했죠. 알림 톡을 이용한 스케줄 자동 발송 시스템부터 시작해서, 리포트 시스템까지 기존에 없던 부분이 많았어요. 그런 문제들을 파악하고 개선해야겠다고 느꼈죠.

그리고 웹으로 사용하기에는 부모님이나 튜터 입장에서 많이 불편하겠다는 생각을 했고, 튜터 페이지의 개선과 관리자 페이지 개선, 그리고 앱이 필요하단 생각이 들었어요.

전 자바 개발자였지만, 이 회사에 리엑트 개발자로 들어와서 리엑트 네이티브로 앱을 만들어야겠단 생각을 했어요. 처음에 플루터와 react native 중 선택의 기로가 있었는데요. 기반되는 웹이 리엑트였다는 점이 리엑트 네이티브와 개발 상 비슷한 맥락을 가져갈 수 있을 듯했고, 플루터의 경우는 최근에 나왔다는 점, 그래서 검증이 어렵다는 점을 이유로 리엑트 네이티브로 개발을 하게 되었는데, 결과적으로 완성도 되고, 론칭도 되어서 잘한 선택이라는 생각도 있지만, 성능상을 고려해보면, 시간이 좀 더 있었다면 다른 선택을 할 수도 있지 않을까? 이런 생각을 해보기도 합니다.

이렇게 탄생한 앱!

안드로이드

https://play.google.com/store/apps/details?id=com.igogo

아이고고 — 우리동네 유아동 방문수업 추천 어플 — Google Play 앱

우리집•우리동네에서 우리 아이만을 위한 맞춤형 클래스로 소통하는 플랫폼, 아이고고! 아이의 성격, 취향, 적성을 모두 고려한 언어•예체능•코딩부터 융합 클래스까지, 부모와 튜터가 아이

play.google.com

IOS

https://play.google.com/store/apps/details?id=com.igogo

아이고고 — 우리동네 유아동 방문수업 추천 어플 — Google Play 앱

우리집•우리동네에서 우리 아이만을 위한 맞춤형 클래스로 소통하는 플랫폼, 아이고고! 아이의 성격, 취향, 적성을 모두 고려한 언어•예체능•코딩부터 융합 클래스까지, 부모와 튜터가 아이

play.google.com

아이고고 앱 화면

다양한 유아동에게 다양한 클래스를 경험하게 해주는 플랫폼입니다.

3월에 착수를 시작해서 9월에 앱을 론칭했는데요. 개발팀이 크지 않은데요. 작은 규모로써는 꽤나 빠르게 앱을 완성했습니다. API 도 만들고, 앱도 살펴보고, 채팅 서버도 구축하고, 관리하는 어드민 페이지도 만들고요. 물론 결제 및 정산에 관련해서도 만들었죠.

앱은 웹에서 이용하는 고객들이 불편할 것이다. 이것을 개선하게 되면 부모나 튜터 입장에서 훨씬 더 편리해질 것이다라는 관점으로 시작했는데요. 결과적으로는 많은 분들이 편리하다고 이야기해주시고 있습니다.

만약 CTO라는 직군을 해보고자 도전하는 친구에게 해주고 싶은 말이 있다면?

스타트업 대표로서의 관점으로 위에서 설명을 했다면, 대학생, 혹은 신입이나 이제 막 경력이 어느 정도 쌓여가는 입장에서 이런 팀장이나 CTO 등등의 직군에 도전해보고 싶을 거라는 생각을 해보았는데요.

보통은 “하지 마라”가 정설과 같은 대답이라고 생각되긴 할 것 같은데요.

용의 꼬리, 뱀의 머리라는 말도 있는데, 뱀의 머리도 머리거든요. 확실한 건, 회사에서 늘 부속품처럼 느껴져서 뭔가 뜨거운 것이 흐르고 계신 분이라면, 한 번쯤은 도전을 생각해 보는 것도 좋겠다는 생각을 해봅니다.

위로 올라가는 길은 다양하게 있을 것 같아요. 대기업을 가고, 대기업에서 또 다른 대기업으로 이직하고, 그렇게 연차가 쌓여서 팀장을 하게 되고, 또 세월이 지나서 과장> 차장> 부장(각기 직급 체계는 다르겠지만요) 이렇게 직급이 쌓여가는 방식, 아니면 새로운 기회들에 마주하는 경험들, 결국 회사가 성장하면 또 그것에 걸맞은 역량이 필요해지겠지만 말이죠. 좋은 사람을 볼 수 있는 안목이 필요한 것 같아요. 회사에 사람을 뽑아야 하니까요. 이 회사에 알맞은 사람이 누구인지, 어떤 역량이 필요한지, 그리고 구성원 간에 갈등은 어떻게 풀어가야 하는 것인지, 어쩌면 관리자와 같은 일이 피곤해서 더 상위 조직으로 가지 않고 개발자로서 개발일만 하려고 하는 분이 계실 수도 있겠단 생각이 드네요. 아마도 CTO가 된다면, 나중에는 개발일을 안 하게 될 수도 있어요. 혹은 하더라도 점점 커질수록 손을 쓸 수 없어지겠죠. 그때마다 모든 코드들을 컨펌할 수도 없고, 모두 코드를 분석할 수 없을 수도 있어요. 그럼 과감하게 권한을 이양하고 믿어주는 게 필요하겠죠. 그냥 멋있어서 시도해본다기보다는, 할 수 있는 일이 무엇인지, 회사에 어떤 것을 해줄 수 있는지, 회사의 가치에 날개를 달아줄 수 있는지, 등등 보다 많은 것을 생각해보면 좋겠다는 생각이 들었어요. 그전에 일단 개발일도 많이 해보는 게 좋겠죠.

우선 개발 프로세스에 대한 전반적인 이해와 시스템 전반에 대한 개발 플로우를 잘 알고 있는게 좋아요.

저의 경우 잡다한 일들도 많이 해봤었는데요. MFC로 카메라 제어 및 전송, 메일링 시스템 만들기, 강연 시스템, 삼성 single login api 사용, 사내 대량 메일 전송 기능, 클라우드 서버 운영, 안드로이드 모션 앱 제작, 앱 모션 외주, 유니티 증강현실, Centos 리눅스 서버 세팅, 우분투 서버 세팅, DB 설치 및 운영, 자바 스케쥴링, POI를 이용한 액셀 입출력 기능, gcm 등등 SMS 발송 기능을 포함한 slack api 연동 및 jenkins, jira api 등 작은 로그인 기능부터 자잘한 설치를 포함한 일들까지 다양한 경험들이 있다 보니, 어찌 보면, 큰 회사에서 분업화되어있어서 경험하지 않아도 되는 경험까지 조각조각 나있는 경험들로 부족한 부분들을 메워오고 있는데요. 당장에는 필요 없는 경험들도 많고, 모든 경험을 다해야 할 필요도 없지만, 경험된 내용들은 확실히 개발 속도에 있어서 실수를 줄이고, 속도가 생기니까요. 다양한 것들을 많이 경험할 수 있다면 그 기회 속에서 많은걸 해보시는 걸 추천드려요.

대표 입장에서 좋은 CTO 란? (역지사지)

앞서 대표 눈으로 보기와 비슷한 맥락인데요.

CTO 가 되고 싶은 입장에서의 이야기를 바로 앞에서 이야기했다면, 대표의 입장에서 좋은 CTO란 무엇일까요?

대표 눈으로 볼 때 3가지 조건 + 알파가 당연 좋은 CTO 이겠지만 조금 더 살을 붙여볼게요.

대표의 필요를 채워줄 수 있는 사람

- 전 웹 개발자입니다. 하지만 대표는 앱을 개발하고 싶어 해요. 그렇다면 그 방식을 제시해서 그것 할 수 있도록 만들어주어야 합니다. 그것이 설령 배워야 한다면 말이죠. 대표의 눈높이를 생각하고 문제를 해결하고 그 해결 방안을 제시해 주는 것이 필요합니다.

대안을 찾는 사람

- 두 군데의 스타트업에 있으면서 대표님들과 소통할 때 하는 말하는 방식이 있습니다. 안됩니다라고 말하지 않기입니다. 사실 안 되는 건 없거든요. 다만 시간과 노력과 공수가 필요한 거죠. 말도 안 되는 요구사항은 말도 안 되는 시간이 필요한 것이고요. 결국 설득에 있어서, 이런 이야기들은 말장난처럼 들릴지는 몰라도, 듣는 사람의 입장에서, 불가능하다는 생각 때문에 생각의 진행을 멈추어 버리는 게 아니라, 가능한 다른 방식을 찾도록 생각이 변화되도록 합니다. 즉, 이런 방식으로 진행하면 2달의 시간이 걸립니다. 대신 이렇게 진행한다면 2주 만의 시간으로 해결할 수도 있어요. 만약 고객의 불편을 고려한다면, 이렇게 먼저 진행하셔서 무거운 문제를 해결하고, 나머지 문제에 대해서는 점진적으로 해결해보는 방식은 어떠신가요? 이렇게 이야기한다면, 생각보다 더 빠르고 단순하고 괜찮은 해결 방식이 나오기도 합니다. 즉, 안된다라는 말을 하게 되었을 때는 다시 왜 안되는지에 대해서 설명을 요구받게 되고, 그 방식을 설명하다 보면, 방어적이 되어버리거든요. 결과적으로 애초 칼과 방패의 싸움을 하려고 이야기를 한 게 아니지만, 그 이야기를 하고 있는 상황들이 연출됩니다. 따라서 그런 이야기의 대화 방식이 중요한 거죠.

어디가 문제인지를 빠르게 캐치하는 사람

- 기술이 있는 CTO는 서비스 모델에 대한 문제도 빠르게 캐치하지만, 속도가 느려지거나, 서비스의 이상에 대한 문제들도 꽤 빠르게 알아냅니다. 그리고 현재 굴러가는 서비스에 대한 이해도가 높을 경우에는 해당 서비스의 개발자가 아니더라도, 해당 서비스를 빠르게 해석할 수 있습니다. 전체를 알고 내부를 아는 사람은 문제에 대한 대응이 빠릅니다. 물론 이런 사람은 실제로 같이 일해보기 전에 알기는 어려운 케이스이긴 합니다. 다만 레퍼런스 체크나 다양한 방식을 토대로 그런 분인지에 대해서 확인해볼 수 있다면 좋겠죠.

의사소통이 편한 사람

- 대화를 해보면 이 사람이 불편한 사람인지 아닌지 알 수 있습니다. 때로는 좋은 기술을 가지고 있는 것이 그 사람의 장점과 매력이 될 수 있지만, 좋은 기술만 있고 소통이 불편하다면 전체적인 조직에서는 좋지 않은 영향을 줄 수 있습니다. 이미 조직 경색이 상당이 오래 진행된 곳에서는 한 사람이 바뀐다고 변화할 수는 없지만, 만약 그런 경우가 아니라면, 위에 사람이 경직되면 아래도 수직 경직될 가능성이 높습니다. 문화적 유연성에 관련된 이야기인데요. 따라서 조직 문화에 대해서 이해도가 높은 사람이 아무래도 대화도 의사소통도 편합니다.

비슷한 업을 경험한 사람

- 아무래도 금융이면 금융, 커머스면 커머스, 플랫폼이면 플랫폼, 비슷한 업종의 경우 해당 경험에 대한 지식으로 올바른 판단을 내리거나 비슷한 경험치로, 해석이 용이합니다.

개발에 대한 전반적인 프로세스를 아는 사람

- 아무리 소통이 잘되고 문제에 대한 이해가 높아도 시스템이 어떻게 만들어져야 하는지 모르거나, 어떻게 기획하고 만들고 배포하는지 경험이 부족한 경우, 개발 인력에 대한 관리가 어려울 수 있는데요. 충분히 개발을 많이해보고 협업도 많이해본 경험도 중요해요. 혼자만 개발하는건 아니니까요.

개발 일정 수립을 할 수 있는 사람

- 가장 어려운 일은 공수를 산정하는 일인데요. 해당 프로젝트을 수행하는게 걸리는 시간이 어느정도인지 규모를 파악하고 그대로 수행하는 것. 이 부분을 잘 못하면 일정이 미루어지기 마련입니다. 개발일정을 스케쥴링하려면 개발팀내의 각각의 역량 파악도 같이 할 수 있어야 하는데요. 스스로의 개발 타임라인 안에서 일정 수립은 어느정도 가능하지만 이런 일정 파악을 잘 할 수 있는 사람이 대표입장에서는 좋은 CTO라 볼 수 있겠죠.

맺음말(각자의 길이 있다. 그럼에도 도전하려고 한다면, 짊어질 것을 짊어져야 한다.)

CTO의 조건이라는 제목으로 다양한 이야기들을 해보았는데요.

1년이 지난 시점, 회사 안에서 조직이 커지면서 다양한 사람들과 교류하고, 소통하고, 성장했던 시간들이었던 것 같습니다. 육아와 함께 시간을 쪼개어서, 짧은 시간 동안 많은 성과를 내기 위해서 효율적인 방식에 대해서도 고민을 많이 했었어요. 내부적으로 소스를 빌드하고, 배포하는 방식을 최대한 간결하게 만들었고, 기존에 있는 시스템을 살리면서 상호적으로 연동하는 방식들도 고민했어야 하고, 또 사람 간의 관계도 생각을 했어야 하는 시간들이었던 것 같네요.

개발자 10년이면 사실 전 개발자 수명이 끝날 거라고 생각했었는데, 어느덧 시간이 이렇게 되었네요. 아마 보시는 분들 중에는 개발자로서 다양한 포지션에 분들이 있을 것이라서, CTO에 한정된 경험이 만족스럽지 못할 수도 있겠네요.

게다가 큰 기업 CTO가 아니라 작은 스타트업의 CTO의 이야기라 경험 또한 매우 국소적이고 한정됩니다. 하지만, 작은 스타트업이니까 일이 당연히 많겠지라고 생각하면 당연해지는 이야기이지만, 또 한편으로, 그런 다양한 일들의 결과물들이 경험으로 바뀌는 멋진 순간을 함께 이야기하고 싶었어요. (아마 기업이 더 성장하면 그에 걸맞는 이야기를 제가 해볼 수 있겠죠!? 간절히 원합니다)

제가 조건이라고 이야기했던 내용들은 상호적인 이야기입니다. 다양한 예외들은 언제나 있습니다. 그리고 그런 예외를 잘 만드는 사람이 또 뛰어난 개발자이기도 하죠.

옛날에는 10년이 되고 20년이 되고 30년이 되어야 의사 결정을 감당할 수 있던 시대가 있던 거 같아요.

이제는 연차에 상관없이, 점차 좋은 의견이라면 받아들여지는 시대가 오고 있는 듯합니다.

CTO도 마찬가지예요. 시작하는 스타트업에서 다양한 기회들은 여전히 공존한다고 생각합니다.

그래서 그 기회에 대해서 이야기하고 싶었습니다.

막연히 꿈만 꾸는 것으로는 이룰 수 있는 게 없겠죠.

하나씩 도전하고 성취하고, 그렇게 하나씩 탑 쌓듯이 쌓아 가다 보면 목표에 이르지 않을까 싶네요!

저도 이 스타트업이 그런 과정 중에 하나라고 생각합니다!

필요하다면, 많은 분들에게 도움이 되고 싶네요!

댓글이나 baeno@nate.com 메일로 궁금한 거 여쭈어 보시면 할 수 있는 대로 답변해드릴게요.

이상 아이들랩 CTO 배진호였습니다.

PS. 12월 초에 글을 마감하려 했는데 어느덧 1월이 되었네요. 2021년 새해 복 많이 받으세요!

안녕하세요.

자바 개발자입니다.

아니 요샌 리엑트, 리엑트 네이티브로

이것저것 개발 중이라 무슨 개발자 인지도 모르겠네요.

이번에 들려드릴 경험은

지난해 10월부터 2020년 2월까지

안드로이드와 아이폰에 앱을 등록하면서

겪은 경험과 방식, 그리고 팁들을 공유하려고 합니다.

물론 전 유니티 개발자가 아니었기 때문에

더 어색하고 비전문적인 입장에서 초보의 느낌으로

경험을 더 잘 살려서 전달해드릴 수 있겠네요.

Unity.com

유니티는 약 5년 전 설치만 한 이후

단 한 번도 보지 않았고,

그 당시 예제 한번 돌려본 이후…

아하 난 이제 유니티를 할 줄 알아

라며 마음속에서만 유니티를 돌리고 있던 진정한

초보였으니 말이죠.

https://brunch.co.kr/@chickenmoim/16

네가 오는날 쓰는 편지

아빠가 아들에게 남기는 글 | 아들아 오늘은 세상이 뒤집어진 날이란다. 이 날은 생각보다 비가 많이 오는 날이었어. 오늘의 이야기였는데 어제의 이야기가 되어버린 이야기. 겨울 2020년 1월 7일. 그래도 2019년 12월생은 아니라 애써 다행이라 생각하고 있었지… 비가 생각보다 많이 내렸고 겨울에 눈이 올 법도 한 날이 었는데 비가 많이 내린 날이었어 아빠와 엄마는 생각보다

brunch.co.kr/@chickenmoim/16

지난 글들을 통해 알 수 있지만 아이가 생겼습니다.

육아와 일을 병행하면서

무엇인가를 다시 완성한다는 일은 보통 쉬운 일은

아니었습니다.

https://brunch.co.kr/@chickenmoim/10

캐릭터 디자이너, 남편으로 살아보기

디자이너와 개발자 남편이 만났을때! | 안녕하세요! 글쓰는 개발자. 치킨 모임이라는 건전한 치킨먹는 모임을 운영하는 운영자이자 캐릭터 디자이너의 남편입니다. 오늘의 이야기는 캐릭터 디자이너의 삶은 어떠한가! 그 바로 옆에서의 생생한 느낌들! 그리고 개발자로써 함께 보내는 그 느낌들을 몇자 적어볼까 합니다. 디자이너랑 함께 사는 일은 어떤 것일지! 궁금하셨다고요! 아마 이 글을 끝까지 읽을때쯤

brunch.co.kr/@chickenmoim/10

전에 캐릭터 디자이너의 남편으로 살아간다는 것이라는

글을 작성한 이후

전시장에서 만난 디자이너 (모르는 분)분께서 글을 잘 읽었다고 하셔서 내심 놀랐는데요.

글을 쓰다 보면 다양한 일들이 일어나는 듯합니다.

이번 증강현실 앱은 이 디자이너 아내의 책,

한글 초성 단어 찾기의 연장선으로 만들어진 증강현실 교육 앱입니다.

한글 초성 단어 찾기 책

한글 여행 앱 메인 화면 모습

한글 여행 앱 메인 화면

자료 수집 및 개발

초기 설계 (세팅)

ㄱ부터 ㅎ까지 아이들에게 배우게 하면서

동시에 초성 단어 찾기 놀이를 통해 아이들에게

재미를 주는 앱으로 기획을 했는데요.

엽서를 통한 증강현실 경험까지 덤으로 주는 방향으로

앱을 기획했어요.

엽서를 통해서 증강 현실을 구현한 화면입니다.

너무나 귀여운 캐릭터 이죠?! ㅎㅎ

이 앱을 만들게 된 계기는 작년 아내가 예비창업 패키지(2019)에 덜컥

되어버리면서 (물론 축하할 일입니다.)

2019 맥북 프로의 위엄

제 게는 이 좋은 노트북과 함께 이 앱 개발의 사명이 (물론 무보수- 완수하리라)

함께 주어지게 됩니다.

초기 유니티 버전 세팅을 비롯해 계속 실패한 프로젝트 생성 화면

문제는 유니티를 설치하는데 버전이 왜 이렇게 많은지

유니티 허브에서는 버전별로 유니티를 관리하고

뭔가 유니티 버전별로 그다지 호환이 완벽한 거 같진 않더군요.

2019.2.2f1 그나마 최신 버전의 유니티를 설치를 했습니다. 근데 최근엔 또 다른 새로운 버전이 나온듯해요.

예제를 돌려보려고 해도 버전이 안 맞으면 도루묵 인 셈이죠.

그리고 초기 세팅 때에 유니티 설치 시에 모듈을 선택하는 부분이 있는데요.

이 모듈 추가 부분에서

NDK iOs, android 등등 기본적인 Build Support들이 설치되어 있어야 합니다. 따라서 맥 용량도 많이 필요해요. 암튼 이런 세팅 부분 때문에도 꽤 시간을 많이 잡아먹었었던 기억이 있네요.

그래서 좋은 예제를 잘 찾아야 합니다.

그래서 유니티 책을 도서관에서 빌려 보기로 했어요.

유니티 책 대여 리스트

유니티에 대해서 c#이라 쉬울 것이라고만 생각을 했는데요.

이게 처음부터 이해하고 개발을 해야 하다 보니

SCENE에 대한 이해와

이 해당 C# 혹은 소스를 매칭 시키는 방식에 대해서 이해가 필요했습니다.

즉, 누군가의 설명 없이는 개발이 용이하지 않은 상황.

사실상 이 유니티 책들은 모두 훑어보았으나, 크게 도움은 되지 않은 듯해요.

그리고 각각 화면별로 역할과 소스의 연결.

이 걸 설명한 좋은 책들이 없었는데요.

대부분 어떤 식이냐면 3D 게임을 만드는데 집중을 하고

예제 돌려 쓰기 인지 거의 설명이 책들이 비슷하고

최근에 유니티에 대한 내용도 없고 설명도

자세하지 않았습니다.

유니티 개발 구조

유니티 실행 화면입니다.

보시면 아시다시피 도대체 뭐가 뭔지 어려운 구조로 되어있습니다.

큰 틀 : Scenes, Hierarchy, 화면, Inspector, 코드

보시다시피 유니티의 화면 구성은 유니티 책을 보면 어느 정도 설명이 되어있는데요

2D로 기본 디폴트로 개발할 수 있고 3D 디폴트로 개발이 가능합니다.

아래 Scencs라고 유니티 아이콘 모양으로 되어 있는 것들이 하나하나의 장면을 설계할 수 있는 요소라고 볼 수 있는데요.

안드로이드로 치면 Activity.java 파일처럼 하나하나의 화면을 설계하는 구조로 되어있는 것이죠.

위의 화면만 보면 장면만 해도 14개 화면으로 구성이 되어있습니다.

앱을 틀어보면 허접하고 뭐 없는 구조임에도 불구하고 이렇게 복잡한 화면 구성으로 되어있는데요.

그리고 하이 라키 부분은 이런 화면 안에서 여러 가지 오브젝트들을 생성하고 위치시킬 수 있습니다.

이미지나 카메라, 그리고 음악까지 다양한 오브젝트 단위를 만들어 둘 수가 있는데요.

이런 오브젝트를 하이 라키 부분에서 생성한 뒤에 Asset에 있는 이미지나 음원 등등과 연결하게 되어있습니다.

그리고 우측에 있는 inspector 가 중요한데요. 언뜻 보면 그냥 오브젝트에 대한 설명 정도로만 볼 수 있는 구조로 되어있는데 이 부분을 통해서 여러 가지 C# 소스를 드래그 함으로써 연결이 가능합니다.

기존에 C#과 이 유니티에서 사용한 C#의 느낌은 달랐는데요. 이 소스에서는 딱 여기 유니티에 맞는 라이브러리와 그리고 라이프 사이클로 되어있습니다.

이 유니티에서 사용하는 C#의 라이브 사이클은 기본적으로

Start(), Update() 함수를 기본으로 추가적으로 여러 이벤트를 비롯해서 다양한 것들을 활용할 수 있습니다.

화면 구성

처음 개발을 진행할 때는 ㄱ부터 ㅎ까지 다양한 오브젝트들을 클릭하고 싶었는데요.

처음엔 가로 3개 세로 5줄로 위아래 스크롤 뷰를 적용하려고 기획을 했는데 확실히 안드로이드 개발과 달리

이런 뷰 적용도 쉽지 않더라고요.

결국 좌우 스크롤로 14개 단어를 대체했는데요.

요렇게 좌우 스크롤 적용 화면입니다.

좌우 스크롤을 적용하기 위해 NGUI를 사용하기 시작합니다.

화면 설계와 반응형스러운 동적 화면 구성.

처음엔 그냥 화면만 대강 만들면 되겠지 싶었는데

버튼을 넣고 이미지를 넣고 오브젝트들을

배치하다 보니 이게 크기가 제 각각인 데다가

안드로이드와 아이폰일 때 크기가 정말하게 상이해서

이 심각한 문제를 처리하기 위해서

반응형스럽게 화면을 자르고 재단하고 크기를 보정해주는

절차를 통해 화면 비율로 동적으로

계산이 필요하단 걸 알았어요.

삽질이 시작됩니다. 좀 더 모듈화를 시켜볼 수도 있었지만

시간이 없는 관계로 삽질을 하기로 합니다

삽질의 현장….

이 삽질의 결과

안드로이드, 아이폰, 아이패드 화면 모두 어느 정도는 화면처리를 할 수 있게 되었는데요.

이 앱 내에서 여행 파트 부분의 모습을 보시면

소스의 적용 결과 화면의 깨짐 없이 다양한 형태로 화면상에 표현되는 것을 볼 수 있습니다. 일반적으로는

크기에 대해서 자동 변환이 없기 때문에 NGUI로는 소스 상의 너비를 계산해서 다양한 크기를 지원할 수 있는 거죠. 물론 최근에는 이 방식을 잘 사용하지는 않는다고 하네요. 그리고 제약사항도 많이 있긴 합니다. 만약 동적 화면 구성하는 게 가능하면 그 방식으로 전환할 생각도 있지만, 또 그런 게 나오려면 시간이 걸리겠죠..?

씬간의 전환

처음에 화면 단위의 전환부터가 고민이었습니다.

초기에 화면을 어떻게 만드는지 고민인 것처럼,

Scene의 파일에 대한 이해도도 떨어지고, 그러다 보니 삽질을 많이 했는데요.

유니티 씨 샾 최상단에 보면

using UnityEngine.SceneManagement;

이렇게 쓰인 부분이 있는데요.

이 장면 간 전환에 관련된 매니저로 씬을 움직일 수 있습니다.

안드로이드의 경우 엑티비티간 호출과 비슷한데요.

SceneManager.LoadScene(“BScene”, LoadSceneMode.Single);

이 소스처럼 직접적으로 바로 씬을 호출하는 방법이 있고,

함수 호출 부 : StartCoroutine(LoadSceneMain());

위 호출 처럼 함수를 만들어서 몇 초뒤에 호출하게 하는 방법도 있습니다.

IEnumerator LoadSceneMain()

{

yield return null;

AsyncOperation oper = SceneManager.LoadSceneAsync(“Main”);

oper.allowSceneActivation = false;

float timer = 0.0f;

while (!oper.isDone)

{

yield return null;

timer += Time.deltaTime;

if (timer > 1.5)

{

oper.allowSceneActivation = true;

}

}

}

그리고 보통 안드로이드의 경우 Intent 를 통해서 액티비티 간의 데이터를 전송할 수 있다면,

유니티에서는 PlayerPrefs라는 것을 사용 가능한데요.

여기에 변수를 PlayerPrefs.SetInt(“hangul”, cur);

이런 형태로 삽입하면서 하나의 씬에서 다양한 화면을 연출해 볼 수도 있습니다.

애니메이션 적용.

이렇게 그림 속에 숨어있는 초성 단어를 다 맞추면 애니메이션 효과를 주는 작업을 했는데요.

생각보다 유니티에선 GIF를 지원하지 않아서 애를 먹었습니다.

그냥 간단히 움직이는 이미지일 뿐인데

그 적용 방법을 찾아 헤매었는데요.

그중에 하나가 애니메이터를 이용한 방식이었는데요 ㅎ

움직이는 이미지를 여러 장 놓고 애니메이션을 만드는 방식은 독특한 방식이었던 듯해요.

이렇게 이미지상에 우측에 버튼을 누르면 이미지들이 하나씩 더 나오는데 해당 이미지들을 연결해서

이미지 컨트롤러를 만들어주고 해당 부분을 적용해야 하는 절차가 있어요.

증강현실 적용기

AR의 경우는 몇 가지 라이브러리가 많은데

저흰 무료이기도 하고 워터마크 있어도 일단 무방하기에

일단 뷰포리아를 사용했는데요.

뷰포리아 사이트

뷰포리아 세팅은 생각보다 간단합니다.

타깃만 잘 등록해주면 되는데요.

크게 라이선스 매니저와 타깃 매니저로 되어있는데요.

그리고 임포트!!

후에 디비를 만들어 주고, 해당 디비에 사진을 등록한 뒤에 해당 파일을 다운로드하여서

유니티 상에 적용해 주기만 하면 됩니다.

짜잔…

실행화면입니다.

3D소스가 바로 증강현실의 가미를 더해주고 있습니다.

이 3D 움직이는 소스가 증강현실의 열쇠라고 볼 수 있네요

이 움직이는 소스의 영상 확장자는 fbx 파일입니다.

회사 자료였다면, 이런 부분에 대한 내용을 이야기하기 껄끄러웠겠지만,

개인 프로젝트이다 보니 이런저런 이야기를 할 수 있는듯해요.

fbx 파일은 3d 멕스에서 변환해서 뽑아낼 수 있는데요.

이 파일은 유니티상에서 바로 적용이 가능한 부분이 있습니다.

애니메이터를 이용해서 움직이는 3D 영상 처리도 가능하고요.

참고와 도움이 되면 좋겠네요.

앱 — 한글송

그리고 앱에서 한글송 부분이 있는데요.

한글을 배우기 쉬운 몇 가지 노래들을 제작해서 앱 안에 넣어 주었어요.

한글송은 직접 가사 기획부 터해서 의뢰해서 좋은 영상으로

나오게 되었는데요

한글송 두 개 보시고 가실게요.

가나다라라송

https://www.youtube.com/watch?v=_3pEUW1RjK8

아예 모음송

https://www.youtube.com/watch?v=MQYs8mJuM-o

이 한글송 코너를 통해서 어린이들이 자음과 모음을 쉽게

익힐 수 있도록 설계했어요.

소스 배포 및 앱 론칭 반영

안드로이드 앱 론칭기

배포의 경우 안드로이드와 아이폰 두 가지를 모두 진행을 했는데요.

예전보다 안드로이드의 경우 절차가 까다로워졌는지 몇 번의 리젝 때문에 멘털이 조금 흔들렸었습니다.

안드로이드 Apk 추출

안드로이드의 경우 보통 APK 파일을 추출하고 사인한 뒤에 올리는 방식으로 론칭을 하는데요.

이번 프로젝트의 경우 유니티이기도 하고 asset 음원 파일 디자인 파일 스리디 파일등등

용량이 꽤나 많은 프로젝트였어요. 다른 안드로이드 프로젝트의 경우 50메가가 넘어가는 경우도 드문 경우라

따로 50메가가 넘을 때에 대해서 대비하진 않았었는데요.

100메가 이상에서는 번들이라는 파일을 뽑으면 되는 구조였어요.

평소 유니티에서 기기로 빌드 시에는 빌드엔 런을 선택하면 되지만,

실제로 안드로이드로 빌드를 할 때에는 최근 안드로이드 정책이 꼭 64 비트를 추가해야 하는 부분이 생겼는데요. 이 경우에 유니티로 번들을 만들어도 잘 적용되지 않는 부분이 있었습니다.

결국 프로젝트 export를 통해서 한 번은 안드로이드 스튜디오를 켜야 했는데요.

아이폰은 XCode 안드로이드는 Android Studio, 처음 개발하는 분들의 입장에서는 유니티만 하면 될 거로 생각하다가, 이것저것 세팅에 많은 시간을 보내겠다는 생각이 들었네요.

안드로이드 스튜디오

다행스러운 부분은

빌드 시에 오류가 없다는 부분이고, 가끔씩 라이브러리가 설치가 안되어있거나

해당 안드로이드 SDK 등등의 패스 문제로 잘 동작하지 않는 경우들이 있어서 신경을 써야 합니다.

이런저런 세팅 후에 ndk 항목에 보시면 x86 까지는 세팅이 되어있는데요.

x86_64의 경우 여기에서 추가적으로 넣어주어야 합니다. (그래들 파일)

그리고 빌드 배포할 때, Generate Signed Bundle / APK를 클릭하시고, 선택을 하게 되면 위에 번들과 APK 파일이 있는데요. 위 번들을 설정하시고 NEXT 버튼을 누르셔서 release를 누르시면 확장자 aab라고 되어있는 파일이 생겨있습니다. 이 파일을 구글 플레이에 올리면 됩니다.

구글의 키 정책 변경 — 혼동과 도가니

앱은 구글 플레이 콘솔로 접속해서 개발자 계정을 만드신 뒤에 올리면 됩니다.

https://developer.android.com/distribute/console?hl=ko

Google Play | Android Developers

Google Play Console로 앱과 게임을 게시하고 Google Play에서 비즈니스를 성장시키세요. 앱의 품질을 개선하고, 사용자층과 소통하고, 수익을 창출하기 위한 여러 기능을 활용할 수 있습니다.

developer.android.com

먼저 애플리케이션 만들기, 그리고 스토어 등록 정보에 정보들을 기입하시고!

캡처샷과 아이콘 사진을 첨부, 그리고 앱 버전을 클릭하셔서 여러 가지 트랙 중에서

프로덕션 트랙에 올리시면 실제로 앱이 론칭되는 구조입니다.

예전 키 체인방식이 아니라서 구글이 자기네들이 키를 가지고 있고 그걸 토대로 돌리라는데 너무 복잡해졌어요.

혹시 궁금해하시는 분들을 위해 링크를 드려봅니다.

https://source.android.com/security/apksigning/v3

APK 서명 체계 v3 | Android 오픈소스 프로젝트 | Android Open Source Project

source.android.com

뭐 좋은 건 알겠는데… 잘 안되더라고요.

빠른 포기…

예전 방식으로 키 만들고 사인하고 올렸습니다.

구글 플레이의 리젝

와 앱스토어(IOS)가 아니라 구글에서 리젝 당할 줄은 몰랐네요.

리젝 사유는 여러 가지가 있었는데요. 몇 가지 사례들을 소개해 드립니다.

이 핑퐁을 몇 번이나 해서 겨우 통과했네요.

결론적으로 처음에는 정보상 기재 시에 사실이 아닌 정보를 빼라는 내용이었고요. 뭐가 사실이 아닌지 난감했는데, 이런 부분도 고려해야 한다는 것, 그리고 3세 이상으로 가족정책 안에 포함되다 보니, 증강현실 앱을 실행할 때, 위험성을 경고하라는 것이었습니다. 문제는 이 경고 문구를 고치고도 몇 번이고 리젝을 당했었는데요.

다시 핑퐁 하고 나서야 겨우 통과가 되었네요. 이 승인됨이라는 단어가 너무나 반갑고 좋은!!!

https://play.google.com/store/apps/details?id=com.restyart.AyyeFriend

한글 여행앱(AR) — 한글놀이 | 한글배우기 | 한글VR앱 | 한글떼기 — Google Play 앱

한글도 배우고! 국내 여행도 즐기는! 신개념 한글 놀이형 앱!! 모두모두 주목! 한글 캐릭터로 신나게 한글을 배우는 시간이에요! 한글 어렵게 배워서 아이들이 한글을 어려워할까봐 걱정했던 부모님들 여기 딱 스톱! 재밌고 신나는 한글 앱을 통해서 아이들에게 한글 교육을 맡겨보아요! 한글 캐릭터 앱! 2018년 한글 공모전 수상작! http://www.hangeulaward.co.kr/kor/sub3_update.php 책으로 만나볼 수 있었던 한글 초성 단어

play.google.com

승인된 앱을 공유합니다!

아이폰 앱 론칭기

안드로이드의 론칭이 끝나고 아이폰을 론칭했는데요.

기존에 아이폰 소스 수정해서 빌드를 해본 적은 있었는데

개발자 계정을 구입해서 등록까지 완료하기는 또 느낌이 새롭네요.

XCode 화면

먼저 아이폰 개발도 마찬가지로 유니티를 통해서 프로젝트가 실행됩니다.

빌드 세팅에 보면 iOS에 Run in XCode라고 되어있는데요 빌드 및 Run 버튼을 누르면 XCode로 실행이 됩니다.

그럼 아이폰 개발이나 소스 작성을 다 알아야 하는가 하면 꼭 그렇지는 않고, 빌드 세팅, 키를 등록하거나 배포하는 방식들을 좀 익숙하게 하면 아이폰을 많이 공부하지 않아도 배포가 가능한데요.

핵심 적인 부분만을 캡처해 보았는데요. Archive를 통해서 빌드한 걸 저장하는 콘셉트로 생각하면 됩니다. 그러면 Organizer로 Archive 된 리스트를 볼 수가 있습니다. 이것을 우측에 Distribute App을 통해서 실제로 론칭하는 과정을 하면 됩니다.

이런 과정을 수행하기 앞서서

https://developer.apple.com/kr/

Apple Developer

developer.apple.com

먼저 애플 개발자 사이트로 접속하셔서

우선 129000.. 1년 개발자 계정을 구입합니다.

구입이 완료되면 Membershiop에 해당 개발자 프로그램의 멤버십에 가입되었다는 내용이 나옵니다.

문제는 DUNS 넘버였는데요.

사실상 이걸 하려고 엄청 고생했는데

생각해보니 저나 제 와이프가 법인이 아닌데

괜히 이걸 하려고 시간을 낭비했네요.

이 던스 넘버를 얻기 위해서 이것저것 시간을 썼는데,

던스 넘버를 요청하기 위해서 사업자 번호 및 다양한 절차들이 필요했고,

문제는 이때 발급받은 숫자를 기억하고 있어야 했는데요. 급하게 갑작스레 전화가 걸려 올 때 이런 전화를 받아야 발급이 된다는 부분도 있고 했다는 부분이었어요.

따라서, 법인이신 분들은 아이폰 출시하실 땐 일정 참고해서 론칭 최소 2달 전부터는 준비하시는 것을 권장드려요.

아이폰 개발자의 등록이 완료되면,

App Store Connect에 접속하시면 됩니다.

처음엔 아무것도 없어요 + 버튼을 누르셔서 앱을 생성하시고,

앱 정보를 입력해 주시면 됩니다.

어떤 앱인지 어떤 내용도 다 작성해 주시고,

앱 버튼 아이콘과, 캡처 화면들도 작성해 주시면 되는데요.

특이사항은, 아이폰 캡처 화면의 경우, 정확한 픽셀로 넣지 않으면 안 된다는 부분이 있어요. 실제로 캡처를 해서 해당 부분으로 넣어도 사이즈를 맞추어야 하는 번거로움 들도 존재합니다.

웹상에서 무료로 사이즈 조절하는 사이트가 있었는데요.

그런 사이트들을 활용해서 겨우 맞춘듯해요.

그리고 아이폰과 마찬가지로 아이패드도 해당 캡처 화면을 모두 입력해 주어야 합니다.

안드로이드의 론칭과 조금 다른 특이점은

XCode 를 통해서 해당 론칭이 되게 되면, (미리 개발자 키 세팅이 되어있어야 합니다.)

그럼 바로 론칭이 되는 게 아니라 상단에 나와있는 TestFlight라는 곳에 빌드된 파일이 먼저 올라오게 되는데요. 이 과정에서 테스트를 거쳐서 정상 빌드가 완료되어야 하고,

이 테스트 플라이트에 올라온 파일을 기반으로 심사를 요청할 수 있다는 사실입니다.

그리고 아이폰도 리젝을 많이 당했는데요.

.

메일함입니다.

2월부터 약 한 달간 아이튠즈와 소통한 내역인데요?

정말 어마어마합니다. 안드로이드와 비교가 안됩니다.

2월 안에는 꼭 론칭해야 하는 상황이었기 때문에, 요구사항들을 수렴하기 위해서 노력을 많이 했는데요.

아이폰의 특징은, 증강현실 사용 시에 설명서가 반드시 있어야 한다는 것이었어요. 그래서

따로 설명 신을 추가해서 개발하게 되고,

또 소스 타깃 정보를 Zip 파일로 제공해야 합니다. 어디서 해당 파일을 얻을 수 있는지 정보들도 동시에 제공해야 하는데요. 업체 입장에서는 해당 파일들이 실물로 있어야 하는 경우들이 있어서 구매를 필요로 할 수도 있고, 한데 꽤나 복잡하게 되어있었습니다.

그리고 자녀 사용 시에는 문제 같은 것을 넣어서 자녀가 마음대로 사용할 수 없게 하라는 문구…

그래서 곱셈 문제를 하나 중간에 로직처럼 넣었습니다..

또 추가적으로는 아이폰의 경우 백버튼이 존재해야 한다는 게 기본적인 사항으로 존재하고 있었는데요. 이런 규격들도 꼼꼼하게 챙겨야 한다는 부분이 조금 디테일이 필요한 부분인듯했어요.

마지막에는 과감하게 앱 설치 기준을 17세 이상으로 바꾸었어요..

( 뭐 부모님 나이가 다들 17세 이상일 테니까요 아하하하… )

그리고 빠른 심사로 겨우 겨우 2월 안에 통과….

아래는 그 결과물 아이폰 링크입니다.

https://apps.apple.com/kr/app/%ED%95%9C%EA%B8%80-%EC%97%AC%ED%96%89%EC%95%B1-ar-%ED%95%9C%EA%B8%80%EB%86%80%EC%9D%B4-%ED%95%9C%EA%B8%80%EB%B0%B0%EC%9A%B0%EA%B8%B0/id1496509424

‎한글 여행앱(AR) — 한글놀이 | 한글배우기

‎한글도 배우고! 국내 여행도 즐기는!++ 신개념 한글 놀이형 앱 모두모두 주목! 한글 케릭터로 신나게 한글을 배우는 시간이에요! 한글 어렵게 배워서 아이들이 한글을 어려워 할까봐 걱정했던 부모님 여기 딱 스톱! 한글앱들이 유료라서 넘 돈이 아까우시죠?! 여기 재밌고 신나는 한글 앱을 통해서 아이들에게 한글 교육을 맡겨보아요! 한글 캐릭터 앱! 2018년 한글 공모전 수상작! 책으로 만나볼 수 있었던 한글 초성 단어 찾기 책에 이어! 한글 여행 앱으로 만

apps.apple.com

완성된 화면들입니다.

말도 많고 탈도 많았는데요.

초기에 서적 및 인터넷 자료로 다 모았고

1~2달은 동작 원리와 화면 구성

그리고 3달~4달은 구현 및 기기별 구현에 집중

5달은 론칭에 온 힘을 쏟았네요.

물론 일 마치고 주말 간에 하느라

밤낮이 없었다는 게 힘든 부분이었지만 말이죠.

NGUI의 한계가 있는 상황에서 예전 소스로 대부분 구현하려니 매끄럽지 않은 부분도 있었는데요.

암튼 간 5개월간 재밌는 경험 했다고 생각해봅니다.

맺음말

약 5개월의 과정 중의 모든 과정들을 설명할 수 없어서 아쉽지만,

개발 경험들을 공유하고,

또 이런 흐름 가운데 필요한 맥락들을 찾을 수 있으면 좋을듯해서 공유자료를 남겼습니다.

확실히 일반적으로 실무를 했을 때와 사이드 잡을 했을 때의 느낌이 다르긴 한데요.

뭔가 새로운 영역에서 시도해보는 것도 재미있는 일이라는 생각이 들었네요.

뷰포리아의 경우 문제가 있다는 이야기를 많이 들어서,

시간이 되면 다른 AR 라이브러리를 활용해서 바꾸는 작업을 해볼까 생각 중이기도 한데요.

연습 삼아서 다루어보기에는 개념잡기에 좋은 것 같다는 생각을 해봅니다.

안드로이드, 아이폰 관련 툴을 조금 알아야 하고, 제가 설명하지 않은 키를 만드는 방법이나 키를 생성하고 등록하는 방법들은 인터넷에 많이 나와있는데요.

그런 부분들을 찾아서 하나씩 적용하는 과정이 결코 짧고 간단한 과정들은 아닌데요.

이런 과정을 통해서 또 배울 부분들이 존재하는 듯합니다.

제 입장에서는 최근 안드로이드로 론칭한 적이 없었고, 주로 업데이트 수준이었는데요.

아이폰도 이렇게 론칭을 위해서 커뮤니케이션해본 경험도 중요한 부분이었다는 생각이 듭니다.

소문으로만 들었던 리젝들에 대해서 경험할 수 있던 시간이었고요.

확실히 안드로이드로 개발을 해본 입장에서 유니티로의 한계점도 분명 존재하는 듯했습니다.

게임이나 이런 영상 관련으로 만들기에는 쉽고 편한데,

UI 적인 측면이나 데이터를 다루는 입장에서는 꽤 라이브러리가 부족하다(유니티)는 느낌도 있었고,

무료로 된 Asset 들을 사용하려는 차원에서, 해당 소스들의 버전들이 잘 안 맞아서 소스가 잘 안되어서 걷어내야 하는 경우도 있고, 쉽지 않다는 생각을 했어요.

이 글이 앱을 준비하고 있거나 혹은 증강 현실에 관심 있던 분들에게 조금이나마 도움이 되었으면 좋겠네요.

혹시 유니티 관련 혹은 앱 관련으로

궁금하신 부분들은 답변해드릴게요.

이상 5개월간의 유니티 증강현실 앱 경험기였습니다.

감사합니다.

다른 직종, 혹은 다른 일을 꿈꾸며 살아가는 순간이 올 수 있다고 생각합니다.

특히 이런

개발자로써 언어를 뛰어 넘어 직종을 바꾸는 일은 매우 간단하거나 쉬운일은 아닌데요.

그 직종 전환에 대해서 이야기 해보려고 합니다.

먼저

자바 개발자

리엑트 개발자

두가지 직종의 차이점을 간단히 설명하고 이야기를 해볼까 합니다.

기존에 자바 개발자라면 사실 굳이 리엑트 개발자로 전향할 필요는 없을 텐데요.

그래도 새로운 기술을 추구하거나, 계속 자바만을 고집하기 싫은 분들의 입장에서는

한번쯤 읽어볼만한 이야기가 될 수도 있겠네요.

자바 개발 9년, 자바 개발자가 알아야 할 것들

자바 개발자에 관련된 이야기는 종종 써왔는데요.

아직 개발자가 아닌 분들의 입장에서는 어떻게 하면 자바 개발자를 할 수 있을지 물어볼 수 있을것 같네요.

시대적인 흐름이나 어떤 방향성들로 직종간 변화가 일어나고 있는지 늘 주의 깊게 보아야 한다고 생각을 하는데요. 자바 개발자의 경우, 우리나라가 흔하고 많은 개발자의 직군이라고 볼 수 있습니다.

주로 큰 기업들의 경우 자바기반으로 코드가 되어져 있습니다. 그렇다고 해서 모든 기업들이 자바를 사용하는 것은 아닌데요. 국가 프로젝트의 경우, 자바 개발이 꽤 많은 부분을 차지하고 있습니다.

보통 학원 수업, 학교 수업을 토대로도 자바의 이모저모들을 접할 수 있는데요.

회사내에서 사용하는 경우 일반 자바 언어만 알아서 되는 것은 아닙니다. 다양한 프레임 워크들을 알아야 하는 경우들이 있는데요. 스프링 프레임워크, 스트럿츠 프레임워크, 스프링 부트 등등 자바 프레임 워크들에 대한 이해와 지식이 필요합니다.

자바 개발자로써 알아야 할 기본적인 내용들에는 스프링 관련 서적들을 보면 잘나와있지만, 객체 지향에 대한 이해, 그리고 myBatis 와 같은 ORM 에 대한 이해, 데이터베이스를 다룰 수 있는 쿼리를 작성할 수 있는 기술적 지식에 대한 이해, 그리고 산업이나 해당 프로젝트의 성향과 그것에 따라서 데이터를 확인하고 데이터 베이스를 설계할 수 있는 능력등등이 기본적인 내용들이라고 할 수 있습니다.

그리고 보통은 자바의 개발의 경우는 jsp형태로 화면을 많이 사용하고, 그리드 솔루션들을 많이 사용하는데요. 전체적으로 jquery, ajax 통신 각종 라이브러리에 대한 이해들이 요구되는 사항들입니다.

이런 과정중에 젠킨스나, 빌드, 배포 등등 CI/CD 와 같은 배포 및 자동화에 대한 이해가 필요하기도 하고, git, bitBucket, github, svn, cvs 같이 소스 형상 관리를 비롯한 툴들을 설치하고, 학습하고, 관리하는 부분이 필요하기도 합니다.

그리고 이클립스, 인텔리제이와 같은 툴 사용법들을 공부할 필요성도 있는데요.

결국 서비스를 만든다는 것에 대해서 전반적인 이해와 함께, 그것들을 사용하는 도구, 그리고 그것에 대한 활용 능력에 대해서 능력들이 필요하게 됩니다.

사실 이런 정보들의 나열만으로도 검색을 통해서 많은 정보들을 접할 수 있습니다.

이 자바 개발을 할 때 필요한 추가적인 정보들로는 그래들, 메이븐과 같은 라이브러리 의존성 관리에 대해서 이해가 필요한데요. 이런 라이브러리들을 잘 사용함으로써, GSON, JSON, XMLParser 등등의 데이터 관리 포멧에 대해서 이해할 수도 있고, 다양한 이미지 라이브러리나 파일 업로드, 혹은 엑셀 다운로드 등등의 다양한 부분들에 대해서 학습할 수 있게 됩니다.

리엑트가 필요한 이유!

자바 개발자로써, 대부분의 서비스들은 만들 수 있었습니다. 웹상의 서비스는요. 물론 앱도 자바로 된 부분은 어느정도 개발이 가능하긴 했지만, 한계를 느꼈던 부분이 있습니다.

그건 백엔드와 프론트엔드가 구분되기 시작하면서부터, 역할에 대한 논란이 가중되기 시작한 거죠. 그냥 일반 자바 개발자와 클라우드 백엔드 개발자 등의 경계가 모호해 지기 시작합니다.

시장은 클라우드 개발자를 뽑으면서 백엔드 개발자를 뽑고, 자바 개발자를 뽑으면서 클라우드 서비스에 대한 이해도가 높은 사람을 요구하고, 데브옵스라는 이름이 대두되면서, 사실상 백엔드, 프론트엔드, 클라우드 개발자, 데브옵스 개발자 등등의 영역간의 모호성들이 많아지기 시작했습니다. 그냥 자바 개발자, 이 타이틀와 그 어떤 시스템을 만들수 있는 능력만으로는 약간 부족하다는 느낌이 들기 시작한거죠.

이미 많은 업체들에서는 이런 전문성을 바탕으로 전문 영역들을 고도화 하고 있는데, 백엔드면 백엔드, 프론트면 프론트 확실한 업종들이 분별될 수 있는 상황과 시점으로 시장의 분위기는 바뀌어 가고 있었습니다.

SPA — 싱글 페이지 어플리케이션 이라는 개념들이 대두 되면서, Vue, React, Angular 등의 프론트 언어가 대두 되기 시작했는데요. 물론 SSR 을 적용하게 되면서 큰 의미없는 논쟁이 되어버리긴 했지만, SPA 의 적용은 웹 푸시를 비롯해서 다양한 장점들을 가지고 있습니다. 확실히 페이지 이동간에 깜박임도 적긴 합니다!

이런 상황에서 기존 자바 개발자로써, 자바 개발을 할 때 jsp 를 고집하는 것 자체가 매우 지금의 시대랑 동떨어진 일이라는걸 매번 느끼고 있었는데요. 상황에 따라서 어쩔 수 없이 jsp 를 써야 하는 환경 자체는 기술적인 부분에 있어서 조금은 고통스러운 일이었습니다.

3년 전, 그래서 엥귤러에 대한 공부를 시작했는데요. 프론트 언어에 대해서 새롭게 이해할 필요성이 있었고, 그냥 자바 개발자가 아니라, 최소 백엔드에서 백단은 자바로 개발하고, 프론트단은 다른 언어로 개발할 필요성을 느끼게 된거죠.

그리고, 엥귤러를 했던 경험을 토대로, 리엑트를 공부하다보니, css 를 다루는 방식, 컴포넌트나 라우팅 방식이 매우 흡사했고, 전체적인 구조적인 부분들을 공부하는데 있어서 조금은 편하게 학습을 할 수 있었습니다.

자바와 리엑트의 차이점

이런 자바와 리엑트에 대해서 몇가지 차이들을 나열해 볼까 합니다.

개발 툴의 차이

개발툴이 사실상의 큰차이가 있을까 싶지만, 엥귤러를 사용할때, 이클립스 상에서 angular cli 를 이용했었는데요. 리엑트를 사용하게 되면서 거의 VSC(Visual Studio Code) 를 쓰게 되었습니다. 파이선 사용자나 기타 예전에 아톰과 같은 툴을 쓰던 분들도 많았을텐데요. VSC 도 거의 비슷하게 여러가지 설치가 가능하고, 설치된 정보를 토대로 다양한 명령어들을 실행할 수 있습니다.

가장 큰 차이점이라고 보는 부분은 이런 자바는 이클립스, 리엑트는 VSC 이렇게 사용하는 툴 자체가 변하다보니, 이클립스에서는 여러가지 세팅에 대해서 프로젝트 세팅에서 신경써주어야 할 부분이 많았다고 한다면, VSC 의 경우는 몇가지 언어를 사용할 수 있도록 세팅하는 부분, 그리고 터미널코드를 많이 사용하는 부분이 좀 많은 변화라고 볼 수 있습니다.

깃 사용 방식의 차이

이클립스에서는 대부분의 명령어들을 마우스와 UI 로 처리가 가능합니다. git 에 올리거나 내리는것도 UI 를 통해서 가능하죠. 물론 소스트리 같이 도와주는 것들을 설치해서 진행할 수 있는데요. 주로 VSC 에서는 UI 보다는 커맨드 창을 통해서 깃을 더 많이 사용하게 됩니다.

배포 방식의 차이

배포의 경우는 회사별로 다양한 부분이 있었습니다. 직접 배포를 하는 곳부터 젠킨스 배포를 하는곳까지, 리엑트쪽을 사용하게 되면서 pm2 를 사용하게 되었는데, 젠킨스와 같이 매우 편리하게 배포하는 기능을 탑재하고 있었습니다.

DB 의 차이

기존에는 주로 mysql, oracle 을 많이 사용해왔는데요. 그러다 보니 데이터를 만들거나 조인하거나 하는 과정들이 툴을 통해서도 많이 진행을 하고, 그렇지 않더라도, 데이터 구조 자체가 테이블 형태이다 보니 그런 사고 방식에 익숙해져 왔습니다. 리엑트로 전환하면서 mongoDB 를 사용하게 되었는데요. 그러다보니 기존의 체계와는 확실히 다른 느낌의 데이터 가공을 느끼게 되네요.

개발 방식의 차이

개발 방식의 큰 차이는 없습니다만, 전반적으로 기획 — 개발 설계 — 개발 진행 — 개발 완료 — 개발 반영 — 운영 반영의 프로세스에 있어서는 큰차이가 없습니다. 내부적으로 자바를 개발할때는 우선적으로 어떤 것을 개발해야 하는지 개발 화면을 보고, 데이터가 있는지 디비를 만들어야 하는지, 혹은 데이터를 어떻게 뽑아 낼지를 생각한 다음에 해당 쿼리를 만들고, 해당 쿼리를 xml 에 담아서 매퍼로 연결한 뒤에 바인딩한 정보를 토대로, 해당 쿼리 아이디를 호출하고, 그것들을 인터페이스화된 매퍼 정보 — 그리고 서비스 객체를 통해 컨트롤러 단에서 모든것들을 불러오게 되어있습니다. 그리고 그 정보를 기반으로 페이지간 전환도 하고, 그 데이터를 가지고 jsp 화면단에서 뿌리던지 아니면 json 형태로 가공하던지 하는 방식들을 선택하게 되어있는데요.

이렇게 리엑트 방식에서의 개발의 경우 데이터 가공에 대해서는 비슷하지만 만약 스프링 — 리엑트였다면 훨씬더 비슷한 방식으로 데이터를 가공하고, 리엑트 상에서는 바인딩된 데이터만 뿌리면 될텐데요. 현재는 Meteor 를 사용하고 있습니다. 즉 미티어 상에서 해당 데이터를 선택하고, 가져오는 방식이 크게 달라졌습니다. JSON 방식의 데이터를 선택 조회 하는 부분에 대한 이해도가 조금 더 필요하게 되었고, 프론트 상에서는 prop, state 같은 리엑트에서 데이터를 다루는 방식에 대한 이해가 더 많이 필요하게 되었는데요. 기존에 jsp 같은 경우는 하나의 jsp 즉 html 파일 같은 파일안에서 구조를 만들다 보니 전체 구조가 jsp 파일 내 순서와 연관성이 있어서 하나의 구조를 이해하면 되었는데요. 리엑트의 경우 컴포넌트 단위의 개발이 쉽고 용이하게 개발이 가능하다보니, Table 하나를 만들더라도 컴포넌트 방식으로 만들어서 불러올 수 있고, 랜더링 방식이나 호출 순서들에 대해서 이해가 많이 필요한듯합니다. 처음 데이터를 매핑하고 하는 부분이 어렵긴 하지만, 실제로 데이터를 가져와서 프론트에 뿌려준 이후에는 그 데이터를 활용하는 것이 기존의 jsp 에 비해서 훨씬 쉽고 재밌어 졌다고 볼 수 있는데요. 이런 과정들을 이해하는게 개발의 묘미인 부분이 아닌가 싶네요.

라이브러리의 차이

라이브러리의 경우 앞서 위의 자바 개발에서 언급했지만, 기존에는 gradle이나 maven 과 같은 것들로 라이브러리들의 의존성들을 관리해왔습니다. 즉 라이브러리의 업데이트나 최신화부분을 해당 gradle, maven 으로 진행을 했었는데요. 리엑트를 사용하면서 VSC 를 사용하다보니, 해당 부분에 대해서는 npm 즉 패키지 파일을 통해서 노드 패키지 메니져를 통해서 모듈 단위로 설치하고 삭제하게 되었다는 점입니다. 그러다보니, nvm 이라는 노드 버젼의 충돌을 막기 위한 버젼 관리에 대한 이해, 그리고 모듈들이 설치되고 삭제되지 않을때 발생하는 여러가지 문제들에 봉착하게 되는데요. 기존의 자바 프로젝트의 경우 이런 모듈들이 안정화 되어있기때문에 거의 수정할일이 없지만, 이렇게 오픈소스들을 활용한 프로젝트의 경우는 버젼단위로 달라지는 여러가지 이슈 문제로 인해서 해당 부분에 대해서 검색하거나 찾아보아야할 부분이 많아졌습니다. 덕분에 다양한 모듈과 컴포넌트들을 경험해 볼 수 있는 기회들이 생기게 된거죠.

scss 의 차이

공고를 보면 Scss 에 대한 이해를 요구하는 경우를 종종 보게 되는데요. css 에 대한 계층간 구조와 미디어쿼리등등에 대해서 이해도가 높다면 크게 어렵지 않습니다. 자바에서는 css 만을 쓰다보니, scss 에 대해서 약간 부족할 수도 있는데 이런 부분들이 차이가 있었다고 볼 수 있습니다.

고려해야할 사항

언어를 바꾼다는 것에는 리스크가 존재합니다. 즉 다른 언어로 돌아가기 어려울 수 있다는 부분입니다. 물론 회사의 사정에 따라서, 기존에 노드 베이스에서 백엔드를 자바로 바꾸기도 합니다. 아마도, 지금 있는 회사에서도 데이터 트래픽이 많아진다면 그렇게 전환 할 수도 있겠죠. 문제는 이런 기존의 데이터들을 새롭게 정형화 시키고 또 다시 API 형태로 가공하는건 매우 중복적이고 지루한 일이 될 수도 있다는 것입니다.

그럼에도, 기존에 안정적을 언어를 알고 있었다는 점과, 그리고 리엑트에 대한 경험을 할 수 있게 되었다는 점자체가 큰 매리트입니다.

현재 페이스북, 리엑트 개발자의 연봉들이 꽤나 높게 측정되었다는 점을 고려해본다면, 이렇게 전향한다는 것, 매우 고무적인 일이 아닌가 싶네요. 국내 서비스중에 리엑트로 된 서비스가 얼마나 많은지는 아직 잘 모르겠습니다. 아마도 엥귤러, 뷰, 리엑트 이 세가지 언어들은 프론트 상에서 계속 발전할 것이라고 생각합니다. 최근 연봉 순위에도 해외에서는 꽤나 높은 연봉으로 나왔으니 말이죠.

아직 국내에서는 SI 시장에 개발자들이 많이 있고, 기존의 자바 개발자의 입장에서 새로운 언어, 리엑트 같은 것들을 배워서 다시 이직을 한다는 것이 작은 리스크로는 여겨지지 않을 것입니다. 꽤나 큰 리스크로 생각이 들텐데요. 프리랜서를 하고, 정규직을 가고, 또 언어를 배우게 되고, 또 새로운 일을 해보게 되는 것.

협상을 잘 할 수만 있다면, 충분히 고려해 볼 일이 아닌가 합니다.

프로젝트 이력서를 보다보면 다양한 이력들이 있는 분들이 있습니다. 다양한 컨포넌트와 다양한 경험과 경력들이 마이너스 요소가 되진 않으니 말이죠.

물론 웹개발자 — 앱개발자 전향시의 리스크는 자바 개발자에서 리엑트 개발자의 전향보다 얼마나 큰 리스크로 작용할지는 또 경험해보아야 할 수 있는 대목일 것 같네요.

맺음말

개발자로써 10년째를 맞이하고 있습니다.

10년전에 개발자로 몇년이나 먹고 살 수 있을까? 전전 긍긍하면서 이 직업을 선택했는데요.

그 당시 눈감고 10년까지만 일한 다는 생각으로 개발일을 해보자 이렇게 생각하고 벌써 10년해가 되었네요.

그나마 다행인건, 그냥 동사하지 않았다는 것 같습니다.

그리고 여전히 개발하는 일이 재밌다는 것. 이 두가지가 흥미로운 점이 아닌가 싶네요!

시대를 가로 지르고, 재미있는 일들에 새로움을 쫓는 분들 응원합니다!

* 현재 제가 있는 회사에서 또 새로운 일에 대해서 함께할 사람을 찾고 있습니다!

리엑트 베이스다보니, 리엑트 네이티브를 할지도 모르고, 요새 뜨고 있는 flutter 를 할지도 모르겠네요~!

* 함께 할 분들은 아래 공고를 참고해주세요~!

https://www.notion.so/igogo/8d8f7668d82b4399a3d21806875d26de

고생은 사서 한다더니 이건 아닌듯.

지난 글에

캐릭터 디자이너 남편으로 살아보기라는 글을 기재했었는데요!

그 결과 책이 완성이 되었습니다.

오늘은 그 책이 완성된 이후의 이야기!

뒷 이야기를 진행해보려고 합니다.

https://brunch.co.kr/@chickenmoim/10

캐릭터 디자이너, 남편으로 살아보기

우여곡절 끝에! 와디즈 펀딩이 종료되었습니다.

종료가 되면 끝이 아니라 새로운 시작입니다.

책을 만들어야 하고! 많이 성원해 주신 분들께 이것저것 챙겨드려야겠죠!

그래서 좋은 분(?)의 소개를 통해!

책을 만드는 공장을 찾아갔습니다!

그리고 책을 제작을 시작했습니다!

대부분의 많은 책들은 출판도시 파주! 그곳에서 책들이 만들어집니다~!

충무로와 같은 인쇄소에서도 책을 제작할 수는 있지만 단가 경쟁력이 떨어지기 때문에!

어느 정도 단가를 맞추기 위해서는 많은 수소문이 필요합니다!

어느 업체에서 진행하는 것이 좋은지 소량은 어느 정도까지 가능한지 알아보아야 하고 견적도 내야겠죠?!

책은 책마다 책 커버, 책 내용, 그리고 양장본인지 한 페이지 한 페이지에 들어가는 종이 재질에 따라서

가격은 천차만별로 가격이 달라지게 됩니다.

저희는 동화책과 비슷한 책이었기 때문에

어떻게 하면 좋은 느낌을 줄 수 있을지 많은 고민을 했습니다.

좋은 책 커버를 써야 된다는 생각을 했고, 종이 재질도 저렴한 재질이 아니라 좋은 재질을 써야 한다고 생각했죠. 그만큼 단가가 올라가긴 했지만, 어찌 보면 출판사로써는 단가 경쟁력에 문제가 있을 수 있다고 생각했지만

아이들이 보는 책이니 만치 좋은 책을 만들어야 한다고 생각했어요!

그 결과

요렇게 책이!! 만들어졌는데요.

책을 출판하기에 앞서서 심각한 고민을 하게 됩니다.

단 일주일. 그 일주일간 고민이 필요했는데요.

이 책을 만들 때, 출판사에게 모두 맡길 것이냐…. 아니면 출판사를 차릴 것이냐의 중대한 고민을 하게 되었죠..

그 실수의 첫발…

맞습니다. 제가 선택했습니다……

지옥으로의 첫발… (아내는 임신중인데요 흑흑 전 나쁜 아빠 ㅠ)

고스란히 출판사를 차리는 일부터 시작해서 출판사 등록, 등등의 일들은 아내가 하는 작업….

물론 이유는 있었는데요.

기존의 서적! 단춧구멍 책.

1쇄 이후에 더 이상 소식이 없는 책… 많은 후기들이 있었고… 나름대로 계속 팔리고 있는 거 같긴 한데.

좋은 후기들 덕택에 나름대로 책을 만든 일이 자랑스럽다고 생각은 하고 있지만…

2쇄가 진행되지 않는 책… 소식 없는 마케팅. 그리고 첫 인쇄 이후에 끝나버린 소식들

책을 처음 제작할 때 사용했던 여러 가지 영상 제작부터 북트레일러까지 직접 제작하고 유통하고 배포했었지만,

사실상 이런 책을 만들고 유통하고 알리는 과정상에서 출판사의 역할이 매우 제한적이고, 많은 책을 만들다 보니, 특정 작가나 특정 책을 띄워 줄 수 없는 확실한 구조적인 부분을 알게 되었거든요.

그러니 결과적으로…

직접 책을 만들어서 유통하고 광고하고, 알리는 방법밖에 없겠다는 생각이 들었습니다.

그래서, 책을 만드는 곳에 찾아가게 되었고, 단가를 맞추고 제작을 의뢰하게 되었죠!

와디즈는 그 마중물의 역할을 충실히 해주었습니다.

이렇게 책을 포장하기 위한 포장지도 사고

이렇게 소모를 차곡차곡…

거의 50여 개의 소포를 만들었는데요…

와 50개 하는 일도 이렇게 힘들 줄 몰랐네요.

상자 포장, 책 포장, 스티커 포장, 배송지 입력 및 택배 선택 및 이동

손수 제작한 손편지와!

요렇게 예쁘게 만들어진 종이가방 증정 이벤트!!

이렇게 사람들에게 좋은 것들을 주는 일은 너무나 기쁘고 좋은 일이지만…

이렇게나 힘들 줄은 몰랐습니다.

먼저 책이 나오고 나서 감리를 보는 과정을 경험하게 되었는데요!

책이 나올 때는 이렇게 판형에 이미 내용물들이 길고 크게 나옵니다.

색을 변경이 가능한데 문제는 이 색을 한 페이지씩 점검하기 때문에 이런 색깔을 보정하는 작업을

잘못하다가는 전체적인 색감에 영향을 줄 수 있거든요? 그래서 처음에 첫 색깔 보정 이후에는

수정하지 않는 게 좋을 것 같아요.

만약 출판사를 끼고 하는 경우는 감리를 시켜주는 경우도 있다고는 하는지 안 시켜주는 경우도 많다고 하네요.

그래서 이런 부분을 색을 중요시하는 출판사나 개인의 경우는 꼭 감리를 가시는 것을 추천드립니다.

이렇게 감리를 마치고 나서!

감리가 끝나면 책이 바로 인쇄됩니다!! 신기하죠?!

바로 뚝딱뚝딱 감리 이후에 1주일 이내에 책이 나옵니다!!

그다음 순서는 배 본사를 선정하는 일인데요.

만약 출판사와 계약을 하게 된다면

이런 일들은 신경 쓸 필요가 없습니다. 왜냐면 출판사가 알아서 해주기 때문이죠.

출판사와 인세 계약의 경우 비밀스러운 일이어서 공개가 쉽지 않지만,

대략적으로 5~15% 사이로 크게 범위를 잡아보겠습니다. 이 정도라고 생각하시면 되는데요.

작가들 입장에서는 먹고 살기에는 터무니없이 적은 금액이라고 할 수 있습니다.

아… 안 되겠다.

큰 출판사에 넣어 본 뒤에 생각을 해보았는데.

그냥 차라리 좋은 작품을 만들었다면, 조금 더 공격적으로 할 수도 있는 것이고~!

널리 알려져야 한다는 생각을 했거든요.

그래서 지옥에서 온 유혹. 출판사를 하자고 말했습니다.

그러고 나서 해야 하는 일의 목록.

인디자인으로 책 넘기기

책 편집하기

KC 인증하기

겉에 있는 종이와 내지 그리고 안에 종이 재질 선택하기

가격 선정하기

ISBN 등록하기

사업자 등록하기

사업자에 종목에 서적 출판업 넣기

배본사 계약하기

교보문고 입점시키기

YES24, 인터파크, 영풍문고, 알라딘 입점하기

배본사 SCM 익히기, 세금 계산서 발행하기

교보문고 협력사 네트워크 들어가기

인터넷 팩스 등록하기

카드 리더기 등록하기

배본사 시스템 이해하고, 발주하기

SNS 홍보하기

맘카페 리스트업 및 맘카페 홍보 멘트 돌리기, 그리고 맘카페에 홍보 문구 작성 및 책 배송

책 소개 및 출판사 소개 등록하기

와… 길죠? 어떻게 이런 일들을 다 할 수 있게 되는지 모르겠네요.

출판사가 알아서 해주어야 하는 목록들인 셈인데요. 이걸 혼자서 다하거나 같이 할 사람이 있으면

나쁘지 않은 것이지만, 처음에 그냥 인세 몇 프로에 만족하고 그냥 시간을 보냈어야 하나 싶은 순간들이…..

위 리스트를 처리하는 과정은 정말 너무나 고되고 길고 힘든 과정입니다.

처음으로 교보문고를 입점했던 날.

출판의 시작을 알렸습니다.

파주 단지에 차를 타고 갔는데요! 교보문고를 먼저 갔습니다.

그 당일날 배 본사 계약과 교보문고 계약을 동시에 진행했습니다.

첫 출판을 하는 경우

신간 도서를 가지고 가야 합니다. 그리고 미리 연락을 통해 미팅을 잡은 뒤에 신간 계약하는 곳에서

기다리면 되는데요

2~4시까지밖에 안 하기 때문에 대기를 하고 기다려야 합니다.

보통은 60~65 공급률을 이야기합니다.

공급률이란 10000원에 판매했을 경우 6500원을 우리에게 주겠다. 그리고 3500원은 서점이 가지겠다고 하는 계약인데요. 보통 책의 원가를 고려했을 때, 매장 가격과 유통 마진 등등 여러 가지 차원으로 권당 6500원을 가져갈 수 있게 되는 셈인데요. 꽤 괜찮다고 느낄 수도 있지만, 만약 책 한 권에 5000원에 만들었다면, 1500원의 마진밖에 안 남는 것이고 택배비까지 부담하게 되면 마진이 거의 안남을 수도 있습니다. 즉, 이 단가에 대해서 정책을 잘 세워두지 않으면… 그냥 내 돈 내고 이익이 없는 일까지도 나올 수 있게 되는 거죠.

즉 한 권을 생산할 때의 단가, 그리고 한 권당 이익을 볼 수 있는 가격, 그리고 판매 수익 등등에 대한 계획과 계산을 잘해야지 수익을 볼 수가 있습니다.

우리는 저희는 우여곡절 끝에 잘 쳐주셔서 공급률을 받게 되었는데요.

계약서를 쓰고~! 책을 70권을 받아주셨습니다.

보통은 책이 한 권이라도 계약이 되어있어야 책을 많이 받아주는데요.

책의 퀄리티를 보시고, 이 책을 받아주는 기준에 따라서 급수가 정해진다고 하는데 10권 30권 50권 70권 100권 1000권 등등 아마도 책이 어느 정도 잘 나갈 것인지를 예측하는 듯싶습니다.

전국에 뿌리고 뿌려서 매대에 잘 올라갈지 아닐지의 여부가 결정되는 듯합니다.

그러고 나서 그 주변에 있는 배본사로 갔습니다.

배본사가 왜 필요한지 의구심이 있었는데요.

가보고 나서 생각이 많이 달라졌습니다.

즉 책의 권수가 많고, 그걸 보관하거나 배송하거나 하는 그 과정들이 어렵기 때문에 이것들을 시스템에 맡긴다고 보면 됩니다.

배본사에 따라서 각각 가격대가 다르게 형성되어 있는데요. 배본사의 유통 구조가 또 보다 보면 배본사가 또 다른 배본사에도 맡기는 구조여서 이 부분을 잘 알아보시면 좋습니다. 저희는 좀 어찌해서 상위 배본사와 계약을 하게 되었는데요~!

월 10만원의 금액으로 저렴하게 배본을 하게 되어서 편하게 일을 처리할 수 있게 되었죠.

배본에 맞기게 되면

저렇게 와디즈 펀딩의 포장을 직접 해야 하는 과정을 다 하지 않아도 되어서 너무 좋습니다.

편의점에서는 대량 택배를 별로 안 좋아하기 때문에 편의점 아저씨에게 눈칫밥을 먹었는데요….

그래서 그냥 다음엔 우체국에 맡기고 보내게 됩니다 ㅎ

자 그래서 배본사와의 계약도 완료.

하나의 출판사와의 계약을 하기 위해서는 다양한 서류들이 필요한데요.

이 모든 서류를 보내고 나서~ 계약 단가가 맞게 되면! 이제 끝! 이제 출판사 소개와 내용들을 정리해서 보내면 됩니다.

이 과정이 끝이 나고! 온라인 계약 팀과도 계약이 끝이 나면 네이버에 노출되기 시작하는데요.

이렇게 한글 초성 단어 찾기라고 치면 네이버 책으로 노출 완료.

그리고 바로 구매 항목에 지금까지 계약한 서점들 리스트가 나오는데요! 도서 11번가와 반디앤루니스, 커넥츠북은 따로 계약하지 않았는데 뜨는걸 보면 다른 회사와 연결이 되어있는것 같아요!

첫 출시는 12월 12일 벌써 시간이 꽤 지났는데요.

이제 12월 말일이 다 되어가는 시점.

처음에 교보문고 입점했을 때,

매장 재고에 이렇게 되어있는 것을 보고! 아 드디어 입점했다.

근데 매대에는 정말 올라갔을까? 팔리긴 할까?!

이런 생각이 많이 들었는데요.

각각 지점에 전화하지 않으면 신간이어도 구석에 들어갈 확률이 아주 많은 듯합니다.

큰 업체가 아닌 이상 그것을 매대에 올리는 것은 각 지점의 권한.. 통화도 많이 해야 하고

잘 부탁드린다고 말씀도 드려야 하고.. 큰 곳에 입점할수록 더 힘든 거 같아요.

그래도 잠실점에 들려서 매대에 올라간 것을 확인!! (제발 잘 좀 보이게 해주세요 ㅠ)

책이 잘 래핑 되어서 올라왔네요!!

아 이제 뚫을 것은 다 뚫었으니까 마케팅을 해야 하는데요.

저희는 좋은 기회가 2번 정도 있었습니다.

하나는 한글 공모전 부스에 참여할 수 있는 기회가 있었는데요.

요래 요래 한글 창의 아이디어 공모전 수상작들을 전시하는 곳에!

들어갈 수 있는 기회,

다들 바쁘셨는지 작품 출시한 두어 분만 오시고! 나머지 한글 팽이와 함께 저희 부스를 주셨는데..

업.. 뭔가 죄송스럽게 저희 부스가 ㅎㅎㅎㅎ 너무 큰 건가 싶을 정도로 감사하게도 좋은 자리를 주셨어요!

ㅅ으로 시작하는 단어 찾기 이벤트도 진행하고!

한글 초성 단어 찾기 책도 보여드리는 기회!

책이 많이 팔리진 않았지만, 출시와 맞추어서 홍보할 수 있는 기회였고요!

그다음 겨울 행사.

핸드메이드 페어 부스에 참여 기회가 생겼는데요. 슈퍼 끼어로 참가자에게 지원하는 혜택!

이렇게 부스 활동을 통해서 또 몇 권을 팔 수 있는 기회!

그리고 다른 홍보활동은 맘 카페를 통해서 진행했는데요!

맘카 페들에게 쪽지와 메일을 보내고~

그 결과 서평 이벤트를 여러 군데서 진행할 수 있게 되었는데요~! 생각보다! 호응이 좋았어요~! 총 6 군데서 진행을 했는데요~!

보시면 느끼시겠지만! 많은 조회수와!

많은 참여율! 좋은 제품이 아니라면 느낄 수 없는 사람들의 호응!!!

우선 책이 너무 잘 나왔기 때문에 이 제품을 경험하게 되면 꼭 팔릴 거라는 생각을 했는데요.

일단 많은 분들이 접할 수 있도록!! 열심히 책을 수급!!! 많은 분들의 참여 감사합니다.

https://cafe.naver.com/nowbook/1588065

https://cafe.naver.com/booksales/1027073

https://cafe.naver.com/bookchildlove/1514007

https://cafe.naver.com/2daumnet/421777

https://cafe.naver.com/plusiplay/20588

https://cafe.naver.com/aldisgo123d/655099

이렇게 총 진행한 카페들입니다~!

아직도 몇 군데는 진행 중이긴 한데요~!!

슬슬 이제 후기도 올라오고 있어요~!

[책키] 책으로 키우는 우리 아이 - STEAM 책육아

와우! 서평 넘 잘 써주셔서 감사합니다!!

그리고 페이스북 마케팅 진행!!

그 결과 책이 계속 팔리고 있는데요~!

교보 문고 협력사 네트워크를 통해서 판매 부수를 확인 가능합니다.

기존 출판사가 아닌 경우는 작가로서는 몇 권이 팔렸는지 어느 정도 진행된 건지 몰라서 답답한 부분이 많은데요.

출판사가 되고 나니 이런 부분은 없어져서 너무 좋네요.

약 15일간 14권 정도! 즉 하루에 1권 정도씩은 팔렸다는 소리인데…

뭐 다른 출판사에서도 꾸준히 팔리고 있으니!!

현재까지 총 판매량은 와디즈 포함 70~80권 정도가 되겠네요!

15일간 그래도 어느 정도 책이 팔리긴 팔리는 거 보니 아주 망하진 않을듯합니다!!

그래도 이렇게 출판사를 차리는 과정은 쉽지 않은 고배이고 힘이 들고

많은 노동력이 들어갔는데요.

아무런 성과가 없기만 한 것은 아닙니다.

두 군데에서 추가적으로 상을 수상했는데요~!

한글송과 애니메이션! 등등의 발표 등을 토대로! 수상 경험 획득!!

책만 만들고 하느라 힘이 들었겠지만~! 그래도 나름대로의 수상 경험과 함께 다양한 경험이 추가로 생기고 있어요. 이건 좋은 일입니다.

결론은.

혼자 출판하는 과정이 쉬운 일도 아니고

책이 팔린다는 일이 너무나 신기하고 재미있는 일이지만,

계약서를 작성하는 일부터!

홍보를 해야 하는 것들까지 너무나 다양하고 많은 일들을 해야 한다는 점

유통이 뚫기가 어렵다는 것들 한번 더 체감한 상황입니다.!

그럼에도 불구하고! 좋은 제품을 가지고 있다면,

한번 출판사 도전부터 1인 출판과 창업들이 많아지는 이런 시점에서~!

한번 도전해보려고 한다면 시도해 볼만한 일이라고 생각하네요~!!

이상 정말 힘들고 어려웠지만, 그래도 꾸역꾸역 해나가고 있다.

이상으로 이번 글은 마칩니다~!

PS. 기타 언급이 어려운 내용들은 생략한 부분들이 많이 있는데요~! 쪽지나 다양한 방식으로 연락을 주시거나 비밀글 등으로 문의하시면 알려드릴 수 있는 부분은 최대한 알려드리도록 할께요.!

#스타트업 #출판 #1인출판 #아예와한글친구들 #한글초성단어찾기책 #한글초성단어찾기

오늘은 실무에 대한 이야기를

해보려 합니다.

학생 때 늘 실무가 중요하다는 이야기를

많이 들었는데요.

정작 그 당시에는 그 실무에 대해서

실체도 모르겠고 공부하는 것이랑 일하는 것

그 차이점이 무엇인지

몰라서 많은 시행착오를 겪었는데요.

회사에 들어가기 전에

미리 알아두면 좋은 것들을

실무를 한다고 할 때 필요한 것들을

좀 정리해서 말씀드려볼까 합니다.

시간의 중요성 (일정 관리)

학교 공부 혹은 학원 공부와 달리 가장 많은 비중을 차지하는 것 중에 하나는 일정 관리가 아닐까 생각을 해봅니다. 무엇보다 나의 시간이 아닌 의뢰자의 시간, 회사의 시간관리라는 점이 포인트입니다.

실무에서는 매우 시간이 빠르게 흘러갑니다. 그 시계가 빠르다는 말은 일을 해야 하는 사람이 바빠진다는 이야기입니다. 어느 정도 예상을 할 수 있겠지만, 일이란 것들의 대부분은 일정이 존재합니다. 뭐 개발자라면 일정이라는 게 늘 바뀌는 것이 아닌가?라고 생각하거나 예측해 볼 수도 있지만, 일정에 대한 규칙이 없으면 모든 일들은 처리가 되지 않은 채로 계속 둥둥 떠다니고 말 것입니다.

첫 프로젝트는 2달 만에 뭔가를 해야 하는 상황이었습니다. 보통은 신입사원에게는 약간 리스크 있는 일들을 주지 않습니다. 이것은 좋은 점이기도 하지만 안 좋은 점이기도 합니다. 왜냐면 신입의 입장에서는 일을 배워야 그 배운 일을 써먹을 수 있고, 그래야 그다음에 다른 일들이 오더라도 당황하지 않을 수 있고, 경험이 생겨야 그 경험을 다시 활용할 수 있는데, 이것이 없으면 세월은 흐르고, 연차는 쌓이고, 자신감은 없어지고.. 뭐 그런 일들이 발생하거든요. 옛말에 어려서 일은 사서도 한다고, 뭐 그런 비슷한 측면으로 신입에게 일이 주어지는 건 어찌 보면 러키 한 일입니다. 처음에 엔지니어링이라는 회사에서 해외 관련 업무들을 많이 했는데, 신입 입장에서 해외 현지에서 사용하는 블로그 시스템을 만들라는 이야기가 나왔습니다. 대신에 조건은 기존에 소스가 있으니까 해당 소스를 잘 커스터마이징 하라는 것이었고, 제 입장에서는 이 제안을 마다할 필요는 없었습니다. 아직 업무에 배정되지 않는 상황에서 해보겠다고 했습니다.

2달 만에 완성해야 하는 기획, 디자인이 있는 일을 해보게 된 거죠.

회사를 오기 전에 절대 경험할 수 없는 것들 중의 하나는 협업입니다. 누가 기획서를 작성하게 되는지, 일은 어떤 방식으로 넘어오는지, 디자인은 누가 하는지, 디자이너와 트러블에 대한 이야기들을 들어본 적은 있는데 그게 실제로도 그러는지 등등 이런 협업의 관점에서 사실 첫 단추는 운이 좋았습니다.

퍼블리싱을 하는 디자이너를 만났기 때문입니다. 2달 안에 모든 것들을 해야 한다니 신입의 입장에서 매우 빡빡하고, 누가 뭘 알려주는 것도 아니고, 게다가 웹이라는 것이 익숙하지 않은 저로선, ajax에 대한 개념 조차 매우 희박해서, 댓글이 달린다는 것 자체만으로도 매우 신기한 상황이었습니다. 화면 전환이 없이 뭔가 처리되는 상황.. 문제는 혼자서 이 시간적인 압박을 보내야 한다는 것이었는데요.

처음엔 문제가 많았습니다. 디자인만 입히고, 대강 들어가야 할 위치에 다 들어가고 하니까 끝이 난 것 같았는데, 충분한 경험이 없는 신입의 입장에서는 빈구석이 많았던 것입니다. 예를 들면, 댓글, 대댓글 쓰기, 그리고 관리자의 권한 문제, 글에 대한 권한, 글에 대한 수정, 게시글 형태와 블로그 형태 타입 별로 다르게 들어가는 로직들, 댓글의 순서 문제… 그냥 네이버 블로그 보면, 혹은 블로그 프로젝트한다고 하면 그냥 별 볼 일 없게 생각하던 것들이, 실제로 블로그를 하려고 하다 보니, 보이는 것부터 보이지 않는 것까지 해야 할 게 많았습니다. 그리고 생각보다 생각을 해야 할게 많았는데요. 와 근데 시간은 짧은데 이걸 다 해야 하고 발견해야 하고 수정해야 하고 다 고쳐야 한다니. 시간에 대한 막막함.. 이 것을 종결시켜야 한다는 그 압박 생각들 아마도 이런 게 가장 시간 관리에 있어 어렵고 힘든 게 아니었나 생각을 해봅니다. 이런 어려운 상황 속에서도 시간 내에 어떻게든 끝을 냈었는데요. 그렇게 하니 그런 부분들이 인정받게 되고, 개발 부서로 변경되는데 이런 상황이 고려받게 되었습니다. 이렇게 시간을 관리하고 일정을 지켜내는 것들. 이것을 하나씩 하다 보면 자연스럽게 회사 내에서 인정받게 됩니다.

내가 하고 싶은 공부가 아닌 해야 하는 일을 하는 것

회사에 들어가기 전에 전 안드로이드 개발을 하고 싶어 했습니다. 그런데 업무적 배정은 웹 개발자가 되었죠. 물론 다른 선택의 기회들이 더 있었는지는 모르겠지만, 회사에서 그렇다고 안드로이드를 개발할 수 있는 상황들이 많이 주어지진 않았습니다. 즉, 업무적 특성이라는 차원인데요. 지금은 9년 동안 개발해오는 시간적인 혜택(?) 때문에 많은 경험들로 안드로이드 외주도 해보고, 안드 개발 업무들도 해보았었지만, 그 당시 업무가 정해지고 나면, 해당 업무를 바꾸거나 하는 일들은 거의 일어나지 않는 일이었습니다. 즉, 내가 하고 싶은 일을 무조건 할 수 있는 상황은 아니었던 거죠. 하지만 그 안에서 회사가 바라는 목표점과 지향점이 있는데, 그것들은 해야 했습니다.

9년 전에 스트럿츠라는 프레임 워크가 있었습니다. 토인비라는 시스템도 있었죠. 그 당시로써도 상당히 오래된 프로그램이었지만, 이런 프로그램들을 걷어낼 수가 없었는데요. 이런 것들을 걷어내려면 새로운 개발이 필요하고, 또 새로운 개발은 돈이 들고, 이 새로운 개발에 생기는 버그들도 고스란히 비용이기 때문에, 아마도 최대한은 적은 비용으로 유지 보수를 하기 위해서 예전 것들을 활용하는 상황. 파워 빌더도 꽤 오랫동안 사용되고 있던 것이긴 했는데요. 사실 그 당시 실무로 스프링을 써보고 싶었지만, 내부에서 사용하는 것이 스트럿츠였기 때문에 스프링을 접하기까지는 2년이라는 세월이 더 걸린 뒤에나 해볼 수 있었습니다.

이렇듯 하고 싶은 일을 하고 싶어도, 회사에서 경험할 수 있는 환경이 주어지지 않으면, 하기 어렵다는 것이 이런 실무의 단점이라고 할 수 있습니다. 즉 첫 단추가 중요하다는 이야기가 많은데, 첫 회사에서 지금 자주 쓰이거나 많이 쓰이는 것들을 학습하지 않다 보면, 나중에 이걸 하려고 해도 너무 늦었다고 느껴지거나 도저히 지금 회사들이 나아가는 방향들을 따라갈 수 없게 되어버려서… 다시 도전하기 어려워질 수 있기 때문인데요.

그럼에도 불구하고, 그 안에서 최선을 다하고, 그것들도 익숙하게 되는 것이 이런 실무들의 경험들이라는 생각이 드네요.

배운 것은 절대 남 주는 게 아니다! 결론은 부지런히 다른 일들을 해보기

회사를 다니면서 매년 목표가 있었습니다. 신입이든 경력이든 성장에 대해서 갈급함은 누구나 있는데요. 처음에는 메일링 시스템이 궁금했습니다. 누가 안 알려줬거든요. 그러다가 메일 관련해서 돈 안 되는 프로젝트를 하나 하게 됐는데, jsp, jstl 관련해서 메일을 운영하는 서비스를 하나 만드는 거였는데 그게 약 150만 원짜리 일이었는데 누가 도와달라고 해서… 2명이서 나눠서 했고.. 2달 동안 약 한 달에 35만 원이라는 금액으로.. 일종의 간식 먹는 기분으로, 나름대로 이 프로젝트를 통해서 메일 프로토콜 pop3와 smtp를 공부하게 되었고, jstl을 공부하게 되었었는데요. 이게 사내에서 사용하는 프로젝트가 jstl을 쓰고 있었기 때문에 삽질(?)들을 토대로 회사에서는 나름대로 삽질을 적게 하고 일을 하게 됩니다. 그 바람에 일의 생산성이나 능률은 훨씬 좋아졌는데요. 삽질이 들어간 만큼 정보를 취득하는 시간은 짧아집니다. 그 시간을 미리 경험했기 때문에 그 안에서의 프로젝트가 훨씬 수월 할 수 있었습니다.

그 뒤에 궁금했던 것은 쉘에 대한 궁금증과 인프라에 대한 궁금증이었는데, 그 당시에 엔지니어링에서 인프라를 꽉 쥐고 계신 차장님께서 인프라 관련된 다양한 것들을 시키셨는데, 그때 사내 메일링 관련된 항목과 인프라 장비의 모니터링 툴 개발도 한번 수정해보라고 시켜보시는 바람에 그런 업무적인 서버 내에 대한 접근 권한들을 가지고 서버에 대해 공부할 수 있는 기회들도 주어졌습니다. 사실 첫 업무가 인사 업무에다가, 경영지원 쪽 개발 업무였기 때문에 인프라 관련된 업무들을 접하기 쉽지 않았지만, 결국 관심이 있으면 다양한 업무에 대해 경험해볼 수 있는 기회들이 생기더군요.

그다음 궁금했던 것은 DB 설계하기, 학생들이 많이 궁금해하는 것들 중 하나는 DBA 가 되고 싶어요. 디비 관리자가 돈을 많이 받는다고 들었어요. 저도 초기엔 이런 측면에서 기획을 하는 분과 디비를 설계하는 분들이 너무 멋있어 보여서, 어떻게 하면 데이터를 다룰 수 있을지 디비를 만져 볼 수 있을지, 뭐 그런 기대감 들로 한껏 마음이 부풀어 있었는데요. 실무에서는 약간 더 데이터에 관해서 예민하기 때문에 데이터를 관리하는 권한을 잘 주지는 않습니다. 물론 그에 대한 책임감과 결과를 잘 알고 잘하는 사람들에게는 좀 더 그 시점이 빨라지기는 하지만, 종종 잘못된 쿼리로 실무 데이터를 날려버린 사람들의 이야기들은 전설로 전승되기 때문에 이런 데이터에 대해서 만져보고 만들어보기 까지는 시간이 걸렸는데요. 경영 지원 업무들을 하면서 신규 프로젝트가 내부에 많았는데요. 인사 데이터 기반, 부서 데이터 기반 강연 시스템, CEO 블로그, 사우 협의회 블로그, 사내 포탈 관리, 팝업 관리 등등 내부 시스템에 대해서 유지보수 후에 신규로 프로젝트할 일이 많아졌고, 그런 데이터를 많이 만지다 보니, 데이터가 있어야 할 곳에 데이터를 있게 하고, 복잡한 칼럼들은 개발을 어렵게 만들고, 쿼리 하나에 30~50줄 되는 걸 보면서, 꼭 이렇게 했어야 했을까 생각을 하다가도, 그래야만 하는 상황을 납득하기도 하면서 조금씩 데이터에 대해서 많이 생각해보게 되었는데요. 이처럼 실무를 하다 보면 그래도 실제로 사용하는 사람들이 사용하는 데이터를 만져보게 된다는 것. 그 학생 때는 엄청 막연하다 보니 프로젝트를 진행하게 되어도, 그 사용자를 생각하면서 만드는 것이 아니라, 만들어 보고 싶은 것을 만들어보게 되어있는데요. 이런 시각적인 차이가 아무래도 실무과의 가장 큰 차이가 아닌가 싶어요. 고객이 원하는 것. 그것을 얼마나 잘 만들어주는지..

그 뒤에도 프로젝트를 해보고 싶다고 늘 생각하고 있었는데, 차세대 프로젝트에 투입도 해보고, 스프링을 써보고 싶다고 생각했는데 스프링 프로젝트도 써보게 되고, 엥귤러를 쓰고 싶다고 생각했는데 스타트업에서 엥귤러도 써보고, 리엑트도 해보고 싶다고 생각을 했는데 지금은 리엑트를 하고 있네요.

경험을 쌓는 과정들이라고 생각해요. 어떤 지점에 가기 위해서는 하나의 단계 단계들을 밟게 되어있는데 계속 멈추어 있을 순 없으니까, 지금 하고 있는 일들은 앞으로 더 나아가기 위한 성장 동력들이 아닌 가 싶네요~ 하시는 것들의 의미들을 잘 생각해보시고, 지금 하는 일들에 낙심하지 마시고, 한 번에 원하는 것을 얻는 경우도 있지만, 돌아가는 경우도 많다는 것.. 생각해 보시면 좋을 것 같네요.

실패를 통한 성장(회사는 완벽한 사람을 좋아한다)

첫 실패는 대학 졸업 미스였어요. 여러 가지 과정 중에 실패가 없었을 거라고 생각하는 분들도 계시지만, 누구나 실패는 하잖아요? 제 실패는 경영학 복수전공을 하고 싶어 했는데, 그것 실패했어요. 그 부분도 사실 중요한 실패 중 하나라고 생각하고 있지만, 대학 학부 때 삼성 관련해서 특점 학점을 채우면 준다는 제도가 있었는데요. 굳이 생각하면 왜 그걸 했나 싶지만, 마지막 학기에 그 때문에 1학점이 비게 되고, 졸업을 한 학기 정도 뒤에 하게 되었는데요. 복수전공을 한 뒤에 회사를 가려던 계획이 물거품 되면서, 갑자기 회사를 가야 한다는 압박과 실무를 경험해야겠다는 생각이 들게 되었는데요. 그 실패를 통해서 개발자의 삶이 시작되었던 게 아닌가 싶네요.

그때 첫 회사로 내비게이션에 들어가는 음성 인식 회사, 지금은 꽤나 커져버린 회사에 들어가게 되었고, 그 회사에서 음성 인식 관련 업무를 2달 정도 했었었어요. 그 뒤에 이직을 하게 되었지만, 이 앞의 과정에서 게임 회사 면접도 해보고, LG 관련 프로젝트도 해보고, 그리고 안드로이드 개발 외주도 취업 전에 해보았었는데, 그 실패의 경험도 매우 쓴맛으로 남아있습니다. 2달 정도의 프로젝트였는데, 기존에 합의했던 내용을 번복하면서, 마지막 날 다 바꿔달라고 하더라고요.. 그냥 깔끔하게 포기했지만, 세상엔 별별 사람이 다 있다는 것을 인정하는 계기가 되었죠.

경험을 가진채 새로운 회사에서 시작하는 것은 마치 전직과도 같은 느낌입니다. 처음부터이기도 하지만, 새롭기도 하지만, 이미 경험치가 있어서 조금 더 빠르게 성장할 수 있으니까요. 많이 실패해보는 것이 좋다고 생각합니다. 프로젝트도 많이 해보고 많은 사람들이랑 프로젝트도 해보고, 또 다른 성공의 발판이 될 수도 있고 실패했다고 해서 결코 그게 부끄러운 일은 아닌 것 같아요.

다만 그 실패를 통해서, 남는 건 있어야겠지만 말이죠. 개발 외주 관련해서는 검증된 회사와 일해야 하고, 그리고 지인을 통해서 하는 게 무조건 좋은 일이 아니라는 점. 누구랑 일하는지 어떤 일을 하는지도 매우 중요하다는 것들.

하지만, 다른 곳에서는 많은 실패를 하더라도, 지금의 회사에서는 최소한의 실패를 보여야 한다는 것이 실무적 관점이라고 생각을 합니다. 회사에서는 딱 성과를 보여야 하는데, 그 성과가 안 나오면, 낙인이 찍힙니다. 이 낙인은 매우 무서운 거라서, 평가는 가중되거든요. 잘하는 사람이라고 인식되면, 계속 평가가 좋아요. 그리고 못한다고 생각되면 계속 평가가 안 좋죠. 이게 실전인 건데요. 그럼 어떻게 잘하는 사람으로 인식될 것인지, 이게 바로 핵심적인 일입니다. 다른 곳에서 실패하더라도 회사에서는 실패하지 않아야 합니다. 즉, 다른 곳의 실패의 이유는 회사에서 실패하지 않기 위해서라는 것이죠. 뭐 그렇다고 삶에서 일부러 프로젝트를 망치거나 어그러트리라는 것은 아닙니다. 늘 실패하지 않기 위해서 최선을 다하는 것은 동일하지만, 실패에 대한 리스크 햇징.즉, 실패를 분산해야 한다는 거죠. 최대한 회사에서는 실패하지 않는 것을 의도함으로써, 그나마 가장 완벽한 것들을 회사에 가져다줄 때, 비로소 찾아오는 보상들.. 그것을 경험해야 합니다.

새로운 언어에 대한 진입 장벽 낮추기(언제든 갈아탈 준비)

개발자의 입장에서 다양한 언어들을 배우는 것은 중요합니다. 존경하는 선배님이 계신데, 그분은 저와 1년밖에 차이가 안 나셨지만, 이미 학부 졸업 시점에 10가지 정도의 언어를 하셨어요. 아직도 너무 대단하신 분이시라!

(찬란)

언어의 개수가 개발 실력을 판가름 내진 않습니다. 한우물만 파는 게 나을 수도 있죠. 하지만, 거시적 관점에서 너무 한우물만 파다가는 물이 안 터지는 경우도 있습니다. 시대가 급변하고 있고, 언어의 종류도 너무 많아지고 있습니다. 언어적 기준점 이외에도 플랫폼적으로도 세분화되고 있기 때문에 개발자의 이름을 붙이기도 너무 복잡해지고 있습니다. 자바 개발자, 파이선 개발자, 안드로이드 개발자, 아이폰 개발자, 리엑트, 뷰 (프런트 개발자), 백엔드 개발자 — 뭐 언어를 붙여야 할지 플랫폼을 붙여야 할지… 너무 많아져서 서로가 서로를 알아보기에도 헷갈리는 느낌까지 듭니다. 그만큼 학생들 입장에서도 배워야 할 것도 너무 많아지고 있고, 뭐부터 해야 할지 몰라서, 기본적인 개발 언어들을 배우다가 끝이 나버리기도 하는데요.

실무에 있다 보면 필요에 따라서 언어가 바뀌기도 합니다. 갑자기 CGI를 해야 하는 경우도 생기고 php를 해야 될 때도 있고, 또 자바나 기타 안드로이드, 아이폰까지 하게 되는 경우들도 있는데요. 원래 한 회 사에 계속 근무하는 경우는 오히려 근무 환경상 변화가 없는 경우도 많지만, 프로젝트를 하거나, 다양한 업무 선상에 있게 되다 보면 다양한 언어에 노출되고 해야 하는 경우들도 생깁니다. 즉, 기회가 생기게 되는데요. 만약 그런 기회가 있어도, 만약 기존에 준비가 되어있지 않으면 시도도 못해보는 경우도 오게 됩니다. 현재 회사는 몽고 디비에 리엑트를 사용 중입니다. 전 자바 개발자이지만, 3년 전부터 엥귤러에 관심이 있어서, 엥귤러 뷰 리엑트 3가지 중에 하나는 해야 한다는 생각이었고, 거의 엥귤러에 관련해서 해외 사이트를 통해서 공부하면서 일을 해보고 있었어요. 근데 실제로 오퍼는 리엑트로 들어오게 된 거죠. 리엑트 관련해서도, 책을 통해서 흐름을 익혀놓긴 했었는데요. 만약 리엑트에 관해서 준비를 하나도 하지 않았다면 아마 일을 받지 않거나 거절했을 것이라는 생각이 드는데요.

마찬가지로, 새로운 언어에 대해서 미리 준비하지 않고 있다면, 시대의 변화에 대응을 하지 못하면, 결국에는 도태거든요. 과거의 것들로부터 탈피할 준비를 계속해야 합니다.

학부 때 배우는 너무 오래되고 낡은 것들.. 그런 낡은 것들도 구수하긴 하지만, 새로운 것들에 대해서 받아들일 준비를 해야 해요. 실무 다른 것 없습니다. 지금 현재 회사들에서 필요로 하는 스펙들을 조사하는 것부터 시작해보는 게 중요하다고 생각합니다.

그리드, 컴포넌트, 엑셀 그 외 세팅하기

실무에 자주 쓰이지만 잘 모르는 것 중에 하나는 그리드입니다. 그리드라는 것이 아주 공통적으로 사용되는 용어는 아닌데요. 대부분의 툴에서는 그리드라고 이름을 많이 붙이는 듯합니다. 그리드는 엑셀 같은 표와 같이 데이터를 처리하고 수정하고 저장할 수 있게 만들어주는 라이브러리 중 하나입니다. 다양한 그리드가 있는데요. 관리자 페이지들이 이런 그리드 형태로 많이 되어있습니다. 이런 그리드의 데이터 처리가 중요한데요. 실제로 실무상에서는 조회 페이지나 검색 페이지들을 개발할 일이 아주 많습니다. 실무자들이 보는 화면들 중에는 데이터를 검색해서 봐야 하고 수정해야 하고 검색해야 하는 것들이 매우 많습니다. 이런 일들을 처리해 주기 위해서는 이런 그리드 화면이 필수라고 할 수 있죠. 그리고 컴포넌트는 그런 그리드들을 사용하거나 다양한 것들을 사용하기 위해서 필요한 항목들인데요. html로 보면 <input>, <areatext>, <select>, <datepicker> 등등의 컴포넌트를 의미합니다. 즉 화면상에 나오는 입력화면, 텍스트 화면, 에디터, 선택하는 버튼, 그리고 날짜 선택이나 캘린더 등등 개발에 필요한 다양한 컴포넌트들이 있는데요. 자주 사용한 사람의 입장에서는 뭐 뭐가 되었든 가져다 쓰면 되는 게 아닌 건가 싶지만, 실무를 안 해보거나 이런 부분을 자주 접하지 않은 입장에서는 이런 칼렌더 하나도 가져다 쓰는 것을 생각하는 것이 아니라 다 하나씩 개발하느라고 시간들을 보내는 경우가 많거든요. 물론 이런 하나하나를 개발하다 보면 내부 로직을 이해하고 실력이 쌓이긴 하지만, 개발 시간을 단축시켜줄 수는 없습니다. 이런 차원에서 이런 컴포넌트들을 찾아보고 이해하고 알아두는 것은 매우 중요합니다.

시간 날 때 깃허브에 들어가서 다양한 컴포넌트나 라이브러리를 찾아보는 일도 매우 중요한 일이죠. 그리고 이미지를 업로드하거나 엑셀을 업로드 다운로드하는 다양한 라이브러리를 사용해 보는 것, 그리고 개발 환경을 세팅해보는 일들, 이런 사사롭고 소소한 일들은 매우 시간이 걸리지만 누가 잘 파악하지 못하는 일들 중 하나일 것입니다. 지금 처음에 배울 때 이런 항목들을 잘해보면서 많이 찾아보면서 배워두는 일 중요한 것 같아요.

회사에서 특정 일들을 하다 보면 대부분이 매뉴얼화되어있기 때문에 설치 과정 조차 거의 매뉴얼 대로만 하면 되어서, 거의 개발에만 집중하게 되어있기 때문에 관심을 가지지 않다 보면 프로젝트를 하려고 하더라도 이런 세팅에 대해서는 매우 난감한 상황이 발생할 수도 있으니까요.

커뮤니 케이션 하기 (사람마다 다른 상사)

실무에 가장 어려운 것 중 하나는 커뮤니케이션입니다. 요새 회사들은 이런 커뮤니케이션 스킬을 배우거나 늘리기 위해서 다양한 것들을 하고 있는데요. 기업문화를 바꾼 다던지, 지라나 빗 버킷, 깃허브 같은 툴을 도입한다던지, 노션 같은 것들을 도입한다던지 하는 툴을 바꾸고 문화를 바꾸는 문화들이 조금씩 자리를 잡고 있습니다.

하지만 가장 어려운 것 중에 하나는 나의 상사가 어떤 사람일지 알 수 없다는 부분인데요. 대표가 어떤 사람인지 모르고, 상사가 어떤 사람인지 모르기 때문에 그냥 커뮤니케이션을 잘한다. 일을 잘한다. 이것 자체가 성립하기 위해서는 윗사람과의 코드를 잘 맞추어야 합니다.

윗사람이 야근을 좋아하는 사람일 수도 있고, 자리를 오래 지키는 걸 좋아하는 사람일 수도 있고, 일을 너무 잘하지 않길 바라는 사람일 수도 있거든요. 이 모든 것들은 회사가 각기 특이한 특이점들이 있기 때문입니다. 윗사람의 생각을 뜯어볼 수 없기 때문에 우리는 그 불안감들로부터 자유로울 수 없습니다.

회사가 커지면 정치라는 이야기를 들어본 적이 있을 것입니다. 막 성장하는 회사들은 이런 것을 느낄 틈이 없습니다. 일만 잘하면 되거든요. 근데 이미 커져버린 회사는 이미 수익 구조가 탄탄해졌기 때문에 성장이 도태되는 느낌이 들기도 합니다. 그 뒤에 일어나는 일들은 성장의 맛을 본 사람들이 떠난다는 것입니다. 새로운 성장으로 가야 하거든요. 그렇게 되면 그 뒤에 일은 뻔합니다. 남은 사람들이 나누어 먹기를 하게 되는 거죠. 그럼 그 남은 사람들 밑에 있는 사람들이 바로 그 정치의 피해자가 됩니다. 일을 왜 많이 했는지, 왜 적게 했는지, 그리고 수많은 부서이동, 성과와 실적 같은 것이 어떻게 평가되는지 아랫사람들은 매우 난해해지는 상황들, 현상을 이해하기 위해서는 한 가지만 보는 것이 아니라 여러 가지 상황들을 맞물려 해석해야 합니다. 이렇게 정치적인 상황은 매우 복잡한 상황이 됩니다. 평가의 방식도 난해해지고, 결과도 난해해지니까요.

우린 이런 상황들을 회사기 때문에 보다 자주 겪습니다. 그래서 소통은 어렵습니다. 가치와 주관이 다르고 그리고 이런 상황 속에서 선택을 해야 하기 때문입니다. 따라서 소극적으로 대응할 수 있는 한 가지 방법은 소통에 있어서 그 사람의 성향과 상황에 따라서 맞추어 주는 것입니다. 그리고 그렇게 맞추어 갈 때 소통을 잘한다. 커뮤니케이션이 되는 사람이다라는 이야기를 듣게 됩니다.

사람에게 먼저 맞추면 그다음에 일은 매우 수월합니다. 사람과 사람의 상대가 어그러지면, 일처리도 매우 힘들어집니다. 그건 비단 개발의 문제만은 아니죠. 그렇기 때문에 커뮤니케이션의 가장 중요한 것 중에 하나는 그 사람이 원하는 것이 무엇인지를 파악하는 것입니다. 그때 비로소 일정을 조율할 수 있고, 우선순위를 조절할 수 있고, 그리고 개발 시간과 역량과 결과들이 뒤따르게 됩니다.

그리고 최근 깃과 관련된 기업의 요구사항들이 많아지고 있는데요. 혼자 개발을 하다 보면, 내 코드를 오픈한 적도 없고, 피드백받은 적도 없고, 현재 잘하고 있는 것인지 아닌지를 판단할 기준들이 없기 때문에 함께 코웍을 하면서 개발에 대해서 같이 리뷰 시간을 가져보는 것이 중요합니다.

맺음말

몇 가지 개발의 실무적 상황과 필요한 것들에 대해서 이야기를 해보았는데요.

처음엔 무엇보다 뭔가를 해야 하는데 잘할 수 있을까라는 생각들,

할 수 있을까? 이런 생각들 때문에 머뭇거리는 경우들이 생기는 것 같습니다.

일단 책과 실무의 차이점은, 책은 다 봐야 그다음 뭘 시작할 수 있는데

실무에 있어서는 책을 다 볼 시간이 없다는 점이고요.

시간을 단축하기 위해서는 모든 방법을 동원하게 됩니다.

지인 찬스, 웹 서핑, 분석

일을 잘한다는 건 이런 전제조건에 개입하는 것이 아니라 결과 대해서 이야기하는 것입니다.

과정도 너무 중요합니다만, 개발의 시간을 단축시키는 다양한 방법들

타인의 소스를 이해하고 분석하는 것들을 자주 하다 보면

그 역량이라는 것이 실무라는 것이 좀 더 쉽고 보다 빠르게 이해되는 시점이 오지 않나 생각해 봅니다.

처음부터 잘하는 사람이 어딨나요. 부딪혀보다 보면 잘하게 되지 않나 싶네요!!

#개발 #실무이야기 #현업 #현직자 #개발9년차 #개발자이야기 #개발시작 #대학생 #도움닫기