요즘 IT에 로우코드와 노코드에 대해서 글을 기고 했다. 로우코드/노코드 기술이 점점 발전하고 있고, 주변에서 ChatGPT를 이용하여 개발에 도움을 받고 있는 상황이다. 로우코드와 노코드 기술의 발전으로 인해 누구나 개발자가 될 수 있는 시대가 열렸다고 할 수 있다. 이런 열품 속에서 개발자의 미래에 대한 글을 작성했다.
자세한 내용은 여기서 확인할 수 있다.
5/20/2023
3/17/2023
코드 재사용성을 결정하기 전 고려해야 할 것들
요즘IT에 코드 재사용성에 대해 기고를 했다. 업무를 진행하면서 항상 고민되는 점이 “코드 재사용”에 대한 것이었다. 아래 기고글 일부를 발췌했다.
그런데 항상 명확한 결론을 내지 못하고 끝낸 적이 많다. 왜 그럴까? 코드 재사용에 대한 의사결정은 간단해 보이지만 사실 많은 고민이 필요한 일이기 때문이다.
코드 재사용에 대한 논의에서는 종종 다음과 같은 이야기들이 오고 간다.
- 코드를 재사용할 수 있도록 만들어야 다른 팀, 다른 서비스가 이점을 얻을 수 있고 중복 코드 문제를 피할 수 있다.
- 코드를 재사용하려고 해서는 안된다. 복제를 하는 것이 좋은 선택이다. 재사용하려고 하면 분기 로직이 추가되는등 오히려 복잡하게 꼬일 수 있다.
- 다른 팀이 코드를 재사용 할 수 있도록 새로운 서비스를 만들어야 한다.
- 기존 라이브러리를 재사용해야 할까? 아니면 자체 코드를 만들어야 할까?
- 인증 로직은 모든 서비스에 동일하게 적용된다. 모든 서비스에서 재사용될 수 있도록 API Gateway에 추가해야 할까? 아니면 프레임워크로 만들어야 할까?
~~ 중간 생략 ~~
자세한 글은 여기서 확인 할 수 있다.
3/15/2023
일정 관리의 중요성
현재 프로젝트는 태스크 관리를 “Jira”에서 하고 있다.
대규모 인원이 오늘 한 업무에 대해서 로깅을 하는 툴중 무난하게 사용할 수 있다는 판단이었다. (물론 회사 공식툴이기도 하다)
어제는 개발 쪽이 아닌 기획 쪽 파트너사와 일정 관련 업무 미팅을 진행했었다.
일정을 따로 관리하고 있다는 얘길 들어서 우리는 Jira로 관리하고 있고, 함께 사용했으면 좋겠다고 의견을 전달했다.
VPN 접속이 어려워서 불편하다. Task가 너무 많아서 느리다. 등 여러 의견이 나왔다.
툴은 툴일 뿐이고 대규모 인원이 같이 Task를 공유하며 효과적으로 사용할 수 있는 다른 방안이 있는지? Task가 많다면 필터를 만들어서 본 적은 있는지? 등을 문의했고, 결국 Jira를 사용하기로 결정했다.
일정을 짜거나 관리해야 하는 것의 문제는, 거의 모든 프로그래머가 원하지 않는 일이라는 것이다.
내 경험상 대부분의 사람들은 태스크를 디테일하게 관리하면서 업무를 진행하지 않는다. (내가 잘못 생각하는 것일 수도 있다.)
그 이유는 일정은 소수의 사람들로 짜여지기 떄문이다. 그리고 대부분 “일정을 제시간에 맞춘 프로젝트는 극소수야”라고 생각한다. 설령 그렇다고 하더라도 일정 목표가 없이 진행하는 것은 더 큰 문제라 생각한다. 그들을 참여시키려면 그들의 불편함을 덜어주는 방법과 이것이 가치가 있다고 믿게 하는 것이다.
데일리 로그 작성 시, 입력 항목을 최대한 심플하게 만드는 것이다. 예를 들어서 이 작업에 쏟은 시간 + 어떤 일을 했는지 요 정도로만 정했다. (진척률은 모듈 리더분들이 관리) 더 세분화되게 관리를 원하는 분은 하위 작업을 생성할 수 있도록 했다. 불편함을 덜어주기 위해 심플 안을 세웠지만, 디테일을 원하는 분들의 기회도 박탈하지 않기 위해서다.
누군가에게 관리를 받는다는 것을 달가와하는 사람은 없다고 생각한다. (나 역시 그렇다.)
회사 혹은 프로젝트에서 진행하는 일은 “혼자”하는 것이 드물다. 거의 대부분 “누군가”와 협업을 해야 하는 경우가 많다. 이 경우에는 일의 순서가 생긴다. 다른 사람이 끝내야 내 일이 시작될 수 있는 상황이 발생한다는 의미이다.
대부분의 사람들은 재미있는 일을 먼저 하고 싶은 성향이 있다. “일의 순서”를 고려하지 않고 모두 재미있는 일을 먼저 한다면 관리하는 입장에서는 매우 난감해진다. 연관된 일이 미뤄지는 상황이 발생하기 때문이다. 불편함은 존재하겠지만, 함께 일하기에 긍정적으로 생각했으면 좋겠다.
문제 해결을 위해 고민해야 할 것들
팀원들이 타 부서와 미팅을 하고 와서 상기된 표정으로 불만을 토로했다. 정해진 것이 없는 시간만 낭비한 회의라는 것이다. 기존 방식의 알고리즘을 바꾸기로 방향성은 정해진 것 같았다. 내부에서 돌던 분석 알고리즘이 시스템 밖에서 동작이 될 것이고 그 결과를 받아서 애플리케이션에 적용해야 하는 상황이다. 그리고 화이트보드에 모여서 어떤 방식으로 인터페이스를 할 것인지 논의를 시작했다.
가만히 지켜보다가 몇 가지 질문을 던졌다.
“알고리즘이 바뀌면 어떤 영향이 있을지 파악하셨나요?”
“…..”
우리가 일하는 분야에서는 문제 해결 능력이 매우 중요하다. 문제 해결 능력은 위의 상황들이 반복되면서 키워진다고 생각한다. 하지만, 그냥 지나가 버리면 역량을 키울 수가 없다. 아래의 사항들을 항상 고민하면서 업무를 수행해야 한다.
- 문제 해결 과정을 학습 - 문제를 발견하고 해결하는 과정은 다양한 방법과 기술이 포함된다. 본인보다 경험이 많은 동료가 문제를 어떻게 푸는지 학습하고 익혀야 한다. 그리고 주변에서 발생하는 문제들에 대입을 하면서 테스트해봐야 한다.
- 새로운 기술을 학습 - 문제점을 파악했지만, 어떤 기술을 사용해서 해결할지는 지식내에서 결정된다. 따라서 계속해서 새로운 기술과 트렌드를 학습해야 한다.
- 경험을 쌓자 - 문제 해결 능력은 경험을 통해 발전한다. 다양한 상황에 놓여야 복잡한 문제를 해결할 수 있다. 문제가 생긴 것을 원망하지 말자
- 동료와 협력 - 동료와 함께 문제를 해결하면 더 좋은 결과를 얻을 수 있다. 함께 협력하면서 해결하는 방법을 배워야 한다.
- 문제의 본질 파악 - 문제의 본질을 파악해야 한다. 문제를 일시적으로 해결하는 것보다 근본적인 원인을 찾아내어 그 문제가 재발하지 않도록 해야 한다.
- 예측하고 대비 - 발생할 수 있는 문제를 미리 예측하고 대비하려고 항상 고민해야 한다. 문제가 발생했을 때 대처하는 방법을 미리 계획해두면 더 빠르게 해결할 수 있다.
위의 사항들을 참조해서 아래의 형태로 문제를 해결하자고 논의했다.
- 알고리즘이 변경됨에 따라 기존 데이터를 대체하는 것인지, 혹은 일부 유지해야 하는 것인지 확인 (기존 로직을 유지해야 하는지 확인 목적)
- 변경에 따른 시스템 영향도 파악
- 알고리즘 변경에 따라 schema 변경을 해야 할지, 아니면 유지할지 고민
- 3번 사항이 결정되면, 인터페이스 방식 결정
- 인터페이스 방식에 따른 연동 규격서 작성 후 논의
- 개발
미팅 시, 상호 이해 관계가 다른 상황이 많이 생긴다. 이럴 때 가장 중요한 것은 내부를 먼저 파악하는 것이다. 그리고 상대방의 이해 관계를 파악해야 한다. 그래야 상호간 협의 접점이 생기기 때문이다. 손해를 보면서 함께 하려는 사람은 지구상에 없다고 생각한다. (가족 제외)
1/31/2023
위임의 중요성
<출처: https://unsplash.com/photos/a9kHtTbjpwY>
권한을 위임하는 것은 팀을 효과적으로 관리하는 중요한 측면이다. 위임을 통해 관리자는 팀 구성원에게 권한과 책임을 할당할 수 있으므로 구성원이 자신의 업무에 대한 소유권을 가지고 업무에 집중할 수 있다.
이런 행위는 생산성 증가, 사기 개선 및 효율적 리소스 사용으로 이어진다. 하지만 권한을 위임하지 않으면 팀 구성원간의 세부 관리, 신뢰 부족의 현상이 발생할 수 있다. 즉, 관리자가 어느선까지 위임을 하느냐에 따라서 팀의 성과가 달라지게 된다.
권한 위임의 주요 이점은 관리자가 자신의 분야에 집중할 수 있는 여유가 생긴다는 것이다. 팀 구성원에게 업무에 대한 권한과 책임을 할당하고 더 중요한 문제에 집중할 수 있도록 시간과 에너지를 확보할 수 있다. 이는 각각 담당하는 전문 분야에 집중할 수 있기에 생산성 향상으로 이어질 수 있다.
생산성을 높이는 것 외에도 권한을 위임하면 팀 구성원이 업무에 대한 오너십을 느낄 수 있다. 이런 권한이 부여되면 업무에 대한 자부심과 성취감을 느낄 가능성이 높아진다. 이는 팀 구성원이 업무에 더 많이 투자하고 최선을 다하도록 동기를 부여하므로 사기가 향상 될 수 있다.
또한 리소스를 보다 효율적으로 사용할 수 있다. 어떤 업무를 처리하는데 적합한 구성원에게 할당하여 팀이 전체 역량을 발휘할 수 있도록 할 수 있다.
처음 관리자가 된 이들은 대부분 마이크로 매니지먼트를 하는 경향이 있다. 팀 구성원을 신뢰할 수 없거나 본인이 해야 한다고 생각하기 때문이다. 이렇게 되면 창의성과 혁신에 부정적인 영향을 미치게 된다. 본인의 입맛에 맞지 않더라도 신뢰와 존중을 기반으로 위임을 해야 한다.
결국, 위임이란 관리자의 통제권을 포기하는 것이 아니라 공유하는 것이라는 것을 이해해야 한다. 관리자는 자신의 기대치를 명확히하고 팀 구성원이 성공하는데 필요한 리소스를 제공하고 최대한 지원을 해야 한다. 그리고 팀원을 신뢰하고 그들이 결정을 내릴 수 있도록 자율성을 부여해야 한다.
위임이라는 행위를 통해 관리자는 자신의 업무에 집중할 수 있고, 팀 구성원은 오너십을 가질 수 있으며, 리소스를 보다 효율적으로 사용할 수 있게된다.
위임은 신뢰를 기반으로 통제권을 공유하는 것을 이해할 때 관리자는 보다 효과적으로 팀을 성공으로 이끌 수 있다.
1/30/2023
[주니어 시리즈] 프록시 서버
블로그에 어려운 글로만 채우는 것 같아서 “주니어 시리즈”를 기획했다. 주니어 개발자가 알면 좋을 것 같은 내용으로 최대한 쉽게 작성하려고 한다.
우리가 사용하는 인터넷은 풍부한 정보와 도구를 제공함과 소셜 네트워크 및 음성/영상 기능을 사용하여 전 세계 사람들을 연결해왔다.
이 모든 것은 보안 및 개인 정보 침해에 대한 위험과 함께 제공된다. 본 글에서는 이런 위험을 완화하는데 중요한 역할을 하는 프록시에 대해서 설명하려고 한다.
프록시 서버
클라이언트에서 웹서버로 전송되는 모든 요청은 일종의 프록시 서버를 거치게 된다. 프록시 서버는 클라이언트와 인터넷 사이의 게이트웨이 역할을 하며 웹사이트와 분리한다.
웹 요청의 소스 IP 주소를 프록시 서버의 IP 주소로 변경한 다음 웹서버로 전달하게 된다. 웹서버는 클라이언트를 인식하지 못하고 프록시 서버만 볼 수 있다.
프록시 서버는 단일 대문 역할을 하여 보안 정책을 보다 쉽게 시행할 수 있다.
요청된 웹페이지를 프록시 서버에 저장하여 성능을 향상시키는 캐싱 매커니즘도 제공한다.
요청된 웹페이지가 캐시 메모리에서 사용 가능한 경우 요청을 웹서버로 전달하지 않고 캐시된 웹페이지를 클라이언트에게 전달한다.
이를 통해 사용자가 많이 방문하는 웹사이트는 서버의 부하를 줄여 많은 비용을 절약 할 수 있다.
순방향(포워드) 프록시 서버
순방향 프록시는 일반적으로 클라이언트에서 구현되며 여러 클라이언트 또는 클라이언트 소스 앞에 위치한다.
순방향 프록시 서버는 주로 회사에서 직원의 인터넷 사용을 관리하고 콘텐츠를 제한하는데 사용된다.
또한 회사의 네트워크에 위협이 될 수 있는 모든 요청을 차단하여 회사 네트워크를 보호하는 방화벽으로도 사용된다.
프록시 서버는 사용자의 국가에서 차단될 수 있는 콘텐츠를 우회하여 접근하는데도 사용되기도 한다.
프록시 서버가 사용자의 세부 정보를 숨김으로 사용자는 익명으로 인터넷을 탐색할 수 있다.
역방향(리버스) 프록시 서버
역방향 프록시 서버는 클라이언트쪽이 아닌 서버쪽에 구현된다. 여러 웹서버 앞에 위치하며 들어오는 요청을 웹서버로 전달한다. 따라서 클라이언트가 아닌 웹서버에 익명성을 제공한다.
역방향 프록시 서버는 일반적으로 웹서버를 대신하여 인증, 콘텐츠 캐싱 및 암호화/복호화 같은 작업을 수행하는데 사용된다.
또한 역방향 프록시는 로드 밸런서로 사용되기도 한다. 하지만 들어오는 트래픽을 웹서버마다 효율적으로 분산시키기 위한 용도로는 최적화되어 있지 않다.
일반적으로 역방향 프록시 서버는 웹서버 또는 웹서버 그룹 단위로 로드 밸런싱을 하게 된다.
요약
프록시 서버는 클라이언트와 인터넷 사이의 대문(게이트웨이) 역할을 하므로써 최종 사용자를 웹사이트와 분리한다. 프록시 서버의 위치에 따라 순방향 프록시 서버인지 역방향 프록시 서버인지가 결정된다. 순방향 프록시는 클라이언트에서 구현되며 여러 클라이언트 또는 클라이언트 앞에 위치하여 요청을 웹서버로 전달한다. 역방향 프록시 서버는 여러 웹서버 앞에 위치하여 요청을 웹서버로 전달한다.
위에서 언급한 내용들을 예시로 표현해보자.
레스토랑에서 웨이터가 주문을 받아 주방장에게 전달하면 주방장은 주문을 외치고 주방에 있는 모든 사람에게 작업을 할당한다고 가정해보자.
- 당신은 클라이언트이다.
- 당신의 주문은 웹요청이다.
- 웨이터는 순방향 프록시 서버이다.
- 주방장은 역방향 프록시 서버이다.
- 주방에서 일하는 다른 세프들은 웹서버이다.
이것으로 프록시에 대한 설명을 끝났습니다. 궁금하신 사항은 의견을 달아주세요.
1/13/2023
기술 능력이 엔지니어에게 가장 중요한 항목이 아닌 이유
일반적으로 엔지니어라고 하면 테크 스킬이 가장 중요한 것이라고 생각을 한다. 물론 엔지니어가 되기 위해서는 기술적 지식이 당연히 필요하고 기술 숙련도에 중점을 둘 가능성이 매우 높다. 하지만 효과적으로 의사소통을 하는 능력은 간과되는 경향이 있다.
엔지니어에게 커뮤니케이션 기술이 필요한 이유는 무엇일까? 우리가 진행하는 과제들은 개인이 혼자서 해결할 수 있는 것이 매우 적다. 기술 지식을 가진 사람들로 구성된 사람들 혹은 팀 간의 협업이 필요하다. 어떤 과제를 하기 위해서는 기술 베이스의 사람도 있지만 기획, 비즈니스 등 다양한 배경을 가진 사람들이 모여서 협업을 하기에 의사소통을 잘하면 더 효율적으로 진행할 수 있다.
어떻게 이해관계자의 기여를 받고 중복되거나 낭비되는 작업을 방지할 수 있을까? 아래 사항들을 고려해서 진행해야 한다.
- 모든 사람이 공동의 목표를 보고 있는지 확인
- 결과물의 모습과 이를 달성하기 위한 로드맵 공유
- 개발 전반에 걸쳐 지속적인 테스트를 통해 불확실성을 해소 및 수용
위에 언급된 항목에는 기술 지식에 대한 언급은 없다.
훌륭한 엔지니어는 이론 및 경험에 대한 지식을 지니고 있다. 코드 수준에서만 작업할 수 있는 사람은 다른 사람이 수행한 기존 구현내에서만 작업할 수 있고, 새로운 로직을 만들려면 수학적 관점에서 로직을 수립하는 것을 이해해야 한다. 그렇지 않으면 항상 다른 사람의 작업물 내에서 진행할 수 밖에 없다.
최고의 엔지니어는 비즈니스와 외부에서 무슨 일이 일어나고 있는지 알고 있어야 한다. 남들이 하는 일을 따라가지 못한다면 결국 뒤처지기 때문이다.
뛰어난 엔지니어는 전체 스택을 이해한다. 아는 범위 내에서 생각하고 결과물을 낼 수밖에 없기 때문에 전체를 이해하려고 노력한다.
신급 엔지니어는 사람들과 대화하는 방법을 알고 있다. 사람들은 자신이 알고 있는 것을 상대방도 알고 있다고 오해하여 불필요한 오버헤드를 만들기도 한다. 동료 엔지니어와 대화하는 경우에는 히스토리를 포함해 단순화하여 커뮤니케이션을 해야 한다. 좋은 일과 위대한 일의 차이는 얼마나 그것이 잘 설명되어 있느냐이다.
커뮤니케이션 기술을 향상시키고 엔지니어링 능력을 향상시키기 위한 단계를 아래와 같다.
1. 다른 사람의 말을 듣는 법을 배우자
다른 사람들은 나와 다르게 의사소통한다는 것을 이해해야 한다. 기술적인 부분을 사업 쪽에 설명할 때, 같은 내용을 전달하는 것도 다양한 방법이 있다는 것을 이해해야 한다. 그리고 그들과 상호 작용할 때는 “그들의 언어”로 소통해야 한다. Mirroring이라는 기술을 이용하게 되면 효과적인 언어 및 비언어적 의사소통 방법을 알 수 있고, 실험해 볼 수 있다. 나도 사업 쪽과 상호 작용을 하면서 이렇게 하려고 많은 노력을 기울이고 있다.
2. 더 많은 대화 시작
서로의 생각을 맞추려면 더 많이 이야기를 해야 한다. 그리고 대화가 끝나면 아쉬웠던 부분을 기억하고 더 나아질 수 있도록 해야 한다.
3. 공감
가장 어려운 것은 공감 능력을 키우는 것이다. 누군가가 당신의 하루를 망치는 무언가를 전달한다면 그들이 어떤 제약을 받고 있는지 생각해야 한다. 물론 이 관점은 사람들이 좋은 의도를 가지고 있다는 가정이다. “왜 이렇게까지 해야 했지?”라고 생각하고 직설적으로 물어 볼 필요도 있다. 누군가를 이해하기 위해 질문하는 것은 경험에서 배울 수 있는 최고의 엔지니어링 기술과 자질 중 하나이다. 이런 부분들을 무서워하거나 두려워하면 안된다.
끝으로, 우리는 종종 기술 숙련도를 엔지니어가 개발해야 할 핵심 기술로 본다. 물론 코딩 및 설계를 할 수 있다는 것은 매우 중요하다. 하지만 코딩하는 내용을 간결하게 전달할 수 없다면 성과를 잘 설명할 수 없을 것이다. 의사소통은 엔지니어가 배워야 할 필수 기술이다. 그 이유는 이해관계자들이 다른 전문가보다 더 잘 소통된다고 느끼기 때문이다.