금융 SI에서 자동화 도구를 도입하며 배운 것들

폐쇄망 환경에서 업무 효율을 높이기 위해 다양한 툴을 도입하며 배운 점들과
공유하는 문화에 기여하기 위해 고민했던 점들을 정리해 봤습니다.
 
금융 SI 폐쇄망이라는 특성상 다양한 기술적-환경적 어려움이 있었고,
이겨내기 위해 했던 고민, 활용했던 도구, 설득 과정을 적어봅니다
 
드라마틱한 성과나, 깊은 기술적 챌린지, 우아한 해결 방법은 없었지만
직장인으로서 개발자로서 많은 것들을 배울 수 있었고, 행복감을 주는 경험이었습니다.
 

1. 주요 도구

정리해 보니 지난 몇 개월간 크고 작은 도구들을 꽤 많이 도입했었습니다.

-  4개의 java 프로그램
-  11개의 VBA 매크로
-  3개의 정규 표현식

 
이 도구들은 저희에게 닥친 문제를 해결하고, 업무 효율을 높이는 데에 기여했다고 생각합니다.
 
제가 생각한 "가장 큰 도움을 준 도구들"은 아래와 같습니다.
(폐쇄망 특성상 자세한 업무 설명이 어려움에 양해 부탁 드립니다.)
 
 

1.1 1600 건 이상의 쿼리 검토 업무 → 검토 대상 75% 이상 감소 (java 프로그램)

• Before: 10명 이상 작업, 3 ~ 5일 검토 계획
• After: 1인 확인, 2일 소요

1600개의 쿼리가 특정 규칙을 만족하는지 확인해야 하는 업무였습니다.
 
중요한 검사이기 때문에, 전부 자동화하기보다는 눈으로 직접 확인해야 하는 대상을 줄이는 데에 집중했고, 조사 대상이 약 400개 이하로 줄어들었습니다.
 
그래프 탐색으로 프로젝트 내 모든 Query 파일 탐색 (xml 파일로 작성됨)
-> 파일별 xml에 태그로 표현된 SQL Query 파싱
-> Query 유형에 따라 다른 유형의 검증 수행
-> 검증 결과와 Query, 파일 정보 등을 모두 정리해 엑셀 파일로 제공
 
 

1.2 DB Migration을 위한 문서 수정 업무 -> 작업 시간 60% 단축 (VBA)

• Before: 2명 작업, 5일 작업 계획
• After: 2인 작업, 2일 요소

 
기존 데이터를 다른 DBMS 서비스로 옮기기 위해 작성해야 하는 문서가 있었고, 해당 문서들을 모두 확인해 Case별로 다른 추가 내용을 기입해야 했다.
 
VBA로 구현. 간단한 비교를 통해 어떤 추가 내용을 기입할지 결정 -> 추가중요한 문서이기 때문에 추가된 내용이 있는 파일과, 추가된 영역을 눈으로 확인하도록 조치
 
 

1.3 Legacy DTO Migration 자동화 -> 하루 평균 10번의 문서 작성 감소

• Before: 하루 평균 10개 이상의 DTO를 GUI 툴을 통해 정의해야 했다.
  모든 필드의 이름, 타입, 크기, 설명, 기본 값 등을 직접 타이핑해 주어야 했음
• After: 폴더 경로만 입력하면 수초 안에 경로 내 DTO 완성

GUI툴에 값을 하나하나 기입해 주면, xml과 유사한 문서 파일이 생성
이 파일이 java DTO를 생성하고, 꼭 이것만 사용해야 한다.
 

1.4 그 외의 도구들과 느낀 점

그 외에도 다양한 도움을 주는 프로그램, 매크로 정규 표현식을 만들었습니다.
정규 표현식은 쉽고 투박하지만, Lagacy C언어 Code를 직접 읽으며 분석하는 시간을 줄여주었습니다.
 
지금까지 구현한 목록입니다. 너무 길어 토글로 정리했습니다.
 

4개의 프로그램, 11개의 VBA 매크로, 3개의 정규식

