안녕하세요
저는 금융 SI 폐쇄망 환경에서 일하며, 문제를 해결하고 업무 효율을 높이기 위해 다양한 자동화 도구를 만들고 공유했습니다.
SI 프로젝트에서 문서 작성, 개발, 프로젝트 관리 업무 수행 중 다양한 불편함과 문제를 만났습니다.
외부 라이브러리나 각종 상용 프로그램을 활용하면 쉽게 해결할 수 있는 문제들이었지만,
금융 SI 폐쇄망이라는 특성상 주어진 도구만을 활용해야 했고, 다양한 기술적-환경적 어려움이 있었습니다.
처음엔 그것을 핑계 삼아 불평불만만 가득했습니다.
하지만 여러 가지 일들을 겪으며 생각을 바꿨고,
나를 위해, 팀을 위해 지금 당장 할 수 있는 것을 찾아 시도했습니다.
드라마틱한 성과, 깊은 기술적 챌린지, 우아한 해결 방법은 없었습니다.
전부 투박했고, 아주 기본적인 알고리즘의 조합이었지만 분명 문제를 해결할 수 있었고,
직장인으로서, 그리고 Developer로서 많은 것들을 배울 수 있었고, 행복감을 주는 경험이었습니다.
1. 주어진 상황과 환경에 불평불만을 갖기 보단, 지금 할 수 있는 것에 집중할 수 있게 되었습니다.
2. 주변의 문제를 SW 개발로 해결하는 경험을 했습니다.
3. 사회 초년생으로서 조직의 목적, 관리자의 고민, 구성원들의 배경과 프로젝트 환경 등에 대해 고민할 수 있었습니다.
4. 내가 좋아하는 것이 무엇인지, 지향하는 문화는 어떤 것인지 알게 되었습니다.
도전하게 된 계기, 시도하는 과정에서 만난 고민, 어려움, 활용했던 도구에 대해 적어보았습니다.
폐쇄망 환경이기에 제가 만든 프로그램과 문서들은 언젠가 모두 삭제됩니다.
행복했던 경험을 오래 간직하기 위해 글을 작성해 보았습니다.
1. 주요 자동화 도구
정리해 보니 지난 몇 개월간 크고 작은 도구들을 꽤 많이 도입했었습니다.
- 6개의 java 프로그램
- 12개의 VBA 매크로
- 3개의 정규 표현식
이 중에서 “가장 큰 도움을 준 도구”들을 정리해 봤습니다
폐쇄망 특성상 자세한 업무 설명이 어려움에 양해 부탁드립니다.
1️⃣ Pro*C Call Graph 생성기 (java 프로그램)
매우 복잡한 호출 관계를 갖는 Pro*C 코드를 분석해, Module 간, 함수 간 Call Graph를 호충 순서를 반영해 엑셀에 트리 형태로 그려내고,
업무에 직접적으로 필요한 호출 Query와 분석 정보를 한눈에 알 수 있게 제공
- Before: 저는 주어진 업무량 소화를 위해 매주 최소 12시간 이상의 추가 근무를 했습니다.
- After: 개발 이후 1주일 분량 2 ~ 3일 만에 추가 근무 없이 해결.
- 프로젝트 내 누구나 사용할 수 있도록 공유, 가장 반응이 좋았던 프로그램
1. 업무에 필요한 정보를 빠르게 확인할 수 있는데 초점
2. 사용자 니즈에 맞게 다양한 탐색 옵션 제공.
- 모듈 호출 그래프, 함수 호출 그래프 선택 옵션
- 선택 모듈과 관련된 도메인 모듈만 탐색 옵션
3. 사용자가 직관적으로 이해할 수 있는 문서 생성을 위해 노력
- 트리 형태로 구성
- 같은 부모 노드를 공유하는 자식 노드 이어주기
- DML 외엔 제거
- DML은 하이라이팅, 종류, 타겟 테이블 첫 줄에 제공
가장 많은 도움을 받으신 팀원분이 소고기를 보내 주시기도 했습니다. 많은 분들이 감사 인사를 주시거나 커피를 사주서 가장 뿌듯함을 안겨준 프로그램이었습니다.
2️⃣ 1,600 건 이상의 쿼리 검토 업무 → 검토 대상 75% 이상 감소 (java 프로그램)
- Before: 10명 이상 작업, 3 ~ 5일 검토 계획
- After: 1인 확인, 2일 소요
1,600개의 쿼리가 특정 규칙을 만족하는지 확인해야 하는 업무였습니다.
중요한 검사이기 때문에, 전부 자동화하기보다는 눈으로 직접 확인해야 하는 대상을 줄이는 데에 집중했고, 조사 대상이 약 400개 이하로 줄어들었습니다. (75% 감소)
그래프 탐색으로 프로젝트 내 모든 Query 파일 탐색 (xml 파일로 작성됨)
-> 파일별 xml에 태그로 표현된 SQL Query 파싱
-> Query 유형에 따라 다른 유형의 검증 수행
-> 검증 결과와 Query, 파일 정보 등을 정리해 엑셀 파일로 제공
3️⃣ DB Migration을 위한 문서 추가 작업 -> 작업 시간 60%, 3일 단축 (VBA)
- Before: 2명 작업, 5일 작업 계획
- After: 2인 작업, 2일 요소 (3일 단축)
Database Migration을 위해 작성해야 하는 문서가 있었고, 해당 문서들을 모두 확인해 상황별로 다른 추가 내용을 기입해야 했다. 문서량이 많은 만큼 2명이서 5 영업일 작업을 계획했었다.
VBA로 구현. 간단한 비교를 통해 어떤 추가 내용을 기입할지 결정. 중요한 문서이기 때문에 추가된 내용이 있는 파일과, 변경된 영역을 눈으로 확인할 수 있도록 안내
4️⃣ Legacy DTO Migration 자동화 -> 하루 평균 10번의 문서 작성 감소
- Before: 하루 평균 10개 이상의 DTO를 GUI 툴을 통해 정의해야 했다.
DTO가 갖는 모든 필드 이름, 타입, 크기, 설명, 기본값 등을 직접 타이핑해 주어야 했음. - After: 폴더 경로만 입력하면 수초 안에 경로 내 DTO 완성
GUI툴에 값을 하나하나 기입해 주면, xml과 유사한 문서 파일이 생성
이 파일이 java DTO를 생성하고, 꼭 이것만 사용해야 한다.
5️⃣ 그 외 도구들
그 외에도 다양한 도움을 주는 프로그램, 매크로 정규 표현식을 만들었습니다.
총 6개의 프로그램, 12개의 VBA 매크로 등을 만들었습니다.
정규 표현식은 기본적인 것이고, 투박하지만, 수천 수만 줄의 Lagacy C Code를 직접 읽으며 분석하는 팀원들의 분석 시간을 줄여주었습니다.
지금까지 구현한 목록입니다. 너무 길어 토글에 접어 두었습니다.
6개의 프로그램, 12개의 VBA 매크로, 3개의 정규식
1. [프로그램] Pro*C 모듈, 함수 Call Graph 생성기
2. [프로그램] Legacy DTO Migration 자동화
3. [프로그램] 1,600건 이상의 쿼리가 특정 규칙을 만족하는지 검증
4. [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증
5. [프로그램] 형상 관리 툴에 push 하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다)
6. [프로그램] DB 컬럼 의미 주석 추가 프로그램 (매일 최소 50개 이상의 컬럼의 한글 의미를 찾아야 했다.)
7. [VBA] DB Migration을 위한 문서 수정 함수
8. [VBA] DB 설계서 컬럼 의미 주석 추가 매크로 (엑셀 파일은 암호화가 되어 있어, 6번 프로그램이 적용되지 않았다.)
9. [VBA] 파일 이름을 통해 UI 정의 문서 내 10개 이상의 셀의 값을 생성해 채워주는 함수
10. [VBA] 폴더 내의 모든 UI 정의 문서에 매크로를 적용하는 함수
11. [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀의 값을 생성해 채우는 함수
12. [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수
13. [VBA] 폴더 내 문서들에 적힌 버전을 원하는 버전으로 바꾸는 함수
14. [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수
15. [VBA] 여러 cell들의 값 앞에 prefix를 붙이고, camel case로 변경하는 함수 (하루에 수십번씩 타이핑해야 했다..)
16. [VBA] 여러 cell들의 기존 prefix를 인식해 새로운 prefix로 교체해주는 함수
17. [VBA] 셀의 값을 카멜 케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스)
18. [VBA] 지정한 색으로 셀을 칠하는 함수들 (셀을 색칠하는 엑셀 단축키는 없음)
19. [정규식] 외부 인터페이스 호출시 input 찾는 정규식 (특정 prefix를 가진 struct가 특정 prefix를 가진 맴버를 호출하는 경우를 찾는 정규식)
20. [정규식] 외부 모듈 호출 정규식 (특정 규칙을 가진 이름의 함수의 호출부를 찾는 정규식)
21. [정규식] 소스코드 전체에서 영문 필드에 달린 한글 주석을 찾는 정규식 (기존엔 전체 프로젝트에 필드를 검색해 주석을 일일이 찾아냈다)
이 도구들이 해결했던 문제와 도와줬던 업무들은 원래 전부 수작업으로 작업해야 했습니다.
사실 간단한 웹 서핑을 통해 누군가의 구현체를 찾을 수도 있고, AI를 통해 빠르게 만들 수도 있는데 왜 전부 수작업으로 수행해야 했을까요?
그 이유는 프로젝트의 높은 보안 요구사항 때문이었습니다.
금융 SI 폐쇄망 환경과 주어진 도구는 다음과 같습니다.
2. 활용 가능한 도구 이해하기
2.1 금융 SI 폐쇄망 환경은 어떨까?
지난 1년간 금융 SI 프로젝트를 참여하며, 환경에 대해 끊임없이 고민했습니다.
금융 SI의 대부분의 제한들은 아래 2가지 요소에서 온다고 추측합니다.
- 금융 도메인 특성상 높은 수준의 보안이 요구된다.
- 금융 도메인 지식이 많은 개발자가 중요하다.
따라서, 평균 연령대와 연차가 높은 편이고, 그런 개발자들에게 익숙한 도구들이 주어진다.
흔히 말하는 "보수적이다"라는 이미지는 이 두 가지 요소에서 오지 않았을까 추측해 봅니다.
그리고 위 2가지 사항에서 아래와 같은 여러 구체적인 제한 사항이 나오게 됩니다.
- 각종 문서 암호화
- 모든 문서 파일은 암호화된다 → 파싱의 가장 큰 장애물
- 추가 언어, 라이브러리 없음
- 주어진 언어 외에 다른 언어나 각종 라이브러리를 추가적으로 반입하기 어려움
- 결국 자동화 도구들은 "제작 시간" 대비 "아끼는 시간"이 커야 하기 때문에, "제작 시간"을 줄여주는 도구들 또한 중요하다.
- 인터넷과 기기 제한
- 보안으로 인해 개인 노트북 반입 어려워, 스마트폰으로 웹 서치
- 생성형 AI 없음. (도입을 시도하는 팀이 있지만 매우 제한적)
- 소프트웨어 제한
- 편리한 IDE (Intellij)나 Plugin 같은 보조 도구 없음
→ 함수 호출부나 정의부 찾기나 리팩토링이 생각보다 어려움 - VSC의 각종 Extension 없음
- 동시편집 툴이나 문서 형상 관리 없음 (컨플루언스, 노션)
- 편리한 IDE (Intellij)나 Plugin 같은 보조 도구 없음
막 신입이었던 저는 바보 같은 생각을 했습니다.
- 인텔리제이를 못 쓴다니 ㅠㅠ 이클립스는 정말 불편해!
- 파이썬도 못 쓴다니 ㅠㅠ
- 엑셀 암호화를 풀 수 없다니 전부 손으로 쳐야 한다고? ㅠㅠ (이건 문제가 맞다)
제가 구상하는 자동화 툴을 쉽게 만들 수 있는 도구의 반입이나,
복호화 툴의 지원을 요청했으나 거절당했고,
주어진 문제를 해결하기 위해 고민하기보단, 상황과 환경에 대한 불평불만이 많았습니다.
다른 개발자, 엔지니어들이 보면 코웃음을 쳤을 것입니다.
크리스 소이어는 게임 최적화를 위해 C 대신 어셈블리로 롤러코스터 타이쿤을 만들었다고 합니다.
게임 슈퍼마리오 브라더스는 겨우 40KB로 작성되었습니다. 당시 게임기인 패미컴의 표준 최대용량이 40KB이기 때문입니다.
이 분들이 저를 보면 무슨 생각을 했을까요?
저를 진짜 개발자라고 인정해 주실 수 있었을까요?
2.2 문제를 해결하기 위해 만드는 사람
문제 해결을 포기하고, 불평 불만으로 가득해 열심히 야근하던 시절에 유튜브에서 어떤 쇼츠를 보았습니다.
마블 시리즈의 아이언맨 3에서 토니 스타크와 꼬마 할리 키너가 대화하는 장면이었습니다.
할리 키너가 토니의 불안 증세를 잠재우는 장면이었습니다.
상황은 이렇습니다.
테러리스트의 습격을 받은 아이언맨은 탈출 도중, 외딴 지역에 불시착했습니다.
슈트는 방전되었고, 저택의 최첨단 설비도 없습니다.
하지만 악당 킬리언의 추격은 끝나지 않았고, 테러리스트 만다린의 아지트도 공격해야 했습니다.
그곳에서 우연히 마주친 할리 키너라는 꼬마의 도움을 받아 슈트의 충전을 시도했지만..
생각대로 잘 되지 않았고, 토니는 평소 앓던 불안증세가 나타나 호흡에 문제가 생겼습니다.
이때 꼬마 할리 키너의 한마디가 아이언맨을 진정시킵니다.
아저씨는 mechanic이잖아요. 맞죠?
그렇다면 무언가 만들어 보는 건 어때요?”
그 말을 듣고 불안 증세가 사라진 토니는 곧장 시골 잡화점으로 달려가 여러 물건들을 구입했고,
그 물건들로 전기 충격 장갑, 사냥돌, 크리스마스 장식 수류탄, 강화 못 총 등을 제작했습니다.
그 무기들은 투박했지만 확실히 적들을 제압할 수 있었고,
테러리스트 만다린의 침소까지 침입할 수 있었습니다.
너무 멋있었습니다.
토니는 최첨단 슈트와 설비 없이도 메카닉이었고,
문제를 해결하기 위해 무언가 만들어 내는 사람이었습니다.
그에 비해 저는 아주 아주 아주 작은 문제를 겪고 있음에도
환경만 탓하며 투덜대기만 했었습니다.
사실 그렇게까지 열악한 상황도 아니었고, 그렇게 대단한 것을 만들어야 하는 상황도 아니었습니다.
갑자기 부끄러움이 밀려 들어왔고, 스스로를 돌아보게 되었습니다.
제가 존경하는 선배 개발자, 엔지니어들이라면 어떻게 했을지 생각했습니다.
환경에 대해 불평하는 대신 지금 할 수 있는 것이 무엇인지 더 찾아보자고 마음먹었습니다.
2.3 가진 도구는 생각보다 많았다.
침착하게 둘러보니, 편리한 최신 툴들이 없을 뿐이지,
문제를 해결할 수 있는 강력한 도구들을 많이 가지고 있었습니다.
1. 엑셀 함수와 VBA는 생각보다 매우 강력했습니다.
평소 엑셀을 다뤄본 적이 없었던 저는 엑셀로 무엇을 할 수 있는지 인지하지 못했었습니다.
2. 정규식만 잘 작성해도 분석 시간을 많이 줄일 수 있었습니다.
3. 반입된 프로그램들이 사용하는 라이브러리들을 잘 찾아보니, java 라이브러리 Apache POI가 있었습니다.
암호화로 인해 엑셀 파싱은 불가능했지만, POI를 활용해 "작성"은 가능했습니다
엑셀 함수 부터 생각보다 매우 강력했습니다.
대표적으로 VLOOKUP은 Vertical + Lookup이라는 의미로, 특정 값을 지정한 범위 내에 있는지 찾아,
발견한 Row의 다른 컬럼 값을 사용할 수 있게 해 줍니다.
예를 들어 위 그림에서 “A003이라는 값을 표 안에서 찾아, 해당 Row 상품 값을 가져오기”와 같은 질의가 가능합니다.
그냥 SQL Query 같죠? 엑셀 파일도 결국 일종의 Table, Table View와 같다고 생각합니다.
VLOOKUP만 잘 활용해도 정말 정말 많은 문제를 해결할 수 있었습니다.
사실 만들었던 프로그램 중 하나는 VLOOKUP과 기존에 제공된 데이터들만 잘 활용했어도, 직접 만들 필요가 없었다는 것을 나중에야 알기도 했습니다.
그 외에도 기본 함수들을 조합해 많은 문제들을 해결할 수 있었습니다.
이들은 GPT가 아주 잘 만들어줍니다. 적극적으로 활용을 권합니다.
2.3.1 Visual Basic for Applications (VBA)
살면서 엑셀을 거의 써본 적이 없어 몰랐지만,
Microsoft Office 프로그램들을 조작할 수 있는 VB라는 언어가 있었습니다.
VBA를 통해 작성한 매크로를 엑셀 파일에서 실행시켜 보니, 엑셀 파일의 내용을 복호화된 상태로 다룰 수 있었습니다.
아마도 VBA를 통한 문서 조작은 Microsoft Office 제품끼리의 상호작용이라고 인정되기 때문인 것 같습니다.
VBA는 우리가 상상하는 기본적인 언어의 기능을 대부분 제공해 줍니다.
- 정규식을 통해 특정 파일들만 순회할 수 있음
- input을 입력받을 수 있음
- 적용할 값이나 경로를 유저가 직접 입력하게 할 수 있음
- 무려 셀을 눌러 input을 지정할 수도 있음
- 간단한 셀과 시트 조작과 스타일 적용은 기본이고, 파일 정보 등의 메타데이터도 활용 가능
- http request 보낼 수 있음. 다른 프로그램 실행 가능
정말 별의별 것이 다 가능하고, 덕분에 정말 많은 도움을 받았습니다.
총 12개의 크고 작은 매크로를 만들었습니다.
- [VBA] DB Migration을 위한 문서 수정 함수
- [VBA] DB 설계서 컬럼 의미 주석 추가 매크로 (엑셀 파일은 암호화가 되어 있어, 6번 프로그램이 적용되지 않았다.)
- [VBA] 파일 이름을 통해 UI 정의 문서 내 10개 이상의 셀의 값을 생성해 채워주는 함수
- [VBA] 폴더 내의 모든 UI 정의 문서에 매크로를 적용하는 함수
- [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀의 값을 생성해 채우는 함수
- [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수
- [VBA] 폴더 내 문서 이름에 적힌 문서의 버전을 모두 바꾸는 함수
- [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수
- [VBA] 여러 cell들의 값 앞에 prefix를 붙이고, camel case로 변경하는 함수 (하루에 수십번씩 타이핑해야 했다..)
- [VBA] 여러 cell들의 기존 prefix를 인식해 새로운 prefix로 교체해주는 함수
- [VBA] 셀의 값을 카멜 케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스)
- [VBA] 지정한 색으로 셀을 칠하는 함수들 (셀을 색칠하는 엑셀 단축키는 없음)
또한 매크로는 단축키 등록이 가능하다는 장점도 있기 때문에,
너무나도 유용하게 잘 사용하고 있습니다. 정말 날개를 달아준 고마운 존재..
2.3.2 정규 표현식의 힘
입사 전엔 사용한 경험이 거의 없었는데,
Legacy C Code를 분석할 때 정규 표현식의 힘은 정말 엄청났습니다!
스크롤을 내리며 특정 패턴을 가진 함수, 변수 할당 등을 찾는 팀원들의 모습을 보았습니다.
충분히 정규 표현식을 통한 검색으로 효율을 높일 수 있어 보였고, 작성해 공유해 드렸습니다.
- 특정 prefix를 가진 struct가 특정 prefix를 가진 멤버를 호출하는 경우를 찾는 정규식
- 특정 규칙을 가진 이름의 함수의 호출부를 빠르게 찾는 정규식
(정확히 어떤 이름으로 정의되어 있을지 미리 알 수 없음) - 필드에 달린 한글 주석을 찾는 정규식
(기존엔 전체 프로젝트에 필드를 검색해 주석을 일일이 찾아냈다)
덕분에 분석할 때마다 시간을 아낄 수 있었습니다.
이 또한 GPT님의 은혜로 쉽게 작성할 수 있었습니다.
2.3.3 기본 jdk와 Apache POI
정말 운이 좋게도 Apache POI가 깔려 있었습니다!
Apache POI 라이브러리는 java로 엑셀 문서를 조작하거나 작성하는 것을 도와줍니다.
사실 엑셀 암호화라는 제약만 없으면 jdk와 Apache POI만 있어도 대부분의 문제는 해결 가능했습니다.
엑셀 파일을 만들고, 셀들을 채우고, 시트를 만들고, 스타일을 입히는 대부분의 행위가 가능합니다!
저희는 암호화되어 있기 때문에, 파싱과 조작은 어려웠고
java 프로그램으로 문제를 해결하는 경우 결과를 이쁘게 정리해 드리는 데에 도움을 받았습니다.
팀원들이 가장 익숙하고, 편하게 볼 수 있는 문서 형태가 엑셀이었기 때문입니다.
java로 작성한 프로그램은 6개였고, 이 중 3개의 프로그램에서 POI를 활용했습니다.
- [프로그램] Pro*C 함수, 모듈 Call Graph 생성기
- [프로그램] 1,600건 이상의 쿼리가 특정 규칙을 만족하는지 검증
- [프로그램] Legacy DTO Migration 자동화
- [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증
- [프로그램] 형상 관리 툴에 push 하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다)
- [프로그램] DB 컬럼 한글 주석 달아주기 (매주 최소 100여 개의 컬럼 한글명을 찾아 기재해야했다.)
3. 만들고 나누었던 이유
3.1 문제를 해결하기 위해 만드는 사람
비전공자였고, C언어의 존재만을 겨우 알던 상태였습니다.
어렸을 때 RPG 만들기와 스타크래프트 유즈맵을 만들었었고, 어린 시절 꿈이었던 게임 개발에 도전하기 위해 처음 C언어를 공부했습니다. 게임을 만들면서 만드는 것의 즐거움을 배웠고, 취미로 알고리즘 문제를 풀며 문제 해결의 줄거움을 배웠습니다. 앱을 만들고, 사이트를 만들며 자연스럽게 개발자가 되고 싶다는 꿈을 키웠고, 현실의 문제를 해결하기 위해 다양한 SW를 만들었습니다.
이 모든 과정은 즐거웠습니다.
하지만, 처음 만나는 환경에서 앞서 잠시 나약한 생각을 했었습니다.
주어진 문제를 해결하기 위해 고민하기보단, 상황과 환경에 대한 불평불만이 많았습니다.
내가 정말 좋아했던 것이 무엇이고, 내가 되고 싶은건 어떤 모습일까 끊임없이 고민했습니다.
고민 끝에, 저는 단순히 "코드를 짜는 것"을 좋아하는 사람이 아니라는 것을 알게 되었습니다.
가장 행복했던 순간들은 "제가 만든 도구가 사람들에게 실질적으로 도움이나 재미를 주었을 때"였습니다.
내가 만든 게임을 누군가 재밌다고 해줬을 때,
내가 만든 사이트, 자동화 도구, IDE 플러그인이 누군가에게 도움이 되었을 때,인텔리제이를 사용하다가 머리가 복잡해진 경험이 있다면?
어느때 보다 도파민이 넘쳐났고, 저는 그 안에서 행복을 느끼는 사람임을 알게 되었습니다.
제가 정말로 좋은 Software Developer 라면, 상황과 환경을 탓할게 아니라
현재 상황에서 할 수 있는 것을 찾고,
어떤 환경에서든 문제를 해결하기 위해 만드는 사람이 될 수 있어야 한다고 생각했습니다.
환경을 탓하는 습관을 버리고, 지금 가진 도구들 내에서 해결할 수 있는 방법을 찾는 습관 덕분에 많은 도구를 만들어볼 수 있었고, 어떤 환경에서도 문제 해결의 방법을 찾아낼 수 있겠다는 자신감이 생겼습니다.
돈을 더 받기 위해서도, 연말에 좋은 평가를 받기 위해서도 아니었습니다.
평일 저녁이나 주말에 추가 근무를 보고하지 않고 만들거나, 점심시간을 활용해 만들었지만, 시간이 조금도 아깝지 않았습니다. 돈 보다 더 큰 만족감을 얻을 수 있었습니다.
3.2 "공유"로 이루고 싶었던 것
작년 5월 부터 벌써 많은 도구를 만들어 사용했고, 다른 사람도 사용할 수 있도록 공유했습니다.
제가 이렇게 만든 도구들을 공유한 이유는 전부 자기 만족 때문입니다.
- 만드는 것을 좋아한다.
- 다른 사람에게 도움이 되는 것을 좋아한다. (네이버 지식인이 취미였다!)
- 더 많은 사람이 쓸수록 내가 만든 도구가 더 효율적인 도구가 된다.
자동화 툴의 효율은 "제작 시간" 대비, "아끼게 되는 시간"으로 결정되기 때문에, 아끼는 시간이 높아질 수록, 유용한 자동화 툴이 된다. - 서로를 위해 기꺼이 공유하는 문화가 형성 됐으면 좋겠다.
개발자로서, 기술 발표나 오픈 소스 기여 활동을 하며, 공유하는 문화를 좋아하긴 하지만,
사실은 직장에서 "내가 공유 받는것"을 기대하며 공유 활동을 했습니다.
현 직장에서 일하며 저는 겪어 보지 못한 매우 다양한 종류의 업무를 수행했습니다.
이제까지 개발 업무는 50% 혹은 그것 보다 낮았고,
개발을 위한 분석, 설계서 작성 등의 각종 문서 작업과 협력사 분들과 커뮤니케이션을 하는 등의 업무를 해왔습니다.
개발은 취직 하기 전에도 꾸준히 해왔기 때문에, 그리 낯설지 않았으나
다른 업무는 달랐습니다.
어떻게하면 더 잘 할 수 있는지, 어떻게 하면 더 효율적으로 할 수 있는지, 아무것도 몰랐습니다.
정보나 노하우의 격차는 실제 업무 수행에 있어서도 큰 차이를 만들었지만, 거의 공유되지 않았습니다.
폐쇄망의 파일 보관소. 그 문서와 도구의 바다 속에서.. 어딘가에 숨겨져 있는 "특정 문서"를 가지고 있는 사람은 업무 효율이 2배 이상 높아지는 경우도 있었습니다. 더 편한 도구나, 그 세팅법을 일부 인원만 알고 사용하는 경우도 있었습니다.
이런 정보들을 모두가 알면 좋을텐데, 똑똑하고 일 잘하는 몇 명이 가끔 찾아내거나, 다른 사람이 사용하는 것을 우연히 보고 찾게 되거나, 친한 사람이 비밀처럼 알려주는 식으로만 이 꿀팁이 공유 됐습니다.
이들은 "노하우"라는 이름으로 비밀리에 공유되고 있었습니다.
어떤 업무가 다 끝났을 때, "알고보니 그 업무의 효율을 높이는 신통방통한 문서나 도구가 있었다"와 같은 상황을 많이 겪었습니다.
SI 프로젝트는 어느 정도 패턴화 되어 있고, 해야 하는 일도 어느 정도 비슷합니다.
대부분의 프로젝트는 같은 문제를 몇번이고 몇번이고 겪고 있습니다.
그런데 왜 더 좋은 길은 아무도 알려주지 않고, 스스로 알아내야만 할까요?
시행착오를 겪으며 사람이 성장할 수 있지만,
그러기엔 SI프로젝트는 너무 일과 문제가 많고, 항상 인력이 부족하고, 다들 지쳐있습니다.
3.3 "노하우"라는 단어가 주는 아픔
각자 시행착오를 반복해 겪을 것이 아니라, 서로의 실패와 성공을 공유하고, 머리를 맞댄다면
똑같은 시도와 똑같은 실패를 최소화할 수 있지 않을까요?
또 누군가 그 방법에서 좋은 아이디어를 얻어 더 멋진 방법을 발견할 수도 있지 않을까요?
모두의 효율이 높아질 수 있는 방법이 있는데 왜 공유되지 않을까요?
그 이유를 자주 고민하고, 곧 은퇴할 연차가 되어가는 부장님 부터 선임분들까지 여쭈어 봤습니다.
부장님께 여러 옛날 이야기들을 들을 수 있었고,
결론적으로는 “정보나 툴 공유자는 칭찬과 장려 대신, 심리적 압박과 책임을 요구받았다”가 원인이었다고 합니다.
무언가 공유하는 행위는 누군가의 눈에는 "굳이 나서는 일", "손으로 하는게 빠른데 굳이 하는 일"로 보일 수도 있고, 실제로 그런 말을 들었다고 합니다. 또한 그 사람이 공유한 도구에 조금의 문제라도 있으면, 평가 절하되거나, 비난을 받거나, 수정 요청에 시달렸다고 합니다.
제가 만든 레거시 분석 툴과 비슷한 툴을 20년 프로젝트에서 개발하신 프리랜서 개발자 분이 계셨는데,
매일 밤세워 자발적으로 프로그램을 만들었지만 끝없는 수정 요청에 오히려 자신이 맡은 업무에 차질이 있었고, 많은 스트레스를 받았다고 합니다.
제가 생각하는 생각의 변화 흐름은 이렇습니다.
- 공유자는 기꺼이 자신의 시간과 지식을 내놓았지만, 칭찬과 격려 대신
"심리적 압박과 책임"을 받았다. - "작업량"과 "연차", "프로젝트 참여 횟수"로 급여가 평가되는 SI 환경 특성상 이런 행동을 한다고 해서 딱히 더 나은 평가를 받진 않는다.
- 공유자들은 자연스럽게 주도적 기여와 공유를 꺼리게 된다.
- 다른 구성원들 또한 공유에 대해 긍정적으로 생각하기 어렵게 된다. (나 또한 받아본 적 없기에..)
- 공유하지 않는 것이 당연한 세상이 온다..
- 다른 이에게 도움을 받은 경험이 없는 사람들이 많아지고, 이들은 자연스럽게 공유의 동기를 못 느낀다.
- 자동화 함수나 툴 또한 누군가 만들어 주는 일이 적어지고, 경험도 듣기 어려워진다.
그러니까 그 툴들이 실제로 얼마나 효용이 있는지, 제작엔 얼마나 걸리는지 추측하기 어렵게 되고, 시도조차 하지 않게 된다.
자연스럽게 무서운 생각이 자리 잡지 않았을까 싶습니다.
- "자발적으로 무언가 만들어 공유한다고 해서 딱히 큰 이득이 있진 않네.. 오히려 힘들어"
- “이건 나만의 노하우인데..”
- "나한테도 누군가 알려주지 않았잖아"
- "다른 사람들이 하지 않는 데는 이유가 있겠지"
3.4 공유하는 조직에 기여하기
이러한 문화가 개선되려면, 선의의 공유자들이 감사와 칭찬, 격려를 받는 환경이 되어야 한다고 생각했습니다.
하지만, 이미 오랜 시간에 걸쳐 문화가 자리 잡혔고, 저는 영향력 있는 사람도 아니었습니다.
그렇다고 영향력 있는 사람이 되기까지 아무것도 하지 않으며 기다리는 것은 싫었습니다.
당장 해볼 수 있는 것을 생각해 보았고, 내 주변이라도 조금씩 바꿔보고 싶었습니다.
이 많은 사람 중 몇 명이라도 감염시킬 수 있다면 그 몇 명이 살아가며 다른 몇명을 감염 시키고
또 그렇게 퍼져나가길 기대했습니다.
제가 생각한 선순환은 아래와 같습니다.
- 내가 먼저 유용한 정보와 유용한 툴을 공유한다.
- 누군가 도움이 되었다고 느낀다면, 나와 비슷한 동기로 툴을 만들거나 정보를 공유하는 사람이 생길 것이다.
- 나부터 그런 사람을 발견하면 적극적으로 감사 인사를 드린다.
- 감염된 사람들은 또 다른 사람을 감염시키며.. -> 모두가 스스로 자신의 노하우를 공유하는 세상이 온다!
이러한 흐름을 상상하며 저만의 작은 퀘스트인 “공유하는 조직 만들기”를 시작됐습니다.
처음엔 작은 단위에서 시작했습니다. 옆자리 동료로 시작해서, 매일 커피를 사러 나가는 동료, 10명 내외의 작은 단위에 공유했습니다. 좋은 반응을 얻고, 용기 내어 프로젝트 개발자 전체 공유도 시도했습니다.
저번 프로젝트에선 자동화 툴 하나와 Spring Batch 가이드문서 하나를 공유했었습니다.
아쉽게도 처음 용기 내어 공유했던 당시엔 반응이 거의 없어 주춤했으나,
몇 달 뒤 여러 사람들이 도움을 받았다는 후일담을 듣게 되었고, 다시 용기가 났습니다.
그 경험으로 이번 프로젝트에서는 더 적극적으로 도구를 만들고, 사람들과 나누고 있습니다.
4. 신뢰와 설득에 대한 고민
신입 개발자로서, 이러한 자동화 툴들을 만들고 공유하는 과정에서, 신뢰와 설득에 대해서도 많이 고민할 수 있었습니다.
호기롭게 전체 개발자 톡방에 직접 작성한 가이드 문서와 자동화 툴을 공유했으나, 반응은 없었습니다.
제가 만든 도구나, 공유한 정보들은 제대로 신뢰를 얻고 사용되기까지 제법 오랜 시간이 걸렸습니다.
제 옆에서 상상할 수 있는 모든 엣지 케이스를 대입하며 테스트 해보시는 분도 계셨습니다.
신뢰 받지 못한 원인은 무엇일까요?
원인은 저에게 있었습니다.
4.1 논리야 놀자!
그때의 저는 논리가 설득의 가장 큰 요소라고 생각했습니다.
처음으로 업무 시간에 자동화 툴 구현을 제안했을 때입니다.
문서 수백 개를 2명이서 5일 동안 수정해야 하는 상황이었습니다.
저의 주장은 아래와 같았습니다.
- 수정 규칙이 명확하기 때문에 코드로 해결할 수 있다.
- 개수가 너무 많아서 직접 하는 게 너무 힘들다.
- 완전 자동화가 걱정되면,
실제로 VBA가 수정한 문서만 정리해서 수정된 부분만 눈으로만 확인할 수 있게 조치할 수 있다. - 구체적으로 로직을 설명했고, 하루 안에 구현할 수 있음을 어필했다.
저의 머리속에선, 제가 제시한 방법과 설명한 로직이 설득력 있다고 생각했습니다.
하지만 많은 우려들을 만나게 되었습니다.
- 제안한 프로그램이 실제로 구현 가능한 것인가?
- 의도대로 실수없이 동작할 것인가?
- 만드는데 오래 걸릴 것 같은데, 혹시 손으로 하는게 더 효율적이진 않을까?
저는 쉽게 받아들여질 것이라고 생각했습니다. 하지만 왜 쉽게 설득하지 못했을까요?
이 우려들은 전부 어디서 온 것일까요?
4.2 SI 프로젝트와 신뢰에 대한 생각
많은 고민 끝에, 모든 우려들의 원인을 아래와 같이 추측했습니다.
"금융 SI 환경은 신입 구성원을 신뢰하기 어려운 환경이다."
이렇게 생각한 이유는 아래와 같습니다.
SI 프로젝트 팀들은 아래와 같은 상황에 놓여 있습니다.
- 수개월 혹은 연 단위로 팀원이 바뀌게 된다.
- 팀원이나 팀 매니저가 직접 팀원을 뽑지 않는 경우가 많다.
- 급여가 연차나 경험과 큰 연관이 있다.
- 금융 프로젝트는 도메인 경험이 중요하다 보니,
고연차, 높은 직위의 인원이 대부분이다. - 대부분의 코드나 프로젝트가 비공개로, 이 사람이 작성한 코드를 확인하기 어렵다.
(실제로 만나보지 않고 평가할 수 있는 요소가 매우 적다.)
이러한 상황 속에서 SI 프로젝트 인원들은 어떻게 사람을 신뢰할 수 있을까요?
아래 4가지 요소에 크게 의존할 수밖에 없다고 생각했습니다.
- 이미 신뢰가 쌓인 사람의 평가
- 어떤 프로젝트를 몇 번 경험했는지
- 개발자의 연차, 등급, 직위
- 직접 눈으로 보고 느낀 점들
그리고 신입 구성원인 저는 아래와 같은 조건을 가지고 있었습니다.
- 팀 관련자가 아니라, 회사 HR 조직이 대신 뽑아줬다.
(3,500명 규모의 회사에 재직 중이고, 채용 과정에서 팀원들의 그림자도 보지 못했습니다.) - 믿을 만한 누군가의 평가 없음
- SI 프로젝트 투입 경험 없음
- 0년 차 신입 개발자
당장 신뢰하기 어려운 것이 당연합니다.
실제로 개발 기간 전까지 많은 우려를 들었습니다.
결국 신뢰 자산이 쌓이기까지 시간이 걸릴 수밖에 없는 상황이었습니다.
천천히 시간을 들여 잘하는 모습을 보여드리고, 신뢰를 쌓아야 했습니다.
하지만 신뢰가 쌓이기 전에, 기존 구성원들에게 다소 낯선 방식의 문제 해결을 신입 구성원이 제한하는 것은 팀원들을 걱정에 빠지게 할 수 밖에 없었다고 생각합니다.
시간이 지나며, 다양한 글들을 읽으며 이런 신뢰 자본에 대해 인식할 수 있었고,
제가 팀원들에게 줬던 우려가 어디서 왔는지 고민해 볼 수 있었습니다.
함께 자라기
일하는 방법의 핵심과 통찰을 다룬다. 개인의 힘으로는 극복할 수 없는 한계를 깨뜨리려면 모두가 같이 발전해야 한다. 나 그리고 더 나아가 남을 변화시키는 삶에 대해 얘기한다.
www.aladin.co.kr
신뢰 자본
몇달전에 미정님을 만나 짧은 대화 시간을 가졌다. 그간 온라인에서만 뵙다가, (기억상으로는) 처음으로 오프라인으로 뵈었다. 전 직장을 같이 다녔지만 미정님은 베트남에서, 나는 서울에서 근
jojoldu.tistory.com
다행히도 함께 하는 시간이 길어지며 신뢰를 쌓았고, “실제로 잘 돌아가는 것”을 여러 번 보여드리면서,
저번 프로젝트 후반에는 저의 관리자 분께서 먼저 “이 문제를 프로그램으로 해결할 수 있는지” 물어봐 주시곤 했습니다.
이번 프로젝트에서도 처음엔 우려 섞인 시선을 받았으나,
다양한 자동화 도구를 공유하며 신뢰가 쌓인 이후엔, 관리자 분께서 먼저 자동화 프로그램을 만들 수 있는지 물어봐 주시기도 했고, 다른 분들에게 제가 만든 툴을 추천하시기도 했습니다.
한번 신뢰가 쌓인 이후엔 설득하기가 훨씬 쉬웠습니다.
설득조차 필요 없었습니다. 일단 믿어주고, 일단 사용해보는 사람이 늘었습니다.
글로만 만났던 설득에 있어 신뢰 자본의 중요성을 직접 느낄 수 있는 좋은 기회였습니다.
5. 후기
지난 8개월간 많은 도구들을 만들고 공유했습니다.
문제를 해결하기 위해 만들고, 나누는 문화를 만들고자 공유했습니다.
그리 대단한 것들은 아니었지만, 뿌듯함과 자신감을 주는 경험이었습니다.
스스로를 인정하고, 누군가에게 도움이 되기 위해 열심히 노력했고,
개인적으로는 만족할 만한 효율 개선을 얻었습니다.
어떤 환경에서든 개발자일 수 있다는 자신감을 얻었고,
신뢰와 설득, 그리고 조직 문화에 대해 고민해 볼 수 있는 좋은 기회였습니다.
사실 누군가의 눈에는 "쓸데없는 고생", "시간 아까운 일", "굳이 하는 일"로 보인다는 사실이 조금 속상할 때도 있습니다.
어떤 프로그램을 만들던 중 "아마도 그것은 필요 없을 것"이라는 누군가의 말에 상처를 받고, 실제로 필요 없을지도 모르겠다는 생각을 헀던 적도 있었습니다.
하지만,
1. 누군가에게 도움이 될 것이라는 확신
2. 진심으로 도움이 되었다고 말해주는 사람들
3. "나는 어떤 환경에서도 문제를 해결하기 위해 만들 수 있다"라는 스스로에 대한 인정
이 세 가지에만 집중했고, 즐겁게 무언가를 만들 수 있었습니다.
저는 더 큰 문제를 해결하는 개발자가 되고 싶습니다.
주변 사람들과 팀을 넘어 더 많은 사람들에게 도움을 주는 개발자가 되고 싶습니다.
그리고 제가 매니저가 된다면, 누구나 기꺼이 자신의 시행착오를 공유하는 조직을 만들어 보고 싶습니다.
그런 개발자가 되기 위해 앞으로도 여러 경험을 쌓고, 고민하고, 시도해 보려 합니다.
폐쇄망 프로젝트는 종료 이후 데이터를 모두 삭제하기 때문에, 제가 만들었던 도구와 가이드 문서들은 모두 사라집니다.
하지만 글로 이 경험을 남긴다면 스스로 더 오래 기억할 수 있고,
또 누군가 읽어준다면 함께 알아줄 사람이 생기기 때문에,
이렇게 저의 생각과 경험을 글로 남깁니다.
읽어주셔서 감사합니다.
안녕하세요
저는 금융 SI 폐쇄망 환경에서 일하며, 문제를 해결하고 업무 효율을 높이기 위해 다양한 자동화 도구를 만들고 공유했습니다.
SI 프로젝트에서 문서 작성, 개발, 프로젝트 관리 업무 수행 중 다양한 불편함과 문제를 만났습니다.
외부 라이브러리나 각종 상용 프로그램을 활용하면 쉽게 해결할 수 있는 문제들이었지만,
금융 SI 폐쇄망이라는 특성상 주어진 도구만을 활용해야 했고, 다양한 기술적-환경적 어려움이 있었습니다.
처음엔 그것을 핑계 삼아 불평불만만 가득했습니다.
하지만 여러 가지 일들을 겪으며 생각을 바꿨고,
나를 위해, 팀을 위해 지금 당장 할 수 있는 것을 찾아 시도했습니다.
드라마틱한 성과, 깊은 기술적 챌린지, 우아한 해결 방법은 없었습니다.
전부 투박했고, 아주 기본적인 알고리즘의 조합이었지만 분명 문제를 해결할 수 있었고,
직장인으로서, 그리고 Developer로서 많은 것들을 배울 수 있었고, 행복감을 주는 경험이었습니다.
1. 주어진 상황과 환경에 불평불만을 갖기 보단, 지금 할 수 있는 것에 집중할 수 있게 되었습니다.
2. 주변의 문제를 SW 개발로 해결하는 경험을 했습니다.
3. 사회 초년생으로서 조직의 목적, 관리자의 고민, 구성원들의 배경과 프로젝트 환경 등에 대해 고민할 수 있었습니다.
4. 내가 좋아하는 것이 무엇인지, 지향하는 문화는 어떤 것인지 알게 되었습니다.
도전하게 된 계기, 시도하는 과정에서 만난 고민, 어려움, 활용했던 도구에 대해 적어보았습니다.
폐쇄망 환경이기에 제가 만든 프로그램과 문서들은 언젠가 모두 삭제됩니다.
행복했던 경험을 오래 간직하기 위해 글을 작성해 보았습니다.
1. 주요 자동화 도구
정리해 보니 지난 몇 개월간 크고 작은 도구들을 꽤 많이 도입했었습니다.
- 6개의 java 프로그램
- 12개의 VBA 매크로
- 3개의 정규 표현식
이 중에서 “가장 큰 도움을 준 도구”들을 정리해 봤습니다
폐쇄망 특성상 자세한 업무 설명이 어려움에 양해 부탁드립니다.
1️⃣ Pro*C Call Graph 생성기 (java 프로그램)
매우 복잡한 호출 관계를 갖는 Pro*C 코드를 분석해, Module 간, 함수 간 Call Graph를 호충 순서를 반영해 엑셀에 트리 형태로 그려내고,
업무에 직접적으로 필요한 호출 Query와 분석 정보를 한눈에 알 수 있게 제공
- Before: 저는 주어진 업무량 소화를 위해 매주 최소 12시간 이상의 추가 근무를 했습니다.
- After: 개발 이후 1주일 분량 2 ~ 3일 만에 추가 근무 없이 해결.
- 프로젝트 내 누구나 사용할 수 있도록 공유, 가장 반응이 좋았던 프로그램
1. 업무에 필요한 정보를 빠르게 확인할 수 있는데 초점
2. 사용자 니즈에 맞게 다양한 탐색 옵션 제공.
- 모듈 호출 그래프, 함수 호출 그래프 선택 옵션
- 선택 모듈과 관련된 도메인 모듈만 탐색 옵션
3. 사용자가 직관적으로 이해할 수 있는 문서 생성을 위해 노력
- 트리 형태로 구성
- 같은 부모 노드를 공유하는 자식 노드 이어주기
- DML 외엔 제거
- DML은 하이라이팅, 종류, 타겟 테이블 첫 줄에 제공
가장 많은 도움을 받으신 팀원분이 소고기를 보내 주시기도 했습니다. 많은 분들이 감사 인사를 주시거나 커피를 사주서 가장 뿌듯함을 안겨준 프로그램이었습니다.
2️⃣ 1,600 건 이상의 쿼리 검토 업무 → 검토 대상 75% 이상 감소 (java 프로그램)
- Before: 10명 이상 작업, 3 ~ 5일 검토 계획
- After: 1인 확인, 2일 소요
1,600개의 쿼리가 특정 규칙을 만족하는지 확인해야 하는 업무였습니다.
중요한 검사이기 때문에, 전부 자동화하기보다는 눈으로 직접 확인해야 하는 대상을 줄이는 데에 집중했고, 조사 대상이 약 400개 이하로 줄어들었습니다. (75% 감소)
그래프 탐색으로 프로젝트 내 모든 Query 파일 탐색 (xml 파일로 작성됨)
-> 파일별 xml에 태그로 표현된 SQL Query 파싱
-> Query 유형에 따라 다른 유형의 검증 수행
-> 검증 결과와 Query, 파일 정보 등을 정리해 엑셀 파일로 제공
3️⃣ DB Migration을 위한 문서 추가 작업 -> 작업 시간 60%, 3일 단축 (VBA)
- Before: 2명 작업, 5일 작업 계획
- After: 2인 작업, 2일 요소 (3일 단축)
Database Migration을 위해 작성해야 하는 문서가 있었고, 해당 문서들을 모두 확인해 상황별로 다른 추가 내용을 기입해야 했다. 문서량이 많은 만큼 2명이서 5 영업일 작업을 계획했었다.
VBA로 구현. 간단한 비교를 통해 어떤 추가 내용을 기입할지 결정. 중요한 문서이기 때문에 추가된 내용이 있는 파일과, 변경된 영역을 눈으로 확인할 수 있도록 안내
4️⃣ Legacy DTO Migration 자동화 -> 하루 평균 10번의 문서 작성 감소
- Before: 하루 평균 10개 이상의 DTO를 GUI 툴을 통해 정의해야 했다.
DTO가 갖는 모든 필드 이름, 타입, 크기, 설명, 기본값 등을 직접 타이핑해 주어야 했음. - After: 폴더 경로만 입력하면 수초 안에 경로 내 DTO 완성
GUI툴에 값을 하나하나 기입해 주면, xml과 유사한 문서 파일이 생성
이 파일이 java DTO를 생성하고, 꼭 이것만 사용해야 한다.
5️⃣ 그 외 도구들
그 외에도 다양한 도움을 주는 프로그램, 매크로 정규 표현식을 만들었습니다.
총 6개의 프로그램, 12개의 VBA 매크로 등을 만들었습니다.
정규 표현식은 기본적인 것이고, 투박하지만, 수천 수만 줄의 Lagacy C Code를 직접 읽으며 분석하는 팀원들의 분석 시간을 줄여주었습니다.
지금까지 구현한 목록입니다. 너무 길어 토글에 접어 두었습니다.
6개의 프로그램, 12개의 VBA 매크로, 3개의 정규식
1. [프로그램] Pro*C 모듈, 함수 Call Graph 생성기
2. [프로그램] Legacy DTO Migration 자동화
3. [프로그램] 1,600건 이상의 쿼리가 특정 규칙을 만족하는지 검증
4. [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증
5. [프로그램] 형상 관리 툴에 push 하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다)
6. [프로그램] DB 컬럼 의미 주석 추가 프로그램 (매일 최소 50개 이상의 컬럼의 한글 의미를 찾아야 했다.)
7. [VBA] DB Migration을 위한 문서 수정 함수
8. [VBA] DB 설계서 컬럼 의미 주석 추가 매크로 (엑셀 파일은 암호화가 되어 있어, 6번 프로그램이 적용되지 않았다.)
9. [VBA] 파일 이름을 통해 UI 정의 문서 내 10개 이상의 셀의 값을 생성해 채워주는 함수
10. [VBA] 폴더 내의 모든 UI 정의 문서에 매크로를 적용하는 함수
11. [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀의 값을 생성해 채우는 함수
12. [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수
13. [VBA] 폴더 내 문서들에 적힌 버전을 원하는 버전으로 바꾸는 함수
14. [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수
15. [VBA] 여러 cell들의 값 앞에 prefix를 붙이고, camel case로 변경하는 함수 (하루에 수십번씩 타이핑해야 했다..)
16. [VBA] 여러 cell들의 기존 prefix를 인식해 새로운 prefix로 교체해주는 함수
17. [VBA] 셀의 값을 카멜 케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스)
18. [VBA] 지정한 색으로 셀을 칠하는 함수들 (셀을 색칠하는 엑셀 단축키는 없음)
19. [정규식] 외부 인터페이스 호출시 input 찾는 정규식 (특정 prefix를 가진 struct가 특정 prefix를 가진 맴버를 호출하는 경우를 찾는 정규식)
20. [정규식] 외부 모듈 호출 정규식 (특정 규칙을 가진 이름의 함수의 호출부를 찾는 정규식)
21. [정규식] 소스코드 전체에서 영문 필드에 달린 한글 주석을 찾는 정규식 (기존엔 전체 프로젝트에 필드를 검색해 주석을 일일이 찾아냈다)
이 도구들이 해결했던 문제와 도와줬던 업무들은 원래 전부 수작업으로 작업해야 했습니다.
사실 간단한 웹 서핑을 통해 누군가의 구현체를 찾을 수도 있고, AI를 통해 빠르게 만들 수도 있는데 왜 전부 수작업으로 수행해야 했을까요?
그 이유는 프로젝트의 높은 보안 요구사항 때문이었습니다.
금융 SI 폐쇄망 환경과 주어진 도구는 다음과 같습니다.
2. 활용 가능한 도구 이해하기
2.1 금융 SI 폐쇄망 환경은 어떨까?
지난 1년간 금융 SI 프로젝트를 참여하며, 환경에 대해 끊임없이 고민했습니다.
금융 SI의 대부분의 제한들은 아래 2가지 요소에서 온다고 추측합니다.
- 금융 도메인 특성상 높은 수준의 보안이 요구된다.
- 금융 도메인 지식이 많은 개발자가 중요하다.
따라서, 평균 연령대와 연차가 높은 편이고, 그런 개발자들에게 익숙한 도구들이 주어진다.
흔히 말하는 "보수적이다"라는 이미지는 이 두 가지 요소에서 오지 않았을까 추측해 봅니다.
그리고 위 2가지 사항에서 아래와 같은 여러 구체적인 제한 사항이 나오게 됩니다.
- 각종 문서 암호화
- 모든 문서 파일은 암호화된다 → 파싱의 가장 큰 장애물
- 추가 언어, 라이브러리 없음
- 주어진 언어 외에 다른 언어나 각종 라이브러리를 추가적으로 반입하기 어려움
- 결국 자동화 도구들은 "제작 시간" 대비 "아끼는 시간"이 커야 하기 때문에, "제작 시간"을 줄여주는 도구들 또한 중요하다.
- 인터넷과 기기 제한
- 보안으로 인해 개인 노트북 반입 어려워, 스마트폰으로 웹 서치
- 생성형 AI 없음. (도입을 시도하는 팀이 있지만 매우 제한적)
- 소프트웨어 제한
- 편리한 IDE (Intellij)나 Plugin 같은 보조 도구 없음
→ 함수 호출부나 정의부 찾기나 리팩토링이 생각보다 어려움 - VSC의 각종 Extension 없음
- 동시편집 툴이나 문서 형상 관리 없음 (컨플루언스, 노션)
- 편리한 IDE (Intellij)나 Plugin 같은 보조 도구 없음
막 신입이었던 저는 바보 같은 생각을 했습니다.
- 인텔리제이를 못 쓴다니 ㅠㅠ 이클립스는 정말 불편해!
- 파이썬도 못 쓴다니 ㅠㅠ
- 엑셀 암호화를 풀 수 없다니 전부 손으로 쳐야 한다고? ㅠㅠ (이건 문제가 맞다)
제가 구상하는 자동화 툴을 쉽게 만들 수 있는 도구의 반입이나,
복호화 툴의 지원을 요청했으나 거절당했고,
주어진 문제를 해결하기 위해 고민하기보단, 상황과 환경에 대한 불평불만이 많았습니다.
다른 개발자, 엔지니어들이 보면 코웃음을 쳤을 것입니다.
크리스 소이어는 게임 최적화를 위해 C 대신 어셈블리로 롤러코스터 타이쿤을 만들었다고 합니다.
게임 슈퍼마리오 브라더스는 겨우 40KB로 작성되었습니다. 당시 게임기인 패미컴의 표준 최대용량이 40KB이기 때문입니다.
이 분들이 저를 보면 무슨 생각을 했을까요?
저를 진짜 개발자라고 인정해 주실 수 있었을까요?
2.2 문제를 해결하기 위해 만드는 사람
문제 해결을 포기하고, 불평 불만으로 가득해 열심히 야근하던 시절에 유튜브에서 어떤 쇼츠를 보았습니다.
마블 시리즈의 아이언맨 3에서 토니 스타크와 꼬마 할리 키너가 대화하는 장면이었습니다.
할리 키너가 토니의 불안 증세를 잠재우는 장면이었습니다.
상황은 이렇습니다.
테러리스트의 습격을 받은 아이언맨은 탈출 도중, 외딴 지역에 불시착했습니다.
슈트는 방전되었고, 저택의 최첨단 설비도 없습니다.
하지만 악당 킬리언의 추격은 끝나지 않았고, 테러리스트 만다린의 아지트도 공격해야 했습니다.
그곳에서 우연히 마주친 할리 키너라는 꼬마의 도움을 받아 슈트의 충전을 시도했지만..
생각대로 잘 되지 않았고, 토니는 평소 앓던 불안증세가 나타나 호흡에 문제가 생겼습니다.
이때 꼬마 할리 키너의 한마디가 아이언맨을 진정시킵니다.
아저씨는 mechanic이잖아요. 맞죠?
그렇다면 무언가 만들어 보는 건 어때요?”
그 말을 듣고 불안 증세가 사라진 토니는 곧장 시골 잡화점으로 달려가 여러 물건들을 구입했고,
그 물건들로 전기 충격 장갑, 사냥돌, 크리스마스 장식 수류탄, 강화 못 총 등을 제작했습니다.
그 무기들은 투박했지만 확실히 적들을 제압할 수 있었고,
테러리스트 만다린의 침소까지 침입할 수 있었습니다.
너무 멋있었습니다.
토니는 최첨단 슈트와 설비 없이도 메카닉이었고,
문제를 해결하기 위해 무언가 만들어 내는 사람이었습니다.
그에 비해 저는 아주 아주 아주 작은 문제를 겪고 있음에도
환경만 탓하며 투덜대기만 했었습니다.
사실 그렇게까지 열악한 상황도 아니었고, 그렇게 대단한 것을 만들어야 하는 상황도 아니었습니다.
갑자기 부끄러움이 밀려 들어왔고, 스스로를 돌아보게 되었습니다.
제가 존경하는 선배 개발자, 엔지니어들이라면 어떻게 했을지 생각했습니다.
환경에 대해 불평하는 대신 지금 할 수 있는 것이 무엇인지 더 찾아보자고 마음먹었습니다.
2.3 가진 도구는 생각보다 많았다.
침착하게 둘러보니, 편리한 최신 툴들이 없을 뿐이지,
문제를 해결할 수 있는 강력한 도구들을 많이 가지고 있었습니다.
1. 엑셀 함수와 VBA는 생각보다 매우 강력했습니다.
평소 엑셀을 다뤄본 적이 없었던 저는 엑셀로 무엇을 할 수 있는지 인지하지 못했었습니다.
2. 정규식만 잘 작성해도 분석 시간을 많이 줄일 수 있었습니다.
3. 반입된 프로그램들이 사용하는 라이브러리들을 잘 찾아보니, java 라이브러리 Apache POI가 있었습니다.
암호화로 인해 엑셀 파싱은 불가능했지만, POI를 활용해 "작성"은 가능했습니다
엑셀 함수 부터 생각보다 매우 강력했습니다.
대표적으로 VLOOKUP은 Vertical + Lookup이라는 의미로, 특정 값을 지정한 범위 내에 있는지 찾아,
발견한 Row의 다른 컬럼 값을 사용할 수 있게 해 줍니다.
예를 들어 위 그림에서 “A003이라는 값을 표 안에서 찾아, 해당 Row 상품 값을 가져오기”와 같은 질의가 가능합니다.
그냥 SQL Query 같죠? 엑셀 파일도 결국 일종의 Table, Table View와 같다고 생각합니다.
VLOOKUP만 잘 활용해도 정말 정말 많은 문제를 해결할 수 있었습니다.
사실 만들었던 프로그램 중 하나는 VLOOKUP과 기존에 제공된 데이터들만 잘 활용했어도, 직접 만들 필요가 없었다는 것을 나중에야 알기도 했습니다.
그 외에도 기본 함수들을 조합해 많은 문제들을 해결할 수 있었습니다.
이들은 GPT가 아주 잘 만들어줍니다. 적극적으로 활용을 권합니다.
2.3.1 Visual Basic for Applications (VBA)
살면서 엑셀을 거의 써본 적이 없어 몰랐지만,
Microsoft Office 프로그램들을 조작할 수 있는 VB라는 언어가 있었습니다.
VBA를 통해 작성한 매크로를 엑셀 파일에서 실행시켜 보니, 엑셀 파일의 내용을 복호화된 상태로 다룰 수 있었습니다.
아마도 VBA를 통한 문서 조작은 Microsoft Office 제품끼리의 상호작용이라고 인정되기 때문인 것 같습니다.
VBA는 우리가 상상하는 기본적인 언어의 기능을 대부분 제공해 줍니다.
- 정규식을 통해 특정 파일들만 순회할 수 있음
- input을 입력받을 수 있음
- 적용할 값이나 경로를 유저가 직접 입력하게 할 수 있음
- 무려 셀을 눌러 input을 지정할 수도 있음
- 간단한 셀과 시트 조작과 스타일 적용은 기본이고, 파일 정보 등의 메타데이터도 활용 가능
- http request 보낼 수 있음. 다른 프로그램 실행 가능
정말 별의별 것이 다 가능하고, 덕분에 정말 많은 도움을 받았습니다.
총 12개의 크고 작은 매크로를 만들었습니다.
- [VBA] DB Migration을 위한 문서 수정 함수
- [VBA] DB 설계서 컬럼 의미 주석 추가 매크로 (엑셀 파일은 암호화가 되어 있어, 6번 프로그램이 적용되지 않았다.)
- [VBA] 파일 이름을 통해 UI 정의 문서 내 10개 이상의 셀의 값을 생성해 채워주는 함수
- [VBA] 폴더 내의 모든 UI 정의 문서에 매크로를 적용하는 함수
- [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀의 값을 생성해 채우는 함수
- [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수
- [VBA] 폴더 내 문서 이름에 적힌 문서의 버전을 모두 바꾸는 함수
- [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수
- [VBA] 여러 cell들의 값 앞에 prefix를 붙이고, camel case로 변경하는 함수 (하루에 수십번씩 타이핑해야 했다..)
- [VBA] 여러 cell들의 기존 prefix를 인식해 새로운 prefix로 교체해주는 함수
- [VBA] 셀의 값을 카멜 케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스)
- [VBA] 지정한 색으로 셀을 칠하는 함수들 (셀을 색칠하는 엑셀 단축키는 없음)
또한 매크로는 단축키 등록이 가능하다는 장점도 있기 때문에,
너무나도 유용하게 잘 사용하고 있습니다. 정말 날개를 달아준 고마운 존재..
2.3.2 정규 표현식의 힘
입사 전엔 사용한 경험이 거의 없었는데,
Legacy C Code를 분석할 때 정규 표현식의 힘은 정말 엄청났습니다!
스크롤을 내리며 특정 패턴을 가진 함수, 변수 할당 등을 찾는 팀원들의 모습을 보았습니다.
충분히 정규 표현식을 통한 검색으로 효율을 높일 수 있어 보였고, 작성해 공유해 드렸습니다.
- 특정 prefix를 가진 struct가 특정 prefix를 가진 멤버를 호출하는 경우를 찾는 정규식
- 특정 규칙을 가진 이름의 함수의 호출부를 빠르게 찾는 정규식
(정확히 어떤 이름으로 정의되어 있을지 미리 알 수 없음) - 필드에 달린 한글 주석을 찾는 정규식
(기존엔 전체 프로젝트에 필드를 검색해 주석을 일일이 찾아냈다)
덕분에 분석할 때마다 시간을 아낄 수 있었습니다.
이 또한 GPT님의 은혜로 쉽게 작성할 수 있었습니다.
2.3.3 기본 jdk와 Apache POI
정말 운이 좋게도 Apache POI가 깔려 있었습니다!
Apache POI 라이브러리는 java로 엑셀 문서를 조작하거나 작성하는 것을 도와줍니다.
사실 엑셀 암호화라는 제약만 없으면 jdk와 Apache POI만 있어도 대부분의 문제는 해결 가능했습니다.
엑셀 파일을 만들고, 셀들을 채우고, 시트를 만들고, 스타일을 입히는 대부분의 행위가 가능합니다!
저희는 암호화되어 있기 때문에, 파싱과 조작은 어려웠고
java 프로그램으로 문제를 해결하는 경우 결과를 이쁘게 정리해 드리는 데에 도움을 받았습니다.
팀원들이 가장 익숙하고, 편하게 볼 수 있는 문서 형태가 엑셀이었기 때문입니다.
java로 작성한 프로그램은 6개였고, 이 중 3개의 프로그램에서 POI를 활용했습니다.
- [프로그램] Pro*C 함수, 모듈 Call Graph 생성기
- [프로그램] 1,600건 이상의 쿼리가 특정 규칙을 만족하는지 검증
- [프로그램] Legacy DTO Migration 자동화
- [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증
- [프로그램] 형상 관리 툴에 push 하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다)
- [프로그램] DB 컬럼 한글 주석 달아주기 (매주 최소 100여 개의 컬럼 한글명을 찾아 기재해야했다.)
3. 만들고 나누었던 이유
3.1 문제를 해결하기 위해 만드는 사람
비전공자였고, C언어의 존재만을 겨우 알던 상태였습니다.
어렸을 때 RPG 만들기와 스타크래프트 유즈맵을 만들었었고, 어린 시절 꿈이었던 게임 개발에 도전하기 위해 처음 C언어를 공부했습니다. 게임을 만들면서 만드는 것의 즐거움을 배웠고, 취미로 알고리즘 문제를 풀며 문제 해결의 줄거움을 배웠습니다. 앱을 만들고, 사이트를 만들며 자연스럽게 개발자가 되고 싶다는 꿈을 키웠고, 현실의 문제를 해결하기 위해 다양한 SW를 만들었습니다.
이 모든 과정은 즐거웠습니다.
하지만, 처음 만나는 환경에서 앞서 잠시 나약한 생각을 했었습니다.
주어진 문제를 해결하기 위해 고민하기보단, 상황과 환경에 대한 불평불만이 많았습니다.
내가 정말 좋아했던 것이 무엇이고, 내가 되고 싶은건 어떤 모습일까 끊임없이 고민했습니다.
고민 끝에, 저는 단순히 "코드를 짜는 것"을 좋아하는 사람이 아니라는 것을 알게 되었습니다.
가장 행복했던 순간들은 "제가 만든 도구가 사람들에게 실질적으로 도움이나 재미를 주었을 때"였습니다.
내가 만든 게임을 누군가 재밌다고 해줬을 때,
내가 만든 사이트, 자동화 도구, IDE 플러그인이 누군가에게 도움이 되었을 때,인텔리제이를 사용하다가 머리가 복잡해진 경험이 있다면?
어느때 보다 도파민이 넘쳐났고, 저는 그 안에서 행복을 느끼는 사람임을 알게 되었습니다.
제가 정말로 좋은 Software Developer 라면, 상황과 환경을 탓할게 아니라
현재 상황에서 할 수 있는 것을 찾고,
어떤 환경에서든 문제를 해결하기 위해 만드는 사람이 될 수 있어야 한다고 생각했습니다.
환경을 탓하는 습관을 버리고, 지금 가진 도구들 내에서 해결할 수 있는 방법을 찾는 습관 덕분에 많은 도구를 만들어볼 수 있었고, 어떤 환경에서도 문제 해결의 방법을 찾아낼 수 있겠다는 자신감이 생겼습니다.
돈을 더 받기 위해서도, 연말에 좋은 평가를 받기 위해서도 아니었습니다.
평일 저녁이나 주말에 추가 근무를 보고하지 않고 만들거나, 점심시간을 활용해 만들었지만, 시간이 조금도 아깝지 않았습니다. 돈 보다 더 큰 만족감을 얻을 수 있었습니다.
3.2 "공유"로 이루고 싶었던 것
작년 5월 부터 벌써 많은 도구를 만들어 사용했고, 다른 사람도 사용할 수 있도록 공유했습니다.
제가 이렇게 만든 도구들을 공유한 이유는 전부 자기 만족 때문입니다.
- 만드는 것을 좋아한다.
- 다른 사람에게 도움이 되는 것을 좋아한다. (네이버 지식인이 취미였다!)
- 더 많은 사람이 쓸수록 내가 만든 도구가 더 효율적인 도구가 된다.
자동화 툴의 효율은 "제작 시간" 대비, "아끼게 되는 시간"으로 결정되기 때문에, 아끼는 시간이 높아질 수록, 유용한 자동화 툴이 된다. - 서로를 위해 기꺼이 공유하는 문화가 형성 됐으면 좋겠다.
개발자로서, 기술 발표나 오픈 소스 기여 활동을 하며, 공유하는 문화를 좋아하긴 하지만,
사실은 직장에서 "내가 공유 받는것"을 기대하며 공유 활동을 했습니다.
현 직장에서 일하며 저는 겪어 보지 못한 매우 다양한 종류의 업무를 수행했습니다.
이제까지 개발 업무는 50% 혹은 그것 보다 낮았고,
개발을 위한 분석, 설계서 작성 등의 각종 문서 작업과 협력사 분들과 커뮤니케이션을 하는 등의 업무를 해왔습니다.
개발은 취직 하기 전에도 꾸준히 해왔기 때문에, 그리 낯설지 않았으나
다른 업무는 달랐습니다.
어떻게하면 더 잘 할 수 있는지, 어떻게 하면 더 효율적으로 할 수 있는지, 아무것도 몰랐습니다.
정보나 노하우의 격차는 실제 업무 수행에 있어서도 큰 차이를 만들었지만, 거의 공유되지 않았습니다.
폐쇄망의 파일 보관소. 그 문서와 도구의 바다 속에서.. 어딘가에 숨겨져 있는 "특정 문서"를 가지고 있는 사람은 업무 효율이 2배 이상 높아지는 경우도 있었습니다. 더 편한 도구나, 그 세팅법을 일부 인원만 알고 사용하는 경우도 있었습니다.
이런 정보들을 모두가 알면 좋을텐데, 똑똑하고 일 잘하는 몇 명이 가끔 찾아내거나, 다른 사람이 사용하는 것을 우연히 보고 찾게 되거나, 친한 사람이 비밀처럼 알려주는 식으로만 이 꿀팁이 공유 됐습니다.
이들은 "노하우"라는 이름으로 비밀리에 공유되고 있었습니다.
어떤 업무가 다 끝났을 때, "알고보니 그 업무의 효율을 높이는 신통방통한 문서나 도구가 있었다"와 같은 상황을 많이 겪었습니다.
SI 프로젝트는 어느 정도 패턴화 되어 있고, 해야 하는 일도 어느 정도 비슷합니다.
대부분의 프로젝트는 같은 문제를 몇번이고 몇번이고 겪고 있습니다.
그런데 왜 더 좋은 길은 아무도 알려주지 않고, 스스로 알아내야만 할까요?
시행착오를 겪으며 사람이 성장할 수 있지만,
그러기엔 SI프로젝트는 너무 일과 문제가 많고, 항상 인력이 부족하고, 다들 지쳐있습니다.
3.3 "노하우"라는 단어가 주는 아픔
각자 시행착오를 반복해 겪을 것이 아니라, 서로의 실패와 성공을 공유하고, 머리를 맞댄다면
똑같은 시도와 똑같은 실패를 최소화할 수 있지 않을까요?
또 누군가 그 방법에서 좋은 아이디어를 얻어 더 멋진 방법을 발견할 수도 있지 않을까요?
모두의 효율이 높아질 수 있는 방법이 있는데 왜 공유되지 않을까요?
그 이유를 자주 고민하고, 곧 은퇴할 연차가 되어가는 부장님 부터 선임분들까지 여쭈어 봤습니다.
부장님께 여러 옛날 이야기들을 들을 수 있었고,
결론적으로는 “정보나 툴 공유자는 칭찬과 장려 대신, 심리적 압박과 책임을 요구받았다”가 원인이었다고 합니다.
무언가 공유하는 행위는 누군가의 눈에는 "굳이 나서는 일", "손으로 하는게 빠른데 굳이 하는 일"로 보일 수도 있고, 실제로 그런 말을 들었다고 합니다. 또한 그 사람이 공유한 도구에 조금의 문제라도 있으면, 평가 절하되거나, 비난을 받거나, 수정 요청에 시달렸다고 합니다.
제가 만든 레거시 분석 툴과 비슷한 툴을 20년 프로젝트에서 개발하신 프리랜서 개발자 분이 계셨는데,
매일 밤세워 자발적으로 프로그램을 만들었지만 끝없는 수정 요청에 오히려 자신이 맡은 업무에 차질이 있었고, 많은 스트레스를 받았다고 합니다.
제가 생각하는 생각의 변화 흐름은 이렇습니다.
- 공유자는 기꺼이 자신의 시간과 지식을 내놓았지만, 칭찬과 격려 대신
"심리적 압박과 책임"을 받았다. - "작업량"과 "연차", "프로젝트 참여 횟수"로 급여가 평가되는 SI 환경 특성상 이런 행동을 한다고 해서 딱히 더 나은 평가를 받진 않는다.
- 공유자들은 자연스럽게 주도적 기여와 공유를 꺼리게 된다.
- 다른 구성원들 또한 공유에 대해 긍정적으로 생각하기 어렵게 된다. (나 또한 받아본 적 없기에..)
- 공유하지 않는 것이 당연한 세상이 온다..
- 다른 이에게 도움을 받은 경험이 없는 사람들이 많아지고, 이들은 자연스럽게 공유의 동기를 못 느낀다.
- 자동화 함수나 툴 또한 누군가 만들어 주는 일이 적어지고, 경험도 듣기 어려워진다.
그러니까 그 툴들이 실제로 얼마나 효용이 있는지, 제작엔 얼마나 걸리는지 추측하기 어렵게 되고, 시도조차 하지 않게 된다.
자연스럽게 무서운 생각이 자리 잡지 않았을까 싶습니다.
- "자발적으로 무언가 만들어 공유한다고 해서 딱히 큰 이득이 있진 않네.. 오히려 힘들어"
- “이건 나만의 노하우인데..”
- "나한테도 누군가 알려주지 않았잖아"
- "다른 사람들이 하지 않는 데는 이유가 있겠지"
3.4 공유하는 조직에 기여하기
이러한 문화가 개선되려면, 선의의 공유자들이 감사와 칭찬, 격려를 받는 환경이 되어야 한다고 생각했습니다.
하지만, 이미 오랜 시간에 걸쳐 문화가 자리 잡혔고, 저는 영향력 있는 사람도 아니었습니다.
그렇다고 영향력 있는 사람이 되기까지 아무것도 하지 않으며 기다리는 것은 싫었습니다.
당장 해볼 수 있는 것을 생각해 보았고, 내 주변이라도 조금씩 바꿔보고 싶었습니다.
이 많은 사람 중 몇 명이라도 감염시킬 수 있다면 그 몇 명이 살아가며 다른 몇명을 감염 시키고
또 그렇게 퍼져나가길 기대했습니다.
제가 생각한 선순환은 아래와 같습니다.
- 내가 먼저 유용한 정보와 유용한 툴을 공유한다.
- 누군가 도움이 되었다고 느낀다면, 나와 비슷한 동기로 툴을 만들거나 정보를 공유하는 사람이 생길 것이다.
- 나부터 그런 사람을 발견하면 적극적으로 감사 인사를 드린다.
- 감염된 사람들은 또 다른 사람을 감염시키며.. -> 모두가 스스로 자신의 노하우를 공유하는 세상이 온다!
이러한 흐름을 상상하며 저만의 작은 퀘스트인 “공유하는 조직 만들기”를 시작됐습니다.
처음엔 작은 단위에서 시작했습니다. 옆자리 동료로 시작해서, 매일 커피를 사러 나가는 동료, 10명 내외의 작은 단위에 공유했습니다. 좋은 반응을 얻고, 용기 내어 프로젝트 개발자 전체 공유도 시도했습니다.
저번 프로젝트에선 자동화 툴 하나와 Spring Batch 가이드문서 하나를 공유했었습니다.
아쉽게도 처음 용기 내어 공유했던 당시엔 반응이 거의 없어 주춤했으나,
몇 달 뒤 여러 사람들이 도움을 받았다는 후일담을 듣게 되었고, 다시 용기가 났습니다.
그 경험으로 이번 프로젝트에서는 더 적극적으로 도구를 만들고, 사람들과 나누고 있습니다.
4. 신뢰와 설득에 대한 고민
신입 개발자로서, 이러한 자동화 툴들을 만들고 공유하는 과정에서, 신뢰와 설득에 대해서도 많이 고민할 수 있었습니다.
호기롭게 전체 개발자 톡방에 직접 작성한 가이드 문서와 자동화 툴을 공유했으나, 반응은 없었습니다.
제가 만든 도구나, 공유한 정보들은 제대로 신뢰를 얻고 사용되기까지 제법 오랜 시간이 걸렸습니다.
제 옆에서 상상할 수 있는 모든 엣지 케이스를 대입하며 테스트 해보시는 분도 계셨습니다.
신뢰 받지 못한 원인은 무엇일까요?
원인은 저에게 있었습니다.
4.1 논리야 놀자!
그때의 저는 논리가 설득의 가장 큰 요소라고 생각했습니다.
처음으로 업무 시간에 자동화 툴 구현을 제안했을 때입니다.
문서 수백 개를 2명이서 5일 동안 수정해야 하는 상황이었습니다.
저의 주장은 아래와 같았습니다.
- 수정 규칙이 명확하기 때문에 코드로 해결할 수 있다.
- 개수가 너무 많아서 직접 하는 게 너무 힘들다.
- 완전 자동화가 걱정되면,
실제로 VBA가 수정한 문서만 정리해서 수정된 부분만 눈으로만 확인할 수 있게 조치할 수 있다. - 구체적으로 로직을 설명했고, 하루 안에 구현할 수 있음을 어필했다.
저의 머리속에선, 제가 제시한 방법과 설명한 로직이 설득력 있다고 생각했습니다.
하지만 많은 우려들을 만나게 되었습니다.
- 제안한 프로그램이 실제로 구현 가능한 것인가?
- 의도대로 실수없이 동작할 것인가?
- 만드는데 오래 걸릴 것 같은데, 혹시 손으로 하는게 더 효율적이진 않을까?
저는 쉽게 받아들여질 것이라고 생각했습니다. 하지만 왜 쉽게 설득하지 못했을까요?
이 우려들은 전부 어디서 온 것일까요?
4.2 SI 프로젝트와 신뢰에 대한 생각
많은 고민 끝에, 모든 우려들의 원인을 아래와 같이 추측했습니다.
"금융 SI 환경은 신입 구성원을 신뢰하기 어려운 환경이다."
이렇게 생각한 이유는 아래와 같습니다.
SI 프로젝트 팀들은 아래와 같은 상황에 놓여 있습니다.
- 수개월 혹은 연 단위로 팀원이 바뀌게 된다.
- 팀원이나 팀 매니저가 직접 팀원을 뽑지 않는 경우가 많다.
- 급여가 연차나 경험과 큰 연관이 있다.
- 금융 프로젝트는 도메인 경험이 중요하다 보니,
고연차, 높은 직위의 인원이 대부분이다. - 대부분의 코드나 프로젝트가 비공개로, 이 사람이 작성한 코드를 확인하기 어렵다.
(실제로 만나보지 않고 평가할 수 있는 요소가 매우 적다.)
이러한 상황 속에서 SI 프로젝트 인원들은 어떻게 사람을 신뢰할 수 있을까요?
아래 4가지 요소에 크게 의존할 수밖에 없다고 생각했습니다.
- 이미 신뢰가 쌓인 사람의 평가
- 어떤 프로젝트를 몇 번 경험했는지
- 개발자의 연차, 등급, 직위
- 직접 눈으로 보고 느낀 점들
그리고 신입 구성원인 저는 아래와 같은 조건을 가지고 있었습니다.
- 팀 관련자가 아니라, 회사 HR 조직이 대신 뽑아줬다.
(3,500명 규모의 회사에 재직 중이고, 채용 과정에서 팀원들의 그림자도 보지 못했습니다.) - 믿을 만한 누군가의 평가 없음
- SI 프로젝트 투입 경험 없음
- 0년 차 신입 개발자
당장 신뢰하기 어려운 것이 당연합니다.
실제로 개발 기간 전까지 많은 우려를 들었습니다.
결국 신뢰 자산이 쌓이기까지 시간이 걸릴 수밖에 없는 상황이었습니다.
천천히 시간을 들여 잘하는 모습을 보여드리고, 신뢰를 쌓아야 했습니다.
하지만 신뢰가 쌓이기 전에, 기존 구성원들에게 다소 낯선 방식의 문제 해결을 신입 구성원이 제한하는 것은 팀원들을 걱정에 빠지게 할 수 밖에 없었다고 생각합니다.
시간이 지나며, 다양한 글들을 읽으며 이런 신뢰 자본에 대해 인식할 수 있었고,
제가 팀원들에게 줬던 우려가 어디서 왔는지 고민해 볼 수 있었습니다.
함께 자라기
일하는 방법의 핵심과 통찰을 다룬다. 개인의 힘으로는 극복할 수 없는 한계를 깨뜨리려면 모두가 같이 발전해야 한다. 나 그리고 더 나아가 남을 변화시키는 삶에 대해 얘기한다.
www.aladin.co.kr
신뢰 자본
몇달전에 미정님을 만나 짧은 대화 시간을 가졌다. 그간 온라인에서만 뵙다가, (기억상으로는) 처음으로 오프라인으로 뵈었다. 전 직장을 같이 다녔지만 미정님은 베트남에서, 나는 서울에서 근
jojoldu.tistory.com
다행히도 함께 하는 시간이 길어지며 신뢰를 쌓았고, “실제로 잘 돌아가는 것”을 여러 번 보여드리면서,
저번 프로젝트 후반에는 저의 관리자 분께서 먼저 “이 문제를 프로그램으로 해결할 수 있는지” 물어봐 주시곤 했습니다.
이번 프로젝트에서도 처음엔 우려 섞인 시선을 받았으나,
다양한 자동화 도구를 공유하며 신뢰가 쌓인 이후엔, 관리자 분께서 먼저 자동화 프로그램을 만들 수 있는지 물어봐 주시기도 했고, 다른 분들에게 제가 만든 툴을 추천하시기도 했습니다.
한번 신뢰가 쌓인 이후엔 설득하기가 훨씬 쉬웠습니다.
설득조차 필요 없었습니다. 일단 믿어주고, 일단 사용해보는 사람이 늘었습니다.
글로만 만났던 설득에 있어 신뢰 자본의 중요성을 직접 느낄 수 있는 좋은 기회였습니다.
5. 후기
지난 8개월간 많은 도구들을 만들고 공유했습니다.
문제를 해결하기 위해 만들고, 나누는 문화를 만들고자 공유했습니다.
그리 대단한 것들은 아니었지만, 뿌듯함과 자신감을 주는 경험이었습니다.
스스로를 인정하고, 누군가에게 도움이 되기 위해 열심히 노력했고,
개인적으로는 만족할 만한 효율 개선을 얻었습니다.
어떤 환경에서든 개발자일 수 있다는 자신감을 얻었고,
신뢰와 설득, 그리고 조직 문화에 대해 고민해 볼 수 있는 좋은 기회였습니다.
사실 누군가의 눈에는 "쓸데없는 고생", "시간 아까운 일", "굳이 하는 일"로 보인다는 사실이 조금 속상할 때도 있습니다.
어떤 프로그램을 만들던 중 "아마도 그것은 필요 없을 것"이라는 누군가의 말에 상처를 받고, 실제로 필요 없을지도 모르겠다는 생각을 헀던 적도 있었습니다.
하지만,
1. 누군가에게 도움이 될 것이라는 확신
2. 진심으로 도움이 되었다고 말해주는 사람들
3. "나는 어떤 환경에서도 문제를 해결하기 위해 만들 수 있다"라는 스스로에 대한 인정
이 세 가지에만 집중했고, 즐겁게 무언가를 만들 수 있었습니다.
저는 더 큰 문제를 해결하는 개발자가 되고 싶습니다.
주변 사람들과 팀을 넘어 더 많은 사람들에게 도움을 주는 개발자가 되고 싶습니다.
그리고 제가 매니저가 된다면, 누구나 기꺼이 자신의 시행착오를 공유하는 조직을 만들어 보고 싶습니다.
그런 개발자가 되기 위해 앞으로도 여러 경험을 쌓고, 고민하고, 시도해 보려 합니다.
폐쇄망 프로젝트는 종료 이후 데이터를 모두 삭제하기 때문에, 제가 만들었던 도구와 가이드 문서들은 모두 사라집니다.
하지만 글로 이 경험을 남긴다면 스스로 더 오래 기억할 수 있고,
또 누군가 읽어준다면 함께 알아줄 사람이 생기기 때문에,
이렇게 저의 생각과 경험을 글로 남깁니다.
읽어주셔서 감사합니다.
