2 분 소요

Keep : 멋지고 어려운것보단 쉽고 편한게 좋아

​ ‘구글 독스’라는 공유문서를 프로젝트의 공통문서로 사용하자고 제안했다. 여러명이 하나의 문서를 함께 편집할 수 있어 이전 대외활동에서 유용하게 사용했기 때문이다. 물론 실제 개발자들은 깃허브나 팀 노션 등 고기능의 툴을 사용하겠지만 당장 개발을 진행해야하는 우리에게 누구나, 바로 쉽게 사용가능한 도구를 적합하게 골랐던 것 같다. 일을 진행하는데 불편하지 않다면 멋지진 않더라도 가능하면 최대한 쉽고, 간단한 도구를 사용해 일을 진행하는 것이 좋다고 생각한다. 이후 다른 팀이나 이후의 프로젝트에서도 이를 사용해 개발을 진행했다는 얘기를 들어 괜시리 뿌듯했다. 이를 통해 개발자는 항상 새로운 앱이나 기술, 기능을 배우고 활용하려는 자세가 업무 능률에 있어 중요하다는 것도 실감했다.

Problem: 구글링도 실력이야

​ 발표는 수월하게 마쳤고 다른 두팀은 모두 2차원 배열을 사용했는데, 나중에서야 구현이 어려웠던 두팀 모두 깃허브에서 코딩을 찾아 변형했다고 들었다. 당시에는 직접 우리손으로 구현한 우리가 더 잘한 것 같고 대단한 것 같았지만, 개발자에게 있어선 구글링도 실력이고 우린 그 자료를 찾지 못한것이다.

​ 한땀한땀 내 손으로 직접하는게 바람직하다고 생각했고 실제로 이렇게 해야만 진행이 되었던 이전 팀활동들과 달리 명확한 해결책이 있는 문제식 프로젝트의 경우 다르게 접근해야한다는걸 깨달았다. 기존에 이 문제를 해결한 사례가 있다면 이를 적극적으로 활용해 결과적으로 우리의 결과물을 더욱 완성도있게 만드는게, 즉 좋은 코딩을 잘 찾아내 분석하고 변형하는게 더 좋은 방식이다.

​ 우리는 공부중인만큼 일일히 구현하는게 더 의미가 있었겠지만 한정된 시간안에 최대한 효율적으로 일을 처리해야하는 실무에선 이런 교과서적 접근방식은 좋지 않을 것이다. 그래서 처음엔 다른 코드를 활용하자는 조장오빠의 의견에 반대였지만 시간이 지날수록 오히려 좋은 방법이 될 수 있었을거라는 생각이 든다. 대신 그게 쓸만한 자료인지, 활용할수 있는 코드인지 빠르게 알아보는건 결국 충분한 공부가 전제되어야하는 일이기에 공부하는동안은 할 수 있는한 기초부터 쌓아올리는 정석적인 방법으로 코드를 짜는 방식을 유지할 것 같다.

Try : 안되면 틀린거고 구현 못하면 무용지물

​ 개발의 쓴맛을 보았던 첫 프로젝트였다. 짧은 시간내에, 확실하게 결과를 내야하는 프로젝트라 심적 부담감이 굉장히 컸다. 분명한 답이 없고 더 좋은 방법과 덜 좋은 방법만 존재했던, 미완성이라도 가치가 있던 이전의 문과식 팀 활동과 달리 명확한 답이 존재하고 그걸 어떻게든 찾아야하는 이과식 프로젝트는 그 성격이 굉장히 달랐고 노력한 만큼, 시간을 들인만큼 좋아지는 결과라는 공식이 당연하게 성립되지 않는 개발이라는 분야가 굉장히 낯설고 힘들었다.

​ 개발은 좋은 기획이나 설계도 중요하지만 궁극적으로 “그래서, 그거 코딩할 수 있어?” 가 생각보다 더 중요한 분야라는걸 느꼈고 개념공부와 계획이 곧 실제 구현으로 바로 연결되지 않는다는걸 알았다. 굉장히 오랜만에 절대 풀지 못할 수학문제를 만난 느낌. “문과식 사고방식을 버려야한다” 라고 개발자의 길로 먼저 들어선 비전공자 친구들이 한 말이 많이 실감이 났다. 이전까진 더 나은 방향이 있을 뿐 내가 틀렸다고 생각한적은 거의 없다. 하지만 개발에선, 안되면 틀린거고 구현 못하는 설계는 무용지물이다.

​ 이를 빠르게 인지하고 다른 해결책, 방법을 빠르게 모색하는게 중요하다. 안되는건 오래 붙잡는다고 나아지지 않는다. 안되는건 아무리 오래 붙잡아도 계속 안되고 시간낭비일 뿐이다. 이를 인정하고 다른 사람들의 의견에 집중할수록 좋은 해결책이 보인다. ‘내가 틀릴 수 있다’ 라는 당연한 명제를 다시한번 실감했고 나와 나의 방법에 대한 객관화를 명확히 하는 것도 실력인걸 깨달았다. 또한 책으로 개념을 쌓고 쉬운 문제부터 연습하면 자연스레 만드는 실력도 생긴다는 나의 당연한 공부명제도 깨지던 경험이었다. 오히려 코딩을 하면서 필요한 개념을 그때그때 찾는 방식이 개념에 대한 이해도 깊어지고 적용도 잘할수 있다.

댓글남기기

참고