1. [프로그램] 1600건 이상의 쿼리가 특정 규칙을 만족하는지 검증 2. [프로그램] Legacy DTO Migration 자동화 3. [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증 4. [프로그램] 형상 관리 툴에 push하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다) 5. [VBA] DB Migration을 위한 문서 수정 함수 6. [VBA] 파일 이름을 통해 UI 정의 문서내 10개 이상의 셀을 채우는 함수 7. [VBA] 폴더 내 모든 엑셀 파일에 대해 2번 함수를 적용하는 함수 8. [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀을 채우는 함수 9. [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수 10. [VBA] 폴더 내 문서 이름에 적힌 문서의 버전을 모두 바꾸는 함수 11. [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수 12. [VBA] 어떤 cell의 내용에 prefix를 붙이고 camel case로 변경하는 함수 (하루에 수십번씩 타이핑 해야 했다..) 13. [VBA] 기존 cell의 prefix 값을 교체하는 함수 14. [VBA] 지정한 색으로 셀을 칠하는 함수 15. [VBA] 셀의 값을 카멜케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스) 16. [정규식] 특정 prefix를 가진 struct가 특정 prefix를 가진 맴버를 호출하는 경우를 찾는 정규식 17. [정규식] 특정 규칙을 가진 이름의 함수의 호출부를 찾는 정규식 18. [정규식] 필드에 달린 한글 주석을 찾는 정규식 (기존엔 전체 프로젝트에 필드를 검색해 주석을 일일히 찾아냈다)

 
 
또한 다양한 도구를 만들고, 사용을 설득하는 과정에서
신입 개발자로서 많은 점을 배울 수 있었습니다.

1. 활용 가능한 도구의 이해
2. 신뢰 자본의 중요성과 설득

이 글에선 제가 자동화를 도입하며 배운 점들과
금융 SI에서 공유하는 문화를 만들기 위한 고민과 시도를 공유합니다.
 
 

2. 활용 가능한 도구 이해하기

2.1 금융 SI 폐쇄망 환경은 어떨까?

 

"금융 SI"로 검색하면 가장 먼저 나오는 사진을 가져왔다. <출처: http://www.ddaily.co.kr/news/article.html?no=154681>

 
 
지난 1년간 금융 SI 프로젝트를 참여하며, 환경에 대해 끊임없이 고민했습니다. 
금융 SI의 대부분의 제한들은 아래 2가지 요소에서 온다고 추측합니다.

1. 금융 도메인 특성상 높은 수준의 보안이 요구된다.
2. 금융 도메인 지식이 많은 개발자가 중요하다.
   따라서, 평균 연령대와 연차가 높은 편이고, 그런 개발자들에게 익숙한 도구들이 주어진다.

흔히 말하는 "보수적이다"라는 이미지는 이 두 가지 요소에서 오지 않았을까 추측해 봅니다.
 
 
그리고 위 2가지 사항에서 아래와 같은 여러 구체적인 제한 사항이 나오게 됩니다.

1. 각종 문서 암호화
   • 모든 문서 파일은 암호화된다 → 파싱의 가장 큰 장애물
2. 추가 언어, 라이브러리 없음
   • 주어진 언어 외에 다른 언어나 각종 라이브러리를 추가적으로 반입하기 어려움
   • 결국 자동화 도구들은 "제작 시간" 대비 "아끼는 시간"이 커야 하기 때문에, "제작 시간"을 줄여주는 도구들 또한 중요하다.
3. 인터넷과 기기 제한
   • 보안으로 인해 개인 노트북 반입 어려워, 스마트폰으로 웹 서치
   • 생성형 AI 없음. (도입을 시도하는 팀이 있지만 매우 제한적)
4. 소프트웨어 제한
   • 편리한 IDE (Intellij)나 Plugin 같은 보조 도구 없음
     → 함수 호출부나 정의부 찾기나 리팩토링이 생각보다 어려움
   • VSC의 각종 Extension 없음
   • 동시편집 툴이나 문서 형상 관리 없음 (컨플루언스, 노션)

 

 
막 신입이었던 저는 바보 같은 생각을 했습니다.

• 인텔리제이를 못 쓴다니 ㅠㅠ 이클립스는 정말 불편해!
• 파이썬도 못 쓴다니 ㅠㅠ
• 엑셀 암호화를 풀 수 없다니 전부 손으로 쳐야 한다고? ㅠㅠ (이건 문제가 맞다)

 
제가 구상하는 자동화 툴을 쉽게 만들 수 있는 도구의 반입이나,
복호화 툴의 지원을 요청했으나 거절당했고, (지금 생각해 보면 거절이 당연)
주어진 문제를 해결하기 위해 고민하기보단, 상황과 환경에 대한 불평불만이 많았습니다.
 
다른 개발자, 엔지니어들이 보면 코웃음을 쳤을 것입니다.
크리스 소이어는 게임 최적화를 위해 C 대신 어셈블리로 롤러코스터 타이쿤을 만들었다고 합니다. 
게임 슈퍼마리오 브라더스는 겨우 40KB로 작성되었습니다. 당시 게임기인 패미컴의 표준 최대용량이 40KB이기 때문입니다.
 
이 분들이 저를 보면 무슨 생각을 했을까요?
 
 

2.2 문제를 해결하기 위해 만드는 사람

불평불만으로 가득하던 때에 유튜브에서 어떤 쇼츠를 보았습니다.
마블 시리즈의 아이언맨 3에서 토니 스타크와 꼬마 할리 키너가 대화하는 장면이었습니다.
할리 키너가 토니의 불안 증세를 잠재우는 장면이었습니다.
상황은 이렇습니다.
 
 

<출처: TopMarvelClips>

 
테러리스트의 습격을 받은 아이언맨은 탈출 도중, 외딴 지역에 불시착했습니다.
슈트는 방전되었고, 저택의 최첨단 설비도 없습니다.
 
하지만 악당 킬리언의 부하들의 추격은 끝나지 않았고, 테러리스트 만다린의 아지트도 공격해야 했습니다.
 
그곳에서 우연히 마주친 할리 키너라는 꼬마의 도움을 받아 슈트의 충전을 시도하려 했으나,
잘 되지 않았고, 토니는 평소 앓던 불안증세가 나타나 호흡에 문제가 생겼습니다.
 

 
 
이때 꼬마 할리 키너의 한마디가 아이언맨을 진정시킵니다.
 
 

<출처: TopMarvelClips>

 
“You're a mechanic, right?”
“Why don't you just build something?”
 
“아저씨는 mechanic이잖아요. 무언가 만들어 보는 건 어때요?”
 

 

<출처: TopMarvelClips>

 
 
그 말에 불안 증세가 사라진 토니는 곧장 시골 마트로 달려가 여러 물건들을 구입했고,
그 물건들로 전기 충격 장갑, 사냥돌, 크리스마스 장식 수류탄, 강화 못 총 등을 제작했습니다.
 
그 무기들은 투박했지만 확실히 적들을 제압할 수 있었고,
악당인 만다린의 침소까지 침입할 수 있었습니다.
 
너무 멋졌습니다..
토니는 최첨단 슈트와 설비 없이도 문제를 해결하기 위해 무언가 만들어 내는 사람이었습니다.
 
그에 비해 저는 환경이 열악하다고 투덜대기만 했었습니다.
사실 그렇게까지 열악한 상황도 아니었고, 그렇게 대단한 것을 만들어야 하는 상황도 아니었습니다.
환경에 대해 불평하는 대신 지금 할 수 있는 것이 무엇인지 더 찾아보자고 마음먹었습니다.
 
 

2.3 엑셀은 힘이 세다

침착하게 둘러보니, 편리한 최신 툴들이 없을 뿐이지,
어느 정도 문제를 해결할 수 있는 도구들은 많았습니다.
 
1. 엑셀 함수와 VBA는 생각보다 매우 강력했습니다.
    평소 엑셀을 다뤄본 적이 없었던 저는 엑셀로 무엇을 할 수 있는지 인지하지 못했었습니다.
2. 정규식만 잘 작성해도 분석 시간을 많이 줄일 수 있었습니다.
3. 설치된 라이브러리들을 확인하다 보니 java 라이브러리 Apache POI가 있었습니다.
   암호화로 인해 엑셀 파싱은 불가능했지만, POI를 활용해 "작성"은 가능했습니다
 
첫 번째로 엑셀 함수는 생각보다 강력했습니다.
대표적으로 VLOOKUP은 Vertical + Lookup이라는 의미로, 특정 값을 지정한 범위 내에 있는지 찾아,
발견한 Row의 다른 컬럼 값을 사용할 수 있게 해 줍니다.
 

<출처 엑셀웍스>

 
예를 들어 위 그림에서 “A003이라는 값을 표 안에서 찾아, 해당 Row 상품 값을 가져오기”와 같은 질의가 가능합니다.
그냥 SQL Query 같죠? 요즘은 엑셀 파일도 결국 Table View와 같다고 생각 중입니다.
 
VLOOKUP만 잘 활용해도 정말 많은 문제를 해결할 수 있었습니다.
사실 만들었던 프로그램 중 하나는 VLOOKUP과 기존에 제공된 데이터들만 잘 활용했어도, 직접 만들 필요가 없었다는 것을 나중에야 알기도 했습니다.
 
그 외에도 기본 함수들을 조합해 많은 문제들을 해결할 수 있었습니다.
이들은 GPT가 아주 잘 만들어줍니다. 적극적으로 활용을 권합니다.
 
 
 

2.3.1 Visual Basic for Applications (VBA)

 

 
살면서 엑셀을 거의 써본 적이 없어 몰랐지만,
Microsoft Office 프로그램들을 조작할 수 있는 VB라는 언어가 있었습니다.
 
VBA를 통해 작성한 매크로를 엑셀 파일에서 실행시켜 보니, 엑셀 파일의 내용을 복호화된 상태로 다룰 수 있었습니다.
아마도 VBA를 통한 문서 조작은 Microsoft Office 제품끼리의 상호작용이라고 인정되기 때문인 것 같습니다.
 
VBA는 우리가 상상하는 기본적인 언어의 기능을 대부분 제공해 줍니다.

1. 정규식을 통해 특정 파일들만 순회할 수 있음
2. input을 입력받을 수 있음
   1. 적용할 값이나 경로를 유저가 직접 입력하게 할 수 있음
   2. 무려 셀을 눌러 input을 지정할 수도 있음
3. 간단한 셀과 시트 조작과 스타일 적용은 기본이고, 파일 정보 등의 메타데이터도 활용 가능
4. http request 보낼 수 있음. 다른 프로그램 실행 가능

정말 별의별 것이 다 가능하고, 덕분에 정말 많은 도움을 받았습니다.
 
총 11개의 크고 작은 매크로를 만들었습니다.

1. [VBA] DB Migration을 위한 문서 수정 함수
2. [VBA] 파일 이름을 통해 UI 정의 문서 내 10개 이상의 셀을 채우는 함수
3. [VBA] 폴더 내 모든 엑셀 파일에 대해 2번 함수를 적용하는 함수
4. [VBA] 파일 이름을 통해 프로그램 정의 문서 내 20개 이상의 셀을 채우는 함수
5. [VBA] 프로그램 정의 문서에 적힌 프로그램 ID를 새로 발급된 ID로 고치는 함수
6. [VBA] 폴더 내 문서 이름에 적힌 문서의 버전을 모두 바꾸는 함수
7. [VBA] UI 문서가 위치한 폴더 이름을 기반으로 어떤 내용을 채우는 함수
8. [VBA] 어떤 cell의 내용에 prefix를 붙이고 camel case로 변경하는 함수 (하루에 수십 번씩 타이핑해야 했다..)
9. [VBA] 기존 cell의 prefix 값을 교체하는 함수
10. [VBA] 지정한 색으로 셀을 칠하는 함수
11. [VBA] 셀의 값을 카멜케이스로 바꾸는 함수 (보통 대문자 스네이크 케이스)

또한 매크로는 단축키 등록이 가능하다는 장점도 있기 때문에,
너무나도 유용하게 잘 사용하고 있습니다. 정말 날개를 달아준 고마운 존재..
 
 

2.3.2 정규 표현식의 힘

 

 
 
입사 전엔 사용한 경험이 거의 없었는데,
Legacy C Code를 분석할 때 정규 표현식의 힘은 정말 엄청났습니다!
 
스크롤을 내리며 특정 패턴을 가진 함수, 변수 할당 등을 찾는 팀원들의 모습을 보았습니다.
충분히 정규 표현식을 통한 검색으로 효율을 높일 수 있어 보였고, 작성해 공유해 드렸습니다.
 

1. 특정 prefix를 가진 struct가 특정 prefix를 가진 멤버를 호출하는 경우를 찾는 정규식
2. 특정 규칙을 가진 이름의 함수의 호출부를 빠르게 찾는 정규식
   (정확히 어떤 이름으로 정의되어 있을지 미리 알 수 없음)
3. 필드에 달린 한글 주석을 찾는 정규식
   (기존엔 전체 프로젝트에 필드를 검색해 주석을 일일이 찾아냈다)

덕분에 분석할 때마다 시간을 아낄 수 있었습니다.
이 또한 GPT님의 은혜로 쉽게 작성할 수 있었습니다.
 
 

2.3.3 기본 jdk와 Apache POI

정말 운이 좋게도 Apache POI가 깔려 있었습니다!
 

 
 
Apache POI 라이브러리는 java로 엑셀 문서를 조작하거나 작성하는 것을 도와줍니다.
사실 엑셀 암호화라는 제약만 없으면 jdk와 Apache POI만 있어도 대부분의 문제는 해결 가능했습니다.
엑셀 파일을 만들고, 셀들을 채우고, 시트를 만들고, 스타일을 입히는 대부분의 행위가 가능합니다!
 
저희는 암호화되어 있기 때문에, 파싱과 조작은 어려웠고
java 프로그램으로 문제를 해결하는 경우 결과를 이쁘게 정리해 드리는 데에 도움을 받았습니다.
팀원들이 가장 익숙하고, 편하게 볼 수 있는 문서 형태가 엑셀이었기 때문입니다.
 
java로 작성한 프로그램은 4개였고, 이 중 2개의 결과를 POI로 정리해 공유했습니다.

1. [프로그램] 1600건 이상의 쿼리가 특정 규칙을 만족하는지 검증
2. [프로그램] Legacy DTO Migration 자동화
3. [프로그램] 프로젝트에서 참조하는 Table들이 특정 컬럼을 갖는지 검증
4. [프로그램] 형상 관리 툴에 push 하는 파일들의 전체 경로 찾기 (직접 찾기 매우 불편했다)

 
 

3. 자동화 툴들로 이루고 싶었던 것

 

함께 자라기 김창준 지음

 

3.1 "공유"로 이루고 싶었던 것

회사에 어느 정도 적응한 작년 5월 부터 벌써 많은 도구를 만들어 사용했고, 공유했습니다.
제가 공유한 이유는 제가 이타적인 행동을 즐기는 선인이라서가 아닙니다.
이러한 툴들을 공유한 동기는 이기적인 동기에서 왔습니다.

1. 내가 만들어낸 무언가가 다른 사람에게 쓰이는 것을 좋아한다.
2. 다른 사람에게 도움이 되는 것을 좋아한다. (네이버 지식인 "고수" 등급 출신 ㅎㅎ)
3. 서로의 효율을 높이기 위해 도움을 주고받는 문화가 형성 됐으면 좋겠다.
4. 더 많은 사람이 쓸수록 내가 만든 도구가 더 효율적인 도구가 된다.
   (자동화 툴의 효율은 "제작 시간" 대비, "아끼게 되는 시간"인데, 제작 시간은 고정이므로, 더 많은 사람이 써서 더 많은 시간이 아껴질수록 유용했던 툴이 된다.)

 
1번은 인정 욕구와 관련 있다고 생각합니다.
전자공학부 학생 시절 처음 개발을 시작하게 된 계기도 “사람들에게 재미를 주는 게임을 만들고 싶다”라는 어린 시절 꿈에서 시작했습니다.
웹 개발자인 지금도 다른 사람들에게 도움이 되거나, 재미를 주는 무언가를 만들어낼 때 행복감을 느낍니다.
[최근 만든 툴 홍보] 인텔리제이를 사용하다가 머리가 복잡해진 경험이 있다면?
 
이런 기분을 회사 안에서도 느껴보고 싶었습니다.
내가 만든 도구를 사람들이 사용하고, 업무에 도움이 된다면 정말 좋겠다는 생각을 했습니다.
실제로 누군가 잘 쓰고 있다고 말씀해주실 때마다 큰 뿌듯함을 느낍니다.
 
 
3번은 더 이기적인 동기입니다.
매크로 도입 시 효율이 매우 높아질 것으로 기대될 때, 누군가 이미 만들어 둔 게 없는지 찾아보곤 했습니다.
사실은 저도 누군가 먼저 만들어 줬으면 좋겠다고 생각했을 때도 많았습니다.
 
하지만, 발견한 툴은 0개였습니다.
 
SI 프로젝트는 어느 정도 패턴화 되어 있고, 작성해야 하는 문서는 대부분 정해져 있는데 왜일까요?
제가 특별히 뛰어나서 자동화 도입 포인트가 보이고, 저만이 그걸 작성할 능력이 있는 걸까요?
절대 아니라고 생각합니다.
 
제가 알아낸 사실은
단순히 도구들 뿐만이 아니라, 개개인이 알아낸 좋은 정보와, 더 나은 방법들이 전혀 공유되지 않는다는 사실을 알게 되었습니다.

 

3.2 "노하우"라는 단어가 주는 아픔
 

<쉿! 너만 알고 있어 - 박현숙>

 
 
이들은 “노하우”라는 이름으로 친분이 있는 소수나, 파트라는 10명 내외 규모의 단위에만 공유되고 있었습니다.
(프로젝트 참여 인원은 보통 100 ~ 300여 명)
 
지금은 “노하우”라는 단어만 들어도 가슴이 아픕니다.
 
각자 시행착오를 반복해 겪을 것이 아니라, 서로의 실패와 성공을 공유하고, 머리를 맞댄다면
똑같은 시도와 똑같은 실패를 최소화할 수 있지 않을까요?

또 누군가 그 방법에서 좋은 아이디어를 얻어 더 멋진 방법을 발견할 수도 있지 않을까요?

 

왜 이런 분위기가 형성 되었을까 자주 고민하고, 곧 은퇴할 나이가 되어가는 선배님들께 여쭈어 봤습니다.

결국 “정보나 툴 공유자는 칭찬과 장려 대신, 심리적 압박과 책임을 요구받았다”가 원인으로 추측됩니다.
저도 그런 압박을 느껴봤고, 여기서 모든 아픔이 출발했을 것입니다.

 
아마도 이런 흐름이었을 것 같습니다.

1. 공유자는 자기 시간을 쓰고, "심리적 압박과 책임"을 받으면서도,
   작업량과 경력으로 급여가 평가되는 SI 특성상 딱히 더 나은 평가를 받진 않았다.
2. 선의의 공유자들은 자연스럽게 주도적 기여와 공유를 꺼리게 된다.
3. 다른 구성원들 또한 공유에 대해 긍정적으로 생각하기 어렵게 된다.
4. 공유하지 않는 것이 당연한 세상이 온다..
5. 다른 이에게 도움을 받은 경험이 없는 사람들이 많아지고, 이들은 자연스럽게 공유의 동기를 못 느낀다.
6. 자동화 함수나 툴 또한 누군가 만들어 주는 일이 적어지고, 경험도 듣기 어려워진다.
   그러니까 그 툴들이 실제로 얼마나 효용이 있는지, 제작엔 얼마나 걸리는지 추측하기 어렵게 되고, 시도조차 하지 않게 된다.

 

법륜 스님 유튜브

 
자연스럽게 무서운 생각이 자리 잡지 않았을까 싶습니다.

• "자발적으로 무언가 만들어 공유한다고 해서 딱히 큰 이득이 있진 않네.."
• “이건 나만의 노하우인데..”
• "나한테도 누가 알려주진 않았잖아"
• "다른 사람들이 하지 않는 데는 이유가 있겠지"

3.3 공유하는 조직 만들기!

이미 오랜 시간 문화가 자리 잡혔고, 저는 이 판(?)에서 영향력 있는 사람도 아니었습니다.

그렇다고 영향력 있는 자리에 오르기까지만을 기다리는 것은 싫었습니다.

내 주변이라도 조금씩 바꿔보고 싶었습니다. 나를 위해서, 우리 팀을 위해서..

 

이 많은 사람 중 몇 명이라도 감염시킬 수 있다면 그 몇 명이 살아가며 다른 몇명을 감염 시키고..

또 그렇게 퍼져나가길 기대했습니다. 

제가 생각한 선순환은 아래와 같습니다.
 

1. 내가 먼저 유용한 정보와 유용한 툴을 공유한다.
   + 필요한 경우 이것이 왜 유용한지, 만드는 데엔 얼마나 걸렸는지 공유한다. (최근 시도 중)
2. 누군가 유용하다고 느낀다면, 나와 비슷한 동기로 툴을 만들거나 정보를 공유하는 사람이 생길 것이다.
3. 그런 사람이 생겨나면, 공개적으로 긍정적 피드백을 마구 보내서 이런 공유 행위는 모두에게 도움되고, 뿌듯한 일이라고 인식하게 한다!
4. 감염된 사람들은 또 다른 사람을 감염시키며..
   -> 모두가 스스로 자신의 노하우를 공유하는 세상이 온다!

이러한 흐름을 상상하며 저만의 “공유하는 조직 만들기에 기여하기” 프로젝트가 시작됐습니다.
 
처음엔 작은 단위에서 시작했습니다. 옆자리 동료로 시작해서, 매일 커피를 사러 나가는 동료, 10명 내외의 작은 단위에 공유했습니다.
좋은 반응을 얻고, 용기 내어 프로젝트 개발자 전체 공유도 시도했습니다.
 
저번 프로젝트에선 자동화 툴 하나와 Spring Batch 가이드문서 하나를 공유했었습니다.
 
아쉽게도 처음 용기 내어 공유했던 당시엔 반응이 거의 없어 주춤했으나,
몇 달 뒤 여러 사람들이 도움을 받았다는 후일담을 듣게 되었고, 다시 용기가 났습니다.

 

이때는 시간이 없어 제대로 영향을 미치지 못했지만,
지금 프로젝트는 시간이 많으니 천천히 파트 단위에서부터 시도해보고 있습니다.
 

4. 신뢰와 설득에 대한 고민

신입 개발자로서, 이러한 자동화 툴들을 만들고 공유하는 과정에서, 신뢰와 설득에 대해서도 많이 고민할 수 있었습니다.
 
호기롭게 전체 개발자 톡방에 직접 작성한 가이드 문서와 툴을 공유했으나, 반응은 없었습니다.
제가 만든 도구나, 공유한 정보들은 신뢰를 얻기까지 제법 오랜 시간이 걸렸습니다.
 
그 원인은 무엇일까요?
 

4.1 논리야 놀자!

<논리야, 놀자 - 위기철>

 
 
그때의 저는 논리가 설득의 가장 큰 요소라고 생각했습니다.
 
처음으로 업무 시간에 자동화 툴 구현을 제안했을 때입니다.
문서 수백 개를 2명이서 5일 동안 수정해야 하는 상황이었습니다.
저의 주장은 아래와 같았습니다.

1. 수정 규칙이 명확하기 때문에 코드로 해결할 수 있다.
2. 개수가 너무 많아서 직접 하는 게 너무 힘들다.
3. 완전 자동화가 걱정되면,
   실제로 VBA가 수정한 문서만 정리해서 수정된 부분만 눈으로만 확인할 수 있게 조치할 수 있다.
4. (아마도) 하루 안에 구현할 수 있다.

 
저의 생각엔, 이 문제를 프로그래밍을 통해 해결하는 것이 매우 효율적일 것으로 생각됐습니다.
좋은 아이디어라며 칭찬을 받게 될 것을 기대했으나,
실제로는 많은 우려들을 만나게 되었습니다.

1. 제안한 프로그램이 실제로 구현 가능한 건지?
2. 신입이 작성해 온 프로그램이 의도대로 동작할지?
3. 실제로 하루 안에 가능한지? (3일 정도 소요될 것으로 생각하신 것 같다)
   -> 직접 작업하는 것보다 더 비효율적이진 않을지에 대한 걱정

 
저는 합리적인 제안을 했다고 생각했습니다. 하지만 왜 쉽게 설득하지 못했을까요?
제가 갖는 확신을 왜 동료에겐 주지 못했을까요?
 
이 우려들은 전부 어디서 온 것일까요?
 

4.2 SI 프로젝트와 신뢰에 대한 생각

많은 고민 끝에, 모든 우려들의 원인을 아래와 같이 추측했습니다.
 
"금융 SI 환경은 프로젝트 경험이 없는 신입 구성원을 신뢰하기 어려운 환경이다."
 
이렇게 생각한 이유는 아래와 같습니다.
SI 프로젝트 팀들은 아래와 같은 상황에 놓여 있습니다.

1. 수개월 혹은 연 단위로 팀원이 바뀌게 된다.
2. 팀원이나 팀 매니저가 직접 팀원을 뽑지 않는 경우가 많다.
3. 급여가 연차나 경험과 큰 연관이 있다.
   또한 금융 프로젝트는 고연차, 높은 직위의 인원이 많은 편이다.
4. 대부분의 코드나 프로젝트가 비공개로, 이 사람이 작성한 코드를 확인하기 어렵다.

 
이러한 상황 속에서 SI 프로젝트 인원들은 어떻게 사람을 신뢰할 수 있을까요?
아래 4가지 요소에 크게 의존할 수밖에 없다고 생각했습니다.

1. 이미 신뢰가 쌓인 사람의 평가
2. 어떤 프로젝트를 몇 번 경험했는가?
3. 직접 눈으로 보고 느낀 점들
4. 개발자의 연차, 등급, 직위

 
그리고 저는 아래와 같은 조건을 가지고 있었습니다.

1. 팀 매니저가 아닌, 회사 HR 조직이 대신 뽑아줬다.
   (3,500명 규모의 회사에 재직 중이고, 채용 과정에서 팀원들의 그림자도 보지 못했습니다.)
2. 믿을 만한 사람의 평가 전혀 없음
3. SI 프로젝트 투입 경험 없음
4. 0년 차 신입 개발자

당장 신뢰하긴 어려운 사람인 것이지요.
실제로 투입 이후, java나 javascript를 단 한 번이라도 써 보았는지에 대한 우려 섞인 질문을 여러 번 받았습니다.
창업 팀에서의 경험이나, 여러 프로젝트 경험을 공유해 드려도 "큰 프로젝트" 경험이 없다는 점에서 우려를 표하시는 분이 여전히 많으셨습니다.
 
결국 신뢰 자산이 쌓이기까지 시간이 걸릴 수밖에 없는 상황이었습니다.
천천히 시간을 들여 잘하는 모습을 보여드리고, 신뢰를 쌓아야 했습니다.
 
하지만 그러한 인지 없이 구성원들에겐 다소 낯선(?) 제안들을 신입 구성원이 퍼부었기 때문에,
팀원들은 걱정을 품을 수밖에 없었다고 생각합니다.

1. 신입사원이 만들었다는 이 툴이 제대로 동작할지?
2. 신입사원이 과연 빠르게 만들 수 있었을지?
   -> 그냥 직접 작업하는 것보다 더 비효율적이진 않았을지?

 
이는 환경을 고려했을 때 당연한 우려라고 생각합니다. 그들은 저 때문에 괴로웠을 것입니다.
다양한 글들을 읽으며 이런 신뢰 자본에 대해 인식할 수 있었고,
제가 팀원들에게 줬던 우려가 어디서 왔는지 고민해 볼 수 있었습니다. 
 

• [도서] 함께 자라기

함께 자라기

 

• [아티클] 신뢰 자본 - 기억보단 기록을 by 향로

신뢰 자본

 
 
 
다행히도 함께 하는 시간이 길어지며 신뢰를 쌓았고,
“실제로 잘 돌아가는 것”을 여러 번 보여드리면서 프로젝트 후반에는 직속 매니저님께서 먼저 “이 문제를 프로그램으로 해결할 수 있는지” 물어봐 주시곤 했습니다.
 
프로젝트 후반부에는 설득하기가 매우 쉬웠습니다.
설득에 있어 신뢰 자본이 논리만큼 중요하다는 것을 다양한 글들을 통해 배우고, 직접 느꼈습니다.
 

4.3 지금 시도 중인 것들

이러한 교훈들을 통해 현재 투입된 두 번째 프로젝트에선 조금 다르게 접근해보고 있습니다.

1. 더 작은 단위에 공유하기
2. 더 작고 가벼운 도구부터 공유하기
3. 만드는 데에 걸리는 시간 공유하기 (생각보다 오래 걸리지 않아요~)
4. 최대한 업무시간 외의 시간만 활용했다.

옆 자리 동료, 10명 규모의 파트에서 시작합니다.
작은 도구인 정규식들부터 공유하기 시작했습니다.
레거시 코드를 분석하기 위해 몇백 줄의 코드를 직접 스크롤하는 팀원들을 위해, 찾고 있는 대상을 빨리 찾는데에 도움을 주었습니다.
 
또한 매크로 제작에 걸리는 시간을 우려하시는 경우, 만든 시간과 업무 외 시간 동안 간단하게 만들었음을 공유했습니다.
 
또한 제가 손이 빠른 것이 AI의 도움을 받아 쉽고 빠르게 만들 수 있다는 점도 강조했습니다.
누구나 할 수 있는 것이고, 간단하게 효율을 개선할 수 있다는 점을 천천히 공유하고 있습니다.
 
물론 이번 프로젝트에서도 똑같은 우려를 만났습니다.
하지만 더 빨리 신뢰를 쌓을 수 있었습니다.
 
작년 프로젝트보다 더 짧은 시간 안에 우려보다 고맙다는 이야기를 더 많이 듣게 되었고,
 
저의 매니저께서 다른 분 게 저의 매크로를 사용해 보라고 권하는 일도 있었습니다.
 
추후 작은 파트의 단위를 넘어 프로젝트 단위로 신뢰를 얻어,
“공유하는 문화에 기여하기 프로젝트”를 성공시키는 게, 이번 프로젝트에서 저만의 작은 목표입니다.
 

5. 후기

지난 8개월간 많은 도구들을 만들고 공유했습니다.
문제를 해결하기 위해 만들고, 나누는 문화를 만들고자 공유했습니다.

그리 대단한 것들은 아니었지만, 뿌듯함과 자신감을 주는 경험이었습니다.

제가 만든 도구나, 직접 공유한 정보로 인해 누군가에게 도움이 되는 일은 항상 즐거운 경험입니다.
 
하지만 어려운 점도 많은 것이 사실입니다.
제가 존경하는 부장님 한 분은 오랜 시간 저와 비슷한 고민을 했었지만, 여러 가지 한계를 만나셨다고 합니다.

그분은 지금도 자발적으로 시간을 내어 주니어들을 교육시켜 주시는 멋진 분입니다.

제가 받는 심리적 압박들에 대해 공유드리니 공감해 주셨고,
“그런 압박들을 앞으로도 계속 받게 될 거야. 그런 활동을 하는 사람은 전부 감내할 수 있어야 해”라는 말씀을 해주셨습니다.

이 말이 종종 생각납니다.

• 조직과 조직원들을 돕는 일인데, 어째서 응원이 아닌 심리적 압박을 감내해야 할까요?
• 더 영향력 있는 사람이 되고, 더 신뢰 받는 사람이 되면 해결될까요?
• 누군가의 말 처럼 이러한 노력들은 다 부질 없을까요?
• 어떻게 하면 모두가 자신의 시행착오를 기꺼이 나누는 문화를 형성할 수 있을까요?

 
이러한 의문들에 대한 답을 찾기 위해 2025년도 열심히 고민하고 공유하려 합니다.
제가 매니저가 된다면, 누구나 기꺼이 자신의 시행착오를 공유하는 조직을 만들어 보고 싶습니다.

 

그러기 위해서 앞으로도 여러 경험을 쌓고, 고민하고, 시도해보려 합니다.
읽어주셔서 감사합니다